4.测试技术
4.1.测试技术分类
4.1.1. 测试技术分类和特点
黑盒测试技术（也称为行为的或基于行为的技术）基于对适当测试依据的分析（例如：正式
需求文档、规格说明、用例、用户故事或业务流程）。这些技术适用于功能和非功能测试。黑盒测
试技术关注在测试对象的输入和输出，而不考虑其内部结构。
白盒测试技术（也称为结构的或基于结构的技术）基于对架构、详细设计、内部结构或测试
对象代码的分析。与黑盒测试技术不同，白盒测试技术关注在测试对象的结构和处理过程。
基于经验的测试技术利用开发人员、测试员和用户的产品经验来设计、实施和执行测试。这
类技术通常与黑盒和白盒测试技术相结合。
4.2 .黑盒测试技术
4.2.1. 等价类划分
- 有效值是组件或系统应接受的值。包含有效值的等价分区称为“有效等价类”。
- 无效值是组件或系统应拒绝的值。包含无效值的等价分区称为“无效等价类”。
- 每个值必须属于一个且只有一个等价类。
- 当测试用例中使用无效等价类，应单独测试，即不能与其他无效等价类组合，以保
证没有失效屏蔽。当多个失效同时发生，但只能观察到一个失效时，其他失效被屏
蔽了，这导致无法发现其他失效。
要使用此技术实现 100％覆盖率，测试用例必须通过使用每个等价类中至少一个值来覆盖所
有已识别的等价类（包括无效等价类）。覆盖度量为至少有一个值已经测试过的等价类的数量除
以所识别的等价类的总数，通常表示为百分比。等价类划分适用于所有测试级别。
4.2.2. 边界值分析
边界值分析可以应用于所有的测试级别。这个技术通常用来测试需要调用一系列数字的测
试需求（包括日期和时间）。对区域的边界值覆盖度量是测试的边界值数量除以识别的边界测试
值总数，通常用百分比表示
4.2.3. 判定表测试
判定表测试的最小覆盖标准通常是对判定表中每个判定规则至少有一个测试用例。这通常涉
及覆盖所有条件的组合。覆盖度量是至少被一个测试用例测试过的判定规则的数量，除以判定规
则总数，通常以百分比表示。
4.2.4. 状态转换测试
覆盖度量通常是识别出已测试状态或已测试转换的数量，除以测试对象已识别出的状态或转
换的总数，一般以百分比表示。
4.2.5. 用例测试
测试可以从用例中推导出来，用例是设计软件项交互的一种特殊方式，包含了软件功能的需
求。用例关联了参与者（用户、外部硬件或其他组件或系统）和主体（用例所应用的组件或系统）。
每个用例规定了一个主体能与一个或多个参与者合作开展的一些行为（UML 2.5.1 2017）。
一个用例能通过交互和活动以及前置条件、后置条件进行描述，如合适，还可以以自然语言进行
描述。参与者和主体之间的交互可能导致主体的状态改变。交互可能以工作流、活动图，或业务
流程模型的图示方式表示。
用例包含了其基本行为的可能变化，包括期望行为和错误处理（系统对程序、应用和通讯错
误的反应和恢复，例如，导致一个错误信息）。设计测试来执行已定义的行为（基本的、异常的或
替代的和错误处理）。覆盖度量是已测试的用例行为数除以用例行为的总数，通常以百分比表示。
4.3.白盒测试技术
4.3.1. 语句测试和覆盖
语句测试执行代码中可执行语句。覆盖度量是被测试执行的语句数，除以测试对象中可执行
语句总数，通常以百分比表示。
4.3.2. 判定测试和覆盖
判定测试执行代码中的判定，以及测试基于判定结果的可执行的代码。为此，测试用例跟随
发生在判定点的控制流（例如，针对 IF 语句,一个对真（true）结果和一个对假（false）结果；
针对 CASE 语句，测试用例将要求对所有可能结果，包括缺省（default）结果进行覆盖）。
覆盖度量是被测试执行的判定结果数，除以测试对象中判定结果的总数，通常以百分比表示。
4.3.3. 语句和判定测试的价值
当实现 100％语句覆盖时，它确保代码中的所有可执行语句至少已被测试过一次，但不能确
保所有判定逻辑都已被测试过。在本大纲中讨论的两种白盒技术中，语句测试可能提供的覆盖低
于判定测试。
当达到 100％的判定覆盖时，它会执行所有判定结果，包括测试取值为真（true）的结果和
取值为假（false）的结果，即使没有清晰的假（false）语句（例如，IF 语句的代码中没有 else）。
语句覆盖有助于发现那些未被其他测试执行到的代码中的缺陷。判定覆盖有助于发现那些在其他
测试中没有对其所有真值（“真”/“假”）都执行到的代码（例如，判定语句）中的错误。
实现 100％的判定覆盖可保证 100％的语句覆盖（但反之不成立）。
4.4.基于经验的测试技术
4.4.1. 错误推测
错误推测法是一种基于测试员的知识来预估错误、缺陷和失效发生的技术，包括：
- 应用软件在过去是如何工作的
- 常犯的错误类型
- 在其它应用软件中发生的失效
错误推测技术的一个系统化方法是创建一个可能的错误、缺陷和失效的列表，并设计测试以
发现失效以及导致它们出现的缺陷。可以根据经验或缺陷和失效的信息，也可根据软件故障原因
的一般知识创建此错误、缺陷和失效列表。
4.4.2. 探索性测试
在探索性测试中，在测试执行期间动态地设计、执行、记录、和评估非正式的（非预定义的）
测试。测试结果常用来进一步了解组件或系统，并对可能需要进一步测试的区域生成测试。
探索性测试有时通过基于会话的测试来构造活动。在基于会话的测试中，探索性测试在定义
的时间盒内进行，测试员使用包含测试目标的测试章程来指导测试。测试员可能使用测试会话表
格来记录随后步骤和发现。
探索性测试在规格说明文档较少或不充分，或测试的时间压力大的情况下是最有帮助的。探
索性测试作为对其他更正式的测试技术的补充也是有用的。
探索性测试与应对性（reactive）测试策略高度相关（参见第 5.2.2 节）。探索性测试能与其
它黑盒、白盒和基于经验的技术组合使用。
4.4.3. 基于检查表的测试
在基于检查表的测试中，测试员设计、实施和执行测试来覆盖检查表中的测试条件。作为分
析的一部分，测试员可以创建新的检查表或扩充现有的检查表，但测试员也可能使用没有修改的
现有检查表。可以基于检验、对用户重要内容的了解，或对软件失效的原因和方式的理解来构建
检查表。
可产生用于支持各种测试类型的检查表，包括功能和非功能测试。在没有详细测试用例的情
况下，基于检查表的测试能提供指南和在一定程度上保持一致性。由于它们是概要性的列表，因
此在实际测试中往往会出现一些变化和衍生，可能导致更高的覆盖，但又保持了低重复性。
若本文有帮助到阅读本文的同学，欢迎点赞、关注、收藏，互相学习交流。
