Postman怎么断言响应正文不包含错误信息_Postman异常文本排除测试

酷杰酱_3431

发布时间：2026-11-06 10:59:28

109人浏览过

来源于php中文网

原创

Postman中排除响应正文特定字符串需用pm.expect(pm.response.text()).to.not.include("error")，避免使用不稳定的responseBody；JSON响应须用try/catch解析后校验字段，状态码排除推荐pm.expect(pm.response.code).to.not.be.within(500, 599)，并为每个检查点单独写pm.test()确保全覆盖。

postman怎么断言响应正文不包含错误信息_postman异常文本排除测试

响应正文不能含特定字符串：用 `pm.expect().to.not.include()`

Postman 默认断言都是“正向匹配”（比如必须含某字符串），但排查错误时更常需要“反向排除”——确认响应里没有 error、Exception、500 Internal Server Error 这类异常文本。直接用 pm.expect(pm.response.text()).to.not.include("error") 最可靠，它基于 Chai 断言库，语义清晰且失败时提示明确。

常见错误现象：tests["no error"] = !responseBody.has("error") 看似能用，但一旦响应为空或解析失败，responseBody 可能是 undefined，导致整个脚本报错中断，断言结果不显示为 FAIL 而是 ERROR。

必须用 pm.response.text() 获取原始响应体，避免 responseBody 在旧语法中行为不稳定
大小写敏感：如果要忽略大小写，得手动转小写再比，例如 pm.expect(pm.response.text().toLowerCase()).to.not.include("error")
多个关键词要逐个断言，Chai 不支持数组批量排除，别写成 .to.not.include(["error", "fail"]) —— 会直接报语法错误

JSON 响应中排除特定字段值：先解析再校验

当接口返回标准 JSON（如 {"code": 500, "msg": "system error"}），光检查正文含不含 error 不够精准。应该先解析 JSON，再针对字段做否定判断，比如确保 code 不等于 500 或 msg 不含敏感词。

典型误用：tests["no 500"] = pm.response.json().code !== 500 —— 如果响应根本不是 JSON（比如服务端返回了 HTML 错误页），pm.response.json() 会抛出解析异常，测试直接中断，看不到 FAIL 提示。

Postman Mac版

Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma

下载

务必加 try/catch 包裹 JSON 解析逻辑，否则异常会吞掉断言结果

推荐写法：

pm.test("No server error in response", function () {
  try {
    const json = pm.response.json();
    pm.expect(json.code).to.not.equal(500);
    pm.expect(json.msg || "").to.not.include("error");
  } catch (e) {
    pm.expect.fail("Response is not valid JSON: " + e.message);
  }
});

注意空值处理：json.msg 可能为 null 或 undefined，直接调 .includes() 会报错，所以用 json.msg || "" 安全兜底

响应头或状态码配合正文排除：避免漏判

单靠正文文本排除容易失效——有些错误只体现在状态码（如 502）或响应头（如 X-Error-Code: TIMEOUT），正文反而为空或被美化过。真正健壮的“异常排除”必须多层覆盖。

容易踩的坑：pm.test("No error", ...) 只写一个测试名，多个断言塞进去，一旦前面的失败，后面的就不会执行（Chai 默认短路）。结果你以为只漏了 code 检查，其实 header 校验根本没跑。

每个独立检查点单独写 pm.test()，比如：pm.test("Status code not 5xx", ...)、pm.test("No X-Error-Header", ...)
状态码排除建议用范围判断：pm.expect(pm.response.code).to.not.be.within(500, 599)，比罗列 !== 500 && !== 502 && !== 504 更可维护
检查自定义错误头时，用 pm.response.headers.has("X-Error-Code") 判断是否存在，再用 pm.response.headers.get("X-Error-Code") 取值进一步校验

断言失败时看不到具体原因？检查 `Test Results` 的折叠细节

Postman 的 Test Results 面板默认只显示 PASS/FAIL 图标和测试名，失败时如果不点开箭头，根本看不到哪一行报错、预期和实际值分别是什么。这对调试“排除型断言”尤其致命——你不知道是正文真含了 error，还是 JSON 解析失败，抑或网络超时返回了空响应。

真实场景中，最常被忽略的是响应编码问题：比如后端返回 GBK 编码的中文错误信息，而 pm.response.text() 默认按 UTF-8 解码，导致乱码字符串无法被正确匹配，断言意外通过。这种问题不会报错，只会让你误以为“没错误”，实则漏检。

调试时在 Tests 里临时加一行：console.log("Raw response:", pm.response.text().substring(0, 200))，看实际拿到的文本长什么样
若怀疑编码问题，改用 pm.response.stream（需 Postman v10+）配合第三方解码库，但多数情况建议后端统一 UTF-8
所有排除类断言，强烈建议在测试名里写明“排除什么”，比如 pm.test("No 'SQL syntax' in body", ...)，方便团队快速定位意图