测试用例设计方法

测试用例的定义

• 测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试某个程序路径或核实是否满足某个特定需求。通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。
• 测试用例（Test Case）是为了高效率地发现软件缺陷而精心设计的少量测试数据。实际测试中，由于无法达到穷举测试，所以要从大量输入数据中精选有代表性或特殊性的数据来作为测试数据。好的测试用例应该能发现尚未发现的软件缺陷

测试用例的特性

• 有效性：测试用例的能够被使用，且被不同人员使用测试结果一致。
• 可复用性：良好的测试用例具有重复使用的功能。
• 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用。
• 可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准。
• 可管理性：测试用例可以作为检验测试人员进度、工作量以及跟踪/管理测试人员工作效率的因素。

测试用例的基本要素

• 用例编号：每个测试用例都有唯一的标识号，用以区别其他测试用例。
• 测试模块：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。
• 用例标题：指明并简单描述本测试用例是用来测试哪些项目、子项目或软件特性的。
• 用例级别：定义测试用例的优先级别，可以粗略地分为 “ 高 ” 和 “ 低 ” 两个级别。
• 测试环境：描述执行测试用例所需要的具体测试环境，包括硬件环境和软件环境。
• 测试输入：用来执行测试用例的输入要求。这些输入可能是数据、文件或具体操作。
• 执行操作：执行本测试用例所需的每一步操作。
• 预期结果： 描述被测项目或被测特性所希望或要求达到的输出或指标。

测试用例的设计原则

• 保证测试用例的明确性：测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。
• 保证测试用例的代表性：尽量将具有相似功能的测试用例抽象合并。
• 保证测试用例的简洁性：测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。

测试用例设计方法

等价类划分法

定义： 输入具有代表性的数据子集。

等价类

• 有效等价类 — 满足需求
• 无效等价类 — 不满足需求

等价类操作步骤

• 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这个过程，直至所有的有效等价类均被测试用例所覆盖；
• 设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这个过程，直至所有的无效等价类均被测试用例所覆盖。

Step1、分析需求中包含多少个独立功能

判断独立功能的标准：

• 功能名是一个动词。
• 不可继续往下分割。
• 包含三要素：输入、处理、输出。

Step2、分别针对每个独立功能开展需求分析

• 分析界面可见输入参数，罗列参数个数及名称 。
• 分析界面不可见输入参数：网络、浏览器/系统、权限、 数据库服务、系统本身服务。

Step3、分析界面可见输入参数的特点及其关系

输入参数需要用户输入数据，并且存在有效/无效规则校验，则用等价类法设计测试用例。

Step4、分别罗列每个界面可见输入参数的有效无效规则，形成等价类表

测试文本框类型应考虑的几个维度：

• 长度
• 类型
• 组成规则
• 是否为空
• 是否重复
  – 是否区分大小写
  – 是否去前中后空格

构造无效规则时要注意：只能同时违背一条规则

边界值

• 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法
• 大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
• 使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

常见的边界值分析

1. 边界值分析使用与等价类划分法相同，只是边界值分析假定错误更多的存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。
2. 通常情况下，软件测试所包含的边界检验集中类型（边界值）：数字（最大/最小），字符（首位/末位），位置（上/下），重量（最重/最轻），速度（最快/最慢），方位（最高/最低），尺寸（最短/最长），空间（空/满）等。

边界值用例设计要点

• 上点
• 离点

判定表

决策表

在一个程序中，如果输入输出比较多，输入之间和输出之间相互制约的条件比较多，在这种情况下应用决策表很合适，它可以很清楚地表达它们之间的各种复杂关系。在一个程序中，如果输入输出比较多，输入之间和输出之间相互制约的条件比较多，在这种情况下应用决策表很合适，它可以很清楚地表达它们之间的各种复杂关系。

决策表法简述

决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并可避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

决策表通常由以下4部分组成

• 条件桩—列出问题的所有条件
• 条件项—针对条件桩给出的条件列出所有可能取值
• 动作桩—列出问题规定的可能采取的操作
• 动作项—指出在条件项的各组取值情况下应采取的动作

将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在判定表中贯穿条件项和动作项的一列就是一条规则。

决策表的构造及化简

1. 列出所有的条件桩和动作桩
2. 确定规则的个数
3. 填入条件项
4. 填入动作项得到初始化决策表
5. 简化决策表，合并相似规则

对于n个条件的决策表，相应有2n规则（每个条件分别取真、假值），当n较大时，决策表很庞大。实际使用决策表时，常常先将它简化。决策表的简化以合并相似规则为目标，即若表中有两条或两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。

当输入条件增大时，若采用因果图法和决策表法，测试用例数会随着条件数呈指数型增长。

正交试验

正交试验设计法，就是使用已经造好了的表格——正交表来安排试验并进行数据分析的一种方法。正交试验采用两两组合方式，减少用例个数，适用于兼容性测试、测试范围小。

场景法

通过运用场景来对系统的功能点或业务流程进行描述，从而提高测试效果的一种方法。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

基本流

从系统某个初始态开始，经一系列状态后到达终止状态的过程中最主要的一个业务流程。

备选流

以基本流为基础，在经过的每个判定节点处满足不同的触发条件而导致的其他事件流。

流程分析法

一个功能的实现需要多个界面协同完成（跨界面）存在逻辑关系（对错不能同时存在，同意/不同意、上一步/下一步）并且不同参数组合会输出不同结果

流程分析法的优缺点

• 优点：流程分析法既能覆盖条件为真的分支，也能覆盖条件为假的分支
• 缺点：流程分析法不能验证每个界面的参数是否正确，验证的是流程， 所以需要与开发进行沟通需求，需要在每个界面进行校验，如果错误，直接在当前界面提示信息，所以需要多种方法组合使用

状态迁移图

所有参数都是有效的参数之间存在约束条件（功能之间的约束、状态之间的约束）

状态迁移图的优缺点

• 优点：保证每一个功能/状态的可达项都被覆盖
• 缺点：对无效的路径无法覆盖

因果图

参数之间存在逻辑关系，不同逻辑组合会输出不同结果

参数之间存在约束关系，输出结果不确定

• 因果符号：恒等、非、或、与
• 原因符号：异、或、唯一、要求
• 结果符号：强制
  

优点

1.充分考虑了输入条件之间的组合，对组合情况覆盖充分。

2.最终每个用例覆盖多种输入情况，有利于提高测试效率。

3.设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有效性高。

4.能够同时得出每个测试项目的预期输出

缺点

1.当被测试特性输入较多时，判定表的规模会非常大。

2.输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余。

输出域覆盖法

需求界面当中可见参数存在有效和无效规则校验，但没有明确限制输入条件，而需求中

给出了输出的限定条件，而我们要根据业务由输出倒退输入，此时可以使用输出域覆盖法设计测试用例。

1.询问开发或根据代码找出所有的输出结果

2.检查写过的测试用例是否把所有输出结果覆盖到，如果有未覆盖到用例则补测试用例

3.根据输出结果倒推测试用例步骤及测试数据

输出域覆盖法能保证所有输出结果是都被覆盖到，要求必须对业务要熟悉。

输入域覆盖法

输入域分析是一种综合的方法，综合了等价类划分法、边界值分析法等方法。这里说的输入域就是指输入，针对输入会有各种各样的输入值：

a.特殊值：主要和输入的特点有关，需要了解系统对该输入的存储和处理。

b.长时间输入：对于那些没有限制输入长度的输入进行长时间的持续输入，以查看是否会存在输入的数据内存越界导致系统故障的情况。

1.根据SRS找出输入的类型边界和特殊值

2.根据类型边界值和特殊值找到相应的类型边界值和特殊值并写出相应的测试用例

输入域覆盖法考虑的更加全面，但是输入不一定存在类型边界或特殊值

异常分析法

异常分析就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此设计测试用例。

主要针对系统的容错能力、故障恢复能力进行测试。简单的说就是人为让系统出故障，然后检查系统的故障恢复能力。

另一方面，针对系统的异常测试（是否做了不应该做的事）也要通过异常分析等手段。

应用

• 针对系统罗列可能的故障

    例如：断电；断网；数据损坏；内存错误；
  

• 针对每种可能的故障设计测试用例

使用步骤

1.构造各种可能出现的环境异常

2.做好手工备份/恢复

3.一个用例包含一个错误

优点：增加软件的可靠性

缺点：异常场景不容易构造，需要多方配合

错误猜测法

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

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

应用

（1）确定合适的错误推测清单

（2）确定需要进行错误猜测的测试子项

（3）根据清单对测试子项的规格进行错误猜测