面试时被问到「回归测试在哪个阶段」，很多人会答「系统测试之后」。这个答案不算错，但把它当成唯一答案就会出问题。回归测试更像一种贯穿全程的活动，而不是流水线上的一道工序。

它跟着「改动」走，不跟着阶段走

只要代码、配置、依赖、数据其中任何一项变了，就可能影响原有功能，这时候就需要回归。单元测试改完一个函数要回归，集成时接口改了要回归，上线前合并分支要回归，线上热修复之后还要回归。所以问它在哪个阶段，准确的回答是：每个阶段都可能有。

各阶段分别回归什么

  • 开发阶段：改完一个模块，跑该模块及相关模块的单元测试，范围小、频率高。
  • 集成阶段：接口联调后，回归主流程和上下游依赖，重点看数据格式和异常分支。
  • 系统测试阶段：新功能测完后，把老功能的核心用例再跑一遍，防止改 A 坏 B。
  • 上线前：对整个版本做一次全量或抽样的回归，通常配合冒烟测试。
  • 线上修复后：热修的影响面往往更大，回归范围要按影响分析来定。

冒烟和回归经常被混着说。冒烟是「能不能跑起来」，几分钟到半小时，只覆盖主流程；回归是「原来对的现在还对不对」，范围大得多。上线前一般先冒烟，通过了再决定回归跑多少。

范围怎么定，比跑多少更重要

全量回归听着稳妥，实际很难每次都做，尤其是手工用例上千条的项目。比较务实的做法是先做影响分析：这次改了哪些文件、调用了哪些接口、哪些表结构动了，顺着依赖往下推，把直接相关的用例标出来优先跑，其余按风险抽样。

还有一个常被忽略的点：缺陷修复后的回归。修一个 bug，至少要把这个 bug 的复现步骤跑一遍，再把同一模块的相邻功能跑一遍。只验证「问题没了」而不验证「没引入新问题」，等于只做了一半。

能自动化的尽量自动化

回归测试重复度高、用例稳定，是最适合自动化的部分。接口层的用例优先做，投入产出比最高；UI 层的用例维护成本大，只保留最核心的几条链路就够了。自动化跑起来之后，回归就从「每次要不要做」变成了「每次自动跑」，讨论阶段的必要性也就小了。

回到最初的问题：如果一定要给个位置，可以说回归测试主要发生在系统测试之后到上线之前，但它真正的触发条件是变更。理解这一点，排期和用例范围才不会被「阶段」两个字框住。