1. 测试用例定义
测试用例又叫做test case，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
2. 编写测试用例的原因
2.1 理清思路，避免遗漏
如果测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
2.2 跟踪测试进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。
2.3 历史参考
在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
2.4 规范作用
我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
3. 测试用例的要素
3.1. 测试用例八大要素
| 测试用例编号 | 测试项目(测试模块) | 预置(前提)条件 | 测试输入 | 预期输出 | 操作步骤 | 测试用例标题 | 级别 |
|---|---|---|---|---|---|---|---|
| ST-子项名-01 | 手机登录 | 手机正常使用 | 手机号 | 正常登录 | 输入手机号并确认 | 测试能否手机登录成功 | 重要 |
1). 测试用例编号
编号由字符和数字组合成的字符串,用例编号具有唯一性、容易识别, 如下表
测试项目
测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等
3). 预置条件
执行当前测试用例需要的前提条件,如果前提条件不满足,则后面的测试步骤不能进行或者得不到预期结果
4). 测试输入
测试用例执行过程中需要加工的外部信息.根据测试用例的具体条件有手工输入、数据库等
5). 预期输出
测试用例的预期输出结果,包括返回值内容、界面响应结果等.
6). 操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
7). 测试用例标题
对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。
8). 级别
对于测试用例的重要程度的区分.包含如下几种:
- 高级别
保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
- 中级别
重要程度介于高和低之间的测试用例
- 低级别
实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
3. 2. 其他要素
- 用例的设计者:能准确找到测试用例的设计人员,对用例修改时能方便找到人员
- 用例设计日期: 方便检查用例的设计进度
- 对应的开发人员: 出现bug后能及时找到相应的人员进行修复
- 测试结果: 执行用例最后执行的结果, 包括:pass、fail、block
- 测试类型: 功能、性能、压力等等
测试用例设计方法—等价类划分法
掌握常用测试用例设计方法,再结合测试用例的要素能给快速的实现测试用例的设计和编写.但是由于软件系统大小的不同我们不可能把所有的单个或组合的情况都进行测试,所以我们测试时应该根据不同的场景设计不同的测试用例,尽可能的覆盖到全部需要测试的情况.
常用的测试用例设计方法有: 等价类划分话、边界值分析法、判定表法、正交验证法、错误推测法、场景法、因果图法.
等价类划分法
1. 等价类划分的介绍和概念定义
- 划分
指互不相交的一组子集，这些子集的并是整个集合。
对测试的意义：完备性和无冗余性。
- 等价类
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，具有等价特性。
- 等价类合理地假设
测试某等价类的代表值就等于对这一类其它值的测试。
- 等价类划分
在测试中最完美的测试是使用穷举测试,把所有的数据都测一遍.但是实际工作中不能采用,因为效率太低了.
理想的测试时:使用最少的测试数据,达到最好的测试质量.
等价类划分法的测试思想是:
从大量数据里划分范围（每个范围内的数据测试效果是等价的所以每个范围是一个等价类），然后从每个范围中挑选代表数据，这些代表数据能反应这个范围内数据的测试结果。
官方定义:
等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
1.1. 类型划分
等价类的类型划分分为:有效等价类和无效等价类.
(1). 有效等价类
有效等价类是指对对于程序的规格说明来说是合理的、有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
(2). 无效等价类
无效等价类指对程序的规格说明是不合理的、无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。利用无效等价类可校验程序对于无效数据的处理能力,检测程序的健壮性、容错能力
注意:
设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。
2. 设计测试用例
步骤:
- 确定需求
- 确定有效等价类和无效等价类
- 对每条等价类设计测试用例
3. 案例
要求:使用等价类划分法测试QQ账号的合法符合规范
| 明确需求 | 输入6-10位的自然数 | |
|---|---|---|
| 有效等价类 | 有效等价类 | 自然数个数大于6小于10个 |
| 无效等价类 | 无效等价类 | 小于6个、大于10个、中文、空格、英文、特殊字符、小数 |
| 设计测试用例 | 有效等价类测试用例 | 无效等价类测试用例 |
测试用例
| 用例编号 | 等价类划分 | 输入 | 预期结果 | 测试结果 | 重要级别 |
|---|---|---|---|---|---|
| UT-QQ账号-01 | 有效等价类 | 12345678 | 正确 | 正确 | 高级 |
| UT-QQ账号-02 | 无效等价爱类 | 12 | 错误 | error | 高级 |
| …. | ….. | …. | …. | …. | …. |
4. 小结
4.1 . 应用场景
- 有输入的地方,可以从大量数据中挑选少量的代表数据进行测试,使用等价类划分法
4.2 . 测试用例的设计
根据等价类划分设计的测试用例,及保证了程序的功能或需求的实现,也一定程度上保证了功能的健壮性的实现, 所以在实际使用中比较多.
边界值测试法
1. 介绍
边界值分析法就是对输入或输出边界值进行测试的,也是一种黑盒测试.
边界值分析法通常作为等价类划分法的补充,其测试用例来自等价类的边界;长期的经验得知,大量的错误是发现在输入或输出范围的边界上，而不是发生再输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多错误.
和等价类划分法的区别:
- 是等价类划分法的补充
- 等价类划分法可以挑选等价范围内任意一个数据作为代表,边界值分析法要求每个边界值都要作为测试条件
- 边界值分析法不仅考虑输入条件,同样考虑输出产生的测试情况
常见的边界值:
- 边界点(上点):输入范围的边界点
- 离点: 离边界点最近的点
- 内点: 输入范围内的任意一个点
对于边界值的说明:
边界值数据本质上属于等价类的范畴,测试时确实是一种冗余（重复），但是为了更好的测试质量（边界值特别容易出bug），边界值必须要单独测,适当必要的冗余是可以接受的.
举例: 0-100内的整数
| 上点 | 0, 100 |
|---|---|
| 离点 | 1, 99; -1,101; 1,101; 0, 99; |
| 内点 | 34 |
2. 使用边界值设计测试用用例
2.1 步骤:
- 明确需求
- 确定有效和无效等价类
- 明确输入条件中的边界值
- 编写测试用例
注意: 边界值法应用时，如果测试时间紧张，应该优先测试最大值和最小值
2.2 案例
要求:测试qq账号是否符合规范
- 需求: qq号是6-10位的整数
- 确定边界值
| 上点 | 6个, 10个 |
|---|---|
| 离点 | 5个, 9个, 7个,11个 |
| 内点 | 8个 |
- 编写测试用例
| 用例编号 | 等价类划分 | 输入 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| UT-QQ是否符合规范-01 | 有效等价类 | 6个 | 正确 | |
| UT-QQ是否符合规范-02 | 有效等价类 | 10个 | 正确 | |
| UT-QQ是否符合规范-03 | 无效等价类 | 5个 | 错误 | |
| UT-QQ是否符合规范-04 | 有效等价类 | 7个 | 正确 | |
| UT-QQ是否符合规范-05 | 无效等价类 | 11个 | 错误 | |
| UT-QQ是否符合规范-06 | 有效等价类 | 9个 | 正确 | |
| UT-QQ是否符合规范-07 | 有效等价类 | 8个 | 正确 | |
| UT-QQ是否符合规范-08 | 无效等价类 | 特殊符号,例如: #,¥ *、空格等 | 错误 | |
| UT-QQ是否符合规范-09 | 无效等价类 | 数字+特殊符号 | 错误 |
3. 小结
边界值分析法作为等价类划分法的补充,经常和等价类划分一起使用.
使用的场景是:有输入并且存在边界值的位置.
判定表法
1. 使用场景
适合于有多个输入和对个输出,输入和输出之间有相互的组合关系, 输入输出之间有相互的制约和依赖关系
2. 定义
判定表也称决策表, 是分析和表达多逻辑条件下执行不同操作的工具.
它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题。
3. 组成
判定表是由条件桩、动作桩、条件项、动作项四部分组成,如下图.
| 条件桩 | 条件项 |
|---|---|
| 动作桩 | 动作项 |
1） 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2） 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3） 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4） 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
4.规则及规则合并
4.1 规则
任何一个条件组合的特定取值及其相应要执行的操作称为规则。
在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
4.2 化简
规则合并有两条或多条规则具有相同动作,并且其条件项之间存在着极为相似的关系。
5. 测试案例设计
步骤:
- 明确规则个数
- 列出所有条件桩和动作桩
- 填入条件项
- 填入动作项,等到初始判定表
- 简化,合并相似规则
6. 案例
1. 案例1
问题要求:对于功率大于50马力的机器、维修记录不全或运行10年以上的机器,应优先维修.
测试案例设计思想
1.1 . 明确规则个数
这里有三个条件:大于50马力、维修记录不全、运行10年以上, 每个条件有2种取值,所以有八种规则.
1.2. 列出条件桩和动作桩
| 条件桩 | 功率大于50马力? |
|---|---|
| 维修记录不全? | |
| 运行超过10年? | |
| 动作桩 | 优先处理 |
1.3. 填入条件项
1.4. 填入动作项等到初始判定表
| 条件桩 | 条件项 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|---|
| 功率大于50马力? | Y | Y | Y | Y | N | N | N | N | |
| 维修记录不全? | Y | Y | N | N | Y | Y | N | N | |
| 运行10年以上? | Y | N | Y | N | Y | N | Y | N | |
| 动作桩 | 优先处理? | X | X | X | X | X | |||
| 其他处理 | X | X | X |
1.5 . 简化判定表
通过初始的判定表我们发现:
-
在三个条件中有2个不满足时,剩下的一个完全没有参考价值,可以进行简化.
只有功率大于50马力、维修记录全的、运行十年以上的才优先处理;
其他处理的情况是:满足动力大于50马力、维修功能完全、没有运行10年以上中只要满足两项
-
简化后为
| 条件桩 | 条件项 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|---|
| 功率大于50马力? | Y | Y | N | N | Y | |
| 维修记录不全? | Y | N | - | - | N | |
| 运行10年以上? | - | Y | Y | N | N | |
| 动作桩 | 优先处理? | X | X | X | ||
| 其他处理 | X | X |
注意: “-”表示取值与否不影响触发的动作.即,不影响规则
2. 案例2.
公交一卡通自动充值系统要求:
- 系统只接收50或100元纸币，一次只能使用一张纸币，一次充值金额只能为50元或100元。
- 若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；
- 若输入50元纸币，并选择充值100元，提示错误，并退回50元；
- 若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；
- 若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；
- 若输入纸币后在规定时间内不选择充值按钮，找零，并提示错误；
- 若选择充值按钮后不输入货币,提示错误
测试案例实现如下
2.1 明确规则个数
| 规则个数(条件桩) | 输入50元 |
|---|---|
| 输入100元 | |
| 充值50元 | |
| 充值100元 |
2.2. 列出条件桩和动作桩
| 动作桩 | 提示充值成功 |
|---|---|
| 充值成功并退卡 | |
| 退卡 | |
| 找零 |
2.3. 列入条件项
2.4. 填入动作项,等待初始的判定表
| 输入条件 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|---|
| 输入50元 | Y | Y | X | ||||||
| 输入100元 | Y | Y | X | ||||||
| 充值50元 | Y | Y | X | ||||||
| 充值100元 | Y | Y | X | ||||||
| 动作桩 | 充值成功并退卡 | X | X | X | |||||
| 提示充值成功 | X | X | X | ||||||
| 找零 | X | X | X | X | |||||
| 提示错误 | X | X | X | X | X |
2.5 简化
这个案例中每个条件都是独立的,没有可以简化的
2.6.测试用例设计
上面的表中每一条就是一个测试用例.
7. 小结
优缺点
优点
- 能把复杂问题按照各种可能情况—列举出俩, 简明而易于理解,避免遗漏
缺点
- 不能表达重复执行的动作、例如循环结构
因果图法
1. 概述
因果图法是一种利用图解法分析输入条件、输出结果的各种组合情况,从而设计测试用例的方法.
因果图法适用于有多个输入和多个输出，而且输入和输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系.
使用场景和判定表法是一样的.
在界面中有多个控件，控件之间有组合或限制关系，不同的输入组合会对应不同的输出结果，如果想弄清楚不同的输入组合到底对应哪些输出结果，可以使用因果图/判定表法。(因果图/判定表法比较适合测试组合数量较少的情况，一般少于20种)
和判定表法的不同:
- 因果图，只是一个用图形表示，表示因果方式不同而已
关联:
- 判定表和因果图是等价的，判定表是因果图的简化版。
2.核心
2.1 因果图
原因(因): 输入条件
结果(果): 输出结果
因果图: 就是通过画图的方式来表示输入条件（因）和输出结果（果）之间的关系。
2.2 因果图中的图形符号
(1). 恒等(=)
含义: 原因出现结果出现,原型不出现,结果不出现. 例如:若c=10,则d=0.
(2). 非 (~)
含义: 若原因出现,则结果不出现;原因不出现则结果出现.例如: 搜索联系人,若有就不提示错误.
(3). 或 (v)
含义: 若几个原因中有一个出现,这结果出现;若都不出现,结果不出现.
(4). 与(^)
含义: 若几个原因都出现结果才出现,否则,结果不出现.
2.3 约束
输入状态相互之间还可能存在某些互相依赖的关系,称为约束. 输出状态之间也存在某些约束.在因果图中使用特定符号表示这些约.
束.
(1). 输入条件约束
- E(exclude) 约束: a和b中至多有一个为1.
- I(include) 包含: a、b和c中至少有一个必须是1.
- R(required) 要求: a是1时，b必须是1.
- O(only) 唯一: a和b必须有一个，且仅有1个为1.
(2). 输出条件约束
- M(mandatory) 强制: 若结果a是1,结果b强制为0.
3. 设计测试用例
步骤
- 了解需求,找出所有的输入条件(因)
- 找出所有的输出结果(果)
- 画因果图、填判定表
- 判定表中每个规则就是一条测试用例
4.案例
问题描述: 如想对文件进行修改,输入的第一列字符必须是a或b,第二列字符必须是一个数字,如果第一列字符不正确则给出信息L,如果第二个字符不正确,则给出字符M
4.1 了解需求,找出输入条件
1— — 第一列字符是a
2 — — 第一列值符为b、
3 — — 第二列必须是数字
4.2 找出所有的输出结果
结果:
4— 信给出息l
5— 信息m
6— 修改文件
4.3 画因果图、填判定表
通过分析得出,原因1和原因2不可能同时出现,添加约束E. 设置9为中间点.
因果图如下:
判定表法
| 条件(原因) | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Y | Y | N | N | N | N | Y | Y | |
| 2 | N | N | Y | Y | N | N | Y | Y | |
| 3 | Y | N | Y | N | Y | N | Y | N | |
| 中间值 | 9 | Y | Y | Y | Y | N | N | ||
| 动作(结果) | 4 | Y | Y | ||||||
| 5 | Y | Y | |||||||
| 6 | Y | Y | Y |
注意: 第7列和第8列不可能出现,所以排除这两种情况.
4.4 根据判定表设计测试用例
5.小结
因果图法是通向判定表法的一个中间过程.我们经常会将因果图法和判定表分析法结合起来使用.
对于业务逻辑比较复杂的我们建议先使用因果图法进行分析,然后再转化为判定表法,最后写测试用例.这样思路比较清晰,
对于简单的可以直接使用判定表法直接分析,然后写测试用例.
正交法
通过分析我们发现,对于图中的程序而言,我们要设计81条测试用例,那么有没有一种方法能够使用最小的测试过程集合获得最大的测试覆盖率呢?
1. 概述
1.1 定义
正交法,也叫正交实验法或者正交排列法, 就是使用最小的测试过程集合获得最大的测试覆盖率。
“正交实验”是研究多因素、多水平的一种实验方法,它利用正交表来对实验进行设计,通过少数实验代替全面的实验.
在一项实验中,把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
1992年AT&T公司,针对某一个软件做了一个回归测试：
在18个周（4个半月）的时间范围内测试1500条测试用例。后来开发时间推迟了，测试时间被压缩了。测试经理想了一个办法，两个人在8个周（2个月）测试1000条测试用例。但是测试经理不能保证该软件就是完全没有问题的。后来他决定用正交表去重新设计一下测试用例，422条测试用例，42个bug。测试完毕后，软件上线了。在上线的两年时间内。凡事被测试到的领域，都没有发现任何问题。后来呢，他从头到尾有总结了一番：有可能只会测试出32条bug。
前后对比：
测试用例的条数少了
测试出来bug的数量多了
1.2 正交表的构成
˙正交表时一种特制的表, 一般记为$$Ln(m^k)$$
- n是表的行数,也就是需要测试组合的次数
- k是表的行数, 表示控件个数(因素的个数,或因子的个数)
- m是每个控件包含的取值个数(各因素的水平数,即各因素的状态数
例如: $$L9(3^4)$$ 正交表如下
2. 使用正交法设计测试用例
2.1 步骤
- 根据需求把空间即其取值列举出来
- 根据空间和空间的取值个数,选择一个合适的正交表
- 根据控件的个数,选择正交表的次幂,也就是正交表中包含的最大值, 例如,4个控件,选择4次幂
- 根据控件取值个数,选择正交表的底,也就是正交表包含的最大值, 例如, 每个控件有3个取值,底是3
- 把控件及其取值映射到正交表中
- 把控件名字分别映射到正交表的列名位置
- 把正交表中每一列的数字分别用对应的控件取值替代
- 根据正交表,编写测试用例
2.2 案例
实现“字符属性设置”的测试用例编写
(1). 列举因子表
| 字体 | 字符样式 | 字体颜色 | 字号 |
|---|---|---|---|
| 仿宋 | 粗体 | 红色 | 20号 |
| 楷体 | 斜体 | 绿色 | 30号 |
| 华文彩云 | 下划线 | 蓝色 | 40号 |
(2) 确定使用的正交表
| 确定采用的正交表 |
|---|
| $$L9(3^4)$$ |
(3). 把控件及其取值映射到正交表中
(4). 编写测试用例
上图正交表每一行都是一条测试用例,, 此处仅列出2条
| 用例编号 | 输入 | 预期结果 | 实际结果 | 是否是bug |
|---|---|---|---|---|
| UT-设置字符子项测-01 | 字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:20 | 仿宋、 粗体、 红色、20号 | ||
| UT-设置字符子项测-02 | 字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:30 | 仿宋、 粗体、 红色、20号 |
3. 小结
3.1 使用场景
- 需求中条件的组合量比较大的时候
- 需求两个两个相互组合的时候
3.2 局限性
正交表的个数有限,一般要求每个控件的取值相等,但是这在实际中很难应用,所以在实际使用时要进行取舍
- 对于控件个数,如果没有,就选择一个接近的
- 对于控制的取值,应该少数服从多数, 有更多空间的取值一样