生产缺陷回灌是什么
生产缺陷回灌指把线上发现的缺陷、事故与用户反馈转化回测试资产：补充或修正用例、扩充测试数据、更新检查清单，让同类问题在后续版本中被提前拦截。回灌是逃逸缺陷的唯一正确去向——不转化就只是被记录，转化了才形成防再犯的闭环。
基本信息
| 输入来源 | 线上缺陷、故障复盘、用户报障、监控告警事件 |
|---|---|
| 转化形式 | 新增用例、修正预期值、补充边界数据、更新检查清单 |
| 必要动作 | 找到漏检原因：用例缺失、数据缺失、环境差异还是流程缺口 |
| 覆盖目标 | 复现路径固化为回归用例，进入常规回归集 |
| 跟踪机制 | 回灌项登记责任人、完成期限、复核状态 |
| 统计视角 | 回灌数量与逃逸缺陷数量的比值反映闭环健康度 |
典型使用场景
- 线上故障复盘后：把触发场景写成用例，防止修复后场景退化。
- 用户报障清理：对每条报障判断是否应转化为回归资产。
- 版本对比：新版本上线前，用历史线上场景集中回放验证。
- 验收标准迭代：把业务侧真实痛点补充进验收清单。
- 新人培训：用真实线上案例讲清被测系统的高风险区。
漏检原因与对策
| 漏检原因 | 对策 |
|---|---|
| 用例缺失 | 补用例并进入回归集 |
| 数据场景缺失 | 扩充测试数据集与生成规则 |
| 环境差异 | 记录差异点，评估仿真或线上验证方式 |
| 流程缺口 | 更新发布检查清单与评审项 |
| 需求理解偏差 | 把验收标准写得更可验证 |
回灌不是只加一条用例：要问清为什么当时没测到，否则补的只是个例。
回灌资产要有人维护：登记责任人并定期复核，避免补完就再没人跑。
回灌要趁热做：故障后一周内完成转化，细节记忆还在，成本最低。