JSON操作符
在我们使用请求时,经常会遇到JSON格式的请求体,所以在介绍组件之前我会将介绍部分操作符,在进行操作时是很重要的
Operator |
Description |
$ |
表示根元素 |
@ |
当前元素 |
* |
通配符,所有节点 |
.. |
选择所有符合条件的节点 |
.name |
子元素,name是子元素名称 |
[start:end] |
数组切片操作符 |
[?(<expression>)] |
过滤器表达式,表达式要评估为布尔值 |
重要组件
在了解组件之前,我们要先了解,在JMeter中,元件的作用域以及执行顺序
作用域: 主要由测试计划的树形结构中的元件父子关系来确定
执行顺序:
取样器中的元件内组件不依赖其他元件就可以执行,所以取样器不存在作用问题
元件的作用域只对它的子节点有作用
其他作用域默认根据测试计划中树形结构来决定
所以对于当进行测试时,如果出现了问题,在检查完请求体以及各项信息之后还有问题,那就可以检查一下组件的顺序
线程组
用来控制JMeter中要用来执行测试的线程数,也可以把一个线程理解为一个测试用户
HTTP取样器
用来设置 http 请求
如果我们要满足中文,可以在内容编码出填写 utf-8
查看结果树
用来查看请求的结果以及请求和响应的详细信息
HTTP Cookie管理器
添加了 HTTP Cookie管理器 之后,就会自动存储并发送Cookie
可以像Web浏览器一样存储和发送Cookie,如果http请求中有Cookie,并会用来进行特定网址的请求
添加之后,就会自动获取cookie并添加入请求,并不需要额外的配置
HTTP 请求默认值
我们可以将所有请求的公共部分填在一起,之后进行每次请求的时候就会获取默认值
一般是填写: 协议、IP、端口号
继承这些默认值的请求就无需再填写对应的内容
用户定义的变量
有时我们只想在固定的场景下使用参数,并且改动后不希望影响其他的脚本
需要结合json操作符
使用方法: 在 HTTP 请求的取样器中引入定义的变量 ${参数名}
使用场景: 变量需要在多个脚本中使用,方便进行统一管理和修改,尤其是多个请求的变量都是同一变量时,就可以进行统一管理
JSON断言
接口发送请求成功,响应码为200(就是自己设置的请求成功的响应码)并不能完全代表接口请求成功,此时就需要关注接口响应数据是否符合预期
针对某一HTTP请求接口添加JSON断言
添加JSON配置: 和JSON提取器语法配置相同
具体设置:
不选 Additionally assert value ,表示添加断言值,只会用来判断字段是否存在,不会对字段的值进行匹配
选择 Additionally assert value ,表示必须添加 Expected Value 期望的断言值,如果此时没有勾选 Match as regular expression ,就会进行完整政正则匹配,即获得内容要和设置内容完全一致
如果选择 Additionally assert value ,并且选 Match as regular expression 正则匹配,则Expected Value 只需要填写部分关键词就行,类似于模糊查询
其中正则表达式需要我们进行了解,我将对一些常见的正则表达符号进行介绍
字符 |
描述 |
[……] |
匹配括号内的所有字符 |
[^……] |
匹配除了括号内的所有字符 |
[A-Z] |
匹配所有大写字母 |
[a-z] |
匹配所有小写字母 |
. |
匹配除换行符之外的任何单个字符 |
\s |
匹配所有空白符 |
\S |
匹配所有非空白符,不包括换行 |
\w |
匹配字母、字母、下划线 |
\d |
匹配任意一个阿拉伯数字 |
更多详细可以查看网页: https://www.runoob.com/regexp/regexp-syntax.html
JSON提取器
接口相应成功后,通过提取返回值对应的字段,可以用于其他接口的参数配置,尤其是 token
那我们要怎么获取对应信息呢?这里也要我们结合json操作符
假设以下是我的json字段
{
"code": 200,
"data": null,
"message": "æ\u0088\u0090å\u008A\u009F"
}
那么此时我要使用 code ,要怎么获取呢?
这里我们查询到了之后,就要去JSON提取器中设置了
配置完成之后,我们就要去 HTTP请求 中进行使用了
然后点击运行,我们就可以看到请求中带入了设置的JSON字段了
CSV数据文件设置 (CSV Data Set Config)
在实际使用中,对于一个接口,我们不可能一直只有一个用户会使用这个接口,更多时候是若干个用户同时使用,那么如果我们只测试一个账号,就会有很多问题无法完全体现,为了更加真实的模拟正常情况,我们就需要同时使用多个用户,这里就需要我们使用 数据文件设置了
在使用之前,我们先来了解这些配置
遇到文件结束符再次循环: 若选择为 true ,当数据不够时就会从头开始重新取; 若选择为 false ,就需要勾选后续的配置,遇到文件结束符就会停止线程(不勾选就会报错)
那么我们要怎么编写 csv文件 呢? 使用 Excel ,编写表格完成之后保存为 .csv 文件
修改配置
修改完之后,当我们发送请求,程序就可以从 csv文件 中获取参数(从上往下依次获取)
同时,因为我们添加了多组数据,我们就需要修改线程数,一个线程用来对应一组数据
只有这样才能保证每次获得的数组不一样
运行结果
同步定时器(集合点)
我们虽然定义了多个线程,但是我们怎么能保证他们是同一时间进行呢?怎么保证线程不是一个一个进行呢?
我们可以通过右上角的三角符号查看线程的运行顺序,这里还可以查看运行时间以及未完成的线程个数
如果我们要让这些线程同时运行,就需要使用同步定时器
在使用之前,我们也要来查看它的配置
需要注意的是: 模拟用户组的数量是不能超过线程组里配置的线程数
在实际运行中, 当进行等待的 进程数>=设置数 时,就直接发送请求,我们举个例子:
在等红绿灯的时候,如果规定一个路口最多能经过5个行人,但是实际情况确是,你不知道什么时候能够到达5个人,还很有可能在到达5个人的时候,同时还达到了6个人,此时已经达到了经过条件,那么也是可以通过路口的
所以 当配置的数量小于线程数时,最好把循环打开,避免最后一次状态为准备好的线程数量达不到进行并发的数量
事务控制器
主要是用来进行测试执行嵌套测试元素所花费的时间,用来模拟用户进行一系列操作的测试
可以更好的测试复杂环境
在没有添加事务控制器之前,一个接口就是一个事务
添加之后,就可以将多个接口放在一起表示一个业务
举例:
从这些测试结果中,我们要怎么来看具体性能怎么样呢?
指标 |
对应 |
说明 |
Sample |
样本数 |
发起的HTTP请求调用数 |
Average |
平均值 |
平均响应时间,单位为毫秒 |
Median |
中位数 |
请求调用响应时间的中间值,也就是50%请求调用的响应时间,单位为毫秒 |
90%Line |
90%百分位 |
90%请求调用的响应时间,单位为毫秒 |
95%Line |
95%百分位 |
95%请求调用的响应时间,单位为毫秒 |
99%Line |
99%百分位 |
99%请求调用的响应时间,单位为毫秒 |
Min |
最小值 |
请求调用的最小响应时间,单位为毫秒 |
Max |
最大值 |
请求调用的最大响应时间,单位为毫秒 |
Error% |
异常% |
调用失败的请求占比,调用失败一般指响应断言失败或者请求调用出错 |
Throughput |
吞吐量 |
TPS/QPS 每秒处理的事务数 |
KB/sec |
接收/发送 |
每秒网络传输的流量大小,单位为KB,这个指标是以网络传输的大小来衡量网络的吞吐量 |
插件
在真实情况下,我们经常需要一点一点的增加线程数,所以需要一些插件
在这之前,我们要为JMeter添加能够添加插件的功能
https://jmeter-plugins.org/install/Install/
下载完之后,放入 自己下载的JMeter文件下的lib/ext路径下 ,然后重启JMeter
重启之后,右上角就多了一个图标
点击,对以下常用插件进行下载
点击右下角下载,下载完成之后会自动重启
下载完成之后,就可以在线程和监听器中看到新的元件
Stepping Thread Group
让我们举一个例子
表示,总共有30个进程,从零开始,每一秒有5个进程做好准备,一组准备好之后,等三秒进行下一组准备,等线程数达到30之后,线程开始运行,并保持运行60秒就开始结束,一次结束5个线程,每隔1秒就会结束5个线程
Response Times Over Time
在测试过程中,它可以帮助测试人员观察并分析响应时间的实时平均值以及整体响应时间的走向。通过这一监听器,测试人员能够更直观地了解系统在不同时间点的响应性能,从而发现可能存在的性能问题或瓶颈。
横坐标通常代表运行时间,而纵坐标则代表响应时间(单位是毫秒)。测试人员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在大的波动。例如,如果响应时间在某个时间点突然增加,这可能意味着系统在该时间点遇到了性能问题。
Transactions per Second (TPS)
TPS监听器是一个用于分析系统吞吐量的重要工具。TPS,即每秒事务数,表示一个客户和向服务器发送请求后服务器做出反应的过程。这个指标反映了系统在同一时间内处理业务的最大能力。TPS值越高,说明系统的处理能力越强。
在使用TPS监听器时,横坐标通常代表运行时间,而纵坐标则代表TPS值。通过监听器展示的图表,可以清晰地看到TPS值随时间的变化情况。在图表中,红色通常表示通过的TPS,而绿色可能表示失败的TPS。这有助于我们快速识别系统性能的变化和瓶颈。
测试报告
JMeter的测试报告是一个非常详细的文档,它提供了测试执行结果的详细信息
我们需要在控制台使用对应指令来生成报告
jmeter -n -t 脚本文件名(加后缀) -l 日志文件名 -e -o 目录(被保存的地方)
-n : 无图形化运行(后台运行,不需要打开JMeter运行)
-t : 被运行的脚本
-l : 将运行信息写入日志文件,后缀必须要为 jtl 的日志文件
-e : 生成日志报告
-o : 指定报告的输出目录
注意: 日志文件和目录可以不存在,若为已经存在的情况下需要保证内容为空,否则会出现错误
打开 index.html ,就可以看到测试报告了