文 / 交通银行测试中心 叶旻
习近平总书记在全国金融工作会议上强调：“必须加强党对金融工作的领导，……紧紧围绕服务实体经济、防控金融风险、深化金融改革三项任务，……保障国家金融安全，促进经济和金融良性循环、健康发展”。要有力防控金融风险、保障国家金融安全，则必须改变目前我国关键领域核心技术受制于人的格局，开展信创建设正是国家为了把握关键领域核心技术而采取的重要举措。金融行业特别是大型银行，作为落实我国信创建设规划的排头兵，在深入推进信创改造的过程中，研究总结形成了信创改造工程的质量保障方法体系，在确保银行产品平稳切换的同时也为中小银行、其他金融机构，乃至其他行业提供了可参考的经验。
银行业信创改造测试面临的难点
信创建设主要通过将系统整体迁移至分布式云平台、升级系统技术架构为分布式云架构，以及更新数据库、操作系统、中间件等软硬件来完成改造。与传统业务发起的产品改造相比，信创改造的主要风险在于信创产品本身质量的不确定性、底层改造对业务影响范围的不确定性，以及信创分步实施对质量统筹的不确定性。
1.信创产品生态薄弱
尽管信创产品近几年发展迅速，产品功能趋于完善，整体可用性逐步提升，但产品生态还较为薄弱。
一是产品自身运行经验欠缺。一方面相较以往成熟的产品，在性能、兼容性、稳定性、健壮性等方面仍存在一定差距；另一方面缺少长时间安全稳定运行业务场景复杂的金融系统的经验积累。
二是同等功能与原使用产品也不完全一致。信创产品底层框架与原使用产品对于相同变量的辨识和解析方式不完全一致，系统处理能力的差异需要更为充分的验证才可以识别出来。因此银行原有系统的迁移、历史软硬件与信创产品的兼容并不是对承载业务系统无感的技术底层优化，而会对业务系统的性能表现、用户的操作体验，甚至账务正确性、运行的稳定性等都会造成一定风险。
2.信创改造对于业务的影响范围难以评估
常规产品建设与改造由业务需求驱动，业务部门会提供产品优化需求，框定项目涉及的业务范围，据此能够较为准确地分析确定测试范围，开展针对性测试，以确保产品质量。而信创改造主要是对正在运行的业务系统实施系统硬件、数据库等基础技术设施，乃至技术框架的变更，是基于技术底层变更驱动的改造，因此对于承载其上的业务影响难以一目了然，影响范围无论是开发人员还是测试人员均难以准确评估，业务人员更是不知所以。
3.信创改造的分步实施规划对测试统筹造成较大压力
信创改造需要分步骤稳步推进，还要兼顾同时开展的业务数字化转型项目建设，因此在有限的时间空间内将面临项目规划难、执行要求高的困难。
一是改造中间态较多。为确保业务无感，各系统的信创改造实施不可能简单“一刀切”，这就使得在同一个测试阶段出现各种中间态并存测试的复杂局面，如果计划不合理就会造成版本冲突、重复工作等较为棘手的测试难题。
二是测试基线模糊。业务系统间关系错综复杂，各系统信创进度和程度很难确保与计划完全保持一致，从而导致项目实施里程碑的测试基线难以统一，不利于对项目计划进行回顾和纠偏。
目前银行实施信创测试的应对措施
1.预判风险，提升信创产品的适配性
一方面形成详尽的改造工程方案规划，通过正面开展分布式事务专项测试、数据库比对、迁移演练、双活切换、网络备份等，确保出现异常时能够快速形成兜底机制，保证系统平稳运行。另一方面，可以通过主动向应用系统注入硬件或软件故障，暴露系统薄弱环节，再有针对性地制定优化方案予以解决，从而规避信创产品自身风险，提升系统的健壮性。
如工行为了稳妥起见，保持一定时间的新老系统并行，密切关注生产运行情况，期间逐步向分布式新核心切换交易流量，稳扎稳打，确保新核心系统顺利接管。农行在分布式核心系统改造中，应用混沌测试技术，结合分布式系统特点，设计了单元化切换、全局流控异常等故障场景，通过监控指标并持续优化，确保系统稳定性。
2.建立映射，充分评估改造影响范围
为准确评估信创改造测试范围，一是要建立技术架构与业务的全量映射关系。可以借助对信创改造涉及技术变动情况的分析溯源，明确业务交易源头，评估测试范围。而近几年工行、建行陆续建成的企业级架构，以及中信银行基于因子分析搭建的“五跃天”测试中台，提供了更好的解决方案，即通过企业级架构对产品分类结构、产品组件、产品条件等进行参数化定义，统一业务与技术的“对话口径”，就可根据改造涉及的技术范围映射出业务范围。如工商银行探索研究提出建设产品图谱，实施产品全生命周期管理，既为承接数字化转型工程任务提供抓手，又为技术底层改造项目实现快速业务范围溯源提供了捷径。邮储银行在新一代个人业务核心系统中采用企业级业务建模的方式梳理业务流程，指导组件化和微服务化的IT架构和IT服务设计，支撑信创改造项目的顺利开展。
二是利用生产流量回放作为业务范围的补充。通过获取生产流量数据在准生产环境或测试环境进行回放，比对相同交易的执行差异，以弥补测试在业务范围和数据覆盖方面的不足。如工行、农行、建行、中信均先后在测试和生产网段部署专用测试环境，将生产交易流量引流回放，比对相同交易在生产环境、测试环境上的执行差异，在信创改造项目中发挥重大作用。中信更是将此项技术作为生产运维的手段之一，建立了长效机制。
3.统筹管理，合理制定信创改造计划
银行业务系统和技术框架错综复杂，信创改造必然分批次、分步骤稳步推进，还要在改造实施的同时兼顾业务发展，这就需要做好信创改造过程内部与外部项目间的统筹规划，合理编排核心系统与外围系统改造迁移的关联关系，把控好改造节奏，确保中间态测试都能业务全覆盖。需要建立统一的管理组织，画好蓝图、加强管控、紧盯风险、动态优化，在确保相互影响最小的同时降低资源投入。
如中行在企业级架构建设基本完成后，仍保留了企业级架构建设办公室，在信创改造过程中，充分考虑信创改造与数字化转型发展需要，合理规划实施安排，做好计划的统筹管理，从而确保了信创改造与常规产品改造的顺利并行。
交通银行关于信创测试的实践探索
交通银行也在积极推进全业务流程信创适配改造工程，2022年7月已成功上线贷记卡分布式核心系统，完成了首个国有大行信用卡分布式核心主机下移重构项目，荣获了2021年度金融科技发展奖一等奖。后续还将完成核心账务和其他业务系统的信创改造。
1.主要措施
（1）做好规划布局，应对信创改造实施节奏。
一是建立专班组织架构。以董事长、行长为组长成立数字化转型领导小组，组建境内外核心下移推进办公室组牵头项目专班管理工作，下设境内总体组、境外总体组、资源保障组共同推进，从而确保能够全面规划实施节奏、统一项目调度，实施工程化管理。
二是充分做好测试准备。根据改造项目整体情况，扩充测试环境容量、完善系统应用，提前开展生产数据导入、变形和验证，准备仿真工具，为开展测试提供数据铺底；优化统一工程管理平台，规范工程管理流程，实施信息共享，为项目顺利开展奠定基础；抽调骨干人员参加项目建设，做好人员保障。
三是合理规划测试资源。统筹常规测试项目与信创改造项目的实施安排，做好测试环境摆布和调度，尽量减少信创改造中间态过多对信创改造本身和常规业务发展的影响。
（2）完善质量目标，应用新型技术防范信创产品潜在风险。
一是有针对性地完善质量目标、关注重点风险。因无法像业务驱动改造一样较为准确地明确影响范围，只能尝试回到质量保证的理论原点重新出发，基于风险开展测试，在常规业务需求测试主要针对功能、性能、兼容、安全等质量目标开展验证的基础上，更加关注移植数据、批量、运行环境、分布式事务等风险，重点确保移植数据的准确性、切换步骤的合理性，以及云平台的适配性等。
二是应用技术与时俱进。通过学习参考各大行信创项目的经验，针对各行的亮点技术开展现场预研，以实现快速技术突破。如对案例进行聚类和参数化改造、实施流量回放，加强自动化测试在业务分支和数据覆盖增加上的作用发挥；通过异常注入等方法，主动识别系统脆弱部分，增强应用健壮性等。
（3）加强板块协作，共同确保改造影响范围完备准确。
正视信创改造经验不足的现实，金融科技板块各部门加强协作。一是业务覆盖方面。开发测试共同对改造涉及接口进行分析溯源，定位涉及交易，为测试框定基础测试范围；测试充分利用积累的资产和经验补充业务分支，以业务维度开展验证，持续向开发获取接口命中率，逐步优化扩充影响范围；运维人员抓取生产流量，配合开展流量回放测试，进一步加强业务交易的数据覆盖。
二是性能措施方面。测试依据业务范围抽取重要端到端性能场景，开发提供场景涉及的系统链路和单系统性能设计信息，测试时以运维获取的当前生产性能表现，结合业务发展规划综合形成性能验收标准；同时，根据端到端测试的情况，开发持续进行系统调优，运维则不断调整投产容量配置，共同确保系统的性能表现。
三是数据一致性方面。开发负责提炼移行规则、编写移行脚本、开发移行比对报表；测试以用户视角，使用移行比对脚本对移行后的数据进行确认，并使用移植数据开展功能验证；运维则配合开发搭建临时环境，使用全量数据开展移植演练，验证移行的步骤方式和时长效率。
2.具体实践
在传统测试工艺中融入对信创改造的思考，并依托信创项目测试开始了新一轮实践。
一是功能测试。在传统功能测试中扩充了获取改造影响范围的方式，即根据开发的分析溯源，明确部分业务交易源头，梳理相关案例作为基础测试范围；通过对存量业务测试资产的复用，如高危、高频交易和历史产品风险涉及的流程、案例等，完善分支覆盖，扩充业务影响范围。比对接口命中情况，进行分类处理，补充没有覆盖的场景，整合类同以及废弃不用的接口，纠正错误的溯源再配备案例开展测试，不断提升测试针对性；通过使用引流回放工具进行生产交易流量回放，反复比对新老系统交易结果，进一步提升交易和数据覆盖。
二是性能测试。将产品自身性能体现、业务场景性能和用户体验反馈并行关注，依据业务范围形成端到端性能场景，依据高频交易、客诉、生产问题等条件评审抽取场景作为验证范围；结合业务发展规划和现行标准确定性能指标，如并发量、响应时间等，明确验收标准；梳理系统链路，开展全链路性能测试，关注性能极限值波动趋势，定位问题原因；反馈测试结果至运维，从而制定增加系统资源、带宽扩容、应用回退等针对性改进措施。
三是移植数据测试。首先根据对业务规则的理解检查技术移植规则、移植脚本的正确性，再按照业务开展需要开发移植报表比对工具，比对迁移前后的报文和结果差异，开展移植数据功能测试，投产后由业务人员开展业务验证，全面确保移植数据的正确性。同时需要提前准备好移植演练环境，细化演练步骤，保证移植过程的合理性，特别要关注数据效率时长是否处于合理区间。
四是批量联测。梳理批量中的业务属性作业范围、作业文件的传输顺序、格式要求、关键时效节点，编制批量调度图，设置检查点；组织各方选择某个批量，开展批量联测，核对批量链路各节点文件传输的准确性，关注异常处理情况。同时，运行环境变化后要重点结合业务场景对批量性能进行验证，确保批量运行效率对生产质量造成影响。
五是账务托底验证。由于资源受限无法开展全量测试，因此对于账务的测试除针对交易本身的总分账核对、账卡核对等账务验证外，更要关注整体账务的正确性。如新老系统并行期间年终决算、监管报表、客户账务清单等方面的正确性和时效性，尤其是结合分布式事务变化特点，开展账务防重等方面验证。
六是安全测试。针对用户场景、业务流程分析可能存在的安全风险，如登录控制、鉴权要求等，有针对性开展安全功能测试；从代码、运行平台和生产环境端到端维度进行漏洞扫描和渗透测试，模拟恶意攻击方法，主动发现和分析系统弱点、技术缺陷或漏洞。
七是用户体验测试。结合信创产品自身特点，分析底层软硬件等变化对性能、用户使用习惯等造成的影响，以及用户的交互界面或用户旅程可能存在的差异，有针对性地制定验证策略并提出优化建议。考虑在信创改造的同时关注用户的使用痛点并同步进行优化，通过众测平台邀请用户参与体验，如对于报错信息的提示等，有效缓解因为性能感受、使用习惯等变化造成的落差。
八是切换测试。明确上线切换步骤，形成详尽的操作清单，通过开展切换演练发现可能存在的异常风险，同时关注逃跑预案，如设置开关、白名单管理、回归等，确保出现异常时能快速降低影响。
九是异常注入测试。测试过程中充分考虑分布式云平台运行过程的差异、云平台整体升级等因素，模拟异常场景提前注入系统，关注系统对于异常的处理进程，建立平台出现异常时的解决预案并进行充分验证，确保系统健壮性。
3.遗留问题
通过对信创测试方法论体系的研究和试行，在贷记卡分布式核心系统重构项目中收获了一定的成功经验，但仍有部分难题还有待进一步思考研究。如基于信创改造的自动化配套实施，应何时开始，在哪些阶段发挥作用，才能确保较优的投入产出；为确保尽可能全面的测试，对于测试案例的规模该如何安排，才能达到进度与质量的平衡；针对信创改造类项目开发和测试投入应如何估算，怎样找到开发测试比的合理区域等。
以上问题希望能在行业深入推进信创改造的过程中进一步摸索探讨，最终取得最优解，从而形成行之有效的实施经验、配套机制，让信创测试工作真正做到安全可控，坚定行业发展信创战略的决心。我们相信银行业核心技术自主可控的明天即将到来，我国关键核心技术攻坚战也终将取得胜利。
（本文仅代表个人观点，不代表任职单位意见，文责由作者自负）
声明：本文来自金融电子化，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
