JMeter官方文档阅读及实践笔记（上）

JMeter笔记

一、测试计划元件概览

本节简单介绍测试计划的不同部分。

最小测试将包括测试计划、线程组和一个或多个采样器。

1、Thread Group，线程组

线程组元素是任何测试计划的起点。所有

控制器

和

采样器

必须在线程组下。其他元素，例如监听器，可以直接放置在测试计划下，在这种情况下，它们将应用于所有线程组。顾名思义，线程组元素控制JMeter将用于执行测试的线程数。线程组的控件允许：

• 设置线程数
• 设置Ramp-up 时间
• 设置执行测试的循环次数

2、Controller，控制器

控制器有两种，即Samplers(采样器) 与Logical Controllers(逻辑控制器)。

2.1 Samplers(采样器)

采样器用于向服务器送不同协议的请求(HTTP/JDBC等)，采样器告诉JMeter向服务器发送请求并等待响应。它们按照它们在树中出现的顺序进行处理。逻辑控制器可用于修改采样器的重复次数及执行逻辑。

如果要向同一服务器发送多个相同类型的请求（例如，HTTP请求），请考虑使用相应类型的

默认配置元件

。每个控制器都有一个或多个默认元件。

每个采样器都有几个可以设置的属性。可以通过向测试计划中添加一个或多个

配置器

来进一步自定义采样器。在测试计划中添加一个

监听器

，以查看和/或将请求的结果存储到磁盘。

最后可向采样器进行各种类型的

断言

，

断言

支持

正则

匹配

2.2 Logical Controllers(逻辑控制器)

逻辑控制器允许自定义JMeter用来决定何时发送请求的逻辑，类似与编程语言中的if_else、while、for等控制语句。为说明逻辑控制器在测试计划中的作用，用以下结构的测试计划树来举例说明：

2.3 Test Fragments(测试片段)

其概念类似于编程语言中的方法/函数、库，纯粹是测试计划中的“代码重用”。

Test Fragment元素是一种特殊类型的控制器，与Thread Group元素位于同一级别的测试计划树上。它与线程组的区别在于，除非模块控制器或Include_Controller引用它，否则不会执行它。

3、 Listeners，监听器

当JMeter运行时，监听器可以访问JMeter收集的有关测试用例的信息。

图形结果

监听器在图形上绘制响应时间；

查看结果树

监听器显示采样器请求和响应的详细信息，并可以显示响应的基本HTML和XML表示；其他侦听器提供摘要或聚合信息。

此外，侦听器可以将数据定向到文件以供以后使用。JMeter中的每个侦听器都提供一个字段来指示要存储数据的文件。还有一个配置按钮，可用于选择要保存的字段，以及是否使用CSV或XML格式。

请注意，所有侦听器都保存相同的数据；唯一的区别在于屏幕上显示数据的方式。

4、Timers，定时器

默认情况下，JMeter线程在不暂停的情况下按

顺序

执行采样器。官方文档建议测试人员通过向线程组中添加一个可用定时器来指定延迟(

思考时间

，模拟真实用户在实际操作中的停顿)。如果不添加延迟，JMeter可能会在很短的时间内发出太多请求，从而使服务器不堪重负。

定时器会使其子节点采样器(Sampler)在正式发出请求前进行一定的延时。

如果选择将多个定时器添加到线程组，JMeter将获取定时器的总和，并在执行定时器所应用的采样器之前暂停一段时间。可以将定时器添加为采样器或控制器的子级，以限制它们所应用的采样器。

为了在测试计划中的单个位置提供暂停，可以使用

流量控制动作

采样器，即

测试活动

采样器：

5、Assertions，断言

断言允许测试人员断言有关从被测试服务器接收的实际响应。使用断言，以测试应用程序的实际响应与预期是否相符。

例如，可以对查询的响应将包含某些特定的文本进行断言。断言支持

正则表达式

，并且可以指示响应包含文本，或者它应该与整个响应匹配。测试人员可以向任何采样器添加断言。例如，向HTTP请求添加一个断言，以检查文本“</HTML>”。然后JMeter将检查HTTP响应中是否存在文本。如果JMeter找不到文本，那么它会将其标记为失败请求。

注意，断言适用于其范围内的所有采样器。要将断言限制为单个采样器，请将断言添加为采样器的子级。

要查看断言结果，请将断言侦听器添加到线程组。失败的断言也将显示在树视图和表侦听器中，并将计入错误%age，例如在聚合和摘要报告中，如：

6、Configuration Elements，配置元件

配置元件与采样器密切配合。虽然它不发送请求（HTTP(S)测试脚本记录器除外），但它可以添加或修改请求，配置元件管理采样器的属性。

配置元件只能从放置该元素的树分支内部访问，同时，子级配置元件中的值会覆盖父级配置元件中的值，从这点上看，配置元件概念上类似于编程语言中的本地变量，如下图：

用户定义变量配置元件

不同。无论将其放置在何处，都会在测试开始时进行处理，这相当与编程语言中的宏定义或全局变量。为了简单起见，建议仅将元素放置在线程组的开头。

7、Pre-Processor Elements，前置处理器

前置处理器在发出采样器请求之前执行一些操作。如果前置处理器连接到采样器元素，那么它将在采样器元素运行之前执行。前置处理器最常用于在样本请求运行之前修改其设置，或更新未从响应文本中提取的变量。

8、Post-Processor Elements，后置处理器

后置处理器在发出采样器请求后执行一些操作。如果后置处理器附加到采样器元素，那么它将在采样器元素运行后立即执行。后置处理器最常用于处理响应数据，通常用于从中提取值。它与前置处理器联合起来常用于

接口关联

。

9、元件执行顺序

同类型的元件按其出现的先后顺序执行，不同类型的元件按以下顺序运行：

1. 配置元件
2. 前置处理器
3. 定时器
4. 采样器
5. 后置处理器（除非采样结果为空）
6. 断言（除非采样结果为空）
7. 监听器（除非采样结果为空）

请注意，计时器、断言、前置处理器和后置处理器仅在有采样器应用时才进行处理。逻辑控制器和采样器按照它们在树中出现的顺序进行处理。根据发现其他测试元件的范围和测试元件的类型来处理其他测试元件。在类型中，元件按照它们在树中出现的顺序进行处理。

如以下测试计划树：

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

其执行顺序为：

10、作用域规则

JMeter测试树包含分层和有序的元素。测试树中的一些元素是严格分层的（监听器、配置元件、后置处理器、前置处理器、断言、定时器），有些元素是主要排序的（控制器、采样器）。当测试人员创建测试计划时，将创建一个有序的样本请求列表（通过采样器），该列表表示要执行的一组步骤。这些请求通常被组织在同样被排序的控制器内。给定以下测试树：

其请求执行顺序依次为：A_请求、B_请求、C_请求、D_请求。有些控制器会影响其子元素的顺序，可以在组件引用中了解这些特定的控制器。

其他元素是分层的。例如，断言在测试树中是分层的。如果它的父级是一个请求，那么它将应用于该请求。如果其父级是控制器，则它会影响该控制器的所有子级请求。在以下测试树中：

所以上述测试树中各元件的执行顺序为：

A_请求
A_响应断言

B_请求
B_响应断言

C_请求
B_响应断言

D_请求

另一个例子，这次使用定时器：

所以上述含定时器的测试树中各元件的执行顺序为：

B_固定定时器
A_请求

A_固定定时器
B_固定定时器
B_请求

A_固定定时器
B_固定定时器
C_请求
A_响应断言

A_固定定时器
B_固定定时器
D_请求

B_固定定时器
E_请求

在配置元件中，还需注意管理器和默认值的区别，如下图：

11、属性与变量

JMeter属性

定义于文件

jmeter.properties

(此文件在/bin目录下)中，其详细配置点见Configuring JMeter，此文件中定义的所有变量对于JMeter而言是全局变量，例如，属性remote_hosts定义JMeter将尝试远程运行的服务器。此文件中的属性可被测试计划中的变量引用，详见Functions - read a property，但不能用于线程特定值。

JMeter变量

是每个线程的本地变量。每个线程的值可能相同，也可能不同。 如果某个变量由线程更新，则仅更改该变量的线程副本。例如，正则表达式提取器后置处理器将根据其线程读取的样本设置其变量，这些变量稍后可以由同一线程使用。有关如何引用变量和函数的详细信息，见Functions and Variables。

注意，测试计划和用户定义变量(UDV)配置元素定义的值在启动时可用于整个测试计划。如果同一变量由多个UDV元素定义，则最后一个变量将生效。线程启动后，初始变量集将复制到每个线程。用户参数预处理器或正则表达式提取器后置处理器等其他元素可用于重新定义相同的变量（或创建新的变量）。这些重新定义仅适用于当前线程。

setProperty 函数可用于定义JMeter属性。这些对测试计划是全局的，因此可以按实际需要在线程之间传递变量/信息。

属性与变量都是大小写敏感的。

12、使用变量参数化测试

变量不必改变——它们可以定义一次，如果不改变，就不会改变值。因此，可以将它们用作测试计划中频繁出现的表达式的缩写。或对于在运行期间恒定但在运行之间可能不同的项目。例如，主机的名称或线程组中的线程数。

例如，可以在测试计划中定义以下内容：

HOST             www.example.com
THREADS          10
LOOPS            20

可以在测试计划中使用${HOST}、${THREADS}等来引用其值。如果以后要更改主机，只需更改HOST变量的值。这对于少量的测试很好，但在测试大量不同的组合时会变得乏味。一种解决方案是使用属性来定义变量的值，例如：

HOST             ${__P(host,www.example.com)}#__P(property,default)是函数，若property不存在或未定义，则返回默认值default,default默认是一。
THREADS          ${__P(threads,10)}
LOOPS            ${__P(loops,20)}

然后，可以按如下方式在命令行上更改的部分或全部值：

jmeter … -Jhost=www3.example.org -Jloops=13

此后，HOST=www3.example.org，LOOPS=13

除上述方式外，也可通过JMeter内置函数来参数化测试。

二、构建测试计划

在本节中，你将学习如何创建基本测试计划来测试网站。你将创建五个用户，向JMeter网站上的两个页面发送请求。此外，你将告诉用户运行两次测试。因此，请求总数为（5个用户）x（2个请求）x（重复2次）=20个HTTP请求。要构建测试计划，你将使用以下元素：线程组、HTTP请求、HTTP请求默认值和图形结果。

有关更高级的测试计划，请参阅Building an Advanced Web Test Plan。

1、添加用户(线程组)

每个JMeter测试计划要做的第一步是添加

线程组

。

线程组

设置JMeter要模拟的用户数、用户发送请求的频率以及应该发送的请求数。

添加线程组后，按下图设置参数，其余部分保持默认：

2、添加HTTP默认请求属性(HTTP请求默认值)

HTTP请求默认值不会使JMeter发送HTTP请求。它只定义了HTTP采样器使用的默认值。

3、添加Cookie支持(HTTP Cookie 管理器)

几乎所有的web测试都应该使用cookie支持，除非你的应用程序特别不使用cookie。要添加cookie支持，只需在测试计划中的每个线程组中添加一个HTTP cookie管理器。这将确保每个线程都获得自己的cookie，但会在所有HTTP请求对象中共享。

无需对Cookie管理器的属性进行任何设置：

4、添加HTTP请求(HTTP采样器)

JMeter按照请求在树中出现的顺序发送请求，所以依次添加以下两个HTTP请求，仅编辑标记的部分，其余保持默认即可：

5、添加监听器查看结果

需要添加到测试计划中的最后一个元件是侦听器。该元件负责将HTTP请求的所有结果存储在文件中，并提供数据的可视化模型。按下图添加以下两个监听器：

三、常用采样器详述

1、HTTP采样器

（1）概述

此采样器允许测试人员向web服务器发送HTTP/HTTPS请求。它还允许测试人员控制JMeter是否解析HTML文件中的图像和其他嵌入资源，并发送HTTP请求以检索它们。默认的解析器是

org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser

。这可以通过jmeter.properties使用属性

htmlparser.className

进行更改。

如果要向同一web服务器发送多个请求，请考虑使用

HTTP请求默认值

这一配置元件，这样就不必为每个HTTP请求输入相同的信息。

或者，有时可能希望使用JMeter的HTTP（s）测试脚本记录器来创建HTTP请求，而不是手动添加HTTP请求。如果有很多HTTP请求或带有许多参数的请求，这可以节省时间。

（2）有关HTTP实现

HTTP采样器的实现有以下三种，可按实际需要设置：

其中，使用

Java JVM

提供的HTTP实现有以下限制：

• 无法控制如何重新使用连接。当JMeter释放连接时，同一个线程重新使用该连接的可能不确定；
• 不支持Kerberos身份验证；
• 它不支持使用Keystore Config进行基于客户端的证书测试；
• 它仅支持以下请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE 和 TRACE；

如果请求需要服务器或代理登录授权（即浏览器将创建弹出对话框），则还必须添加

HTTP授权管理器

配置元件。对于正常登录（即用户在表单中输入登录信息），您需要确定表单提交按钮的作用，并使用适当的方法（通常是POST）和表单定义中的适当参数创建HTTP请求。如果页面使用HTTP，则可以使用JMeter代理来捕获登录序列。

（3）SSL证书设置

每个线程使用单独的SSL上下文。如果要使用单个SSL上下文（而不是浏览器的标准行为），即所有线程共用一个SSL上下文，请设置JMeter属性：

https.sessioncontext.shared=true

默认情况下，从5.0版开始，SSL上下文在线程组迭代期间保留，并为每个测试迭代重置。如果在测试计划中，同一用户迭代多次，则应将其设置为false。

httpclient.reset_state_on_thread_group_iteration=true

注意，这不适用于 Java HTTP实现：

JMeter默认为SSL协议级别TLS。如果服务器需要不同的级别，例如SSLv3，请更改JMeter属性，例如：

https.default.protocol=SSLv3

JMeter还允许通过更改属性

https.socket.protocols

来启用其他协议。

（4）有关Cookie的建议

如果请求使用Cookie，那么您还需要一个

HTTP Cookie管理器

。您可以将这些元素添加到线程组或HTTP请求中。如果有多个HTTP请求需要授权或cookie，请将这些元素添加到线程组。这样，所有HTTP请求控制器将共享相同的授权管理器和Cookie管理器元素。

（5）采样器参数详情

Basic 选项卡各参数

Advance 选项卡各参数

（6）模拟慢连接

HttpClient4

和

Java Sampler

支持模拟慢速连接，见jmeter.properties中的以下条目：

# Define characters per second > 0 to emulate slow connections#httpclient.socket.http.cps=0#httpclient.socket.https.cps=0

然而，

Java Sampler

仅支持慢速HTTPS连接。

（7）响应大小计算

Java实现

在响应体大小中不包括传输开销，例如块头。

HttpClient4实现

却是在响应体大小中包含开销，因此该值可能大于响应内容中的字节数。

（8）重试处理

默认情况下，

HttpClient4

和

Java实现

的重试都设置为0，这意味着不尝试重试。 对于

HttpClient4

，可以通过设置相关的JMeter属性来覆盖重试计数，例如：

httpclient4.retrycount=3

对于

HttpClient4

，默认情况下将在Idempente Http方法上进行重试。如果要重试所有方法，请设置属性：

httpclient4.request_sent_retry_enabled=true

注意，默认情况下，

Java实现

不会重试，可以通过设置来指定：

http.java.sampler.retries=3

（9）证书异常的处理

可能会遇到错误：java.security.cert.CertificateException: Certificates does not conform to algorithm constraints。如果在具有SSL证书（其本身或其信任链中的一个SSL证书）的网站上运行HTTPS请求，该证书的签名算法使用MD2（如md2WithRSAEncryption）或SSL证书的大小小于1024位，则证书不符合算法约束。

此错误与Java 8中安全性的提高有关。

为了顺利执行HTTPS请求，可以通过编辑Java

jdk.certpath.disabledAlgorithms

属性来降低Java安装的安全性。根据实际情况，删除MD2值或大小限制。该属性在以下路径中：

JAVA_HOME/jre/lib/security/java.security

2、JDBC采样器

（1）概述

此采样器用于向数据库发送JDBC请求（SQL查询）。

（2）JDBC Connection Configuration

（3）设置Query Type

（4）应用举例

有以下表和Select 语句，如下：

使用JDBC采样器来实现和上面SQL一样的效果：

3、测试活动采样器(Flow Control Action)

测试活动

采样器是一种用于条件控制器的采样器。此测试元件不是生成样本，而是暂停或停止选定的目标。

这个采样器与事务控制器结合使用也很有用，因为它允许在不需要生成样本的情况下包含暂停。对于可变延迟，将暂停时间设置为零，并添加一个

定时器

作为子项。

四、逻辑控制器

逻辑控制器确定采样器的处理顺序或逻辑。

1、简单控制器

简单逻辑控制器用于组织采样器和其他逻辑控制器。与其他逻辑控制器不同，该控制器不提供组织以外的功能。如果把JMeter元件当成编程语言中的“语句”的话，简单控制器则相当于一个花括号或python的缩进，用于将其他“语句”组织起来：

以下图为例，各元件的执行顺序为：A1->A2->B1->B2

2、循环控制器

每次在测试运行期间，用于控制此控制器的子元件将被迭代的运行次数；作用类似于编程语言中的for循环。

JMeter将循环索引公开为名为**jm<循环控制器名称>__idx的变量。例如，如果循环控制器名为LC，则可以通过${__jm__LC__idx}**访问循环索引。索引从0开始。

以下图为例，各元件的执行顺序为A->B->B->B->B->B：

3、仅一次控制器

此控制器下的子控制器在每个线程中将只运行一次，这对于登录请求十分有用，因为在实际操作中线程(用户)仅需登录一次就可获取之后的请求所需的token、sessionID或cookie等持久化标记变量。

以下图为例的测试计划中，线程组有发送两个HTTP请求的线程，每个线程登录一次，之后再进行搜索B三次，尽管将线程组的迭代次数设置为3，但每个JMeter线程只登录一次，因为该请求位于

仅一次控制器

中。

每个JMeter线程将按以下顺序发送请求：登录、搜索B、搜索B、搜索B。

4、交替控制器

如果将元件或其他逻辑控制器添加为

交替控制器

的子控制器，则JMeter将在每个循环迭代的其他控制器之间交替。

（1）选项 Interleave across threads

勾选

Interleave across threads

的作用，以下图的计划树举例说明，此树的线程组有4各线程4次迭代：

（2）示例

示例一

迭代序数每个JMeter线程在每次迭代中发送的请求1A_HTTP请求1D_HTTP请求2B_HTTP请求2D_HTTP请求3C_HTTP请求3D_HTTP请求4因为在交替控制器中没有更多的请求， JMeter重新启动并发送第一个HTTP请求，即A_HTTP请求。4D_HTTP请求5B_HTTP请求5D_HTTP请求

示例二

在本例中，我们将线程组配置为具有单个线程，循环计数为8。注意，测试计划有一个外部交替控制器，内部有两个交替控制器。

外部交替控制器在两个内部交替控制器之间交替。然后，每个内部Interleave Controller在每个HTTP请求之间交替。每个JMeter线程将按以下顺序发送请求：A1、C、B1、C、A2、C、B2、C。

如果主交替控制器下的两个交替控制器是简单的控制器，则顺序为：A1、A2、C、B1、B2、C。然而，如果在此同时，主交替控制器(O_交替控制器)上选中了

忽略子控制器块

，则顺序为：A1、C、B1、C、A2、C、B2、C。

5、随机控制器

随机逻辑控制器的作用类似于交错控制器，不同之处在于它不是按顺序通过其子控制器和采样器，而是在每次通过时随机选取一个。

另外，需注意，多个控制器之间的交互会产生复杂的行为。随机控制器尤其如此。在假设任何给定的交互都会产生什么结果之前，要先进行测试调试。

6、随机顺序控制器

随机顺序控制器很像简单控制器，因为它最多执行一次每个子元件，但节点的执行顺序是随机的。

7、吞吐量控制器

吞吐量控制器允许用户控制执行的频率。有两种模式：

Percent executions：使控制器在测试计划中执行一定百分比的迭代。

Total executions：使得控制器在发生一定数量的执行之后停止执行。

与

仅一次控制器

类似，此设置在父循环控制器重新启动时重置。此控制器的名称不正确，因为它不控制吞吐量。有关可用于调整吞吐量的元件，因该是

吐量定时器

。

吞吐量控制器在与其他控制器组合时会产生非常复杂的行为，特别是与交织或随机控制器作为父控制器（也非常有用）。

8、Runtime控制器

Runtime控制器

控制其子级将运行多长时间。控制器将运行其子级，直到超过配置的运行时。

9、If 控制器

If 控制器

允许用户控制其下面的测试元素（其子项）是否运行。

对于其中的布尔变量表达式的填写而言，常用的布尔表达式脚本如下：

${__groovy(vars.get("myVar") != "Invalid" )}(Groovy检查 myVar变量的值不等于字符串“Invalid”)${__groovy(vars.get("myInt").toInteger() <=4 )}(Groovy检查 myInt变量的值小于等于4)${__groovy(vars.get("myMissing") != null )}(Groovy 检查 myMissing变量是否为空)${__jexl3(${COUNT}<10)}(计算COUNT变量的值是否小于10)${RESULT}(返回RESULT变量的值，RESULT必须是布尔值)${JMeterThread.last_sample_ok}(检查采样器最近一次运行结果是否PASS)

另外，当变量表达式执行出错时，将直接返回false，同时记录一条日志在jmeter.log文件中，关于__groovy()函数和__jexl3()函数的详细定义，见__jexl3 和 __groovy，其主要用于提高JMeter的运行性能，这两者在使用上最大的不同在于groovy()必须要与vars.get(自定义的变量名)结合使用

10、While控制器

While 控制器

运行其子级，直到条件为“false”，类似于python中的while语句。While 控制器公开索引的取名原则同

循环控制器

，关于此点见本文

四.2 循环控制器

常用变量表达式示例如下：

${VAR}-其中VAR被其他测试元素设置为false
${__jexl3(${C}==10)}${__jexl3("${VAR2}"=="abcd")}${_P(property)} - 其中property在其他地方设置为“false”

11、Switch控制器

Switch控制器

的作用类似于

交替控制器

，因为它在每次迭代中运行一个从属元素，但控制器不是按顺序运行它们，而是运行由切换值定义的元素；类似于Java/C语言中的switch语句。

12、Foreach控制器

ForEach控制器

循环遍历一组相关变量的值。当采样器（或控制器）添加到ForEach控制器时，每个采样（或者控制器）都会执行一次或多次，其中在每个循环期间，变量都有一个新值。输入应由多个变量组成，每个变量都用下划线和数字扩展。每个这样的变量都必须有一个值。

以下图为例说明，更细致的示例下载官网原jmx文件自行调试体会：

13、模块控制器(类似python的函数调用)

模块控制器

提供了一种机制，用于在运行时将测试计划片段替换到当前测试计划中。相当于python中的函数调用引用。

另外，在测试计划中，只有

逻辑控制器

下的子节点集或

测试片段

元件才能称之为模块，相当于python中的函数，才能在模块控制器中被之选择调用。

示例如下：

14、Include控制器(类似python的import)

Include控制器

引用外部已保存为.jmx文件的测试计划作为当前测试计划的一部分，类似于python中的import。但有以下几点需注意：

• 被引用的测试计划的线程组将在包含过程中被忽略；
• 如果测试使用Cookie管理器或用户定义变量，则应将其放在顶级测试计划中，而不是包含的文件中，否则无法保证其正常工作；
• 当两个Include控制器包含同一个JMX文件时，这两个Include控制器的命名必须不同。

15、事务控制器(统计场景响应时间)

事务控制器

生成一个额外的样本，用于测量执行嵌套测试元件所花费的总时间。可用于涉及多个接口请求的业务进行计时统计，事务响应时间是性能测试中衡量业务性能的主要指标。事务即场景，可以将多接口串联的场景自动的分类显示，更易于分类识别整个场景的响应时间。

以下图为例进行说明，以下测试树为

添加用户

的业务，共涉及两个接口，登录接口、添加用户接口，即模拟管理员登录账号后添加用户的场景(业务/事务)：

16、录制控制器

录制控制器

是一个占位符，指示代理服务器应该将样本记录到哪里。在测试运行期间，它没有任何效果，类似于简单控制器。但在使用HTTP（S）测试脚本记录器进行录制时，默认情况下，所有录制的样本都将保存在录制控制器下。

录制控制器常与JMeter

HTTP代理服务器

元件组合使用，如下图：

（1）配置JMeter代理：

（2）配置系统代理(WIN10为例)：

（3）配置浏览器代理(Firefox版本: 111.0 (64 位)为例)：

（4）启动JMeter代理：

（5）访问测试网站：

（6）测试完后，停止JMeter代理服务器，还原所有代理设置：

此时可以看到，录制的各请求已经保存到录制控制器下了，点击运行，即可直接查看运行结果：

结果查看：

17、临界部分控制器(Critical Section Controller)

临界部分控制器

确保其子元素（采样器/控制器等）将仅由一个线程执行，进而控制各并发线程请求的顺序是一样的，因为在执行控制器的子元素之前将获取命名锁。

以下部分参考自：https://blog.csdn.net/qq_38368494/article/details/125841424

临界部分控制器

，本质上是一个锁，对于多线程的线程组而言，同层级无逻辑控制器控制的取样器，执行顺序是按从上往下的顺序执行的，但在多用户并发时，每一个并发用户(线程),也都是从上往下执行的，只是因为是并发，同一时刻，可能有不同用户(线程)做完了不同接口请求，而

查看结果树

只是按照完成时间的先后显示请求结果。

并发请求(线程)这个控制器时，会先根据‘锁名称’生成一个‘锁’，锁定控制器下的所有子元素，等到所有子元素都执行完‘锁’才会释放，下一个请求(线程)才能执行，即，把原本的并发请求的并行处理方式，变成了串行处理。

可以使用随机数函数、时间戳函数、线程数函数等自动生成值的函数就可以修改critical section controller的锁名称为动态值，当某个线程调用时，就会自动生成一个新的锁名称。

如以下，按线程数动态生成锁名称：

五、常用监听器

除了监听测试结果之外，大多数

监听器

还提供了查看、保存和读取保存的测试结果的方法。请注意，侦听器是在其所在范围的末尾进行处理的。另外，所有含GUI页面的监听器都不得在负载测试期间使用，因为它们会消耗大量资源（内存和CPU），仅在功能测试或测试计划调试和验证期间使用它们。

测试结果的保存和读取是通用的。不同的监听器有一个面板，可以通过该面板指定将向其中写入（或从中读取）结果的文件。默认情况下，结果存储为XML文件，通常扩展名为“.jtl”。以CSV形式存储是最有效的选项，但不如XML（另一种可用选项）详细。

侦听器不以

CLI模式

处理示例数据，但如果配置了输出文件，则会保存原始数据。为了分析CLI运行生成的数据，需要将文件加载到相应的监听器中。

要读取现有结果并显示它们，可在监听器的“文件”面板“浏览”按钮打开文件。

1、图形结果(Graph Results)

图形结果

监听器生成一个简单的图，用于绘制所有采样时间。沿着图的底部，以毫秒为单位显示当前样本（黑色）、所有样本的当前平均值（蓝色）、当前标准偏差（红色）和当前吞吐率（绿色）。

吞吐量数字表示服务器每分钟处理的实际请求数。此计算包括添加到测试中的任何延迟以及JMeter自己的内部处理时间。这样计算的好处是，这个数字代表了真实的东西——事实上，被测试的服务器每分钟处理那么多请求，测试人员可以增加线程数量和/或减少延迟，以发现服务器的最大吞吐量。然而，如果测试人员进行的计算考虑了延迟和JMeter的处理，那么就不清楚从这个数字中能得出什么结论。

2、断言结果(Assertion Results)

断言结果

显示每个采样的标签。它还报告作为测试计划一部分的任何断言的失败。如下图：

3、察看结果树(View Results Tree)

察看结果树

显示所有样本响应的树，允许查看任何样本的响应。除了显示响应之外，还可以看到获得此响应所花费的时间，以及一些响应代码。请注意，Request面板仅显示JMeter添加的头。它不显示HTTP协议实现可能添加的任何标头（如Host）。

此页面有非常丰富的响应结果查看器及测试器，以便在设置

响应断言

时进行调试（如正则、Json表达式、JQuery、Xpath等），更多用法见官网View Results Tree。

4、聚合报告(Aggregate Report)

聚合报告

为测试中每个不同名称的请求创建一个表行。对于每个请求，它汇总响应信息，并提供请求计数、最小值、最大值、平均值、错误(异常)率、近似吞吐量（请求/秒）和千字节每秒吞吐量。一旦测试完成，吞吐量就是整个测试期间的实际吞吐量。

吞吐量是从采样器目标（例如，在HTTP采样的情况下是远程服务器）的角度计算的。JMeter会考虑生成请求的总时间。如果其他采样器和定时器在同一个线程中，那么它们将增加总时间，从而降低吞吐量值。因此，两个具有不同名称的相同采样器的吞吐量将是两个具有相同名称的采样器的一半。正确选择采样器名称以从“聚合报告”中获得最佳结果非常重要。

中位数和90的计算 % 行（第90百分位）值需要额外的内存。JMeter现在将具有相同运行时间的样本组合在一起，因此使用的内存要少得多。然而，对于花费几秒钟以上的样本，有可能更少的样本具有相同的时间，在这种情况下，需要更多的内存。请注意，您可以在之后使用此侦听器重新加载CSV或XML结果文件，这是避免性能影响的推荐方法。请参阅

摘要报告

，了解类似的侦听器，该侦听器不存储单个样本，因此需要恒定内存。

5、汇总图(Aggregate Graph)

汇总图

与

聚合报告

类似，主要区别在于

汇总图

提供了一种生成条形图并将图保存为PNG文件的简单方法。

生成的图表如下：

6、汇总报告(Summary Report)

摘要报告为测试中每个不同名称的请求创建一个表行，这与

聚合报告

类似，只是它使用的内存较少。其中吞吐量的计算方式与

聚合报告

是一样的。

7、用表格查看结果(View Results in Table)

此监听器为每个样本结果创建一行。与

查看结果树

一样，此可视化工具使用大量内存。

8、简单数据写入器(Simple Data Writer)

这个监听器可以将结果记录到文件中，但不能记录到UI中。它旨在通过消除GUI开销来提供一种高效的数据记录方式。在CLI模式下运行时，

-l

选项可用于创建数据文件。要保存的字段由JMeter属性定义，有关详细信息，请参阅

jmeter.properties

文件。

9、响应时间图(Response Time Graph)

响应时间图

绘制了一个折线图，显示了测试期间每个标记请求的响应时间的演变。如果同一时间戳存在多个样本，则显示平均值。

运行测试计划后，图例如下：

六、常用定时器

请注意，在发现计时器的范围内，计时器在每个采样器之前进行处理；如果在同一范围内有多个计时器，则所有计时器都将在每个采样器之前进行处理。 计时器只能与采样器一起处理。与采样器不在同一范围内的计时器根本不会被处理。 要将计时器应用于单个采样器，请将计时器添加为采样器的子元素。计时器将在执行采样器之前应用。要在采样器之后应用计时器，可以将其添加到下一个采样器，也可以将其作为

测试活动(Flow Control Action)

采样器的子采样器添加。

1、固定定时器(Constant Timer)

此定时器用于在每个线程在请求之间暂停相同的时间。

以下图所示的测试树为例：

设置固定定时器时：

不设置时：

2、高斯随机定时器(Gaussian Random Timer)

此定时器的作用与

固定定时器

一样，不同点在于此定时器的暂停时间不是固定的，而是发生在固定时间附近的符合高斯分布的随机时间，用于模拟压测时的

思考时间

。

3、统一随机定时器(Uniform Random Timer)

此定时器作用及延时时间的产生同高斯随机定时器，不同在于此定时器产生的随机延时的时间间隔的概率是一样的，总延迟是随机值和偏移值的总和。

4、常数吞吐量定时器(Constant Throughput Timer)

这个定时器引入了可变的暂停，计算的目的是使总吞吐量（以每分钟样本数计）尽可能接近给定的数字，即用于控制JMeter的吞吐量，当然，如果服务器无法处理，或者其他定时器或耗时的测试元素阻止了吞吐量，吞吐量会更低。

以下源自官网的文档有些费解，生动易理解的例子参考链接：https://blog.csdn.net/qq_15055139/article/details/124615470。

共享和非共享算法都旨在产生所需的吞吐量，并将产生类似的结果。 共享算法应该生成更准确的整体交易速率。 非共享算法应该在线程之间生成更均匀的事务分布。

5、同步定时器(Synchronizing Timer),LR中的集合点

同步定时器

的目的是阻止线程，直到X个线程被阻止，然后一次释放所有线程。因此，

同步定时器

可以在测试计划的各个点创建大的即时负载。