4. Postman 入门:从安装到脚本验证,一条线走通

Postman 核心功能架构与工作流 安装与界面 下载与安装 主界面布局 请求构建区 响应查看区 集合与请求 集合管理 HTTP 请求配置 参数与头信息 批量运行 环境与变量 全局变量 环境变量 变量优先级 动态值 脚本与测试 Pre-request Tests 脚本 断言验证 数据提取 测试执行与验证

4.1 安装与界面概览

Postman 的安装没什么门槛,去官网下个客户端,一路下一步就行。但我得提醒一句——千万别用 Chrome 插件版,那个已经停维护了。直接装独立客户端,Windows / macOS / Linux 都支持。

装好之后打开,界面分成几块:左边是侧边栏,管集合和请求的;中间是工作区,配请求用的;右边是响应区。说白了就是一个「请求编辑器 + 响应查看器」的组合体。我个人习惯把侧边栏收窄一点,给工作区腾地方,看着爽。

小技巧: 刚装完先别急着写请求,打开 Settings → General,把 "Trim keys and values in editors" 关掉。我以前被它自动 trim 坑过,一个接口调了半天发现是参数空格被吞了…

4.2 集合与请求管理

集合就是个文件夹,把你相关的请求放一起。我建议按业务模块来分:用户模块一个集合、订单模块一个集合、支付模块一个集合。别把几百个请求全扔默认集合里,找都找不到。

创建请求也很简单,点一下 "New" 选 HTTP Request,填 URL 和方法就行。这里有个坑——很多人上来就填 URL 发请求,结果参数写死在请求里,换个环境就得改半天。

避坑: 请求里的域名、端口、密钥这些,一律用变量代替。后面讲环境变量你就明白了。

集合还有个很实用的功能——批量运行。你可以把一个集合里所有请求按顺序跑一遍,看看哪些挂了。

实战建议: 每写完一个接口测试,都跑一遍集合,确保没把之前的搞坏。这叫回归,养成习惯。

4.3 环境变量与全局变量

这是 Postman 最常用的功能之一。简单来说:全局变量所有环境都能用,环境变量只在你选中的那个环境里生效。

我举个例子:你的 API 在开发环境是 dev.api.com,测试环境是 test.api.com,生产环境是 api.com。你难道每次换环境都去改 URL?

不用。你建三个环境:dev、test、prod,每个环境里定义一个变量 base_url,请求里写 {{base_url}}/users。切换环境,自动换域名。

对比维度 环境变量 全局变量
作用范围 只在选中的环境内 所有环境都可见
优先级 高(覆盖全局) 低(被环境覆盖)
典型用途 域名、端口、账号 固定 、版本号
切换方式 右上角下拉选环境 一直生效,无需切换
你想想看, 要是全局变量和环境变量同名了,谁说了算?答案是环境变量。我曾经吃过这个亏——全局写了个 ,环境里也写了一个,结果查了半天才发现环境变量把全局覆盖了。记住:环境变量 > 全局变量。

4.4 Pre-request Script

Pre-request Script 是在请求发出去之前执行的一段脚本。说白了,就是让你在发请求前做点准备工作。

最常见的场景是算签名。我前几年做一个支付项目,每个请求都要把参数拼接后算 MD5 放头里。手动算?不可能的。用 Pre-request Script 自动算:

// 生成时间戳
pm.variables.set("timestamp", Date.now());

// 拼接参数算签名(示意)
const data = pm.request.body.raw + pm.variables.get("timestamp");
const sign = CryptoJS.MD5(data).toString();
pm.variables.set("sign", sign);

你看,请求里只用写 {{sign}} 和 {{timestamp}},脚本自动填充。换环境、换参数,签名跟着变,永远不会忘。

我个人习惯: 把 Pre-request Script 当成「请求的初始化函数」。生成随机数、设置时间戳、从环境变量里拿 —— 全放这。这样每个请求本身保持干净,只