我看到有许多系统需要测试案例的可追溯性，我开始问自己这两个文物之间的关系是什么。例如，为什么有测试用例的概念而不是仅仅称它们为详细要求？测试用例实际上是对需求集的细化吗？如果测试用例不是需求并且要求超过文档要求（例如测试更多错误等），那么确定需求集是不完整的？需求只是抽象的测试用例吗？
答案 0 :(得分：2)
我看到有许多系统需要测试案例的可追溯性，我开始问自己这两个文物之间的关系是什么。 例如，为什么有测试用例的概念而不是仅仅称它们为详细要求？测试用例实际上是对需求集的细化吗？
我认为这种区别只表示它们何时生产，以及用于何种目的。在我们了解许多实现特定细节之前很早就生成了需求。我们试图让它们保持中立，因此它们往往更抽象。
测试脚本的目的有些不同。需求告诉开发人员系统应该做什么，而不是如何做。然而，测试用例（因为它们经常被编写）确切地指定了如何做某事，并且他们经常会参考实际的实现细节。
如果测试用例不是要求并且要求超过文档要求（例如测试更多错误等），那么确定要求集是不完整的？
是的，要求设置不完整。这始终是因为无论您工作多久，您都无法完整记录所有用户或利益相关方的所有期望。
但是测试用例也不完整。完全测试是不可能的。任何一组测试都是所有潜在测试的样本集。但是，测试通常在稍后阶段完成，届时我们会对需求有更多了解，因此它们可以更具体，更详细，更完整，而不是完全完整。
看看： http://www.ibm.com/developerworks/rational/library/04/r-3217/
在本文中，作者解释了如何从用例到测试用例。作者提出的观点是，虽然用例包含所有流和子流，但测试用例是特定数据和通过系统的特定流。
需求只是抽象测试用例吗？
我会说是的，他们可以这样看待。有些人甚至会不去编写测试用例，只是将这些要求作为“检查表”来进行测试。
从测试用例到需求的可追溯性是一个非常好的想法，是一种非常流行的方法。工具实现此功能，因为它销售。但这种方法存在局限性和陷阱。当工具愉快地报告100％覆盖率时，通常会有一种错误的完整感，因为您恰好对每个需求进行了1次测试。它并没有真正解决一些要求不仅仅需要一个测试的问题。它也没有考虑测试的内容或测试是否实际涵盖了他们应该做的事情。
如果您对要求 - >测试可追溯性感兴趣，您应该了解该方法的局限性，并意识到应该与其他方法结合使用，以便为您的测试提供更全面的方法。 / p>
答案 1 :(得分：1)
在TDD中，测试用例是需求。
但是有些要求是不可测试的，或者需要大量的测试设备。
答案 2 :(得分：1)
实际上，这取决于团队/组织使用的开发过程。
在敏捷（Scrum，XP和变体）流程中，通常没有要求，验收测试用于验证用户故事是否正确实施。因此，用户故事是某种要求/规范。
在测试驱动开发测试中是要求。
在Waterfall中，您通常会创建一个文档，列出软件的所有要求并与利益相关者一起批准。然后根据这些要求进行开发，并根据它们测试您的软件。正如Frank的回答所提到的，通过这个过程，您需要从需求到测试用例的可追溯性，因为CMMI要求您测试所有需求。
答案 3 :(得分：1)
就我而言，
a要求可追溯到一组旨在满足要求的规范。 然后，跟踪规范以测试用于验证规范的案例。
因此，您可以将测试用例追溯到需求。
答案 4 :(得分：0)
测试用例不是精炼要求。当然，它们可能需要的不仅仅是文档化的要求，因为要求是您的设计的基础，这是您的测试用例所需要的。这不是需求集不完整的问题。
此外，要求还可能包括非功能性要求，您可能根本无法提供测试用例。
对我而言，从需求到测试用例的可追溯性方面是一种确保所有功能需求得到考虑并且一切都以正确方式工作的方法。如果您在整个过程中失去了可追溯性，这意味着您有一些要求，您可能无法确定它在设计中的位置。如果你能说出你的需求在设计中的位置，但你没有跟踪测试用例，那么它只是意味着你错过了测试这个要求。
总而言之，这种可追溯性可确保您的测试用例涵盖您的所有功能要求。不过，您可以拥有更多测试用例，以及更多（非功能）要求。
答案 5 :(得分：0)
据我了解，需求比测试用例更为通用。
要求可能是例如：该方法不应接受18-64范围之外的数字。测试用例可能类似于：
但在很大程度上，这是开发团队内部共同理解的问题......
托马斯