BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

软件质量神话的经验研究

| 作者 Gavin Terrill 关注 1 他的粉丝 ,译者 金明 关注 0 他的粉丝 发布于 2009年10月14日. 估计阅读时间: 1 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

少百分之六十到九十的bug会更慢? by Lee Vincent

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

Re: 少百分之六十到九十的bug会更慢? by 陆 超

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

Re: 少百分之六十到九十的bug会更慢? by wang egmkang

没有Bug是不可能的.

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

与上线之后的补丁数相似,发布时间受到更多因素(特别是非技术因素)的影响。正如code coverage与补丁数目不具备相关性,我也看不出TDD与发布时间具备明显的相关性。

温伯格说过,如果不需要正确执行,那么可以再任由短的时间内“完成”任意的功能(大意如此)。可见,必要的测试是发布的必要条件。

不完整,不详细,可参考 by 刘 显珂

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

Re: 少百分之六十到九十的bug会更慢? by Jun Ran

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

Re: 少百分之六十到九十的bug会更慢? by 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.

Re: 少百分之六十到九十的bug会更慢? by 峻申 吴

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

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

8 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT