代码检查错误列表总结（第一部分）
- 数据引用错误和数据运算错误
| 数据引用错误 | 数据运算错误 | ||
|---|---|---|---|
| 是否有引用的变量未赋值或未初始化？ | 是否存在非算术变量间的运算？ | ||
| 下标的值是否在范围之内？ | 是否存在混合模式的运算？ | ||
| 是否存在非整数下标？ | 是否存在不同字长变量间的运算？ | ||
| 是否存在虚调用？ | 目标变量的大小是否小于赋值大小？ | ||
| 当使用别名时属性是否正确？ | 中间结果是否上溢或下溢？ | ||
| 记录和结构的属性是否匹配？ | 是否存在被0除？ | ||
| 是否计算位串的地址？是否传递位串参数？ | 是否存在二进制的不精确度？ | ||
| 基础的存储属性是否正确？ | 变量的值是否超过了有意义的范围？ | ||
| 跨过程的结构定义是否匹配？ | 操作符的优先顺序是否被正确理解？ | ||
| 索引或下标操作是否有“仅差一个”的错误？ | 整数除法是否正确？ |
| 11. 继承需求是否得到满足？ | | | |
- 数据声明错误和比较错误
| 数据声明错误 | 比较错误 | ||
|---|---|---|---|
| 是否所有的变量都已声明？ | 是否存在不同类型变量间的比较？ | ||
| 默认的属性是否被正确理解？ | 是否存在混合模式的比较运算？ | ||
| 数组和字符串的初始化是否正确？ | 比较运算符是否正确？ | ||
| 变量是否赋予了正确的长度、类型和存储类？ | 布尔表达式是否正确？ | ||
| 初始化是否与存储类相一致？ | 比较运算是否与布尔表达式相混合？ | ||
| 是否有相似的变量名？ | 是否存在二进制小数的比较？ | ||
| 操作符的优先顺序是否被正确理解？ | |||
| 编译器对布尔表达式的计算方式是否 被正确理解？ |
代码检查错误列表总结（第二部分）
- 控制流错误和输入/输出错误
| 控制流错误 | 输入/输出错误 | ||
|---|---|---|---|
| 是否超出了多条分支路径？ | 文件属性是否正确？ | ||
| 是否每个循环都终止了？ | OPEN语句是否正确？ | ||
| 是否每个程序都终止了？ | I/O语句是否符合格式规范？ | ||
| 是否存在由于入口条件不满足而跳过循环体？ | 缓冲大小与记录大小是否匹配？ | ||
| 可能的循环越界是否正确？ | 文件在使用前是否打开？ | ||
| 是否存在“仅差一个”的迭代错误？ | 文件在使用后是否关闭？ | ||
| DO/END语句是否匹配？ | 文件结束条件是否被正确处理？ | ||
| 是否存在不能穷尽的判断？ | 是否处理了I/O错误？ | ||
| 输出信息中是否有文字或语法错误？ |
- 接口错误和其他检查
| 接口错误 | 其他检查 | ||
|---|---|---|---|
| 形参的数量是否等于实参的数量？ | 在交叉引用列表中是否存在未引用过的变量？ | ||
| 形参的属性是否与实参的属性相匹配？ | 属性列表是否与预期的相一致？ | ||
| 形参的量纲是否与实参的量纲相匹配？ | 是否存在“警告”或“提示”信息？ | ||
| 传递给被调用模块的实参个数是否等于其形参个数？ | 是否对输入的合法性进行了检查？ |
代码走查
代码走查与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规 程和错误检查技术的集合。代码走查的过程与代码检查大体相同，但是规程稍微 有所不同，采用的错误检查技术也不一样。
就像代码检查一样，代码走查也是采用持续一至两个小时的不间断会议的形 式。代码走查小组由三至五人组成，其中一个人扮演类似代码检查过程中“协调 人”的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个人 担任测试人员。关于这三到五个人的组成结构，有各种各样的建议。当然，程序 员应该是其中之一。我们建议另外的参与者应该包括：
- 一位极富经验的程序员；
- 一位程序设计语言专家；
- 一位程序员新手（可以给出新颖、不带偏见的观点）；
- 最终维护程序的人员； • 一位来自其他不同项目的人员；
- 一位来自该软件编程小组的程序员。
开始的过程与代码检查相同：参与者在走查会议的前几天得到材料，这样可 以专心钻研程序。然而走查会议的规程则不相同。不同于仅阅读程序或使用错误 检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带 着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。在会议期间，每个测试用例都在人们脑中进行推演。也就是说，把测试数据沿程序的逻辑结构走一遍。程序的状态（如变量的值）记录在纸张或白板上 以供监视。
当然，这些测试用例必须结构简单、数量较少，因为人脑执行程序的速度比 计算机执行程序的速度慢上若干量级。因此，这些测试用例本身并不起到关键的 作用；相反，它们的作用是提供了启动代码走查和质疑程序员逻辑思路及其设想 的手段。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的， 而不是由测试用例本身直接发现的。
与代码检查相同，代码走查参与者所持的态度非常关键。提出的建议应针对 程序本身，而不应针对程序员。换句话说，软件中存在的错误不应被视为编写程 序的人员自身的弱点。相反，这些错误应被看做是伴随着软件开发的艰难性所固 有的。
与代码检查过程中描述的相似，代码走查应该有一个后续过程。同样，代码 检查所带来的附带作用（如可以发现易出错的程序区域，通过接触软件错误、编 程风格和方法来获得教育等）同样也会发生在代码走查过程中。
桌面检查
人工查找错误的第三种过程是古老的桌面检查方法。桌面检查可视为由单人 进行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程 序推演测试数据。
对于大多数人而言，桌面检查的效率是相当低的。其中的一个原因是，它是 一个完全没有约束的过程。另一个重要的原因是它违反了本书第2章提出的测试原 则，即人们一般不能有效地测试自己编写的程序。因此桌面检查最好由其他人而 非该程序的编写人员来完成（例如，两个程序员可以相互交换各自的程序，而不 是检查自己的程序）。但是即使这样，其效果仍然逊色于代码走查或代码检查。原 因在于代码检查和代码走查小组中存在着互相促进的效应。小组会议培养了良性 竞争的气氛，人们喜欢通过发现问题来展示自己的能力。而在桌面检查中，由于 没有向其他人展示的机会，也就缺乏这个显而易见的良好效应。简而言之，桌面 检查胜过没有检查，但其效果远远逊色于代码检查和代码走查。
同行评审
最后一种人工评审方法与程序测试并无关系（其目标不是为了发现错误），却仍在这里谈到，这是因为它与代码阅读的思想有关。
同行评审是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性 对匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。
选出一位程序员来担任这个评审过程的管理员，管理员又会挑选出6～20名参 与者（为保持匿名性，6人是最少数量）。这些参与者都应具备相似的背景（例如， 不能把Java应用程序员与汇编语言系统程序员编为一组）。要求每名参与者都挑选 出两个由自己编写的程序以供评审。其中的一个程序应是参与者自认为能代表其 自身能力的最好作品，而另一个则是参与者自认为质量较差的作品。
当所有的程序都收集完毕后，就将这些程序随机分发给参与者。每名参与者 拿到4个程序进行评审，其中的两个是“最好”的程序，另外两个则是相对“较差” 的程序，但评审人自己并不知道。每名参与者每评审一个程序得花费30分钟，评 审完后填写一张评价表。所有4个程序都评审完后，参与者对4个程序的相对质量 进行分级。评价表要求评审人用1～10的分值（1代表明确的“是” ，10代表明确的 “否”），对诸如下面的问题进行回答：
- 程序是否易于理解？
- 高层次的设计是否可见且合理？
- 低层次的设计是否可见且合理？
- 修改此程序对评审者而言是否容易？
- 评审者是否会以编写出该程序而骄傲？
评审人还应给出总的评价和建议的改进意见。 评审结束之后，参与者会收到自己的那两个程序的匿名评价表，此外还会收 到一个带统计的总结，说明在所有的程序中其程序的整体和具体得分情况，以及 他对其他程序的评价与其他评审人对同一程序打分的比较分析情况。同行评审的 目的是让程序员对自身的编程技术进行自我评价。同样，该过程也适用于企业开 发和课堂教学环境。