JMeter性能测试的基础知识和个人理解
1. JMeter的简介
JMeter是Apache组织开发的开源项目，设计之初是用于做性能测试的，同时它在实现对各种接口的调用方面做的比较成熟，因此，常被用做接口功能测试和性能测试。它能够很好的支持各种常见接口，如HTTP(S)、WebService、JDBC、JAVA、FTP等，并以多种形式展现测试结果。
2. 组成部分
这部分主要是自己使用过的一些组件和配置的整合，不会详细的讲解每一个组件，有很多的组件都没有介绍到，详细的还请参考JMeter的官方文档：https://wiki.apache.org/jmeter。
2.1 Thread Group（线程组）
线程组模拟多个用户，同时或者有顺序的去执行任务。一个线程组可设置多个线程，每个线程之间互不影响。通过线程组模拟多个用户用来进行服务器的并发或者负载测试。
前提是创建一个Test Plan,对于Test Plan的创建，从File选项就可以创建了。关于线程组的创建，右键TestPlan，选择【Add->Threads->Thread Group】，如下图：
添加完毕，如下图是线程组的一些详细的设置,具体的描述参考下文：
关于【Action to be taken after a Sampler error】这里设置的是当有一个请求出现了错误时，要怎么做。
Continue: 出错不会影响到其他的请求
Start Next Thread Loop：停止当前这一次的Thread Loop，不管当前Thread Loop的请求是否完成，直接进入下一次。
Stop Thread：会停止了当前的线程组
Stop Test：停止这一次测试，会等待最后执行的请求的响应。
Stop Test Now：强制停止这次测试，不会等待最后执行的请求的响应。
关于 【Thread Properties】则是每一个线程的属性
Numbers of Threads:模拟的用户或者线程数量
Ramp-Up Period: 所有的线程在指定的时间内完成启动
Loop Count： 这一组线程执行的次数，举个例子，线程数10，Loop Count为5，则这个测试最终会发起50个请求。
Scheduler:指定一个线程组测试配置开始和结束时间，例如：指定Duration为3600，则一个小时后该测试就结束了。
2.2 Sampler（请求的类型）
Sampler是JMeter的取样器，采样器用于发送请求到不同类型的服务器。其实通俗的理解可以将它看作是一种请求（不是很准确），例如HTTP，FTP等，实际上它可以执行许多的取样。我一般使用的多是HTTP，所以就举HTTP例子来讲解下。
添加一个HTTP Sampler，右键单击线程组，依次选择【Add->Sampler->HTTP Request】即可,如下图：
添加完HTTP取样器后，配置该HTTP请求的一些参数以及URL等，途中的一些配置使用的是自定义变量进行填入的，后面会提到该组件，HTTP请求具体如下图：
配置的HTTP Sampler将是前面的线程组中的每一个线程要执行的具体的操作，那些线程组会按照线程组的配置，发送向指定的服务器应用发送HTTP请求。
2.3 Configuration Element（配置组件）
主要用于定义一些配置和一些变量，提供给其他的组件使用，例如自定义变量，像上面的HTTP Sampler中使用到的${host},${port}等变量，可以使得测试的配置更加的灵活。
添加一个自定义的变量，右键单击线程组，依次选择【Add->Config Element->User Defined Variables】即可,如下图：
添加完该组件后，定义一些自定义变量，如下图所示：
2.4 Listener（监听器）
Listener提供的组件可以用来对请求的数据和响应的结果进行分析和统计，例如Summary Report可以统计测试信息的概要信息，View Result Tree可以监听拦截到每一次请求的数据和响应的数据结果。
2.4.1 Summary Report
添加Summary Report,右键单击线程组，依次选择【Add->Listener->Summary Report】即可,如下图：
Summary Report主要包括了请求数，平均响应时间，最小响应时间，最大响应时间，出错率，吞吐量，每秒接收数据和每秒发送数据等，详细如下图所示：
2.4.1 View Result Tree
添加View Result Tree,右键单击线程组，依次选择【Add->Listener->View Result Tree】即可,如下图：
View Result Tree主要监听了请求的信息和响应的数据信息，详细如下图所示，
对于Listener而言，是没有什么需要配置的，主要是通过这些组件，将数据可视化，方便测试人员分析和统计结果。
2.5 Timer（定时器）
JMeter可以使用定时器来定义请求之间的等待时间。如果不指定，JMeter会一个请求完成后立即执行下一个请求，没有任何等待时间。
2.5.1 Synchronizing Timer（模拟并发）
性能测试中我们经常提到一个概念就是“并发”，其实在实际真实的性能测试中是不存在真正的并发的。为了更真实的模拟对一个请求的并发测试场景，我们通常设置一个聚合请求的点，JMeter中提供了这样的一个功能设置，就是Timer中的Synchronizing Timer，它通过设置一个请求总数和一个等待时间，保证在指定时间内达到设置的请求数时，作为一组请求发送出去。举个例子：请求数为20，等待时间无限长（即设置为0），那么需要请求数达到20个时（原有的线程数一定要有20个或者以上，否则永远将无法满足这个条件，就不会发送了），JMeter才会发送请求，这样保证了最接近并发的场景。
添加一个Synchronizing Timer的步骤：右键单击线程组，依次选择【Add->Timer->Synchronizing Timer】即可,如下图：
设置Synchronizing Timer的一组请求的数量和等待请求数达到设置的数量值时的等待时间，即超时时间，如果为0表示一直等待，如果请求数达不到设置的值则一直不会发送。如果设置了值则如果指定时间内没有达到那么多个请求，时间到了也会将请求都发送出去，基本设置如下图：
注意：这个请求数量和超时时间的设置不合理会导致不会发请求。如果超时时间设置为0了，那么一定要保证Synchronizing Timer设置的请求数小于线程总数，才能保证可以集合到指定的请求数。如果设置了超时时间则可以避免这种情况的出现，达到超时时间后无论是否满足了设置的请求数都会发送出去。
关于模拟并发的一些理解，如果使用Synchronizing Timer模拟50个并发，那么假设我们使用了一个有50个线程的线程组，超时时间设置为0，则该测试每次都会等到有50个线程准备好了，一起发送请求，这样就模拟了指定时刻50个用户像系统并发请求的场景。这种请求往往是一瞬间的事情，如果只有50个线程，那么下一次发起这个请求肯定需要等到所有的请求和响应完成，才能发起，至于这期间的间隔时间是多少就是不确定的，可能是1s,可能是5s，也可能是10s甚至是100s，都有可能；如果想要持续的发起50个并发，让两组并发之间的时间尽可能的短，则可能需要将线程数进行调大，设置为200,300或者500，其实这个值越大未必越好，或者说不断的发起指定的并发请求未必是合理的，因为并发越大，每次并发的间隔越短的话，系统接收到的请求越多，那么很可能会已经超出了系统的负载，那么服务器就会处理超时，其实这样也没什么意义了。所以对于这个并发的设置该怎么测，要怎么的效果，还需要根据实际的情况进行调整，寻找系统合适的并发数，做一定持续时间的并发数反而比设置短时间的持续并发来的有意义些。
2.5.2 Constant Throughput Timer（常数吞吐量计时器）
常数吞吐量计时器，可以对测试计划设置指定的吞吐量，以指定的吞吐量测试系统。
添加一个 Constant Throughput Timer的步骤：右键单击线程组，依次选择【Add->Timer-> Constant Throughput Timer】即可,如下图：
常数吞吐量计时器，指定吞吐量，如下图的吞吐量设置为了每分钟3000，则TPS为50,即每秒50个请求，然后还有个选项是设置这个吞吐量是基于哪一些线程的，如果选择This thread only则控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的target Throughput 乘以该线程的数量。例如该测试计划总共开启来的10个线程，每分钟吞吐量为600（即每秒10个请求），那么总的吞吐量就为10个线程*10个请求，每秒的吞吐量为100。其他的选项分别问所有激活的线程组成或者线程组的组成，例如基于线程组则表明，该线程组的吞吐量控制为指定的数量。具体如下图：
关于吞吐量的理解，假设有一个场景，我想要测试一组数据维持1min，然后每秒的吞吐量控制为50TPS；对于这种场景，我进行了一组测试，新建了个测试计划，添加的一个线程组，配置的用户数为1个（即线程数为1），然后添加一个Constant Throughput Timer，设置每分钟的吞吐量为3000，即50TPS(每秒的请求数)，然后进行测试。虽然只使用了一个用户或者说线程，但是依然可以模拟出每秒50个请求的场景，这个就是Constant Throghput Timer的作用。
至于它和上面的Synchronizing Timer有什么区别？其实他们两个使用的场景或者目标是不一样的，Synchronizing Timer控制的是为测试计划或者线程组的所有线程设置一个阈值，只有线程到达了某个值才统一一起发送，这就像某个指定时刻像系统发起指定的请求。而Synchronizing Timer控制的是指定的线程或者线程组它们的吞吐量，通过指定吞吐量来进行一定吞吐量对系统进行持久性测试。
2.6 Assertions(断言)
断言就是断定测试结果的正确性，通过断言可以根据我们知道的结果来判断请求响应是否正确。用于检查测试中得到的响应数据等是否符合预期，用以保证性能测试过程中的数据交互与预期一致。
2.6.1 Response Assertion
JMeteer可以通过，右键【Test Plan或者 Thread Group】添加断言，选择【Add->Assertions->Response Assertion】,具体如下图所示：
添加完后，下面是响应断言的一些配置选项，可以设置断言应用到那些请求，断言的目标对象是什么，例如针对"Text Respone"断言等，还有添加断言的期待值，具体如下图：
2.6.2 JSON Assertion
JMeteer可以通过，右键【Test Plan或者 Thread Group】添加断言，选择【Add->Assertions->Json Assertion】,具体如下图所示：
添加完后，下面是JSON断言的一些配置选项，JSON断言主要是针对响应的JSON数据，可以通过$.符号来取JSON得值，然后与断言的期望值匹配，进而决定请求的响应有没达到了期望，具体如下图：
对于Jmeter的断言来说，基本上是这样进行添加和配置。用于检查测试中得到的响应数据等是否符合预期，用以保证性能测试过程中的数据交互与预期一致，通过断言可以帮助我们筛选正确的响应。
3.运行JMeter
3.1 GUI的JMeter运行
GUI的JMeter运行就上面的图示一般，运行只需要点击按钮就好，如下图：
一般来说说，JMeter的GUI运行方式，会比较好系统的资源，所以需要比较多的内存，容易出现Out Of Menmory问题，用于实践不是太长的测试场景效果会比较好，否则可能会出现卡死的现象。几个小时甚至十几个小时的测试都可以采用GUI方式测试，但如果时持续好几天甚至超长时间，推荐使用命令运行。
3.1 命令行的JMeter运行（最佳实践）
命令行的运行方式是官方推荐的方式，这种方式没那没好系统的资源，不用渲染GUI界面，可以长时间稳定的运行，但是由于是命令行所以一些结果的分析没那没详细和直接，需要使用图形界面的工具解析测试的日志和结果得到详细的分析结果。
参考下面的表中的JMeter的一些常用的参数释义：
| 命令参数 | 命令参数释义 |
|---|---|
| -n | 设置命令行模式，在非 GUI 模式下运行 JMeter |
| -t | 指定JMX脚本路径，参数为：JMX脚本路径，如果非当前目录需要使用全路径或者相对路径 |
| -l | 指定结果文件路径（jtl或者csv文件），参数为：结果文件路径，如果不存在会自动创建 |
| -j | 指定执行日志路径，参数为：日志路径，如果路径不存在，不会自动创建，同事将日志输出到控制台即命令行。 |
| -g | 指定测试结果文件路径。仅用于生成测试报表。参数为：csv结果文件 |
| -e | 设置测试完成后生成测试报表 |
| -o | 指定测试报表生成文件夹。文件夹必须为空或者不存在，参数为：报表文件夹路径。 |
命令行运行测试计划：
#windows方式(CMD需要进入到JMeter的bin目录下)，Linux也是进入到JMeter的bin目录下
#1.普通的执行测试
jmeter -n -t test.jmx
#2.指定结果文件及日志路径的测试
jmeter -n -t test.jmx -l report\testresult.csv -j reporttestog.log
#3.特别注意如果使用SSH连接到Linux执行命令，那么需要使用nohup和&来保证进程在session关闭时不会退出,&表示测试程序会在后台运行。
nohup jmeter -n -t test.jmx &
nohup jmeter -n -t test.jmx -l report\testresult.csv -j reporttestog.log &
针对生成的testresult.csv，可以使用GUI的JMeter创建Listener的聚合器等组件来对日志进行详细的分析，方便以图形的方式展现测试的结果以及日志。
停止测试计划的命令：
#停止测试计划的命令有两种，推荐第一种。
#1.使用shutdown.sh(Linux)或者shutdown.cmd(widnows)
./shutdown.sh
或者
./shutdown.cmd
#2.使用stoptest.sh(Linux)或者stoptest.cmd(widnows)
./stoptest.sh
或者
./stoptest.cmd
使用shutdown脚本停止测试，如果有的线程还没运行完毕也会等待它们执行结束；如果使用stoptest脚本停止测试则直接结束测试不管是否还有线程还未执行完毕。一般推荐shutdown的方式，除非卡住了的情况才是用stoptest方式。
4.参考文档
https://www.cnblogs.com/fengpingfan/p/5586711.html