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