1.3 小结

评审是由项目利益相关者共同检查软件产品，并在评审会议上进行相应讨论，最后以会议纪要的形式记录结果。基本的评审过程由计划阶段、预备会阶段、个人准备阶段、评审会议阶段、返工阶段和跟踪结果阶段组成。参与评审的主要角色包括经理、主持人、作者、评审员和记录员等。有时其他项目利益相关者也会参与其中，如用户或者客户代表。

评审有多种类型，其特点如下。

（1）走查可以是一种非正式的评审过程。作者在会议中将文档演示给评审人员，评审参与者几乎没有为评审会议做任何准备。走查特别适用于小型开发团队、问题讨论和人员培训。

（2）审查是正式的评审过程。通过检查表来做一些准备工作，有明确的入口和出口准则。评审会议由经过培训的主持人来主持，并且收集的数据可以用来改善开发和审查过程。

（3）对于技术评审，每个人的评审结果需要在会议之前提交给评审主持人。会议根据每个问题的重要性进行优先级排序。作者一般不参与评审会，相应的评审检查只是通过文档进行。

（4）非正式评审不基于正式的过程，并不要求必须以何种方式产生结果。这种类型的评审可以通过较少的工作量完成，而且通过率很高，所以这种评审会经常使用。

使用什么样的评审技术由特定的环境决定，即采用评审的具体的组织和项目。可以通过评审过程相应的裁剪以满足具体的需要，从而提高评审的效率。在软件开发团队中建立合作和协商的气氛，对于成功开展评审活动非常重要。

除了评审，静态分析也是静态测试技术中一个重要手段。静态分析不需要运行测试对象，而是借助工具检查测试对象。静态分析工具能够分析程序代码（如控制流和数据流），同时产生HTML和XML等格式的输出。与评审一样，静态分析的目的是发现文档或者代码中的缺陷或者可能存在的缺陷隐患；不同的是静态分析一般通过工具的支持来实现。例如，拼写检查工具可以认为是静态分析的一种形式，它可以发现文档中的拼写错误，从而有利于提高文档质量。静态分析的另外一个目的是得到度量数据，从而评估测试对象的质量和复杂度。

在使用工具分析和检查文档时，被分析的文档必须以特定的结构和标准来组织。静态分析只有在工具的支持下才有意义。正式的文档可以是代码、技术需求、软件架构或者软件设计等。例如，UML中的类型图模型。以HTML和XML格式产生的输出文档可以通过工具支持进行静态分析，还可以分析设计阶段开发的正式模型。软件开发过程中经常进行静态分析的对象是程序代码。