测试方法划分
测试方法一般按以下几种划分:
- 按照执行阶段划分为:白盒测试、黑盒测试、灰盒测试。
- 按照执行状态划分为:静态测试、动态测试。
- 按照执行行为划分为:手动测试、自动测试。
白盒测试
白盒测试(White Box Testing)又称结构测试、逻辑驱动测试或基于代码的测试,主要检查产品内部结构是否按照规格说明书的规定正常运行。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒顾名思义是指盒子是可视的,观察者清楚盒子内部的东西以及里面是如何运作的,因此,白盒测试需要测试人员对系统内部的结构和工作原理有一个清楚的了解。
黑盒测试
黑盒测试(Black Box Testing)也称功能测试,主要来检测每个功能是否都能正常使用。它也是在软件测试中使用最广泛的一类测试。
在黑盒测试中,通常把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,对程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。
由于黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。所以黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。关注的是软件的功能需求,主要试图发现以下类型的错误:
- 功能是否正确,是否有遗漏。
- 界面是否错误。
- 数据结构或外部数据库访问错误。
- 性能错误。
在实际工作中,最常见的黑盒测试方法有:功能性测试、性能测试、安全性测试、兼容性测试、稳定性测试、可靠性测试以及安装卸载测试等。
从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况进行考虑,才能查出程序中所有的错误。因为穷举测试是不可能的,所以要有针对性地选择测试用例。通过制定测试案例指导测试的实施,保证软件测试有组织、有计划地进行。只有对黑盒测试进行量化,才能保证软件的质量,具体量化的方法之一就是测试用例。
黑盒测试用例设计方法包括等价类划分法、边界值分析法、判定表分析法、因果图分析法、正交试验法、流程分析法、状态迁移法、异常分析法以及错误推测法等。
等价类划分法
等价类划分法是一种典型的黑盒测试用例设计方法,使用等价类划分,是将软件的输入域分为若*分,然后从每个部分中选取少数具有代表性的数据进行测试,这样可以避免穷举产生的大量用例。
等价类是指某个输入域的子集合,在该子集合中,每个输入数据对于揭露软件中的错误都是等效的。简单地说,就是指输入该输入域中的某一个数据,如不能揭露被测对象中的缺陷,那么我们就说这个输入域中的所有数据都无法揭露该缺陷,反之亦然。
等价类划分一般划分为两种情况:有效等价类和无效等价类。
- 有效等价类:对需求规格说明而言,合理的、有效的输入数据构成的集合。
- 无效等价类:对需求规格说明而言,不合理的、无效的输入数据构成的集合。
因为软件不仅要能接收合理的数据,不合理的数据也需要做出正确响应,所以在设计测试用例时,两种等价类都需要考虑,这样的测试才能确保软件具有更高的可靠性。
根据需求规格说明书确定被测对象的输入域,进行等价类划分。等价类划分的标准,划分的子集必须是互不相交的,符合完备测试,避免出现冗余。
等价类划分法的划分原则,通常按照以下规则进行划分等价类:
1)如果规定输入的取值范围或个数时,则划分一个有效等价类和两个无效等价类。如:注册用户名的长度限制6~18个字符,6~18个字符是有效等价类,小于6个字符和大于18个字符则是两个无效等价类。
2)如果规定了输入的集合或规则必须要遵循的条件,则划分一个有效等价类,和一个无效等价类。如:注册用户名的格式要求必须以字母开头时,以字母开头是有效等价类,非字母开头则是无效等价类。
3)如果输入条件是一个布尔值,则划分为一个有效等价类和一个无效等价类。如:在注册用户时需要遵循协议或条款是否接受时,“接受”是有效等价类,“不接受”则是无效等价类。
4)如果输入条件是一组数据(枚举值),并且程序对每一个输入的值做不同的处理,则化为若干个有效等价类和一个无效等价类。如:网游中充值VIP等级(3个等价),对每个VIP的等级优惠不同,VIP1、VIP2、VIP3不同等级是三个有效等价类,不是VIP用户则是无效等价类。
5)如果输入条件规定了必须要遵循的某些规则下,则划分为一个有效等价类和若干个无效等价类(无效等价类需要从不同的角度去违反规则)。如:密码要求首位必须是大写字母的,首字母大写是有效等价类,首位小写字母的、首位为数字的或首位为特殊字符的则是无效等价类。
6)不是所有的等价类都有无效等价类。如性别的选择只有男或女两种。
【案例解析】
某网站的用户注册的需求说明,用户名为必填项,要求长度为6~18个字符,并由字母、数字、下划线组成,必须以字母开头,结尾必须是数字或字母,而且不区分大小写字母,重名账号不允许注册。密码为必填项,要求8~15个字符,首位必须是大写字母,而且区分大小写字母。确认密码,要求与密码输入一致。
根据上面需求说明,首先进行划分等价类。经过细化后并将有效等价类和无效等价类填入等价类划分设计表中,并进行编号
根据覆盖的规则,将测试数据覆盖的有效和无效等价类编号填入表中
最后根据上面的测试数据设计对应的测试用例
边界值分析法
边界值分析法是对等价类划分法的一个补充,该方法不仅需要考虑输入域的边界,而且还要关注输出域的边界。由长期的测试工作经验得知,大量的错误发生在输入和输出范围的边界上。因此针对各种边界情况设计用例,可以查出更多的错误。
该方法一般在规定了取值范围或规定了值的个数,或者明确输入条件的有序集合中使用。
通常按照以下规则进行边界点的划分:
- 如果规定了输入域的取值范围,则选取刚好在范围边界的点,以及刚好超过边界的点,作为测试的输入数据。
- 如果规定了输入值的个数,则用最大个数,最小个数,比最小个数少1,比最大个数多1的数作为测试数据。
- 如果规定了输入是一个有序的集合,则选取集合的第一个元素和最后一个元素作为测试数据。
【案例解析】
某银行系统,允许用户通过日期对交易进行查询,系统对输入日期的限定为1990年1月~2049年12月,并规定:日期由6位数字字符组成,前4位表示年,后2位表示月。
分析输入条件有6位数字字符,年份的范围,月份范围,
输入条件 |
有效等价类 |
有效边界点 |
无效等价类 |
无效边界点 |
日期长度 |
6位数字字符 |
6位 |
小于6位数字字符 |
5位 |
大于6位数字字符 |
7位 |
|||
日期类型 |
数字字符 |
无 |
非数字字符 |
无 |
年份范围 |
1990-2049 |
1990,2049 |
小于1990 |
1989 |
大于2049 |
2050 |
|||
月份范围 |
01-12 |
01,12 |
小于1 |
00 |
大于12 |
13 |
判定表分析法
在等价类设计法中,没有考虑输入域的组合情况,导致设计的用例中无法覆盖输入域之间存在关联的地方。为了弥补等价类设计的不足,这里介绍一种新的用例设计方法——判定表分析法。
判定表分析法主要是分析和表达多种输入条件下系统执行不同动作的技术。在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了,它可以把复杂的逻辑关系和多种条件组合的情况表达得很明确。判定表由四个部分组成,
1)条件桩:列出被测对象的所有输入,并列出输入条件与次序无关。
2)动作桩:列出输入条件系统可能采取的操作,这些操作的排序顺序没有约束。
3)条件项:列出输入条件的其他取值,在所有可能情况下的真假值。
4)动作项:列出在条件项的各种取值情况下应采取的动作。
【案例解析】
书籍阅读指南,需求描述如下:
1)觉得疲倦但对书的内容感兴趣,同时书的内容让你糊涂,回到本章重读。
2)觉得疲倦但对书的内容感兴趣,同时书的内容不让你糊涂,继续读下去。
3)不觉得疲倦并对书的内容感兴趣,同时书的内容让你糊涂的话,回到本章重读。
4)觉得疲倦并对书的内容不感兴趣,同时书的内容不让你糊涂,停止阅读休息。
5)觉得疲倦并对书的内容不感兴趣,并且书的内容让你糊涂,请停止阅读休息。
6)不疲倦,对书的内容感兴趣,书的内容不糊涂,继续读下去。
7)不疲倦,不感兴趣,对书的内容糊涂,跳到下一章去读。
8)不疲倦,不感兴趣,对书的内容不糊涂,跳到下一章去读。
首先分析条件桩和动作桩,条件项有您觉得疲倦吗、您对书中的内容感兴趣吗、书的内容让你糊涂吗;动作桩有回到本章重读、继续读下去、跳到下一章去读、请停止阅读休息。
其次根据条件来计算规则23个(即8),构成判定表.
再根据合并规则,将1和5、2和6、3和4、7和8合并得到判定表
合并后只剩4条规则,看上去用例数减少了,但是很容易产生漏测的风险。
流程分析法(场景法)
流程分析法也称场景法,主要是针对测试场景类型。它是从白盒测试设计方法中的路径覆盖分析法演变过来的一种重要的方法。在白盒测试中,路径就是指函数代码的某个分支组合,路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。在黑盒测试中,若将软件系统的某个流程看成路径的话,则可以针对该路径使用路径分析的方法设计测试用例。
在实际工作中,流程分析法是最容易理解和执行的,它是主要通过流程对系统的功能点或业务流程进行描述,可以展示测试效果。流程分析法一般包含基本流和备选流,从一个流程开始,通过描述经过的路径来遍历所有的基本流和备选流。
- 基本流:是指程序的主流程,是实现业务流程最简单的路径。
- 备选流:是指实现业务流程时,因错误操作或者是异常操作,导致最终未达到目的流程。
直线表示基本流;其他曲线表示为备选流。由图可以看到,一个备选流可以从基本流开始;也可以从备选流开始。备选流的终点,可以是一个流程的出口,也可以是回到基本流,还可以是汇入其他的备选流。可以确认的流程如下所示:
备注:(1)图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径;
(2)一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);
(3)一个备选流可能起源于另一个备选流(如备选流2);
(4)一个备选流也可能终止用例而不再重新加入到某个流(如备选流2和4)
二、场景法使用步骤场景法的使用步骤如下:
(1)分析需求,根据需求说明描述出程序的基本流及各项备选流
(2)根据基本流和各项备选流生成不同的场景
(3)针对每一个场景生成相应的测试用例
(4)重新审核生成的所有测试用例,把多余的测试用例去掉,确定好每一个测试用例,并设计测试数据
【案例解析】
小明要在某购物网站上购买一件衣服,使用场景法设计测试用例
前提条件:
1)假设小明在购物网站上的账号为:ming,密码:123
2)假设小明的银行卡账号为:62282***1216,密码:123
3)衣服的价格为:180元
步骤一:列出基本流和备选流
类型 |
场景描述 |
基本流 |
小明进入某购物网站,选择好一件喜欢的衣服->加入购物车->点击付款->输入该网站正确的账号密码登录系统->再次点击付款->输入正确的银行卡账号密码->支付成功 |
类型 |
场景描述 |
备选流1 |
登录用户名不存在或不正确 |
备选流2 |
登录密码不正确 |
备选流3 |
输入银行卡账号不正确 |
备选流4 |
输入银行卡密码不正确 |
备选流5 |
银行卡余额不足 |
备选流x |
用户退出系统 |
步骤二:根据基本流和备选流来确定场景
场景 |
描述1 |
描述2 |
场景1-购物成功 |
基本流 |
|
场景2-登录用户名不存在或不正确 |
基本流 |
备选流1 |
场景3-登录密码不正确 |
基本流 |
备选流2 |
场景4-输入银行卡账号不正确 |
基本流 |
备选流3 |
场景5-输入银行卡密码不正确 |
基本流 |
备选流4 |
场景6-银行卡余额不足 |
基本流 |
备选流5 |
步骤三:针对各种场景,设计相应的测试用例
场景/条件 |
用户账号 |
用户密码 |
银行卡账号 |
银行卡密码 |
银行卡余额 |
预期结果 |
场景1-购物成功 |
V |
V |
V |
V |
V |
系统提示“登录成功”,系统提示“支付成功” |
场景2-登录用户名不存在或不正确 |
I |
N/A |
N/A |
N/A |
N/A |
系统提示“输入的用户名不存在或者不正确” |
场景3-输入密码不正确 |
V |
I |
N/A |
N/A |
N/A |
系统提示“输入的登录密码不正确” |
场景4-输入银行卡账号不正确 |
V |
V |
I |
N/A |
N/A |
系统提示“输入的银行卡账号不正确” |
场景5-输入银行卡密码不正确 |
V |
V |
V |
I |
N/A |
系统提示“输入的银行卡密码不正确” |
场景6-银行卡余额不足 |
V |
V |
V |
V |
I |
系统提示“银行卡余额不足” |
备注:V-表示有效的数值;I-表示无效的数值;N/A表示不适用
总结
1、场景法的使用会考虑到较多会出现的情况,适用于业务流程较清晰的软件系统或功能模块