回归测试基础：从"改不动"到"放心改"

说到回归测试，我脑子里第一个蹦出来的画面是——几年前一个深夜，我盯着流水线里红了一大片的测试报告，头皮发麻。那次我们只改了一行配置，结果导致三个核心模块的接口全挂了。嗯，从那以后我再也不敢小看回归测试了。

说白了，回归测试就是：你改了一处代码，要确保其他没改的地方没被你搞坏。它不是什么高深的理论，而是每个开发者每天都要面对的现实。

1. 什么是回归测试？先讲个故事

想象你有一栋房子，今天你给客厅换了一盏灯。结果发现——卧室的插座没电了。你换灯和卧室插座有啥关系？没有直接关系，但可能你换灯时不小心碰到了总闸的一根线。

代码也是一样。你改了A模块，B模块可能就崩了。为什么？因为代码之间总有隐形的依赖：共享变量、全局配置、接口契约、数据库表结构……你改了一处，另一处可能就默默挂了。

回归测试就是那个帮你"试灯"的过程——在你提交代码后，自动跑一遍已有的测试用例，看看有没有新引入的失败。

我个人习惯把回归测试分成两个层次：

• 单元回归——改完一个函数，跑这个模块的所有单元测试
• 集成回归——改完一个服务，跑整个系统的集成测试/端到端测试

为什么非要分两层？因为我在项目里吃过亏。有一次我只改了底层工具类，觉得单元测试过了就没跑集成测试，结果把上游三个服务的JSON序列化格式全改了——白花了两天回滚。所以现在我的原则是：单元测试保底，集成测试救命。

2. 为什么CI中回归测试那么重要？

这个问题我问过很多团队。得到的答案五花八门，但核心就一句话：不跑回归测试的CI，就是个摆设。

你看，CI（持续集成）的本质是什么？是让每个人每天多次把代码合并到主干，然后自动构建、自动测试。如果少了回归测试这一步，会发生什么？

1. 合并灾难：你合并代码时觉得没问题，结果把别人昨天刚修好的bug给覆盖了。等到上线才发现，所有人都一脸懵。
2. 反馈延迟：传统模式里，测试可能等到下班前才跑一轮。CI里的回归测试应该在每次提交后几分钟内给出结果。我见过最夸张的团队——回归测试跑8小时。你想想看，等到第二天上班才知道昨天的提交挂了，这反馈还有什么意义？
3. 信任崩塌：如果CI流水线经常假绿（测试通过但实际有bug），或者经常假红（测试不稳定但代码没问题），团队就不再信任流水线了。我前东家就发生过这种事——流水线红了没人管，因为"那个测试太随机了"。最后花了三周重构了回归用例，才把信任找回来。

CI中回归测试的价值，用一句话总结就是：把"我改坏了什么"这个问题的答案，从"上线后才知道"提前到"提交时就知道"。

场景	无回归测试的CI	有回归测试的CI
改了一个公共工具类	所有调用方可能默默挂掉，上线后才暴露	回归测试立即发现失败，可以回退或修复
升级了第三方依赖版本	接口兼容性问题等到E2E测试才暴露，通常要等几天	回归测试在几分钟内发现，依赖升级可以安全推进
合并了多个分支的代码	冲突只在构建时发现，逻辑冲突很难察觉	回归测试覆盖逻辑冲突，让合并更加安全

3. 与传统回归测试的区别

传统回归测试是什么样的？我记得刚入行时，团队的做法是：开发完成一个版本后，QA手动拉一份测试用例清单，一条一条执行。整个过程持续两三天，数据量大的项目甚至一周。

为什么CI里的回归测试不一样？我总结了四个关键区别：

• 频率：传统回归测试通常在版本发布前做一次；CI里每次提交都要做，一天可能几十次。
• 范围：传统回归测试追求全覆盖，所有用例都跑一遍；CI里讲究"快速反馈"，会优先跑受影响范围内的用例，再补全量回归。
• 触发方式：传统回归测试是人工触发的；CI里是自动触发的——代码一推，流水线自动跑。
• 结果处理：传统回归测试失败后，QA需要写bug报告，通知开发修，定位问题可能又花一天；CI里失败后，开发者能立刻看到失败的用例和日志，可以秒级定位。

你想想看，传统回归测试"跑一次等三天"，而CI回归测试"每次提交等五分钟"——这背后不仅仅是效率的提升，更是开发模式的转变。它让你敢改、能改、改完放心推。我个人认为，回归测试从传统走向CI，核心变化就是"反馈速度"的飞跃。

总结一句

回归测试在CI里不是可选项，而是必选项。它让你的每一次修改都有人替你"兜底"，让你的每个提交都更安全。我见过太多团队因为没有回归测试，把CI流水线变成了"自动部署工具"，而不是"质量守护者"——说白了，那等于没做CI。

记住：没有回归测试的CI，不算真正的持续集成。