目录:
- 测试用例价值与体系
- 测试用例概念
- 测试用例价值
- 测试用例学习路线
- 黑盒测试方法论-等价类
- 等价类划分法:
- 等价类分类
- 等价类划分原则
- 等价类设计步骤
- 黑盒测试方法论-边界值
- 黑盒测试方法论-因果图
- 因果图定义
- 因果图适用场景
- 因果图中的基本符号
- 因果图中的约束条件
- 因果图法基本步骤
- 黑盒测试方法论-判定表
- 判定表法
- 判定表的组成
- 判定表设计步骤
- 举例:
- 黑盒测试方法论-场景法
- 场景法概述:
- 场景法用例设计步骤
- 画流程图
- 测试用例基础概念
- 测试用例示例
- 测试用例的组成
- 测试用例的优先级(测试用例根据重要性分成一定的等级.)
- 测试用例设计工具
- 测试用例设计与评审
- 设计方法的选择
- 测试用例编写步骤
- 测试用例评审
- 面试测试测试用例设计
- 面试形式
- 思路:
- 面试思路:
- 搜索功能测试用例设计
1.测试用例价值与体系
- 测试用例概念
- 测试用例价值
- 测试用例学习路线
测试用例概念
- 测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期的结果的文档通过大量的测试用例来检验软件的运行效果
- 它是指导测试工作进行的依据
测试用例价值
- 指导测试的实施
- 规划测试数据的准备
- 编写测试脚本的”设计规格说明书”
- 评估测试结果的度量基准
- 分析缺陷的标准
测试用例学习路线
2.黑盒测试方法论-等价类
等价类划分法:
- 等价类划分是一种重要的、常用的黑盒测试方法
- 不需要考虑程序的内部结构,只需要考虑程序的输入规格即可
- 它将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性
- 用户所有可能输入的数据,划分成了若干个子集,然后从每一个子集当中选取少数具有代表性的数据作为测试用例
- 在有限的测试资源的情况下,用少量有代表性的数据得到比较好的测试效果
等价类分类
- 有效等价类:指符合《需求文档》,输入合理的数据集合
- 无效等价类:指不符合《需求文档》,输入不合理的数据集合
等价类划分原则
1.规定输入的取值范围或个数时,划分一个有效和两个无效:
- 假设有一个输入要求用户输入年龄,取值范围为18到65岁,那么可以将等价类划分为一个有效等价类(如25岁)和两个无效等价类(如10岁和80岁),因为这两个取值不在规定范围内。
⒉规定了输入的集合或规则必须要遵循的条件,则划分一个有效和一个无效
- 假设有一个输入要求用户输入电子邮件地址,规定必须以@example.com结尾,那么可以将等价类划分为一个有效等价类(如example@example.com)和一个无效等价类(如example@gmail.com),因为后者不符合规定的结尾。
3.输入条件是一个布尔值,则划分为一个有效和一个无效
- 假设有一个输入要求用户选择是否愿意接收促销邮件,那么可以将等价类划分为一个有效等价类(选择愿意)和一个无效等价类(选择不愿意)。
4.输入条件时一组数据,并且每一个输入的值做不同的处理,则划分若干个有效和一个无效
- 假设有一个输入要求用户输入手机号码,根据手机号码的地区不同,处理方式也不同,那么可以将等价类划分为若干个有效等价类(如中国地区手机号码、美国地区手机号码等)和一个无效等价类(如一个无效的号码)。
5.输入条件规定了必须要遵循的某些规则下,则划分为一个有效和若干个无效
- 假设有一个输入要求用户设置密码,规定密码必须包含至少一个大写字母和一个特殊字符,那么可以将等价类划分为一个有效等价类(符合要求的密码,如Password#123)和若干个无效等价类(不符合要求的密码,如password123、PASSWORD123等)。
6.不是所有的等价类都有无效等价类
- 假设有一个输入要求用户选择性别,那么可以将等价类划分为一个有效等价类(如选择男性)但没有无效等价类,因为选项只有男性和女性两种情况,没有其他无效的选择。
等价类设计步骤
- 先划分等价类:找出所有可能的分类
- 确定有效等价类:需求中的条件
- 确定无效等价类:与条件相反的情况,再找到特殊情况
- 确立等价类后,划分出等价类表(熟练的话可以省略)
- 从各个分类中挑选测试用例数据
- 生成可以执行的测试用例
举例:计算 1—100 的整数之和(包括 1 和 100)
1.先划分等价类:找出所有可能的分类
- [1,100]整数
- <1整数
- >100整数
- 小数
- 字母
- 汉字
- 特殊字符
- 为空
2. 确定有效等价类:需求中的条件
- [1,100]整数
3.确定无效等价类:与条件相反的情况,再找到特殊情况
- <1整数
- >100整数
- 小数
- 字母
- 汉字
- 特殊字符
- 为空
4.确立等价类后,划分出等价类表(熟练的话可以省略)
5. 从各个分类中挑选测试用例数据
6.生成可以执行的测试用例
3.黑盒测试方法论-边界值
- 通常使用边界值法和等价类配合使用
边界值分析法
- 大量的软件测试实践表明,故障往往出现在定义域或值域的边界上,而不是在其内部
- 为检测边界附近的处理专门设计测试用例,通常都会取得很好的测试效果
- 边界值分析法是一种很实用的黑盒测试用例方法,它具有很强的发现故障的能力
- 边界值分析法是作为对等价类划分法的补充,测试用例来自等价类的边界
边界值确定
- 上点:边界上的点
- 离点:离上点最近的点
- 内点:在输入域内任意一个点
- 选取正好等于、刚好大于或刚好小于边界值作为测试数据
边界点划分规则
- 如果规定了输入域的取值范围
- 选取刚好在范围边界的点
- 刚好超过边界的点
- 如果规定了输入值的个数
- 最大个数
- 最小个数
- 比最小个数少 1
- 比最大个数多 1
- 如果规定了输入是一个有序的集合
- 选取集合的第一个元素
- 选取集合的最后一个元素
使用边界值法对上边的那个例子的测试用例做补充:
4.黑盒测试方法论-因果图
因果图定义
- 因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法
- 它适合于检查程序输入条件的各种组合情况
- “因” —— 输入条件
- “果” —— 输出结果
因果图适用场景
- 描述多种条件的组合
- 产生多个动作
因果图中的基本符号
- 恒等:若原因出现,则结果出现;若原因不出现,则结果也不出现
- 非:若原因出现,则结果不出现;若原因不出现,则结果出现
- 或:有多个原因。若几个原因中有一个出现,则结果出现;若几个原因都不出现,则结果不出现
- 与:有多个原因。若几个原因都出现,则结果才出现;若其中一个原因不出现,则结果不出现
因果图中的约束条件
- 互斥 E:a、b、c 只能有一个成立,但是可以都不成立
- 包含 I:a、b、c 中至少有一个成立
- 唯一 O:a、b、c 有且仅有一个成立
- 要求 R:如果 a 成立,则要求 b 必须也成立,其他的不约束
- 屏蔽 M:如果 a 成立的时候,强制 b 不成立,其他的不约束
因果图法基本步骤
- 找出所有的输入条件(因)
- 找出所有的输出条件(果)
- 明确所有输入条件之间的制约关系以及组合关系
- 明确所有输出条件之间的制约关系以及组合关系
- 找出什么样的输入条件组合会产生哪种输出结果
- 把因果图转换成判定表
- 为判定表中的每一列表示的情况设计测试用例
举例:(交通一卡通自动充值软件系统)
需求解释
- 系统只接收 50 或 100 元纸币,一次只能使用一张纸币,一次充值金额只能为 50 元或 100 元
- 在请投币的后面按 50 元按钮,代表投入 50 元纸币;按 100 元按钮,代表投入 100 元纸币
- 若按 50 元按钮,并选择充值 50 元,完成充值,提示充值成功
- 若按 50 元按钮,并选择充值 100 元,提示输入金额不足,退回 50 元
- 若按 100 元按钮,并选择充值 50 元,完成充值,提示充值成功,退回 50 元
- 若按 100 元按钮,并选择充值 100 元,完成充值,提示充值成功
- 若按投币按钮后在规定时间内不选择充值按钮,提示错误,退回投入纸币
- 若选择充值按钮后不按投币按钮,提示错误
找到所有输入条件编号
- 选择投币 50 元
- 选择投币 100 元
- 选择充值 50 元
- 选择充值 100 元
找到所有输出条件编号
- 完成充值提示充值成功
- 退回纸币
- 提示错误
找出什么样的输入条件组合会产生哪种输出结果,把因果图转换成判定表
- 条件 1 单独出现 – 2,3
- 条件 2 单独出现 – 2,3
- 条件 3 单独出现 – 3
- 条件 4 单独出现 – 3
- 条件 1、3组合 – 1
- 条件 1、4 组合 – 2,3
- 条件 2、3 组合 – 1,2
- 条件 2、4 组合 – 1
转化为测试用例
5.黑盒测试方法论-判定表
判定表法
- 因果图只是一种辅助工具,通过分析最终得到判定表,再通过判定表编写测试用例
- 画因果图非常麻烦,影响测试效率,可以直接写判定表,进而编写测试用例
判定表的组成
- 条件桩:问题的所有条件
- 动作桩:问题的所有输出
- 条件项:针对条件桩的取值
- 动作项:条件项的各种取值情况下的输出结果
判定表设计步骤
- 列出所有的条件桩和动作桩
- 确定规则数:条件取值个数^条件数
- 填入条件项
- 填入动作项。得到初始判定表
- 简化判定表
举例:
- 判断三角形
- 输入三个正整数 a、b、c,分别作为三角形的三条边
- 判断三条边是否能构成三角形
- 如果能构成三角形,判断三角形的类型(等边三角形、等腰三角形、一般三角形)
确定条件桩
- C1:a,b,c 构成三角形?a<b+c、b<a+c、 c<a+b
- C2:a = b?
- C3:a = c?
- C4:b = c?
确定动作桩
- A1:非三角形;
- A2:不等边三角形;
- A3:等腰三角形;
- A4:等边三角形;
- A5:不可能;
确定条件项和动作项
设计判定表
简化判定表
设计测试用例
6.黑盒测试方法论 - 场景法
场景法概述:
场景法就是模拟用户操作软件时的场景,主要用于测试系统的业务流程
- 基本流:按照正确的业务流程来实现的一条操作路径
- 备选流:导致程序出现错误的操作流程
场景法用例设计步骤
- 根据需求规格说明,画出功能模块流程图
- 根据流程图,描述出程序的基本流及备选流
- 根据基本流和备选流生成不同的场景,构造场景列表
- 对每一个场景生成相应的测试用例
- 对生成的所有测试用例重新复审,去掉多余的测试用例
- 测试用例确定后,为每一个测试用例确定测试数据值
示例:(对淘宝网购物流程设计测试用例)
画流程图
确定基本流
- 进入淘宝首页
- 浏览商品
- 进入单品页
- 选择商品规格和数量
- 加入购物车
- 前往购物车
- 选择商品
- 结算,进入确认订单页
- 提交订单
- 付款成功
- 等待收货
- 确认收货
确定备选流
- 备选流 1:加入购物车时,不选择商品规格和型号,返回基本流第 4 步
- 备选流 2:加入购物车时,商品库存不足,返回基本流第 4 步
- 备选流 3:加入购物车时,未登录,登录后返回基本流第 3 步
- 备选流 4:加入购物车后,继续选购,返回基本流第 4 步
- 备选流 5:加入购物车,未选择商品,结算,返回基本流第 7 步
- 备选流 6:支付失败,返回基本流第 8 步
- 备选流 7:未选择商品加入购物车,退出购物,结束
构造场景
- 场景 1: 登录后成功购物(基本流)
- 场景 2: 未选择商品规格和型号就添加购物车(基本流 + 备选流 1)
- 场景 3: 选择的商品库存不足(基本流 + 备选流 2)
- 场景 4: 未登录添加购物车(基本流 + 备选流 3)
- 场景 5: 商品添加购物车后继续购物(基本流 + 备选流 4)
- 场景 6: 进入购物车,未选择商品直接结算(基本流 + 备选流 5)
- 场景 7: 支付过程出错(基本流 + 备选流 6)
- 场景 8: 没有添加商品到购物车(基本流 + 备选流 7)
生成测试用例
7.测试用例基础概念
- 测试用例示例
- 测试用例的组成
- 测试用例的优先级
- 测试用例设计工具
测试用例示例
测试用例的组成
- 用例编号模块
- 测试点(测试标题)
- 优先级
- 前提条件
- 测试步骤
- 期望结果(预期结果)
- 实际结果
测试用例的优先级 (测试用例根据重要性分成一定的等级.)
- P0
- P1
- P2
- P3
测试用例设计工具
- 思维导图
- excel
8.测试用例设计与评审
- 设计方法的选择
- 测试用例编写步骤
- 需求分析
- 测试用例编写
- 测试用例的粒度
- 测试用例评审
设计方法的选择
- 任何情况下,都需要采用等价类划分法,将无限测试变成有限测试
- 在规定了数据范围的情况下,必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现,考虑使用场景法
- 如果含有输入条件的组合情况,考虑选用因果图和判定表法
- 采用错误推断法再追加测试用例
测试用例编写步骤
- 划分功能模块
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 隐形需求
示例:
需求分析
- 帐号是手机号
- 手机号仅限制为国内常用的号段
- 密码必须为数字+英文的形式,字段为8-12个字符
- 账号密码都为空时,登录按钮置灰不可点击
- 点击登录按钮,发起登录请求
- 请求成功,跳转到首页
- 点击忘记密码跳转到找回密码页
业务逻辑:
用思维导图,设计测试用例
用思维导图,编写测试用例
测试用例的粒度:
- 测试用例可以写的很简单,也可以写的很复杂
- 最简单的测试用例是测试的纲要,仅仅指出要测试的内容
- 测试用例写的过于简单,则可能失去了测试用例的意义
- 测试用例写得过于复杂或详细,会带来两个问题:效率问题,维护成本问题
测试用例评审
- 测试用例的本身的描述是否清晰,是否存在二义性
- 测试用例内容是否正确,是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
9.面试测试测试用例设计
面试形式
- 自有产品功能测试用例设计
- 常用应用测试用例设计
思路:
- 需求分析
- 界面
- 功能
- 易用性
- 兼容性
- 性能
- 安全性
面试思路:
10.搜索功能测试用例设计
注意,这个是设计测试用例,而非测试用例的编写,测试用例编写耗时间,设计测试用例可以做为编程测试用例的指导思路,个人感觉写的挺lg,我的收获是我为百度的字符搜索功能,语音搜索工能,图片搜索功能写过一堆设计测试用例的思路。这个价值的话,我只能说,我有一定的理解,可供参考。