前言

在现代软件开发与多系统联调过程中,API 调试是每个研发、测试与运维人员的核心高频工作。

许多人对 Postman 的认知仅停留在“输入 URL,点击 Send 按钮查看 Response”的初级阶段。实际上,作为一个完备的 API 全生命周期平台,Postman 拥有极其强大的工业级功能,如多维变量管理、前置/后置脚本、异步嵌套请求、自动化断言测试以及 Mock 服务等。

本篇文章将带你全方位剖析 Postman,从底层请求体的不同类型到高级脚本编写,并实战演练如何利用它调试 WebService/SOAP 接口、构建自动化测试工作流以及配合 CI/CD 实现自动化部署测试。


一、 基础篇:HTTP 请求体类型与底层机制解析

在 Postman 中构建 POST/PUT 请求时,我们需要在 Body 中配置请求体。正确选择请求体类型决定了 HTTP 请求头中 Content-Type 的底层设置:

1
2
3
4
5
6
7
8
9
+-------------------------------------------------------------+
| 请求体类型 | Content-Type 自动设定值 | 适用场景
+-------------------+-----------------------------------------+----------------
| form-data | multipart/form-data; boundary=... | 混合传输文件和键值对
| urlencoded | application/x-www-form-urlencoded | 纯文本表单提交
| raw (JSON) | application/json | 绝大多数现代 REST API
| raw (XML) | text/xml 或 application/xml | WebService/XML API
| binary | application/octet-stream (常需手动修改) | 单个大文件二进制上传
+-------------------------------------------------------------+

1.1 multipart/form-data

对应 HTML 中的 <form enctype="multipart/form-data">。它将表单划分为多个 Part,每个 Part 都有自己的 Boundary(边界分隔符)。

  • 特点:支持将 文件(File) 与普通的文本键值对混合发送。
  • Postman 操作:在 Key 输入框悬停,点击右侧的下拉菜单,将类型由 Text 改为 File,即可上传本地文件。

1.2 application/x-www-form-urlencoded

对应默认的 HTML 表单提交方式。

  • 特点:数据被编码为 key1=value1&key2=value2 格式进行发送。特殊字符会被转义(URL Encoding)。
  • 局限性不支持上传文件,只适合纯文本的简单表单提交。

1.3 raw (原始类型)

最常用的数据类型。你可以直接输入任何纯文本格式的数据,并在右侧下拉菜单中选择其子类型(JSON, XML, HTML, Text)。

  • JSON:Postman 会自动在 Headers 中添加 Content-Type: application/json,并将内容进行 JSON 校验。
  • XML:自动在 Headers 中添加 Content-Type: text/xml

1.4 binary (二进制)

用于将文件内容作为请求体直接发送(通常不带表单的键值包装),适用于需要以二进制流形式上传大文件(如大图片、音视频文件、PDF 报告)的场景。


二、 变量系统与五大作用域层级

Postman 拥有非常严密的变量作用域系统。当多处定义了同名变量时,作用域越窄(优先级越高)的变量会覆盖作用域宽的变量

1
2
3
4
5
6
7
+-------------------------------------------------------+
| Global (全局) - 整个 Workspace 可见 |
| └─ Collection (集合) - 仅限该 Collection 内可见 |
| └─ Environment (环境) - 仅在选定环境生效 |
| └─ Data (外部数据) - 仅在 Runner 批量测试生效|
| └─ Local (局部) - 仅限单次脚本运行 | (优先级最高)
+-------------------------------------------------------+
  1. Global(全局变量):工作空间内所有 Collection 共享。适用于存放通用配置。
  2. Collection(集合变量):特定 Collection 独享,变量随 Collection 一起导出。适合存储该 Collection 下所有 API 共享的数据。
  3. Environment(环境变量):最常用。你可以创建“开发”、“测试”、“生产”环境,配置各自的 ipbase_url。在右上角下拉切换环境时,双花括号 {{base_url}} 会自动替换。
  4. Data(数据变量):在 Collection Runner 运行自动化测试时,从外部 CSV 或 JSON 文件导入的数据。
  5. Local(局部/临时变量):在 Pre-request 或 Tests 脚本中通过代码定义,生命周期仅限于单次 HTTP 请求执行。

💡 动态变量 (Dynamic Variables)

Postman 提供了一组内置的动态变量,可以直接在 URL、Header 或 Body 中用双花括号引用,免去手写脚本生成的麻烦:

  • {{$guid}}:生成一个随机的 UUID V4 字符串。
  • {{$timestamp}}:生成当前 Unix 时间戳(秒级)。
  • {{$randomInt}}:生成 0 到 1000 之间的随机整数。
  • {{$randomPhoneNumber}}:生成一个随机的手机号码。

三、 实战:在 Postman 中完美调试 WebService/SOAP 接口

WebService (SOAP) 接口在各类企业级遗留系统(如传统 ERP、金融核心、医疗系统)中依然很活跃。要在 Postman 中成功调用它,请严格执行以下步骤:

  1. 设置 Method 为 POST:WebService 接口的读写操作全部基于 POST 请求。
  2. 配置 URL:填写 WebService 的实际服务访问端点(而不是以 ?wsdl 结尾的地址)。
  3. 配置 Headers
    • SOAP 1.1
      • Content-Typetext/xml; charset=utf-8
      • 必须手动添加 SOAPAction 标头(其值通常为 "命名空间/方法名",可以从 WSDL 中找到)。
    • SOAP 1.2
      • Content-Typeapplication/soap+xml; charset=utf-8。不需要 SOAPAction 标头。
  4. 编辑 Body
    • 选择 raw -> XML
    • 写入符合 SOAP 格式规范的 Envelope 报文:
1
2
3
4
5
6
7
8
9
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:web="http://www.example.com/webservice">
<soapenv:Header/>
<soapenv:Body>
<web:GetUserInfo>
<web:userId>USR20260628001</web:userId>
</web:GetUserInfo>
</soapenv:Body>
</soapenv:Envelope>

四、 脚本编写:Pre-request Script 与 Tests 自动化断言

Postman 在请求执行前后提供了两个沙盒 JavaScript 运行节点。这是实现接口自动化、加解密签名的核心地带。

4.1 Pre-request Script 最佳实战:接口签名与加密

很多企业级接口在发送前,要求在 Header 或 Body 中加入安全签名(如 sign = md5(app_key + timestamp + nonce))。我们可以利用 Postman 内置的 CryptoJS 库在请求发送前自动计算并生成签名:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 1. 生成 10 位 Unix 时间戳
const timestamp = Math.round(new Date().getTime() / 1000).toString();
pm.environment.set("current_timestamp", timestamp);

// 2. 生成随机 Nonce(可以使用 UUID 或随机数)
const nonce = pm.variables.replaceIn('{{$guid}}');
pm.environment.set("api_nonce", nonce);

// 3. 从环境变量获取 AppKey 和 AppSecret
const appKey = pm.environment.get("app_key");
const appSecret = pm.environment.get("app_secret");

// 4. 按规则拼接字符串并进行 HmacSHA256 签名计算
const stringToSign = `appKey=${appKey}&nonce=${nonce}&timestamp=${timestamp}`;
const sign = CryptoJS.HmacSHA256(stringToSign, appSecret).toString(CryptoJS.enc.Hex);

// 5. 设置为环境变量供 Header 引用
pm.environment.set("api_sign", sign);

console.log(`[Sign Generator] StringToSign: ${stringToSign} | Sign: ${sign}`);

在 Request 的 Headers 面板配置:

1
2
3
4
5
6
KEY          | VALUE
-------------+---------------------
X-App-Key | {{app_key}}
X-Timestamp | {{current_timestamp}}
X-Nonce | {{api_nonce}}
X-Sign | {{api_sign}}

4.2 异步嵌套请求 (pm.sendRequest):自动拉取 Token

有时候,我们调用的所有业务接口都需要一个鉴权 Token,而这个 Token 只有 2 小时有效期。我们不希望每次都去手动调用登录接口拷贝 Token。

利用 pm.sendRequest,我们可以在 Pre-request Script 中实现自动静默登录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
const token = pm.environment.get("auth_token");
const tokenExpireTime = pm.environment.get("token_expire_time"); // 存时间戳

// 如果 Token 为空,或者当前时间已经接近/超过过期时间,则自动重新获取
if (!token || !tokenExpireTime || new Date().getTime() > Number(tokenExpireTime)) {
console.log("Token 已过期或不存在,启动自动登录获取...");

const loginRequest = {
url: pm.environment.get("base_url") + "/api/v1/auth/login",
method: 'POST',
header: {
'Content-Type': 'application/json'
},
body: {
mode: 'raw',
raw: JSON.stringify({
username: pm.environment.get("login_username"),
password: pm.environment.get("login_password")
})
}
};

// 发起异步 HTTP 请求
pm.sendRequest(loginRequest, function (err, response) {
if (err) {
console.error("自动登录请求异常:", err);
return;
}

const resJson = response.json();
if (resJson.code === 200) {
const newToken = resJson.data.token;
// 缓存 Token,并计算新的过期时间(例如 7200 秒,我们扣除 60 秒的安全冗余)
const expireTimestamp = new Date().getTime() + (7200 - 60) * 1000;

pm.environment.set("auth_token", newToken);
pm.environment.set("token_expire_time", expireTimestamp.toString());
console.log("新 Token 获取成功,已写入环境变量。");
} else {
console.error("自动登录失败,原因:", resJson.message);
}
});
}

4.3 Tests 脚本:解析 XML 响应与断言测试

Tests 中,我们除了可以校验常规的 JSON 数据,还可以对 WebService 返回的 XML 报文进行断言。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 示例一:普通 REST 接口的常用断言
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

pm.test("Response time is less than 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("JSON 字段结构完整性断言", function () {
const jsonData = pm.response.json();
pm.expect(jsonData).to.have.property('code', 200);
pm.expect(jsonData.data).to.have.property('user_id');
});

// 示例二:解析 WebService XML 响应并断言
pm.test("XML 响应特定节点内容校验", function () {
// 将 XML 转换为 JSON 格式便于路径访问
const responseJson = xml2Json(responseBody);

// 按照 SOAP 报文的层级节点深度访问
const resultNode = responseJson['soap:Envelope']['soap:Body']['GetUserInfoResponse']['GetUserInfoResult'];

// 断言结果不为空且包含预期字符串
pm.expect(resultNode).to.not.be.undefined;
pm.expect(resultNode).to.include("Success");
});

五、 Collection Runner 与 Newman 命令行的 CI/CD 集成

当你在 Postman 中整理好了一个 Collection(比如包含 20 个 API 接口,并全部配置了自动化 Tests 断言),你可以对其进行批量冒烟测试和 CI/CD 自动化集成。

5.1 在 Postman UI 中运行 (Collection Runner)

  1. 点击 Collection 旁边的 “…” (三点图标) -> Run collection
  2. 配置参数:
    • Iterations:迭代运行的次数(比如循环跑 5 次)。
    • Delay:每个请求之间的延迟时间(毫秒),防止将后端服务压垮。
    • Data:如果是批量测试不同数据(如批量注册 100 个账号),可以导入一个包含测试数据的 CSV 或 JSON 文件。
  3. 点击 Run,Postman 会按照顺序依次发送请求,并实时展现每个接口的断言测试结果(Pass / Fail)。

5.2 命令行工具 Newman:CI/CD 自动化集成

如果你希望将这些 API 测试放到 Jenkins、GitLab CI 或 GitHub Actions 中,使项目在编译构建后自动执行接口回归测试,你可以使用 Postman 官方提供的命令行工具 Newman

步骤 1:安装 Newman

1
2
# 需要有 Node.js 环境
npm install -g newman

步骤 2:从 Postman 导出文件

  • 导出 Collection:右键 Collection -> Export,另存为 my_collection.json
  • 导出 Environment:点击 Environment 管理页面的 Export 按钮,另存为 my_env.json

步骤 3:在命令行/构建服务器运行

1
newman run my_collection.json -e my_env.json --reporters cli,html --reporter-html-export report.html

该命令会在终端输出精美的运行状态,并在本地生成一份可视化的网页版测试报告 report.html。如果断言失败率不为 0,Newman 会返回非 0 的 Exit Code,构建工具(如 Jenkins)收到后便会自动标记本次构建失败。


六、 Mock Server 快速搭建与联调

在前后端分离的开发流程中,往往后端接口方案已经敲定,但代码尚未编写完成,而前端急需真实接口进行页面绘制和调试。Postman 的 Mock Server 能够完美充当这个“替身”。

1
2
3
4
5
6
7
8
+------------+       Request       +--------------------+
| 前端/客户端| ------------------> | Postman Mock Server|
+------------+ +--------------------+
|
v 自动匹配 Example
+--------------------+
| 返回预设的 Response |
+--------------------+

6.1 创建 Mock Server

  1. 在左侧面板选择 Mock Servers -> Create Mock Server
  2. 填写 Mock Server 的基本接口配置(如请求方法、Path、预设返回状态码和 Body)。
  3. 命名并点击 Create。Postman 会为你生成一个公共的以 mock.pstmn.io 结尾的 Base URL(例如 https://3f89xxxx.mock.pstmn.io)。

6.2 配置具体接口的 Example(响应样例)

  1. 在你的 Collection 中,找到某个准备 Mock 的请求。
  2. 点击请求右侧的 “…” -> Add example
  3. 在 Example 的 Response 区域输入期望返回的假数据(如模拟登录成功返回的 JSON)。
  4. 保存 Example。
  5. 前端开发者只需要请求 https://3f89xxxx.mock.pstmn.io/api/v1/user/info,Postman 就会根据 Path 自动匹配该 Example 并将预设数据返回给前端。

结语

Postman 已经从最初的浏览器插件演进为一个多功能的 API 协同生态。无论是手写 CryptoJS 签名、通过 pm.sendRequest 构建登录前置流,还是将导出的 Collection 丢给 Newman 在持续集成服务器中跑自动化,都展示了它在工程级研发中无可替代的价值。

熟练掌握这些高级功能,能极大缩短前后端对接和自动化回归测试的周期,让每一次接口交付都坚如磐石!