【测试开发】用例篇（2）

1. 正交表法

1.1 什么是正交表

最简单的正交表是L⁴(2³)，含意如下：

1. “L”代表正交表
2. L角的指数“4”表示有 4 横行，简称行，即要做四次试验
3. 括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个
4. 括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2（每一个变量的取值只有两种）

正交表的特点是其安排的试验方法具有均衡搭配特性。

1.2 两个重要概念

因素：输入的变量

水平：每一个输入变量（因素）的取值

以下是一个正交表：

正交表的两条性质：

1. 每一列中各数字出现的次数都一样多
2. 如何两列中各有序数对出现的次数一样多

以此正交表为例：

对于第一条：

1. 1出现的频次是12
2. 2出现的频次是12
3. 3出现的频次是12

第一条每一列：

1. 1出现3次
2. 2出现3次
3. 3出现3次

对于第二条：

• 可用第一条推出

1.3 如何通过正交表设计测试用例

1. 充分理解需求
2. 确定因素、确定水平
3. 画正交表
4. 补充正交表
5. 将正交表转换成测试用例

1.3.1 充分理解需求

针对一个注册案例进行设计测试用例：姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册

1.3.2 确定因素、确定水平

因素：

1. 姓名
2. 邮箱
3. 密码
4. 确认密码
5. 验证码

水平：

1. 填写
2. 不填写

1.3.3 allpairs画正交表

1. 将因素和水平放在Excel表格中

2. 在allpairs的安装路径下创建一个文本文件：

• 请自行下载安装allpairs
  

3. 复制粘贴刚才的表格
   

4. 通过命令行生成正交表

5. 查看生成的正交表

6. 在Excel表中查看（复制粘贴）

• pairings等等东西目前不需要注意
• ~填写的意思是，可以是填写也可以是不填写，但是要保证正交表的那个特性！

例如：

1.3.4 补充正交表

比如补充一条测试用例，全部都不填写的情况

补充正交表，不需要保证仍是正交表，补充的例子是我们人为写的，特别关注的测试用例~

1.3.5 将正交表转换成测试用例

当然，在这里，我们的两个水平是两个分类，所以这更像是在划分测试点，因为它没全包含测试用例的几个要素：

• 所以要进行补充测试要素

正交表在测试用例设计中有重要的意义

• 它是一种有效的测试用例设计技术，可以帮助测试人员在有限的资源和时间下，优化测试覆盖率，发现更多的缺陷。

正交表的科学依据源于统计学的设计理论

• 它可以通过有效的组合和排列，提供一组最小的测试用例
• 同时覆盖了系统中可能存在的多个独立因素或因素组合

通过使用正交表，测试人员可以在较少的测试用例数量下，覆盖更多的场景，减少测试的工作量和时间成本

2. 场景设计法

2.1 场景

针对用户使用软件的一系列操作，形成的一个场景

• 例如点外卖：想吃什么类型的 => 想吃哪个商家 => 想吃哪道菜 => 选择菜品指标 => 填写地址和联系方式 => 备注+支付 => 提交订单 => 商家接单 => 商家出单 => 骑手接单 => 骑手送货 => 用户收到外卖 => 用户评论

而按照这条路线，如果每个环节都没出现啥问题，是可以进行完毕的，这就是“主事件流”

• 其中几个环节是可能出现问题的

• 如没有这个类型的餐厅、商家未营业、此菜售空/下架、地点不配送、钱不够…

• 而这种只进行主事件流部分就“宣告失败”的，称为“次事件流”

2.2 如何通过这个方法设计测试用例

1. 充分理解需求
2. 确定主事件流
3. 确定次事件流
4. 每一个事件流就是一个测试用例

2.2.1 充分理解需求

以ATM取款场景为例

2.2.2 确定主事件流

1. 插卡
   ↓
   
2. 输入密码
   ↓
   
3. 选择业务
   ↓
   
4. 选择金额
   ↓
   
5. 出钞
   ↓
   
6. 取卡
   

2.2.2 确定次事件流

各个环节可能出现的问题：

主事件流：

次事件流：

2.2.3 一个事件流就是一个测试用例

对于每个事件流，补充测试要素即可~

3. 错误猜测法

依据测试人员经验（根据遇到过的错误，进行合理猜测）

所以没啥可讲的，重点在多看多练多实践…

常见的有：

• 注册：

1. 校验特殊字符（例如空格）的处理
2. 密码校验的大小写
3. 姓名中的特殊字符
4. 密码发送是否明文
5. …

4. 常见案例练习

4.1 用FIddler代理来模拟弱网

打开速度影响，根据用户相关规则，影响网络条件：

查看用户相关规则：

出现一个脚本：

ctrl + f 查找：

找到这个设置相关代码：

1. 传输1KB花费时间300ms
2. 下载1KB花费时间150ms

• 这个数值设置得越大，网络越差越弱

4.2 接口测试

这里的接口就是前后端交互的接口，不是我们的接口类，但是本质上就是一个名词，差不多就那个意思，接口其实就是一些方法的集合罢了，而在此处，接口就是前后端交互的通道，而接口测试，其实就是模拟前端发送请求走这个通道给后端~

所以，就需要我们的一个软件=> Postman，其使用不再赘述

• 参考此博文的2.5：【JavaEE】HTTP状态码-HTTP数据报的构造_s:103的博客-CSDN博客

可以结合fiddler/浏览器进行抓包，找到接口，复制url，通过Postman构造请求进行发送

• 请求的内容也可以仿造已有的包，结合实际测试内容去构造
• fiddler在进行其他测试的时候，注意关闭弱网

个人比较习惯用fiddler的Raw，用记事本去看，这样可以一眼看全部，当然如果对http请求和响应还不是很熟练，可以看看浏览器和fiddler其他的一些按钮，可以可视化的看到一些信息，自行研究！

对于复制请求，在postman上粘贴，我建议使用浏览器：

• 需要刷新，然后在这里看到接口

在postman进行import：

粘贴：

点击send，就相当于向该接口发起了一次请求

针对参数进行测试（传递所有参数、传递部分参数、不传递参数、传递其他的参数、改变参数的值…）

• 你可以试一下对自己的网站的注册功能进行测试，比如空用户名/空昵称进行注册，看看是否注册成功~

针对性能进行测试

• 后面讲解性能测试的时候再细说

4.3 对冒泡排序进行测试

这里是一类问题，就是对代码的测试，涉及白盒测试，于进阶篇讲解！

4.4 Linux的zip命令

4.4.1 功能测试

1. 压缩的是一个目录，或者是一个文件

对test目录进行压缩：

zip使用手册：

对111.txt文件进行压缩：

对nohup.out进行压缩

• 对于nohup.out文件的介绍：nohup.out是什么文件?nohup.out如何写?_一棵小白菜#的博客-CSDN博客

4.4.2 界面测试

• 其实这就是界面，只不过是在命令行显示~

压缩信息要提示正确！

4.4.3 性能

对于5G网络条件下和压缩1KB大小的目录/文件，性能怎么样！

4.4.4 安全

压缩完文件，下一次解压文件不能损坏！

4.4.5 可视化压缩工具测试用例设计

跟上面的测试点一致，只不过现在是用户能看到的可视化页面了~

• 针对这些测试点，结合我们的测试用例设计方法，去设计测试用例即可~

4.5 水杯测试用例设计（水杯是一个实体）

这是一道测试实体题

水杯是真水杯，不是啥专业名词

列出万能公式：

一些测试点可能适合在不同的划分里，不要太刻意去区分，这里不需要太严格！

• 写测试点，是没有标准答案的！合理发挥即可，不要太大压力！
• 可能我没想到的你想到了，由你进一步发挥！

补充测试点：

4.6 微信发送朋友圈设计测试用例（软件的一个模块）

这是一道测试软件模块题

列出万能公式：

• 如果这个划分不够全面，再进行补充~

对于xss漏洞，就是web中嵌入了恶意脚本代码，导致脚本语言被执行，文本不显示等等的问题…

• 不是重点，不做赘述，参照博文：什么是XSS漏洞—漏洞原理学习_xss漏洞原理_Ping_Pig的博客-CSDN博客