接受测试和代码覆盖范围

Question

测量接受测试的覆盖范围的最佳方法是什么？

您如何定义您的接受测试涵盖了多少？何时足够？

Answer 1

进行接受测试时，我宁愿看 功能覆盖范围 即测试给定应用程序的多少功能（或用户故事或用例）。对我来说，对于每个功能（或用户故事或用例），应测试所有方案或可能的路径。换句话说，功能应该是编写测试计划的起点，目标应该是涵盖功能，而不是代码。这是一个轻微的差异，但重要的是：测量使用代码覆盖的测试是面向开发人员的，测量功能覆盖范围是最终用户的。

关于测量，敏捷的开国元勋之一罗恩·杰弗里斯（Ron Jeffries）写了一个很好的摘要，他认为他认为是真正有价值的指标，RTF或运行测试的功能。您可以查看文章 这里. 。我只是在下面引用一小部分：

该项目的重点是什么？

我只是在猜测，但我认为大多数软件开发项目的重点是可以有效的软件，并且每美元投资的功能最多。我称该概念运行了测试[功能]，实际上可以在一定程度上进行测量。

想象一下RTF的以下定义：

1. 所需的软件被分解为命名功能（需求，故事），这是交付所需系统的含义的一部分。
2. 对于每个命名功能，都有一个或多个自动接受测试，它们在工作时将表明实现了所讨论的功能。
3. RTF指标在项目的每一刻都显示了多少个功能通过其所有接受测试。

通过独立定义的测试，已知有多少个客户定义的功能？现在有一个我可以忍受的指标。

为了报告进度，我特别喜欢累积流程图。他们清楚地表明了什么时候出了问题，例如（这里是燃烧风格）：

_{（资源： Xprogramming.com)}

对于现实生活中的例子，请看一下 这个帖子 或者 这个 （烧毁样式图）。