TDD 中的需求可追溯性？ [关闭]答案

【问题标题】：Requirement Traceability in TDD? [closed]TDD 中的需求可追溯性？ [关闭]
【发布时间】：2011-02-08 02:08:01
【问题描述】：

一直都说需求是可追溯的，但是说到敏捷开发，就很难了。 我的问题是，如何在敏捷，特别是测试优先开发或测试驱动开发中管理需求可追溯性（或需求变更管理）？

【问题讨论】：

你说你得到了答案。那么你会接受其中一个答案吗？ :-)
我知道它目前是如何完成的。我正在研究 TDD 中的需求可追溯性，因此必须查看其实现的所有可能方式。总之，我会接受每一个答案，然后一一详细探讨:)

标签： tdd bdd agile

【解决方案1】：

在 TDD 或 BDD（行为驱动开发）中，您的需求会在测试中捕获。

您可以根据实际需求（更多 TDD 模型）映射您的测试，也可以将您的测试实际用作产品的需求（更多 BDD 模型）。

如需了解如何使用 BDD 和作为需求运行的测试的一个很好的示例，请查看 Ruby/Rails 世界的 RSpec 和 Cucumber。

我曾在 FDA 监管的环境中工作并负责质量工程，我可以告诉您，TDD/BDD 非常适合 FDA 审核员所针对的模型。

BDD 模型将允许您跟踪：

要求 -> 测试
测试 -> 实施
实施执行 -> 测试结果

【讨论】：

【解决方案2】：

当需求发生变化时，测试也会发生变化。请记住，测试是活的文档和需求规范。因此，这种变化是无缝的。

例如：需求变更导致测试期望变更，进而导致代码变更。

【讨论】：

【解决方案3】：

可能是我遗漏了一些东西，但 TFD 或 TDD 处于单元测试级别。在我看来，您所指的是由Traceability matrix 和/或acceptance tests 管理的。

【讨论】：

TDD 不一定在单元测试级别。这正是开发人员最常与之交互的地方。
我将 TDD 视为一个完整的开发周期，其中我们有需求，然后我们创建测试列表，然后从中创建单元测试等等。我的问题是如何在敏捷中管理需求可追溯性，特别是在 TDD 中，我们可能没有规范文档并且需求一直在变化。在那种情况下，我们如何跟踪需求以防发生任何变化？

【解决方案4】：

敏捷可追溯性一开始就非常棘手，目前有很多工具声称通过记录用户故事或从用户故事生成需求或在测试中的 TDD 中提供可追溯性。

我们考虑任何敏捷方法时的重点是不必强调文档（阅读Agile Manifesto。因此，我不确定敏捷将如何具有可追溯性以及如何简化其核心原则。

【讨论】：

【解决方案5】：

最近在网上发现了一个可追溯的需求管理工具。 [http://code.google.com/p/ultimate-trace/ Ultimate Trace] 试一试。它为我们节省了维护可追溯性的大量精力。

【讨论】：

【解决方案6】：

重新阅读宣言。它更重视四个语句的右半部分，但请注意它的内容是“左边有值”。这意味着文件本质上不是邪恶的或被禁止的，它们应该谨慎查看，不应该推翻工作的真正目的。话虽如此，电子可追溯性工具已经存在多年，有些更优雅，有些绝对是野兽。从测试用例跟踪到定义它们的故事很重要，尤其是当系统进入 R&M 时。否则，随着系统的增长，您会在追踪系统文档与追踪系统组件之间进行权衡。可追溯性可以通过命名约定、配置/代码基线工具的某些功能、测试套件工具或 RTM 来处理。老式的、老式的方法是一个电子表格（请切开我的手腕），但我们现在已经走了很长一段路。

【讨论】：