Postman断言脚本必须填在Tests选项卡，响应后自动执行，依赖pm.response等对象；填错位置（如Pre-request Script）则不运行，常见错误包括ReferenceError、0/0结果、语法混用；推荐统一使用pm.test()配合Chai断言，避免旧语法tests["xxx"]=...；JSON断言需先校验Content-Type和解析异常，再安全访问嵌套字段；Test Results中显示通过/失败数，每条pm.test应职责单一以便定位问题。
Postman断言脚本必须填在请求编辑页的 Tests 选项卡里，不是 Pre-request Script、不是 Body、也不是 Headers —— 填错位置就完全不会执行。
断言脚本只在 Tests 标签页生效
点击一个已配置好的请求，在 URL 输入框下方能看到多个标签页，其中 Tests 是唯一支持断言运行的位置。它在响应返回后自动触发，此时 pm.response、pm.environment 等对象才可用。
常见错误现象：
-
ReferenceError: pm is not defined：多因使用 Chrome 应用版 Postman（已停更），改用官网下载的独立桌面版即可解决 - 脚本无报错但 Test Results 显示 0/0：检查是否误填在
Pre-request Script或其他非Tests区域 - 断言通过但逻辑没生效：确认是否用了旧版
tests["xxx"] = ...语法却依赖pm.response.json()，两者混用易出错
pm.test() 和 tests[] 两种写法怎么选
新版推荐统一用 pm.test() + Chai.js 断言风格，语义清晰、链式调用稳定、错误提示友好；tests[] 是旧语法，虽仍兼容，但不支持嵌套断言、无法自定义失败消息、调试困难。
实操建议：
- 新项目或新接口一律用
pm.test("描述", () => { pm.expect(...).to.eql(...); }) - 若维护老集合且含大量
tests["xxx"] = responseBody.indexOf(...) !== -1，可逐步迁移，不必强求一次性替换 -
pm.test()内部必须是同步函数，不能await，如需异步处理（如调用外部 API 验证 token），得改用 Pre-request Script + 环境变量中转
JSON 响应断言最容易踩的三个坑
90% 的 JSON 断言失败不是逻辑错，而是解析阶段就崩了 —— 比如响应体实际是 HTML 错误页、空字符串、XML 或带 BOM 的 UTF-8 编码。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
务必加保护逻辑：
- 先校验响应类型：
pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json") - 再尝试解析，用
try/catch包裹：let jsonData; try { jsonData = pm.response.json(); } catch (e) { throw new Error("Invalid JSON: " + e.message); } - 访问嵌套字段前检查路径存在：
pm.expect(jsonData?.data?.list?.[0]?.id).to.equal(123)，避免Cannot read property 'list' of undefined
断言结果在哪看、怎么看懂
点击 Send 后，在响应区域切换到 Test Results 标签页。这里显示的是真实执行结果，不是控制台输出。
关键细节：
-
3/3表示共运行 3 条pm.test()，全部通过；2/3表示有 1 条失败，点开对应条目才能看到具体哪行抛错、预期/实际值差异 - 失败时错误堆栈会定位到
pm.test函数体内，但不会标行号，建议每条pm.test只做一件事，方便排查 - 如果某条断言依赖上一条的结果（比如先取 token 再用 token 请求），它们之间无隐式顺序 —— 必须合并进同一个
pm.test函数，或拆成多个独立测试并接受“失败即中断”
真正容易被忽略的是：断言脚本没有事务性，一条失败不影响其余执行，但也不会自动跳过后续依赖步骤 —— 所以结构设计比语法更重要。
