需在Tests脚本中做业务语义断言，如登录后校验token存在且长度≥32，查询订单校验data为非空数组，删除接口检查204状态码，避免仅断言code=0等格式正确但语义错误的情况。
怎么用 Tests 脚本验证上一个接口的响应是否被正确传给下一个
关键不是“有没有传”，而是“传得对不对”——比如 user_id 字段从上一个接口返回的是字符串 "123"，但下一个接口要求整型，直接塞进去就可能 400。Postman 本身不校验类型或结构，得靠脚本主动检查。
常见错误现象：400 Bad Request 或 500 Internal Server Error，但参数看起来都“有值”。实际是字段名拼错、嵌套层级不对、或 JSON 解析后取值路径失效（比如返回 {"data": {"id": 123}}，却写了 pm.response.json().id）。
- 先在上一个请求的
Tests中提取并存为变量：const res = pm.response.json();<br>pm.environment.set("user_id", res.data?.id?.toString() || ""); - 在下一个请求的
Pre-request Script中加防护性检查：const uid = pm.environment.get("user_id");<br>if (!uid || isNaN(Number(uid))) {<br> throw new Error(`Invalid user_id: "${uid}"`);<br>} - 发送前用
Console面板确认变量值：console.log("user_id =", pm.environment.get("user_id"));
环境变量和 Collection 变量混用时，哪个优先级更高
Collection 变量优先级高于 Environment 变量，但低于 Local 变量。这在链路测试中极易踩坑：比如你用 pm.environment.set("token", ...) 存了登录态，但集合里又定义了同名 Collection Variable 值为 dummy_token，那后续所有请求实际用的都是后者。
使用场景：多环境共用一套集合时，常用 Collection 变量存通用配置（如 base_url），Environment 变量存环境专属值（如 auth_token）。一旦混淆，链路会在某个环境突然中断，且错误提示完全不指向变量冲突。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 调试时优先查
pm.variables.get("xxx")，它返回当前作用域下真实生效的值 - 避免重名：给 Collection 变量加前缀，比如
coll_base_url，Environment 变量用env_auth_token - 在集合根节点的
Pre-request Script中统一初始化，防止子请求读到未赋值的空变量
怎么确保整个链路里时间戳、随机串、签名三者严格同步生成
加密加签类接口失败，80% 出在“时间戳过期”或“随机串重复”。Postman 的 Pre-request Script 是唯一能保证三者原子性生成的地方——不能分开写在不同请求里，也不能依赖外部服务生成后再粘贴。
性能影响：每次请求都执行一次 HMAC-SHA256 计算基本无感，但若误把 RSA 私钥加密逻辑放进来，会明显拖慢请求速度，且私钥硬编码在脚本里存在泄露风险。
- 所有动态值必须在同一段脚本内生成：
const timestamp = Date.now().toString();<br>const nonce = Math.random().toString(36).substr(2, 8);<br>const params = { app_id: "abc", timestamp, nonce, ... };<br>const sign = CryptoJS.HmacSHA256(CryptoJS.enc.Utf8.parse(JSON.stringify(params)), "secret").toString(); - 签名前务必对参数做字典序排序（很多文档没明说，但服务端强制要求）
- 时间戳单位要和服务端一致：服务端用秒，你就
Math.floor(Date.now()/1000)；用毫秒就直接用Date.now()
链路验收时为什么响应体断言通过了，但业务还是失败
因为断言只管“格式对”，不管“语义对”。比如登录接口返回 {"code": 0, "data": {"token": "xxx"}}，你写了 pm.expect(json.code).to.eql(0) 就认为成功，但其实 token 是个无效值，下游调用立刻 401。
容易被忽略的地方是：链路中每个环节的“成功”定义不同。登录要校验 token 非空且长度合理；查询订单要校验 data 是数组且至少含一项；而删除接口的“成功”甚至可能是空响应体 + 204 状态码。
- 每个请求的
Tests必须包含业务层断言，不止状态码和 code 字段：const data = json.data;<br>pm.test("Token is valid length", () => {<br> pm.expect(data.token).to.exist;<br> pm.expect(data.token.length).to.be.at.least(32);<br>}); - 用
pm.response.code替代字符串匹配状态码，避免"200"和200类型不一致导致断言失效 - 链路末尾加汇总断言：比如下单后查订单列表，断言新订单的
status是"created"，而不是笼统的"exists"
