生产原型交易回放测试设计及实践

随着业务的发展和银行业科技应用水平的不断提高，在互联网+、大数据等新技术的推动下，银行科技已逐步向云化、大数据化、移动化、敏捷化方向发展。同时科技和业务间的关系也逐步由技术支持发展到技术引领，银行IT部门不再是单一的技术支持部门，而是一个面向整个银行业务提供业务管理解决方案的平台，在这一平台上可实现业务运行、资源调配和业务变革。

　　为了适应新的技术发展方向和业务合作模式，近年来各银行也开始重新规划技术支持体系，重新建设新的核心系统，并以核心系统为基础，全面提升服务、发展、创新的能力。同时在客户需求多元化、监管要求精细化、经营管理科学化的趋势下，项目规模越来越大，项目复杂度和管理难度也随之提高。如何保障核心系统建设整体测试质量，实现核心系统的快速、安全、稳定迁移，成为人们日益关注的问题。下文重点介绍某商业银行信用卡核心系统升级项目中的生产原型交易回放测试(以下简称“交易回放测试”)方法，通过该方法可以快速地发现系统功能缺陷、数据迁移问题、业务参数问题和新旧系统未发现差异等。

一、对系统迁移项目测试的思考

　　系统迁移测试通常会涉及功能测试、数据迁移测试、性能测试、投产演练等类型的测试，每个测试的内容和方法有所差异。测试用例设计使用了包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等测试方法，先根据需求书设计基本的功能测试用例，用边界值设计边界测试用例，用错误推测法设计异常测试用例。整个设计过程需反复利用八种测试用例设计方法对测试用例进行分解与合并，利用发散思维追加测试用例。

　　测试方法论从不同维度对测试案例进行完善，而实际工作受限于业务复杂度和时间限制，往往无法对所有场景进行完整枚举，从而让人产生这样的疑惑：测试方案是否完全覆盖生产情况?是否存在场景缺失?异常处理能力是否充分?未来生产运行能否稳定?

　　软件项目的质量目标就是投产后生产的安全稳定，基于生产稳定运行的目标可进行反向思维：在进行系统替换升级时，能否利用旧系统的交易信息完成对新系统的测试验证?以往利用生产进行系统验证，大部分是通过白名单机制在生产进行试运行或生产并行试运行进行验证，这两种方法都能有一定的验证效果，但也存在诸多不足，白名单试运行交易量小，只能作一定范围的功能验证，无法作大量的交易验证，特别是在多交易并发的验证和生产负载验证的场景很难实现。生产并行录入的验证基本局限于人工操作的功能验证，客户自动发起功能很难得到验证。能否在测试环境，把生产发生的交易作为案例，完成相应的验证测试呢?

二、交易回放测试方法介绍

　　1．方法定义

　　交易回放测试通过收集生产交易信息，在测试环境搭建模拟新旧两套生产环境，采用工具回放生产交易，结合需求差异分析结果，以生产处理结果为核对标准，并通过分类汇总、明细核对等方式与生产处理结果进行比对分析，验证测试环境交易测试结果的正确性，从而达到用生产原型对新系统进行验证的目的。

　　交易回放测试的主要特点有以下两方面。

　　(1)测试案例设计

　　回放测试的案例直接来源于生产，以生产发生交易原型为测试案例，把生产发生的交易作为回放测试输入，进行测试验证。在回放测试案例设计时，需要确定回放的系统范围和生产时间范围，范围确定，也就确定了具体的回放案例内容，无须进行明细案例设计。

　　(2)测试结果分析

　　不用提前做好每个执行案例的预估结果。测试结果检查的重点在于发现新怕系统的差异点，以生产交易结果作为测试案例的结果目标，以需求变更和环境变化作为结果偏移可能进行分析，找出异常的偏离案例。

　　2．使用方式

　　回放测试根据测试目的不同，可以分为功能回放测试和性能回放测试。

　　(1)功能回放测试

　　功能回放测试的重点是验证生产原型各场景交易功能的正确性，规避测试场景缺失造成的漏测，或由于生产异常数据引发的异常情况。功能回放测试可覆盖联机交易场景，也可以用于批量场景的验证。

　　在通常情况下会有多个系统需要进行回放测试，在执行回放时，可以先逐个系统进行交易回放，最后各系统同步进行交易回放。逐个系统交易回放，可减少系统间交叉影响，重点分析单一的系统功能正确性，快速地发现单一系统问题。各系统同步进行交易回放，可验证整个系统架构体系的支持能力和运维情况。进行功能验证时，为避免系统超负载影响功能回放的结果，交易回放的峰值需保持在测试环境支持交易峰值70％以下。

　　回放测试使用报文回放工具对生产报文进行回放测试，收集生产和测试环境处理结果进行比对。由于新旧系统存在需求差异和一定程度的环境差异，部分新旧系统差异是可接受的，回放测试功能验证时，需对差异原因进行分析，区别可接受差异和缺陷引起差异，具体对比分析可从以下几个方面进行。

　　①新旧系统回应码统计分析。以旧系统业务逻辑处理结果作为标准，对交易处理结果分类统计，核对新旧系统的处理结果差异，找出差异较大的部分进行原因分析。

　　②新旧系统抽样勾兑分析。在分类对比统计的基础上，对每笔交易回应情况进行笔笔勾兑，分析每笔回应差异的原因。由于交易量较大，可以选取一段时间周期内的交易进行分析，提升分析效率。重点关注新旧系统一边成功、一边失败的交易分析。

　　③新系统渠道和核心交易对比分析。根据系统间交易回应代码对照表，对比回放测试环境中，核心系统与渠道交易回应情况，找出交易数量的差异，分析原因，重点是发现接口理解差异和异常处理不足。

　　④新旧系统回应报文对比。抽取部分回应报文进行报文对比，检查回应报文各域的处理结果是否正常。

　　⑤批量入账异常对比。批次回放时，对批量入账结果进行比对，比对交易是否完成对账入账处理，重点核对新旧系统处理结果不同的交易，并对原因进行分析。

　　⑥批次入账后产生本利费、账户状态抽查。对于发生交易的账户，抽取部分数据对入账后本利费的差异进行比对分析，同时核对账户状态差异。

　　(2)性能回放测试

　　交易回放在验证功能的同时，也可以用于性能的验证，该方法与压力测试的主要区别是，压力测试的交易场景基于评估模型构造，回放基于生产交易的收集，包含所收集范围的全交易量，包括生产交易配比和交易顺序。性能回放测试能整体验证新系统的性能情况，也能验证评估模型中交易量占比小的交易是否存在大性能消耗的情况；同时回放报文中包含了生产环境可能存在的异常报文，通过回放能验证在压力情况下，异常报文对性能的影响；可通过调整回放的交易峰值和回放时间长度，对系统的性能和稳定性进行验证。性能回放测试重点分析系统性能的表现，同时关注交易整体成功率与生产环境的差异。

　　3．测试方案

　　(1)实施范围

　　在重大工程项目中，通常除了核心的几个系统改造外，还有几十上百个系统同步配合改造，由于交易渠道多，接口多，所有系统渠道都进行回放测试不是最有效的方式。在选定回放测试的范围时，除了重大改造系统外，还需遵循业务量集中、应用架构聚合、关联影响巨大等原则进行范围选定。

　　①业务量集中。为保障测试覆盖大部分交易，结合整体系统交易量，可对所有交易渠道交易量占比进行统计，按照交易量顺序，选取渠道系统进行交易回放，为保障测试效果，建议选择参与渠道交易量在总交易量中占比超过80％以上。

　　②系统架构聚合。根据历史经验，系统架构上的交汇点，往往也是风险集中点，建议对系统架构和流程进行分析，对架构流程的汇聚点系统安排参与回放测试。

　　③关联影响巨大。还存在一部分业务量可能不大，但一旦出现异常会对银行声誉或客户服务水平有着重大影响的业务系统，在选择回放测试范围时，建议将这部分系统纳入测试范围。

　　(2)交易回放节点

　　回放测试是用工具对生产报文录播的过程，录播选择在什么流程节点非常关键，该节点既是测试发起节点，也是生产流水的收集点，选择时需考虑以下几方面因素。

　　①节点后续流程能覆盖主要的交易流程和变更要点，保障回放测试对变更范围的有效覆盖。

　　②选择新旧系统架构和接口变化较小的节点作为回放点，尽可能保障回放信息与生产环境的一致性，减少交易报文的转换工作量，同时保障案例报文与生产的一致性。

　　③节点是交易的汇聚点，可以减少收集、回放的工作量，同时还能有效控制交易顺序，有效模拟生产交易情况。

　　④节点收集流水时可能对生产产生一定性能影响，必须避免对原生产系统的冲击从而引发不必要的问题。对于交易比较集中的节点，可以考虑增加收集服务器，节点做旁路，增加一个交易报文转发机制，把交易流水分发到收集的服务器，收集服务器负责信息收集处理，隔离信息收集对生产的影响。

　　(3)回放时间

　　回放测试是将生产某个时段的交易在测试环境进行录播测试，时间范围的选择就是案例的选择，选取有代表性的时间周期才能有效地验证生产交易场景。考虑到联机回放测试可以与批次结合进行测试，回放时间可以收集一天的数据进行分阶段回放，每天联机交易回放与批次回放结合进行验证。为了覆盖更多的交易类型，建议选取交易量较大且包含更多特殊交易的时间进行录播回放。

　　首先，分析生产业务量分布和业务类型的分别情况，分析一段时期内每天生产交易量变化情况，对于交易量突增的分析增长点是否有特殊业务场景；其次，抽取生产每天交易类型分布，看特殊时点的交易类型分布是否具备一定的特殊性；再次，对生产上定时发生的批量交易进行特殊性分析。根据以上三个方面的分析，尽量选取包含生产特殊场景的时间段进行交易回放，对于个别无法在回放中包含的特殊场景，需评估其在其他测试中是否被有效覆盖。

　　(4)回放分析

　　对于功能回放测试，由于整体回放测试系统和分析方式比较多，每个系统间的每种方式都进行比对，工作量非常大，且核心账务配合工作将成为瓶颈。确定分析内容时，重点落实新旧系统回应码统计分析、新旧系统抽样勾兑分析，同时落实重点改造系统的渠道和核心的交易对比分析，其他对比方式可根据时间计划和资源情况安排。

　　性能回放测试的重点是系统和应用的性能指标表现，在功能指标上，关注整体成功率是否与生产环境持平即可。一般建议先进行功能回放分析，在保障功能正确性后，再进行性能回放测试，可有效提高整体测试效率和效果。

　　(5)交易唯一性

　　在整个回放测试中，多个地方涉及新旧系统交易处理结果的对比分析，怎么在新旧系统中简单、快速地识别出来同一笔交易，以避免由于类同交易错配，影响分析效率和效果?确定一笔交易唯一性的主要域有交易日期、账号、金额、商户、交易流水号，在不同环境下基本上都是以上要素的抽样组合，其中最有效的方式是交易日期、账号、金额和交易流水号。通常在回放中维持不变的内容有账号、金额和商户号，回放测试过程交易日期由于环境变更会有变化，但基本可转换比较，个别系统流水号会改变交易流水号。建议在测试中以日期、账号、金额、流水号来确定交易唯一性，如果个别系统无法保障交易流水的唯一性，可增加商户做识别，，同时在比较过程中注意剔除错配的情形。

　　4．回放条件

　　(1)报文接收回放和分析工具及脚本开发

　　①报文接收方案。根据交易回放点方案，确定报文接收方案，并提前做好开发测试，并在生产环境投产。在不影响生产稳定运行的前提下，结合脱敏要求在收集报文时进行脱敏处理，避免单独进行脱敏的时间消耗。

　　②报文发送工具开发。做好交易回放点新旧系统差异分析，实现差异报文的转换。同时实现报文发送效率的控制，做到发送原交易时间周期可控，发送峰值可控，并提前完成程序的测试验证。

　　③报文分析脚本。由于对比分析内容比较多，为提高效率，建议提前做好对比分析脚本的开发测试工作，以提高测试效率。

　　④特殊程序修改。由于生产和测试密钥体系差异和信息安全要求，无法模拟生产密码的相关验证，因此应屏蔽加密接口反馈结果的检查动作，以默认密钥验证成功反馈结果；做好密码屏蔽程序修改和测试。

　　⑤其他特殊修改。为保障交易在新旧系统中的唯一性识别，可临时修改新系统流水分配逻辑，提前做好测试，同时注意做好生产版本和特殊测试版本间的版本管理。

　　(2)回放测试数据和环境准备

　　回放测试基于测试执行结果与生产的比对，交易处理的一致性除要求交易请求报文一致外，还需保障环境基础数据的一致性。由于回放的数据跨度比较长，且每个账户在备份时点附近不可能都有交易发生，系统备份时间存在细微差距对测试影响不大。

　　根据回放时间选择，假设选择T日数据进行回放，则必须对T日开始时点相应系统的基础数据进行备份，利用备份的数据，通过恢复数据或数据迁移方式搭建相应的回放测试环境。也可以利用生产系统日常的备份，以减少整体备份工作量。

　　提前开启回放日志录制，在回放周期时间段后，关闭录制功能，并把数据恢复到回放测试环境，供交易回放工具使用。部分系统流水包含请求报文内容，可利用生产流水进行回放。在回放时间周期后，备份生产相应系统的交易流水，恢复到回放测试环境，供回放测试分析使用。

　　由于整个回放测试相关系统有一定关联关系，在进行数据脱敏时必须制定统一的脱敏要求，保障上下游数据的匹配。同时也可以搭建特殊网络段，配合数据工作间的方式制定整体的信息安全保障方案。

　　(3)完成回放环境性能差异分析

　　由于采用工具对交易进行回放，回放时交易量比较大，为了避免系统交易瓶颈影响功能回放测试的效果，需提前评估各系统在测试环境可支持的最大交易峰值。结合生成交易量分布比例和测试环境支持能力的评估，预估混合测试最大支持交易量及交易配比。

 1 2 3 下一页 尾页

扫码即可手机
阅读转发此文