一、测试用例的基本要素
测试用例的概念:测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
评价测试用例的标准:对比好坏用例的评价标准
- 用例表达清楚,无二义性
- 用例可操作性强
- 用例的输入与输出明确。一条用例只有一个预期结果
- 用例的可维护性好
- 用例对需求的覆盖率高
二、测试用例万能公式
功能测试:产品是否实现了预期的功能
性能测试:功能测试没有问题,不代表性能好(网站速度、流畅的)
界面测试:布局、每个元素的大小、颜色、材质
兼容性测试:软件的不同版本、打开网站所用的不同浏览器,不同的系统版本、数据兼容性(不同版本数据是否展示正确且相同)
易用性测试:产品是否容易上手、提升文字(登陆时)、打开软件的操作步骤提示
安全测试:产品网站系统,用户信息,页面数据展示的是是否恰当和合适
(用户的隐式数据)
登录时候是否加密
接口返回值—SQL注入
越权问题(垂直越权和水平越权):权限、管理员、普通用户
不同的角色对应不同的功能
1.水杯测试用例(非软件类)
2.网站登录测试用例(软件类)
三、测试用例的具体设计方法(根据需求)
1.等价类
- 有效等价类
- 无效等价类
示例:
登录密码:密码位数不得小于6位,不得大于25位
有效等价类:测试用例密码位数10位
无效等价类:测试用例密码位数4位
2.边界值
有效边界+无效边界
如上述例子
无效边界为5、26长度密码
有效边界为规定位数内的密码
边界值有三个点需要注意
上点:边界上的点如密码长度为6或25位,即6,25是边界值的上点
内点:顾名思义,边界以内的点称为内点
离点:如果边界为闭区间(即包含该值的点,如6,25),则离点为边界外的点,如果是开区间(即大于或者小于,如x>5,则x不能取5),离点就是范围内的点示例1:
集合为[1,11]:
上点:1,11(边界上的点)
内点:5(属于边界内的点)
离点:0,12(位于1,11区间以外)示例2:
集合为(1,11]:
上点:1,11(边界上的点)
内点:5(属于边界内的点)
离点:2,12(集合不包括1,但是包括11,所以离点取1范围内的点和11范围外的点)示例3:
集合为(1,11):
集合为(1,11]:
上点:1,11(边界上的点)
内点:5(属于边界内的点)
离点:2,110(集合不包括1,11,所以离点取1,11范围内的点)
3.判定表(因果图)【使用场景较少】
使用场景:输入条件的组合对应不同的结果,例如外卖红包,订单满30减10
设计步骤
-
确认输入条件和输出条件
1.输入条件:我不需要外卖,即不输入或者说我不提交订单;反之我提交订单;订单不够30元,是一个输入;相对应,订单超过30元也是一个输入(以上就是四个输入:需不需要外卖,以及够不够30元)
2.输出条件:有无优惠 -
找到输入条件的输出条件的关系
不提交订单,外卖小于30,无优惠
不提交订单,外卖大于30,无优惠
提交订单,外卖小于30,无优惠
提交订单,外卖大于30,有优惠 -
画判定表
有无提交订单 | Y | Y | N | N |
---|---|---|---|---|
够不够30元 | Y | N | Y | N |
有无优惠 | Y | N | N | N |
- 根据判定表编写测试用例
4.正交表(用的少)
正交实验法指从打大量的实验中中挑选出适量的、有代表性的点,依据”正交表“从而合理的设计出测试用例。
设计步骤
1、找出因素数和水平数
2、生成正交表(用到了allpairs)
3、根据正交表来编写测试用例
4、补充可能存在遗漏但是非常重要的测试用例举例:我们要针对一个网站的用户注册页面来设计一个测试用例
1、找出因素数和水平数
因素:用户名、邮箱、密码、确认密码
水平 :填写、不填写
2、生成正交表(用到了allpairs)
3、根据正交表来编写测试用例
全部填写
填写用户名,不填写邮箱、密码、确认密码
填写邮箱、确认密码,不填写用户名、密码
填写密码,不填写用户名、邮箱、确认密码
填写用户名、邮箱,不填写密码确认密码
填写确认密码,不填写用户名、邮箱、密码
4、补充可能存在遗漏但是非常重要的测试用例
全部不填写
5.场景设计法
首先需要明确什么是场景,如网购一个商品就是一个场景
场景就是一个测试用例,由两部分构成
主事件流:网购商品流程(打开app->搜索商品->选择商品->加入购物车->选择支付方式->支付->生成支付信息)
次事件流:包含于主事件流以外的情况,如app打不开,闪退等;搜索的结果并没有该类型商品;我选择商品以后还需要其他商品....
那么上述流程就是测试流程,也是测试点
测试点1:打开购物app,搜索商品,选择商品,加入购物车,选择支付方式,支付成功,生成订单
测试点2:打开app,app闪退
测试点3:打开app,搜索商品,没有商品信息
......
6.错误猜测法(注意!不是瞎猜!!!)
根据 测试人员的经验和知识的积累,来猜测某一块功能有问题。
随后,有针对性的进行测试用例的编写。
说白了:就是程序员的经验之谈。
错误猜测法,有点类似于探索性测试。
针对性比较强,比较依赖测试人员个人的水平。
比如:
搜索查询框 - 空格
在某个 软件/网页 中,搜索关键字的时候,而且这个关键字,在服务器的数据库中是有对应的数据的。
只要我们在关键字的左右两侧敲一个空格(关键字 :“空格 + 奥特曼 + 空格”),就搜索不到。
因为这两个空格,导致原本可以搜索到的数据,现在搜索不到了。
在Java中,String类型有一个方法 trim(),可以去除 字符串 前后的 空格。
由这个问题引申出另外一个问题:字符串中间的空格是否要去掉?
答案:不能!
中间的空格,一般是用户刻意敲的,可能具有实际的意义。
而两侧的空格,可能是用户误敲的,没有实际的意义。