文丨中国工商银行业务研发中心 周颖 易蕾 袁亚辉
数字化转型背景下，为进一步提升系统测试效能和服务体验，工商银行业务研发中心深入开展针对灰盒测试的探索与实践，在测试环境复用、风险程序筛查、测试范围定位等领域取得显著成效。基于上述实践，笔者结合测试对象数字化、灰盒化以及高风险接口设计等角度，详细阐述了有效提升验收测试准确度和工作效率的实践路径和方法。
近年来，随着数字化转型的持续推进，银行系统测试整体呈现出时间缩短、风险增大等趋势，传统测试方法已无法充分满足数字化发展需要。以常用的黑盒测试为例，测试人员往往需要耗费较多时间与开发人员反复确认代码改造点、测试范围和重点测试场景等，而沟通过程中一旦存在任何偏差，均可能导致测试进度缓慢、测试精度不足等问题；此外，在白盒测试领域，传统测试方法虽能够较为精准地揭示隐藏代码中的错误和瓶颈，但要求测试人员具备一流的编程技能，且测试案例复杂度及对环境的依赖度较高。为解决上述痛点，工商银行业务研发中心(以下简称“业研中心”)在灰盒测试领域积极开展创新探索与实践，通过引入数字化、灰盒化、透明化等测试方法，显著提高了案例设计精准度，扩大了对高风险场景覆盖面。
一、测试对象数字化实践路径
在实际测试工作中，业研中心将测试对象数字化定义为“将测试对象分解成最小单元(如程序、文件或代码)进行静态扫描解析，记录最小单元的特征值，并通过对收集到的数据进行自动化、智能化分析，协助测试人员做出正确决策”。在此过程中，测试对象主要由开发人员交付，并可进一步分为全量交付和增量交付两种类型。
1.全量交付测试对象数字化
测试对象全量交付是指开发团队的交付物为全量程序和文件，同时包括本期修改内容和未修改内容，该方式在云原生环境下被大量使用，且其中大部分为未修改内容。针对上述特点，业研中心在解析过程中使用了多线程方法来提高交付物的解析效率，并将程序级别的MD5特征值作为程序的唯一标识记录入数据库中(包括应用名、版本号、程序名、记录时间、程序路径和MD5特征值)，在此基础上，即可通过MD5特征值来准确判断不同版本间的同名程序是否发生变化，进而为后续灰盒测试提供数据基础。
2.增量交付测试对象数字化
测试对象增量交付是指开发团队交付物仅包括本期修改内容，该方式无需进行版本间的特征值对比，且交付物中存在的程序即为有改造的程序。值得注意的是，即使当前大部分应用已转型为全量交付，但其数据库变更仍在使用增量交付的方式。对此，业研中心在解析增量交付物时，对数据库变更内容进行了特殊处理，即选择将其中的DDL、DML分别进行解析存储，再结合生产环境统计信息，进行数据库层面的评估和风险控制。
二、基于代码扫描的测试对象灰盒化方法
随着分布式系统架构下的服务数量不断增加，服务调用链路愈发复杂，测试范围不断扩大，对测试覆盖的完整性和准确性提出了新的要求。对此，业研中心基于静态代码扫描，使版本内所有的服务调用链路和服务名均能够被精准获取，进而可辅助测试人员对软件内部结构有清晰的认知，达到测试对象灰盒化的目的，提高案例设计的精准度。
从技术角度来看，服务调用链路描绘了各服务之间的调用关系(包括应用间的服务调用与应用内的服务调用)，清晰准确的服务调用链路不仅能够帮助测试人员缩短排查测试问题的时间，还能为测试人员提供测试是否全面覆盖的客观指标。举例来说，在Dubbo微服务框架下，服务提供者需要在provider.xml中注册服务，而使用者则可以根据该文件查找全部注册服务，并通过扫描代码获取服务之间的调用关系。其中，不同层次的服务主要是通过函数实现相互调用，而各种服务也可通过使用注解的方式实现bean注入，进而调用各个功能组件。服务调用链路获取流程如图1所示。
图1 服务调用链路获取流程
在验证实践中，前期准备工作包括获取应用的镜像包，对镜像包进行解压，以及反编译解压后的jar包以获取代码源文件，之后是对代码进行扫描来获取服务调用链路。具体而言，通过对源代码目录下的文件进行遍历和逐行扫描，即可根据服务调用规则来提取该文件中的特定方法调用了何种服务，进而得到两个服务之间的调用关系。例如，基于上述方法获取的查询多信用卡信息的服务调用链路如图2所示。其中，为验证服务调用链路的准确性，业研中心将使用静态代码扫描获取的服务调用链路信息与全息监控平台所记录的交易链路信息进行比对，结果显示静态代码扫描获取的服务调用链路包含了全息监控中不存在的组件模块。对此，为了得到完整的服务调用链路，可对全息监控平台有记录而代码扫描未获取的服务链路开展分析，提取该链路调用规则，并将其添加到之前的服务调用规则中，以实现持续优化。实际操作中，全息监控平台可以记录已经测试过的服务调用链路。如果能够获取到本次版本相比上次版本所修改内容涉及的服务调用链路，通过计算全息监控记录的服务链路与被包含在涉及修改服务调用链路的比率，就能够为测试人员提供一个衡量测试是否充分的客观指标。
图2 查询多信用卡信息的服务调用链路
需要强调的是，在开展静态代码扫描的过程中，业研中心着重识别了三类高风险服务并给予重点关注：一是涉及修改的服务，此类服务由于源代码被修改，其功能极可能已发生变化。二是调用次数频繁的服务，此类服务调用频繁，主要涉及基础但不可或缺的服务。三是交易链路众多的服务，此类服务通常影响范围较大。
针对上述高风险服务，通过对测试对象进行数字化处理，然后基于SQL语句批量查询不同版本间发生修改的服务，并统计特定服务的调用次数，测试人员即可按照需求选取调用次数排名靠前的服务进行重点关注。为了获取涉及交易链路众多的服务，在得到服务调用链路后，测试人员通过统计各服务在所有服务交易链路中出现的次数，并根据需求选取出现次数排名靠前的服务，即可优先关注涉及高风险服务链路的测试覆盖情况。
三、实践成效总结
1.测试对象数字化应用效果
在测试环境复用方面，随着灵活投产策略的推进，不同投产日的不同项目往往会在同一套测试环境中进行测试，而一旦测试交付物更新了同一个程序，则不同项目的测试过程极可能相互影响，且此前这类情况只能由开发人员来综合评估和控制。对此，数字化后的测试交付物支持对数据库中的程序特征值进行对比，快速查询不同投产日的交付物中是否存在交叉，从而在程序层面排除测试项目互相影响的可能，使不同项目在同一套测试环境中保持独立性、准确性。实践中，当使用该方法进行筛查后，每个投产日平均可排查出5个以上因公用程序交叉导致的版本隐患，换言之，即可使多个投产日的数十个项目在同一套测试环境中保持相对独立，并保障测试结果的准确性。
在风险程序筛查方面，软件开发过程中常常使用开源组件和jar包提高开发效率，但如果此类公共组件存在安全漏洞和后门，将造成较大的影响，需及时解决和升级。对此，通过使用测试交付物数字化后的信息，可快速检索出特定组件分布的具体位置，并在后续版本中持续检验是否所有的问题组件均已整改升级。在实际应用中，业研中心已实现对log4j、kafka等19个常用高风险组件的例行筛查，共筛查出50余次此类组件的异常降级、版本过低等安全隐患，有效保障了系统安全运行。
在数据库变更管理方面，随着平台应用数据库占比的逐步提高，平台数据库表结构变更频次也随之升高，而因此产生的投产风险隐患也逐步显现。对此，业研中心通过解析数据库版本包，联动生产环境获取变更数据库表数据量、字段长等信息，并训练变更风险评估模型，构建了相对完善的数据变更管理系统。截至目前，该系统已覆盖全行98个重点应用，通过开展数据库版本在生产环境下的变更风险等级定级，累计发现高风险变更表43张、变更内容69项，并支持在版本测试阶段提前进行风险预警，大大降低了投产风险。
2.灰盒测试应用效果
在实际生产环境中，通常是小部分高频交易占据了总交易量的绝大部分，而这些高频交易也是开发测试工作的重中之重，如要对此类敏感场景进行版本改造，在开展全量交易分支验证的基础上，还需对有改造的分支进行重点验证。对此，基于灰盒测试方法，测试人员将可以准确识别出重点场景中发生改造的服务、程序、方法和分支，并为其指明测试风险点和重点内容；同时，通过服务调用链路图，还可将测试数据流精确引导至系统中存在改造的部分，强化测试工作指向性。目前，灰盒测试方法已成功应用在快捷支付等高频、高风险场景测试中。
在业务测试开始前，基于灰盒化的版本交付物将可追溯到具体发生版本改造的服务，关联到待测试的业务场景，并通过解析为业务测试人员框定测试范围，明确测试重点。此外，基于灰盒化处理的信息，可以进一步使用提前录用脚本的方式，对存在改造的场景进行自动化测试，提高测试的自动化水平，以及通过检查改造服务的覆盖情况，对测试工作的完整性进行评估。在实际测试中，业研中心从应用维度对存在版本改造的服务或接口进行了覆盖率检查，以确保在投产前使有改造的服务均得到有针对性的重点测试，而对无改造的服务则进行通过性验证，从而合理科学地分配测试资源，有效把控投产风险。
后续，业研中心将继续紧跟科技改革步伐，以科技创新为驱动，不断加强系统测试方法研究，努力提升测试质量和效率，严格把控测试风险，力求为业界数字化转型提供更多可借鉴的经验方法，深入探索与国际接轨的金融信息系统测试之路，为推动金融行业数字化发展贡献新思路、新力量。
本文刊于《中国金融电脑》2023年第6期
声明：本文来自中国金融电脑+，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
