软件测试-性能测试⼯具篇(沉淀中)
文章目录
- 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 Cookie管理器
- 2.5 HTTP请求默认值
- 2.6 ⽤⼾定义的变量
- 2.7 CSV数据⽂件设置
- 2.7.1 操作步骤
- 2.8 JSON提取器
- 2.9 JSON断⾔
- 2.10 同步定时器(集合点)
- 2.11 事务控制器
- 2.12 Jmeter插件
- 2.12.1 Stepping Thread Group
- 2.13 常⻅监听器
- 2.13.1 聚合报告
- 2.13.2 Response Times Over Time
- 2.13.3 Transactions per Second(TPS)
- 3. 测试报告
- 4. 性能分析
- 4.1 响应时间
- 4.2 错误率(可靠性)
- 4.3 吞吐量
- 总结
1. JMeter介绍
环境要求:
Apache JMeter 是 Apache 组织基于 Java 开发的压⼒测试⼯具,⽤于对软件做性能测试
1.1 安装JMeter
1.下载tar包,解压即可。
解压完成后:
1.2 打开JMeter
⽅式⼀:点击bat⽂件
⽅式⼆:命令⾏启动(推荐)
step1:添加JMeter系统环境变量
step2:保存后打开命令⾏⼯具
输⼊命令jmeter即可启动JMeter⼯具
1.3 JMeter基础配置
• 修改字体为中⽂
在jmeter的bin⽬录下,修改⽂件中的内容:language=zh_CN
1.4 JMeter基本使⽤流程
1)启动JMeter
2)在“测试计划”下添加“线程组
3)在“线程组”下添加“HTTP”取样器
4)在“线程组”下添加“查看结果树”监听器
5)点击“启动”按钮运⾏,查看接⼝测试结果
1.5 JMeter元件作⽤域和执⾏顺序
在JMeter中,元件的作⽤域和执⾏顺序是⾮常重要的概念。
作⽤域:
JMeter元件的作⽤域主要由测试计划的树形结构中的元件⽗⼦关系来确定。
执⾏顺序:
取样器(sampler)元件内组件不依赖其他元件就可执⾏,因此取样器不存在作⽤问题
元件作⽤域只对它的⼦节点有作⽤,
其他作⽤域默认根据测试计划中树形结构来定;
2. 重点组件
2.1 线程组
控制JMeter将⽤于执⾏测试的线程数,也可以把⼀个线程理解为⼀个测试⽤⼾。
线程数:⼀个线程即⼀个测试⽤⼾,设置发送的请求次数
Ramp-up时间(秒):设置性能测试运⾏时间,单位为秒
循环次数:
◦ 配置指定次数:控制脚本循环执⾏的次数
◦ 配置循环永远
▪ 需要调度器配置使⽤
▪ 运⾏时间:脚本执⾏时间
▪ 延迟启动时间:脚本等待指定时间才能运⾏
2.2 HTTP取样器
添加必需的配置:
http协议
http主机名/IP
端⼝
◦ http协议端⼝号80
◦ https端⼝号443
请求⽅法
路径(⽬录+参数)
内容编码(默认的ISO国际标准,但对中⽂⽀持不友好,可以使⽤utf-8)
参数
◦ 参数可以拼在路径⾥,也可以卸载参数中
◦ POST参数要放到消息体数据中{wd:test}
2.3 查看结果树
取样器结果:统计请求相关的信息
1 Thread Name:线程组名称
Thread Name:线程组名称
Sample time:发送请求时间
load time:响应时间
Response code :接⼝响应状态码
请求:HTTP请求的请求头和请求体的详细信息
响应:HTTP响应的响应头和响应体的详细信息
2.4 HTTP Cookie管理器
HTTP Cookie管理器像Web浏览器⼀样存储和发送Cookie。如果HTTP请求并且响应包含cookie,则Cookie管理器会⾃动存储该cookie,并将其⽤于将来对该特定⽹站的所有请求。每个JMeter线程都有⾃⼰的"cookie存储区"。因此,正在测试使⽤cookie存储会话信息的⽹站,则每个JMeter线程都将拥有⾃⼰的会话。此类Cookie不会显⽰在Cookie管理器显⽰屏上,可以使⽤"查看结果树监听器"查看。
缓存配置可选择standard(标准)或compatibility(兼容的),当然也可以⼿⼯添加⼀些cookie.
添加了HTTP Cookie管理器后,会⾃动存储并发送Cookie
2.5 HTTP请求默认值
博客中涉及到的接⼝协议、IP、端⼝号全都⼀样,可以单独抽取出来存放在默认值中,其他接⼝就可以省略不写协议、IP、端⼝号
2.6 ⽤⼾定义的变量
添加⽅式:线程组—配置元件—⽤⼾定义的变量
有时我们只想要在固定的场景⾥使⽤参数化,改动后不希望影响到其他的脚本。
使⽤:在HTTP请求的取样器中引⼊定义的变量。${参数名}
适⽤场景:变量需要在多个脚本中使⽤,⽅⾯统⼀管理和修改
2.7 CSV数据⽂件设置
以登陆接⼝为例,当我们执⾏登陆接⼝的性能测试时,⼿动配置了⽤⼾名和密码为固定的username和password,然⽽实际使⽤中不可能只有⼀个⽤⼾登陆,为了模拟更真实的登录环境,我们需要提供更多的⽤⼾username和password来实现登录操作
添加⽅式:线程组⸺配置元件⸺CSV数据⽂件设置
2.7.1 操作步骤
1)CSV数据⽂件设置
• ⽂件名:填写csv⽂件的路径。建议使⽤绝对路径。
• ⽂件编码:UTF-8
• 变量名称:从csv数据⽂件中读起的数据需要保存到的变量名。有多个变量时⽤逗号分隔
• 是否忽略⾸⾏:是否从csv数据⽂件第⼀⾏开始读取。
• 分隔符:要求与csv数据⽂件中多列的分隔符⼀致
• 遇到⽂件结束符再次循环:若选择为True当数据不够的时候会从头取。若选择False,则需要勾选
下⾯的配置,遇到⽂件结束符停⽌线程,这⾥如果不勾选,请求将会报错。
2)编写test.csv⽂件,⽰例:
3)修改登陆接⼝及其他涉及到username和password获取的参数
修改完该配置后,登陆接⼝发起请求时将从csv⽂件中获取配置好的username和password参数,获取顺序为从上往下依次获取
4)修改线程组中线程数,使得每次取到的username和password都不⼀样
5)运⾏结果
2.8 JSON提取器
接⼝响应成功,通过提取返回值对应字段,可⽤于其他接⼝的参数配置
1)添加JSON提取器
针对某⼀个HTTP请求接⼝添加JSON提取器
案例:以博客⾸⻚为例
[
{
"postTime": "2024-04-18 05:20:16",
"title": "ddddd",
"blogId": 13,
"userId": 3,
"content": "# 在这⾥写下⼀篇博客\r\ndddd"
},
{
"postTime": "2022-10-22 02:38:21",
"title": "今天学习了吗",
"blogId": 12,
"userId": 3,
"content": "今天是2022年10⽉22⽇17:42分,为了..."
}
]
JSON操作符参考:
英文
转汉语
Operator | Description |
---|---|
$ | 表⽰根元素 |
@ | 当前元素 |
* | 通配符。所有节点 |
… | 选择所有符合条件的节点 |
. | ⼦元素 |
[‘’ (, ‘’)] | 括号表示子元素或子元素列表 |
[ (, )] | 数组索引或索引列表 |
[start:end] | 数组切片操作符 |
[?()] | 过滤器表达式。表达式必须评估为布尔值。 |
参考⽂档:https://github.com/json-path/JsonPath/tree/master/json-path
获取相应中的所有blogId元素:..blogId获取第⼀个blogId元素:..blogId 获取第⼀个blogId元素:..blogId获取第⼀个blogId元素:.[0]blogId
2)添加JSON配置
3)配置json提取的参数
运⾏脚本后,所有的查看博客内容接⼝对应的blogId统⼀替换为12:
2.9 JSON断⾔
接⼝发送请求成功,响应码为200并不能完全代表接⼝请求成功,我们更多需要关注接⼝响应数据是否
符合预期。
1)添加JSON断⾔
针对某⼀个HTTP请求接⼝添加JSON断⾔
2)添加JSON配置
同JSON提取器语法配置
注意:
1)若不选Additionally assert value,表⽰添加断⾔值,则可⽤来判断字段是否存在
2)选择Additionally assert value,则必须添加Expected Value期望的断⾔值 (精确匹配,区分大小写)
3)若不选Match as regular expression正则匹配,则Expected Value必须填写完整,少⼀个字符都
会导致断⾔失败
4)若选择Match as regular expression正则匹配,则Expected Value可以仅写上部分关键词即可断
⾔成功
2.10 同步定时器(集合点)
为了达到并发的效果,需要添加同步定时器
Meter同步定时器的作⽤主要在于模拟多⽤⼾并发访问的场景,确保多个线程能够同时执⾏某个操作,以达到真正的并发效果。
当多个线程同时启动时,它们可能会在不同的时间间隔内执⾏,这样就⽆法达到真正的并发效果。同步定时器的作⽤就是将这些线程的执⾏时间同步,使它们在同⼀时间点执⾏。它可以在多个线程之间制造⼀定的延迟,直到同时到达指定时间点,再同时执⾏后续的操作。
此外,同步定时器可以理解为集合点,当线程数量达到指定值后,再⼀起释放,可以瞬间产⽣很⼤的压⼒。这样,可以更好地模拟真实的⽤⼾并发访问场景,提⾼测试的准确性和可靠性。
在性能测试过程中,为了真实模拟多个⽤⼾同时进⾏操作以度量服务器的处理能⼒,可以使⽤同步定时器来设置集合点。不过,虽然通过加⼊集合点可以约束请求同时发送,但不能确保请求同时到达服务器,所以只能说是较真实模拟并发
现实⽣活中,红绿灯就相当于⼀个集合点,有⼈先到达,有⼈后达到,但必须等到绿灯后所有⼈才能
开始过⼈⾏道。
2.11 事务控制器
JMeter事务控制器的作⽤主要⽤于测试执⾏嵌套测试元素所花费的总时间。这相当于模拟⽤⼾进⾏⼀系列操作的测试。
在进⾏⻚⾯性能测试或API性能测试时,事务控制器是⼀个⾮常重要的⼯具。它可以帮助测试⼈员更准确地评估系统性能,尤其是在涉及多个接⼝或操作的复杂场景中。例如,在订单提交的过程中,可能需要调⽤多个接⼝,并且某些接⼝可能依赖于前⼀个接⼝的结果。在这种情况下,使⽤事务控制器可以将这些接⼝统⼀视为⼀个事务进⾏性能测试,从⽽得到更接近真实场景的性能测试结果
若不添加事务控制器,则⼀个接⼝即⼀个事务。
添加了事务控制器后,可以将多个接⼝统⼀放到⼀个事务控制器下作为⼀个事务。
2.12 Jmeter插件
下载Jmeter插件功能:
https://jmeter-plugins.org/install/Install/
将下载好的插件放到jmeter下lib/ext⽂件夹下:
此时,jmeter界⾯右上⻆将会展⽰⼀个⼩蝴蝶形状的⼯具,该⼯具即jmeter插件功能,点击该功能可以下载jmeter中⽀持的各种插件:
在真实企业压测场景中,我们通常为⼀点⼀点的逐步增加线程数,因此需要安装新的插件来⽀持线程
数的配置。
通过插件管理⼯具下载其他插件:
1)在插件中下载其他监听器插件
2)在插件中下载线程组插件
点击Apply Changes and Restart JMeter等待下载完成并重启JMeter:
下载完成后再线程和监听器中可以看到新增的元件:
2.12.1 Stepping Thread Group
梯度压测线程组
This group will start:启动多少个线程,同线程组中的线程数
First, wait for:等待多少秒才开始压测,⼀般默认为0
Then start:⼀开始有多少个线程数,⼀般默认为0
Next,add:下⼀次增加多少个线程数
threads every:当前运⾏多⻓时间后再次启动线程,即每⼀次线程启动完成之后的的持续时间;
using ramp-up:启动线程的时间;若设置为5秒,表⽰每次启动线程都持续5秒
thenhold loadfor:线程全部启动完之后持续运⾏多⻓时间
finally,stop/threadsevery:多⻓时间释放多少个线程;若设置为5个和1秒,表⽰持续负载结束之后
每1秒钟释放5个线程
2.13 常⻅监听器
2.13.1 聚合报告
从聚合报告可以看到性能测试过程中整体的数据变化
2.13.2 Response Times Over Time
Response Times Over Time主要⽤于监听整个事务运⾏期间的响应时间。在测试过程中,它可以帮助
测试⼈员观察并分析响应时间的实时平均值以及整体响应时间的⾛向。通过这⼀监听器,测试⼈员能
够更直观地了解系统在不同时间点的响应性能,从⽽发现可能存在的性能问题或瓶颈。
Response Times Over Time的图形展⽰中,横坐标通常代表运⾏时间,⽽纵坐标则代表响应时间(单位是毫秒)。测试⼈员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在⼤的波动。例如,如果响应时间在某个时间点突然增加,这可能意味着系统在该时间点遇到了性能问题。
2.13.3 Transactions per Second(TPS)
JMeter中的Transactions per Second(TPS)监听器是⼀个⽤于分析系统吞吐量的重要⼯具。TPS,即每秒事务数,表⽰⼀个客⼾机向服务器发送请求后服务器做出反应的过程。这个指标反映了系统在同⼀时间内处理业务的最⼤能⼒。TPS值越⾼,说明系统的处理能⼒越强。
在使⽤TPS监听器时,横坐标通常代表运⾏时间,⽽纵坐标则代表TPS值。通过监听器展⽰的图表,可以清晰地看到TPS值随时间的变化情况。在图表中,红⾊通常表⽰通过的TPS,⽽绿⾊可能表⽰失败的TPS。这有助于我们快速识别系统性能的变化和瓶颈。
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个9-----100000只能出现一次错误
军事系统,要求可靠性达到5个9-----1000000只能出现一次错误。
错误率⾼的原因:
接⼝请求错误
服务器⽆法继续处理,达到了瓶颈(代码写的不好,内存泄漏、硬件资源等)
后端系统限流(系统⾥配置了不能超过多少并发)、熔断、降级
什么是熔断、降级?
熔断:防⽌系统因某个服务的故障⽽整体崩溃。当电商平台上⽤⼾⽀付时,收银台发现某个⽀付渠道,如微信⽀付失败率突增,超时严重,那么就可以临时把这个⽀付⽅式熔断掉
降级:主动关闭⼀些⾮核⼼功能,以确保核⼼功能的正常运⾏。某次腾讯视频挂了的时候,⽤⼾名称默认显⽰腾讯⽤⼾,这也是⼀种降级⽅式,⽤兜底名称做展⽰
4.3 吞吐量
吞吐量越⼤,性能越好;吞吐量相对稳定或者变低,可能系统达到了性能瓶颈
吞吐量变化规律:
波动很⼤:代表系统性能不稳定
慢慢变⾼,再趋于稳定:和并发量强相关。如果并发量⼩于吞吐量,慢慢增⼤并发量,吞吐量也会随之增加
慢慢变低,并发量也减少了:要么说明性能测试要结束了,并发减少;也可能是系统变的卡顿,从⽽导致响应时间变慢,导致单个线程发起的并发量变少
总结
以上就是软件测试-性能测试⼯具篇(沉淀中)的全部内容了,后续会在测试报告中实践,感兴趣记得关注博主的更新动态。喜欢博主写的内容可以一键三连啊!!!!!