3. 用于代码检查的错误检查列表

　　代码检查过程的一个重要部分就是对照一份错误检查列表来检查程序是否存在常见错误。遗憾的是，有些错误检查列表更多的注重编程风格而不是错误（例如：“注释是否准确且有意义？”）或者检查太过模糊而实际上没有用（例如：“代码是否满足设计需求？”）。这些都是在制定错误检查列表时应当注意的问题。根据自己使用的编程语言等环境中特有的错误以及代码检查中发现的错误，我们需要对已有的错误检查列表进行调整。

　　4. 代码走查

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

　　就像代码检查一样，代码走查也是采用持续1-2小时的不间断会议的形式。代码走查小组由3-5人组成，其中一人扮演协调人的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个担任测试人员。关于这3-5人的组成结构，有各种各样的建议。当然，程序作者应该是其中之一。建议其他的参与者应该包括：

　　◆ 一位极富经验的程序员。

　　◆ 一位程序设计语言专家。

　　◆ 一位程序员新手（可以给出新颖、不带偏见的观点）。

　　◆ 最终将维护程序的人员。

　　◆ 一位来自其他不同项目组的人员。

　　◆ 一位来自该软件编程小组的程序员。

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

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

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

　　与代码检查一样，代码走查应该有一个针对错误修正的后续跟踪过程。代码检查的有益附带作用也同样对代码走查有效。

　　5. 桌面检查

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

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

　　三、在项目中应用 静态白盒测试

　　再次说明一下，之所以需要在项目中使用这些静态白盒测试方法是基于这样的原则：错误发现得越早，改正错误的成本越低，正确改正错误的可能性越大，改正错误时可能引发的其他错误的数量也越少。

　　项目里负责执行静态白盒测试的角色并不固定。在某些项目中，程序员是组织和执行的人，软件测试员被邀请作为独立的观察者。而另外一些项目中，软件测试员是该任务的执行人，编写代码的程序员和其他同时协助测试。项目组可以选择两者之一，这取决于哪种更适合项目的情况。

　　和很多事情一样，如果决定在项目中实行一些静态白盒测试活动，那么首先需要考虑的就是“目的”、“目标”、“策略”等等。假定在项目A中，我们决定采用桌面检查和代码检查来保障代码质量和产品年质量。我们可以想到如下的应用方案。