软件测试：代码检查、走查与评审.doc

代码检查、走查与评审
多年以来，软件界的大多数人都持有一个想法，即编写程序仅仅是为了提供给 机器执行，并不是供人们阅读的，软件测试的惟一方法就是在计算机上执行它。20 世纪 70 年代早期，一些程序员最先意识到阅读代码对于构成完善的软件测试和调 试手段的价值，通过他们的努力，原有的观念开始发生变化。

今天，并不是所有的软件测试人员都要阅读代码，但是研读程序代码作为测试 工作的一部分，这个观念已经得到了广泛认同。以下几个因素会影响到特定的测试 和调试工作需要人工实际阅读代码的可能性：软件的规模和复杂度、软件开发团队 的规模、软件开发的时限（例如时间安排表是松散还是紧密）等，当然还有编程小 组的技术背景和文化。

基于这些原因，在深入研究较为传统的基于计算机的测试技术之前．我们首先 讨论非基于计算机测试的过程(即“人工测试”)。人工测试技术在查找错误方面非 常有效，以至于任何编程项目都应该使用其中的一种或多种技术。应该在程序开始 编码之后、基于计算机的测试开始之前使用这些方法。同样，也可以在编程过程的 更早阶段就开始设计和应用类似的方法（例如在每个设计阶段的末尾），但是这些 内容超出了本书讨论的范围。

在开始讨论人工测试技术之前，有一条重要的注意事项：由于包含了人为因素 在内，导致很多方法的正规性要差于由计算机执行的数学证明，人们可能会怀疑某 些如此简单和不正规的东西是否有用。反之亦然。这些不正规的方法并没有妨碍测 试取得成功；相反，它们从以下两个方面显著地提高了测试的功效和可靠性。

首先，人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误 的可能性也越大。其次，程序员在开始基于计算机的测试时似乎要经历一个心理上 的转变。从内部产生的压力似乎会急剧增长，并产生一个趋势，要“尽可能快地修 正这个缺陷”。由于这些压力的存在．程序员在改正某个由基于计算机测试发现的 错误时所犯的失误，要比改正早期发现的问题时所犯的失误更多一些。
3.1 检查与走查(Inspections And Walkthroughs)

代码检查与走查是两种主要的人工测试方法。由于这两种方法具有很多的共同 之处，在这里我们将一起讨论它们的相似点，而它们的不同之处将在后续章节中进 行介绍。

代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论 采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在参加者会议 上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来，但不必找出改 正错误的方法。换句话说，是测试，而不是调试。

代码检查与走查已经广泛运用了很长时间。我们认为，它们的成功与本文
第 2章所述的那些原则有关。 在代码走查中，一组开发人员（三至四人为最佳）对代码进行审核。参加者当中只有一人是程序编写者。因此软件测试的主要工作是由其他人，而不是软件编写者本人来完成．这符合“软件编写者往往不能有效地测试自己编写的软件”的测 试原则。

代码检查与走查是对过去桌面检查过程（在提交测试前由程序员阅读自己程序 的过程）的改进。与原方法相比，代码检查与走查更为有效，同样是因为在实施过 程中，除了软件编写者本人，还有其他人参与进来。

代码走查的另一个优点在于，一旦发现错误，通常就能在代码中对其进行精确 定位，这就降低了调试（错误修正）的成本。另外，这个过程通常发现成批的错误。 这样错误就可以一同得到修正。而基于计算机的测试通常只能暴露出错误的某个表 症（程序不能停止，或打印出一个无意义的结果），错误通常是逐个地被发现并得 到纠正的。

在典型的程序中，这些方法通常会有效地查找出 30％～70％的逻辑设计和编码 错误。但是，这些方法不能有效地查找出高层次的设计错误，例如在软件需求分析 阶段的错误。请注意，所谓 30％～70％的错误发现率，并不是说所有错误中多达70％可能会被找出来，而是讲这些方法在测试过程结束时可以有效地查找出多达 70％的已知错误。请记住，第 2 章告诉我们，程序中的错误总数始终是未知的。
当然，可能存在对这统计数字的批评，即人工方法只能发现“简单”的错误（即

与基于计算机的测试方法相比，所发现的问题显得微不足道），而困难的、不明显 的或微妙的错误只能用基于计算机的测试方法才能找到。然而，一些测试人员在使 用了人工方法之后发现，对于某些特定类型的错误，人工方法比基于计算机的方法 更有效，而对于其他错误类型，基于计算机的方法更有效。这就意味着，代码检查
/走查与基于计算机的测试是互补的。缺少其中任何一种，错误检查的效率都会降低。 最后，不但这些测试过程对于测试新开发的程序有着不可估量的作用，而且对
于测试更改后的程序，这些测试过程具有相同的作用，甚至更大。根据我们的经验，

修改一个现存的程序比编写一个新程序更容易产生错误(以每写一行代码的错误数 量计)。因此，除了回归测试方法之外，更改后的程序还要进行这些人工方法的测试。

3.2 代码检查(Code Inspections)

所谓代码检查是以组为单位阅读代码，它是一系列规程和错误检查技术的集 合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。这里对整个规程 进行简短的概述，之后我们将重点讨论实际的错误检查技术。

一个代码检查小组通常由四人组成，其中一人发挥着协调作用。协调人应该是 个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚。 协调人的职责包括以下几点：
• 为代码检查分发材料、安排进程。
• 在代码检查中起主导作用。
• 记录发现的所有错误。
• 确保所有错误随后得到改正。 协调人就像质量控制工程师。小组中的第二个成员是该程序的编码人员。小组中的其他成员通常是程序的设计人员（如果设计人员不同于编码人员的话），以及一名测试专家。 在代码检查之前的几天，协调人将程序清单和设计规范分发给其他成员。所有成员应在检查之前熟悉这些材料。在检查进行时，主要进行两项活动：

1. 由程序编码人员逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提问题、判断是否存在错误。在讲述中，很可能是程序编码

人员本人而不是其他小组成员发现了大部分错误。换句话说，对着大家大 声朗读程序，这种简单的做法看来是一个非常有效的错误检查方法。
2. 对着历来常见的编码错误列表分析程序（该列表将在下一节中介绍）。 协调人负责确保检查会议的讨论高效地进行、每个参与者都将注意力集中于查找错误而不是修正错误（错误的修正由程序员在检查会议之后完成）。
会议结束之后，程序员会得到一份已发现错误的清单。如果发现的错误太多， 或者某个错误涉及对程序做根本的改动，协调人可能会在错误修正后安排对程序进 行再次检查。这份错误清单也要进行分析，归纳，用以提炼错误列表，以便提高以 后代码检查的效率。

如上所述，这个代码检查过程通常将注意力集中在发现错误上，而不是纠正错 误。然而，有些小组可能会发现，当检查出某个小问题之后，有两三个人(包括负责 该代码的程序员本人)会建议对设计进行明显的修补以解决这个特例。那么，对这个 小问题的讨论，反过来会将整个小组的注意力集中在设计的某个部分。在探讨修补 设计来解决这个小问题的最佳方法时，有人可能会注意到另外的问题。既然小组已 经发现了设计中同一部分的两个相关问题，那么每隔几段代码就可能需要密集的注 释。几分钟之内，整个设计就被彻底检查完，任何问题都会一目了然。

在代码检查的时间及地点的选择上，应避免所有的外部干扰。代码检查会议的 理想时间应在 90～120 分钟之间。由于开会是一项繁重的脑力劳动，会议时间越长 效率越低。大多数的代码检查都是按每小时大约阅读 150 行代码的速度进行。因此， 对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个 或几个模块或子程序。

请注意，要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查 视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。正确的做 法是，程序员必须怀着非自我本位的态度来对待检查过程，对整个过程采取积极和 建设性的态度：代码检查的目标是发现程序中的错误，从而改进软件的质量。正因 为这个原因，大多数人建议应对代码检查的结果进行保密，仪限于参与者范围内部。
尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。
除了可以发现错误这个主要作用之外．代码检查还有几个有益的附带作用。其 一，程序员通常会得到编程风格、算法选择及编程技术等方面的反馈信息。其他参 与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅。还有，代码检 查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的测试过程 中将更多的注意力集中在这些地方（本文第 2 章中的测试原则之一）。

3.3 用于代码检查的错误列表

代码检查过程的一个重要部分就是对照一份错误列表，来检查程序是否存在常 见错误。遗憾的是，有些错误列表更多地注重编程风格而不是错误（例如，“注释

是否准确且有意义？”，“if-else 代码段和 do-while 代码段是否缩进对齐？”）， 错误检查太过模糊而实际上没有用（例如，“代码是否满足设计需求？”本节中 讨论的错误列表是经多年对软件错误的研究编辑而成的。该错误列表在很大程度上 是独立于编程语言的，也就是说，大多数的错误都可能出现在用任意语言编写的程 序中。读者可以把自己使用的编程语言中特有的错误，以及代码检查发现的错误补 充到这份错误列表中去。

3.3.1 数据引用错误

1. 是否有引用的变量未赋值或未初始化？这可能是最常见的编程错误，在各种 环境中都可能发生。在引用每个数据项（如变量、数组元素、结构中的域）时，应 试图非正式地“证明”该数据项在当前位置具有确定的值。

2. 对于所有的数组引用，是否每一个下标的值都在相应维规定的界限之内？

3. 对于所有的数组引用，是否每一个下标的值都是整数？虽然在某些语言中这 不是错误，但这样做是危险的。

4. 对于所有的通过指针或引用变量的引用，当前引用的内存单元是否分配？这 就是所谓的“虚调用（dangling reference）”错误。当指针的生命期大于所引用内存 单元的生命期时，错误就会发生。当指针引用了过程中的一个局部变量，而指针的值又被赋给一个输出参数或一个全局变量，过程返回（释放了引用的内存单元）结

束，而后程序试图使用指针的值时，这种错误就会发生。与前面检查错误的方法类 似，应试图非正式地“证明”，对于每个使用指针值的引用，引用的内存单元者都 存在。

5. 如果一个内存区域具有不同属性的别名，当通过别名进行引用时，内存区域 中的数据值是否具有正确的属性？在 FORTRAN 语言中对 EQUIVALENCE 语句使 用，或 COBOL 语言中对 REDEFINES 语句使用的地方，都可能发生这种错误。例 如，一个 FORTRAN 语言程序包含一个实型变量 A 和一个整型变量 B，两者都通过 使用 EQUIVALENCE 语句而成为同一内存区域的别名。如果程序先对 A 赋值，然后 又引用变量 B，由于机器可能会将内存中用浮点位表示的实数当作整数，在这种情 况下错误就可能发生。

6. 变量值的类型或属性是否与编译器所预期的一致？当 C、C++或 COBOL 程 序将某个记录读到内存中，并使用一个结构来引用它时，由于记录的物理表示与结 构定义存在差异，这种情况下错误就可能发生。

7. 在使用的计算机上，当内存分配的单元小于内存可寻址的单元大小时，是否 存在直接或间接的寻址错误？例如，在某些条件下，定长的位串不必以字节边界为 起点，但是地址又总是指向字节边界的。如果程序计算一个位串的地址，稍后又通 过该地址引用这个位串，可能会指向错误的内存位置。将一个位串参数传送给一个 子程序时，也可能发生这种情况。

8. 当使用指针或引用变量时，被引用的内存的属性是否与编译器所预期的一 致？这种错误的一个例子是，当一个指向某个数据结构的 C++指针被赋值为另外 的数据结构的地址。

9. 假如一个数据结构在多个过程或子程序中被引用，那么每个过程或子程序对 该结构的定义是否都相同。

10. 如果字符串有索引，当对数组进行索引操作或下标引用，字符串的边界取 值是否有“仅差一个(off-by-one)”的错误？

11. 对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？
3.3.2 数据声明错误

1. 是否所有的变量都进行了明确的声明？没有明确声明虽然不一定是错误，但 通常却是麻烦的源头。举例来说，如果一个程序的子程序接收一个数组参数，却未 将该参数定义为数组（如用 DIMENSION 语句），对该数组的引用（如 C=A(I)）会 被解释为一个函数调用，导致计算机试图将此数组当作程序执行。另外，如果某个 变量在一个内部过程或程序块中没有明确声明，是否可以理解为该变量在这个程序 块中被共用？

2. 如果变量所有的属性在声明中没有明确说明，那么默认的属性能否被正确理 解？举例来说，在 Java 语言中，程序接收到的默认属性往往是导致意外情况发生的 源头。

3. 如果变量在声明语句中被初始化，那么它的初始化是否正确？ 在很多语言 中，数组和字符串的初始化比较复杂，因此也成为容易出错的地方。

4. 是否每个变量都被赋予了正确的长度和数据类型？

5. 变量的初始化是否与其存储空间的类型一致？举例来说，如果 FORTRAN 语 言子程序中的一个变量在每次调用子程序时都需要重新初始化一次，那么必须使用 赋值语句对其初始化，而不应该用 DATA 语句。

6. 是否存在着相似名称的变量（如 VOLT 和 VOLTS）？这种情况不一定是错 误，但应被视为警告，这些名称可能会在程序中发生混淆。

3.3.3 运算错误

1. 是否存在不一致的数据类型（如非算术类型）的变量间的运算？

2. 是否有混合模式的运算？例如，将浮点变量与一个整型变量做加法运算。这 种情况并不一定是错误，但应该谨慎使用．确保程序语言的转换规则能够被正确理 解。看看下面的 Java 程序片段．显示了整数运算中可能发生的取整误差：
int x = 1; int y = 2; int z = 0; z = x/y;
System.out.println("z = " + z);

OUTPUT:
z = 0

3. 是否有相同数据类型不同字长变量间的运算？

4. 赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果？

5. 在表达式的运算中是否存在表达式向上或向下溢出的情况，也就是说，最终 的结果看起来是个有效值，但中间结果对于编程语言的数据类型可能过大或过小。

6. 除法运算中的除数是否可能为 0？

7. 如果计算机表达变量的基本方式是基于二进制的，那么运算结果是否不精 确？也就是说，在一个二进制计算机上，10×0.l 很少会等于 l.0。

8. 在特定场合，变量的值是否超出了有意义的范围？例如，对变量
PROBABILITY 赋值的语句可能需要进行检查，保证赋值始终为正且不大丁 1.0。

9. 对于包含一个以上操作符的表达式，赋值顺序和操作符的优先顺序是否正 确？

10. 整数的运算是否有使用不当的情况，尤其是除法？举例来说．如果 i 是一 个整型变量，表达式 2*i/2 == i 是否成立，取决于 i 是奇数还是偶数，或是先 运算乘法，还是先运算除法。

3.3.4 比较错误

1. 是否有不同数据类型的变量之间的比较运算，例如，将字符串与地址、日期 或数字相比较？

2. 是否有混合模式的比较运算，或不同长度的变量间的比较运算？如果有，应 确保程序能正确理解转换规则。

3. 比较运算符是否正确？程序员经常混淆“至多”、“至少”、“大于”、“不小于”、 “小于”和“等于”等比较关系。

4. 每个布尔表达式所叙述的内容是否都正确？在编写涉及“与”、“或”或“非”的表达式时，程序员经常犯错。

5. 布尔运算符的操作数是否是布尔类型的？比较运算符和布尔运算符是否错 误地混住了一起？这是一类经常会犯的错误。这里我们描述几个典型错误的例子。 如果想判断 i 是否在 2～10 之间，表达式 2x ||y 也是不正确 的，正确的应该是(i>x)||(i>y)。如果要比较三个数字是否相等，表达式 if(a==b==c)的实际意思却大相径庭。如果需要验证数学关系 x>y>z，正确的表 达式应该是(x>y)＆＆(y>z)。

6. 在二进制的计算机上，是否有用二进制表示的小数或浮点数的比较运算？由 于四舍五入，以及用二进制表示十进制数的近似度，这往往是错误的根源。

7. 对于那些包含一个以上布尔运算符的表达式，赋值顺序以及运算符的优先顺 序是否正确？也就是说，如果碰到如同(if((a==2)＆＆(b==2)||(c==3))的表 达式，程序能否正确理解是“与”运算在先还是“或”运算在先？

8. 编译器计算布尔表达式的方式是否会对程序产生影响？例如，语句 if((x==0 && (x/y)>z)对于有的编译器来说是可接受的，因为其认为一旦“与” 运算符的一侧为 FALSE 时，另一侧就不用计算；但是对于其他编译器来说，却可 能引起一个被 0 除的错误。

3.3.5 控制流程错误

1. 如果程序包含多条分支路径，比如有计算 GOTO 语句，索引变量的值是否 会大于可能的分支数量？例如，在语句

GOTO (200，300，400)，i

中，i 的取值是否总是 1、2 或 3？

2. 是否所有的循环最终都终止了？应设计一个非正式的证据或论据来证明每 一个循环都会终止。

3. 程序、模块或子程序是否最终都终止了？

4. 由于实际情况没有满足循环的入口条件，循环体是否有可能从未执行过？如果确实发生这种情况，这里是否是一处疏漏？例如，如果循环以下面的语句作为开

头．
for {i==x；i<=z；i++} {
...
}
while(NOTFOUND){
...
}
当 NOTFOUND 初始时就为假，或者 x 大于 z 时，情况会如何呢’

5. 如果循环同时由迭代变量和一个布尔条件所控制（如一个搜索循环），如果 循环越界（fall-through）了，后果会如何？例如，伪指令循环以
D0 I=1 to TABLESIZE WHILE (NOTFOUND)
开头，如果 NOTFOUND 永不为假，会发生什么结果呢？

6. 是否存在“仅差一个”的错误，如迭代数量恰恰多一次或少一次？这在从 0 开始的循环中是常见的错误。我们会经常忘记将“0”作为一次计数。举例来说， 如果想编写一段 Java 代码执行 10 次循环，下面的语句是错误的，因为它执行了 11 次：
for(int i=0;i<=10;i++){ System.out.println(i);
}

正确的应该是执行 10 次循环
for(int i=0;i<=9;i++) { System.out.println(i);
}

7. 如果编程语言中有语句组或代码块的概念（例如 do-while 或{...}），是 否每一组语句都有一个明确的 while 语句，并且 do 语句也与其相应的语句组对 应？或者，是否每一个左括号都对应有一个右括号？目前的大多数编译器都能识别 出这些不匹配的情况。

8. 是否存在不能穷尽的判断？举例来说，如果一个输入参数的预期值是 1，2 或 3，当参数值不为 l 或 2 时，在逻辑上是否假设了参数必定为 3？如果是这样的话， 这种假设是否有效？
3.3.6 接口错误

1. 被调用模块接收到的形参（parameter）数量是否等于调用模块发送的实参
（argument）数量？另外，顺序是否正确？

2. 实参的属性（如数据类型和大小）是否与相应形参的属性相匹配？

3. 实参的量纲是否与对应形参的量纲相匹配？举例来说，是否形参以度为单位 而实参以弧度为单位？

4. 此模块传递给被模块的实参数量，是否等于被模块期望的形参数量？

5. 此模块传递给彼模块的实参的属性，是否与彼模块相应形参的属性相匹配？

6. 此模块传递给彼模块的实参的量纲，是否与彼模块相应形参的量纲相匹配？

7. 如果调用了内置函数，实参的数量，属性，顺序是否正确？

8. 如果某个模块或类有多个入口点，是否引用了与当前入口点无关的形参？下 面 PL/1 程序的第二个赋值语句就存在这种错误
A: PROCEDURE(W,X); W=X+1;
RETURN
B: ENTRY(Y,Z); Y=X+Z;
END;

9. 是否有子程序改变了某个原本仅为输入值的形参？

10. 如果存在全局变量．在所有引用它们的模块中，它们的定义和属性是否相 同？

11. 常数是否以实参形式传递过？在一些用 FORTRAN 语言编写的程序中，诸如

CALL SUBX(J, 3)

的语句是很危险的，因为如果子程序 SUBX 对其第二个形参进行赋值，常数 3的值将会被改变。
3.3.7 输入/输出错误

1. 如果对文件明确声明过，其属性是否正确？

2. 打开文件的语句中各项属性的设置是否正确？

3. 格式规范是否与 I/O 语句中的信息相吻合？举例来说，在 FORTRAN 语言中， 是否每个 FORMAT 语句都与相应的 READ 或 WRITE 语句相一致(就各项的数量和属 性而言)？

4. 是否有足够的可用内存空间，来保留程序将读取的文件？

5. 是否所有的文件在使用之前都打开？

6. 是否所有的文件在使用之后都关闭了？

7. 是否判断文件结束的条件，并正确处理？

8. 对 I/O 出错情况处理是否正确？

9. 任何打印或显示的文本信息中是否存在拼写或语法错误？

3.3.8 其他检查

1. 如果编译器建立了一个标识符交叉引用列表，那么对该列表进行检查，查看 是否有变量从未引用过，或仅被引用过一次。

2. 如果编译器建立了一个属性列表，那么对每个变量的属性进行检查，确保没 有赋予过不希望的默认属性值。

3. 如果程序编译通过了，但计算机提供了一个或多个“警告”或“提示”信息， 应对此逐一进行认真检查。“警告”信息指出编译器对程序某些操作的正确性有所 怀疑，所有这些疑问都应进行检查。“提示”信息可能会罗列山没有声明的变量， 或者是不利于代码优化的用法。

3. 程序或模块是否具有足够的鲁棒性？也就是说，它是否对其输入的合法性进 行了检查？
5. 程序是否遗漏了某个功能？
这些检查列表在表 3-l 和表 3-2 中进行了总结。 表 3-1 代码检查错误列表总结第一部分

数据引用错误
运算错误
1.是否有引用的变量未赋值或未初始化？
1.是否存在非算术变量间的运算？
2.下标的值是否在范围之内？
2.是否存在混合摸式的运算？
3.是否存在非整数下标？
3.是否存在不同字长变量问的运算？
4.是否存在虚调用？
4.目标变量的大小是否小于赋值大小？
5.当使用别名时属性是否正确？
5.中间结果是否上溢或下溢？
6.记录和结构的属性是否匹配？
6.是否存住被 0 除？
7. 是否计算位串的地址？是否传递位串参
数？
7.是否存在二进制的不精确度？
8.基础的存储属性是否正确？
8.变量的值是否超过了有意义的范围？
9.跨过程的结构定义是否匹配？
9.操作符的优先顺序是否被正确理解？
10.索引或下标操作是否有“仅差一个”的错
误？
10.整数除法是否正确？
11.继承需求是否得到满足？

数据声明错误
比较错误
1.是否所有的变量都已声明？
1.是否存在不同类型变量间的比较？
2.默认的属性是否被正确理解？
2.是否存在混合模式的比较运算？
3.数组和字符串的初始化是否正确？
3.比较运算符是否正确？
4.变量是否赋予了正确的长度，类型和存储
类？
4.布尔表达式是否正确？
5.初始化是否与存储类相一致？
5.比较运算是是否与布尔表达式相混合？
6.是否有相似的变量名？
6.是否存在二进制小数的比较？

7.操作符的优先顺序是否被正确理解？

8.编译器对布尔表达武的计算方式是否被正
确理解？

表 3-2 代码检查错误列表总结第二部分

控制流程错误
输入/输出错误
1.是否超出了多条分支路径？
1.文件的属性是否正确？
2.是否每个循环都终止了？
2.0PEN 语句是否正确？
3.是否每个程序都终止了？
3.I/O 语句是否符合格式规范？
4.是否存在由于入口条件不满足而跳过循环
体？
4.缓冲大小与记录大小是否匹配？
5.可能的循环越界是否正确？
5.文件在使用前是否打开？
6.是否存在“仅差一个”的迭代错误？
6.文件在使用后是否关闭？
7.DO/END 语句是否匹配？
7.文件结束条件是否被正确处理？
8.是否存在不能穷尽的判断？
8.是否处理了 I/O 错误？
9.输出信息中是否有文字或语法错误？

接口错误
其他检查
1.形参的数量是否等于实参的数量？
1.在交叉引用列表中是否存在未引用过的变
量？
2.形参的量纲是否与实参的量纲相匹配？
2.属性列表是否与预期的相一致？
3.形参的量纲是否与实参的量纲相匹配？
3.是否存在“警告”或“提示”信息？
4.传递给被调用模块的实参个数是否等于其
形参个数？
4.是否对输入的合法性进行了检查？
5.传递给被调用模块的实参属性是否与其形
参属性匹配？
5.是否遗漏了某个功能？
6.传递给被调用模块的实参量纲是否与其形
参量纲匹配？

7.调用内部函数的实参的数量、属性，顺序是
否正确？

8.是否引用了与当前入口点无关的形参？

9.是否改变了某个原本仅为输入值的形参？

10.全局变量的定义在模块间是否一致？

11.常数是否以实参形式传递过？

3.4 代码走查(Walkthroughs)

代码走查与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规程 和错误检查技术的集合。代码走查的过程与代码检查大体相同，但是规程稍微有所 不同，采用的错误检查技术也不一样。

就像代码检查一样，代码走查也是采用持续一至两个小时的小间断会议的形 式。代码走查小组由三至五人组成，其中一个人扮演类似代码检查过程中“协调人” 的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个人担任测 试人员。关于这二到五个人的组成结构，有各种各样的建议。当然，程序员应该是 其中之一。我们建议另外的参与者应该包括：(1)一位极富经验的程序员；(2)一位程 序设计语言专家；(3)一位程序员新手（可以给出新颖，不带偏见的观点），(4)最终 将维护程序的人员；(5)一位来自其他不同项目的人员；(6)一位来自该软件编程小组 的程序员.
开始的过程与代码检查相同：参与者在走查会议之前的几天得到材料，他们可

以专心钻研程序。然而走查会议的程则不相同。不同于仅阅读程序或使用错误检查 列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一 些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。 在会议期间，每个测试用例都在人们脑中进行推演。也就是说，把测试数据沿程序 的逻辑结构走一遍。程序的状态（如变量的值）记录在纸张或白板上以供监视。

当然，这些测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计 算机执行程序的速度慢上若干量级。因此，这些测试试用例本身并不起到关键的作 用；相反，它们的作用是提供了启动代码走查和质疑程序员逻辑思路及其设想的手 段。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是 由测试用例本身直接发现的。

与代码检查相同，代码走查参与者所持的态度非常关键。提出的建议应针对程 序本身，而不应针对程序员。换句话说，软件中存在的错误不应被视为编写程序的 人员自身的弱点。相反，这些错误应被看作是伴随着软件开发的艰难性所固有的。

与代码检查过程中描述的相似，代码走查应该有一个后续过程。同样，代码检 查所带来的附带作用（如可以发现易出错的程序区域，通过接触软件错误、编程风 格和方法来获得教育等）同样也会发生在代码走查过程中。

3.5 桌面检查(Desk Checking)

人工查找错误的第二种过程是古老的桌面检查方法。桌面检查可视为由单人进 行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推 演测试数据。

对于大多数人而言，桌面检查的效率是相当低的。其中的一个原因是，它是一 个完全没有约束的过程。另一个重要的原因是它违反了本书第 2 章提出的测试原则， 即人们一般不能有效地测试自己编写的程序。因此桌面检查最好由其他人而非该程 序的编写人员来完成（例如，两个程序员可以相互交换各自的程序，而不是桌面检 查自己的程序）。但是即使这样，其效果仍然逊色于代码走查或代码检查。原因在 于代码检查和代码走查小组中存在着互相促进的效应。小组会议培养了良性竞争的气氛，人们喜欢通过发现问题来展示自己的能力。而在桌面检查中，由于没有其他人可供展示，也就缺乏这个显而易见的良好效应。简而言之，桌面检查胜过没有检 查，但其效果远远逊色于代码检查和代码走查。

3.6 同行评分(Peer Ratings)

最后一种人工评审方法与程序测试并无关系（其目标不是为了发现错误），却 仍在这里谈到，这是因为它与代码阅读的思想有关。

同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对 匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。

选出一位程序员来担任这个评分过程的管理员，管理员又会挑选出大约 6～20 名参与者（保持匿名性，6 人是最少数量）这些参与者都应具备相似的背景（如， 不能把 Java 应用程序员与汇编语言系统程序员编为一组）要求每名参与者都挑选出 两个由自己编写的程序以供评审。其中的一个程序应是参与者自认为能代表其自身 能力的最好作品，而另一个则是参与者自认为质量较差的作品。

当所有的程序都收集完毕后，就将这些程序随机分发给参与者。每名参与者拿 到 4 个程序进行评审，其中的两个是“最好”的程序，另外两个则是相对“较差” 的程序，但评审人自己并不知道。每名参与者每评审一个程序得花费 30 分钟，评 审完后填写一张评价表。所有 4 个程序都评审完后，参与者对 4 个程序的相对质量 进行分级。评价表要求评审人用从 1～7 的分值（代表明确的“是”，7 代表明确的 “否”）对诸如下面的问题进行回答：
• 程序是否易于理解？
• 高层次的设计是否可见且合理？
• 低层次的设计是否可见且合理？
• 修改此程序对评审者而言是否容易？
• 评审者是否会以编写出该程序而骄傲？ 还要要求评审人给出总的评价和建议的改进意见。 评审结束之后，参与者会收到自己的那两个程序的匿名评价表，此外还会收到一个带统计的总结，说明在所有的程序中其程序的整体和具体得分情况，以及他对其他程序的评价与其他评审人对同一程序打分的比较分析情况。同行评分的目的，是让程序员对自身的编程技术进行自我评价。同样，该过程适用于企业开发和课堂 教学环境。

3.7 小结

本章讨论了软件开发人员通常不会考虑到的一种测试形式——人工测试。大多 数人都以为，因为程序是为了供机器执行而编写的，那么也该由机器来对程序进行 测试。这种想法是有问题的。人工测试方法在暴露错误方面是很有成效的。实际上， 大多数的软件项目都应使用到以下的人工测试方法：
• 利用错误列表进行代码检查。
• 小组代码走查。
• 桌面检查。
• 同行评审。