问需求和测试用例之间的关系是什么？

EN

我看到有很多用于测试用例可追溯性需求的系统，我开始问自己这两个工件之间的关系是什么。例如，为什么有测试用例的概念，而不是仅仅将它们称为详细的需求？测试用例实际上是对需求集的改进吗？

我认为这种区别只是表明了它们是何时产生的，以及为了什么目的。在我们知道很多具体的实现细节之前，需求就已经产生了。我们试图让它们保持实现中立，所以它们往往更抽象。

测试脚本的目的略有不同。需求告诉开发人员系统应该做什么，而不是如何做。然而，测试用例(就像它们经常被编写的那样)精确地指定了如何做一些事情，并且它们通常会引用实际的实现细节。

如果测试用例不是需求，并且需要比文档记录的需求更多的需求(例如，测试更多的错误，等等)，那么需求集肯定是不完整的吗？

是的，这些需求集是不完整的。这总是因为你永远不能完整地记录所有用户或利益相关者的所有期望，无论你在那里工作了多长时间。

但是测试用例也是不完整的。完全的测试是不可能的。任何一组测试都是所有潜在测试的样本集。然而，测试通常是在较晚的阶段完成的，那时我们对需求有了更多的了解，因此它们可以更具体、更详细、更完整，而不是完全完成。

看一下：http://www.ibm.com/developerworks/rational/library/04/r-3217/

在这篇文章中，作者解释了如何从用例到测试用例。作者提出的观点是，当用例包含所有流和子流时，测试用例是通过系统的特定数据和特定流。

需求仅仅是抽象的测试用例吗？

我会说是的，他们可以这样看待。有些人甚至不写测试用例，只是将需求作为测试基础的“检查表”。

从测试用例到需求的可追溯性是一个非常好的想法，也是一个非常流行的方法。工具实现这一特性是因为它很畅销。但这种方法也有局限性和陷阱。当工具愉快地报告100%的覆盖率时，通常会有一种错误的完备感，因为您恰好对每个需求都有一个测试。它并没有真正解决这样的问题，即一些需求需要的不仅仅是一个测试。它也没有考虑到测试的内容，或者测试是否真正涵盖了它们应该涵盖的内容。

如果您对需求->测试可追溯性感兴趣，您应该意识到该方法的局限性，并意识到它应该与其他方法结合使用，以便为您的测试提供更全面的方法。

在TDD中，测试用例就是需求。

但有些需求是不可测试的，或者需要巨大的测试设施。

实际上，这取决于团队/组织使用的开发过程。

• 在敏捷(Scrum，XP和变体)过程中，通常没有要求，并使用验收测试来验证用户故事是否正确实现。因此，用户故事是某种类型的requirement/specification.
• In测试驱动开发测试是requirements.
• In瀑布，您通常会创建一个文档，列出您的软件的所有需求，并与利益相关者一起批准它。然后，您可以根据这些需求进行开发，并根据这些需求测试您的软件。正如弗兰克的回答中所提到的，在这个过程中，您需要从需求到测试用例的可追溯性，因为CMMI要求您测试所有需求。