9. 回归测试怎么做才不会漏测

回归测试看起来简单，很多人理解成"Bug 修了再测一遍"。

但真实项目里，回归测试做不好，很容易出现修了一个问题、带出三个新问题。

一、回归测试的目标是什么

回归测试有两个目标：

• 验证原问题是否修复；
• 验证修复没有影响相关功能。

所以回归不是只点原来的复现步骤，还要看影响范围。

二、先确认修改范围

回归前要问开发：

• 改了哪些文件或接口；
• 影响哪些模块；
• 是否改了公共组件；
• 是否涉及数据库脚本；
• 是否影响历史数据；
• 是否有配置变更。

如果开发改的是公共方法，那影响范围可能远大于当前 Bug。

三、原 Bug 必须按步骤验证

首先要验证原问题：

• 使用原账号；
• 使用原数据；
• 使用原环境；
• 按原复现步骤操作；
• 确认实际结果符合预期。

如果原问题是偶现，还要多次验证，并结合日志确认是否仍有异常。

四、相关功能要做影响范围回归

比如修复登录密码校验问题，相关回归可能包括：

• 正常登录；
• 错误密码；
• 验证码；
• 输错锁定；
• 修改密码；
• 找回密码；
• 多端登录；
• Token 过期。

如果只测错误密码，很可能漏掉其他登录相关问题。

五、核心链路优先回归

时间有限时，回归要按风险排序。

优先级一般是：

• 核心业务流程；
• 本次修改模块；
• 关联模块；
• 历史 Bug 高发区域；
• 低风险页面样式和文案。

比如订单模块改了金额计算，必须优先回归下单、优惠、支付、退款，而不是先看页面按钮颜色。

六、回归清单可以减少漏测

建议为核心模块维护回归清单。

比如订单回归清单：

• 正常下单；
• 库存不足；
• 优惠券使用；
• 支付成功；
• 支付失败；
• 取消订单；
• 退款；
• 订单状态流转；
• 数据库订单和库存一致性。

回归清单不是越多越好，而是覆盖核心风险。

七、上线前回归要关注环境差异

上线前还要关注：

• 测试环境和生产配置是否一致；
• 数据库脚本是否执行；
• 缓存是否刷新；
• 定时任务是否开启；
• 第三方接口地址是否正确；
• 灰度或开关配置是否正确。

很多线上问题不是代码没测，而是配置和环境差异导致的。

八、面试回答模板

可以这样回答：

回归测试我会先验证原 Bug 是否按复现步骤修复，然后根据开发修改范围判断影响模块。如果改动涉及公共方法、接口或数据库，我会扩大回归范围，覆盖相关功能和核心业务链路。时间有限时，我会优先回归主流程、高风险模块和历史 Bug 高频区域。对于订单、登录、支付这类核心功能，我会维护回归清单，避免每次只凭记忆测试导致漏测。

这个回答能体现你的风险意识。

九、下一步建议

建议你准备一个自己熟悉模块的回归清单。

例如：

• 登录模块回归清单；
• 订单模块回归清单；
• 审批流回归清单。