-
概述
- 黑盒测试的用例设计
-
背景
- 面试老问
- 为啥, 是不是把我当功能测试来了
- 想了想
- 之前翻来覆去, 只有 边界值 和 等价类
- 我对测试理论, 主要的来源, 就是 软件测试, 和 软件测试的艺术 两本书
- 但下面的好些方法, 书里也没讲, 因果图当时觉得是天书, 根本看不懂也不敢说
- 结果就是, 每次面试官问我, 我只能说 边界值 和 等价类
- 然后面试官 微微一笑, 语重心长的跟我说这些
- 你现在的思路, 还是个开发
- 你大学功课, 肯定没有学好
- 然后我还一脸懵逼
- 这些东西, 看起来还真的比较系统
- 普通人想总结出来, 估计比较难
- 如果是书上讲的, 可我又始终找不到
- 在 csdn 和 51testing 追根溯源, 已经找到了 2005 年
- 想了想, 真心浪费了不少时间, 以后随缘在找吧,
- 其实 博客里, 写的也听清楚的, 我就先看看吧
- 之前翻来覆去, 只有 边界值 和 等价类
- 面试老问
1. 测试分类
-
概述
- 简单分下类
-
分类
- 黑盒
- 静态
- 看需求, 看设计
- 动态
- 执行
- 静态
- 白盒
- 静态
- 代码评审
- 动态
- debug
- 静态
- 黑盒
-
本次目标
- 动态黑盒
2. 动态黑盒测试分类
-
概述
- 简单分类
-
分类
-
通过性测试
- 目的
- 证明产品符合要求
- 目的
-
失败性测试
- 目的
- 证明产品不符合要求
- 目的
-
-
执行
- 顺序
- 通过性测试
- 先证明基本流程没有问题
- 失败性测试
- 再尝试找出一些漏洞
- 通过性测试
- 顺序
2. 动态黑盒用例设计
- 概述
- 简单的用例设计思路
1. 等价类划分
-
概述
- 对输入进行划分, 目的是区别有效和无效输入
-
步骤
- 理解需求
- 需求或者业务
- 理解输入
- 输入的意义
- 理解输入的规则
- 划分等价类
- 根据规则, 将输入划分
- 若干个 有效等价类
- 若干个 无效等价类
- 根据规则, 将输入划分
- 设计用例
- 带入参数, 设计用例
- 理解需求
2. 边界值
-
概述
- 在 有效等价类 和 无效等价类 的边缘试探
-
步骤
- 划分等价类
- 整理用例
- 让用例分布在 有效等价类 和 无效等价类 的边界
-
其他边界
- 循环
- 第一轮和最后一轮
- 集合
- 第一个元素和最后一个元素
- 循环
3. 判定表法
-
概述
- 依靠 判定表, 来辅助设计用例
- 通常是用来处理 限制条件较多 的 单个输入
- 配合之前的等价类与边界值, 设计合适的用例
-
步骤
-
确定等价类与边界值
-
选定 输入
- 选定一个相对复杂的输入
- 有 多组 限制条件
- 选定一个相对复杂的输入
-
整理输入条件
- 列判定表
- 行
- 每一行为一个约束
- 满足为 true
- 不满足为 false
- 每一行为一个约束
- 列
- 每一列为一个等价的结果
- 由各个条件是否生效, 最后得出一个用例
- 每一列为一个等价的结果
- 行
- 列判定表
-
筛选合适可能
- 筛选每列, 构造用例
- 合理, 则构造用例, 作为 通过性测试 用例
- 不合理, 则构造用例, 作为 失败性测试 用例
- 不存在, 不作构造
- 筛选每列, 构造用例
-
4. 正交表法
-
概述
- 乍一看类似于 判定表 法
- 通常用来处理多个 多个输入
-
步骤
- 整理 每个输入的 判定表
- 确定 每个输入 需要考虑的状态
- 正向
- 逆向
- 确定 每个输入 需要考虑的状态
- 组合 多种输入
- 用类似于 笛卡尔积 的方式来组成 多组输入
- 最后根据结果, 划分 通过性测试, 和 失败性测试
- 用类似于 笛卡尔积 的方式来组成 多组输入
- 整理 每个输入的 判定表
-
与 判定表 的区别
- 判定表
- 对象是 单个输入
- 可能会存在 不可能的情况
- 正交表
- 对象是 所有输入
- 通常只考虑可能的情况
- 判定表
5. 流程图法
-
概述
- 根据业务流程, 选择更加接近真实的用例
- 提高测试精度
- 减少测试时间
- 根据业务流程, 选择更加接近真实的用例
-
步骤
- 理解需求
- 理解需求和设计
- 整理流程
- 整理用户经常会触发的流程
- 正常流程
- 异常流程
- 整理好后, 生成流程图
- 整理用户经常会触发的流程
- 设计用例
- 根据流程图, 设计输入
- 理解需求
-
意义
- 关注 设计好的流程
- 更加贴近真实, 可以保证软件的 下限
- 实际的意义
- 感觉更加适合 回归测试
- 之前的设计, 留下的用例会很多很细,
- 最好在 接口层面 执行
- 最好有 自动化
- 帮助测试理解产品, 理解用户
- 感觉更加适合 回归测试
- 关注 设计好的流程
6. 直觉法
- 概述
- 这个就是纯蒙
- 靠工作经验, 觉得哪里可能有问题, 然后就试着去做
- 这个就是纯蒙
ps
-
ref
- 软件测试
- 软件测试的艺术
- 黑盒测试方法用例设计详解
- 这些玩意是从哪看来的
- 我前两本书上都没有啊...
-
其实, 还有个 因果图
-
概述
- 当 输入与输出 过于错综复杂时, 可以借助 因果图 来构造 正交表
-
ref
- 因果图法
- 老实说, 这个老铁讲得很清楚
- 我之前完全不懂, 现在半懂不懂了
- 之前看的, 是 软件测试
- 上面一些列的 图例, 花里胡哨的连线, 把人绕晕了
- 看了这个后, 我知道了这些
- 因果图 首先要划分 输入和结果
- 输入 和 输入之间, 是有关系的
- 这些关系, 需要用 约束 来限制
- 结果之间, 也是如此
- 画图第一步, 摆放输入 和 结果
- 注意 约束关系
- 不要划线
- 这只是个 模板
- 根据 可能的输入, 通过 连线, 来构造结果
- 注意
- 一种场景, 就要用一张图
- 我之前天真的以为一张图上, 要包含所有的可能
- 哈哈哈, 太天真了
- 我之前天真的以为一张图上, 要包含所有的可能
- 一种场景, 就要用一张图
- 注意
- 最后, 将结果 填入到 正交表 里
- 是的, 你没看错
- 正交表
- 这个东西, 只是 正交表 法下面的一个
- 可以理解为 插件 吧
- 是的, 你没看错
- 之前看的, 是 软件测试
- 我之前完全不懂, 现在半懂不懂了
- 老实说, 这个老铁讲得很清楚
- 因果图法
-
为什么不讲
- 我也不懂
- 真的有人用吗?
- 混迹几家中小公司, 没见一个开发, 测试在用
- 大公司如果有人用, 请原谅我的见识浅薄
-
-
后续
- 当然是 白盒用例设计 了