老功能突然不行了，别慌
上周我们团队上线了一个新功能，主要是优化下单流程。结果第二天早上，测试同事跑过来说购物车清空不了，用户一结算，之前加的东西全没了。这可不是新功能的问题，是老得不能再老的基础功能。我当时心里一紧——回归测试明明过了，怎么还出这种事？
先确认是不是真出问题
第一反应别急着改代码。先复现一遍，看看是不是偶发，或者环境问题。比如有一次我们发现登录失败，查了半天代码，最后发现是测试环境的数据库连接池满了，根本不是逻辑问题。所以第一步：把操作步骤写清楚，换个账号、换个设备再试一次。
如果是稳定复现，那就得进第二步了。
快速定位改动影响范围
打开 Git，查最近提交记录。重点看和出问题模块相关的文件有没有被改过。哪怕只是动了一行 import，也可能引入副作用。比如我们那次购物车问题，就是有人在优化加载速度时，顺手重构了一个全局状态管理的方法，结果这个方法正好被购物车依赖。
用 git diff 看具体修改：
git log --oneline -- shopping-cart.js user-state.js找到可疑提交后，可以 git checkout 回退到上个版本，验证问题是否消失。如果消失了，基本就能锁定问题来源。
临时应对：回滚还是热修复？
如果问题是线上已影响用户，就得做选择题。回滚整个版本最保险，但可能连累其他正常的新功能。如果改动不大，建议单独修复问题模块，打个热更新补丁。
比如我们那次就只修复了状态初始化逻辑，没动其他代码。补丁上线后，购物车恢复正常，下单流程也保留了。
从流程上减少类似问题
光救火不行，得堵住漏洞。我们后来做了三件事：
1. 关键老功能加自动化回归测试用例，每次提交自动跑一遍；
2. 提交前必须通过本地 run test，CI 不过不准合入；
3. 复杂改动必须两人 code review，尤其涉及公共模块。
有次新人想优化用户信息加载，提了 PR，review 的同事一眼看出他改了缓存 key 的生成规则，差点导致头像全部显示错乱。提前拦住了。
别让“以前好好的”成为借口
开发里最怕听“之前没问题啊”。系统是活的，今天改 A，明天改 B，A 和 B 碰一块可能就炸。老功能出问题不稀奇，关键是反应要快，路径要清。发现问题不怕，怕的是拖几天才暴露，那时候谁改的都忘了，更难查。
现在我们每天早会第一句就是：昨天有没有 regression（回归问题）？有就优先处理。慢慢就成了习惯。”,"seo_title":"回归测试发现老功能出问题如何应对","seo_description":"当回归测试发现老功能异常时，如何快速定位问题、选择回滚或修复，并通过流程优化减少后续风险","keywords":"回归测试,老功能出问题,代码回归,测试问题处理,效率提升,软件开发"}