软件测试（四）：软件测试用例设计

文章目录

测试设计与测试用例
- 测试设计
- 测试分析和设计的主要任务
- 确定测试条件
- 测试用例
- 测试用例关键点
- 测试用例案例
- 测试用例常用设计方法
- 测试用例demo
等价类划分法
- 等价类划分定义
- 等价类划分原则
- 基于等价类划分的用例设计
- 等价类划分实战
- 等价类的特点
- 等价类划分要注意的问题
- 经典等价类划分面试题
边界值分析法
- 边界值法定义
- 边界值设计原则
- 边界值设计用例
因果图与判定表法
- 因果图法
- 因果图-判定表
- 判定表
- 设计步骤
- 实战
- - 分析输入条件和输出条件
  - 分析、简化并画出判定表
  - 得到测试用例
- 经典因果图—判定表面试题
正交实验法
- 正交实验法定义
- 正交实验法设计步骤
- 正交实验法例子
测试场景设计
- 场景法原理
- 场景法基础设计
- 场景法设计步骤
- 场景法设计例子
测试用例综合设计

测试设计与测试用例

测试设计

测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动

测试分析和设计的主要任务

评审测试依据（需求，系统架构、设计和接口说明）
评估测试依据和测试对象的可靠性
通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级
设计测试用例，确定优先级
确定测试条件和测试用例所需的必要的测试数据

确定测试条件

依据在测试策略或测试计划中确定的测试技术
通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件

测试用例

测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。

测试用例应该具有可重复性、可验证性和需求可追踪性。

测试用例关键点

前提条件，如项目或局部测试环境的需求，及其交付计划
测试步骤
测试数据
预期结果

测试用例案例

测试用例常用设计方法

等价类划分法
因果图设计法
边界值法
判定表设计法
正交实验法

测试用例demo

测试一个两位数的加法计算器

等价类划分法

很明显，我们不可能对两位数相加的所有情况进行穷举测试

如果不能进行穷举测试，我们将面临以下问题

在测试了1+1，1+2，1+（-1）和1+（-2）之后，还是否有必要测试1+3，1+4？

如果不对加法计算器程序进行穷举测试，能否放心的认为所有的参数组合都是正确的？

等价类划分定义

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例，每一类的代表性数据在测试中的作用等价于这一类中的其他值。

也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

等价类划分原则

如果输入条件规定了取值的范围或值的个数，则可确定一个有效等价类和两个无效等价类
如果一个输入条件说明了一个“必须成立”的情况，则可划分为一个有效等价类和一个无效等价类
如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分为一个无效等价类
如果我们确知，已划分的某等价类中的各元素在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类
在确定了等价类之后，建立等价类表，列出所有划分出的等价类

基于等价类划分的用例设计

明确测试对象，非测试对象保证正确
为每个等价类规定一个唯一的编号
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，最后使得所有无效等价类均被测试用例所覆盖

等价类划分实战

根据测试需求可以分为三个等价类：
- 一个有效数据的等价类，两个无效数据的等价类
- 有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合
- 无效数据等价类就是：由那些对程序的规格说明无意义的、不合理的输入数据所构成的集合
建立等价类表：

-在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，以便在编写测试用例的时候有所依据
确定测试用例：
- 为等价类表中的每一个等价类分配一个唯一的编号
- 设计一个新的测试用例，使他能够尽量覆盖尚未覆盖的有效等价类
- 重复这一步骤，使得所有有效等价类均被测试用例所覆盖
- 与上步类似，设计一个新的测试用例，使他只覆盖一个无效等价类
- 重复这一步骤，使得所有无效等价类均被测试用例所覆盖
细化等价类划分：
- 在测试“-99 <= 数值 <= 99”的这个等价类区间的时候，我们发现如 10 + 40 ，-20 + 30 和 -30 +（-30）这类的正数相加，正数负数相加，负数相加也是不同的等价区间，因此我们可以使用更多的等价类划分
- 根据以上等价类划分的结果，得出下表的等价类表
完善测试用例：
- 根据上面划分的4个等价类，我们至少需要有5个测试用例

等价类的特点

测试相同的内容
如果等价类中的一个测试能够捕获一个缺陷，那么选择该等价类中的其他测试也能捕获该缺陷
如果等价类中的一个测试不能够捕获一个缺陷，那么选择该等价类中的其他测试也不能捕获该缺陷
如果正确的划分等价类，可以大大降低测试用例的数量，测试会准确有效
如果错误的将两个不同的等价类当作一个等价类，那就会遗漏一种测试情况
相反，把同一个等价类看作了两个不同的等价类，那么测试就会说冗余的

等价类划分要注意的问题

不但要考虑有效等价类，也要考虑无效等价类
仔细划分，审查划分
过于粗略可能会漏掉软件缺陷
组织评审

经典等价类划分面试题

问题：根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例

“一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形说不等边的、是等腰的、还是等边的”

边界值分析法

边界值法定义

边界值分析法是一种补充等价类划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例
实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果
边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例

边界值设计原则

如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例
如以a和b为边界，测试用例应以包含a和b及略大于a和略小于b的值

边界值设计用例

我们继续以计算器的例子，根据边界值分析的方法来看看如何对边界值进行测试

由于允许输入的数值在-99到99之间，所以我们可以把-99和99看作两个边界值。我们测试的时候可以取紧邻边界值的数值和边界值本身作为输入

因果图与判定表法

因果图法

等价类划分法和边界值分析法都是着重考虑输入条件，而不考虑输入条件的各种组合、输入条件之间的相互制约关系。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字。因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法，这就需要利用 因果图（逻辑模型）。

因果图-判定表

因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的操作。因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序在输入条件的某种组合下的输出是否正确。

概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变），将因果图转换为判定表，为决策表中的每一列设计一个测试用例。这种方法考虑到啦输入情况的各种组合以及各个输入情况之间的相互制约关系。

判定表

判定表是分析和表达多逻辑条件下执行不同操作的工具，在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了，因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

举一个例子：

判定表通常由四个部分组成：

条件桩：列出了问题的所有条件，通常认为列出得条件的次序无关紧要。
动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
条件项：列出针对它左列条件的取值，在所有可能情况下的真假值
动作项：列出在条件项的各种取值情况下应该采取的动作

设计步骤

分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
分析软件规格说明中语义的内容，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。
由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特点的情况，在因果图上使用一些记号表明约束或限制条件。
把因果图转换为判定表
根据判定表中的每一列设计测试用例

实战

我们继续以计算器的例子，根据因果图+判定表设计测试用例测试两位数加法计算器

分析输入条件和输出条件

输入1:
- 条件1: 0 <= x <= 99
- 条件2: -99 <= x < 0
- 条件3: x < -99
- 条件4: x > 99
输入2:
- 条件1: 0 <= x <= 99
- 条件2: -99 <= x < 0
- 条件3: x < -99
- 条件4: x > 99
输出
- 正确计算
- 错误提示

分析、简化并画出判定表

得到测试用例

经典因果图—判定表面试题

问题：某厂工资发放

描述、分析：工资分为年薪制a1,月薪制a2；错误程度分为普通a3，严重a4；

工资为a1的员工犯普通错误的扣工资2%（b1）,犯严重错误扣工资6% (b2);

工资为a2的员工犯普通错误的扣工资4%（b3）,犯严重错误扣工资8% (b4);

其中，a1和a2为互斥；b1,b2和b3,b4是互斥；a3和a4可以同时具备。

正交实验法

正交实验法定义

正交试验设计法是从大量的试验点中挑选出适量的、有代表性的表，应用依据迦罗卡瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法。
指标：通常把判断试验结果优势的标准叫做试验的指标
因子（因素factor）：所有影响试验指标的条件
因子的状态（水平level）：而影响实验因子的，叫做因子的状态（因子变量的取值）

正交实验法设计步骤

提取功能说明，构造因子------状态表
加权筛选，生成因素分析表

计算各因子和状态的权值，删去一部分权值较小，即重要性较小的因子或状态，使最后生成的测试用例集缩减到允许范围。
利用正交表构造测试数据集
- 如果各个因子的状态树是不统一的，几乎不可能出现均匀的情况，必须首先用逻辑命令来组合各因子的状态，作出布尔图
- 根据布尔图得到相应阶数的正交表
- 依照因果图上根结点到叶子结点的顺序逐步替换正交表上的中间节点，得到最终的正交表
利用正交表每行数据构造测试用例
- 正交表的表示形式：Ln( t ^ c ) 其中：L 为正交表的代号，n 为行数（试验次数），t为水平数，c 为列数（因素数）
- 例如；L4( 2 ^ 3 ) ，它表示需做4次实验，最多可观察3个因素，每个因素均为2水平

正交实验法例子

我们现在要测试支付宝web网站，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器需要考虑

提取系统功能说明中的因子
- web浏览器：ie11、Chrome、firefox
- 插件：无、flash、支付宝插件
- 应用服务器：iis 、Apache、jetty
- 操作系统：Windows2000、WindowsNT、Linux
分析各因子的状态
- 插件：1 = none、2 = flash、3 = 支付宝插件
- web浏览器：1 = ie11、2 = Chrome、3 = firefox
- 应用服务器：1 = iis 、2 = Apache、3 = jetty
- 操作系统：1 = Windows2000、2 = WindowsNT、3 = Linux
选择正交表
- 正交表水平数为3，因素数为4，选择L9 ( 3 ^ 4 )
将因子、状态映射到上面正交表中

测试场景设计

场景法原理

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

场景法基础设计

经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径
备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中
也可能起源于另一个备选流，或者终止用例而不再重新加入到某个流
每个经过用例的可能路径，可以确定不同的用例场景
从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
- 场景1 基本流
- 场景2 基本流备选流1
- 场景3 基本流备选流1 备选流2
- 场景4 基本流备选流3
- 场景5 基本流备选流3 备选流1
- 场景6 基本流备选流3 备选流1 备选流2
- 场景7 基本流备选流4
- 场景8 基本流备选流3 备选流4

场景法设计步骤

根据说明，描述出程序的基本流及各项备选流
根据基本流和各项备选流生成不同的场景
对每一个场景生成相应的测试用例
对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

场景法设计例子

以淘宝网为例，我们都在淘宝上买过东西，整个购买过程为：

用户登陆到网站后，进行商品的选择，当选好自己心仪的商品后进行购买，这时把所需商品放进购物车，等进行结账的时候，用户需要登录自己注册的账号，登录成功后，进行结账并生成订单，整个购物过程结束。
通过以上的描述，从中确定哪是基本流，哪些是备选流

根据基本流和备选流来确定场景

测试用例综合设计

测试用例项划分

测试用例划分的经典方法是瀑布模型，从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。要从更多的角度切入系统，把系统切分成一块一块的来进行测试，从而确保测试大项的完整性
切面设计
- 功能点切面：最常见的切面，通常认为页面上的一个按钮就是一个功能点。根据功能的复杂程度，按每个功能进行用例的撰写
- 隐含切面：完整业务流程的测试，从需求、业务角度来进行编写
功能点用例设计
1. 任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强
2. 必要时用等价类划分的方法补充一些测试用例
3. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法
4. 如果程序业务复杂度比较高，则适当使用场景法补充一部分测试用例

举例：共享单车充值

边界值考虑充值金额：0元，1元，负值，非金额参数，多位小数（小数后位3位），银行卡限额

由于充值时可以选择不同的银行、支付渠道，所以针对支付宝、微信、通联、银行直连等渠道分别设计测试用例

考虑异常场景，如充值失败、银行卡余额不足、银行返回超时等

如果场景中还包含更复杂的业务场景，如满减、满赠、增加抽奖次数等，还需要结合场景法进行测试