编者注：在2023年6月17日举办的“2023 MeterSphere开源持续测试平台城市遇见· 深圳站”活动中，国信证券的资深测试经理林英分享了题为《基于开源工具的系统质量保障实践》的主题演讲。以下内容根据本次演讲整理而成。
国信证券股份有限公司（简称“国信证券”）是一家全国性大型综合类证券公司，在全国117个城市和地区共设有58家分公司、183家营业部。国信证券拥有国信期货有限责任公司、国信弘盛私募基金管理有限公司、国信资本有限责任公司、国信证券（香港）金融控股有限公司等4家全资子公司，50%持股鹏华基金管理有限公司。公司及子公司经营范围涵盖证券经纪、融资融券、代销金融产品、做市交易、期货经纪、资产管理、投资咨询业务、创业管理服务业务等。
国信证券资深测试经理 林英
一、国信证券系统测试的背景及面临的挑战
1. 国信证券系统测试的背景
作为深圳本地的中国头部证券公司，国信证券对系统质量有着极高的要求，对测试质量保障的要求也随之提高。通常来说，金融行业的信息系统通常具有以下的一些特点：
① 双态IT系统架构，技术复杂度高
金融信息系统中一般会同时拥有稳态和敏态这样的“双态”业务系统。
其中，稳态业务系统主要是指承载用户开户、业务办理、证券买卖、委托撤单、交易报盘、统一清算等证券公司最核心业务的系统。稳态业务的建设一般较早，国信证券的稳态业务系统设计采用了较为传统的总线模式，其中有的系统已经在Windows操作系统上运行了大约20年的时间；
敏态业务系统则是为了满足基金业务多样化和创新的需求，承载智能选股决策分析等类别的新生业务系统。敏态业务诞生较晚，其系统技术架构相较于稳态业务更新，大部分采用的是微服务架构，少部分采用容器化部署方式，以便更好地满足业务快速迭代的诉求。
证券业务的敏态系统更偏于面向互联网用户侧，用户侧业务从敏态系统进入后，通过稳态的核心业务长链路到达交易所等地。基于“稳态”与“敏态”共存的系统状况，测试产品的选型需要可以同时较好地满足“双态”模式下业务系统的测试要求。
② 多模式交付形态，系统数量多
除主要的业务系统外，国信证券还拥有运营平台、资讯平台等多类支撑系统。对于这些支撑系统，如果在市场调研之后与公司业务需求较为匹配，会通过外购的方式来引入这些成熟的系统产品；如果有一定的定制化需求，则会与厂商合作共建；除此之外，公司有时也会采用内部完全自研的方式进行系统建设。这些支撑系统的来源不一，交付模式不同，导致整个系统的质量管理更为复杂。
③ 行业监管严格，容错率极低
金融行业的信息系统直接关系到用户的资金安全。如果未能及时排查并解决系统中出现的故障，就很容易导致用户在使用的过程中出现资产损失。所以监管方对于公司内IT团队的要求也会更加严格，一旦系统出现问题，必须在规定时间内快速处理，否则团队将面临严重的问责与处罚。
2. 金融信息系统面临的挑战
国信证券的金融系统主要分为重要系统和一般系统。这两类系统的侧重点不同，需要采用不同的方式去维护，这也就意味着它们在系统的建设和运维过程中将面临着不同的挑战。
① 重要系统
重要系统是包括开户业务、交易业务以及一些清算业务等在内的系统。重要系统大多与客户资金等重要信息相关，是公司重点保障的对象。负责的IT团队需要具有对Bug排查的敏锐度和速度，因而会投入比较多的资源，加强测试、验收、运维，以保障其运行质量。
重要系统质量保障面临的挑战主要有：
■ 业务系统上线的验证依赖外部同事
目前，国信证券内部共有各类型的组件350个，应用系统每年会有约3000次变更。并且，公司每个星期都会配合上交所、深交所进行一些通关测试，每两周会有定期的系统重启，每个月会有灾备演练，每半年会有年度灾备演练。每次通关测试或系统重启等活动后，都需要再次对业务系统进行一次全方位的验证。
因监管要求，验证工作更依赖营业部的工作人员来协助进行。但营业部的工作主要是服务客户，营业部的工作人员对于IT系统的了解往往不够深入，且跨部门的沟通协作也容易导致信息缺损，在系统验证的过程中就可能会出现一些疏漏。
■ 业务故障报告依赖客户
国信证券的业务故障报告遵从“客户发现问题并反馈→客户经理反馈→一线应急人员上报→二线运维人员反馈→开发人员处理”的流程。业务故障报告的整个流程链路过长，反馈耗费的时长同步增加，问题现场回溯和排障的困难也会影响修复时间。这种延误和低效率可能触及证监会的监管红线，也容易导致影响的范围进一步扩大，把小问题变成大问题。
总结来说，重要系统的风险管控主要体现在验收测试以及验收之后持续运营的过程当中。
② 一般系统
国信证券对一般系统的投入资源相比重要系统而言要少一些。对于一般系统，通常仅有一个项目经理来负责管理，包揽技术管控、需求设计、系统测试、系统运维等多种工作。
对于一般系统来说，面临的主要挑战就是无法有效地管控厂商提供系统的质量。国信证券一般是通过直接外购的方式获得一般系统，但厂商的产品质量往往也是参差不齐。在系统交付模式中的需求设计、开发编码、系统测试等部分主要都是供应厂商自发进行，甲方难以介入并提前进行质量管控。只有在系统交付时，才会由外包同事现场进行一轮纯手工的验收测试，系统交付的质量风险较高，缺陷修复后的回归验证周期也比较长。而从质量保障的角度看，一般系统的风险管控在系统上线前就要开始进行。
二、质量管理与业务监控的建设思路
针对不同种类系统面临的问题，国信证券整理了一些解决问题的思路，具体如下：
1. 落实“三个统一”的标准化厂商质量管理
“三个统一”包括统一测试管理、统一标准交付物以及统一工具，三者之间互相关联、互相促进，可以达成“交付系统的质量与效率同步提升”的目标。其中，在统一测试管理的场景下，可以更好地推进测试工具统一；统一的测试工具及相应的统一测试标准可以促进标准交付物的形成；标准交付物的成型和数量增长也将反哺统一测试管理。通过这样的管理思路，国信证券可以逐步提升统一标准化厂商质量的过程管理工作。
2. 业务层主动监控，提前感知系统的可用性故障
针对公司内重要系统的痛点，为达成线上验收、客户报账等重要业务事项的质量保障，国信证券的IT团队选择尝试“测试右移”的思路，将测试环节右移到生产环境一侧。在生产环境中自动化模拟用户的业务调用操作，可以进行实时的业务拨测，提高发布验证的效率，提前感知系统的可用性，并保障系统的稳定运行。
在公司业务变更时，团队通过在生产环境中运行接口测试或自动化测试，也可以快速发现生产过程中或系统变更时出现的故障，为系统排障争取更多的时间，减少对用户体验的负面影响时长。
3. 开源工具助力传统企业低成本快速构建IT基础设施
基于前面两条建设思路，国信证券的IT团队决定采用“工具先行”的模式，借助低成本的开源测试工具，快速构建IT基础设施并保障其运行质量。
之所以决定选用开源的测试工具，而不是选择购买闭源产品、定制或自研测试软件，国信证券的IT团队有以下几点考量：
① 开源工具的成本较低
除去产品费用等显性成本较低外，开源工具的学习成本、使用中节约的时间成本等隐性成本，相较于其他测试工具也更具优势。因为开源工具的流通更广，员工有过该软件学习和使用经历的可能性就更高，也更容易在丰富的社区教程帮助下学会软件的操作技能，无形中节约了测试团队的学习成本；
② 周期短，见效快
已有的测试工具会比定制或自研的测试工具更加成熟，可以达到“开箱即用”的效果，将之接入业务系统的难度更低，建设周期更短；
③ 技术更先进
开源测试工具往往采用主流技术栈，技术选型具有先进性，可以在一定程度上降低软件学习与使用的门槛；
④ 产品生命力强
开源软件的用户更加广泛，且产品会随着大量用户的不断反馈而持续迭代，更有持续演进的动力，生命力比闭源软件、定制软件或自研软件更强大。
三、MeterSphere在国信证券的落地实践
1. 开源工具选型
在经过详细的调查选型后，国信证券的IT团队选择了MeterSphere一站式开源持续测试平台。MeterSphere最吸引团队的优势包括：
① 开源社区活跃度高
MeterSphere的用户群广泛，开源社区活跃度非常高。目前MeterSphere在GitHub已获得9000多个Star、2000多次Fork，已经在很多企业中被落地使用；
② 功能全面
作为一款一站式的开源持续测试平台，MeterSphere中包含了国信证券的测试工作所需要的测试跟踪、接口测试、性能测试等几乎全部功能；
③ 兼容JMeter
在引入MeterSphere之前，国信证券的性能测试工作主要是基于JMeter展开的。公司的交易系统等稳态系统中有一些非通用的数字协议，也是通过基于JMeter研发的扩展插件去进行兼容和支持的。由于MeterSphere也可以兼容JMeter，引入MeterSphere平台后可以方便、快速地在二者之间完成测试工作的对接；
④ 扩展性强
MeterSphere可以兼容多种协议，拥有丰富的插件体系。这就意味着MeterSphere作为一款软件具有充足的扩展性，能够更好地适应国信证券内部的诸多系统；
⑤ 测试环境适配
MeterSphere支持容器化部署，便于信创环境等多种测试环境的快速迁移和与测试工具的适配；
⑥ 采用主流技术栈
MeterSphere主要采用Java语言编写，使用Spring Boot（后端）、Vue.js（前端）等常见的技术栈，与国信证券的业务系统和IT团队成员技能契合度高。
2. 业务监控的落地实践
① 业务监控全方位覆盖
国信证券的IT团队通过MeterSphere的接口自动化功能，以“金太阳” 移动APP为试点，实现了对包括交易、理财、开户、首页、行情、资讯等在内的核心业务系统内业务监控的100%覆盖，以及对自建数据中心与行情云上机房的100%覆盖。覆盖接口共591个，接口覆盖率达到94.5%。业务监控保持7*15小时（09：00~23：59，节假日不休）的不间断运行。
② 监控告警发现、推送、响应、处理的闭环实现
在MeterSphere的协助下，国信证券实现了监控告警发现、推送、响应、处理的闭环管控。在业务监控保持7*15小时（09：00~23：59）不间断运行的情况下，当业务系统中出现错误，业务监控就会发出对应告警，并将告警推送至统一告警事件平台以及负责人微信，快速触达负责问题处理的IT工作人员。
同时，平台可以针对这些告警做出分类分级的处理，协助工作人员快速进行问题的优先级排序并制定处理决策。对于告警的故障问题，MeterSphere也可以给出机房定位、接口定位、错误内容和错误时间等清晰的信息提示。IT团队还对业务监控的参数进行了染色，便于知悉错误的提交者是内部工作人员还是外部用户。
在公司业务系统变更时，可能会短时间内触发大量告警。IT团队设计了告警的可配置自动恢复策略。在系统变更结束、服务恢复正常之后，不用浪费人力去一个个地手动排查处理，这些失效的告警可以自动恢复正常。
③ 实现对私有协议及各种非标准协议的支持
国信证券的业务系统中还涉及多种私有协议和非标准协议，IT团队在MeterSphere平台通过可扩展的插件机制解决了这问题。在整个过程中，按照“依赖厂商-合作共研-自主开发”三步走的模式，目前已经扩展了4个插件，包括飞致云的客户成功团队帮助开发的两种插件、国信证券IT团队与飞致云共同研发的私有TPC网关插件，以及国信证券自主研发的华锐极速交易插件。后续国信证券将根据业务系统的要求，根据测试需求自主扩展MeterSphere平台的插件体系。
④ 在应用变更、系统重启及日常业务巡检发挥价值
通过MeterSphere平台建设的业务监控体系在国信证券业务系统变更、重启及日常的业务巡检中发挥了很高的价值。业务监控体系上线一年间内，IT团队共发现了61个线上问题，其中72%的问题是在日常巡检中被发现，28%的问题是在应用变更和日常重启中被发现。作为金融类企业，国信证券的线上故障率在同类企业中一直处于较低水平。
3. 基于MeterSphere进行业务系统质量管理
① 明确系统质量过程管理规范
通过使用MeterSphere测试平台，国信证券打破了系统供应商的黑盒子，明确了对合作厂商交付系统质量的全过程管理规范，即将测试管理的过程“左移”到厂商交付之前。
在系统需求设计之后，国信证券会对此需求设计进行初步评审，然后系统供应商再开始进行开发编码。开发编码结束后，团队会与厂商先沟通进行一次用例评审，让厂商依据要求进行系统测试，并要求厂商对产出物进行标准化管理。最终，国信证券在进行业务系统的内部测试验收时，会对此过程执行过程审计，通过审计后方可开放系统的线上部署。
② 统一平台，标准化交付物，快速验收存档
国信证券要求系统供应厂商与国信证券使用数据兼容的统一测试平台——即MeterSphere一站式开源测试平台。在交付业务功能的基础上，厂商需要向国信证券同步交付编写的功能测试用例、接口自动化用例与性能测试用例等，通过MeterSphere平台即可将这些测试相关的交付内容直接导入至国信证券的内部环境。这样系统采购之后的维护期就可以在系统供应厂商无需介入的情况下，快速上手执行系统升级或服务迁移等操作，并直接运行已有的用例开展测试工作，实现系统交付的无缝衔接以及厂商和交付系统的标准化管理。
③ 面向不同项目及角色，提供多样服务能力
MeterSphere平台为国信证券IT团队中不同的项目与角色提供多样化的服务能力。
■ 对于开发人员来说，MeterSphere支持多种接口协议的调试、编辑、回放，同时提供前后端分离开发模式的接口Mock服务，还能实现接口测试一键转性能测试，有效提升了软件开发的效率；
■ 对于测试经理来说，MeterSphere可以系统化地管理测试过程中的资产数据，便于进行用例的储存和复用，也可以直接在MeterSphere平台对用例进行在线评审。在MeterSphere的“测试管理”模块中，可以对测试任务进行线上分配，并对工作人员的测试进度进行实时追踪。对于在MeterSphere平台进行的测试工作，也可以更规范地进行测试过程的审计，即时更新审计结果并为执行动作留痕。审计中发现的缺陷则可以进行分类处理，保障交付系统的质量；
■ 对于应用运维人员来说，MeterSphere平台可以进行业务变更后的验证，提高验证效率，加速业务更新上线。在业务系统的日常巡检中，MeterSphere平台也发挥了非常大的作用，当发现系统问题时MeterSphere可以及时进行统一告警，并将告警消息推送至负责人微信等，减小问题的影响时长和影响范围，帮助提升整个系统的稳定性。