Jmeter系列- test plan【测试计划】详细讲解 、 测试计划参数详解 、基础线程组Thread Group_jmeter中测试计划和线程组的关系

测试计划

作用

• 测试计划描述了 Jmeter 在执行时，一系列的步骤
• 一个完整的测试计划包含了一个或多个【线程组、逻辑控制器、采样器、监听器、定时器、断言和配置元素】测试计划添加or删除元件

测试计划添加or删除元件

• 通过右键点击树中的元件，选中要添加的元件
• 也可以通过合并（merge）或打开（open）从文件中加载和添加元件

配置树中的元件

• 树中的每一个控件都能通过右边内容区显示
• 树中的每一个控件都能在树中随意拖动

运行测试计划

• 可以通过ctrl+r运行测试计划
• 通过右侧的数字：活动线程数/线程总数，这仅适用于本地运行的测试；
• 使用客户端-服务器模式时，它们不包括在远程系统上启动的任何线程【分布式压测时，master机不会显示所有远程salve机的线程总数】

特别注意

仅在调试测试计划时，才应该使用上面的 GUI 模式【界面模式】，如果实际运行负载测试的时候，应该使用CLI模式【命令行模式、无界面模式】

暂停运行测试计划

两种暂停方式

• 停止线程（ctrl + .）【硬中断】
• 关闭线程（ctrl + ,）【软中断】

stop threads

• 许多采样器（Samplers）都是可中断的，这意味着可以提前终止活动采样
• stop命令将检查所有线程是否已在默认超时（即5000 ms = 5秒）内停止
• 如果有线程还没被停止，则会发送一条信息；此时可以再发送一次 stop 命令，但如果还是失败的话，就得退出 Jmeter 来清理

特别注意

上述说的默认超时可以通过Jmeter属性来改变 jmeterengine.threadstop.wait 【jmeter安装目录 / bin / jmeter.properties】

shutdown threads

• 线程会在当前运行任务结束后停止，不会中断活动线程正在执行的任务
• 会出现一个【正在停止测试】的窗口（如下图），直到所有线程都运行完成了才会关闭
• 如果停止时间太久，也可以直接发stop命令

注意点

• 在Linux CLI模式下，是没有快捷键来停止线程运行的，所以Jmeter 在 CLI模式下会监听特定端口上的命令（默认端口4445，可以通过 jmeterengine.nongui.port 修改）
• 如果 4445 端口被占用了（比如，另一个Jmeter实例用了），Jmeter 会自动选择备用端口；
• Jmeter 将尝试监听下一个更高的端口，直到到达Jmeter属性 jmeterengine.nongui.maxport 为止，该属性默认为4455

在CLI模式下，如何停止线程执行

在bin目录下，运行脚本

1. stoptest.cmd / stoptest.sh 【硬中断】
2. shutdown.cmd / shutdown.sh 【软中断】

注意，只有在同一个 host 下运行的脚本，Jmeter 才会接受

测试计划参数

用户定义的变量

• 这里用户添加的变量，相当于全局变量，所有线程组都共用
• 一般添加一些系统常用的配置
• 一般不建议在测试计划上添加变量，因为不方便启用（disable）和禁用（enable）
• 可以添加用户自定义变量组件来代替，如下图

测试计划中 独立运行每个线程组（例如在一个组运行结束后启动下一个）

 

默认：不勾选，默认各线程组并行、随机执行

作用：勾选后，用于控制测试计划中的多个线程组的执行顺序，保证顺序执行各线程组

下图是没有勾选时，多个线程组执行的顺序，可以看到并不完全是顺序执行的

下图是勾选后，多个线程组的执行顺序，可以看到当执行完第一个线程组所有取样器才会执行第二个线程组的，按顺序执行

特别注意：

• 线程组中的取样器执行顺序：默认是从上到下执行
• 交替控制器、随机控制器、随机顺序控制器、循环控制器 可以改变取样器的执行顺序

函数测试模式

勾选后，如果监听器（如：查看结果树）配置了保存到一个文件中（如下图），那么jmeter会将每次的请求结果保存到文件中

在负载测试中不建议勾选，平时调试脚本情况下可以勾选

添加目录或jar包到classpath

当BeanShell脚本需要调用外部的java文件或jar包时，可以把jar包路径添加到这里，然后在BeanShell中直接import进来，并调用jar包中的方法

Thread Group基础线程组介绍

Thread Group的简单理解

• 线程组是一个测试计划的开始点
• 在一个测试计划中的所有元件都必须在某个线程组下
• 线程组决定 Jmeter 执行测试计划的线程数

Thread Group提供的主要作用

• 设置线程数
• 设置ramp-up period
• 设置执行测试的次数【循环次数】

 

Thread Group的独立性

每个线程都会独立的运行测试计划，互不干扰，多个线程用于模仿对服务器的并发访问。

Thread Group线程属性讲解

在取样器错误后要执行的动作

默认：继续

建议：继续

假设一个HTTP Sampler报错了，后面还有其他请求，最好肯定是继续执行下去啦

线程属性值

设置的线程属性值是【预期压力值】

而聚合报告是【压力测试的实际结果】

线程数

• Jmeter java进程下启动的线程，用来模拟真实用户数，1线程数 = 1用户数
• windows下，2g的 java内存，1m 的栈空间，最大启动线程数=1000
• Linux下，2g的 java内存，1m 的栈空间，最大启动线程数=2000
• 在Jmeter中，先启动线程，再运行线程，后释放线程【启动线程并运行，释放线程】
• 线程数建议不超过1000

Ramp-Up时间（秒）【确定一个线程的 启动时间】【精良不要设置为 0 】

• 预期线程组的所有线程从启动-运行-释放的总时间
• ramp up=0时，表示瞬时加压，启动线程的时间无限趋近于0
• 特别注意：在负载测试的时候，尽量把ramp up设置大一些，让性能曲线平缓，容易找到瓶颈点

循环次数

• 每个线程循环执行的次数，默认一次【便于理解：线程的迭代次数、重复发起请求的次数】
• 如果设置为永远，那么 jmeter 将以最大的可能去发送请求，以此测试出最大并发数

线程属性值的简单栗子

上图：10s 内启动并运行 10 个线程，一共启动 10 个线程，总共发送 20 个请求（10*2），每秒启动一个线程，然后运行两次

备注：如果 ramp-up 时间内，所有线程不能启动运行完的话，时间则会顺延下去

Ramp-up 设置注意事项

Ramp-up需要设置足够长的时间来避免在测试刚开始时工作量过大

• 假如需要大量线程的话，不建议设置成0，0 属于瞬时加压【过小的 ramp-up period 】
• 如果设置 0，Jmeter 将在测试开始时就启动全部线程并立即发送请求，这样很容易让服务器达到饱满状态，且瞬间会增加很大的负载量，容易让服务器超载，这样是不合理的；
• 不合理的原因并不是因为平均压力值过高，而是因为所有线程都在初始状态时一起并发访问，从而引起不正常的初始访问峰值，可以通过 Jmeter 的聚合报告看到这种情况

Ramp-up还必须足够短，保证最后一个线程在第一个线程完成之前开始运行

• 如果 Ramp-up 过大，则会降低访问峰值的负载，即没有达到预期的压力峰值，无法获取准确的服务器最大负载情况【过大的 ramp-up period 】
• 具体的表现为：一些线程还没有启动，初期启动的部分线程已经结束了【导致实际并发量并会小于预期并发量】

如何确定一个合理的ramp-up period

• 首先，让初始点击率接近平均点击率，前提是确定合理的访问量
• 初始的 ramp-up period = 平均点击率= 总线程/点击率；
  • 假如线程数=100，点击率=10次/s，则ramp-up period = 100/10 = 10s

延迟创建线程直到需要

 

延迟创建线程，直到线程被需要、采样器开始执行时才会被创建，避免资源浪费

官方英文

When selected, JMeter will allocate threads according to the ramp up times. Otherwise all threads are allocated to the JVM process the moment the test is started, regardless of ramp up time.

译文

选中后，JMeter将根据 Ramp-up 时间来分配线程。 否则，无论 Ramp-up 时间如何设定，所有线程都将在测试开始时分配给JVM进程。

调度器Specify Thread Lifetime【scheduler】

调度器的作用：控制每个线程组运行的持续时间以及它在多少秒后再启动

Duration (seconds) ：持续时间；线程组运行的持续时间

Startup Delay (seconds)：启动延迟；测试计划开始后，线程组的线程将在多少秒后再启动运行

 

调度器和循环次数的关系

• 循环次数有固定值且 ≠ -1，持续时间不会生效，以循环次数为准
• 循环次数设置为永远或 -1 时，持续时间才会生效

调度器注意事项

当线程组运行完持续时间后，会逐步释放线程，不会一下子把所有线程释放掉，而释放线程也是需要时间的~

所以测试计划总的时间（右上角的时间）会 > 持续时间+启动延迟

 

预习TPS

 

• 总的完成请求数 = 线程总数 * 循环次数
• 平均TPS = 总请求数 / 线程运行总时间【上图，右上角黄色三角形的时间】
• 平均TPS（即聚合报告的TPS）是仅供参考的
• 实际的TPS是由服务器决定的，因为它是衡量服务器处理能力的性能指标