. Bug 数量——可能按优先级或严重性排列
一般来说，错误的数量会在项目生命周期的中期开始增加。在截止日期之前的几天或几周（取决于项目的规模），团队将集中精力减少 bug 的数量，直到 bug 的数量达到某种渐近线。这个渐近线最终代表了项目产品的整体质量。因此，跟踪错误总数（区分其优先级）是一个很好的指标。

然而，并非所有错误都是一样的。这就是为什么大多数团队都会为错误分配优先级和/或严重性。例如，跟踪 P1 错误和 P2 错误可能很有趣，而且仅跟踪这些错误。这取决于您产品的成熟度。对于新产品，您需要继续关注 P1。事实上，具有大量 P1 的产品会被认为不起作用。

如果您不再有任何 P1，但仍然有 P2，用户仍然会遇到这些错误，这可能会对他们对产品的看法产生负面影响。

如果你希望你的产品被认为是高质量的，例如苹果的水平，那么当你解决了很多 P3 和 P4 错误时，这实际上就会发生。这是您需要达到的水平。因此，只专注于跟踪现在对您重要的事情。

什么时候使用它？

如果您的产品质量对您的业务很重要，那么此指标非常有帮助。如果是这样，您应该不断跟踪它。但是，如果您解决了所有 P1 和 P2 问题，您可能希望通过跟踪 P3 等方式来实现更高的质量标准。

2. 更改失败百分比
Accelerate将故障定义为“导致服务降级或随后需要修复（例如，导致服务受损或中断、需要修补程序、回滚、修复转发或补丁）”的更改。所以这个评级是导致部署失败的部署数量。

请注意，此定义不包括部署失败的更改。该信息很有用，但不是此 KPI 的重点。

什么时候使用它？

如果您专注于将频繁部署变成日常习惯，那么为了使其有价值，您需要保持较低的失败率。事实上，随着 DevOps 团队的经验和能力的增强，这个评级应该会随着时间的推移而降低。故障率不断上升，或者故障率很高且不会随着时间的推移而下降，这表明整个 DevOps 流程中存在问题。这是整个过程质量的一个很好的代理指标。

3. 拉取请求质量
拉取请求可以让您很好地了解代码库的整体复杂性。代码库越复杂，以下指标较高的可能性就越大：

拉取请求破坏构建或无法通过测试套件的次数百分比；
合并请求与拒绝请求的百分比；
拉取请求的评论数量 - 您不希望数字太低，但也不希望数字太高。这些指标显示您的团队如何协作以及您的拉取请求是否引起了足够的关注。它可以间接指示投入生产的代码的质量。
何时使用它们？

该指标不是衡量 DevOps 流程的质量（例如变更失败百分比），而是衡量团队的工作和协作方式。代码审查是如何使用的以及它们有用吗？衡量合并的拉取请求与拒绝的拉取请求的演变将帮助您了解您的团队是否随着时间的推移而改进。您还可以深入研究团队成员，看看他们是否也在进步。

4. 测试覆盖率
该指标只是您正在测试的软件中的代码总行数与当前执行的所有测试用例的代码行数之间的比率。

当通过执行的代码行数来衡量时，普遍接受的“足够”测试覆盖率是多少？共识徘徊在 80% 左右——对于关键系统来说更高（关键的定义可能因行业、地理位置、用户群等而异）。

什么时候使用它？

当然，您不需要 100% 的测试覆盖率。然而，了解自己的处境并对其进行跟踪有助于了解您是否在以速度换取质量。请记住，“建立在不良需求之上的高质量产品是劣质产品”，尤其是测试覆盖率。

5. 平均故障间隔时间 (MTBF) 和平均恢复/修复时间 (MTTR)
这两个指标都衡量软件在生产环境中的性能。由于软件故障几乎是不可避免的，因此这些软件指标试图量化软件恢复和保存数据的效果。

如果 MTTR 值随着时间的推移而变小，则意味着开发人员在理解问题（例如错误）以及如何修复这些问题方面变得更加有效。

何时使用它们？

如果团队使用这些指标来实现特定目标，那么这些指标会非常有趣：“我们需要在我们的产品上达到这一水平的 MTBF 或 MTTR。” 这将促进您的团队对客户提出的重要问题的响应能力，并将帮助您保持产品和团队的高标准。为了提高这些指标的性能，团队可能会明白他们需要解决问题的真正原因，而不是简单的补丁。

6. 服务水平协议（SLA）
每个团队都有自己的 SLA 定义。但这里是 Airbnb 使用的一个，你会发现它非常有趣。SLA 是您的团队在特定时间内修复和部署的阻止程序错误的百分比（例如，阻止程序错误 24 小时，关键错误 5 天）。您可能真正喜欢这个指标的原因是它让您从用户的角度更好地了解您的产品质量。

什么时候使用它？

该指标非常接近MTTR，但不仅限于软件故障。它扩展到任何类型的错误。同样，如果由具有特定目标的团队使用该指标，则非常有趣：“我们需要在我们的产品上实现此 SLA。” 该指标可培养团队的产品质量所有权和响应能力。这就是 Airbnb 使用它的原因。

7. 缺陷去除效率（DRE）
缺陷去除效率用于量化最终用户在产品交付后 (D) 发现的缺陷数量与产品交付前发现的错误 (E) 之间的关系。公式为：DRE = E / (E+D)

DRE越接近1，产品交付后发现的缺陷就越少。在整个测试计划中，平均 DRE 分数通常约为 85%。然而，通过彻底、全面的要求和设计检查流程，这一比例有望提升至 95% 左右。

什么时候使用它？

该指标的用途与跟踪错误数量的演变类似。跟踪它们可能是多余的。我们对错误数量有偏好，因为您现在可以区分哪些错误优先级对您很重要，并且仍然了解总体数量（而不仅仅是趋势）。

8. 应用程序崩溃率（ACR）
应用程序崩溃率的计算方法是应用程序失败次数 (F) 除以应用程序使用次数 (U)。但实际上有几种方法可以计算它。

每个用户的应用程序崩溃次数：此数字显示有多少用户曾经遇到过崩溃情况。该指标的可接受范围为 < 1%。对于成熟的应用程序来说，这个数字应该更低，因为功能会更稳定。但是，在计算整个应用程序的实际数量时，可以忽略最终在回滚实例中出现的错误更新，以获得准确的表示。
每个会话的应用程序崩溃次数：此数字显示与会话数相比应用程序崩溃的次数。该指标的可接受范围为 < 0.1%。但是，可以将其分为会话类型和应用程序流，以便更好地理解问题。
每个屏幕视图的应用程序崩溃次数：此数字将应用程序收到的总屏幕视图数与崩溃次数进行比较。该指标的可接受范围为 < 0.01%。必须对此进行分类，以了解崩溃对功能交付的影响。
什么时候使用它？

当您心中有特定目标时，这个指标很有趣。例如，您可以努力使软件最关键的用户流中的 ACR 低于 0.25%。

9. 缺陷密度
有两种不同的方法来查看缺陷密度：

面向规模的指标关注软件的规模，通常以千行代码 (KLOC) 表示。一旦决定了一行代码的构成，这是一个相当容易收集的软件指标。不幸的是，它对于比较用不同语言编写的软件项目没有用。一些示例包括每个 KLOC 的错误或每个 KLOC 的缺陷。

面向功能的指标重点关注软件提供的功能量。但功能不能直接测量。因此，面向功能的软件指标依赖于计算功能点（FP）  ——一种量化产品提供的业务功能的测量单位。功能点对于比较用不同语言编写的软件项目也很有用。该指标将查看每个 FP 的错误或每个 FP 的缺陷

功能点不是一个容易掌握的概念，而且方法也各不相同。这就是为什么许多软件开发经理和团队完全跳过功能点的原因。他们认为功能点不值得花时间。

什么时候使用它？

依赖于代码行的面向大小的指标使得它们本身没有用处。因此，您不应该将两个不同的软件项目与它们进行比较。这就是为什么您可能不太喜欢使用它。而且面向功能的指标很难计算和达成一致。您可能想向它们引入控制措施，但列表中可能有更好的指标。

10. 依赖时代
技术债务的另一个指标是代码库中使用的依赖项的过时程度。跟踪这一点可能会很有趣，作为所有依赖项的平均值，可能有一个变体，这样您就可以确定一个依赖项何时很旧并且需要您的注意。