[笔记]3.软件代码中的BUG问题的一些记录
2006-05-18 08:50
633 查看
题记
你越了解你的对手——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的水平。
除开特殊类型的软件系统,一般情况下,开发高质量的软件,比开发低质量软件然后修正的成本要低。
不再调试上花时间?——这是一个很有价值,并值得努力的目标
你越了解你的对手——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的水平。
除开特殊类型的软件系统,一般情况下,开发高质量的软件,比开发低质量软件然后修正的成本要低。
不再调试上花时间?——这是一个很有价值,并值得努力的目标
相关文章推荐
- python笔记 <记录一些比较杂的问题>
- 看代码过程中碰到的一些问题以及笔记
- 代码设置输出缓存头的一些问题记录
- 驱动开发中碰到的一些问题笔记记录一下
- 一些问题关于代码大全,移山之道,快速软件开发
- 张孝祥老师交通灯管理系统的学习笔记 在做一件事时,首先要明确要达到什么效果。有目的性。就软件项目来说就是,首先要看的就是项目所提出的项目要求。做项目,不急于写代码,先把问题搞清楚,把要求分
- Qt 笔记(记录使用Qt中遇到的一些问题)
- MyGeneration学习笔记(3) : dOOdads及生成代码的一些bug
- 关于软件的使用中的一些小问题的记录汇总(长期更新)
- 记录软件开发中的一些软件配置等问题
- Android笔记--一些常用的不常用的小代码记录
- 怎样才能把一个代码变成软件成品?一个初学者的困惑,我们写的代码都只能是解决一些数学问题而已。怎么把它变成一个软件。
- 记录一些经常忘记的CSS代码(CSS bug/hack 收集贴)
- Java 基础一些代码练习笔记(ArrayList)
- 记录eclipse 外部导入的工程无法使用自己定义的代码风格问题
- redhat及deban系列linux软件管理的一些问题
- tcpdump抓包,然后使用tcpreplay进行回放,出现了一些问题,目前找不到答案,暂时先记录在这里
- BUG笔记:Win8 IE10下input[type="password"]内字符显示被截取问题
- 嵌入式软件开发问题及其解决办法记录
- 上班时候,老被腾讯弹出来的新闻打扰,很少烦恼,于是编写了一小程序,用于彻底解决这个问题,并代码开源,以防杀毒软件告诉你是病毒