黑匣子测试器应该如何测量测试覆盖率？

Question

我在产品公司担任QA/测试工程师。我被指派了一个新的项目/增强，将在下一个生产版本中交付给客户。业务分析师发布新特性/模块的“功能规范(SRS)”。接下来，我开始编写测试用例/场景。

在此之后，DEV团队发布了构建，我开始进行“功能性”测试。我遇到问题，报告他们，它得到修复，我重新测试他们，这继续，直到我说一切都好。该产品最终被发布到生产服务器。

现在，如果管理层问我关于测试覆盖率、测试用例覆盖率的问题，那么最好的答案是什么。我的团队不遵循敏捷。它仍然沿用旧的基于瀑布的方法。没有冲刺或用户故事。

现在，我相信“测试用例不是测试”，行业正在向性能文化迈进。现在，熟练的探索性测试比测试用例度量更重要。那么，为什么编写的测试用例数量应该定义测试覆盖率。我编写了100个测试用例，涵盖了SRS中的所有需求。那么问题是，我的覆盖率是100%。为什么这种覆盖测量是错误的和过时的？

Answer 1

黑匣子方法本身就是专门为从用户的角度向后而设计的。黑匣子测试和白盒测试的区别在于对底层代码和组件的了解。

因此，当您准备黑匣子测试时，您应该从用户的角度来使用该应用程序。这是每个用户的立场，包括应用程序的超级用户，而不是开发人员视图。忽略代码覆盖率，并从用户的角度专门关注使用情况。一旦您到达那里，然后通过添加边界/边缘案例测试来构建它。总是以彻底的探索性测试来结束，这可能会带来在标准测试和边界测试中没有尝试过的不同组合。

对下面的

做了详细的介绍

1. 查看应用程序的用户透视图
2. 从用户能力/角度看边界/边缘情况
3. 用于测试各种组合的探索性测试

如果您已经完全覆盖了上面的内容，那么您可以说您已经从黑匣子测试方法中获得了可靠的测试覆盖率。关键是三个项目的功能覆盖范围，因此，如果您有45条功能，并且您拥有上述所有功能，您可以说是100%。如果您有上面的一些内容，但不是全部，那么您可以想出一个公式来提供测试覆盖执行的管理。(也就是说，38有全部3和7有1，即(38*3)+(7*1)/ (45*3) = 89.6%的承保范围)你可以根据风险调整它，并在需要时或多或少地给予某些部分价值。

Answer 2

在高度管制的行业，没有正式的规范，就不会有任何改变。这样做是出于责任和证明的原因。如果你是在设计软件来保护人们的安全，那你一定要确保你能应付每一次突发事件。

您的经理在谈论测试用例覆盖率时所问的是“您的测试包括规范吗？”