前段时间集中阅读了几本测试相关的书籍，把其中和Review相关的东东整理出来，主要说的Code Review的一些具体的方法。有些书对不同方法的做了很严格的区分（至少名字很不一样^_^）。这一点我倒认为不必深究，实践的时候领略要点就OK。

　　一、静态白盒测试概述

　　首先区分软件测试的几个术语：“白盒测试”，“黑盒测试”，“静态测试”，“动态测试”。

　　白盒测试，也称为透明测试（clear-box testing）。白盒测试针对逻辑结构进行检查，它允许我们看到程序的内部结构。黑盒测试（black-box testing）是一种数据驱动的测试，这种测试方法将程序视为一个黑盒子，测试目标与程序的内部机制和结构无关，而是把重点集中在检查程序是否其规范（外部规格说明）一致。

　　静态测试是指测试项目中非计算机执行的部分，比如文档、代码等。静态测试的方法是检查和审核。动态测试是指通常意义上的测试——使用和运行软件。

　　在《软件测试的艺术（第二版）》一书中有人工测试（译者翻译为“人工测试”，英文表达为“non-computer testing”）的概念。其作者所述的“人工测试”，使用专业一些的术语就是“静态白盒测试”。静态白盒测试方法在查找错误方面非常有效，以至于每个编程项目都应使用其中的一种或多种。这些方法在程序开始编码之后、基于计算机的动态测试开始之前使用，

　　需要说明的是，我们的讨论主要针对“编码”进行，但事实上，静态白盒测试不仅可以应用在编码阶段，也可以在项目开发过程的更早阶段就开始设计和应用类似的方法（例如每个设计阶段的末尾），或针对项目文档而非代码进行静态白盒测试。

　　以下讨论几种主要的静态白盒测试方法：

　　◆ 代码检查（code inspection）

　　◆ 代码走查（code walkthrough）

　　◆ 桌面检查（desk checking）

　　二、静态白盒测试详述

　　并不是所有的软件测试人员都会阅读代码，但是业界已经广泛认同把研读程序代码作为测试工作的一部分。软件的规模和复杂度、软件开发团队的规模、软件开发的时限以及开发团队的技术背景和文化等等，这些因素都可能导致需要在特定的测试和调试工作中阅读代码。基于这些原因，我们需要深入的探讨一些被广泛使用的静态白盒测试方法。

　　对于静态白盒测试，最不幸的是它常常不能“善始善终 ”。项目小组往往认为它耗时太多、费用太高、没有产出。其实，问题在于人们一般认为程序员的任务是编写代码，而任何破坏代码编写效率的事情都会阻碍整个开发过程。另外，由于包含了人为因素，导致很多方法的正规性要差于计算机动态执行的数学证明，人们可能会怀疑某些如此简单和不正规的方法是否有用。

　　这些不正规的方法并没有妨碍测试取得成功，相反它们显著地提高了测试的功效和可靠性。首先，人们已经普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。其次，在开始动态测试后程序员似乎会经历一个心理上的转变，从内部产生的压力会急剧增长，并产生一个趋势：要“尽可能快地修正这个缺陷”。由于这些压力的存在，程序员在改正某个由动态测试发现的错误时所犯的失误要比改正早期发现的问题时所犯的失误更多一些。

　　1. 代码检查与走查

　　代码检查与走查是两种主要的检查代码的方法，这两种方法具有很多共同之处。代码检查与走查要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在会议上进行所谓“头脑风暴”。“头脑风暴”的目标是找出错误，而不必找出改正错误的方法。

　　在代码检查与走查中，一组开发人员（3-5人）对代码进行审核。参加者当中有一人是程序编写者。软件测试的主要工作是由其他人而不是编写者来完成的。这符合软件测试的一个重要原则：软件编写者往往不能有效测试自己编写的软件。

　　代码检查与走查的一个重要优点在于，一旦发现错误，通常就能够在代码中对其进行精确定位，从而降低了调试（错误修正）的成本。另外，这个过程通常可以发现成批的错误，这样错误就可以一同得到修正。而基于计算机执行的动态测试通常只能暴露出错误的某个表征，错误是逐个的被发现并得到修正的。

　　在典型的程序中，代码检查与走查通常可以有效查找出30%-70%的逻辑设计和编码错误（当然，这些方法不能有效地查找出高层次的设计错误，例如软件需求分析阶段的错误）。这里所谓的 30%-70%的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是说这些方法在测试过程结束时可以有效查找出多达70%的已知错误。请记住，程序中的错误总数始终是未知的。