第2章 回归测试基础理论：概念、分类与基本原则
说实话，很多团队把“回归测试”简单理解为“再跑一遍”。但我告诉你，真这么干，项目迟早出问题。这一章，我会从最基础的东西讲起，把回归测试的概念、分类以及它与部署验证的关系彻底说清楚。
2.1 回归测试到底在测什么？
回归测试不是重复劳动。它的目标是——验证代码变更没有破坏已有功能。你改了A模块，B模块照样要能用；你升级了底层库，上层业务不能崩。这就是回归测试的核心逻辑。
我见过一个项目，开发改了底层缓存中间件的连接池参数，自测时所有接口都正常。结果回归测试一跑，发现某个定时任务因为连接超时直接挂掉。这就是典型的“改一处、炸一片”。没有回归测试，这种问题上线就是故障。
2.2 回归测试的分类
按粒度、策略和触发时机，我习惯把回归测试分成以下几类。表格里列清楚了：
| 分类维度 | 类型 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 按粒度 | 单元回归、接口回归、UI回归、端到端回归 | 单元回归跑单测，接口回归跑契约，UI回归跑截图对比 | 曾在端到端回归中漏掉了数据库回滚验证，导致数据脏写 |
| 按策略 | 完全回归、选择性回归、冒烟回归 | 完全回归（发布前全量跑）、选择性回归（只跑改动影响模块） | 选择性回归依赖精准的依赖分析，有一次分析漏了公共工具类，结果线上挂了 |
| 按触发方式 | 持续回归（CI触发）、定时回归（日/周）、发布前回归 | CI回归通常只跑核心用例，发布前跑全量 | 持续回归如果跑全量导致流水线过慢，开发者经常跳过，后来我拆成了分层 |
你看，每种分类都有它的适用场景。我个人习惯在项目中同时保留三种粒度：单元回归保底层、接口回归保协议、端到端回归保流程。这样出了问题，定位速度能快很多。
2.3 回归测试的基本原则
做回归测试这么多年，我总结出四个原则。你想想看，是不是这么回事：
- 原则一：先核心后外围。用户最常用的功能，必须优先回归。我曾经按模块时间顺序排用例，结果把登录流程放到了最后，上线后才发现登录挂了……从那以后我每次回归都先跑核心路径。
- 原则二：增量回归优于全量回归。每次变更只跑受影响的部分。怎么判断受影响？靠代码依赖图、调用链分析、或者历史故障记录。全量回归虽然安全，但成本太高，不适合每日频繁发布。
- 原则三：回归用例要持续更新。每次新功能上线、每次线上故障修复，都要补对应的回归用例。这就像一个“安”，网眼不能越来越大。
- 原则四：回归结果要有可追溯性。谁跑的？跑了哪些用例？结果如何？失败原因是什么？这些信息必须记录下来。不是为了问责，是为了下次改同一块代码时能快速定位。
2.4 回归测试与部署验证的关系模型
很多同学问：回归测试和部署验证到底啥关系？是同一件事吗？
不是。但两者高度关联。部署验证是对部署行为本身和环境的验证——比如版本包是否正确、配置文件有没有漏、服务能不能正常启动。而回归测试是对软件功能逻辑的验证——代码改完后，业务逻辑是否还正常。
我一般把两者的关系画成一个模型：
下面这张图直观地展示了回归测试与部署验证的全景关系：
从图中你可以看到：代码变更后，左右两条线并行。左边是部署验证（快而浅），右边是回归测试（慢而深）。只有当两者都通过，才允许发布。这就是 “先验证部署，再回归功能，最后合闸生效” 的执行顺序。
这里有个细节：部署验证如果失败，就别做回归测试了。节省时间，尽快修复配置或环境问题。只有部署验证通过后，回归测试才有意义——因为你确保代码已经正确部署到了目标环境。我见过团队在部署验证没通过的情况下强跑回归，结果全是环境不一致导致的假失败，白白浪费了30分钟。
2.5 实战中如何落地这一模型？
落地其实不复杂。我以CI流水线为例，给你一个实际流程：
- 代码合并到主干 → 触发流水线。
- 阶段一：部署验证（30秒）
检查产物版本号、配置文件占位符替换、端口连通性、健康检查接口返回200。全部通过才进入下一阶段。 - 阶段二：回归测试前置（1分钟）
运行冒烟回归集（20～50条核心用例），快速判断是否有重大缺陷。 - 阶段三：全量回归（非阻塞，异步执行）
全量回归用例库（2000+条）在后台运行，结果汇总到质量看板。不阻塞发布，但如果失败会发告警。 - 发布决策：阶段一和阶段二全部通过 → 自动上线；阶段三失败 → 触发回滚并通知值班人员。