这个“测试效率”数字的含义是什么？

Question

为了寻找一种测量软件测试效率的方法，我找到了以下公式

Testing Efficiency = (No. of defects Resolved / Total No. of Defects Submitted)* 100

来自例如这里。

但是，这看起来并不是用于测试效率的度量，而是更多地用于解决所发现的缺陷。发现缺陷是一回事，修复它们不是测试人员的责任。那么，在什么意义上，它怎么可能是“测试效率”呢？

另外，实际数字是什么? 0%意味着没有任何缺陷已经解决，100%意味着所有的缺陷都已经解决了。80%的数字意味着什么？看到80%的缺陷已经修复，这仅仅是反映软件发布当前状态的一个数字吗？我能从那个号码看更多吗？时间分布能告诉我一些更有洞察力的东西吗？

Answer 1

测试效率是衡量所报告的bug的相关性的一种方法。低效率意味着测试团队报告了许多不值得修复的bug。这是相当有限的，而且过于简单化。

我最好用一个饼图来显示所有已解决的错误的“解决方案”。这显示了“固定”、“无法复制”、“另一个错误的复制”、“不会修复-业务决策”等解决方案类别。这张饼形图使我们能够就测试效率进行一次交谈。结果，我们打开了很多重复的bug --所以我们在bug跟踪系统中增加了搜索功能。此外，由于业务决策，很多bug都被关闭了，但是PM没有进行审查。因此，在关闭这样的bug之前，我们添加了一个PM审查。在此之前，我们只修复了50%的错误报告。事后，为80%。

很难对什么是好的给出一个数字，但是这个方法可以让你问“这是个问题吗？”，然后给出一些关于如果存在问题如何解决的见解。

Answer 2

测试效率，以及其他指标，仅仅是一个指导方针。它不能说明整个情况，必须把它放在上下文中才能有意义。

这更多地是管理层在进行评估时所使用的一种指示。例如，当一位高级经理问一个项目负责人：“最近我们在修复缺陷方面投入了一些资金，情况如何？”项目负责人可能会使用测试效率来演示资金的使用效果。

我发现一个有趣的场景是：

• 我曾经为一位测试经理工作，他非常喜欢用sprint故事点来衡量他的团队的效率。有一次，我们开了个会，他展示了这个团队在上一次冲刺中的效率下降，因为我们完成的故事点比以前的记录少了1分。他花了整整一个小时的时间讨论我们效率下降的原因。

像sprint故事点和测试效率这样的度量更多的是指南，它们不是严格量化的，应该与其他度量相结合才能得到整体的结果。

Answer 3

就像许多其他度量标准一样，它并不意味着太多，尤其是它本身。假设您将它与“代码覆盖率”度量和“在生产中发现的缺陷”度量相结合--您可以从中获得一些意义。

这个名字可能指的是“测试的产品有多好”。