本书可使你明白当对错误有深刻了解时，你能测试得很好。

哪一个程序含最多的错误
你可能很自然地想到错误均分在你的整个源代码中。如果你平均每 1000 行代码发现 10 错
误，你可假定平均第 100 行子程序你可发现一个错误。这确实是一个很自然的假设，但是它是
错误的。实际上，绝大多数错误往往倾向于集中在少数有缺陷的子程序中。以下是错误和代码
的一般联系：
· 80%的错误往往出现在 20%的子程序中（Endres 1975，Gremillion 1984，Boehm 1987）。
· 50%的错误往往出现在 10%的子程序中（Endres 1975，Gremillion 1984）。
在你认清必然之前，你也可能认为这种联系是并不重要的。
首先，20%的项目子程序占用了 80%的开发代价。但是，这并不意味着这花费最多的 20%
的子程序就是含最多错误的 20%的子程序。
其次，尽管高缺陷率子程序所耗代价比是一定的，它所耗代码是异常昂贵的。在 60 年代，
IBM 公司对 OS/360 操作系统进行研究时发现，所有错误并不是均分于整个子程序中而是集中
在少数子程序中。那些常带有错误的子程序是“程序开发中昂贵的实体”（Jones 1986）。在 1000
行代码中。这些子程序所含错误数可高达 50 个，修改这些错误常常是十倍于开发整个系统所需
的平均时间。
第三，开发代价高昂的子程序的含义也是显而易见的。正如一古老的名言所说一样，“时间
就是金钱”，其推论是“金钱就是时间”。如果你避开那些令人讨厌的子程序，就可将各种开支
削减 80%左右，同时将整个项目的工作量削减相当多。这是软件质量一般原则的鲜明表述，即
提高开发质量就能提高开发进度。
第四，避开令人生厌的子程序，对维护的含意也是清晰的。维护侧重于判断、重设计、重
写那些被认为是有错的子程序。 Gerald Weinberg 曾报道过一个允许维护程序员花费少量时间选
择和重写那些产生最多问题子程序的例子。在相当短的时间内，总错误比和维护量都减少了很
多。
错误排序
已有研究者试图按其类型将错误排序，并确定每种错误类型的范围。每位程序员都曾遇到
过令人生厌的错误：边界错误、忘记重新初始化循环变量等等。本书中的所有检查表提供了更
多的细节。
Baris Beizer 集成了几种研究数据，得出了一种不容置疑的详细错误排序方法。以下是其研
究结果的摘要：
25.18% 结构错误
22.44% 数据错误
16.19% 功能实现错误
9.88% 实现错误
8 98% 系统错误
8.12% 功能需求错误
2.76% 测试定义或执行
1.74% 系统、软件结构错误

4.71% 其它
Beizer 的研究结果为两位有效数字，但是对错误类型的研究通常并不是不可置疑的，目前
人们已经报道了许多类型的错误，研究错误的所得结果相差也很大。其结果差别可能为 50%而
不是一个百分点。不同的报道其结果相差大，像 Beizer 这样将各种研究结果集成起来所得出的
结论可能是没有什么意义的。但是即使所得结论不是无可置疑的，它还是有一定建设性意义的。
以下是由 Beizer 的研究所得出的一些推论：
大多数的错误的范围是相当有限的。某一项研究表明：不用修改多于一个的子程序，你就
可发现 85%的错误（Endres1975）。
许多错误并不是结构性错误。研究人员进行了 97 次采访发现三个最常见的错误源为：贫乏
的应用控制知识、需求的冲突和缺乏信息交流和协调( Curits , Krasner 和 Iscoe1988)。
大多数实现错误来自程序员。在所有错误中，有 95%的错误是由程序员本人引起的，2%的
错误由系统软件所引起，l%是由硬件引起(Brown 和 sampaon19733,Ostrand 和 Weyuker1984)。
书写错误是一个相当普遍的错误源。一项研究表明 36%的错误是书写错误（Weiss1975）。
在 1987 年对接近了百万行的动态飞行软件研究表明 18%的错误是书写错误（Card1989）.另一
研究表明：4%的错误是拼写错误（Endre1975）。在作者本人的一个程序中。一位同事发现几个
拼写错误只是由于通过一个拼写检查程序运行一个可执行文件所引起的。你应对细节计算有所
注意，如你对此有所怀疑，你应考虑三种最为昂贵的编程错误。Gerald Weinberg 报道这三种错
误的花费分别为 16 亿美元、9 亿美元、2.45 亿美元。以上每一花费都包括了对前一个修正程序
的任何修改。对设计的误解是许多程序常犯的错误。
Beizer 的研究发现 16.19%的错误是由于对设计的误解。而另一项研究则表明 19%的错误
是由于对设计的误解（1990）。花费时间对设计有一个深刻的理解是值得的。虽然这并不能产生
立竿见影的效果，但是在整个项目的生存周期中你将会得到回报的。
避免赋值语句的错误是质量的关键。一项研究表明 41%的错误来自赋值语句，它和绝大部
分错误是边界错误或循环错误是相矛盾的（Youngs1974），这项研究还同时表明：发现赋值语句
错误所花时间是发现其它错误所需时间的 3 倍（Gould1975），它指出了一个主要的盲区。在此
以前，我们似乎没有给予赋值错误以和边界错误相同的地位。但是花费时间考虑如何避免它们
是值得的。
大多数错误是容易改正的。大约 85%的错误在几个小时之内就可改好。而约 15%的错误修
改时间为几小时或几天不等，其余 1%的错误所需时间稍长一点。本结果也得到 Beizer 的约 20%
的错误需花费 80%的资源来改错的观点支持。通过回溯设计进行分析和设计评审可避免出现较
多的错误。
用错误数度量你所在组的经验。本节中所讨论的结果不同，说明了不同的人其实际经验是
相差悬殊的、这使你很难利用其它组的经验。一些结果跟通常的直觉是相矛盾的、你可能需要
用其它工具弥补你的直觉的不足。一个较好的方法是度量你的进度，这样你就能够知道问题之
所在。
错误创建所导致的出错比较
如果错误划分不明确，许多数据错误就可归于由不同的开发活动所引起的。其中，创建总会引起不少错误。有时，人们认为改正创建错误要比改正分析或结构错误省事些。改正单个创
建错误可能是省事一些，但这并不意味着定位全部创建错误的代价小。
· 在小规模项目中，实现错误占了整个错误相当大的一部分比例。在一次对一个小项目
(1000 行代码)的代码研究中，75%的错误来自编码，10%错误来自分析，15%的错误来
自设计（Jones1986a）。这种错误划分可视为许多小项目的错误分配。
·

[1] [2] 下一页