前面部分主要是编写测试用例的方法和方向,后面一部分是编写出具体的测试用例
目录
什么是测试用例
1.设计测试用例的万能公式
1.1.从思维出发
1.2.万能公式
1.3.弱网测试
1.4.安装与卸载测试
2.设计测试用例的方法
2.1.基于需求的设计方法
2.2.等价类
2.3.正交法
编辑
2.4.场景法
2.5.判定表法
什么是测试用例
背景:我们在写程序或者刷题的时候,要想验证自己写的程序是否正确,都会代入几个特殊值去测试该程序,通过程序的结果就能判断出来。而对于我们的项目也是一样,但是测试用例会非常的多喝复杂,所以也就需要我们去学习,做到全方面的想出测试用例。
因此,对于设计测试用例有一个原则:
测试用例中一个必需部分 是 对预期输出或者结果进行定义
什么意思呢?使用当前的测试用例,就一定会有一个预期的结果,是通过或者失败。然后通过测试,就能显而易见的对比结果了。
(1)对新自行车进行测试
对于一个新项目,我们需要测试。那我们现在对一辆新买的自行车也需要测试,就需要设计测试用例,才能知道从哪些方面入手。
- 是否可以正常骑行
- 刹车是否灵敏/正常
- 坐垫是否舒服
- 外观是否有掉漆
- 等等等
这些都是我们从脑子里面想出来的一些测试用例,如果不进行记录,很快就会忘记,而且会想的不全面,因此,我们就有一些记录测试用例的手段。
(2)记录测试用例的手段
第一种:通过excel表格
第二种:通过思维导图/脑图
我们在日常学习和面试中,都是推荐使用第二种。
下面,我们通过第二种举例说明。
(3)使用脑图设计测试用例
下面是对一个键盘进行设计的测试用例
虽然通过脑图记录了很多的测试用例,但是不够具体,远远不可以作为工作中具体的测试依据。而且对于不同的对象,每次去设计测试用例都是要重新出发。
因此,我们就需要去学习设计测试用例的万能公式和方法,后续在设计测试用例的时候,就可以固定的从大多数方向入手,设计的也快,也更加全面和具体。
1.设计测试用例的万能公式
这里介绍的万能公式有两个方面,一方面是思维上的万能公式,另一个方面是具体的万能公式(方向)
1.1.从思维出发
对于设计测试用例,都需要哪些思维呢?也就是需要往那些方向去思考。
常规思考 + 逆向思维 + 发散性思维
因此,得出设计测试用例也存在几条原则
(1)测试用例的编写不仅应当根据有效和预料到的输入情况,而且也应该根据无效和未料到的输入情况
比如我们测试登陆页面,不仅要测试输入正确密码时的情况,也要测试错误密码时的情况或者其他的格式
(2)检查程序是否“未做其应该做的”仅是成功的一半,还应该测试另一半是否“做了其不应该做的”
和上一条一样,输入错误的就是不应该做的,也要进行测试
(3)计划测试工作时不应该默许假定不会发生错误
和上面的一样,不应该默认输入的密码都是正确的
上述只是设计测试用例的一些思维,仅供一些方向,但是还不够,还需要一些具体的方法。
1.2.万能公式
(1)万能公式
功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全性测试
这就是设计测试用例的万能公式,可以帮助我们从哪些方向出发,进行设计测试用例。
(2)每个方向应该测试的
- 功能测试
从产品的功能出发,验证功能是否正常(功能就是此类产品通常都具有的)
- 界面测试
我们肉眼可以看到的成为界面。可以从颜色、大小、外观入手进行测试
- 性能测试
也就是测试一些极端的情况
- 兼容性测试
例如,测试不同系统的版本、不同的浏览器等等
- 易用性测试
是否具备一些新手引导教学或者看起来易操作
- 安全性测试
是否可以保证用户的隐私安全,信息是否容易被窃取等情况
(3)登陆页面-测试用例
这些是自己通过万能公式设计的一些设计用例,看起来都非常的少。
我们看一下比较官方的设计:
上述的万能公式也只是针对大部分场景,还有一些特殊情况可能还未测试到
1.3.弱网测试
(1)弱网测试的目的
目的是尽可能保证用户的使用体验。具体的点包括下面:
- 页面响应时间是否可以接受(不同网络下,页面刷新成功的时间是否可以接受)
- 页面呈现是否完成一致(比如只加载了部分内容)
- 超时文案是否符合定义,异常信息是否显示正常(是否会提升加载超时等)
- 是否有超时重连
- 安全角度
- 大流量事件风险
(2)如何进行弱网测试
我们需要借助抓包工具,我们就以fiddler为举例
步骤:
第一步:打开fiddler
第二步:开启弱网
第三步:打开脚本编辑器设计网速
出现该页面
查询
输入关键词:m_simulateModem
找到可以设计网速的代码位置
通过前面勾选的弱网开关,就会执行里面的代码,也就是会按照里面设置的网速执行。
如何设计网速?
里面的两个数字,设置的越大,网速就越慢,反之越快。
1.4.安装与卸载测试
对于一些需要安装的软件,我们也需要进行安装和卸载的测试
主要包括两个方面
(1)安装
- 安装包是否可以正常安装
- 卸载之后,再次选择安装是否可以安装
(2)卸载
- 安装后是否可以卸载
- 安装一天后再进行卸载
- 反复多次安装和卸载
- 卸载到一半退出,卸载是否成功或者卸载一半
2.设计测试用例的方法
2.1.基于需求的设计方法
比如,要测试一个登陆的界面,首先根据万能公式写出大概得方向,然后针对每个方向,都会有很多的需求,根据需求来设计测试用例。
比如:登陆账号密码,可以分出测试登陆成功和登陆失败的两种测试用例;然后需要很限制密码的长度,针对密码的长度,也进行设计测试用例,这就是基于需求的设计测试用例方法
2.2.等价类
我们为什么要设计等价类呢?举个例子,比如上述的密码长度规定在6-15位,那如何更快的测试呢?总不能一个个长度的密码都要测试吧?显然这是不科学的做法,因此就需要有等价类。
(1)等价类概念
依据需求将输⼊(特殊情况下会考虑输出)划分为若⼲个等价类,从等价类中选出⼀个测试⽤例,如果?这个测试⽤例测试通过,则认为所代表的等价类测试通过,这样就可以⽤较少的测试⽤例达到尽量多的?功能覆盖,解决了不能穷举测试的问题。
解决的问题:可能需要穷举的测试
(2)等价类分类
等价类分为:有效等价类和无效等价类
1.有效等价类:满足需求的集合、有效的输入。比如密码长度要求6-15位,那么在这个范围内的等价类就成为有效等价类
2.无效等价类:根据需求说明书,不满足需求的集合。比如上面的,测试密码长度不在合理范围内的等价类就称为无效等价类
(3)有效、无效等价类举例
根据密码长度6-15位举例:
有效等价类:6位密码长度、15位密码长度,10位密码长度
无效等价类:5位密码长度、16位密码长度
(4)边界值
简介:边界值是基于等价类的一种补充,也就是测试边界值的一个黑盒方法,这里的边界也就是来自等价类的边界。
1)边界值分为:边界值+次边界值
1.有边界值是有效等价类中的数据,那么次边界值是无效等价类中的边界
2.若边界值是无效等价类中的数据,那么次边界值为有效等价类中的边界
2)举例:
需求范围1:密码有效长度为:[6,15]
有效等价类的范围:[6,15],无效等价类:<6或者>15
边界值:6,15-----边界值属于有效等价类中的数据,所以次边界值为5,16,也就是无效等价类的边界
需求范围1:密码有效长度为:(6,15)
有效等价类的范围:[7,14],无效等价类:<=6或者>=15
边界值:6,15-----边界值属于无效等价类中的数据,所以次边界值为:7,14;也就是有效等价类的边界值
2.3.正交法
这种方法比较困难,实际中一般很少直接使用,就算进行使用,也是借助工具生成的。
对于一些场景,比如部分填写信息,那得设计多少的测试用例?是庞大的一个数字,所以我们就需要通过正交法来辅助编写测试用例。
比如有如下的信息,姓名、电子邮箱、密码、确认密码、验证码,这五个信息,每个选项都有填写/不填写,组合起来就是32可能,实际肯定不会采取这种方案,因此就需要通过正交法产生一个正交表,正交表中就可以帮助我们编写测试用例了。
(1)概念
正交表的两个性质:
- 每一列中,不同的数字出现的次数相等
- 任意两列中数字的排列方式齐全而且均衡
对于性质1,比如第一列因素中:数字1、数字2、数字3都出现了3次,次数相同。
性质2:这就是对比两列得出的结果了,比如数字1在每一行中都出现过,数字2、3同理。
(2)设计正交表的步骤
1)根据需求找出因素和水平
2)将因素和水平写入到表格中(表格不需保存)
3)在allparis.exe同级文件夹下创造一个txt文件,将excel表格中的内容复制进去(可以保证格式没有问题,否则后续操作会出问题)
4)使用allparis.exe工具对txt文件生产正交表文件(通过cmd控制台,使用allparis.exe test01.txt > res-test01.txt,两个txt是文件名字,可随意)
5)根据生成的正交表编写测试用例
(3)使用正交法编写测试用例
1)根据需求找出因素和水平
2)将因素和水平写入到表格中(表格不需保存)
3)在allparis.exe同级文件夹下创造一个txt文件,将excel表格中的内容复制进去(可以保证格式没有问题,否则后续操作会出问题)
创造txt文件
复制内容
4)使用allparis.exe工具对txt文件生产正交表文件(通过cmd控制台,使用allparis.exe test01.txt > res-test01.txt,两个txt是文件名字,可随意)
第一步:
第二步:
第三步:查看新文件
5)根据正交表,编写测试用例
其中,~的意思是可以填写,也可以不填写
- 姓名填写,电子邮箱填写,密码填写,确认密码填写,验证码填写
- 姓名填写,电子邮箱不填写,密码不填写,确认密码不填写,验证码不填写
- 姓名不填写,电子邮箱填写,密码不填写,确认密码填写,验证码不填写
- 姓名不填写,电子邮箱不填写,密码填写,确认密码不填写,验证码填写
- 姓名~填写,电子邮箱填写,密码填写,确认密码不填写,验证码不填写
- 姓名~填写,电子邮箱不填写,密码不填写,确认密码填写,验证码填写
- 姓名不填写,电子邮箱不填写,密码不填写,确认密码不填写,验证码不填写
2.4.场景法
目前很多的软件的每个功能都可以形容成一个个事件,也就是一个个流程,所以我们就可以根据场景来设计测试用例
(1)概念
我们通常以正常的⽤例场景分析开始,然后再着⼿其他的场景分析。场景法⼀般包含基本流和备⽤流,从⼀个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备⽤流来完成整个场景。
场景主要包括4种主要的类型:正常的⽤例场景,备选的⽤例场景,异常的⽤例场景,假定推测的场景。
(2)举个例子
我们以去逛街买衣服为例
正常的流程就是:逛街-->到达服装店-->选上衣服-->拿下衣服。但是呢,在实际生活中,难免会出现一些意外或者突发情况,就会导致无法按照正常的流程完成,即使这样,最终也是完成了买衣服的任务。
所以,我们就可以根据不同的流程去测试软件的功能。
(3)场景法软件测试举例
我们以登陆邮箱为例
正常流程:输入正确邮箱账号,输入正确密码,在输入验证码,点击登陆即可完成。但是我们也要测试一些其他的流程,也就是备用流
测试1:输入正确邮箱账号,输入正确密码,输入验证码,点击登陆,登陆成功。
测试2:输入正确的邮箱账号,输入正确的密码,输入错误验证码,登陆失败,输入正确验证码,登陆成功。
测试3:输入正确邮箱账号,输入错误密码,输入正确验证码,登陆失败,重新输入正确密码和验证码,登陆成功。
……
像这样的场景测试用例有很多很多,大家可以去试试看。
2.5.判定表法
对于上面的一些方法,显然还不能应付所有的场景,比如说,有几个选项,不同的组合会造成结果不一样,如果使用正交法就无法解决了。
判定表法是一种逻辑判断工具,几种条件组合在一起会得出一个结果
(1)步骤
1)确认需求中输入条件和输出条件
2)找出输入条件和输出条件之间的关系
3)画判定表
4)根据判定表编写测试用例
下面我们以上面的步骤来进行举例
(2)举例
有一个需求是这样的,对于邮箱注册,如果账号中包含admin字符,或者通过内部链接进入注册页面,最后提交注册按钮,就可以成为管理员身份,反之都不行。
所以成为管理员身份有两个条件
1)确认需求中输入条件和输出条件
输入条件:账号包含admin字符,或者内部链接,最后提交注册按钮
输出条件:管理员身份/非管理员身份
2)找出输入条件和输出条件之间的关系
账号包含admin字符,提交注册按钮,成为管理员身份;
通过内部链接进入注册页面,提交注册按钮,成为管理员身份
其他的条件,都不能成为管理员身份
3)画判定表
我们以上面的表格为例使用excil画出表格
4)根据判定表书写测试用例
比如上述有8列,就可以编写出8个测试用例
- 账号包含admin,提交注册按钮,成为管理员身份;
- 内容链接进入注册页面,提交注册按钮,成为管理员身份
- 账号包含admin,不提交注册按钮,不能成为管理员身份
- 账号包含admin,通过内部链接进入,提交注册按钮,成为管理员身份
- ……
以上就是关于测试用例篇的全部内容了,感谢各位观看