题记

　　你越了解你的对手——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的水平。

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

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