目录
一,判定表法的定义
二,为什么要使用判定表法
三,判定表法的优缺点
1,优点
2,缺点
四,判定表法的四大组成部分
五,判定表的规则与合并标准
规则:
六,判定表法的适用场景
七,判定表法分析案例
案例一:
1,明确需求
2,画判定表
案例二:
1,明确需求
2,画判定表
3,简化判定表,输出用例(一个规则对应一条测试用例)
案例三:支付宝个人账户注册—验证用户名
1,明确需求
2,画判定表
3,简化判定表,输出用例(一个规则对应一条测试用例)
一,判定表法的定义
判定表法又称决策表,判定表法(Decision table)同因果图法一般也是一种表达逻辑判断的工具。
判定表是一种以表格形式分析和表达多逻辑条件下执行不同操作的工具。
它能够将复杂的问题按照各种可能的情况全部列举出来,因此,利用判定表能够设计出完整的测
试用例集合。
二,为什么要使用判定表法
等价类划分法和边界值分析法都是着重考虑单个输入的输入条件
并没有考虑输入条件的各种组合、输入条件与输出条件之间的相互制约关系
三,判定表法的优缺点
1,优点
- 能把所有条件组合充分地表达出来,并且最为严格、最具有逻辑性
- 化繁为简,能够精简、准确的输出测试用例数据
- 条件组合明确,故此也不容易遗漏
2,缺点
- 判定表在用于知识表达中,存在其他方式达不到的作用,例如不能表达重复执行的动作(循环结构体)
- 判定表的建立过程较复杂,表达式繁琐
- 有多个条件时就会有多个翻倍的规则数
四,判定表法的四大组成部分
条件桩(Condition Stub):列出问题的所有条件,列出条件的次序无关紧要
动作桩(Action Stub):列出问题中可能采取的操作,操作的排列顺序没有约束
条件项(Condition Entry):列出条件对应的取值,所有可能情况下的真假值
动作项(Action Entry):列出条件项的各种取值情况下应该采取的动作结果
五,判定表的规则与合并标准
规则:
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件,每个条件的取值有两个(0,1),全组合就有2的n次方种规则
合并标准:
有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系
六,判定表法的适用场景
- 针对不同逻辑条件的组合值,分别执行不同的操作
- 针对于多种输入、输出条件的表达组合以及条件组合
- 重要系统、模块、玩法的使用规则的排列顺序不会也不影响执行哪些操作
- 规格说明以判定表形式给出,或很容易转换成判定表
七,判定表法分析案例
案例一:
1,明确需求
验证”用户欠费或者关机,则不允许主被叫“功能的测试
2,画判定表
条件 | 是否欠费 | 是 | 是 | 否 | 否 |
是否关机 | 是 | 否 | 是 | 否 | |
操作 | 是否允许主被叫 | 否 | 否 | 否 | 是 |
案例二:
1,明确需求
- 如果金额大于500元,又未过期,则发出批准单和提货单
- 如果金额大于500元,但过期了,则不发批准单和提货单
- 如果金额小于等于500元,则不论是否过期都发出批准单和提货单
- 在过期的情况下不论金额大小还需发出通知单
2,画判定表
条件 | 是否大于500 | 是 | 是 | 否 | 否 |
是否过期 | 是 | 否 | 是 | 否 | |
操作 | 批准单 | × | √ | √ | √ |
提货单 | × | × | √ | × | |
通知单 | √ | × | √ | × |
3,简化判定表,输出用例(一个规则对应一条测试用例)
用例编号 | 模块 | 用例标题 | 优先级 | 前提条件 | 操作步骤 | 预期结果 | 实际结果 |
order_01 | 订单 | 发通知单(大于500,过期) | P0 | 打开订单验证程序 |
1,输入金额600; 2,选择已过期; 3,点击验证按钮。 |
发通知单,不发批准单,提货单 | |
order_02 | 订单 | 发批准单,提货单(大于500,未过期) | P0 | 打开订单验证程序 |
1,输入金额600; 2,选择未过期; 3,点击验证按钮。 |
发批准单,提货单,不发通知单 | |
order_03 | 订单 | 发通知单,批准单,提货单(小于等于500,过期) | P0 | 打开订单验证程序 |
1,输入金额400; 2,选择已过期; 3,点击验证按钮。 |
发通知单,批准单,提货单 | |
order_04 | 订单 | 发批准单,提货单(小于500,未过期) | P0 | 打开订单验证程序 |
1,输入金额400; 2,选择未过期; 3,点击验证按钮。 |
发批准单,提货单,不发通知单 |
案例三:支付宝个人账户注册—验证用户名
1,明确需求
- 输入手机号或者电子邮箱作为账户名
- 输入正确验证码
- 两项验证成功,填写账户信息
- 如果一项验证不正确(输入手机号或电子邮箱格式错误),报错L
- 验证码输入错误,报错M
2,画判定表
分析需求,确定条件桩和动作桩;全组合条件,得到条件项;根据条件项填写动作项。
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
条件 | 第一项 | 输入手机号 | √ | √ | √ | √ | × | × | × | × |
输入电子邮箱 | √ | √ | × | × | √ | √ | × | × | ||
第二项 | 输入正确的验证码 | √ | × | √ | × | √ | × | √ | × | |
操作 | 填写账户信息 | True | True | True | ||||||
报错L | True | True | ||||||||
报错M | True | True | True | True |
3,简化判定表,输出用例(一个规则对应一条测试用例)
由上面的判定表可看出,第一条和第二条的情况不存在,再从结果来看,相同结果但是条件不同的情况不可简化,因此得到下面六条用例
用例编号 | 模块 | 用例标题 | 优先级 | 前提条件 | 操作步骤 | 预期结果 | 实际结果 |
ZC_01 | 注册 | 注册成功 | P0 | 稳定的网络环境 |
1,输入手机号; 2,输入正确的验证码; 3,点击验证。 |
提示”验证成功“; 跳转填写账户信息界面。 |
|
ZC_02 | 注册 | 注册失败 | P1 | 稳定的网络环境 |
1,输入手机号; 2,输入错误的验证码。 3,点击验证。 |
提示”验证失败“。 | |
ZC_03 | 注册 | 注册成功 | P0 | 稳定的网络环境 |
1,输入电子邮箱; 2,输入正确的验证码。 3,点击验证。 |
提示”验证成功“; 跳转填写账户信息界面。 |
|
ZC_04 | 注册 | 注册失败 | P1 | 稳定的网络环境 |
1,输入电子邮箱; 2,输入错误 的验证码。 3,点击验证。 |
提示”验证失败“。 | |
ZC_05 | 注册 | 注册失败 | P1 | 稳定的网络环境 |
1,不输入手机号或电子邮箱; 2,输入正确的验证码。 3,点击验证。 |
提示”验证失败“。 | |
ZC_06 | 注册 | 注册失败 | P1 | 稳定的网络环境 |
1,不输入手机号或电子邮箱; 2,输入错误的验证码。 3,点击验证。 |
提示”验证失败“。 |
了解更多🙂测试用例设计方法🙂,可以关注博主或者专栏哦!
常见的测试用例设计方法1—等价类划分,请戳下面链接!
常见测试用例设计方法1—等价类划分_小宝的宝呢的博客-CSDN博客
常见的测试用例设计方法2—边界值划分,请戳下面链接!
常见测试用例设计方法2—边界值划分_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法3-判定表法,请戳下面链接!
常用测试用例设计方法3-判定表法_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法4-场景法,请戳下面链接!
常用测试用例设计方法4-场景法_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法5-错误推算法,请戳下面链接!
常用测试用例设计方法5-错误推算法_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法6-状态迁移法,请戳下面链接!
常用测试用例设计方法6-状态迁移法_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法7-因果图法,请戳下面链接!
常见的测试用例设计方法7—因果图法_小宝的宝呢的博客-CSDN博客
常用测试用例设计方法8-正交试验法,请戳下面链接!
https://blog.csdn.net/weixin_53436351/article/details/123747925