很多朋友刚开始接触接口测试和性能测试时习惯先去搜索各种工具然后发现 Jmeter 的资料虽然多但大多比较零散有的只讲安装有的只讲某个元件很少有能把接口测试和性能测试串起来、带着真实项目走一遍的完整教程。本文就围绕 Jmeter 接口测试与 Jmeter 性能测试这两条主线从零开始搭建环境再通过一个模拟电商项目中的真实接口场景一步步完成接口请求、参数化、关联、断言以及性能测试中的线程组设置、监听器分析和结果解读。无论你是刚入门测试的新人还是准备在项目中落地压测的开发者都可以对照本文操作。1. 接口测试与性能测试为什么要选 Jmeter在动手操作之前先把概念理清楚。很多初学者容易把“接口测试”和“性能测试”混为一谈或者觉得它们是两套完全独立的东西。实际上两者关系非常紧密接口测试保证了单个接口的功能正确性性能测试则验证了接口在并发压力下的稳定性。而在 Jmeter 里这两类工作可以共用同一套脚本体系这也是 Jmeter 在测试领域长期占据重要位置的原因。1.1 接口测试到底是测什么服务端接口测试本质上是在不经过页面 UI 的情况下直接对后端提供的 HTTP 接口发起请求然后验证返回的数据是否符合预期。比如一个登录接口我们需要验证传入正确的用户名密码是否返回 token 和用户信息。传入错误的密码是否返回明确的错误码。缺少必填参数时接口是否给出参数校验提示。请求方法用错时比如 GET 写成 POST是否返回 405。这些验证内容用 Jmeter 都可以完成。Jmeter 通过线程组模拟请求发起方用 HTTP 请求采样器组装请求数据再用断言来判断返回结果是否正确。整个流程不需要写复杂的代码通过图形界面拖拽配置即可完成。1.2 性能测试解决什么问题性能测试的核心是回答三个问题系统能承受多少并发用户在并发过程中响应时间是否满足要求系统在持续压力下会不会崩溃或出现资源耗尽Jmeter 通过线程组中的线程数、循环次数、Ramp-Up 时间来模拟不同规模的并发请求。注意这里的“线程数”并不完全等同于“真实用户数”因为 Jmeter 线程会以最快速度不间断地发送请求。更准确的理解是线程数代表“同时活跃的请求数量”而真实用户场景通常还需要通过常数吞吐量定时器或将思考时间考虑进来。1.3 为什么 Jmeter 是入门首选相比 LoadRunner、Apifox、Postman 等工具Jmeter 的优势非常明显Apache 开源免费安装包小跨平台支持 Windows、macOS、Linux。基于 Java 开发只要本机有 JDK 即可运行。插件生态丰富支持各种协议和监控集成。既适合单接口调试也适合复杂场景压测。脚本本质是 XML 文件方便团队共享和后续集成到 CI/CD 流水线。当然这并不是说其他工具不好。比如 Postman 在接口调试的便捷性上非常好Apifox 在接口文档管理和 Mock 方面有优势LoadRunner 在企业级大型压测中依然有市场。但在“接口测试 性能测试一体化学习”这件事上Jmeter 仍然是最适合系统学习的工具。2. 环境准备JDK 与 Jmeter 安装配置Jmeter 本身不需要安装解压即用但它依赖 Java 运行环境。所以在安装 Jmeter 之前先确保本机 JDK 正确安装并配置好了环境变量。2.1 JDK 安装与环境变量配置建议使用 JDK 8 或 JDK 11。较新的 Jmeter 5.x 版本对 JDK 版本有一定要求通常 JDK 8 以上即可但为了避免兼容问题推荐 JDK 11。以 Windows 为例安装 JDK 后需要配置 JAVA_HOME。验证是否安装成功打开命令行并输入java -version如果显示类似下面信息说明 JDK 配置成功java version 1.8.0_301 Java(TM) SE Runtime Environment (build 1.8.0_301-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode)如果提示“java 不是内部或外部命令”说明环境变量没有配置好需要检查 JAVA_HOME 和 Path。2.2 Jmeter 下载与启动Jmeter 官方下载地址是 Apache Jmeter 官网推荐下载二进制版本例如 apache-jmeter-5.6.3.zip。下载完成后解压到本地目录注意路径中尽量不要包含中文和空格否则某些版本的 Jmeter 在后续保存脚本时可能出现乱码问题。解压后的目录结构大致如下apache-jmeter-5.6.3/ ├── bin/ ├── docs/ ├── extras/ ├── lib/ └── LICENSE进入 bin 目录Windows 用户双击 jmeter.bat 启动图形界面macOS 或 Linux 用户执行 jmeter.sh。cd apache-jmeter-5.6.3/bin sh jmeter.sh启动后出现 Jmeter 主界面默认会有一个测试计划节点。为了后续操作稳定建议在启动前先确认一下 Jmeter 界面语言。如果显示英文可以通过菜单栏 Options - Choose Language 切换为中文方便新手学习。中文选项中有“简体中文”选择后立即生效无需重启。2.3 快速验证安装是否正常启动成功后先做一个最简单的验证在测试计划下新增线程组和 HTTP 请求访问一个公开接口比如 httpbin.org 的 GET 接口然后运行看结果。在这里只强调一个点Jmeter 默认启动的是 GUI 模式这种模式适合脚本调试但不适合实际压测。真正压测时建议使用命令行模式jmeter -n -t test.jmx -l result.jtl -e -o report后面的实战环节会专门讲解命令行压测和报告生成。3. Jmeter 核心元件剖析Jmeter 的脚本并不是简单地把请求发给服务器而是由各种“元件”组合成完整的测试逻辑。理解这些元件的分类和作用是学会 Jmeter 的关键。很多新手一开始就陷入“一个一个按钮乱点”的状态根本原因就是没有建立 Jmeter 的元件体系认知。3.1 元件分类Jmeter 的元件按照功能可以分为以下几类配置元件用来提供变量、CSV 数据、默认请求属性等。比如 CSV 数据文件设置、HTTP 请求默认值。前置处理器在请求发送之前执行常用于参数预处理、签名生成。取样器真正发送请求的元件。HTTP 请求、JDBC 请求、Debug 采样器都属于取样器。后置处理器在请求返回之后执行常用于从响应中提取数据。正则表达式提取器、JSON 提取器都属于这一类别。断言验证响应是否符合预期比如响应断言、JSON 断言、持续时间断言。监听器收集和展示测试结果比如查看结果树、聚合报告、图形结果。定时器控制请求发送的频率模拟用户思考时间。逻辑控制器控制请求执行逻辑如循环控制器、如果控制器、事务控制器。这里有一个常见误区测试计划和线程组不属于以上任何单一分类它们是整个脚本的“容器”结构。测试计划是根节点线程组是具体执行场景的入口。3.2 测试计划与线程组测试计划是 Jmeter 脚本的最顶层结构。测试计划中可以添加“用户自定义变量”这些变量对整个脚本全局有效。比如服务器地址、端口号、公共请求头等都可以放在这里。线程组是具体执行场景的容器。线程组中有几个重要参数参数作用示例线程数模拟并发请求的数量10Ramp-Up 时间线程启动到全部启动所需秒数5循环次数每个线程执行的次数100调度器是否按持续时间或启动延迟来执行勾选后设置持续时间 600 秒线程数和循环次数的组合决定了总的请求量。比如线程数 10、循环次数 100总请求数就是 1000。3.3 取样器与监听器取样器中最常用的是 HTTP 请求。HTTP 请求中需要配置协议、服务器名称或 IP、端口号、方法、路径、请求体等。监听器用来观察测试结果。常用的几个监听器包括查看结果树调试脚本时最常用可以查看每个请求的请求数据和响应数据。聚合报告统计总请求数、平均响应时间、中位数、90% 响应时间、错误率、吞吐量。图形结果展示响应时间随请求变化的趋势。性能测试时查看结果树这种监听器会严重影响 Jmeter 自身性能所以在压测阶段不应该使用它。压测过程中直接使用命令行模式结束后再打开聚合报告或生成 HTML 报告。4. 接口测试项目实战模拟电商系统登录到下单全流程下面进入真正的项目实战。为了贴近真实环境这里以“模拟电商平台”为例完成从登录、查询商品、添加购物车到提交订单的完整接口链路测试。整个流程会覆盖 Jmeter 的常用功能参数化、关联、断言、事务控制器。4.1 项目接口说明假设被测系统提供了以下接口本文以模拟接口地址演示实际测试时替换为真实环境接口名称请求方法路径说明用户登录POST/api/user/login入参 username、password返回 token商品列表GET/api/product/list需要请求头 token返回商品列表添加购物车POST/api/cart/add入参 productId、quantity需要 token提交订单POST/api/order/submit入参 cartId、addressId需要 token这些接口之间存在依赖关系登录后才能调用商品列表添加购物车需要商品 ID提交订单需要购物车 ID。这正是接口测试中典型的“关联”场景。4.2 创建测试计划与线程组打开 Jmeter在测试计划上右键选择“添加 - 线程用户 - 线程组”。线程组名称修改为“电商接口测试线程组”。线程数设置为 1循环次数设置为 1因为这是功能性的接口测试先保证流程正确不涉及并发。接下来在线程组下添加 HTTP 请求默认值。作用是将服务器地址、端口号等公共信息提取出来这样每个 HTTP 取样器就不需要重复填写服务器地址。右键线程组 - 添加 - 配置元件 - HTTP 请求默认值填写协议http服务器名称或 IPdemo-api.example.com端口号8080然后添加 HTTP 信息头管理器添加 - 配置元件 - HTTP 信息头管理器请求头中添加 Content-Type: application/json后续所有请求都会带上这个头。4.3 第一个接口用户登录在线程组下添加 HTTP 请求名称修改为“用户登录”。配置内容方法POST路径/api/user/login请求体{ username: testuser, password: 123456 }在 Body Data 标签页中填入上述 JSON。运行后在查看结果树中可以看到响应。为了验证接口是否正确在线程组下添加“查看结果树”监听器运行脚本查看响应内容。正常响应类似{ code: 200, message: success, data: { token: eyJhbGciOiJIUzI1NiJ9.xxx, userId: 1001, nickname: 测试用户 } }这里返回的 token 是后续接口的“通行证”需要提取出来。这就是接口测试中非常重要的“关联”操作。4.4 使用 JSON 提取器完成 token 关联Jmeter 中提取 JSON 响应内容推荐使用 JSON 提取器。右键“用户登录”请求 - 添加 - 后置处理器 - JSON 提取器。配置如下变量名称loginTokenJSON 路径表达式$.data.token匹配编号1默认值TOKEN_NOT_FOUND设置完成后后续请求可以通过 ${loginToken} 引用这个 token 值。如果接口返回的不是标准 JSON或者 JSON 路径表达式不够用可以使用正则表达式提取器。比如正则表达式token:([^])模板$1$匹配编号1这里需要理解一个概念JSON 提取器适用于响应体是 JSON 格式的接口正则提取器适用范围更广但编写规则需要更仔细。接口响应是标准 JSON 时优先使用 JSON 提取器更直观、更稳定。在登录接口后面再添加一个 HTTP 信息头管理器通过“添加配置元件”的方式将 token 放到请求头中Authorization: Bearer ${loginToken}注意这个信息头管理器要放在登录接口之后的层级下这样后面的商品列表、添加购物车、提交订单接口就会自动携带这个请求头。4.5 第二个接口商品列表与商品 ID 提取添加 HTTP 请求名称为“商品列表”。方法GET路径/api/product/list运行后响应中会返回商品列表{ code: 200, data: [ { productId: 501, productName: 手机, price: 1999 }, { productId: 502, productName: 耳机, price: 299 } ] }后续添加购物车需要用到 productId这里继续用 JSON 提取器提取第一个商品的 ID变量名称productIdJSON 路径表达式$.data[0].productId匹配编号1默认值PRODUCT_NOT_FOUND如果是提取全部商品 ID 用于循环测试可以把匹配编号设为 -1表示匹配所有结果但那样变量的引用方式是 ${productId_1}、${productId_2}使用时会稍复杂。初学者先掌握提取第一个元素就足够。4.6 第三个接口添加购物车与购物车 ID 提取添加 HTTP 请求名称为“添加购物车”。方法POST路径/api/cart/add请求体{ productId: ${productId}, quantity: 1 }这里的 ${productId} 引用前面提取到的商品 ID。运行后如果接口正常会返回 cartId 或 cartItemId。同样使用 JSON 提取器提取变量名称cartIdJSON 路径表达式$.data.cartId匹配编号1默认值CART_NOT_FOUND4.7 第四个接口提交订单添加 HTTP 请求名称为“提交订单”。方法POST路径/api/order/submit请求体{ cartId: ${cartId}, addressId: 8001 }到此一个完整的“登录 - 查询商品 - 加购 - 下单”的接口链路就完成了。运行整个测试计划如果一切正确四个请求都会显示绿色成功状态。4.8 添加响应断言只有请求成功还不够还需要验证接口返回的数据是否正确。Jmeter 中常用响应断言来校验响应内容是否包含某个关键字。右键“用户登录”请求 - 添加 - 断言 - 响应断言。配置响应字段响应文本匹配规则包含测试模式success这样如果登录接口返回的文本中没有包含“success”字符串断言就会失败请求会被标记为红色。更严谨的接口测试建议针对每个接口分别添加合理的断言。比如商品列表接口断言包含“productName”添加购物车接口断言包含“cartId”。断言不是越多越好但也不能完全不写。完全没有断言的脚本即使接口返回 500只要响应时间正常在 Jmeter 中也不会被判定为失败这会严重影响后续性能测试结果的可信度。4.9 接口测试中的参数化真实的测试场景中不可能所有用户都使用同一个账号。Jmeter 的参数化就是让不同请求使用不同的测试数据。Jmeter 常用参数化方案有用户自定义变量使用固定值适合稳定的环境参数。CSV 数据文件设置从外部文件读取数据适合大量用户数据。函数助手比如 __Random、__time 等动态函数。CSV 数据文件设置是最常用的。首先准备一个 data.csv 文件username,password user001,123456 user002,123456 user003,123456在线程组下添加“配置元件 - CSV 数据文件设置”配置文件名/path/to/data.csv文件编码UTF-8变量名称username,password分隔符,然后修改登录请求的 Body Data{ username: ${username}, password: ${password} }这样每个线程执行时都会从 CSV 中取出一行数据。这里需要注意一个细节如果并发执行时 CSV 数据文件中的数据量少于线程数可能出现数据不足的问题。生产级压测时要确保测试数据足够或者开启 CSV 数据文件设置中的“循环”选项。4.10 接口同时跑多个线程的实践很多朋友会遇到“模拟登录后同时跑 5 个线程跑查询接口”的需求。比如先用一个账号登录然后让 5 个并发用户同时查询商品列表。实现方式有两种方式一在同一个线程组中通过“常数吞吐量定时器”或“同步定时器”控制并发节奏。但这种方式比较粗糙不容易精确模拟“只对查询接口并发”的场景。方式二使用“setUp 线程组 普通线程组”。setUp 线程组先执行登录登录得到的 token 以属性props方式保存普通线程组中的 5 个线程在请求时读取该属性。setUp 线程组中登录脚本添加 JSR223 后置处理器使用 Groovy 脚本把 token 存到全局属性中props.put(globalToken, vars.get(loginToken));普通线程组的查询接口请求头中可以直接引用${__P(globalToken,)}。这样就能实现“先登录一次再并发查询”的常见场景。5. Jmeter 性能测试完整实战接口测试通过后接下来进入性能测试环节。性能测试不是简单地把线程数调大而是有一套标准的步骤和指标解读方法。5.1 性能测试的完整步骤标准性能测试流程可以拆成以下步骤确定性能测试目标。比如系统需支持 500 并发用户平均响应时间小于 2 秒错误率低于 1%。准备测试环境。尽量使用与生产环境隔离的测试环境避免压测影响线上业务。编写或复用接口测试脚本。设置性能测试场景。比如阶梯加压、持续压测、峰值压测。执行压测。通过命令行方式运行避免 GUI 性能干扰。监控系统资源。查看 CPU、内存、网络、数据库连接池等指标。分析测试结果。输出聚合报告、HTML 报告定位瓶颈。回归验证。优化后重新压测对比结果是否改善。5.2 性能测试线程组设置以“模拟登录后同时跑 5 个线程跑查询接口”为例把普通线程组配置为线程数5Ramp-Up 时间1循环次数100Ramp-Up 时间的作用是让线程在指定时间内逐步启动而不是瞬间同时发起。如果 Ramp-Up 设置为 1代表 5 个线程在 1 秒内全部启动基本上属于瞬时并发。如果要做更真实的容量测试建议线程数设置为 50Ramp-Up 时间设置为 10循环次数设置为 200。此时总请求量为 10000。还可以结合“聚合报告”观察响应时间分布。聚合报告中的关键指标解读指标含义参考标准Samples总请求数-Average平均响应时间越小越好Median50% 请求的响应时间比 Average 更能反映典型体验90% Line90% 请求的响应时间反映大多数用户感受95% Line95% 请求的响应时间反映压力下的体验99% Line99% 请求的响应时间反映极端情况Min / Max最小/最大响应时间关注 Max 是否有尖刺Error %错误百分比目标通常小于 1%Throughput吞吐量每秒处理请求数越大越好5.3 性能测试命令行的使用GUI 模式跑压测有个致命问题Jmeter 自身的界面渲染、监听器数据收集都会消耗系统资源导致压测结果不准确。特别是在大并发场景下GUI 模式本身就是瓶颈。正确做法是使用命令行模式。将脚本保存为 test_plan.jmx放到 bin 目录下或指定路径执行jmeter -n -t test_plan.jmx -l result.jtl -e -o report参数说明-n非 GUI 模式。-t指定测试脚本路径。-l指定结果文件路径保存为 JTL 格式。-e测试结束后生成 HTML 报告。-oHTML 报告输出目录。注意结果文件和报告目录不能已存在否则会报错。如果希望保留多次压测结果建议每次压测都创建新的目录例如 report_20260316_001 这样的命名方式。执行过程中控制台会输出实时进度summary 2000 in 00:00:10 200.0/s Avg: 450 Min: 210 Max: 1200 Err: 0 (0.00%) summary 3000 in 00:00:15 200.0/s Avg: 480 Min: 200 Max: 1500 Err: 10 (0.33%)这一行数据包含了实时吞吐量、平均响应时间、错误率等信息。压测结束后打开 report 目录下的 index.html可以看到 Jmeter 生成的 HTML 报告包含图形化的性能指标、响应时间分布、错误统计、吞吐量趋势等信息。这个报告用于团队评审和性能分析非常方便。5.4 参数化在性能测试中的应用性能测试中参数化同样重要。但需要特别注意如果性能测试脚本中使用了 CSV 参数化要确保 CSV 文件中的数据量远大于总请求数否则会出现“数据用尽”的情况。CSV 数据文件设置中有两个选项“遇到文件结束符再次循环”和“停止线程”需要按照测试目标选择。如果希望模拟不同用户名的并发登录可以在 CSV 数据文件设置中勾选“遇到文件结束符再次循环”这样数据会重复使用。但如果 token 登录会被服务端去重重复使用同一账号可能造成数据冲突这时需要准备足够多的测试账号。6. 常见问题与排查思路Jmeter 使用过程中新手会遇到各种各样的问题。这里整理几个高频问题并给出排查思路。问题现象常见原因解决思路启动 jmeter.bat 闪退JDK 未安装或环境变量配置错误先执行 java -version 验证 JDK再检查 JAVA_HOME 和 Path脚本中出现中文乱码文件编码不一致测试计划中设置编码为 UTF-8Jmeter 的 jmeter.properties 中修改 sampleresult.default.encodingUTF-8请求返回 403 或 401缺少请求头或 token 失效检查 HTTP 信息头管理器确认 token 是否成功提取并在后续请求中正确引用响应结果中文乱码响应编码与 Jmeter 默认 ISO-8859-1 不一致在后置处理器或 BeanShell 中处理编码或修改 Jmeter 全局编码为 UTF-8CSV 文件数据没有生效文件路径错误或分隔符不匹配检查文件路径是否绝对路径确认 CSV 中的分隔符和配置项一致聚合报告中吞吐量很高但响应时间也很高可能测试本身处于过载状态分析 90% Line 和 99% Line判断是否存在响应时间尖刺Jmeter 自身占用了过多 CPU 和内存GUI 模式下有大量监听器压测时使用命令行模式去掉查看结果树等调试监听器Token 提取失败后续接口全部失败JSON 路径写错或响应结构变了先用查看结果树查看响应确认 JSON 路径正确必要时使用 JSON 断言先验证返回结构关于 Jmeter 安全证书的问题也需要补充当录制或测试 HTTPS 接口时Jmeter 会提示证书不受信任或者请求返回握手失败。解决方案分为两种如果是测试环境可以在 Jmeter 的 bin 目录下找到 ApacheJMeterTemporaryRootCA.crt 证书并导入到本机受信任的根证书颁发机构如果是生产环境的业务接口一般由企业统一签发证书不需要 Jmeter 再去生成临时证书。7. 最佳实践与工程建议Jmeter 的脚本是测试团队的资产脚本质量直接影响测试的准确性和可维护性。以下是一些来自实际项目的建议。7.1 脚本命名与结构规范每个线程组、取样器、监听器都必须有清晰可读的名称。建议在取样器名称中包含被测接口的含义比如“登录-获取token”“商品列表-查询”。添加断言时断言名称要说明验证点比如“断言-登录返回success”。测试计划中不要出现无意义的默认名称比如“HTTP 请求”。7.2 配置与脚本分离将服务器地址、端口号、测试环境标识等配置放到“用户自定义变量”或“HTTP 请求默认值”中。不同环境的配置建议使用独立的 properties 文件或通过命令行参数传入而不是每个脚本都写死一遍。使用 -J 参数可以在命令行中动态指定属性值例如jmeter -n -t test_plan.jmx -Jserver.hosttest.example.com -Jserver.port8080 -l result.jtl -e -o report这样一来同一份脚本可以在测试环境、预发环境、生产环境之间灵活切换无需修改脚本文件。7.3 性能测试中的数据与监控压测前确认测试数据量充足尤其是登录账号、商品 ID 等业务主键数据。压测时不仅看 Jmeter 的响应指标还要关注被测服务器的 CPU、内存、磁盘 IO、网络带宽、数据库连接池等指标。推荐使用 Jmeter InfluxDB 插件 Grafana 实现实时性能监控。Jmeter 将测试数据写入 InfluxDBGrafana 从 InfluxDB 读取数据生成可视化仪表盘可以实时查看吞吐量、响应时间、错误率等关键指标的变化趋势。性能测试报告要保留现场信息压测时间、版本号、线程数、测试数据量、服务器配置等否则发现问题后难以回溯。7.4 HTTP 请求中的异常处理接口测试过程中建议开启“从 HTML 文件获取所有内含的资源”时谨慎使用。性能测试中除了被测接口外不要勾选这个选项否则 Jmeter 会额外请求页面中的图片、CSS、JS 等静态资源干扰压测结果。另外HTTP 请求中“跟随重定向”和“自动重定向”的区别需要理解自动重定向只适用于 GET/HEAD 请求而且不会记录重定向过程跟随重定向会记录每一步重定向请求适用于 POST 后返回 302 再跳转的场景。在接口测试中建议使用“跟随重定向”便于定位问题。7.5 日志与结果保存使用命令行压测时-l 参数生成的 JTL 文件是原始结果数据建议每次都保留。HTML 报告目录以时间戳命名例如 report-20260316-1400避免覆盖历史报告。调试脚本时使用查看结果树正式压测时务必移除或禁用该监听器。8. 学习路线与后续扩展到此你已经完成了从 Jmeter 安装、接口测试脚本编写、参数化与关联、性能测试场景设置到结果分析的一整套流程。这套知识体系足够支撑你在日常工作中独立完成中小型项目的接口测试和性能摸底。接下来如果想继续深入可以从下面几个方向选择深入学习 Jmeter 函数与 BeanShell/JSR223 脚本完成更复杂的签名生成、加密参数、响应解密等场景。学习 Jmeter 分布式压测解决单机无法模拟大并发的问题。学习 Jmeter 与 Maven/Jenkins 集成把接口测试和性能测试接入 CI/CD 流水线。学习 InfluxDB Grafana Jmeter 的实时监控体系打造团队级性能测试平台。了解其他测试工具比如 Postman、Apifox、LoadRunner 的适用场景做横向对比但不要盲目切换。最后建议你动手把本文的模拟电商接口流程完整地操作一遍。可以从简单的登录接口开始先把环境跑通再逐步增加商品查询、加购、下单的关联逻辑最后加大线程数观察响应时间的变化。性能测试没有捷径多跑几次不同的场景配置看实际数据来理解线程数、Ramp-Up 时间、循环次数和最终吞吐量之间的关系会比背任何理论都有效。如果本文对你有帮助可以收藏备用。后续遇到 Jmeter 的报错或性能测试指标问题也欢迎在评论区交流。