实战 | 持续测试在商业银行的本地化实践
欢迎金融科技工作者积极投稿！
投稿邮箱：newmedia@fcmag.com.cn
——金融电子化
文 / 中国农业银行研发中心 王欣 苏畅 阮绍臣
中国农业银行研发中心测试二部处长 王欣
近年来，随着业务快速交付诉求的增加以及敏捷开发模式的流行，越来越多的企业都采用DevOps模式进行项目开发，DevOps越来越多地出现在各大商业银行的重点工作中。2020年中国农业银行建成了从需求、开发、测试到部署的端到端持续交付流水线，并通过了 DevOps 标准持续交付部分的3级评估。探索具有农行特色的DevOps建设之路，仍需在DevOps各个环节的不断摸索与实践，尤其在企业落地敏捷及DevOps实践视为瓶颈的测试环节，只有实现持续测试才能实现持续交付的目标。
持续交付的关键——持续测试
持续交付是银行对软件研发能力的核心目标，以实现向用户持续交付有价值的软件服务，商业银行以组织、流程和系统为基础，依托持续交付能力，服务银行业务目标和战略。
图1 持续交付能力
测试环节之所以被企业落地敏捷及DevOps实践视为瓶颈，是因为在持续交付流水线中，相比持续集成、持续部署等，持续测试的建设相对落后，在测试基础设施、测试自动化、测试创新上还做得不够。持续测试是DevOps倡导的6C（Continuous）核心理念之一，是保证银行DevOps转型成功的关键因素。相对于传统测试中测试投入集中于测试执行阶段，持续测试在研发全生命周期中的测试投入则更为平滑连续。强调测试贯穿于整个软件交付周期的所有活动中持续进行，引导建立跨职能团队，促进各部门协同工作，持续发现缺陷并迅速修复，提倡尽早测试、不断测试和自动化测试。
商业银行持续测试体系
自动化测试在商业银行已推行多年，但在测试方法中占据主要地位的仍然是手工测试，这是因为自动化测试仍然面临着一些痛点问题，如自动化有成本、稳定性和可靠性不高、测试数据和关联系统可用性问题等。虽然通过大力发展自动化测试，商业银行一定程度上实现了回归测试效率提升，但要满足持续交付的要求，只有自动化测试还不够。建立持续测试体系，不仅能够解决上述痛点问题，还能以恰到好处的测试、最快的速度覆盖交付所面临的业务风险，给研发团队提供快速的质量反馈。
图2 持续测试体系
近两年来，商业银行的DevOps建设走向深入，持续测试体系已初步构建完成。从软件产品质量模型角度出发建立测试策略模型，对测试体系形成自上而下的整体统筹，进一步确定在持续迭代的测试活动中，该验证哪些质量属性、采用哪些测试方法、运用哪些测试工具、达成哪些质量目标，可以从根本上提升测试充分性，达成质效合一的目标。持续测试体系主要包含四个方面。
1.手工测试。自动化测试并不能完全替代手工测试，一些功能的自动化工具支持度不高，一些功能使用探索性测试反而更加快速灵活，一些需要主观感受的用户体验测试也离不开手工。借助TMOCK工具，可基于UI设计图快速开展前端测试和体验性测试，而不依赖于后端开发完成。由此在开发早期就获得UI用户体验反馈，快速定版UI，提升研发效能。
2.自动化测试。功能测试中，擎云平台作为自动化测试平台UI级/API级自动化的设计、执行和结果分析，AUIT作为擎云平台录制/回放模式的补充，用于支持敏捷研发模式的UI自动化测试；性能测试中，Xmeter作为性能测试平台完成性能脚本生成和压力模拟，辅以性能监控工具进行测试结果搜集；安全测试中，安全漏洞扫描工具用于系统安全诊断，渗透测试工具用于模拟系统外部攻击；可靠性测试中，借助混沌工程测试工具完成实验，在可控范围内注入异常场景，验证系统弹性，发现系统未知缺陷，验证应急手段的有效性。
3.测试服务。数据管理服务，用于在持续测试中缩短测试数据的创建和维护时间，擎云平台实现了测试数据与脚本分离，借助数据抽象和数据资源池达到了测试数据与环境无关；环境管理服务，擎云平台实现了测试环境自管理，环境可用性心跳监控机制；MOCK服务，依托服务虚拟化技术，被测试对象依赖的系统组件不能被正常访问的情况下，保证测试环境和测试数据问题不影响测试的速度、准确性和完整性，TMOCK实现了对测试请求数据的解耦和对关联系统环境的解耦，还可模拟测试环境中的极端和异常条件下的行为，以覆盖更多的测试场景。
4.测试管理。测试过程管理，基于DevOps工程实践，依托以ITA为主的管理链、以TFS为主的研发链，测试设计积累的测试用例，在ITA完成测试评审后，与测试执行发现的测试缺陷，统一纳入TFS资产管理；测试度量，应用精准测试技术，使用Jacoco开展代码覆盖统计与分析，改进自动化测试案例以提升测试充分性。统计测试全生命周期度量指标，作为DevOps流水线质量门禁，并与质量目标对比完成产品质量评价。
持续测试的本地化实践
持续测试不能简单采取“拿来主义”，商业银行持续测试的本地化实践也因地制宜、各具特色。测试自动化作为持续测试的核心，如何达到尽早测试、测试左移的目标，实现测试可以随时开展、平滑有序、快速高效，商业银行进行了如下探索与实践。
图3 软件产品质量模型
测试没有必要也无法穷尽所有分支路径，既不多测也不少测的测试策略是持续测试的目标之一。通过制定基于质量模型的测试策略，定义测试范围、测试重点和质量目标，自上而下的实现对软件产品的整体质量把控。从产品价值和风险的角度出发，不同价值类型的需求（质量要求）是不一样的，首先按照产品价值可以对系统功能进行分类，再通过历史版本测试情况风险分析，识别问题或风险的高发区，测试范围和测试重点即可确定。
结合测试范围、测试重点和质量目标，可确定自动化测试分层，测试重点中的功能需完成UI自动化测试覆盖，测试范围中的全部功能需完成API自动化测试覆盖。基于某敏捷项目测试实践，将测试设计活动左移到系统设计阶段，利用系统UI设计图和前后端接口设计文档快速生成UI自动化测试案例和API自动化测试案例。应用自研的UI自动化测试工具（AUIT，Agile UI automated Testing tool），根据系统UI标注图和开发框架定制的界面，为所有交互UI元素约定唯一的ID属性值，创建UI元素素材库并最终形成可进行自动化案例编写的测试对象库，依托测试对象库设计并生成UI自动化案例，自动化案例执行时按照测试对象库ID信息进行UI元素定位捕捉。这样，不但可以省去手工测试案例的设计和执行环节，而且在UI开发完成前就可生成自动化案例。
图4 传统测试与持续测试
此外，将测试执行活动左移到系统开发阶段，对应于前后端分离开发，利用Mock测试服务和UI/API自动化测试案例，分别完成前端和后端的测试执行，实现前后端分离测试。应用自研的虚拟测试服务工具（TMOCK，MOCK for Testing），为系统测试提供MOCK服务，根据不同的通信协议，完成报文解码、交易识别、报文校验、报文编码，返回报文等操作。在前端开发完成，后端开发尚未完成的情况下，支持使用HTTP+Jason和TCP+NETE协议进行前后端通讯的系统，为待测前端程序提供虚拟后端服务响应，并支持正常业务逻辑、测试数据异常（数据长度、数据类型）、测试报文异常（多参、少参、报文格式）以及系统网络异常（网络中断、延迟）等测试场景，使用UI自动化案例在测试交付前即可完成前端测试；在后端开发完成，关联系统组件开发尚未完成的情况下，同样可以为待测后端程序提供虚拟关联系统服务响应，使用API自动化案例在测试交付前即可完成后端测试。
图5 TMOCK解决方案框架
待到前后端完成系统联调和测试交付后，可复用前期积累的UI/API自动化测试案例，即刻完成自动化回归测试；对于当前自动化测试框架不支持的功能特性，使用少量手工的探索性测试进行补充，快速完成系统测试反馈，较传统测试缩短了测试周期，提升了交付效率。基于系统开发阶段的前后端分离测试，将bug提交在编码阶段，解决了前后端耦合导致缺陷定位成本升高的问题，降低了bug解决成本。
结 语
持续测试在促进团队协作、缩短交付周期、提升产品质量等方面的作用日趋明显，展望软件测试的未来，持续测试是最具确定性的趋势之一。然而，目前商业银行所能实现的持续测试和理想中的持续测试还有一定差距，在持续测试体系的落地实践中，仍然会碰到很多问题，一些环节仍需手工完成，一些流程还不够平滑连续。商业银行在持续测试的本地化实践仍在继续，经过组织、流程、工具链的不断创新与磨合，相信不久的将来定能实现真正意义的持续测试。
往期精选：
《金融电子化》新媒体部：主任 / 邝源 编辑 / 傅甜甜 潘婧