测试入门秘籍<<独孤九剑>>之破刀式-软件测试设计
测试入门秘籍<<独孤九剑>>之破刀式-软件测试设计
破解诸般单刀、双刀、柳叶刀、鬼头刀、大砍刀、斩马刀种种刀法。
测试设计与测试用例
测试设计
- 测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。
测试分析和设计的主要任务
- 第一步:评审测试依据(需求,系统架构,设计和接口说明)
- 第二步:评估测试依据和测试对象的可靠性
- 第三步:通过对测试项、规格说明、测试对象行为和结构的分析,识别测试条件并确定优先级
- 第四步:设计测试用例,并确定优先级
- 第五步:确定测试条件和测试用例所需的必要的测试数据
确定测试条件
- 依据在测试策略或测试计划中确定的测试技术
- 通过对测试依据和测试目标的分析,可以确定需要测试的内容,获得测试条件
测试用例
- 测试用例是通过使用在测试计划中确定的测试技术,对于已确定的测试条件进行逐步的推敲,精炼而设计出来的重点说明如何具体操作产生何种结果的文档
- 测试用例应该具有可重复性、可验证性和需求可追踪性
测试用例设计包括以下关键点
- 前提条件,如项目或局部测试环境的需求,以及其交付计划
- 测试步骤
- 测试数据
- 预期结果
- 实际结果
测试用例案例
序号 | 模块名称 | 测试子项 | 用例名称(测试意图) | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 测试结果 | 缺陷编号 | 备注 |
---|---|---|---|---|---|---|---|---|---|---|
1 | ||||||||||
2 |
测试用例常用设计方法
- 等价类划分法
- 边界值法
- 因果图设计法
- 判定表设计法
- 正交实验法
等价类划分法
测试一个两位数的加法计算器
测试需求:
- 测试两个参数的值相加后的结果是否正确
- 其中:输入的数值在-99到99之间大于99或小于-99的输入应被拒绝,并显示错误信息
等价划分法
- 根据测试续期,我们开始测试
- 分别给第一个参数和第二个参数输入表中的值,得到的测试结果如表所示(略)
- 很明显,如果我们对第一个参数的值分别从-99到99的199个数,第二个参数的值分别从-99到99的199个数,我们是不可能对两位数相加的所有情况进行穷举测试
无法穷举测试,我们面临的问题:
- 在测试了1+1,1+2.....之后,还是否有必要测试1+3,1+4呢?
- 如果不对程序进行穷举测试。能否放心的认为所有的参数组合是正确的呢?
解决办法:等价类划分法
- 等价类划分的办法是把程序的输入域划分成若干部分
- 然后从每个部分中选取少数代表性数据当作测试用例
- 每一类的代表性数据在测试中的作用等价于这一类的其他值
- 也就是说,如果某一类中的一个例子发现了错误,这一等价类中的其他例子也能发现同样的错误
- 反之,如果某一类中的一个例子没有发现错误,则这一类中的其他例子也不会查出错误
等价类划分的原则
- 如果输入条件规定了取指的范围或值得个数,则可确定一个有效等价类和两个无效等价类
- 如果一个输入条件说明了一个”必须成立“的情况,则可划分一个有效等价类和一个无效等价类
- 如果输入条件规定了输入数据的一组可能的值,而且程序是不同的方式处理每一种值,则可为每一种值划分一个有效等价类,并划分一个无效等价类
- 如果我们确知,已划分的某种等价类中的各个元素(例子)在程序中的处理方式是不同的,则应据此将此等价类进一步划分成更小的等价类
- 在确立了等价类之后,建立等价类表,列出所有划分出的等价类
基于等价类划分的用例设计
总结:让每一个有效等价类都有用例应对,让每一个无效等价类都有一个唯一的用例来应对
- 明确测试对象,非测试对象保证正确
- 为每个等价类规定一个唯一的编号
- 设计一个新的测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步,最后使得所有有效等价类均被测试用例所覆盖
- 设计一个新的测试用例,使其只覆盖一个无效等价类,重复这一步使所有无效等价类均被覆盖
等价类划分实战
第一步:根据测试需求可以分为三个等价类:
- 一个有效数据的等价类,两个无效数据等价类
- 有效数据等价类就是:由那些对程序的规格说明有意义的,合理的输入数据所构成的集合
- 无效数据等价类就是:那些对程序的规格说明不合理的或无意义的输入数据所构成的集合
第二步:建立等价类表
- 实际工作中,我们通常在确立了等价类以后,把程序中所有的等价类建立等价类表,以便在编写测试用例的时候有所依据
序号 | 功能项 | 有效等价类 | 编号 | 无效等价类 | 编号 |
---|---|---|---|---|---|
1 | 两位数加法 | -99<=加数取值<=99 | 2 | 加数取值<-99 加数取值>99 |
1 3 |
第三步:确定测试用例
- 为等价类表中的每一个等价类分配一个唯一的编号
- 设计一个新的测试用例,使它能够尽量覆盖尚未覆盖的有效等价类
- 重复这一步骤,从而使所有有效等价类均被测试用例所覆盖
- 与上步类似,设计一个新的测试用例,使它只覆盖一个无效等价类
- 重复这一步骤,从而使所有无效等价类均被测试用例所覆盖
测试用例编号 | 输入数值 | 所属等价类 | 预期输出 |
---|---|---|---|
1 | -50+24 | 2 | 正确输出:-26 |
2 | -130 | 1 | 错误信息 |
3 | 125 | 3 | 错误信息 |
第四步:细化等价类划分
- 在测试”-99<=数值<=990“的这个等价类区间的时候
- 我们会发现如10+40 ,-20+30和-30+(-30)这类的正数相加,正数负数相加,负数相加也是不同的等价区间
- 因此我们可以使用更多的等价类划分
序号 | 功能项 | 有效等价类 | 编号 | 无效等价类 | 编号 |
---|---|---|---|---|---|
1 | 两位数加法 | -99<=加数取值<=0 0<=加数取值<=99 |
2 3 |
加数取值<-99 加数取值>99 |
1 4 |
第五步:完善测试用例
- 根据上面划分的4个等价类,我们至少需要由5个测试用例
测试用例编号 | 输入数值 | 所属等价类 | 预期输出 |
---|---|---|---|
1 | 50+2 | 3 | 正确输出:52 |
2 | -63+(-20) | 12 | 正确信息:-83 |
3 | -30+10 | 2,3 | 正确输出:-20 |
3 | -130 | 1 | 错误信息 |
3 | 125 | 4 | 错误信息 |
等价类划法的原则
等价类的特点
- 测试相同的内容
- 如果等价类中的一个测试能够捕获一个缺陷,那么选择该等价类中的其他测试也能捕获该缺陷
- 如果等价类中的一个测试不能捕获缺陷,那么选择该等价类中的其他测试也不会捕获缺陷
- 如果正确的划分等价类,可以大大降低测试用例的数量,测试会准确有效
- 如果错误的将两个不同的等价类当作一个等价类,那就会遗漏一种测试情况
- 相反的,把统一等价类看作两个不同的等价类,那么测试就会是冗余的
等价类划分要注意的问题
- 不但要考虑有效等价类,也要考虑无效等价类
- 仔细划分,审查划分
- 过于粗略可能会漏掉软件缺陷
- 组织评审
等价类用例设计练习
测试需求
- 余额宝提现到银行卡增加新规则:快速到账(2小时)日限额1w元
- 超过1w只能选择普通到账
- 按照等价类划分法设计测试用例
分析过程
序号 | 功能项 | 有效等价类 | 编号 | 无效等价类 | 编号 |
---|---|---|---|---|---|
1 | 余额宝快速提现 | 0<=取现金额<=10000 | 2 | 取现金额<0 | 1 |
取现金额>10000 | 3 | ||||
2 | 余额宝普通提现 | 0<=取现金额<= (余额宝总余额)10000 | 5 | 取现金额 <0 | 4 |
取现金额>100000 | 6 |
- 细致分析需求,日限额1w,所以要区分两个场景
序号 | 功能项 | 有效等价类 | 编号 | 无效等价类 | 编号 |
---|---|---|---|---|---|
1 | 余额宝快速提现(第一次) | 0<=取现金额<=10000 | 2 | 取现金额<0 | 1 |
取现金额>10000 | 3 | ||||
1 | 余额宝快速提现(第N次) | 0<=取现金额<=10000-已提现金额 | 8 | 取现金额<0 | 7 |
取现金额>10000-已提现金额 | 9 | ||||
2 | 余额宝普通提现 | 0<=取现金额<= (余额宝总余额)10000 | 5 | 取现金额 <0 | 4 |
取现金额>100000 | 6 |
经典等价类划分面试题
- 问题:根据下面给出的规格说明,利用等价类划分的方法,给出足够的测试用例
- 一个程序读入3个整数,把这个三个数值看做一个三角形的3条边的长度值
- 这个程序要打印出信息,说明这个三角形是不等边的、是等腰的、还是等边的
边界值法
为什么错了?
第一个参数输入-99,第二个参数输入98,程序报错提示:输入的参数值必须大于-99同时小于99
- 根据前面的等价类方法,我们按照测试用例表给出的测试用例进行了测试,没有发现问题
- 那么为什么现在输入参数-99和98后,程序提示输入的数据有误了呢?
- 而-99是合理的输入数据,以-99作为输入数据应该是有效等级类中的数据
- 是不是等价类划分方法有问题呢?
边界值分析法
- 边界值分析法是一种补充等价划分的测试用例设计技术,它不是选择等价类的任意元素,而是选择等价类边界的测试用例
- 实践证明,在设计测试用例时,对边界附近的处理必给予足够重视,为检验边界附近的处理专门设计测试用例,常常取得良好的测试效果。
- 边界值分析法不仅重视输入条件边界,而且也从输出域导出测试用例
边界值设计的原则
- 如果输入条件规定了取值范围,应该以范围边界内以及刚刚超范围的边界外的值作为测试用例
- 如果a和b为边界值,测试用例应当包含a和b以及略大于a和略小于b的值
边界值设计用例
- 由于允许输入的数值在-99到99之间,所以我们可以把-99和99看作两个边界值。我们而是的时候剋有取紧邻边界值的数值和边界值本身作为输入
测试用例编号 | 输入数值 | 被测边界 | 预期输出 |
---|---|---|---|
1 2 3 |
-100 -99+(-99) -98+(-98) |
-99 | 错误信息 正确输出:-198 正确输出:-196 |
4 5 6 |
98+98 99+99 100 |
99 | 正确输出:196 正确输出:198 错误信息 |
边界值用例设计练习
- 同样的测试需求:余额宝提现到银行卡增加新规则:快速到账(2小时)日限额1w元
序号 | 功能项 | 输入数值 | 被测边界 | 预期输出 |
---|---|---|---|---|
1 | 余额宝快速提现(第一次 | 0 -1 1 |
0 | .. |
1000 9999 100001 |
10000 | .. | ||
2 | 余额宝快速提现(第n次,假设已提现5000) | 0 -1 1 |
0 | .. |
5000 4999 5001 |
10000-已提现金额=5000 | .. | ||
3 | 余额宝普通提现 | 0 -1 1 |
0 | .. |
999999 | 最大金额 | .. |
因果图&判定表
因果图法
- 等价类划分法和边界值分析方法都是着重考虑输入条件
- 而不考虑输入条件的各种组合,输入条件之间的相互制约的关系
- 如果在测试时必须考虑输入条件的各种组合,则可能的组合将是天文数字
- 因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法,这就是需要利用因果图(逻辑模型)
- 因果图法基于这样的思想:一些程序的功能可以用决策表的形式来表示,并根据输入条件的组合情况规定相应的操作
- 因此,可以考虑为决策表中的每一列设计一个测试用例,以便测试程序在输入条件的某种组合下的输出是否正确
- 概况地说,因果图方法就是从程序规格说明书的描述中找出因(输入条件)和果(输出结果或程序状态的改变)
- 将因果图转换为判定表,为决策表中的每一列设计一个测试用例
- 这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系
判定表
- 判定表(Decision Table) 是分析和表达多逻辑条件下执行不同操作的工具
- 在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了
- 因为它可以把复杂的逻辑关系和多种条件组合的情况表达得具体又明确
判定表通常由四个部分组成:
- 条件桩:列出了问题得所有条件,通常人为列出得条件得次序无关紧要
- 动作桩:列出了问题规定可能采取得操作,这些操作得排列顺序没有约束
- 条件项:列出针对它左列条件得取指,在所有可能情况下得真假值
- 动作项:列出在条件项得各种取值情况下应该采取得动作
设计步骤
- 分析软件规格说明中哪些是原因(即输入条件或输入条件得等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
- 分析软件规格说明中语义得内容,找出原因与结果之间、原因与原因之间对应得关系,根据这些关系画出因果图
- 由于语法或环境限制,有些原因与原因之间、原因与结果之间得组合情况不可能出现。为表明这些特定得情况,在因果图上使用一些记号表明约束或限制条件
- 把因果图转换为判定表
- 根据判定表中得每一列设计测试用例
实战
- 使用因果图+判定表设计测试用例测试两位数加法计算器
分析输入条件和输出条件
-
输入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
-
输出
- 正确计算
- 错误提示
分析条件互斥
-
输入
- 输入1:
- 1、2、3、4互斥
- 输入2:
- 1、2、3、4互斥
- 输入1:
-
输出
- 输出结果正确和错误互斥
分析、简化并画出判定表
得到测试用例
测试用例编号 | 输入数值 | 预期输出 |
---|---|---|
1 | 98+98 | 正确输出:196 |
2 | 99+(-99) | 正确输出:0 |
3 | -98+(50) | 正确输出:-48 |
4 | -34+(-45) | 正确输出:-79 |
5 | -100 | 错误信息 |
6 | 100 | 错误信息 |
7 | 20+(-123) | 错误信息 |
8 | 20+(123) | 错误信息 |
因果图法用例设计练习
- 同理我们将同一测试需求需求用因果图设计:
- 余额宝提现到银行卡增加新规则:快速到账(2小时)日限额1w元,超过1w元只能选择普通到账
分析输入条件和输出条件
-
输入
-
输入1:
- a1:快速提现
- a2:普通提现
-
输入2:
- a1:0<X<=10000
- a2:X<=0
- a3:X >10000
-
-
输出
- B1 提现成功
- B2 提现失败
分析、简化并画出判定表
输入 | ||||||
---|---|---|---|---|---|---|
a1 | T | T | T | T | F | F |
a2 | F | F | F | T | T | T |
输入2 | ||||||
a1 | T | F | F | T | F | F |
a2 | F | T | F | F | T | F |
a3 | F | F | T | F | F | T |
输出 | ||||||
b1 | X | X | X | |||
b2 | X | X | X |
经典因果图-判定表面试题
- 问题:某厂工资发放
- 描述、分析:
- 工资分为年薪制a1,月薪制a2
- 错误程度分为普通a3,严重a4
- 工资为a1的员工犯普通错误的扣工资2%(b1),犯严重错误扣工资6%(b2)
- 工资为a2的员工犯普通错误的扣工资4%(b3),犯严重错误扣工资8%(b4)
- 其中,a1和a2为互斥;b1,b2 和b3,b4是互斥;a3和a4可以同时具备
正交实验法
-
正交实验设计法(Orthogonal experimental design),是从大量的试验点中挑选出适量的、由代表性的点、应用依据伽罗卡瓦理论到处的”正交表“,合理的安排试验的一种科学的试验设计方法
-
指标:通常把判断试验结果优劣的标准叫做试验的指标
-
因子(因素Factor):所有影响试验指标的条件
-
因子的状态(水平Level):而影响实验因子的,叫做因子的状态(因子变量的取值)
正交实验法设计步骤
-
提取功能说明,构造因子-状态表
-
加权筛选,生成因素分析表
计算各因子和状态的权值,删去一部分权值较小,即重要性较小的因子或状态,使最后生成的测试用例集缩减到允许范围
-
利用正交表构造测试数据集
- 如果各个因子的状态树是不统一的,几乎不可能出现均匀的情况,必须首先用逻辑命令来组合因子的状态,作出布尔图
- 根据布尔图得到相应阶数的正交表
- 依照因果图上根节点到叶子节点的顺序逐步替换正交表上的中间点,得到最终的正交表
-
利用正交表每行数据构造测试用例
- 正交表:正交表的表示形式:Ln(t^c)其中:L为正交表的代号,n为行数(试验次数),t为水平数,c为列数(因素数)
- 例如:L4(2^3),它表示需做4次实验,最多可观察3个因素,每个因素均为2水平
- 一个正交表中也可以各列的水平数不相等,我们称它为混合型正交表,如L8(2^4 4^1)
- 此表的5列中,有1列为4水平,4列为两水平
- 根据正交表的数据结构看出,正交表是一行n行c列的表,其中第j列由数码1,2,..tj组成,这些数码均各出现n/t次
如何查找正交表
- Technical Support(support.sas.com)
http://support.sas.com/techsup/technote/ts723_Designs.txt - 查Dr. GenichiTaguchi 设计的正交表
http://www.york.ac.uk/depts/maths/tables/orthogonal.htm
正交实验法例子
- 我们现在要测试支付宝web网站,该站点由大量的服务器和操作系统,并且有许多具有各个插件的浏览器需要考虑
- WEB浏览器:IE11、chrome、FireFox
- 插件:无、Flash、支付宝插件
- 应用服务器:IIS 、Apache 、Jetty
- 操作系统:Windows2000、Windows NT、Linux
- 提取系统功能说明中的因子
- web浏览器
- 插件
- 应用服务器
- 操作系统
- 分析各个因子的状态
- 插件 1=None、2=Flash、3=支付宝插件
- web浏览器:1=IE11、2=chrome、3=FireFox
- 应用服务器: 1=IIS、2=Apache、3=Jetty
- 操作系统:1=Windows2000、2=Windows NT、3=Linux
- 选择正交表
- 正交表水平数位3,因素数为4。选择L9(3^4)
- 正交表水平数位3,因素数为4。选择L9(3^4)
4.将因子、状态映射到上面的正交表中
测试场景设计
场景法原理
- 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景形成了场景,而同一事件不同的触发顺序和处理结果就形成了事件流
- 这种在软件设计方面的思想可以引入到软件测试中,可以生动地描绘出事件触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行
场景法基础设计
- 经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,时经过用例的最简单的路径。
- 备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3)
- 也可能起源于另一个备选流(如备选流2), 或者终止用例而不再重新加入到某个流(如备选流2和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 | 无选购商品 |
备选流x | 退出系统 |
- 根据基本流和备选流来确定场景
场景1-购物成功 | 基本流 | |
---|---|---|
场景1-购物成功 | 基本流 | |
场景2-账号不存在 | 基本流 | 备选流1 |
场景3-账号错误 | 基本流 | 备选流2 |
场景4-密码错误 | 基本流 | 备选流3 |
场景5-无选购商品 | 基本流 | 备选流4 |
实际测试中用例设计的综合运用
测试用例综合设计
- 测试用例项划分
- 测试用例划分的经典方法时瀑布模型,从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。
- 要从更多的角度切入系统,把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性
- 切面设计
- 功能点切面:最常见的切面,通常人为页面上的一个按钮就是一个功能点。根据功能的复杂程序,按每个功能进行用例的撰写。
- 隐含切面:完整业务流程的测试;从需求、业务角度进行编写
- 功能点用例设计
- 任何情况下都必须使用边界值分析方法 ,经验表明用这种方法设计出测试用例发现程序错误的能力最强
- 必要时用等价类划分方法补充一些测试用例
- 如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法
- 如果程序业务复杂度比较高,则适用使用场景法补充一部分测试用例
测试用例综合设计
举例:比如共享单车充值
- 边界值考虑充值金额:0元、1元、负数、非金额参数、多位小数(小数后位3位),银行卡限额
- 由于充值时可以选择不同的银行、付渠道、以针对支付宝、微信、通联、银行直连等渠道分别设计测试用例
- 考虑异常场景,如充值失败、银行卡余额不足、银行返回超时等
- 如果场景中还包含更复杂的业务场景,如满减、满赠、增加抽奖次数等,还需要结合场景法进行测试