测试

JMeter在Mac下的安装使用

Posted Cola🌀

前言

Apache JMetier是Apache组织开发的基于Java的压力测试工具。一款非常优秀的开源的性能测试工具。

Jmeter是由Apache公司开发的一个纯Java开源项目，即可以用于做接口测试也可以用于做性能测试，具备高移植性和扩展性，可以实现跨平台运行，可以实现分布式负载。

采用多线程，允许通过多个线程并发取样或通过独立的线程对不同的功能同时取样。

  • 开源许可证：Jmeter完全免费，允许开发者使用源代码进行开发
  • 友好的 GUI：Jmeter 非常易于使用，不需要花时间来熟悉它
  • 平台无关：Jmeter 是 100% 纯 Java 桌面应用程序。所以它可以在多个平台上运行
  • 完整的多线程框架：Jmeter 允许通过单独的线程组并发和同时采样不同的函数
  • 可视化测试结果：测试结果可以以图表、表格、树形和日志文件等不同格式显示
  • 安装简单：您只需复制并运行 *.bat 文件即可运行 JMeter，无需安装。
  • 高度可扩展：您可以编写自己的测试。JMeter 还支持可视化插件，让您可以扩展测试
  • 多种测试策略：Jmeter支持负载测试、分布式测试、功能测试等多种测试策略。
  • 模拟：JMeter 可以模拟多个用户的并发线程，为测试中的 Web 应用程序创建沉重的负载
  • 支持多协议：Jmeter不仅支持Web应用程序测试，还可以评估数据库服务器性能。JMeter 支持所有基本协议，如 HTTP、JDBC、LDAP、SOAP、JMS 和 FTP
  • 记录和回放：记录浏览器上的用户活动并使用 JMeter 在 Web 应用程序中模拟它们
  • 脚本测试：Jmeter可以与Bean Shell和Selenium集成以进行自动化测试。

使用 Jmeter 一般用于以下两种类型的性能测试（基本能覆盖绝大多数的性能测试需求）

  • 负载测试：通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
  • 压力测试：测试系统能承受的最大负载能力。目的在于发挖掘出目标服务系统可以处理的最大负载。

Mac OS Jmeter安装运行

1、Jemter下载

由于本机已经安装了JDK，所以直接安装Jemter即可

JMeter下载地址：https://jmeter.apache.org/download_jmeter.cgi

　

说明：开源软件下载一般有两个版本可供下载：
Binaries：二进制版，即已经编译好、可直接执行；
Source：源代码版，需要自己编译；

2、运行

# 进入文件夹 
cd /Users/xxx/Documents/jmeter/apache-jmeter-5.6.3/bin
# 运行Jmeter
sh jmeter

　

　　

JMeter基础设置：把语言设置成中文

找到 jmeter.properties 文件

　

#Preferred GUI language. Comment out to use the JVM default locale's language.
language=zh_CN

　

Jmeter组件ー线程组

线程组：在 JMeter 中，线程组（Thread Group） 是性能测试的 “用户模拟核心”，用于定义 “多少用户” 以 “何种方式” 发起请求，是所有测试计划的起点（所有取样器、监听器等组件都必须放在线程组下）。

　

简单理解：线程组就像一个 “用户池”，每个线程（Thread）代表一个虚拟用户，线程组的配置决定了这些虚拟用户的行为模式。

通俗的讲，一个线程组可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。多个用户同时去执行相同的一批次任务。每个线程之间都是隔离的，互不影响的。一个线程的执行过程中，操作的变量，不会影响其他线程的变量值。

线程组的核心配置项：

线程组的主要参数用于控制虚拟用户的数量、启动方式和运行时长，以模拟不同的负载场景：

  1. Number of Threads (users)
    • 表示并发的虚拟用户数量（每个线程对应一个用户）。
    • 例：设置为 100，表示同时模拟 100 个用户发起请求。
  2. Ramp-Up Period (in seconds)
    • 表示 “所有线程启动完成的总时间”，控制用户的启动速度。
    • 例：100 个线程，Ramp-Up 设为 10 秒 → 每秒启动 10 个用户（避免瞬间压垮服务器）。
    • 若设为 0，表示所有线程同时启动（模拟突发流量）。
  3. Loop Count
    • 表示每个线程执行请求的次数。
    • 例：设为 10 → 每个用户重复执行 10 次请求；设为 “Forever” → 无限循环（需配合 “Duration” 控制总时长）。
  4. Delay Thread creation until needed
    • 勾选后，线程会在 “需要时才创建”（而非提前创建所有线程），节省资源。
  5. Scheduler（调度器，展开后可见）
    • Duration (seconds)：测试总运行时长（覆盖 Loop Count，到时间后自动停止）。
    • Startup Delay (seconds)：测试启动前的延迟时间（用于准备环境）。

线程组的类型：

JMeter 提供多种线程组，适用于不同测试场景：

  1. Thread Group（普通线程组）
    • 最常用的基础线程组，支持上述所有配置，适合大多数常规性能测试（如模拟稳定并发用户）。
  2. Setup Thread Group
    • 用于 “测试前的准备操作”（如初始化数据、登录系统），会在普通线程组运行前执行。
  3. Teardown Thread Group
    • 用于 “测试后的清理操作”（如删除测试数据、登出系统），会在普通线程组运行后执行。

线程组的作用：

  • 模拟用户并发：通过 “线程数” 控制同时发起请求的用户量。
  • 控制负载模式：通过 “Ramp-Up” 和 “Loop Count” 模拟用户的启动速度和操作次数。
  • 组织测试流程：结合 Setup/Teardown 线程组，实现 “准备 – 测试 – 清理” 的完整流程。

例如：要测试一个接口在 “100 用户同时访问，持续 5 分钟” 的性能，只需：

  • 线程数设为 100
  • Ramp-Up 设为 0（瞬间启动）
  • 勾选 Scheduler，Duration 设为 300 秒（5 分钟）

线程组是 JMeter 性能测试的 “骨架”，所有请求逻辑（取样器）、结果分析（监听器）都依赖线程组来驱动执行。

　

Jmeter组件ー取样器

在 JMeter 中，取样器（Sampler） 是用于模拟用户请求、向目标服务器发送请求并获取响应的核心组件，是性能测试中产生 “负载” 的关键。它相当于用户的 “操作行为”，比如访问网页、调用接口、发送数据库查询等。

　

取样器的作用：

  • 向服务器发送具体的请求（如 HTTP 请求、数据库查询、FTP 上传等）。
  • 记录服务器的响应数据（响应时间、状态码、响应内容等）。
  • 作为性能测试的 “负载源”，通过多线程并发执行，模拟大量用户的访问压力。

常见的取样器类型：

JMeter 内置了多种取样器，覆盖不同的协议和场景，常用的包括：

  1. HTTP Request：最常用的取样器，模拟 HTTP/HTTPS 请求（如访问网页、调用 REST API、提交表单等）。
  2. JDBC Request：用于发送数据库查询请求（支持 MySQL、Oracle、SQL Server 等），测试数据库性能。
  3. FTP Request：模拟 FTP 协议的上传、下载操作。
  4. SOAP/XML-RPC Request：测试 SOAP 协议的 WebService 接口。
  5. TCP Sampler：通过 TCP 协议发送自定义数据，测试基于 TCP 的服务。
  6. WebSocket Sampler：测试 WebSocket 协议的实时通信服务（如聊天功能）。
  7. BeanShell Sampler：通过脚本（BeanShell）自定义请求逻辑，处理复杂场景。

取样器的使用场景：

  • 当你需要模拟用户 “访问某个网页” 时，用 HTTP Request 取样器。
  • 当你需要测试 “数据库查询的响应时间” 时，用 JDBC Request 取样器。
  • 当你需要自定义复杂请求逻辑（如动态参数生成）时，用 BeanShell Sampler。

取样器与其他组件的关系：

取样器通常需要配合其他组件使用

  • 线程组：控制取样器的并发数（模拟多少用户）。
  • 监听器：收集取样器的结果（如响应时间图表、吞吐量统计）。
  • 配置元件：为取样器提供参数（如 HTTP 头信息、数据库连接信息）。
  • 断言：验证取样器的响应是否符合预期（如检查状态码是否为 200）。

简单来说，取样器是 JMeter 中 “实际干活” 的组件，所有性能测试的请求都由它发起，没有取样器，测试就无法产生实际的负载。

　

Jmeter组件ー结果树

在 JMeter 中，结果树（View Results Tree） 是一个常用的监听器组件，用于详细展示测试过程中每个请求的具体内容、服务器响应数据以及执行状态，是调试测试脚本和分析请求细节的重要工具。

　　

简单来说，结果树就像一个 “请求 – 响应日志记录仪”，能帮你直观看到每个虚拟用户发送了什么请求、服务器返回了什么内容，以及请求是否成功。

结果树的核心功能：

  1. 展示请求与响应的详细信息
    • 请求部分：显示取样器发送的完整请求数据，包括协议（如 HTTP）、请求 URL、参数、 headers、Body 等（例如 HTTP 请求的表单数据、JSON payload 等）。
    • 响应部分：显示服务器返回的完整响应，包括状态码（如 HTTP 200/404/500）、响应 headers、响应体（如 HTML 内容、JSON 数据、错误信息等），还支持格式化显示（如 JSON、XML 格式化）。
  2. 标记请求执行状态
    • 结果树用不同颜色标识请求状态：
      • 绿色：请求成功（通常结合断言判断，符合预期结果）。
      • 红色：请求失败（如超时、状态码错误、断言不通过等）。
    • 每个请求条目会显示执行时间、响应时间等基础指标。
  3. 支持筛选和搜索
    • 可按 “成功 / 失败”“请求类型” 等筛选结果，快速定位问题请求。
    • 提供搜索功能，可在请求 / 响应内容中查找特定关键词（如错误信息、某个参数值）。
  4. 保存和导出结果
    • 可将结果树中的数据保存为 XML、CSV 等格式，便于后续分析。
    • 支持重新发送请求（“Re-send” 功能），方便调试时重复测试某个请求。

结果树的使用场景：

  • 调试测试脚本：当测试计划运行异常（如响应不符合预期）时，通过结果树查看请求参数是否正确、响应是否包含错误信息，快速定位问题（例如参数传递错误、接口返回格式异常）。
  • 验证请求逻辑：确认取样器是否按预期发送请求（如动态参数是否正确替换、请求方法 / URL 是否正确）。
  • 分析失败原因：对于红色失败的请求，查看响应中的错误详情（如 “500 服务器内部错误” 的具体堆栈信息），判断是客户端请求问题还是服务器端故障。

结果树与其他监听器的区别：

结果树侧重于单请求的细节展示，而其他监听器（如 “汇总报告”“图形结果”）更关注整体性能指标（如平均响应时间、吞吐量、错误率）。

  • 调试阶段：主要用结果树查看具体请求 / 响应细节。
  • 性能分析阶段：结合汇总报告、图形结果等看整体指标。

示例：HTTP 请求的结果树展示：

假设用 “HTTP 请求” 取样器访问 https://example.com，结果树中会显示：

  • 请求：GET https://example.com，包含请求 headers（如 User-Agent、Accept 等）。
  • 响应：状态码 200 OK，响应 headers（如 Content-Type: text/html），以及 HTML 格式的响应体内容。
  • 若请求失败（如 URL 错误），则显示状态码 404 Not Found，并标记为红色。

总之，结果树是 JMeter 中用于 “精细化调试” 的核心工具，尤其在测试脚本开发阶段，能帮你快速排查请求逻辑和响应问题，确保测试计划的正确性。

还可以添加很多种其他的结果图，比如Summary Report，Aggregate Report，Graph Results，Response Time Graph

　　

　　

　　

　　

　　

Jmeter组件ーHTTP Cookie 管理器

添加了HTTP Cookie管理器后，会自动存储并发生Cookie。

　

　　

上面选项默认标准即可。

HTTP Cookie管理器像Web浏览器应用存储和发送Cookie。如果HTTP请求并且响应包含Cookie，则Cookie管理器会自动存储该Cookie，并将其用于将来对该特定网站的所有请求。每个JMeter线程都有自己的“Cookie存储区”。因此，正在测试使用Cookie存储会话信息的网站，每个JMeter线程都将拥有自己的会话。此类Cookie不会显示在Cookie管理器显示屏上，可以使用“查看结果树监听器”查看。

缓存配置可选择 standard（标准）或 compatibility（兼容的），当然也可以手工添加一些Cookie。

　　

Jmeter组件ーHTTP Cookie 管理器

添加方式：线程组—>配置元件—>用户定义的变量

有时候我们想要在固定的场景里使用参数化，改动后不希望影响到其他的脚本。这时候就可以自定义变量。

使用方式：在HTTP请求的取样器中引入定义的变量。${参数名}。

　

　

适用场景：变量需要在多个脚本中使用，方便统一管理和修改。

　

Jmeter组件ーCSV数据文件设置

以登录接口为例，当我们执行登录接口的性能测试时，手动配置了用户名和密码固定的username，然后实际使用中不可能只有一个用户登录，为了模拟更真实的登录环境，我们需要提供更多的用户username和password来实现登录操作。

添加方式：线程组—>配置元件—>CSV数据文件设置

操作步骤

1、CSV数据文件设置

文件名：填写CSV文件的路径。建议使用绝对路径。

文件编码：UTF-8。

变量名称：从CSV数据文件中读取的数据需要保存到变量名。有多个变量时用逗号分隔。

是否忽略首行：是否从CSV数据文件第一行开始读取。

分隔符：要求与CSV数据文件中多列的分隔符一致。

遇到文件结束符再次循环：若选择为True，当数据不够的时候会从头去。若选择False，则需要勾选下面的配置，遇到文件结束符停止线程，这里如果不勾选，请求将会报错。

2、编写test.csv文件

3、修改登录接口及其他涉及到username和password获取的参数

修改完该配置后，登录接口发起请求时将从CSV文件中获取配置好的username和password参数，获取顺序为从上往下依次获取获取。

4、修改线程组中线程数，使得每次取到的username和password都不一样

5、运行结果

　

Jmeter组件ー同步定时器

为了达到并发的效果，需要添加同步定时器。

没添加同步定时器前，有多个请求，只要这个请求准备好了，就发送。

添加同步定时器后，设置一个集合点，有多个请求，这几个请求要满足这个集合点的数量，一起发送请求。

同步定时器可以理解为过红绿灯，红灯的时候人都在等绿灯，绿灯后全部人都可以一起过马路了。

JMeter 同步定时器的作用主要在于模拟多用户并发访问的场景，确保多个线程能够同时执行某个操作，以达到真正的并发效果。

当多个线程同时启动时，它们可能会在不同的时间间隔内执行，这样就无法达到真正的并发效果。同步定时器的作用就是将这些线程的执行时间同步，使它们在同一时间点执行。它可以在多个线程之间制造一定的延迟，直到同时到达指定时间点，再同时执行后续的操作。

此外，同步定时器可以理解为集合点，当线程数量达到指定值后，再一起释放，可以瞬间产生很大的压力。这样，可以更好地模拟真实的用户并发访问场景，提高测试的准确性和可靠性。

在性能测试过程中，为了真实模拟多个用户同时进行操作，用来度量服务器的处理能力，可以使用同步定时器来设置集合点。不过，虽然通过加入集合点可以约束请求同时发送，但不能确保请求同时到达服务器，所以只能说是较真实模拟并发。

现在模拟5个请求同时并发执行。

执行顺序如图：

这里同步定时器设置模拟用户数量最好是和线程组里的线程数量相同，或者线程数量是模拟用户数量的整数倍（但线程循环要设为永远，指定时间循环），这样才不会导致有剩余的请求发送不出去（因为要等到达集合点的数量，才能把这些请求一起发送出去）。

本文通过乘客和公交的比喻解释了线程组数量与同步定时器的关系。线程组相当于乘客，定时器模拟用户组的数量相当于公交车座位。为了处理20个线程（乘客），若每个定时器（公交车）能处理8个线程，则需运行3次来完成任务。最后一次运行即使未满员，也会在超时后触发。

线程组数量和同步定时器数量用 乘客 和公交 做比喻：

线程组数量相当于 乘客（20）

定时器模拟用户组的数量 相当于 公交车上的座位数量（8）

也就是说要运完20个乘客需要 3次 （3*8>20）， 同步定时器 每次并发的数量是 8个，当最后一次不满8个时，设置 超时时间。超时过后，不满8个 也会触发 。 超时时间设置为0，最后一次并发线程数量不满8个时，程序会一直阻塞。

　

Jmeter组件ー事务控制器

JMeter 事务控制器的作用主要用于测试执行嵌套测试元素所花费的总时间。这相当于模拟用户进行一系列操作的测试。

在进行页面性能测试或API性能测试时，事务控制器是一个非常重要的工具。它可以帮助测试人员更准确地评估系统性能，尤其是在涉及多个接口或操作的复杂场景中。例如，在订单提交的过程中，可能需要调用多个接口，并且某些接口可能依赖于前一个接口的结果。在这种情况下，使用事务控制器可以将这些接口统一视为一个事务进行性能测试，从而得到更接近真实场景的性能测试结果。

若不添加事务控制器，则一个接口即一个事务。

添加了事务控制器后，可以将多个接口统一放到一个事务控制器下座位一个事务。

如图，把登录页和用户信息放到同一个事务中：

发起请求，查看聚合报告

发现原来的请求依然在，还多了个登录事务。

　

Jmeter 好多组件, 既可以加到采样器下面, 又可以加到线程组下面, 有什么区别吗?

在 JMeter 中，同一组件（如断言、配置元件等）既可以添加到 “取样器下方”，也可以添加到 “线程组下方”，核心区别在于作用范围（Scope）—— 即该组件对哪些取样器生效。

在 JMeter 中，同一组件（如断言、配置元件等）既可以添加到 “取样器下方”，也可以添加到 “线程组下方”，核心区别在于作用范围（Scope）—— 即该组件对哪些取样器生效。

核心原则：组件的 “作用域继承”

JMeter 组件的作用范围遵循 “层级结构”：父级组件会对其下所有子级取样器生效；子级组件（如放在某个取样器下方）仅对该取样器生效。
简单说：

  • 放在 线程组下方 → 对该线程组内所有取样器生效（全局作用域）。
  • 放在 某个取样器下方 → 仅对当前这个取样器生效（局部作用域）。

举例说明（以 “断言” 和 “配置元件” 为例）

1. 断言（Assertion）

断言用于判断请求响应是否符合预期（如检查状态码、响应内容等）。

  • 放在线程组下：线程组内所有取样器的响应都会被这个断言检查。
    例：线程组下有 3 个 HTTP 请求（A、B、C），若在线程组下加一个 “响应断言（检查状态码 200）”，则 A、B、C 的响应都会被检查是否返回 200。
  • 放在取样器 A 下：仅取样器 A 的响应会被这个断言检查，B、C 不受影响。
    例：仅需验证 A 请求的响应包含 “success” 字段，其他请求无需检查，则将 “响应断言” 放在 A 下方。

2. 配置元件（Config Element）

配置元件用于提供全局参数（如 HTTP 头信息、变量、数据库连接等）。

  • 放在线程组下：线程组内所有取样器都会共享该配置。
    例：线程组下加一个 “HTTP 信息头管理器”，设置 Content-Type: application/json，则该线程组内所有 HTTP 请求都会自动带上这个头信息。
  • 放在取样器 A 下：仅取样器 A 会使用该配置，其他取样器不生效。
    例：大部分请求用 application/json 格式，但取样器 A 需要用 application/x-www-form-urlencoded，则单独在 A 下方加一个 “HTTP 信息头管理器”（会覆盖线程组的全局配置）。

3. 定时器（Timer）

定时器用于控制请求的发送间隔（如模拟用户思考时间）。

  • 放在线程组下：线程组内所有取样器执行前都会等待该定时器设置的时间。
    例：线程组下加一个 “固定定时器（3 秒）”，则 A、B、C 每个请求前都会等待 3 秒。
  • 放在取样器 A 下：仅 A 请求执行前会等待，B、C 不受影响。

特殊规则：优先级

当 “线程组下的全局组件” 与 “取样器下的局部组件” 配置冲突时，局部组件优先级更高（会覆盖全局配置）。例：

  • 线程组下的 “HTTP 信息头管理器” 设置 User-Agent: JMeter。
  • 取样器 A 下的 “HTTP 信息头管理器” 设置 User-Agent: Chrome。
    → 最终 A 请求的 User-Agent 是 Chrome（局部覆盖全局），其他请求仍为 JMeter。

总结

组件位置作用范围适用场景
线程组下方对线程组内所有取样器生效全局共享的配置（如通用头信息、全局断言）
某个取样器下方仅对当前取样器生效局部特殊配置（如单独的定时器、专属断言）

　

Jmeter组件ー常见监听器

1.Active Threads Over Time

表示运行的线程数，可以看到，随着时间的变化，线程数随之变多，每隔3秒，增加5个，直到线程数到20停止增长，到后面每隔1秒释放5个线程，和上面我们设置的阶梯线程组一样

2.聚合报告

从聚合报告可以看到性能测试过程中整体的数据变化。如图：

3.Response Times Over Time

Response Times Over Time 主要用于监听整个事务运行期间的响应时间。在测试过程中，它可以帮助测试人员观察并分析响应时间的实时平均值以及整体响应时间的走向。通过这一监听器，测试人员能够更直观地了解系统在不同时间点的响应性能，从而发现可能存在的性能问题或瓶颈。

Response Time Over Time的图形展示中，横坐标通常代表运行时间，而纵坐标则代表响应时间（单位是毫秒）。测试人员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在大的波动。例如：如果响应时间在某个时间点突然增加，这可能意味着系统在该时间点遇到了性能问题。

4.Transactions per Second（TPS）

JMeter中的Transactions per Second（TPS）监听器是一个用于分析系统吞吐量的重要工具。TPS，即每秒处理的事务数，表示一个客户机向服务器发送请求后，服务器做出反应的过程。这个指标反映了系统在同一时间内处理业务的最大能力。TPS值越高，说明系统的处理能力越强。

在使用TPS监听器时，横坐标通常代表运行时间，而纵坐标则代表TPS值。通过监听器展示的图表，可以清晰地看到TPS值随时间的变化情况。在图表中，红色通常表示通过的TPS，而绿色可能表示失败的TPS。这有助于我们快速识别系性能的变化和瓶颈。

　

响应断言

JMeter 是一个功能强大的性能测试工具，它可以模拟大量用户并发访问网站或应用程序，以测试其性能和稳定性。在进行性能测试时，我们需要对响应结果进行断言，以确保应用程序或网站的功能和性能符合预期。

在 JMeter 中，响应断言是一种用于检查服务器响应是否符合预期的机制。JMeter 提供了多种类型的响应断言，包括文本、响应代码、响应头、响应时间等。下面将详细介绍 JMeter 中的响应断言。想要学习更多关于 JMeter 的知识，可访问 Jmeter 中文文档。

响应断言类型

文本响应断言

文本响应断言是最常用的一种断言类型，它用于检查服务器响应中是否包含特定的文本。例如，我们可以使用文本响应断言来检查登录页面是否包含“用户名”和“密码”这两个关键字。如果服务器响应中不包含这些关键字，那么断言将失败。

在 JMeter 中，文本响应断言有多种选项，包括：

  • 包含/不包含：检查服务器响应中是否包含/不包含特定的文本。
  • 匹配/不匹配：使用正则表达式来检查服务器响应中是否包含/不包含特定的文本。
  • 大小写敏感/不敏感：指定断言是否区分大小写。

响应代码断言

响应代码断言用于检查服务器响应的 HTTP 状态码是否符合预期。例如，我们可以使用响应代码断言来检查登录页面是否返回 HTTP 200 状态码。如果服务器返回的状态码不是 200，那么断言将失败。

在 JMeter 中，响应代码断言有多种选项，包括：

  • 等于/不等于：检查服务器响应的 HTTP 状态码是否等于/不等于特定的值。
  • 区间：检查服务器响应的 HTTP 状态码是否在特定的区间内。

响应头断言

响应头断言用于检查服务器响应的 HTTP 头信息是否符合预期。例如，我们可以使用响应头断言来检查登录页面是否返回特定的 Content-Type 头信息。如果服务器返回的头信息不符合预期，那么断言将失败。

在 JMeter 中，响应头断言有多种选项，包括：

  • 包含/不包含：检查服务器响应的头信息中是否包含/不包含特定的值。
  • 匹配/不匹配：使用正则表达式来检查服务器响应的头信息中是否包含/不包含特定的值。
  • 大小写敏感/不敏感：指定断言是否区分大小写。

响应时间断言

响应时间断言用于检查服务器响应的时间是否符合预期。例如，我们可以使用响应时间断言来检查登录页面的响应时间是否小于 5 秒。如果服务器响应时间超过了预期，那么断言将失败。

在 JMeter 中，响应时间断言有多种选项，包括：

  • 大于/小于/等于：检查服务器响应的时间是否大于/小于/等于特定的值。
  • 百分比：指定服务器响应时间的百分比，例如 90%，并检查是否小于特定的值。

具体使用示例

添加 HTTP 接口

我们有如下的 HTTP 接口。

添加断言

添加响应断言: 右击接口 > 添加 > 断言 > 响应断言。

之前的接口返回的数据结果如下：

{
    "total": 3,
    "data": [
        {
            "id": 1,
            "name": "Apple",
            "price": 100
        },
        {
            "id": 2,
            "name": "Orange",
            "price": 200
        },
        {
            "id": 3,
            "name": "Banana",
            "price": 300
        }
    ]
}

我们对 响应文本中 包含字符串 “Apple” 做断言：

我们对 HTTP 的响应码 做断言：

断言结果

运行用例。如果响应符合断言，则什么都不会发生。否则，在结果树中会看到报错信息。将 响应文本中包含Apple 的断言值改成 Apple3，运行，就会看到如下的报错：

总之，响应断言是 JMeter 中非常重要的一个功能，它可以帮助我们检查服务器响应是否符合预期。在进行性能测试时，我们应该根据实际情况选择合适的断言类型，并设置合适的参数，以确保测试结果的准确性和可靠性。

测试报告

JMeter 测试报告是一个全面而详细的文档，它提供了关于测试执行结果的详细信息，帮助用户全面评估系统的性能并进行性能优化。

生成性能测试报告的命令：Jmeter -n -t 脚本文件 -l 日志文件 -e -o 目录
 -n：无图形化运行

 -t：被运行的脚步

 -l：将运行信息写入日志文件，后缀为 jtl 的日志文件

 -e：生成测试报告

 -o：指定报告输出目录

 命令解析：先把指定的 jmx 文件执行一遍，再生成测试报告，放在当前路径first目录下（还有将运行信息写入日志文件，命名为 first.jtl）。

运行完脚本后，查看对应的文件目录，如图：

测试报告就在 index.html 文件下。

里面的相关数据，JMeter工具里有的，这个报告里面都有。

　

性能分析

通过三大指标来分析性能问题。

1、响应时间

如果响应时间超过了要求，代表系统到了瓶颈。

注意事项：分析在多少线程的情况下发送了超标。

响应时间变化的原因：

1、系统不稳定，有时快有时慢。

2、随着并发压力变大而慢慢变慢，响应时间变高。

2、错误率（可靠性）

高并发场景下，系统是否能够正常处理业务。

要求：99.99%可靠，99.999%    (通常企业标准是4个9，军事标准为5个9）

错误率高的原因：

1、接口请求错误。

2、服务器无法继续处理，达到了瓶颈（代码写的不好，内存泄露，硬件资源等）。

3、后端系统限流（系统里配置了不能超过多少并发）、熔断、降级。
熔断：防止系统因某个服务器的故障而整体崩溃。当电商平台上用户支付时，收银台发现某个支付渠道，如微信支付失败率突增，超时严重，那么就可以临时把这个支付方式熔断掉。
降级：主动关闭一些非核心功能，以确保核心功能的正常运行。某次腾讯视频挂了的时候，用户名称默认显示未腾讯用户，这也是一种降级方式，用兜底名称做展示。）

3、吞吐量

吞吐量越大，性能越好；吞吐量相对稳定或者变低，可能系统达到了性能瓶颈。

吞吐量变化规律：

波动很大：代表系统性能不稳定。

慢慢变高，在趋于稳定：和并发量相关。如果并发量小于吞吐量，慢慢增大并发量，吞吐量也会随之增加。

慢慢变低，并发量也减少了：要么性能测试要结束了，并发减少；也可能是系统变的卡顿，从而导致响应时间变慢，导致单个线程发起的并发量变少。