5.1 逃逸缺陷率与质量逃逸

概述与动机

逃逸缺陷率衡量的是抵达生产环境、影响真实用户的缺陷，有别于本书第4部分所涵盖的、通过测试、代码评审或静态分析更早被捕捉到的缺陷。这种区分极为重要：一个在代码评审中被捕捉到的缺陷，修复起来只需几分钟，也没有用户会看到它；同样的缺陷，一旦逃逸到生产环境，可能要付出数小时的事件响应代价，造成真实的客户伤害，以及信任上可衡量的损伤。从真正的意义上说，这项指标是第4部分所涵盖的一切的最终记分卡，因为尽管内部质量指标（复杂度、覆盖率、静态分析）表现良好，逃逸缺陷率却在上升，通常意味着那些内部信号实际上并没有捕捉到对真实用户而言重要的故障模式。

本主题以其代价理应获得的严肃态度对待逃逸缺陷，同时抵制把原始数量当作一块简单记分牌的诱惑。并非所有缺陷都是同等的：一处很少被查看的帮助文本中的拼写错误，和一个金融交易系统中的数据损坏错误，技术上都是逃逸缺陷，把它们同等对待，会产生一个要么噪声太大无法据以行动、要么更糟、对真正风险所在之处具有积极误导性的指标。本主题的核心建议，配以对缺陷如何被分类的细致关注的严重程度加权跟踪，正是直接针对这个问题。

对大团队而言，逃逸缺陷率是本书的内部工程指标与第5部分整体所关切的面向客户的世界之间最清晰的桥梁之一。企业组织用它来论证对第4部分测试和评审实践的投资正当性；在政府组织中，一个逃逸缺陷可能意味着一次错误的福利计算，或一次失败的公共服务互动，因此它被当作公众信任和法律风险的直接衡量指标，而不仅仅是一项内部工程统计数据。

核心原则

逃逸缺陷率是内部质量实践的最终记分卡。 尽管第4部分的指标表现良好、逃逸缺陷率却在上升，意味着那些指标没有捕捉到重要的东西。
严重程度比原始数量更重要。 按真实的客户或业务影响给缺陷加权，而不要把每一次逃逸都同等对待。
分类的一致性至关重要。 两个团队用不同方式对严重程度进行分类，产生的数字无法被公平比较。
这项指标暴露在定义操纵的风险之下， 与变更失败率（主题 2.10）如出一辙：收窄”缺陷”的定义范围，会让数字变得好看，却不会减少真实的客户伤害。
根本原因分类把一个数量变成一个诊断工具。 知道缺陷为什么逃逸，比只知道逃逸了多少更具可操作性。

建议

用一个一致的、有文档记录的量表，按严重程度给逃逸缺陷加权

用一个固定的严重程度量表（通常是关键、重大、轻微，或一个等效的数字量表），根据真实的客户或业务影响对每一个逃逸缺陷进行分类：数据丢失或损坏、安全暴露，以及功能完全不可用位于最顶端；一个没有功能影响的外观问题位于最底端。跟踪一个按严重程度加权的趋势，而不只是一个原始数量，这样轻微问题的一次激增，就不会在视觉上淹没一次规模更小、后果却严重得多的关键问题增长。

在各团队之间标准化分类标准

如果放任不同团队独立地对严重程度进行分类，它们会朝不同的标准漂移，有些偏保守，有些偏宽松，这让跨团队比较变得毫无意义，更糟的是，还会造成一种为了让本团队的数字看起来更好而慷慨地向下分类的激励（主题 1.2 定义操纵的一个变体）。发布清晰的、基于示例的分类标准，并定期审计各团队分类结果的一个样本，检查一致性。

跟踪根本原因，而不只是数量和严重程度

对每一个逃逸缺陷，记录它为什么逃逸了：一个测试缺口、需求中一个被遗漏的边界情况、预发布环境与生产环境之间的一个环境差异，一次遗漏了这个问题的评审。随时间推移汇总这些根本原因数据，以发现系统性模式，如果某个具体类别（比如说，环境差异导致的缺陷）在你的逃逸缺陷中占主导地位，这就直接指向了一个具体的、可修复的流程缺口，而不是一句模糊的”多测试一点”的笼统呼吁。

把逃逸缺陷连接回它们的源头内部质量信号

在可能的情况下，把一个逃逸缺陷追溯回它来自的代码区域，检查那个区域是否在第4部分的指标中显现过警示信号：它是否是一个复杂度热点（主题 4.1、主题 4.3），它的变异杀死率是否偏低（主题 4.2），静态分析是否在附近标记出了什么（主题 4.4）。正是这种连接，验证了你的内部质量指标是否真正能预测真实的、面向客户的缺陷，还是它们衡量的东西，在你的具体情境中，与客户实际体验到的东西并不相关。

防范缺陷分类变成一场问责游戏

依据主题 1.1 的诊断性框架，把缺陷根本原因分析明确地定位为一个系统性问题，而不是一场针对个人的问责游戏。一个害怕因逃逸缺陷而被问责的团队，有很强的动机去少报、向下错误分类，或抵制彻底的根本原因分析，所有这些都会腐蚀本主题所依赖的这份数据本身。无责事后分析实践，在主题 6.2 有更深入的探讨，在这里直接适用。

权衡取舍：利与弊

方案	优点	缺点
原始逃逸缺陷数量	报告起来简单	把一处拼写错误和一个数据损坏错误同等对待；嘈杂且具有误导性
按严重程度加权的跟踪	更准确地反映真实的客户影响	需要一致、有纪律的分类
各团队独立的分类标准	灵活，协调开销低	产生跨团队无法比较的数字；招致宽松化的漂移
标准化、经过审计的分类	公平、可比较，抵御操纵	需要持续的治理和定期的审计工作

核心张力是本地灵活性与跨团队可比性之间的张力。让每个团队按适合自己情境的方式对缺陷严重程度进行分类，实施起来更简单，但产生的数字无法在组织层面被公平地比较或汇总，还会造成一种为保护自身指标而慷慨分类的暗中激励。解决这种张力的办法，是投资于标准化的、有文档记录的分类标准和定期的跨团队审计，把这当作一项治理工作（主题 1.4），鉴于这项指标与真实客户影响的直接联系，这份投入是值得的。

与团队讨论的问题

我们是否按严重程度跟踪逃逸缺陷，还是一个原始数量把一个轻微的外观问题和一个关键的数据问题同等对待？ 拉出你实际的仪表盘并检查；如果严重程度加权尚未落实，这就是本主题所建议的单一价值最高的变更。
同一个缺陷的严重程度，两个不同的团队会以同样的方式分类吗，还是分类已经在组织内部彼此漂移开来？ 挑一个真实的、模糊的过去缺陷，让两个不同团队的代表独立地对它进行分类；诚实地比较结果。
我们逃逸缺陷最常见的根本原因是什么，我们当前的流程是否真正解决了它，还是我们只是在个别事件发生时逐一应对？ 汇总过去几个月的根本原因数据，寻找主导的模式。
我们的逃逸缺陷是否曾追溯到我们内部质量指标（复杂度、覆盖率、静态分析）已经标记为有风险的区域？ 这种连接验证了你第4部分的指标在你的具体情境中是否真正具有预测性，还是它们遗漏了真正重要的故障模式。
我们的缺陷分类流程让人感到安全吗，还是工程师在报告或分类一个与自己相关的缺陷时会害怕被问责？ 一种容易问责的文化，会通过少报和宽松分类系统性地腐蚀这份数据；在这里诚实地面对你当前的文化。
我们的逃逸缺陷率是否曾经在没有测试或评审实践相应变化的情况下，可疑地快速改善？ 与变更失败率（主题 2.10）一样，这是分类标准而不是真实风险发生了变动的最清晰迹象。

行业视角

初创公司。 对一个缺陷量小、能够直接讨论每一个缺陷的小团队而言，正式的严重程度分类往往没有必要。值得及早养成的习惯，只是从一开始就一贯地跟踪缺陷，哪怕只是非正式地，这样一旦团队成长到需要更正式分析的规模，历史数据就已经存在了。

小型企业。 一个简单、共享的严重程度量表，哪怕只有三个等级（关键、重大、轻微），由负责支持和缺陷分诊的人一贯地应用，就能在不需要复杂工具或专门质量职能的情况下，捕捉到本主题的大部分价值。

企业。 在这里，跨团队分类的一致性是杠杆最高的投资，因为在数十个团队之间标准不一致，会让全组织范围内的质量比较变得毫无意义。投资于有文档记录、基于示例的分类标准和定期审计，并系统性地把逃逸缺陷连接回第4部分的内部质量信号，以验证这些信号中哪些在你的组织中真正具有预测性。

政府。 一个面向公众或福利计算系统中的逃逸缺陷，除了其工程成本之外，还承载着法律和公众信任方面的分量。对影响公民服务的缺陷，以格外的严谨对待严重程度分类，并做好准备，分类决定可能面临外部审查，这有力地论证了应当采用有文档记录、经过审计、一致的标准，而不是临时的判断。

案例

企业。 一家订阅软件公司的逃逸缺陷数量已经连续两个季度上升，最初的关切集中在这个原始数字上。按严重程度加权的分析揭示，这种增长几乎完全出现在轻微的外观问题上，恰逢一次近期的用户界面重新设计，而关键和重大缺陷在同一时期实际上略有下降。对轻微问题激增的根本原因分析指向了专门针对新界面组件的视觉回归测试方面的一个缺口，这是一个有针对性、低成本的修复，如果团队对未加权的原始数量做出反应、把它当作一场未加区分的质量危机来处理，这个修复本会被完全错过。

政府。 一家州失业机构的福利计算系统曾出现一个逃逸缺陷，在被发现之前，数月内错误地拒绝了一小部分原本符合资格的申请。一次根本原因调查发现，这个缺陷源自一个此前十八个月前在一次内部质量评审中就已被标记为复杂度热点的代码区域（主题 4.1、主题 4.3），但这个热点从未被优先纳入补救计划，因为在此之前还没有出现任何缺陷让这种风险变得具体。该机构修订后的流程，现在明确地在测试和评审优先级中，对被标记为热点的区域给予更高的权重，正是因为内部复杂度信号与真实逃逸缺陷风险之间这种被证明、经过验证的联系。

商业理由：动机、投资回报与总拥有成本

严谨地跟踪逃逸缺陷率，配以严重程度加权和根本原因分析，其回报是能够把质量投入引导到真正能减少面向客户伤害的地方，而不是对一个不加区分、把琐碎和严重问题混在一起的数量做出反应。上面的订阅软件案例清楚地展示了这一点：对原始数量的反应本会触发一场宽泛、不聚焦的质量行动，而基于严重程度加权、由根本原因指引的应对，识别出了一个具体、廉价、有针对性的修复。

总拥有成本包括分类纪律（一致的标准、定期的审计）和根本原因跟踪工作，这两者主要是流程投资，而不是工具成本。这份投入通过把质量精力引导到逃逸缺陷风险真实、经过验证的来源，直接以避免的客户伤害和事件响应成本收回自身。

反模式与陷阱

把原始缺陷数量当作指标： 把琐碎和严重问题混为一谈，掩盖了真正的信号。
各团队之间不一致的严重程度分类： 让跨团队比较变得毫无意义，招致宽松化的分类漂移。
没有根本原因跟踪： 把一个数量变成一个没有诊断价值的数字，让系统性模式保持不可见。
容易问责的报告文化： 通过少报和宽松分类腐蚀数据，正是主题 1.2 所警告的那种激励暴露风险。
从不把逃逸缺陷连接回内部质量信号： 错过了根据真实结果验证或推翻第4部分预测性指标的机会。
一次没有流程变化支撑、快得可疑的改善： 分类标准而不是真实风险发生了变动的最清晰迹象。

成熟度模型

第一级，启动： 逃逸缺陷即使被跟踪，也只是作为一个没有严重程度加权或根本原因分析的原始数量。
第二级，发展： 存在一些严重程度分类，但各团队之间标准不一，根本原因跟踪也不一致。
第三级，标准化： 严重程度分类在全组织范围内被标准化并有文档记录，根本原因分类被一贯地应用。
第四级，管理： 逃逸缺陷被系统性地追溯回内部质量信号，以验证其预测价值，分类被定期审计以确保一致性。
第五级，协奏： 组织能够指出具体的、可衡量的逃逸缺陷率下降，这些下降可以追溯到经过内部质量信号验证的、由根本原因指引的有针对性质量投资。

讨论思路

上个季度我们排名第一的逃逸缺陷，换一个团队会以同样的方式分类吗？
我们逃逸缺陷最常见的根本原因是什么，我们真的在解决它吗？
一个逃逸缺陷是否曾追溯到我们内部指标已经标记过的区域？
我们团队报告并诚实地分类一个自己造成的缺陷时，是否感到安全？
对我们当前的缺陷数量做一次按严重程度加权的审视，会揭示出原始数量所掩盖的什么？

要点回顾

逃逸缺陷率是内部质量实践的最终记分卡；尽管第4部分的指标表现良好、逃逸缺陷率却在上升，意味着那些指标没有捕捉到重要的东西。
按严重程度加权，使用一个一致的、有文档记录、经过审计的分类量表，绝不单独依赖一个原始数量。
跟踪根本原因，而不只是数量和严重程度，把这项指标变成一个真正的诊断工具。
把逃逸缺陷连接回内部质量信号（复杂度、覆盖率、静态分析），验证这些信号是否真正具有预测性。
防范一种容易问责的文化，它会通过少报和宽松化的漂移腐蚀报告和分类。

参考文献与延伸阅读

Site Reliability Engineering，Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy编（适用于缺陷根本原因分析的无责事后分析实践）。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（交付实践与质量结果之间的关系）。
Code Complete，Steve McConnell著（缺陷分类与根本原因分析实践）。
The Field Guide to Understanding Human Error，Sidney Dekker著（故障调查的系统性、无责框架）。