1. 项目概述：为什么选择JMeter作为性能测试的起点？

如果你刚接触软件测试，尤其是性能测试，听到JMeter这个名字可能既熟悉又陌生。它不像Postman那样在接口调试领域家喻户晓，也不像LoadRunner那样带着“昂贵”和“企业级”的光环。但在我十多年的测试生涯里，JMeter一直是我工具箱里最可靠、最常用的一把“瑞士军刀”。简单来说，JMeter是一个100%纯Java开发的、开源免费的桌面应用，主要用于对服务器、网络或对象模拟巨大的负载，进行性能测试、压力测试和功能测试。它最初是为测试Web应用而设计，但现在已经扩展到了数据库、FTP、LDAP、SOAP/REST Web Services等多种协议。

为什么我强烈建议零基础的测试新人从JMeter开始？原因很直接： 门槛低，上限高，生态成熟 。门槛低体现在它完全免费，图形化界面操作直观，不需要你一开始就写复杂的脚本；上限高是指它支持高度自定义的插件和脚本（BeanShell/Groovy），足以应对企业级复杂的性能测试场景；生态成熟则意味着你在网上几乎能搜到任何问题的解决方案，社区活跃，插件丰富。无论是想测试一个简单的网页打开速度，还是模拟上万用户同时抢购的电商场景，JMeter都能胜任。对于开发、测试、运维乃至产品经理，了解JMeter都能让你对系统的“抗压能力”有一个量化的认知，这在今天高并发的互联网环境下至关重要。

2. 环境准备：稳扎稳打搭建测试基石

在兴奋地双击JMeter图标之前，我们必须先把它的“地基”——Java环境给打好。很多新手卡在第一步，就是因为忽略了环境配置。

2.1 JDK的选择与安装

JMeter运行依赖于Java环境，更准确地说，是JDK（Java Development Kit）。这里有个关键点： JMeter 5.4.1及以上版本需要JDK 8或11 。更高版本的JDK（如17、21）可能存在兼容性问题，官方并未完全支持。

操作步骤：

  1. 确认与下载 ：访问Oracle官网或OpenJDK发行版（如Adoptium）网站。对于新手，我推荐直接使用 OpenJDK 11 (LTS版本) ，它免费且长期支持。下载对应你操作系统（Windows/macOS/Linux）的安装包。
  2. 安装过程 ：在Windows上，运行安装程序，记住你的安装路径（例如 C:\Program Files\Java\jdk-11.0.xx ）。在macOS上，通常下载的是 .dmg 或 .pkg 文件，按向导安装即可。Linux用户可以使用包管理器，如 sudo apt install openjdk-11-jdk 。
  3. 验证安装 ：打开命令行（Windows的CMD或PowerShell，macOS/Linux的Terminal），输入 java -version 。如果正确显示类似 openjdk version “11.0.xx” 的信息，恭喜你，第一步成功了。

注意 ：仅仅安装还不够，通常安装程序会自动配置 JAVA_HOME 环境变量。但为了保险起见，最好手动检查一下。在Windows中，可以搜索“环境变量”进行查看和设置； JAVA_HOME 的值就是你的JDK安装目录。

2.2 JMeter的下载与“绿色”安装

JMeter的安装可能是你经历过最简单的“安装”——它根本不需要安装程序，是一个纯绿色的压缩包。

操作步骤：

  1. 官方下载 ：前往Apache JMeter官网的下载页面。建议下载最新的稳定版（如写作时的5.6.3）。你会看到一个 apache-jmeter-5.6.3.zip （Windows）或 .tgz （macOS/Linux）的文件。
  2. 解压即用 ：将这个压缩包解压到你电脑上任意一个你容易找到的目录，比如 D:\Tools\ 或 /Users/YourName/Applications/ 。解压后的文件夹就是JMeter的全部，你可以把它理解为一个便携软件。
  3. 启动JMeter ：
    • Windows ：进入解压后的 bin 目录，双击 jmeter.bat 文件。
    • macOS/Linux ：打开终端，进入 bin 目录，运行 ./jmeter.sh 。

第一次启动可能会稍慢，因为需要初始化。成功后，你会看到JMeter的图形化界面。至此，你的性能测试实验室就搭建完毕了。

实操心得 ：我习惯在桌面创建一个 jmeter.bat （Windows）的快捷方式，这样以后启动更方便。右键 jmeter.bat ，选择“发送到”->“桌面快捷方式”即可。另外，如果启动时命令行窗口一闪而过，通常是环境变量 JAVA_HOME 没设置对，回头检查那一步。

3. 核心界面初探：认识你的指挥中心

第一次打开JMeter，界面上的各种菜单和树形结构可能会让人有点懵。别担心，我们不需要一下子掌握所有，先认识几个最核心的“指挥单元”。

测试计划 (Test Plan) ：这是JMeter脚本的根容器，所有其他元件都组织在它之下。你可以把它想象成一个项目的总纲。在开始前，最好给它起个有意义的名称，比如“用户登录接口压测”。

线程组 (Thread Group) ：这是JMeter场景设计的核心，定义了模拟用户的并发模型。右键“测试计划” -> “添加” -> “线程（用户）” -> “线程组”即可添加。线程组里有几个关键参数：

  • 线程数（用户数） ：模拟的并发用户数量。比如设为100，就是模拟100个用户同时操作。
  • Ramp-Up时间（秒） ：所有线程启动完毕所需的时间。如果线程数=100，Ramp-Up=10，意味着JMeter会在10秒内均匀地启动这100个线程，而不是瞬间同时启动。这更符合真实场景。
  • 循环次数 ：每个线程执行测试计划的次数。如果勾选“永远”，则会一直执行，直到手动停止。

取样器 (Sampler) ：告诉JMeter发送什么类型的请求。最常用的是 HTTP请求 。右键“线程组” -> “添加” -> “取样器” -> “HTTP请求”。在这里你需要配置服务器名称（域名或IP）、端口、请求路径（Path）、请求方法（GET/POST等）。

监听器 (Listener) ：用来查看、分析和保存测试结果。JMeter提供了很多监听器，最常用的是“查看结果树”和“聚合报告”。 “查看结果树” 可以让你看到每一个请求和响应的详细信息，用于调试脚本非常方便。 “聚合报告” 则提供了整体的性能数据概览，如平均响应时间、吞吐量、错误率等。

逻辑控制器、配置元件、断言、前置/后置处理器 ：这些是更高级的元件，用于控制逻辑（如循环、条件判断）、管理配置（如HTTP头、Cookie）、验证结果（检查响应内容）和处理数据（提取变量）。我们第一个测试可以先不用，后续再深入。

工作流程 ：一个最简单的测试逻辑就是： 测试计划 包含一个 线程组 ，线程组下挂着一个 HTTP请求取样器 ，然后添加一个 监听器 来看结果。JMeter会按照这个结构，启动指定数量的线程（虚拟用户），每个线程按顺序执行其下的取样器（发送请求），并将结果反馈给监听器。

4. 第一个实战测试：对百度首页发起性能探测

理论说得再多，不如亲手跑一个。我们就以访问百度首页为例，完成第一个完整的性能测试脚本。

4.1 创建与配置测试脚本

  1. 新建测试计划 ：启动JMeter，默认会新建一个空的测试计划。我们将其重命名为“我的第一个JMeter测试”。
  2. 添加线程组 ：右键测试计划 -> 添加 -> 线程（用户） -> 线程组。在右侧面板中，设置：
    • 线程数：5 （我们先模拟5个用户，小试牛刀）
    • Ramp-Up时间：1 （在1秒内启动这5个用户）
    • 循环次数：2 （每个用户访问2次）
  3. 添加HTTP请求 ：右键线程组 -> 添加 -> 取样器 -> HTTP请求。这个HTTP请求代表用户的一个操作。配置如下：
    • 名称：访问百度首页
    • 协议： https
    • 服务器名称或IP： www.baidu.com
    • 端口号：443 （HTTPS默认端口，可以不填，JMeter会根据协议自动识别）
    • HTTP请求： GET
    • 路径： / （访问根路径，即首页）
  4. 添加监听器 ：我们需要添加两个监听器来观察结果。
    • 查看结果树 ：右键线程组 -> 添加 -> 监听器 -> 查看结果树。这个用于调试，可以看到每次请求的详情。
    • 聚合报告 ：右键线程组 -> 添加 -> 监听器 -> 聚合报告。这个用于查看整体性能指标。

4.2 执行测试与解读结果

  1. 保存脚本 ：点击菜单栏的“文件” -> “保存”，将你的测试计划保存为一个 .jmx 文件。这是一个好习惯。
  2. 运行测试 ：点击工具栏上方的绿色“启动”按钮（或按Ctrl+R）。你会看到右上角的状态图标变成绿色，并且最底部的状态栏显示活动的线程数。
  3. 查看“查看结果树” ：运行结束后，点击“查看结果树”。在左侧面板会看到10个样本（5个用户 * 2次循环）。点击任意一个，右侧会显示该次请求的详细数据：
    • 取样器结果 ：显示请求状态（应该是绿色对勾，表示成功）、响应代码（200）、响应信息（OK）。
    • 请求 ：可以看到JMeter实际发出的HTTP请求头。
    • 响应数据 ：可以看到百度服务器返回的HTML页面内容。如果看到熟悉的百度页面代码，说明请求成功了！
  4. 解读“聚合报告” ：这是性能测试的核心产出。点击“聚合报告”，你会看到一个表格，包含以下关键指标：
    • 样本 ：总共发出的请求数，应该是10。
    • 平均值 ：所有请求的平均响应时间（单位：毫秒）。这个值越小越好。
    • 中位数 ：响应时间的中位数，有一半的请求响应时间比它快，一半比它慢。它比平均值更能抵抗极端值的影响。
    • 90%百分位 ：90%的请求响应时间都在这个值以内。这是一个非常重要的指标，它告诉你绝大多数用户的体验。比如90%百分位是500ms，意味着90%的用户感觉页面在0.5秒内打开了。
    • 最小值/最大值 ：最快和最慢的响应时间。
    • 异常% ：出错请求的百分比。对于百度首页，这个值应该是0.00%。
    • 吞吐量 ：单位时间内（每秒）服务器处理的请求数。这是衡量系统处理能力的关键指标，越高越好。
    • 接收/发送KB/秒 ：网络吞吐量。

注意事项 ：第一次运行测试时，你可能会在“查看结果树”里看到一些红色的失败请求，错误信息可能是“Non HTTP response code: java.net.UnknownHostException”。这通常是因为网络问题（如DNS解析失败）或JMeter本身没有权限访问网络（特别是在公司受限环境）。请检查你的网络连接，并尝试ping一下 www.baidu.com 看是否能通。

5. 脚本优化与参数化：让测试更贴近真实

直接请求一个固定页面只是开始。真实的用户行为是多样的，比如搜索不同的关键词。这就需要我们引入 参数化 的概念。

5.1 使用CSV文件进行参数化搜索

假设我们要模拟用户使用不同的关键词搜索。我们可以将关键词列表放在一个CSV文件中，让JMeter每次请求读取不同的值。

  1. 准备CSV数据文件 ：新建一个文本文件，命名为 search_keywords.csv ，用记事本打开，输入内容如下（每行一个关键词）： 

    JMeter教程
性能测试
自动化测试
Java编程

    保存文件，记住它的路径，比如 D:\TestData\search_keywords.csv 。

  2. 添加CSV数据文件设置 ：右键线程组 -> 添加 -> 配置元件 -> CSV数据文件设置。

    • 文件名：浏览选择你的 search_keywords.csv 文件。
    • 文件编码：UTF-8（根据你的文件编码选择）。
    • 变量名称： keyword （这个变量名我们后面会用到）。
    • 其他选项默认即可。

  3. 修改HTTP请求 ：双击之前创建的“访问百度首页”HTTP请求，将其重命名为“百度搜索”。修改配置：

    • 路径： /s
    • 添加参数：在“参数”表格中，添加一个参数。
      • 名称： wd
      • 值： ${keyword} （这里就是引用CSV文件中定义的变量！）
      • 注意：勾选“编码”，因为搜索词可能需要URL编码。

  4. 调整线程组 ：将线程组的“循环次数”改为4（因为我们有4个关键词），或者勾选“永远”，并在CSV配置中设置“遇到文件结束符再次循环？”或“遇到文件结束符停止线程？”来控制。

  5. 运行并观察 ：再次运行测试。在“查看结果树”中，点击不同的请求样本，查看“请求”标签下的“GET数据”，你会发现每次请求的 wd 参数值都不一样，依次是“JMeter教程”、“性能测试”……这就实现了参数化搜索。

5.2 添加断言验证结果

我们怎么知道搜索请求是否真的成功返回了正确的结果呢？光看响应代码200可能不够，因为服务器可能返回了一个错误页面但状态码仍是200。这时就需要 断言 。

  1. 添加响应断言 ：右键“百度搜索”HTTP请求 -> 添加 -> 断言 -> 响应断言。
  2. 配置断言 ：我们假设搜索结果的标题里会包含我们搜索的关键词。
    • 要测试的响应字段：选择“响应文本”。
    • 模式匹配规则：选择“包括”（表示响应文本中要包含我们指定的内容）。
    • 要测试的模式：点击“添加”，输入 ${keyword} 。这样断言就会动态检查响应中是否包含当前循环使用的关键词。
  3. 查看断言结果 ：添加一个监听器 -> 断言结果。运行测试后，可以在这里查看每个断言是通过还是失败。如果失败，说明响应内容可能不符合预期，需要排查。

通过参数化和断言，你的测试脚本就从简单的“访问页面”升级为可以模拟真实用户行为、并能自动验证结果正确性的自动化测试脚本了。

6. 核心监听器深度解析：读懂性能数据报告

“聚合报告”给了我们一堆数字，但这些数字到底说明了什么？我们来深入解读一下，并介绍另一个强大的监听器： 图形结果 。

6.1 聚合报告关键指标实战解读

继续使用我们参数化搜索的脚本，将线程数增加到20，Ramp-Up=5，循环2次（总请求数约160）。运行后查看聚合报告：

  • 吞吐量 (Throughput) ：假设这里是 120.0/sec。这意味着你的测试机每秒向百度服务器发送了120个请求，同时服务器也处理并返回了120个响应。 这个值受限于测试机性能、网络带宽和目标服务器性能三者中的瓶颈 。在对比测试时，吞吐量越高通常意味着服务器处理能力越强。
  • 平均值/中位数/90%百分位 ：假设平均值=150ms，中位数=120ms，90%百分位=300ms。
    • 平均值150ms：所有请求的平均响应时间。
    • 中位数120ms：比平均值低，说明大部分请求确实很快，但存在一些慢请求拉高了平均值。
    • 90%百分位300ms ：这是最重要的用户体验指标。它意味着90%的用户感觉搜索在300毫秒内完成了。作为测试者，你需要关注这个值是否满足业务要求（例如，产品要求95%的搜索请求响应时间<400ms）。
  • 异常% ：必须密切关注。即使是0.5%的异常率，在百万级访问量下也意味着数千名用户失败。需要结合“查看结果树”或“用表格查看结果”监听器定位具体是哪些请求失败了，原因是什么（超时、返回错误代码、断言失败等）。

6.2 使用图形结果进行趋势分析

“聚合报告”是数字总结，“图形结果”则是可视化趋势。

  1. 添加图形结果 ：右键线程组 -> 添加 -> 监听器 -> jp@gc - 活动线程数 和 jp@gc - 响应时间随时间变化 。注意，这两个是插件，需要安装。对于标准JMeter，可以使用“图形结果”监听器（功能较基础）。
  2. 运行长时间测试 ：为了看到趋势，修改线程组，设置线程数=10，Ramp-Up=30（缓慢加压），循环“永远”。
  3. 启动测试并观察 ：运行几分钟后停止。在“响应时间图”上，你可以看到随着时间推移，响应时间的曲线。理想情况下曲线应该平稳。如果看到响应时间随着测试进行不断攀升，最后维持在高位，这可能意味着服务器存在资源泄漏（如内存泄漏）或数据库连接未释放，无法承受长时间的压力。而“活动线程数”图则清晰地展示了并发用户数随时间的变化过程。

实操心得 ：对于正式的性能测试，我很少在GUI模式下运行长时间测试或高并发测试，因为JMeter的GUI本身会消耗大量资源，影响结果准确性。通常的做法是：在GUI模式下录制、调试好脚本，然后使用 命令行（非GUI）模式 去执行压测，并将结果保存为 .jtl 文件，最后再在GUI中加载这个结果文件，用监听器进行分析。命令行示例： jmeter -n -t D:\test.jmx -l D:\result.jtl -e -o D:\html_report 。其中 -n 是非GUI模式， -t 指定脚本， -l 指定结果文件， -e -o 用于生成一个漂亮的HTML报告。

7. 常见问题排查与性能测试思维建立

走到这里，你已经可以完成一个基本的性能测试了。但在实际工作中，你会遇到各种各样的问题。下面是一些典型问题及排查思路，更重要的是，我想分享一些性能测试的核心思维。

7.1 新手常踩的“坑”与解决方案

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

    • 原因 ： JAVA_HOME 环境变量未正确设置，或者指向了JRE而不是JDK。
    • 解决 ：确保已安装JDK 8或11，并正确设置了 JAVA_HOME 系统环境变量，指向JDK安装根目录（如 C:\Program Files\Java\jdk-11.0.xx ）。同时将 %JAVA_HOME%\bin 添加到 Path 变量中。

  2. 问题：发送HTTP请求失败，错误码如“Non HTTP response code: java.net.SocketTimeoutException”

    • 原因 ：请求超时。可能是服务器处理太慢，也可能是网络延迟太高。
    • 解决 ：首先在HTTP请求的“高级”选项卡中，适当增加“超时”设置（连接、响应超时）。其次，检查服务器状态和网络。最后，考虑是否测试机本身性能不足，成为了瓶颈。

  3. 问题：测试结果中吞吐量非常低，但服务器监控显示CPU/内存使用率也很低

    • 原因 ：这是典型的 “思考时间”缺失 或 “ pacing time”问题 。现实中用户操作之间有间隔，而JMeter如果不加控制，会在一个请求结束后立即发送下一个，这会给服务器造成远超真实场景的瞬时压力。
    • 解决 ：在线程组下添加 “定时器” 。常用的有“固定定时器”，设置一个毫秒级的等待时间（如1000ms），模拟用户操作间隔。添加定时器后，吞吐量会下降，但测试场景会更真实。

  4. 问题：如何测试需要登录的接口？

    • 解决 ：这涉及到 “Cookie管理” 或 “Token管理” 。
      • Cookie ：添加一个 “HTTP Cookie管理器” 配置元件，JMeter会自动像浏览器一样处理Cookie。你只需要先用一个HTTP请求完成登录（这个请求会返回Set-Cookie），后续的请求就会自动带上Cookie。
      • Token ：更常见。先用一个HTTP请求调用登录接口，从响应中（通常是JSON）使用 “JSON提取器” 或 “正则表达式提取器” 将token值提取出来，保存为一个变量（如 ${auth_token} ）。然后在后续需要认证的请求中，在“HTTP信息头管理器”里添加一个Header，比如 Authorization: Bearer ${auth_token} 。

7.2 建立性能测试的核心思维

工具的使用是基础，但比工具更重要的是思维。性能测试不是“跑个脚本看数字”，而是一个系统的工程。

  1. 明确测试目标 ：在开始前，必须问清楚：这次测试要解决什么问题？是验证系统能否支撑“双十一”的预期流量？还是找出某个接口的瓶颈？目标决定了你的测试场景设计（如并发用户数、业务混合比例、持续时长）。

  2. 理解业务模型 ：你的线程组设置（并发数、Ramp-Up、循环）必须模拟真实的用户行为。例如，登录操作可能只发生一次，而浏览商品是高频操作。这就需要使用不同的线程组和“吞吐量控制器”来配比不同的业务操作。

  3. 监控与分析并重 ：JMeter测的是客户端感受到的性能。要定位瓶颈，必须同时监控服务器端的资源（CPU、内存、磁盘IO、网络IO）和应用指标（数据库连接数、慢查询、JVM GC情况、中间件队列长度等）。将JMeter的结果曲线与服务器监控曲线在时间轴上对齐分析，才能找到根因。

  4. 增量与对比测试 ：不要一上来就用最大压力。应该采用 “梯度增压” 的方式，比如从50并发开始，逐步增加到100、200…，观察系统性能指标（响应时间、吞吐量、错误率）的变化趋势。当错误率显著上升或响应时间不可接受时，就找到了系统的近似拐点。任何优化前后，都必须使用相同的测试脚本和环境进行对比测试，用数据证明优化的效果。

从安装到第一个脚本，再到参数化和结果分析，你已经走完了JMeter入门的关键路径。记住，JMeter只是一个工具，它把你对系统性能的疑问，变成了可量化的数据和图表。真正的价值在于你如何设计测试场景，如何解读这些数据，并最终推动系统性能的优化。接下来，你可以尝试用JMeter去测试你正在开发或维护的项目的登录接口、查询接口，在实践中你会遇到更多具体问题，而每一个问题的解决都会让你对性能测试的理解更深一层。

# 压力测试
Logo
乐奇 Rokid 开放社区

更多推荐

cover

一句话打造「丢哪里」垃圾分类AIUI智能体

avatar 乐奇 Rokid 开放社区
cover

从源码拆解一个 AIUI 每日一词智能体：页面、离线索引与硬件交互

avatar 乐奇 Rokid 开放社区
cover

“什么值得买”兴趣消费服务接入乐奇AI眼镜，开启“看见即搜索”新体验

avatar 乐奇 Rokid 开放社区