【发布时间】：2010-10-14 11:45:33
【问题描述】：
我看到有许多系统要求测试用例可追溯性，我开始问自己这两个人工制品之间的关系是什么。例如，为什么有测试用例的概念，而不是仅仅将它们称为详细需求？测试用例实际上是对需求集的细化吗？如果测试用例不是需求并且需要比文档化的需求更多（例如测试更多的错误等），那么需求集肯定是不完整的吗？需求只是抽象的测试用例吗？
【问题讨论】：
标签： testing requirements
【发布时间】：2010-10-14 11:45:33
【问题描述】：
我看到有许多系统需要测试用例可追溯性，我开始问自己这两个人工制品之间的关系是什么。 例如，为什么有测试用例的概念，而不是仅仅将它们称为详细需求？测试用例实际上是对需求集的细化吗？
我认为这种区别只表明它们是何时产生的，以及用于什么目的。在我们知道很多实现的具体细节之前，需求很早就产生了。我们试图让它们的实现保持中立，因此它们往往更抽象。
测试脚本的目的有些不同。需求告诉开发人员系统应该做什么，而不是如何去做。然而，测试用例（因为它们经常被编写）准确地指定了如何做某事，并且它们通常会参考实际的实现细节。
如果测试用例不是需求并且需要比文档化的需求更多（例如测试更多错误等），那么需求集肯定是不完整的吗？
是的，要求设置不完整。这总是因为无论您工作多长时间，您都无法完整记录所有用户或利益相关者的所有期望。
但是测试用例也不完整。完整的测试是不可能的。任何一组测试都是所有潜在测试的样本集。但是，测试通常在稍后阶段完成，此时我们对需求了解得更多，因此它们可以更具体、更详细、更完整，而不是不完整。
看看： http://www.ibm.com/developerworks/rational/library/04/r-3217/
在本文中，作者解释了如何从用例到测试用例。作者提出的观点是，虽然用例包含所有流和子流，但测试用例是特定数据和通过系统的特定流。
需求只是抽象的测试用例吗？
我会说是的，可以这样看待它们。有些人甚至会不编写测试用例，而只是将需求用作测试的“清单”。
从测试用例到需求的可追溯性是一个非常好的想法，也是一种非常流行的方法。工具实现了这个功能，因为它很畅销。但是这种方法存在局限性和陷阱。当工具高兴地报告 100% 覆盖率时，通常会产生一种错误的完整性感觉，因为您碰巧对每个需求都有 1 个测试。它并没有真正解决某些要求需要的不仅仅是一项测试的问题。它也不考虑测试的内容或测试是否真正涵盖了它们应该包含的内容。
如果您对需求->测试可追溯性感兴趣，您应该了解该方法的局限性，并意识到应该谨慎地与其他方法结合使用，以便为您的测试提供更全面的方法。
【讨论】：
-
感谢您的好回答，澄清了我对需求可追溯性的理解
在 TDD 中，测试用例是需求。
但有些要求是不可测试的，或者需要庞大的测试设施。
【讨论】：
-
据我所知，你怎么会有一个不可测试的需求呢？你怎么知道要求已经满足？你能举一个这样的要求的例子吗？
-
一个例子：“软件应该用Ada编写”，只有代码审查才能验证。另一个：“此功能应在 20 毫秒内运行”，如果出于任何原因，项目团队无法使用实际硬件，唯一验证它的方法是从汇编代码中计算 WCET。
-
在 TDD 中，测试是由开发人员在实现代码之前编写的。它们不是我们传统上认为的要求。开发人员在开始编写 TDD 测试之前仍然需要一些其他工件（用户故事、验收测试、用例）。
实际上这取决于团队/组织使用的开发过程。
在敏捷（Scrum、XP 和变体）流程中，通常不使用要求和验收测试来验证用户故事是否正确实施。所以用户故事是某种需求/规范。
在测试驱动开发中，测试是要求。
在 Waterfall 中，您通常会创建一个文档，其中列出您的软件的所有要求并与利益相关者一起批准。然后您根据这些要求进行开发并根据它们测试您的软件。正如 Frank 的回答中提到的，通过这个过程，您需要从需求到测试用例的可追溯性，因为 CMMI 要求您测试所有需求。
【讨论】：
就我而言，
需求被追踪到一组旨在满足需求的规范。 然后，将规范跟踪到旨在验证规范的测试用例。
因此，您可以将测试用例追溯到需求。
【讨论】：
测试用例不是细化的需求。当然，它们可能需要的不仅仅是文档化的需求，因为需求是您设计的基础，也是您的测试用例所需要的。这不是需求集不完整的问题。
此外，需求还可能包括非功能性需求，您可能根本无法提供测试用例。
对我来说，从需求到测试用例的可追溯性方面是一种确保所有功能需求都得到考虑并且一切都以正确方式运行的方法。如果您在途中的某个地方失去了可追溯性，这意味着您有一些需求，您可能无法确定它在设计中的哪个位置得到满足。如果您能分辨出您的需求在设计中的哪个位置，但您没有跟踪到该需求的测试用例，那么这只是意味着您错过了测试此需求。
因此，总而言之，这种可追溯性可确保您的测试用例涵盖您的所有功能需求。不过，您可以拥有更多测试用例以及更多（非功能性）需求。
【讨论】：
据我了解，需求比测试用例更笼统。
例如，要求可能是：该方法不应接受 18-64 范围之外的数字。然后测试用例可能类似于：
- 提供 17 作为输入
- 提供 65 作为输入
- 提供 -1 作为输入
但在很大程度上，这是开发团队内部的共识问题...
托马斯
【讨论】：