文章目录
- 目录
-
- [1. 测试用例](#1. 测试用例)
-
- [1.1 概念](#1.1 概念)
- [2. 设计测试用例的万能公式](#2. 设计测试用例的万能公式)
-
- [2.1 常规思考+逆向思维+发散性思维](#2.1 常规思考+逆向思维+发散性思维)
- [2.2 万能公式](#2.2 万能公式)
- [3. 设计测试用例的方法](#3. 设计测试用例的方法)
-
- [3.1 基于需求的设计方法](#3.1 基于需求的设计方法)
- [3.2 具体的设计方法](#3.2 具体的设计方法)
-
- [3.2.1 等价类](#3.2.1 等价类)
- [3.2.2 边界值](#3.2.2 边界值)
- [3.2.3 正交法](#3.2.3 正交法)
- [3.2.4 判定表法](#3.2.4 判定表法)
- [3.2.5 场景法](#3.2.5 场景法)
- [3.2.6 错误猜测法](#3.2.6 错误猜测法)
- [3.3 更多用例练习](#3.3 更多用例练习)
-
- [3.3.1 命令行程序](#3.3.1 命令行程序)
- [3.3.2 接口](#3.3.2 接口)
目录
- 测试用例
- 设计测试用例的万能公式
- 设计测试用例的方法
1. 测试用例
1.1 概念
什么是测试用例？
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：标题、测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则一：
测试用例中一个必需部分是对预期输出或结果进行定义
什么是要素？
我们在编写测试用例的时候，每个用例需要给出这些要素对应的信息。
为什么需要测试用例呢，不写测试用例可以进行测试吗？
测试中可能会遇到很多问题，诸如：
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）
- 存在大量冗余测试影响测试效率
测试用例的出现就是解决这些问题。
上面展示的是传统的编写测试用例的方式，我们在学习敏捷模型的时候了解到，如今大多数企业采用的都是思维导图的方式来编写测试用例。以下内容包括日常用例练习都是用思维导图/脑图进行编写。
2. 设计测试用例的万能公式
2.1 常规思考+逆向思维+发散性思维
正确设计测试用例的思想：常规思维+逆向思维+发散性思维
设计测试用例的原则二：
- 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。
- 检查程序是否"未做其应该做的"仅是成功的⼀半，测试的另⼀半是检查程序是否"做了其不应该做的"。（是上⼀条原则的必然结果）
- 计划测试工作时不应默许假定不会发现错误。
2.2 万能公式
设计测试用例的万能公式：功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试
案例：
除了万能公式之外，还有两个比较常用的测试类型：弱网测试、安装卸载测试
- 弱网测试
弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：
- 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
- 页面呈现是否完成一致。
- 超时文案是否符合定义，异常信息是否显示正常。
- 是否有超时重连。
- 安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
- 大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
弱网需要借助工具来构造弱网，这里推荐使用fiddler
1）fiddler配置代理
2）fiddler进行抓包（桌面/移动端）
3）fiddler如何构造弱网条件
- 安装卸载测试
针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载
3. 设计测试用例的方法
3.1 基于需求的设计方法
基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。
测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。
以该注册邮箱账号需求为例，我们来设计测试用例。
- 明确需求中的功能点
账号注册，账号登陆
- 结合万能公式设计测试点
3.2 具体的设计方法
3.2.1 等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
等价类分类：
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
- 无效等价类：根据需求说明书，不满足需求的集合
根据等价类设计测试用例的方式：
- 确定有效等价类和无效等价类
- 编写测试用例，设计具体测试数据
缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充
3.2.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界值包含：边界值 + 次边界值
3.2.3 正交法
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交法的目的是为了减少用例数目，用尽量少的用例覆盖输入的两两组合。
3.2.4 判定表法
需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮成为管理员身份；反之无管理员身份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题，而判定表法能够解决需要考虑输入之间的组合关系对应不同结果的场景。
3.2.5 场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
场景法通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
针对场景法给出生活中的案例，以逛街买衣服为例，讲讲场景法的使用方法：
该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
案例：
还是根据邮箱账号注册的案例，根据场景法来设计测试用例
3.2.6 错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的"探索式测试方法"的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
3.3 更多用例练习
3.3.1 命令行程序
存在功能可以在命令行使用zip/unzip命令对文件进行解压缩，这样的场景如何来设计测试用例？
功能测试：对不同的文件类型进行测试
- 普通的txt文件能够生成zip文件
- 图片/视频/zip文件能够生成zip文件
- 多个文件能够生成zip文件（混合文件）
- 空文件夹可以生成zip文件
- 错误的命令是否可以解压（zip zip/没有写压缩包文件名称/没有源文件）
- 其他参数的测试
界面测试：
- 文件压缩成功命令行提示是否美观
- 文件压缩报错命令行提示是否友好
性能测试：
- 文件大小超过1G时文件是否可以压缩
- 文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内
兼容性测试：
- zip工具可以在多系统上使用，如Windows、Linux、Mac
易用性测试：
- zip命令有使用帮助教程，如zip --help命令下会展示如何使用
安全性测试：
- 使用zip命令不会泄漏文件内容
3.3.2 接口
