第一章：回归测试基础

1.1 什么是回归测试

回归测试，说白了就是——改完代码后，再跑一遍老用例。

你可能会问：「这有什么好讲的？」嗯，我刚开始做测试时也这么想。直到有一次，我改了一行配置，结果把登录模块搞崩了。那行代码跟登录八竿子打不着，但就是出了问题。

回归测试的核心逻辑很简单：确保新代码没把老功能搞坏。它不测新功能好不好用，只关心旧功能还能不能用。

举个例子。你有个电商系统，下单流程跑得好好的。某天你优化了库存查询的SQL，觉得稳了。结果上线后，用户下单时总报「库存不足」——明明有货，就是下不了单。这就是典型的回归问题。

1.2 回归测试的目的与价值

回归测试的目的，我总结成三个字：保底线。

• 目的一：发现「副作用」——改A坏B，这是最常见的坑
• 目的二：验证「兼容性」——新代码跟老模块能不能和平共处
• 目的三：守住「质量基线」——每次发布，质量不能往下掉

它的价值在哪？我直接说个真实案例。

我在项目中遇到过一件事：一个支付模块，开发改了超时时间配置。他觉得「就改个数字，没事」。结果上线后，所有微信支付都回调失败。为什么？因为超时时间改了，但回调接口的签名校验逻辑没同步更新。

如果当时有回归测试，这个事故完全可以避免。你想想看，一个配置项引发的连锁反应，靠人工review根本看不出来。

1.3 回归测试在软件生命周期中的位置

回归测试不是独立存在的。它贯穿整个软件生命周期，但有几个关键节点特别重要。

阶段	回归测试的作用	我的建议
单元测试阶段	验证单个模块修改后不影响其他模块	每个开发提交代码前，跑一遍单元回归
集成测试阶段	验证模块间接口是否正常	每次集成后，跑核心接口的回归用例
系统测试阶段	验证全流程功能是否正常	每周跑一次全量回归，别等上线前
上线前	最终把关，确保质量达标	必须跑完所有P0级回归用例

为什么会这样安排？因为越早发现问题，修复成本越低。我曾经在一个项目里，上线前才跑回归，结果发现核心流程全挂了。开发通宵改代码，测试通宵验证，所有人都崩溃。

从那以后，我养成了一个习惯：每次代码合并前，先跑一遍回归。哪怕只改了一行注释，也要跑。你可能会觉得「太夸张了吧？」但说实话，被坑过几次你就懂了。

1.4 回归测试的常见误区

聊几个我见过的典型误区，你对照看看自己有没有中招。

• 误区一：回归测试 = 手工点点点——手工回归效率低、易遗漏。我建议至少把核心流程自动化
• 误区二：回归用例越多越好——不是的。用例多了维护成本高，跑一次要半天。关键是「精准回归」
• 误区三：回归测试是测试的事——错了。回归测试是团队的事。开发也要参与，至少保证单元回归通过

我记得有个项目，测试团队维护了2000多条回归用例。每次回归要跑8小时，结果呢？大部分用例都是冗余的。后来我们做了用例精简，只保留500条核心用例，回归时间缩短到1小时，缺陷发现率反而提升了。

为什么？因为用例多了，反而容易「灯下黑」。你想想看，2000条用例跑完，你敢说每条都看了结果吗？大概率是「绿了就过，红了再看」。但500条用例，每条都能仔细核对。

1.5 回归测试的自动化策略

说到自动化，我个人的经验是：不要一上来就想全自动化。

先问自己三个问题：

1. 哪些用例是每次回归必跑的？——这些优先自动化
2. 哪些用例跑一次要很久？——这些考虑并行执行
3. 哪些用例经常变？——这些先别自动化，等稳定了再说

我一般这样划分：

优先级	用例类型	自动化策略
P0	核心业务流程	必须自动化，每次提交触发
P1	重要功能模块	自动化，每日定时执行
P2	边缘场景	手工执行，每周一次

嗯，这里要注意：P0用例的自动化，一定要做到「稳定可靠」。我见过太多团队，自动化用例跑一次挂一次，最后没人敢信。那还不如手工跑。

1.6 小结

回归测试不是什么高深的技术，但它是一个「保命」的环节。我做了这么多年测试，最大的感悟就是：没有回归测试的发布，就是在赌运气。

你可能会觉得「我们项目小，不用搞这么复杂」。但说实话，项目越小，越经不起线上事故。一次故障，可能就把用户信任全毁了。

所以我的建议是：从今天开始，给你的项目加上回归测试。哪怕只有10条核心用例，也比没有强。

下一章，我会讲如何设计回归测试用例。咱们聊聊「怎么选用例」「怎么维护用例」「怎么让回归测试真正落地」。到时候见。