SoftwareTest4 - 咋设计一个好的测试用例

Hello , 大家好 , 又给大家带来新的专栏喽 ~
这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .
那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html
希望大家都能够拿到好的 Offer

一 . 设计测试用例的万能公式

测试用例的概念 : 对被测系统提供的一组集合
测试用例存在的意义 : 帮助测试人员了解测什么、怎么测
假如说有一个水杯 , 针对水杯来设计测试用例
初步分析 :

1. 水杯是否可以盛水
2. 水杯不漏水
3. 水杯耐温
4. 水杯是否方便喝水
5. 水杯喝水是否喇嘴
6. 水杯携带是否方便
7. 水杯是否保温
8. 水杯是否防摔
9. 水杯的容量、外观、质量是否符合预期
10. …

上述过程 , 就是想一个说一个 , 按照这样设计测试用例的方法 , 肯定不是很好的
那么就给大家介绍一个万能公式帮助大家分析思路 , 让大家的测试用例尽量覆盖全面
功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试

功能测试

对产品的功能设计测试用例
正常情况下来源于需求文档 , 但是面试的时候面试官不可能给你一个需求文档让你分析 , 所以还需要来自于一定的生活经验

性能测试

我们的功能虽然实现了 , 但是好不好使还不一定 , 还得测试一下性能如何 , 我们就可以测试一下极端情况 : 高并发测试、响应时间测试等等
比如小刀电动车和法拉利 , 虽然都能用 , 但是从性能来说 : 法拉利还是比小刀电动车牛逼的
功能测试没问题不代表性能就没有问题
后续还会给大家讲解性能测试

界面测试

我们在软件开发之前 , 就会设计出产品模型图 , 工作中需要按照产品模型图去进行测试 , 那么测试人员测试的时候也要关注实现出来的效果是否与需求文档相同 , 我们需要考虑每个元素的大小、颜色、材质、形状；页面跳转、文字的错别字、遮挡等 , 都需要进行测试

兼容性测试

版本的兼容性 : 软件的不同版本是否兼容
浏览器的兼容性 : 不同浏览器展示效果是否相同
系统兼容性 : Windows/Mac
数据的兼容性 : 有没有可能一行数据 , 在 Windows 上一行显示 , 但是在 Mac 版本上就分两行显示了

易用性测试

产品是否具备简单易上手的属性 : 新用户没用过你的产品 , 那么你是否能让用户上手就能用明白 .
玩游戏还有新手教程呢

安全测试

用户的隐私数据是否加密 (比如说注册场景注册成功之后直接把密码展示在界面上了 , 或者接口返回值(响应) : 比如说这个接口返回了用户的隐私数据)
还有一些操作需要注意 , 比如 :
SQL 注入

后台的查询语句 : select * from info where ziduan = 关键字;
假如用户输入的关键词是 ' or 1='1', 此时就导致全表数据返回
select * from info where ziduan = '1' or 1='1';
1
2
3

越权问题
分为垂直越权和水平越权
垂直越权 : 我是普通用户 , 但是能操作管理员具备的操作
水平越权 : 我们都是普通用户 , 但是张三可以操作或者浏览到只有我能操作的数据 , 就比如 : 张三和李四都记笔记 , 但是张三能看到李四记的笔记 , 也能修改李四记的笔记 , 这肯定不行 , 所以这就是水平越权
假如我就是个普通用户 , 你给了我很大的权力 , 那我就可以为所欲为了 , 这肯定是不可以的

---

案例

案例1 : 对水杯设计测试用例

接下来 , 使用万能公式 , 对水杯设计测试用例
设计测试用例的过程 , 推荐大家使用思维导图 , 下载 XMind 即可 https://xmind.cn/

水杯的测试用例.xmind
那么设计测试用例一定是越多越好吗 ?
如果这个是面试的时候面试官问的 , 那答案一定是 : 不是 , 测试用例虽然能提高测试质量 , 但是质量覆盖率高才最好
但是 , 在面试的时候设计测试用例越多越好 , 面试官出测试用例题是为了考察大家设计测试用例的能力 , 考察大家的发散性思维 , 你写的越多 , 靠谱的就越多

---

案例 2 : 对登录页面设计测试用例

登录页面测试用例.xmind
在对登录页面设计测试用例的过程中 , 我们需要关注到几个问题

1. 在性能测试中 , 有一个叫做 “用户打开页面需要多久” 的测试用例 , 这个案例我们为什么要不写成 “用户打开页面的响应时间” 呢 ?

2. 兼容性测试中 , 提到了不同浏览器 . 那市面上有很多浏览器 , 难道我们都要去测试吗 ?

   这当然不是 , IE 浏览器都被淘汰了 , 还测试他干嘛 .
   那我们选择测试浏览器的标准是什么 ?

   1. 大部分用户使用的
   2. 在工作中 , 后台可以获取到用户手机型号/浏览器/浏览器的版本号 , 后台把这些信息汇总 , 我们只需要根据给出的数据进行筛选 , 使用人数多的我们优先测试

二 . 具体设计测试用例的方法

2.1 等价类

我们目前有一个需求 : 用户的密码为 6~18 位 , 那么测试的时候我们应该提出哪些测试用例呢 ?
是 6 位 的密码 , 还是 15 位的密码 , 还是 20 位的密码呢 ?
难不成我们每个数字都测试一遍 , 从 -∞ ~ +∞ ?
使用穷举法明显不太可能 , 但是我们可以根据需求特征 , 使用等价类测试方法找出具有标志性的测试用例进行测试

---

等价类的概念

等价类实际上就是一个 分区/分块 的概念

依据需求将输入 ( 特殊情况下会考虑输出 ) 划分为若干个等价类

把一个需求分解成许多小需求

从等价类中选出一个测试用例 , 如果这个测试用例测试通过 , 则认为所代表的等价类测试通过
这样就可以用较少的测试用例达到尽量多的功能覆盖 , 解决了不能穷举测试的问题
等价类的划分 :

1. 有效等价类 : 根据程序的需求说明书 (其实就是需求文档) , 是合理的、有意义的集合
2. 无效等价类 : 根据程序需求说明书 , 是不合理的、无意义的集合

所以上面那个例子中 , 6~18 位就是有效等价类 , 无效等价类就是非 6~18 位(小于 6 位 , 大于 18 位)
再举个栗子 : 购买的水果有橘子、柠檬、香蕉
其中 , 有效等价类就是橘子、柠檬、香蕉 , 无效等价类就是其他水果(比如 : 柚子 , 榴莲 , 樱桃等等)

等价类的用例编写

关于等价类的测试用例编写 , 一般分为两个步骤

1. 确认有效等价类和无效等价类
2. 编写测试用例

那么我们的测试用例就可以编写下面这几条 :

1. 输入长度为 6~18 位的密码 , 具体是 10 位
2. 输入长度为小于 6 位的密码 , 具体是 1 位
3. 输入长度为大于 18 位的密码 , 具体是 20 位

在测试用例的编写中 , 我们还需要格外关注边界值的问题

2.2 边界值

我们之前介绍过双 11 活动
假如我们的代码是这样写的

11.11 00:00:00 <= activityTime < 11.12 00:00:00
1

如果你边界条件控制不好 , 就容易出现很大问题
如果我们这样写

11.11 00:00:00 <= activityTime < 11.11 23:59:59
1

那 11.11 23:59:59 到 11.12 00:00:00 这一分钟就不算了吗 , 有的人就是卡最后一分钟抢货 , 你直接不让人家抢能行吗 ?
所以边界值的问题在我们测试的过程中 , 非常重要 !
那边界值指的是什么 ?
边界值指的就是有效边界 + 无效边界 , 什么意思 ?
分析一下我们最刚开始的栗子

再举个栗子 : 成绩大于 60 分 , 请问他的边界值是什么 ? (成绩一定为整数)
有效边界 : 61 分 (因为要求大于 60 分 , 60 就不能算)
无效边界 : 59 分

有的地方还这样讲 : 边界值集合 = 边界值 + 次边界值

2.3 判定表

下面这张图片 , 就是一个判定表 , 在不同的条件下 , 进行不同的操作
赊欠情况 > 60 天 , 并且发货单金额大于 500 元 , 我们不发出批准书
赊欠情况 > 60 天 , 并且发货单金额小于等于 500 元 , 我们发出批准书发出发货单、发出赊欠报告
赊欠情况 <= 60 天 , 我们发出批准书发出发货单

判定表使用的场景比较少
使用场景 : 输入条件的组合对应不同的结果
给大家讲一下判定表设计测试用例的步骤 :

1. 确认输入条件和输出条件
2. 找出输入条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试用例

给大家举个案例 : 双 11 , 平台搞活动 , 当某一订单使用了红包或者订单金额大于 300 元 , 就被认为是优惠订单 , 否则是不优惠的订单
按照步骤就进行分析吧

1. 确认输入条件和输出条件

   1. 输入条件 : 红包、订单金额大于 300 元、订单已提交

      一定要格外注意订单已提交这一个条件 , 如果订单不提交 , 就不会有任何事发生

   2. 输出条件 : 有优惠、无优惠

2. 找出输入条件和输出条件之间的关系 : 先确定输入条件之间有效的排列组合 , 最后根据排列结果分析并给出分析结果

AC:有红包并且提交了订单
BC:订单金额大于 300 元并且提交了订单
ABC:有红包并且订单金额大于 300 元,最后提交了订单
A:有红包,订单金额未大于 300 元,没提交订单(有优惠,不买,就是玩)
B:订单金额大于 300 元,无红包,没提交订单(有优惠,不买,就是玩)
C:无红包,订单金额未大于 300 元,提交了订单(大冤种)
AB:有红包,并且订单金额大于 300 元,但是未提交订单(有便宜不占)
非ABC:无红包,订单金额未大于 300 元,未提交订单(啥也不干)
1
2
3
4
5
6
7
8

他们对应的输出结果如下 :

3. 根据上面的排列组合画判定表

符合条件的就填 Y , 不符合条件的就填 N

4. 根据判定表编写测试用例

1.有红包、订单金额小于等于300元,并且提交订单,则该订单有优惠
2.订单金额大于300元、无红包,并且提交订单,则该订单有优惠
3.有红包、订单金额大于300元,并且提交订单,则该订单有优惠
4.有红包、订单金额小于等于300元,但是未提交订单,则该订单无优惠
5.订单金额大于300元、无红包,但是未提交订单,则该订单无优惠
6.无红包、订单金额小于等于300元,并且提交订单,则该订单无优惠
7.有红包、订单金额大于300元,但是未提交订单,则该订单无优惠
8.无红包、订单金额小于等于300元,并且未提交订单,则该订单无优惠
1
2
3
4
5
6
7
8

与判定表类似的还有因果图 , 但是因果图使用场景及其的少 , 并且极其复杂 , 就不带着大家来看了 , 大家只需要知道 , 因果图是根据判定表画出来的 , 而且因果图画法不唯一
这就是因果图 , 看着就很头疼

2.4 场景设计法

场景设计法使用的场景也非常少 , 它主要用来进行一个思路引导的作用 , 告诉我们不能完全参考需求文档上写的基本流程 , 要尽可能多地设计可能存在的意想不到的流程 .
分为基本事件流和备选事件流
看取钞的例子

基本事件流就是一件事的主干 , 备选时间流就是在基本事件流的基础上发生的额外的事情 , 一般备选时间流要比基本事件流要长
我们也可以通过场景设计法编写测试用例

1. 基本事件流的用例 : 先插卡 , 然后输入正确的密码 , 选择取款功能 …
2. 备选事件流的用例 :
   1. 插入卡 , 但是插不进去 …
   2. 密码输入错误 , 把卡弹出来了
   3. …

2.5 正交法

正交法的定义

正交表在实际测试中 , 用到的场景也比较少
使用判定表设计测试用例 , 很容易就设计出了非常多测试用例 , 这样对于测试工作的推进并不是什么好事 , 所以我们需要筛选出尤其关键的测试用例进行测试 , 用局部代替所有 , 所以就可以使用正交法筛选测试用例 .
我们先来看什么是正交法
正交试验设计法指从大量的试验中挑选出适量的、有代表性的点，依据 “正交表” 从而合理的设计出测试用例
其中 , 提到了正交表

我们直接通过一个例子理解正交表的定义

那么我们再从软件测试的角度看一下正交表

正交法的性质

1. 每一列中，不同的数字出现的次数相等。

   

2. 任意两列中数字的排列方式齐全而且均衡。

   

根据正交表设计测试用例

1. 找出因素和水平

   找出测试用例和测试用例对应的可能性

2. 生成正交表 : 使用 allpairs 生成正交表

   pairs.zip
   下载成功之后直接解压即可 , 不要进行任何操作

3. 根据正交表编写测试用例

4. 补充可能存在遗漏但是非常重要的测试用例

接下来 , 我们就举一个案例 , 来根据正交表设计测试用例

1. 找出因素和水平 :

   因素 : 用户名、手机号、密码、确认密码、手机号
   水平 : 填写、不填写

2. 生成正交表

   首先 , 我们打开电脑里面的 excel 软件 ! (word 啥的都不可以)
   横行写因素 , 竖行写水平
   
   接下来 , 把这段内容选中 , 进行复制

   选中左上角 , 按住 shift 点击右下角 , 就全部选中了

   接下来 , 在我们 allpairs 的存放目录下面新建一个 txt 文件 , 名字无所谓 , 但是要记住
   
   将刚才复制的结果粘贴进 txt 文档 , ctrl + s 退出即可 , 不要去进行任何修改 !
   
   还要注意一点 , 用记事本打开不要用其他文本编辑软件

3. 使用 cmd 通过 allpairs 生成正交表

   进入到 allpairs 的文件路径 , 在地址栏输入 cmd
   
   然后输入命令 : allpairs.exe 任意文件名.txt>任意文件名jg.txt
   
   这时候 , 我们的文件夹内就出现了保存正交表结果的 txt 文档
   注意 : 这个结果文档不需要我们提前创建 , 别多此一举 , 人家 allpairs 都帮你准备好了
   
   

4. 根据正交表编写测试用例

   

1.全部填写用户名、手机号、密码、确认密码、验证码
2.填写用户名,不填写手机号、密码、确认密码、验证码
3.填写手机号、确认密码,不填写用户名、密码、验证码
4.填写密码、验证码,不填写用户名、手机号、验证码
5.填写用户名、手机号、密码,不填写确认密码、验证码
6.填写用户名、确认密码、验证码,不填写手机号、密码
1
2
3
4
5
6

5. 补充可能存在遗漏但是非常重要的测试用例 : 全部不填写

1.全部填写用户名、手机号、密码、确认密码、验证码
2.填写用户名,不填写手机号、密码、确认密码、验证码
3.填写手机号、确认密码,不填写用户名、密码、验证码
4.填写密码、验证码,不填写用户名、手机号、验证码
5.填写用户名、手机号、密码,不填写确认密码、验证码
6.填写用户名、确认密码、验证码,不填写手机号、密码
7.全部不填写用户名、手机号、密码、确认密码、验证码
1
2
3
4
5
6
7

这样 , 我们就通过了较少用例完成了基本的测试 , 避免了过多测试用例造成测试人员压力过大的问题

2.6 错误猜测法

错误猜测法就是根据测试人员自己的工作经验以及生活经验 , 猜测出现问题的位置在哪里
一般情况下测试人员非常敏感的位置就是边界值