静态测试

对工作产品（文档和代码）进行静态测试和分析，对提高产品质量有很大的帮助。本章介绍了静态测试的一般情况，以及所涉及的具体过程，包括其活动和必须填补的角色。我们描述了四种经过验证的技术和它们的具体优势，以及在应用它们时确保成功的因素。最后，我们比较了静态和动态测试技术。

• 被低估的技术

静态测试（或 "静态分析"）可以在基于工具的环境中进行，也可以手动进行，是一种经常被忽视的测试技术。动态测试的测试对象（见第5章）是使用测试数据运行的可执行程序，而静态测试可以在任何一种与产品开发有关的工作产品上进行。静态测试可以采取由一个或多个人进行仔细检查的形式（见第4.3节），也可以使用适当的分析工具进行（见第7.1.3节）。

• 一切都是为了预防

静态测试的基本概念是预防。在进一步的开发过程中，错误和其他偏离计划的情况被识别出来，以免产生负面影响。所有相关的工作产品在任何人做任何进一步的工作之前都是有质量保证的。这可以防止有问题的临时工作产品进入开发流程，并在以后造成昂贵的故障。
静态测试可以在各种情况下进行（见下文），而且通常是开发过程中的一个组成部分（即在计划阶段就提供测试资源）。例如，在航空和医药等对安全要求很高的行业，静态分析是确保所需产品质量的一个极其重要的因素。

参考资料

• 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
• python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• 英文原版下载：Software Testing Foundations, 5th - 2021.pdf (访问密码: 订阅号pythontesting 发送 密码) https://url97.ctfile.com/f/18113597-853966551-6ed72c

4.1我们可以分析和测试什么？

• 一种通用的技术

除了代码本身，软件开发也会产生很多其他的工作产品。大多数文件在产品的进一步发展中起着某种作用，因此每个文件的质量都是整个结果质量的重要因素。
可以用静态分析（尤其是审查，见下文）来检查的工作产品包括规范、业务需求、功能和非功能需求以及安全需求。规范的错误需要在转化为代码之前被发现。在敏捷项目中，史诗和用户故事要进行静态测试。静态分析揭示的缺陷种类包括不一致、含糊不清、矛盾、差距、不准确和冗余。

在软件设计过程中，架构和设计规范（如类图）被创建，可以像程序代码一样进行静态测试。构成网站的代码也可以通过这种方式进行测试（例如，自动验证链接和其相应的目标网站）。代码可以被检查是否与项目的编程指南一致。
一般来说，静态测试可以验证在被分析的文件中是否遵守了任何预定的标准。
此外，最好是检查和验证所有在测试期间创建的文件、定义和工具（如测试计划、测试用例、测试程序和脚本、验收标准）。其他可以通过静态测试验证的文件和工作产品包括合同、项目计划、时间表、预算和用户手册。
此外，静态测试的结果也可以用来改进整个开发过程。如果某些种类的缺陷在特定的开发步骤中反复出现，这就表明这个步骤需要调查，如果有必要，可以进行优化。这种过程通常伴随着额外的人员培训。

4.2静态测试技术

• 人的精神和分析能力

人的精神和分析技能可以用来通过对有关文件的密切调查来分析和评估复杂的情况。对这种分析的成功至关重要的是，有关人员要理解他们正在阅读的文件，并理解其中的陈述和定义。静态测试通常是检查文档和其他工作产品语义的唯一有效方法。

它们是各种静态测试技术，在其彻底性、所需资源（即人和时间）以及所追求的目标方面都有所不同。一些常见的静态测试技术详见下文。使用的术语是基于ISTQB®大纲和ISO 20246。

• "审查"（Review）有多种含义

最常见和最重要的静态测试技术是审查。在这种情况下，"审查"一词有多种含义。它被用来描述工作产品的静态分析，但也被用来作为由人类执行的所有静态分析技术的一般术语。术语 "检查"（inspection）也被用来描述类似的过程，尽管它经常被用来指根据预定的规则正式执行静态测试（以及收集指标和数据）。
不同的审查过程

审查可以非正式地或正式地进行。非正式的审查不遵守预先定义的过程，对预期结果或记录的内容没有明确的定义。相反，正式的评审过程（见第4.3.1节）是预先定义的，参与者（见第4.3.3节）记录一组计划的结果。
你选择的审查过程的类型将取决于以下因素：
开发生命周期模型： 你在使用哪个模型？模型中的哪些地方和中期结果适合于进行评审？
开发过程的成熟度： 过程有多成熟，要检查的文件的质量有多高？
要检验的文件的复杂性： 哪些产出显示出高度的复杂性，因此适合进行（正式）审查？
法律或法规要求和/或可追溯的审计跟踪的必要性： 哪些法规必须遵守，哪些质量保证的证明（也就是审查）是必须的？

• 不同的目标

评审的预期目标也决定了你选择哪种类型的评审过程（见4.4节）。你是关注缺陷检测还是关注被测试工作产品的一般可理解性？新的团队成员是否必须通过评审来熟悉某个特定的文件？评审是否有助于团队达成一致决定？你所进行的评审的类型将取决于你对这些问题的回答。

4.3 评审过程

• 评审活动

审查工作产品的过程包括计划、开始、参与者（专家、审查员、检查员）的准备、沟通和分析结果、纠错和报告（。
图像

4.3.1审查过程活动

• 规划

定义你的目标并选择审查的类型

在计划阶段，管理层--或者更准确的说，项目管理部门--必须决定哪些文件（或文件的一部分）需要接受哪种类型的评审（见4.4节）。这个决定会影响到必须担任的角色（见第4.3.3节）、必要的活动，如果需要，还会影响到检查表的使用。你还需要决定评估哪些质量特性。也要计划每次评审的估计工作量和时间范围。项目经理选择一个由适当技能的参与者组成的团队，并给他们分配角色。项目经理还必须与评审对象的作者检查他们是否处于可评审的状态，即他们至少已经达到了部分结论，并且尽可能的完整。
正式的审查需要预定的进入和退出标准。如果计划包括进入标准，你需要在进行审查之前检查这些标准是否已经实现。

• 不同的观点会增加有效性

从不同的角度检查文件，或让个人检查文件的特定方面，可以提高审查过程的有效性。这些观点和/或方面必须在计划阶段确定。
你不一定要审查整个文件。选择包含高风险缺陷的部分，或能够使你对整个文件的质量得出结论的样本部分，往往是有意义的。
如果你想举行预审会议，你需要决定何时何地举行。

评审过程的开始（或 "启动"）是向参与者提供所有必要的实物和电子材料的时刻。这可以是简单的书面邀请，也可以是一个审查前的会议，会上讨论审查的重要性、目的和目标。如果参与者还不熟悉评审对象的环境，也可以用启动仪式来简要说明评审对象如何适合其应用领域。

• 基准文件

除了要审查的工作产品外，审查参与者还需要其他材料。这些材料包括任何有助于决定他们正在看的东西是一个偏差、一个错误/缺陷，还是一个正确的陈述的文件。这些是检查审查对象的基础（例如，用例、设计文件、指南和标准）。这些文件通常被称为 "基线"。额外的测试标准（也许是以检查表的形式）有助于结构化程序。如果你使用表格来记录你的发现，这些需要在程序开始时分发。
如果你正在进行正式的审查，你需要检查进入标准是否已被满足。如果不符合，应该取消审查。这样可以节省时间，否则就会浪费在审查 "不成熟 "的工作产品上。

• 研究审查对象

只有当所有参与者都准备充分时，审查才会成功，所以审查小组的每个成员都要为审查做个别准备。
审查员（或 "检查员"）以提供的文件为基准，对审查对象进行严格审查。任何潜在的缺陷、建议、问题或评论都会被记录下来。
个人准备可以采取多种形式。关于这些的更多细节，见4.3.2节。

• 整理你的发现

在个人准备之后，对发现进行整理和讨论。这可以在审查会议上进行，也可以在公司内部的在线论坛上进行。对团队成员发现的潜在偏差和缺陷进行讨论和分析。你还必须定义谁负责纠正所发现的缺陷，如何监控纠正进度（见6.4.4节），并确定是否需要或有必要对固定的文件进行后续评审。
在计划期间，要确定所调查的质量特性。对每个特性进行评估，并将分析结果记录下来。
然后，评审组要提供关于接受评审对象的建议：
接受，不作修改或稍作修改
由于广泛的变化，有必要进行修订
不接受
附注：对审查会议的建议

如果举行审查会议，尽量遵守以下建议：
将会议时间限制在两小时内。如果有必要进一步讨论，最早在第二天举行后续会议。
如果一个或多个审查员缺席，或虽出席但准备不足，主持人（见下文）有权取消或暂停会议。
讨论的对象是工作成果，而不是其作者：
评审员需要注意他们的措辞。
不能要求作者为自己或其作品辩护。然而，对他的决定进行辩解可能是有用的。
主持人也不能成为评审员。
不能讨论审查标准中没有涉及的一般风格问题。
制定和讨论潜在的解决方案不是评审组的工作（见下文对该规则的例外）。
每个审查员都必须有足够的机会陈述她的结论
评审员应努力达成并记录共识
研究结果不应该被表述为对作者的纠错指示。然而，对审查对象的纠正或改进的建议可以帮助提高产品质量。
个别结论应被归类为：
关键（审查对象不适合其预期的目的，缺陷必须在发布前得到纠正）。
主要缺陷（对象的可用性是有限的，在发布前必须纠正缺陷）
轻微缺陷（与计划略有偏差--例如，印刷中的语法错误，不影响使用）
良好（没有缺陷，在修订过程中不改变）。
纠正和报告

• 纠正缺陷

审查过程中的最后一项活动是报告你的发现并纠正审查中发现的任何缺陷或不一致之处。评审会议的记录通常包含了所有需要的信息，因此对于需要修改评审对象的缺陷，不需要单独的报告。一般来说，作者会纠正审查所揭示的任何缺陷。
除了写报告，你发现的任何缺陷也可以直接与负责人或团队沟通。然而，这涉及到良好的人际关系技巧，因为没有人真正喜欢谈论自己的错误（见2.4节）。

• 正式审查涉及更多的工作

在正式评审中，你需要记录一个缺陷或其报告的当前状态（见第6.4.4节）。只有在负责的评审员同意的情况下，才可以改变缺陷的状态。您还需要检查指定的退出标准是否已经完成。

评估正式审查会议的结果将帮助你改进审查过程，并使相应的准则和检查表保持更新。这需要收集和评估适当的指标。
评审的结果因评审的类型和涉及的正式程度而有很大的不同（见4.4节）。下面几节将详细介绍审查过程的不同方法，并继续讨论正式审查中涉及的角色和责任。

4.3.2 不同的个人审查技术

• 整理你的发现

基本审查过程通常要求每个参与者为团队审查做准备。有各种个人审查技术，有助于揭示缺陷。这些技术可以应用于所有类型的评审（见第4.4节），尽管它们的效果会根据你所进行的评审类型而有所不同。下面的章节描述了各种单独的审查技术。

• 没有规则

顾名思义，这种技术不涉及关于个人准备的预定义规则。评审员通常按顺序阅读工作产品，并记录发现的任何问题、发现或缺陷。文件的类型也是任意的。因为它们只需要很少（或没有）的准备，所以临时性的审查相当频繁，而且因为没有涉及规则，结果在很大程度上取决于个别审查员的技能。如果一个审查对象由一个以上的人审查，一些问题肯定会被标记多次。
基于检查表的审查

• 使用检查表

使用检查表是一个很好的方法来组织你的阅读，从而提高个人审查的有效性。你可以定义哪些检查表是由哪些审查员使用的。检查包含基于在早期项目过程中发现的潜在缺陷的问题清单。这些问题也可以基于需要遵守的正式准则或标准，如下面的例子所示。

案例研究： 使用检查表

审查需求文件的检查表：
文件的结构是标准化的吗？
是否有关于如何使用该文件的解释（即解释性介绍）？
需求文件中是否包括项目摘要？
是否有词汇表以帮助一致的理解？
...
我们的例子显示了一个审查需求文件的检查表，但检查表可以被制定来帮助审查任何类型的工作产品（例如，代码审查）。检查表必须定期更新，以包括新认识到的问题，并删除与过期或已解决的问题有关的问题。检查表一般应保持简短，只包括关键问题。
基于检查表的技术的主要好处是它系统地涵盖了所有典型的缺陷类型。这种技术的潜在缺点是，它倾向于将审查 "集中 "在特定的问题上，从而降低了发现与所列问题无关的缺陷的可能性。在使用这种技术时，要始终保持开放的心态。
使用场景和试运行7

• Use case演练

基于场景的审查是基于预定义的、结构化的指导方针，规定了如何贯穿审查对象。特定用例的可用性简化了这种类型的审查，因为你所要做的就是对所有的用例进行 "干运行"。例如，在我们的VSR-II案例研究中，我们可以检查所有的 "配置车辆 "和 "选择特别版 "案例是否被正确实现（也见5.1.6节）。
在代码审查的情况下，这种情况也可以基于缺陷的类别。例如，审查员可以专注于代码中的错误处理，而另一个则专注于检查边界的遵守情况。情景帮助审查员发现特定类型的缺陷，通常比简单地通过问题清单工作更有效。
然而，完全使用场景会使识别其他类型的缺陷（如缺失的属性）更加困难，如果可能的话应该避免。

• 不同的角色和观点

在基于角色的评审中，评审员的任务是从专家的角度来检查评审对象。要做到这一点，评审员必须已经在专家角色中工作，或者至少对其有强烈的同情心。基于角色的审查的基本思想是利用每个角色提供的技能。当然，扮演某个角色的人必须有适当的技能。例如，让测试人员审查需求总是有用的，因为他们可以在开发过程的早期检查需求是否有足够精确的定义，以便有效地从需求中得出测试条件和测试案例。

• 利用专家技能

其他典型的审查角色是利益相关者，如终端用户或客户组织内的系统操作者。如果最终用户或系统的操作者不能参加审查会议（通常是这种情况），这些角色必须由其他人来扮演。终端用户 "的角色可以进一步细化，取决于这个人是 "有经验 "还是 "无经验"。如果该系统要在组织内使用，审查员可以扮演系统或用户管理员的角色。

案例研究： 基于角色的审查

一份需求文件要进行基于角色的审查。在审查过程中，Joe Smith被指派为设计师的角色。理想情况下，Joe知道软件系统的设计，并将在现实世界的项目中履行这个角色。Joe分析了需求，看看为了使需求得到充分的实现，对系统的结构需要做哪些改变。Jane Brown是一名测试员，在审查中采用这一角色。在审查过程中，她将检查是否有可能毫不含糊地决定（在实施和测试之后）每个需求已经得到满足。简将 "系统将实现快速操作 "的要求标记为没有充分的量化。没有可以测量的数字，也没有先决条件或约束条件来确定在什么情况下时间可以被认为是充分的。其他的角色也需要被填补，以便进一步仔细检查这些要求。

• 不同的观点

所有可用的角色都指向不同的缺陷、不一致的地方和差距。基于角色的评审员承担了不同利益相关者的观点，从而检查了系统的不同方面。利益相关者本身的（通常是主观的）观点也需要被纳入到评审中。下面的例子说明了在我们的案例研究项目中，对下一次迭代的日程安排审查存在不同的利益。

案例研究： 基于观点的审查

销售部门的观点说，一个特定的需求在需求文档中需要高优先级，因为这个功能是一个重要客户要求的，需要尽快实施。从测试人员的角度来看，这个功能与其他已经实施的功能非常相似，所以在实施和测试中不应该有任何严重的问题。因此，她建议及时实施这个新功能。

然而，从测试的角度来看，另一个新功能更为关键，因为它是这个项目中第一个实现人工智能（AI）的功能。到目前为止，团队在这个领域还没有经验。因此，测试人员假设这个功能需要大量的实施和测试工作，所以需要为它分配更多的资源。
基于视角的审查的基本原则是，每个审查员从不同的视角看审查对象，并因此而运行不同的场景。然后，审查结果不仅可以用来评估有关文件，还可以用来估计任何需要修改的紧迫性和范围。要做到这一点，每个评审员都要通过不同的情景，并使用结果来评估所调查的文件。利用不同的利益相关者的观点可以增加每个人的审查深度，而且角色的分配可以减少缺陷和其他问题的重复命名。使用检查表也是提高这种审查有效性的好方法。
经验性研究认为基于观点的审查是检查需求和技术描述的最有效的方法。其成功的关键之一是在分析和评估风险时，包含了许多利益相关者的观点。

4.3.3 审查过程中的角色和责任

在讨论审查的一般原则时，已经大致描述了审查过程中涉及的角色和责任。下面的章节将更详细地介绍典型的正式审查中的角色和责任。
并非每个角色都必须由一个人担任，有些角色之间的重叠可以证明由一个人担任多个角色是合理的（例如，主持人和审查负责人）。然而，哪些角色可以合并取决于项目的性质和你需要实现的质量标准。与各个角色相关的个别活动也因你所进行的评审类型而不同（见4.4节）。

• 管理

管理层选择哪些工作产品和支持材料将被纳入审查，以及哪种类型的审查将被进行。管理层还负责计划审查和分配所需资源（人员、时间、资金），并需要关注成本效益。如果审查的结果不是结论性的，管理层就需要介入并做出控制性的决定。

管理团队的成员如果也是审查对象的作者的老板，就不应该参加审查会议，因为这涉及到对作者而不是他的工作的隐性评价，会限制审查话语的自由。还有一种情况是，管理层没有适当的IT技能来有效参与技术审查会议。当然，对于项目计划会议和其他由管理层领导的任务来说，情况并非如此，在这些会议上，项目和一般管理技能是至关重要的。

• 评审组长

评审组长承担着总体责任，因此需要确保计划、准备、执行、修改和任何后续工作都有助于实现评审目标。审查负责人决定谁参与审查，以及审查的时间和地点。

• 主持人

主持人（通常也被称为主持人）的工作是确保评审会议的顺利进行。审查会议的成功往往取决于主持人的主持和外交技巧。他或她必须善于汇集反对的观点，并在不伤害任何人的感情的情况下保持讨论的简短。此外，还需要有一定程度的自信和察觉谈话中的暗语的能力。主持人不能有先入为主的想法，也不能对审查对象有个人看法，要负责收集任何结果的指标，并确保写出会议报告。

• 作者

这里的作者是指评审对象的作者。如果有多个作者，其中一个在评审会议期间承担唯一作者的角色。作者确保条目标准得到满足，换句话说，审查对象处于 "可审查 "状态。通常情况下，作者负责纠正审查期间发现的任何缺陷，因此也负责满足退出标准。作者决不能把对工作的批评当作个人行为。审查过程只是为了提高审查对象的质量。

• 评审员

评审员（有时也被称为 "检查员"）是由最多五名专家组成的小组，他们在做了适当的准备后参加评审。评审员通常是其工作被评审的项目组的一部分，但也可以是对结果有兴趣的其他利益相关者或具有专业和/或技术能力的人。
评审员的任务是识别和描述评审对象中存在问题的地方。拥有不同视角的评审员（测试人员、开发人员、最终用户、系统操作人员、商业分析师、可用性专家等等）有助于评审的有效性，尽管你要确保只有那些与评审对象相关的专家参与其中。
让个别评审员专注于评审的特定方面，可以提高评审过程的效率。例如，一个审查员可以专注于对某一特定标准的遵守，而另一个则检查程序的语法。这种角色的分配是在审查计划阶段进行的。
评审员必须明确区分评审对象中通过评审的部分和需要改进的部分。缺陷必须被清楚地记录下来，以便于识别和解决。

• 记录员

抄写员（或称 "记录员"）记录未解决的问题、未解决的问题，以及审查中产生的任何其他相关任务。该文件必须简短而精确，并且必须包括所有发生的讨论的不失真的总结。
随着专用工具变得越来越普遍，审查记录员的工作正在慢慢变得过时。如果使用了这样的工具，每个评审员都可以直接在工具界面上记录缺陷、开放性问题和决定，而不需要单独的文件。

由于实际原因，作者往往也是抄写员。作者通常清楚地知道什么是需要记录的，以便执行评审员所要求的修改。

4.4审查的类型

题外话：管理评审

在查看审阅对象时，可以发现两种审阅类型：

• 对开发过程中作为工作产品创建的文件的评审
• 对项目或开发过程本身进行分析的评审

第二组的审查被称为 "管理"、"项目 "或 "过程 "审查。它们的目的包括调查规章制度和计划是否得到遵守，分析所需任务的执行情况，以及对过程所做改变的有效性。

• 审查对象是整个项目，主要的审查目标是确定其目前的技术和经济状况，以及检查其是否按计划进行，以及项目管理的情况如何

• 管理评审通常在项目达到某个特定的规划里程碑、完成某个开发阶段时进行，或者作为支持未来项目学习过程的 "死后 "分析。

• 在敏捷项目中，这种审查通常采取 "回顾性 "会议的形式。这些会议通常在每个冲刺阶段之后举行，使团队能够比较笔记并收集关于如何在下一个冲刺阶段改进工作的想法。

• 主要目的是识别缺陷

下面将详细介绍第一种类型的审查，其主要目的是通过调查文件来识别缺陷。你执行的审查类型取决于项目的性质、可用的资源、审查对象的类型、潜在的风险、业务领域、公司文化和其他标准。
审查可以是非正式的审查，走访，技术审查，或检查。所有这些都可以作为 "同行审查 "进行--换句话说，在公司层次结构中，有相同或相似层次的同事参与。
审查对象可以使用一种以上的审查方式进行审查。例如，非正式审查可以用来验证审查对象是否处于适合后续技术审查的状态，以及所需的努力是否合理。

• 非正式审查-没有严格的准则

非正式审查是一种 "软 "审查，它仍然遵循标准审查过程（见第4.3节），但没有严格的正式结构。非正式评审的主要目的是识别缺陷，并向评审对象的作者提供短期反馈。它也可以用来发展新的想法，并对现有问题提出解决方案。小问题也可以在非正式评审中得到解决。

• 作者/读者反馈周期

非正式审查通常是由作者发起的。计划阶段包括选择参与者和确定交付结果的日期。非正式评审的成功在很大程度上取决于评审员的技能和动机。可以使用核对表，但非正式评审通常不需要单独的会议来讨论结果。在这种情况下，非正式评审实际上只是一个简单的作者/读者反馈循环。

因此，非正式审查是由一个或多个同事对审查对象进行简单的双重检查--"伙伴检查"。学习效果和团队成员之间的互动是受欢迎的副作用。就结果而言，一份发现的问题清单或审查对象的更正/评论副本通常就足够了。诸如 "结对编程"、"伙伴测试 "和 "代码交换 "等技术也可以被视为非正式评审的一种。由于非正式评审易于组织，且涉及的工作相对较少，因此被广泛用于各种项目中，而不仅仅是在敏捷环境中。
演练

• 走读

除了识别缺陷之外，走读还可以用来检查是否符合所需的标准和项目规范。这也是一个讨论替代性实施方案的论坛，而且还可以就程序或风格的变化交换意见，从而促进参与者的学习。走读的结果应该是一种共识。
走读的重点是一个通常由作者领导的会议。结果需要被记录下来，但并不真正需要准备一份正式的记录或总结报告。检查表的使用也是可选的。与技术审查或检查相比，涉及的个人准备工作很少，演练可以在完全没有准备的情况下进行。
在会议期间，典型的使用场景被命名，并以过程为导向的方式进行演练。程序部分的模拟或测试运行（所谓的 "干运行"）也是可能的，个别测试案例也可以模拟。评审员将参与者提出的意见和问题作为识别潜在缺陷的基础。
作者负责做任何需要的修改，通常不涉及进一步的监督。

这种技术适用于五人以下的小团队，几乎不需要准备和跟进。它非常适合于检查非关键对象。在实践中，演练的范围从极其非正式到相当正式。

因为作者通常会带领大家走一遍，所以你必须注意审查对象还是要批判性地、公正地进行审查。否则，作者的潜在偏见可能导致对关键问题的讨论不足，从而扭曲了结果。

• 技术审查：欢迎其他建议

除了识别缺陷外，技术审查的主要重点是形成共识。其他目标包括评估产品质量和建立对审查对象的信心。
在技术评审中，欢迎新的想法和替代实施的建议，技术问题可以由专家来解决。为了充分发挥这种讨论的作用，作者在相同或密切相关的技术领域工作的同事应该作为评审员参与。此外，让其他领域的专家参与进来，可以帮助防止团队对自己的习惯视而不见。
个人的准备工作在技术评审中至关重要。也可以使用检查表。如果可能的话，审查会议应该由受过训练的审查主持人领导，但不是由作者领导。审稿人之间的讨论不能失控，应该坚持就作者今后可以做什么来改进他的工作达成共识。会议不是必须的，讨论可以在其他论坛上进行，例如在公司的内部网上。
审查的结果需要记录，但不是由作者记录。通常情况下，要准备一份潜在缺陷的描述清单和一份总结性的审查报告。
技术审查也可以采取多种形式，从完全非正式的到严格组织的，每个步骤都有预定的进入和退出标准，并强制使用报告模板。

如果评审员事先将他们各自的评审结果提交给会议主持人，这有助于将评审会议的重点放在最重要的地方。然后，主持人可以对这些意见进行优先排序，并利用会议讨论最重要的要点和最明显的分歧意见。
技术审查的结果是所有参与者的责任。如果你在会议期间不能达成共识，你可以举行投票来解决讨论，并将结果记录在评审报告中。
技术审查的参与者没有责任考虑他们提出的建议的后果。这是由管理层负责的。

• 检查（Inspection）正式的预定流程

检查是最正式的审查类型，遵循严格的预定流程。所有参与者都是项目专家或审查对象其他方面的专家，每个人都在审查中采取特定的角色。评审过程受规则的制约，这些规则为流程的每个方面定义了检查标准。每个检测步骤都有自己的进入和退出标准。
检查的目标是识别缺陷和不一致，确定检查对象的质量，以及建立对工作产品的信心。在这里，达成共识也是过程的一个重要部分。检查的结果应该帮助作者在未来避免类似的错误，并且像技术审查一样，帮助提高未来工作的质量。
另一个目标是改进软件开发过程（见下文）。检查的目标在计划阶段就已经确定，审查员需要解决的问题数量从一开始就受到限制。
在检查开始前，检查对象会被正式检查为 "可审查性"，并被验证是否达到了准入标准。审查员的个人准备是根据预定的规则或标准使用检查表进行的。

• 抽样检查会议

抽样检查会议可以按以下方式进行： 会议由训练有素的主持人（不是作者）主持，他介绍参与者和他们的角色，并对要检查的主题进行简要总结。主持人询问所有审查员是否有足够的准备（例如，确保所有的检查表问题都已回答）。主持人也可以问审查员花了多少时间，他们发现了多少缺陷。
首先讨论并记录影响整个对象的一般不一致之处。
然后，审查员对检查对象的内容进行简明而有逻辑的介绍。如果有必要，可以宣读部分材料（但不是由作者宣读）。这时其他审查员可以提出问题，并且可以详细讨论对象的选定方面。作者（不能是评审组长、主持人或抄写员）回答任何直接问题。如果审查员和作者不能就如何处理某个问题达成一致，在会议结束时进行表决。

如果讨论偏离主题，则由主持人进行干预。主持人还必须确保涵盖检查对象（和一般对象）的所有选定方面，并明确记录所有缺陷和不一致之处。
在会议结束时，所有的缺陷都会被提出来，并由所有参与者检查是否完整。对任何未解决的问题进行简要讨论，但不讨论可能的解决方案建议。如果对未解决的问题是否代表缺陷没有达成共识，这种差异将记录在报告中。最后的报告总结了检查的所有结果，并提供了所有潜在缺陷的描述清单。
最后，对检查进行评估，并决定检查对象是否需要更多的工作。在检查过程中，所做的任何改变和后续工作都是正式的规范。

• 对开发和审查过程的额外评价

检查过程中收集的一些数据也可以用来确定开发过程中的薄弱环节的原因，从而提高其质量。这些数据也可用于改进检查过程本身。两个过程质量的任何改善都可以通过比较任何改变前后收集的数据来验证。

这种类型的审查通常被称为设计、代码或软件检查。这个名字是基于被检查的文件的类型。然而，如果存在正式的审查标准，所有类型的文件都可以被检查。

• 选择审查的类型

什么时候以及使用什么类型的检查取决于你所追求的目标，所要求的质量，以及这将花费的精力。项目环境对这些决定也很关键，不可能做出具体的建议。你必须根据不同的项目来决定哪种审查方式最适合当前的情况。下面的问题将帮助你决定进行哪种类型的审查：
审查结果的形式可能是一个因素。你需要一个全面的报告，还是一个没有记录的执行结果就足够了？
安排时间是容易还是困难？找到一个五位、六位或七位专家都有时间的日期可能是很难的工作。
审查是否需要来自多个学科的专家？
评审员需要对评审对象有多少具体的了解？
评审员有多大的动力花时间和精力集中在计划的评审上？
计划的努力与预期的结果是否相称？
审查对象有多正式？基于工具的分析能否在审查前进行？
你有多大的管理支持？如果时间紧迫，审查是否可能被限制甚至被砍掉？

4.5关键因素、好处和限制

• 提高质量和降低成本

审查是保证被调查的工作产品的质量的有效工具。理想情况下，审查将在工作产品定稿后立即进行。这样，任何不一致或缺陷都能及时发现，作者也能尽快得到反馈。解决任何问题都会使有关文件的质量得到提高，从而对开发过程产生有利的影响，这样就可以在减少缺陷的牵引下继续进行开发。此外，静态测试经常会发现一些使用动态测试很难（或不可能）发现的缺陷（见4.6节）。
通过审查早期识别和纠正缺陷，通常比后来在应用程序已经达到可执行的开发阶段时解决缺陷要便宜。当一个应用程序的早期版本已经交付或已经在使用时，这一点尤其正确。
静态测试通常比动态测试便宜（见第5章），因为缺陷可以直接在文件中得到纠正，不再需要进一步检查。纠正动态测试中出现的故障一般需要额外的确认或回归测试。评审往往可以节省大量的开发时间。
然而，说审查会减少成本并不总是准确的。例如，如果静态测试发现了内存泄漏，补救这个问题可能是非常耗时的。在这里，你需要区分进行审查的成本和纠正审查发现的缺陷的成本。纠正文件中的文字的成本是可以忽略不计的。换句话说，修正的努力取决于需要注意的问题的性质。
如果代码审查已经消除了测试对象（即代码）中的缺陷，并且由于审查而减少了发现进一步缺陷的风险，那么动态测试可能会涉及更少的努力。
在经过审查和纠正的文件中，减少缺陷和不一致的数量，也会减少审查期间的成本。

在审查和纠正的文件中，减少缺陷和不一致的数量也会在系统的生命周期中减少成本。例如，审查可以揭示出客户需求中的不准确之处，这些问题可以在实施前得到解决。审查也会导致系统运行时发生的故障数量减少。此外，开发过程中的生产力也会提高，因为团队将使用改进的设计和代码，更容易维护（即，理解和改变）。

• 改善团队沟通

除了提高质量和降低成本，审查对开发团队内部的合作也有积极影响：
因为审查总是在小组环境中进行，它们鼓励参与者之间的知识交流。这导致了个人工作方法的改进，从而使他们的工作质量得到普遍提高。
在小组环境中，必须以所有参与者都能理解的方式展示材料。这种清晰的需求往往会产生作者本来不会有的洞察力。
整个团队都觉得对审查对象的质量负责，结果是每个人都能理解的文件。
为了提高审查质量，或者说首先要有一个成功的审查，需要考虑各种组织和人员方面的因素。下面的章节列出了其中最重要的因素。
组织的成功因素

• 组织因素

项目管理部门通过在整个开发过程中为评审提供足够的资源来支持评审过程。
正式的评审是提前计划好的，并以明确的、可核实的目标来组织。
参与者有足够的时间为审查做准备。
原则上，所有类型的审查（例如，基于检查表或基于角色）都适合于识别审查对象的缺陷。可以根据商定的目标、被调查对象的类型和水平以及参与者的技能来选择最合适的类型。
检查表涵盖了最重要的风险，并且总是最新的。
大规模的文件是分部分而不是整体来审查的，这样可以尽快向作者提供缺陷反馈。

• 与人有关的因素

你需要选择 "正确的 "参与者来达到你计划的评审目标。选择那些技能和观点意味着他们需要理解评审对象以便继续工作的人，是最有成效的。因为评审对象通常会被用作设计测试用例的基础，让测试人员参加评审是有意义的。这样，测试人员从开发过程的一开始就熟悉了项目文件，可以马上开始指定测试用例。这种基于测试的观点也有助于质量保证的其他方面，如验证一个对象的可测试性。
评审的作用是保证被调查对象的质量，所以对缺陷、不准确和偏离计划的识别是有意的，应该鼓励。然而，审查人员必须以客观、公正的方式传达他们的发现。审查必须在信任、保密的气氛中进行，参与者应避免使用表示厌烦、沮丧或敌视其他参与者的手势。作者要确信审查的结果不会影响他在公司的地位。作者应该把审查看作是一个积极的经历，所有参与者最后都应该觉得参加审查是花了很多时间的。
参与者花时间专注于细节。审查是为了让参与者不至于失去注意力。不要试图一次性审查大型文件，并提前限制审查会议的长度。
如果有必要，在审查前为参与者提供额外的培训，特别是对于像检查这样的正式审查。
尽量鼓励学习气氛，使每个人都能从每次审查中受益。这也能提高审查过程和个人审查技术的质量。

• 为什么审查有时会失败

如果审查因准备不足而失败，这通常是由于时间安排不当造成的
如果评审员不理解评审的意义或评审过程对质量改进的有效性，你可以用当前项目（或早期项目）的数字来强调评审过程的重要性
审查会因为文件不充分或不完整而失败。在审查对象的同时，你必须确保所有的支持性文件都有必要的细节深度。只有在这种情况下，审查才应该进行。

静态测试和动态测试的区别

• 识别不同类型的缺陷

静态测试和动态测试可以用来实现相同的目标（见第2.1.2节），但通过识别不同类型的缺陷来相互补充。静态测试直接识别文档和其他工作产品中的故障，而动态测试通常识别源代码中的故障，而不是其他类型的文档（可执行模型除外）。你发现的任何故障，如果要成功解决，就必须追溯到导致这些故障的故障。故障往往在很长一段时间内没有被发现，例如，如果相应的代码只是很少被执行。因此，它需要大量的努力来设计适当的测试用例。源代码中的这些类型的故障通常更容易用静态测试来识别。

-检查 "内部 "质量

动态测试验证了测试对象的可见的、外部的行为，而静态测试的重点是提高被调查对象的内部质量。
通过审查发现的典型缺陷

下面几节详细介绍了典型的缺陷和不准确之处，这些缺陷和不准确之处可以通过评审快速而廉价地识别出来，因此也可以快速解决：
需求缺陷
在需求文件中发现的典型缺陷是：不一致、含糊不清、矛盾、差距、不准确或冗余。
软件设计缺陷
在指定系统内部接口的架构文件中发现的缺陷。当单个组件或模块之间的依赖（或 "耦合"）程度很高时，就很难完全理解和测试它们，这主要是因为创建相应的测试环境所花费的精力与结果的重要性不相称。组件/模块之间的内聚力也可以被分析。强一致性的组件负责单一的、明确定义的任务。
执行松散的任务选择的组件表示低内聚力，这和高程度的耦合一样是不利的。设计效率低下的算法和数据库结构也可以被识别。
编码缺陷
如果你有足够的时间和适当的技术人员，所有的编程缺陷都可以通过代码审查来识别。这使你能够发现没有价值的变量或从未被调用的多余的变量。你也可以用审查来检测不可达的或重复的代码。这些类型的缺陷也可以通过编译器或使用自动静态分析工具来检测，这通常比基于人的技术更快、更便宜。
对标准的偏离
标准和准则有助于实现高质量的产品，而对编程准则的不充分遵守则会导致相反的结果，即：质量差。如果清楚地知道对某些准则的遵守将被检查，那么从一开始就坚持这些准则的动力就大得多。
错误的接口规范
组件之间的接口名称和它们的参数（数量、数据类型和顺序）必须单独检查，因为不是所有的差异都会在集成过程中发现。
例如： 不正确的接口定义

NASA的火星探测器 "火星气候轨道器 "是著名的、有据可查的、不正确的接口定义的例子[URL: Mars Climate Orbiter]。系统程序员使用了多种测量系统（公制和英制），这一疏忽导致了探测器的损失。正式的代码审查可能会发现测量系统规范中的这种不一致。
安全漏洞
除了动态安全测试外，静态测试也可以帮助发现这些类型的漏洞。例如，当缓冲区溢出发生时，因为约束条件没有被明确检查，或者输入数据或SQL查询被故意操纵时。
测试基础的可追溯性或覆盖率的差距或不准确之处
我们在2.3.8节讨论了可追溯性和覆盖程度的重要性。可追溯性中的差距使可追溯性本身变得毫无用处，因为你不能再在需求和相应的测试用例之间建立联系。在退出标准和所需的覆盖程度方面的不准确也使这些方面无法使用，并可能导致不正确的估计或扭曲的结果。例如，审查报告可以指出已完成的退出标准的缺失测试。

• 可维护性

软件系统通常有惊人的长生命周期，使可维护性成为任何系统的重要方面。大多数可维护性的缺陷可以通过静态测试来识别。这些缺陷包括不正确的模块化（见上面的耦合和内聚），单个组件的不良重用性，以及难以修改的复杂代码，因此在修改时增加了产生新故障的风险。

4.7总结

• 每个工作产品（即每个文件）都可以被审查，只要所有参与审查的人都知道如何阅读和理解有关的文件。
• 评审是静态测试，与动态测试不同，不需要执行代码。这意味着评审可以在任何时候适用于软件开发过程中使用的或由软件开发过程中创造的所有形式的工作产品。
• 多双眼睛比单双眼睛看到的东西更多，这一点同样适用于软件开发。用于监控和提高质量的审查就是基于这一原则。文件由一个以上的人检查，并在专门的会议上讨论和记录结果。
• 评审过程中涉及的活动有：计划、启动、个人准备（即个人评审）、讨论结果（问题交流和分析，通常在专门的会议上）、修复和报告。
• 为了在个别审查阶段更好地识别缺陷，你可以使用各种不同的审查技术：
  • 临时性的
  • 无规则
  • 基于检查表：预先制定的问题支持审查过程
  • 场景和模拟运行：场景的运行
  • 基于角色：参与者在审查中采用特定的角色
  • 基于观点：对评审对象的不同看法
• 需要为审查分配的角色有经理、审查负责人、促进者（主持人）、作者、审查员（专家）和抄写员。
• 评审的类型有很多，由于相关的标准没有使用统一的术语，所以用来描述它们的名称也会有所不同。在本章中，我们讨论了以下四种审查类型：
  • 非正式审查不遵循任何正式的规则，所产生的文件的形式也没有规定。因为它涉及的工作相对较少，所以非正式审查过程已经成为一种广泛接受和使用的技术。
  • 走读是一种非正式的技术，即作者在会议上向评审员介绍文件。在这里，准备工作也是最少的。走读是小型开发团队的理想选择，他们需要讨论替代方案并在团队中分配知识。
  • 技术审查遵循更严格的流程，个别审查员的准备工作是必不可少的。评审员应该是作者的专业同事，这样可以讨论替代方案的实现。
  • 检查是这些类型的审查中最正式的。准备工作以检查表为基础，每个审查步骤都有自己的进入和退出标准。审查会议由经过培训的主持人主持。除了检查工作产品的质量外，检查的目的是改善开发和审查过程。
• 为了使其尽可能有效，审查一般是根据公司的具体要求进行的。最重要的因素之一是在软件开发过程中的所有参与者之间建立一种合作氛围。
• 如果你牢记适当的组织和与人相关的成功因素，只要你注意避免已知的陷阱，审查可以成为提高软件开发项目质量的一个严肃有效的工具。
• 评审通常会发现与动态测试不同的缺陷。