最简断言应使用 pm.test 包裹并推荐 pm.expect(pm.response.code).to.be.equal(200)，避免全等误判类型；需校验 200~299 范围时用 .within(200, 299)；失败时应输出响应体辅助调试。
pm.response.code === 200 是最简断言，但别直接写死
Postman 断言状态码为 200，最常用也最容易出错的是直接用全等判断：pm.response.code === 200。这在大多数 HTTP 成功响应下没问题，但要注意：pm.response.code 返回的是数字类型，而某些代理或 Mock 服务可能返回字符串（比如 "200"），此时会静默失败。更稳妥的做法是显式转数字或用宽松比较：
-
pm.expect(pm.response.code).to.be.equal(200)—— 基于 Chai 的断言，自动处理类型转换，推荐 -
pm.expect(+pm.response.code).to.eql(200)—— 强制转数字再比，明确意图 - 避免
pm.response.code == "200"：字符串比较不可靠，且绕过类型检查
用 pm.test 包裹断言，否则不报错也不显示结果
很多人把断言语句直接写在 Tests 标签页里，却不加 pm.test，结果脚本执行了但 Postman 不识别为测试项，既不计入测试统计，失败时也不高亮提示。必须用 pm.test 显式声明测试名称：
- 正确写法：
pm.test("Status code is 200", () => { pm.expect(pm.response.code).to.be.equal(200); }); - 错误写法：
pm.expect(pm.response.code).to.be.equal(200);—— 没有pm.test，等于“没写断言” - 多个断言可共用一个
pm.test块，但建议每个逻辑独立成 test，便于定位失败点
需要校验 200~299 范围？别手写 if，用 .inRange()
有些接口成功响应可能是 201（Created）、204（No Content）等，硬写 === 200 会误判。Chai 提供了 .inRange() 方法，简洁又语义清晰：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
pm.test("Status code is in 2xx range", () => {
pm.expect(pm.response.code).to.be.within(200, 299);
});
-
.within(200, 299)包含边界，覆盖全部标准成功状态码 - 注意不是
.between()—— Chai 的.between是开区间，.within才是闭区间 - 如果后端返回非标准码如
210或299，也要确认是否属于你认可的成功范围
断言失败时看不到响应体？加 pm.response.text() 或 pm.response.json()
仅校验状态码不够，很多问题出在 200 但 body 是错误 JSON 或空字符串。断言失败时 Postman 默认只显示测试名和错误类型，不会自动打印响应内容。调试时务必手动输出：
- 查原始响应：
console.log(pm.response.text()); - 查解析后 JSON（需确保是合法 JSON）：
console.log(pm.response.json()); - 加在断言前或
catch块里，例如：pm.test(..., () => { console.log(pm.response.json()); pm.expect(...); }); - 注意：如果响应体不是 JSON，
pm.response.json()会抛异常，导致后续断言不执行 —— 先用pm.response.headers.get("Content-Type")判断类型更安全
实际跑通的关键不在“怎么写”，而在“怎么让失败可见”。状态码断言本身极轻量，但一旦嵌套在集合运行、环境切换或前置脚本之后，漏掉 pm.test 或忽略响应体类型，就很容易变成“看着绿、实则错”。
