随着金融科技的不断发展与创新，大数据人工智能、云计算等技术在金融领域的应用日益深入，数字金融领域不断涌现出物联网和数字货币等新兴场景。这无疑加剧了各个银行之间的竞争，谁能推出时效性高、创新性高、体验性好的产品，谁就能在市场取得先机。这一趋势无疑对金融系统安全带来了巨大的挑战，也对提出了更高的要求。

　　测试作为产品研发生命周期的重要一环，在质量保障上已经扮演了越来越关键的作用。手工测试因投入大，效率低等弊端，已经逐渐无法满足金融科技背景下产品快速迭代的需要。通过各项技术开展自动化测试是金融科技背景下银行测试的必经之路。

　　自动化测试简介与分类

　　自动化测试是指把以人为驱动的测试行为转化为机器执行的一种过程。通常，自动化测试可以应用于功能测试中的各个流程，包括单元测试、集成测试、功能测试、验收测试以及后续的回归测试。自动化测试为适应不同系统的不同要求，也可分为接口自动化测试与界面自动化测试。为适用于不同场景，自动化测试可扩充为案例自动化设计、案例自动化执行、案例测试结果自动化比对、案例报告自动化生成。以上概念均有比较成熟的定义与介绍，在此不再赘述。

　　银行业自动化测试应用

　　金融领域的测试与其他行业软件测试区别主要包括：面临更加严格的监管、对系统可靠性要求高、数据量大等特点。以下将以接口自动化、界面自动化以及案例测试结果自动比对三个方面的案例进行介绍。

　　一、接口测试执行自动化

　　在银行系统底层代码逻辑进行优化与升级时，通常需要对全量的交易功能开展大规模的回归测试。如果手动执行这些测试，短期内根本无法完成。测试人员可以通过API接口自动化用例的执行，来完成这一测试过程。下面以生产日志回放为例介绍这一过程。

　　测试过程可分为获取测试用例—测试执行—读取测试结果三步。测试用例的获取可以通过生产环境直接获取，由于银行系统保密性的要求，获取数据需要经过脱密后才能使用。

　　然后根据上表请求日志的时间顺序，向程序改造后的测试环境服务器依次发送请求报文。最后，通过编程读取交易的返回判断交易是否成功。

　　以上是接口级自动化的最直接应用。通常接口自动化的案例来源还可以是根据接口编写的案例，这类案例虽然编写门槛较高，但是往往较为稳定，只要接口不发生变动且环境数据相对稳定，就可以重复使用。接口测试自动化通常被使用于比较成熟较少改动的银行系统。

　　二、界面测试执行自动化

　　银行系统在面临监管时，常常有和人行对接的需求。如：人行大小额系统测试。大额支付系统在每个周末或法定节假日期间的首日运行，并执行特殊业务规则：业务受理时间为前一自然日20:30至当日8:30。小额支付系统实行7天×24小时连续不间断运行。由于所有银行均需要与人行的大小额测试环境进行对接，故即使是测试环境，人行的会计日期不能也不能随意更改，只能随自然日变动。

　　在案例设计时，大量案例的执行时间需要在周末、节假日、下班时间，若采用手工测试，需要人员加班才能开展。我们在项目实操中使用了与手工提交最为接近的界面自动化测试，通过定时执行案例，在非工作时间，自动开展测试工作。测试人员只需要在工作时间通过查看执行结果即可了解执行的详细情况，避免了非工作时间的加班，极大提升了效率。

　　使用UIAutomation界面自动化基本分为要素录制—案例编写—执行

　　要素录制：一般使用微软UI Spy工具，即可获得ClassName、Name和窗口信息。后面使用工具来读取这些要素时，需要靠这些属性定位这些要素的位置。

　　案例编写：界面用例的编写可以通过执行工具来实现对要素的控制。例如：

　　执行：直接利用界面自动化测试工具，在定时的时间发送编写的案例即可。自动化工具会先定位到预录制的要素定位，然后通过根据工具预设的“输入”“点击”等命令实现对要素的操作。此时，执行案例可以跨越时间的限制，在非工作时间不断自动化发起交易，完成测试执行。

　　界面自动化能发挥“最类似手工提交”的特点，编写和执行门槛低，完成测试可行度高。但由于案例本身可复用程度低，且容易受到硬件等多方制约，所以维护成本较高。

　　三、案例测试结果比对自动化

　　银行系统会经历周期性的系统联通性升级改造，此类改造通常不会改变顶层代码逻辑，甚至不会改造代码，往往只是将系统直接的通信方式进行了改造，此类改造的原理图大致如下图所示。这类改造涉及的范围广，由于所有交易（或大量指定交易）的通信方式均由A切换成B，从而会影响该系统的全部功能；但是由于被测系统程序并没有发生变动，测试通过准则相对较低，仅需要将全部功能进行通过性检验即可。

　　与上文所提到的接口自动化不同的是，所谓的通过性检验，不仅是有返回报文，更需要对改造前后返回报文的一致性进行检查。如果说人工测试执行只是效率较低下的话，人工比对返回结果更会出现准确性的问题。自动化的结果比对可以高效、准确、有针对性地完成案例结果自动分析的作用。

　　整个过程可以分为读取—解析—比对三步。首先，将执行完毕的返回报文Response1与返回报文Response2保存入数据库表格中。如下图所示，关键部分为Response1与Response2的一致性比对。

　　然后，对于Response1与Response2需要一致的交易，如查询类交易，可以跳过解析，直接进入比对一步。如上图中第一列的两个返回报文，其Response1与Response2内容完全一致，可以直接作为两个字符串作为比较，如果完全一致，则测试通过。

　　最后，对于金融性交易，返回结果往往不一致，如：返回的流水号不一致，余额不一致。这时候需要我们将报文里的字段均解析出来，跳过这些内容。如下如所示，虽然两个Response都是“交易成功”，但是返回的请求流水号<ReqSeqNo>以及余额<Balance>却不一致（相当于前后两次交易，余额不一致）。强行对整个报文进行比对，会发生报错，需要进行处理后进行逐字段比对。

　　处理完后的记录如同下图所示。我们只要跳过流水号<ReqSeqNo>和余额<Balance>这两个本身就不同的字段，只比对其他核心字段，就可以准确的进行通信方式A和通信方式B的返回报文的比对，避免系统误报错。这类比对方法不仅效率远超人工，更是避免了人工比对看错、不仔细的问题，让准确率有了很大的保证。

　　银行业自动化测试优势分析

　　通过以上三个实例可以简单归纳出银行业自动化测试能够显著解决三种传统人工测试的制约：数量制约、时间制约、质量制约。

　　数量制约：自动化测试使得大规模回归测试变得的更加便捷。一般而言，系统在投产上线后会经历多次优化改造，回归测试量大、任务重，但是回归测试结果是可以提前设定的预期值，可以自动判断执行成功与否。通过提前编写自动化测试用例，或者将直接生产日志处理后回放等手段，来实现后续的多次执行。这种方法可以打破回归测试数量制约，每一次都能扩大测试范围，实现全量回归，从而提升系统可靠性。

　　时间制约：在银行业的测试中，某些场景需要在非工作时间内进行，甚至7X24小时不间断测试。手工测试实现的代价大，人力投入高。引入软件自动化测试就如同实体产业引入自动化流水生产线一样，能够实现全天候的开展测试工作。测试人员仅需要如同质检员一般在工作时间查看自动测试结果，进行结果分析和bug提交。

　　质量制约：由于自动化测试从执行到结果保存和比对都是自动执行的，可以有效的避免手工提交出现的“点错”、“看错”等问题。自动化测试还能保证每次测试的执行内容和测试结果的一致性，进一步提升测试结论的可靠性。

　　小结

　　银行信息始终拥有结构复杂、关联系统多、数据量庞大和安全性要求高等特点。作为测试人员，在应对高风险的测试工作时，需要拿出的的更加有保障的测试手段。加之金融科技的浪潮袭来，提高测试效率也成为了必须的工作要求。自动化测试正是应对金融科技的一份答卷。在测试工作中，不断研究和实践各类自动化技术，引入行业优秀自动化测试工具，有助于达到事半功倍的效果。

作者：梁珺凯   

来源：51Testing软件测试网原创