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