软件测试3(用例设计方法//判定表与场景法)

目录

目标

一、解决多条件有依赖关系测试(判定表)

1.1概念

1.2步骤

1.3案例

需求

判定表

用例

1.4 练习(文件修改)

需求

判定表

用例

1.5 判定表总结

使用场景

提示

二、业务测试覆盖(场景法)

重点:

说明:

意义:

2.1流程图

2.2案例(ATM)

三、扩展

3.1冒烟测试

定义

目的

特点

应用场景

实施步骤

示例

3.2错误推荐法

特点

应用场景

实施步骤

示例


目标

  • 能对多条件依赖关系进⾏设计测试点
  • 能对于项⽬业务进⾏设计测试点
  • 了解冒烟测试和错误推荐法

一、解决多条件有依赖关系测试(判定表)

1.1概念

判定表

定义:是一种以表格形式表达多条件逻辑判断的工具

● 组成:
▷ 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
▷ 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
▷ 条件项:列出条件对应的取值,所有可能情况下的真假值。
▷ 动作项:列出条件项的、各种取值情况下应该采取的动作结果。

条件

是否欠费

是否关机
操作是否允许被主叫

● 规则:
▷ 判定表中贯穿条件项和动作项的一列就是一条规则
▷ 假设有 n 个条件,每个条件的取值有两个 (0,1),全组合有 2 的 n 次方种规则

1.2步骤

①明确需求
②画出判定表
  • 列出条件桩和动作桩
  • 填写条件项,对条件进⾏全组合
  • 根据条件项的组合确定动作项
  • 简化、合并相似规则(有相同的动作)

③根据规则编写测试⽤例

1.3案例

需求

规则

  1. 如果金额大于 500 元,又未过期,则发出批准单和提货单;
  2. 如果金额大于 500 元,但过期了,则不发批准单与提货单;
  3. 如果金额小于等于 500 元,则不论是否过期都发出批准单和提货单;
  4. 在过期的情况下不论金额大小还需要发出通知单。
判定表
是否大于 500
是否过期
批准单×
提货单×
通知单××
用例
用例编号用例标题项目 / 模块优先级前置条件测试步骤测试数据预期结果
order_001发通知单(大于 500,过期)订单P0打开订单验证程序1. 输入金额
2. 输入是否过期
3. 点击验证按钮
金额:600
是否过期:过期
发通知单,不发批准单、提货单
order_002发批准单、提货单(大于 500,未过期)订单P0打开订单验证程序1. 输入金额
2. 输入是否过期
3. 点击验证按钮
金额:600
是否过期:未过期
发批准单、提货单,不发通知单
order_003发通知单、批准单、提货单(小于等于 500,过期)订单P0打开订单验证程序1. 输入金额
2. 输入是否过期
3. 点击验证按钮
金额:400
是否过期:过期
发通知单、批准单、提货单
order_004发批准单、提货单(小于等于 500,未过期)订单P0打开订单验证程序1. 输入金额
2. 输入是否过期
3. 点击验证按钮
金额:400
是否过期:未过期
发批准单、提货单,不发通知单

1.4 练习(文件修改)

需求
  1. 输入的第一列字符必须是 A 或 B
  2. 第二列字符必须是一个数字
  3. 如果第一列字符不正确,则给出信息 L
  4. 如果第二列字符不正确,则给出信息 M
  5. 如果两列字符输入正确,则修改文件成功
判定表
第一列是 A 或 B
第二列是数字
L
M
文件修改成功
用例
用例编号用例标题项目 / 模块优先级前置条件测试步骤测试数据预期结果
wj_001输出文件修改成功(第一列是 A 或 B,第二列是数字)文件P0打开验证程序1. 输入第一列
2. 输入第二列
3. 点击确定
1. 第一列:A 或 B
2. 第二列:1
输出文件修改成功
wj_002输出 M(第一列是 A 或 B,第二列不是数字)文件P1打开验证程序1. 输入第一列
2. 输入第二列
3. 点击确定
1. 第一列:A 或 B
2. 第二列:a
输出 M
wj_003输出 M、L(第一列不是 A 或 B,第二列不是数字)文件P1打开验证程序1. 输入第一列
2. 输入第二列
3. 点击确定
1. 第一列:C
2. 第二列:a
输出 M、L
wj_004输出 L(第一列不是 A 或 B,第二列是数字)文件P1打开验证程序1. 输入第一列
2. 输入第二列
3. 点击确定
1. 第一列:C
2. 第二列:1
输出 L

1.5 判定表总结

使用场景

  • 有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖 (制约) 关系
  • 判定表一般适用于条件组合数量较少的情况 (比如 4 个条件以下)

提示

  1. 多条件之间有依赖关系,使用判定表来进行测试覆盖。
  2. 判定表一般适合 4 个以内条件依赖关系。
  3. 如果条件超过 4 个,就不适合覆盖所有条件,应采用(正交法)来解决。

二、业务测试覆盖(场景法)

重点:

  • 覆盖业务测试,需要使用场景法
  • 先测试业务,再测试单功能、单模块、单页面

说明:

  • 场景法也可以叫流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例。

意义:

  • 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用
  • 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试

2.1流程图

我们的业务用例是根据流程图来梳理的

练习流程图的工具:

1、线上⼯具(选一个自己喜欢的就好)

2、Windows离线⼯具:visio

2.2案例(ATM)

1、开始 -> 插入银行卡 -> 验证银行卡失败 -> 结束
2、开始 -> 插入银行卡 -> 验证银行卡成功 -> 输入错误 3 次 -> 结束
3、开始 -> 插入银行卡 -> 验证银行卡成功 -> 密码正确 -> 选择取款 -> 账户余额不足 -> 结束

......

用例编号用例标题项目 / 模块优先级前置条件测试步骤测试数据预期结果
ATM_001取款失败(非银行卡)ATMP1打开程序1、插入银行卡
2、点击验证
银行卡:美容会员卡取款失败,退卡。
ATM_002取款失败(密码错误达 3 次)ATMP1打开程序1、插入银行卡
2、输入密码
卡:银行卡
密码:错误密码
取款失败,吞卡。
ATM_003取款失败(账户余额不足)ATMP11、打开程序
2、银行卡余额为 0
1、插入银行卡
2、输入密码
3、选择取款
4、输入取款金额
卡:银行卡
密码:正确密码
取款金额:100
取款失败,提示余额不足,退卡。
ATM_004取款失败(取款金额错误)ATMP11、打开程序
2、银行卡余额为 100000000
1、插入银行卡
2、输入密码
3、选择取款
4、输入取款金额
卡:银行卡
密码:正确密码
取款金额:150
取款失败,提示:错误,取款金额必须为 100 的整数倍,单次取款最大限制 5000。
ATM_005取款失败(ATM 余额不足)ATMP11、打开程序
2、银行卡余额为 100000000
3、ATM 机余额为 0
1、插入银行卡
2、输入密码
3、选择取款
4、输入取款金额
卡:银行卡
密码:正确密码
取款金额:100
取款失败,提示:抱歉,故障。
ATM_006取款成功ATMP01、打开程序
2、银行卡余额为 100000000
3、ATM 机余额 300000
1、插入银行卡
2、输入密码
3、选择取款
4、输入取款金额
卡:银行卡
密码:正确密码
取款金额:200
取款成功,打印凭证,减少卡余额。

三、扩展

3.1冒烟测试

定义

源于硬件领域(给硬件加电,观察基本功能是否正常),在软件测试中,指对软件版本的核心功能进行快速验证,确保基本功能可用,为后续测试奠定基础。

目的

  • 快速判断软件版本是否存在严重缺陷或阻塞性问题,避免在不稳定版本上浪费后续测试资源。
  • 确认软件 “可测”,若核心功能不工作,版本需重新构建或开发修复。

特点

  • 快速轻量:用例少而精,聚焦核心流程,而非全面测试。
  • 侧重主路径:关注主要功能流程是否畅通,不深入细节(如边界值、兼容性等)。

应用场景

  • 每次新版本提交测试时,作为首轮测试。
  • 敏捷开发中,每日新构建版本需先通过冒烟测试,确保持续集成的稳定性。

实施步骤

  1. 确定冒烟用例:挑选软件最核心、影响面广的功能(如电商 APP 的登录、商品浏览、购物车添加、结算)。
  2. 执行测试:按用例快速验证,检查是否出现崩溃、功能无响应、关键数据丢失等严重问题。
  3. 结果判定
    • 若通过,进入详细测试阶段;
    • 若不通过,记录缺陷并退回开发团队修复。

示例

以某外卖 APP 为例,冒烟测试用例可能包括:

  • 打开 APP,能否正常登录(账号密码正确时)。
  • 进入首页,能否搜索餐厅、查看菜品。
  • 选择菜品加入购物车,能否成功提交订单。
    若登录功能崩溃或无法提交订单,冒烟测试不通过,版本需立即返工。

冒烟测试是软件质量的 “第一道防线”,以低成本快速过滤明显缺陷,保障测试流程的有效性和效率。

3.2错误推荐法

错误推荐法是一种软件测试方法,其核心是凭借测试人员的经验、专业知识及对类似项目的了解,主动推测软件中易出现错误的区域或功能点,进而针对性地设计测试用例,挖掘潜在缺陷。

特点

  • 主观性与经验依赖:高度依赖测试人员的经验和直觉,不同经验的人员应用效果有差异。
  • 快速灵活:无需详尽的规格说明,可快速开展,补充常规测试方法。
  • 针对性强:聚焦历史缺陷多、逻辑复杂或变更频繁的模块,能发现常规方法易忽略的问题。

应用场景

  • 时间紧迫时:快速对核心功能或高风险区域进行测试补充。
  • 复杂模块:如算法复杂的计算模块、交互频繁的界面模块。
  • 历史缺陷模块:曾频繁出现问题的模块,借鉴历史经验重点测试。

实施步骤

  1. 回顾历史缺陷:分析类似项目或模块的历史缺陷数据,总结常见错误类型(如输入验证不当、边界条件处理错误)。
  2. 分析当前软件:结合当前软件的功能、架构、技术特点,推测易出错点(如全新的用户认证模块,推测密码强度校验、登录超时处理可能有问题)。
  3. 设计测试用例:针对推测的错误点,设计用例(如密码输入框输入超长字符、特殊符号、空密码等,验证系统处理是否正确)。

示例

以某电商 APP 的支付模块为例,根据经验,支付金额计算、支付渠道切换易出错。用错误推荐法设计用例:

  • 输入非整数金额(如 99.99 元),检查支付计算是否正确。
  • 频繁切换支付渠道(如支付宝、微信、银行卡),观察是否出现卡顿、数据错乱或支付失败。

错误推荐法是对常规测试方法(如等价类划分、边界值分析)的有效补充,能提升测试效率,尤其在经验丰富的测试团队中,可显著提高缺陷发现率,优化软件质量。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值