Postman 接口测试入门：从发请求到写断言

上一篇《左移右移的三道防线》结尾我说过，方法论系列 6 篇完结，接下来从"想明白"到"做出来"------用 Postman + JavaScript 把这套方法论真正落到工具里。

这一篇是这个新系列的开篇，把 Postman 从"我用来点点点的工具"升级成"接口自动化的入口"。整篇用一个贯穿案例------优惠券领券接口的测试------把"发请求、写断言、保存用例"三步讲透。

核心判断

Postman 不是一个"发请求的工具"------它是接口自动化的工作台：环境变量、请求模板、脚本、断言、批量执行，全在同一个工具里闭环。

很多人用 Postman 只用到了 20%：Send 按钮一点，看一眼响应，关掉走人。本质上 Postman 在他手里就是一个"图形化的 curl"。但 Postman 真正的威力在另外 80%：Tests 脚本、Pre-request、环境变量、Collection Runner------把"我手动跑"变成"机器自动跑、可重复跑、可批量跑"。

这篇就把那 80% 的入口------发请求、写断言、保存用例------打通。

第一步：搭好工作台

解决什么：用 Postman 之前，先把"环境、Collection、环境变量"这三件套准备好。没有这三件套，所有操作都是一次性的，谈不上自动化。

怎么做：

建一个 Collection：Collection 是 Postman 里"一组请求的容器"，相当于一个项目。你后续所有的请求、脚本、用例都装在 Collection 里。
建一个 Environment ：Environment 是一组"环境变量"，比如 base_url、token、user_id 都在这。测试环境一套、生产环境一套，切换时一键换环境，不用改请求。
变量引用 ：请求里所有"会变"的值都用 {{变量名}} 引用，不要写死。比如：

bash 复制代码

{{base_url}}/coupon/receive
Authorization: Bearer {{token}}

为什么必须做这一步 ：如果你把"测试环境的 URL"硬编码在每个请求里，切换环境时要改 N 个请求；用 {{base_url}} 引用，切换环境只改 Environment 一个地方。这就是自动化的种子------把"重复的配置"抽成变量。

最小工作台长这样：

text 复制代码

📁 Collection：优惠券系统接口测试
  📂 领券模块
    📄 领券接口（POST /coupon/receive）
    📄 查询券详情（GET /coupon/detail）
  📂 下单模块
    📄 下单接口（POST /order/create）
🔧 Environment：测试环境
  - base_url：https://test-api.example.com
  - token：<登录后填>
  - test_user_id：10086

口诀：Collection 装请求，Environment 装配置，请求里只放 {{变量}}。

第二步：把"手动点点点"变成"可复用的请求模板"

解决什么：用 Postman 点一次能调通接口，但如果不保存，这个请求就是"一次性的"。做自动化必须把"能跑通的请求"沉淀成模板，下次直接调。

怎么做：以领券接口为例，看一个请求的四要素。

案例：领券接口

要素	例子
URL	`{{base_url}}/coupon/receive`
Method	POST
Headers	`Content-Type: application/json`、`Authorization: Bearer {{token}}`
Body（JSON）	`{ "userId": "{{test_user_id}}", "couponTemplateId": "tpl_100_minus_20" }`

填好后，点 Send 验证一次------确认能跑通。

然后点 Save，存到"领券模块"这个文件夹下。

为什么必须 Save ：Save 之后这个请求才"存在"于你的 Collection 里。下次做联调、做回归、做交接------任何人打开这个 Collection 都能直接调这个请求，不用从头填。这就是"请求模板"的价值：把一次性的手动操作变成可复用的资产。

口诀：能跑通的请求必 Save，Save 之后才有"用例"可言。

进阶习惯：填 Description

每个请求的 Description 里写两行：

这个接口是干什么的
调用前需要什么前置条件

例：

text 复制代码

用途：为指定用户领取一张优惠券实例
前置：用户已登录（token 有效）、优惠券模板存在

这是写给"三个月后的自己"和"接手的同事"看的，省一遍又一遍问"这接口是啥意思"。

第三步：写断言------让"我看一眼"变成"机器自动判"

解决什么 ：Send 之后，Postman 会显示响应。但"看一眼"是手动行为------你点一次、看一次、关掉，下次还要再点再看。断言就是让 Postman 自动判断"这次请求是不是符合预期"，符合就绿勾，不符合就红叉。

怎么做 ：点开请求下方的 Tests 标签页，写 JavaScript 脚本。

最常用的三个断言：

javascript 复制代码

// 1. 状态码断言：HTTP 状态码是不是 200
pm.test("状态码是 200", function () {
    pm.response.to.have.status(200);
});

// 2. 响应体断言：返回的 JSON 里某字段是否符合预期
pm.test("返回了券实例 ID", function () {
    const json = pm.response.json();
    pm.expect(json.couponId).to.exist;          // 字段存在
    pm.expect(json.couponId).to.be.a("string");  // 类型是字符串
    pm.expect(json.couponId).to.have.lengthOf(20); // 长度符合预期
});

// 3. 响应头断言：比如 Content-Type 是 JSON
pm.test("响应是 JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});

写完点 Send，Tests 标签页会显示每个断言的通过/失败结果------绿的通过，红的失败。

口诀：没断言的请求等于没测试。Send 不是结束，断言通过才是。

为什么断言这么重要：

回归场景里，你要跑几十上百个请求，不可能一个个看响应
断言让 Postman 变成"自动判卷老师"------你点一次 Collection Runner，它跑完所有请求，自动告诉你"哪几个挂了"
没有断言，就没有自动化；有断言，机器才能替你判断对错

进阶：把"单次请求"变成"一条完整用例"

前面三步做完后，你已经能"发请求 + 断言 + 保存"了。但这只是"半自动"------你点 Send 才跑一次。真正的"用例"还要做到两件事：

Pre-request Script：跑请求前的"造数 / 准备"

解决什么 ：很多接口不是孤立能调通的------调用前需要"用户已登录"、"购物车已有商品"、"账户有余额"。这些前置条件在 Tests 里没法做，要放在 Pre-request Script（请求前执行）。

案例：领券接口的 Pre-request Script

javascript 复制代码

// Pre-request Script：先登录拿 token，再调领券
pm.sendRequest({
    url: pm.environment.get("base_url") + "/user/login",
    method: "POST",
    header: { "Content-Type": "application/json" },
    body: {
        mode: "raw",
        raw: JSON.stringify({
            username: "user_yang",
            password: "test123"
        })
    }
}, function (err, res) {
    if (err) {
        console.log("登录失败", err);
        return;
    }
    // 把登录返回的 token 存到环境变量
    pm.environment.set("token", res.json().token);
});

关键点 ：Pre-request 脚本每次跑都重新登录、拿新 token------不是"用一次残留 token 跑一百次"，而是"每次都是新的 token"。这就是上一篇《造数工厂》的思想在 Postman 里的具体落地：数据按需创建，不依赖残留。

Tests 后置：跑完的"清理 + 数据回传"

解决什么 ：用例跑完后要"清理"------领的券要还回去、创建的订单要取消；还要"回传"------把响应里的 couponId 存起来给后续请求用。

案例：领券接口的 Tests 后置

javascript 复制代码

// Tests：断言 + 回传数据
pm.test("领券成功", function () {
    pm.response.to.have.status(200);
    const json = pm.response.json();
    pm.expect(json.couponId).to.exist;

    // 把 couponId 存到环境变量，给后续"下单用券"接口用
    pm.environment.set("coupon_id", json.couponId);
});

// 后置清理：跑完后把券退回
pm.sendRequest({
    url: pm.environment.get("base_url") + "/coupon/return",
    method: "POST",
    header: {
        "Content-Type": "application/json",
        "Authorization": "Bearer " + pm.environment.get("token")
    },
    body: {
        mode: "raw",
        raw: JSON.stringify({ couponId: pm.environment.get("coupon_id") })
    }
});

口诀：Pre-request 造前置，Tests 断结果 + 传数据 + 清理------三个动作一套用例。

一个完整的用例长这样

把上面所有要素拼起来，一条标准的接口自动化用例长这样：

text 复制代码

📄 领券接口（POST /coupon/receive）
  ├─ 描述：用例-领券成功-默认模板
  ├─ URL：{{base_url}}/coupon/receive
  ├─ Method：POST
  ├─ Headers：Content-Type、Authorization
  ├─ Body：{ userId, couponTemplateId }
  ├─ Pre-request Script：先登录拿 token
  ├─ Tests：
  │   ├─ 断言：状态码 200
  │   ├─ 断言：返回 couponId
  │   └─ 动作：存 couponId 到环境变量 + 调退回券接口
  └─ 状态：✅ 通过（最近一次跑）

这一条用例 = 一个可重复运行、可自动判结果、不依赖残留数据的测试。这才是 Postman 自动化的最小单元。

三步法心法回顾

搭工作台 ------Collection 装请求、Environment 装配置、请求里只用 {{变量}}
存请求模板------能跑通的必 Save，附 Description
写断言------没断言的请求不算测试；Pre-request 造前置、Tests 断结果 + 传数据 + 清理

一句话心法：Postman 的价值不在 Send 按钮，在 Tests 脚本和变量串联------把它从"图形化 curl"升级成"接口自动化工作台"。

三个常见误区

误区一：只点 Send，不 Save。请求关掉就没了，下个迭代要重填。把"能跑通的请求"沉淀成模板，是自动化的起点。

误区二：只发请求不写断言 。跑完看一眼响应没问题就关掉------这是手动测试，不是自动化。没有断言，就没有自动化可言。

误区三：把 Postman 当"个人工具"，不组织 Collection 。所有请求平铺，三个月后自己都找不到。Collection 按"业务模块"分文件夹，每个文件夹下放该模块的所有接口------这是后续做"按模块回归"的基础。

写在最后

这一篇是新系列的开篇，核心只做了一件事：把 Postman 从"图形化 curl"升级成"接口自动化工作台"。

入口就是三步：搭工作台、存请求模板、写断言。Pre-request 和 Tests 脚本是让用例"自给自足"的关键------自己造前置、自己断结果、自己传数据、自己清理。

下一篇讲《环境变量与 Pre-request Script：接口串联的骨架》------多个接口怎么串成一条链路？领券 → 加购物车 → 下单 → 支付，怎么让上一个接口的输出自动变成下一个接口的输入？这就是变量串联的功夫。关注一下，咱们接着把这个系列往下推。