有很多方法可以做到这一点；我过去使用的一些数据点是：

• 构建损坏：自动构建编译/测试失败率是上升还是下降？
• 假设一个敏捷开发模型，用户故事是否完整，是否经过 QA + 利益相关者的审查
• 代码冻结是否有效？开发人员还在检查新功能吗？这通常意味着有更多的测试要做
• 项目结束时是否有很多代码合并？这往往会导致不稳定，并且可能表明您需要进行更有针对性的测试
• 自动化测试信心。您的自动化测试覆盖率越高，您在代码更改时就越有信心
• 是否有任何未打开的阻止程序错误？
• 关键错误的发现率是增加还是减少？

我不认为有“可接受的”缺陷到达率这样的概念，就目标数量而言，您通常希望尽快发现它们。因此，在英语中，您希望找到尽可能多的错误。

阅读该指标的关键方法是您希望随着时间的推移保持一致的到达率，即您希望缺陷到达趋势相当平坦且从不为零，例如每天 15-25 次而不是一天 2 次和下一次 50 次.

一旦您的错误被一致地发现，您就想查看错误修复率。

简单的答案是平均每天修复的错误数量，然后将错误总数除以平均值。这大约是直到您达到零错误为止的天数。因此，如果您每天要修复 5 个错误并且您有 200 个活动错误，那么您最早将在 40 个工作日内发布。如果您想更快地发布，您将需要停止添加功能并专注于修复更多错误。

可以反向使用相同的信息来计算最大允许的错误计数。假设您距离所需的发货日期只有 40 天，并且您每天要修复 5 个错误，如上例所示。如果您今天的活动错误数超过 200，您可能会错过目标。这个数字在 2 周内不断减少，还有 30 个工作日，如果你要赶上发货日期，你的 bug 数量应该在 150 个大关。