一、测试用例概念
- 测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果的文档
- 通过大量的测试用例来检验软件的运行效果
- 它是指导测试工作的依据
二、测试用例价值
- 指导测试的实施
- 规划测试数据的准备
- 编写测试脚本的“设计规格说明书”
- 评估测试结果的度量基准
- 分析缺陷的标准
三、黑盒测试方法
一、等价类划分法
1.等价类划分法概念
- 等价类划分是一种重要的、常用的黑盒测试方法
- 不需要考虑程序的内部结构，只需要考虑程序的输入规格即可
- 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性
- 用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
- 在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试结果
2.等价类分类
- 有效等价类：指符合《需求文档》，输入合理的数据集合
- 无效等价类：指不符合《需求文档》，输入不合理的数据集合
3.等价类划分原则
- 规定输入的取值范围或个数时，划分一个有效和两个无效
- 规定了输入的集合或规则必须要遵循的条件，则划分一个有效和一个无效
- 输入条件是一个布尔值，则划分一个有效和一个无效
- 输入条件是一组数据，并且每一个输入的值做不同的处理，则划分若干个有效和一个无效
- 输入条件规定了必须要遵循的某些规则下，则划分为一个有效和若干个无效
- 不是所有的等价类都有无效等价类
4.等价类设计步骤
1.先划分等价类：找出所有可能得分类
2.确定有效等价类：需求中的条件
3.确定无效等价类：与条件相反的情况，再找到特殊情况
4.从各个分类中挑选测试用例数据
5.等价类划分方法
在确定了等价类之后，可按下表的形式列出所有划分出的等价类表
输入条件 有效等价类 无效等价类
6.等价类总结
- 长度
- 类型
- 组成规则
- 是否为空
- 是否重复
- 是否去除空格
二、边界值
1.边界值分析法
- 大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部
- 为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果
- 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力
- 边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界
2.边界值确定
- 上点：边界上的点
- 离点：离上点最近的点
- 内点：在输入域内任意一个点
- 选取正好等于、刚好大于或刚好小于边界值作为测试数据
3.边界点划分规则
- 如果规定了输入域的取值范围
- 选取刚好在范围边界的点
- 刚好超过边界的点
- 如果规定了输入值的个数
- 最大个数
- 最小个数
- 比最小个数小1
- 比最大个数多1
- 如果规定了输入是一个有序的集合
- 选取集合的第一个元素
- 选取集合的最后一个元素
4.边界值总结
- 确定边界情况
- 选取正好等于、刚好大于或刚好小于边界值作为测试数据
- 确定各个值的等价类
三、因果图
1、因果图定义
- 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法
- 它适合于检查程序输入条件的各种组合情况
- “因”–输入条件
- “果”–输出结果
2.因果图适用场景
- 描述多种条件的组合
- 产生多个动作
3.因果图中的基本符号
- 恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
- 非： 若原因出现，则结果不出现；若原因不出现，则结果出现
- 或：有多个原因。若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现
- 与：有多个原因。若几个原因都出现，则结果出现；若几个原因中有一个不出现，则结果不出现
4.因果图中的约束条件
- 互斥E：a，b，c只能有一个成立，但是可以都不成立
- 包含I：a，b，c中至少有一个成立
- 唯一O：a，b，c有且仅有一个成立
- 要求R：如果a成立，则要求b必须也成立，其他的不约束
- 屏蔽M：如果a成立的时候，强制b不成立，其他的不约束
5.因果图法基本步骤
- 找出所有的输入条件（因 ）
- 找出所有的输出条件（果）
- 明确所有输入条件之间的制约关系以及组合关系
- 明确所有输出条件之间的制约关系以及组合关系
- 找出什么样的输入条件组合会产生哪种输出结果
- 把因果图转换成判定表
- 为判定表中的每一列表示的情况设计测试用例
四、判定表
- 因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例
- 画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例
1.判定表的组成
- 条件桩：问题的所有条件
- 动作桩：问题的所有输出
- 条件项：针对条件桩的取值
- 动作项：条件项的各种取值情况下的输出结果
2.判定表设计步骤
- 列出所有的条件桩和动作桩
- 确定规则数：条件取值个数^条件数
- 填入条件项
- 填入动作项。得到初始判定表
- 简化判定表
3.判定表举例
- 判断三角形
- 输入三个正整数a、b、c，分别作为三角形的三条边
- 判断三条边是否能构成三角形
- 如果能构成三角形，判断三角形的类型（等边三角形、等腰三角形、一般三角形）
确定条件桩
- C1：a,b,c构成三角形？a<b+c、b<a+c、c<a+b
- C2：a=b?
- C3：a=c?
- C4：b=c?
确定动作桩
- A1：非三角形
- A2：一般三角形
- A3：等边三角形
- A4：等腰三角形
- A5：不可能
确定条件项和动作项
| 条件桩 | 条件项 |
|---|---|
| C1：a,b,c是否构成三角形？ | 1：满足任意两边之和大于第三边 0：不满足任意两边之和大于第三边 |
| C2：a=b? | 1：a=b 0：a!=b |
| C3：a=c? | 1：a=c 0：a!=c |
| C4：b=c? | 1：b=c 0：b!=c |
| 动作桩 | 动作项 |
| A1：非三角形 | 1：不是三角形 |
| A2：一般三角形 | 1：是三角形 |
| A3：等边三角形 | 1：是等边三角形 |
| A4：等腰三角形 | 1：是等腰三角形 |
| A5：不可能 | 1：不可能 |
设计判定表
| 条件桩 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C1：a,b,c是否构成三角形？ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| C2：a=b? | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| C3：a=c? | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| C4：b=c? | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| 动作桩 | ||||||||||||||||
| A1：非三角形 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||
| A2：一般三角形 | 1 | |||||||||||||||
| A3：等边三角形 | ||||||||||||||||
| A4：等腰三角形 | 1 | 1 | 1 | 1 | ||||||||||||
| A5：不可能 | ||||||||||||||||
| 1 | 1 | 1 |
简化判定表
| 条件桩 | |||||||
|---|---|---|---|---|---|---|---|
| C1：a,b,c是否构成三角形？ | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
| C2：a=b? | - | 0 | 0 | 0 | 1 | 1 | 1 |
| C3：a=c? | - | 0 | 0 | 1 | 0 | 0 | 1 |
| C4：b=c? | - | 0 | 1 | 0 | 0 | 1 | 1 |
| 动作桩 | |||||||
| A1：非三角形 | 1 | ||||||
| A2：一般三角形 | 1 | ||||||
| A3：等边三角形 | |||||||
| A4：等腰三角形 | 1 | 1 | 1 | 1 | |||
| A5：不可能 | |||||||
| 1 |
设计测试用例
| 编号 | a | b | c | 预期结果 |
|---|---|---|---|---|
| 1 | 1 | 4 | 5 | 非三角形 |
| 2 | 3 | 4 | 5 | 一般三角形 |
| 3 | 3 | 2 | 2 | 等腰三角形 |
| 4 | 2 | 3 | 2 | 等腰三角形 |
| 5 | 2 | 2 | 3 | 等腰三角形 |
| 6 | 2 | 2 | 2 | 等边三角形 |
五、场景法
1.场景法概述
- 场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
- 基本流：按照正确的业务流程来实现的一条操作路径
- 备选流：导致程序出现错误的操作流程
2.场景法用例设计步骤
- 根据需求规格说明，画出功能模块流程图
- 根据流程图，描述出功能的基本流及备选流
- 根据基本流和备选流生成不同的场景，构造场景列表
- 对每一个场景生成相应的测试用例
- 对生成的所有测试用例重新复审，去掉多余的测试用例
- 测试用例确定后，为每一个测试用例确定测试数据值
四、测试用例基础概念
一、测试用例的组成
- 用例编号
- 模块
- 测试点（测试标题）
- 优先级
- 前提条件
- 测试步骤
- 期望结果（预期结果）
- 实际结果
二、测试用例的优先级
- 测试用例根据重要性分成一定的等级
- P0
- P1
- P2
- P3
三、测试用例设计工具
- 思维导图
- excel
五、测试用例设计与评审
一、设计方法的选择
- 任何情况下，都需要采用等价类划分法，将无限测试变为有限测试
- 在规定了数据范围的情况下，必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
- 如果含有输入条件的组合情况，考虑选用因果图法和判定表法
- 采用错误推断法再追加测试用例
二、测试用例编写步骤
- 划分功能模块
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 隐形需求
登录功能测试用例设计
设计思路
用例设计
三、测试用例的粒度
- 测试用例可以写的很简单，也可以写的很复杂
- 最简单的测试用例是测试的纲要，仅仅指出要测试的内容
- 测试用例写的过于简单，则可能失去了测试用例的意义
- 测试用例写得过于复杂或详细，会带来两个问题：
- 效率问题
- 维护成本问题
四、测试用例评审
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
五、测试用例设计
1.思路
- 需求分析
- 界面
- 功能
- 易用性
- 兼容性
- 性能
- 安全
