领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
TDD真的可以确保质量？
作者 Ben Hughes 译者 韩锴 发布于 2008年1月31日
加拿大国家研究委员会发表过一篇题为“测试先行方法对于编程的效果”的论文，其中有一些值得关注的评注。这项研究由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?
译者 韩锴 毕业于北京工业大学软件学院，现任ThoughtWorks公司咨询师，热衷于敏捷软件开发技术的实践和推广。
总结
发表人
Xiong Jeff
发表于
Re: 总结
发表人
guan jayden
发表于
"TDD真的可以确保质量"说法本身是伪命题
发表人
Hua Yan
发表于
TDD，试过就知道，用过都说好;)
发表人
han isaac
发表于
TDD
发表人
王 丽娟
发表于
TDD
发表人
Tong James
发表于
Re: TDD
发表人
陈 之过
发表于
-
TDD似乎能够提高生产力，有可能同时提高质量，至少不太可能使质量下降。很好，有这个结论就够了。
再次说明一件事情：TDD是开发方法，而不是测试方法。 -
请问什么能够确保质量？——没有什么可以“确保”的。如果能提高质量而且还能提高生产力就已经很可取了。
-
TDD，试过就知道，用过都说好;)
-
在一个项目中实践了TDD，个人觉得效果很好。
但总得说来，个人认为，测试先行对项目的生产力、质量是否有帮助并不会有一个定论，因为开发人员对测试的认知程度是不同的。 -
最低质量。。。。。这个词不好理解啊。
仅从新闻看，有一个疑问:两组的编程水平和智力水平是否相似？
对照组的习惯是一些老程序员的习惯，他们开发出来的东西事必质量高一些。极端一点的考虑，新手程序员恐怕就算是采用了TDD也不如他们的东西质量高，因为他们想的全嘛。
再想深一点，国外的学生他们的思维习惯更偏向于TDD呢？还是偏向于对照组的习惯呢？思维习惯的差别也会影响实验效果。 -
个体之间肯定会存在差异的,而且tdd也不是万金油,所以这样的测试并不能说明问题,这一点上,文章中也提到了
-
在这个所谓的TDD实验，很有可能没有重构。
7 条回复
关注此讨论 回复