测试用例的设计

测试用例的概念

什么是测试⽤例？
测试⽤例（Test Case）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

比如我们买回来了一个新电视，要进行测试：

然而这只是根据生活经验来得出的测试用例，在软件测试中，我们不可能仅凭现场想到的测试用例来完成一次完整的测试。

笔试的时候编写测试用例的题目，需要按照excel表格的方式来答题。（会涉及测试用例的要素）

示例：

而面试的时候回答测试用例，用思维导图的方式一一道来即可。（不会涉及测试用例的要素）

示例：

设计测试用例的万能公式

首先设计测试用例的时候，需要具备以下的思路：

常规思考： 比如用正确的账号和密码进行登录。

逆向思维：故意使用错误的账号和密码进行登录，或者使用正确的账号或者错误的密码来登录。

发散性思维：比如账号故意使用字符串，或者考虑到SQL注入攻击等等。

这是我们设计测试用例的一个前提思路，但是当我们面对面试官的时候，能想出来的测试用例还是有限的，我们可以通过一个万能公式帮我们去引导。

测试用例的万能公式：功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全性测试

功能测试：从产品功能角度出发，验证功能是否正确。

界面测试：肉眼可看到的地方都称为界面，比如形状，大小，颜色，有些还有材质等。

性能测试：通常举一些极端性的例子，比如高温，低温，潮湿环境等等。

兼容性测试：比如不同的系统，浏览器等等。

易用性测试：具备简单易上手的属性。

安全性测试：是否具备危险材质，化学气体；再比如登录界面，接口响应是否考虑到用户的数据安全性，还有SQL注入，越权等问题。

以水杯的测试用例，用万能公式进行引导如下：

另外除了万能的测试公式外，还有两个常用的测试类型：弱网测试 和 安装和卸载测试

关于弱网测试

也就是模拟用户在网络条件差的情况下，软件运行是否依旧符合预期。

我们可以用filddler这个抓包软件来模拟弱网环境。

打开filddler后，先打开弱网设置的脚本：

找到

其中request-trickle-delay表示的就是上行速率，也就是我们传给服务器的速率，下面的就表示的是下行速率。这里的300表示的是传输1kb需要300ms。

我们可以将其改为较大的值后保存退出

在这里将Simulate Modem Speeds打开。

然后再打开一个网页，就会发现明显加载速度就慢多了。

所以我们可以借助抓包工具来进行弱网测试。

关于安装和卸载测试

针对需要进⾏部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。

设计测试用例的方法

基于需求的设计方法

这里回顾一下测试和开发工作的展开依据：

测试⼈员接到需求之后，要对需求进⾏分析和验证，从合理的需求中进⼀步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试⽤例。

以该注册邮箱账号需求为例，我们来设计测试⽤例。

这里依然还可以套用之前的万能公式进行举例：

不过关于兼容性这里，还补充一个数据兼容性，比如：

总结：

基于需求的测试方法大致分为以下几步：

1.明确需求功能点：账号注册，账号登录

2.结合万能公式的测试点：

具体的设计方法

这里又包括很多设计方法。

等价类

依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，
如果 这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达
到尽量多的 功能覆盖，解决了不能穷举测试的问题。

比如：账号的长度范围是 6 ~ 15，并且是闭区间 [6,15]。那么对于测试用例7 8 9 ...15其实是等价类。

其中，等价类又分类两类：

有效等价类：
对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验
证程序是否实现了规格说明中所规定的功能和性能

无效等价类：
根据需求说明书，不满⾜需求的集合。

根据等价类设计测试⽤例的⽅式：
1.确定有效等价类和⽆效等价类
2.编写测试⽤例，设计具体测试数据

缺点：等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。

边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。

边界值包含：边界值+次边界值

先看示例：

边界值就是给定返回的左数据和右数据。

而选额次边界值的时候，需要根据边界值的有效无效情况来定。

正交法

假设我们有n个选项，那么枚举所有的组合就是 2 ^ n。

假设现在有5个选项，姓名、电⼦邮箱、密码、确认密码、验证码，那么排列组合设计出来的用例数量就是32个。

正交法的⽬的是为了减少⽤例数⽬。⽤尽量少的⽤例覆盖输⼊的两两组合。

正交表的示例：

它表示需作9次实验，最多可观察4个因素，每个因素均为3水平。

这里的水平举个例子，在填写邮箱那里，我们可以选择填写和填写，那么我们就可以假设填写表示1，不填写表示0，那么就一共是两个水平。

这就是一个 L9(3 ^ 4) 的一个正交表。

关于正交表的性质：
每⼀列中，不同的数字（水平）出现的次数相等。
•
任意两列中数字的排列⽅式⻬全⽽且均衡

还是对于刚刚那个注册登录的测试，如果我们用排列组合的方式测试，那么需要测试32次，如果用设计正交表的方式，那么测试的数量会更少，同时还能保证高的覆盖率。

但是对于我们一个普通人来说，很难手动设计正交表。

一般通过allparis工具来帮助我们生成。

正交法设计测试用例的步骤：

1.找到因素和水平。

2.用allparis生成正交表：

a.将因素和水平写入⼊Excel表格中。

（这里建议使用Excel，因为allpairs对文本的格式要求很严格，WPS也行，因为我没钱，所以这里用WPS演示了）

如上图，我将因素 和水平都写在表格里了，然后将其复制，粘贴到paris的文件夹里的一个txt文件中，记得保存

然后通过cmd打开Windows的命令行，进入到这个目录中

然后这样运行：
这里的目标文件可以不用预先创建，并且建议不要预先创建，因为如果里面有数据的话会干扰结果。执行完命令后，如果什么提示都没有，则表示执行成功了。这里文件名的后缀必须是.txt。

可以看到，它这里就帮我们生成好一个正交表了。

一个是6个实验，也就是说，原来需要32个测试，现在只需要6个了。另外，这个~填写和~不填写表示的意思是：任意选择一个。

不过我们仔细观察一下这个正交表，发现它其实并没有严格遵守正交表的性质 ：
任意两列中数字的排列⽅式⻬全⽽且均衡
不过影响不是很大。

另外，虽说是6个测试用例，但是我们还需要对齐进行补全：

之前学了边界值的测试方法，我们发现，这里有全部填写的测试情况，但是并没有全部不填写的情况，这种情况需要我们自行进行补全。

判定表法

通过具体的⽅法能够将测试⽤例设计的更加完整和规范。
需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝
份；反之⽆管理员⾝份

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。
⽽正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。

判定表是⼀种表达逻辑判断的⼯具，形如：

根据判定表法设计测试用例的步骤：

1.确认需求中的输入和输出条件。

2.找出输入条件和输出条件之间的关系。

3.画判定表

4.根据判定表编写测试用例。

场景法

现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流

我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。
场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历
所有的基本流和备⽤流来完成整个场景。场景主要包括4种主要的类型：正常的⽤例场景，备选的
⽤例场景，异常的⽤例场景，假定推测的场景。

之前不是也介绍过基于需求的设计方法吗？同样对于登录注册的场景，也可以用场景法：

总结：

确认基本流和备用流后，编写测试用例：

另外我们要注意一个易错的地方，比如有这么一个场景：

假设现在是5月中旬，现在公司的这个产品有一个活动，那就是在5月会发放一个10块的优惠券，但是每个月的活动是不一样的，比如6月的优惠力度减小，变成5块了。那么对于这个需求的变更，我们需要今天测试，然后明天上线，那么对于这样的代码：
这样一改，乍一看没毛病，但是我们发现明明还在5月，但是5月的活动没了，这显然是不合理的。因此，新增加的代码应该对旧代码没有影响。

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽针对性地设计测试⽤例的⽅法。

这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。
错误推测法和⽬前流⾏的"探索式测试⽅法"的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产
出⽐很⾼，被⼴泛应⽤于测试

举例：

密码：是否加密，是否具备安全性。

获取用户输入：是否存在SQL注入的情况。

软件存在多个版本：那么多个版本都要测试。

关于测试一个项目的技巧（比如博客系统项目的测试）

更多的用例测试

命令行测试

比如对一个zip命令进行测试。

那么我们可以直接套用万能公式：
功能测试：对不同的⽂件类型进⾏测试
1）普通的txt⽂件能够⽣成zip⽂件
2）图⽚/视频/zip⽂件能够⽣成zip⽂件
3）多个⽂件能够⽣成zip⽂件（混合⽂件）
4）空⽂件夹可以⽣成zip⽂件
5）错误的命令是否可以解压（zip zip/没有写压缩包⽂件名称/没有源⽂件）

6）其他参数的测试

界⾯测试：
1）⽂件压缩成功命令⾏提⽰是否美观
2）⽂件压缩报错命令⾏提⽰是否友好

性能测试：
1）⽂件⼤⼩超过1G时⽂件是否可以压缩
2）⽂件⼤⼩超过1G时⽂件压缩消耗的时间是否在合理的时间范围内

兼容性测试：
1）zip⼯具可以在多系统上使⽤，如Windows、Linux、Mac

易⽤性测试：
1）zip命令有使⽤帮助教程，如zip --help命令下会展⽰如何使⽤

安全性：
1） 使⽤zip命令不会泄漏⽂件内容

接口测试

对一个网站，它有很多的请求方法，我们用开发者界面是无法进行接口测试的，我们可以用postman这个工具来帮助我们进行接口测试。

对于一个web程序，我们有以下的测试点：

不同的请求⽅式：
 1.以GET⽅式请求接⼝是否可以返回预期的响应数据
 2.以POST⽅式请求接⼝是否可以返回数据
 参数组合（如果接⼝需要拼参数的情况下）：
 1.空参数
 2.多参数
 3.少参数
 4.参数对应的值为空/过⻓/特殊字符....

 不同的参数格式：
 1.url拼参
 2.form-data格式
 3.raw格式等等
 接⼝性能：
 1.⼀千万个请求同时发起，是否能够返回响应
 2.并发情况下响应时间是否在⼤众接受范围内

以B站为例：

不过要先打开发者工具：

接着进入postman，然后我们可以先直接复制B站首页的域名，然后用postman简单的请求一次

这里可以看到我们用的是get方法，显示的结果也是B站的首页

如果将请求方法改为Post

很明显，B站就简短的回复了 方法不被允许。

测试完了get和post，我们还可以测试对请求参数的拼接：

另外我们还可以导入curl，postman会为我们生成一个一模一样的请求

最后再以CSDN为例，就以我的文章管理中心：
比如这个就是用的POST的方法。

复制curl的方法：

直接对着比如上面的logs右键，然后选择复制--复制为cURL(bash)。 然后在postman中导入

点击continue后：

再导入即可：
这样就将刚刚的cURL导入进来了。

其中在Headers里面有很多报头信息：

再找一些其它的，比如这个带了Cookie：

那我们就还可以验证这个网站是否对Cookie进行了身份校验，在postman中导入cURL后

此时我们就发现这里是带了Cookie信息的，我们先勾选上试试：

然后进行请求：

响应中说明是没问题的。

此时我们将Cookie去掉后：

发现就不行了，它提醒我们需要登录后再操作。