本文是通过学习对测试用例编写方法的个人总结,仅供参考
测试项目的执行文档,其作用是防止测试过程中的漏测,对测试流程制定标准
编写测试用例的时候需考虑软件质量模型(功能性、性能效率、兼容性、易用性、可靠性、信息安全、可维护性、可移植性)
编写格式
- 用例编号:项目+模块+编号
- 用例标题:预期结果+操作步骤
- 模块/项目:所属项目或模块
- 前置条件:执行用例时有哪些前置操作
- 优先级
- 测试步骤
- 测试数据
- 预期结果
以花瓶为例子编写十条测试用例
XMind
Excel
用例编号 | 用例标题 | 模块 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 |
1 | 容量 | 功能 | 花瓶为空,有测量容量的工具 | P1 | 将水倒入花瓶至注水线或装满,后将花瓶内的水倒入测量工具内测量 | ||
2 | 抗冲击能力 | 功能 | 花瓶完整且测试前无磕碰 | P1 | 对花瓶进行各种击打/碰撞/摔落,测试花瓶在受到多大的冲击下能够保持完整 | ||
3 | 耐热性 | 功能 | 有测温和调温工具 | P1 | 使用调温工具,将花瓶放置在不同的温度下,观察花瓶的外观变化 | ||
4 | 耐腐蚀性 | 功能 | 花瓶无破损,配置不同种类的溶液 | P1 | 将花瓶浸泡在不同种类的溶液中(纯净水/自来水/盐水等),观察花瓶的外观变化 | ||
5 | 耐用性 | 功能 | 花瓶无使用记录 | P1 | 长时间使用花瓶,评估其外观和功能变化 | ||
6 | 稳定性 | 功能 | 花瓶无磕碰破损记录 | P1 | 将花瓶放在水平面上,轻触花瓶,观察是否有摇晃 | ||
7 | 完整性 | 外观 | 花瓶无磕碰破损记录 | P1 | 观察花瓶外观是否完整,是否有破损 | ||
8 | 美观性 | 外观 | 花瓶无磕碰破损记录 | P1 | 评估花瓶颜色/外观等是否吸引人 | ||
9 | 易用性 | 用户体验 | … | … | … | ||
10 | 安全性 | 用户体验 | … | … | … |
设计用例
用例的设计根据不同的场景有不同的设计方法
测试用例方法—-等价类划分法(黑盒)_以(一)某城市电话号码功能测试为例子,描述等价类划分原理以及测试用例设计的原-CSDN博客
- 等价类划分法解决穷举场景
- 边界值分析法解决边界限制场景
- 判定表法解决多条件依赖场景
- 场景法解决业务场景
等价类划分:
将程序的输入域,按照某种共同特征,划分为不相干的几个子集,称为等价类
其中,满足需求的称为有效等价类,不满足需求的称为无效等价类
划分原则
例1:
验证6-8位自然数
等价类:有效:8位自然数;无效:4位自然数、8位非自然数
编写用例:12345678、1234、1234567a
用例编号 | 用例标题 | 项目/模块 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 |
1 | 合法(8位自然数) | 1、输入自然数 2、验证 | 12345678 | 合法 | |||
2 | 不合法(4位自然数) | 1、输入自然数 3、验证 | 1234 | 不合法 | |||
3 | 合法(8位非自然数) | 1、输入自然数 4、验证 | 1234567a | 不合法 |
例2:
测试点提取:
区号验证、前缀验证、后缀验证
有效类 | 无效类 | |
地区码 | 1、NULL 2、三位数字 | 1、两位数字 2、三位非数字 |
前缀 | 非0/1开头的三位数字 | 1、0开头的三位数字 2、1开头的三位数字 2、非0/1开头的四位数字 3、非0/1开头的三位非数字 |
后缀 | 四位数字 | 1、三位数字 2、四位非数字 |
用例编号 | 用例标题 | 模块 | 前置条件 | 优先级 | 测试步骤 | 测试数据 | 预期结果 |
tel_01 | 合格(区号为NULL+前缀为非0/1开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号NULL 前缀234 后缀1234 | 通过验证 |
tel_02 | 合格(区号为三位数字+前缀为非0/1开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀234 后缀1234 | 通过验证 |
tel_03 | 不合格(区号为两位数字+前缀为非0/1开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号12 前缀234 后缀1235 | 无法通过验证 |
tel_04 | 不合格(区号为三位非数字+前缀为非0/1开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号abc 前缀234 后缀1235 | 无法通过验证 |
tel_05 | 不合格(区号为三位数字+前缀为0开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀034 后缀1236 | 无法通过验证 |
tel_06 | 不合格(区号为三位数字+前缀为1开头的三位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀134 后缀1236 | 无法通过验证 |
tel_07 | 不合格(区号为三位数字+前缀为非0/1开头的四位数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀2345 后缀1237 | 无法通过验证 |
tel_08 | 不合格(区号为三位数字+前缀为非0/1开头的三位非数字+后缀为四位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀abc 后缀1237 | 无法通过验证 |
tel_09 | 不合格(区号为三位数字+前缀为非0/1开头的三位非数字+后缀为三位数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀abc 后缀123 | 无法通过验证 |
tel_10 | 不合格(区号为三位数字+前缀为非0/1开头的三位非数字+后缀为四位非数字) | 号码规则验证 | / | P0 | 输入区号、前缀、后缀 验证 | 区号123 前缀abc 后缀abcd | 无法通过验证 |
例3:
一元二次方程求解程序
提取测试点:方程是否合法,单实数根,双实数根,虚数根
有效类划分
有效类 | 无效类 | |
a | 非0常数 | 1、0 2、非常数 |
b | 常数 | 非常数 |
c | 常数 | 非常数 |
b^2-4ac | 1、=0 2、>0 3、<0 | / |
测试用例
用例编号 | 用例名称 | 项目/模块 | 优先级 | 前置条件 | 测试数据 | 测试步骤 | 预期结果 |
1 | a:1 b:2 c:1 | x=1 | |||||
2 | a:1 b:-3 c:2 | x=1||x=2 | |||||
3 | a:1 b:1 c:1 | x有虚数根 | |||||
4 | a:0 b:2 c:1 | 非法 | |||||
5 | a:a b:2 c:1 | 非法 | |||||
6 | a:1 b:b c:1 | 非法 | |||||
7 | a:1 b:2 c:c | 非法 |
等价类划分法针对的是有大量测试数据,但没法穷举测试的地方,如:输入框,下拉列表,单选复选框
边界值分析法
解决边界限制问题(如区一个集合区间内的值)
边界范围节点
选取正好等于、刚好大于、刚好小于边界的值作为测试数据
- 上点:边界上的点(正好等于)
- 离点:距离上点最近的点(刚好大于/小于)
- 内点:范围内的点
边界值分析法 最多七条用例,最少五条用例(去掉靠近内点的两个上点)
边界值分析法流程
- 明确需求
- 确定有效等价类和无效等价类(不可忽略,因为边界值只考虑值的分类,无法判断如数据类型等其他属性)
- 确定边界范围值
- 编写测试用例
例1:
输入的标题字数要求大于0,小于20
提取测试点
提取等价类
有效 | 无效 | |
字数 | >0&&<=20 | 1、=0 2、>20 |
确定边界值
上点 | 0,20 |
离点 | 1,19,21 |
1,19,20为有效类,0,21为无效类
编写测试用例
用例编号 | 用例名称 | 项目/模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
title_01 | a | 合格 | |||||
title_02 | 19个a | 合格 | |||||
title_03 | 20个a | 合格 | |||||
title_04 | Null | 不合格 | |||||
title_05 | 21个a | 不合格 |
例2
边界值法验证QQ号合法性(6-10位自然数)
提取测试点
提取等价类
有效 | 无效 | |
长度 | >=6&&<=10 | 1、Null 2、<6||>10 |
字符类型 | 自然数 | 非自然数 |
确定边界值(长度)
上点 | 6,10 |
离点 | 5,7,(9,)11 |
编写测试用例
用例编号 | 用例名称 | 项目/模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
QQ_01 | 123456 | 合法 | |||||
QQ_02 | 1234567890 | 合法 | |||||
QQ_03 | 1234567 | 合法 | |||||
QQ_04 | Null | 不合法 | |||||
QQ_05 | 12345 | 不合法 | |||||
QQ_06 | 12345678901 | 不合法 | |||||
QQ_07 | abcdef | 不合法 | |||||
QQ_08 | abcde | 不合法 | |||||
QQ_09 | abcdefghij | 不合法 | |||||
QQ_10 | abcdefghijk | 不合法 |
例3
找零最佳组合
假设商品价格[X]均为不超过100的整数,若顾客购买一件商品,付款[Y]在100元内,求找给顾客的最小货币张数[a]
货币面值:50[R50]、20[R20]、10[R10]、5[R5]、2[R2]、1[R1]
分析:输入值:X,Y;输出值:a
X的约束:X<=100&&X>0
Y的约束:Y<=100&&Y>0&&Y>=X
a=R50+R20+R10+R5+R2+R1,其中R50、R10、R5、R1的约束为0<=R<=1,R20、R2的约束为0<=R<=2
提取测试点
提取等价类
有效 | 无效 | |
X | 0<x<=100 | 1、X<=0 2、X>100 |
X为整数 | X不为整数 | |
Y | 0<x<=Y<=100 | 1、Y<=0 2、Y>100 3、Y<X |
Y为整数 | Y不为整数 |
分析边界值
X | Y | |
上点 | 0,100 | X,100, |
内点 | 50 | |
离点 | -1,101 | X-1,101 |
设计测试用例
用例编号 | 用例名称 | 项目/模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | |
X | Y | |||||||
50 | 50 | R | ||||||
50 | 75 | R | ||||||
50 | 100 | R | ||||||
100 | 100 | 不合法 | ||||||
0 | 0 | |||||||
0 | 50 | |||||||
0 | 100 | |||||||
0 | -1 | |||||||
… | … | … |
测试用例优化:离点(开区间选择内部离点,闭区间选择外部离点)
边界值分析法的常用使用场景
- 在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
- 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语
- 典型代表:有边界范围的输入框类测试
等价类和边界值为最常用的方法
判定表法
判定表多用于逻辑判断的场景
是以表格形式表达多条件逻辑判断的工具
组成
- 条件桩:列出问题的所有条件,列出条件的次序无关紧要
- 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束
- 条件项:列出条件对应的取值,所有可能情况下的真假值
- 动作项:列出条件项的、各种取值情况下应该采取的动作结果
判定表中每一列就是一条规则
假设有n个条件,每个条件的取值均为a,则共有a^n条规则
步骤
- 明确需求
- 画出判定表
- 列出条件桩和动作桩
- 填写条件项,对条件进行全组合
- 根据条件项的组合确定动作项
- 简化、合并相似规则
- 编写测试用例
例1
如果金额大于500元,又未过期,则发出批准单和提货单
如果金额大于500元,但过期了,则不发批准单和提货单
如果金额小于等于500元,则不论是否过期都发出批准单和提货单
在过期的情况下不论金额大小还需发出通知单
画判定表
条件 | 金额是否大于500 | 1 | 1 | 0 | 0 |
是否过期 | 0 | 1 | 1 | 0 | |
操作 | 批准单 | 1 | 0 | 1 | 1 |
提货单 | 1 | 0 | 1 | 1 | |
通知单 | 0 | 1 | 1 | 0 |
测试用例
用例编号 | 用例名称 | 项目/模块 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 |
a_01 | 1、501 2、没过期 | 发批准单和提货单 | ||||||
a_02 | 1、501 2、过期 | 发通知单 | ||||||
a_03 | 1、500 2、过期了 | 发批准单、提货单和通知单 | ||||||
a_04 | 1、500 2、没过期 | 发批准单和提货单 |
使用场景
有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有约束关系
一般用于组合条件数量较少的地方
条件组合较多时可以用正交表和因果表实现
场景法
笔者所在公司要求的Xmind提取测试点是场景法的一种应用,因此不过多赘述
大致可以理解为根据软件的使用场景,划分各个模块和功能,对软件的流程和数据流向进行可视化表现。一般表现为流程图等。
如图为一个简单的搜索订单编号的测试点提取
个人理解,前文提到的等价类、边界值、判定表法需要综合运用到场景法中的具体点,场景法只是一种测试大纲。
如图中的第一行输入框就可以使用前文的等价类/边界值方法,选择日期可以使用判定表法
错误推荐法
通过经验推测系统可能出现的问题
根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷
笔者在校期间内主攻的方向是算法,对于后端开发比较熟悉,因此入职后测试的第一个软件,在缺乏测试基本理论的情况下,基本都是靠经验判断哪里存在缺陷。如哪些操作可能会造成内存溢出,哪些地方可能遗漏了异常检测等。