blocks|key|969348|text|在TDD或BDD+(行为驱动开发)中，您的需求将在测试中捕获。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|969349|您可以根据实际需求(更多的TDD模型)映射您的测试，或者实际使用您的测试作为产品的需求(更多的BDD模型)。|969350|关于BDD和测试作为需求可以做什么的一个很好的例子，请查看Rails世界中的RSpec和黄瓜。|offset|length|969351|在FDA监管的环境中工作，负责质量工程，我可以告诉你，TDD/BDD非常适合FDA审计师所反对的模型。|969352|BDD模型将允许您通过以下方法进行跟踪：|969353|需求->测试|unordered-list-item|969354|测试->实现|969355|实现执行->测试结果|969356|entityMap|0|LINK|mutability|MUTABLE|url|http://rspec.info/|1|http://cukes.info/^0|0|0|12|5|0|18|2|1|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@$F|15|G|16|1|17]|$F|18|G|19|1|1A]]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1D|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|1E|8|@]|9|@]|A|$]]|$1|Q|3|R|5|N|7|1F|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]|10|$5|V|W|X|A|$Y|11]]]]

In TDD or BDD (Behavior Driven Development) your requirements are captured in your tests. 

You can either map your tests against actual requirements (more TDD model) or actually use your tests as the requirements for your product (more BDD model). 

For a great example of what you can do with BDD and tests functioning as requirements, checkout <a href="http://rspec.info/" rel="nofollow">RSpec</a> and <a href="http://cukes.info/" rel="nofollow">Cucumber</a> from the Ruby/Rails world.

Having worked in an FDA regulated environment, with responsibility for Quality Engineering, I can tell you that TDD/BDD fits incredibly well into the model an FDA Auditor is working against.

A BDD model will allow you to trace through:

<ul>
<li>Requirements -> Tests</li>
<li>Tests -> Implementation</li>
<li>Implementation Execution -> Test Results</li>
</ul>

blocks|key|2525187|text|当需求发生变化时，测试就会发生变化。请记住，测试是活的文档和需求规范。因此，这种变化是无缝的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2525188|例如:需求更改会导致测试期望的更改，而这反过来又会导致代码更改。|2525189|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

When the requirements change, the tests change. Remember that the tests are the living documentation and requirements specification. Therefore, the change is seamless.

For example: Requirements changes lead to test expectation changes, which in turn lead to code changes.

blocks|key|969278|text|可能是我遗漏了一些东西，但TFD或TDD处于单元测试级别。在我看来，您所指的是由可追溯矩阵和/或验收试验管理的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|969279|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Traceability_matrix|1|http://en.wikipedia.org/wiki/Acceptance_testing^0|14|5|0|1C|4|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

May be I am missing something but TFD or TDD is at the unit testing level. What you are referring to is managed by <a href="http://en.wikipedia.org/wiki/Traceability_matrix" rel="nofollow">Traceability matrix</a> and/or <a href="http://en.wikipedia.org/wiki/Acceptance_testing" rel="nofollow">acceptance tests</a> in my opinion.

blocks|key|2166360|text|敏捷可追溯性是非常棘手的，目前有许多工具声称可以通过记录用户故事或从用户事例或从测试生成需求在TDD中提供跟踪性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2166361|当我们考虑任何敏捷方法时，重点不在于强调文档(阅读敏捷宣言+)。因此，我不确定敏捷将如何具有可追溯性，以及如何简化其核心原则。|offset|length|2166362|entityMap|0|LINK|mutability|MUTABLE|url|http://agilemanifesto.org/^0|0|P|4|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Agile traceability is very tricky to begin with, A lot of tools are currently available that claim to provide traceability by documenting user stories, or generating requirements from user stories or in TDD from Tests. 

The point when we consider any Agile method is not having to emphasize on documentation(Read the <a href="http://agilemanifesto.org/" rel="nofollow">Agile Manifesto</a>. So, I am not sure how Agile will have traceability and also streamline with its core principles.

blocks|key|2166364|text|最近在网上找到了一个追踪、需求管理工具。http://code.google.com/p/ultimate-trace/终极追踪，试一试。它为我们节省了很大的精力来维护可追溯性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2166365|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Lately found a traceablity, requirement management tool online. [http://code.google.com/p/ultimate-trace/ Ultimate Trace] Give it a try. It saved us a lot of effort maintaining traceability.

blocks|key|2525271|text|重读宣言。它更重视这四个语句的右半部分，但请注意，它是这样写的：“左边有值”。这意味着文件本身并不是邪恶的或被禁止的，它们应该被谨慎地看待，而不应该否定工作的真正目的。尽管如此，电子追踪工具已经存在多年了，一些更优雅，一些绝对的野兽。从测试用例跟踪到定义它们的故事是很重要的，特别是当系统进入R&M时，否则，随着系统的增长，您将不再追逐系统的文档来跟踪系统的组件。可追溯性可以通过命名约定(配置/代码基线工具的某些特性)、测试套件工具或RTM来处理。老式的方法是电子表格(请割断我的手腕)，但我们已经走了很长一段路了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2525272|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Re-read the manifesto. It values the right-half of the four statements more, but note that it reads, "there is value on the left." Which means that documents are not inherently evil or forbidden, they should just be view cautiously and should not overrule the real purpose of the work. That being said, electronic traceability tools have been out there for years, some more elegant and some absolute beasts. Tracking from test cases back to the stories defining them is important, especially as systems move into R&amp;M. Otherwise, as systems grow you trade off chasing down documentation of the system for chasing down components of the system. Traceability may be handled by naming conventions, some feature of a configuration/code baseline tool, by a test suite tool, or by an RTM. The old, old school approach was an spreadsheet (slit my wrists, please), but we have come a long way by now.

Its always said that the requirements should be traceable but when we talk about agile development, it is quite difficult.
My question is that how requirement traceability (or requirement change management) is managed in agile and specifically Test First Development or Test Driven Development?

Requirement Traceability in TDD?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

它总是说需求应该是可跟踪的，但是当我们谈到敏捷开发时，这是相当困难的。我的问题是需求可追溯性(或需求变更管理)是如何在敏捷(特别是测试第一开发或测试驱动开发？)中进行管理的。

问TDD中的需求可追溯性？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD中的需求可追溯性？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD中的需求可追溯性？
EN