在实践中人们发现，对于某些类型的错误，人工的静态测试方法比基于计算机的动态方法更有效，而对于其他类型的错误则相反。这意味着，代码检查与走查和基于计算机的动态测试是互补的，缺少任何一种，都会降低错误检查的效率。

　　在产品维护阶段，修改一个现存的程序可能比编写一个新程序更容易产生错误，因此除了回归测试之外，更改后的程序仍然需要进行这些人工方法的测试。

　　2. 代码检查

　　所谓代码检查，是以组为单位阅读代码，它是一系列规程和错误检查方法的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。这里对整个规程进行简短的描述。

　　一个代码检查小组通常由四人组成，其中一人发挥协调作用。协调人应该是个称职的程序员，但不是该程序的编码人员。他不需要对程序的细节了解的很清楚。协调人的职责包括一下几点：

　　◆ 为代码检查分发材料、安排进程。

　　◆ 在代码检查中起主导作用。

　　◆ 记录发现的所有错误。

　　◆ 确保错误随后得到改正。

　　协调人就像质量控制工程师。

　　小组中的第二个成员是该程序的编码人员。小组中的其他成员通常是程序的设计人员（如果设计人员不同于编码人员的话），以及一名测试专家。

　　在代码检查之前的几天，协调人将程序清单和设计规范分发给其他成员。小组中的其他成员应在检查之前熟悉这些材料。在进行检查时，主要进行两项活动。

　　1）由程序作者逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提出问题、判断是否存在错误。在讲述中，很可能是程序作者本人而非其他成员发现了大部分错误。换句话说，对着大家朗读程序，这种简单的做法看来是一个非常有效的错误检查方法。

　　2）对着历来常见的编码错误检查列表（在后面介绍）分析程序。

　　协调人负责确保检查会议的讨论高效地进行，每个参与者都将注意力集中于查找错误而不是修正错误（错误的修正由程序员在检查会议之后完成）。

　　会议结束之后，程序员会得到一份已发现错误的清单。如果发现的错误太多或者某个错误涉及对程序做根本的改动，协调人可能会在错误修正后安排对程序进行再次检查。这份错误清单也要进行分析、归纳，用以提取错误检查列表，以便提高以后代码检查的效率。

　　如上所述，这个代码检查过程通常将注意力集中在发现错误上，而不是修正错误。然而，有些小组可能会发现，当检查出某个小问题之后，小组中会有人建议对设计进行明显的修补以解决问题。这时小组的注意力被集中在设计的某个部分，在探讨修补设计来解决问题的最佳方法时，同时也对设计进行了完整的检查。

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

　　请注意，要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击而采取了防范的态度，那么检查过程就不会有效果。正确的做法是，程序员必须怀着非自我本位的态度来对待检查过程，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进软件质量。正因为如此，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。

　　除了发现错误这个主要作用之外，代码检查还有几个有益的附带作用。其一，程序员通常会得到编程风格、算法选择及编程技术等方面的反馈信息。其他参与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅。其二，代码检查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的动态测试过程中将更多的注意力集中在这些地方（有一条测试原则是这样子的：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比）。