3,判定表法(解决多条件依赖问题)
3.1 定义及组成部分
定义:是一种以表格形式表达多条件逻辑判断的工具
组成:
-
条件桩(Condition Stub):列出了测试对象的所有条件。一般情况下,列出的条件的次序不会影响测试对象的动作
-
动作桩(Action Stub):列出了测试对象所有可能执行的操作。一般情况下,这些执行的操作没有先后顺序的约束
-
条件项(Condition Entry):列出针对特定条件的取值,即条件的真假值。
-
动作项(Action Entry):列出在不同条件项的各种取值组合情况下,测试对象应该执行的动作。
规则:
3.2 设计用例步骤
-
列出需求
-
画出判定表
-
列出所有条件桩和动作桩
-
填写条件项,对条件进行全组合
-
根据条件项的组合确定动作项
-
简化、合并相似规则(有相同动作)
-
-
根据规划编写测试用例
3.2 案例
1、明确需求 | ||
---|---|---|
1、如果金额大于500元,又未过期,则发出批准单和提货单 | ||
2、如果金额大于500元,但过期了,则不发出批准单和提货单 | ||
3、如果金额小于等于500元,则不论是否过期都发出批准单和提货单 | ||
4、在过期的情况下,不论金额大小还需要发出通知单 |
2、判定表 | |||||
---|---|---|---|---|---|
大于500 | 是 | 是 | 否 | 否 | |
条件 | 未过期 | 是 | 否 | 是 | 否 |
动作 | 批准单 | √ | × | √ | √ |
退货单 | √ | × | √ | √ | |
通知单 | × | √ | × | √ | |
用例编号 | 用例标题 | 项目/模块 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 |
order_001 | 发批准单和提货单(大于500、未过期) | 订单 | 软件打开 | P1 | 1,输入金额 2, 查看是否过期 |
1、金额:501 2、未过期 |
发: 批准单、提货单 不发:通知单 |
|
order_002 | 发通知单(大于500、已过期) | 订单 | 软件打开 | P1 | 1,输入金额 2, 查看是否过期 |
1、金额:501 2、过期 |
发: 通知单 不发:批准单、提货单 |
|
order_003 | 发批准单和提货单(等于于500、未过期) | 订单 | 软件打开 | P1 | 1,输入金额 2, 查看是否过期 |
1、金额:50o 2、未过期 |
发: 批准单、提货单 不发:通知单 |
|
order_004 | 发批准单和提货单(小于503、过期) | 订单 | 软件打开 | P1 | 1,输入金额 2, 查看是否过期 |
1、金额:400 2、过期 |
发: 批准单、提货单、通知单 |
3.3 使用场景
-
有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有制约(依赖)关系
-
一般适用于条件组合数量4个以下
-
提示:如果项目中多条件组合大于4个相互依赖,可以使用正交表格