对于测试人员而言，TDD意味着什么？

        英文原文：What does TDD mean for me, the Tester?

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

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

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

        我对 TDD 的看法

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

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

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

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

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

        设计一个测试缺陷

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

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

        多沟通多测试

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

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

        重构

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

        闭环

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

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

        写在最后

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

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

        1.   尝试情景驱动测试

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

        2.   做个细心的观察者

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

        3.   干一行，精一行。

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