jmeter-性能测试场景

一、负载测试场景设计

注意：

做与性能相关的测试， 一定要在一次测试完成之后休息一些时间，再开始第二次测试。 不然就可能因为上一次的测试，影响后续的测试结果，导致越测数据越乱，越不知道怎么分析。
因为性能测试如果有性能瓶颈，会导致服务器出现性能问题。 性能问题千千万，各种情况不一样。如果你没有休息，服务器的资源没有释放，恢复正常，有开始下一次测试， 那么你做的几次性能测试的服务器基础情况是不一样的，所以你测试结果的数据不一样是很正常。

休息多长时间的依据：
被测服务器，执行 top命令， us+sy的值，基本不变，变动非常小， load average的第1个值，基本不变。

负载测试场景设计

概念： tps 服务器每秒处理的事务数 假设1tps 1h 就要处理 3600个事务 10h 3600个
事务 1天 处理86400个事务。
假设 1tps是 1个并发用户数1秒钟发1次请求。
假设10个并发用数1秒，发10个请求， 1天 86.4w次请求
100个并发用户数， 1填 864w次请求
这个计算是一种非常粗略的计算，可以做一个估算。也就可以大概的估算下来，生产环境的并发用户数，一般情况下，都在百级，也就是说并发用户数应该在小几百以内。
用5秒钟累加10个并发用户数： 与 每秒增加2个并发用户数 ====这两个不一定等价
=用5秒钟累加10个并发用户数： 这句话只代表在5秒钟结束的时间点，10个并发用户数会产生出来。 不代表产生的过程是理想的平均。=

填写线程组 ： Stepping Thread Group
This group will start 100 threads： 这个线程组将启动100个线程
First,wait for 0 seconds; 首先 ，等待0 秒
Then start 0 threads; 然后， 启动0个线程
Next,add 10 threads every 30 seconds, using ramp-up 5 seconds.
用5秒钟，累加10个线程，然后运行30秒
Then hold load for 60 seconds. 持续进行60秒的测试
Finally,stop 5 threads every 1 seconds. 每1秒停止5个线程

试运行： GUI运行
取样器
查看结果树： 勾选仅错误日志
Active Threads Over Time： 随着运行时间增长的活跃线程数图
Response Times Over Time： 随着运行时间增长的响应时间图
Transactions per Second： 随着运行时间增长的tps

找出项目接口的最大可接受并发用户数。

最大可接受并发用户数的判断标准：

1、看响应是否有连续报错，------行业中对于这个报错率的标准是 ＜0.1%

2、平均响应时间＜1.5s

2.1求最大可接受的并发用户数的区间

看图分析，得出最大可接受的并发用户数的区间：
看tps图，有没有报错， 没有报错，====第1个标准不能用
如果有连续报错， 就看连续报错的这个时间段，对应的活跃线程数图中线程数是多少，这个线程数的值，就是超过了最大可接受并发用户数的上边界。 -------也就是说此时的线程数就是最大可接受并发用户数区间的最大边界值。 下边界就是 最大边界值 减去 阶梯的步长。

看随着时间变化的响应时间的图， 看在哪一段时间中，平均响应时间超过1.5s。
通过这个时间段，就去活跃线程数图中， 找这段时间段线程数
判断最大可接受并发用户数的区间就是用这个。

如上图不好查看具体的数据可以点击settings

点击上图的位置后点击chart查看具体的时间

根据上图可以看出平均响应时间超过1.5s的时间大概在1分47秒到2分钟之间
然后根据这个时间去活跃线程数图对应的时间节点查看最大并发用户数的取值范围
根据上图可以看出我的最大并发用户数的区间在35-40之间

求最大可接受的并发用户数

然后在根据上图测试的最大并发用户数再次精确你最大并发用户数（设置如下图）

将其保存然后启用命令行测出最大并发用户数

jmeter.bat -n -t xxx.jmx 

可以从图中可以看出平均响应时间超过1.5s的时间在38，那么最大并发用户数为37

3、服务器的资源利用率 ＜80%

一切的性能测试，都需要有性能监控。一切可监控的资源，尽可能都监控起来。
监控： 监控工具 + 监控平台
监控工具，容易上手。
ServerAgent监控、nmon、influxdb+grafana、Prometheus+grafana+xxxxxxx

服务器的资源利用率看这里

性能测试场景设计

线程组： 普通线程组
线程数： 通过负载测试得到接口的最大可接受并发用户数。 46
ramp-up时间： 启动上面设置的线程数的总时长。
一般这个设置， 100以内，设置1-2秒即可，100-500左右，设置3-5秒，500-1000左右，设置5秒左右。
把上面的只有的线程都启动的总时间， 不能简单的进行除法计算（不代表每秒产生多少并发用户数），这个时间只能说明，在你设置的这个时间点结束的时候，你上面的设置的线程数会产生出来。
循环次数： 线程数产生出来之后，会执行几轮迭代的请求，就退出运行。
做性能测试，一般不直接设置数量
一般来说如果看到一个非常精确、整数（如：100、1000、500、3000次）基本上就说明，数据不可靠。
性能测试中，循环次数，要勾选永远， 且勾选调度器，配置持续运行时长。
调度器中持续运行时长，就是 执行性能测试的时间长度。
经验： 一般设置为 5-10分钟

设置一个线程数 ， ramp-up设置1，循环次数设置1， 这种 不是秒杀场景
线程组下面，放置接口取样器。一般情况下，做性能测试，是先做单接口的性能测试，然后，多接口、业务的性能测试，所以一般先一个线程组下面放1个取样器。

聚合报告 & 汇总报告：

每一行，是一种事务
列： 样本。 在性能测试一段时间内总的请求量 = 并发用户数 * 请求频率 * 请求的时长
列： 平均数 ~ 最大值， 都是 响应时间，单位是 ms 毫秒
列： 异常率 请求失败的次数 ÷ 总请求次数
失败： JMeter默认的 请求失败： http协议，是 响应码为4xx、5xx 才认为是失败。
4xx、5xx 反应的是 服务器处理器情况。
但是如果加了断言，你人为的会把断言失败的计算到失败次数中，把请求失败的次数值变大了，异常率就变大了。
列： 吞吐量 每秒的事务数
在网络没有瓶颈的时候， 会把这个值 当作 TPS 来用。
列： 接收 & 发送 是吞吐率， 可以用于 判断是否有 网络瓶颈。

在 负载测试时， GUI界面()中，不会看 聚合报告&汇总报告， 但是，在性能测试时，试运行的时候，
会看聚合报告或汇总报告。 为什么？
1、负载测试目标是 最大并发用户数， 聚合报告、汇总报告中，根本不存在这个数据。
2、负载测试的时候，并发用户数是在变化的，性能测试时，并发用户数是固定

真正执行性能测试使用CLI命令：

jmeter.bat -n -t 你的脚本 -l 结果保存到文件 -e -o 输出报告到文件夹

得到html测试报告。

HTML报告

APDEX 用户满意度指数： 最大值 1， 越接近1，说明满意度越高。

默认的标准： 满意标准 接口的响应时间小于500ms， 满意到能接受的极限的标准 接口的响应时间在500ms ~ 1500ms之间。
APDEX计算公式：（ sum(接口响应时间小于500ms的次数) + sum(响应时间介于500~1500ms之间的
次数)0.5）÷ 总的次数3333次， 小于500ms —1602， 在500~1500ms之间 ----1068次（1602+0.51068）/3333 =0.641

statics 聚合报告

这个里面，也没有并发用户数和 执行时长

error 错误统计

错误的概要信息， 没有详细信息。

charts图表

默认时，间隔1分钟，取一个点
可以改间隔时长。jmeter/bin文件夹下reportgenerator.properties 配置文件中：
jmeter.reportgenerator.overall_granularity=60000 就是1分钟。 可以修改这个值，最小不能小于
1000
在jmeter工具tools文件下根据jtl文件可以重新生成一份报告

Response Times Over Time响应时间图

Transactions Per Second tps图

Active Threads Over Time活跃线程图

性能报告优化工具
bootstrap5 ： 不用写css、js
python3 + pandans
基于jmeter的jtl文件进行数据分析，生成HTML报告，所以，这个工具，没有修改任何JMeter源代码。 这个工具，兼容任意版本的JMeter生成的jtl文件。
jtl文件，必须是 csv格式的jtl文件，不能是xml。

在性能测试中，当并发用户数不够的时候，会用分布式
分布式执行的命令： jmeter.bat -n -t xxx.jmx -R\-r -l xxxx.jtl -e -o xxx

分布式环境搭建看这里

压力测试场景设计

关键词： 比较长的时间
压力测试场景： 阶梯线程组、普通线程组，都可以，只要把持续运行时长，设置的比较长。

秒杀的场景

秒杀场景，不关注响应时长，但是关注报错
秒杀参与时间很短，但是服务器不能出现崩溃。
保证在比较短时间内，服务正常，还要持续很长时间都是正常的。
秒杀要在短时间内，收到大量请求的时候能正常，同时还要正常运行一段很长时间，每时每刻都要能支撑得了秒杀时的大并发量。

波浪型场景Ultimate Thread Group

Ultimate Thread Group
波浪场景设计： 下一行的 初始化的时间点， 大于等于上一行所有时间之和
这个线程组，也可以设计阶梯线程组， 而且设计的阶梯线程组，可以不固定步长。

面向目标场景

实际工作中，会有，性能测试的需求是，如：测试某个接口tps是否能达到多少 （达到50tps）；
或者测试某个接口能否支持多少并发用户数（200并发用户数）
目标是xxtps, 能用这个数值作为并发用户数吗？--------不能。
Arrivals Thread Group 就可以设置面向tps的目标场景
Concurrency Thread Group 达到多少并发用户数 ------- 不适合去做负载场景并发用户数会时刻变化

混合场景

混合场景，不是接口的简单混合（不是说我性能测试的时候，调了多个接口）

混合场景： 同一时间点，不同数量的并发用户数，调用了不同的接口，看服务器在出来这些接口的时候
的性能情况。
绝对不可能是1个线程组，肯定是多个线程组。 线程组才能设置不同的并发用户数。
单接口的性能测试时候，不能在一个测试计划下，同时启用多个线程组。
在同一个测试计划下，启用多个线程组，进行性能测试，就变成了，多个接口的混合场景了。

难，难在哪儿？

1、多个线程组，他们的线程数，应该怎么设置

解决办法：

常规规模公司：通过经验，反复分析，自定义一个比例

大公司：流量回放
2、多个线程组之间，不能直接跨线程组引用参数的

解决办法：

使用JMeter的属性
JMeter属性，是工具自身的可以在工具的任何地方被使用。
当一个线程组中的参数，被定义为属性之后， 整个jmeter工具的任何一个线程组，都可以引用这个属性的值。




提取属性会导致部分接口失败，需要先单独跑几次引用属性然后在进行性能测试