一、能对穷举场景设计测试点——等价类划分法
-
说明:在所有测试数据中,具有某种共同特征的数据集合进行划分
-
分类
- 有效等价类:满足需求的数据集合
- 无效等价类:不满足需求的数据集合
-
步骤
- 明确需求
- 确定有效和无效等价类
- 提取数据编写测试用例
-
适用场景
-
针对:需要有大量数据测试输入,但是没法穷举测试的地方
- 输入框
- 下拉列表
- 单选复选框
-
典型代表:页面的输入框类测试
-
-
重点
- 有效等价和单个无效等价各取一个即可
- 验证类型
- 正向:一条用例尽可能覆盖多条
反向:每一条都是一个单独用例
-
难点
长度——边界
类型——等价
规则——等价
二、能对限定边界规则设计测试点——边界值分析法
-
边界范围节点
- 选取正好等于、刚好大于、刚好小于边界的只作为测试数据
- 上点:边界上的点(正好等于)
- 离点:距离上点最近的点(刚好大于、刚好小于)
- 内点:范围内的点(区间范围内的数据)
- 选取正好等于、刚好大于、刚好小于边界的只作为测试数据
-
应用步骤
1. 明确需求
2. 确定有效和无效等价类
3. 确定边界范围值
4. 提取数据编写测试用例-
提示:
- 有关范围限制,最多7条测试用例(优化为5条)
- 边界值能解决位数限制问题,但不能解决类型问题(要结合等价类)
-
练习
-
-
案例优化:
- 上点:必选(不考虑区间开闭)
- 内点:必选(建议选择中间范围)
- 离点:开内闭外(考虑开闭区间,开区间选择内部离点,闭区间选择外部离点)
-
适用范围:
- 在等价类的基础上针对边界范围的测试数据输入的地方(重点关注边界)
- 常见词语描述:大小,尺寸,重量,最大,最小,至多,至少等修饰词语
- 典型代表:有边界范围的输入框类测试
-
总结
- 强调:单个输入框,常用的方式 边界+等价类
- 面试题:最常用的用例设计方法有哪些?——等价类、边界值
三、能对多条件依赖关系进行设计测试点——判定表
-
判定表法的引用
- 案例:验证“若用户欠费或关机,则不允许主被叫”的功能测试
- 说明:
- 等价类边界值分析法主要关注单个输入类条件的测试
- 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约的测试
-
判定表定义及组成部分
- 定义:是一种以表格形式表达多条件逻辑判断的工具
- 组成
- 条件桩:列出问题中的所有条件,累出条件的次序无关紧要
- 动作桩:列出问题中可能采取的操作,操作的顺序排序没有约束
- 条件项:列出条件对应的取值,所有可能情况下的真假值
- 动作项:列出条件项的各种取值情况下应该采取的动作结果
规则:
- 判定表中贯穿条件项和动作项的一类就是一条规则
- 假设有n
个条件,每个条件的取值有两个(0,1)
,全组合有2^n
中规则 -
判定表法设计用例步骤
- 明确需求
- 画出判定表
- 列出条件桩和动作桩
- 填写条件项,对条件进行全组合
- 根据条件项的组合确定动作项
- 简化、合并相似规则(有相同的动作)
- 根据规则编写测试用例
-
使用场景
由多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
判定表一般适用于条件组合数量较少的情况(比如4个条件以下) -
案例
-
练习1——订单
- 规则
- 如果金额大于500元,又未过期,则发出批准单和提货单
- 如果金额大于500元,但过期了,则不发批准单和提货单
- 如果金额小于等于500元,则不论是否过期都发出批准单和提货单
- 在过期的情况下,不论金额大小还需要发出通知单
- 规则
-
练习2——文件修改
- 规则
- 输入的第一列字符必须是A,B
- 第二列字符必须是一个数字
- 如果第一列字符不正确,则给出信息L
- 如果第二列字符不正确,则给出信息M
- 如果两列字符输入正确,则修改文件成功
提示
1、多条件之间有依赖关系,使用判定表来进行测试覆盖
2、判定表一般适合4个以内条件依赖关系
3、如果条件超过4个,就不适合覆盖所有条件,应采用(正交法)来解决四、能对于项目业务进行设计测试点——场景
- 重点
- 覆盖业务测试,需要使用流程图法
- 先测试业务,再测试单功能,单模块,单页面
- 流程图:使用标准徒刑和箭头来表达程序或业务的走向
-
流程图对测试人员的作用
- 能够看懂流程图,设计业务用例
- 当需求文档信息不全时,能够根据需求,梳理出流程
- 网页版工具:https:procession.com/
- windows工具:visio
-
流程图练习
- 用户名为admin,密码为123456,输出:登录成功
- 登陆、搜索商品、添加购物车、去结算、支付、如果支付成功,则提示下单成功,否则提示支付失败
- 用户名为admin,密码为123456,输出:登录成功
-
介绍
- 说明:场景法也可以叫做流程图法,是用流程图描述用户单使用场景,然后通过覆盖流程路径来设计测试用例
- 意义
- 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用
- 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试
-
案例
- ATM取款机流程
- ATM取款机流程
-
流程图
-
测试模板
- 规则
五、错误推荐法
- 介绍
- 定义:通过经验推测系统可能出现的问题
- 思想:根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷
- 场景
当项目用例都执行完毕,且BUG修复完成,离上线还有一段时间,在这段时间中可以使用错误推荐法复测主要业务或测试未覆盖的功能