目录
[1. 概念](#1. 概念)
[1.1 什么是测试用例](#1.1 什么是测试用例)
[1.2 什么是要素](#1.2 什么是要素)
[1.3 为什么需要测试用例](#1.3 为什么需要测试用例)
[2. 设计测试用例的万能公式](#2. 设计测试用例的万能公式)
[2.1 常规思维 + 逆向思维 + 发散性思维](#2.1 常规思维 + 逆向思维 + 发散性思维)
[2.2 万能公式](#2.2 万能公式)
[3. 设计测试用例的方法](#3. 设计测试用例的方法)
[3.1 基于需求的设计方法](#3.1 基于需求的设计方法)
[3.2 具体的设计方法](#3.2 具体的设计方法)
[3.3 更多用例练习](#3.3 更多用例练习)
测试用例
1. 概念
1.1 什么是测试用例
// 测试用例 (Test Case) 是为了实施测试而被测试的系统提供的一组集合, 这组集合包含: 测试环境, 测试步骤, 测试数据, 预期结果等要素
1.2 什么是要素
// 我们在编写测试用例的时候, 每个用例需要给出这些要素对应的信息
// 要素包括: 用例编号, 标题, 测试方式, 功能模块, 重要性, 测试前提, 测试环境, 测试数据, 测试步骤, 期望结果等
1.3 为什么需要测试用例
1.3.1 测试中可能会遇到很多问题, 测试用例的出现急速解决这些问题, 例如:
// 不知道是否较全面的测试了所有功能
// 测试的覆盖率无法衡量
// 对新版本的重复测试很难实施
// 存在大量冗余测试影响测试效率
1.3.2 测试用例还可以避免测试人员被迫背锅
2. 设计测试用例的万能公式
// 例如: 现在有一款产品, 要求我们对 "门锁" 设计测试用例
// 测试用例的设计, 最重要的一点就是保证功能是正确的
2.1 常规思维 + 逆向思维 + 发散性思维
// 正确设计测试用例的思想: 常规思维 + 逆向思维 + 发散性思维
// 设计测试用例的原则二 :
2.1.1 测试用例的编写不仅应当根据有效和预料到的输入情况, 而且也应该根据无效和未预料到的输入情况
2.1.2 检查程序是否 "未做其应该做的" 仅是成功的一半, 测试的另一半是检查程序是否 "做了其不应该做的"
2.1.3 计划测试工作时不应默许假定不会发生错误
2.2 万能公式
// 设计测试用例的万能公式:
// 功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试
2.2.1 功能测试
// 功能测试时一个试图发现程序与其外部规则说明之间存在不一致的过程
// 从产品功能角度出发, 验证功能是否是正确的
2.2.2 界面测试
// 对软件界面上所有的内容都需要进行测试
// 界面涉及到的内容: 元素 (大小, 颜色, 形状, 材质)
// 要求: 整体界面测试界面的实现与设计图要求一致, 界面元素测试
2.2.3 性能测试
// 性能测试和功能测试的区别是: 功能测试检查软件是否做了, 性能测试测试软件做的好不好
// 通常为一些极端的情况验证功能是否是正常的
2.2.4 兼容性测试
// 软件是部署在硬件系统之上, 并依赖所需的软件环境. 软件是否能够在不同环境下正确运行需要测试人员进行验证
// 选取标准: 优先选择使用当前产品 top 级别的机型进行测试; 选择主流的浏览器/机型进行测试
2.2.5 易用性测试
// 易用性测试的标准是检查产品是否具备简单易上手的属性
2.2.6 安全测试
// 安全测试和性能测试一样都是比较大的领域
// 常见的安全问题: 隐私数据明文显示; 参数未强校验导致 SQL 注入; 越权: 普通用户也可以执行管理员权限的操作
// 除了万能公式外, 还有一个比较常用的测试类型: 弱网测试, 安装卸载测试
// 弱网测试: 主要是为了尽可能保证用户体验
// 借助抓包工具来模拟实现弱网测试 (fiddle, charles)
// 安装卸载测试: 针对需要部署的软件, 除了软件功能外, 我们还需要关注软件的能够成功完成安装和卸载
// 安装: 安装包是否可以安装, 卸载之后是否可以继续安装, 重复安装...
// 卸载: 安装完成后卸载, 安装一半后卸载, 卸载一次后继续安装继续卸载
// 测试接口: URL, 请求参数, 请求方法, 响应
3. 设计测试用例的方法
// 以下都是针对黑盒测试用例设计的测试方法
3.1 基于需求的设计方法
// 分为: 功能相关和非功能相关
// 基于新需求的设计方法也是总的设计测试用例的方法, 在工作中, 我们需要参考需求文档/产品规格说明书来设计测试用例
// 测试人员街道需求之后, 要对需求进行分析和验证, 从合理的需求中进一步分析细化需求, 从细化的需求中找到测试点.
3.1.1 明确需求中的功能点
3.1.2 结合万能公式设计测试点
3.2 具体的设计方法
3.2.1 等价类
// 依据需求将输入划分为若干个等价类, 从等价类中选出一个测试用例, 如果这个测试用例测试通过, 则认为所代表的等价类测试通过, 这样就可以用较少的测试用例达到尽量多的功能覆盖, 解决了不能穷举测试的问题
// 等价类分为: 有效等价类; 无效等价类
// 有效等价类: 满足用户需求的数据集合
// 无效等价类: 不满足用户需求的数据集合
// 如何通过等价类的方法设计测试用例: 1. 充分理解需求; 2. 划分出有效等价类和无效等价类; 3. 从有效等价类中抽取一个测试用例测试, 从无效等价类中抽取一个进行测试; 4. 组合有效等价类, 组合无效等价类
3.2.2 边界值
// 边界值包括: 边界值 + 次边界值
// 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法, 通常边界值分析法是作为对等价类划分法的补充
// 主要测试的点: 上点, 离点, 内点
// 上点: 边界上的点, 不管是开区间, 闭区间, 还是半开半闭
// 内点: 边界内的点, 不管是开区间, 闭区间, 还是半开半闭
// 离点: 边界左右的一个点, 如果是闭区间, 离点就是范围外的点, 如果是开区间, 离点就是范围内的点
// 设计测试用例的步骤: 1. 充分理解需求; 2. 找离点, 内点, 上点; 3. 针对离点, 内点, 上点设计测试用例
3.2.3 正交法
// 正交法的目的是为了减少用例数目, 用尽量少的用例覆盖输入的两两组合
// 可以使用 pairs 设计工具来设计正交表
// 步骤: 1) 在微软自带的 Excel 中输入 因素 和 水平; 2) 复制到 allpairs.exe 同级目录下的 .txt 文档中直接保存; 3) 在黑窗口输入命令 allpairs.exe 空格 .txt 文档 > 新命名一个用来保存正交表的 .txt 文档 回车
// 在根据生成好的正交表来编写测试用例的同时也要继续补全重要的测试用例
// allpairs 工具生成的正交表和实际的正交表会有一定的出入, 但是不影响整体的情况
3.2.4 判定表法
// 通过具体的方法能够将测试用例设计的更急完整和规范, 通过判定表法我们可以非常容易的编写测试用例 (思路清晰)
// 判定表是一种表达逻辑判断的工具
// 根据判定表法设计测试用例的步骤: 1) 确认需求中输入条件和输出条件; 2) 找出输入条件和输出条件之间的关系; 3) 画判定表; 4) 根据判定表编写测试用例
3.2.5 场景法
// 场景法一般包含基本流 (基本事件流) 和备用流 (备用事件流)
// 现在的软件几乎都是用事件触发来控制流程的, 实践触发时的情景形成了场景, 而同一事件不同的触发顺序和处理结果就形成了事件流
// 通过运用场景来对系统的功能点或业务流程的描述, 从而提高测试效果的一种方法
3.2.6 错误猜测法
// 对被测试软件的需求理解以及设计的理解, 过往经验以及个人直觉, 推测出软件可能存在的缺陷, 从而针对性地设计测试用例的方法
// 强调的是对测试软件的需求理解以及设计实现的细节把握, 还有个人的经验和直觉
// 和目前流行的 "探索式测试方法" 的基本思想一致, 这类方法在敏捷开发模式下的投入产出比很高, 被广泛应用于测试
3.3 更多用例练习
3.3.1 命令行程序
// 关于 Windows, Linux 系统命令设计测试用例
3.3.2 web 程序
// 使用 postman 进行测试
// postman 具体安装及使用点击下面链接跳转