逻辑控制器
逻辑控制器可以按照设定的逻辑控制取样器的执行顺序
常用的逻辑控制器:
If控制器用来控制它下面的测试元素是否运行
添加方式:测试计划 --> 线程组–> (右键添加) 逻辑控制器 --> 如果(If)控制器
需求
- 使用‘用户定义的变量’定义一个变量name,name的值可以是‘baidu’或‘taobao’
- 根据name的变量值实现对应网站的访问
操作步骤
- 添加线程组
- 用户定义的变量
- 添加If控制器,判断name是否等于baidu
- 添加HTTP请求,用来访问百度
- 添加If控制器,判断name是否等于taobao
- 添加HTTP请求,用来访问传智播客
- 添加查看结果树
通过设置循环次数,来实现循环发送请求
添加方式:测试计划 --> 线程组–> (右键添加) 逻辑控制器 —循环控制器
需求
循环访问百度10次
操作步骤
- 添加线程组
- 添加循环控制器
- 添加HTTP请求
- 添加查看结果树
循环控制器
线程组属性可以控制循环次数,那么循环控制器有什么用?
线程组属性控制组内所有取样器的执行次数,而循环控制器可以控制组内部分取样器的循环次数,后者控制精度更高
ForEach控制器一般和用户自定义变量或者正则表达式提取器一起使用,其在用户自定义变量或者从正则表达式提取器的返回结果中读取一系列相关的变量。 该控制器下的取样器都会被执行一次或多次,每次读取不同的变量值。
添加方式:测试计划 --> 线程组–> (右键添加) 逻辑控制器 --> ForEach控制器
需求
有一组关键字
[hello,jmeter,test],使用用户定义的变量存储要依次取出关键字,并在百度搜索,例如:https://www.baidu.com/s?wd=hello
操作步骤
- 添加线程组
- 用户定义的变量
- 添加ForEach控制器
- 添加HTTP请求
- 添加查看结果树
序号前不要带0,如:name_01、name_02这种识别不到。
需求
访问https://demodaojia.ecjia.com/,获取返回信息中的商品分类名称信息,并全部保存下来要依次取出关键字,并在百度搜索,例如:https://www.baidu.com/s?wd=说过蔬菜
操作步骤
- 添加线程组
- 添加HTTP请求1 (水果网站)
- 添加正则表达式提取器
- 添加ForEach控制器
- 添加HTTP请求2(百度)
- 添加查看结果树
提示:在Jmeter中叫做同步定时器,在其他软件中又叫集合点。
思考?
- 如何模拟多个用户同时抢一个红包?
- 如何测试电商网站中的抢购活动、秒杀活动?
SyncTimer的目的是阻塞线程,直到阻塞了n个线程,然后立即释放它们。 同步定时器相当于一个储蓄池,累积一定的请求,当在规定的时间内达到一定的线程数量,这些线程会在同一个时间点一起= 并发,所以可以用来做大数据量的并发请求。
添加方式:测试计划 --> 线程组–> HTTP请求 --> (右键添加) 定时器 --> Synchronizing Timer
场景
模拟100个用户同时访问百度首页,统计高并发情况下运行情况
操作步骤
- 添加线程组,设置线程数=100
- 添加HTTP请求
- 添加同步定时器
- 添加查看结果树
- 添加监听器-聚合报告
问题: 当用户数不能整除集合点组件的一组用户数属性时,如果超时时间是 0,会导致程序挂起,怎么避免挂起?
方案1: 点击 stop 强行终止,但是不建议
方案2: 修改一组用户数,能够做到整除(治标不治本)
方案3: 修改超时时间,不设置为 0,即便一组用户数填充不满,只要超时,也会执行(建议)
常数吞吐量定时器可以让JMeter以指定数字的吞吐量(以每分钟的样本数为单位,而不是每秒)执行。
吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组。
添加方式:测试计划 --> 线程组–> HTTP请求 --> (右键添加) 定时器 --> Constant Throughput Timer
场景
一个用户以 20QPS (20 次/s) 的频率访问百度首页,持续一段时间,统计运行情况
操作步骤
- 添加线程组,循环次数设置成永远
- 添加HTTP请求
- 添加常数吞吐定时器
- 添加查看结果树
- 添加监听器-聚合报告
在使用JMeter进行性能测试时,如果并发数比较大(比如项目需要支持10000并发),单台电脑的(CPU和内存)可能无法支持,这时可以使用JMeter提供的分布式测试的功能。
- JMeter分布式测试时,选择其中一台作为控制机(Controller),其它机器做为代理机(Agent)。
- 执行时,控制机会把脚本发送到每台代理机上,代理机拿到脚本后就开始执行,代理机执行时不需要启动JMeter界面,可以理解它是通过命令行模式执行的。
- 执行完成后,代理机会把结果回传给控制机,控制机会收集所有代理机的信息并汇总。
- Agent机上需要安装JMeter
- 修改服务端口
- 注意:非必须。如果是在同一台机器上演示需要使用不同的端口,多台机器可以不修改
- 打开bin/jmeter.properties文件,修改
server_port
,比如:server_port=2001
- 将RMI SSL设置为禁用
- 打开bin/jmeter.properties文件,修改为:server.rmi.ssl.disable=true
- 运行Agent上的jmeter-server.bat文件,启动JMeter
- 修改JMeter的bin目录下jmeter.properties配置文件,修改
remote_hosts
- 示例:
remote_hosts=192.168.182.100:1099,192.168.182.101:1099
- IP和Port是Agent机的IP以及自定义的端口,多台Agent之间用","隔开
- 将RMI SSL设置为禁用
- 打开bin/jmeter.properties文件,修改为:server.rmi.ssl.disable=true
- 启动JMeter
- 选择菜单:运行–>远程启动/远程全部启动
一台控制机和两台执行机,做分布式;要求控制机启动,两台执行机执行,反馈结果;
实现步骤
1.配置代理机一,并启动
2.配置代理机二,并启动
3.配置控制机,并启动
4.添加线程组
5.添加HTTP请求
6.添加聚合报告
- 修改完端口要重启JMeter
- 控制机和代理机最好分开,由于控制机需要发送信息给代理机并且会接受代理机回传的测试数据,所以控制机自身会有消耗
- 参数文件:如果使用csv进行参数化,那么需要把参数文件在每台slave上拷一份且路径需要设置成一样的;
- 每台机器上安装的JMeter版本和插件最好都一致,否则会出一些意外的问题;
位置: 测试计划->右键->监听器->聚合报告
- Label:每个请求的名称(勾选:在标签中包含组名称,显示线程组名-取样器名)
- #样本:各请求发出的数量
- 平均值:平均响应时间(单位:毫秒)。默认是单个Request的平均响应时间
- 中位数:中位数,50% <= 时间
- 90%百分比:90% <= 时间
- 95%百分比:95% <= 时间
- 99%百分比:99% <= 时间
- 最小值:最小响应时间
- 最大值:最大响应时间
- 异常%:请求的错误率 = 错误请求的数量/请求的总数
- 吞吐量:吞吐量。默认情况下表示每秒完成的请求数,一般认为它为TPS。
- 接收 KB/sec:每秒从服务器端接收到的千字节数
- 发送 KB/sec:每秒向服务器发送的千字节数
JMeter支持生成HTML测试报告,以便从测试计划中获得图表和统计信息。
进入jmeter的bin目录下,输入如下命令:
jmeter -g test.jtl -o /path
# -g:后跟test.jtl文件所在的路径
# -o:后跟生成的HTML文件存放的路径
注意:如果是在Windows环境命令行运行,必须指定生成的HTML文件存放文件夹,否则会报错;如果是linux环境,如指定路径下不存在该文件夹,会生成对应的文件夹存放报告文件!
如果还未生成.jtl文件,则可以通过如下命令,一次性完成测试执行和生成HTML可视化报告的操作,进入jmeter的bin目录下,输入如下命令:
jmeter -n -t ./test.jmx -l ./test.jtl -e -o ./path
# -n:以非GUI形式运行Jmeter
# -t:source.jmx 脚本路径
# -l:result.jtl 运行结果保存路径(.jtl),此文件必须不存在
# -e:在脚本运行结束后生成html报告
# -o:用于存放html报告的目录
注意
test.jtl和report会自动生成,如果在执行命令时result.jtl和report已存在,必须用先删除,否则在运行命令时就会报错
Test and Report informations
APDEX (应用性能指标)
Requests Summary(请求总结)
成功与失败的请求占比,KO指失败率,OK指成功率
它包括Over Time(时间变化) 、Throughput(吞吐量) 、Response Times(响应时间)
①、Response Times Over Time(脚本运行期间的响应时间变化趋势图)
说明:可以根据响应时间和变化和TPS以及模拟的并发数变化,判断性能拐点的范围。
②、 Response Time Percentiles Over Time (successful responses)
说明:脚本运行期间成功的请求响应时间百分比分布图,可以理解为聚合报告里面不同%的数据,图形化展示的结果。
③、Bytes Throughput Over Time(脚本运行期间的吞吐量变化趋势图)
说明:在容量规划、可用性测试和大文件上传下载场景中,吞吐量是很重要的一个监控和分析指标。
④、 Latencies Over Time(脚本运行期间的响应延时变化趋势图)
说明:在高并发场景或者强业务强数据一致性场景,延时是个很严重的影响因素。
①、Transactions Per Second(每秒事务数)
说明:每秒事务数,即TPS,是性能测试中很重要的一个指标,它是用来衡量系统处理能力的一个重要指标。
①、 Response Time Percentiles(响应时间百分比分布曲线图)
说明:即响应时间在某个范围内的请求在所有请求数中所占的比率,相比于平均响应时间,这个值更适合用来衡量系统的稳定性。
②、Time Vs Threads(平均响应时间和线程数的对应变化曲线)
说明:可以通过这个对应的变化曲线来作为确定性能拐点的一个参考值。