JMeter教程系列（一）-基本介绍

1，概述

Jmeter主要是用来进行接口测试和性能测试，当然不仅仅局限在HTTP/HTTPS，包括

• Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
• SOAP / REST Webservices
• FTP
• Database via JDBC
• LDAP
• Message-oriented middleware (MOM) via JMS
• Mail - SMTP(S), POP3(S) and IMAP(S)
• Native commands or shell scripts
• TCP
• Java Objects

Jmeter有两种模式，GUI和non-GUI模式，GUI也就是我们所谓的IDE，有界面的，一般在windows上安装

non-GUI顾名思义就是没有界面的，采用命令行的执行方式。

官方建议：如果进行性能测试，不要使用GUI模式，比较耗资源吧

2，使用教程

2.1 开始

　2.1.1  概述

　Jmeter使用一般步骤是打开GUI模式-创建plan-开始测试-转non-GUI模式-性能测试-测试分析

　2.1.2  环境要求

　jdk8+

　任意兼容java的操作系统

　2.1.3  安装

   下载地址http://jmeter.apache.org/download_jmeter.cgi   傻瓜式安装即可，尽量不要文件夹包含空格

   配置JAVA_HOME CLASSPATH环境变量（百度很容易找到）

  2.1.4  运行

  安装完成之后，在安装目录下的bin目录可以找到以下一些文件，其中.bat双击打开，.cmd需要在dos下执行，.sh是在linux环境下执行

  jmeter.bat    打开GUI模式

  shutdown.cmd  优雅的停止 （等待正在运行的线程执行完毕）

 stoptest.cmd   暴力的停止（当前正在运行的线程都杀死）

2.2 创建一个testplan

实操-非常简单

2.3  元素介绍

2.3.1  测试计划

 1，可以定义变量，作用于整个test plan

2，连续运行线程组（一次运行一个线程组）

3，主线程停止后，线程组停止

4，功能测试模式（保存响应数据和采样器数据）这只试用小规模测试，会影响性能

2.3.2  线程组

线程组是整个测试计划执行的开始之处，用来控制多个线程的运行。线程组可以设置线程数，启动时间，运行次数等

 ramp-up period   表示的是多久启动完所有设置的线程，如设置了10个线程，100s内启动完成，那么每个线程启动间隔时间就是10s；

该参数的设置既要足够的长，以免在大量并发的情况下，在开始测试的时候不至于对服务器造成压力；

该参数的设置也要足够的短，确保第一个线程运行完成之后，最后一个线程已经启动

一般设置该参数等于线程数，并根据需要做适当的上下调整；

duration设置线程组的运行时间，startup delay设置线程组的启动延迟时间；这两个参数设置之后，每次循环一次之后，会校验时间是否到达，如果到达则停止，否则继续下一轮测试

2.3.3  控制器

控制器有两种，采样器和逻辑控制器；

采样器是用来给服务器发送请求，也就是我们说的http协议请求；逻辑控制器是用来控制什么时候或者是否给服务器发送请求

采样器（红色是我们常用的接口测试）：

• 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

记住：我们要习惯的给每个请求增加校验，因为有时候我们的请求返回状态是正确的，比如200ok;但是返回的内容可能是错误的，特别在压测的时候，我们一定要加上校验，因为压测最容易导致并发错误，不加上的话可能很容易错过严重性的问题；

逻辑控制器：

逻辑控制器就是控制请求次数，什么时候发送请求，是否要发送请求，发送顺序等等

具体请看第3部分

2.3.4  监听器

常用的就是查看结果树， 要想了解更多查看https://jmeter.apache.org/usermanual/listeners.html

2.3.5  定时器

定时器是为了在指定请求发送之前延迟一会。一般在压测过程中防止对服务器造成大量压力或者模拟实际用户场景而使用。

2.3.6  断言

断言就是为了验证响应结果的

2.3.6  配置元素

配置项是为请求服务的，用来配置修改请求信息。

有关这些配置元素的作用域，记住原则：

1，配置元素的作用域只作用于它所在的分支

2，如果子分支和父分支存在相同的配置元素，选择就近原则

 a.上面这个图的配置元素项-HTTP Cookie Manager 是在Simple Controller分支下，所以这个元素对该分支下的所有请求采样器都是有效的，因此他作用于web page 1 和 web page 2，但是不作用于 web page 3

b. 两个相同的web defaults配置元素，我们看到web defaults 2是在父分支 Thread Group下，而web defaults 1是在子分支loop controller下，因此考虑就近原则，web defaults 1只作用于子分支loop controller的web page 2,而web default2 作用于父分支下的除了web page 2的其他所有请求采样器

2.3.7 前置处理器

顾名思义，是在请求发送之前需要处理的动作。通常用来改变请求配置，设置或者更新变量

2.3.8 后置处理器

顾名思义，是在请求发送之后需要处理的动作。通常用来处理响应数据，比如提取数据等

2.3.9 执行顺序

0. Configuration elements
1. Pre-Processors
2. Timers
3. Sampler
4. Post-Processors (unless SampleResult is null)
5. Assertions (unless SampleResult is null)
6. Listeners (unless SampleResult is null)

逻辑控制器和请求采样器是根据树结构顺序执行的。

举个例子，现有test plan如下树结构

• Controller
• Post-Processor 1
• Sampler 1
• Timer 1
• Assertion 1
• Pre-Processor 1
• Timer 2
• Post-Processor 2

执行顺序应该是

pre-processor1

Timer1

Timer2

Sampler1

Post-Processor1

Post-Processor2

Assertion1

2.3.10 作用域

Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers 这些元素是有严格的层次级别的，控制器和采样器是顺序的，也就是步骤执行的，如下执行顺序即为one,two,three,four

不过前面说了，有些控制器是可以改变和控制执行顺序的

又如断言，如果其父节点是采样器，那么他就作用于该采样器，如果其父节点是控制器，那他作用于整个控制器下面的采样器，如下Assertion #1作用于请求One, 而Assertion #2 作用于请求 Two  Three.

我们再来看定时器，如下执行顺序是one,two,three,four,five;Timer #1作用于 Two, Three, and Four， Assertion #1 作用于Three. Timer #2 作用于所有

 注意，配置元素中的Header Manager, Cookie Manager and Authorization manager 和默认配置元素有一些区别，所有默认配置元素会被组合成一个集合，里面包含所有设置的值，然而这几个manager不会被合并，如果一个请求下有多个同样的manager，只能选取一个

2.3.11 属性和变量

 属性在jmeter.properties中定义，属性是全局的，一般用来定义jmeter默认值，属性可以被test plan引用；而变量不是全局的。在testplan中定义的和在配置元素‘用户定义变量’是在整个test plan启动的时候就可以访问的。如果同一个变量在多个‘用户定义变量’中配置，只有最后一个有效。

一旦启动test plan，初始定义的变量就会赋给每个线程。而元素‘用户参数’，前置处理器，正则表达式提取器，后置处理器是可以用来重新定义变量值的，但被改后只能用于当前线程。

属性是全局的，所以可以在线程之间传递。可以通过函数setProperty设置全局属性

2.3  远程测试

暂时不介绍-出系列单独介绍

https://jmeter.apache.org/usermanual/remote-test.html

2.4  实时监控

暂时不介绍-出系列单独介绍  

InfluxDB+Grafana

https://jmeter.apache.org/usermanual/realtime-results.html

2.5.  最佳实践

a 建议用最新版本的Jmeter

b 设置合适的线程数，电脑硬件以及测试计划的配置都有可能影响线程数。线程数依赖于环境性能，越好可能jmeter工作越困难，因为响应太快了。任何的压测工具，如果设置不合理的线程数，可能都会遇到"Coordinated Omission"这类问题，给出错误的不正确的结果。

如果需要大规模压测，请在多个机器上使用命令行模式或者采用分布式测试方式，可以通过创建JavaTest采样器测试下能达到的最大吞吐量。

c 在每个线程组下创建一个HTTP Cookie manager , 除非确定不用缓存cookie

d 在每个线程组下创建一个HTTP Header manager 

e 建议使用录制方式

f 使用变量方式

g 减少资源占用（针对压测的）

• 使用命令行模式
• 尽量少的使用监听器
• 不用使用查看结果树和查看结果表，只在debug的时候使用
• 减少使用大量类似或相同的请求，采用循环或者用csv改变请求采样器
• 不要用功能模式Functional Mode
• 用csv替代xml
• 只有在需要的时候才保存数据
• 尽量少的使用断言
• 用更高级的脚本语言

2.6  压测思考

• 疑问？平均用户量多少（低峰） 高峰用户量多少？什么时候压测方便?下班还是周末？避免压垮服务器  我们的应用有状态机吗？怎么管理的，cookies,session? 压测目标是什么？
• 资源准备：需要什么资源，以及资源在哪里？谁负责？谁搭建环境？谁可以帮忙扩展资源等等
• 测试顺序一般是
  • 低流量测试
  • 基准测试（平均用户量）
  • 压测（高峰用户量）
  • 破坏性测试（最大可能承受的量）
• 在什么样的平台上（windows,linux,等）
• 需要哪些工具或者技能，比如查看指标，测试网络等等