【测试】编写测试用例的常用方法

---

黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。

1）等价类划分法

等价类划分法是把所有可能输入的数据，即将程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

• 适用场景：有数据输入的地方，就可以使用等价类划分法。例如，输入框。

1.1 什么是等价类

某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。

等价类划分有两种不同的情况，有效等价类和无效等价类。

• 有效等价类：

  是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。

• 无效等价类：

  指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能多个。

例如，登录界面的手机号输入框（只允许输入数字）：

• 有效等价类：数字（合法手机号码）
• 无效等价类：汉字、表情、符号、空格等

1.2 划分标准

完备测试、避免冗余，即划分为互不相交的一组子集，而子集的并是整个集合。

• 并是整个集合（完备性）。
• 子集互不相交（保证一种形式的无冗余性）。
• 同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到“相同的执行路径”。

1.3 划分方法

1、确立等价类

• 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
  • 如：输入值是学生成绩，范围是0~100。
• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
• 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
• 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
  • 如：输入条件说明学历可为专科、本科、硕士、博士四种之一，则分别取这四种的四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
• 在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
• 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应在将该等价类进一步的划分为更小的等价类。

在确立了等价类后，可建立等价类表，列出所有划分出的等价类输入条件：有效等价类、无效等价类。

2、转化为测试用例

从划分出的等价类中按以下三个原则设计测试用例：

• 为每一个等价类规定一个唯一的编号。
• 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
• 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

1.4 实例：三角形问题

某程序规定：输入三个整数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形、等边三角形时，分别做计算。
用等价类划分方法为该程序进行测试用例设计。

1.4.1 分析对输入条件的要求（显性和隐性）

1、整数
2、三个数
3、非零数
4、正数
5、两边之和大于第三边
6、等腰
7、等边

如果a、b、c满足条件1~4，则输出下列四种情况之一：

• 如果不满足条件（5），则程序输出为“非三角形”
• 如果三条边相等，即满足条件（7），则程序输出为“等边三角形”
• 如果只有两条边相等，即满足条件（6），则程序输出为“等腰三角形”
• 如果三条边都不相等，则程序输出为“一般三角形”

1.4.2 列出等价类表并编号

1.4.3 编写测试用例

• 覆盖有效等价类的测试用例：
  • 3 4 5 覆盖（1-4）（5-7）
  • 4 4 5 覆盖（1-4）（5-7）（8）
  • 4 5 5 覆盖（1-4）（5-7）（9）
  • 5 4 5 覆盖（1-4）（5-7）（10）
  • 4 4 4 覆盖（1-4）（5-7）（11）
    
    
• 覆盖有效等价类的测试用例：
  

---

2）边界值分析法

大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

• 与等价类区别：

  • 边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界都要作为测试条件。
  • 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

2.1 分析方法

首先应确定边界情况：

• 通常输入和输出等价类的边界，就是应着重测试的边界情况。
• 应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

常见的边界值：

• 对16Bit的整数而言，32767和32768是边界
• 屏幕上光标在最左上、最右下位置
• 报表的第一行和最后一行
• 数组元素的第一个和最后一个
• 循环的第0次、第1次和倒数第2次、最后一次
  
  

边界检验的常见类型：

• 数字（最大/最小）
• 字符（首位/末位）
• 位置（上/下）
• 重量
• 大小
• 速度（最快/最慢）
• 方位（最高/最低）
• 尺寸（最短/最长）
• 空间（空/满）

2.2 内部边界值分析

2.2.1 什么是内部边界值条件？

在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

2.2.2 内部边界值条件种类：

• 数值的边界值检验：

  计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。
  

• 字符的边界值检验：

  在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。
  

• 其它边界值检验：

  在不同的行业应用领域，依据硬件和软件的标准不同而具有各自特定的边界值。

2.3 转化为测试用例

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。
• 将以上两种规则应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
• 分析规格说明，找出其它可能的边界条件。

2.4 实例：三角形的边界问题

在三角形问题描述中，除了要求边长是整数外，没有给出其它的限制条件。在此，我们将三角形每边边长的取范围值设值为[1, 100]。

---

3）因果图法（不太重要，熟练后可直接使用判定表）

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

• 适用场景：在一个界面中有多个控件，如果控件之间存在组合关系或者限制关系，不同的控件组合会产生不同的输出结果。

3.1 什么是因果图？

4种符号分别表示了规格说明中向4种因果关系：

• 左结点表示输入状态（或称原因）

• 右结点表示输出状态（或称结果）

• C1和Ef均可取值0或1，0表示某状态不出现，1表示某状态出现

• 关系：

  • 恒等：若c1是1，则e1也是1；否则e1为0。
  • 非：若c1是1，则e1是0；否则e1是1。
  • 与：若c1和c2都是1，则e1为1；否则e1为0。“与”也可有任意个输入。
  • 或：若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入。
    
    

• 约束：

  输入状态相互之间还可能存在某些依赖关系，称为约束。例如，某些输入条件本身不可能同时出现。
  

  • 输入条件的约束有以下4类：
    • E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
    • I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
    • O约束（唯一）；a和b必须有一个，且仅有1个为1。
    • R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
  • 输出条件约束类型：
    • M约束（强制）：若结果a是1，则结果b强制为0。

3.2 采用因果图法设计测试用例

1、分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

2、分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。

3、由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

4、把因果图转换为判定表。

5、把判定表的每一列拿出来作为依据，设计测试用例。

3.4 实例：自动售货机

有一个处理单价为5角钱的饮料的自动售货机。其规格说明如下：

• 若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。
  • 若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来。
  • 若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

1、列出原因和结果

• 原因：
  • （1）售货机有零钱找
  • （2）投入1元硬币
  • （3）投入5角硬币
  • （4）押下橙汁按钮
  • （5）押下啤酒按钮
• 结果：
  • 21——售货机〖零钱找完〗灯亮
  • 22——退还1元硬币
  • 23——退还5角硬币
  • 24——送出橙汁饮料
  • 25——送出啤酒饮料

2、画出因果图

所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。

• 中间结点：
  • 11—— 投入1元硬币且押下饮料按钮
  • 12——押下〖橙汁〗或〖啤酒〗的按钮
  • 13——应当找5角零钱并且售货机有零钱找
  • 14——钱已付清

3、 转换成判定表

• 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。
• 第16列与第32列因什么动作也没做，也删去。

最后可根据剩下的16列作为确定测试用例的依据。

4）判定表驱动法

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

• 适用场景：在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即针对不同逻辑条件的组合值，分别执行不同的操作。

• 优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

• 缺点：不能表达重复执行的动作，例如循环结构。

4.1 判定表的组成

判定表由四部分组成：

• 条件桩（Condition Stub）：

  列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

• 动作桩（Action Stub）：

  列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

• 条件项（Condition Entry）：

  列出针对它左列条件的取值。在所有可能情况下的真假值。

• 动作项（Action Entry）：

  列出在条件项的各种取值情况下应该采取的动作。

4.2 规则及规则的合并

• 规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。
  • 在判定表中贯穿条件项和动作项的一列就是一条规则。
  • 显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
• 化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

4.3 判定表建立步骤

1、确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故2n种规则。

2、 列出所有的条件桩和动作桩。

3、填入条件项。

4、填入动作项，完成初始判定表。

5、简化，合并相似规则（相同动作）。

4.4 实例：

对功率大于50马力的机器，维修记录不全或已运行10以上的机器，应给予优先的维修处理。这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定表。

1、确定规则的个数

这里有3个条件，每个条件有两个取值，故应有222=8种规则。

2、列出所有的条件桩和动作桩

• 条件：
  • 功率大于50马力吗？
  • 维修记录不全吗？
  • 运行超过10年吗？
• 动作：进行优先处理

3、填入条件项

可从最后1行条件项开始，逐行向上填满。

4、填入动作桩和动作项

这样便得到如下图的初始判定表：

5、简化初始判定表

合并相似规则后得到：

---

5）场景图法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

场景法是基于软件业务的测试方法，测试人员把自己当成最终用户，尽可能真实地模拟用户在使用此软件的操作情形。

• 适用场景：业务比较复杂的软件系统都适合使用场景法。
• 先整体后细节：先关注它的主要功能和业务流程是否正确实现。当业务流程测试没有问题，也就是软件的主要功能没有问题时，再去关注控件的等价类、边界值等细节测试。

*重点模拟两类操作：

• 用户正确操作的业务过程：验证软件的业务功能是否正确实现。
• 模拟用户错误操作的情形：验证软件的异常处理能力（健壮性）。

5.1 场景划分

• 基本流（有效流、正确流）：

  模拟用户正确的业务操作流程就是基本流。

• 备选流（无效流、错误流）：

  模拟用户错误的操作流程就是备选流。

5.2 实例：ATM

下图所示是ATM例子的流程示意图：

1、场景设计

• 注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。

2、用例设计

对于这7个场景中的每一个场景都需要确定测试用例。

• 可以采用矩阵或决策表来确定和管理测试用例。
• 下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
  • 本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
    

3、数据设计

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据：

---

6）其他方法

6.1 正交排列法

从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。

• 类似的方法有：聚类分析方法、因子方法方法等。

• 适用场景：在一个界面中有多个控件，每个控件有多个取值，要考虑不同控件不同取值之间的组合 ，且组合数量较大的话，我们就可以使用正交排列法。

6.2 测试大纲法

• 适用场景：软件中有多个窗口，窗口中有若干操作（功能点），为了理清窗口之间的关系（结果），可以使用测试大纲法。

6.3 错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

6.4 白盒测试常见的用例设计方法

• 代码检查法
• 静态结构分析法
• 静态质量度量法
• 逻辑覆盖法
• 基本路径覆盖测试法
• 域测试
• 符号测试

---

【部分内容参考自】

• 编写测试用例的方法：https://www.cnblogs.com/fuxinxin/p/8991703.html
• 测试用例设计方法：https://www.cnblogs.com/molrang/p/6420918.html