判定表测试用例方法——实例

测试用例设计方法——判定表法

判定表法表示的是有多个输入,和多个输出,而且输入与输入之间有相互的组合关系、输入和输出之间有相互的制约和依赖关系, 判定表由四个组成部分

判定表基本概念
 条件桩:输入条件, 列出了系统的所有输入,列出的输入次序无关紧要
 动作桩:结果, 列出了系统可能采取的操作,这些操作的排列顺序没有约束
 条件项:输入条件取值的全部组合, 列出针对它左列输入的取值,在所有可能情况下的真假值
 动作项:条件项对应的所有的结果, 列出在输入项的各种取值情况下应该采取的动作
 规则:一组条件与动作的组合,一条规则对应一条测试用例
“动作项和条件项一起,指出了在条件项的各种取值情况下应该采取的动作,在判定表中贯穿条件项和动作项的一列就是一条规则,可以针对每个合法输入组合的规则设计用例进行测试”
2.实例:
 功能:若用户欠费或关机,则不允许机主被叫

3.判定表法设计测试用例的步骤:
 定义条件桩与动作桩——设计优化判定表(全组合)——填写动作项——简化判定表(结果相同的列,如果只有一个条件不同,可以将这两列合并成一列)——抽取用例(每个规则对应一条用例)
4.案例分析
 案例:注册功能,验证用户名需求:第一项要求输入手机号或邮箱作为账户名,第二项要求正确输入验证码,两项都验证成功后填写账户信息;但如果第一项校验不成功,则报错L(输入手机号或邮箱格式错误);如果是第二项验证不成功,则报错M(验证码输入错误)。
 全组合:

简化判定表:
 第一项输入手机号,则第一项不可能输入邮箱,因此1,2情况不存在;3,5情况结果相同,但是有两个条件不同,因此不能合并。

 步骤总结:
  1.分析需求,确定条件桩和动作桩
   2.全组合条件,得到条件项;
   3.根据条件项,依次填写动作项;
  4.简化判定表;
  5.输出测试用例(一个规则对应一条测试用例)。

练习案例:

有一个饮料自动售货机(处理单价为5角钱硬币)的控制处理软件,它的软件规格说明有
1.若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。
2.不能同时投两个硬币,不能一次同时购买2瓶及以上饮品。
3.如果出现错误,给出相应的提示信息。

根据上诉需求,使用判定表法编写测试用例的步骤如下:
1.分别找出所有的原因和结果,并找出原因与结果之间的所有可能的组合关系,画出判定表。

 

根据判定表中的信息,编写测试用例。
————————————————
版权声明:本文为优快云博主「rm group」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/weixin_44752664/article/details/124045495

### 软件测试中的判定表法 在软件测试领域,判定表法是一种系统化的方法,用于设计和执行测试用例,以验证系统在不同条件组合下的预期行为。这种方法特别适合处理具有多个输入条件以及这些条件间存在复杂逻辑关系的情形。 #### 条件识别与决策规则建立 当应用判定表法时,首要任务是识别所有可能影响程序行为的输入条件,并将其列于表格左侧;接着定义每种条件下系统的期望响应作为动作列表置于右侧。对于每一个独特的条件集合作出相应的反应形成一条条目或称为“规则”,它们贯穿整个表格连接起特定条件集合同其对应的行动方案[^1]。 ```plaintext | 条件C1 | 条件C2 | ... | 动作A1 | |--------|--------|-----|---------| | T | F | ... | 执行X | | F | T | ... | 不执行Y | ... ``` 此结构有助于清晰展示各种情况及其对应的结果,便于理解和维护。 ### 等价类划分方法详解 等价类划分则是另一种重要的黑盒测试技术,它基于这样的假设:如果一个给定范围内的任意两个值都能使被测对象表现出相同的行为,则可以认为这两个值属于同一个类别——即所谓的有效等价区间。同样地,在无效范围内也可以找到类似的分组方式。通过这种方式减少不必要的重复劳动并提高效率。 #### 原理说明 该方法的核心在于将输入域分割成若干子区域(有效/无效),从中挑选代表性的样本点来进行实际操作而不是穷尽所有的可能性。具体而言: - **确定等价类的原则**:依据功能规格说明书描述的功能特性来决定哪些部分应该划分为同一类; - **选取典型实例**:从每个已确认的有效或无效区域内随机抽取至少一个成员参与后续流程; 这种策略不仅简化了工作量而且提高了覆盖率因为通常情况下只要覆盖到了各个分类就足以发现大部分潜在缺陷[^2]。 ### 实战演练 考虑如下简单例子用来对比两种方法的应用场景差异: 假设有这样一个需求:“用户登录界面接受用户名长度介于6到8字符之间”。此时可采用以下方式进行测试规划: - 使用**等价类划分**: - 输入`username="abcdef"` (有效) - 输入`username="abcde"` (过短, 无效) - 输入`username="abcdefghi"` (过长, 无效) 上述做法能够有效地检验边界附近的数据表现形式而不必逐一尝试全部选项。 而针对更复杂的业务逻辑如订单状态转换机制则更适合运用**判定表**: | 用户权限 | 商品库存充足? | 支付成功与否 | 订单创建结果 | |--| | VIP会员 | 是 | 成功 | 创建新订单 | | 普通客户 | 否 | 失败 | 提示错误信息 | 这里展示了不同类型用户的购买过程会因多种因素共同作用而导致不同的最终结局,利用判定表能直观表达此类多维度交互的影响效果[^3]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值