文章目录
- [1. 测试用例](#1. 测试用例)
-
- [1.1 概念](#1.1 概念)
- [2. 设计测试用例的万能公式](#2. 设计测试用例的万能公式)
-
- [2.1 常规思考+逆向思维+发散性思维](#2.1 常规思考+逆向思维+发散性思维)
- [2.2 万能公式](#2.2 万能公式)
- [3. 设计测试用例的方法](#3. 设计测试用例的方法)
-
- [3.1 具体的设计⽅法](#3.1 具体的设计⽅法)
-
- [3.1.1 等价类](#3.1.1 等价类)
- [3.1.2 边界值](#3.1.2 边界值)
- [3.1.3 正交法](#3.1.3 正交法)
-
- [3.1.3.1 如何设计正交表](#3.1.3.1 如何设计正交表)
- [3.1.4 判定表法](#3.1.4 判定表法)
-
- [3.1.4.1 根据判定表法设计测用例的步骤](#3.1.4.1 根据判定表法设计测用例的步骤)
- [3.1.5 场景法](#3.1.5 场景法)
- [3.1.6 错误猜测法](#3.1.6 错误猜测法)
- [3.3 更多用例练习](#3.3 更多用例练习)
-
- [3.3.1 命令行程序](#3.3.1 命令行程序)
- 3.3.2web程序
1. 测试用例
1.1 概念
什么是测试⽤例？
测试⽤例（TestCase）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
软件中涉及到的特性太多了，仅仅通过个人的经验并不能完成一次完整的测试，漏测的风险是非常高的。
编写测试用例是有讲究的，但是这种讲究在之前用到的比较多（通过excel来编写和管理测试用例），现在用脑图/思维导图比较多。
| 用例编号 | test-01 |
|---|---|
| 标题 | 成功注册⽹易邮箱 |
| 测试⽅式 | ⼿⼯测试 |
| 功能模块 | 注册登陆 |
| 重要性 | 重要 |
| 测试前提 | 系统运⾏正常，邮件服务器已开启 |
| 测试环境 | win10Chrome版本103.0.5060.66（正式版本）（64位） |
| 测试数据 | 邮箱地址：[email protected]；密码：123456 ；⼿机号：12312341234 |
| 测试步骤 | 1.打开⾕歌浏览器，输⼊⽹易注册地址https://mail.163.com/register/index.htm。 2.输⼊邮箱地址，密码，⼿机号，获取验证码并输⼊正确的验证码，勾选协议。3.点击注册按钮 |
| 期望结果 | 展现注册成功的结果⻚，并且使⽤刚注册的账号可以正常登陆并进⼊邮箱⾸⻚ |
笔试的时候编写测试用例题，需要按照excel表格的方式来答题（会涉及到测试用例的要素）。
面试的时候设计测试用例题，需要按照思维导图的方式一一表述出来即可（不会涉及到测试用例的要素）。
对一个产品来实现测试，设计测试的点越多，覆盖的功能也就越多，产品的覆盖度也就越高。
测试用例非常多，仅仅通过人的大脑记忆肯定是不现实的，最终要变成文字版本的测试用例。因此，实际在工作中，我们在执行测试之前一定要先把测试用例设计好。
设计的用例越多肯定是越好的，但是用例越多，测试的工作成本也就越高，因此实际在工作中要求测试用例能够覆盖的测试面越高越好~。但是！！！在找工作中，设计的测试用例原则为：越多越好！！！
2. 设计测试用例的万能公式
⽤例的设计最重要的⼀点是保证功能是正确的。
2.1 常规思考+逆向思维+发散性思维
正确设计测试⽤例的思想：常规思维+逆向思维+发散性思维
设计测试⽤例的原则⼆：
1.测试⽤例的编写不仅应当根据有效和预料到的输⼊情况，⽽且也应该根据⽆效和未预料到的输⼊情况。
2.检查程序是否"未做其应该做的"仅是成功的⼀半，测试的另⼀半是检查程序是否"做了其不应该做的"。（是上⼀条原则的必然结果）
3.计划测试⼯作时不应默许假定不会发现错误。
2.2 万能公式
设计测试⽤例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试。
- **功能测试：**从产品的功能角度触发，验证产品功能的正确性。
- 界面测试： 肉眼可以看到的都叫界面，界面上所有的元素（大小、颜色、形状、材质）都需要测试。
- 性能测试： 通常都是一些极端的情况。
- 兼容性测试： 浏览器的兼容性、不同版本（软件、系统）、数据兼容性。
- 易用性测试： 具备简单易上手的属性（引导教程、用户说明书）。
- 安全测试： 接口请求参数、响应数据要考虑到数据的安全性。数据存储也要考虑到数据的安全性。SQL注入、越权（垂直越权、水平越权）、是否具备危险材质、有毒气味。
功能没有问题不代表性能没有问题。
除了万能公式之外，还有⼀个⽐较常⽤的测试类型：弱⽹测试、安装卸载测试。
弱网测试
弱⽹测试的⽬的就是尽可能保证⽤⼾体验，关注的关键点包括：
• ⻚⾯响应时间是否可以接受，关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间，⾸屏时间等。
• ⻚⾯呈现是否完成⼀致。
• 超时⽂案是否符合定义，异常信息是否显⽰正常。
• 是否有超时重连。
• 安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。
• ⼤流量事件⻛险：是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。
弱⽹需要借助⼯具来构造弱⽹，这⾥推荐使⽤fiddler
- fiddler配置代理
- fiddler进⾏抓包（桌⾯/移动端）
- fiddler如何构造弱⽹条件
安装卸载测试
检查是否可以正常卸载
检查是否可以正常安装
安装卸载后再重新安装，是否可以正常安装
重复卸载
重复安装
...
水杯的测试用例：
面试的时候，通常面试官给出的设计用例的对象就是一句话，没有具体的描述，该如何让设计测试用例？
- 根据个人的经验（购物车、红包）。
- 没有用过（人为的去想象功能）。
- 测试的时候一定不要假设没有问题，而是认定一定有问题，想办法把问题找出来。
- 工作中，测试用例的数量跟产品的质量有一定的关系，也不意味着设计越多的测试用例越好，而是能够覆盖的业务场景越多测试的质量越多但是如果测试用例设计的过少，说明产品的质量一定是比较差.
- 面试的时候，面试官主要考察同学们思维发散能力和用例设计的能力，用例设计的越多，意味着设计测试用例的能力越好，思维发散能力越强.
3. 设计测试用例的方法
3.1 具体的设计⽅法
我们以测试上面的内容来设计测试用例：
3.1.1 等价类
依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
等价类分类：
• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
• ⽆效等价类：根据需求说明书，不满足需求的集合。
3.1.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界值包括：边界值和次边界值。边界值即给定返回的最左边和最右边的数据。
选择次边界值要根据边界值的有效/无效来设计：
1）若边界值为有效的数据，则次边界值为无效的边界。
2）若边界值为无效的数据，则次边界值为有效的边界。
我们在一开始设计的测试用例的基础上加上边界值的测试用例：
现在我们的测试用例还是有点多，我们可以删除同类的测试用例
3.1.3 正交法
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonalexperimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交表：
如图最简单的正交表是L(4)(2^(3))，含意如下："L"代表正交表；L下角的数字"4"表示有4横行，简称行，即要做四次试验；括号内的指数"3"表示有3纵列，简称列，即最多允许安排的因素是3个；括号内的数"2"表示表的主要部分只有2种数字，即因素有两种水平1与2。
【正交表的构成】：因素数、水平数、行数。【因素】：对指标的影响条件，通常是正交表中的一列。
【水平】：因素对应的可选项。
【正交表的性质】：每一列中，不同的数字出现的次数相等。任意两列中数字的排列方式齐全而且均衡
【举例】：
因素：存在的条件（姓名、电子游戏、密码、确认密码、验证码）
水平：因素的取值（填写、不填写）
正交表的行数计算公式：
3.1.3.1 如何设计正交表
借助工具来实现正交表---allpairs
1. 根据需求找到因素和水平
2. 将因素和水平写入excel表格中（过度一下，不用保存文件）
建议使用微软自带的excel表格，有些同学电脑上有wps、其他的excel工具（不建议使用）。
3. 在allpairs.exe同级目录下创建空的.txt文件，将excel表格中的内容复制到.txt文件中
在复制之后千万不要有任何其他的操作，直接保存文本即可。
4. 使用allpairs.exe工具对.txt文件 生成正交表文件
可以使用终端窗口输入命令：allpairs.exe test.txt > result.txt
该命令表示将源文件text.txt生成正交表文件result.txt。
建议不要提前创建目标文件result.txt，可以是一个不存在的文件，若存在，一定要保证该文件为空。
result.txt
allpairs工具生成的正交表和实际的正交表会有一定的出入，但是不影响整体的情况。
5. 根据正交表编写测试用例，继续将重要的用例补全
3.1.4 判定表法
判定表是一种表达逻辑判断的工具：
3.1.4.1 根据判定表法设计测用例的步骤
【需求】：用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮成为管理员身份；反之无管理员身份。
1. 确认需求中输入条件和输出条件
2. 找到输入条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试用例
3.1.5 场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
场景法就是一个常规的流程中，某些阶段可能会出现一些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验同学们的发散思维。
【案例】：邮箱账号注册
根据场景法设计测试用例额步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试用例
4.编写测试用例
编写测试用例：
1.输入正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。
2.不输入账号密码，点击注册，提示重新输入
3.只输入账号，不输入密码，点击注册，提示重新输入
4...
3.1.6 错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。错误推测法和目前流行的"探索式测试方法"的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。
3.3 更多用例练习
3.3.1 命令行程序
存在功能可以在命令行使用zip/unzip命令对文件进行解压缩，这样的场景如何来设计测试用例？
zip命令
功能测试：对不同的文件类型进行测试
1）普通的txt文件能够生成zip文件
2）图片/视频/zip文件能够生成zip文件
3）多个文件能够生成zip文件(混合文件)
4）空文件夹可以生成zip文件
5）错误的命令是否可以解压(zipzip/没有写压缩包文件名称/没有源文件)
6）其他参数的测试
界面测试：
1）文件压缩成功命令行提示是否美观
2）文件压缩报错命令行提示是否友好
性能测试：
1）文件大小超过1G时文件是否可以压缩
2）文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内
兼容性测试：
1）zip工具可以在多系统上使用，如Windows、Linux、Mac
易用性测试：
1）zip命令有使用帮助教程，如zip--help命令下会展示如何使用
安全性：
1）使用zip命令不会泄漏文件内容
3.3.2web程序
如何对当前接口设计测试用例呢？
不同的请求⽅式：
1.以GET⽅式请求接⼝是否可以返回预期的响应数据
2.以POST⽅式请求接⼝是否可以返回数据
参数组合（如果接⼝需要拼参数的情况下）：
1.空参数
2.多参数
3.少参数
4.参数对应的值为空/过⻓/特殊字符...
不同的参数格式：
1.url拼参
2.form-data格式
3.raw格式等等
接⼝性能：
1.⼀千万个请求同时发起，是否能够返回响应
2.并发情况下响应时间是否在⼤众接受范围内
通常情况下会借助接口测试工具postman来进行测试：
添加请求的方式：
- 手动填写
- 复制请求并添加到postman
- 打开页面开发者工具，选中要复制的接口，右键复制url
- 打开postman，点击import按钮，选择Raw text方式导入请求，将复制好的url粘贴到文本框中，选择 continue。
- 继续点击 import
- 最终，接口被成功导入到postman中啦
