题记
你越了解你的对手——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的水平。
除开特殊类型的软件系统，一般情况下，开发高质量的软件，比开发低质量软件然后修正的成本要低。
不再调试上花时间？——这是一个很有价值，并值得努力的目标
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。