有什么数据驱动的技术来确定是否已经完成了足够的测试？

Question

我见过一些SQA组使用缺陷到达率或“发现”率来确定是否准备发布一段软件。我们的想法是，发现缺陷的速度将放缓到一个可接受的水平。

这些技术是什么？如何确定“可接受的”缺陷到达率？

编辑:丹尼尔的回答给出了一个很好的项目列表。详细说明这个问题:允许确定适当的下降速率/发现缺陷的方法是什么？

编辑2：此链接显示了该方法的一个示例。。有人用过这个或类似的东西吗？

Answer 1

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

• 构建破坏:自动构建编译/测试失败率是上升还是下降？
• 假设一个敏捷开发模型，用户故事是否已经完成，并且是否经过QA +涉众的审查？
• 代码冻结有效吗？开发人员还在签入新功能吗？这通常意味着需要进行更多的测试。
• 在项目结束时会有很多代码合并吗？这往往会导致不稳定，这可能是一个迹象，你需要做更有针对性的测试。
• 自动化测试信心。自动化测试覆盖范围越好，当代码更改时，您就越有信心。
• 还有什么阻滞剂漏洞没有打开吗？
• 关键错误的发现率是在增加还是在下降？

Answer 2

我不认为有这样一个概念，作为一个“可接受的”缺陷到达率，在一个目标号码的意义上，你通常希望尽快发现他们。所以，在英语中，你想找到尽可能多的bug。

读取该指标的关键方法是，您希望随着时间的推移有一个一致的到达率，也就是说，您希望缺陷到达趋势相当平稳，而不是零，比如每天15-25，而不是一天两天，下一天50。

一旦您不断地发现错误，就需要查看bug的修复率。

简单的答案是平均每天修复的bug数，并将bug总数除以平均值。这大约是你到达零臭虫前的几天。所以，如果你每天修复5个bug，并且你有200个活跃的bug，你最早要在40个工作日内发货。如果您希望更早发布，您将需要停止添加功能，并专注于修复更多的bug。

可以反向使用相同的信息来计算最大允许的错误计数。假设你只有40天才能到达你想要的船期，而且你每天都要修复5个错误，就像前面的例子一样。如果您的活动bug计数超过200今天，您可能会错过您的目标。这个数字不断减少，因此在两个星期的时间，与30个工作日，你的错误计数应该在150马克，如果你要达到你的船日期。