黑盒测试：理论与实践

一. 如何设计测试用例

这里简单说一下应该如何设计测试用例, 首先, 我们知道测试用例就是测试人员向被测试系统提供的一组测试数据, 它主要包含测试环境, 测试步骤, 测试数据, 预期结果等要素;

设计测试用例的万能公式:

功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

知道了这些, 我们就可以分析需求, 然后通过一些科学的设计测试用例的方法, 从需求中提取出测试项, 再去根据测试项进行进一步的细分, 提取出测试点, 编写测试用例.

通过下面的内容来进一步学习如何设计测试用例.

二. 常用黑盒测试方法

1. 基于需求设计的测试用例

需求是测试人员进行测试的依据, 基于需求去设计测试用例是最基本的方法, 当测试人员拿到需求之后, 需要分析需求, 验证需求的合理性与正确性; 随后, 从需求中提取出测试项, 再去根据测试项进行进一步的细分, 提取出测试点, 编写测试用例.

需求文档 -> 梳理需求 (掌握需求) -> 针对文档设计测试用例 (基于需求设计测试用例)

在分析测试需求时, 一般分为功能测试需求和非功能测试需求:

功能测试需求通常包括以下几个方面:

1. 系统各个功能界面的验证
2. 借助业务把功能串起来进行测试
3. 功能的一致性, 交互性 (多功能互操作) 的测试
4. 系统的不同输入, 结果输出的业务数据测试
5. 功能的错误操作, 异常操作的测试 (属于负面测试)
6. 功能实现用到的算法验证, 有时需要用代码评审
7. 用户操作的易用性, 用户体验, 往往结合功能测试同时验证

针对具体的需求, 可以根据业务分类, 用户角色(餐厅的会员系统)或者用户操作区域等将系统的功能, 分解成若干个功能模块, 然后按照功能模块分别进行测试需求分析; 按照功能模块划分, 业务模块划分是最常见的做法.

非功能测试需求主要涉及性能, 安全性, 可靠性, 兼容性, 易维护性和可移植性等.

①功能测试 (用户基本功能需求)

比如登录页的基本功能: 登录, 找回密码, 二维码登录, 记住账号和密码等.

②性能测试

对于非软件来说, 性能可以有耐寒性, 耐高温性, 耐腐蚀性, 保温性, 使用寿命, 抗压性, 耐摔性等; 对于软件来说, 需要经常考虑以下几个方面:

1. 响应时间 (1s以内或者2s以内)
2. 多个用户同时访问, 服务器是否响应, 或者响应时间等

③易用性测试 (考虑用户体验)

易用性主要是考虑用户的使用体验, 要方便用户去使用

如: 关键功能是否容易看到, 操作起来是否方便, 必要的功能是否会有提示, 是否有使用教程等

④兼容性测试

常见的兼容性有以下几个:

1. 各个版本的操作系统是否兼容

2. 能否在各个浏览器上面兼容

3. 运行的环境: PC端, 小程序, 移动端

4. 能否在各个版本的浏览器, 操作系统上面运行

5. 能否在不同分辨率下兼容

如果是物体, 比如说水杯, 它的兼容性可以考虑, 水杯能否装一些饮料, 能否装一些其他液体…

⑤界面测试 (UI,外观)

对于物体来说就是外观, 比如形状, 颜色, 大小, 图案等方面

而对于我们软件来说主要有以下几个方面:

1. 页面布局是否合理
2. 页面是否有错别字, 病句
3. 文本框/输入框大小形状颜色等是否合理
4. 界面的设计是否符合页面的需求
5. 密码等隐私信息是否支持密文等

⑥安全测试

对于物体而言是在使用过程中可能出现的安全隐患, 如爆炸, 发生化学反应, 高温, 有毒物质等

对于软件而言主要有以下几个方面:

1. 是否存在SQL注入

2. 是否存在XSS漏洞

3. 是否存在脚本攻击

4. 是否有权限设置, 用户信息认证, 人脸识别

5. 接口安全, 私密信息以及参数是否进行加密

这里以QQ登录为例, 进行具体的测试用例设计.

基于需求设计测试用例的这种方法是其实是比较单一的, 只使用这种方法进行测试用例的设计难免会有很多的地方考虑不周, 所以下面介绍的黑盒测试方法就是在基于需求的基础上, 更精细的进行弥补和设计.

2. 等价类划分法

等价类的概念是软件测试中的一个重要概念, 它是指输入域中的一组数据, 这组数据在被测软件的处理结果上具有等价性, 简单来说等价类就是将数据划分集合, 将输入划归为不同的等价类换, 等价类中包含的所有值在软件的响应上具有相同或相似的效果.

依据需求将输入 (特殊情况下会考虑输出) 划分为若干个等价类, 从等价类中选出一个测试用例, 如果这个测试用例测试通过, 则认为所代表的等价类测试通过, 这样就可以用较少的测试用例达到尽量多的功能覆盖, 解决了不能穷举测试的问题.

等价类的划分有两种情况:

• 一是有效等价类: 满足用户需求输入集合
• 二是无效等价类: 不满足用户输入集合

等价类思想设计测试用例步骤:
①充分理解需求
②划分有效等价类, 划分无效等价类
③从有效等价类抽取其中一个数据进行设计测试用例; 从无效等价类中抽取其中一个进行测试用例设计
比如注册页面用户名限定长度 6~15 位, 那么 6 位以上, 15 及以下(包含 6 和 15 )的都为有效等价类, 其余的是无效等价类, 通俗点举例我们去超市买水果, 葡萄, 草莓, 西瓜这些就是有效等价类, 而白菜, 土豆, 大米就是无效等价类.

三角形问题: 输入 3 个整数 a, b, c 分别作为三角形的 3 条边, 通过程序判断 3 条边构成三角形的类型为等边三角形, 等腰三角形, 一般三角形或者不构成三角形.

3. 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法, 通常边界值分析法是作为对等价类划分法的补充, 这种情况下, 其测试用例来自等价类的边界

其主要的测试点是对 “输入” 或 “输出” 的 “边界” 值进行测试

这里有几个边界值的概念:

1. 上点: 边界上的点 (不管区间的开闭)
2. 内点: 边界内的点
3. 离点: 离上点最近的点 (当上点为闭区间的点时, 离点在该点的外侧, 当上点为开区间的点, 离点在该点的内侧)

边界值设计测试用例方法:
①充分理解需求
②找边界点
③针对边界点设计测试用例

还是以用户名限定长度 6~15 位为例:

4. 判定表分析法 (因果分析法)

判定表法是因果图法的简化, 只是省略了因果图法中的画图过程, 是黑盒测试中常用的一个方法, 它主要用于测试有多种输入, 并且结果会依赖于输入的情况而有所不同的场景.

判定表中存在以下 4 种关系:

• 与: 所有的条件必须满足, 如果一个条件不满足, 此时结果为假
• 或: 满足其中一个条件结果就为真, 如果条件全部为假, 结果就为假
• 恒等: 条件为真, 结果一定为真
• 非: 条件为假, 结果才为真

判定表分析法设计测试用例的步骤：
①分析所有可能的输入和可能的输出
②找出输入与输出之间的对应关系
③设计判定表
④把判定表对应到每一个测试用例

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

• 第一步

输入: 订单已提交, 订单金额大于300, 有红包
输出: 优惠, 不优惠

• 第二步

1. 订单已提交, 金额大于300, 有红包, 优惠
2. 订单已提交, 金额大于300, 没有红包, 优惠
3. 订单已提交, 金额小于300, 有红包, 优惠
4. 订单已提交, 金额小于300, 没有红包, 不优惠
5. 订单不提交, 金额大于300, 有红包, 不优惠
6. 订单不提交, 金额大于300, 没有红包, 不优惠
7. 订单不是交, 金额小于300, 有红包, 不优惠
8. 订单不提交, 金额小于300, 没有红包, 不优惠

• 第三步

• 第四步

案例2:

产品说明书: 有一个处理单价为1元5角的盒装饮料的自动售货机, 若投入1元5角, 按下 “可乐”, “雪碧”, 或 “红茶” 按钮, 相应的饮料就送出来; 若投入的是2元硬币, 在送出饮料的同时退还5角硬币.

• 第一步

输入: 输入1.5元硬币, 输入2元硬币, 按"可乐", 按"雪碧", 按"红茶"
输出: 可乐, 雪碧, 红茶, 输出5角硬币

• 第二步

1. 输入1.5元硬币, 按 “可乐”, 输出 “可乐”
2. 输入1.5元硬币, 按 “雪碧”, 输出 “雪碧”
3. 输入1.5元硬币, 按 “红茶”, 输出 “红茶”
4. 输入2元硬币, 按 “可乐”, 输出 “可乐”, 输出5角硬币
5. 输入2元硬币, 按 “雪碧”, 输出 “雪碧”, 输出5角硬币
6. 输入2元硬币, 按 “红茶”, 输出 “红茶”, 输出5角硬币

• 第三步

• 第四步

判断表分析法特别适用于需要考虑输入输出之间的组合关系, 不同的组合对应的输出结果不一致的情况;

不画因果图的原因: 因果图画判定表显得比较多余, 实际情况下在判定表中根据输入输出就可以得到测试用例了.

5. 正交排列

上面的判定表法存在用例数目比较多的情况, 而正交法的目的就是为了减少用例数目, 用尽量少的用例覆盖输入的两两组合; 正交排列是一种系统的, 有序的排列方式, 用于软件测试用例设计中, 可以保证测试用例的互相独立,减少重复测试, 提高测试效率.

正交法中必须要知道的就是正交表了, 正交表是一种用表格表示的正交数组, 用于测试用例的设计与管理; 它采用行列交叉的方式, 将被测系统的多个因素以及每个因素的取值组合成表格, 这样我们就可以在这个表格里系统地选择测试值, 组合成测试用例.

正交表由以下要素构成:

1. 因素: 影响被测系统的输入变量
2. 各因素的取值 (水平): 每个因素可取的值或值范围
3. 行与列的表头: 行表头表示被固定的值,列表头表示变量值
4. 单元格: 每个单元格代表一个测试值的组合,可映射为一条测试用例

正交表的两条性质:

1. 每一列中各数字出现的次数都一样多
2. 任何两列中的各有序数对出现的次数都一样多

通过正交表设计测试用例的步骤:

①充分理解需求

②确定因素, 确定水平

③画正交表

④补充正交表

⑥将正交表转换成测试用例

这里以注册需求为例:

• 第一步, 确定因素和确定水平

因素: 姓名, 邮箱, 密码, 确认密码, 验证码必须全部输入, 才能进行注册
水平: 填写 / 不填写

• 第二步, 画正交表

这里需要借助一个工具来实现正交表

下载 allpairs: 可以直接去官网下载 https://www.satisfice.com/download/allpairs#

然后在 Excel 中填写因素和水平:

填写完成后在 allpairs 安装目录下新建一个 txt 文本文件：demo20230517.txt, 然后把 Excel 中数据复制进去并保存;

保存后打开 cmd 切换到 allpairs 所在的目录, 输入 allpairs.exe demo20230517.txt > 20230517result.txt

此时, 正交表就出现在 20230517result.txt 中了

打开看到红色框住的这些内容就是我们所需要的正交表了

这个正交表中~填写的意思是此处选项选填写或者不填写都行, 不影响测试结果.

使用 allpairs 生成的内容, 不一定完整; 还需要新增一些其他的测试用例; 比如这里还需要补充所有输入都不填写的情况.

• 第三步, 将正交表转换成测试用例

6. 场景设计法

主要分为基本事件流和多个备用事件流.

基本事件流: 对于一个场景的最基本的事件流, 即软件功能按照正确的事件流, 中间无任何差错, 从开始直接执行到结束的一条正确流程.

备用事件流: 对于一个业务可能发生异常情况的场景进行测试, 软件功能在执行过程中, 除了基本流之外可能遇到的各种情况, 是包含可能存在问题的各支流.

场景测试法设计测试用例的步骤:

①充分理解需求

②确定主事件流

③确定次事件流

④每一个事件流就是一个测试用例

7. 用例场景示例

用户登录到网站后, 进行书籍的选择, 当选好自己心仪的书籍后进行订购, 这时把所需图书放进购物车, 等进行结帐的时候, 用户需要登录自己注册的帐号, 登录成功后, 进行付款交易, 交易成功后, 生成订购单, 整个购物过程结束.

基本流：登录在线网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 付款 -> 生成订单

备选流１: 用户不存在 -> 注册用户

备选流２: 密码不正确

备选流３: 账户余额不足 -> 充值

备选流 4 : 账户无金额 -> 充值

可以确定出已下场景:

场景 1 (成功购物): 基本流

场景 2 (账户不存在): 基本流 + 备选流１

场景 3 (账户密码错误): 基本流 + 备选流２

场景 4 (账户余额不足): 基本流 + 备选流 3

场景 5 (账户无金额): 流 + 备选流 4

设计出如下测试用例:

1. 成功购物, 登录网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 付款 -> 生成订单
2. 账户不存在, 登录网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 账号不存在, 注册用户 -> 登录账号 -> 付款 -> 生成订单
3. 账户密码错误, 登录网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 密码错误, 重新输入登录 -> 付款 -> 生成订单
4. 账户余额不足, 登录网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 付款 -> 余额不足, 充值 -> 付款 -> 生成订单
5. 账户无金额, 登录网站 -> 选择书籍, 放入购物车 -> 登录账号 -> 付款 -> 账号无金额, 充值 -> 付款 -> 生成订单

8. 错误猜测法

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

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

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

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

错误猜测法的基本步骤:

①分析程序逻辑和实现, 推测出最可能出现的错误类型, 常见的错误类型有: 变量未初始化, 数组下标越界, 参数传递错误, 逻辑运算错误等

②根据猜测出的错误类型和程序逻辑设计测试用例, 这些用例的测试数据应能够激发相应类型的错误

③执行设计的测试用例 ,验证实际输出结果是否与预期一致, 如果存在不一致,则发现了程序错误

④根据测试结果进行错误修复和重测试, 直至所有测试用例的结果均符合预期

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：1150305204【暗号：csdn333】

三. 补充案例

Fiddler实现弱网测试

第一步, 打开Fiddler, Rules -> Performance -> 勾选 Simulate Modem Speeds, 勾选之后访问网站会发现网络慢了很多.

第二步, 设置弱网参数, 菜单 Rules -> Cutomize Rules

让我们来分析一下这几行代码:

if (m_SimulateModem) {
    // Delay sends by 300ms per KB uploaded.
    oSession["request-trickle-delay"] = "300"; 
    // Delay receives by 150ms per KB downloaded.
    oSession["response-trickle-delay"] = "150"; 
}

• 首先来判断 m_SimulateModem 是否为 true (是否开启), 也就是是否设置了弱网模式.
• oSession[“request-trickle-delay”] = "300";

Delay sends by 300ms per KB uploaded: 上传1KB内容需要 300ms, 转化一下上传速度: 1Kb/0.3s = 3.3KB/s, 也就是说网络上行速度只有 3.3KB.

• oSession["response-trickle-delay"] = "150";

Delay receives by 150ms per KB downloaded: 下载1KB内容需要 150ms, 转化后的下载速度: 1KB/0.15s = 6.6KB/s, 也就是说网络下载速度只有6.6KB。

• 如果你想设置下载的速度为50KB/s, 你则需要设置 Delay 时间为 20ms.
• 也可以限制上传的速度, 调整 oSession["response-trickle-delay"] 的值即可.

第三步, 验证效果, 同样的接口, 开启弱网前后分别运行一次, 查看统计数据.

第四步, 恢复设置, 完成测试之后, 需要再次执行: 打开Fiddler, Rules -> Performance -> 取消勾选 Simulate Modem Speeds, 关闭弱网模拟.

水杯测试用例

微信朋友圈测试用例

淘宝购物车测试用例

可视化压缩工具测试用例