1.参与需求评审业务，开发，测试三者看似是不同的个体，但实际上的工作是紧密相连的。测试人员往往在开发阶段才拿到业务需求说明书开始编写测试案例，这无疑会降低测试效率。需求评审环节有助于快速全面了解客户需求，它会节省后续测试人员了解业务需求的时间，并且测试重点难点都可以借此机会在会上阐明，经过讨论找到解决方法。2.借助业务流程图编写测试案例对于一些比较复杂的需求，由于其分支路径较多，测试时容易忽略个别情况。这时尽量根据业务需求绘制业务流程图，或者询问开发人员在编码时是否有参考相关业务流程图。业务流程图能够直观清晰的表现出各个分支路径的情况，有效的避免了测试案例不全面的现象。例如，我在进行对公账户冻结相关交易优化的测试工作时，根据短短几行的业务需求，绘制出了及其复杂的业务流程图。下图是简易版本，着重描述了部分冻结强制扣划分支的业务逻辑，相关公式和数字用字母替代。对于这样的需求，如果不绘图或者制表，很难设计出全面且正确的测试案例。但是经过和业务人员、开发人员讨论，确定详细的业务流程图后，测试案例的编写自然而然不会有任何遗漏。所以，对于多分支的业务需求，应该善于绘图，利用图表明确测试思路。3.业务关联系统分析在测试领域，关联系统分析不充分是发生变更的重要原因之一。服务方系统接口有变动，相关消费方系统调用该接口的功能都要根据情况有所调整，或者进行全量回归。因为跨系统调用，往往涉及多个开发人员，大家对彼此的系统了解度不够，进行关联性分析时要格外严谨。4.完整的业务场景业务流程往往会形成一个闭环，开户-启用-销户、冻结-续冻-解冻、签约-维护-解约，因此业务场景尽量要完整。例如，开销户在设计时逻辑可能会有所差异，在开户时对新开账户和转出账户的客户号一致没有进行判断，但是在支付和销户时却要求客户号一致才能进行交易，因此存在可以开户但是不能销户和进行其他操作的风险。所以在进行案例设计时，虽然改造点是开户交易或者签约交易，但是应尽量对一个完整的业务流程进行测试工作。5.日期日期在测试时是一个非常重要的因素，也许当天能够做成的交易，切换一下会计日期或者修改一下交易日期就会失败。例如，在测试多级账簿余额调整时，原交易日期为当前会计日期，则交易信息正确，原交易日期小于当前会计日期，则收付款方多级账簿号则显示有误，原因是不同的交易日期对应的程序分支不一样。因此，在设计案例时要充分考虑时间因素对交易的影响，分析是否需要设计各种日期取值。6.缓存数据当对测试数据有严格的要求时，例如涉恐信息，应当注意缓存数据的影响。比如先输入一组有效的数据，进行提交，交易进行到一半时终止交易，这时交易信息不会清空，然后修改为无效的测试数据，再进行提交，则有成功的可能性，而这是与业务需求相违背的。因此，当对输入内容有限制时，应确保缓存数据会及时清空或者更新。7.测试数据类型测试数据种类要丰富，例如本次改造涉及已到期临时户的情况，那么未到期临时户、已到期基本户、已到期一般户、已到期专用户、注册验资户、已到期外汇账户等等都要进行验证。往往缺陷都发生在关联要素上，而不是改造点本身，因为开发人员在编码时只对改造点进行单元测试，而关联要素则容易被忽略。8.凭证回单凭证回单一定要清晰直观，因此在交易成功后需要检查凭证回单的显示情况。重点应检查当交易信息量较大时用省略号替代的交易信息是否为重要信息，比如金额、账号等，以及印章是否会遮挡住部分重要信息，客户签字是否有足够的空间等问题。
彼岸之澄
