回归测试基础回顾
回归测试到底是个啥
说白了，回归测试就是「改完代码再测一遍」。你想想看，每次我们修了个 Bug，或者上了个新功能，最怕的就是「修一个、炸一片」。我入行头两年就吃过这亏——改了个登录超时逻辑，结果下单接口全部超时，线上炸了半小时。
回归测试的核心任务就一个：保证旧功能没被新代码搞坏。它不关心你新加的特性好不好用，只盯着「以前能跑的东西现在还能不能跑」。
回归测试的目的
- 尽早发现问题：在发布前把回归缺陷揪出来，而不是等用户投诉。
- 验证系统稳定性：每次改动后，确认系统的核心链路依然可靠。
- 降低发布风险：尤其是 Feature Flag 场景下，切换开关可能瞬间影响全量用户。
- 积累测试资产：回归用例跑得多了，你自然知道哪些模块最脆弱。
我个人习惯把回归测试比喻成「给老代码盖个安全毯」——你每改一次，就抖一抖毯子，看看有没有落灰的隐患掉下来。
所以，回归测试的关键不在于「全」，而在于「准」。
范围选择策略
谈到策略，我得先泼盆冷水：没有银弹。每个团队的情况不一样，但我总结了三种最常用的方法，你可以根据项目阶段灵活搭配。
| 策略名称 | 核心逻辑 | 适用场景 | 我的经验 |
|---|---|---|---|
| 全量回归 | 所有功能用例全部执行 | 核心模块、大版本发布 | 平时别用，太贵。我只有发大版本时跑一次。 |
| 基于影响分析 | 只测被改动波及的模块 | 日常迭代、Feature Flag 开关切换 | 最推荐。我用代码依赖图和调用链推导影响范围。 |
| 风险导向 | 优先测曾经出过 Bug 的高风险区域 | 时间紧张、老项目重构 | 特管用。我曾经用这个方法把回归时间压缩了70%。 |
你可能会问：「那到底选哪个？」我的建议是：日常用「基于影响分析」，大版本用「全量+风险导向」组合。Feature Flag 场景下，建议再叠加一个「开关配置变更回归」——因为开关本身也可能有 Bug。
自动化回归的价值
讲实话，没有自动化，回归测试就是一场噩梦。我见过一个项目，每次发布前手动回归要花3天，20个人轮流转…上线前一天还在通宵测。后来上了自动化，回归时间从3天变成了30分钟。
自动化回归的价值具体在哪？我列几条特别实在的：
- 反馈快：代码提交后10分钟告诉你「挂了」还是「没事」。人肉测哪有这速度？
- 重复执行零成本：跑100次和跑1次花的是一样的人工精力（除了机器电费）。
- 消除人为遗漏：人总有漏测的时候，机器不会。
- 持续验证：可以在 CI/CD 管道里自动触发，每次合并都跑一遍。
一个真实例子
之前在做一个 Feature Flag 项目，有个开关叫「新版支付网关」。开关打开时走新服务，关闭时走旧版。
某天我在旧版上修了一个金额保留两位小数的问题。按理说只改旧版，不会影响新版。但人肉回归没发现问题，上线后才发现——新版也引用了同一个金额格式化函数。旧代码改了，新代码也跟着受影响，但是新代码没测试，结果线上多扣了用户一分钱。
这个教训告诉我：在 Feature Flag 场景下，回归测试必须同时覆盖开关打开和关闭两种状态。自动化回归可以轻松做到这一点，手动操作实在太容易漏了。
自动化回归的核心是「稳定的用例」+「合理的范围」+「持续维护」。缺一不可。
知识结构图
我的一些总结
回归测试这事，做多了你会发现一个规律：90%的回归缺陷都集中在20%的模块里。与其每次都手忙脚乱地跑全量，不如花精力把这20%的核心用例写稳、写好、自动化起来。
Feature Flag 给回归测试带来了一个新挑战——开关本身也是一个变量。我的建议是：把开关配置也纳入回归范围，写几个专门验证「开关切换后系统表现」的用例。别小看这几条，我曾经靠它们抓出过一个开关过期却忘记下线的隐患。
最后分享个小技巧：自动化回归用例里，我习惯加一条「健康检查用例」——只测最核心的功能（比如：用户能登录、能下单、能支付）。这条用例跑通了，其他用例哪怕没跑完，我也敢说「系统大概率是活的」。你想想看，是不是这个道理？