1.1 评审

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

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

（1）计划阶段：选择评审员并分配角色、为正式的评审类型（如审查）规定评审的入口和出口准则，以及选择需要评审的文档或文档章节等。

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

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

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

（5）返工阶段：修复评审过程中发现的缺陷，通常由作者完成。

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

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

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

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

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

评审相对可以比较容易实现较高的覆盖率。根据笔者在实际项目中的经验，评审可以发现产品中70%-80%的缺陷；动态测试则很难达到50%。图1-1所示为一个评审和动态测试在发现缺陷有效性方面的例子。在该例中，原来只进行单元测试和系统测试（图1-1 的左边），而现在在单元测试和系统测试之前引入了文档评审和代码评审（图1-1的右边）。图中的数据说明评审和动态测试相结合之后（假设评审和动态测试发现缺陷的有效性都是50%）可以提高产品质量，即通过引入评审，可以提高缺陷发现率，从而提高产品质量。

从图中可以看出，评审的引入可以大大提高产品质量，即整个测试过程的缺陷发现率从原来的75%（150/200 = 75%）提高到93.5%（187/200 = 93.5%）。但是引入评审提高产品的质量是以增加项目成本和时间作为代价的。因此在实际的项目测试过程中，需要平衡产品质量、进度和成本之间的关系，以实现项目的总体目标。

（2）提高有效性。测试人员尽早介入项目是有效测试的基本原则之一，这样可以尽早参与发现软件产品中的缺陷，从而节省时间和降低成本，因为在项目的早期发现缺陷可以大大减少缺陷修复的时间和成本。

评审可以降低测试和开发的成本，因为在项目的早期发现和修复缺陷的成本比在动态测试执行阶段发现和修复缺陷的成本小得多；同时有效的评审可以减少动态测试执行的时间。表1-1所示为统计得到的在不同阶段修复缺陷的成本。

（3）可预测性。动态测试是整个测试过程中最难预测和最难管理的活动之一，其原因主要表现为如下方面。

● 缺陷数目、缺陷修复时间及缺陷相关信息的随机性和不确定性导致计划和分配测试资源非常困难。

● 动态测试过程中发现的缺陷数目越多，测试就越难于管理。因此动态测试活动发现缺陷数目的减少可以减轻测试的不可预测性，从而提高整体项目的预测性。

早期开展的评审活动一方面可以尽早发现和修复软件产品中的缺陷，减少遗留到后续阶段的缺陷数目；另一方面也可以根据评审活动中发现的缺陷数目和类型分布等数据评估测试对象的质量和缺陷分布，从而减轻动态测试活动的不可控性和不可预测性。

（4）培训目的。通过有效的评审，评审团队成员之间，包括作者和评审人员之间都相当于参加了一次培训，有助于在将来的项目中产生更好质量的文档。有效的文档评审过程也是一次相互学习的过程，因为评审过程、规则和实践等在评审团队成员之间进行了共享；同时通过评审成员之间的分析和讨论，项目技术相关的知识和技能也可以在团队之中传播。

（5）缺陷预防。评审的重要目的之一是尽早发现软件产品中的缺陷，为将来的项目改进提供数据和经验，不断地改进开发过程、测试过程和评审过程等，在将来的项目中达到缺陷预防的目的。例如，通过评审过程中学习到的知识技能和经验可以改进评审相关的检查表。

1.1.1 评审遵循的原则

评审是静态测试的重要组成部分，其通过直接检查软件产品发现缺陷。评审通常发现的是软件产品的缺陷，而非失效。软件产品可以是软件开发生命周期中的各种文档，如需求规格说明、设计规格说明、测试计划和测试设计规格说明等。为了有效地开展评审活动，需要遵循如下基本原则，以避免评审过程中的某些错误。

（1）尽早开展评审活动。准备相关的软件产品（如被评审的文档）和项目必须遵循的标准后，应该及时开展各种评审活动。测试人员在软件开发生命周期的尽早介入，可以尽早参与发现软件产品中的缺陷，从而节省时间和降低成本。

（2）控制评审会议的时间。通常会议时间应该控制在两个小时之内。如果需要，可以在当天发起另一个会议。如果评审会议的时间过长，评审人员过于疲劳会降低评审的效率。

（3）评审的是软件产品而不是作者。因此评审员必须注意其言语及表达方式，避免作者成为被攻击的目标或者被迫处于防御的位置。评审员提交的问题不应该以命令或者嘲笑的形式写给作者，中肯的改进或者修改建议对质量改进是有帮助的，并且是明智的。

（4）每个评审员都必须有机会充分地表达各自的观点，并且评审会议纪要必须完整地记录每个评审员的意见和建议。

（5）发现缺陷，而不是修复缺陷。评审会议关注的是发现被评审对象中的缺陷，而尽量避免讨论针对缺陷的可能解决方案和方法，提出解决方案及其对应的讨论不应该是评审会议的关注点。

（6）评审过程中发现的缺陷和问题，应该划分为不同的严重程度级别。

● 严重缺陷：评审对象不能满足其目标，在批准评审对象之前必须修复相关缺陷。

● 重要缺陷：影响评审对象的可用性，批准评审对象之前应该修复相关缺陷。

● 一般缺陷：小的偏差，基本不影响使用。

● 好的：没有缺陷，返工时无须修改。

（7）评审团队最后应该对评审对象给出如下评审意见。

● 接受：文档不需要修改或者只要微小的修改。

● 有条件接受：文档需要修改，但是不需要进一步评审。

● 不接受：文档需要深入修改，并且需要重新评审或者其他检查措施。

1.1.2 选择合适的评审类型

评审可以是正式或非正式的，软件产品可能需要经历不同的评审类型，此时评审对象的评审顺序不同。例如，技术评审之前可能需要非正式评审。

不同评审类型在特点、目的、过程、优缺点和应用领域等方面有所不同，下面基于IEEE Std 1028– 2008软件评审和审计标准，分别说明审查、技术评审、走查、非正式评审、管理评审和审计等评审类型。

（1）审查。审查的主要目的是检查并发现软件产品中的缺陷，这是一种系统的同行检查方法，主要关注软件产品是否满足规格说明及其是否体现了特定的质量特性，以及是否满足了规范、标准、指南、计划、规格说明和规程等要求，并识别其中存在的差异。审查过程中还需要收集相关的度量数据（如缺陷及工作量等），这些数据用于改进审查过程及其支持文档（如检查表）；同时审查得到的数据也可作为项目管理的输入。

审查一般由2至6个人参与，包括作者。审查由经过审查培训的人员负责开展。在审查过程中必须确定补救措施或者调查活动，尽管在审查会议上并不讨论解决方案。

参与审查的角色主要有主持人、记录员、宣读员、作者和审查员。一般情况下，作者不应该作为主持人、记录员和宣读员，审查主持人可以作为记录员，审查员的主管不应该参与审查会议。有些审查可能会针对软件产品为每个审查员指定特定的审查主题，以保证有效的审查覆盖率。例如，有的审查员负责评审软件产品和标准之间的一致性，有的负责评审软件产品的语法等。审查员的职责应该由审查主持人在计划阶段确定。

审查主持人的一个重要职责是负责建立预期的审查效率，包括审查准备和会议的审查效率。确定审查效率是审查计划阶段的重要活动。表 1-2所示为每个小时根据页数或者代码行建议的审查效率。

如果审查会议过程中审查员对发现的缺陷有不同的意见，可以放在审查会议的后期讨论。

审查会议结束前需要讨论最终的审查结果，确定被审查的软件产品是否满足审查的出口准则和质量要求。审查结果包括以下内容。

● 接受：软件产品不需要任何修改或者只需要细小的修改，不需要进一步验证。

● 有条件接受：软件产品可以接受，但其相应的修改必须经过审查主持人或者指定审查员的验证。

● 不接受：软件产品不能被接受，并且完成相应的修改后，需要重新审查。

审查的另外一个重要任务是数据收集和改进活动，审查需要提供相关数据用来分析软件产品的质量、生成软件产品过程的有效性，以及审查本身的有效性和效率。为了保证审查的有效性，与审查相关的数据不应该作为评估审查参与人员的依据。为了分析这些数据，需要将审查会议中得到的缺陷进行合理分类。收集的审查相关数据包括被审查的软件产品、审查召开的日期、审查参与的成员、审查员准备的时间、审查会议的时间、审查对象规模和审查结果等。

审查中收集的数据应该定期进行分析，从而优化审查本身的过程，并改进生成软件产品的过程。经常重复出现的缺陷应该记录在审查的检查表中。而相关人员也应该定期检查审查使用的检查表，不断地优化和改进其质量。通过分析审查对象的规模、审查员准备时间、会议时间和发现的缺陷等，可以评估审查的效率，并且作为下次审查的有效输入数据。

（2）技术评审。技术评审是一种同行间的小组讨论活动，主要为了对测试对象所采用的技术实现方法达成共识。其目的是为了评估软件产品是否满足预期的使用要求，识别软件产品和规格说明与标准之间不一致的地方。技术评审可以为管理人员提供证据确认项目的技术状态，如测试过程中的测试用例设计规格说明可以通过技术评审来开展。技术评审也可以检查项目中采用的多个不同方案。

技术评审的主要参与人员包括决策者、评审主持人、记录员和技术评审员，也可以包括项目的其他利益相关者，如客户代表。技术评审中识别的问题如果需要管理人员的支持，那么相关的管理人员也可以参与。

技术评审的输入除了相关的规范、标准、计划和规格说明之外，评审检查表与缺陷分类等也是重要的内容。对于技术评审而言，评审主持人需要负责选择合适的技术评审员；而管理人员需要在时间和资源方面保证技术评审员及时到位。

技术评审的输出应当文档化，其中主要包括技术评审的对象、参与技术评审的成员名单、技术评审的目标、技术评审的相关输入、评审得到的软件产品缺陷列表、管理问题列表、应对活动列表（应对活动的状态、负责人、完成的目标时间与完成的实际时间等）和评审团队得到的建议列表，并且判断软件产品是否满足了规范和标准等的要求。

（3）走查。走查通过作者逐步陈述文档的内容，收集测试对象的相关信息，并对其中的内容达成共识，其目的如下。

● 发现缺陷。

● 改善软件工作产品。

● 讨论软件工作产品的替换方案。

● 评估和标准及规格说明等的一致性。

● 评估软件产品的可用性。

● 培训参与者。

走查也可能发现软件工作产品中的不足，如软件工作产品中的效率和可读性问题、设计和代码中的模块化问题，以及不可测的规格说明等。

走查的主要参与人员包括走查主持人、记录员、作者与走查员等，至少需要两个成员参与（包括作者本人）。走查参与人员的角色可以相互兼顾，如走查主持人或者作者可以是记录员，走查主持人也可以是作者本人。走查员的直接管理主管一般不参与走查活动。

走查过程中也建议收集相关的数据，用来分析被走查的软件产品的质量、生成软件产品过程的有效性及走查本身的有效性和效率。为了保证走查的有效性，收集的走查相关数据不应该作为评估走查参与人员的依据。为了分析这些数据，需要在走查会议中得到的缺陷进行合理的分类。走查收集的数据包括被走查的软件产品、走查开始的日期、走查参与的成员、走查员准备的时间、走查会议的时间、走查对象规模和走查对象的走查结果等。走查中收集的数据应该定期进行分析，以优化走查本身的过程，并且改进生成软件产品的过程。

（4）非正式评审。非正式评审是一种不基于正式（文档化）过程的评审，它是评审的精简版，在某种程度上遵循通用的评审过程。通常情况下，由作者发起非正式评审。评审计划限定于选择评审员和要求他们在指定时间点提交意见和建议。非正式评审通常不召开会议和相互交换意见，只是作者和评审员之间的交互。非正式评审可以是一种由一个或多个同事完成的交叉阅读，其结果不需要明确的文档化，有时一个评审清单或修订文档就足够了。

结对编程、结对测试和代码交换等都是非正式评审的方式，非正式评审非常普遍，并且由于工作量小而被广泛接受。

（5）管理评审和审计。除了前面提到的审查、技术评审、走查和非正式评审之外，IEEE Std 1028-2008中还涉及管理评审和审计。

管理评审是由管理层或其代表执行的对软件采购、供应、开发、运作或维护过程的系统化评估，包括监控过程、判断计划和进度表的状态、确定需求及系统资源分配或评估管理方式的效用，以达到正常运作的目的。其目的是监控项目过程、确定项目计划和执行进度状态，或者评估为获取某个目的而采用的管理方法的有效性，可以帮助确定合适的纠正措施、项目资源分配的变更或项目范围的变更。

管理评审可以用来识别当前项目状态和计划是否存在偏差、采取的管理方法是否合适及是否满足要求等。在管理评审过程中，相关的技术知识可以帮助管理评审达到目的。管理评审的对象可以是软件工作产品，如测试执行状态；也可以是软件开发相关的过程，如缺陷管理过程。

管理评审的主要参与人有决策者、评审主持人、记录员、管理人员和开发人员等，也可以包括其他项目利益相关者。例如，其他小组成员和客户代表等。

管理评审的过程满足通用的评审6大阶段，分别是计划管理评审、管理评审预备会、评审员准备、管理评审会议、返工阶段和跟踪结果阶段。

管理评审的输出应当文档化，其中应该包括管理评审的对象（软件工作产品或过程）、参与管理评审的成员名单、管理评审的目标、管理评审的相关输入、管理评审得到的应对活动列表（应对活动的状态、负责人、完成的目标时间和完成的实际时间等）及管理评审识别的缺陷列表等。

管理评审的主要特征如下。

● 其目的是监控进程和评估状态并为下一步行动做出决策。

● 由对项目或系统负有直接责任的经理执行。

● 由项目利益相关者或决策者执行，如更高级别的经理或总监。

● 核对与计划的一致性或与计划之间的偏离度及管理规程的充分性。

● 评估项目风险。

● 结果包括行动应对计划和待解决的问题列表。

● 参与者要求进行各项准备工作，必须在文档中记录相关的决策。

审计是对软件产品或过程开展的独立评审，用来确认产品是否满足标准、指南、规格说明和基于客观准则的步骤等。审计对象包括产品的内容与形式、产品开发应该遵循的过程，以及度量符合标准或指南的准则。审计是非常正式的，其目的是提供独立的评估，证明软件产品和过程与规范、标准、指南、计划、规格说明和规程等的一致性，因此审计在揭示缺陷方面的效率最低。

审计的主要参与人员包括审计负责人、记录员、审计员、审计发起者和被审计的组织，审计角色中的审计发起者确定审计的具体需求。审计发起者选择审计组织开展独立的审计评估活动并为审计员提供相关的信息，包括审计的目的、被审计的软件产品或者过程及评估标准等。审计负责人生成审计计划，审计员准备审计活动。

审计的主要特征如下。

● 其目的是对过程的一致性、规范性和标准等提供独立的评估。

● 审计负责人对审计活动负责，并且担任审计主持人的角色。

● 审计员通过谈话与仔细检查文档，收集一致性的证据。

● 审计结果包含观察资料、建议、纠正活动和通过/不通过的结论。

（6）特殊工作产品的评审。除了上面提到的评审类型（审查、技术评审、走查、非正式评审、管理评审和审计）之外，评审也可以根据被评审的工作产品名称或者活动划分。

● 合同评审：通常与合同里程碑关联，通常作为安全关键系统的管理评审，其中涉及的角色主要包括管理人员、客户和技术人员等。

● 需求评审：可以是走查、技术评审或者审查，通常考虑安全相关和依赖性需求，也可以是其他功能和非功能需求。

● 设计评审：典型的技术评审或审查，其中涉及的角色主要包括技术人员、客户和项目利益相关者等。设计评审又可以分为下面两种类型。

➢ 初步设计评审（评审某些技术设计和测试的最初方法）。

➢ 关键设计评审（评审所有被提议的设计解决方案，包括测试用例和测试规程）。

● 验收评审/资质评审：是用来获得管理层对系统的批准，也可以归为资质评审，这是一种常见的管理评审或审计。

● 运行预备评审：系统正式运行前的评审，该评审的通过可作为系统正式运行的入口准则之一。

1.1.3 案例分析：如何开展评审活动

评审可以提高软件产品的质量，提高发现和修复缺陷的有效性，并且为后续的开发、测试和管理控制活动提供更好的可预测性。在评审过程中评审成员之间的讨论和解释可以作为一种有效的培训手段，而收集的数据和信息可以为将来项目的缺陷预防提供重要的依据，因此评审应该作为重要的静态测试技术引进测试组织中。

被评审的产品应当符合相应条件（如审查需要满足一定的评审入口准则），同时不同的评审对象需要不同的评审员参与。例如，测试计划对应测试经理、商业需求或测试设计对应测试分析员，以及功能规格说明、测试用例或测试脚本对应测试技术分析员。表1-3所示为某项目中和测试紧密相关的5个文档的建议评审人员。

其中的评审员，如功能开发经理，可以指定符合要求的开发人员代替其参与评审活动。评审对象的“作者”一栏中列出了该文档的主要责任人，有的文档可能需要多个项目人员共同完成，作者可能有多人。例如，测试计划由测试经理负责，但是需要测试分析员、测试技术分析员及其他测试人员提供相关信息和数据（如工作量估算的数据和风险信息等）。

为了成功地将评审引入到项目和组织中，需要采取以下措施。

（1）获得管理层支持：评审需要时间和资源，如评审员的时间计划、工作量计划、评审需要的基础设施和设备等，这些都需要组织管理层的支持。

（2）管理人员培训：早期发现和修复缺陷可以节约时间和降低成本。管理人员必须意识到学习新的评审技术是一项投资，其收益不是立即可见的，随着时间的推移会越来越明显地显现出来。管理人员需要在评审成本、利益和执行方面进行有效的平衡。

（3）正规的评审过程：组织内定义并文档化评审步骤，定义不同的评审类型和评审过程中不同的角色和职责，并对评审过程定义合适的监控手段和形式。通过评审过程的监控和改进提供评审的度量数据（如评审的效率和发现缺陷的分布等）。

（4）开展评审技术和规程的培训：根据项目特点和评审类型开展评审技术和规程的培训，更好地让评审参与人员了解评审的目的、评审的过程及评审的作用和意义，从而更加有效地开展评审，而不是作为过程的一部分流于形式。

（5）获得评审员和评审对象作者的支持：评审要求评审对象的作者提供合适的评审资料，以满足评审的入口准则。并且需要评审员具备合适的专业技能和知识，拥有足够的能力完成评审工作。

（6）评审最重要的文档：由于软件开发的时间和资源有限，因此需要将评审用于最重要的文档（如需求、合同和计划等）。

正式而严格的评审包括6个阶段，即计划阶段、预备会阶段、个人准备阶段、评审会议阶段、返工阶段和跟踪结果阶段。下面以“IGMP系统需求规格说明”的评审活动（审查）为例，介绍评审过程的这6个通用阶段。

（1）计划阶段。作者将评审对象和相关的输入材料汇总给评审主持人，主要内容如下。

● 评审对象：IGMP系统需求规格说明。

● 输入材料：包括IGMP用户需求规格说明、IGMP V1版本RFC 1112、IGMP V2版本RFC 2236和IGMP V3版本RFC 3376。

评审主持人在评审计划阶段需要考虑以下方面的内容。

● 选择合适的评审员组建评审团队，包括产品经理、产品架构师、功能架构师、测试经理、测试分析员和测试技术分析员，其中评审的角色主要包括评审主持人（同时作为评审的记录员）、评审员和作者。

● 确定“IGMP系统需求规格说明”的具体评审时间和评审会议召开的地点，如预订评审会议的会议室。

● 确定评审准备时间，并分发评审对象和输入资料，要求评审员在规定时间内向评审主持人反馈针对文档提出的建议和发现的缺陷。

如果需要，在计划阶段确定评审的范围和重点。例如，如果评审对象内容过多，可以选择重点或者风险较高部分评审。这是针对“IGMP系统需求规格说明”的第1次正式评审，因此需要仔细检查需求规格说明的各个部分。

评审计划阶段的信息可以通过邮件方式分发给所有的评审员，也可以在预备会上详细阐述。针对“IGMP系统需求规格说明”，通过邮件系统发出正式的“评审邀请信”，详细内容如下。

例1-1 “IGMP系统需求规格说明”评审邀请信

评审对象：IGMP系统需求规格说明。

输入资料：输入资料.tar。

作者：XXX。

评审时间：XXXXXX。

评审地点：XXXXXX。

下面是本次评审必须参与的评审员。

XXX（产品经理）

XXX（产品架构师）

XXX（功能架构师）

XXX（测试经理）

XXX（测试分析员）

XXX（测试技术分析员）

上述评审员必须提交发现的缺陷或者问题，评审过程只有在所有的评审员提交comments之后才能正常结束。评审时采用的评审检查表已经包括在本邮件的附件中。

评审员提交comments的同时需要提供各自花费的评审准备的工作量，以方便管理工具度量并收集与工作量相关的数据。

评审员提交的缺陷或者问题，请按照缺陷过程定义的类型分类，以方便缺陷工具度量并收集缺陷相关数据。

如果评审员没有任何comments，请提交“no comments”作为一条comments。

（2）预备会阶段。发出“IGMP系统需求规格说明”评审邀请信之后，如果评审主持人认为有些评审的要点和注意事项还需要进行面对面的沟通，那么就有必要召开预备会。在预备会上，评审主持人简单介绍评审的对象和相关资料，并说明采用的评审技术。重要的是评审主持人将解答“评审邀请信”中无法说清楚的一些问题，如建议的审查效率、至少需要的准备时间和可能采用的审查检查表等。

针对“IGMP系统需求规格说明”，评审主持人认为在“评审邀请信”中已经提供了足够的信息，所以省略了预备会阶段。

（3）个人准备阶段。在个人准备阶段，评审员需要仔细阅读并检查评审对象，以及与评审相关的输入资料。根据各自的职责要求和评审目的尽量发现评审对象中的缺陷，并根据缺陷分类要求合理分类；同时记录自己花费在检查评审对象中的准备时间和工作量。

在个人准备阶段，评审员采用合适的审查检查表来检查软件产品是提高评审效率和覆盖率的有效手段。表1-4所示为从测试人员的角度（不包括IGMP相关的技术和实现等方面的内容，只包括一些通用的检查点）针对系统需求文档采用的检查表的部分内容。

个人准备阶段的主要工作是检查评审对象，发现缺陷，并将缺陷合理分类，以方便后续的缺陷分析和过程改进。表1-5所示为针对“IGMP系统需求规格说明”文档采用的缺陷分类及含义。

评审员在评审会议之前，将发现的缺陷和问题，以及在评审准备工作中花费的时间和工作量反馈给作者和评审主持人。

（4）评审会议阶段。在评审会议阶段，评审主持人应该在会议之前强调评审的关注点是发现缺陷，而不是讨论针对缺陷的解决方案；评审的对象是软件产品，而不是文档的作者。如果在评审会议阶段，有一些额外的议题需要讨论，也应该放在会议的后期进行。

评审会议阶段的一个重点工作是检查评审对象，发现并讨论其中的缺陷和问题。记录员应该详细记录缺陷的内容、分类和位置等。如果评审员之间对缺陷有不同的意见，也可以放在会议后期讨论。另一个重点工作是检查个人准备阶段发现的缺陷列表，以保证缺陷列表的完整性和正确性。

在评审会议阶段需要给出评审对象的最后评审结果。

● 接受：文档不需要修改或者只需要微小的修改。

● 有条件接受：文档需要修改，但是不需要进一步的评审。

● 不接受：文档需要深入修改，并且需要重新评审或者其他检查措施。

表1-6所示为针对“IGMP系统需求规格说明”文档得到的部分缺陷列表。

根据在评审会议中汇总的缺陷列表，以及组织中定义的审查出口准则，评审员给“IGMP系统需求规格说明”的评审结论为“有条件接受”。

（5）返工阶段。返工阶段是作者根据评审员反馈的缺陷列表和建议修改文档。如果评审的最后结果是不接受，那么作者除了修改之外，还需要为下个阶段的评审做好相关的准备工作。

“IGMP系统需求规格说明”的评审结论是“有条件接受”，因此文档作者必须修改评审过程中发现的缺陷，例如，增加IGMP功能的非功能性需求条目和规范IGMP术语等。

（6）跟踪结果阶段。跟踪结果阶段主要是评审主持人或者其他指定人员检查返工阶段的输出，验证作者是否正确完成了修改任务。针对“IGMP系统需求规格说明”，评审主持人指定其中的一位评审员（测试分析员）来对作者修改之后的文档进行跟踪和检查，并给出建议。

跟踪阶段的另一个重要工作是收集和分析“IGMP系统需求规格说明”评审过程中的一些数据和信息，如分析“IGMP系统需求规格说明”的质量、生成“IGMP系统需求规格说明”过程的有效性，以及审查本身的有效性和效率。评审过程中收集的数据包括被评审的软件产品、召开评审的日期、参与评审的成员、评审员准备的时间、评审会议的时间、评审对象规模和评审结果等，这些数据可以用来分析评审质量和效率。跟踪阶段也需要不断地优化和改进检查表的质量。

例1-2 “IGMP系统需求规格说明”审查收集的数据

表1-7所示为“IGMP系统需求规格说明”审查收集的数据。

1.1.4 影响评审成功的因素

在实际评审过程中经常由于各种原因，评审最终无法达到预期目的。从而导致评审在软件开发生命周期中的作用大大减弱，甚至在有的组织和项目中评审只是流于形式。导致评审失败的常见因素如下。

（1）参加评审的人员没有时间保证，或者不具备必需的资格或技术能力。例如，对于主持人而言，除了技术技能，必须具备更多的心理技能。技能的缺乏可以通过培训或者使用咨询公司有资质的人员解决。

（2）管理层在项目计划中的不准确估算可能导致评审的时间压力较大，进而导致令人不满意的评审结果，有时较低成本的评审类型能够缓解这个问题。

（3）由于评审员在准备阶段准备不足而失败，这种情况大部分是因为选择了不合适的评审员所造成的。如果评审员没有认识到评审的重要性及其对质量改进的巨大影响，并且评审因此而失败，那么有必要通过实例演示等方式说明评审如何提高生产率和改进产品质量。

（4）因为没有文档或者文档准备不足而失败，在评审之前必须检查所有需要的文档已经存在，并且已经描述充分（如采取严格的评审入口准则）。

（5）如果没有管理层的支持，评审过程无法成功。因为无法获得必需的资源，评审的结果也不会用于过程改进。不幸的是，评审经常会出现这种情况。

成功运用评审的一个重要方面是不断从评审过程中积累经验教训，从而持续不断地改进评审过程。

尽管测试过程中评审活动面临各种各样的问题和困难，但是也有许多因素有助于评审的成功开展。如果未充分考虑以下因素，评审可能会以各种方式走入歧途。

（1）技术因素。

● 保证正确遵循针对评审类型所定义的过程，特别是针对正式的评审，如审查。

● 记录评审所花费的成本（如时间成本）和所获得的收益。

● 评审早期的草稿或者部分文档，以提前识别其中的各种缺陷类型，防止它们被引入整个文档。

● 在启动评审过程之前，通过定义评审的入口准则确保全部或部分文档已为评审准备就绪。

● 运用组织特有的缺陷检查表，提高评审的效率和有效性。

● 根据不同的目标（如技术改进、信息转移或进度管理）运用多种类型的评审。

● 评审影响重大决策的文档，如在决定是否批准项目主要开支之前，需要认真审查相关的建议、合同或高级需求。

● 抽样调查某一限定的文件子集以达到评估的目的。

● 鼓励发现最重要的缺陷，注重内容而非形式。

● 持续改进评审过程。

（2）组织因素。

● 即使在最后期限的压力下，管理人员也应该确保花费足够的时间用于评审活动。

● 切记评审中花费的时间和预算并非与发现的缺陷数目成比例。

● 要给予足够的时间修改在评审中发现的缺陷。

● 永远不要将评审中的度量数据用于个人的绩效评估。

● 对于不同类型的评审要确保有合适的评审员参与。

● 为评审参与人员提供评审方面的培训，特别是正式的评审类型。

● 成立评审主持人论坛，以相互分享经验和想法。

● 确保人人参与评审，并且保证每个人都对负责的文档内容进行了评审。

● 将最正式的评审技术用于最重要的文档。

● 确保由不同技术和背景的人员组成的评审团队具有良好的平衡性。

● 认可通过评审过程所取得的改进。

（3）人员问题。

● 使项目利益相关者认识到评审将会发现缺陷，并改进软件产品质量。

● 对于缺陷修复和再评审要给予充足的时间。

● 要确保评审对于作者来说是一次正面和积极的经历。

● 营造一种“无责备”的氛围，从而乐于接受缺陷的识别。

● 要确保评审意见具有建设性、有益性和客观性，而非主观性。

● 作者不同意或者不愿意的情况下不进行评审。

● 鼓励成员深层次思考评审文档的最重要的方面。