企业官网建设流程全解析

我先把口径说一下：写这篇时，我会直接按照一个做接口测试的“老手”边操作边记录的口吻来写，把 JMeter 发 POST 请求、设置 JSON 格式这件事的“为什么”和“怎么做”一并讲透。重点会落在 Content-Type 的设定逻辑、Body Data 和 Parameters 的区别、实际踩过的坑，以及一个可以照抄的完整流程上。

1. 为什么 JSON 格式的 POST 请求总要在 JMeter 里“特殊处理”

先说一个很常见的现象：很多人用 JMeter 发 POST 请求时，图省事直接在 Parameters 里把参数一行一行地填进去，结果接口返回 415 Unsupported Media Type，或者后端收不到参数，然后就开始怀疑脚本写错了。

其实问题大概率不在脚本，而在请求头。HTTP 协议里，Content-Type 这个字段就是告诉服务端“我这个请求体的数据是什么格式”。你填的表单键值对是application/x-www-form-urlencoded，你传的 JSON 文本是application/json，服务端拿到请求体之后，会先看这个头，再决定用哪种解析器去读你的 body。你要是嘴里说着 JSON，手上传的却是表单格式，后端按 JSON 解析自然解析不出来。

在 JMeter 里有两种常见的“传参”方式：一个是 Parameters 页签，它本质上是帮你按照表单格式去构造请求体；另一个是 Body Data 页签，它是把你写的原始数据原样塞进请求体里。那 JSON 这东西本身就是一个字符串文本，你想原样发给服务端，就得在 Body Data 里写，而不是 Parameters。这也是为什么“JMeter 发送 POST 请求并设置 JSON 格式”这个问题几乎每个做接口测试的人都会遇到，它不是一个偏门操作，而是最基础最日常的一个组合。

还有一点绕不开：JMeter 默认发出的 POST 请求，Content-Type 是跟着你的用法变的。你在 Parameters 里填参数，默认就是表单格式；你在 Body Data 里写 JSON，不手动指定头的话，有些服务端就默认按纯文本去接了，运气好碰上宽松的接口也能通，运气不好直接报错，所以整个操作里最关键的动作其实是“在请求头里明确声明 Content-Type 是 application/json”，这一步到位，后面就顺了。

我带的几个做测试的同事，之前每次写脚本到这一步都会犹豫一下：到底是把 JSON 放在 Body Data 里，还是放在参数里，还是要在 Header 里写 Content-Type。这篇文章就把这个链路完整地拆开，顺带把如何在 JMeter 里从零搭一个可复用的 POST JSON 请求的流程走一遍，适合刚接触 JMeter 接口测试的人做参考，也适合写过一阵子但总碰上奇怪报错的人拿来对照排查。

2. 实操前需要理解的三件套：请求体格式、Header 与 JMeter 元件层级

动手前先把 JMeter 里几个和“POST JSON”直接相关的概念捋一遍。理解这三件事，后面碰到任何报错都能自己定位，不然只会照着截图点，换个版本换个接口又懵了。

2.1 请求体格式决定了后端怎么理解你的数据

我习惯把这个道理类比成“寄快递填单子”：你寄一个易碎品，快递公司怎么知道要轻拿轻放？因为你勾选了“易碎品”那个选项。后端接口就像一个快递分拣中心，它拿到包裹（请求）之后，先看面单（Header 里的 Content-Type），面单上写着“这是 JSON”，它就用 JSON 解析器去拆包裹；面单上写着“这是表单”，它就用表单解析器去拆。

常见的 POST 请求体格式就这么几种：

• application/json：JSON 文本，结构化的嵌套数据最合适，接口联调时最常用。
• application/x-www-form-urlencoded：表单格式，键值对，用 & 连接，浏览器原生表单默认就是这个。
• multipart/form-data：也是表单的一种，但支持文件上传和二进制内容。
• text/plain：纯文本，基本不用于接口数据传递。

所以，当你准备发的是一段 JSON 字符串时，必须在 Header 里让后端知道：“我这个请求体是 JSON 格式”。否则后端拿到一段看起来像 JSON 但没被正确声明的字符串，可能直接当成普通文本去处理，轻则参数解析不出来，重则接口直接拒绝。

这里额外说一个很多人忽略的点：JSON 字符串内部的字段格式也要严格合法。用 Body Data 传 JSON 时，JMeter 不会帮你校验语法，你把{"name": "张三", "age": 25}写错一个逗号、少写一个引号，后端解析一样会报错，这不是 JMeter 的问题，而是 JSON 本身对格式要求苛刻。后面我会专门讲怎么在写 Body Data 时避免这种低级错误。

2.2 Header 在 JMeter 里的两种添加方式，用错就全乱了

要让请求带上Content-Type: application/json，JMeter 里最直接的做法是添加一个 HTTP Header Manager。这个元件有两个层级可以放。

• 第一种：放在HTTP 请求采样器下面。这样只对这一个请求生效。适合单个接口单独造数据的情况。
• 第二种：放在线程组下面。这样整个线程组里所有 HTTP 请求都继承这个 Header。适合同一批接口都需要 JSON 格式的情况。

这两种方式不是互斥的。实际应用中我的习惯是：如果整个测试计划就是围绕某个 JSON 接口做的，那我把Content-Type: application/json放在线程组级别统一加一次，下面所有请求都不用重复配置，脚本干净得多。如果线程组里有多个接口，有的要 JSON，有的要表单，那就把公共的头放线程组，把差异化的头放到各自请求下面，子级的 Header Manager 会覆盖掉同名的父级 Header，这个覆盖逻辑是关键。

还有一种更隐蔽的做法：直接在 HTTP 请求的 Advanced 页签里靠参数拼接去伪造 Content-Type，但这种方式一般不稳定又不直观，不建议用。正规做法就是 Header Manager。

另外一个容易出错的地方：你在 Body Data 里写了 JSON，同时又在 Parameters 里填了参数。这种情况 JMeter 不会报错，但实际发出的请求体可能把两部分的参数都拼进去，后端解析时获取参数的优先级不可控，结果就是接口行为变得很诡异。所以发 JSON 的时候，Parameters 页签里最好留空，别混着写，这是我在实际工作中反复强调的一条规则。

2.3 可视化理解 JMeter 的测试计划结构，知道元件放哪层是第一步

你安装完 JMeter、打开界面之后，左侧默认的树状结构是这样的：

• 测试计划
  • 线程组
    • HTTP 请求采样器
      • HTTP Header Manager
      • HTTP 信息头管理器（注意版本不同可能名字表述有差异）
    • 监听器（查看结果树、聚合报告等）

如果你对 JMeter 完全不熟，先闭眼记住一个原则：线程组是“一个用户”的抽象，里面的 HTTP 采样器是“这个用户做的每一个操作”，Header Manager 是“这个用户发出请求时带的头盔”。你配置脚本的过程，本质上就是在回答三个问题——谁能发起请求（线程组）、请求长什么样（HTTP 请求采样器）、请求需要带什么附加信息（Header Manager）。

有了这个粒度认识，后面在界面上操作的时候就不会觉得元件多了繁琐，因为你心里有树形结构，知道每个元件负责什么。我写这节就是想让大家形成一个全局观，别一上来就埋头填写表格，填完发现请求发不出来，回头找不到具体问题在哪。

3. 从零开始的完整流程：JMeter 发送 POST JSON 请求的规范步骤

接下来就是大家最关心的实操环节。我会带着你从创建测试计划一路走到查看响应结果，每一步都说明“我为什么这么做”。以下操作基于 JMeter 5.x 版本，但老版本 3.x、4.x 的界面布局大同小异，参照做基本不会出错。

3.1 第一步：搭建最基本的测试计划骨架

打开 JMeter，默认会有一个测试计划。右键点击它，选择“添加”，然后选“线程组”。如果不打算刻意做并发压力测试，线程组里的“线程数”就填 1，“循环次数”填 1，这样就是一个单用户单次的接口调试环境。

线程组里设置项有几个需要注意的：

• 线程数：模拟多少个用户同时发请求。调试接口时填 1 就好，别一上来填 100，不然服务端压力大不说，排查问题也麻烦。
• Ramp-Up 时间：10 秒内启动 10 个线程，表示每个间隔 1 秒。调试接口时不用关注这个。
• 循环次数：1 表示一个线程只跑一次。

这里有个小技巧：想要永久循环跑压力测试，可以把循环次数勾上“永远”，但调试阶段千万别勾，否则发出去的请求会一波接一波停不下来，查看结果树时整个页面都是刷新的数据，根本没法看。

线程组搭好之后，右键线程组，添加一个“Sampler”里的“HTTP 请求”。这个采样器就是核心了。

名称建议改成接口的名字，比如“查询用户信息-正常流程”，不要叫默认的“HTTP Request”。因为在结果树里一眼区分不同请求、定位问题的时候，一个可读性好的名称能省很大精力。尤其脚本里有多个请求时，默认名字会让你完全分不清哪个是哪个。

3.2 第二步：在 HTTP 请求采样器里正确填写请求信息

选中 HTTP 请求采样器，右侧会露出配置面板。我按从上到下的顺序，把每个关键字段怎么填都说一遍。

• 协议：根据接口情况填http或https。注意：https 接口如果证书有问题，JMeter 默认会报 SSL 相关错误，处理方法留在后面讲。
• 服务器名称或 IP：就是域名或 IP。比如api.example.com，不要带 http，不要带路径。
• 端口号：默认 80（http）或者 443（https），如果接口用了自定义端口比如 8080，一定要填，不然请求会默认走到 80。
• 方法：下拉框选择POST。这里一定别顺手用默认的 GET，接口如果是 POST 请求，你用 GET 打过去，大概率会得到 405 Method Not Allowed。
• 路径：接口的具体路径，比如/api/v1/user/login。注意路径必须以/开头，这个跟浏览器里访问地址是一样的，少了斜杠部分服务器会混淆。

填完这些，页面下方有两个大块区域，一个是“参数”，一个是“Body Data”。这两个区域的关系我已经在前面讲了，发 JSON 时，你需要在“Body Data”里输入完整的 JSON 字符串。

比如现在要模拟一个查询用户信息的接口请求，JSON 请求体是这样的：

{ "userId": "10086", "userName": "测试员", "page": 1, "pageSize": 20 }

那我在 Body Data 区域里就原样粘贴这段内容，不需要额外做什么序列化处理。因为 Body Data 的本质就是“原始请求体数据”，你写什么，发送的请求体里就是什么。

但这里有一个高频易错点：如果你在 JSON 里写了中文“测试员”，需要保证 JMeter 的编码设置是正确的，否则后端接收到中文后可能是乱码。默认情况下，JMeter 发送请求时使用 ISO-8859-1 编码，这个编码不支持中文，所以必须在请求里指定 UTF-8 编码格式。怎么指定？往下看，Header 那一步就有答案。

3.3 第三步：用 HTTP Header Manager 声明 JSON 格式与 UTF-8

右键刚才创建的 HTTP 请求采样器，选择“添加” -> “配置元件” -> “HTTP 信息头管理器”（不同版本翻译略有不同，本质是 HTTP Header Manager）。

添加成功后，在右侧参数列表里添加两行：

• 第一行：Name 填Content-Type，Value 填application/json; charset=utf-8。
• 第二行：Name 填Accept，Value 填application/json。这一行不是必须的，但对某些有严格接口规范的团队来说，加了它后端能进一步确认客户端期望返回 JSON 数据，碰上一些网关或框架还会检查这个字段，所以顺手加上更稳。

做完这一步，其实就可以发起请求了。但为了更准确地看懂“我到底发了什么、服务端到底回了什么”，还需要加监听器。

这里插一句为什么要加 charset=utf-8：HTTP Header 里，charset 用来声明请求体文本内容的字符编码。如果后端框架按照 UTF-8 解析请求体，你这边发送的字节流却按 ISO-8859-1 编码，中文就会变成乱码字符。这是我自己踩过的一个很基础的坑，排查半天发现就是编码没指定，加上charset=utf-8后问题直接消失。

3.4 第四步：添加“查看结果树”监听器，观察请求与响应

右键线程组，选择“添加” -> “监听器” -> “查看结果树”。

结果树是接口调试阶段最好用的监听器，没有之一。它会把你发出的请求头、请求体、响应头、响应体全部展示出来，就像在浏览器开发者工具里看网络请求一样。双击结果树打开，上方是请求列表，下方左侧区域可以切换查看请求头和请求体。

执行脚本的方式有两种：

• 点击上方绿色三角“启动”按钮，跑完整线程组。
• 如果是单请求调试，你可以只选中采样器，然后点击绿色三角，它会只执行选中的那个采样器。

跑完之后，在结果树里点击请求，右侧会自动显示绿/红灯状态。绿色表示响应状态码是 2xx 或 3xx，红色表示 4xx 或 5xx。这不是接口业务上的成功与否，只是请求通没通。判断接口业务是否正常，还要看响应体里的业务字段，比如"code": "0000"这种。

看到响应结果之后，建议把这三个位置都点开看看：

1. 请求体：确认是不是你写的 JSON 字符串，有没有被 JMeter 自动做过编码转换。
2. HTTP 请求头：确认Content-Type是否已正确设置为application/json; charset=utf-8。
3. 响应体：确认后端返回的数据是否符合预期。

很多同学发完请求说“我明明设置了 JSON，后端怎么还说不是 JSON”，很可能就是在请求头那一栏没有看到Content-Type，或者看到了但值是text/plain。这一步不要跳过，每次发请求前，先养成习惯看一眼“请求体预览”。

3.5 第五步：用断言让请求结果自动校验，而不是人肉看响应

接口调试通了之后，如果你想把这个请求固化成回归用例，不能每次看响应体人肉判断，要用断言自动化校验。JMeter 里最常用的是“响应断言”。

右键 HTTP 请求采样器 -> 添加 -> 断言 -> 响应断言。

配置方式可以选择“测试字段”为“文本响应”，然后在“模式匹配规则”里选择“包含”，在“测试模式”里填上期望出现的业务成功字段，比如"code": "0000"或者"success": true。这样只要响应体里包含这个字符串，断言就通过，请求标记为绿色；不包含则判定失败。

如果你需要进一步提取响应体里的某个值供后续请求使用，就得用 JSON 提取器或者正则表达式提取器。这个属于进阶玩法，这里先点到为止，重点是先把 POST JSON 这个环节跑通。

4. 设置 JSON 格式时最容易踩的坑，逐个对照排查

实际操作过程中，几乎每个人都会碰到下面几个问题。我把最典型的情况和对应排查思路整理一下，把自己踩过的坑列出来供大家对照。

4.1 接口报 415 Unsupported Media Type，这是最典型的问题

现象：请求能发出去，但服务端直接返回 415。

原因：服务的接口声明了只接受application/json，但你发的请求 Content-Type 还是默认的application/x-www-form-urlencoded，或者你干脆没设 Content-Type，服务端不认。

排查顺序：

1. 打开查看结果树，切到请求头 tab，看里面有没有 Content-Type。
2. 如果有，看值是application/json还是别的。
3. 如果是别的，检查 Header Manager 是否添加成功、是否拼错了大小写。

解决办法：在 Header Manager 里逐字确认 Content-Type 的值是application/json; charset=utf-8。还有一点必须提醒：如果你是在测试计划级别添加的 Header Manager，然后又在线程组或请求级别添加了另一个 Header Manager，注意后者的配置可能覆盖前者。我见过一个案例，两个 Header Manager 都存在时子级覆盖了父级的 Content-Type，接口就从 JSON 变成text/plain了，这属于元件的层级优先级问题，排查时要想得到。

4.2 中文乱码问题，接口收到一堆问号

现象：请求体是 JSON，里面含中文，服务端接收到的数据变成???或者乱码。

原因：请求体在发送时使用了非 UTF-8 编码。JMeter 早期版本中，默认编码是 ISO-8859-1，它是单字节编码，中文字符会被丢弃或转换错误。

解决办法：在 Header Manager 里设置Content-Type: application/json; charset=utf-8。如果你已经这样设置了还乱码，再检查两个地方：一是 JMeter 安装目录下bin/jmeter.properties文件里是否有sampler.encoding这种配置项，把它改成 UTF-8；二是你写 Body Data 时编辑器右下角是否显示了正确的编码格式。另外，请求响应乱码时，查看结果树里可以勾选“编码”为 UTF-8 来显示，但那只影响显示，不影响请求发送。

4.3 请求体 JSON 没被正确发送，后端拿到的是空对象

现象：Body Data 里明明写了完整的 JSON，结果服务端说请求体为空，或者把 JSON 当成了普通字符串，取不到字段。

原因：最常见的是在 Parameters 和 Body Data 两个页签里同时写了内容。当 Parameters 里有值时，JMeter 会以表单格式构造请求体，而 Body Data 里的内容就算写了他也不一定按你想象的顺序拼进去，服务端解析就错乱了。

解决办法：发 JSON 的请求，Parameters 留空。或者说，确定请求格式是 JSON 之后，就只专注于 Body Data 这一个区域。

另外还有一个隐藏点：如果 Body Data 里写了一个超大 JSON 字符串，或者包含特殊符号，JMeter 有时会把它解析出问题。我遇到过一次，JSON 里带了一个#字符，结果脚本执行时 JMeter 把它当作注释处理掉了一部分内容。遇到这种包含特殊字符的 JSON，建议将整个 JSON 字符串先保存到一个外部文件里，然后用__FileToString函数读取内容传入 Body Data。这是处理复杂超长 JSON 的一条可靠经验，比直接内联粘贴稳得多。

4.4 HTTPS 接口 SSL 证书报错，请求压根出不去

现象：点击启动，结果树里请求直接红色报错，提示 SSL 证书问题。

原因：接口是 https，JMeter 默认会校验服务端 SSL 证书，自签名证书或者某些内部环境证书不被信任，就会报错。

解决办法：在 JMeter 的系统属性里临时关闭 SSL 校验。具体做法是添加一个 HTTP 请求采样器的子级元素，或者在 JMeter 安装目录的bin/system.properties文件里配置jmeter.temp.properties。更简单的方式是使用一个叫 “HTTPS 请求默认值”的元件，在高级设置里把“使用本机 IP”等选项调整。最直接的方法：右键线程组，添加一个“非测试元件”里的“HTTP 请求默认值”，在高级里勾选“在 HTTP 请求中强制使用 SSL 版本”或者干脆把“JVM 系统属性”里的https.protocols调整一下。

不过说实话，这些方法有点绕。我平常用得最多的办法是另一个思路——在 JMeter 的 bin 目录下打开命令行，执行一个修改过的 jmeter 启动脚本，把-Djsse.enableSNIExtension=false这类参数传进去，规避部分 SSL 握手问题。但如果你只是做接口调试，更省事的方式是用http环境地址测通流程，必要时再处理证书。这个取舍取决于你的环境，不强求一步到位。

4.5 请求头类型匹配但接口仍无法解析请求体，检查 JSON 语法

现象：Content-Type 设置正确、Header 也没问题，但服务端报JSON parse error。

原因：Body Data 里的 JSON 字符串不合法，比如多了一个逗号、少了一个引号、字段名没有用双引号包住。

排查办法：把 Body Data 里的内容原样复制到一个在线的 JSON 校验工具或本地的 JSON 格式化工具里跑一遍，确定语法合法后再粘贴。很少有人意识到，Body Data 区域在 JMeter 里是一个普通文本编辑器，它不会对你的输入做任何智能校验。你写{userId: 1}这种在 JavaScript 里能跑通的字面量，在严格 JSON 语法里就是不合法的，必须是{"userId": 1}。

我在实践中也总结了一个习惯：不要在 Body Data 里手敲 JSON，先在别处写好校验过，再复制粘贴进 JMeter。这样能避免大量“看不出哪里错”的语法问题。

5. 进阶延伸：参数化、提取返回值与多接口串联，让脚本真正能落地复用

只发一个写死的 POST JSON 在多数实际项目里不够用，因为需要测试的数据往往不止一组。所以这节讲三个提升脚本复用性的思路，每一个都是在 POST JSON 基础上自然延伸的。

5.1 用 CSV 数据文件实现多组测试数据的批量化

如果你想用同一份 JSON 结构测试 10 组不同数据，没必要复制 10 个 HTTP 请求。在 JMeter 里用 CSV 数据文件配置元件，可以实现从外部文件读取每组测试数据。

具体做法是：新建一个 txt 或 csv 文件，每行存一组数据。比如：

user001,张三,25 user002,李四,30

然后在 JMeter 里添加“CSV 数据文件设置”，配置文件名路径、变量名称列表。假设变量名是userId,userName,userAge，那在 Body Data 里写 JSON 就可以写成这样：

{ "userId": "${userId}", "userName": "${userName}", "age": ${userAge} }

注意，这里的变量引用方式是${变量名}，JMeter 会在请求发送前做变量替换。我建议把所有变量都用双引号包起来，因为 JSON 字符串值必须要引号。不过像 age 这种数字类型，不带引号也是合法的，我在上面就是不加引号，这样服务端拿到的 age 就是数字类型。

这种做法的好处在于，你只需要维护一个外部测试数据文件，就能驱动一条测试用例跑出很多组数据。数据准备阶段和后端接口的耦合度也降低了。

5.2 用 JSON 提取器把上一个接口的返回参数带到下一个请求

接口联调时，很多流程是依赖前面的接口返回值的。比如登录接口响应里带了 token，查询接口的请求头或请求体里需要带 token。

右键一个 HTTP 请求采样器，添加“后置处理器”里的“JSON 提取器”。我知道有些版本叫“JSON JMESPath 提取器”，用法略有差异，但思路一样。配置参考：

• 变量名称：token
• JSON 路径表达式：$.data.token
• 默认值：NOT_FOUND

配置完成后，同一个线程组里的后续请求就可以在 Body Data 里写"token": "${token}"，JMeter 会自动替换。这套逻辑是所有 JMeter 接口联调脚本的核心。

5.3 断言 + 聚合报告，评估接口性能的基础配置

做压力测试时，查看结果树反而不适合跑多线程，因为每个线程的每个请求都会写进结果树，内存消耗很大。压测场景下应该用“聚合报告”或者“Summary Report”这种统计类监听器来查看 TPS、平均响应时间、错误率这些指标。

聚合报告里的关键指标包括：

• 样本数：总共发出多少请求。
• 平均响应时间：所有请求耗时的平均值。
• 吞吐量：每秒能处理多少请求（TPS），这是压测最核心的指标。
• 错误率：失败请求占比。

如果不会看这些指标，压测结果就没有意义。我个人习惯是先在低并发下跑通脚本，确认错误率 0%，再逐步加大线程数和循环次数，观察吞吐量变化和错误率走向。直接一把梭设置 1000 个线程测试，往往会让服务器直接卡死，反而测不出真实性能水平，这是经验之谈。

6. 综合案例：模拟一个带参数、断言和返回提取的用户登录查询流程

为了让前面所有内容串起来，我做一个“登录后查询用户列表”的示例。这个例子综合了 POST JSON 请求、Header 设置、JSON 提取器、关联断言，做完这一套之后，你应该可以举一反三迁移到自己的接口场景。

6.1 场景描述与用到的元件清单

假设被测系统有两个接口：

1. 登录接口：POSThttps://api.example.com/auth/login，请求体格式：

{ "username": "admin", "password": "123456" }

响应体返回格式：

{ "code": "0000", "message": "success", "data": { "token": "A1B2C3D4E5F6" } }

2. 用户列表接口：POSThttps://api.example.com/user/list，请求头需要携带登录接口返回的 token，请求体格式：

{ "page": 1, "pageSize": 20 }

目标：用 JMeter 完整跑通登录，拿到 token，带上 token 查询用户列表，并断言用户列表接口返回成功。

6.2 各步骤的配置明细

第一步：建测试计划，添加线程组，线程数 1，循环次数 1。

第二步：在线程组下面添加“HTTP 请求默认值”（如果打算复用协议头）。也可以在测试计划层级添加 HTTP 信息头管理器，放公共 Header。我给个更清晰的方案：在线程组下添加 HTTP Header Manager，设置 Content-Type 和 Accept，值分别是application/json; charset=utf-8和application/json。这样登录和查询两个请求都会带上。

第三步：添加第一个 HTTP 请求，命名为“登录接口”。协议选 https，服务器名称填 api.example.com，方法选 POST，路径填/auth/login。Body Data 中写完整 JSON。右键这个请求，添加“后置处理器” -> “JSON 提取器”。变量名填 token，JSON 表达式填$.data.token，默认值填 NOT_FOUND。跑完登录后，token 变量会被替换成实际返回值。

第四步：添加第二个 HTTP 请求，命名为“查询用户列表”。协议、服务器名称同上，方法选 POST，路径填/user/list。Body Data 里写：

{ "page": 1, "pageSize": 20, "token": "${token}" }

很多人问到“token 到底放在请求体还是请求头”，这取决于接口定义。在本例中假设接口要求放在请求体里，那就直接写。若接口要求放在请求头里，则在第二个请求下再添加一个 Header Manager，增加一行token: ${token}。

第五步：右键第二个请求，添加“断言” -> “响应断言”。测试字段选“文本响应”，模式匹配规则选“包含”，测试模式填"code": "0000"。运行后结果树里可以直观看到：登录请求绿色，查询请求绿色，响应体含期望字段。

整个流程跑通后，这个脚本就是一个非常典型的“接口链路自动化”样例。你还可以进一步将 thread count 调大，将脚本变成一个小压测脚本，观察接口在并发情况下的吞吐量和错误率。

6.3 执行结果分析与一些脚本维护技巧

执行结束后，不要只看绿色就结束。我每次都会把登录接口的响应体打开，复制 token 值，再去第二个请求的请求体里看替换后的值，确认关联拿到的数据确实是我期望的那一份。

如果发现第二个请求返回 401 Unauthorized，十有八九是 token 没有成功替换或者 token 过期。这时需要回过去排查 JSON 提取器的 JSON 路径有没有写对，以及登录响应体里 token 字段的层级路径是不是data.token。排查这种关联问题时，查看结果树的请求体和响应体就是你最好的调试工具，比问谁都管用。

脚本维护上还有一个习惯：凡是包含敏感信息的内容，比如密码，尽量用变量参数化或配置文件引用，不要直接硬编码在 Body Data 里。因为 JMeter 脚本本质是 XML 文件，多人协作时你的密码会对其他人可见，这属于安全习惯问题。

7. 写在最后：发 JSON POST 请求这件事，核心就是“格式声明精确”

从最早自己在 JMeter 里懵懵懂懂发第一个 POST JSON 请求，到现在熟练处理各种接口联调脚本，我最深的体会就是：这类工具操作本质上不复杂，复杂的是你不知道自己发送了什么、不知道服务端按什么格式来解析。JMeter 的掌握过程，其实就是在不断回答“我这次请求体到底是什么格式的”这个问题。

有耐心的测试人员，可以在动手前先想清楚：我要发给谁、以什么格式发、服务端期望我以什么格式发。想明白这三个问题，操作上的每一步都是顺理成章的。反过来，如果上来就盲目填参数、配 Header，出了问题就随手改，那就算这次成功了，下次碰到相似但不一样的情况，照样卡住。

我给新手和记性不好的同事最常重复的一条建议，就是在发请求前打开查看结果树的“请求体”和“请求头”两个 tab 看一眼。这比任何教程都有效。JMeter 里所有的问题，本质上都是“发的和收的对不上”这个问题，而这两个 tab 会把“你实际发了什么”原原本本摆在你面前。大部分报错，你只要愿意打开看，就已经解决一半了。

最后分享一个我自己用下来的小技巧：做 JSON 格式 POST 请求时，把常用的 Header 配置和 Body Data 格式保存成模板，放在 JMeter 的 templates 目录或者一个专门的“模板.jmx”文件里。每次新项目建测试计划，直接打开模板另存为新文件，这样能省掉每次重新配置 Header 和断言的时间，而且模板里的脚本都是之前验证过能跑的，不容易再犯低级的格式错误。这个习惯帮我省了不少时间，照着这样做，接口测试脚本的搭建效率会提高很多。