回归测试

回归测试

回归测试是在软件修改后，重新执行之前通过的测试用例，确认原有功能没被新代码破坏的一种验证手段。

说白了，就是改完bug、加完新功能之后，回头把老功能再跑一遍，看看有没有“修好这个，崩了那个”。我干这行八年，几乎每个项目都栽过这种坑——最典型的是去年一个支付模块升级，开发顺手优化了订单状态判断逻辑，结果导致退款成功后订单状态卡在“待发货”，三天才被客服发现。

它不是可有可无的补救措施，而是上线前必须走的一步。跳过回归测试就上线，等于把风险直接甩给用户。

实际操作中，回归测试范围得看改动大小：

• 改一行工具类方法，可能只测调用它的2–3个核心流程
• 重构整个用户登录模块，就得覆盖所有关联场景：手机号、微信授权、游客转正式账号、登出再登录……甚至包括弱网重试和token过期处理
• 如果用的是自动化回归，要注意脚本维护成本——我见过团队花三个月写了一套UI回归脚本，结果半年后因为页面元素ID全换了，脚本失效率超70%，最后反而拖慢了迭代节奏

手工回归容易漏，自动化回归又怕“假绿灯”（测试通过但实际业务逻辑已偏移）。所以真正靠谱的做法是：核心路径用自动化保底，高频异常分支靠手工点检，每次发版前拉上测试、开发、产品三方一起过一遍关键链路。

这一点非常关键。