逃逸缺陷指在某个测试或评审环节未被发现，直到更后阶段（如验收、上线、客户使用）才暴露出来的缺陷。判断一个缺陷是否属于逃逸缺陷，关键在于它相对于哪一道质量关口“逃逸”：同一缺陷以测试完成为关口可能算逃逸，以发布评审为关口则可能不算。本文说明定义、边界、产生链路，并给出记录与复盘方法。
要点总览（TL;DR）
- 逃逸缺陷指缺陷在经过某道既定质量关口时未被拦截，流入关口之后的阶段才被发现；判定前必须先确定参照关口。
- 同一缺陷以测试完成为关口可能算逃逸，以发布评审或客户验收为关口则结论可能不同，统计口径需在团队内统一。
- 已知风险评审放行、关口之后新引入的问题、客户自行变更导致的配置错误，通常不纳入逃逸缺陷。
- 逃逸缺陷是对象，缺陷泄漏率是度量，线上缺陷只描述发现位置；回归缺陷与遗留缺陷属于另外的判定维度。
- 预防依赖结构化记录：发现阶段、参照关口、引入环节、漏出原因、关联需求与版本，并把复盘结论转为可跟踪的改进工作项。
逃逸缺陷的直接定义
逃逸缺陷（英文常见说法为 escaped defect 或 defect escape）可以复述为：缺陷在经过某道既定的质量关口时未被拦截，流入该关口之后的阶段才被发现。这个定义包含三个要素：缺陷本身客观存在、有一道本应拦截它的关口、以及它在关口之后才暴露。
把定义拆开看，需要回答三个问题。第一，谁在什么阶段漏掉了什么——通常是测试、评审或验收角色，在用例执行、代码评审、发布检查等活动中，未能识别出某个已经存在的缺陷。第二，在哪个环节被发现——可能是下一轮测试、上线验证、客户验收或生产环境使用中。第三，参照的是哪道关口——这是判定的前提。没有关口，就没有“逃逸”的方向。
因此，讨论逃逸缺陷时，规范的表述应当带上关口，例如“相对于系统测试完成关口逃逸的缺陷”“相对于发布评审关口逃逸的缺陷”。只说“这是逃逸缺陷”而不交代参照关口，容易在团队之间产生口径分歧。同一份缺陷清单，测试团队按测试完成口径统计，运维团队按上线关口统计，数量可能相差很大，但两者都不算错，只是参照点不同。
哪些缺陷算逃逸，哪些不算
划定边界的关键，是先明确统计口径，再逐条判断。常见的参照关口有三类：测试阶段关口（如单元测试完成、系统测试完成）、发布关口（如发布评审通过、灰度结束）、客户环境关口（如客户验收、正式使用）。同一缺陷在不同口径下可能纳入，也可能排除。
下面按情形列出纳入与排除的判断：
| 情形 | 是否属于逃逸缺陷 | 判断依据 |
|---|---|---|
| 系统测试用例已覆盖该场景但未执行到位，上线后发现 | 属于（以测试完成为关口） | 关口内本应拦截，实际漏出 |
| 测试环境无法复现、生产环境才暴露的环境差异问题 | 视口径而定 | 若关口定义包含生产环境验证，则不算逃逸；若以测试完成为关口，则属于漏出 |
| 需求理解偏差导致实现与预期不符，验收时才被业务方指出 | 通常属于（以需求评审或验收为关口需分别判断） | 若需求评审关口未识别歧义，可计为相对该关口的逃逸 |
| 已知风险经评审后决定放行的问题 | 不算 | 属于有意识的决策，不是未被拦截 |
| 上线后因新需求变更引入的问题 | 不算 | 缺陷在关口之后才被引入，不存在“逃逸” |
| 客户环境特有的配置错误 | 视责任边界而定 | 若配置由交付方提供且未经检查，可纳入；若属客户自行变更，一般不纳入 |
需要说明的是，跨团队质量指标体系的设计、服务事件的根因分析与问题管理流程，属于另外的管理主题，本文不展开。这里只解决“一个缺陷算不算逃逸”这一判断问题。
逃逸缺陷是怎么产生的：从引入到暴露的链路
逃逸缺陷的形成可以概括为一条链路：缺陷在某个人工或自动环节被引入，经过若干道拦截关口，因关口覆盖不足而未被识别，最终在更后阶段暴露。理解这条链路，比记住定义更有助于预防。
缺陷引入环节与拦截关口通常存在对应关系。需求阶段的歧义，应由需求评审和验收标准检查来拦截；编码阶段的逻辑错误，应由代码评审、单元测试和静态检查来拦截；集成阶段的接口不匹配，应由集成测试来拦截；环境与配置问题，应由部署验证和预发环境检查来拦截。当某道关口缺失、执行不充分，或关口与引入环节不匹配时，缺陷就有了漏出的通道。
常见的漏出路径包括：
- 关口覆盖不足：某类变更没有对应的评审或测试环节，例如配置修改、脚本调整、依赖升级未纳入常规检查。
- 用例缺失或过期：需求已变化，测试用例未同步更新，导致新逻辑没有被验证。
- 环境差异：测试环境的数据量、依赖版本、网络条件与生产不同，问题只在真实环境出现。
- 执行偏差：用例存在但未按计划执行，或执行结果未被认真核对。
- 交接信息丢失：评审中提出的疑问未形成可跟踪的条目，后续环节无人跟进。
发现阶段越靠后，修复与影响成本通常越高。测试阶段发现，修复范围局限在代码与用例；上线后发现，往往还涉及回滚、数据修复、客户沟通和信任损失。这一趋势是团队愿意单独统计逃逸缺陷的直接原因，但具体成本差异因系统和业务而异，不宜套用固定倍数。
逃逸缺陷与缺陷泄漏率、线上缺陷的区别
这三个说法经常混用，实际指向不同层面。逃逸缺陷是对象，指某一个具体的缺陷；缺陷泄漏率是度量，指逃逸缺陷在总体缺陷中的占比；线上缺陷是发现位置的描述，只说明缺陷在哪里被发现。三者关系可以用一句话概括：用泄漏率去度量逃逸缺陷的数量，而线上缺陷只是逃逸缺陷可能出现的位置之一。
| 概念 | 是什么 | 回答的问题 | 常见误用 |
|---|---|---|---|
| 逃逸缺陷 | 具体的缺陷对象 | 这个缺陷相对于哪道关口漏出了 | 把所有线上问题都称为逃逸缺陷 |
| 缺陷泄漏率 | 度量指标 | 逃逸缺陷占总体缺陷的比例是多少 | 把比率当作单个缺陷的属性 |
| 线上缺陷 | 按发现位置分类的缺陷 | 缺陷在哪里被发现 | 认为线上发现必然等于逃逸 |
| 回归缺陷 | 修复或变更后重新出现的缺陷 | 已有功能是否被破坏 | 与逃逸缺陷混为一谈 |
| 遗留缺陷 | 已知但暂未修复、被记录在案的缺陷 | 哪些问题被有意推迟 | 把主动推迟也算作逃逸 |
回归缺陷关注的是“修好之后又坏了”，遗留缺陷关注的是“知道但先不修”，两者与逃逸缺陷的判定维度不同。一个缺陷可以同时是回归缺陷和逃逸缺陷，例如修复引入的新问题在测试阶段未被发现、上线后才暴露；也可以只是遗留缺陷，因为它在关口内已被识别并记录，只是按计划延后处理。
一个具体例子与常见误解
以下为演示情景，用于说明判定过程，不作为真实案例引用。
某功能需求要求“订单金额超过 500 元时自动触发人工审核”。开发实现时把阈值写成了 5000 元，测试用例只覆盖了 600 元和 100 元两个金额，未覆盖阈值边界附近的其他取值，系统测试通过。发布评审时无人核对阈值配置，功能上线。两周后运营人员发现大量 800 元订单未进入人工审核，提交缺陷。
判定过程分三步。第一步，确定参照关口。若以系统测试完成为关口，该缺陷在关口内未被发现，属于逃逸缺陷；若以发布评审为关口，同样属于逃逸，因为评审也未拦截。第二步，定位引入环节与漏出原因。引入环节是编码时的阈值错误，漏出原因是测试用例缺少边界值覆盖，且发布检查未包含配置核对。第三步，确认它不属于已知风险放行，也不属于上线后新引入的问题，因此纳入逃逸统计。
围绕这个例子，有几种常见误解值得纠正：
- “线上发现就是逃逸缺陷”：线上发现只说明位置。如果该问题在测试阶段已被记录为已知风险并评审放行，它就不是逃逸缺陷。
- “逃逸缺陷等于测试失职”：漏出可能源于需求歧义、用例设计、环境差异或评审缺失，责任分布在多个环节，简单归因于测试团队会掩盖真实原因。
- “逃逸缺陷数量越少越好”：数量下降可能是质量提升，也可能是关口前移后统计口径变化，或团队因担心追责而少报。脱离口径和上报文化谈数量，结论不可靠。
- “所有逃逸缺陷都要同等对待”：应按影响范围、发现阶段和可复现性分级，优先处理高影响、可预防的类型。
把逃逸缺陷记录成可分析的对象
逃逸缺陷只有被结构化记录，才具备预防价值。一张只写“线上有问题、已修复”的缺陷单，无法回答它从哪道关口漏出、由哪个环节引入，也就无法指导下一次改进。建议在缺陷单中固定记录以下字段：
- 发现阶段：测试、验收、灰度、生产、客户使用等，用于确定参照关口。
- 参照关口：本次判定所依据的质量关口，保证统计口径一致。
- 引入环节：需求、设计、编码、配置、依赖升级等，定位改进点。
- 漏出原因：用例缺失、环境差异、评审缺失、执行偏差等分类。
- 关联需求与版本：把缺陷挂回具体需求、迭代和发布版本，便于按版本聚合分析。
- 影响与处理结论：影响范围、修复方式、是否需补充用例或检查项。
记录之后需要有流转和复盘。典型流程是：缺陷被发现后进入缺陷单，由提交人填写发现阶段与关联版本，测试与研发共同确认引入环节和漏出原因，形成复盘结论，再转化为具体的改进动作，例如补充边界值用例、在发布检查清单中增加配置核对项。改进动作应作为独立工作项跟踪到关闭，避免复盘结论停留在文档里。
ONES 可以在这一流程中承载记录与流转。ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布、沉淀问题和经验；ONES TestCase 支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并支持项目缺陷分布统计与自动生成测试报告。上述字段中的发现阶段、引入环节等，可作为缺陷单的补充信息随单流转，具体字段配置范围建议在选型时结合实际版本核验。复盘结论则可沉淀为团队文档，与缺陷单相互关联，形成从发现、归因到改进的闭环。
常见问题
团队统计逃逸缺陷时，参照关口应该选测试完成还是发布评审？
两种口径都可以用，关键是全团队统一并写进统计说明。以测试完成为关口，关注的是测试环节的拦截效果，统计范围更大；以发布评审为关口，关注的是发布前整体把关，范围更窄。若两个团队各用一套口径又互相比较数量，结论会失真。可行做法是选定一个主口径用于趋势观察，另一个作为辅助口径用于定位漏出环节，并在缺陷单中记录本次判定所依据的关口。
在测试环境无法复现、只在生产环境出现的问题，算逃逸缺陷吗？
取决于关口定义是否包含生产环境验证。若团队以测试完成为关口，这类问题属于关口内未拦截、之后才暴露，可纳入逃逸统计；若关口定义本身延伸到灰度或生产验证，则它在关口内被发现，不算逃逸。更值得关注的是漏出原因：环境差异属于可预防类型，可通过补充预发环境检查、缩小配置差异来减少同类问题，而不是只争论归类。
逃逸缺陷数量下降，是否说明质量变好了？
不能直接下结论。数量下降可能来自质量提升，也可能来自统计口径调整、关口前移，或团队因担心追责而少报。判断时需要同时看口径是否变化、上报是否充分、以及缺陷的发现阶段分布。若数量下降但客户反馈的问题没有减少，往往说明记录环节出了问题。建议把逃逸缺陷数量与漏出原因分类一起看，关注可预防类型的占比变化。
复盘逃逸缺陷时，改进动作怎样才不会停留在文档里？
把每条复盘结论转成有负责人、有截止时间、可验证的工作项，并与原缺陷单关联。改进动作要具体到可检查的对象，例如“为金额阈值补充边界值用例”“在发布检查清单增加配置核对项”，而不是“加强测试意识”。关闭条件也应可验证，例如新增用例已纳入回归集、检查清单已更新并被执行。定期回看这些工作项的完成情况，比反复开复盘会更能减少同类漏出。
用 ONES 记录逃逸缺陷时，需要额外准备什么？
ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；ONES TestCase 支持未通过用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并支持项目缺陷分布统计与自动生成测试报告。发现阶段、参照关口、引入环节等逃逸判定所需信息，可作为缺陷单的补充字段随单流转，具体字段配置范围建议在选型时结合实际版本核验。若需要逃逸率专项报表，也应在选型阶段确认统计口径的实现方式。
