■中国农业银行研发中心 刘跃光 冯 瑶

一、传统功能测试面临挑战

随着金融系统软件复杂度的持续提升，传统的基于人对业务理解的经验型测试方法面临着巨大的挑战。由于敏捷迭代引起的回归测试工作量远超瀑布模式，开发与测试岗位技能不同，以及测试过度依赖人的经验等原因，功能测试的充分度越来越难以保证。在此背景下，金融系统软件测试及开发过程中存在如下问题。

一是开发人员与测试人员之间的交互和沟通存在壁垒。在功能测试阶段，测试人员通过黑盒测试方法对待测系统进行测试，由于无法知晓程序内部逻辑，通常发现缺陷的处理流程是：测试人员发现缺陷后向开发人员反馈，由开发人员进行问题复现，通过debug等方式找到故障代码段。在这个过程中，由于开发和测试人员的岗位技能和知识储备不同，双方通常需要反复沟通才能定位缺陷，查找和修复缺陷的成本高。

二是回归测试的精准性难以保证。在项目测试中，修改项目代码后，往往需要对关联的测试案例进行回归测试。然而，如何找到关联度最高的测试案例，往往需要通过人工筛选来判断，回归测试的准确度高度依赖于测试人员的经验。

三是黑盒测试的充分性难以衡量。功能测试往往采用黑盒的方式实施，在测试过程中，测试人员无法直观地看到测试用例与代码的关联，以及用例对源代码的覆盖程度，测试充分性缺乏明确的度量指标作为依据。功能用例设计容易产生遗漏，很难发现代码中隐藏的缺陷。

四是测试执行结果可信度较低。现有功能测试的人力投入大，但测试经理并没有一种有效手段去获取测试人员的测试记录。所以，亟待一种能够真实记录测试执行过程的辅助监控手段，可以向测试经理给出可信的数据分析结果，防止伪造和篡改测试执行数据带来的测试管理困难。

二、精准测试概念及相关技术

（一）精准测试概念

精准测试是一种应用于黑盒测试方法的代码级测试覆盖技术，与传统的白盒测试开展代码覆盖测试不同，它将黑盒测试和白盒测试进行了有机结合，通过获取测试用例和代码逻辑之间的关联信息，可以获得白盒测试级的代码覆盖率数据，并实现双向追溯统计，从而达到“精准测试”的目的。这个“精准”主要体现在：一是在测试执行过程中，获取和收集底层代码运行数据，能够可视化地看到代码执行情况（代码执行充分度），进而为补充或减少冗余用例提供依据。二是通过对变更代码的识别，可精准圈定需要回归测试的用例范围。三是对发现的缺陷，通过测试用例可间接实现对代码的精准定位，在此过程中，需要用到统计代码覆盖率、代码插桩、连接代码和测试用例、测试用例智能选取、智能缺陷定位等技术。

（二）相关技术

1.代码覆盖率。代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。最常用的度量代码覆盖率有四种方式。

（1）语句覆盖：又称行覆盖。语句覆盖率指已经被执行到的语句占总可执行语句的百分比。这是最常用也是要求最低的覆盖率指标。实际项目中通常会结合判定覆盖率或者条件覆盖率一起使用。

（2）判定覆盖：又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否各被覆盖至少一次。比如，对于if（a > 0 && b > 0），就要求覆盖a > 0 && b > 0为True和FALSE各一次。

（3）条件覆盖：是指判定中的每个条件的可能取值至少满足一次，度量判定中的每个条件的结果True和FALSE是否都被测试到了。比如，对于if（a > 0 && b > 0），就要求a>0取True和FALSE各一次，同时要求b>0取True和FALSE各一次。

（4）路径覆盖：路径覆盖率=被执行到的路径数/程序总路径数。路径覆盖的目标是选取足够多的测试数据，使程序的每条可能路径都至少执行一次。路径覆盖是覆盖率最高的一种覆盖技术。但对于复杂的程序来说，路径数量巨大，要测试每条路径既困难又费时，几乎是不可能达到100%的。

统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性地进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。我们通常希望代码覆盖率越高越好，代码覆盖率越高越能说明测试用例设计是充分的，但测试的成本也会随着代码覆盖率的提高以类似指数级的方式迅速增加。

2.代码插桩技术。实现代码覆盖率统计的最基本的方法就是代码插桩。代码插桩就是在被测代码中自动插入用于覆盖率统计的探针代码，并保证插入的探针代码不会给原代码带来任何影响。根据插桩对象的不同，可以分为源代码插桩、中间代码插桩、二进制代码插桩三大类。

源代码插桩是通过对代码源文件插入探针进行词法和语法分析。这种方式对应用的源码有侵入式更改。业界比较成熟的源代码插桩工具有GCT等。

中间代码插桩是对如Java编译后生成的.class等中间代码文件进行插桩。首先对中间码文件进行分析，确定需要插桩的位置，再将探针插入到这个文件中。业界比较成熟的工具有Jacoco、Emma等。

二进制代码插桩是对程序真正运行的目标文件进行探针插入操作。业界比较成熟的工具有XDebug等。

3.构建测试用例与代码关系。测试人员在进行黑盒测试的过程中，精准测试工具捕获测试用例步骤关联的函数和相应的调用关系信息，将测试用例、用例相关函数信息、关联函数调用关系信息存储起来形成知识库。而形成知识库的过程，对测试人员和开发人员来说是透明的。构建测试用例与代码关系的过程见图1。

图1 构建测试用例与代码关系

4.回归测试用例精准选取。测试用例智能选取可根据程序的变动情况对测试用例的优先级进行分析和打分，筛选出优先需要执行的重要用例。使用智能回归测试用例选取功能算法的前提是至少需要两个插桩版本的应用程序。在回归测试用例选取的时候，会对比选中的工程版本对应的代码，分析代码版本涉及的函数变化，进而通过函数与测试用例的对应关系，推导出涉及到的测试用例，从而实现回归测试用例的自动选取，大大减少回归测试的时间及风险。

5.测试缺陷精准定位。测试发现的缺陷通常是由开发人员来进行分析和定位的，而精准测试则通过测试用例和代码建立的关联关系，能够将缺陷对应代码出错位置直接定位出来，这相当于增加了测试数据和测试过程的本身价值。因为精准测试技术可以获知每个用例执行的详细路径信息，如果测试人员告知用例状态（例如是否通过、是否正确），那么精准测试算法就会根据正确和失败的路径进行差异计算 ，给出缺陷出现具体位置的可疑度排名，这对于测试人员来说，只要找到类似的输入，程序在输出上有对错区分用例，就可以实现智能定位缺陷功能。

三、精准测试探索及分析

（一）精准测试的实践过程

首先使用一个前置编译器，对某金融系统的被测代码进行静态分析和代码插桩，其中静态分析会产生程序的结构数据（例如控制流数据）以及符号信息（PBD文件）并进行存储，经插桩后的代码通过原有编译系统编译后，发布到被测环境。其次，测试人员通过精准测试客户端运行测试用例，采集器就可以接收每个用例对应的代码执行数据，并记录采集到的插装代码发送的程序运行逻辑编号信息。这些编号和静态分析产生的符号信息是一一对应的，即通过客户端执行完测试用例后就可以达到测试用例和代码关联数据，该数据支持正反向查询。最后，可对测试用例运用深度分析、缺陷定位、用例聚类分析、回归测试用例选取、最小测试用例集合等功能，以报表形式展示测试生成的数据，导出测试报告。精准测试的实践过程见图2。

图2 精准测试实践过程

（二）精准测试技术优点

通过精准测试技术的应用实践，可总结出以下优点：

1.通过精准测试技术可提升测试的充分性。精准测试技术可建立代码与测试用例的关联。通过运行测试用例，可以查看代码覆盖率，得到精准的量化数据。测试人员在完成测试后，开发人员根据精准测试得到的量化数据总结程序中的未覆盖功能点列表，然后由测试人员补充编写测试用例并执行。通过重复此过程来提高测试的充分性。

2.实现了可信的测试管理模式。目前，常规的测试管理方式是人为录入数据，数据本身的真实性无法保证。而精准测试的底层数据来自于执行测试用例时代码执行数据的采集，通过专用接口上传，无法被篡改和伪造。精准测试技术提供的可信测试管理模式非常适用于金融公司对第三方测试团队的管理，在一定程度上解决了测试的真实性问题。

3.可快速定位缺陷所在的代码段，节省缺陷修复时间。测试人员发现缺陷后，不需要再使用传统方式向开发人员说明缺陷出现的场景、数据、环境等信息，开发人员也不需要在开发环境复现和调试。使用精准测试技术，开发人员可以直接看到测试发现缺陷时的代码执行逻辑，并基于此直接定位问题，交互流程和步骤都大为简化。

4.可识别有改动的代码段，更好地开展回归测试。对于敏捷迭代的项目，可识别出每次迭代的变动代码，从而选取出相关的测试用例，节省了回归测试时间，提高了测试效率。

（三）精准测试技术不足

精准测试较传统功能测试在方法上有很大突破，但从技术层面看，该技术还处于发展初期，并不是完美的，通过应用和实践，也发现有以下不足：

1.对于架构较为复杂以及涉及众多外围系统的金融系统项目，插桩和部署采集精准测试数据的监控工具难以实现。通常金融单位部署程序和插桩操作涉及多部门人员，复杂系统由于跨部门、跨平台、无权限、应用服务器数量众多等原因，实施起来难度较大。

2.目前对金融系统常用的技术语言支持有限，不支持C#、node.js、Python等类型的项目。

3.实践应用工具是通过源代码插桩方式，属于侵入式插桩，且需将源代码下载到客户端所在机器，才能查看测试用例和源代码对应关系，这对于保密要求较高金融软件，存在源码安全管理方面的风险。

四、应用精准测试的实施策略

（一）优先使用中间代码或二进制插桩方式

源代码插桩方式对于待测的程序进行了修改，不能做到投产程序与测试程序的统一。同时，由于插桩操作过程可对源代码进行查看，因此保密性较差。中间代码插桩和二进制代码插桩的前提是对目标代码进行词法、语法分析，由于目标代码不是源代码，语法、语义信息并不完整，所以，相较源代码插桩方式来讲，中间代码插桩和二进制代码插桩的技术难度更大。但由于中间代码插桩和二进制代码插桩对源代码不可见并且没有侵入性修改，符合金融系统代码保密性要求和“所测即所投”的理念。因此，在技术允许的前提下应优先使用中间代码插桩或二进制插桩方式进行金融系统的精准测试。

（二）将精准测试技术纳入DevOps流水线统一实施

DevOps遵循精益思想，关注研发技术管理标准化，倡导工具赋能、融会贯通。将精准测试技术相关工具纳入DevOps实施流水线，将改变测试案例与代码孤立的现状，促使开发测试紧密衔接，达到工具贯通、流程贯通、数据贯通的效果，可强化质量管控，提升测试自动化水平。

（三）让精准测试技术满足“双模”研发模式，适应更多敏捷项目

现在越来越多的项目使用敏捷开发模式，由于程序版本迭代很快，通常在某个版本上采集少量覆盖率数据后，新的程序版本就发布了，在此情况下使用传统的白盒测试工具就无法直接统计到新程序版本的覆盖率数据，此时可以借助精准测试中的累计覆盖率来解决这个问题，将多个版本的代码覆盖率以最新版本的代码结构进行投影并在控制流上进行累加。测试团队可以结合每个版本的覆盖率以及完整测试周期内所有程序版本的累计覆盖率为参考，来保证项目测试的充分性。

（四）拓展精准测试工具支持开发语言，满足不同项目需要

精准测试工具应支持金融系统中多种编程语言，如 Rule、C#、Python、Node.js、Scala、Go 等，以便为更多的复杂应用系统提供自动化测试解决方案。

五、测试展望

在数字化转型时代背景下，金融科技及金融产品创新与迭代加速，分布式、微服务、集群化的IT架构给软件测试带来了前所未有的挑战，通过测试技术、测试方法创新来应对这些挑战，无疑是正确和可行的措施之一。精准测试将黑盒测试与白盒测试进行了有效结合，解决了传统测试的一些痛点，能够有力地提高测试质量和效率，是值得推广和应用的。

展望未来，在精准测试的基础上，实现智能（AI）测试也是可期和可以实现的。软件测试从手工测试→自动化测试→测试自动化→精准测试→智能测试，是一个逐渐演进的过程，在这个过程中，测试人员所需要做的就是提升能力，拥抱变化。