JMeter学习教程

aka卡卡2026-03-28 8:29

文章目录

JMeter教程

1.安装教程

1.jdk相关

安装JMeter之前，需要先安装配置Java环境jdk

2.JMeter相关

1.JMeter下载地址

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

下载完了就解压下载的zip

2.环境变量配置

1.找到 此电脑右键-【属性】-【高级系统设置】-【环境变量】

2.新建系统变量 JMETER_HOME

变量名：JMETER_HOME

变量值：jmeter的安装路径。例如：D:\下载的软件\Jmeter\apache-jmeter-5.5

3.编辑系统变量 CLASSPATH

变量名：CLASSPATH

复制代码 
%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan.jar;

追加后的变量值：

复制代码 
.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar;%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan.jar;

4.编辑变量名 Path，

新增环境变量：

复制代码 
%JMETER_HOME%\bin
3.运行JMeter

双击安装路径bin文件内的jmeter.bat

展示以下内容即为配置成功

4.JMeter如何设置中文
5.插件
1.自带的插件
2.不是自带的插件

以BlazeMeter 插件为例

步骤：

1.关闭JMeter窗口

2.下载 JMeter Plugins Manager

打开官网：https://jmeter-plugins.org/install/Install/

下载 文件：

复制代码 
jmeter-plugins-manager-x.x.jar

3.把 jar 放到 JMeter 的 lib/ext 目录

把下载的文件复制到：

复制代码 
apache-jmeter-5.6.3\lib\ext\

⚠️ 路径一定要对，别放错

4.双击bin\jmeter.bat 重新启动 JMeter

5.打开插件管理器

启动后，菜单里会多一个：Options → Plugins Manage 或者中文：选项 → 插件管理器

6.安装 BlazeMeter 相关插件

在插件管理器里：

  1. 切到 Available Plugins

  2. 搜索关键词：

    复制代码 
    BlazeMeter

  3. 勾选（至少）👇其中一个：

    • ✅ BlazeMeter Plugins
    • 或 Random CSV Data Set Config
    • 或 Random CSV Data Set

  4. 点击：

    复制代码 
    Apply Changes and Restart JMeter

👉 JMeter 会自动下载 + 重启

补充：

如果没看到BlazeMeter Plugins，就勾选 Random CSV Data Set

👉 名字不同，但就是它本尊

7.重新导入你的 .jmx

复制代码 
File → Open → upDown.jmx

🎉 这次可以正常打开了

7.查看是否安装成功

使用

JMeter = 帮你自动点接口的工具

你平时是：

  • Postman 点一下
  • 浏览器点一下

JMeter 是：

  • 帮你点 100 次
  • 帮你同时点 10 个人
  • 帮你不停点

1.调接口

第 1 步：打开 JMeter

👉 双击你桌面的 JMeter 图标

第 2 步：添加"人"（线程组）👤

右键左边：

复制代码 
Test Plan
 → Add
   → Threads (Users)
     → Thread Group

你会看到右边 3 个参数：

参数 填什么 现在先这么填
Number of Threads 模拟多少人 1
Ramp-Up Period 多久启动完 1
Loop Count 每人跑几次 1
第 3 步：添加"接口请求"🌐

右键 Thread Group：

复制代码 
Thread Group
 → Add
   → Sampler
     → HTTP Request
第 4 步：填写接口信息（重点）

假设你的接口是：

复制代码 
http://localhost:8080/api/test

你在 JMeter 里填：

字段 填什么
Protocol http
Server Name localhost
Port 8080
Method GET
Path /api/test
第 5 步：加一个"结果查看器"👀（必须）

否则你根本不知道成功还是失败。

右键 Thread Group：

复制代码 
Thread Group
 → Add
   → Listener
     → View Results Tree
第 6 步：点绿色 ▶ 运行 🚀
  • 点顶部绿色三角
  • 看左边 View Results Tree
  • 点里面那一条请求

你会看到：

  • Response code: 200 → 成功 ✅
  • Response data → 接口返回内容

到这里你已经会60% 了 🎉：

  • 新建脚本
  • 配线程组
  • 调接口
  • 看结果

2.测试 POST 接口（造数据用）

第 1 步：Method 改成 POST

在 HTTP Request 里：

复制代码 
Method = POST
第 2 步：加请求头（JSON 接口必做）

右键 HTTP Request：

复制代码 
Add
 → Config Element
   → HTTP Header Manager

加一行：

Name Value
Content-Type application/json
第 3 步：填 Body Data

在 HTTP Request 里：

复制代码 
Body Data

写：

复制代码 
{
  "name": "test_user",
  "age": 18
}
第 4 步：跑一次 ▶

在 View Results Tree 看结果：

  • 200 / 201 = 成功
  • 400 / 500 = 请求写错了

3.造 100 条数据

你现在已经能 POST 一条，我们让它跑 100 次。

第 1 步：改线程组参数
复制代码 
Number of Threads = 1
Loop Count = 100
第 2 步：点 ▶

👉 接口会被调 100 次

👉 后端会插 100 条数据

4.不重复数据（超实用）🔥

把 Body 改成这样：

复制代码 
{
  "name": "user_${__time(YMDHMS)}",
  "age": ${__Random(18,60)}
}

5.如何让 JMeter 里「自动格式化」JSON（不再乱）

在 View Results Tree 里用内置格式化（最简单）

在 JMeter 的：View Results Tree → 右侧 Response Data

👉 操作步骤：

  1. 在左侧选中任意一条 HTTP Request
  2. 在右侧上方找到这个下拉框（你现在显示的是：Text）
  3. 点开它，看看有没有这些选项之一：
  • JSON
  • HTML
  • XML

在 JMeter 5.6.3 里，正常会有一个：

🔹 选择：JSON 或 JSON (pretty)（如果有）

选了之后，JSON 就会自动格式化展开，像这样：

复制代码 
{
  "args": {},
  "data": {
    "name": "user_900",
    "username": "u_dfacc",
    "email": "mail_485@test.com"
  },
  "headers": {
    "host": "postman-echo.com",
    ...
  },
  "json": {
    "name": "user_900",
    "username": "u_dfacc",
    "email": "mail_485@test.com"
  },
  "url": "https://postman-echo.com/post"
}

6.正确的文件类型区分（这个非常重要，新手必学）

JMeter里常见几种文件，你现在混淆了 👇

文件类型 后缀 用途 能不能用 File→Open 打开
测试计划文件 .jmx 整个测试工程 ✅ 可以
请求头文件 .txt / .csv 只给 Header Manager 用 ❌ 不能
CSV 数据文件 .csv 造数据用 ❌ 不能
结果文件 .jtl 保存执行结果 ❌ 不能

7.GET 和 POST区分

✅ GET：用来【查询 / 获取数据】

🔴 POST：用来【新增 / 提交数据】

可以把"接口"想成一家餐厅的窗口

GET =「我要看菜单 / 查信息」

特点：

  • 只是拿数据、查数据
  • 不会改变服务器里的东西
  • 就像：
    • 查余额
    • 查用户信息
    • 查订单列表

例子：

复制代码 
GET /users
GET /users/1

意思是：

"服务器，把用户列表给我看一下"

"服务器，把 1 号用户的信息给我看一下"

POST =「我要下单 / 新建一条记录」

特点：

  • 是在往服务器"提交新数据"
  • 会改变服务器里的内容
  • 就像：
    • 注册新用户
    • 新增订单
    • 新增文章

例子：

复制代码 
POST /posts

意思是：

"服务器，我要新建一条数据，这是内容"

区别
区别 1：参数放的位置不同（非常重要）

🟢 GET 的参数：一般放在 URL 里（地址后面）

比如：

复制代码 
/users?id=1

或者：

复制代码 
/users/1

👉 参数是"明文写在地址上的"

👉 浏览器能直接看到

👉 一般用于：查询条件

在 JMeter 里：写在 Path 后面 或 写在 Parameters 表格里

🔴 POST 的参数：一般放在 Body 里（请求体）

比如你刚刚用的：

复制代码 
{
  "title": "test_title",
  "body": "this is a test body",
  "userId": 101
}

👉 参数是"藏在请求体里的"

👉 地址栏看不到

👉 一般用于：注册 / 新增 / 提交表单

在 JMeter 里：写在 Body Data 里

区别 2：GET 一般没有 Body，POST 一定有 Body
类型 有没有 Body 常见用途
GET ❌ 基本没有 查询数据
POST ✅ 一定有 新增 / 提交数据

所以：

  • 你 GET 请求时，Body 是空的 → 正常
  • 你 POST 请求时，如果 Body 为空 → 基本就是错的
区别 3：GET 通常"安全"，POST 会"改数据"

接口测试里有个概念：

  • GET：幂等 / 安全（多查几次没影响）
  • POST：有副作用（每调一次可能多一条数据）

所以在公司里：

  • GET 可以随便测
  • POST / DELETE / PUT 要小心，不然会把测试库塞满
区别4：状态码（做断言会用到）

一般规律是：

🟢 GET 成功：返回：200 OK

🔴 POST 成功：常见返回：201 Created（最标准） 或 200 OK

比如你刚刚新增帖子，返回里多了：

复制代码 
"id": 101

说明：新数据创建成功了

总结
对比点 GET POST
主要用途 查询数据 新增 / 提交数据
会不会改服务器数据 ❌ 不会 ✅ 会
参数放哪里 URL / Parameters Body Data
有没有 Body ❌ 一般没有 ✅ 一定有
是否常用于注册 ❌ ✅
是否常用于查询 ✅ ❌

除了 GET / POST，真实项目里还有两个常见方法：

方法 用途 你现在理解
GET 查数据 ✅ 已掌握
POST 新增 / 造数据 ✅ 已掌握
PUT / PATCH 修改数据 🔜 后面会学
DELETE 删除数据 🔜 后面会学

比如：

  • POST → 新增用户
  • PUT → 修改用户信息
  • DELETE → 删除用户
  • GET → 查询用户信息

实战

实战1：JSONPlaceholder（假数据 REST API）

接口地址：https://jsonplaceholder.typicode.com/users

作用：模拟"创建用户"（POST 造数据），不需要账号、不需要登录

公共测试 API 你可以用下面这个网站来实操 JMeter：

🌟 JSONPlaceholder（假数据 REST API）

👉 API基础地址：https://jsonplaceholder.typicode.com/

这是一个免费、零配置的 REST API，专门提供给开发者和测试人员用来测试请求。你可以直接发送各种 HTTP 请求（GET、POST、PUT、DELETE）来练习。

📌 示例请求：

类型 URL 描述
GET https://jsonplaceholder.typicode.com/users 获取用户列表
POST https://jsonplaceholder.typicode.com/users 创建一个模拟用户

注意：即使你 send POST，服务端不会真的创建数据，但会返回你发送过来的内容 + 一个假 ID 作为响应（用于测试）。

目标接口： POST 创建用户（用于造数据）

复制代码 
https://jsonplaceholder.typicode.com/users

它接受 JSON 数据，并返回你发送的 JSON + 生成的 id（模拟成功响应）。

这个网站（JSONPlaceholder）是一个假接口 / 模拟接口，它的特点是：

🔹 POST 请求时：

服务器并不会真的保存你发的数据

🔹 它只返回一个：

  • 固定或递增的 id
  • 不一定把你提交的字段原样返回

步骤：

1.打开JMeter并添加 Thread Group（用户组）

左侧 右键 Test Plan → Add → Threads (Users) → Thread Group

在右侧填写：

  • Number of Threads (users) ：5
    👉 模拟 5 个用户
  • Ramp-Up Period (seconds) ：5
    👉 5 秒内启动完
  • Loop Count ：2
    👉 每个用户发送 2 次请求

现在相当于：一共会发 10 次请求

2.添加 HTTP 请求 HTTP Request（真正造数据的地方）

右键 Thread Group → Add → Sampler → HTTP Request

右侧填写如下（非常关键，照着填）：

🔹 基本信息

  • Protocol ：https
  • Server Name or IP ：jsonplaceholder.typicode.com
  • Port Number：留空
  • Method ：选择 POST
  • Path ：/users

设置请求数据（Body Data）在 HTTP Request 下方， 选择 Body Data 这个标签页

输入下面这段 JSON（先用固定数据，最简单版本）：

json 复制代码 
{
  "name": "test_user",
  "username": "test001",
  "email": "test001@test.com"
}

⚠️ 注意：这是标准 JSON，最后一行不要多逗号

3.添加结果查看器 View Results Tree（否则你啥也看不到）

右键 Thread Group → Add → Listener → View Results Tree

这个非常重要，用来：

  • 看请求发没发出去
  • 看服务器返回什么

4.点击顶部绿色 ▶️ ，第一次运行测试（不加造数据，先跑通流程）

现在结构应该是：

复制代码 
Test Plan
 └─ Thread Group
     ├─ HTTP Request
     └─ View Results Tree

点击顶部绿色 ▶️ 运行

然后点左边的 View Results Tree，会看到左侧出现很多请求记录

补充：运行之前先保存文件

5.查看结果，对比是否成功

1.看 Response Data返回内容（最重要）

如果看到：多了一个 "id": 数字，说明：

  • JMeter 请求配置正确
  • 接口连通正常
  • 造数据成功

这个网站（JSONPlaceholder）是一个假接口 / 模拟接口，它的特点是：

🔹 POST 请求时：

服务器并不会真的保存你发的数据

🔹 它只返回一个：

  • 固定或递增的 id
  • 不一定把你提交的字段原样返回

所以现在：

复制代码 
{
  "id": 11
}

表示的含义是：

✅ 请求成功到达服务器

✅ 服务器"假装"帮你创建了一个用户

✅ 给你返回了一个"新用户ID"

但：

❌ 它没有把 name / username / email 回显回来（这是这个测试网站的设计方式）

👉 所以这不是你 JMeter 配错，而是这个网站本身就只返回 id。

2.看 Request确认数据是否正确发出

在 View Results Tree 里：

  1. 点一条请求
  2. 右侧切到标签页：Request
  3. 点 Raw 或 Body Data

你应该能看到你发出去的内容，比如：

复制代码 
{
  "name": "user_123",
  "username": "u_abcd",
  "email": "mail_88@test.com"
}

如果这里是对的，说明：

✅ 你的造数据是成功的

✅ JMeter 参数 / 随机函数没问题

❌ 只是服务器没回显而已

6.开始真正"造数据"（自动变用户名）

用 JMeter 自动生成随机用户

把刚才 Body Data 改成这样：

复制代码 
{
  "name": "user_${__Random(1,1000)}",
  "username": "u_${__RandomString(5,abcdef,)}",
  "email": "mail_${__Random(1,999)}@test.com"
}

再点 ▶️ 运行。

会看到每一次请求返回的数据都不一样

这就是真正的：批量造数据测试接口 ✅

通过这个练习，你已经掌握：

  • ✔️ 创建 Thread Group（模拟用户）
  • ✔️ 配置 HTTP 请求
  • ✔️ 发送 POST 造数据
  • ✔️ 查看返回结果
  • ✔️ 用随机函数生成测试数据

这就是性能测试 / 接口造数据的核心基础。

实战2： ReqRes 免费测试 API

官网接口地址：

复制代码 
https://reqres.in/api/users

这个接口的特点：

  • ✔️ 支持 POST 创建用户
  • ✔️ 会把你发的数据 + id + 创建时间全部返回
  • ✔️ 非常适合学习 JMeter 接口测试

基本配置

  • Protocol：https
  • Server Name or IP：reqres.in
  • Method：POST
  • Path：/api/users

运行报错403：

原因：是 ReqRes 把 JMeter 当成"机器人"拦掉了你返回头里有这些关键信息：

  • server: cloudflare
  • cf-mitigated: challenge

这说明：

👉 ReqRes 网站现在开启了 Cloudflare 防刷 / 防机器人机制

👉 它会拦截：

  • JMeter
  • Postman（有时也会）
  • 非浏览器请求

所以：

  • 浏览器访问没问题
  • 但 JMeter 发请求 → 被当成攻击流量 → 直接 403 拦掉 ❌

这是接口测试里非常真实的一种情况

1.对于刚才那个：

复制代码 
https://reqres.in/api/users

现在这个状态是：

❌ 用 JMeter 发请求 → 被 Cloudflare 拦截 → 返回 403

❌ 请求根本没有真正到达业务接口

❌ 所以：一条假数据都没有造成功

也就是说：👉 现在在 JMeter 里用这个地址 = 完全造不了数据。

2.403 在测试里到底意味着什么？

你看到的是：

复制代码 
HTTP/1.1 403 Forbidden
cf-mitigated: challenge
server: cloudflare

这在测试领域的含义非常明确：

  • 请求被 安全网关 / 防火墙 拦截
  • 还没到真正的业务接口层
  • 后端根本没收到你的数据

所以：

  • ❌ 没创建用户
  • ❌ 没写数据库
  • ❌ 没造任何假数据
  • ❌ 只是被挡在门口

实战3：Postman 官方测试接口

接口地址：

复制代码 
https://postman-echo.com/post

这个接口的特点：

  • ✔️ 专门给测试工具用
  • ✔️ 永远不会封 IP / 拦 JMeter
  • ✔️ 会把你发的所有数据完整返回
  • ✔️ 特别适合新手学习
1.在 HTTP Request 里填
  • Protocol ：https
  • Server Name or IP ：postman-echo.com
  • Method ：POST
  • Path ：/post
2.在 Body Data 里输入
复制代码 
{
  "name": "test_user",
  "username": "test001",
  "email": "test001@test.com"
}
3.HTTP Header（新手最容易忽略）

很多接口必须声明你发的是 JSON。

右键 HTTP Request → Add → Config Element → HTTP Header Manager

在右侧加两行：

Name Value
Content-Type application/json
Accept application/json
4.运行测试

点绿色 ▶️，然后打开 View Results Tree → 点一条请求 → 看 Response Data

返回内容：

复制代码 
{
  "args": {},--->URL 上的参数（GET 参数）;这次是 POST + Body 方式，所以这里是空的，是正常的
  "data": {------------------------->服务器收到的「原始请求体」,原始收到的字符串内容
    "name": "test_user",
    "username": "test001",
    "email": "test001@test.com"
  },
  "files": {},--->上传文件时用的
  "form": {},--->表单方式提交的数据（x-www-form-urlencoded / form-data）;用的是 JSON 提交，所以这里是空的，是正常的
  "headers": {--------------------------------------->请求头信息
    "host": "postman-echo.com",------------------->请求的域名
    "content-length": "87",------------------------>body大小
    "accept-encoding": "gzip, br",----------------->是否支持压缩
    "x-forwarded-proto": "https",
    "accept": "application/json",----------------->希望服务器返回的格式JSON
    "content-type": "application/json",----------->告诉服务器：发送的是JSON 格式的数据。错了，会导致服务器收不到参数，会报错400/415
    "user-agent": "Apache-HttpClient/4.5.14 (Java/1.8.0_421)"--->告诉服务器：是用 JMeter（底层是 Java HttpClient）发的请求
  },
  "json": {------------------------------------>服务器解析后的 JSON 对象（最常用）,⭐ 真正"有业务意义的数据"，一般都在 "json" 这一块里
    "name": "test_user",
    "username": "test001",
    "email": "test001@test.com"
  },
  "url": "https://postman-echo.com/post"----------->真正的请求url，用来确定请求地址是否正确、是否被重定向
}

最外层结构说明（总览）

你的返回是一个 JSON 对象，大概分成 7 块：

复制代码 
{
"args": {},
"headers": {...},
"data": {...},
"form": {},
"files": {},
"json": {...},
"url": "https://postman-echo.com/post"
}

1."url" ------ 你真正请求的地址

复制代码 
"url": "https://postman-echo.com/post"

👉 含义：

这是服务器告诉你：

"你刚刚请求的 URL 是这个"

用来确认：

  • 请求地址对不对
  • 有没有被重定向

这个字段一般不用测试重点关注。

2."headers" ------ 你这次请求的「请求头信息」

复制代码 
"headers": {
  "content-length": "88",
  "x-forwarded-proto": "https",
  "host": "postman-echo.com",
  "content-type": "application/json",
  "accept-encoding": "gzip, br",
  "accept": "application/json",
  "user-agent": "Apache-HttpClient/4.5.14 (Java/1.8.0_421)"
}

这是：

👉 你这次 HTTP 请求带过去的请求头

重点给你挑几个最重要的解释：

🔹 1. content-type

复制代码 
"content-type": "application/json"

含义：

你在告诉服务器：

"我发过去的是 JSON 格式的数据"

这是接口测试里最重要的头之一 。

如果这里错了，经常会导致：

  • 服务器收不到参数
  • 返回 400 / 415 错误

你这里是 ✅ 完全正确的。

🔹 2. user-agent

复制代码 
"user-agent": "Apache-HttpClient/4.5.14 (Java/1.8.0_421)"

含义：

告诉服务器：

"我是用 JMeter（底层是 Java HttpClient）发的请求"

将来你在公司会看到：

  • Postman
  • 浏览器
  • App

都会有不同的 user-agent。

🔹 3. accept

复制代码 
"accept": "application/json"

含义：

你在说：

"我希望服务器返回 JSON 给我"

🔹 4. 其他几个

  • host：你请求的是哪个域名
  • content-length：你这次 body 大小（88 字节）
  • accept-encoding：是否支持压缩

这些一般不用你重点关心，知道是"请求头信息"就够了。

3."data" ------ 服务器收到的「原始请求体」

复制代码 
"data": {
  "name": "user_47",
  "email": "mail_298@test.com",
  "username": "u_eabfa"
}

🔥🔥 这是非常非常重要的一块。

它表示：

👉 服务器真正"收到的请求 Body 内容"

也就是说：

你在 JMeter 里造的数据：

已经：

  • ✅ 成功发出
  • ✅ 服务器成功接收
  • ✅ 格式完全正确

这一块是你将来做断言、校验、取值时的重点对象。

4."json" ------ 服务器解析后的 JSON 对象（最常用）

复制代码 
"json": {
  "name": "user_47",
  "email": "mail_298@test.com",
  "username": "u_eabfa"
}

这一块和 data 看起来一样，但含义略有不同：

  • data：原始收到的字符串内容
  • json：服务器已经帮你解析成 JSON 对象后的结果

在真实项目里：

👉 你做断言 / 提取字段

👉 基本都是从这一块取

例如以后你会经常做：

  • 校验 name 是否正确
  • 提取 username 保存成变量
  • 判断 email 是否符合规则

所以你现在记住一句话就够了：

⭐ 真正"有业务意义的数据"，一般都在 "json" 这一块里

5."args" / "form" / "files" ------ 这次没用到的部分

🔹 1. args

复制代码 
"args": {}

含义：

这是 URL 上的参数（GET 参数）

例如如果你访问：

复制代码 
/post?age=18&city=beijing

这里就会显示：

复制代码 
"args": {
"age": "18",
"city": "beijing"
}

你这次是 POST + Body 方式，所以这里是空的 ✅ 正常。

🔹 2. form

复制代码 
"form": {}

这是：

表单方式提交的数据（x-www-form-urlencoded / form-data）

你现在用的是 JSON 提交，所以这里是空的 ✅ 正常。

🔹 3. files

复制代码 
"files": {}

这是：

上传文件时用的

你现在没传文件，所以空的 ✅ 完全正常。

⭐ 最重要的一块："json"（你真正造的数据）

复制代码 
"json": {
  "name": "test_user",
  "username": "test001",
  "email": "test001@test.com"
}

👉 这就是：

你在 Body Data 里发出去的 JSON 数据

这说明：

  • ✅ 服务器正确收到了你的数据
  • ✅ JMeter 请求发送成功
  • ✅ 造数据流程是通的

🔹"data"（另一种回显方式）

复制代码 
"data": {
  "name": "test_user",
  "username": "test001",
  "email": "test001@test.com"
}

这个和 json 基本一样，也是回显你发的内容。

🔹 "headers"（你这次请求带的请求头）

复制代码 
"headers": {
  "accept": "application/json",
  "content-type": "application/json",
  "user-agent": "Apache-HttpClient/4.5.14 (Java/1.8.0_421)"
}

这里可以看到：

  • Content-Type 正确是 application/json ✅
  • User-Agent 是 JMeter 自己的

🔹 "url"

复制代码 
"url": "https://postman-echo.com/post"

表示你真正请求的地址。

用接口测试的专业角度来看你这次结果：

项目 是否成功 说明
请求发送成功 ✅ 没有 403 / 400 / 500
JSON 格式正确 ✅ content-type 正确
数据成功造出 ✅ name / email / username 全部变化
服务器成功接收 ✅ data / json 里完整显示
返回内容可解析 ✅ 格式标准 JSON
加上"随机造数据"（真正开始造大量数据）

把 Body Data 改成这样：

复制代码 
{
  "name": "user_${__Random(1,1000)}",
  "username": "u_${__RandomString(5,abcdef,)}",
  "email": "mail_${__Random(1,999)}@test.com"
}

再跑一次。

你会看到每一条 Response 里的数据都不一样：

这就是真正的：

👉 自动批量造测试数据 👌

实战4：JSONPlaceholder（全球最常用的接口测试练习站）

官网地址（不用注册）： 👉 https://jsonplaceholder.typicode.com

接口 1：查询用户列表（GET 请求）
复制代码 
https://jsonplaceholder.typicode.com/users

浏览器里打开你就能看到一堆 JSON 用户数据。

json 复制代码 
[
  {
    "id"：1，
    姓名：Leanne Graham，
    "username": "Bret",
    电子邮件：Sincere@april.biz，
    "地址"： {
      "街道": "库拉斯之光"
      "套房": "556号公寓"
      "城市": "格温伯勒"
      邮政编码：92998-3874，
      "geo": {
        纬度：-37.3159，
        "lng": "81.1496"
      }
    },
    "电话"："1-770-736-8031 x56442"
    网站：hildegard.org，
    "公司"： {
      "name": "Romaguera-Crona",
      "catchPhrase": "多层客户端-服务器神经网络",
      "bs": "利用实时电子市场"
    }
  },
  {
    "id"：2，
    姓名：埃尔文·豪厄尔
    "username": "Antonette",
    电子邮件：Shanna@melissa.tv，
    "地址"： {
      "街道": "维克多平原"
      "套房": "879号套房"
      "城市"： "威斯康堡"
      邮政编码：90566-7771，
      "geo": {
        "lat": "-43.9509",
        "lng": "-34.4618"
      }
    },
    电话：010-692-6593 x09125，
    网站：anastasia.net，
    "公司"： {
      "name": "Deckow-Crist",
      "口号"："积极主动的教学应急措施"，
      "bs": "协同可扩展的供应链"
    }
  },
  {
    "id"：3，
    姓名：克莱门汀·鲍赫
    "username": "Samantha",
    电子邮件：Nathan@yesenia.net，
    "地址"： {
      "街道": "道格拉斯延长线"
      "套房": "847套房"
      "城市": "麦肯齐黑文"
      邮政编码：59590-4157，
      "geo": {
        "lat": "-68.6102",
        "lng": "-47.0653"
      }
    },
    电话：1-463-123-4447
    网站：ramiro.info，
    "公司"： {
      姓名：Romaguera-Jacobson，
      "catchPhrase": "面对面的分岔界面"
      "bs": "启用战略应用"
    }
  },
  {
    "id"：4，
    姓名：帕特里夏·莱布萨克
    "username": "Karianne",
    电子邮件：Julianne.OConner@kory.org
    "地址"： {
      "街道": "Hoeger Mall"
      "套房": "692号公寓"
      "城市"： "南埃尔维斯"
      邮政编码：53919-4257，
      "geo": {
        "lat": "29.4572",
        "lng": "-164.2990"
      }
    },
    电话：493-170-9623 x156，
    网站：kale.biz
    "公司"： {
      "name": "Robel-Corkery",
      "宣传语"："多层级零容忍生产力"
      "bs": "过渡到尖端网络服务"
    }
  },
  {
    "id"：5，
    姓名：切尔西·迪特里希
    "username": "Kamren",
    电子邮件："Lucio_Hettinger@annie.ca",
    "地址"： {
      "街道": "滑雪漫步"
      "套房": "351套房"
      城市：罗斯科维尤，
      邮政编码：33263，
      "geo": {
        纬度：-31.8129，
        "lng": "62.5342"
      }
    },
    电话：(254)954-1289，
    网站：demarco.info，
    "公司"： {
      "名称": "Keebler LLC",
      "宣传语"："以用户为中心的容错解决方案"，
      "bs": "彻底改变端到端系统"
    }
  },
  {
    "id"：6，
    "name": "丹尼斯·舒利斯特女士",
    "username": "Leopoldo_Corkery",
    电子邮件："Karley_Dach@jasper.info",
    "地址"： {
      "街道": "诺伯托十字路口"
      "套房": "950号公寓"
      "城市"： "南克里斯蒂"
      邮政编码： 23505-1337，
      "geo": {
        纬度：-71.4197，
        "lng": "71.7478"
      }
    },
    "电话"："1-477-935-8478 x6430"
    网站：ola.org，
    "公司"： {
      "name": "Considine-Lockman",
      "catchPhrase": "同步底线界面"
      "bs": "e-enable 创新应用"
    }
  },
  {
    "id"：7，
    姓名：库尔蒂斯·魏斯纳特
    "username": "Elwyn.Skiles",
    电子邮件：Telly.Hoeger@billy.biz，
    "地址"： {
      "街道": "雷克斯小径"
      "套房": "280套房"
      "城市"： "豪茅斯"
      邮政编码：58804-1099，
      "geo": {
        "lat": "24.8918",
        "lng": "21.8984"
      }
    },
    电话：210.067.6132
    网站：elvis.io，
    "公司"： {
      "名称": "Johns Group",
      "catchPhrase": "可配置的多媒体任务组",
      "bs": "生成企业电商"
    }
  },
  {
    "id"：8，
    "姓名": "Nicholas Runolfsdottir V",
    "username": "Maxime_Nienow",
    电子邮件：Sherwood@rosamond.me，
    "地址"： {
      "街道": "埃尔斯沃思峰"
      "套房": "729套房"
      "城市"： "Aliyaview"，
      邮政编码：45169，
      "geo": {
        纬度：-14.3990，
        lng：-120.7677
      }
    },
    电话：586.493.6943 x140
    "网站": "jacynthe.com",
    "公司"： {
      "名称": "Abernathy集团",
      "宣传语"："实施了次要概念"，
      "bs": "e-启用可扩展的电子零售商"
    }
  },
  {
    "id"：9，
    姓名：格伦娜·雷切特
    "username": "Delphine",
    电子邮件：Chaim_McDermott@dana.io，
    "地址"： {
      "街道": "戴纳公园"
      "套房": "449号套房"
      "城市": "巴塞洛缪伯里"
      邮政编码： 76495-3109，
      "geo": {
        "lat": "24.6463",
        lng：-168.8889
      }
    },
    电话：(775)976-6794 x41206，
    "网站": "conrad.com",
    "公司"： {
      "name": "Yost and Sons",
      "catchPhrase": "可切换的基于上下文的项目",
      "bs": "聚合实时技术"
    }
  },
  {
    "id"：10，
    姓名：克莱门蒂娜·杜布克，
    "username": "Moriah.Stanton",
    电子邮件："Rey.Padberg@karina.biz",
    "地址"： {
      "街道": "凯蒂收费公路"
      "套房": "198号套房"
      "城市"： "莱布萨克伯里"，
      邮政编码：31428-2261
      "geo": {
        纬度：-38.2386，
        "lng": "57.2232"
      }
    },
    电话：024-648-3804
    网站：ambrose.net，
    "公司"： {
      "名称": "Hoeger LLC",
      "口号"："集中授权工作组"
      "bs": "目标端到端模型"
    }
  }
]
1.新建一个测试计划，配置线程组

1.打开 JMeter

2.在 Test Plan 上：右键 → Add → Threads (Users) → Thread Group

3.点 Thread Group，右侧填：

  • Number of Threads (users)：1
  • Ramp-Up Period：1
  • Loop Count：1

意思是： 1 个用户 发 1 次请求

2.添加 HTTP 请求

在 Thread Group 上：右键 → Add → Sampler → HTTP Request

右侧填写：【最重要的地方】

项目 填写内容
Protocol https
Server Name or IP jsonplaceholder.typicode.com
Port Number 留空
Method GET
Path /users

⚠️ 注意：

  • Path 只写 /users
  • 不要把整个 URL 粘进去
3.加一个查看结果的监听器

在 Thread Group 上：右键 → Add → Listener → View Results Tree 这个是最重要的新手监听器。

4.运行

点工具栏的绿色三角形 ▶️

然后：

  • 点左边的 View Results Tree
  • 点中间的请求
  • 点右边的：

👉 Response Data

你应该能看到一大串 JSON，比如：

json 复制代码 
[
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
      "name": "Romaguera-Crona",
      "catchPhrase": "Multi-layered client-server neural-net",
      "bs": "harness real-time e-markets"
    }
  },
  {
    "id": 2,
    "name": "Ervin Howell",
    "username": "Antonette",
    "email": "Shanna@melissa.tv",
    "address": {
      "street": "Victor Plains",
      "suite": "Suite 879",
      "city": "Wisokyburgh",
      "zipcode": "90566-7771",
      "geo": {
        "lat": "-43.9509",
        "lng": "-34.4618"
      }
    },
    "phone": "010-692-6593 x09125",
    "website": "anastasia.net",
    "company": {
      "name": "Deckow-Crist",
      "catchPhrase": "Proactive didactic contingency",
      "bs": "synergize scalable supply-chains"
    }
  },
  {
    "id": 3,
    "name": "Clementine Bauch",
    "username": "Samantha",
    "email": "Nathan@yesenia.net",
    "address": {
      "street": "Douglas Extension",
      "suite": "Suite 847",
      "city": "McKenziehaven",
      "zipcode": "59590-4157",
      "geo": {
        "lat": "-68.6102",
        "lng": "-47.0653"
      }
    },
    "phone": "1-463-123-4447",
    "website": "ramiro.info",
    "company": {
      "name": "Romaguera-Jacobson",
      "catchPhrase": "Face to face bifurcated interface",
      "bs": "e-enable strategic applications"
    }
  },
  {
    "id": 4,
    "name": "Patricia Lebsack",
    "username": "Karianne",
    "email": "Julianne.OConner@kory.org",
    "address": {
      "street": "Hoeger Mall",
      "suite": "Apt. 692",
      "city": "South Elvis",
      "zipcode": "53919-4257",
      "geo": {
        "lat": "29.4572",
        "lng": "-164.2990"
      }
    },
    "phone": "493-170-9623 x156",
    "website": "kale.biz",
    "company": {
      "name": "Robel-Corkery",
      "catchPhrase": "Multi-tiered zero tolerance productivity",
      "bs": "transition cutting-edge web services"
    }
  },
  {
    "id": 5,
    "name": "Chelsey Dietrich",
    "username": "Kamren",
    "email": "Lucio_Hettinger@annie.ca",
    "address": {
      "street": "Skiles Walks",
      "suite": "Suite 351",
      "city": "Roscoeview",
      "zipcode": "33263",
      "geo": {
        "lat": "-31.8129",
        "lng": "62.5342"
      }
    },
    "phone": "(254)954-1289",
    "website": "demarco.info",
    "company": {
      "name": "Keebler LLC",
      "catchPhrase": "User-centric fault-tolerant solution",
      "bs": "revolutionize end-to-end systems"
    }
  },
  {
    "id": 6,
    "name": "Mrs. Dennis Schulist",
    "username": "Leopoldo_Corkery",
    "email": "Karley_Dach@jasper.info",
    "address": {
      "street": "Norberto Crossing",
      "suite": "Apt. 950",
      "city": "South Christy",
      "zipcode": "23505-1337",
      "geo": {
        "lat": "-71.4197",
        "lng": "71.7478"
      }
    },
    "phone": "1-477-935-8478 x6430",
    "website": "ola.org",
    "company": {
      "name": "Considine-Lockman",
      "catchPhrase": "Synchronised bottom-line interface",
      "bs": "e-enable innovative applications"
    }
  },
  {
    "id": 7,
    "name": "Kurtis Weissnat",
    "username": "Elwyn.Skiles",
    "email": "Telly.Hoeger@billy.biz",
    "address": {
      "street": "Rex Trail",
      "suite": "Suite 280",
      "city": "Howemouth",
      "zipcode": "58804-1099",
      "geo": {
        "lat": "24.8918",
        "lng": "21.8984"
      }
    },
    "phone": "210.067.6132",
    "website": "elvis.io",
    "company": {
      "name": "Johns Group",
      "catchPhrase": "Configurable multimedia task-force",
      "bs": "generate enterprise e-tailers"
    }
  },
  {
    "id": 8,
    "name": "Nicholas Runolfsdottir V",
    "username": "Maxime_Nienow",
    "email": "Sherwood@rosamond.me",
    "address": {
      "street": "Ellsworth Summit",
      "suite": "Suite 729",
      "city": "Aliyaview",
      "zipcode": "45169",
      "geo": {
        "lat": "-14.3990",
        "lng": "-120.7677"
      }
    },
    "phone": "586.493.6943 x140",
    "website": "jacynthe.com",
    "company": {
      "name": "Abernathy Group",
      "catchPhrase": "Implemented secondary concept",
      "bs": "e-enable extensible e-tailers"
    }
  },
  {
    "id": 9,
    "name": "Glenna Reichert",
    "username": "Delphine",
    "email": "Chaim_McDermott@dana.io",
    "address": {
      "street": "Dayna Park",
      "suite": "Suite 449",
      "city": "Bartholomebury",
      "zipcode": "76495-3109",
      "geo": {
        "lat": "24.6463",
        "lng": "-168.8889"
      }
    },
    "phone": "(775)976-6794 x41206",
    "website": "conrad.com",
    "company": {
      "name": "Yost and Sons",
      "catchPhrase": "Switchable contextually-based project",
      "bs": "aggregate real-time technologies"
    }
  },
  {
    "id": 10,
    "name": "Clementina DuBuque",
    "username": "Moriah.Stanton",
    "email": "Rey.Padberg@karina.biz",
    "address": {
      "street": "Kattie Turnpike",
      "suite": "Suite 198",
      "city": "Lebsackbury",
      "zipcode": "31428-2261",
      "geo": {
        "lat": "-38.2386",
        "lng": "57.2232"
      }
    },
    "phone": "024-648-3804",
    "website": "ambrose.net",
    "company": {
      "name": "Hoeger LLC",
      "catchPhrase": "Centralized empowering task-force",
      "bs": "target end-to-end models"
    }
  }
]

这是第一次：

✅ 用 JMeter 成功测通一个真实接口

✅ 成功拿到服务器返回数据

接口 2：查询某一个用户-带参数的接口

带参数的接口：

复制代码 
https://jsonplaceholder.typicode.com/users/1

在 JMeter 里改一下：

HTTP Request 里：

  • Method：GET

  • Path 改成：

    /users/1

运行：

json 复制代码 
{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "suite": "Apt. 556",
    "city": "Gwenborough",
    "zipcode": "92998-3874",
    "geo": {
      "lat": "-37.3159",
      "lng": "81.1496"
    }
  },
  "phone": "1-770-736-8031 x56442",
  "website": "hildegard.org",
  "company": {
    "name": "Romaguera-Crona",
    "catchPhrase": "Multi-layered client-server neural-net",
    "bs": "harness real-time e-markets"
  }
}

这就是：🔥 典型的"根据 ID 查询详情接口"

接口 3：新增用户（POST） -造数据接口

地址：

复制代码 
https://jsonplaceholder.typicode.com/posts

在 JMeter 里这样配置：

1.新增一个 HTTP Request
项目 填写
Protocol https
Server Name jsonplaceholder.typicode.com
Method POST
Path /posts
2.添加 HTTP Header Manager（非常重要）

在这个 HTTP Request 上：

  • 右键 → Add → Config Element → HTTP Header Manager

添加两行：

Name Value
Content-Type application/json
Accept application/json
3.填写 Body 数据（造一条假数据）

在 HTTP Request 里：

  • 点 Body Data

  • 填：

    {
    "title": "test_title",
    "body": "this is a test body",
    "userId": 101
    }

4.添加监听器，点击运行

在 View Results Tree → Response Data 里，你会看到类似：

说明：

  • 你成功发了 POST 请求
  • 服务器成功收到了数据
  • 并返回了一个新 id

总结一下你已经学会的能力：

能力 是否掌握
发送 GET 请求 ✅
发送 POST 请求 ✅
设置 Header ✅
造 JSON 数据 ✅
查看 Response ✅
判断是否成功 ✅

这已经是：🔥 公司接口测试入门级核心技能

1.断言（Assertion）」：自动判断接口是否成功

配置断言

  • Apply to（作用范围）

  • Response Field to Test（测试哪里）

  • Pattern Matching Rules（匹配规则）

  • Patterns to Test（断言内容）

因为在真实工作里：

  • 不是"能发请求就行"
  • 而是：

❓ 接口到底对不对 ？

❓ 返回结果是不是符合预期 ？

❓ 系统有没有悄悄出错？

这些，全靠：断言（Assertion）

JSONPlaceholder网站

用这个接口来练断言（GET 查询接口）：

复制代码 
https://jsonplaceholder.typicode.com/users/1

浏览器打开你会看到：

json 复制代码 
{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "suite": "Apt. 556",
    "city": "Gwenborough",
    "zipcode": "92998-3874",
    "geo": {
      "lat": "-37.3159",
      "lng": "81.1496"
    }
  },
  "phone": "1-770-736-8031 x56442",
  "website": "hildegard.org",
  "company": {
    "name": "Romaguera-Crona",
    "catchPhrase": "Multi-layered client-server neural-net",
    "bs": "harness real-time e-markets"
  }
}

这是一个固定返回值接口，特别适合练断言

🎯 断言目标：

1️⃣ 返回状态码必须是：200

2️⃣ 返回结果里必须包含："id": 1

3️⃣ 返回结果里必须包含："username": "Bret"

如果有一个不对：🔴 这次接口请求 = 失败（标红）

1.先把这个 GET 接口跑通

在 Thread Group 下面，新建：右键 Thread Group → Add → Sampler → HTTP Request

填写：

项目 内容
Protocol https
Server Name or IP jsonplaceholder.typicode.com
Method GET
Path /users/1

再加一个监听器（如果你还没有）： Thread Group → Add → Listener → View Results Tree

先点 ▶️ 跑一次，确认：

  • 请求是绿色
  • Response Data 里能看到 JSON 用户信息
2.加第一个断言（状态码断言）

这是最基础、最重要、每天都在用的断言。

🎯 目标：判断返回码必须是 200

操作步骤

在这个 HTTP Request 上：右键 → Add → Assertions → Response Assertion

右侧这样设置：

【第一部分：Response Field to Test】

勾选：✅ Response Code

【第二部分：Pattern Matching Rules】

选择：✅ Equals

【第三部分：Patterns to Test】

点 Add，输入：

复制代码 
200

意思是：

👉 如果返回码 ≠ 200

👉 这条请求直接判定失败

🔹 现在点 ▶️ 再跑一次

然后去：

  • View Results Tree
  • 点这条请求

你会看到：

  • 绿色成功 ✅
  • Assertions 里显示通过（JMeter5.6.3版本：✅ 断言"通过"时，默认是【不显示任何提示的】 ❌ 只有当断言"失败"时，才会明确显示错误信息）

断言通过（正常情况）：

  • 请求是绿色的 ✅
  • 在 Sampler Result 里：
    • Response code = 200
    • Success = true

而且：

  • 没有任何 "Assertion failure" 字样
  • Assertion Results 可能是空的

这就说明：

🎯 所有断言全部通过

如果断言失败：

  • 这条请求会变成 🔴 红色
  • 点进去，在：

👉 Sampler Result 里会看到：

  • Assertion failure: true
  • 或 Assertion failure message: ...

👉 Assertion Results 标签页里会看到：

  • 哪一个断言失败
  • 期望值 / 实际值
Assertion Results（断言结果监听器）

工作中我们常用这个：🌟 Assertion Results（断言结果监听器）

操作：在 Thread Group 上：👉 右键 → Add → Listener → Assertion Results 然后再跑一次

在 JMeter 5.6.3 里：

🔹 Assertion Results 窗口显示 HTTP Request 条目 ≠ 说明断言失败

🔹 只要没有红色、没有 Failure Message、Failure = false

👉 那就是：全部断言通过了 ✅

也就是说：

现在你的情况是：

✔ 3 个 HTTP Request 都跑过了

✔ 每一个请求里的断言都通过

👉 完全正常，不是错误 🎉

在 JMeter 5.x 版本中：

👉 Assertion Results 的真实含义是："列出【执行过并且包含断言的请求结果】"

错误断言

接口：https://postman-echo.com/post

1.准备一个一定会返回成功的 POST 请求（基础环境）

2.先加一个"正确的断言"（确认通过状态）

在这个 HTTP Request 上：👉 右键 → Add → Assertions → Response Assertion

设置如下：

🔹 Apply to：勾选：Main sample and sub-samples

🔹 Response Field to Test：勾选：Response Data

🔹 Pattern Matching Rules：选择：Contains

🔹 Patterns to Test：填一个肯定存在的字段，比如："test_user"

🟡 小提示
  • Contains → 字符串直接包含，空格敏感
  • Matches → 正则匹配，更灵活
  • Equals → 必须完全一样，包括空格
  • Substring → 和 Contains 类似，但不常用

3.运行

4.故意制造一个"错误断言" ❌

把 Patterns to Test 改成："this_value_never_exist_123" （随便写，只要保证接口不会返回这个字符串）

5.运行

🔴 在 View Results Tree 里：

  • 这条 HTTP Request 变成：红色
  • 点进去 → 右边：

在 Sampler Result 里你会看到：

复制代码 
Assertion failure: true
Assertion failure message: Test failed: text not found

🔴 在 Assertion Results 里：

你会看到一行记录：

  • Label：HTTP Request 名字
  • Failure：true ❌
  • Failure Message：类似：Test failed: text not found

这就说明：

🎯 断言真正生效了

JMeter 已经帮你"自动发现错误结果"

更真实的错误断言

接口返回里一定有：

复制代码 
"username": "test001"

你可以这样断言：

Patterns to Test："username":"wrong_name"

这样就是：

  • 字段存在
  • 但值不对
  • 断言失败

这在实际工作中非常常用（校验字段值正确性）。

JSON Extractor（提取返回里的字段当变量）

比如：

  • 从返回里取出 username
  • 或取出 id
  • 再用到下一个接口里

这是接口自动化的"灵魂技能"。

真实完整接口自动化示例

接口： https://httpbin.org

这是：

  • 专门给接口测试 / 自动化用的网站
  • 不封 JMeter
  • 返回标准 JSON
  • 非常适合练：POST + 断言 + JSON 提取

1.目标效果：

1️⃣ 发送 POST 请求创建一个用户

2️⃣ 断言返回里包含 id（创建成功）

3️⃣ 用 JSON Extractor 提取返回的 id

4️⃣ 用这个 id 再发一个 GET 请求查询用户

5️⃣ 再断言查询结果正确

2.步骤：

1.跑通POST接口
json 复制代码 
{
  "name": "Tom",
  "username": "tom_001",
  "email": "tom@test.com"
}
Name Value
Content-Type application/json
Accept application/json

运行效果：

json 复制代码 
{
  "args": {}, 
  "data": "{\r\n  \"name\": \"Tom\",\r\n  \"username\": \"tom_001\",\r\n  \"email\": \"tom@test.com\"\r\n}\r\n", 
  "files": {}, 
  "form": {}, 
  "headers": {
    "Accept": "application/json", 
    "Content-Length": "77", 
    "Content-Type": "application/json", 
    "Host": "httpbin.org", 
    "User-Agent": "Apache-HttpClient/4.5.14 (Java/1.8.0_421)", 
    "X-Amzn-Trace-Id": "Root=1-69773c22-1bb75fa5652b0a5f21abb93d"
  }, 
  "json": {
    "email": "tom@test.com", 
    "name": "Tom", 
    "username": "tom_001"
  }, 
  "origin": "223.167.64.69", 
  "url": "https://httpbin.org/post"
}

看到这个说明：

🎉 接口正常

🎉 JMeter 没被拦截

🎉 可以继续练断言 + 提取

接口自动化的核心技能组合

✅ 断言（验证接口返回对不对）

✅ 提取变量（从返回里取值）

✅ 使用变量（后续请求 / 打印验证）

2. 断言

目标：

👉 让 JMeter 自动判断：返回结果里必须包含 "tom_001"

👉 如果没有，就算失败

步骤：

1.在 POST 请求上添加断言

在POST Create User (httpbin) 这个 HTTP Request 上： 右键 → Add → Assertions → Response Assertion

2.在 Response Assertion 里这样设置：

① Apply to（作用范围）勾选：☑️ Main sample only

② Response Field to Test（测试哪里）勾选：☑️ Response Text （默认一般就是这个）

③ Pattern Matching Rules（匹配规则）选择：🔘 Contains（包含）

④ Patterns to Test（断言内容）在下面的大框里，点 Add，然后输入：tom_00

3.运行测试

1.Assertion Results 窗口：如果成功，会看到：No assertion failures 或者 空白（在 JMeter 5.6.3 里，成功通常不显示内容）

2.请求图标颜色：🟢 绿色 = 断言通过

3.用 JSON Extractor 提取 username

现在我们要从返回的 JSON 里，把："username": "tom_001" 取出来，存成一个变量，比如：${username}

步骤：

1.在 POST 请求上添加 JSON Extractor

右键 → Add → Post Processors → JSON Extractor

2.配置 JSON Extractor

在 JSON Extractor 里填：

  • Name（随便）：Extract username

  • Names of created variables（变量名）：username

⚠️ 记住：后面用的变量就是 ${username}

  • JSON Path Expressions：$.json.username

我们返回的结构里是：

复制代码 
"json": {
  "username": "tom_001"
}

所以路径是：$.json.username

  • Match No. ：填：1

  • Default Values（可选，但建议填）：NOT_FOUND

3.运行测试

现在变量已经被提取出来了，但我们还没"看到"它。

4.打印变量，验证提取成功

👉用一个最简单的方法： 加一个 Debug Sampler + 查看变量

步骤：

1.添加 Debug Sampler

在 Thread Group 上（不是在 HTTP Request 上）： 右键 → Add → Sampler → Debug Sampler

2.添加查看结果监听器（如果你还没加）

确认你已经有： View Results Tree（如果没有：Thread Group → Add → Listener → View Results Tree）

3.运行

在 View Results Tree 里：

👉 点 Debug Sampler

👉 切到右边的：

  • Response Data 或
  • Response Body

你会看到一大堆变量，其中找这一行：

复制代码 
username=tom_001

🎉🎉🎉 如果看到这个，说明：

  • ✅ POST 成功
  • ✅ JSON 返回正常
  • ✅ 断言生效
  • ✅ 变量提取成功

2.接口关联测试

企业里最常见的： 接口关联测试（上下游接口）：

用这个 ${username} 作为参数，再发一个 GET / POST 请求 ，模拟：先创建用户 → 再查询用户

思路
复制代码 
① POST 创建用户
   ↓（JSON Extractor 提取 username）
② GET 查询用户（用 ${username}）
   ↓
③ 断言校验（是不是查到刚创建的用户）
接口

为了避免 Cloudflare / 403 / 验证码坑 ，我们用这两个 测试专用接口：

✅ POST 创建用户（会回显数据）
复制代码 
https://httpbin.org/post
✅ GET 查询（模拟"查用户"）
复制代码 
https://httpbin.org/get?username=xxx

⚠️ 说明一句：httpbin 不是真的数据库 ，但它会把你传的参数 原样返回，非常适合练接口关联。

步骤
1.POST 创建用户

1️⃣ HTTP Request（POST）：Thread Group → Add → Sampler → HTTP Request

设置：

  • Name：POST Create User
  • Method：POST
  • Server Name：httpbin.org
  • Path：/post

  • Body Data（JSON）

    复制代码 
    {
  "username": "tom_001",
  "email": "tom@test.com"
}

2️⃣ HTTP Header Manager（必须）

挂在 POST Create User 下面：

Name Value
Content-Type application/json
Accept application/json

3️⃣ JSON Extractor（重点）

挂在 POST Create User 下面：

  • Name：Extract username
  • Apply to：Main sample only
  • Names of created variables：username
  • JSON Path Expressions：$.json.username
  • Match No：1

👉 这一步的效果是：${username} = tom_001

2.GET 查询用户（接口关联的关键）

1️⃣ 添加一个新的 HTTP Request（GET）:👉 右键 Thread Group → Add → Sampler → HTTP Request

设置：

  • Name：GET Query User
  • Method：GET
  • Server Name：httpbin.org
  • Path：/get?username=${username}

⚠️ 重点来了：这里的 ${username} 就是上一步 POST 提取出来的变量

2️⃣ 给 GET 请求加断言（验证是否关联成功）Response Assertion

👉 挂在 GET Query User 下面

设置：

  • Field to Test：Text Response
  • Pattern Matching Rules：Contains
  • Patterns to Test：tom_001

含义：如果 GET 返回结果里 能看到刚才 POST 的 username ，说明接口关联成功

3.验证变量是否真的传过来了（Debug）

1.添加Debug Sampler： 挂在 Thread Group 下（和两个 HTTP Request 同级）

设置：JMeter variables：True

2.添加View Results Tree（必须）：挂在 Thread Group 下

4.运行

① 点 View Results Tree 会看到 3 条记录：

复制代码 
POST Create User
GET Query User
Debug Sampler

② 点 Debug Sampler → Response Data 你应该能看到：

复制代码 
username=tom_001

✅ 说明：变量传递成功

③ 点 GET Query User → Response Data

你会看到类似：

复制代码 
{
  "args": {
    "username": "tom_001"
  }
}

④ 点 Assertion Results

  • ✅ 通过：接口关联成功
  • ❌ 失败：变量没传 / 写错路径

到这一步，你已经会了：

✅ POST 造数据

✅ JSON 提取

✅ 参数化

✅ 接口关联

✅ 上下游接口测试

✅ 企业里最常用的测试模型

进阶：随机造数据+导出测试报告

步骤：

1.把 username 改成随机数（真正「造数据」）

使用JMeter 内置函数 __Random

1️⃣ 改 POST 请求里的 Body Data

找到你现在的 POST Create User

👉 Body Data 里原来是：

复制代码 
{
  "name": "Tom",
  "username": "tom_001",
  "email": "tom@test.com"
}

✨ 改成这样（直接复制）

复制代码 
{
  "name": "Tom",
  "username": "tom_${__Random(1000,9999)}",
  "email": "tom_${__Random(1000,9999)}@test.com"
}

📌 解释（给小白的）：

  • ${__Random(1000,9999)}
    👉 每次运行都会生成一个 1000--9999 的随机数
  • 每次请求：
    • username 都不一样
    • email 也不一样
  • 这就叫：真正的接口造数据（Mock / 压测 / 冒烟测试）
2️⃣ 运行后验证「真的随机」

运行 ▶️ 后：

  • 打开 View Results Tree

  • 点 Debug Sampler

  • 看 Response Data 里有没有：

    username = tom_7202

再跑一次：

复制代码 
username = tom_8616

👉 如果每次不一样 = ✅ 成功

3️⃣ GET 请求用变量（上下游关联）

你的 GET 请求里，把 Path 或参数写成：

复制代码 
/users?username=${username}

或者（示例）：

复制代码 
/users/${username}

📌 ${username} 来自你前面的 JSON Extractor

2.把结果导出成「测试报告」（企业必备）

接下来这个非常重要 💼

👉 测试不是跑完就完，一定要"交报告"

一句话结论（先记住）

🚫 不要在 GUI 里生成正式报告

✅ 用 命令行 + HTML Report

步骤：

1.保存你的 .jmx 脚本
复制代码 
C:\Users\xx\pc\JMeter\work\test3.jmx
2.用命令行跑 JMeter（重点）
1️⃣ 打开 JMeter 的 bin 目录

在空白处： Shift + 右键 → 在此处打开 PowerShell / CMD

2️⃣ 执行这条命令（直接用）
复制代码 
jmeter -n ^
 -t C:\Users\xx\pc\JMeter\work\test3.jmx ^
 -l C:\Users\xx\pc\JMeter\work\result.jtl ^
 -e -o C:\Users\xx\pc\JMeter\work\report

📌 解释一下你在干嘛（很重要）：

参数 意义
-n 非 GUI 模式（正式跑）
-t 你的测试脚本
-l 原始结果数据（.jtl）
-e 生成 HTML 报告
-o 报告输出目录
3️⃣ 跑完后你会得到什么？

双击打开 目录：C:\Users\xx\pc\JMeter\work\report 里面有：index.html

会看到一个非常专业的网页报告：

  • TPS
  • 响应时间
  • 成功率
  • 错误率
  • 接口统计

📌 这就是：可以直接给测试主管 / 开发 / 项目经理看的报告

总结：目前已经完成了 👇

✅ POST 接口造随机数据

✅ JSON Extractor 提取变量

✅ GET 接口使用变量（接口关联）

✅ Response Assertion 校验结果

✅ Debug Sampler 验证变量

✅ 命令行生成 HTML 测试报告

👉 这是 真实企业接口测试的完整闭环

看测试报告

1.看报告的正确心态

是在回答这 5 个问题：

1️⃣ 接口 通不通？

2️⃣ 快不快？

3️⃣ 稳不稳？

4️⃣ 有没有失败？

5️⃣ 能不能 上线 / 提测 / 给开发？

只要你能回答这 5 个，你就会"看报告"了。

1.看Dashboard（首页）

先看这 3 个地方就够了：

① APDEX（体验指数）【先不用怕】

你会看到一个类似：

复制代码 
APDEX = 1.00

简单理解：

  • 1.00 = 非常爽
  • 0.85 以上 = 可以接受
  • < 0.7 = 用户要骂人了

📌 如果你是接口功能测试阶段：👉 只要不是 0，就先别纠结它

② Requests Summary（最重要！！）

这是你 最该盯的表 👀

你会看到类似：

Label #Samples Average Error %
POST Create User 3 120 ms 0.00%
GET Get User 3 80 ms 0.00%

解释：

🔹 Label = 你 JMeter 里的 HTTP Request 名字

👉 用来看 哪个接口

🔹 #Samples = 跑了多少次

你看到 3，很正常：

  • 线程数 = 1
  • 循环次数 = 3

就是 3 次

🔹 Average（平均响应时间）单位是：毫秒 ms

大概判断标准（功能测试阶段）👇

  • < 200ms ✅ 很快
  • 200--500ms 🙂 正常
  • 1000ms ⚠️ 慢了，要注意
🔹 Error %= 失败率（最重要）
  • 0.00% = 全部成功 ✅
  • > 0 = 必须查失败原因 ❌

👉 你现在如果是 0%，说明：

POST + GET + 断言
全都跑通了

③ Errors（如果有才看）

  • 如果你的 Error % 是 0：👉 这一栏你可以直接跳过

  • 如果有错误，它会告诉你：

    • 哪个接口错了

    • 错了多少次

JSON 提取器（关联参数）

比如：

  • POST 创建用户 → 返回 id
  • 再用这个 id 去 GET 查询

这一步叫：参数关联（面试必考）

状态码断言 + JSON 字段断言组合

比如同时校验：

  • 状态码 = 200
  • code = 0
  • message = "success"

CSV 造数据（批量造用户）

用 CSV Data Set Config：

  • 一次跑 100 个用户注册
  • 自动换 name / email

峰值场景设计

在性能测试中，系统可能遇到正常业务流量之外的高峰压力，比如：

  • 电商促销秒杀
  • APP 同时登录人数激增
  • 某接口同时被大量请求

峰值场景设计就是模拟这种"瞬间高并发/高压力"的情况，测试系统在峰值下是否还能正常响应，不崩溃或报错。

JMeter中如何设计峰值场景？
  1. 确定目标接口
    • 选出你要测试的接口（如登录、下单、支付接口）
  2. 设置虚拟用户数（Threads）
    • 正常流量 1000 人，峰值可能 5000 人同时访问
    • JMeter 设置 Thread Group（线程组）模拟这些用户
  3. 控制启动速率
    • 可以设置 Ramp-Up 时间（用户逐渐加速）
    • 峰值测试通常 Ramp-Up 很短，模拟瞬间涌入
  4. 循环次数 / 持续时间
    • 可以设置每个线程循环发送请求次数
    • 或持续测试一定时间（如 5-10 分钟）
  5. 添加断言 & 监听器
    • 验证响应是否正确（状态码、字段）
    • 监控响应时间、吞吐量、错误数
  6. 分析结果
    • 平均响应时间、最大响应时间
    • 错误率
    • 系统在峰值下是否能承受压力
示例-JSONPlaceholder-单个接口

官方测试站点：

复制代码 
https://jsonplaceholder.typicode.com

这是一个公开的 REST API 测试平台，专门给开发和测试练习用的。

URL：获取所有帖子

复制代码 
POST https://jsonplaceholder.typicode.com/posts
1.测试目标（真实场景设定）

假设这是我们公司的"发帖接口"。

业务背景：

  • 平时每秒 20~50 请求
  • 活动期间可能 800 人 3 秒内同时发帖
  • 需要验证接口在瞬时高峰下是否稳定
2.峰值测试目标
  1. 模拟 800 用户
  2. 3 秒内全部发起请求（瞬时冲击）
  3. 成功率 ≥ 99%
  4. 平均响应时间 ≤ 1000ms
3.JMeter 实操完整步骤
第一步：新建线程组

添加：

复制代码 
Test Plan
   → Thread Group

填写：

参数 值
Number of Threads 800
Ramp-Up Period 3
Loop Count 1

解释：

👉 3 秒内启动 800 用户

👉 这是典型"瞬时峰值冲击"

这就是峰值场景设计核心。

第二步：添加 HTTP Request

在线程组下添加：

复制代码 
HTTP Request

填写：

项目 内容
Protocol https
Server Name jsonplaceholder.typicode.com
Method POST
Path /posts
第三步：添加 Header Manager

添加：

复制代码 
HTTP Header Manager

添加一行：

复制代码 
Content-Type : application/json
第四步：添加请求体

选择：

复制代码 
Body Data

填写：

复制代码 
{
  "title": "peak_test",
  "body": "jmeter_peak_practice",
  "userId": 1
}
第五步：添加断言（必须）

添加：

复制代码 
Response Assertion

设置：

  • 第一个断言：Response Code = 201

  • 第二个断言：Response Body 包含 "id"

这样可以验证：不是光返回，而是真成功。

第一个断言：校验状态码 = 201

第二个断言：校验返回体包含 id

第六步：添加监听器

添加：

  • Summary Report （汇总报告），选中 Thread Group
  • Aggregate Report（聚合报告），选中 Thread Group

注意：不要用 View Results Tree 跑 800 并发，会卡

重要：Aggregate Report（聚合报告）字段说明：

字段名 中文解释 单位 代表什么意思 正常参考值
Label 接口名称 - 当前压测的是哪个接口 -
# Samples 请求总数 次 一共发送了多少次请求 越多数据越准
Average 平均响应时间 ms 所有请求的平均耗时 < 1000ms
Median 中位数 ms 一半请求比它快，一半比它慢 越低越好
90% Line 90%响应时间 ms 90%的请求在这个时间内完成 < 2000ms
95% Line 95%响应时间 ms 95%的请求在这个时间内完成 < 3000ms
99% Line 99%响应时间 ms 99%的请求在这个时间内完成 越低越好
Min 最快响应时间 ms 最快的一次请求耗时 越低越好
Maximum 最慢响应时间 ms 最慢的一次请求耗时 不应特别高
Error % 错误率 % 失败请求的比例 = 0%
Throughput 吞吐量 次/秒 每秒处理多少请求 越高越好
Received KB/sec 接收数据量 KB/秒 每秒从服务器接收多少数据 一般不重点看
Sent KB/sec 发送数据量 KB/秒 每秒发送多少数据 一般不重点看

🎯 新手重点记住这 4 个

最重要指标 看什么
Average 整体速度
90% Line 大部分用户体验
Error % 系统是否崩溃
Throughput 系统处理能力

为什么不能用 View Results Tree 跑 800 并发？

因为：View Results Tree 会：

👉 记录每一个请求的详细内容

👉 800 并发 × 数据量大

👉 电脑会卡顿甚至假死

它只适合：

✔ 调试阶段

✔ 小并发（比如 1~5 线程）
🎯 正确使用方式：

1.调试阶段（小并发）

设置：

  • Threads = 1
  • Ramp-Up = 1

可以加：

复制代码 
View Results Tree

看请求是否成功。

2.正式峰值测试阶段（800并发）

删除或禁用：

复制代码 
View Results Tree

只保留：

  • Summary Report
  • Aggregate Report

Summary Report （汇总报告）：

在 JMeter 中，**监听器（Listener）**用来收集和显示测试结果。Summary Report 是最常用的一种，尤其适合峰值/压力测试场景

监听器 用途 为什么峰值测试必加
View Results Tree 详细显示每个请求的请求/响应 并不适合大量并发请求，跑大并发会卡死
Summary Report 显示统计数据（总请求数、平均响应时间、吞吐量、错误率等） 可以快速看到整体性能，轻量不卡 UI，适合峰值测试
Graph Results / Aggregate Graph 可视化图表 可选，用于报告呈现

所以你做峰值场景的时候，Summary Report 能帮你快速判断系统承压能力和性能瓶颈。

Summary Report 主要指标解读

字段 含义 如何解读
Label 请求名 看哪个接口
# Samples 请求次数 看发了多少请求
Average 平均响应时间（ms） 越低越好
Min / Max 最快/最慢响应 Max 太高说明有瓶颈
Std. Dev 响应时间标准差 高说明性能不稳定
Error % 错误率 0% 理想，峰值测试要重点关注
Throughput 吞吐量（请求/秒） 系统承载能力指标
KB/sec 带宽消耗 可选，评估网络压力

💡 注意 ：峰值测试时，不建议用 View Results Tree，会把内存撑爆。只用 Summary Report 就够了。

第七步：开始测试

点击 ▶ 运行。

等待执行完成。

分析运行结果

步骤：

1.查看 Summary Report 结果：

  • 点击 Summary Report 标签

  • 按 Label 找到你关注的接口

  • 查看 Average、Max、Error %、Throughput 四个核心指标

  • 如果 Error % > 0 或 Max 响应时间远大于 Average，说明系统在峰值下有问题

2.查看 Aggregate Report 结果

  • 点击 Aggregate Report 标签

  • 按 Label 查接口

  • 看 Median / 90% Line 判断大部分用户体验

  • 和 Summary Report 对比，确认峰值压力下的稳定性

总结分析流程

  1. 确认线程组设置合理 → 添加 Summary Report / Aggregate Report
  2. 运行测试 → 等线程全部结束
  3. 打开监听器 → 查看主要指标（平均、最大、错误率、吞吐量）
  4. 分析系统瓶颈：
  • Max >> Average → 可能瞬时压力大
  • Error % > 0 → 系统有异常
  • Throughput 低 → 系统处理能力不足

1.先看 Aggregate Report（最重要）

你的核心数据是：

指标 数值 说明
#Samples 784 总共发出了 784 个请求
Average 30776 ms 平均响应时间 = 30.7 秒 ⚠ 这是非常慢的。正常接口：100ms ~ 500ms 是正常，1~2 秒已经偏慢，30 秒是严重超时级别
90% Line 42096 ms 90% 的请求都在 42 秒以内返回。说明：几乎所有请求都很慢
95% Line 42112 ms
99% Line 49583 ms
Max 106170 ms 最慢的请求 106 秒，这已经是严重阻塞了。
Error % 43.37% 错误率 43%，说明每 100 个请求，有 43 个是失败的。这在生产是灾难级别。正常标准： 优秀：0% 、可接受：< 1% 、超过 5% 就要排查
Throughput 7.3/sec 每秒只处理 7 个请求。800 并发（之前说的峰值场景），但系统每秒只扛住 7 个请求，说明服务器已经被打爆了。

结果说明：

指标 你的数据 说明
Average 30776ms 平均 30 秒，非常慢
90% Line 42096ms 大部分请求都很慢
Error % 43% 几乎一半请求失败
Throughput 7.3/sec 每秒只能处理 7 个请求

结论：服务器已经被压垮。

为什么会这样？

因为你用的是： httpbin.org 这种公共测试网站

问题：

  1. 它本身有限流
  2. 它不是为 800 并发准备的
  3. 海外网络延迟高
  4. 会主动拒绝请求

所以：

✔ 响应时间飙升

✔ 错误率暴涨

✔ 吞吐量极低

压测结论

公司报告，可以这样写：

在 800 并发条件下：

  • 平均响应时间：30.7 秒
  • 90% 请求响应时间：42 秒
  • 最大响应时间：106 秒
  • 错误率：43%
  • 吞吐量：7.3 TPS

系统在高并发下：

  • 响应时间严重升高
  • 错误率显著上升
  • 吞吐能力明显不足

初步判断系统在该并发级别已达到性能瓶颈。

补充：

现在这个情况是正常的，因为：是用公共网站做 800 并发压测，它必崩。这正是峰值测试的意义。

对比实验（非常重要）

修改：

Thread 数量：

复制代码 
Threads = 10
Ramp-up = 5

运行会看到：

  • 响应时间明显下降
  • 错误率接近 0
  • Throughput 上升

这样你就能对比出：

👉 系统在不同并发下的性能变化

这才是真正的性能测试思维。

示例-多个接口（JSONPlaceholder）
平台接口选取

我们挑选几个常用接口模拟压力测试：

接口名 方法 URL
获取所有帖子 GET https://jsonplaceholder.typicode.com/posts
获取单条帖子 GET https://jsonplaceholder.typicode.com/posts/1
创建新帖子 POST https://jsonplaceholder.typicode.com/posts
更新帖子 PUT https://jsonplaceholder.typicode.com/posts/1
删除帖子 DELETE https://jsonplaceholder.typicode.com/posts/1
1️⃣ 测试目标
  • 模拟多接口高并发访问，验证系统峰值处理能力。
  • 收集以下指标：
    • 响应时间（平均、最大）
    • 吞吐量
    • 错误率
2️⃣ 测试设计

并发设置（示例）：

  • 并发线程数：100、200、400、800
  • Ramp-up（预热时间）：30秒
  • 循环次数：10次（或持续 5 分钟）
  • 目标：同时对多个接口发请求，观察性能瓶颈。
3️⃣ 测试步骤（以 JMeter 为例）
第一步：创建线程组
  1. 打开 JMeter → 右键 → 添加 → 线程（用户） → 线程组
  2. 配置线程组：
    • 线程数（并发用户）：100
    • Ramp-Up 时间：30 秒
    • 循环次数：10
第二步：添加 HTTP 请求

对每个接口分别添加 HTTP 请求采样器：

  1. 获取所有帖子

    • 右键线程组 → 添加 → 取样器 → HTTP 请求
    • 配置：
      • 名称：Get All Posts
      • 方法：GET
      • URL：https://jsonplaceholder.typicode.com/posts

  2. 获取单条帖子

    • 名称：Get Post 1
    • 方法：GET
    • URL：https://jsonplaceholder.typicode.com/posts/1

  3. 创建新帖子

    • 名称：Create Post

    • 方法：POST

    • URL：https://jsonplaceholder.typicode.com/posts

    • Body Data（JSON）：

      json 复制代码 
      {
  "title": "测试标题",
  "body": "测试内容",
  "userId": 1
}

  4. 更新帖子

    • 名称：Update Post 1

    • 方法：PUT

    • URL：https://jsonplaceholder.typicode.com/posts/1

    • Body Data（JSON）：

      json 复制代码 
      {
  "id": 1,
  "title": "更新标题",
  "body": "更新内容",
  "userId": 1
}

  5. 删除帖子

    • 名称：Delete Post 1
    • 方法：DELETE
    • URL：https://jsonplaceholder.typicode.com/posts/1
第三步：添加Header Manager
接口 Header Manager 是否必须 配置示例
GET /posts 不需要 -
GET /posts/1 不需要 -
POST /posts 推荐 Content-Type: application/json
PUT /posts/1 推荐 Content-Type: application/json
DELETE /posts/1 可选 不强制，但可以加 Accept: application/json
第四步：添加断言

五个接口断言配置示例

接口 HTTP 方法 断言类型 断言字段 断言内容 / 说明
获取所有帖子 /posts GET 响应文本 (Response Text) Body 包含关键字：userId 说明：返回的 JSON 列表每条记录都有 userId
获取单条帖子 /posts/1 GET 响应文本 (Response Text) Body 包含关键字："id": 1 说明：确保返回的是 ID=1 的帖子
创建新帖子 /posts POST 响应文本 (Response Text) Body 包含关键字：id 或 title 说明：确保 POST 成功返回新帖信息
更新帖子 /posts/1 PUT 响应文本 (Response Text) Body 包含关键字："title":"更新标题" 说明：验证接口返回的数据已更新
删除帖子 /posts/1 DELETE 响应码 (Response Code) Response Code 期望值：200 说明：删除接口返回 200 即成功

1️⃣ 接口 1：获取所有帖子 /posts（GET）

  1. 选中 Get All Posts HTTP 请求采样器
  2. 右键 → 添加 → 断言 → 响应断言 (Response Assertion)
  3. 配置响应断言：
    • 响应字段 (Response Field to Test)：响应文本 (Response Text)
    • 模式匹配 (Pattern Matching Rules)：包含 (Contains)
    • 模式 (Patterns to Test) ：userId
  4. 保存

说明 ：确保返回的 JSON 列表中包含 userId 字段，接口返回有效数据。

2️⃣ 接口 2：获取单条帖子 /posts/1（GET）

  1. 选中 Get Post 1 HTTP 请求采样器
  2. 右键 → 添加 → 断言 → 响应断言 (Response Assertion)
  3. 配置：
    • 响应字段：响应文本 (Response Text)
    • 模式匹配：包含 (Contains)
    • 模式 ："id": 1
  4. 保存

说明：确保返回的是 ID=1 的帖子。

3️⃣ 接口 3：创建新帖子 /posts（POST）

  1. 选中 Create Post HTTP 请求采样器
  2. 右键 → 添加 → 断言 → 响应断言 (Response Assertion)
  3. 配置：
    • 响应字段：响应文本 (Response Text)
    • 模式匹配：包含 (Contains)
    • 模式 ：id 或 title
  4. 保存

说明 ：确保 POST 成功，返回新帖信息。
注意 ：Header Manager 必须有 Content-Type: application/json

4️⃣ 接口 4：更新帖子 /posts/1（PUT）

  1. 选中 Update Post 1 HTTP 请求采样器
  2. 右键 → 添加 → 断言 → 响应断言 (Response Assertion)
  3. 配置：
    • 响应字段：响应文本 (Response Text)
    • 模式匹配：包含 (Contains)
    • 模式 ："title":"更新标题"
  4. 保存

说明 ：确保 PUT 请求更新成功，返回的数据里标题已经被更新。

Header Manager 保持 Content-Type: application/json

5️⃣ 接口 5：删除帖子 /posts/1（DELETE）

  1. 选中 Delete Post 1 HTTP 请求采样器
  2. 右键 → 添加 → 断言 → 响应断言 (Response Assertion)
  3. 配置：
    • 响应字段：响应码 (Response Code)
    • 模式匹配：等于 (Equals)
    • 模式 ：200
  4. 保存

说明：只要 DELETE 返回 200 就认为删除成功

第五步：添加监听器
  • 聚合报告（Aggregate Report）：统计平均响应时间、最大响应时间、吞吐量、错误率--->在线程组下添加
  • 查看结果树（View Results Tree）：调试接口请求（峰值测试建议少用，否则很卡）

定时器

峰值场景设置测试不加定时器

峰值测试 = 瞬间冲击系统

目的就是：

  • 同一时间大量请求
  • 看系统能不能扛住
  • 找极限

如果你加定时器：每个请求之间等 500ms

那就变成：模拟正常用户行为

❌ 这就不是峰值测试了

✔ 这是压力测试 / 负载测试

🟢 三种测试的区别（你记住这个就不会乱了）

测试类型 要不要定时器
功能调试 可以加
负载测试（模拟用户） ✅ 要加
峰值测试（瞬间打爆） ❌ 不要加

定时器：

  • 在"线程组"下添加定时器（Timer） ，模拟真实用户间隔，例如：
    • 恒定定时器：500ms → 每隔 0.5 秒发送请求
  • 使用 随机定时器 可以模拟更真实的请求分布。

1.在"线程组"下添加定时器（Timer）

而不是每个接口单独加。

因为：

  • 定时器对"它下面所有请求"生效
  • 结构更清晰
  • 更符合真实用户行为

作用：每个请求之间固定间隔

步骤：在线程组右键 → 添加 → 定时器 → 恒定定时器（Constant Timer）

  1. 随机定时器(更真实)

真实用户不会刚好 500ms，所以我们用随机波动。

步骤：线程组右键 → 添加 → 定时器 → 高斯随机定时器（Gaussian Random Timer）

英文 中文意思 作用
Deviation 偏差值 上下波动范围
Constant Delay Offset 固定延迟 基础等待时间

🧠 高斯随机定时器的公式：实际等待时间 ≈固定延迟 ± 偏差

第六步：运行测试
  • 点击 开始按钮 ，观察：
    • 响应时间趋势
    • 吞吐量是否稳定
    • 是否出现请求失败或错误
第七步：分析结果
  • 对比各接口性能指标：
    • 哪个接口响应慢
    • 哪个接口失败率高
  • 生成图表：
    • 平均响应时间柱状图
    • 最大响应时间柱状图
    • 吞吐量曲线图
    • 错误率表 & 柱状图

1.看TOTAL

TOTAL：

Samples: 5000

Average: 784ms---->平均响应时间，整体还可以（<1秒）

90%Line: 1562ms

95%Line: 2234ms--->95%用户在 2.2秒以内，即有 5% 的请求超过 2.2 秒。对于生产系统来说：如果是普通业务，可以接受；如果是核心接口，偏慢

Error%: 0.2%--->错误率，5000 个请求里出错 10 个左右。可以接受，但要看是哪个接口出错

Throughput: 49.3/sec---->吞吐量，系统每秒处理 49 个请求。说明系统并发能力一般，不算特别强。

2.看 Average：哪个接口最慢？

接口 平均响应
Get All Posts ❌ 1410ms
其他接口 600ms 左右

👉 Get All Posts 明显拖慢整体性能

3.重点问题接口分析

🔴 Get All Posts

复制代码 
Average: 1410ms
90%Line: 3086ms
95%Line: 3944ms
Max: 14930ms

问题：

  • 95% 要 3.9 秒
  • 最大 14.9 秒
  • 接收数据 286 KB/sec（远大于其他接口）

👉 原因很明显：

这个接口返回的是：全部帖子数据

数据量大、响应体大，所以慢

🟡 Update Post 1

复制代码 
Error %: 1.0%

只有这个接口有错误。

👉 说明：

可能：

  • PUT 请求失败
  • 并发更新导致冲突
  • 或断言问题

建议你用 View Results Tree 单独跑 50 次检查。

补充检查：禁用其他接口检查

1.禁用其他接口：选择请求，右键 → Disable，禁用后会 变成灰色

2.添加查看结果树

右键 线程组→添加 → 监听器 → 查看结果树 (View Results Tree)

3.降低线程数（方便调试）

进入 线程组 设置：

复制代码 
线程数 (Number of Threads)：10
Ramp-Up：1
循环次数：5

这样会发送：检查 50 次

复制代码 
10 × 5 = 50 请求

4.运行

断言匹配模式不一致，没有完全匹配，空格或者换行不一致就失败

解决办法：

方法一：把断言改为 只匹配 title

  • Response Assertion → Pattern → 只写：

    更新标题

  • Match → Contains

  • Match rule → Match Any

这样只要响应里包含 "更新标题"，就通过。

✅ 简单稳定

✅ 不受 JSON 格式空格影响

方法二：用正则表达式（更专业）

  • 勾选 Use Regular Expression---->JMeter5.6.3版本默认，不需要单独勾选
  • Response Field → Response Text
  • Pattern Matching → Contains
  • Pattern → "title"\s*:\s*"更新标题"

解释：

  • \s* 匹配任意空格或换行
  • 能适应不同 JSON 格式

方法三（企业常用）：只断言 HTTP Status Code

  • Response Field → Response Code
  • Pattern → 200

原因：

  • 性能测试关注响应时间、吞吐量、错误率
  • 不关注 JSON 内容

4.系统瓶颈判断

你现在吞吐量：49 req/sec

如果线程是 300：说明系统已经在"接近瓶颈"。

如果你再提高到 500 线程：可能：

  • 响应时间飙升
  • 错误率上升

5.专业测试结论（你可以直接写报告）

📌 性能总结

  1. 系统整体平均响应时间 784ms，表现正常。
  2. 95% 请求在 2.2 秒以内。
  3. 吞吐量 49 req/sec，系统处理能力一般。
  4. 错误率 0.2%，处于可接受范围。
  5. Get All Posts 接口响应时间显著高于其他接口，疑似数据量过大导致性能下降。
  6. Update Post 1 接口存在 1% 错误率，需要排查。

6.面试：如果是面试官问你怎么说？

可以说：

在多接口峰值测试中，我通过 JMeter 聚合报告分析各接口响应时间、分位值及吞吐量，发现列表接口因返回数据量较大导致响应时间偏高，同时更新接口存在少量失败，需要进一步排查后端逻辑。

解决后重新运行：方法二

分析：

一、先看整体结果（TOTAL）

指标 数值 说明
Samples 14175 总请求数
Average 4875 ms 平均响应时间
90%Line 3853 ms 90%请求响应时间
95%Line 6339 ms 95%请求响应时间
Error % 0.138 % 错误率
Throughput 0.89 /sec 吞吐量

解释

总请求数

复制代码 
14175

说明：

复制代码 
100线程 × 10循环 × 5接口 ≈ 5000

你多跑了几次，所以累计到了 14175。

二、重点看每个接口表现

1️⃣ Get All Posts（最慢）

指标 值
Average 15711 ms
Max 2470447 ms
Error 0.006%

说明：

  • 获取所有帖子数据量最大
  • 返回 JSON 很大
  • 所以响应时间最长

👉 这是正常现象。

2️⃣ Get Post 1（单条查询）

指标 值
Average 2951 ms
Error 0.0007%

说明：

  • 单条数据
  • 响应时间明显更快

3️⃣ Create Post

指标 值
Average 2171 ms
Error 0.0003%

说明：

  • 写入接口
  • 性能还可以

4️⃣ Delete Post

指标 值
Average 1839 ms
Error 0.0007%

说明：

删除操作响应时间较短。

🚨 5️⃣ Update Post 1（问题接口）

指标 值
Average 1623 ms
Error % 0.683 %

这里要重点分析。

错误率

复制代码 
0.683 %

换算：

复制代码 
0.683 / 100 × 2830 ≈ 19 个请求失败

说明：

复制代码 
并发更新时出现失败

可能原因：

1️⃣ PUT 接口模拟更新同一条数据

2️⃣ 并发冲突

3️⃣ mock API 不稳定

三、吞吐量（Throughput）

TOTAL：

复制代码 
0.892 requests/sec

说明：

服务器处理能力很低，因为这是 公共测试 API。

真实系统一般是：

复制代码 
100 ~ 5000 req/sec

四、最大响应时间异常

你这里有一个非常异常的值：

复制代码 
Max = 2470447 ms

换算：

复制代码 
2470447 ms ≈ 41 分钟

说明：

有一次请求 超时或卡住。

常见原因：

  • 公共 API 限流
  • 网络波动
  • JMeter线程阻塞

五、结论（测试报告可以这样写）

示例总结：

复制代码 
本次测试模拟100并发用户访问5个接口，总请求数14175。

整体平均响应时间为4875ms，
90%请求在3853ms以内完成，
错误率为0.138%。

其中：

Get All Posts接口由于返回数据量较大，
平均响应时间达到15711ms，为性能瓶颈。

Update Post 1接口出现0.683%的错误率，
推测为并发更新同一资源导致冲突。

整体吞吐量为0.89 requests/sec，
由于测试平台为公共API服务，
服务器性能较低，结果仅作为压测流程练习参考。

现在已经会：

✔ JMeter脚本

✔ 多接口压测

✔ 聚合报告

✔ 错误分析

再补一个东西，你就 能写性能测试项目到简历里了：

👉 性能瓶颈分析图（Excel可视化）

一般做这 4 个图：

1️⃣ 平均响应时间柱状图

2️⃣ 最大响应时间柱状图

3️⃣ 吞吐量折线图

4️⃣ 错误率柱状图

你前面其实已经做过了。

第八步：测试报告分析模板

一、测试结果分析（根据 Aggregate Report）

本次性能测试通过 Apache JMeter 对系统接口进行并发压力测试，共测试 5 个接口：

  • Get All Posts
  • Get Post 1
  • Create Post
  • Delete Post 1
  • Update Post 1

线程组配置：

  • 并发线程数：100
  • Ramp-Up：30 秒
  • 循环次数：10

本次测试共发送请求 14175 次。

二、整体性能指标

指标 数值
总请求数 14175
平均响应时间 4875 ms
90%响应时间 3853 ms
95%响应时间 6339 ms
最大响应时间 23694 ms
错误率 13.81%
吞吐量 0.89 req/sec

分析：

系统在 100 并发压力下出现明显性能瓶颈：

  • 平均响应时间 接近 5 秒
  • 最大响应时间 23 秒
  • 错误率 13.81%（偏高）

一般生产系统要求：

  • 错误率 <1%
  • 平均响应 <2秒

因此当前系统 性能不达标。

三、各接口性能分析

1 Get All Posts

指标 数值
请求数 2851
平均响应 15711 ms
最大响应 87691 ms
错误率 0.63%

分析：

该接口响应时间 非常慢（15秒） ，最大响应 87秒，说明：

可能存在：

  • 查询数据量过大
  • SQL 未优化
  • 未分页

这是 主要性能瓶颈接口。

2 Get Post 1

指标 数值
平均响应 2951 ms
最大响应 17373 ms
错误率 0.07%

分析：

该接口性能 基本稳定 ，但平均响应接近 3秒，仍有优化空间。

3 Create Post

指标 数值
平均响应 2171 ms
最大响应 18797 ms
错误率 0.03%

分析：

写接口性能正常，但在高并发下 最大响应接近19秒，可能存在：

  • 数据库写锁
  • 事务等待

4 Delete Post 1

指标 数值
平均响应 1839 ms
最大响应 12667 ms
错误率 0.07%

分析：

删除接口整体稳定。

5 Update Post 1

指标 数值
平均响应 1623 ms
最大响应 9596 ms
错误率 68.37%

分析：

该接口 错误率非常高（68%），属于严重问题。

可能原因：

  • 数据更新冲突
  • 参数错误
  • 接口逻辑异常
  • 数据库锁竞争

需要重点排查。

四、系统瓶颈总结

本次测试发现以下性能问题：

1 接口响应慢

特别是：

  • Get All Posts

平均响应：

复制代码 
15.7 秒

明显过慢。

2 错误率过高

系统总体错误率：

复制代码 
13.81%

主要来自：

复制代码 
Update Post 1

错误率：

复制代码 
68.37%

属于严重故障。

3 吞吐量低

系统吞吐量：

复制代码 
0.89 req/sec

说明系统在高并发情况下处理能力较弱。

五、优化建议

建议从以下方面优化系统性能：

1 SQL优化

重点优化：

复制代码 
Get All Posts

建议：

  • 增加分页
  • 添加数据库索引
  • 减少全表扫描

2 接口优化

针对：

复制代码 
Update Post 1

排查：

  • 参数校验
  • 数据库事务
  • 并发更新冲突

3 数据库优化

建议：

  • 优化慢查询
  • 减少锁等待
  • 增加连接池

六、测试结论

在 100 并发压力测试下：

  • 系统响应时间偏高
  • 错误率较高
  • 吞吐能力不足

当前系统 性能不满足生产要求，建议进行性能优化后重新测试。

第九步：提优化建议

1.性能优化建议

根据本次性能测试结果，针对系统存在的响应时间较慢、错误率较高等问题，提出以下优化建议：

1 接口查询优化

针对接口 Get All Posts 平均响应时间较高的问题，建议：

  • 对数据库查询语句进行优化
  • 为高频查询字段添加索引
  • 避免全表扫描
  • 对查询结果增加 分页机制

优化后可以显著降低接口响应时间。

2 数据库性能优化

在高并发情况下，数据库可能成为系统瓶颈，建议：

  • 优化慢 SQL 查询
  • 合理使用数据库索引
  • 调整数据库连接池大小
  • 减少长事务

提高数据库处理能力。

3 接口并发处理能力优化

针对接口 Update Post 1 错误率较高的问题，建议：

  • 检查接口逻辑是否存在并发更新冲突
  • 优化接口事务处理逻辑
  • 增加异常处理机制
  • 避免频繁锁表或死锁情况

提高系统稳定性。

4 系统架构优化

在高并发场景下，建议：

  • 引入 缓存机制（如 Redis）
  • 对热点数据进行缓存
  • 减少数据库访问压力

提高系统整体性能。

5 压测场景优化

建议后续增加更多测试场景，例如：

  • 单接口压力测试
  • 混合业务场景测试
  • 峰值压力测试
  • 稳定性测试（长时间运行）

全面评估系统性能。

2.测试总结（最后一段）

本次通过 Apache JMeter 对系统接口进行了并发性能测试，在 100 并发用户场景下：

  • 系统平均响应时间较高
  • 个别接口出现较高错误率
  • 系统吞吐量较低

说明系统在高并发场景下仍存在一定性能瓶颈，需要进一步优化数据库查询、接口逻辑以及系统架构。

在完成相关优化后，建议重新进行性能测试，以验证系统性能提升效果。

统计数据可视化

可视化分析需要借助 JMeter 的其他监听器或导出数据后画图

方法一：用 JMeter 内置监听器可视化

可用监听器（轻量可用）

监听器 可视化效果 使用场景
Graph Results 折线图显示响应时间变化 压力/峰值测试，观察响应波动
Response Times Over Time 响应时间随时间变化曲线 峰值阶段性能波动分析
Aggregate Graph 与 Aggregate Report 类似，但用柱状/折线图显示 总览吞吐量、平均响应时间、错误率

步骤示例（Aggregate Graph）：

  1. 右键 Thread Group → Add → Listener → Aggregate Graph
  2. 运行峰值测试
  3. 打开 Aggregate Graph 标签
  4. 会显示每个接口：
    • 平均响应时间（柱状）
    • 吞吐量（折线）
    • 错误率（标记红色）
  5. 通过柱状/折线比较各接口性能，直观看出瓶颈

方法二： Excel / CSV 可视化

更稳定的导出方式（推荐峰值测试用）

峰值测试并发大时，其实不推荐用监听器导出。

更专业做法是：用 Simple Data Writer

步骤：

1️⃣ 右键 Thread Group

→ Add

→ Listener

→ Simple Data Writer

2️⃣ 选择保存路径：

复制代码 
result.csv

3️⃣ 运行测试

4️⃣ 测试结束后，直接用 Excel 打开这个 CSV

这个方法：

✔ 不占用大量内存

✔ 适合 800+ 并发

✔ 比 Aggregate Report 更专业

2.做可视化图表（最标准方式）

步骤：

1️⃣ 用 Simple Data Writer 导出 CSV

2️⃣ 用 Excel 做图：

  • 平均响应时间柱状图：行 → Label、值 → elapsed → 平均值（高峰值接口的柱子特别高 → 就是瓶颈）
  • 吞吐量折线图：行 → Label、timeStamp 最大值 - 最小值
  • 错误率对比图：新列写公式=COUNTIF(F列, FALSE)/COUNT(F列)，对每个接口计算
  • 最大响应时间：行 → Label、值 → elapsed → Max （观察峰值时响应最慢的接口）

这样才是真正的"可视化分析"。

步骤：

1️⃣ 平均响应时间柱状图

  1. 打开 CSV

  2. 做图

    1.选中你的全部数据（包含列名）

    • 在 Excel 里 Ctrl+A

    • 菜单栏 → 插入 → 数据透视表

    • 弹窗里，选择"新工作表" → 点击"确定"

    2.在右侧"数据透视表字段"：

    • 拖 label 到"行"
    • Excel 会自动把每个接口名列出来
    • 拖 elapsed 到"值"
    • 默认可能显示"求和" → 我们改成 平均值 ：点击值右侧下拉 → 值字段设置 → 平均值 → 确定

    3.插入柱状图

    1. 选中 label + 平均 elapsed 两列
    2. 菜单栏 → 插入 → 图表 → 柱状图 → 聚合柱状图

3.Excel 会生成柱状图：

  • X轴 → 接口名
  • Y轴 → 平均响应时间
  • 高柱子 → 响应慢的接口
  • 低柱子 → 响应快的接口

💡 高峰值接口的柱子特别高 → 就是瓶颈

2️⃣ 最大响应时间
  1. 用数据透视表：
    • 行 → Label
    • 值 → elapsed → Max
  2. 插入柱状图或折线图
  3. 观察峰值时响应最慢的接口
3️⃣ 吞吐量（Requests/秒）

计算公式：

复制代码 
吞吐量 = 总请求数 / 测试总耗时（秒）
1.吞吐量柱状图（最常用）

步骤：

  1. 总请求数 → Excel 统计每个 Label 出现次数
  2. 测试总耗时 → CSV 中 timeStamp 最大值 - 最小值，计算测试总秒数=(最大值-最小值)/1000，吞吐量=总请求数800/测试总秒数
  3. 绘制柱状图或折线图（更推荐） → 直观看接口吞吐量
2.吞吐量随时间变化曲线图（更高级，适合测试报告）

步骤：

1.在 A1右侧新插入列：秒级时间

在B2 输入：

复制代码 
=INT((A2-$A$2)/1000)

向下填充。

2.创建数据透视表

在字段列表里：

1️⃣ 把 秒级时间 → 拖到「行」区域

2️⃣ 把 label → 拖到「值」区域

默认会变成：

复制代码 
计数 of label

这就是：

👉 每秒的请求数

👉 也就是吞吐量（Requests/sec）

3.插入折线图

1️⃣ 选中透视表里的：

  • 秒级时间
  • 计数

2️⃣ 点击：

复制代码 
插入 → 折线图

生成的图就是：

📈 吞吐量随时间变化曲线

怎么看这张图？

理想情况：

  • 曲线平稳
  • 没有大幅波动
  • 没有突然掉到0

说明系统稳定

异常情况：

  • 曲线突然掉到0 → 系统挂了
  • 剧烈波动 → 性能不稳定
  • 越来越低 → 系统抗压能力差
4️⃣ 错误率

公式：

复制代码 
错误率 = COUNTIF(success, FALSE) / 总请求数

步骤：

  1. 在 Excel 新列写公式：

    复制代码 
    =COUNTIF(F列, FALSE)/COUNT(F列)

  2. 对每个接口计算

总请求数==COUNTIF(D(label列)😄(label列),H2(新建接口名列))

失败数==COUNTIFS(D(label列)😄(label列),H2(新建接口名列),I(总请求列):I(总请求列),"FALSE")

失败率==U2(失败数)/T2(总请求数)

  1. 插入柱状图 → 红色标注高错误率接口

可视化分析思路：

  • 响应时间柱状图：平均 vs 最大 → 高 Max 值表示瞬时压力大
  • 吞吐量折线图：观察系统承载能力随时间变化
  • 错误率红色标记：快速定位出错接口
汇总
1️⃣ 数据检查与标注
  • 检查异常值：确认是否有极端值（比如响应时间异常高），并在图上标注。
  • 条件格式 ：
    • 错误率 > 0 自动红色标记（你之前已经做过）。
    • 响应时间超过 SLA（比如 1 秒）可以用不同颜色标注。
  • 单位统一：时间统一为 ms，吞吐量统一为 req/s。
2️⃣ 图表优化与说明
  • 添加标题和说明 ：
    • 平均响应时间 → "各接口平均响应时间 (ms)"
    • 最大响应时间 → "各接口峰值响应时间 (ms)"
    • 吞吐量 → "系统吞吐量 (req/s)"
    • 错误率 → "各接口失败率 (%)"
  • X/Y 轴标签明确，必要时加网格线辅助阅读。
  • 图例清晰，特别是曲线图中多条线。
3️⃣ 分析总结
  • 找瓶颈 ：
    • 哪些接口平均响应时间高？峰值高？
    • 哪些接口吞吐量低？
    • 哪些接口错误率高？
  • 发现趋势 ：
    • 吞吐量随时间变化是否平稳？
    • 响应时间与吞吐量是否呈现冲突（高吞吐量时响应时间升高）？
  • 对比 SLA ：
    • 哪些指标达不到性能标准？
    • 哪些接口表现优秀？
4️⃣ 形成报告
  • 表格+图表结合 ：
    • 用错误率表 + 柱状图说明接口稳定性。
    • 平均/最大响应时间图表说明性能水平。
    • 吞吐量曲线图说明系统承载能力。
  • 文字总结 ：
    • 描述关键发现（如"接口 A 峰值响应时间达 3500ms，超过 SLA"）。
    • 给出改进建议（如"优化接口 B 查询逻辑"）。
  • 可选附录 ：
    • 测试环境说明（硬件、并发数、网络条件）。
    • 测试时间段

💡 建议顺序（在报告里）：

  1. 测试环境 & 测试目标
  2. 数据统计 & 图表
  3. 异常指标标注 & 解释
  4. 综合分析 & 改进建议
标准性能测试报告模板

系统接口性能测试报告

1️⃣ 测试概述

  • 测试目标：评估系统各接口在并发情况下的性能，包括响应时间、吞吐量及稳定性。
  • 测试环境 ：
    • 服务器：CPU x核 / 内存 xGB / 网络带宽 xMbps
    • 测试工具：JMeter / Excel
    • 并发线程数：800
    • 测试时间段：2026-03-01 10:00 -- 2026-03-01 12:00

2️⃣ 测试指标说明

指标 说明 单位
平均响应时间 各接口请求平均完成时间 ms
最大响应时间 单次请求最大耗时 ms
吞吐量 系统单位时间处理请求数量 req/s
错误率 接口请求失败占比 %

3️⃣ 数据统计 & 可视化

3.1 平均响应时间柱状图

  • 说明：展示各接口在测试期间的平均响应时间。
  • 图表：插入你的平均响应时间柱状图
  • 分析 ：
    • 接口 A 响应时间最高，为 1200ms，略高于 SLA（1000ms）。
    • 接口 B、C 响应时间稳定在 300--500ms，表现良好。

3.2 最大响应时间柱状图

  • 说明：展示各接口峰值响应时间，识别性能瓶颈。
  • 图表：插入你的最大响应时间柱状图
  • 分析 ：
    • 接口 D 单次峰值响应时间达 3500ms，需优化处理逻辑。
    • 大部分接口峰值响应时间 ≤ 2000ms，符合预期。

3.3 吞吐量柱状图 & 曲线图

  • 说明：展示系统承载能力及随时间变化的吞吐量趋势。
  • 图表：插入你的吞吐量柱状图和曲线图
  • 分析 ：
    • 系统整体吞吐量平均 750 req/s，高并发下仍保持稳定。
    • 接口 B、E 吞吐量略低，可能受数据库查询影响。

3.4 错误率表 & 柱状图

  • 说明：展示各接口请求失败率，标红突出问题。
  • 图表：插入你的错误率表 + 柱状图
  • 分析 ：
    • 接口 F 错误率最高为 0.8%，需关注稳定性。
    • 其他接口错误率 ≤ 0.25%，系统整体稳定。

4️⃣ 综合分析

  • 性能瓶颈 ：
    • 接口 D 最大响应时间过高 → 优化数据库查询或缓存策略。
    • 接口 F 错误率稍高 → 排查网络或服务异常。
  • 系统承载能力 ：
    • 总体吞吐量和响应时间表现良好，基本满足 SLA。
  • 趋势观察 ：
    • 高并发情况下，吞吐量稳定，响应时间小幅波动。
    • 错误率集中在少数接口，整体稳定性较高。

5️⃣ 改进建议

  1. 对接口 D 优化查询逻辑或增加缓存。
  2. 排查接口 F 错误原因，提升稳定性。
  3. 对响应时间略高接口进行压力调优测试。
  4. 后续测试增加不同并发等级，观察系统变化趋势。

6️⃣ 附录

  • 测试工具截图
  • 完整原始数据表
  • SLA 标准说明
  • 测试环境配置详细信息

💡 操作提示

  • 图表可直接复制 Excel 中已有的四类图表到报告中。
  • 对异常值或超 SLA 的指标，在图表上加红色标注或箭头，让报告一目了然。
  • 文字分析部分可根据实际数据微调。

常见错误排查

情况 1：全是红色 ❌

点一条红的，看：

  • 上面标签点 Response Headers / Response Data

如果看到：

  • 404 → Path 写错了
  • 400 → JSON 格式错了
  • 没返回内容 → 协议 https / 地址错

情况 2：报错 "Non HTTP response"

通常是：

  • Protocol 没填 https
  • Server Name 写成带 https 的完整地址了

⚠️ 正确写法是：

  • Protocol：https
  • Server：jsonplaceholder.typicode.com
  • Path：/users

情况3：报错403 Forbidden

返回头里有这些关键信息：

  • server: cloudflare
  • cf-mitigated: challenge

这说明：

👉 ReqRes 网站现在开启了 Cloudflare 防刷 / 防机器人机制

👉 它会拦截：

  • JMeter
  • Postman（有时也会）
  • 非浏览器请求

所以：

  • 浏览器访问没问题
  • 但 JMeter 发请求 → 被当成攻击流量 → 直接 403 拦掉 ❌

这是接口测试里非常真实的一种情况。

在公司里经常发生：

  • 接口在浏览器能访问
  • 但测试工具 403 / 401 / 302

原因常见是：

  • 防爬虫
  • 鉴权
  • Token / Cookie
  • Cloudflare / WAF

备注：内容源于网上和chatgpt

相关推荐
xiufeia1 天前
JMeter
java·jmeter·tomcat·高并发
文人sec2 天前
【Linux 服务器上搭建 JMeter 性能测试与监控环境（实战版）】
linux·运维·服务器·jmeter·性能测试
测试19982 天前
Jmeter接口测试：使用教程（上）
自动化测试·python·测试工具·jmeter·职场和发展·测试用例·接口测试
半个俗人5 天前
05postman关联-常用的数据提取方式
测试工具·jmeter·postman·js
爆更小哇9 天前
jmeter插件下载+创建梯度线程组+命令生成性能测试报告
测试工具·jmeter·自动化
抓到小松鼠10 天前
jmeter-事务控制器
jmeter
热门推荐
012026年3月AI领域大事件：DeepSeek引领开源风暴02GitHub 镜像站点03围棋-html版本04班级宠物园部署指南05小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）06【计算机一级WPSoffice】小黑课堂题库软件下载安装教程（2026年3月最新版）07Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南08UV安装并设置国内源09OpenClaw 使用和管理 MCP 完全指南10中国象棋-html版本