测试用例学习路线
@startmindmap
* 测试用例
** 黑盒测试方法论
*** 等价类
*** 边界值
*** 因果图
*** 判定表
*** 场景法
*** 基于模型的测试
** 白盒测试方法论
** 测试用例基础概念
** 测试用例设计
** 面试测试用例设计
** 常用测试策略与测试手段
@endmindmap
测试用例设计：
- 设计方法的选择
- 测试用例编写步骤
- 需求分析
- 测试用例编写
- 测试用例的粒度
- 测试用例评审
等价类划分法
- 等价类划分是一种重要的、常用的黑盒测试方法
- 不需要考虑程序的内部结构，只需要考虑程序的输入规格即可
- 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性
- 用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
- 在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果
等价类分类
- 有效等价类：指符合《需求文档》，输入合理的数据集合
- 无效等价类：指不符合《需求文档》，输入不合理的数据集合
有效等价类+无效等价类=等价类
等价类划分原则
- 规定输入的取值范围或个数时，划分一个有效和两个无效
- 规定了输入的集合或规则必须要遵循的条件，则划分一个有效和一个无效
- 输入条件是一个布尔值，则划分为一个有效和一个无效
- 输入条件时一组数据，并且每一个输入的值做不同的处理，则划分若干个有效和一个无效
- 输入条件规定了必须要遵循的某些规则下，则划分为一个有效和若干个无效
- 不是所有的等价类都有无效等价类
等价类设计步骤
- 先划分等价类：找出所有可能的分类
- 确定有效等价类：需求中的条件
- 确定无效等价类：与条件相反的情况，再找到特殊情况
- 从各个分类中挑选测试用例数据
等价类总结
- 长度
- 类型
- 组成规则
- 是否为空
- 是否重复
- 是否去除空格
边界值分析法
- 大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部
- 为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果
- 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力
- 边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界
边界值确定
- 上点：边界上的点
- 离点：离上点最近的点
- 内点：在输入域内任意一个点
- 选取正好等于、刚好大于或刚好小于边界值作为测试数据
边界点划分规则
- 如果规定了输入域的取值范围
- 选取刚好在范围边界的点
- 刚好超过边界的点
- 如果规定了输入值的个数
- 最大个数
- 最小个数
- 比最小个数少 1
- 比最大个数多 1
- 如果规定了输入是一个有序的集合
- 选取集合的第一个元素
- 选取集合的最后一个元素
边界值总结
- 确定边界情况
- 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据
- 确定各个值的等价类
因果图定义
- 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法
- 它适合于检查程序输入条件的各种组合情况
- “因” —— 输入条件
- “果” —— 输出结果
因果图适用场景
- 描述多种条件的组合
- 产生多个动作
因果图中的基本符号
- 恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现
- 非：若原因出现，则结果不出现；若原因不出现，则结果出现
- 或：有多个原因。若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现
- 与：有多个原因。若几个原因都出现，则结果才出现；若其中一个原因不出现，则结果不出现
因果图中的约束条件
- 互斥 E：a、b、c 只能有一个成立，但是可以都不成立
- 包含 I：a、b、c 中至少有一个成立
- 唯一 O：a、b、c 有且仅有一个成立
- 要求 R：如果 a 成立，则要求 b 必须也成立，其他的不约束
- 屏蔽 M：如果 a 成立的时候，强制 b 不成立，其他的不约束
因果图法基本步骤
- 找出所有的输入条件（因）
- 找出所有的输出条件（果）
- 明确所有输入条件之间的制约关系以及组合关系
- 明确所有输出条件之间的制约关系以及组合关系
- 找出什么样的输入条件组合会产生哪种输出结果
- 把因果图转换成判定表
- 为判定表中的每一列表示的情况设计测试用例
判定表法
- 因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例
- 画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例
场景法概述
- 场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
- 基本流：按照正确的业务流程来实现的一条操作路径
- 备选流：导致程序出现错误的操作流程
场景法用例设计步骤
- 根据需求规格说明，画出功能模块流程图；
- 根据流程图，描述出程序的基本流及备选流；
- 根据基本流和备选流生成不同的场景，构造场景列表；
- 对每一个场景生成相应的测试用例；
- 对生成的所有测试用例重新复审，去掉多余的测试用例；
- 测试用例确定后，为每一个测试用例确定测试数据值
确定基本流（购物网站）
- 进入淘宝首页
- 浏览商品
- 进入单品页
- 选择商品规格和数量
- 加入购物车
- 前往购物车
- 选择商品
- 结算，进入确认订单页
- 提交订单
- 付款成功
- 等待收货
- 确认收货
确定备选流
- 备选流 1：加入购物车时，不选择商品规格和型号，返回基本流第 4 步
- 备选流 2：加入购物车时，商品库存不足，返回基本流第 4 步
- 备选流 3：加入购物车时，未登录，登录后返回基本流第 3 步
- 备选流 4：加入购物车后，继续选购，返回基本流第 4 步
- 备选流 5：加入购物车，未选择商品，结算，返回基本流第 7 步
- 备选流 6：支付失败，返回基本流第 8 步
- 备选流 7：未选择商品加入购物车，退出购物，结束
构造场景
- 场景 1: 登录后成功购物（基本流）
- 场景 2: 未选择商品规格和型号就添加购物车（基本流 + 备选流 1）
- 场景 3: 选择的商品库存不足（基本流 + 备选流 2）
- 场景 4: 未登录添加购物车（基本流 + 备选流 3）
- 场景 5: 商品添加购物车后继续购物（基本流 + 备选流 4）
- 场景 6: 进入购物车，未选择商品直接结算（基本流 + 备选流 5）
- 场景 7: 支付过程出错（基本流 + 备选流 6）
- 场景 8: 没有添加商品到购物车（基本流 + 备选流 7）
设计方法的选择
- 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
- 在规定了数据范围的情况下，必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
- 如果含有输入条件的组合情况，考虑选用因果图和判定表法
- 采用错误推断法再追加测试用例
测试用例编写步骤
- 划分功能模块
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 隐形需求
需求分析
- 帐号是手机号
- 手机号仅限制为国内常用的号段
- 密码必须为 数字+英文 的形式，字段为 8-12 个字符
- 账号密码都为空时，登录按钮置灰不可点击
- 点击登录按钮，发起登录请求
- 请求成功，跳转到首页
- 点击忘记密码跳转到找回密码页
测试用例编写
@startmindmap
* 登录功能
** 正向功能验证
** 界面验证
** 单个功能验证
*** 手机号输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 数据约束：是否符合真实手机号的规则
*** 密码输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 匹配性：等价类分析测试数据
*** 登录按钮
**** 不同的网络
**** 异常操作
*** 忘记密码按钮
**** 点击忘记密码跳转忘记密码页
left side
** 功能之间交互验证（场景分析）
*** 使用判定表分析手机号与密码填写组合场景是否覆盖完全
**** 手机号与密码都为空
*** 从登录业务逻辑角度，使用场景法补充场景
**** 手机号未注册
** 隐性需求
*** 密码密文展示
*** 账号互踢
*** 登录有效时间
*** 退出登录
*** 不同设备登录数据是否同步
@endmindmap
测试用例的粒度
- 测试用例可以写的很简单，也可以写的很复杂
- 最简单的测试用例是测试的纲要，仅仅指出要测试的内容
- 测试用例写的过于简单，则可能失去了测试用例的意义
- 测试用例写得过于复杂或详细，会带来两个问题：
- 效率问题
- 维护成本问题
测试用例评审
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
思路
- 需求分析
- 界面
- 功能
- 易用性
- 兼容性
- 性能
- 安全性
startmindmap
- 面试测试用例设计思路
** 需求分析
*** 明确需求
*** 和面试官交流需求细节
** 界面测试
*** 页面布局设计和产品原型图一致
*** 页面文案正确
** 功能测试
*** 正向功能验证
*** 单个功能项验证
*** 功能之间交互验证
*** 接口验证
** 易用性测试
*** 功能操作是否简便
*** 页面布局是否美观合理
*** 提示语相关信息是否易于理解
** 兼容性测试
*** APP
**** 平台
**** 厂商
**** 系统版本
**** 屏幕大小与分辨率
*** WEB
**** 浏览器
**** 操作系统
**** 分辨率
left side
** 性能测试
*** 服务器性能测试
*** APP 客户端性能测试
** 安全性测试
*** 注入攻击
*** 加密
*** 权限
** APP 测试要点
*** 网络
*** 中断
*** 系统权限
** WEB 测试要点
*** 链接测试
*** 多个浏览器同时访问
@endmindmap
软件测试流程
- 完成软件测试工作的必要步骤
需求分析-测试计划-测试设计-测试执行-测试总结
测试计划模板
- 测试计划模版：测试计划模版
测试计划编写要点
- 5W + H 原则
- why：为什么要进行这些测试
- what：测试哪些方面，不同阶段的工作内容
- when：测试不同阶段的起止时间
- where：相应文档，缺陷的存放位置，测试环境等
- who：项目有关人员组成，安排哪些测试人员进行测试
- how：如何去做，使用哪些测试工具以及测试方法进行测试
业务架构分析工具
- 思维导图
- plantuml
@startmindmap
* 登录
** 账号密码登录
*** 账号输入框
*** 密码输入框
*** 登录按钮
** 第三方登录
@endmindmap
@startuml
actor 用户
用户 -> 客户端: 点击账号密码登录
客户端 --> 用户: 登录界面
用户 -> 客户端: 输入帐号、密码，点击登录按钮
客户端 -> 客户端: 前端校验帐号和密码规则
alt 校验通过
客户端 -> 服务端: 传递帐号和密码
else
客户端 --> 用户: 返回校验后的提示信息
end
database 数据库
服务端 -> 数据库: 查询用户登录信息
数据库 --> 服务端: 返回查询结果
服务端 --> 客户端: 返回登录结果
alt 登录成功
客户端 --> 用户: 登录成功，返回我的页面，展示登录后的信息
else
客户端 --> 用户: 提示登录失败信息
end
@enduml
Bug 判定标准
程序错误、程序漏洞、程序不完善
- 软件未达到客户需求文档的功能和性能
- 软件出现客户需求不能容忍的错误
- 软件的使用未能符合客户的习惯和工作环境
- 软件超出需求文档的范围
严重程度和优先级的关系
- 一般地，严重性程度高的软件缺陷具有较高的优先级
- 有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理
- 有时候一些严重性低的缺陷却需要及时处理，具有较高的优先级
Bug 处理流程
不同角色的对 Bug 的职责
Bug 处理流程：
Bug 处理意见:
Bug 报告
- 记录 Bug
- 跟踪 Bug
- 更好的和开发人员交流
Bug 报告模版:
Bug 报告要素
1. Bug 编号
2. 所属产品
2. 发现的版本
3. 所属的模块
4. 提交人
5. 错误类型
6. 复现概率
7. 严重级别
8. 优先级
9. 标题：言简意赅说明是什么 bug
10. 内容（描述）
- 测试环境
- 前提条件
- 复现步骤
- 预期结果
- 实际结果
11. 附件：截图、出错的 log 日志、测试用的数据
测试总结
测试报告作用
- 把测试的过程和结果写成文档
- 对发现的问题和缺陷进行分析
- 为纠正软件的存在的质量问题提供依据
- 为软件验收和交付打下基础
测试报告模板
- 测试报告模版：测试报告模版
总结要点
- 人力投入
- 用例覆盖情况
- Bug 的分类及数量统计
- 遗留 Bug 情况
- 测试风险
- 测试结论
业务架构分析工具 plantuml
plantuml 介绍
- UML：统一建模语言
- plantuml：第三方插件工具
- plantuml 官网：使用简单的文字描述画UML图的开源工具。
- plantuml 中文文档：plantuml中文文档
- plantuml 在线绘图地址：https://plantuml.ceshiren.com/