[笔记]3.软件代码中的BUG问题的一些记录

题记

你越了解你的对手——BUG，你的测试就越做的更好，软件质量就越可靠。

虽然很难将其他组织的经验数据应用到自己所在的组织，甚至有些数据和直觉相反，但你需要行动起来，借助一些方法，评估自己的情况，去改进。

 

BUG不是均匀分布

如果没有经过分析，自然的想法是BUG的分布会比较分散的，等概率的存在于整个系统。事实上经典的2-8原则这里依然有效：

20%的类/子程序中存在80%的BUG，换言之，20%的类/子程序占用了80%的开发成本;甚至有人统计出50%的BUG存在于5%的类中；

有资料说IBM对自己的OS/360操作系统的分析发现，只占少数的容易出问题的子程序每千行代码BUG高达50个，修复的代价是开发整个系统的成本的10倍(这个成本包括了客户支持和现场维护)

 因为复杂造成BUG集中的类/子程序，则需要设计时考虑降低复杂度，已经开发的应该考虑重构方案。

 

大多数BUG的影响范围是有限的

研究发现，85%的BUG可以在修改不超过一个类/子程序的范围内被修正。

 

大部分BUG都很容易修正

大约85的BUG可以在几个小时内修正；大约15%的BUG需要几个小时到几天；只有不到15的BUG需要更长的时间；

 

程序员错误理解设计引起的BUG的情况

有研究表明16%的BUG是这个原因造成的，另一个研究结果该原因带来了19%的BUG。因此花点时间彻底了解设计是很值得的。

 

软件设计编码之外最常见的三种BUG源头：

缺乏应用领域的知识；

频繁变动或者矛盾的需求；

沟通和协调的失效；

 

软件设计构件期的BUG源头分布情况是：

95%的BUG是程序开发人员造成的，系统软件造成的为2%，硬件原因为1%，其他软件为2%；

 

特别的，拼写错误是一个很常见的BUG源

不同类型的软件系统，拼写带来的BUG情况差别是比较大，从4%到36%不等。

想一想人类有史以来三个最昂贵的软件BUG——分别价值16亿、9亿和2.45亿美元，都是因为一个不正确的字符造成的。

我自己曾经因为把user拼写为uesr带来很大麻烦，昨天下午检查数据库数据时又无意中发现一个把organization拼写为organiztion的BUG。

 

业界经验，在已经发行的大多数软件中平均千行代码中有1-25个BUG。

微软的数据是内部测试千行代码有10-20个缺陷，已经发布的产品则下降为0.5。

国防和航天类系统则能达到每50万行0个BUG的水平。

有报告宣称使用TSP方式的开发小组，可以达到千行代码0.06个BUG的水平。

 

除开特殊类型的软件系统，一般情况下，开发高质量的软件，比开发低质量软件然后修正的成本要低。

 

不再调试上花时间？——这是一个很有价值，并值得努力的目标