Postman Tests 怎样校验 JSON 响应字段

Postman 里校验 JSON 响应字段，核心不是把断言写在请求 URL 旁边，而是在请求的 Scripts → Post-response 中先解析 pm.response.json()，再用 pm.test 和 pm.expect 检查字段值、类型和结构。这样运行请求后，测试结果会单独列出每条检查，字段缺失、值不符和响应根本无法解析也能分开判断。

官方地址：https://learning.postman.com/docs/tests-and-scripts/write-scripts/test-examples/

最小可靠写法是“先解析、再分组断言、最后看 Test Results”。不要把 JSON 文本包含判断当成字段断言，它只能说明整段文本里出现过某个字符串。

先找到响应断言的正确入口

打开一个请求后，进入 Scripts → Post-response。这里的脚本在收到响应后执行，能够访问 pm.response，也能通过 pm.test 创建可单独查看的测试项。不要把验证代码写到请求前脚本里：请求前脚本适合准备变量，响应字段断言必须等服务器返回内容后才有意义。

可以把一个响应检查拆成三层：

解析 JSON 后校验状态码、字段值和类型

下面是一份可以直接改字段名的最小模板。注释只保留关键边界：先判断状态码，再解析响应，最后把字段值和字段类型拆成不同测试。

// 先确认请求到达了预期的 HTTP 结果
pm.test("状态码为 200", function () {
  pm.response.to.have.status(200);
});

// 解析一次响应，后面的多个测试复用同一个对象
const data = pm.response.json();

pm.test("name 字段值正确", function () {
  // eql 比字符串包含更严格，能避免把相似文本误判为通过
  pm.expect(data.name).to.eql("Jane");
});

pm.test("age 字段是数字", function () {
  // 类型断言用于提前发现后端把数字序列化成字符串的变化
  pm.expect(data.age).to.be.a("number");
});

这里的 data 是解析后的 JavaScript 对象，不是原始响应文本。eql 适合精确比较值；a("number") 适合比较类型。若同一个字段同时有值和类型要求，建议拆成两条测试，结果面板会更容易定位。

嵌套对象和数组要沿着真实路径断言

接口响应经常把数据放在 data、items 或更深的对象里。不要先把整段 JSON 转成字符串再查关键词，否则字段路径错了仍可能“碰巧通过”。直接沿着对象路径取值，并先判断数组是否存在。

// 解析响应后再进入嵌套对象，避免把整个 JSON 当作普通字符串搜索
const data = pm.response.json();

pm.test("响应包含用户资料", function () {
  // required 字段缺失时，断言会明确失败，而不是静默通过
  pm.expect(data.data).to.be.an("object");
  pm.expect(data.data.profile.id).to.be.a("string");
});

pm.test("列表包含目标状态", function () {
  // 先确认 items 是数组，再判断数组元素是否包含目标值
  pm.expect(data.items).to.be.an("array");
  pm.expect(data.items.map(item => item.status)).to.include("active");
});

如果数组元素是对象，可以用 find 找到目标项，再对结果做对象断言。查找不到时不要继续访问它的子字段，否则测试结果会变成一条不易理解的脚本异常。

// 在数组中找到目标对象，并给找不到的情况留下清晰错误信息
const data = pm.response.json();

pm.test("列表中存在通知配置", function () {
  const notice = data.settings.find(item => item.type === "notification");
  pm.expect(notice, "没有找到 notification 配置").to.be.an("object");
  // 找到对象后，再检查它的 detail 数组
  pm.expect(notice.detail).to.include("email");
});

可选字段、空值和类型变化怎样写

不是每个字段都必然存在。把“字段必须存在”和“字段允许缺省”分开，测试才不会把接口契约写错：

例如一个备注字段允许为 null，可以明确断言它是字符串或空值，而不是让脚本在后续调用中随机报错：

// 允许 note 为空，但非空时必须保持字符串类型
const data = pm.response.json();

pm.test("note 字段符合可选字段约定", function () {
  pm.expect(data.note === null || typeof data.note === "string").to.be.true;
});

从 Test Results 区分三类失败

运行请求后打开测试结果区域，先看失败发生在哪一层：

1. 解析失败：pm.response.json() 无法把响应转换成 JSON。先看响应是否是 HTML 错误页、空响应或格式不完整。
2. 字段断言失败：JSON 已经解析成功，但字段值、类型、路径或数组内容不符合条件。回到响应面板逐层核对路径。
3. 脚本运行异常：例如对未找到的数组元素继续取属性。给查找结果增加明确的对象断言，让错误落到真正的前置条件。

不要只看“有一条红色测试”就改接口。先区分 HTTP 状态码、JSON 解析和业务字段断言，才能判断是服务返回不对、响应格式不对，还是测试脚本假设过于严格。

把断言整理成可复用的小模板

当多个请求都有相同的响应约定时，先保持断言粒度一致，再考虑抽取公共脚本。最小模板可以固定为“状态码—解析—必填字段—可选字段—数组约束”五段，后续只替换业务字段。

// 统一的响应断言骨架，按接口契约删减不需要的检查
pm.test("请求成功", function () {
  pm.response.to.have.status(200);
});

const data = pm.response.json();

pm.test("返回对象包含 id", function () {
  // 必填字段直接检查类型，避免字段缺失被忽略
  pm.expect(data.id).to.be.a("string");
});

pm.test("items 是数组", function () {
  // 数组断言为后续 length、find 或 include 提供前置条件
  pm.expect(data.items).to.be.an("array");
});

公共断言不要为了“全部请求都能跑”而把所有字段都写成可选。每条测试都应该对应一个真实接口约定；如果不同接口的返回结构确实不同，就保留各自的字段路径，换来的可读性通常比强行抽象更有价值。

常见问题

为什么只用 pm.response.text() 不够？

它拿到的是整段文本，只适合检查原文是否包含某个字符串。要判断字段路径、值和类型，应解析为对象后再断言。

字段不存在时怎样避免脚本报一长串异常？

先对父对象或 find 的结果做存在性和类型断言，再访问子字段；这样 Test Results 会指出缺少哪一层。

JSON 能解析但字段断言失败，先查哪里？

先在响应面板确认字段路径、大小写和实际类型，再检查是否把字符串、数字、空值或数组元素误当成了另一种类型。

Postman Tests 的稳定写法可以归纳为一句话：先确认 HTTP 结果，再解析 JSON，最后沿着真实对象路径做值、类型和结构断言。把解析失败、字段不符和脚本异常分开后，Test Results 才真正能帮助你定位接口问题。