文章目录
- 目录
- 1. JMeter介绍
- 1.1 安装JMeter
- 1.2 打开JMeter
- 1.3 JMeter基础配置
- 1.4 JMeter基本使用流程
- 1.5 JMeter元件作用域和执行顺序
- 2. 重点组件
- 2.1 线程组
- 2.2 HTTP取样器
- 2.3 查看结果树
- 2.4 HTTP请求默认值
- 2.5 JSON提取器
- 2.6 用户定义的变量
- 2.7 JSON断言
- 2.8 同步定时器(集合点)
- 2.9 事务控制器
- 2.10 常见监听器
- 2.10.1 聚合报告
- 2.10.2 Response Times Over Time
- 2.10.3 Transactions per Second(TPS)
- 2.11 CSV数据文件设置
- 2.12 HTTP Cookie管理器
- 2.13 Jmeter插件
- 2.13.1 Stepping Thread Group
- 3. 测试报告
- 4. 性能分析
- 4.1 响应时间
- 4.2 错误率(可靠性)
- 4.3 吞吐量
目录
- JMeter介绍
- 重点组件
- 测试报告
- 性能分析
1. JMeter介绍
环境要求:
Apache JMeter 是 Apache 组织基于 Java 开发的压力测试工具,用于对软件做性能测试
1.1 安装JMeter
下载tar包,解压即可:
解压完成后:
1.2 打开JMeter
方式一:点击bat文件
方式二:命令行启动(推荐)
step1:添加JMeter系统环境变量
step2:保存后打开命令行工具
输入命令jmeter即可启动JMeter工具
1.3 JMeter基础配置
修改字体为中文:
在jmeter的bin目录下,修改文件中的内容:language=zh_CN
1.4 JMeter基本使用流程
补充:
- 两个最常用的按钮
- 运行前需要保存
- 启动JMeter
- 在“测试计划”下添加“线程组”
- 在“线程组”下添加“HTTP”取样器
- 填写“HTTP请求”的相关请求数据
- 在“线程组”下添加“查看结果树”监听器
- 点击“启动”按钮运行,查看接口测试结果
1.5 JMeter元件作用域和执行顺序
在JMeter中,元件的作用域和执行顺序是非常重要的概念。
作用域:
JMeter元件的作用域主要由测试计划的树形结构中的元件父子关系来确定。
执行顺序:
取样器(sampler)元件内组件不依赖其他元件就可执行,因此取样器不存在作用问题,元件作用域只对它的子节点有作用,其他作用域默认根据测试计划中树形结构来定。
2. 重点组件
2.1 线程组
控制JMeter将用于执行测试的线程数,也可以把一个线程理解为一个测试用户。
2.2 HTTP取样器
2.3 查看结果树
注:
2.4 HTTP请求默认值
补充:
博客中涉及到的接口协议、IP、端口号全都一样,可以单独抽取出来存放在默认值中,其他接口就可以省略不写协议、IP、端口号。
补充:
在测试博客列表页时,当我们像博客登录接口一样,填写了协议、IP、端口号、请求方法、路径之后,会发现接口会报错,是因为我们没有在请求头中添加登录凭证。(因为只有登录状态下才能查看博客列表页)
在Postman中加上之后是这样的:
在Jmeter中:
但是我们现在给的登录凭证是配置死的(会过期,或者换成其他用户登录就不行了),我们应该要给登录接口返回的data值,接下来我们就来介绍如何实现。
2.5 JSON提取器
接口响应成功,通过提取返回值对应字段,可用于其他接口的参数配置
- 添加JSON提取器
JSON操作符参考:
- 添加JSON配置
- 配置json提取的参数
2.6 用户定义的变量
添加方式:线程组 — 配置元件 — 用户定义的变量
补充:
我们在测试发布博客接口时会遇到下面的问题:
2.7 JSON断言
接口发送请求成功,响应码为200并不能完全代表接口请求成功,我们更多需要关注接口响应数据是否符合预期。
- 添加JSON断言
- 添加JSON配置
注意:
- 若不选Additionally assert value,表示添加断言值,则可用来判断字段是否存在
- 选择Additionally assert value,则必须添加Expected Value期望的断言值(精确匹配,区分大小写)
- 若不选Match as regular expression正则匹配,则Expected Value必须填写完整,少一个字符都会导致断言失败
- 若选择Match as regular expression正则匹配,则Expected Value可以仅写上部分关键词即可断言成功
2.8 同步定时器(集合点)
为了解决这个问题,达到并发的效果,我们可以添加同步计时器:
JMeter同步定时器的作用主要在于模拟多用户并发访问的场景,确保多个线程能够同时执行某个操作,以达到真正的并发效果。
当多个线程同时启动时,它们可能会在不同的时间间隔内执行,这样就无法达到真正的并发效果。同步定时器的作用就是将这些线程的执行时间同步,使它们在同一时间点执行。它可以在多个线程之间制造一定的延迟,直到同时到达指定时间点,再同时执行后续的操作。
此外,同步定时器可以理解为集合点,当线程数量达到指定值后,再一起释放,可以瞬间产生很大的压力。这样,可以更好地模拟真实的用户并发访问场景,提高测试的准确性和可靠性。
在性能测试过程中,为了真实模拟多个用户同时进行操作以度量服务器的处理能力,可以使用同步定时器来设置集合点。不过,虽然通过加入集合点可以约束请求同时发送,但不能确保请求同时到达服务器,所以只能说是较真实模拟并发。
注:
2.9 事务控制器
JMeter事务控制器的作用主要用于测试执行嵌套测试元素所花费的总时间,这相当于模拟用户进行一系列操作的测试。
在进行页面性能测试或API性能测试时,事务控制器是一个非常重要的工具。它可以帮助测试人员更准确地评估系统性能,尤其是在涉及多个接口或操作的复杂场景中。例如,在订单提交的过程中,可能需要调用多个接口,并且某些接口可能依赖于前一个接口的结果。在这种情况下,使用事务控制器可以将这些接口统一视为一个事务进行性能测试,从而得到更接近真实场景的性能测试结果。
若不添加事务控制器,则一个接口即一个事务。
添加了事务控制器后,可以将多个接口统一放到一个事务控制器下作为一个事务。
2.10 常见监听器
2.10.1 聚合报告
从聚合报告可以看到性能测试过程中整体的数据变化。
2.10.2 Response Times Over Time
建议看完下面的监听器插件后再看这里。
Response Times Over Time主要用于监听整个事务运行期间的响应时间。在测试过程中,它可以帮助测试人员观察并分析响应时间的实时平均值以及整体响应时间的走向。通过这一监听器,测试人员能够更直观地了解系统在不同时间点的响应性能,从而发现可能存在的性能问题或瓶颈。
Response Times Over Time的图形展示中,横坐标通常代表运行时间,而纵坐标则代表响应时间(单位是毫秒)。测试人员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在大的波动。例如,如果响应时间在某个时间点突然增加,这可能意味着系统在该时间点遇到了性能问题。
2.10.3 Transactions per Second(TPS)
建议看完下面的监听器插件后再看这里。
JMeter中的 Transactions per Second(TPS)监听器是一个用于分析系统吞吐量的重要工具。TPS,即每秒事务数,表示一个客户机向服务器发送请求后服务器做出反应的过程。这个指标反映了系统在同一时间内处理业务的最大能力。TPS值越高,说明系统的处理能力越强。
在使用TPS监听器时,横坐标通常代表运行时间,而纵坐标则代表TPS值。通过监听器展示的图表,可以清晰地看到TPS值随时间的变化情况。
2.11 CSV数据文件设置
以登陆接口为例,当我们执行登陆接口的性能测试时,手动配置了用户名和密码为固定的username和password,然而实际使用中不可能只有一个用户登陆,为了模拟更真实的登录环境,我们需要提供更多的用户username和password来实现登录操作。
添加方式:线程组⸺配置元件⸺CSV数据文件设置
操作步骤:
- CSV数据文件设置
- 文件名:填写csv文件的路径,建议使用绝对路径
- 文件编码:UTF-8
- 变量名称:从csv数据文件中读起的数据需要保存到的变量名,有多个变量时用逗号分隔
- 是否忽略首行:是否从csv数据文件第一行开始读取
- 分隔符:要求与csv数据文件中多列的分隔符一致
- 遇到文件结束符再次循环:若选择为True当数据不够的时候会从头取;若选择False,则需要勾选下面的配置,遇到文件结束符停止线程,这里如果不勾选,请求将会报错
- 编写test.csv文件,示例:
- 修改登陆接口及其他涉及到username和password获取的参数
修改完该配置后,登陆接口发起请求时将从csv文件中获取配置好的username和password参数,获取顺序为从上往下依次获取
- 修改线程组中线程数,使得每次取到的username和password都不一样
- 运行结果
2.12 HTTP Cookie管理器
HTTP Cookie管理器像Web浏览器一样存储和发送Cookie。如果HTTP请求并且响应包含cookie,则Cookie管理器会自动存储该cookie,并将其用于将来对该特定网站的所有请求。每个JMeter线程都有自己的“cookie存储区”。因此,正在测试使用cookie存储会话信息的网站,则每个JMeter线程都将拥有自己的会话,此类Cookie不会显示在Cookie管理器显示屏上,可以使用“查看结果树监听器”查看。
缓存配置可选择standard(标准)或compatibility(兼容的),当然也可以手工添加一些cookie。
2.13 Jmeter插件
下载Jmeter插件功能:
将下载好的插件放到jmeter下lib/ext文件夹下:
此时,jmeter界面右上角将会展示一个小蝴蝶形状的工具,该工具即jmeter插件功能,点击该功能可以下载jmeter中支持的各种插件:
在真实企业压测场景中,我们通常为一点一点的逐步增加线程数,因此需要安装新的插件来支持线程数的配置。
通过插件管理工具下载其他插件:
- 在插件中下载其他监听器插件
- 在插件中下载线程组插件
点击Apply Changes and Restart JMeter等待下载完成并重启JMeter:
下载完成后再线程和监听器中可以看到新增的元件:
2.13.1 Stepping Thread Group
梯度压测线程组
- This group will start:启动多少个线程,同线程组中的线程数
- First, wait for:等待多少秒才开始压测,一般默认为0
- Then start:一开始有多少个线程数,一般默认为0
- Next,add:下一次增加多少个线程数
- threads every:当前运行多长时间后再次启动线程,即每一次线程启动完成之后的的持续时间
- using ramp-up:启动线程的时间;若设置为5秒,表示每次启动线程都持续5秒
- then hold load for:线程全部启动完之后持续运行多长时间
- finally,stop / threads every:多长时间释放多少个线程;若设置为5个和1秒,表示持续负载结束之后每1秒钟释放5个线程
3. 测试报告
JMeter测试报告是一个全面而详细的文档,它提供了关于测试执行结果的详细信息,帮助用户全面评估系统的性能并进行性能优化。
生成性能测试报告的命令:
Jmeter -n -t 脚本文件 -l 日志文件 -e -o 目录
-n : 无图形化运行
-t : 被运行的脚本
-l : 将运行信息写入日志文件,后缀为jtl的日志文件
-e : 生成测试报告
-o : 指定报告输出目录
注意: 日志文件和目录可以不存在,若为已经存在的情况下需要保证内容为空,否则会出现错误!
正确演示示例:
性能测试报告生成成功后,在rizhi文件夹下将出现以下内容:
双击index.html文件,界面展示如下:
4. 性能分析
通过三大指标来分析性能问题
4.1 响应时间
如果响应时间超过了要求,代表系统到了瓶颈
注意事项:分析在多少线程的情况下发生了超标
响应时间变化的原因:
系统不稳定,有时快有时慢
随着并发压力变大而慢慢变慢,响应时间变高
4.2 错误率(可靠性)
⾼并发场景下,系统是否能够正常处理业务
要求:99.99% 可靠:99.9999%
错误率高的原因:
接口请求错误
服务器无法继续处理,达到了瓶颈(代码写的不好,内存泄漏、硬件资源等)
后端系统限流(系统里配置了不能超过多少并发)、熔断、降级
什么是熔断、降级?
熔断:防止系统因某个服务的故障而整体崩溃。当电商平台上用户支付时,收银台发现某个支付渠道,如微信支付失败率突增,超时严重,那么就可以临时把这个支付方式熔断掉
降级:主动关闭一些非核心功能,以确保核心功能的正常运行。某次腾讯视频挂了的时候,用户名称默认显示腾讯用户,这也是一种降级方式,用兜底名称做展示
4.3 吞吐量
吞吐量越大,性能越好;吞吐量相对稳定或者变低,可能系统达到了性能瓶颈
吞吐量变化规律:
波动很大:代表系统性能不稳定
慢慢变高,再趋于稳定:和并发量强相关。如果并发量小于吞吐量,慢慢增大并发量,吞吐量也会随之增加
慢慢变低,并发量也减少了:要么说明性能测试要结束了,并发减少;也可能是系统变的卡顿,从而导致响应时间变慢,导致单个线程发起的并发量变少