为什么要做回归检查
修复本身可能引入新问题：在共享校验层加严条件后，正常业务流程可能被一起挡住；改动公共组件后，相邻接口的行为也可能发生变化。回归检查就是围绕修复的影响面验证正常功能仍然可用。范围要与影响面匹配，过宽会挤占窗口，过窄会漏检。
基本信息
| 检查对象 | 同一组件、同一校验层、共享代码路径 |
|---|---|
| 方法 | 正向用例加相邻接口抽查 |
| 记录 | 回归项清单与逐项结果 |
| 异常处理 | 发现新问题按新发现流程记录与定级 |
| 范围依据 | 由修复的影响面推导，而非凭经验拍定 |
典型使用场景
- 服务层统一修复：确认正常用户路径未被误伤
- 公共组件升级：验证依赖该组件的多个功能仍可正常使用
- 权限收敛：确认合法角色的正常访问未被限制
- 接口层改动：抽查同层其他接口行为是否一致
- 上线前核对：回归结果作为发布决策的输入
回归检查示例
回归检查示例
修复内容：订单归属校验（服务层统一实现）
回归项：
1. 本人订单查询仍可正常返回
2. 列表、详情与导出接口行为保持一致
3. 后台管理端查询不受影响
结果：三项通过，未发现新增问题回归范围与影响面
| 修复类型 | 回归重点 | 常见遗漏 |
|---|---|---|
| 服务层校验 | 正向业务流程与相邻接口 | 只测被改的那一个接口 |
| 公共组件升级 | 所有调用方功能 | 遗漏间接调用路径 |
| 配置调整 | 受影响角色的正常访问 | 只验证管理员视角 |
| 网关与规则变更 | 跨模块调用 | 忽略内部服务间调用 |
回归范围与修复影响面匹配：过宽浪费宝贵的复测窗口，过窄会在上线后暴露被改坏的功能。
回归中发现的新问题不要当噪音处理：按新发现流程记录、定级并纳入台账，否则会在下一轮重复出现。