《软件测试的艺术》第四章测试用例的设计

4.0 前言
4.1 白盒测试
- 逻辑覆盖测试
- - 语句覆盖
  - 判定覆盖/分支覆盖
  - 条件覆盖
  - 判定/条件覆盖
  - 多重条件覆盖
4.2 黑盒测试
- 4.2.1 等价划分
- - 4.2.1.1 确定等价类
  - 4.2.1.2 生成测试用例
- 4.2.2 边界值分析
- 4.2.3 因果图
4.3 错误猜测
4.4 测试策略
4.5 小结

4.0 前言

本书第二章已经证明穷举的黑盒和白盒测试通常是不可能的，但同时也建议：将这两种测试的要素组合起来得到一种合理的测试策略。 我们可以通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试。

4.1 白盒测试

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。

逻辑覆盖测试

下图是一个普通的程序流程图，其中有两个判定语句和两个复制语句，以及四条路径L1：ace，L2：abd，L3：abe，L4：acd。

语句覆盖

语句覆盖每条语句至少执行一次。

我们可以创建一个测试用例（2，0，4）使得覆盖图中所有的语句（包括判定语句和赋值语句），也就是走L1路径，它并没有覆盖所有的路径，因此语句覆盖的覆盖程度最低。

判定覆盖/分支覆盖

判定覆盖又称分支覆盖，它不仅每个语句执行一次，而且每个判断都必须有“是”和“否”的结果、每个入口点（包括ON单元）都必须至少被调用一次。判定覆盖通常可以满足语句覆盖，但是仍然有至少三种例外情况：

程序中不存在判断
程序或子程序/方法有多重入口点。只有从程序的特定入口点进入时，某条特定的语句才能执行到。
在ON单元里的语句。遍历每条分支路径并不一定能确保所有的ON单元都能执行到。

在图4-1中两个涵盖了路径ace和abd，或涵盖了路径acd和abe的测试用例就可以满足判定覆盖的要求。如果我们选择了后一种情况，两个测试用例的输入是A=3，B=0，X=3和A=2，B=1，X=1.

条件覆盖

在条件覆盖的情况下，要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。因为这并不总能让每条语句都执行到，因此作为对这条准则的补充就是对程序或子程序，包括ON单元的每一个入口点都至少调用一次。

上图中的条件取值组合以及测试用例如下：

可以看出来即使条件组合覆盖比较复杂，但是还没有覆盖所有的路径，因此我们需要覆盖强度更高的逻辑覆盖。

判定/条件覆盖

判定/条件覆盖将一个判断中的每一个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。

由于逻辑与和逻辑或表达式存在短路的情况，因此，条件覆盖或者判定/条件覆盖准则不一定会发现逻辑表达式中的错误，因为有的路径可能根本不会被执行。

多重条件覆盖

多重条件覆盖将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。

总的来说，对于包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例，实现：（1）将每个判断的所有结果都至少执行一次；（2）将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序，最简单的测试准则就是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。

4.2 黑盒测试

基于程序规格说明书黑盒测试的目标是找出程序不符合规格说明书的地方。

4.2.1 等价划分

一个好的测试用例描述为具有相当高的可能性发现某个错误来，因此，当测试某个程序时，我们就被限制在从所有可能的输入中努力找出某个小的子集，这个子集必须是正确的，并且是可能发信最多错误的子集。

确定这个子集的一种方法，就是要意识到一个精心挑选的测试用例还应具备另外两个特性：

严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量。这个特性意味着每个测试用例都必须体现尽可能多的不同的输入情况，以使最大限度地减少测试所需的全部用例的数量。
它覆盖了大部分其他可能的测试用例。也就是说，它会告诉我们，使用或不使用这个特定的输入集合，哪些错误会发现，哪些会被遗漏掉。这个特性意味着应该尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理地假设测试每个等价类的代表性数据等同于测试该类的其他任何数据。

这两种思想形成了称为等价划分的黑盒测试方法。第二种思想可以用来设计一个“令人感兴趣的”输入条件集合以供测试，而第一个思想可以随后用来设计涵盖这些状态的一个最小测试用例集。

使用等价划分方法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成测试用例。

4.2.1.1 确定等价类

确定等价类是选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。我们确定了两类等价类：有效等价类代表对程序的有效输入，而无效等价类代表的则是其他任何可能的输入条件（即不正确的输入值）。

一些指导原则：

如果输入条件规定了一个取值范围（例如，“数量可以是从1到999”），那么就应确定出一个有效等价类（1<数量<999）以及两个无效等价类（数量<1，数量>999）。
如果输入条件规定了取值的个数（例如，“汽车可登记一至六名车主”），那么就应确定出一个有效等价类和两个无效等价类（没有车主，或车主多于六个）。
如果输入条件规定了一个输入值的集合，而且有理由认为程序会对每个值进行不同处理，那么就应为每个输入值确定一个有效等价类和一个无效等价类。
如果存在输入条件规定了“必须是”的情况，例如“标识符的第一个字符必须是字母”，那么就应该确定一个有效等价类（首字母是字母）和一个无效等价类（首字母不是字母）。

4.2.1.2 生成测试用例

为每个等价类设置一个不同的编号。
编写新的测试用例，尽可能多地覆盖那些尚未被覆盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。
编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。（用单个测试用例覆盖无效等价类，是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。）

4.2.2 边界值分析

所谓边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

边界值分析方法与等价划分方法的不同：

与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。
与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。

通用指南：

如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例。例如，如果输入值的有效范围是-1.0至+1.0，那么应针对-1.0,1.0，-1.001和1.001的情况设计测试用例。
如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例。例如，如果某个输入文件可容纳1~255条记录，那么应根据0、1、255和256条记录的情况设计测试用例。
对每个输出条件应用指南1。例如，如果某个程序员按月计算FICA的扣除额，且最小金额是$0.00，最大金额是$1165.25，那么应该设计测试用例来测试扣除$0.00和$1165.25的情况。此外，还应观察是否可能设计出导致扣除金额为负数或超过$1165.25的测试用例。注意，检查结果空间的边界很重要，因为输入范围的边界并不总是能代表输出范围的边界情况。
对每个输出条件应用指南2。如果某个信息检索系统根据输入请求显示关联程度最高的信息摘要，而摘要的数量从未超过4条，则应编写测试用例，是程序显示0条、1条和4条摘要，还要设计测试用例，导致程序错误地显示5条摘要。
如果程序的输入或输出是一个有序序列，则应特别注意该序列的第一个和最后一个元素。
此外，发挥聪明才智找出其他的边界条件。

4.2.3 因果图

边界值分析和等价划分的一个弱点是未对输入条件的组合进行分析。对输入组合进行测试并不是简单的事情，因为即使对输入条件进行了等价划分，这些组合的数量也是个天文数字。如果在选择输入条件的子集时没有采用一个系统的方法，很可能选择出一个任意的输入条件子集，这样会使测试没有什么成效。

因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和不明确之处。

因果图是一种形式语言，用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路，但没有使用标准的电子学符号，而是使用了稍微简单点的符号。

生成测试用例的过程如下：

将规格说明分解为可执行的片段。
确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类。所谓“果”，是指一个输出条件或系统转换（输入对程序或系统状态的延续影响）。例如，如果某个事物引起文件或数据库记录被修改，那么这种改变就是一个系统转换，而系统反馈的确认信息就是一个输出条件。因果关系一旦确定下来，每个“因”和“果”都被赋予一个惟一的编号。
分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。这就是所谓的因果图。
给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。
通过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。
将判定表中的列转换为测试用例。

建立有限项的判定表的过程：

选择一个“果”（动作）作为当前状态（1）。
对因果图进行回溯，查找导致该“果”为1（根据约束条件）的所有“因”的组合。
在判定表中为每个“因”的组合生成一列。
对于每种“因”的组合，判断其他“果”的状态，并放置在一列中。

在执行第二步时要做以下考虑：

当回溯经过一个结果应为1的or结点时，不要同时将该or结点的一个以上的输入设置为1。这就是所谓的“路径敏感性”，其目的是避免由于原因之间的屏蔽而漏掉某些错误。
当回溯经过一个结果应为0的and结点时，显然应列出导致结果为0的所有的输入组合情况。然而，如果碰到的情况是一个输入为0，其他的输入中有一个或更多为1，那么就无需罗列出其他输入可能为1的所有情况。（啥意思？——不必列出所有情况，列出一种使之为1的情况即可）
当回溯经过一个结果应为0的and结点时，仅有一种所有输入皆为0的情况需要列举出来（如果这个and结点位于因果图的中部，其输入来自于其他中间结点，那么所有输入都为0的情况就会非常多）。

示例：

具体如何由因果图法设计测试用例的实例见此，实例写的很清楚明白

因果图方法没有充分考虑边界条件，但这并不意味着我们需要为边界条件重新生成更多的测试用例——我们可以在此过程中尝试覆盖边界条件，即在由因果图生成测试用例时，可以将边界条件一并考虑进去。

现在已经有了商业软件可以帮我们完成从因果图到判定表的转化。

4.3 错误猜测

错误猜测法在软件测试活动种，人们可以依靠经验和直觉推测系统种可能存在的各种错误，从而有针对性的编写检查这些错误的列子，这就是错误推测法。

基本思想：根据以往的测试经验和对系统内部的知识的了解，列出系统中各种可能有的错误和容易发生的特殊情况，再根据他们来设计测试用例，随着在产品测试的实践对产品的了解的加深和测试经验的丰富，使用错误推测法设计的测试用例往往非常有效，可以作为测试设计的一种补充手段，并且积累的经验越丰富，方法使用效率越高。

4.4 测试策略

一组合理的策略如下：

如果规程说明中包含输入条件组合的情况，应首先使用因果图分析法。
在任何情况下都应使用边界值分析方法。应记住，这是对输入和输出边界进行的分析。边界值分析可以产生一系列补充的测试条件，但是，也正如“因果图分析”一节所述，多数甚至全部条件都可以被整合到因果图分析中。
应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
使用错误猜测技术增加更多的测试用例。
针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。

4.5 小结

本章介绍了以下几种测试用例设计方法：

逻辑覆盖测试。该测试要求程序中的所有判断都应至少覆盖一次，同时每一条语句或者入口点都被执行一次。
等价类划分。通过定义条件和错误类来帮助减少测试的工作量。这种划分假设某分类的一个代表值能够等价于该分类的所有值或条件。
边界值分析。测试等价类中每一个分类取边界值的情况，既要考虑输入等价类，也要考虑输出等价类。
因果图。通过生成布尔图来诠释测试用例的可能结果，使用该法旨在帮助选择那些有效地测试用例达到比较完整的测试用例设计效果。
错误猜测。依靠直觉和测试专家经验来定位程序可能出错的地方，并由此设计出更高效的测试用例。