Postman API测试工具安装与实战指南

本文还有配套的精品资源，点击获取

简介：Postman是一款广泛使用的API开发与测试工具，极大简化了HTTP请求的构建、发送与结果分析流程。本文详细讲解了Postman 6.1.4版本的安装步骤、核心功能及API测试流程，涵盖请求构建、测试脚本编写、集合管理、环境变量配置、文档生成、Mock服务器搭建等关键功能，适用于不同操作系统的用户。通过本文，开发者可以快速掌握Postman的使用方法，提升API调试与测试效率，适合初学者和专业开发者参考学习。

1. Postman简介与安装流程

Postman 是一款专为 API 开发和测试设计的集成化工具，广泛应用于前后端接口调试、自动化测试、接口文档生成等场景。其核心优势在于支持 RESTful 和 GraphQL 协议，并提供图形化界面以简化 HTTP 请求的构建与管理。无论是调试本地服务还是对接云端 API，Postman 都能显著提升开发效率。

1.1 Postman 的核心功能概述

Postman 提供了多种功能模块，包括但不限于：

功能模块	作用说明
请求构建器	可视化构建和发送 HTTP 请求
响应查看器	实时展示返回数据，支持JSON、XML、HTML等格式
环境与变量管理	支持多环境配置切换，提升跨环境调试效率
测试脚本编写	使用 JavaScript 编写 Pre-request Script 和 Tests 脚本
集合管理	将多个请求组织为集合，便于团队协作与自动化测试
Mock 服务器	快速创建模拟 API 接口用于开发或测试
监控与自动化	支持定时运行集合，进行接口健康检查

1.2 安装流程详解

Postman 提供多种安装方式，适配主流操作系统：Windows、macOS 和 Linux。推荐使用其官方下载页面获取原生应用安装包，以获得最佳性能与功能支持。

1.2.1 Windows 系统安装步骤

1. 打开浏览器，访问 Postman 官网 ；
2. 选择对应系统版本（Windows 64-bit 或 32-bit）并下载安装包；
3. 双击 .exe 文件，按照提示完成安装流程；
4. 启动 Postman，首次运行可选择登录或使用试用模式。

# 可选：使用 PowerShell 安装（需配置 Chocolatey）
choco install postman

1.2.2 macOS 系统安装步骤

1. 访问官网下载 .dmg 安装包；
2. 双击 .dmg 文件，将 Postman 拖拽至“Applications”文件夹；
3. 在 Launchpad 中打开 Postman，首次运行可选择登录或试用。

1.2.3 Linux 系统安装步骤

1. 前往官网下载 .tar.gz 压缩包；
2. 解压文件并移动到合适目录，例如 /opt/postman ；
3. 创建启动脚本或桌面快捷方式。

# 解压并运行 Postman
tar -xvf postman.tar.gz -C /opt/
/opt/Postman/postman

注意事项：
- 若为离线环境，可提前下载安装包并拷贝至目标机器；
- Chrome 插件版已停止更新，建议统一使用原生应用版本；
- 首次启动后建议配置基础环境变量与默认请求参数，以提高后续调试效率。

2. Postman支持的HTTP请求类型

在现代 Web 开发和 API 测试中，HTTP 请求是与后端服务进行交互的核心机制。Postman 作为一款功能强大的 API 开发与测试工具，全面支持常见的 HTTP 方法，并提供便捷的界面与脚本支持，帮助开发者快速构建、调试和测试各种类型的请求。本章将系统讲解 HTTP 请求类型的基本语义、Postman 中的构建方式、请求行为控制技巧，以及通过实际案例演示如何在 Postman 中模拟典型的 API 调用场景。

2.1 常见HTTP方法的语义与应用场景

HTTP 方法定义了客户端与服务器之间的交互方式。理解这些方法的语义和适用场景，是正确使用 Postman 进行 API 测试的前提。

2.1.1 GET、POST、PUT、DELETE 的基本定义与数据交互模式

HTTP 方法中最常见的四种是 GET 、 POST 、 PUT 和 DELETE ，它们分别用于数据的获取、创建、更新和删除。

方法	语义	安全性	幂等性	数据交互方式	适用场景
GET	获取资源	是	是	URL 参数传递	查询数据、搜索接口
POST	创建资源	否	否	Body 中传递数据	用户注册、提交表单
PUT	更新资源	否	是	Body 中传递完整数据	替换资源、更新信息
DELETE	删除资源	否	是	URL 或 Body 中指定	删除用户、移除记录

语义说明 ：
- 安全性 ：是否对服务器状态产生副作用。
- 幂等性 ：多次调用是否产生相同的结果。

示例：使用 Postman 发送 GET 请求获取用户列表

GET https://api.example.com/users

逻辑分析 ：
- 使用 GET 方法访问 /users 接口，通常返回用户列表。
- 请求中没有 Body，参数通过 URL 的 Query String 传递。
- 示例中未携带参数，表示获取全部用户。

示例：使用 POST 创建用户

POST https://api.example.com/users
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

逻辑分析 ：
- POST 请求用于创建新用户。
- Content-Type 设置为 application/json ，表示请求体为 JSON 格式。
- 请求体中包含用户信息，服务器根据这些信息创建新记录。

2.1.2 PATCH、OPTIONS、HEAD 等扩展方法的实际用途分析

除了基础方法外，HTTP 协议还定义了一些扩展方法，用于特定场景。

方法	语义	适用场景
PATCH	部分更新资源	修改用户信息的部分字段（如昵称）
OPTIONS	获取资源通信选项	CORS 预检请求、获取允许的方法
HEAD	获取响应头	检查资源是否存在或获取元数据
TRACE	回显请求	调试网络路径（不推荐生产环境使用）

示例：使用 PATCH 更新用户部分信息

PATCH https://api.example.com/users/1
Content-Type: application/json

{
  "email": "new_email@example.com"
}

逻辑分析 ：
- 使用 PATCH 方法，仅更新用户的 email 字段。
- 与 PUT 不同， PATCH 只发送需要修改的数据片段。
- 更适用于轻量级更新，减少网络传输负担。

示例：使用 HEAD 获取响应头信息

HEAD https://api.example.com/users/1

逻辑分析 ：
- 不返回响应体，只返回 HTTP 头。
- 可用于检查资源是否存在（查看状态码），或获取 Content-Length 、 Last-Modified 等元数据。

2.2 在Postman中构建不同类型的请求

Postman 提供了直观的界面，使得构建各种 HTTP 请求变得简单高效。

2.2.1 请求方法选择与URL输入区域的操作细节

在 Postman 界面中，请求方法选择器位于请求 URL 输入框的左侧。用户可点击下拉菜单选择 GET 、 POST 、 PUT 、 DELETE 等方法。

graph TD
A[选择请求方法] --> B[输入请求 URL]
B --> C[设置请求参数]
C --> D[配置 Headers]
D --> E[设置 Body (POST/PUT 等)]
E --> F[发送请求]

操作步骤 ：
1. 点击方法选择器，选择所需 HTTP 方法。
2. 在 URL 输入框中填写完整的 API 地址（如 https://api.example.com/users ）。
3. 如需参数，点击 Params 标签页添加 Query 参数。
4. 切换 Headers 设置请求头。
5. 对于 POST 、 PUT 等方法，切换 Body 设置请求体。

2.2.2 参数传递方式：Query Params 与 Path Variables 的区别与设置

Query Params（查询参数）

Query 参数通过 URL 的查询字符串传递，格式为 key=value ，多个参数之间用 & 分隔。

GET https://api.example.com/users?role=admin&limit=10

在 Postman 中，点击 Params 标签页，添加键值对即可。

Path Variables（路径变量）

路径变量是 URL 中的一部分，通常用于标识资源 ID。

GET https://api.example.com/users/123

在 Postman 中，可以通过预定义变量（如 {{userId}} ）实现动态路径：

GET https://api.example.com/users/{{userId}}

区别总结 ：

类型	示例	是否推荐用于敏感数据	适用场景
Query Params	?id=123&token=abc	否	过滤、分页、搜索
Path Variables	/users/123	否	资源标识、路径导航

2.3 请求行为控制与高级选项配置

Postman 不仅可以发送请求，还提供了丰富的控制选项来优化请求行为。

2.3.1 超时设置、重定向处理与代理配置

超时设置

在 Settings （设置）中可以配置请求的超时时间，避免长时间等待。

graph LR
A[请求发起] --> B{是否超时?}
B -- 是 --> C[中断请求]
B -- 否 --> D[等待响应]

重定向处理

Postman 默认自动跟随重定向（如 302），但也可以在设置中禁用：

• Settings > General > Follow redirects 勾选与否决定是否自动跳转。

代理配置

在公司网络或测试环境中，可能需要通过代理访问外部 API：

1. 打开 Postman 设置（Preferences）。
2. 切换到 Proxy 标签页。
3. 启用 Custom proxy configuration 。
4. 输入代理地址和端口。

2.3.2 使用 Pre-request Script 预设动态行为

Postman 支持在请求发送前运行 JavaScript 脚本，用于生成动态参数、加密签名等。

示例：在 Pre-request Script 中生成时间戳

// 生成当前时间戳
pm.environment.set("timestamp", Math.floor(Date.now() / 1000));

逻辑分析 ：
- 使用 pm.environment.set() 设置环境变量 timestamp 。
- 该变量可在 URL 或 Body 中引用 {{timestamp}} 。

示例：在请求 URL 中使用变量

GET https://api.example.com/data?timestamp={{timestamp}}

优势 ：
- 实现请求参数的自动化生成。
- 减少手动输入错误，提升测试效率。

2.4 实践案例：模拟典型API调用场景

通过实际案例，我们来演示如何在 Postman 中完成完整的 API 操作流程。

2.4.1 用户注册（POST）与信息更新（PUT）流程实现

用户注册（POST）

POST https://api.example.com/register
Content-Type: application/json

{
  "username": "testuser",
  "password": "secure123",
  "email": "testuser@example.com"
}

预期响应 ：

{
  "status": "success",
  "userId": 456
}

信息更新（PUT）

使用上一步返回的 userId 更新用户信息：

PUT https://api.example.com/users/{{userId}}
Content-Type: application/json

{
  "email": "new_email@example.com"
}

逻辑分析 ：
- 注册后自动获取 userId ，并将其设置为环境变量。
- 使用该变量构造 PUT 请求，更新用户邮箱。

2.4.2 批量删除资源（DELETE）与条件查询（GET with filters）

批量删除用户（DELETE）

DELETE https://api.example.com/users?ids=1,2,3

逻辑分析 ：
- 使用 Query 参数 ids 指定多个用户 ID。
- 后端根据逗号分隔的 ID 批量删除用户。

条件查询用户（GET）

GET https://api.example.com/users?role=admin&active=true

逻辑分析 ：
- 使用 Query 参数进行条件过滤。
- role=admin 表示只返回管理员用户。
- active=true 表示只返回激活状态的用户。

通过本章内容，我们系统讲解了 Postman 中支持的各类 HTTP 请求类型，包括其语义、使用场景、构建方式以及高级控制技巧。结合实际案例，展示了如何使用 Postman 模拟典型 API 调用流程。这些内容为后续章节中更高级的测试与自动化打下了坚实基础。

3. 请求头与请求体配置

在现代API开发中，HTTP请求的精确构造是确保服务间通信正确性和安全性的核心环节。Postman作为一款功能完备的API测试工具，提供了对请求头（Headers）和请求体（Body）高度灵活且精细的控制能力。这一章节将深入剖析如何在Postman中高效配置请求头与请求体，并结合实际场景说明其技术实现路径与最佳实践。通过系统性掌握这些基础但关键的能力，开发者不仅能准确模拟各类客户端行为，还能有效验证后端接口在复杂输入条件下的响应逻辑。

3.1 请求头（Headers）的作用机制与常见字段

HTTP请求头是客户端向服务器传递元信息的重要载体，它们不携带业务数据本身，却决定了请求如何被处理、认证方式、内容编码类型等关键控制流逻辑。Postman为用户提供了直观的Headers编辑界面，支持手动添加、删除或动态注入头部字段，从而满足从简单调试到生产级测试的各种需求。

3.1.1 Content-Type、Authorization、User-Agent等核心Header解析

HTTP头部字段种类繁多，但在日常API调用中最常使用的包括 Content-Type 、 Authorization 和 User-Agent 。理解这些字段的语义及其作用范围，是构建合规请求的前提。

• Content-Type ：该字段用于告知服务器当前请求体的数据格式。例如，当发送JSON数据时应设置为 application/json ；表单提交则使用 application/x-www-form-urlencoded 或 multipart/form-data 。若此值错误，服务器可能无法正确解析请求体，导致400 Bad Request错误。

• Authorization ：这是实现身份验证的核心字段，通常采用Bearer Token、Basic Auth等形式。例如JWT令牌常以 Bearer <token> 的形式附加于此，服务端据此判断用户权限。Postman提供专门的身份验证配置面板，也可直接在Headers中自定义。

• User-Agent ：标识发起请求的客户端类型，如浏览器、移动App或自动化脚本。部分API会根据该字段进行访问控制或返回适配的内容版本。

以下是一个典型的请求头配置示例：

Header Name	Value
Content-Type	application/json
Authorization	Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6…
User-Agent	MyApp/1.0 (Postman Automation)
X-Request-ID	req-abc123

上述表格展示了四个常用Header的应用场景。其中 X-Request-ID 属于自定义字段，可用于链路追踪，在分布式系统中帮助定位问题请求。

graph TD
    A[Client Sends Request] --> B{Does Request Have Headers?}
    B -- No --> C[Server Uses Default Behavior]
    B -- Yes --> D[Parse Content-Type]
    D --> E{Is Format Supported?}
    E -- No --> F[Return 415 Unsupported Media Type]
    E -- Yes --> G[Process Body According to Type]
    H[Check Authorization Header] --> I{Valid Token?}
    I -- No --> J[Return 401 Unauthorized]
    I -- Yes --> K[Proceed with Business Logic]

该流程图清晰地描绘了服务器如何基于请求头做出决策的过程。可以看出，Header不仅是“附加信息”，更是决定请求能否进入业务逻辑的关键开关。

参数说明与执行逻辑分析

在Postman中，Headers可通过两种方式设置：
1. 在请求编辑器的 “Headers” 标签页 中手动输入键值对；
2. 使用脚本动态生成，如通过Pre-request Script写入临时Header。

例如，在Pre-request Script中动态设置一个时间戳Header：

// 动态添加时间戳到请求头
pm.request.headers.add({
    key: 'X-Timestamp',
    value: new Date().toISOString()
});

代码逐行解读：
- 第1行：注释说明脚本目的；
- 第2行：调用 pm.request.headers.add() 方法，向当前请求添加一个新的Header；
- key : 指定Header名称为 'X-Timestamp' ；
- value : 获取当前UTC时间并转换为ISO标准字符串格式。

该技术特别适用于需要防重放攻击或记录请求时间的API测试场景。

此外，Postman还支持自动填充某些Header。例如启用“Send no-cache headers”选项后，会自动添加 Cache-Control: no-cache 和 Pragma: no-cache ，避免缓存干扰测试结果。

3.1.2 自定义Header在身份认证与服务路由中的实践意义

除了标准Header外，许多微服务架构依赖自定义Header来实现高级功能，如灰度发布、租户隔离或多数据中心路由。

以一个SaaS平台为例，不同客户属于不同的租户（Tenant），后端服务需通过 X-Tenant-ID 来区分数据访问权限。此时可以在Postman中设置如下Header：

Header Name	Value
X-Tenant-ID	tenant-prod-01
X-Feature-Flag	enable-new-ui

这种设计使得同一套API可以在不同环境下表现出差异化行为，而无需修改URL或参数结构。

更进一步，结合环境变量可实现多租户快速切换：

// Pre-request Script 示例：根据环境动态设置租户ID
const tenantId = pm.environment.get("CURRENT_TENANT_ID");
if (tenantId) {
    pm.request.headers.upsert({
        key: "X-Tenant-ID",
        value: tenantId
    });
}

逻辑分析：
- pm.environment.get("CURRENT_TENANT_ID") 从当前激活的环境变量中读取租户ID；
- upsert() 方法表示“存在则更新，不存在则插入”，确保Header唯一；
- 这种方式实现了环境无关的请求模板复用，极大提升测试效率。

此外，Kubernetes Istio等服务网格也广泛使用自定义Header进行流量管理。例如：

Outlier-Check: true
Lb-Policy: round_robin
Region: us-west-2

这些Header由网关解析，影响负载均衡策略或熔断机制，属于基础设施层面的控制信号。

综上所述，Header不仅是协议规范的一部分，更是现代API治理体系中的“隐形控制器”。熟练掌握其配置方法与应用场景，是构建高可靠性测试流程的基础能力。

3.2 请求体（Body）的数据格式支持

HTTP请求体承载着真正的业务数据，尤其在POST、PUT等方法中起着决定性作用。Postman提供了多种Body格式的支持，允许用户以最贴近真实场景的方式构造请求内容。本节将详细解析各种Body类型的适用场景、配置方式及潜在陷阱。

3.2.1 raw格式下的JSON、XML、Text编码配置

Postman的 raw 类型允许用户自由输入原始文本内容，并指定MIME类型。这是最常用的Body输入方式之一，尤其适合RESTful API交互。

JSON 格式示例

{
  "username": "alice_wonder",
  "email": "alice@example.com",
  "profile": {
    "age": 28,
    "city": "New York"
  },
  "roles": ["user", "editor"]
}

参数说明：
- username , email : 基础字段；
- profile : 嵌套对象，展示复杂结构支持；
- roles : 数组类型，体现JSON的表达能力。

在Postman中选择 Body → raw → JSON 后粘贴以上内容，并确保Header中设置了 "Content-Type": "application/json" 。

注意事项：
- JSON必须语法合法，否则服务器可能拒绝解析；
- Postman提供语法高亮和错误提示，便于排查格式问题；
- 支持双大括号变量替换，如 {{baseUrl}} 可嵌入动态值。

XML 格式示例

<?xml version="1.0" encoding="UTF-8"?>
<User>
  <Username>bob_builder</Username>
  <Email>bob@example.com</Email>
  <Profile>
    <Age>35</Age>
    <City>London</City>
  </Profile>
</User>

尽管JSON已成为主流，但仍有不少传统系统（如银行、电信）使用SOAP+XML接口。Postman对此类需求同样支持良好。

对应Header应设置为：

Content-Type: application/xml

或

Content-Type: text/xml

Text 纯文本

对于日志推送、脚本传输等场景，可使用纯文本格式：

This is a plain text message sent via POST.
No structure, just raw content.

Content-Type 设置为 text/plain 即可。

3.2.2 form-data与x-www-form-urlencoded表单提交差异

这两种格式均用于模拟HTML表单提交，但在编码方式和用途上有显著区别。

特性	form-data	x-www-form-urlencoded
编码方式	multipart/form-data	application/x-www-form-urlencoded
是否支持文件上传	✅ 是	❌ 否
数据可读性	高（分段清晰）	低（URL编码）
典型使用场景	文件上传、混合数据	登录表单、搜索查询

form-data 示例

假设我们要上传一张用户头像并附带用户名：

Key	Value	Type
avatar	[File] photo.jpg	File
username	john_doe	Text

Postman会自动生成边界符（boundary），并将请求体分割为多个部分：

--abcd1234
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

<binary data here>
--abcd1234
Content-Disposition: form-data; name="username"

john_doe
--abcd1234--

x-www-form-urlencoded 示例

仅文本字段时推荐使用：

username=john_doe&password=secret123&remember=true

所有特殊字符会被URL编码，如空格变为 %20 。

代码示例（Pre-request Script 动态生成表单数据）：

const formData = {
    username: pm.environment.get("TEST_USER"),
    password: pm.environment.get("TEST_PASS"),
    timestamp: Date.now()
};

// 手动拼接为 x-www-form-urlencoded 格式
const encoded = Object.keys(formData)
    .map(key => `${encodeURIComponent(key)}=${encodeURIComponent(formData[key])}`)
    .join('&');

pm.request.body.raw = encoded;

逻辑分析：
- 构造一个包含环境变量引用的对象；
- 使用 encodeURIComponent 安全编码每个键值；
- 最终赋值给 pm.request.body.raw ，需配合正确的Content-Type。

3.2.3 binary文件上传的实现方式与限制说明

binary模式专用于上传单一文件，如图片、PDF、ZIP等二进制资源。

操作步骤：
1. 切换至 Body → binary；
2. 点击 “Select File” 按钮选择本地文件；
3. 自动设置 Content-Type 为文件MIME类型（如 image/png ）。

限制说明：
- 不支持同时上传多个文件；
- 文件大小受限于Postman客户端内存及目标服务器配置；
- 无法添加额外元数据字段（除非搭配form-data使用）。

推荐做法：优先使用 form-data 实现“文件+参数”混合上传，灵活性更高。

3.3 动态参数注入技术

静态请求难以应对多环境、多用户、多状态的测试需求。Postman提供的变量系统允许在Headers和Body中动态注入参数，大幅提升测试脚本的复用性与自动化程度。

3.3.1 利用双大括号语法{{variable}}引用变量

Postman使用Mustache风格的双大括号 {{variable}} 实现变量插值。该语法可在URL、Headers、Body中任意位置使用。

例如，在JSON Body中：

{
  "userId": "{{current_user_id}}",
  "action": "update_profile",
  "timestamp": "{{timestamp}}"
}

只要 current_user_id 和 timestamp 在当前上下文中已定义（如环境变量），Postman会在发送前自动替换。

变量查找顺序：
1. Local（局部，仅本次运行）
2. Collection Variables
3. Environment Variables
4. Global Variables
5. Data Variables（来自外部CSV/JSON文件）

这种层级机制确保了配置的灵活性与安全性。

3.3.2 结合环境变量实现多环境Header自动切换

设想我们有三个环境：dev、staging、prod，每个环境有不同的Base URL和认证Token。

创建环境文件 development.json 内容如下：

{
  "name": "Development",
  "values": [
    {
      "key": "base_url",
      "value": "https://api.dev.example.com"
    },
    {
      "key": "auth_token",
      "value": "dev-jwt-token-123"
    }
  ]
}

在Headers中配置：

Key	Value
Authorization	Bearer {{auth_token}}
Host	{{base_url}}

切换环境时，所有引用自动更新，无需手动修改请求。

优势：
- 减少人为错误；
- 提高团队协作一致性；
- 易于集成CI/CD流水线。

3.4 实战演练：构造带认证令牌的JSON请求

本节通过完整案例演示如何利用前述知识完成一次真实的用户资料更新操作。

3.4.1 获取JWT Token并设置至Authorization Header

假设登录接口为 POST /auth/login ，返回Token如下：

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

在Tests脚本中提取并保存：

const responseJson = pm.response.json();
const token = responseJson.token;

pm.environment.set("ACCESS_TOKEN", token);

随后在后续请求的Headers中使用：

Key	Value
Authorization	Bearer {{ACCESS_TOKEN}}
Content-Type	application/json

3.4.2 发送结构化JSON Body完成用户资料修改请求

构造PUT请求更新用户信息：

{
  "firstName": "Alice",
  "lastName": "Wonderland",
  "preferences": {
    "theme": "dark",
    "language": "en-US"
  }
}

URL: {{base_url}}/users/{{user_id}}

Headers已自动携带Token，请求成功后服务器返回200 OK。

整个流程形成闭环，体现了Headers、Body、变量系统的协同工作能力，为构建自动化测试套件奠定坚实基础。

4. 测试脚本编写（JavaScript）

在现代API开发与自动化测试实践中，仅依赖手动发送请求并观察响应结果的方式已远远不能满足复杂系统对可靠性、可维护性和持续集成的需求。Postman提供的 测试脚本功能 ，基于JavaScript语言构建，允许开发者在每个请求前后执行自定义逻辑，实现断言验证、数据提取、流程控制和性能监控等高级行为。这些脚本运行于Postman内置的沙箱环境中，具备安全隔离性的同时，通过 pm 对象模型暴露丰富的API接口，极大提升了测试的智能化水平。

本章将深入探讨Postman中JavaScript脚本的核心机制，涵盖其执行环境、常用API、断言编写方法、动态数据管理策略，并结合实际项目场景设计可复用的测试模板，帮助用户从“会用Postman”进阶到“精通自动化测试”。

4.1 Postman内置沙箱环境与Script执行时机

Postman之所以能在不牺牲安全性的前提下支持脚本执行，得益于其采用的 V8引擎驱动的JavaScript沙箱环境 。该环境限制了对操作系统底层资源的直接访问（如文件系统、网络套接字），但保留了足够强大的能力用于处理HTTP请求生命周期中的前置准备与后置验证任务。理解脚本的执行时机和作用域是构建稳定自动化流程的第一步。

4.1.1 Pre-request Script与Tests脚本的执行顺序与作用域

在Postman中，每个请求都可以配置两种类型的JavaScript脚本：

• Pre-request Script ：在请求发出前执行。
• Tests ：在收到响应之后执行。

它们分别位于请求编辑界面的两个独立标签页中，具有不同的执行阶段和用途。

执行顺序图示（Mermaid流程图）

graph TD
    A[用户点击 "Send"] --> B{是否存在 Pre-request Script?}
    B -- 是 --> C[执行 Pre-request Script]
    B -- 否 --> D[构造请求并发送]
    C --> D
    D --> E[接收服务器响应]
    E --> F{是否存在 Tests 脚本?}
    F -- 是 --> G[执行 Tests 脚本]
    F -- 否 --> H[显示响应结果]
    G --> H

上述流程清晰地展示了脚本在整个请求周期中的位置。Pre-request Script可用于生成签名、设置动态Header或修改请求参数；而Tests脚本则专注于响应验证、数据提取和状态记录。

作用域差异分析

特性	Pre-request Script	Tests
可访问对象	pm.request , pm.variables , cryptoJS , moment 等库	pm.response , pm.cookies , pm.environment 等
是否能读取响应	❌ 不可访问 pm.response	✅ 完整响应可用
典型用途	设置时间戳、加密签名、随机数生成	断言状态码、解析JSON、提取Token
异常影响	若出错，请求不会发送	即使断言失败，不影响后续流程（除非中断集合运行）

注意：尽管脚本错误通常不会阻断整个请求流程，但在使用Newman进行CI/CD时，可通过配置使任何断言失败导致构建失败。

4.1.2 支持的JavaScript API：pm对象模型详解

Postman通过全局对象 pm 提供了一套结构化的API，使得脚本能以声明式方式操作请求、响应、变量和环境信息。以下是核心模块的分类说明。

pm 对象主要子模块

模块	功能描述
pm.sendRequest()	发起异步HTTP请求（常用于获取Token）
pm.expect()	Chai断言库的封装，用于值比对
pm.response	获取当前请求的响应内容（状态码、body、header等）
pm.environment	管理环境变量（get/set/delete）
pm.globals	操作全局变量
pm.collectionVariables	集合级别变量操作
pm.request	修改即将发出的请求（URL、headers、body等）
pm.info	获取当前运行上下文信息（如迭代次数、请求名称）

示例代码：使用Pre-request Script添加认证签名

// 生成带时间戳的HMAC-SHA256签名
const timestamp = Math.floor(Date.now() / 1000).toString();
const secretKey = 'your-secret-key';
const message = `${pm.request.method}${pm.request.url}${timestamp}`;

// 使用CryptoJS计算签名
const signature = CryptoJS.HmacSHA256(message, secretKey).toString(CryptoJS.enc.Hex);

// 将参数注入请求头
pm.request.headers.add({
    key: 'X-Timestamp',
    value: timestamp
});
pm.request.headers.add({
    key: 'X-Signature',
    value: signature
});

逐行逻辑解读 ：

• 第2行：获取当前UNIX时间戳（秒级），作为防重放攻击的时间标记；
• 第3–4行：定义密钥与拼接待签消息字符串，格式为“HTTP方法 + URL路径 + 时间戳”；
• 第7行：调用Postman内建的 CryptoJS 库执行HMAC-SHA256哈希运算，输出十六进制编码的签名；
• 第10–13行：通过 pm.request.headers.add() 动态添加自定义Header字段，供服务端验证身份合法性。

此模式广泛应用于金融类API、支付网关等需要强安全校验的接口中。由于签名依赖实时时间戳，必须在每次请求前重新计算，因此Pre-request Script成为理想选择。

参数说明表

参数名	类型	是否必需	说明
method	String	是	HTTP方法（GET、POST等）
url	String	是	请求完整URL
timestamp	Number	是	当前时间戳（秒）
secretKey	String	是	客户端与服务端共享的密钥
signature	String	输出	生成的HMAC签名值

此类脚本体现了Pre-request Script的核心价值——在请求发出前完成敏感逻辑处理，避免硬编码或人工干预。

4.2 断言编写与响应验证

高质量的API测试不仅要求“能通”，更需确保“正确”。Postman的 Tests脚本 正是为此而生。借助Chai风格的断言语法与JSON Schema校验能力，可以精准判断响应是否符合预期，从而实现自动化的质量门禁。

4.2.1 使用pm.response.to.have.status()进行状态码校验

最基础也是最关键的断言是对HTTP状态码的检查。例如，成功创建资源应返回 201 Created ，未授权访问应返回 401 Unauthorized 。

示例代码：多维度状态码断言

// 基础状态码校验
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// 扩展：根据环境判断不同期望值
const expectedStatus = pm.environment.get("expect_success") === "true" ? 200 : 400;
pm.test(`Expected status: ${expectedStatus}`, function () {
    pm.response.to.have.status(expectedStatus);
});

逻辑分析 ：

• 第2–4行：使用 pm.test() 定义一个名为“Status code is 200”的测试项，内部调用 pm.response.to.have.status(200) 断言实际状态码等于200；
• 第7–9行：引入环境变量 expect_success 动态决定期望状态码，实现灵活测试策略切换。

这种条件化断言适用于A/B测试或多分支业务逻辑的验证场景。

4.2.2 JSON响应字段提取与值比对（pm.expect与tv4 schema）

除了状态码，还需验证响应体的内容结构与语义正确性。

示例代码：验证JSON响应字段并比对数值

// 解析响应体为JSON对象
const responseJson = pm.response.json();

// 断言关键字段存在且类型正确
pm.test("Response has valid user data", function () {
    pm.expect(responseJson.id).to.be.a('number');
    pm.expect(responseJson.name).to.be.a('string').and.not.empty;
    pm.expect(responseJson.email).to.include('@');
});

// 使用pm.expect进行精确值匹配
pm.test("User role is admin", function () {
    pm.expect(responseJson.role).to.eql("admin");
});

参数说明 ：

• responseJson : 由 pm.response.json() 解析得到的JavaScript对象；
• to.be.a(type) : Chai类型断言，检测数据类型；
• not.empty : 断言字符串非空；
• include('@') : 检查邮箱格式合理性（简化版）；
• eql() : 深度相等比较，支持对象/数组。

此外，对于复杂的嵌套结构，推荐使用 JSON Schema验证 ：

const schema = {
    type: "object",
    properties: {
        id: { type: "integer" },
        name: { type: "string" },
        isActive: { type: "boolean" },
        createdAt: { type: "string", format: "date-time" }
    },
    required: ["id", "name"]
};

pm.test("Response matches schema", function () {
    pm.expect(tv4.validate(responseJson, schema)).to.be.true;
});

tv4说明 ：Postman集成了轻量级JSON Schema验证器 tv4 ，可在Tests脚本中直接调用 tv4.validate(data, schema) 返回布尔值。

响应结构验证表格

字段	类型	必填	示例值	校验方式
id	integer	✅	12345	pm.expect(type).to.be.a('number')
name	string	✅	“Alice”	not.empty
email	string	⚠️	“alice@example.com”	include('@')
role	string	✅	“admin”	eql("admin")
createdAt	string	✅	“2025-04-05T10:00:00Z”	format: date-time

此类结构化校验有助于早期发现接口契约变更带来的兼容性问题。

4.3 提取与共享数据：从响应中获取Token或ID

在真实业务流中，多个API之间往往存在依赖关系。例如：登录接口返回JWT Token → 后续请求携带该Token → 查询用户详情 → 删除账户。若每次都需要手动复制粘贴Token，效率低下且易出错。Postman提供了变量机制来解决这一痛点。

4.3.1 解析JSON响应并写入环境变量（pm.environment.set）

示例代码：从登录响应中提取Token并存储

// 获取响应JSON
const loginRes = pm.response.json();

// 提取access_token字段
const accessToken = loginRes.data?.access_token;

// 写入环境变量
if (accessToken) {
    pm.environment.set("auth_token", accessToken);
    console.log("✅ Auth token saved to environment:", accessToken.substring(0, 10) + "...");
} else {
    console.warn("⚠️ No token found in response");
}

逐行解析 ：

• 第2行： pm.response.json() 将响应体转换为JS对象；
• 第4行：使用可选链操作符 ?. 安全获取深层属性，防止因字段缺失导致脚本崩溃；
• 第7行： pm.environment.set(key, value) 将Token持久化至当前激活的环境中；
• 第8行： console.log 输出日志（可见于Postman Console），便于调试。

此后，在其他请求的Headers中可直接使用 {{auth_token}} 引用该变量：

Authorization: Bearer {{auth_token}}

4.3.2 构建跨请求依赖链：登录→获取数据→注销流程自动化

通过组合Pre-request Script与Tests脚本，可实现完整的端到端工作流自动化。

Mermaid流程图：自动化依赖链示意

sequenceDiagram
    participant Client
    participant LoginAPI
    participant UserDataAPI
    participant LogoutAPI

    Client->>LoginAPI: POST /auth/login
    LoginAPI-->>Client: 200 OK + {token: "xyz"}
    Note right of Client: Tests脚本提取token<br>存入环境变量

    Client->>UserDataAPI: GET /user/profile<br>Header: Bearer {{auth_token}}
    UserDataAPI-->>Client: 200 OK + 用户信息

    Client->>LogoutAPI: POST /auth/logout<br>Header: Bearer {{auth_token}}
    LogoutAPI-->>Client: 204 No Content

该流程无需人工干预即可完成身份认证全过程，特别适合集成至CI/CD流水线中。

实际应用技巧

• 在集合根目录的 Pre-request Script 中统一注入认证Header；
• 利用 pm.sendRequest() 在Tests中主动调用下游接口（谨慎使用，避免循环）；
• 设置超时与重试机制，提升稳定性。

4.4 实际项目应用：构建可复用的测试断言模板

在大型项目中，重复编写相似断言会降低维护效率。通过抽象通用逻辑，可创建标准化的测试脚本模板，实现一次编写、多处复用。

4.4.1 标准化错误响应检测逻辑

无论成功还是失败，API应遵循统一的响应格式。以下是一个通用错误结构的断言模板：

// 统一错误响应断言函数
function assertErrorStructure(statusCode, expectedCode) {
    pm.test(`Expect error response with status ${statusCode}`, () => {
        pm.response.to.have.status(statusCode);
        const res = pm.response.json();
        pm.expect(res.success).to.be.false;
        pm.expect(res.error).to.be.an('object');
        pm.expect(res.error.code).to.equal(expectedCode);
        pm.expect(res.error.message).to.be.a('string').and.not.empty;
    });
}

// 调用示例：验证400 Bad Request
assertErrorStructure(400, "INVALID_INPUT");

优势 ：将重复逻辑封装为函数，提高可读性与一致性。

4.4.2 响应时间监控与性能基线判断脚本

除功能性外，性能也是API质量的重要指标。可通过 pm.response.responseTime 实现响应延迟监控。

示例代码：性能基线断言

const MAX_RESPONSE_TIME = 500; // 毫秒

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

// 分级报警机制
if (pm.response.responseTime > 300) {
    console.warn(`🐢 Slow response: ${pm.response.responseTime}ms`);
} else {
    console.log(`⚡ Fast response: ${pm.response.responseTime}ms`);
}

应用场景 ：在压力测试或生产模拟中，快速识别潜在瓶颈。

性能监控配置表

指标	正常范围	警告阈值	危险阈值	处理建议
响应时间	<300ms	300–500ms	>500ms	优化数据库查询或缓存
吞吐量	>50 RPS	20–50 RPS	<20 RPS	检查服务实例数量
错误率	0%	<1%	≥1%	查看日志与熔断机制

结合Newman与Prometheus，还可实现自动化性能趋势分析。

综上所述，Postman的JavaScript脚本能力不仅是简单的“加个断言”，更是构建 智能、可靠、可持续演进的API测试体系 的核心支柱。掌握其原理与最佳实践，是每一位资深API工程师的必备技能。

5. 使用集合管理API请求

Postman的 集合（Collection） 功能是其最强大的特性之一，它不仅是API请求的组织容器，更是实现 自动化测试、文档生成、持续集成 的关键载体。集合将零散的API请求按业务逻辑进行分组，使得开发、测试、文档维护等工作更加系统化、模块化。通过集合，开发者可以构建完整的API测试流程，甚至将测试流程自动化运行在CI/CD管道中，如使用Postman自带的 Newman CLI工具 进行集成部署。

本章将从集合的结构设计、配置继承机制、导出导入策略，到最后的综合实战，系统地讲解如何高效地使用集合来管理你的API测试任务。

5.1 集合（Collections）的组织结构与设计原则

5.1.1 按业务模块划分集合：如“用户管理”、“订单服务”

在构建Postman集合时，建议采用 业务模块划分 的方式进行组织。例如，在一个电商平台项目中，可以将API请求分为如下几个集合：

模块名称	包含的API示例	说明
用户管理	/login, /register, /profile/edit	管理用户注册、登录与资料修改
商品服务	/products/list, /product/detail	提供商品信息查询功能
订单中心	/orders/create, /orders/list	订单创建与查询功能
支付回调	/payment/notify, /payment/status	支付成功后的异步回调处理

设计建议 ：
每个集合应围绕一个 业务领域 展开，避免将不相关的API混杂在一起，便于后续维护和协作。

5.1.2 子文件夹的嵌套使用与请求归类策略

Postman支持在集合中创建 子文件夹（Folders） ，用于进一步细分请求。例如，在“用户管理”集合下，可以建立如下子文件夹：

graph TD
    A[用户管理] --> B(注册与登录)
    A --> C(用户信息维护)
    A --> D(权限与角色管理)

使用技巧 ：
- 子文件夹可以嵌套多层，但建议不要超过3层，避免结构过于复杂。
- 每个子文件夹内可以设置 共享的Headers、环境变量、预脚本 等，提升配置效率。

5.2 集合级别的配置继承机制

5.2.1 共享Headers、Authentication和Pre-script的统一设置

Postman允许在集合级别设置 通用请求配置 ，这些配置将被集合内的所有请求继承。这对于统一身份认证、公共请求头等设置非常有用。

示例：在集合中统一设置Authorization Header

1. 打开Postman，选择一个集合（如“订单服务”）。
2. 点击右上角的 … ，选择 Edit 。
3. 在 Authorization 标签页中选择认证方式（如Bearer Token）。
4. 输入Token值（也可以使用变量 {{auth_token}} ）。
5. 点击 Update 。

此时，该集合下的所有请求将自动携带该认证信息，无需在每个请求中重复配置。

示例代码：统一设置Pre-request Script

你还可以在集合中设置统一的Pre-request Script，比如动态生成时间戳：

// 设置当前时间戳到环境变量
pm.environment.set("timestamp", Date.now());

该脚本会在集合中每个请求执行前自动运行，所有请求都可以通过 {{timestamp}} 调用该变量。

5.2.2 变量作用域在集合层级的表现形式

Postman中的变量具有 作用域层级 ，具体如下：

graph TD
    A[局部变量] --> B[请求变量]
    B --> C[集合变量]
    C --> D[环境变量]
    D --> E[全局变量]

• 集合变量 适用于整个集合内的所有请求。
• 如果多个层级的变量名称相同，Postman会使用 优先级更高的变量 。
• 你可以通过集合编辑界面的 Variables 标签页来定义集合变量。

5.3 导出与导入：实现团队间协作与备份恢复

5.3.1 JSON格式的集合导出与版本控制集成

Postman支持将集合导出为JSON格式，方便在团队中共享或纳入版本控制系统（如Git）。

操作步骤：

1. 在左侧集合列表中右键点击某个集合。
2. 选择 Export 。
3. 选择导出格式（建议选择“Collection v2.1”）。
4. 保存为 .json 文件。

你可以将该文件提交到Git仓库，实现版本控制和团队协作。

示例JSON结构片段：

{
  "info": {
    "name": "订单服务",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "创建订单",
      "request": {
        "method": "POST",
        "url": "https://api.example.com/orders/create",
        "body": {
          "mode": "raw",
          "raw": "{ \"product_id\": 123, \"quantity\": 2 }"
        }
      }
    }
  ]
}

提示 ：使用Postman的 自动化测试脚本 和 集合变量 可使导出的集合具备良好的可移植性。

5.3.2 使用CLI工具newman进行持续集成部署

Newman 是Postman的命令行工具，支持在无界面环境下运行集合测试，非常适合集成到CI/CD流程中。

安装Newman：

npm install -g newman

执行集合测试：

newman run "订单服务.postman_collection.json" --environment "开发环境.postman_environment.json"

输出结果示例：

┌─────────────────────────┬──────────┬──────────┐
│                         │  executed│   failed│
├─────────────────────────┼──────────┼──────────┤
│              iterations │        1 │        0 │
│                requests │        3 │        0 │
│              test-scripts │        3 │        0 │
│         prerequest-scripts │        3 │        0 │
│                     assertions │        6 │        0 │
└─────────────────────────┴──────────┴──────────┘

持续集成建议 ：
- 将Newman集成到Jenkins、GitHub Actions等CI平台。
- 设置定时任务或触发机制，实现每日自动化回归测试。

5.4 综合实战：构建完整的电商平台API测试集合

5.4.1 包含商品查询、下单、支付回调等端到端流程

我们将以一个电商平台为例，构建一套完整的API测试集合，涵盖以下流程：

1. 用户登录 ：获取JWT Token。
2. 商品查询 ：根据分类或关键词搜索商品。
3. 下单操作 ：创建订单并传递商品信息。
4. 支付回调 ：模拟支付网关回调通知。
5. 订单状态验证 ：确认订单状态是否更新为“已支付”。

示例请求顺序图：

sequenceDiagram
    用户->>登录接口: POST /login
    登录接口-->>用户: 返回JWT Token
    用户->>商品接口: GET /products?category=electronics
    商品接口-->>用户: 返回商品列表
    用户->>订单接口: POST /orders/create
    订单接口-->>用户: 返回订单ID
    用户->>支付接口: POST /payment/notify
    支付接口-->>订单接口: 异步通知支付成功
    用户->>订单接口: GET /orders/{order_id}
    订单接口-->>用户: 返回订单状态（已支付）

每个步骤的Postman请求设置：

步骤	请求方法	URL	参数/Body示例
登录	POST	https://api.example.com/login	{ “username”: “test”, “password”: “123456” }
商品查询	GET	https://api.example.com/products	?category=electronics
下单	POST	https://api.example.com/orders/create	{ “product_id”: 123, “quantity”: 1 }
支付回调	POST	https://api.example.com/payment/notify	{ “order_id”: 456, “status”: “paid” }
订单状态查询	GET	https://api.example.com/orders/{{order_id}}	-

5.4.2 集成自动化测试脚本与文档生成配置

自动化测试脚本示例：

// 在“登录”请求的Tests脚本中提取Token
pm.test("登录成功并获取Token", function () {
    pm.response.to.have.status(200);
    var jsonData = pm.response.json();
    pm.environment.set("auth_token", jsonData.token);
});

// 在“创建订单”请求中使用Token
pm.request.headers.add({
    key: "Authorization",
    value: "Bearer {{auth_token}}"
});

自动生成文档：

Postman支持将集合导出为API文档，步骤如下：

1. 在集合页面点击 … ，选择 Publish Docs 。
2. 选择环境（如“开发环境”）。
3. Postman将自动生成在线文档，支持公开访问或团队共享。

文档模板示例 ：
- 请求方法、URL、Headers、Body、响应示例都将自动生成。
- 可自定义描述、参数说明、错误码等信息。

通过本章的学习，你已经掌握了如何使用Postman的集合功能来组织API请求、统一配置、跨团队协作，并最终构建一个完整的电商平台API测试流程。集合不仅是测试工具，更是 API开发、测试、文档、自动化集成 的中枢，值得每一位开发者深入掌握。

6. 环境变量与全局变量设置

6.1 变量系统的基本概念与优先级规则

Postman 提供了一套灵活的变量系统，允许用户在不同作用域中定义和使用变量，从而实现动态请求构建、跨请求数据共享以及多环境适配。理解变量的作用域及其优先级是设计高效测试流程的关键。

Postman 中的变量主要分为以下四类：

变量类型	作用域范围	持久化方式	示例用途
局部变量	单次请求生命周期内有效	内存中临时存储	动态生成的 nonce 值
全局变量	所有集合和环境中均可访问	需手动保存	公共 API 密钥（不推荐明文）
环境变量	当前激活环境下的所有请求可用	存储于 Postman 云或本地	不同环境的 base_url、token
数据文件变量	运行 Collection Runner 时通过 CSV/JSON 注入	文件驱动	批量创建用户的用户名密码列表

变量解析优先级顺序如下（由高到低）：

1. 局部变量（Local Variable）
2. 环境变量（Environment Variable）
3. 全局变量（Global Variable）
4. 集合变量（Collection Variable）
5. 数据文件变量（Data File Variable）

注意：若多个变量具有相同名称，Postman 将按照上述优先级选择其值。

变量命名规范建议：

• 使用小写字母 + 下划线风格（如 api_base_url ），避免驼峰命名以提升可读性。
• 敏感信息（如 JWT token、密码）应启用 Postman 的“保密字段”功能，在 UI 中隐藏显示。
• 推荐使用命名空间前缀区分模块，例如： auth_token , user_id , payment_endpoint 。

// 示例：在 Pre-request Script 中设置局部变量
pm.variables.set("request_nonce", Math.random().toString(36).substr(2, 8));

该代码生成一个随机字符串作为本次请求的唯一标识符，仅在当前请求上下文中有效。

6.2 多环境配置管理：开发、测试、生产环境切换

在实际项目中，API 通常部署在多个环境中（开发、测试、预发布、生产）。通过 Postman 的 环境管理器（Environment Manager） ，我们可以为每个环境独立配置基础参数，并实现一键切换。

创建三个典型环境：

1. Development Environment
   - base_url : https://dev-api.example.com/v1
   - auth_mode : bearer
   - debug : true

2. Staging Environment
   - base_url : https://staging-api.example.com/v1
   - auth_mode : oauth2
   - debug : false

3. Production Environment
   - base_url : https://api.example.com/v1
   - auth_mode : bearer
   - debug : false

切换操作步骤：

1. 点击右上角环境选择下拉框 → “Manage Environments”
2. 添加新环境并填写对应键值对
3. 保存后返回请求界面，URL 可使用 {{base_url}}/users 形式引用
4. 切换环境即可自动变更目标服务地址

GET {{base_url}}/products?category={{default_category}}
Authorization: Bearer {{access_token}}

此请求会根据当前激活的环境动态替换 base_url 和 access_token ，极大提升了测试灵活性。

此外，可以结合 pm.environment.getName() 在 Tests 脚本中添加环境感知逻辑：

if (pm.environment.getName() === "Production") {
    pm.test("Production: Response time < 1s", function () {
        pm.expect(pm.response.responseTime).to.be.below(1000);
    });
}

6.3 环境变量在复杂工作流中的高级应用

除了基本的 URL 替换，环境变量还可用于实现更复杂的自动化场景。

动态生成时间戳与随机数据

// Pre-request Script 示例：生成 ISO 时间戳
const now = new Date().toISOString();
pm.environment.set("current_timestamp", now);

// 生成唯一邮箱用于注册测试
const randomEmail = `testuser_${Date.now()}@example.com`;
pm.environment.set("test_email", randomEmail);

随后可在 Body 或 Query 参数中引用：

{
    "email": "{{test_email}}",
    "created_at": "{{current_timestamp}}"
}

条件逻辑控制接口行为（A/B 测试）

假设某接口支持两种算法路径 /v1/recommendations?type=legacy 与 type=new ，可通过环境变量控制流量分发：

// 在 Pre-request Script 中插入逻辑
const flowType = pm.environment.get("recommendation_flow") || "legacy";
pm.variables.set("flow_type", flowType);

请求 URL 设置为：

GET {{base_url}}/recommendations?type={{flow_type}}

只需修改环境变量 recommendation_flow 为 "new" 即可快速切换测试组。

使用脚本更新环境变量链

// Tests 脚本中提取响应数据并持久化
const jsonResponse = pm.response.json();
pm.environment.set("last_created_order_id", jsonResponse.id);
pm.environment.set("order_status", jsonResponse.status);

这使得后续请求可以直接依赖前序结果：

DELETE {{base_url}}/orders/{{last_created_order_id}}

6.4 完整API测试流程实战：从登录到数据清理的全链路自动化

构建一个闭环测试流程，涵盖认证获取 → 资源操作 → 清理释放全过程。

场景描述：用户下单全流程自动化

1. POST /auth/login → 获取 token
2. GET /cart → 查询购物车
3. POST /orders → 提交订单
4. DELETE /orders/:id → 删除订单（清理）

步骤说明：

第一步：登录并提取 Token

// Tests 脚本
pm.test("Status 200", () => pm.response.to.have.status(200));
const res = pm.response.json();
pm.environment.set("access_token", res.token);
pm.environment.set("user_id", res.user_id);

第二步：在 Headers 中引用 Token

Authorization: Bearer {{access_token}}
Content-Type: application/json

第三步：提交订单时引用 user_id

{
    "userId": "{{user_id}}",
    "items": [
        { "productId": "P001", "quantity": 2 }
    ]
}

第四步：清理资源

DELETE {{base_url}}/orders/{{last_order_id}}

配合 Collection Runner 或 Newman CLI，可实现无人值守执行：

newman run "E-commerce-API-Flow.json" \
  --environment="Test-Env.json" \
  --global-var "run_id=run_$(date +%s)" \
  --reporters cli,json \
  --delay-request 500

整个流程通过环境变量串联各环节数据依赖，形成稳定可靠的端到端测试链条。

本文还有配套的精品资源，点击获取

简介：Postman是一款广泛使用的API开发与测试工具，极大简化了HTTP请求的构建、发送与结果分析流程。本文详细讲解了Postman 6.1.4版本的安装步骤、核心功能及API测试流程，涵盖请求构建、测试脚本编写、集合管理、环境变量配置、文档生成、Mock服务器搭建等关键功能，适用于不同操作系统的用户。通过本文，开发者可以快速掌握Postman的使用方法，提升API调试与测试效率，适合初学者和专业开发者参考学习。

本文还有配套的精品资源，点击获取