3.1 静态测试基础

静态测试不需要执行被测软件，通过人工检查（例如评审）或借助工具（例如静态分析），对代码、过程规格说明、系统架构规格说明或其他工作产品进行评估。测试目的包括提高质量、检测缺陷以及评估可读性、完整性、正确性、可测试性和一致性等特性。静态测试可用于验证和确认。

测试人员、业务代表和开发人员在实例映射（example mapping）、协作用户故事编写和待办列表（backlog）细化会议期间紧密合作，以确保用户故事和相关工作产品满足定义的准则，例如“就绪的定义”。可以应用评审技术来确保用户故事完整且易于理解，并包含可测试的验收准则。通过提出恰当的问题，测试人员能够深入探索、质疑并协助改进所提出的用户故事。

静态分析可以在动态测试之前识别问题，通常所需工作量相对较小，因为静态测试不需要测试用例，并且通常使用工具。静态分析通常被整合到持续集成框架中。虽然静态分析主要用于检测特定的代码缺陷，但也可用于评估维护性和信息安全性。拼写检查工具和可读性工具是静态分析工具的实例。

3.1.1 静态测试可检查的工作产品

使用静态测试进行检查。例如，需求规格说明文档、源代码、测试计划、测试用例、产品代办项、测试章程、项目文档、合同和模型。

对于静态分析来说，工作产品需要结构化，以便对其检查（例如，具有形式化语法的模型、代码或文本）。

不适合进行静态测试的工作产品包括难以人为解释的工作产品，以及不应该通过工具进行分析的工作产品（例如，由于法律原因，不应该对第三方可执行代码进行分析）。

3.1.2 静态测试的价值

静态测试可以在软件开发生存周期的早期阶段检测缺陷，从而实现早期测试的原则。静态测试还可以识别动态测试无法检测到的缺陷（例如，无法访问的代码、没有按预定实现的设计模式、不可执行的工作产品缺陷）。

静态测试提供了评估工作产品的质量和建立对工作产品信心的能力。通过验证文档化的需求，利益相关方还可以确保这些需求真正描述了他们的实际需要。由于静态测试可以在软件开发生存周期的早期进行，因此可以在利益相关方之间建立共识。利益相关方之间的沟通也将得到改善。因此，建议更广泛的利益相关方参与静态测试。

尽管实施评审的成本可能很高，但项目总体成本通常比不进行评审低得多，因为实施评审的项目后期修复缺陷所需的时间和工作量较少。

静态分析可以更有效地检测代码缺陷，从而减少代码缺陷的数量，并且降低开发的总体工作量。

3.1.3 静态测试和动态测试的差异

静态测试和动态测试相辅相成。二者具有相似的目的，例如支持工作产品中缺陷的检测，但也存在一些差异，例如：

• 静态测试和动态测试（通过失效分析）都可以检测错误，但是有些错误类型只能通过静态测试或动态测试来发现。

• 静态测试直接发现缺陷，而动态测试引发失效，并通过随后的分析确定相关缺陷。

• 静态测试可以更容易检测出在代码路径上的缺陷，这些缺陷在动态测试中很少被执行，或很难到达。

• 静态测试可用于不可执行的工作产品，而动态测试只能用于可执行的工作产品。

• 静态测试可用于测量不依赖于执行代码的质量特性（例如，维护性），而动态测试可用于测量依赖于执行代码的质量特性（例如，性能效率）。

通过静态测试更容易发现的典型缺陷包括：

• 需求缺陷（例如，不一致、含糊不清、矛盾、遗漏、不准确、重复）。

• 设计缺陷（例如，低效的数据库结构、模块化程度低）。

• 特定类型的代码缺陷（例如，未定义值的变量、未声明的变量、无法访问或重复的代码、过度复杂的代码）。

• 与标准的偏差（例如，未遵守编码规范中的命名约定）。

• 错误的接口规格说明（例如，参数的数量、类型或顺序不匹配）。

• 特定类型的安全性漏洞（例如，缓冲区溢出）。

• 测试依据覆盖的差距或不准确（例如，验收准则的漏试）。

3.1 静态测试基础