接口测试03-JMeter参数化-直连数据库-断言

1 JMeter参数化(重点)

1.1 概念

参数化: 动态的获取或设置数据

1.2 作用

程序较之于人工的优势:

高效率
安全 = (提高脚本的编写质量)
功能更强大 = 比如响应时间(以毫秒计)的判断

1.3 实现_概述

JMeter 中常见的参数化实现方案:

用户定义的变量
CSV 数据文件设置
用户参数
函数

四种参数化方案互为补充，各自都有各自的应用场景

1.3.1 用户定义的变量

需求:对学生管理系统执行增删改查相关操作时，资源路径不一定相同，但都是 /api/departments/ 开头（比如:查询所有学院信息的资源路径是 /api/departments/,修改学院信息的资源路径是 /api/departments/:ID/,根据 ID 删除指定学院信息的资源路径是 /api/departments/:ID/）。

每次都编写此路径前缀效率偏低且易出错,而又由于资源路径并不完全一致，又不可以使用 http 请求默认值封装，该怎样优化呢？

实现:

将被复用的数据提取并封装

组件添加

配置组件

　　2. 调用被封装的数据格式: ${变量名}

1.3.2 CSV数据文件设置(重点)

需求: 针对学生管理系统的新增接口做功能测试,通过新增接口提交多条测试数据

铺垫知识: CSV文件

CSV (逗号分隔值)文件，是程序中常见的一种数据存储格式

实现思想:

实现步骤:

编写新增脚本(注意: 提交的是 JSON 数据，请设置信息头管理器)
使用 CSV 文件存储测试用例
- 文件路径，非随意设置，和脚本平级，新建了目录，保存了文件(方便使用相对路径，保证脚本的可移植性)
- 文件编辑使用的 notepad++,设置编码集为 UTF-8 无 BOM 格式
核心:添加中间件关联脚本与文件

读 = 从 CSV 文件获取数据

写 = 将获取的数据导入到脚本

循环读写 = CSV 文件有多少行，就循环多少次(静态的设置循环次数，不建议使用)

1.3.3 用户参数

需求: 针对学生管理系统的新增接口做功能测试,通过新增接口提交多条测试数据

实现步骤:

编写新增脚本
封装测试数据(使用用户参数组件封装数据而非 CSV 文件)

3.关联数据与脚本

PS: CSV数据文件设置与用户参数比较

结论: 一般情况下，建议优先选择 CSV 数据文件设置

比较:

实现流程而言，用户参数更方便
不过, 用户参数较之于 CSV 有显著缺陷:
- 数据量较大时，数据设计不如 CSV 文件方便
- 执行效率，用户参数偏低(因为开启与循环次数对应的线程，而线程的创建、管理与维护比较耗费测试机资源)
建议: 数据量比较大，优先选择 CSV，如果数据量比较小，且每一条数据都对应一个用户，建议使用用户参数

1.3.4 函数(重点)

需求: 循环查询100次所有学院信息,在结果树中为请求结果添加标号

实现:

打开函数相关组件: 函数助手
- 方式1: 工具栏倒数第二个记事本图标
- 方式2: 菜单栏 ---> 选项 ---> 函数助手
- 方式3: Ctrl + Shift + F1
在函数助手中选择所需函数，并配置函数

3在脚本中调用函数

PS: Jmeter 常用函数

counter == 计数器

参数1: TRUE 每个线程单独一个计数器 FALSE 所有线程共用一个计数器
random == 随机数

参数1: 取值区间的最小值(包含)

参数2: 取值区间的最大值(包含)
time == 时间

无参: 获取时间戳

参数1: 将时间格式化 yyyy/MM/dd HH:mm:ss == 年/月/日时:分:秒

引言:为什么要学习直连数据库与断言

前面我们学习了参数化，通过参数化，可以动态的获取、设置或生成测试数据，可以帮我们提高测试脚本的编写效率和编写质量，这种以程序驱动代替人工驱动数据设计方案优势是显而易见的，推而广之，在整个接口测试流程中，除了测试数据的设计，响应结果的判断分析也是极为重要的一大环节实现，之前，我们都是人工判断响应结果的，比如手工查看验证码是否符合预期，手工访问数据库并与响应体的结果进行比对......显然的，该过程复杂且低效，那么如何优化呢？

JMeter也早早的帮我们考虑到了这些问题，并提供了相关解决方案，比如:可以通过直连数据库让程序代替人工访问数据库，可以使用断言让程序代替人工判断响应结果等等。二者的作用与参数化一致，都是以程序驱动代替人工驱动，可以提高测试效率和测试质量。

接下来，我们就系统性的学习一下直连数据库与断言吧。