我曾作为测试人员在一些执行TDD的开发团队里工作，但是我从没认真想过TDD对我来说有什么影响，直到有天有人问我：“TDD是一种主流的项目驱动方法，作为测试人员你是怎么理解它的？”

  问的多好！

  我的第一反应是TDD使我对软件及其相关的测试有了一定的了解，因而我能在设计产品，预测商业风险和评估对页面展示/验收测试的潜在影响上面贡献自己的价值。

  本文就是想跟大家详细说说，我是如何在TDD环境中创造价值的。

TDD项目里有哪些重要的角色？

  TDD是采用极限编程思想的实践，因此这里我借用极限编程团队里的角色名：

  · 程序员

  · 测试人员

  · 客户

你觉得TDD是什么？

  或许我应该从我对TDD的理解说起。我确信我并不是TDD相关的权威，因此我会长话短说。TDD的基本原理大概是，先写测试代码，然后只写能让测试通过的必要的功能代码，然后去重构代码使其更整洁，更高效或者满足一些编码标准。这就是众所周知的TDD周期（红，绿，重构）。

  TDD主要是关于代码的设计，作为附属品的测试结果使得我们可以充分发挥测试人员的优势，从而不必屈服于程序员们100%安全和放心的错觉。

   TDD可以给程序员提供快速的反馈，这对于他们能否设计出更靠谱的代码来说也是至关重要的。大大地缩短反馈回路也是持续集成（CI）和持续交付（CD）自动化框架的核心准则。测试人员可以甚至必须充分利用快速反馈回路，去防止代码偏离最初的设计想法，同时去使得持续集成和持续交付成为可能。

    很多人认为TDD周期是从编写测试代码开始的，但我却不赞同。通过观察，我认为添加测试代码不是TDD周期的第一步，想清楚测试代码应该是什么样的才是。

不写代码的测试人员如何参与到TDD中？

   很重要的一点，程序员关心代码的设计而测试人员关心软件的功能。但是这两者之间的界限是很模糊的，也就是说，测试人员能且应该关心代码是如何设计的，同样地，程序员也应该对软件的功能多一些关注。

   关于代码设计，测试人员关心的是可测试性。根据James Bach的理论，测试人员应该关心的两个重要问题是，可测试性是可控制，并且可观测的。我们可以把系统放进我们需要的场景下去观察系统的功能吗？把应用程序放进我们测试需要的多种场景下容易吗？我们如何确定应用程序在一个给定的时间点在做什么，打日志的方法可行吗？打什么样的日志呢？

   当和程序员讨论软件的时候，我喜欢用序列图来描述系统不同部分的请求和响应。这使得我们能够了解流经系统的不同状态，反过来也能帮助我们想出哪些地方是需要测试的。

   这是一个典型的Web应用的例子：

    我对系统的理解和程序员对程序组件级别的深入了解使得我们可以避免一些不必要的重复测试，也能更好的防止无效的测试。我们都对测试的策略了然于心。

以下是一个关于协同测试策略的模拟对话，参与者有Paul (程序员), Terry (测试人员) and Carl (客户)。

Paul: “嗨， Carl, Terry, 能耽误你们一点儿时间吗?

Terry: “好”

Carl: “没问题”

Paul: “好的，来坐下吧。我们的系统需要访问一些我们之外的系统。目前，当这些外部的第三方应用无响应或者不好用时，我们会在用户界面展示不同的错误信息。从技术角度来看，这不是很好，因为用户界面不应该对这些错误的不同有所感知。Carl，你觉得在用户界面用一个通用的错误信息来表明第三方服务不可用怎么样？”

Carl:（思考了一会儿）”是的，我也觉得通用的错误信息更好些。” 

Terry: “好吧。我们有一些测试是用来确认用户界面上的这些错误信息的，这些测试还需要执行吗”

Paul: “不用。我们会在后台服务抓取错误然后抛出通用的错误信息。”

Terry: “好吧，我在用户界面加个断言怎么样呢?”

Paul: “应该不必，因为我们的后台服务会在错误处加断言。”

Terry: “可是你的断言是在你发送错误的位置，我们却不知道错误是否已经在用户界面展示出来了。我想做一个用户界面层面的测试去确认错误信息已经展示出来了并且用户也根据我们的错误信息做了后续操作。”

Paul: “我还没想到更好的用户引导。Carl，你觉得和当前的用户引导一样可以吗?”

Carl: “可以的话，当然好了。”

Paul: “没问题。工作量可能会增加一点，但是我们应该能做到。我们需要更新一下日志，才能看到抛出的新的通用错误。很快你就能看到改变了。”

Terry: “太好了，我想我应该从当前的错误场景里重构一个场景来验证通用的错误提示，然后删除其他多余的场景。我要怎么才能触发错误场景来测试呢?”

Paul: “触发错误的流程和当前应该是一样的，我们只是采用了不同的方式来处理错误。当前的模拟第三方服务应该是仍然有效的，但是我们进行单元测试的时候会对它进行校验，因而需要周知你们。你们都赞成吗？”

Terry: “没问题!”

Carl: “没问题!”

Paul: ”好极了！我们快点抓紧时间，看看进行到哪里了！”

TDD周期的执行

  首先，我们来简单过一下TDD流程，来描述一下我是如何执行测试的。

写测试代码

  程序员以写代码来开始TDD周期，然后关注单元测试反馈的结果。

  我以深入思考我的测试思路并且去探索不同的边缘测试场景开始。我会去写一些之后可以自动化执行的测试场景。

  随着设计的发展，会出现越来越多的问题等着我们去回答。

  例如，程序员会给我创造一个特定的场景而我需要去很全面的测试，因为他们试图用单元测试去覆盖这个场景但测试证明是不足的。

  同样地，我的边界场景可能也需要设计去变化或调整。

写能让测试通过的功能代码

  当程序员有代码或测试要提交的时候他们会告知我。我们会运行这些代码和并执行相关的测试（主要是单元集成测试），讨论达到可验收状态需要完成的标准，然后我会在程序员的机器上粗略的测试这个软件。

  我会尝试用一些边缘测试和异常情况测试来检查测试的正确性。这也是一个向用户展示我们产品的机会，从而去确认我们的产品是否符合用户的期望。

  测试代码的反馈循环和演示代码的提交只需要几个小时的时间而不是几天。

  根据软件的发展，我会在将自动化应用到我的一些测试场景的同时向程序员展示我的测试体系。

 诚然，在产品代码完成之前我没法保证测试是绝对没问题的（在真正的TDD周期里），但是最起码的，我对程序员和我们测试过的代码有很多信心。

重构

  程序员提高产品的质量，而我继续我的探索。

 通过和程序员合作，我知道哪些测试已经进行过了以及各部分是如何相互作用的，我也知道了程序员同时进行编码和测试潜在的弊端。

 我用从合作的部分获取的信息去构建并完善我探索性部分的测试体系。

 在重构阶段我也会回顾可测试性和测试的覆盖率去保证产品仍然是有效并高效的。

 例如，程序员可能认为一个需求需要用单元测试而不是ＵＩ场景来证明。我们讨论测试的意义以及压力测试的优缺点。如何测试是由一个团队共同决定的，而不仅仅是一个片面的想法。

 软件的设计和软件的功能是相互参考的。因为没什么是隐藏的所以提bug变成了一个更轻量级的操作。

结束循环

 我觉得TDD周期里开发团队的紧密合作就像是缝衣服，针脚就是交互关系而不同的衣服就是不同的关系。更紧密的针脚使得联结更为紧密，而松散的针脚则会引发衣服很快分崩离析的可能。

 当需要判断一个特征是否通过的时候，开发团队和业务相关人员不仅仅是从测试人员而是会从众多来源获得反馈。

 测试人员允许，代码才算通过或者测试人员作为产品质量的最后一道防线的观念已经不存在了。整个团队的人员都知道产品的状态和功能所以每个人都可以对产品是否可以投放到生产环境拥有发言权。

 下图描述了上述的TDD周期，但是我又加了一些测试人员可以参与到整个流程里面的不同类型场景的例子：

如果你的团队不执行TDD周期呢？

 程序员可能不会把他们的开发过程称为TDD，也不会先写测试代码。但是好在他们会开会讨论如何设计他们的代码而你作为一个测试人员，完全是可以再这个阶段参与进来的。

 仅仅因为一个开发团队不用测试区驱动他们的代码设计并不意味着他们没有对设计进行思考。测试时一个很好的附属品。

 如果你和你的程序员们没有为产品构建一个测试框架用以自测，这种情况关闭与程序员的前期合作将会有助于预防缺陷。

现在该怎么办呢?

 这有一些曾经帮助我和程序员配合更紧密的小技巧，它们也帮助我更多的参与到了产品的设计。

上下文驱动测试

 测试场景驱动测试方法。

 我离开了瀑布/阶段交付的组织加入了极限编程开发团队，转而执行ＴＤＤ周期。我先前的测试方法就不是很好用了。

　为了能够在新的团队里提供有价值的测试，我需要去学习和调整。上下文驱动的测试团体给我带来了很多成长，也让我明白了我是什么类型的测试人员以及在团队里适合扮演什么样的角色。

了解程序员的艺术

　程序员通常对他们的工作很引以为傲。花一点时间去了解下从他们做了什么，为什么那样做以及他们是如何走到今天的，你会惊讶的发现，这种兴趣很快就会有回报。

成为领域的专家

　拥有你自己测试的领域。

　去了解谁会是你产品的用户，以及你的产品将会解决他们遇到的哪些问题。越接近我们的用户，我们的测试会做的越好。

　有一本伟大的书，让我对领域和设计相关的会话有了更好的理解，是Eric Evan的领域驱动设计。

　贯穿全书的一个主要观点是通用语言的使用。很多模棱两可源于商业语言翻译成了“dev speak”。

　了解你的领域并且推进通用的语言，能有效的避免这些模棱两可。

证明你的价值

　我对测试的喜爱，还有我的开发团队其他人员的密切合作不是一蹴而就的事情。

　这个过程经过了很多努力工作和辛苦，但是通过批判的思考，热情还有在一个有一个项目中证明我自己，我现在可以证明我在一个以程序员为中心的环境中是存在价值的了。

　既然我能做到，那么你为什么不可以。

　你是一个测试团队的测试人员。你对你的产品设计有自己的想法。你可能只是现在还不知道。

【英文原文：http://www.ministryoftesting.com/2014/08/tdd-testers/】

{测试窝原创译文，译者：婷婷}

译者简介：婷婷，努力的女孩最美。