软件测试 —— jmeter（2）

软件测试 ------ jmeter（2）

HTTP默认请求头（元件）
元件作用域和取样器作用域
[HTTP Cookie管理器](#HTTP Cookie管理器)
同步定时器
jmeter插件
[梯度压测线程组（Stepping Thread Group）](#梯度压测线程组（Stepping Thread Group）)
- - 参数解析
  - 总结
[Response Times over Time](#Response Times over Time)
[Active Threads Over time](#Active Threads Over time)
聚合报告
测试报告
- - 性能分析

上一次我们简单介绍了一下jmeter和简单使用了一下jmeter，今天我们继续介绍一下jmeter中的其他插件：

HTTP默认请求头（元件）

我们之前创建了一个HTTP请求，我们的手动输入信息：
如果我们有很多的HTTP请求，每一个我们都要手动输入的话，那就太麻烦了，所以我们可以默认配置HTTP的默认请求：

在测试计划上右击：

里面填上相应的信息：
这个时候我们可以把原来HTTP请求中信息抹掉：
这个时候点击运行：
并且我再添加HTTP请求，都是会按照我们默认请求值里面的信息配置：

元件作用域和取样器作用域

如果我们此时再创建一个线程组，添加HTTP请求：
这个时候，HTTP请求3会报错：
我们发现HTTP请求3没有按照之前的配置填入信息，但此时我把HTTP请求默认值给它拉到外面：

此时请求通过了，这就说明我们改变了HTTP请求默认值元件的作用范围。
这就要谈到元件和取样器 的作用范围了
元件作用域只对它的子节点有作用，

取样器(sampler)元件内组件不依赖其他元件就可执行，因此取样器不存在作用问题 ：

HTTP Cookie管理器

我们还有另外一个元件，HTTP Cookie管理器 ：
HTTP Cookie管理器像Web浏览器⼀样存储和发送Cookie。如果HTTP请求并且响应包含cookie,则Cookie管理器会⾃动存储该cookie,并将其用来于将来对该特定网站的所有请求。每个JMeter线程都有自己的"cookie存储区"。因此，正在测试使用cookie存储会话信息的⽹站,则每个JMeter线程都将拥有自己的会话。此类Cookie不会显⽰在Cookie管理器显⽰屏上,可以使⽤"查看结果树监听器"查看。

缓存配置可选择standard(标准)或compatibility(兼容的),当然也可以手工添加⼀些cookie.添加了HTTP Cookie管理器后，会自动存储并发送Cookie。

同步定时器

我们看到右上角的黄色三角形符号：
点击之后会进入到界面，这个时候，我们再次运行：

我们就可以看到各个线程的执行情况，我们看到所有的线程并不是同一时间准备好的，这样我们无法模拟并发的场景，这个时候我们要添加同步计时器 ：

模拟用户组的数量和线程组的数量是一致的。这里注意一下，配置好之后放到全局范围我们再来看：
我们发现两个线程组是同时启动的，这样就可以模拟并发场景了。

jmeter插件

如果我们还想要安装其他的插件，我们就要安装一下小蝴蝶 ：

点击这个跳到对应官网：

https://jmeter-plugins.org/install/Install/

下载好了之后，把插件移动到lib下的ext下：

关闭jmeter之后，再次打开，右上角就会多了一个小蝴蝶的标志：

点击进去就可以搜索下载对应的插件：

我们先安装一个线程组的插件：

点击下方的Apply，就会安装好了重启，之后我们右击查看关于线程组的元件多了两个：

然后我们安装一下extra，帮助我们看到结果：

梯度压测线程组（Stepping Thread Group）

右击，添加梯度压测线程组（Stepping Thread Group）

我们来解释一下这几个参数是啥意思：

这张图显示了JMeter中线程组（Thread Group）的调度参数配置。以下是各个参数的详细解析：

参数解析

This group will start [number] threads:

设置为 100：表示这个线程组将启动100个虚拟用户（threads）。

First, wait for [number] seconds:

设置为 0：表示在启动任何线程之前，等待0秒。这意味着线程会立即开始执行。

Then start [number] threads:

设置为 0：表示在等待时间结束后，立即启动0个线程。这里设置为0，意味着不会立即启动任何线程。

Next, add [number] threads every [number] seconds, using ramp-up [number] seconds:

设置为 20 threads every 3 seconds, using ramp-up 3 seconds：

表示每3秒增加20个线程，并且每个线程的启动间隔为3秒。

例如，在第3秒时启动第一个线程，在第6秒时启动第二个线程，以此类推，直到所有20个线程都启动完毕。

Then hold load for [number] seconds:

设置为 6：表示在所有线程启动后，保持负载（即所有线程都在运行）6秒。

Finally, stop [number] threads every [number] seconds:

设置为 20 threads every 10 seconds：

表示在保持负载6秒后，每10秒停止20个线程。

例如，在第7秒时停止前20个线程，在第17秒时停止接下来的20个线程，以此类推，直到所有线程都停止。

总结

初始阶段：

立即启动0个线程。

每3秒增加20个线程，每个线程的启动间隔为3秒。

负载保持阶段：

在所有线程启动后，保持负载6秒。

停止阶段：

每10秒停止20个线程，直到所有线程都停止。

为了能够看到启动了梯度压测线程组的变化，我们也得添加一些监听器：

Response Times over Time

右击添加，Response Times over Time：

这样我们在启动的时候，就会在这上面看到实际的情况，记得往线程组中添加请求：

Active Threads Over time

我们还可以添加Active Threads Over time来查看线程的活动情况：

聚合报告

从聚合报告可以看到性能测试过程中整体的数据变化：

指标	说明
Samples	发起的 HTTP 请求调用数
Average	平均响应时间，单位为毫秒
Median	请求调用响应时间的中间值，也就是 50% 请求调用的响应时间，单位为毫秒
90%Line	90% 请求调用的响应时间，单位为毫秒
95%Line	95% 请求调用的响应时间，单位为毫秒
99%Line	99% 请求调用的响应时间，单位为毫秒
Min	请求调用的最小响应时间，单位为毫秒
Max	请求调用的最大响应时间，单位为毫秒
Error%	调用失败的请求占比。调用失败一般指响应断言失败或者请求调用出错
Throughput	TPS/QPS，每秒处理的事务数
KB/sec	每秒网络传输的流量大小，单位为 KB。这个指标是以网络传输的大小来衡量网络的吞吐量

测试报告

JMeter测试报告是⼀个全面而详细的文档，它提供了关于测试执行结果的详细信息，帮助用户全面评估系统的性能并进行性能优化。

生成性能测试报告的命令：

text 复制代码

Jmeter -n -t 脚本文件 -l 日志文件 -e -o ⽬录
-n ： 无图形化运⾏
-t ： 被运行的脚本
-l ： 将运行信息写入志文件，后缀为jtl的日志文件
-e ： 生成测试报告
-o ： 指定报告输出目录

执行成功之后会有对应的报告文件：

性能分析

通过三大指标来分析性能问题：

响应时间

定义：响应时间是指从客户端发出请求到接收到服务器响应的整个过程所需的时间。

瓶颈指示：如果响应时间超过了要求，这可能意味着系统已经到达了其处理能力的极限或存在其他性能瓶颈。

注意事项：

分析在多少线程的情况下发生了响应时间超标的情况。

注意响应时间的变化趋势，以确定是否存在系统不稳定的问题。

响应时间变化的原因：

系统不稳定：系统有时快有时慢，可能是由于资源竞争、负载不均等因素导致。

并发压力增大：随着并发用户的增加，响应时间可能会逐渐变长，表明系统在高负载下的性能下降。

错误率（可靠性）

定义：错误率衡量的是系统在高并发场景下能否正常处理业务请求的能力。通常要求达到极高的可靠性标准，如99.99%或更高。

错误率高的原因：

接口请求错误：API调用失败，可能是由于参数错误、网络问题等。

服务器无法继续处理：当服务器达到其处理极限时，可能导致错误率上升。这可能是由于代码质量问题、内存泄漏或其他硬件资源限制。

后端系统限流、熔断、降级：为了保护系统的稳定性，可能会对某些服务实施限流措施，或者在检测到异常时采取熔断和降级策略。

什么是熔断、降级？

熔断：防止系统因某个服务的故障而整体崩溃。例如，在电商平台上用户支付时，若发现某支付渠道（如微信支付）失败率突增或超时严重，可以临时将该支付方式熔断，即停止使用这一渠道以保护系统的其余部分。

降级：主动关闭一些非核心功能，确保核心功能的正常运行。例如，腾讯视频在出现问题时，用户名默认显示为"腾讯用户"，这是一种降级方式，使用兜底名称进行展示以保证基本服务的可用性。

吞吐量

定义：吞吐量指的是单位时间内系统能够处理的请求数量。一般而言，吞吐量越大，性能越好。

吞吐量变化规律：

波动很大：这代表系统性能不稳定，可能存在资源分配不合理等问题。

慢慢变高，再趋于稳定：这种模式通常与并发量强相关。随着并发量从小到大逐渐增加，吞吐量也会相应增长，直到达到一个稳定的水平。

慢慢变低，并发量也减少了：这可能是性能测试接近尾声，人为减少并发量的结果；但也可能是系统变得卡顿，响应时间变慢，从而导致单个线程发起的并发量减少。