jmeter学习笔记

前言

Jmeter 已经是测试必备技能之一，日常工作中使用十分广泛。之前都是断断续续的学，断断续续的用，每次要使用的时候基本上都已经忘记的差不多啦，还要重新找资源重新学习一遍，十分消耗时间。特此写一遍笔记总结归纳一下，方便日后自己使用及与他人分享。

环境部署

目录介绍

目录介绍

文件/目录	作用
bin	包含启动、配置等相关命令、自己写的脚本默认另存为该目录下
docs	官方接口文档，二次开发需要了解的一些接口
extras	辅助库，持续集成会用到
lib	核心库，包含 JMeter 用到的各种基础库和插件
lib\ext	官方提供的第三方插件
license	包含 non-ASF 软件的许可证
printable_docs	离线的帮助文档，可以查看函数等内容
LICENSE	Jmeter 许可说明
NOTICE	Jmeter 简单信息说明
README.md	Jmeter 官方基本介绍

bin目录介绍

文件	作用
jmeter.properties	JMeter 核心配置文件，各种配置基本在这完成
log4j.conf	JMeter 日志配置管理
jmeter.log	JMeter 运行日志记录，什么输出信息、警告、报错都在这里进行了记录
jmeter.bat	windows 下 jmeter 启动文件
shutdown.cmd	windows 下 jmeter 关闭文件
stoptest.cmd	windows 下 jmeter 测试停止文件
jmeter-server.bat	windows 下 jmeter 服务器模式启动文件
jmeter-server	mac 或者 Liunx 分布式压测使用的启动文件

jmeter.properties 配置项

• 待修改配置复制粘贴到同目录下的 user.properties ， 避免升级时丢失自定义配置
• 语言配置只能在配置文件jmeter.properties中才能生效

# 默认语言设置 中文 zh_CN
language=en  
# 捕捉cookie开关 默认为：false
CookieManager.save.cookies=true 
# 配置编辑器的字体和尺寸
jsyntaxtextarea.font.family=宋体
jsyntaxtextarea.font.size=20 
# 默认编码格式：ISO-8859-1 建议修改为：常用的UTF-8
sampleresult.default.encoding=UTF-8 
# 配置远程主机host
remote_hosts=127.0.0.1 
# 设置日志输出级别
log_level.jmeter=INFO 
# 设置junit日志输出级别
log_level.jmeter.junit=DEBUG 
# 设置输出报告模板格式
jmeter.save.saveservice.output_format=csv 
#开启视网膜模式
jmeter.hidpi.mode=true 
# 将图标放大 1.2 倍
jmeter.hidpi.scale.factor=1.2 
 # 功能区图标尺寸设置
jmeter.toolbar.icons.size=32x32
# 视图区图标尺寸设置
jmeter.tree.icons.size=24x24 
# 内容区尺寸设置
jsyntaxtextarea.font.size=18 
# 内容区字体设置
jsyntaxtextarea.font.family=consolas 
# 默认：false
# post请求自动添加Content-Type: application/x-www-form-urlencoded
post_add_content_type_if_missing=true

面板介绍

常用菜单

• run 分布式运行相关的
• option 打开日志，修改语言，还有管理插(需要先安装插件管理器)
• tools 看函数助手

常用图标

• 从左往右依次是
  • 新建测试计划
  • 选择测试计划模板创建一个新的测试计划
  • 打开jmeter脚本
  • 保存jmeter脚本
  • 剪切
  • 复制
  • 粘贴
  • 展开目录树
  • 收起目录树
  • 禁用或启用元件
  • 本机开始运行当前测试计划
  • 立即开始在本机运行当前测试计划
  • 停止
  • 关闭
  • 清除
  • 清除全部
  • 查找
  • 清除查找
  • 函数助手对话框
  • 帮助

测试计划

添加测试计划

• 默认添加

• 测试计划的作用

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

• 测试计划添加测试元件

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

• 配置树中的元件

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

• 运行测试计划

  • 可以通过ctrl+r运行测试计划
  • 通过右侧的数字：活动线程数/线程总数，这仅适用于本地运行的测试；
  • 使用客户端-服务器模式时，它们不包括在远程系统上启动的任何线程【分布式压测时，master机不会显示所有远程salve机的线程总数】
  • 仅在调试测试计划时，才应该使用上面的 GUI 模式【界面模式】，如果实际运行负载测试的时候，应该使用CLI模式【命令行模式、无界面模式】

• 暂停运行测试计划

  • 停止线程（ctrl + .）【硬中断】

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

  • 关闭线程（ctrl + ,）【软中断】

    • 线程会在当前运行任务结束后停止，不会中断活动线程正在执行的任务
    • 会出现一个【正在停止测试】的窗口（如下图），直到所有线程都运行完成了才会关闭
    • 如果停止时间太久，也可以直接发stop命令
    • 在Linux CLI模式下，是没有快捷键来停止线程运行的，所以Jmeter 在 CLI模式下会监听特定端口上的命令（默认端口4445，可以通过 jmeterengine.nongui.port 修改）
    • 如果 4445 端口被占用了，Jmeter 会自动选择备用端口
    • Jmeter 将尝试监听下一个更高的端口，直到到达Jmeter属性 jmeterengine.nongui.maxport 为止，该属性默认为4455

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

  • 在bin目录下，运行脚本
  • stoptest.cmd / stoptest.sh 【硬中断】
  • shutdown.cmd / shutdown.sh 【软中断】

测试计划属性

• 用户定义的变量

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

• 独立运行每个线程组（例如在一个组运行结束后启动下一个）

  • 默认：不勾选，默认各线程组并行、随机执行
  • 勾选：用于控制测试计划中的多个线程组的执行顺序，保证顺序执行各线程组
  • 特别注意：
    • 线程组中的取样器执行顺序：默认是从上到下执行
    • 交替控制器、随机控制器、随机顺序控制器、循环控制器可以改变取样器的执行顺序

• 函数测试模式

  • 勾选后，如果监听器（如：查看结果树）配置了保存到一个文件中（如下图），那么jmeter会将每次的请求结果保存到文件中
  • 在负载测试中不建议勾选，平时调试脚本情况下可以勾选

• 添加目录或jar包到classpath

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

线程组

添加线程组

• 右键单击测试计划按照下图依次选择
  

• Thread Group的简单理解

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

• Thread Group提供的主要作用

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

• Thread Group的独立性

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

线程组属性

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

  • 默认：继续
  • 默认值即可。假设一个HTTP Sampler报错了，后面还有其他请求，最好肯定是继续执行下去啦

• 线程属性值

  • 作用

    • 设置的线程属性值是【预期压力值】
    • 而聚合报告是【压力测试的实际结果】

  • 线程数

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

  • Ramp-Up时间（秒）

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

  • 循环次数

    • 每个线程循环执行的次数，默认一次
    • 如果设置为永远，那么 jmeter 将以最大的可能去发送请求，以此测试出最大并发数

• 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

• 延迟创建线程直到需要

  • 延迟创建线程，直到线程被需要、采样器开始执行时才会被创建，避免资源浪费
  • 官方解释：选中后，JMeter将根据 Ramp-up 时间来分配线程。 否则，无论 Ramp-up 时间如何设定，所有线程都将在测试开始时分配给JVM进程。

• 调度器Specify Thread Lifetime【scheduler】

  • 作用

    • 控制每个线程组运行的持续时间
    • 以及它在多少秒后再启动

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

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

• 调度器和循环次数的关系

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

• 调度器注意事项

  • 当线程组运行完持续时间后，会逐步释放线程，不会一下子把所有线程释放掉，而释放线程也是需要时间的~
  • 所以测试计划总的时间（右上角的时间）会 > 持续时间+启动延迟

• TPS

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

自定义线程组

• 安装自定义线程组
• 选项- 插件管理器 - Available Plugins - 选择 Custom Thread Groups
  

Stepping Thread Group

• 特点：

  • 有预览图显示估计的负载
  • 可延迟启动线程组
  • 可持续增加线程负载
  • 可设置最大负载的持续运行时间

• 作用：

  • 减少服务器的瞬时压力，做性能测试应该逐步增加压力，而不是瞬时加压
  • 逐步增压越平缓越好，更容易从结果看到多少压力值下，有性能瓶颈
    -参数详解：
    
  • this group will start：表示总共要启动的线程数；若设置为 100，表示总共会加载到 100 个线程
  • first，wait for：从运行之后多长时间开始启动线程；若设置为 0 秒，表示运行之后立即启动线程
  • then start：初次启动多少个线程；若设置为 0 个，表示初次不启动线程
  • next add：之后每次启动多少个线程；若设置为 10个，表示每个梯次启动 10 个线程
  • threads every：当前运行多长时间后再次启动线程，即每一次线程启动完成之后的持续时间；若设置为 30 秒，每梯次启动完线程之后再运行 30 秒
  • using ramp-up：启动线程的时间；若设置为 5 秒，表示每次启动线程都持续 5 秒（和基础线程组的ramp-up一样意思）
  • then hold load for：线程全部启动完之后持续运行多长时间，如图：设置为 60 秒，表示 100 个线程全部启动完之后再持续运行 60 秒
  • finally，stop/threads every：多长时间释放多少个线程；若设置为 5 个和 1 秒，表示持续负载结束之后每 1 秒钟释放 5 个线程

• 负载预览图

  • 从第0秒开始启动线程，每 5 秒内启动10个线程并且运行30秒，以此循环，直到一共启动了 100 个线程
  • 当已启动 100 个线程后，持续负载运行60秒
  • 持续负载运行60秒后，每 1 秒释放五个线程，直到全部线程被释放【注意：线程释放过程中，线程依然在运行】

• 结合Active Threads Over Time查看结果

  • 安装可视化插件：https://jmeter-plugins.org/?search=jpgc-graphs-basic
    

  • 运行Stepping Thread Group需要和Active Threads Over Time结合起来使用，这样能看到动态的阶梯加压效果

  • 可以看到和Stepping Thread Group负载预览图基本一致，证明加压效果是正常的

Concurrency Thread Group

• 作用：

  • Concurrency Thread Group提供了用于配置多个线程计划的简化方法
    该线程组目的是为了保持并发水平，意味着如果并发线程不够，则在运行线程中启动额外的线程
  • 和Standard Thread Group不同，它不会预先创建所有线程，因此不会使用额外的内存
  • 对于上篇讲到的Stepping Thread Group来说，Concurrency Thread Group是个更好的选择，因为它允许线程优雅地完成其工作
  • Concurrency Thread Group提供了更好的用户行为模拟，因为它使您可以更轻松地控制测试的时间，并创建替换线程以防线程在过程中完成

• 参数详解
  

  • Target Concurrency：目标并发（线程数）
  • Ramp Up Time：启动时间；若设置 1 min，则目标线程在1 imn内全部启动
  • Ramp-Up Steps Count：阶梯次数；若设置 6 ，则目标线程在 1min 内分六次阶梯加压（启动线程）；每次启动的线程数 = 目标线程数 / 阶梯次数 = 60 / 6 = 10
  • Hold Target Rate Time：持续负载运行时间；若设置 2 ，则启动完所有线程后，持续负载运行 2 min，然后再结束
  • Time Unit：时间单位（分钟或者秒）
  • Thread Iterations Limit：线程迭代次数限制（循环次数）；默认为空，理解成永远，如果运行时间到达Ramp Up Time + Hold Target Rate Time，则停止运行线程【不建议设置该值】
  • Log Threads Status into File：将线程状态记录到文件中（将线程启动和线程停止事件保存为日志文件）；

• 注意点：

  • Target Concurrency只是个期望值，实际不一定可以达到这个并发数，得看上面的配置【电脑性能、网络、内存、CPU等因素都会影响最终并发线程数】
  • Jmeter会根据Target Concurrency的值和当前处于活动状态的线程数来判断当前并发线程数是否达到了Target Concurrency；若没有，则会不断启动线程，尽力让并发线程数达到Target Concurrency的值

• Concurrency Thread Group和Stepping Thread Group的区别

  • Stepping Thread Group不提供设置启动延迟时间，阶梯增压过渡时间，阶梯释放过渡时间，但Concurrency Thread Group提供

  • Stepping Thread Group可以阶梯释放线程，而Concurrency Thread Group是瞬时释放（具体看下面介绍）

  • Stepping Thread Group设置了需要启动多少个线程就会严格执行，Concurrency Thread Group会尽力启动线程达到Target Concurrency值

  • 通俗点理解

    • Stepping Thread Group 是手动场景：测试过程，按照设定好的步骤执行
    • Concurrency Thread Group 是目标场景：达到某个目标运行场景，测试过程不可控，动态变化

  • 类比 LR

    • Stepping Thread Group ：设置并发用户数，持续时间等，每隔多少时间自动增加多少个用户
    • Concurrency Thread Group：预设一个目标并发数，每隔一段时间增加一部分并发数，直到 TPS 达到目标并发数，然后持续运行一段时间

• Concurrency Thread Group + Active Threads Over Time
  

  • 第一个关注点：阶梯增压过程
    看Concurrency Thread Group负载预览图每次阶梯增压都是瞬时增压的，但是实际测试结果可以看到它也是有一个过渡期，并不是瞬时增压

  • 第二个关注点：持续负载运行结束后，所有线程瞬时释放。

    • 从图最后可以看到，所有线程都是瞬时释放的
    • 普通的线程组有三种状态：启动、运行、释放；而Concurrency Thread Group的线程可以理解成只有两种状态：启动、运行；因为线程都在极短的时间内就结束了

• Concurrency Thread Group的扩展

  • 当Concurrency Thread Group与Throughput Shaping Timer（吞吐量计时器）一起使用时，可以用tstFeedback 函数的调用来动态维护实现目标RPS所需的线程数
  • 使用此方法时， 需要将Ramp Up Time 和 Ramp-Up Steps Count 置空
  • 但要确保 Hold Target Rate Time ≥ Throughput Shaping Timer 时间表中指定的总持续时间值（Duration）

Controllers

Jmeter有两种类型的控制器：Samplers（取样器）和Logical Controllers（逻辑控制器）；它们驱动着测试的进行

取样器

• 取样器是Jmeter向服务器发送请求并等待响应
• 多个取样器按照它们在树中出现的顺序运行
• 取样器 + 控制器可以修改取样器的执行次数

常用取样器

• FTP Request
• HTTP Request (can be used for SOAP or REST Webservice also)
• JDBC Request
• Java object request
• JMS request
• JUnit Test request
• LDAP Request
• Mail request
• OS Process request
• TCP request
  

取样器特性

• 每个取样器都有几个可以设置的属性
• 也可以向测试计划或线程组中添加多个Config Element（配置元件）来更进一步自定义取样器
• 最后，要在测试计划中添加一个Listener（监听器），以便查看请求结果，或存储结果到磁盘

逻辑控制器

逻辑控制器简介

• 逻辑控制器可以自定义决定发送请求的时机的逻辑
• 逻辑控制器可以更改其子元件的请求的顺序
• 逻辑控制器可以组合使用，然后获取不同的结果
• 逻辑控制器用法
  • 先添加逻辑控制器
  • 在逻辑控制器下添加sample
• 无逻辑控制器时线程组下各组件的默认执行优先级
  • 配置元件、监听器
  • 前置处理器
  • 定时器
  • 逻辑控制器
  • 取样器
  • 后置处理器
  • 断言
• 无逻辑控制器时线程组下各组件的默认执行顺序
  • 从上到下

常用逻辑控制器

Listeners

监听器在Jmeter运行时，收集取样器运行的信息。

常用监听器

• Graph Results ：在图表上绘制响应时间
• View Result Tree

监听器特点

• 所有监听器拿到的结果数据都是一致的，唯一区别就是数据的显示方式，不同监听器，显示方式都不一样
• 监听器可以添加到任何位置包括测试计划、线程组、取样器等地方，它们会收集同级别下的数据和所有子元件的数据

监听器安装

• 见上文

处理器

前置处理器

• 在发出取样器请求前执行一些操作
• 用的比较多的是：设置一些参数、修改取样器的设置、脚本预处理

后置处理器

• 在取样器请求发出后执行一些操作
• 用的比较多的是：处理响应数据，提取某个值

配置元件

-配置元件和取样器的关系十分紧密

• 常用配置元件
  • HTTP默认值，设置数据库连接，FTP连接等

参考

https://www.cnblogs.com/poloyy/p/15257716.html
https://www.cnblogs.com/Zfc-Cjk/p/8975619.html
https://www.cnblogs.com/yoyoketang/p/14183361.html