还记得早前CSDN发过的这篇《TDD已死，测试永生》吗？文中大意是说Ruby on Rails的创始人David Heinemeier痛批TDD过于偏重单元测试，过于琐碎，会使系统由许多中间层、中间对象网组成，带来复杂臃肿的架构。对于这一观点颇有争议，本文作者Duncan Nisbet则认为TDD对于测试人员来说有着很好的指导作用。

译文如下：

作为一名测试人员，似乎测试驱动开发(TDD)技术与自己没有太大关系，但是在实际工作中，我却发现TDD对测试环节也是有很好指导作用的。

作为极限编程(XP)所倡导的方式，TDD中的角色配置如下：

• 程序员
• 开发人员
• 用户

我对TDD的看法

除了要掌握TDD中提出的“红-绿-重构”环，我认为能否写出一个有效的测试缺陷是关键的一步，而能否弄清测试缺陷是什么更是关键中的关键。

较少与写代码打交道的测试人员该如何参与TDD环节

很多时候，人们认为程序员关注的是代码设计，测试员关注的是软件行为。但是这两者之间的界限其实是不需要太过明确的，他们双方可以形成互补。根据软件测试大师James Bach的定义，测试人员有两个主要的职责：可控制性和可监控性。比方说：系统能否在我们设好的状态下正常运作以及我们该如何进行监控？程序能否在设定的关键点上按时执行以及该如何进行记录？

在谈及程序员的角色时，我习惯用时序图来描述系统中有关请求和响应的部分。这样会让程序员和测试员都能明白系统在不同状态下的走向，从而明白什么样的测试才是需要的。测试人员与程序员应该互相合作，避免重复或无效的测试。

这是一个典型的Web程序时序图：

设计一个测试缺陷

一般情况下，在TDD环中，程序员的工作始于代码，同时等候着单元测试那边的反馈。

我会琢磨该选择哪种测试方法和什么样的边界测试用例，以及列出测试中可能遇到的情况。由于软件设计工作是渐进明细的，有不少问题会在这个过程中产生。例如：需要就某个特殊情况对单元测试做出修改，或是边界用例需要代码做出变更。因此要设计好测试用例，尽早把潜在缺陷暴露出来。

多沟通多测试

程序员会与我就测试范围和时间进行沟通，然后我们会一起把代码以及测试计划粗略过一遍，商讨好具体的测试范围与标准，然后开展测试工作。

我会尝试测试几个预先设计好的边缘用例和突发用例，以检查其有效性。这样做的好处是能有机会向客户展示软件，看是否符合他们的期望。一般情况下，这个双向的沟通交流过程需要几个小时。

重构

程序员继续完善代码，测试人员继续完成测试任务。以搭档的形式与程序员一起工作，可以更好地理解程序的流程走向，清楚什么测试才是需要的，以及找出程序的灰色地带和错误多发位置，进行改进修正。通过透明坦诚的双向沟通，会减少很多误会和无用功。

闭环

到了收尾阶段，我觉得这个工作与修补衣服差不多的。缝补的针线越细密，出差错的几率越少。

要做软件功能性方面的审查，参与方不能仅仅是测试人员，还得与该软件相关联的人员或部门参与，如：运营部，市场部等。这样一来，在最后的项目结束会议中，多方可以各抒己见，从而最终评定该产品是否值得推出和推广。

写在最后

依据上述步骤，我在TDD环中加入了测试人员工作环节，形成TDD-测试人员环，请看下图：

结合自己的实际情况，我还有以下几点提示，可以让TDD-测试人员环走得更顺：

1.  尝试情景驱动测试

当刚从一个瀑布开发团队转入极限编程团队时，我经历了一段过渡阵痛期。而情景驱动测试的出现，帮助我最终顺利完成 了转换。

2.  做个细心的观察者

程序员一般都会为自己的作品感到骄傲。我们不妨多花时间去了解身边的程序员，看看他们做了什么，怎么做的，又是如何得到今天的成就的。天道酬勤，你会有意想不到的收获。

3.  干一行，精一行。

我们不能仅仅关注自己的测试工作，所谓知己知彼，百战不殆；我们需要深入了解自己公司的产品，看看这个软件帮助客户解决了什么问题或还没有解决什么问题，将来会如何发展。只有凡事占得先机，我们在测试这条路上才会走得更好更远。