9. 回归测试怎么做才不会漏测？
回归测试看起来简单，很多人理解成“Bug 修了再测一遍”。
但真实项目里，回归测试做不好，很容易出现修了一个问题、带出三个新问题。
一、回归测试的目标是什么
回归测试有两个目标：
- 验证原问题是否修复；
- 验证修复没有影响相关功能。
所以回归不是只点原来的复现步骤，还要看影响范围。
二、先确认修改范围
回归前要问开发：
- 改了哪些文件或接口；
- 影响哪些模块；
- 是否改了公共组件；
- 是否涉及数据库脚本；
- 是否影响历史数据；
- 是否有配置变更。
如果开发改的是公共方法，那影响范围可能远大于当前 Bug。
三、原 Bug 必须按步骤验证
首先要验证原问题：
- 使用原账号；
- 使用原数据；
- 使用原环境；
- 按原复现步骤操作；
- 确认实际结果符合预期。
如果原问题是偶现，还要多次验证，并结合日志确认是否仍有异常。
四、相关功能要做影响范围回归
比如修复登录密码校验问题，相关回归可能包括：
- 正常登录；
- 错误密码；
- 验证码；
- 输错锁定；
- 修改密码；
- 找回密码；
- 多端登录；
- Token 过期。
如果只测错误密码，很可能漏掉其他登录相关问题。
五、核心链路优先回归
时间有限时，回归要按风险排序。
优先级一般是：
- 核心业务流程；
- 本次修改模块；
- 关联模块；
- 历史 Bug 高发区域；
- 低风险页面样式和文案。
比如订单模块改了金额计算，必须优先回归下单、优惠、支付、退款，而不是先看页面按钮颜色。
六、回归清单可以减少漏测
建议为核心模块维护回归清单。
比如订单回归清单：
- 正常下单；
- 库存不足；
- 优惠券使用；
- 支付成功；
- 支付失败；
- 取消订单；
- 退款；
- 订单状态流转；
- 数据库订单和库存一致性。
回归清单不是越多越好，而是覆盖核心风险。
七、上线前回归要关注环境差异
上线前还要关注：
- 测试环境和生产配置是否一致；
- 数据库脚本是否执行；
- 缓存是否刷新；
- 定时任务是否开启；
- 第三方接口地址是否正确；
- 灰度或开关配置是否正确。
很多线上问题不是代码没测，而是配置和环境差异导致的。
八、面试回答模板
可以这样回答：
回归测试我会先验证原 Bug 是否按复现步骤修复，然后根据开发修改范围判断影响模块。如果改动涉及公共方法、接口或数据库，我会扩大回归范围，覆盖相关功能和核心业务链路。时间有限时，我会优先回归主流程、高风险模块和历史 Bug 高频区域。对于订单、登录、支付这类核心功能，我会维护回归清单，避免每次只凭记忆测试导致漏测。
这个回答能体现你的风险意识。
九、下一步建议
建议你准备一个自己熟悉模块的回归清单。
例如：
- 登录模块回归清单；
- 订单模块回归清单；
- 审批流回归清单。
配套刷题：
