主要测试分析方法及其特点

从测试方法上来看，大致可以分成黑盒测试和白盒测试两种。黑盒测试是把测试对象看做一个黑盒，测试时不需要考虑内部的逻辑结构和内部特性，只需要检查程序的功能是否符合它的预期。白盒测试把测试对象看做一个打开的盒子，测试人员通过程序的逻辑结构设计测试用例，对程序的所有逻辑进行测试，确定是否与预期结果一致。黑盒测试包含：边界值分析、因果图、组合测试、决策表测试、缺陷分类、基于缺陷的技术、域分析、错误推测、等价类划分、状态转换测试、用例测试、用户故事测试等。白盒测试包含：条件测试、判定条件测试、改进的条件/判定覆盖、复合条件测试、路径测试、API测试、控制流分析、圈复杂度、数据流分析、静态分析等。

边界值分析

边界值分析用于测试有序等价类边界上的数据。有两种边界值分析法：二值测试法或三值测试 法。二值测试法，取一个边界值（正好在边界上的值），一个刚刚超过边界的值（可能的最小增幅）。边界值分析的覆盖率定义为：测试的边界条件总数／识别的边界条件总数。边界值分析可以用于：

• 数值范围

• 非数值变量的数值特性（如，长度）

• 循环（包括在用例中的循环）

• 存储的数据结构

• 由时间确定的活动

边界值分析的精确性取决于等价类划分的精确。必须注意有效数据和无效数据的增幅以便于精确地定义测试数据。

因果图

因果图可以从各种描述程序功能逻辑（规则）的资源中导出，如从用户故事、流程图等。因果图有助于 获得程序逻辑结构的概图，典型地用做决策表的基础。用因果图和/或决策表捕获决策可以让我们系统地 达到程序逻辑所需要的测试覆盖。

• 覆盖率 = 用例覆盖的因到果的线条／所有可能的因到果的线包括条件的组合。

因果图适用的测试级别和情况与决策表一样。尤其是因果图展示了条件组合引起的结果（因果关系）和 排斥的结果（非），多个条件均为真引起的特定结果（与）和某一条件为真引起的特定结果（或）。因果图需要更多的时间和精力。也要求工具的支持。因果图的设计者和使用者都必须理解图中的特殊表达符号。

组合测试

当软件测试使用多个参数，每个参数有多个值，值的组合太多，以至于要完全测试这些组合在时间上根 本不可行，这时可以采用组合测试技术。这里的参数必须是独立的和兼容的，任何参数的任何选项可以 与任何其他参数的任何选项组合。

组合测试中的覆盖率主要指分层覆盖率：

• 1-维（1-wise）或单覆盖 = 每个参数的每个值至少在所选择的 组合中出现一次

• 2-维（2-wise）或成对覆盖 = 要求任意两个参数的每一 对值至少包含在一个组合中

• n-维覆盖 = 要求选定组合中包括任何n 参数值的所有子组 合。n 越大，要达到100％的覆盖率的组合也就越多。

如果参数可以取很多值，应该先通过等价类分析或其他的选择机制来减少每个参数的测试值，然后再使 用组合测试来降低组合的测试值子集。 这些技术通常应用在集成测试级别、系统测试级别和系统集成测试级别。

有时很难确定参数和它们各自的值。某些参数之 间有一个意想不到的交互，手动寻找一个组合的最小集合并满足一定程度的覆盖很困难。

决策表测试

决策表是用来测试组合条件之间的相互作用。决策表提供了一个明确的方法来测试验证所有相关条件组 合和验证被测软件所有可能组合的操作。决策表测试的目标是确保每个条件、关系和约束的组合被测试 到。当试图测试每个可能的组合时，决策表可能会变得非常庞大。智能地将所有可能组合减少到真正“感兴趣”的组合，这种方法被称为精简的决策表测试。

• 覆盖率 = 条件组合用例／所有可能的条件组合。

决策表测试适用于集成、系统和验收测试级别。当需求定义采用流程图和业务规则表时，特别适合使用这种技术。充分的边界值分析、等价类划分是与决策表技术相互补充的。找出所有参与交互的条件具有挑战性，尤其当需求定义不完善，或者根本不存在时。

缺陷分类

缺陷分类法是分类的缺陷类型列表。这些列表可以很通用，作为高层次的指南，也可以是非常具体的。

基于缺陷的技术

根据已知的缺陷类型来系统地获取测试用例的技 术。也称之为故障注入测试，主要是以逆向思维和异常场景为思考导向。通常用于系统测试居多。对不同类型的软件有标准的缺陷分类。可以包括缺 陷类型、根源、失效症状、风险场景 清单、特定 类型缺陷。缺陷类型的分类一般基于经验，对新型业务很难有依据

域分析

域是一个定义的值的集。集可以是一个单变量的值域范围（一维域，例如，“在24岁以上和66岁以下的 男子”），或是相互作用的几个变量的值域（多维域，如范围“男性年龄在24以上66岁以下，体重在69 公斤以上，90公斤以下”）。一维域的分析通常使用等价类划分和边界值分析。在多维域的情况下，用等价类和边界值等方法生成的测试用例数会随着变量数增长呈指数上升，而采用域分析方法测试用例数呈线性增长。

• 最小覆盖 = 对应于每个域的IN、ON、OFF和OUT值都有一个测试用例。

域分析结合决策表、等价类和边界值可以生成较小的测试集，该集覆盖了重要的和容易失效的区域。任何测试级别都可以使用域分析，但大 部分时候用在集成测试和系统测试级别。做完整的域分析需要对需求有非常深入的理解，以确定不同域和域之间可能的相互作用。

等价类划分

等价类划分（EP）用于降低测试用例数，这类测试用例有效地测试软件的输入、输出、内部值和时间相关值的处理。划分是用来创建等价类（通常称作等价类划分），等价类划分将数据分成不同的组，软件 会用相同的方式处理同组内的任何数据。假定要覆盖同一等价类中的所有数据，只需从这些数据中选取一个代表值。

• 覆盖率 = 被测代表值的等价类个数／总的识别出的等价类个数（测试同一等价类的多个代表值不 会增加测试覆盖）。

等价类划分普遍用于新版本或新发布的冒烟测试，因为它可以快速确定基本功能是否工作，经常和边界值划分组合使用。在使用时要理解隐含的一些处理方式，例如，输入可为正数，也可为负数的时候，最好将正数、负数划为两个不同的等价类。

状态转换测试

状态转换测试用于测试软件通过有效或无效的转换进入和退出定义的状态的能力。事件引起软件从一个 状态转移到另一个状态并执行相应的行动。事件可以是满足某些影响转换路径的条件（有时也叫关条件 /guard conditions 或转换关/transition guards）。例如，用有效用户名和密码组合的登录事件与用无效 密码组合的登录事件引起的转换是不同的。

相对于其他类型的测试技术而言，状态转换测试的测试覆盖率分层次：

• 最低覆盖率 = 到过的每个状态 ／遍历每一个转换。
  

• 100％覆盖率 = 保证访问 了每个状态和遍历每个状态转换
  

• “n-切换覆盖”指覆盖状态转换的数目。（100% 1-切）
  

• “往返覆盖”在转换序列形成循环的情况下适用。
  

状态转换测试用于测试有定义的状态和引起状态转换的事件或场景。定义状态表或状态图时确定状态往往是最困难的部分。

用例测试

用例测试模拟系统行为提供事务性的、基于场景的测试。用例定义了参与者和系统之间为达到某种目的 进行的互动。参与者可以是用户也可以是外部系统。

• 最小覆盖 = 每个主路径（正向）一个测试用例+每个替代路径（流）一个测试用例

• 100%覆盖：测试的路径 = 主路径和 替代路径的和。

用例测试一般被用于系统测试和验收测试级别。视集成水平高低也可以被用于集成测试，视组件的行为 甚至也可以被用于组件测试。用例测试常作为性能测试的基础，因为它更接近系统的真实使用。用例中 描述的场景有可能会被分配给虚拟用户来生成系统实际的负载。用例必须与真实使用相吻合才能保证测试的有效性。精确定义不同的替代路径（流）对测试的覆盖率很重要。

用户故事测试

主要用于敏捷方法中，如Scrum，需求是以用户故事的形式呈现，主要描述在一个迭代中可以设计、开发、 测试和演示的小的功能单元。

• 最低覆盖 = 验证每个定义的验收标准都已满足。

用户故事测试主要用于功能测试和非功能测试，用于所有级别的测试，期望开发人员在交付代码给下一级测试（例如，集成测试，性能测试）之前向测试团队成员演示为 用户故事实现的功能。因为US是功能的小增量，有可能要求有驱动程序和桩，以实现交付的功能件测试。这通常需要编程能 力和使用有助于测试的工具，比如API测试工具。

条件测试

在判定（分支）测试中将判定看作一个整体，测试用例分别评估真和假的结果，而条件测试考虑的是在 判定中的单个简单的“原子”条件。每个判定语句是由一个或多个简单的“原子”条件组成，而每个 “原子”条件能计算出一个布尔值（真/假），这些值的逻辑组合便得出判定的最终结果。测试用例必须 评估每个原子条件的两个真值（真和假），以达到覆盖率的要求。当一个判定只有单个的原子条件，条件测试等同于判定测试。

• 条件覆盖率：用例涉及的条件组合／所有条件组合

• 判定覆盖率：用例涉及的结果组合／所有条件组合会有的结果组合

当一个判定中存在两个或两个以上的原子条件，在测试设计过程中，如果没有很好地选择测试数据，会导致只达到条件覆盖而没有达到判定覆盖。

判定条件测试

判定条件测试明确要求测试必须达到条件覆盖，同时，也要求满足判定覆盖。在不需要增加额外的测试用例以达到条件覆盖的情况下，对原子条件的测试数据 值做出慎重的选择可以达到这一覆盖要求。

• 判断覆盖率 ：用例涉及的结果组合／所有条件组合会有的结果组合。

测试过程中往往需要比判定覆盖更多的测试用例，当时间很紧迫时，就可能存在困难。

改进的条件/判定覆盖

改进的条件/判定覆盖提供了一个更强的控制流覆盖级别。假设在N个单独的原子条件下， MC/DC通常可以得到 N+1个单独的测试用例。MC/DC实现了判定条件覆盖，但是需要满足以下条件：1. 至少在一个测试中，判定结果会随着原子条件X 是否为真而改变 2. 至少在一个测试中，判定结果会随着原子条件X 是否为假而改变 3. 每个不同的原子条件都有满足条件1和2的测试。

当一个表达式中某个特定的项多次出现时，要达到MC/DC覆盖变得较为复杂。根据代码中的判定语句，可能无法仅通过改变重叠项的值去改变判定的输出结果。

复合条件测试

在极少数情况下，可能需要测试所有可能的判定内所包含的真/ 假数值组合。这种穷尽级别的测试被称作复合 条件覆盖。这种测试技术历来被用于测试嵌入式软件，因为这种软件需要确保其很长一段时间内的运行稳定可靠和不崩溃。

所需的测试数目依赖于判定语句中的原子条件个数，同时该测试数目可以由计算2的n次方来确定，n是未重叠的原子条件个数。种方法所需的测试用例的绝对数量非常庞大，在很多情况下更适合采用MC/DC覆盖。

路径测试

路径测试包括识别贯穿于代码中的路径，然后创建相关测试来覆盖这些路径。原则上，测试每一条贯穿 于系统的独特路径都是非常有用的。策略的关键点是代码中每个可能的分支至少测 试过一次，也可能多次。

• 覆盖率 = 用例涉及的路径／所有路径（不考虑循环）

因为代码中存在循环而使得测试用例的 数目会变得非常庞大。虽然有可能使用控制流程图来确定路径，在现实中还是需要利用工具对复杂模块的路径进行计算。

API测试

逆向测试在API测试中很重要。由于API之间经常松散耦合，会导致实际的交易/事务丢失或时序出现问题，这使恢复和重试机制的全 面测试成为必要。提供API接口的组织必须确保所有的服务具有非常高的可用性。这往往需要由API发 布者和基础构架支持者提供严格的可靠性测试。

• 最低级覆盖率：每个API至少被执行一次，以及所有有效／无效的输入值组合

API背后的逻辑往往复杂且有各种依赖联动，需要多做测试分析。

控制流分析

控制流分析是一种静态分析技术，借助于控制流图或使用工具来分析程序的控制流。运用这种技术可以 发现许多系统中的异常，包括设计不当的循环（例如，有多个入口点）、在某些语言（比如， Scheme）中模棱两可的函数调用的目标、不正确的操作序列。

圈复杂度

圈复杂度通常是用来量化一个模块整体的复杂程度。系统 越复杂，就越难维护，且会包含更多的缺陷。多年来许多研究指出了复杂度和包含缺陷数目的相关性。NIST（美国国家标准和技术研究所）建议以10作为最大圈复杂度值。任何一个模块，如果它的复杂度 很高（超过10），则应该将此模块划分成多个模块。

数据流分析

数据流分析包含了多种用以收集关于系统中变量使用信息的相关技术。这里，对变量的生命周期（即， 何处变量被声明了、被定义了、被读取了、被评估和被撤销了）进行详细的研究，因为异常可能发生于 变量生命周期中的任何操作。

静态分析

静态分析的目标是检测代码和系统架构中实际的或潜在的缺陷并提高其维护性。静态分析可以有工具的支持，例如代码扫描。