评审是静态测试技术的重要组成部分，是对软件工作产品（包括代码）进行测试的一种方式，它应该在动态测试之前进行。评审通常是通过深入阅读和理解被检查文档来完成的。

　　评审包括管理评审、审查、技术评审、走查和非正式评审等不同的评审技术，具体的内容参见4.3节。根据IEEE Std 1028-2008的定义，评审的通用过程由以下六个阶段组成。

　　● 计划阶段：选择评审员，分配角色；为更加正式的评审类型（例如：审查）规定评审的入口准则和出口准则；选择需要进行评审的文档或文档章节等。

　　● 预备会阶段：分发文档，向评审参与者解释评审的目标、过程和文档；核对入口准则（针对更正式的评审类型）。

　　● 个人准备阶段：在评审会议之前，每位评审参与者准备各自的评审工作，标注评审对象中可能的缺陷、问题和建议。

　　● 评审会议阶段：讨论评审员提交的问题列表，并形成会议纪要（针对更正式的评审类型）。会议参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。

　　● 返工阶段：修复评审过程中发现的缺陷，通常由作者进行。

　　● 跟踪结果阶段：检查缺陷是否已解决，收集度量数据，并评估出口准则（针对更正式的评审类型）。

　　评审过程中需要不同角色人员的参与，他们在评审过程中的职责和作用是不一样的。评审中涉及的主要角色包括经理、主持人或组长、作者、评审员和记录员，其他可能牵涉的人员还包括决策者或者其他利益相关者、客户或者用户代表。另外一个可选的角色有时会出现在审查中，那就是宣读员，他在评审会议中给产品的某些部分进行宣读。

　　针对某个软件工作产品，可以采用多种评审类型，例如：首先进行技术评审，以决定在接下来的迭代开发中实现哪些功能；而对于其中所包含的具体功能，也许需要针对规格说明进行审查。

　　在软件开发生命周期早期，通过评审发现软件工作产品中的缺陷，其修复缺陷的成本会比在动态测试中才发现此类缺陷修复成本低得多（例如：由于需求不正确引起的缺陷）。评审的优点主要体现在以下五个方面。

　　1）提高质量

　　评审和动态测试都有共同的目标：发现缺陷，但它们在发现缺陷的方式和手段上有各自不同的优缺点。因此，在实际的测试过程中，需要将这两种手段结合起来，进行优势互补，从而更加有效地提高产品的质量。

　　评审相对于动态测试，可以比较容易实现较高的覆盖率。根据笔者在实际项目中的经验，评审可以发现产品中70%～80%的缺陷，而对于动态测试而言，发现的缺陷很难达到50%。图1是一个评审和动态测试集合的例子，显示了评审和动态测试相结合（假设评审和动态测试发现缺陷的有效性都是50%）是如何提高产品的质量的。

图1  评审的质量控制功能