缺陷逃逸率是什么
缺陷逃逸率（Defect Escape Rate）衡量发布后才发现、而发布前测试未拦住的缺陷占比：逃逸缺陷数除以发布前发现数与发布后逃逸数之和，可按版本、模块、严重度分别统计。它是测试有效性的直接信号之一，但前提是缺陷记录口径稳定、统计窗口明确，否则数字没有可比性。
基本信息
| 常用公式 | 逃逸率 = 发布后缺陷 ÷（发布前缺陷 + 发布后缺陷）×100% |
|---|---|
| 发布前口径 | 测试与评审阶段发现并记录的缺陷 |
| 发布后口径 | 上线后由用户、支持团队或监控发现的缺陷 |
| 统计窗口 | 发布后固定观察期（如三十天）内，前后口径必须一致 |
| 细分维度 | 按模块、缺陷类型、严重度、发现阶段分层统计 |
| 配套指标 | 缺陷检出率、缺陷清除效率、平均修复时长 |
典型使用场景
- 版本复盘：对比相邻版本的逃逸率与逃逸缺陷分布，判断测试是否有效。
- 风险定位：逃逸缺陷集中在某模块时，检查该模块用例密度与评审质量。
- 流程改进：区分逃逸发生在需求、设计、编码还是测试环节，对症下药。
- 度量对话：与团队讨论拦不住的真实原因，而不是围绕数字互相指责。
- 发布决策：逃逸率异常升高时，在发布检查清单中增加对应风险项。
常见分母争议与建议
| 争议点 | 两种口径 | 建议 |
|---|---|---|
| 是否算需求类缺陷 | 算入或剔除 | 单列统计，不混入测试有效性口径 |
| 观察期多长 | 七天或三十天 | 各版本固定同一个窗口 |
| 监控发现的算不算 | 算入或只算用户报障 | 算入，但标注发现渠道 |
| 低严重度是否过滤 | 全部统计或只看高严重度 | 主指标看全部，辅以高严重度单独看 |
低基数时看趋势不看单点：小样本百分比波动大，至少连续几个版本再下结论。
口径要冻结：什么算逃逸、观察多久、需求变更导致的问题算不算，都要写进团队约定。