Jmeter
性能测试
- 负载测试:有助于确定系统在正常和峰值条件下的行为方式。
- 压力测试(疲劳测试):有助于确定计算机，网络，程序或设备在不利条件下保持一定效率的能力。
JMeter特性
- 开源应用程序
- JMeter带有简单的交互式GUI
- 支持各种测试方法:JMeter支持各种测试方法，如负载测试，分布式测试和功能测试等
- Web: HTTP, HTTPS, SOAP
- 数据库: JDBC, LDAP, JMS
- Mail: POP3
- 支持多协议:JMeter支持HTTP，JDBC，LDAP，SOAP，JMS和FTP等协议
- JMeter可以使用虚拟用户或唯一用户模拟多个用户，以便对正在测试的Web应用程序产生大量负载
- 多线程框架：允许许多或单独的线程组同时和同时采样不同的函数
- 远程分布式测试:JMeter具有用于分布式测试的主从概念，其中主服务器将在所有从服务器之间分配测试，而从服务器将针对服务器执行脚本
- 测试结果可视化:如图形，表格，树型和报告
JMeter工作流程
JMeter通过模拟一组用户将请求发送到目标服务器。 随后，收集数据以通过各种格式计算目标服务器的统计和显示性能度量。
JMeter主要测试组件
- 测试计划(Test Plan)是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。
- 线程组(Thread Groups)线程组元件是任何测试计划的起点。代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。
- 控制器(Controller)分为采样器(Sampler)和逻辑控制器(logic Controller)。逻辑控制器(Logic Controller)可以自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
- 监听器(Listener)负责收集测试结果，同时也被告知了结果显示的方式。
- 定时器(Timer)负责定义请求之间的延迟间隔。
- 配置元件(Config Elements)维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
- 前置处理器(Pre Processors)负责在生成请求之前完成工作。常常用来修改请求的设置。
- 后置处理器(Post Processors))负责在生成请求之后完成工作。常常用来处理响应的数据。
- 断言(Assertions)可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
JMeter测试计划(Test Plan)
测试计划可视化为用于运行测试的JMeter脚本。 测试计划由测试元素组成，例如线程组，逻辑控制器，样本生成控制器，监听器，定时器，断言和配置元素。
测试计划包含执行脚本的所有步骤。 测试计划中包含的所有内容都按照从上到下的顺序执行，或者按照测试计划中定义的顺序执行。
JMeter线程组(Thread Groups)
一个测试计划的所有元件必须在一个线程组下。线程组元件控制JMeter运行测试时使用的线程数。Thread Group有三个和负载信息相关的参数：
- Number of Threads： 设置发送请求的用户数目
- Ramp-up period： 每个请求发生的总时间间隔，单位是秒。比如你的请求数目是5，而这个参数是10，那么每个请求之间的间隔就是10/5，也就是2秒
- Loop Count： 请求发生的重复次数，如果选择后面的forever（默认），那么请求将一直继续，如果不选择forever，而在输入框中输入数字，那么请求将重复指定的次数，如果输入0，那么请求将执行一次。
JMeter控制器(Controllers)
分为采样器(Sampler)和逻辑控制器(logic Controller)
1. 采样器(Sampler)
采样器是允许JMeter将特定类型的请求发送到服务器的组件。它模拟用户对目标服务器的页面的请求。
采样器是必须将组件添加到测试计划中的，因为它只能让JMeter知道需要将哪种类型的请求发送到服务器。JMeter取样器包括：
- FTP请求
- HTTP请求(也可用于SOAP或REST Web服务)
- JDBC请求
- Java对象请求
- JMS请求
- JUnit测试请求
- LDAP请求
- 邮件请求
- 操作系统进程请求
- TCP请求
2. 逻辑控制器(logic Controller)
逻辑控制器可控制线程中采样器处理顺序的流程。 也可更改来自其子元素的请求的顺序。即逻辑控制器允许你定制JMeter何时发送请求。以下是JMeter中所有逻辑控制器的列表：
| 简单控制器（Simple Controller） | 组织采样器和其它的逻辑控制器（分组功能），提供一个块的结构和控制，并不具有任何的逻辑控制或运行时的功能 | |
| 循环控制器（Loop Controller） | 指定其子节点运行的次数，可以使用具体的数值，也可以使用变量 |
|
| 仅一次控制器（Once Only Controller） | 在测试计划执行期间，该控制器下的子结点对每个线程只执行一次，登录场景经常会使用到这个控制器 | |
| ForEach控制器（ForEach Controller） | ForEach控制器一般和用户自定义变量一起使用，其在用户自定义变量中读取一系列相关的变量。该控制器下的采样器或控制器都会被执行一次或多次，每次读取不同的变量值。 |
|
| 事务控制器（Transaction Controller） | 事务控制器会生产一个额外的采样器，用来统计该控制器子结点的所有时间 |
|
| If 控制器（If Controller） | 根据给定表达式的值决定是否执行该节点下的子节点，默认使用javascript的语法进行判断 |
|
| Switch控制器（Switch Controller） | Switch控制器通过给该控制器中的Value赋值，来指定运行哪个采样器 | 有两种赋值方式：第一种是数值，Switch控制器下的子节点从0开始计数，通过指定子节点所在的数值来确定执行哪个元素。第二种是直接指定子元素的名称，比如采样器的Name来进行匹配。当指定的名称不存在时，不执行任何元素。当Value为空时，默认执行第1个子节点元素 |
| 吞吐量控制器(Throughput Controller) | 控制其下的子节点的执行次数与负载比例分配 | 两种方式：1.Total Executions：设置运行次数 2.Percent Executions：设置运行比例(1~100之间) |
| 随机控制器(Random Controller) | 随机执行其下的所某个子结点 | |
| 随机顺序控制器(Random Order Controller) | 随机执行其下的所有子结点 |
另：其他控制器
- 运行时控制器
- 录音控制器
- while控制器
- 模块控制器
- 包括控制器
- 交错控制器
JMeter监听器(Listeners)
性能测试就是以各种形式分析服务器响应，然后将其呈现给客户端。
当JMeter的采样器组件被执行时，监听器提供JMeter收集的关于那些测试用例的数据的图形表示。它便于用户在某些日志文件中以表格，图形，树或简单文本的形式查看采样器结果。
监听器可以在测试的任何地方进行调整，直接包括在测试计划下。JMeter提供了大约15个监听器，但主要使用的是表，树和图形。以下是JMeter中所有监听器的列表：
- View Results Tree察看结果树
- Summary Report概要报告
- Aggregate Report聚合报告
- Backend Listener
- Aggregate Graph汇总报告
- Comparison Assertion Visualizer
- Generate Summary Results生成概要结果
- Graph Results图表结果
- JSR223 Listener
- Mailer Visualizer邮件观察仪
- Response Time Graph
- Save Responses to a file保存响应到文件
- Simple Data Writer简单的数据编写者
- View Results in Table用表格查看结果
- Bean Shell Listener :BeanShell监听器
常用的三个监听器：
1. 察看结果树：查看请求结果，通过的测试通常为绿色。红色则代表失败。查看对应Sampler的测试结果的请求、响应数据。
不过要注意的是，该监听器笔者推荐做调试用，在实际运行压测时，应该禁用，因为大量请求时，该监听器会造成大IO消耗，影响压力机性能。
2. 概要报告：提供了最简要的测试结果信息，同时可以配置将相应的信息保存至指定的文件中（支持xml、csv格式的文件）。单击Configure按钮，可以配置结果保存各种选项。以下是每个标签说明：
| Label | 请求名称 |
| Samples | 请求计数 |
| Average | 请求响应平均耗时 |
| Min | 请求响应最小耗时 |
| Max | 请求响应最大耗时 |
| Std. Dev | 请求响应时间的标准差 |
| Error % | 请求错误率 |
| Throughput | 吞吐量 |
| Received KB/sec | 每秒接收（即响应）的数据量KB |
| Sent KB/sec | 每秒发送的数据量KB |
| Avg. Bytes | 服务端响应的数据的平均值 |
3. 聚合报告：应该是最详细的报告了，也是最为常用的报告。是大家在压测过程中最常用的监听器。该监听器对于每个请求，它统计响应信息并提供请求数，平均值，最大，最小值，中位数、90%、95%、错误率，吞吐量(以请求数/秒为单位)和以kb/秒为单位的吞吐量。
| Label | 请求名 |
| Samples | 请求计数 |
| Average | 请求响应平均耗时 |
| Meian | 中位数，表示50%的请求在该耗时内完成 |
| 90% Line | 表示90%的请求在该耗时内完成 |
| 95% Line | 表示95%的请求在该耗时内完成 |
| 99% Line | 表示99%的请求在该耗时内完成 |
| Min | 请求响应最小耗时 |
| Max | 请求响应最大耗时 |
| Error % | 请求错误率 |
| Throughput | 吞吐，每秒处理请求数 |
| Received KB/sec | 每秒接收多少KB数据 |
| Sent KB/sec | 每秒发送多少KB数据 |
JMeter定时器(Timers)
模拟用户在网站或应用程序上执行操作的暂停与延迟。可用定时器来定义每个请求到达时间等待的终止。
- 定时器是在每个sampler（采样器）之前执行的，而不是之后（无论定时器位置在sampler之前还是下面）
- 当执行一个sampler之前时，所有当前作用域内的定时器都会被执行
- 如果希望定时器仅应用于其中一个sampler，则把定时器作为子节点加入
- 如果希望在sampler执行完之后再等待，则可以使用Test Action
| BeanShell定时器（BeanShell Timer） | 一般情况下用不到，但它可以说是最强大的，因为可以自己编程实现想要做的任何事情，例如：希望在每个线程执行完等待一下，或者希望在某个变量达到指定值的时候等待一下 | |
| 固定吞吐量定时器（Constant Throughput Timer） | 可以让JMeter以指定数字的吞吐量（即指定TPS，只是这里要求指定每分钟的执行数，而不是每秒）执行 | |
| JSR223定时器（JSR223 Timer） | 相当于BeanShell定时器的“父集”，它可以使用java、JavaScript、beanshell等多种语言 | |
| 泊松随机定时器（Poisson Random Timer） | 在每个线程请求之前按随机的时间停顿，大部分的时间间隔出现在一个特定的值，总的延迟就是泊松分布值和偏移值之和 | 1.Lambda(in milliseconds):兰布达值 2.Constant Delay Offset(in milliseconds):暂停的毫秒数减去随机延迟的毫秒数 |
| 同步定时器（Synchronizing Timer） | loadrunner当中的集合点（rendezvous point）作用相似，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力。 | 1.Number of Simulated Users to Group by：模拟用户的数量，即指定同时释放的线程数数量 2.Timeout in milliseconds：超时时间，即超时多少毫秒后同时释放指定的线程数 |
| 均匀随机定时器（Uniform Random Timer） | 和高斯随机定时器的作用差异不大，区别在于延时时间在指定范围内且每个时间的取值概率相同，每个时间间隔都有相同的概率发生，总的延迟时间就是随机值和偏移值之和。 | 1.Random Delay Maximum(in milliseconds):随机延迟时间的最大毫秒数 2.Constant Delay Offset(in milliseconds):暂停的毫秒数减去随机延迟的毫秒数 |
| 固定定时器（Constant Timer） | 让每个线程在请求之前按相同的指定时间停顿,固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间.对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing（两次迭代之间的间隔时间）；对于“事务控制器”来说，定时器相当于loadrunner中的think time（思考时间：实际操作中，模拟真实用户在操作过程中的等待时间）。 | |
| 高斯随机定时器（Gaussian Random Timer） | 每个线程在请求前按随机时间停顿 |
JMeter配置元件(Configuration Elements)
不发送请求（HTTP代理服务器除外），可以补充或修改请求。即JMeter配置元件可以用来初始化默认值和变量，以便后续采样器使用。将在其作用域的初始化阶段处理。
- CSV Data Set Config：被用来从文件中读取数据，并将它们拆分后存储到变量中，适合处理众多变量
- Variable Names：变量名列表（逗号分隔）。JMeter2.3.4以后的版本，支持CSV标题行，如果变量名为空，那么文件的第一行将被读取，并被解释为列名的列表。这些变量名必须使用分割符加以区分，他们可以使用双引号加以引用。默认情况下，该文件仅打开一次，而每个线程会使用文件中不同的数据行。至于数据行传递给线程的顺序，依赖于他们执行的顺序，数据行在每次测试循环的开始阶段读取，文件名和模式在第一次循环时解析。
- Delimiter:默认逗号
- Allow quoted data?: CSV文件是否容许值被引用
- Recycle on EOF?: 达到文件结尾后，是否从文件开始循环重新读取（默认True),当到达文件尾时，且Recycle选项设置为True，就会从文件第一行重新开始读取，如果设置为false,而Stop thread on EOF?是False，那么当到达文件尾部时所有变量都将被置为<EOF>,可以通过设置JMeter属性csvdataset.eofstring来改变该值。如果Recycle选项为false,而Stop thread是True,那么到达文件尾部之后，将导致线程被终止。
- Stop thread on EOF?:达到文件结尾后，线程是否该终止。
- Sharing mode：如果希望每个线程拥有自己独立的值集合，那么就需要创建一系列数据文件，为每个线程准备一个数据文件，如test1.csv、test2.csv等，使用文件名test${__threadNum}.csv,并将“sharing mode"设置为"Current thread"
- All threads:文件在所有线程间共享
- Current thread group: 每个文件会针对每个线程组打开一次
- Current thread: 每个文件会针对每个线程单独打开
- Identifier:所有线程共享相同的标识，共享相同的文件。如有４个线程组，测试人员可以使用一个通用ＩＤ，以便在两个或多个线程组之间共享文件。
注意：CSV Dataset变量在每次测试循环的初始阶段定义，由于定义发生在配置处理完成之后，所以他们不能用于一些配置元件（如JDBC Config），以便在配置时处理他们的内容。可在HTTP Auth Manager中正常使用。
- FTP Request Defaults:被用于设置FTP请求的默认值
- HTTP授权管理器：可以帮助测试人员指定针对Web页面的一个或多个登录。如果没有定义，HTTP客户端采样器默认使用pre-emptive校验，要禁止这一功能，做如下设置： jmeter.propertied中：设置 httpclient.parameters.file=httpclient.parameters httpclient.parameters中：设置 http.authentication.preemptive$Boolean=false ，上面的设置只影响HTTPClient采样器(SOAP采样器，也使用HTTPClient). 注意，如果在一个采样器的作用域范围内有多个授权管理器，那么目前没办法确认JMeter使用哪个授权管理器。
- Base URL: 一部分或者完整的URL，用于匹配一个或者多个HTTP 请求URL。例如：指定一个Base URL（http://jakarta.apache.org/restricted/),对应用户名“jmeter",密码”jmeter".如果测试人员发送一个HTTP请求到 URL（http://jakarta.apache.org/restricted/ant/myPage.html),授权管理器就会发送用户名为"jmeter"登录信息
- username:校验用的用户名
- Password：该用户的密码
- Domain:针对NTLM使用的域
- Realm:针对NTLM使用的realm
- HTTP Cache Manager:被用来为其作用域内的HTTP请求提供缓存功能，如果“Use Cache-Control/Expires header When ..."选中，那么会根据当前时间来选择，如果请求是”GET"，而时间指向未来，那么采样器就会立即返回，而无须从远程服务器请求URL,这样是为了模拟浏览器的操作，请注意Cache-Control头必须是“pulic”的，并且只有"max-age"终结选项会被处理，如果请求文档自从其被缓存以来没有发生任何改变，那么响应包体就会为空。
- HTTP Cookie管理器：主要有两个功能：
- 它像web浏览器一样存储和发送Cookie。，如果测试人员有一个HTTP请求和相应里包含Cookie,Cookie管理器会自动存储Cookie，那么接下来针对特定web站点的所有请求中使用该Cookie。可在结果树中查看。接收到的Cookie可以被保存为变量，须定义属性"CookieManager.save.cookie=true",另外，在被存储前Cookie名称会加上前缀“COOKIE_"，要恢复早前处理方式，则定义属性”CookieManager.name.prefix="(一个或多个空格）。如果启动了该功能，那么名称为TEST的Cookie,可以通过${COOKIE_TEST}加以引用。
- 手动为Cookie管理器添加一个Cookie（为所有JMeter线程所共享）。
- HTTP请求默认:设置HTTP请求使用的默认值
- HTTP信息头管理器：可添加或者重载HTTP请求头，JMeter目前支持多个信息头管理器，信息头目将被合并起来构成采样器列表。如果一个待合并条目匹配一个已经存在的信息头名，那么它就会替代目前的条目，除非条目值是空，在这种情况下已经存在的条目会被移除，这容许用户设置一系列默认信息头，并对特定采样器加以调整。
- Name（header):请求头的名称，经常用到的两个通用请求头 “User-Agent" 和”Referer"
- Value:请求头的值
- 登录配置元件：为采样器添加或重载用户名和密码。
- 用户定义的变量：定义初始化一系列变量。都在初始化阶段处理。因此有些变量不能引用。
- Random Variable:被用来产生随机数字字符串，接下来将其存放到变量之中。
- Variable Name: 变量名，用于保存随机字符串
- output format： 使用java.text.DecimalFormat格式字符串，例如”000"会产生至少3个数字的随机数，或者“USER_000"产生的输出格式为USER_nnn,如果不指明，就是用long.toString()来产生数字
- Minimum Value: 产生随机数的最小值（整数）
- Maximum Value:
- Seed for Random function：随机数产生器的种子，默认为当前时间（以毫秒为单位）
- Per Thread(User)?: 如果为False，则随机数产生器在线程组的所欲线程共享，为True,则每个线程都有自己的随机数产生器。
- 计数器：容许用户创建一个计数器，可在线程组中任何地方被引用
- 简单配置元件：可以在采样器中添加或者重载任意值
JMeter前置处理器(Pre-Processor Elements)
前置处理器用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如，HTTP URL重写修复符则可以实现URL重写，当RUL中有sessionID 一类的session信息时，可以通过该处理器填充发出请求的实际的sessionID
JMeter后置处理器(Post-Processor Elements)
后置处理器是用于对Sampler 发出请求后得到的服务器响应进行处理。一般用来提取响应中的特定数据（类似LoadRunner测试工具中的关联概 念）。例如，XPath Extractor 则可以用于提取响应数据中通过正则表达式获得的数据。
JMeter断言(Assertions)
断言用于检查测试中得到的相应数据等是否符合预期，断言一般用来设置检查点，用以保证性能测试过程中的数据交互是否与预期一致。
