修复验证范围是什么
修复验证范围指缺陷修复后，验证工作要覆盖到哪里：只按原步骤复测缺陷点远不足以收工，还需要覆盖代码变更的影响面、相关功能回归与数据一致性检查。范围定得准，验证既不过度也能兜住风险；范围拍脑袋，要么漏检耦合问题，要么每次全量回归拖垮进度。
基本信息
| 最小范围 | 按原复现步骤验证缺陷已修复，边界条件一并覆盖 |
|---|---|
| 影响面来源 | 代码 diff、调用方、公共组件、配置与数据变更 |
| 回归取舍 | 高频路径必测，低频路径按影响概率抽样 |
| 数据检查 | 修复涉及数据修正时要核对存量与新增数据 |
| 历史参考 | 同类缺陷的历史波及范围往往可复用 |
| 结论记录 | 验证结论写明覆盖了什么、没覆盖什么、残留风险 |
典型使用场景
- 公共库修复：被多模块引用的组件改动后，按调用方清单逐项回归。
- 数据脚本修复：验证修复逻辑的同时抽查存量数据是否已修正。
- 接口变更修复：除接口本身外，复测消费该接口的下游行为。
- 紧急热修：时间受限时按影响面矩阵圈定最小必测集。
- 疑难缺陷：修复不彻底反复重开时，先扩展验证范围找遗漏场景。
范围判定信号
| 信号 | 扩展动作 |
|---|---|
| 改动触及公共组件 | 全部调用方回归 |
| 改动涉及数据写路径 | 核对数据一致性与幂等 |
| 缺陷由分支条件触发 | 补齐同分支相邻条件用例 |
| 修复跨多个提交 | 按提交逐个确认影响 |
| 历史重开过的缺陷 | 扩大回归并复看关联脚本 |
验证不是只验缺陷点：修复本身也可能引入新问题，影响面回归是必要成本。
范围要写进验证记录：写清覆盖边界，后续重开时才有对比依据。
时间压缩时优先保高频路径与数据正确性，别把回归砍到只剩原步骤。