软件测试用例设计方法详解

软件测试用例设计方法详解

引用

CSDN

1.

https://blog.csdn.net/WR1207/article/details/136624679

测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

评价测试用例的标准：对比好坏用例的评价标准

• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高

测试用例的设计方法（黑盒测试）

基于需求进行测试用例的设计

基于需求设计的测试用例只是一个大概的测试用例

如果拿着这个用例去进行测试，测试的软件不完善

这个测试方法只是针对软件进行了大概的测试

具体的设计方法

等价类

2.2.1.1 等价类思想

我们举个例子：

在我们品尝美食的时候，只需要吃一口就知道这道菜是否好吃

此例子就是等价类思想

2.2.1.2 什么是等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例

如果这个测试用例测试通过，则认为所代表的等价类测试通过

这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充

以上述的需求为例：

用户名 （必填），录入用户名 （ 6至15 ） 字符类型 A-Z，不区分大小写

用户名由长度为 6-15 位的字符串组成，那么针对字符有效等价类为A-Z，a-z

无效等价类为两个：

数字：1，0.1，-1 特殊字符：@，#，￥，空格

2.2.1.3 如何通过等价类设计测试用例

1. 充分理解需求
2. 划分有效等价类 和 无效等价类
3. 细分有效等价类，细分无效等价类
4. 组合有效等价类，组合无效等价类

第一步 和 第二步

第三步 和 第四步

有效等价类在组合的时候，一个测试点，尽可能多的去覆盖有效等价类

无效等价类在组合的时候，只能组合一个无效等价类，其余的需要的有效等价类组合

2.2.1.4 什么样的需求适用于等价类这个方法

输入数据是无穷的，但是输入数据有特点

边界值

边界值分析法就是对输入或输出的边界值进行测试的一种 黑盒测试方法

通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界

2.2.2.1 上点、离点、内点

上点：无论是开区间还是闭区间还是半开半闭区间，上点就是边界上的点

内点：无论是开区间还是闭区间还是半开半闭区间，内点就是边界内的点

离点：边界左右的一个店，如果是闭区间，离点就是范围外的点，如果是开区间，离点就是范围内的点

例子：

输入框长度为 [1, 11] ，取边界值为：1、11、12、0

上点：1、11

内点：5

离点：0、12

输入框长度 (1, 11]

上点：1，11

内点：5

离点：2，12

输入框长度 (1, 12)

上点：1，11

内点：5

离点：2，10

2.2.2.2 设计测试用例步骤

1. 充分理解需求
2. 找离点、内点、上点
3. 针对离点、内点、上点 设计测试用例

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力

以注册为例

1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文

场景设计法

2.2.4.1 什么是场景

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

2.2.4.2 设计测试用例步骤

1. 主事件流
2. 次事件流
3. 将主事件流和次事件流串起来就会形成场景，一个场景就是一个测试用例

以淘宝购物为例子

首先是主事件流：

1. 打开 app
2. 搜索商品
3. 选中商品
4. 加入购物车
5. 选择支付方式
6. 支付
7. 生成订单

其中会出现以下这些问题（次事件流）：

在打开中可能会出现 app 闪退

可能会没有搜索出来任何商品

电脑没有电

改了关键词搜索出来了商品

只看了商品最上面的信息

还看了商品其他信息

没有网了

加入一件，加入两件，加入N件

加入购物车的时候，商品下架

绑定了银行卡

没有绑定银行卡

绑定了微信

白条

支付成功

银行卡没有钱

没有绑定任何支付方式

支付超时

订单状态是什么

测试用例：

1. 打开淘宝app，搜索商品，选中商品，加入购物车，选择支付方式，支付成功，生成订单
2. 打开淘宝，app闪退，没有订单

判定表

2.2.5.1 逻辑关系

1. 恒等：条件为真，结果一定为真，条件为假，结果一定为假
2. 与：条件全为真，结果才为真，条件中有一个为假，结果为假
3. 或：条件全为假，结果才为假，条件中有一个为真，结果才真
4. 非：条件为假，结果才为真

2.2.5.2如何通过判定表法设计

1. 充分理解需求
2. 分析所有有可能的输入和可能的输出
3. 找出输入与输出之间的对应关系
4. 画判定表
5. 把判定表对应到每一个测试用例

案例：

假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进行优惠”

输入：订单提交，订单没有提交，金额大于等于300，金额小于300，有红包，无红包

输出：有优惠，没有优惠

对应关系：

订单已提交，金额大于等于300，有红包，有优惠

订单已提交，金额大于等于300，没有红包，有优惠

订单已提交，金额小于300，有红包，有优惠

订单已提交，金额小于300，没有红包，没有优惠

订单未提交，金额大于等于300，有红包，没有优惠

订单未提交，金额大于等于300，没有红包，没有优惠

订单未提交，金额小于300，有红包，没有优惠

订单未提交，金额小于300，没有红包，没有优惠

判定表：

正交表

2.2.6.1 概念

1. 因素：变量
2. 水平：变量的取值

2.2.6.2 正交表的性质

每一列中 各数字 出现的次数都一样多

任何两列中的 各有序数对 出现的次数都一样多

2.2.6.2 设计测试用例步骤

1. 确定因素
2. 确定因素取值（水平）
3. 通过工具画正交表
4. 将正交表转化成测试用例
5. 补充正交表

案例：

以注册的需求为例：

姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册

因素：姓名、邮箱、密码、确认密码、验证码

水平：每个元素 填写 或者 不填写

测试点：

1. 姓名填写，邮箱填写，密码填写，确认密码填写，验证码填写
2. …

测试用例设计思路（万能公式）

1. 功能
2. 界面
3. 易用性
4. 兼容性
5. 安全性
6. 性能
7. 网络

设计 物体 的测试用例

物体：

功能：如果是一个物体，功能就是这个物体经常用来干什么

界面：物体看上去形状，颜色，大小

易用性：物体设计的符合人体工学

兼容性：一个物体除了本质功能，还能做哪些事情

安全性：物体不能对人的健康有损害

性能：承受能力，以水杯为例，就可以考虑到抗压力，水杯耐热耐寒

设计 软件 的测试用例

软件：

功能：软件本职能够用来干什么

兼容：软件在各个平台能够运行，通常考虑到的设备有 IOS，Android，PC（电脑，Windows，Linux，Mac），如果是浏览器，就要考虑 浏览器版本

操作系统也要考虑它的版本

易用性：软件设计符合大众操作习惯（警告：黄色；报错：红色；通过：绿色）

安全：软件防止黑客攻击，xss漏洞，sql 注入

性能：软件页面渲染的时长，软件能够同时承载大量用户的访问

界面：图片布局，图片大小，颜色字体…

微信发送朋友圈：

zip 命令设计测试用例（压缩）：

设计测试用例 控制网络

在设计测试用例的时候，我们可以通知网络，观察软件的各个功能是否可以正常操作

这里我们可以使用 Fiddler、Charles

每上传 1KB 数据花费的时间

每上传 1KB 数据花费的时间

如果时间越大，网速就会越慢

接口测试

可以用可视化工具（postman）

接下来就可以通过 postman 来做接口测试

那么什么是接口呢？

针对接口的方法进行测试：post、get、put、delete

针对参数进行测试：针对参数的取值（取值符合类型要求，不符合类型要求，参数个数的要求，参数为空）

针对业务进行测试：接口返回的每个参数取值对不对，接口返回的参数对不对