跟踪需求到自动化测试用例，看起来是很自然而非常需要的，但是坦白说我从来没有看到这发生，并且对其感到困惑。我一直认为这是因为需求被掩盖了或者是过于高层次，以致不支持可跟踪性。虽然那可能在某些情况下是真的，但是并不完全是真的。

　　一位经验丰富的测试经理告诉我，为什么她不把需求跟踪到她的自动化测试用例中去。

　　她指出：大部分工具都允许需求链接到测试脚本，但是任何进行工业级的自动化的人都会把脚本做得可重用并把测试用例转换成数据。理论上你也可以把需求标识到每一条数据记录中，但是这样会使跟踪更改变得棘手，因为数据通常存储为文本而需求标识存储为数据库的键。

　　此外，她注意到编写得好的测试用例实际上就是有效的需求，因此没有必要在其他地方复制相同的信息。她的测试用例都有字段描述测试的执行条件，她用这个字段来文档化需求。实际上，她发现一个典型的需求管理系统允许在描述需求时存在太多的偏差，导致不明确和前后矛盾，然而，一个测试用例必须细化和足够明确，以便被执行。

　　当然并不是每个人都知道需求，但是每个人都会有缺陷。那么与缺陷跟踪系统做个接口如何？毕竟，一个全面的自动化测试套件应该发现需要被捕获和解决的问题。但是，同样的，并不是那么的简单。

　　我们有一个顾客要求我们的自动化测试框架与他的顾客缺陷管理系统整合，我们花费了大量的成本和精力来做。当我们的下一个版本出来的时候，我联系他，以便验证针对他的接口的修改是否正确，但是出乎我的意料，他竟然说他没有再用它。当然，我想知道为什么。

　　他说有3个原因。首先，当一个自动化测试失败时，有很多可能的原因：测试环境可能未正确地配置；测试数据可能未同步；测试脚本本身可能有一些问题；或者软件有一些问题。只有1/4的机会是真正的软件缺陷。作为一个惯例，他的测试人员会检查测试日志的错误，然后做出诊断 – 通常包括手工的重新执行测试 – 来揭露问题的原因。

　　这意味着他们需要把那些非软件的问题筛选出来。这个过程是极其耗费时间的，因为他们运行冗长的测试套件，而测试数据问题可能引起上百个错误。即便是软件的问题，它也可能引起多个错误，因此会创建多个重复的问题报告。这些缺陷会使他们的缺陷库极度地膨胀，影响缺陷的关闭率，因此影响用于预计发布日期用的典型的S曲线报告。

　　另外，等到他们需要做出缺陷的分析和结论时，他们要提供的信息和分析报告要比测试日志能提供的多很多。他们仍然需要从缺陷管理系统中抽取问题信息并添加额外的信息，因此并没有节省时间。

　　最后，他说，在自动化测试中，出现失败的脚本或步骤未必就是问题的真正根源。往往问题的真正起因发生在比测试的错误日志记录更早的之前，因此与测试日志的信息没有非常密切的关系。总之，他觉得整合是麻烦多于带来的价值。

　　因此，我的任务是找出这些问题是个别的还是规律，或者是否有其他途径来使整合更加高效…或者没有。你的发现是什么呢？