摘要：随着金融科技的不断发展与创新，大数据人工智能、云计算等技术在金融领域的应用日益深入，数字金融领域不断涌现出物联网和数字货币等新兴场景。这无疑加剧了各个银行之间的竞争，谁能推出时效性高、创新性高、体验性好的产品，谁就能在市场取得先机。这一趋势无疑对金融系统安全带来了巨大的挑战，也对提出了更高的要求。
测试作为产品研发生命周期的重要一环，在质量保障上已经扮演了越来越关键的作用。手工测试因投入大，效率低等弊端，已经逐渐无法满足金融科技背景下产品快速迭代的需要。通过各项技术开展自动化测试是金融科技背景下银行测试的必经之路。
自动化测试简介与分类
自动化测试是指把以人为驱动的测试行为转化为机器执行的一种过程。通常，自动化测试可以应用于功能测试中的各个流程，包括单元测试、集成测试、功能测试、验收测试以及后续的回归测试。自动化测试为适应不同系统的不同要求，也可分为接口自动化测试与界面自动化测试。为适用于不同场景，自动化测试可扩充为案例自动化设计、案例自动化执行、案例测试结果自动化比对、案例报告自动化生成。以上概念均有比较成熟的定义与介绍，在此不再赘述。
银行业自动化测试应用
金融领域的测试与其他行业软件测试区别主要包括：面临更加严格的监管、对系统可靠性要求高、数据量大等特点。以下将以接口自动化、界面自动化以及案例测试结果自动比对三个方面的案例进行介绍。
一、接口测试执行自动化
在银行系统底层代码逻辑进行优化与升级时，通常需要对全量的交易功能开展大规模的回归测试。如果手动执行这些测试，短期内根本无法完成。测试人员可以通过API接口自动化用例的执行，来完成这一测试过程。下面以生产日志回放为例介绍这一过程。
测试过程可分为获取测试用例—测试执行—读取测试结果三步。测试用例的获取可以通过生产环境直接获取，由于银行系统保密性的要求，获取数据需要经过脱密后才能使用。
然后根据上表请求日志的时间顺序，向程序改造后的测试环境服务器依次发送请求报文。最后，通过编程读取交易的返回判断交易是否成功。
以上是接口级自动化的最直接应用。通常接口自动化的案例来源还可以是根据接口编写的案例，这类案例虽然编写门槛较高，但是往往较为稳定，只要接口不发生变动且环境数据相对稳定，就可以重复使用。接口测试自动化通常被使用于比较成熟较少改动的银行系统。
二、界面测试执行自动化
银行系统在面临监管时，常常有和人行对接的需求。如：人行大小额系统测试。大额支付系统在每个周末或法定节假日期间的首日运行，并执行特殊业务规则：业务受理时间为前一自然日20:30至当日8:30。小额支付系统实行7天×24小时连续不间断运行。由于所有银行均需要与人行的大小额测试环境进行对接，故即使是测试环境，人行的会计日期不能也不能随意更改，只能随自然日变动。
在案例设计时，大量案例的执行时间需要在周末、节假日、下班时间，若采用手工测试，需要人员加班才能开展。我们在项目实操中使用了与手工提交最为接近的界面自动化测试，通过定时执行案例，在非工作时间，自动开展测试工作。测试人员只需要在工作时间通过查看执行结果即可了解执行的详细情况，避免了非工作时间的加班，极大提升了效率。
使用UIAutomation界面自动化基本分为要素录制—案例编写—执行
要素录制：一般使用微软UI Spy工具，即可获得ClassName、Name和窗口信息。后面使用工具来读取这些要素时，需要靠这些属性定位这些要素的位置。
案例编写：界面用例的编写可以通过执行工具来实现对要素的控制。例如：
执行：直接利用界面自动化测试工具，在定时的时间发送编写的案例即可。自动化工具会先定位到预录制的要素定位，然后通过根据工具预设的“输入”“点击”等命令实现对要素的操作。此时，执行案例可以跨越时间的限制，在非工作时间不断自动化发起交易，完成测试执行。
界面自动化能发挥“最类似手工提交”的特点，编写和执行门槛低，完成测试可行度高。但由于案例本身可复用程度低，且容易受到硬件等多方制约，所以维护成本较高。
三、案例测试结果比对自动化
银行系统会经历周期性的系统联通性升级改造，此类改造通常不会改变顶层代码逻辑，甚至不会改造代码，往往只是将系统直接的通信方式进行了改造，此类改造的原理图大致如下图所示。这类改造涉及的范围广，由于所有交易（或大量指定交易）的通信方式均由A切换成B，从而会影响该系统的全部功能；但是由于被测系统程序并没有发生变动，测试通过准则相对较低，仅需要将全部功能进行通过性检验即可。
与上文所提到的接口自动化不同的是，所谓的通过性检验，不仅是有返回报文，更需要对改造前后返回报文的一致性进行检查。如果说人工测试执行只是效率较低下的话，人工比对返回结果更会出现准确性的问题。自动化的结果比对可以高效、准确、有针对性地完成案例结果自动分析的作用。
整个过程可以分为读取—解析—比对三步。首先，将执行完毕的返回报文Response1与返回报文Response2保存入数据库表格中。如下图所示，关键部分为Response1与Response2的一致性比对。
然后，对于Response1与Response2需要一致的交易，如查询类交易，可以跳过解析，直接进入比对一步。如上图中第一列的两个返回报文，其Response1与Response2内容完全一致，可以直接作为两个字符串作为比较，如果完全一致，则测试通过。
版权声明：本文出自《51测试天地》第六十期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任
