我看到有许多系统用于需求与测试用例的追踪，我开始思考这两个文档之间的关系。比如说，为什么要有测试用例这个概念，而不是只叫它们详细的需求呢？测试用例是否实际上是对需求集的细化？如果测试用例不是需求，需要比记录的需求（例如测试更多错误等）更多，那么需求集肯定是不完整的？需求只是抽象的测试用例吗？
6个回答
4
我看到有许多关于需求到测试用例追溯的系统，开始思考这两个文档之间的关系。例如，为什么要将测试用例称为详细需求，而不是只叫做需求呢？测试用例实际上是需求集的细化吗？
我认为这种区分只是表示它们产生的时间和目的不同。在我们了解很多具体实现细节之前，非常早期就会产生需求。我们试图保持它们的实现中立性，因此它们往往更加抽象。
测试脚本的目的有些不同。需求告诉开发人员系统应该做什么，而不是如何做到。然而，测试用例（通常是这样编写的）确切地指定如何做某事，并且它们经常引用实际的实现细节。
如果测试用例不是需求，需要比文档化的需求更多（例如，测试更多错误等），那么需求集是不完整的吗？
是的，需求集是不完整的。因为无论您花费多长时间来工作，都无法完全记录所有用户或利益相关者的所有期望。
但是测试用例也不完整。完全的测试是不可能的。任何一组测试都只是所有潜在测试的样本集合。然而，测试通常在后期进行，我们对需求了解更多，因此可以更具体、更详细、更完整，但并非完全完整。
请参阅： http://www.ibm.com/developerworks/rational/library/04/r-3217/ 在这篇文章中，作者解释了如何从用例到测试用例。作者的观点是，虽然用例包含所有流程和子流程，但测试用例是具体数据和系统通过的具体流程。
“需求只是抽象测试用例吗？” 我会说是的，它们可以被视为这样。有些人甚至会认为不编写测试用例，只使用需求作为基础进行测试的“清单”。
将测试用例与需求进行追踪是一个非常好的想法，也是一种非常流行的方法。工具实现这个功能是因为它有市场。但是这种方法存在着局限性和陷阱。当工具高兴地报告覆盖率达到了100%时，往往会产生虚假的完整感，因为你恰好为每个需求编写了1个测试用例。这并没有真正解决某些需求需要更多测试用例的问题。它也没有考虑测试内容或测试是否实际覆盖了应该覆盖的内容。
如果您对需求->测试追踪感兴趣，应该意识到这种方法的局限性，并意识到它应该与其他方法谨慎结合使用，以提供更全面的测试方法。
我认为这种区分只是表示它们产生的时间和目的不同。在我们了解很多具体实现细节之前，非常早期就会产生需求。我们试图保持它们的实现中立性，因此它们往往更加抽象。
测试脚本的目的有些不同。需求告诉开发人员系统应该做什么，而不是如何做到。然而，测试用例（通常是这样编写的）确切地指定如何做某事，并且它们经常引用实际的实现细节。
如果测试用例不是需求，需要比文档化的需求更多（例如，测试更多错误等），那么需求集是不完整的吗？
是的，需求集是不完整的。因为无论您花费多长时间来工作，都无法完全记录所有用户或利益相关者的所有期望。
但是测试用例也不完整。完全的测试是不可能的。任何一组测试都只是所有潜在测试的样本集合。然而，测试通常在后期进行，我们对需求了解更多，因此可以更具体、更详细、更完整，但并非完全完整。
请参阅： http://www.ibm.com/developerworks/rational/library/04/r-3217/ 在这篇文章中，作者解释了如何从用例到测试用例。作者的观点是，虽然用例包含所有流程和子流程，但测试用例是具体数据和系统通过的具体流程。
“需求只是抽象测试用例吗？” 我会说是的，它们可以被视为这样。有些人甚至会认为不编写测试用例，只使用需求作为基础进行测试的“清单”。
将测试用例与需求进行追踪是一个非常好的想法，也是一种非常流行的方法。工具实现这个功能是因为它有市场。但是这种方法存在着局限性和陷阱。当工具高兴地报告覆盖率达到了100%时，往往会产生虚假的完整感，因为你恰好为每个需求编写了1个测试用例。这并没有真正解决某些需求需要更多测试用例的问题。它也没有考虑测试内容或测试是否实际覆盖了应该覆盖的内容。
如果您对需求->测试追踪感兴趣，应该意识到这种方法的局限性，并意识到它应该与其他方法谨慎结合使用，以提供更全面的测试方法。
- Mark Irvine
1
感谢您的好回答，它澄清了我对需求追踪的理解。 - logic_chopper
1
在TDD中，测试用例就是需求。
但是有些需求是无法测试的，或者需要庞大的测试设施。
但是有些需求是无法测试的，或者需要庞大的测试设施。
- mouviciel
3
为了增加我的知识，你如何拥有一个不可测试的需求？你怎么知道这个需求已经被满足了呢？你能举一个这样的需求的例子吗？ - logic_chopper
1一个例子：“软件应该用Ada编写”，只有代码审查才能验证。另一个例子：“这个函数应该在20毫秒内运行”，如果由于任何原因实际硬件不可用于项目团队，唯一的验证方法是从汇编代码计算WCET。 - mouviciel
1在TDD中，测试是由开发人员在实现代码之前编写的。它们不是我们传统意义上认为的需求。开发人员在开始编写TDD测试之前仍需要其他一些文档（用户故事、验收测试、用例）。 - Mark Irvine
1
实际上这取决于团队/组织所使用的开发流程。
在敏捷（Scrum、XP和变体）流程中，通常没有需求，验收测试用于验证用户故事是否正确实现。因此，用户故事是某种需求/规格说明。
在测试驱动开发中，测试就是需求。
在瀑布流模型中，通常创建一个文档列出软件的所有需求，并与利益相关者批准。然后根据这些需求进行开发并测试软件以符合它们。正如弗兰克的回答中提到的那样，使用这个流程需要从需求到测试用例的可追溯性，因为CMMI要求您测试所有需求。
- Sergii Pozharov
1
在我的情况下，
一个需求被追溯到一组旨在满足该需求的规格说明。 然后，规格说明被追溯到测试用例，旨在验证规格说明。
因此，您可以将测试用例追溯回需求。
一个需求被追溯到一组旨在满足该需求的规格说明。 然后，规格说明被追溯到测试用例，旨在验证规格说明。
因此，您可以将测试用例追溯回需求。
- EKI
0
测试用例并不是精细化的需求。当然，它们可能需要比记录的需求更多，因为需求是设计的基础，而设计又是测试用例所必需的。这并不是需求集不完整的问题。
此外，需求还可能包括非功能性需求，对于这些需求，您可能根本无法提供测试用例。
对我来说，从需求到测试用例的可追溯性是确保所有功能需求得到考虑并且一切正常运行的一种方式。如果您在某个地方失去了可追溯性，这意味着您有一些需求，您可能无法确定在设计中满足了哪些要求。如果您可以确定您的需求在设计中得到了满足，但是您没有将其追溯到测试用例，则仅意味着您错过了测试此需求的机会。
因此，总之，这种追溯性确保您的测试用例涵盖了所有功能需求。尽管如此，您可以拥有更多的测试用例，以及更多（非功能性）需求。
- Frank
0
据我理解，需求比测试用例更为一般。
例如，一个需求可能是：该方法不应接受18-64范围之外的数字。而测试用例则可能是：
- 输入17
- 输入65
- 输入-1
但总的来说，这是开发团队共同理解的问题...
Thomas
- Thomas Weller
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接