软件质量神话的经验研究

作者 Gavin Terrill 译者 金明 发布于 2009年10月13日

领域

架构 & 设计,

过程 & 实践

主题

软件工匠 ,

架构 ,

敏捷

标签

质量

分享到

微软研究所发布了一项检验软件工程神话的经验研究结果报告。由Nachi Nagappan主持的这项工作，衡量了通用的软件工程实践给软件质量带来的真正影响。分析显示：

• 测试中更高的代码覆盖率与上线之后需要补丁数的减少之间并不具有必然相关性，也有许多其他因素在发挥着作用。
• TDD改善了质量，但时间更长：“研究小组发现：相对没有使用TDD的团队所产出的代码，使用TDD的团队所产出的代码在缺陷分布密度上要低百分之六十到九十。他们同时发现采用TDD的团队要多花费百分之十五到三十五的时间才能完结项目。”
• 使用断言和代码验证能减少bug数。而且，“在代码里面能有效使用断言的软件工程师，往往是受过良好训练和经验丰富的，这对最终结果是一个利好因素。”
• 组织结构对质量有更深远的影响：“组织的衡量指标，如果跟代码不相干，我们预测软件会有85%的失败倾向。”
• 分布式团队开发对软件质量的影响实在是微不足道。

微软开发团队正在使用这些研究成果，其中包括帮助像Windows Vista SP2这样的项目进行风险分析和bug分类。

查看英文原文：Empirical Studies on Software Quality Mythology

译者 金明 是ThoughtWorks咨询师，SCJP，系统分析师。关注敏捷方法学，特别是敏捷实施和项目管理的实践。

1. 返回顶部

   少百分之六十到九十的bug会更慢？

   发表人 Lee Vincent

   TDD改善了质量，但时间更长：“研究小组发现：相对没有使用TDD的团队所产出的代码，使用TDD的团队所产出的代码在缺陷分布密度上要低百分之六十到九十。他们同时发现采用TDD的团队要多花费百分之十五到三十五的时间才能完结项目。”
   带着一堆bug完成项目能称其为"完成"了么? 还不是要多花几倍的时间来返工么？

   回复

2. 返回顶部

   Re: 少百分之六十到九十的bug会更慢？

   发表人 陆 超

   关键在于不是说软件必须没有bug了才能发布的...
   发布时间也很重要.

   回复

3. 返回顶部

   Re: 少百分之六十到九十的bug会更慢？

   发表人 wang egmkang

   没有Bug是不可能的.

   回复

4. 返回顶部

   TDD与发布时间并不具备必然相关性。

   发表人 Shi Liang

   与上线之后的补丁数相似，发布时间受到更多因素（特别是非技术因素）的影响。正如code coverage与补丁数目不具备相关性，我也看不出TDD与发布时间具备明显的相关性。
   
   温伯格说过，如果不需要正确执行，那么可以再任由短的时间内“完成”任意的功能（大意如此）。可见，必要的测试是发布的必要条件。

   回复

5. 返回顶部

   不完整，不详细，可参考

   发表人 刘 显珂

   我注意到他们采用的软件工程方法与过程是“通用的软件工程实践”，具体是怎样的？TDD在敏捷开发中结合其它实践才能发挥出更好的作用。
   “采用TDD的团队要多花费”与哪个团队做比较，大家做同样的项目，至少要来个对照组吧？
   我个人以为大家参考一下就行了。

   回复

6. 返回顶部

   Re: 少百分之六十到九十的bug会更慢？

   发表人 Jun Ran

   InfoQ的英文站点上，很多人也对此进行了质疑，你可以看下，基本结论是本文作者其实是断章取意了，导致很多误解；

   回复

7. 返回顶部

   Re: 少百分之六十到九十的bug会更慢？

   发表人 Lee Vincent

   InfoQ的英文站点上，很多人也对此进行了质疑，你可以看下，基本结论是本文作者其实是断章取意了，导致很多误解；

   
   引用一下：
   I wondered how TDD could report 60 to 90% fewer defects but still take 15 to 35% longer, since fewer defects means less rework. It didn't add up, logically.
   
   So I followed the links to the original paper and found my answer. The 15 - 35% is only the original development time, and does not include the increased maintenance cost of the non-TDD approach. To quote the paper:
   
   Another interesting observation from the outcome measures in Table 3 is the increase in time to develop the features attributed to the usage of the TDD practice, as subjectively estimated by management. The increase in development time ranges from 15% to 35%. From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM.

   回复

8. 返回顶部

   Re: 少百分之六十到九十的bug会更慢？

   发表人 峻申 吴

   文章有误~你说的是对的。测试的目的不是发现bug，而是尽可能多的发现bug。
   因此开发中质量标准可以理解为尽可能让测试人员少发现bug。
   而TDD是实现这个质量标准的利器。相比不使用TDD，而花费在解决bug上的时间，要比用TDD多出来的15%-35%时间多很多了。

   回复

• 更早的 >