我们的核心系统是一个单体系统，支撑全球多个国家和地区的业务。同时，业务部门近年生意红火，接了几个大客户，针对这些大客户的大型项目也在如火如荼地进行中。



由于生产环境只有一套，而且已经有业务在生产环境上跑，这些大项目最终也要在这套生产环境上上线。这套系统是糅合了各地、各不同业务的复杂系统。



之前，为了满足各个客户交付时间，每个项目都拉了一个独立的分支进行开发，减少各项目之间的依赖，但这也导致了每个项目各自为政，互不交流。一旦这些项目开发完成，要和生产环境的版本进行合并。这种巨型合并势必带来巨大风险，相互隔绝的开发模式也将带来大量的合并冲突。



我们一直在思考如何降低这种合并风险，以及如何打破各大型项目各自为政的困局，实现产品化的敏捷交付。回归测试成为实现这些使命的基础。



使命——实现敏捷交付



前面提到，目前的开发模式是针对不同的大客户，分别设立了不同的大型项目进行开发。这些项目的交付周期往往数以年计，交付周期长，风险大。



生产环境又只有一套，而且已经有业务在生产环境上跑，代码合并困难，上线风险巨大。



我们希望能打破这种大型项目的交付形式，以产品化的思维进行管理。



具体实施的思路是：



1. 合并——对各大型项目的现有代码与生产环境的版本进行一次性的合并；

2. 统一Backlog——各类需求（包括现在以大型项目形式服务的大客户的需求）以用户故事的形式进入到同一个Backlog；

3. Scrum——建立以Scrum为形式的持续交付机制，以一个月作为Sprint的周期，通过Sprint计划会议敲定Sprint的交付计划；

4. 持续交付——每个Sprint完成计划内各用户故事的交付全流程，包括回归测试和上线到生产环境。



要实现以上模式，上线前的回归测试至关重要。而且由于一个Sprint内，也就是一个月内，要完成Sprint交付计划内所有用户故事的需求澄清、设计、开发、测试、用户验收和上线，时间非常紧，回归测试也必须在一、两天内完成。



如何实现既能充分保护生产环境，又能实现快速反馈的回归测试，成为一个重要议题。



自动化大量功能测试不可行



对于如何设计和实施覆盖率高、执行稳定而且快速的自动化回归测试，一直是一个难题。



我们曾经的一个思路是把现有的功能测试用例进行自动化，但很快发现这个思路不可行，主要原因如下：



1. 只能依赖UI测试——由于核心系统是供应商产品，开发是由供应商负责的，对我们来说就是个黑盒子，我们只能通过UI进行测试。众所周知，UI的自动化测试，开发、维护成本高，脆弱而且执行时间长；

2. 无法快速反馈——通过功能进行覆盖，要求不断增加测试用例来提高覆盖率，由于UI测试的执行时间长，用例越多，整体执行时间越长，如果执行周期要数以天计，则无法达到快速反馈的目的；

3. 性价比低——功能测试用例的覆盖率其实是不可见的，即使把所有功能测试都自动化了，其实际覆盖率依然不高，也就是说这个投入的性价比很低。



我们必须要寻找一种方法，以最小的投入获取最大的保障。



我们对回归测试自动化的预期进行了重新定位。我们进行回归测试，就是要保护生产环境的关键业务可以照常进行。我们要防止的，是新的特性发布造成生产环境灾难，也就是导致关键业务无法进行的大面积故障。对于非灾难性的小故障，完全可以通过运维手段来处理。



因此，我们不应该把回归测试定位为防止一切问题。



以不变应万变



基于以上对回归测试预期的重新定位，我们和业务部门协商，请他们列举出当前在生产环境上最关键的业务过程有哪些。我们要保证的是，当新的特性上线后的首个交易日，原有的最关键的业务过程不会受到严重影响。



基于这个预期，我们以业务部门提供的关键业务过程作为测试用例，并形成以下的回归测试思路：



准备阶段：



1. 在某个测试环境里，系统版本与生产环境版本相同；

2. 备份环境数据；

3. 以某个交易日为基准，执行相应的测试用例；

4. 备份输入、输出数据（包括生成的接口文件和报表）。



执行阶段：



1. 在该测试环境里，导入在准备阶段备份的环境数据；

2. 升级系统到目标版本；

3. 以准备阶段相同的交易日和相同的输入数据（在准备阶段已备份）执行相同的测试用例，生成相应的接口文件和报表；

4. 与准备阶段的输出（接口文件和报表）进行比对；

5. 如果目标版本的输出与原版本的对比没有非预期的差异，视为通过。



简单总结，就是对比两个系统版本在相同测试环境、相同环境数据、相同交易日、相同输入的情况下，输出是否有非预期的差异。



这个思路的最大特点是，以不变应万变。生产环境的关键业务过程不会经常变化，也就是说测试用例基本上比较固定。通过反复运行固定的测试用例实现回归测试的目标，保护生产环境上的关键业务过程，避免灾难。以最少的用例实现最大的保护。



而且测试的结果验证是通过比对不同版本的输出，我们不必在乎具体的输出内容，只需要关注输出是否有非预期差异。



当然，一旦有新的大客户上线，也就是有新的关键业务过程，这些过程也应该放入到回归测试用例中，用例的选择还是以避免灾难为准则。



在前面提到的功能测试思路里，我们需要不断增加测试用例以增加测试覆盖率，但是由于测试只能在UI进行，这样无限增加功能测试用例是不可持续的。



通过实践，我们发现要充分发挥这个新思路的价值，要注意以下几点：



1. 专属环境——由于这套环境需要反复整理环境数据和升级，一定要为这个回归测试准备一套专属的测试环境，不要在共享的环境里进行；

2. 明确检查点——由于执行测试输出的接口文件、报表里一定有时间戳、自增ID等每次执行都会变化的信息，不能简单通过文件来比对。在拟定测试用例时，就应该明确这些接口文件、报表里的有哪些数据需要检查。在每个版本交付时，开发人员也应该明确告知哪些数据检查点会有预期差异。否则对比工作将耗费大量的时间和精力；

3. 变更范围要小——如果对比的两个系统版本的变更范围太大，会导致输出有大量差异，比对意义不大。因此这个方法不太适合大的合并，比较适合落实了敏捷交付后，由于每个Sprint的变更范围较小，两个系统版本间的输出差异不多，比对较容易。



以这个思路建立了回归测试框架，我们便可以着手执行过程的自动化，从而提升其执行的效率。



总结



我们的核心系统是一套单体复杂系统，支撑全球多个国家和地区不同的业务。



为了实现敏捷交付，我们希望打破目前以大型项目为形式的各自为政，把各项目的所有需求放在统一的Backlog通过Scrum的方法进行持续交付。



要实现这一点，我们需要在每个Sprint都进行有效的回归测试，以保护生产环境的关键业务在新特性上线后不会有灾难性的故障。



通过对比两个系统版本在相同测试环境、相同环境数据、相同交易日、相同输入的情况下，执行关键业务过程的有限的测试用例，输出是否有非预期的差异的回归测试方法，以少胜多，以不变应万变，持续保护生产环境的核心业务，为持续交付保驾护航。





近期必读：



很不幸，自动化测试永远只能是必要非充分条件



为什么每个软件人都要懂点系统架构？



面对疫情这样的复杂问题，有什么招呢？



关于作者





刘华（Kenneth）



• 就职于世界500强银行，负责基金服务业务软件开发与交付

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书





小说体敏捷/DevOps转型教科书和实战经验分享



购书指南

纸质书、电子书在京东、当当、亚马逊、微信读书等渠道已全面上架，搜索关键字“猎豹 敏捷”即可找到。有声书已登录喜马拉雅、微信读书，适合路上听书的你。