集合级Tests脚本必须写在Postman集合的Tests标签页中，右键集合→Edit→Tests，该脚本作用于集合下所有请求（含子文件夹），在Collection Runner或单个请求Send时触发，优先级低于请求级Tests。
集合级 Tests 脚本写在哪
Postman 的集合公共断言必须写在集合（Collection）的 Tests 标签页里，不是单个请求或文件夹下。右键点击集合名称 → Edit → 切换到 Tests 选项卡，这里填入的 JavaScript 会自动作用于该集合下所有请求（包括子文件夹里的请求）。
注意：脚本只在「集合运行」（Collection Runner）或「单个请求发送」时触发，但不会影响手动点击文件夹/请求的 Send 行为——除非那个请求本身也启用了 Tests；集合级 Tests 是兜底逻辑，优先级低于请求级 Tests。
怎么用 pm.test 写通用状态码断言
最常用的是统一校验 HTTP 状态码是否为 200，但别直接抄旧版 tests["xxx"] = responseCode.code === 200 —— 这是 v2.x 语法，新版 Postman 已弃用 responseCode 和 tests 全局对象，必须用 pm.test + pm.response.to.have.status() 风格。
pm.test("Status must be 200", () => { pm.response.to.have.status(200); });- 如果要兼容多种成功码（比如
201、204），改用pm.expect([200, 201, 204]).to.include(pm.response.code) - 若某接口允许重定向（
302），又不想让断言失败，得显式排除：加个if (pm.response.code !== 302) { ... }包裹逻辑
集合级断言里怎么安全读取 JSON 响应
直接写 pm.response.json() 很危险：只要响应体不是合法 JSON（比如空响应、HTML 错误页、二进制文件），脚本就会抛 SyntaxError，整个断言块中断，后续测试不执行，且错误提示藏在控制台里很难发现。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
正确做法是加 try/catch：
pm.test("JSON body has data field", function () {
try {
const json = pm.response.json();
pm.expect(json).to.have.property('data');
} catch (e) {
pm.expect.fail('Response is not valid JSON: ' + e.message);
}
});
其他常见坑：
- 没检查
Content-Type就硬解析：先用pm.response.headers.get("Content-Type")?.includes("application/json")做守门员 - 想取嵌套字段但路径不存在：用
_.get(json, "data.user.id", null)（需提前在 Collection Settings → Variables 里引入 Lodash）或手写json?.data?.user?.id - 把
pm.environment.set()放在集合级 Tests 里：它会覆盖所有请求的环境变量，容易引发变量污染
为什么集合断言有时不生效
常见原因就三个：
- 没点保存：编辑完集合的
Tests脚本后，必须点右上角 Save，否则下次打开还是旧脚本 - 运行方式不对：用单个请求的
Send按钮发请求时，集合级 Tests 是生效的；但如果你用的是Runner，要确认 Runner 界面右上角选中了正确的集合（不是文件夹），且勾选了Run collection tests - 脚本语法错误：哪怕只是少了个括号，整个集合 Tests 都会静默跳过，不会报红。建议在脚本开头加一行
console.log("collection test running");，然后按Ctrl+Alt+C打开 Postman Console 看输出
集合级断言真正难的不是写法，而是厘清「哪些逻辑真该放这里」——比如 token 刷新、错误码分类统计、跨请求数据比对，这些一旦写错，会影响整套用例的稳定性。别为了省事把所有断言都堆上去。
