1. 项目概述：为什么是JMeter？

如果你是一名软件测试工程师，或者正在向这个方向发展，那么“性能测试”这个词你一定不陌生。当用户抱怨系统卡顿、页面加载缓慢，或者在大促活动时服务器直接宕机，背后往往就是性能测试的缺失。而在这个领域，Apache JMeter几乎是一个绕不开的名字。它是一款100%纯Java开发的开源工具，从1998年诞生至今，已经成为全球范围内最流行、最经典的性能测试工具之一。

我接触JMeter超过十年，从早期的2.x版本用到现在的5.x，看着它从一个简单的Web测试工具，演变成一个支持数据库、消息队列、FTP、TCP等多种协议的全能型测试平台。很多新手可能会被它略显“复古”的图形界面吓到，或者觉得配置起来步骤繁琐。但我想说的是，JMeter的魅力恰恰在于它的“直接”和“强大”。它不依赖任何商业授权，你可以用它来模拟成千上万的虚拟用户，对服务器发起“攻击”，从而精准地找到系统的性能瓶颈——是数据库查询慢了，还是应用服务器内存不足，或者是网络带宽成了瓶颈。

对于初学者而言，掌握JMeter是进入性能测试领域性价比最高的路径。它不仅能帮你理解性能测试的核心概念（如并发用户、响应时间、吞吐量），其丰富的插件生态和灵活的脚本能力，也能满足从简单接口压测到复杂业务场景模拟的几乎所有需求。这篇内容，我将从一个老测试的角度，带你从零开始，彻底搞懂JMeter是什么，以及如何正确地把它“请”到你的电脑上，为后续的实战扫清障碍。

2. JMeter核心架构与工作原理拆解

在动手安装之前，花几分钟理解JMeter是怎么工作的，会让你后续的使用事半功倍。很多人在配置线程组、取样器时感到困惑，本质上是因为没搞清楚其内在逻辑。

2.1 核心组件模型：测试计划是如何执行的？

你可以把JMeter想象成一个戏剧导演。一个完整的性能测试，就是一场由它编排的“大戏”。

• 测试计划 (Test Plan)：这是整场戏的“剧本大纲”。所有其他元素都挂在它下面，它定义了测试的全局设置，比如是否独立运行每个线程组、是否添加函数或用户定义的变量。
• 线程组 (Thread Group)：这是“演员组”。每个线程（Thread）模拟一个虚拟用户（VUser）。你可以定义有多少个这样的“演员”（线程数），他们以多快的速度入场（Ramp-Up Period），以及每个演员要把自己的戏份重复演多少遍（循环次数）。
• 取样器 (Sampler)：这是“演员的具体动作”。比如，HTTP请求取样器代表演员去访问一个网页；JDBC请求取样器代表演员去执行一条SQL语句。它告诉JMeter需要向服务器发送哪种类型的请求。
• 逻辑控制器 (Logic Controller)：这是“剧情编排”。它可以控制取样器的执行顺序，比如循环控制器让某个动作重复执行，仅一次控制器让某个动作只执行一次，事务控制器则把多个动作打包成一个事务来衡量其整体性能。
• 配置元件 (Config Element)：这是“道具和场景配置”。比如，HTTP请求默认值可以设置所有HTTP请求共用的服务器地址和端口；CSV数据文件设置可以从外部文件读取测试数据，实现参数化。
• 前置处理器/后置处理器 (Pre-processors/Post-processors)：这是“动作前后的准备与收尾”。前置处理器在取样器执行前工作，常用于构造请求数据；后置处理器在取样器执行后工作，最常用的就是“正则表达式提取器”或“JSON提取器”，用于从服务器响应中截取我们需要的数据，供后续请求使用。
• 断言 (Assertions)：这是“动作效果的检查员”。用来验证服务器的响应是否符合预期，比如检查响应中是否包含某个关键字，或者响应代码是否为200。
• 监听器 (Listener)：这是“现场的观众和录像机”。它负责收集、展示和保存测试结果。比如“查看结果树”可以看到每个请求和响应的详情，“聚合报告”则生成吞吐量、响应时间、错误率等关键指标的统计报表。

注意：这个“导演-演员-动作”的模型是理解JMeter脚本结构的基础。一个常见的误区是直接在测试计划下添加多个取样器，而不使用线程组。这会导致这些取样器只被一个线程（用户）顺序执行一次，完全无法模拟并发场景。所有模拟用户行为的操作，都必须在线程组这个容器内进行。

2.2 工作原理：并发压力是如何产生的？

JMeter的工作原理并不神秘。当你启动一个测试计划时，会发生以下事情：

1. 启动引擎：JMeter根据线程组的设置，在JVM中创建对应数量的线程。每个线程都是独立的，模拟一个真实的用户。
2. 执行脚本：每个线程（虚拟用户）会在线程组内，按照逻辑控制器的编排，顺序执行其下的取样器、配置元件等。
3. 发送请求：执行到取样器时，JMeter会按照配置（如URL、参数、头信息）构造一个真实的网络请求（HTTP、JDBC等），并发送给目标服务器。
4. 接收响应 & 处理：服务器处理请求并返回响应。JMeter接收到响应后，会依次交给该取样器下的后置处理器、断言进行处理。
5. 记录结果：无论成功与否，该次取样器的执行结果（响应时间、状态、字节数等）都会被发送给所有配置的监听器进行记录和展示。
6. 迭代与结束：一个线程执行完一轮（一次循环）后，根据循环次数的设置，决定是开始下一轮循环，还是退出。当所有线程都执行完毕，或者你手动停止测试，压力测试结束。

关键在于，所有这些线程是并发执行的（当然，受限于你机器的CPU和内存资源）。JMeter通过多线程技术，用一台机器模拟出了成百上千用户同时操作的场景。

2.3 JMeter的优势与局限：它真的是万能的吗？

任何工具都有其适用边界，JMeter也不例外。

核心优势：

• 开源免费：这是它最强大的竞争力，无需为许可证付费，企业和个人可以无负担使用。
• 跨平台：基于Java，真正做到“一次编写，到处运行”，Windows、Linux、macOS上体验一致。
• 协议支持广泛：除了最常用的HTTP/HTTPS，还支持FTP、JDBC、JMS、SOAP、TCP等，通过插件可以扩展更多。
• 功能强大且灵活：丰富的测试元件和强大的逻辑控制能力，可以构建非常复杂的测试场景。配合BeanShell或JSR223处理器，甚至能嵌入Java/Groovy代码实现高度定制化。
• 结果分析能力：自带多种监听器，并能生成HTML报告，便于进行性能分析。
• 社区生态活跃：拥有庞大的用户群和社区，遇到问题容易找到解决方案，插件管理器（Plugins Manager）让功能扩展变得异常简单。

主要局限与注意事项：

• GUI模式耗资源：在图形界面下运行大型测试（如数千线程）会消耗大量客户端资源，可能导致结果不准确。最佳实践是：用GUI模式进行脚本编写和调试，用命令行（非GUI）模式进行真正的压力测试。
• 单机性能瓶颈：一台机器能模拟的虚拟用户数受限于其网络、CPU、内存和端口数。要模拟超大并发，需要使用分布式测试，由一台控制机（Master）调度多台压力机（Slave）共同施压。
• 学习曲线：对于完全新手，需要理解性能测试概念和JMeter自身的元件体系，初期可能觉得复杂。
• 对前端渲染压力模拟不足：JMeter主要模拟的是协议层的请求（如HTTP），对于现代Web应用前端JavaScript执行、页面渲染带来的性能消耗模拟能力较弱。这部分通常需要与浏览器自动化工具（如Selenium）结合，或使用WebDriver Sampler插件。

理解这些，你就能更客观地看待JMeter，知道在什么场景下用它最合适，以及在哪些方面可能需要寻求其他工具或方案的补充。

3. 手把手安装与环境配置指南

知道了JMeter能做什么，接下来就是把它“请”回家。安装JMeter本身极其简单，因为它是一个绿色免安装的软件。真正的关键在于其运行环境——Java的配置。十次安装问题，九次出在Java环境上。

3.1 前置条件：Java环境安装与验证

JMeter是Java程序，所以必须确保系统中已安装合适版本的Java运行环境（JRE）或开发工具包（JDK）。我强烈推荐直接安装JDK，因为它包含了JRE，并且为后续可能需要的脚本开发（如使用JSR223处理器）做好准备。

步骤1：检查现有Java版本打开你的终端（Linux/macOS）或命令提示符/PowerShell（Windows），输入：

java -version

如果显示类似java version "1.8.0_381"或openjdk version "17.0.10"的信息，并且版本号在Java 8 或以上（JMeter 5.x 推荐 Java 8 或 11），那么你可以跳过安装步骤。但请注意，很多电脑预装的是JRE，版本可能较老，建议还是安装最新的JDK。

步骤2：下载与安装JDK访问Oracle官网或OpenJDK发行版网站（如Adoptium）下载JDK。对于新手，我推荐从 Adoptium 下载，它提供了清晰的LTS（长期支持）版本选择。

• 版本选择：选择JDK 11或JDK 17的LTS版本。目前JMeter 5.6+ 对JDK 11和17支持良好，且这两个版本生态成熟稳定。
• 系统选择：根据你的操作系统（Windows x64 Installer, macOS ARM64 DMG, Linux tar.gz等）下载对应的安装包。
• 安装：Windows和macOS运行下载的安装程序，一路“下一步”即可。Linux系统解压tar.gz包到指定目录（如/usr/local/java/）。

步骤3：配置JAVA_HOME环境变量（关键步骤）这是最容易出错的一步。JAVA_HOME是一个指向你JDK安装根目录的环境变量，许多Java应用（包括JMeter）都依赖它来找到Java。

• Windows系统：

  1. 右键点击“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。
  2. 在“系统变量”部分，点击“新建”。
  3. 变量名：JAVA_HOME
  4. 变量值：你的JDK安装路径，例如C:\Program Files\Eclipse Adoptium\jdk-11.0.22.7-hotspot。注意路径中不要包含bin目录。
  5. 找到系统变量中的Path，双击编辑，在末尾新增一条：%JAVA_HOME%\bin。
  6. 依次点击“确定”保存所有窗口。

• macOS / Linux系统： 通常将以下内容添加到你的shell配置文件（如~/.zshrc,~/.bashrc, 或~/.bash_profile）中。

  export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home # macOS示例路径 # 或 export JAVA_HOME=/usr/local/java/jdk-11.0.22 # Linux示例路径 export PATH=$JAVA_HOME/bin:$PATH

  保存文件后，执行source ~/.zshrc（或其他对应的配置文件）使配置生效。

步骤4：最终验证重新打开一个新的命令提示符/终端窗口，依次执行：

java -version javac -version echo %JAVA_HOME% # Windows # 或 echo $JAVA_HOME # macOS/Linux

确保java和javac命令都能正确显示版本，并且JAVA_HOME变量输出正确的路径。至此，Java环境准备完毕。

3.2 JMeter本体下载与安装

JMeter的安装简单到令人发指——其实就是解压缩。

步骤1：前往官网下载访问 Apache JMeter 官网 。点击首页的“Download Releases”链接。在下载页面，你会看到两个版本：

• Binaries：这是我们需要的，包含可执行文件的压缩包（如apache-jmeter-5.6.3.zip）。
• Source：JMeter的源代码，普通用户无需下载。

请下载zip或tgz格式的Binaries文件。建议选择.zip格式，通用性更好。

实操心得：官网下载速度可能较慢，特别是对于国内用户。一个实用的技巧是使用国内的镜像站点。在下载页面，找到“ mirrors ”链接，点击后会列出全球镜像列表，选择距离你较近的镜像（如位于中国的镜像）可以极大提升下载速度。

步骤2：解压到本地目录将下载的压缩包解压到你希望安装的目录。路径中最好不要包含中文或空格，以避免一些潜在的路径解析问题。例如：

• Windows:D:\Tools\apache-jmeter-5.6.3
• macOS/Linux:~/Applications/apache-jmeter-5.6.3或/opt/apache-jmeter-5.6.3

解压后，目录结构如下：

• bin/: 核心目录，包含启动脚本（jmeter.bat用于Windows，jmeter.sh用于Unix/Linux/macOS）以及配置文件。
• lib/: 存放JMeter核心和扩展的JAR包。
• extras/: 一些有用的附加文件，比如用于生成HTML报告的Ant构建文件。
• docs/: 用户手册。
• printable_docs/: 可打印的文档。

步骤3：启动JMeter

• Windows: 进入bin目录，双击jmeter.bat。
• macOS/Linux: 打开终端，进入bin目录，执行sh jmeter.sh或./jmeter.sh。

首次启动可能会稍慢，因为需要加载各种库。成功启动后，你会看到JMeter的图形化界面。恭喜，安装成功！

3.3 基础配置优化与汉化（可选）

安装完成后，有几点基础优化可以让你的使用体验更佳。

1. 内存调整（重要！）默认情况下，JMeter分配的内存可能较小（通常1GB左右），在运行大型测试或使用较多监听器时容易内存溢出（OOM）。我们需要修改bin目录下的JMeter启动脚本。

• Windows: 用文本编辑器（如Notepad++）打开jmeter.bat。
• macOS/Linux: 打开jmeter.sh或jmeter（无后缀）文件。

找到设置JVM参数的行，通常是HEAP相关的设置。修改以下参数（根据你的机器内存调整，建议不超过物理内存的1/4到1/2）：

set HEAP=-Xms1g -Xmx4g -XX:MaxMetaspaceSize=512m

• -Xms1g: 初始堆内存为1GB。
• -Xmx4g: 最大堆内存为4GB。
• -XX:MaxMetaspaceSize=512m: 元空间最大内存（Java 8+）。

保存文件，重启JMeter生效。

2. 界面语言切换JMeter支持多语言，包括中文。在GUI界面中，可以通过菜单栏进行切换：Options->Choose Language->Chinese (Simplified)。切换后界面即刻汉化，对新手非常友好。但请注意，很多专业资料和社区讨论仍使用英文术语，建议熟悉后切换回英文，以便与全球社区接轨。

3. 安装插件管理器（强烈推荐）原生JMeter功能已经很强，但插件生态让它变得无比强大。JMeter Plugins Manager是一个官方推荐的插件管理工具，可以让你轻松搜索、安装和管理数百个社区插件。

1. 从 JMeter Plugins官网 下载plugins-manager.jar。
2. 将下载的JAR文件放入JMeter安装目录的lib/ext子目录下。
3. 重启JMeter。启动后，你会在Options菜单下看到一个新的Plugins Manager选项。 通过它，你可以安装像“Custom Thread Groups”（提供更多并发模型）、“3 Basic Graphs”（更直观的结果图表）、“WebDriver Sampler”（支持浏览器行为模拟）等极其有用的插件。

4. 第一个性能测试脚本实战

理论准备和环境搭建都已就绪，现在让我们通过一个最简单的HTTP接口测试，来感受JMeter的工作流程。我们将创建一个测试计划，模拟10个用户，在5秒内陆续启动，每个用户访问百度首页一次。

4.1 创建测试计划与线程组

1. 启动JMeter：按照上述步骤启动JMeter，你会看到一个空白的“测试计划”。
2. 保存测试计划：首先，点击菜单栏File->Save或Save As...，将空白测试计划保存为一个.jmx文件，例如first_test.jmx。这是一个好习惯，避免意外关闭导致脚本丢失。
3. 添加线程组：右键点击左侧树形结构中的Test Plan->Add->Threads (Users)->Thread Group。线程组是性能测试的基石，所有虚拟用户和他们的行为都在这里定义。

4.2 配置线程组参数

点击新创建的“Thread Group”，在右侧面板中，我们需要配置几个核心参数：

• 线程数（Number of Threads (users)）：输入10。这表示我们将模拟10个虚拟用户。
• Ramp-Up时间（Ramp-Up period (seconds)）：输入5。这表示JMeter将在5秒内启动全部10个线程。如果设置为0，则所有线程立即启动，可能对服务器造成瞬间巨大冲击，不符合大多数真实场景。
• 循环次数（Loop Count）：输入1。每个线程只执行一次其下的所有操作。勾选“永远（Forever）”会让测试一直运行直到手动停止。

核心原理解读：Ramp-Up参数至关重要。假设你设置线程数为100，Ramp-Up为10秒。JMeter会计算出一个启动间隔：10秒 / 100线程 = 0.1秒/线程。它大约每0.1秒启动一个新线程，直到100个线程全部启动。这模拟了用户逐渐进入系统的场景，比“瞬间洪水”更真实，也更容易观察系统在压力逐步增加下的表现。

4.3 添加HTTP请求取样器

现在，我们要告诉这些“用户”具体做什么——访问一个网页。

1. 右键点击Thread Group->Add->Sampler->HTTP Request。
2. 点击新创建的“HTTP Request”，在右侧面板配置：
   • 名称：改为一个有意义的名称，如“访问百度首页”。
   • 协议：http或https。我们访问百度，所以填https。
   • 服务器名称或IP：www.baidu.com。不需要加http://。
   • 端口号：HTTP默认80，HTTPS默认443。对于https://www.baidu.com，端口号留空即可，JMeter会自动使用443端口。
   • 路径：/。表示访问网站根目录。

其他参数如“参数”、“消息体数据”等暂时留空。这样一个最简单的HTTP GET请求就配置好了。

4.4 添加监听器查看结果

如果不添加监听器，测试运行后你将看不到任何结果。监听器就像测试的“仪表盘”。

1. 右键点击Thread Group->Add->Listener->View Results Tree。这个监听器以树形结构展示每个请求和响应的详细信息，非常适合调试。
2. 为了获得聚合统计数据，我们再添加一个Summary Report或Aggregate Report监听器。右键点击Thread Group->Add->Listener->Aggregate Report。这个监听器会生成一个表格，汇总所有请求的响应时间、吞吐量、错误率等关键指标。

4.5 运行测试与分析结果

1. 保存：再次点击保存按钮（Ctrl+S）。
2. 运行：点击工具栏上的绿色“启动”按钮（或按Ctrl+R）。你会看到右上角的状态图标变成绿色，并且监听器开始接收数据。
3. 观察“查看结果树”：在“查看结果树”中，点击左侧的取样器名称，右侧会显示“取样器结果”、“请求”、“响应数据”等标签页。在“响应数据”中，你应该能看到百度首页的HTML源代码。绿色对勾表示请求成功。
4. 分析“聚合报告”：测试运行结束后（10个请求很快完成），查看“聚合报告”。你会看到类似下面的数据：
   • 样本数（# Samples）: 10，代表总共发出了10个请求。
   • 平均值（Average）: 所有请求的平均响应时间（毫秒）。
   • 中位数（Median）: 响应时间的中位数，对异常值不敏感，更能代表一般用户体验。
   • 90%百分位（90% Line）: 90%的请求响应时间小于这个值。这是评估性能的一个重要指标，它告诉我们绝大多数用户的体验上限。
   • 最小值/最大值（Min/Max）: 最快和最慢的响应时间。
   • 异常%（Error %）: 请求的错误率。
   • 吞吐量（Throughput）: 每秒完成的请求数（Requests per Second）。这是衡量系统处理能力的关键指标。
   • 接收/发送KB/秒（KB/sec）: 网络吞吐量。

通过这个简单的测试，你已经完成了从脚本创建、配置、执行到结果分析的完整流程。虽然测试对象很简单，但流程和核心概念与测试一个复杂的电商下单接口并无本质区别。

5. 进阶配置与最佳实践避坑指南

掌握了基础操作后，我们来探讨一些让测试更真实、更高效、更稳定的进阶配置和实践中必须避开的“坑”。

5.1 参数化与数据驱动测试

在真实场景中，用户的操作不是一成不变的。比如登录，每个用户需要使用不同的用户名和密码。这就需要参数化。

• 使用CSV数据文件：这是最常用的参数化方法。
  1. 创建一个CSV文件（如users.csv），内容如下：

     username,password user1,pass1 user2,pass2 user3,pass3

  2. 在线程组下添加一个CSV Data Set Config(Add->Config Element->CSV Data Set Config)。
  3. 配置：
     • Filename: CSV文件的完整路径。
     • Variable Names:username,password(与CSV表头对应)。
     • 其他选项：Recycle on EOF?(文件结束后是否循环) 和Stop thread on EOF?(文件结束后是否停止线程) 根据测试场景选择。
  4. 在HTTP请求中，将用户名和密码字段的值改为${username}和${password}。JMeter在运行时会自动从CSV文件中按行读取数据并替换变量。

避坑技巧：CSV文件路径尽量使用绝对路径，或者将文件放在JMeter的bin目录下使用相对路径。在分布式测试时，需要确保CSV文件在所有Slave机器的相同路径下都存在。

5.2 关联与动态数据提取

很多操作是有关联的。例如，先调用登录接口获取一个token，然后在后续的查询接口中使用这个token。这就需要从服务器响应中提取动态数据。

• 使用后置处理器：最常用的是JSON Extractor(针对JSON响应) 或Regular Expression Extractor(针对文本/HTML响应)。
  1. 在登录请求下，添加一个JSON Extractor。
  2. 配置要提取的变量名（如access_token）、JSON路径表达式（如$.data.token）。
  3. 在后续的请求中，在请求头或参数中使用${access_token}来引用这个值。

5.3 断言：验证结果是否正确

性能测试不仅要测“快不快”，还要测“对不对”。断言就是用来验证服务器响应是否符合预期的元件。

• 添加响应断言：在请求下添加Response Assertion。
  • 可以断言“响应文本”是否包含某个字符串。
  • 可以断言“响应代码”是否等于200。
  • 可以断言“响应头”是否包含特定信息。 如果断言失败，该请求在监听器中会被标记为失败，错误率也会相应增加。

5.4 命令行模式运行与生成HTML报告

如前所述，GUI模式只适合调试。真正的压测必须在命令行（非GUI）模式下进行，以减少客户端资源消耗，获得更准确的结果。

基本命令：

# Windows jmeter -n -t D:\path\to\your_test.jmx -l D:\path\to\test_result.jtl -e -o D:\path\to\html_report_folder # macOS/Linux ./jmeter.sh -n -t /path/to/your_test.jmx -l /path/to/test_result.jtl -e -o /path/to/html_report_folder

• -n: 非GUI模式。
• -t: 指定要运行的JMX测试脚本文件。
• -l: 指定保存原始结果数据的JTL文件路径。
• -e: 测试结束后生成HTML报告。
• -o: 指定生成HTML报告的目录（目录必须为空或不存在）。

HTML报告解读：生成的报告非常专业，包含概述、统计表格、响应时间随时间变化曲线、吞吐量随时间变化曲线等。这是向团队汇报测试结果的绝佳材料。

5.5 常见问题与排查技巧实录

在实际使用中，你肯定会遇到各种问题。这里记录几个最典型的：

问题1：启动JMeter报错“Not able to find Java executable or version.”

• 排查：JAVA_HOME环境变量未正确设置，或者Path中未包含%JAVA_HOME%\bin。
• 解决：严格按照3.1节步骤重新检查和配置环境变量，并确保在新终端中验证。

问题2：运行测试时JMeter卡死或无响应，或抛出“java.lang.OutOfMemoryError”

• 排查：客户端资源（尤其是内存）不足。可能原因：①监听器添加过多（特别是“查看结果树”，它会记录所有请求详情，压力测试时务必禁用或仅用于调试）；②模拟的线程数过多，单机无法承载；③未调整JVM堆内存。
• 解决：
  1. 压测时，在GUI模式禁用所有监听器（右键点击监听器 -> 取消勾选“启用”），或者直接在命令行运行。
  2. 合理设置线程数。单台普通电脑模拟1000-3000个线程是常见上限，取决于请求的复杂度和响应大小。需要更大并发请使用分布式测试。
  3. 按照3.3节调整jmeter.bat或jmeter.sh中的堆内存参数（-Xmx）。

问题3：测试结果中吞吐量（Throughput）远低于预期

• 排查：瓶颈可能不在服务器，而在压力机本身。使用资源监视器（Windows任务管理器，Linux的top或htop）观察压测时JMeter进程的CPU、内存、网络使用率。
• 解决：
  • 如果压力机CPU或网络打满，说明压力机性能不足，需要优化脚本（如减少不必要的监听器）或使用更多/更强的压力机进行分布式测试。
  • 检查JMeter日志（jmeter.log文件），看是否有大量错误或警告。

问题4：模拟登录后，后续请求提示“未登录”或“会话失效”

• 排查：最常见的原因是Cookie或Session未正确处理。HTTP协议是无状态的，服务器通过Cookie（如JSESSIONID）来识别用户会话。如果JMeter没有自动管理Cookie，那么每个请求都被服务器视为新用户。
• 解决：
  1. 在线程组或HTTP请求默认值中，添加一个HTTP Cookie管理器(Add->Config Element->HTTP Cookie Manager)。它会像浏览器一样自动存储和发送Cookie。
  2. 确保你的登录请求成功，并且服务器返回了Set-Cookie头。在“查看结果树”中检查登录请求的响应头。
  3. 对于一些使用Token而非Cookie的系统，则需要使用前面提到的“关联”技术，手动提取Token并添加到后续请求的Header中（如Authorization: Bearer ${access_token}）。

掌握这些进阶技巧和避坑指南，你的JMeter技能就从“能用”进阶到了“好用”和“敢用”。性能测试是一个实践性极强的领域，多动手、多思考、多分析，每一次遇到的问题和解决的过程，都是宝贵的经验积累。