您如何回答经理、测试人员和团队中其他人提出的以下问题:
在哪个版本中修复了错误 #829？在我们当前的测试版本中完成了哪些任务？
简而言之，从报告到部署，您如何实现需求、任务和错误的可追溯性？您使用哪些流程、工具和技术来实现这一目标？
最佳答案
我们使用 TRAC与 SVN在我们公司，并通过定期计划部署(每月一次...
当报告错误时，它会被输入到 TRAC 并给出一个票证编号(例如#1001)
修复错误后，代码将通过 SVN checkin 说明中的票号 (#1001) 重新 checkin SVN。
开发人员记下 SVN 变更集编号(例如 [5000])并打开 TRAC web ui。关闭票证时，他们将变更集编号放在票证的注释中。
这样，SVN checkin 引用了票证……而票证引用了 SVN checkin 。
然后我们的日常构建针对 SVN 变更集执行(例如，今天的构建是变更集 [5050] 的所有内容)，并且在我们的部署通知中对此进行了说明。
Deployed On | Environment | Changeset
--------------+-------------------------+--------------------------
10-01-2008 | DEV | 5100
10-01-2008 | STAGING | 5080
10-01-2008 | STABLE | 5050
01-01-2008 | PRODUCTION | 5000
这样，测试人员在审查测试修复程序时，可以通过票证注释中的更改集知道他们正在查看的构建是否包含修复程序。
关于continuous-integration - 持续集成 : how do you tie back your builds to requirements/tasks/bugs?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/241397/