TDD真的可以确保质量？

作者 Ben Hughes译者 韩锴 发布于 2008年1月31日 上午11时12分

社区

Agile

主题

敏捷技术,

调查,

质量交付

标签

评论,

统计,

测试驱动开发,

测试

加拿大国家研究委员会发表过一篇题为“测试先行方法对于编程的效果”的论文，其中有一些值得关注的评注。这项研究由24位IT专业的毕业生参加，它丰富了正在升温的关于测试先行领域的研究。尽管出于快速了解领域知识的目的，TDD作为一种卓越的学习工具已被认可，但至于它是否真与软件质量直接相关，这个问题仍然没有得到证明。这次研究不具有最终的权威性，不过它仍然揭示出一些有趣的结论——尤其是在对实验结果进行分析时，存在有不同的声音。

下面的内容摘自于研究报告的摘要：

测试驱动开发（TDD）的基础是：首先用一个测试将一项功能规范地表示出来，然后实现这项功能，让测试通过，最后不断地重复这个过程。本论文描述了一次对照实验，它评估了TDD这个重要方面：即在TDD中，程序员首先会编写功能测试，然后才编写相应的实现代码。

多位大学毕业生参与了这次实验。其中实验组开发时运用了测试先行的策略，而对照组运用的是更为传统的开发技术——实现功能在先，编写测试在后。两组人员都遵循增量的过程，一次增加一项新功能，然后执行回归测试。

研究者对此的评注道：“实验的结果证实了测试先行技术的一个抉择理论——测试先行通常选择以生产力为中心，而不是质量。”

我们的主要结论是，坚持测试先行的程序员会为每个程序单元编写更多的测试。更进一步的，随着程序员测试的增加，生产力通常会按照比例达到更高的级别。因此，通过一系列的级联反应，测试先行似乎能够提高生产力。

……我们同时还注意到，随着程序员测试数量的递增，软件的最低质量在线性地增加。而它与采用的开发策略无关。

但是也有不同的声音。Jacob Proffitt是一位博客作者，自称是一位“充满热情的程序员，偶尔当一下管理人员，总的来说是个多才多艺的技术人员”。他研究了这篇论文后，在blog上发表了对论文的质疑。他认为，这篇论文在下结论时存在着强烈的确认偏袒[译注*]（confirmation bias）——比如，文中的结论忽视了很多实验中的调查事实。他相信，“TDD与质量的关系仍然有很多值得怀疑的地方”，比如：

• 对照组（非TDD，“后测试”）在每个方面上都获得了更高的质量——他们的质量有更高的上限、下限、平均值和中值。
• 对照组坚持更少的测试，却获得了更好的质量。
• 质量在TDD组才更显著地与测试的数量相关联（这是一个有趣的不同点，我不确定作者是否意识到了这一点）。
• 对照组的生产力可以作为测试量的函数，因此是高度可预见的，而且它比TDD组拥有更强的测试相关性。

Jacob指出，这些学生的数据告诉我们的唯一事实是：

• 坚持测试先行的学生平均会写更多的测试。
• 学生写的测试越多，生产率越高。
• 软件的最低质量随着测试数量的提高而线性地提升。

IEEE软件杂志的编辑Hakan Erdogmus是原始论文的合著者。他从不同的视角审视了这些观点：

单独一个学生，尤其是像我们的那些没有经验的学生，无论怎样安排实验，都不能证明或者证伪任何事情。实验的观察结果最多只能轻轻揭开大谜团的一角。在很多情况下，它们引发的疑问远远多于它们所能回答的，希望随着我们在研究中提出越来越多的相关问题，能加深我们对于这些现象的理解……事实上，经验主义的软件工程术语里头并没有“证实”这种说法。我们研究一种技术，充其量只能丰富我们的“证据”，并且提出一个待驳倒的理论来。尽管通过少数的实践以及一些值得注意的观察结果，我们可以宣称证据已经很充分了。但是，“陪审团”还在屋中讨论着，一直没有定论。

随后，Hakan向InfoQ展示了关于TDD更为深入的探讨，这些讨论是基于目前已经完成的大量研究之上的：

从2001年到2008初所公布的23个TDD研究案例表现出一些相互冲突的结果，但是总的趋势却在走向一个一致的结论。研究结果的不同产生于上下文因素的多样性，它们都会影响到接受测量的结论和变量。在质量面前，即使存在些许争议，但结果是非常有说服力的。其中的22项研究，评估了一些内部或者外部的质量在TDD的影响下，会产生什么不同。其中13项报告表明TDD带来了不同程度的提高，4项表明TDD不是决定性的因素，4项表明没有非常明显的不同（包括我们自己的研究）。只有一项报告表明TDD导致了质量的下降。

译注* 人在争论或作出判断时，总是习惯倾向于接受有利于自己观点的证据，而忽略不利于自己观点的证据。这种现象被称为“确认偏袒（confirmation bias）”。

查看英文原文： Does TDD Really Ensure Quality?

1. 返回顶部

   总结

   2008年1月31日 下午7时34分 发表人 Jeff Xiong

   TDD似乎能够提高生产力，有可能同时提高质量，至少不太可能使质量下降。很好，有这个结论就够了。
   再次说明一件事情：TDD是开发方法，而不是测试方法。

   回复

2. 返回顶部

   "TDD真的可以确保质量"说法本身是伪命题

   2008年1月31日 下午7时47分 发表人 Yan Hua

   请问什么能够确保质量？——没有什么可以“确保”的。如果能提高质量而且还能提高生产力就已经很可取了。

   回复

3. 返回顶部

   TDD，试过就知道，用过都说好;)

   2008年2月1日 上午2时38分 发表人 isaac han

   TDD，试过就知道，用过都说好;)

   回复

4. 返回顶部

   TDD

   2008年2月1日 上午4时52分 发表人 丽娟 王

   在一个项目中实践了TDD，个人觉得效果很好。
   但总得说来，个人认为，测试先行对项目的生产力、质量是否有帮助并不会有一个定论，因为开发人员对测试的认知程度是不同的。

   回复

5. 返回顶部

   TDD

   2008年2月2日 上午12时43分 发表人 James Tong

   最低质量。。。。。这个词不好理解啊。
   仅从新闻看，有一个疑问:两组的编程水平和智力水平是否相似？
   对照组的习惯是一些老程序员的习惯，他们开发出来的东西事必质量高一些。极端一点的考虑，新手程序员恐怕就算是采用了TDD也不如他们的东西质量高，因为他们想的全嘛。
   再想深一点，国外的学生他们的思维习惯更偏向于TDD呢？还是偏向于对照组的习惯呢？思维习惯的差别也会影响实验效果。

   回复

6. 返回顶部

   Re: TDD

   2008年2月3日 下午6时35分 发表人 Chen Zhiguo

   个体之间肯定会存在差异的,而且tdd也不是万金油,所以这样的测试并不能说明问题,这一点上,文章中也提到了

   回复

7. 返回顶部

   Re: 总结

   2008年2月10日 上午7时22分 发表人 jayden guan

   在这个所谓的TDD实验，很有可能没有重构。

   回复

• 更早的 >