前段时间集中阅读了几本测试相关的书籍，把其中和Review相关的东东整理出来，主要说的Code Review的一些具体的方法。有些书对不同方法的做了很严格的区分（至少名字很不一样^_^）。这一点我倒认为不必深究，实践的时候领略要点就OK。
一、 静态白盒测试概述
首先区分软件测试的几个术语：“白盒测试”，“黑盒测试”，“静态测试”，“动态测试”。
白盒测试，也称为透明测试(clear-box testing)。白盒测试针对逻辑结构进行检查，它允许我们看到程序的内部结构。黑盒测试(black-box testing)是一种数据驱动的测试，这种测试方法将程序视为一个黑盒子，测试目标与程序的内部机制和结构无关，而是把重点集中在检查程序是否其规范（外部规格说明）一致。
静态测试是指测试项目中非计算机执行的部分，比如文档、代码等。静态测试的方法是检查和审核。动态测试是指通常意义上的测试——使用和运行软件。
在《软件测试的艺术（第二版）》一书中有人工测试（译者翻译为“人工测试”，英文表达为“non-computer testing”）的概念。其作者所述的“人工测试”，使用专业一些的术语就是“静态白盒测试”。静态白盒测试方法在查找错误方面非常有效，以至于每个编程项目都应使用其中的一种或多种。这些方法在程序开始编码之后、基于计算机的动态测试开始之前使用，
需要说明的是，我们的讨论主要针对“编码”进行，但事实上，静态白盒测试不仅可以应用在编码阶段，也可以在项目开发过程的更早阶段就开始设计和应用类似的方法（例如每个设计阶段的末尾），或针对项目文档而非代码进行静态白盒测试。
以下讨论几种主要的静态白盒测试方法：
Ø 代码检查（code inspection）
Ø 代码走查（code walkthrough）
Ø 桌面检查（desk checking）
rel="File-List" href="file:///C:%5CUsers%5CBaib%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"> rel="themeData" href="file:///C:%5CUsers%5CBaib%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> rel="colorSchemeMapping" href="file:///C:%5CUsers%5CBaib%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">二、 静态白盒测试详述
并不是所有的软件测试人员都会阅读代码，但是业界已经广泛认同把研读程序代码作为测试工作的一部分。软件的规模和复杂度、软件开发团队的规模、软件开发的时限以及开发团队的技术背景和文化等等，这些因素都可能导致需要在特定的测试和调试工作中阅读代码。基于这些原因，我们需要深入的探讨一些被广泛使用的静态白盒测试方法。
对于静态白盒测试，最不幸的是它常常不能“善始善终”。项目小组往往认为它耗时太多、费用太高、没有产出。其实，问题在于人们一般认为程序员的任务是编写代码，而任何破坏代码编写效率的事情都会阻碍整个开发过程。另外，由于包含了人为因素，导致很多方法的正规性要差于计算机动态执行的数学证明，人们可能会怀疑某些如此简单和不正规的方法是否有用。
这些不正规的方法并没有妨碍测试取得成功，相反它们显著地提高了测试的功效和可靠性。首先，人们已经普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。其次，在开始动态测试后程序员似乎会经历一个心理上的转变，从内部产生的压力会急剧增长，并产生一个趋势：要“尽可能快地修正这个缺陷”。由于这些压力的存在，程序员在改正某个由动态测试发现的错误时所犯的失误要比改正早期发现的问题时所犯的失误更多一些。
代码检查与走查是两种主要的检查代码的方法，这两种方法具有很多共同之处。代码检查与走查要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在会议上进行所谓“头脑风暴”。“头脑风暴”的目标是找出错误，而不必找出改正错误的方法。
在代码检查与走查中，一组开发人员（3-5人）对代码进行审核。参加者当中有一人是程序编写者。软件测试的主要工作是由其他人而不是编写者来完成的。这符合软件测试的一个重要原则：软件编写者往往不能有效测试自己编写的软件。
代码检查与走查的一个重要优点在于，一旦发现错误，通常就能够在代码中对其进行精确定位，从而降低了调试（错误修正）的成本。另外，这个过程通常可以发现成批的错误，这样错误就可以一同得到修正。而基于计算机执行的动态测试通常只能暴露出错误的某个表征，错误是逐个的被发现并得到修正的。
在典型的程序中，代码检查与走查通常可以有效查找出30%-70%的逻辑设计和编码错误（当然，这些方法不能有效地查找出高层次的设计错误，例如软件需求分析阶段的错误）。这里所谓的30%-70%的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是说这些方法在测试过程结束时可以有效查找出多达70%的已知错误。请记住，程序中的错误总数始终是未知的。
在实践中人们发现，对于某些类型的错误，人工的静态测试方法比基于计算机的动态方法更有效，而对于其他类型的错误则相反。这意味着，代码检查与走查和基于计算机的动态测试是互补的，缺少任何一种，都会降低错误检查的效率。
在产品维护阶段，修改一个现存的程序可能比编写一个新程序更容易产生错误，因此除了回归测试之外，更改后的程序仍然需要进行这些人工方法的测试。
所谓代码检查，是以组为单位阅读代码，它是一系列规程和错误检查方法的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。这里对整个规程进行简短的描述。
一个代码检查小组通常由四人组成，其中一人发挥协调作用。协调人应该是个称职的程序员，但不是该程序的编码人员。他不需要对程序的细节了解的很清楚。协调人的职责包括一下几点：
Ø 为代码检查分发材料、安排进程。
Ø 在代码检查中起主导作用。
Ø 记录发现的所有错误。
Ø 确保错误随后得到改正。
协调人就像质量控制工程师。
小组中的第二个成员是该程序的编码人员。小组中的其他成员通常是程序的设计人员（如果设计人员不同于编码人员的话），以及一名测试专家。
在代码检查之前的几天，协调人将程序清单和设计规范分发给其他成员。小组中的其他成员应在检查之前熟悉这些材料。在进行检查时，主要进行两项活动。
1) 由程序作者逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提出问题、判断是否存在错误。在讲述中，很可能是程序作者本人而非其他成员发现了大部分错误。换句话说，对着大家朗读程序，这种简单的做法看来是一个非常有效的错误检查方法。
2) 对着历来常见的编码错误检查列表（在后面介绍）分析程序。
协调人负责确保检查会议的讨论高效地进行，每个参与者都将注意力集中于查找错误而不是修正错误（错误的修正由程序员在检查会议之后完成）。
会议结束之后，程序员会得到一份已发现错误的清单。如果发现的错误太多或者某个错误涉及对程序做根本的改动，协调人可能会在错误修正后安排对程序进行再次检查。这份错误清单也要进行分析、归纳，用以提取错误检查列表，以便提高以后代码检查的效率。
如上所述，这个代码检查过程通常将注意力集中在发现错误上，而不是修正错误。然而，有些小组可能会发现，当检查出某个小问题之后，小组中会有人建议对设计进行明显的修补以解决问题。这时小组的注意力被集中在设计的某个部分，在探讨修补设计来解决问题的最佳方法时，同时也对设计进行了完整的检查。
在代码检查的时间及地点的选择上，应避免所有的外部干扰。代码检查会议的理想时间应在90-120分钟之间。由于开会是一项繁重的脑力劳动，会议时间越长效率越低。大多数的代码检查都是按照每小时阅读150行代码的速度进行。因此，对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序。
请注意，要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击而采取了防范的态度，那么检查过程就不会有效果。正确的做法是，程序员必须怀着非自我本位的态度来对待检查过程，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进软件质量。正因为如此，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。
除了发现错误这个主要作用之外，代码检查还有几个有益的附带作用。其一，程序员通常会得到编程风格、算法选择及编程技术等方面的反馈信息。其他参与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅。其二，代码检查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的动态测试过程中将更多的注意力集中在这些地方（有一条测试原则是这样子的：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比）。
代码检查过程的一个重要部分就是对照一份错误检查列表来检查程序是否存在常见错误。遗憾的是，有些错误检查列表更多的注重编程风格而不是错误（例如：“注释是否准确且有意义？”）或者检查太过模糊而实际上没有用（例如：“代码是否满足设计需求？”）。这些都是在制定错误检查列表时应当注意的问题。根据自己使用的编程语言等环境中特有的错误以及代码检查中发现的错误，我们需要对已有的错误检查列表进行调整。
错误检查列表的示例请参见附录。
代码走查与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规程和错误检查方法的集合。代码走查的过程与代码检查大体相同，但是规程稍微有所不同，采用的错误检查方法也不一样。
就像代码检查一样，代码走查也是采用持续1-2小时的不间断会议的形式。代码走查小组由3-5人组成，其中一人扮演协调人的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个担任测试人员。关于这3-5人的组成结构，有各种各样的建议。当然，程序作者应该是其中之一。建议其他的参与者应该包括：
Ø 一位极富经验的程序员。
Ø 一位程序设计语言专家。
Ø 一位程序员新手（可以给出新颖、不带偏见的观点）。
Ø 最终将维护程序的人员。
Ø 一位来自其他不同项目组的人员。
Ø 一位来自该软件编程小组的程序员。
开始的过程与代码检查相同：参与者在走查会议的前几天得到材料，他们可以专心钻研程序。然而走查会议的规程则不同。不同于仅阅读程序或使用错误检查列表的代码检查，代码走查的参与者使用了计算机来执行代码。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。在会议期间，每个测试用例都在人们脑中进行推演。也就是说，把测试数据沿程序的逻辑结构走一遍。程序的状态记录在纸或白板上以供监视。
当然，这些测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢若干数量级。因此这些测试用例本身并不起到关键作用。它们的作用是提供了启动代码走查和质疑程序员逻辑思路及其他设想的手段。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
与代码检查相同，代码走查参与者所持的态度非常关键。提出的建议应针对程序本身，而不应针对程序员。换句话说，软件中存在的错误不应被视为程序作者自身的弱点。这些错误应被看作是软件开发的艰难性所固有的。
与代码检查一样，代码走查应该有一个针对错误修正的后续跟踪过程。代码检查的有益附带作用也同样对代码走查有效。
桌面检查方法是一种古老的人工查找错误的方法。桌面检查可视为由单人进行的代码检查或代码走查：由一个人阅读程序，对照错误检查列表检查程序，对程序推演测试用例数据。
对于大多数人而言，桌面检查的效率是比较低的。其中一个原因是：它是一个完全没有约束的过程。由于人们一般不能有效地测试自己编写的程序（软件测试的重要原则之一），因此桌面检查最好由其他人而非该程序作者来完成（例如，两个程序员可以相互交换各自的程序来进行检查）。即使这样，桌面检查的效果仍然逊色于代码检查和走查。代码检查和走查的小组中存在互相促进的效应，小组会议培养了良性竞争的气氛，人们喜欢通过发现问题来展示自己的能力。而在桌面检查中，由于没有其他人，也就缺乏这个显而易见的良好效应。简而言之，桌面检查胜过没有检查，但其效果逊色于代码检查和走查。
3840
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
