自动化测试篇--用例篇
目录
一.什么是测试用例？
二.如何设计测试用例？
三.炒冷饭ing
四.具体的测试设计方法
1.等价类
2.边界值
3.场景法
4.正交法
5.判定表法
6.错误猜测法
五.实践操作
一.什么是测试用例？
测试⽤例（TestCase）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则⼀：
测试用例中⼀个必需部分是对预期输出或结果进⾏定义
现在需要测试一个买回来的新电视，会有下列的步骤：
1)开机测试
2)切换频道
3)调一下分辨率
4)蓝牙功能
这里一条一条的表述就是一个个测试用例，软件涉及特性多，因此需要将测试用例记录下来；编写测试用例可以让我们知道需要测试哪些内容，尽可能做到测试覆盖率更高
主流的测试用例写法有2种，一种是excel表格写法，一种是思维导图写法
比如我们要去测试登录功能，那如果使用excel表格写法，就会出现如下的一张表格
分为了标题、环境、测试步骤、测试用例和预期结果五大部分
二.如何设计测试用例？
笔试的时候编写测试用例，需要按照excel表格来答题（会涉及到测试用例的要素）
面试的时候按照思维导图的方式来回答即可（不涉及测试用例的要素，可以下载xmind这个软件来画思维导图）
测试引例：
在设计一个门锁的时候有什么需要注意的？
要考虑到锁的质量、安全性、尺寸、性能、功能与便捷性
这样说比较笼统，不够具体；工作中，测试用例的设计并不是越多越好，而是能覆盖更多的可能性
一般软件测试的时候，需要 常规思考+逆向思维+发散性思维
比如我们在测试登录功能的时候，常规思维是使用一般性的字符和密码是否能够登录？
逆向思维是如果我用特殊字符是否能够登录？
发散性思维是用特殊的，非常规的需要一定专业知识的方法来测试；比如在用户空填写 select *，是否会把所有用户的信息都提取出来？
万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试
功能测试：参考需求文档，验证软件功能是否正确
界面测试：界面所有的元素都需要测试，主要集中在大小、颜色和形状（硬件产品还得加上材质）
性能测试：五菱汽车和法拉利的区别，功能就是车门、车窗，两辆车都有；但是百公里加速、舒适度方面，就是性能的差异；性能通常是在一些极端的情况下去测试功能是否可用，比如同时有几亿用户同时访问一款软件，这款软件的功能是否能被继续使用
兼容性测试：在谷歌浏览器能打开的，在ie浏览器是否能打开？（还有不同操作系统的兼容性）。数据兼容性，即邮箱注册后个人手机号是否可以登录；或者300家与3000000家，无论数字多大，文字都不会出现重叠；或者代码更改后，是否会出现差错。
易用性测试：显示界面是否便捷好用，比如淘宝网购，如果没有商品搜索栏那么就需要修改了，或者说一款游戏的新手教程是否通俗易懂
安全测试：sql注入、DDOS攻击以及密码安全（接口响应、登录场景和用户信息存储时）等……
登陆时，把密码用小黑点隐藏起来
发出request请求以后，前端接口把密码隐藏起来不显示
用户表的方法来保证密码安全，软件获得用户密码以后，通过加密算法变成一串乱码进行存储；然后每次用户输入密码之后，就会先将密码通过同一加密算法转换成乱码，然后去比对是否和用户表里的乱码一致，这也就是为什么用户忘记密码以后，必须要重新设置一个密码，而不能直接获得原始密码（原始密码已经变成乱码了）
下图为对水杯用万能公式进行测试
还有弱网测试（网络比较差的情况下，功能是否正常运行，为了满足更多的网络环境）
如何弱网测试？
这⾥推荐使用fiddler（一款抓包工具，也可以用wireshark或者charles），使用流程如下：
查找语句可以使用 ctrl+f 快捷键，上行是从客户端传到服务器，下行是从服务器传到客户端
打开了弱网设置后，就能够明显感受到加载页面变慢了，也可以把m_simulatemodem数值设置得很大，越大越慢越慢效果越明显
还有安装与卸载测试
安装：安装包是否可以安装、卸载之后是否可以继续安装、重复安装
卸载：完成安装后卸载、安装一般后卸载、卸载一次以后重新安装、卸载一半以后取消卸载
三.炒冷饭ing
跟开发产生争执该怎么办？
1.反思自己，是不是bug描述不够准确
2.站在用户思考问题，反问开发人员：“如果你是用户，能接受这样的设计吗？”
3.bug等级一定要有理有据（三思而后定）
4.最好给出解决方案
继续炒冷饭（doge），反思自己+用户角度+谨慎定级+解决方案
5.最后一招，直接找领导解决（测试+产品+开发代表开个会，探讨怎么解决问题）
四.具体的测试设计方法
1.等价类
将输入划分为多个等价类，等价类当中选择几个最具有代表性的测试用例，只要它们几个通过了，相当于全都通过了
比如注册密码测试，需求文档要求的是密码长度范围必须控制在6-15位字符，那么我们就测一个6位的密码是否通过，测一个15位的密码是否通过，测一个5位的密码是否不同通过，测一个16位的密码是否不通过，只要4个结果与预期相符，相当于所有的情况都通过了
有效等价类：6-15位 当中选几个代表用例
无效等价类：<6位 or >15位 当中选几个代表用例
2.边界值
6-15位密码，边界值即6、15、5和16，一般性选取的等价类测试用例为整个等价集合的边界值
边界值包含：边界值+次边界值
边界值有效，那么次边界值无效，反之亦然；例如[6,15]的数字范围，边界值为6、15（有效），次边界值为5、16（无效）；还有(6,15)的数字范围，边界值为6、15（无效），次边界值为7，14（有效）
3.场景法
右边那一条也是备用流，也是备用流，也是备用流！！！
场景法是通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从⽽⽤来发现需求中存在的问题。
场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流（基本事件流），从阶段中分析出来的不同情况被称之为备选流（备用事件流）。
根据场景法设计邮箱注册的测试用例：
根据场景法设计测试⽤例的步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试⽤例
4.编写测试⽤例
1.确定基本流，邮箱注册需要先点击注册，然后填写个人信息，然后点击注册最后激活
2.确定备选流，点击注册以后很多公司会弹出一个弹窗，是一份声明协议，不同意协议就是备选流；填写信息是否有误？点击注册后是否能够联网传送？激活邮件或者激活验证码是否传达？激活事件是否在规定的时间范围内？等等备用流……
3＆4.编写测试用例
1）基本流：点击注册，同意协议，输入正确信息，点击注册成功激活
2）备用流：点击注册，不同意协议，重新点击注册，重复基本流操作
3）备用流：点击注册，同意协议，输入错误信息，重新点击注册……
4.正交法
正交法的⽬的是为了减少⽤例数⽬。⽤尽量少的⽤例覆盖输⼊的两两组合。
下表即为正交表，因素为存在的条件，水平为因素的取值
最简单的正交表是L4(2^3)，其中4为行号（每列有4行），L为正交表，3为因素数（即只存在列号1、列号2和列号3），2为水平数（即最大的表中数值只会到2，不是指行号、列号）
因此下表应该是L12(2^11)
正交表的性质：
- 一列中每个数字出现次数相同，列1的1出现6次，2也出现6次
- 每一列的每个数字出现次数相同，列1的1出现6次，列2的1也出现6次，列3的1……
- 两列的几个数字组合，出现了11、12、21、22、111、112、121、……，排列方式齐全
而正交试验设计是根据正交性，由试验因素的全部水平组合中挑选出有代表性的点进行试验，通过这部分试验结果的分析了解全面试验情况，找出最优的水平组合。
还是以登录注册功能为例，共有姓名、电子邮箱、密码、确认密码和验证码五项
同时还分为了填写与不填写两种
5个因素，2个水平（分为了0、1，0代表填写，1代表不填写）
设计正交表：借助工具allpairs来实现正交表
下载链接：
https://www.satisfice.com/download/allpairs
使用步骤（以登录注册为例）：
- 根据需求找出因素和水平
- 将因素和水平写入到excel表格中（不保存表格，建议使用微软的excel表格软件）
- 在allpairs.exe同级文件夹下创建一个txt文件，将excel表格中的内容复制到txt文件中，并保存（不要有其他的操作！！！）
- 在终端中使用allpairs.exe工具对txt文件生成正交表文件，具体操作如下
终端中通过cd命令进入release文件夹
生成语法如上所示，res-test.txt是allpairs工具所生成的正交表文件，名字可以随意
没有任何提示就说明生成成功！
上图就是使用allpairs工具生成的正交表，工具生成的正交表会和理想的正交表有一定出入，但没有太大的影响
~：表示可以填写也可以不填写
根据生成好的正交表来编写测试用例，继续将重要的用例补全
还漏了全都填写、全都不填写两种重要的用例
因此最后正交表法能将32种（2^5=32）测试用例简化为8种
若不使用excel，而直接手动在txt文件中编写因素和水平，使用命令生成正交表会存在格式校验错误的情况，allpairs工具对格式要求非常严格，这也就是建议使用微软的excel表格的原因
5.判定表法
判断表法是一种表达逻辑判断的工具，形如上图读书的判定表
只要觉得疲惫，无论是否感兴趣都休息；不觉得疲惫，若感兴趣则继续；不觉得疲惫也不感兴趣，就直接读下一章
没有判定表，写出来的用例组合会非常凌乱，思路不清晰
根据判定表法设计测试用例的步骤：
1. 确认需求中输⼊条件和输出条件
2. 找出输⼊条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试⽤例
现在有一个案例分析：⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员身份；反之无管理员⾝份。
写成逻辑语言：
账户包含admin字符 || 内部链接进入注册页面 + 提交注册按钮 -> 成为管理员
账户不包含admin字符 || 不通过内部链接进入注册页面 + 不提交注册按钮 -> 不成为管理员
……
根据判定表法，输入条件为账户包含admin字符（视为a）、内部链接进入注册页面（视为b）和提交注册按钮（视为c）；输出条件为成为管理员（视为1），或者不成为管理员（视为2）
输⼊条件： ac ab bc abc a b c ⾮ abc（ac代表ac发生，b没有发生，以此类推）
对应结果： 1 2 1 1 2 2 2 2
根据输入输出关系，在excel软件中画出判定表，共有 2^3 = 8 种不同情况（000~111）
表格如下图所示
最后根据判定表编写测试用例
a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份 e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
6.错误猜测法
错误猜测法是基于过往经验与个人经验，来推测出软件可能存在的缺陷，这是一种基于经验主义的办法，但这类方法投入产出比很高，所以还是被广泛应用于测试。
五.实践操作
实践操作时，需要用到xmind来画思维导图，用postman来对接口进行测试