测试用例篇章
本节概要：
测试⽤例的概念
设计测试⽤例的万能思路
设计测试⽤例的⽅法
一、测试用例
1.1 概念
什么是测试用例？
测试⽤例（Test Case）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则一： 测试用例中⼀个必需部分是对预期输出或结果进⾏定义
什么是要素？我们在编写测试⽤例的时候，每个⽤例需要给出这些要素对应的信息。
| ⽤例编号 | test-01 |
| 标题 | 成功注册⽹易邮箱 |
| 测试⽅式 | ⼿⼯测试 |
| 功能模块 | 注册登陆 |
| 重要性 | 重要 |
| 测试前提 | 系统运⾏正常，邮件服务器已开启 |
| 测试环境 | win10 Chrome版本103.0.5060.66（正式版本）（64位） |
| 测试数据 | 邮箱地址：996402440@qq.com 密码：123456 ⼿机号：12312341234 |
| 测试步骤 | 1.打开⾕歌浏览器，输⼊⽹易注册地址：https://mail.163.com/register/index.htm 2.输⼊邮箱地址，密码，⼿机号，获取验证码并输⼊正确的验证码，勾选协议 3.点击注册按钮 |
| 期望结果 | 展现注册成功的结果⻚，并且使⽤刚注册的账号可以正常登陆并进⼊邮箱⾸⻚ |
现在实际工作中大多数采用思维导图的方式来编写测试用例。
为什么需要测试⽤例呢，不写测试⽤例可以进⾏测试吗？
因为软件中涉及到的特性太多了，仅仅通过头脑风暴是无法完成一次完整的测试。编写测试用例，通过编写测试用例我可以想到要测试哪些内容，通过一次又一次的更新修改将测试用例写到完成，功能覆盖率更高即可。
测试中可能会遇到很多问题，诸如：
不知道是否较全⾯的测试了所有功能
测试的覆盖率⽆法衡量
对新版本的重复测试很难实施（即回归测试⽆法仅通过⼈⼯测试的⽅式进⾏历史功能的回归）
存在⼤量冗余测试影响测试效率
测试⽤例的出现就是解决这些问题。另外，测试⽤例的作⽤还可以避免测试⼈员被迫背锅~~
二、设计测试用例的万能公式
2.1 常规思考+逆向思维+发散性思维
正确设计测试⽤例的思想：常规思维+逆向思维+发散性思维
设计测试用例的原则二：
- 测试⽤例的编写不仅应当根据有效和预料到的输⼊情况，⽽且也应该根据⽆效和未预料到的输⼊情况。
- 检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该做的”。（是上⼀条原则的必然结果）
- 计划测试⼯作时不应默许假定不会发现错误
明白了设计测试⽤例是思维的正确还往往不够，往往是想到一条写一条，能够设计出来的测试用例整体上数量是合格的，但是测试用例不够具体，太笼统了，无法作为测试工作的参考依据。
工作中，测试用例的设计并不是越多越好，而是能够达到更大的功能覆盖率则是最好的。
若仅仅通过头脑⻛暴去设计测试⽤例，能够想出来的⽤例是寥寥⽆⼏的，
所以在设计测试⽤例的时候需要有思路的去设计
2.2 万能公式
设计测试用例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易用性测试+安全测试
功能测试：从产品功能角度出发，验证功能是否是正确的；
界面测试：肉眼可以看到的部分都称为界面，界面所有的元素都需要测试；
性能测试：通常是一些特殊极端的情况
兼容性测试：不同的版本（软件，系统）的兼容性，浏览器的兼容性，不同的浏览器，数据的兼容性（新版本更新旧版本也得正常这里也还涉及到一个回归测试）
易用性测试：具备简单易上手的属性（引导教程）
安全测试：是否有危险因素，接口返回值省略隐私数据，接口响应数据也要考虑到用户数据的安全性，登录场景也需要将密码进行加密展示，数据库存储用户隐私数据是否加密，SOL注入，越权
以登录邮箱为例子：密码是否为掩码展示，前后端传参是否对密码进行加密传输（不加密传输会被恶意抓包泄露用户隐私数据）。
除了万能公式之外，还有⼀个比较常用的测试类型：弱网测试、安装卸载测试
弱网测试：
为了覆盖更多的网络场景，保证在网络环境不太好的情况下，页面可以正常的加载不至于崩调，保证功能是正常的。
弱⽹测试的⽬的就是尽可能保证用户体验，关注的关键点包括：
• ⻚⾯响应时间是否可以接受，关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间，⾸屏时间等。
• ⻚⾯呈现是否完成⼀致。
• 超时⽂案是否符合定义，异常信息是否显⽰正常。
• 是否有超时重连。
• 安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。
• ⼤流量事件⻛险：是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。
弱⽹需要借助⼯具来构造弱网，这⾥推荐使⽤fiddler
1）fiddler配置代理
2）fiddler进⾏抓包（桌⾯/移动端）
3）fiddler如何构造弱⽹条件
安装卸载测试：
针对需要进⾏部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。
一般用于移动端和客户端。
三、设计测试用例的方法
3.1 基于需求的设计方法
测试和开发开展工作的依据：软件需求（用户需求经过需求分析会议后变成软件需求文档）
基于需求的设计⽅法也是总的设计测试⽤例的⽅法，在⼯作中，我们需要参考需求⽂档/产品规格说明书来设计测试⽤例
测试⼈员接到需求之后，要对需求进⾏分析和验证，从合理的需求中进⼀步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试⽤例。以该注册邮箱账号需求为例，我们来设计测试⽤例。
1.明确需求中的功能点 ：账号注册，账号登陆
2.结合万能公式设计测试点
上面叫做根据需求文档先设计初步的测试用例，而部分用例还需细化，就需要借助具体的设计方法
3.2 具体的设计方法
3.2.1 等价类
依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果 这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的 功能覆盖，解决了不能穷举测试的问题。
缺点：等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。
3.2.2 边界值
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等 价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。
边界值包含：边界值+次边界值。
3.2.3 正交法
正交法的⽬的是为了减少⽤例数⽬。⽤尽量少的⽤例覆盖输⼊的两两组合
正交试验设计(Orthogonal experimentaldesign)是研究多因素多⽔平的⼀种设计⽅法，它是根据正交 性，由试验因素的全部⽔平组合中挑选出部分有代表性的点进⾏试验，通过对这部分试验结果的分析了 解全⾯试验的情况，找出最优的⽔平组合。正交试验设计是⼀种基于正交表的、⾼效率、快速、经济的试验
正交表的性质：
• 每⼀列中，不同的数字出现的次数相等。
• 任意两列中数字的排列⽅式⻬全⽽且均衡
正交法设计测试⽤例的步骤：
1. 找到因素和⽔平
2. ⽤allparis⼯具⽣成正交表
a. 将因素和⽔平写⼊Excel表格中
b. allparis⽬录下创建新的⽂本⽂件new.txt，复制Excel中的因素和⽔平，直接粘贴到⽂本中保存
并退出
c. 使⽤allparis命令⽣成正交表：allparis.exe new.txt>zhengjiao.txt
3. 根据正交表编写测试⽤例
4. 补充遗漏的重要测试⽤例
3.2.4 判定表法
通过具体的⽅法能够将测试⽤例设计的更加完整和规范。需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝份；反之⽆管理员⾝份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。
根据判定表法设计测试⽤例的步骤：
1. 确认需求中输⼊条件和输出条件
2. 找出输⼊条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试⽤例
3.2.5 场景法
现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流。
通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从⽽⽤来发现需求中存在的问题。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备⽤流来完成整个场景。场景主要包括4种主要的类型：正常的⽤例场景，备选的⽤例场景，异常的⽤例场景，假定推测的场景。
读完上⾯的概念是不是⼀脸懵，场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法⽐较考验同学们的发散思维。
该⽅法可以⽐较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，是测试⽤例更容易理解和执⾏。典型的应⽤是是⽤业务流把各个孤⽴的功能点串起来，为测试⼈员建⽴整体业务感觉，从⽽避免陷⼊功能细节忽视业务流程要点的错误倾向
根据场景法设计测试⽤例的步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试⽤例
4.编写测试⽤例
编写测试⽤例：
1.输⼊正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。
2.不输⼊账号密码，点击注册，提⽰重新输⼊
3.只输⼊账号，不输⼊密码，点击注册，提⽰重新输⼊
4......
3.2.6 错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽针对性地设计测试⽤例的⽅法。
这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。 错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产出⽐很⾼，被⼴泛应⽤于测试。