回归测试的实践与思考

上周写了一篇关于测试过程效率演变的文章，其中聊了很多过程改进的方法。比如：需求阶段应该做好评审和风险预案；研发阶段应该做好质量卡点，持续集成流水线以及为研发自测做好辅助工作；测试阶段的重点是测试计划和质量门禁，同时关注线上的发布质量，通过线上巡检和监控，持续提升测试过程效率和最终的交付质量。

很多时候我们都在关注整体的质量和效率，却往往忽视了一些细节的东西，比如回归测试。很多人会觉得回归测试不就是把case重新执行一遍，看看有没有新的问题就行了。但实际上，很多线上的问题其实都需要在回归测试环节来评估验证。

这篇文章，我想聊聊我对于回归测试的思考，以及些许实践。

软件研发测试的交付模型

软件从需求出现到最后的线上发布，大致要经历如下几个阶段：

需求阶段：需求阶段测试介入，主要是评估本次测试所涉及的范围，评估需要投入的测试资源，以及所需的时间。这三点是影响质量最根本的三要素，如果在需求阶段三者无法抉择平衡，那后续测试工作的开展难度会变得很大。

开发阶段：进入开发阶段时一般本版本的迭代计划就确定了，包括技术实现方案、提测时间、验收和发布时间。这个时候的重点在于尽可能提升研发编码质量(code review&单元测试)，以及做好质量卡点(提测质量&冒烟测试)，以便于降低后续执行测试用例时的成本。

测试阶段：正常来说，测试阶段可以划分为四个部分，即集成测试(接口测试&执行用例)、系统测试(业务链路测试&组合场景测试)、回归测试(全业务链路测试)、验收测试(产品业务方介入，评估是否符合需求要求和预期)。

发布阶段：发布阶段测试工作的重点，其实就是变更检查。因为发布阶段，是将代码合并，发布到灰度/预发环境，其中涉及到很多的参数&字段&文件变更，如果这个阶段对于变更没有很严格的规范和变更检查，那么很容易导致发布到线上时出现各种各样的线上问题。

回归测试要解决什么问题

从提测到线上发布，大部分的测试活动开展集中在这个阶段。其中：

• 单元测试是验证最小实现单元的逻辑符合预期；
• 冒烟测试是保证后续测试活动可以正常开展不被主流程阻塞；
• 集成测试主要是验证单一业务模块的数据交互逻辑和功能实现符合预期；
• 系统测试主要是验证多个应用之间的调用依赖关系以及复杂业务场景的功能实现正确与否；
• 回归测试时会将各个develop分支代码合并，验证已发现的bug是否都已修复，以及合并后是否引入了新的bug；
• 验收测试的主要目的，除了需求和产品介入验证待发布的产品是否符合预期之外，还有就是达成一致的发布决定；

换个角度理解，回归测试将测试的范围从本次迭代的技术团队内部，扩展到了整个软件产品范围。即回归测试之前，大家关注的重点是本次迭代的需求是否实现，是否存在问题；而回归测试，则是要评估本次迭代是否兼容了历史版本，是否会影响之前已实现的功能。

软件测试工作除了要保障每次迭代的质量，还要考虑全局的整体软件质量，回归测试的作用就是从阶段走向全局，这也是为什么很多自动化测试工作都是从回归测试阶段介入的原因。

需求可能存在逻辑缺陷，研发在编码实现和修复bug时也无法顾及全局的质量，这才是回归测试的意义。通过更大范围的验证，来保障整体的交付质量符合预期。

回归测试的实践注意事项

在具体的工作实践中，回归测试遇到的最大挑战，就是回归的范围如何界定。结合我的实践经验，我个人认为可以从如下几点来考量：

• 选择迭代需求对应的测试用例(确认问题修改的正确性和修改的扩散局部影响性)；
• 选择重点部分的测试用例(如果回归测试成本高耗时久可以如此，但可能会遗漏，因此测试用例需要分级)；
• 选择修改部分直接关联的测试用例(前期测试被修改模块对应的测试用例，进行覆盖验证)；
• 选择修改部分间接影响模块对应的测试用例(比如修改了支付相关bug，选择订单模块的用例进行验证)；
• 选择最小的测试用例集合进行回归(比如直接修改部分100%覆盖，间接影响部分80%覆盖，业务主流程60%覆盖)；

上述提到的几点回归测试范围界定的方法仅供参考，因为很多工作并不只是回归测试阶段开展。比如：需求分析阶段就要确定测试点和关联范围；用例设计阶段就要结合需求进行用例优先级和用例集合划分(打标签)；集成和系统测试阶段就要对用例和缺陷进行关联，避免遗漏。

软件测试是一个系统性的工作，除了要关注执行细节，还要从全局来考虑，这也是为什么要设计测试计划的原因。