目录
目标
- 能对多条件依赖关系进⾏设计测试点
- 能对于项⽬业务进⾏设计测试点
- 了解冒烟测试和错误推荐法
一、解决多条件有依赖关系测试(判定表)
1.1概念
判定表
定义:是一种以表格形式表达多条件逻辑判断的工具
● 组成:
▷ 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
▷ 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
▷ 条件项:列出条件对应的取值,所有可能情况下的真假值。
▷ 动作项:列出条件项的、各种取值情况下应该采取的动作结果。
条件 | 是否欠费 | 是 | 是 | 否 | 否 |
是否关机 | 是 | 否 | 是 | 否 | |
操作 | 是否允许被主叫 | 否 | 否 | 否 | 是 |
● 规则:
▷ 判定表中贯穿条件项和动作项的一列就是一条规则
▷ 假设有 n 个条件,每个条件的取值有两个 (0,1),全组合有 2 的 n 次方种规则
1.2步骤
- 列出条件桩和动作桩
- 填写条件项,对条件进⾏全组合
- 根据条件项的组合确定动作项
- 简化、合并相似规则(有相同的动作)
③根据规则编写测试⽤例
1.3案例
需求
规则:
- 如果金额大于 500 元,又未过期,则发出批准单和提货单;
- 如果金额大于 500 元,但过期了,则不发批准单与提货单;
- 如果金额小于等于 500 元,则不论是否过期都发出批准单和提货单;
- 在过期的情况下不论金额大小还需要发出通知单。
判定表
是否大于 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 练习(文件修改)
需求
- 输入的第一列字符必须是 A 或 B
- 第二列字符必须是一个数字
- 如果第一列字符不正确,则给出信息 L
- 如果第二列字符不正确,则给出信息 M
- 如果两列字符输入正确,则修改文件成功
判定表
第一列是 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 个条件以下)
提示
- 多条件之间有依赖关系,使用判定表来进行测试覆盖。
- 判定表一般适合 4 个以内条件依赖关系。
- 如果条件超过 4 个,就不适合覆盖所有条件,应采用(正交法)来解决。
二、业务测试覆盖(场景法)
重点:
- 覆盖业务测试,需要使用场景法
- 先测试业务,再测试单功能、单模块、单页面
说明:
- 场景法也可以叫流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例。
意义:
- 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用
- 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试
2.1流程图
我们的业务用例是根据流程图来梳理的
练习流程图的工具:
1、线上⼯具(选一个自己喜欢的就好)
- 流程图.drawio - draw.io
- ProcessOn思维导图流程图-在线画思维导图流程图_在线作图实时协作
- Lucidchart | Diagramming Powered By Intelligence
- 迅捷画图-专业的在线作图网站,在线画思维导图、流程图
- Communicate Complexity With Intuitive Diagramming | Gliffy by Perforce
2.2案例(ATM)
1、开始 -> 插入银行卡 -> 验证银行卡失败 -> 结束
2、开始 -> 插入银行卡 -> 验证银行卡成功 -> 输入错误 3 次 -> 结束
3、开始 -> 插入银行卡 -> 验证银行卡成功 -> 密码正确 -> 选择取款 -> 账户余额不足 -> 结束
......
用例编号 | 用例标题 | 项目 / 模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
---|---|---|---|---|---|---|---|
ATM_001 | 取款失败(非银行卡) | ATM | P1 | 打开程序 | 1、插入银行卡 2、点击验证 | 银行卡:美容会员卡 | 取款失败,退卡。 |
ATM_002 | 取款失败(密码错误达 3 次) | ATM | P1 | 打开程序 | 1、插入银行卡 2、输入密码 | 卡:银行卡 密码:错误密码 | 取款失败,吞卡。 |
ATM_003 | 取款失败(账户余额不足) | ATM | P1 | 1、打开程序 2、银行卡余额为 0 | 1、插入银行卡 2、输入密码 3、选择取款 4、输入取款金额 | 卡:银行卡 密码:正确密码 取款金额:100 | 取款失败,提示余额不足,退卡。 |
ATM_004 | 取款失败(取款金额错误) | ATM | P1 | 1、打开程序 2、银行卡余额为 100000000 | 1、插入银行卡 2、输入密码 3、选择取款 4、输入取款金额 | 卡:银行卡 密码:正确密码 取款金额:150 | 取款失败,提示:错误,取款金额必须为 100 的整数倍,单次取款最大限制 5000。 |
ATM_005 | 取款失败(ATM 余额不足) | ATM | P1 | 1、打开程序 2、银行卡余额为 100000000 3、ATM 机余额为 0 | 1、插入银行卡 2、输入密码 3、选择取款 4、输入取款金额 | 卡:银行卡 密码:正确密码 取款金额:100 | 取款失败,提示:抱歉,故障。 |
ATM_006 | 取款成功 | ATM | P0 | 1、打开程序 2、银行卡余额为 100000000 3、ATM 机余额 300000 | 1、插入银行卡 2、输入密码 3、选择取款 4、输入取款金额 | 卡:银行卡 密码:正确密码 取款金额:200 | 取款成功,打印凭证,减少卡余额。 |
三、扩展
3.1冒烟测试
定义
源于硬件领域(给硬件加电,观察基本功能是否正常),在软件测试中,指对软件版本的核心功能进行快速验证,确保基本功能可用,为后续测试奠定基础。
目的
- 快速判断软件版本是否存在严重缺陷或阻塞性问题,避免在不稳定版本上浪费后续测试资源。
- 确认软件 “可测”,若核心功能不工作,版本需重新构建或开发修复。
特点
- 快速轻量:用例少而精,聚焦核心流程,而非全面测试。
- 侧重主路径:关注主要功能流程是否畅通,不深入细节(如边界值、兼容性等)。
应用场景
- 每次新版本提交测试时,作为首轮测试。
- 敏捷开发中,每日新构建版本需先通过冒烟测试,确保持续集成的稳定性。
实施步骤
- 确定冒烟用例:挑选软件最核心、影响面广的功能(如电商 APP 的登录、商品浏览、购物车添加、结算)。
- 执行测试:按用例快速验证,检查是否出现崩溃、功能无响应、关键数据丢失等严重问题。
- 结果判定:
- 若通过,进入详细测试阶段;
- 若不通过,记录缺陷并退回开发团队修复。
示例
以某外卖 APP 为例,冒烟测试用例可能包括:
- 打开 APP,能否正常登录(账号密码正确时)。
- 进入首页,能否搜索餐厅、查看菜品。
- 选择菜品加入购物车,能否成功提交订单。
若登录功能崩溃或无法提交订单,冒烟测试不通过,版本需立即返工。
冒烟测试是软件质量的 “第一道防线”,以低成本快速过滤明显缺陷,保障测试流程的有效性和效率。
3.2错误推荐法
错误推荐法是一种软件测试方法,其核心是凭借测试人员的经验、专业知识及对类似项目的了解,主动推测软件中易出现错误的区域或功能点,进而针对性地设计测试用例,挖掘潜在缺陷。
特点
- 主观性与经验依赖:高度依赖测试人员的经验和直觉,不同经验的人员应用效果有差异。
- 快速灵活:无需详尽的规格说明,可快速开展,补充常规测试方法。
- 针对性强:聚焦历史缺陷多、逻辑复杂或变更频繁的模块,能发现常规方法易忽略的问题。
应用场景
- 时间紧迫时:快速对核心功能或高风险区域进行测试补充。
- 复杂模块:如算法复杂的计算模块、交互频繁的界面模块。
- 历史缺陷模块:曾频繁出现问题的模块,借鉴历史经验重点测试。
实施步骤
- 回顾历史缺陷:分析类似项目或模块的历史缺陷数据,总结常见错误类型(如输入验证不当、边界条件处理错误)。
- 分析当前软件:结合当前软件的功能、架构、技术特点,推测易出错点(如全新的用户认证模块,推测密码强度校验、登录超时处理可能有问题)。
- 设计测试用例:针对推测的错误点,设计用例(如密码输入框输入超长字符、特殊符号、空密码等,验证系统处理是否正确)。
示例
以某电商 APP 的支付模块为例,根据经验,支付金额计算、支付渠道切换易出错。用错误推荐法设计用例:
- 输入非整数金额(如 99.99 元),检查支付计算是否正确。
- 频繁切换支付渠道(如支付宝、微信、银行卡),观察是否出现卡顿、数据错乱或支付失败。
错误推荐法是对常规测试方法(如等价类划分、边界值分析)的有效补充,能提升测试效率,尤其在经验丰富的测试团队中,可显著提高缺陷发现率,优化软件质量。