---

一、JMeter性能测试技巧

1、CSV文件驱动

jmeter读取csv文件数据，一行一行的循环读取
单线程、多线程都是一致的
当读取最后一条后，会从头开始继续读取

2、定时器

a、泊松随机定时器

b、固定定时器

通过Thread Delay设定每个线程请求之前的等待时间(单位为毫秒)。注意:固定定时器的延时不会计入当前sampler的响应时间里，但是会计入事务控制器的时间。 对于事务控制器来说，定时器相当于loadrunner中的think time(思考时间:实际操作中，模拟真实用户在操作过程中的等待时间)

通常所说的响应时间，大部分情况下是针对某一个具体的sampler (http请求)，而不是针对一组sampler组合的事务。

c、高斯随机定时器

如果需要每个线程的延迟时间是符合标准正态分布的随机时间停顿，那么使用这个定时器，总延迟=高斯分布值(平均Q.O和标准偏差1.0)*指定的偏差值+固定延迟偏移

(Math.abs((this.random.nextGaussian()*偏差值)＋固定延迟偏移))

d、均衡随机定时器

e、同步定时器

作用：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力

f、固定吞吐量定时器

g、精准吞吐量定时器

3、全局变量 - 跨线程数据传递

用到了Jmeter元件：
计数器：记录当前执行的是第几次，并通过 number 变量保存
JSON提取器：提取登录接口响应体中的token
BeanShell断言：将token设置为全局变量，可以跨线程组使用
HTTP Cookie管理器：提取上面保存的全局变量

4、Debug调试器

查看Jmeter变量以及属性

5、JMeter执行机端口被占用

二、JMeter性能测试结果查看三大方式

1、GUI界面报告+插件

缺点：界面模式运行，会额外占用（脚本执行机器）更多的资源

既要模拟对服务器发起请求，还要汇总页面、图片、图标、统计数据。CPU是有限的
jmeter作为施压机 - 核心工作 - 模拟并发
实时做统计，导致并发效果不能匹配性能场景

a、聚合报告

90%百分位：表示1000个请求有900个请求的响应时间是小于等于36毫秒
95%百分位：表示1000个请求有950个请求的响应时间是小于等于60毫秒返回
99%百分位：表示1000个请求有990个请求的响应时间小于等于135毫秒返回，有10个请求的响应时间大于135毫秒

90%百分位、95%百分位、99%百分位：各个响应时间段的占比

聚合报告相比较汇总报告，多了三个响应时间分布信息
中位数：表示有1000个请求，其中有500个请求小于等于27毫秒，相当于分界线。

b、汇总报告

具体各个字段的说明在上一篇文章

c、Basic Graphs图表

2、CLI命令行运行+HTML报表

这个命令会生成html报表
jmeter -n -t[jmx file] -l [results file] -e -o [Path to web report folder]

a、命令参数详解

-n：在非GUI模式下运行Jmeter

-t：测试文件
要运行的jmeter测试文件(.jmx).
“-t LAST”：将最后加载用过的文件

-l：日志文件，要将样本记录到文件，例如test001.jtl

-e：–报告的ndofloadtests，负载测试后生成报告仪表盘

-o：保存html报告的路径，此文件夹必须为空或者不存在

b、命令行的测试进度报告

我们通常会在一个linux机器上面去执行

缺点：命令行去运行—推荐的；但是：最终要生成测试结果报告，虽然没有UI界面那么大的消耗，但是依然会有资源压力；
最大的缺点：当测试时间很长时，我们并不能实时的监控

当我们对系统进行12个小时的测试时，但是第1个小时就出现问题，此时并不能看出问题。等12个小时后里面出现几十万次报错，此次测试没用，
测试机器有问题；测试应该停止，而不能继续测试。

3、后端监听器接仪表盘

常用的方案

InfluxDB+Grafana

三、InfluxDB+Grafana Jmeter测试监控大屏

1、整体架构梳理

2、Linux环境中InfluxDB安装与配置

https://blog.csdn.net/YZL40514131/article/details/134933846

3、JMeter后端监听器链接InfluxDB

a、jmeter配置

b、influxdb创建对应的数据库

1、第一步：在influxdb服务器上面，输入influx命令进入influx
2、第二步：influx中输入语句：创建jmeter数据库
create database jmeter;
3、第三步：退出influx
quit

注意事项influxdb与jmeter之间一定要网络互通
如果是虚拟机或者其他linux最好关闭防火墙

4、Linux环境中Grafana环境搭建

a、进入安装包所在目录执行命令

root@hecs-213321:~/performance_testing/monitor# tar -zxvf grafana-9.0.0.linux-amd64.tar.gz 

b、解压

root@hecs-213321:~/performance_testing/monitor# ls
grafana-9.0.0                     influxdb_1.8.0-2_amd64.deb  prometheus-2.36.1.linux-amd64.tar.gz
grafana-9.0.0.linux-amd64.tar.gz  influxdb-1.8.0.x86_64.rpm

c、启动

cd grafana-9.0.0

记得启动相关的命令，在解压后的文件夹里面
例如

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# 

d、启动命令

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# ./bin/grafana-server web

停止：ctrl+c
关闭ssh窗口，程序就停止了

e、工作中：后台启动

nohup ./bin/grafana-server web > grafana-server.log 2>&1 &

root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# nohup ./bin/grafana-server web > grafana-server.log 2>&1 &[1] 3481095
root@hecs-213321:~/performance_testing/monitor/grafana-9.0.0# ls
bin  conf  data  grafana-server.log  LICENSE  NOTICE.md  plugins-bundled  public  README.md  scripts  VERSION

f、web访问

http:ip:3000
默认端口3000
默认用户名和密码都是admin

5、Jmeter - InfluxDB -Grafana完整构建调试

a、添加数据源

选择InfluxDB

配置InfluxDB地址

配置InfluxDB对应的表和访问方式

b、配置大屏数据展示

导入模板

导入json文件

配置模板

6、常见问题

1、网络不通，检查网络IP是否写对，防火墙是否关闭
2、jmeter里面的influxdb地址里面的db=jmeter：和你在influxdb里面创建的数据库一致
3、后端监听器里面measurement：默认携程jmeter和grafana监控大屏模板相对应

7、优点

横向对比多次性能测试数据
长时间测试，能够实时监控性能测试执行情况

四、性能测试领域细分概念：以目的进行划分

1、基准测试：理论推断

目的：平时负载情况，资源占用情况

2、负载测试：实际性能数据（小规模）

目的：想知道一个系统在多少并发的时候会出现问题，这个问题不只是资源的问题，

基准测试和负载测试共同目的是，探索程序的负载能力

3、压力测试：

取负载测试结果中的最高负载能力-压测
取超出预期负载的测试，看程序的性能反应

4、耐久性测试（疲劳测试）（在压力测试和负载测试之间）

压力测试所持续时间----体现到耐久性
取决于业务场景

生成环境高并发压力，一天中的某几个小时，钉钉打卡（小时为单位，24小时/12小时）
全天都有压力，以天为单位（3天/7天）

5、尖峰测试

模拟突然出现的高并发负载，观察程序在这种情况下出现的反应

压力测试、耐久性测试、尖峰测试是为了探索程序在高负载情况下的反应

我们作为基准测试，通过基准测试得到负载测试大概率的线程数量通过负载测试，我们可以简单的分析到系统的性能瓶颈达到了，以50ms为响应时间为例，当响应时间小于50ms表示系统性能没有问题。如果超过了50ms代表系统的瓶颈到了，这个时候我就能知道当前线程数为多少。

接着拿着这个线程数据去做压力测试，观察这10个线程能不能长期稳定的低于50ms。

五、业务流程性能测试

以流程：打开首页——》选择自己喜欢的小说为例

用户真实操作：打开首页（多个接口加载）——》介绍页打开（多个接口加载）
但是：从首页到小说介绍页——》需要用户思考时间
添加定时器
首页与介绍页之间添加1个定时器

通常用到2个定时器

固定定时器

统一随机定时器

携带token的怎么处理？

例如：访问书架接口，有个前提：先登录
前置条件：100个已登录的账户，线程数为1，循环1000次，访问书架
线程组目录如下
操作步骤：
1、新建setUp线程组 - 预先登录100个用户
设置1个线程，循环100次

2、添加CSV数据文件设置，提前准备好用户名表

3、添加登录接口

4、添加HTTP信息头管理器

5、添加JSON断言

6、添加JSON提取器

JSON提取器提取的数据不能跨线程使用
变量名login_token：不能跨线程组使用

需要用到BeanShell，将login_token保存为全局变量，共享给其他的线程组
这里有100个login_token保存100个全局属性

7、添加BeanShell断言
将Json提取器中的变量设置为全局变量，目的是跨线程组使用

8、添加调试取样器
JMeter属性设置为True
可以查看jmeter的运行信息，例如设置的全局变量

9、添加计数器
记录当前执行的是第几次，并通过 number 变量保存

10、新增书架接口线程组

11、线程组下新建HTTP取样器

12、添加HTTP Cookie管理器

13、添加HTTP信息头管理器

14、添加JSON断言

面试：
当时负责什么模块？怎么设计性能测试用例的？
业务流程怎么测试的？

定时器：用户思考时间

登录接口怎么做的？
模拟多少用户登录？
登录完成后去压测某一个接口
用了哪些组件？
怎么去跨线程组共享变量的？