Postman + Newman 接口自动化回归实战：把手工点测变成每日自动巡检

场景背景

我们组维护一套自研的设备管理后台，后端是 ASP.NET WebAPI，前端有 APP、小程序、Web 三个端。每次发版前，测试同学都要手工把 40 多个接口挨个点一遍：改参数、看状态码、对返回结构。一轮下来 40 分钟，还经常漏测——最惨的一次是登录接口改了 token 有效期，回归时漏测了"刷新 token"分支，上线第二天用户集体掉线。

后来我把整套流程用 Postman + Newman 搬进 Jenkins，每天早 8:00 自动跑一遍全量回归，失败自动发邮件。这篇文章完整记录落地过程。



第一步：把手工点测沉淀成 Collection

最关键的一步不是工具，而是"把测试用例从人脑里挪出来"。原则是按业务域分组，而不是按接口路径：

DeviceAPI/
├── 认证
│   ├── 登录成功
│   ├── 登录-密码错误
│   └── 刷新 token
├── 设备
│   ├── 查询设备列表（分页）
│   ├── 新增设备
│   └── 删除设备-无权限
└── 数据
    └── 查询历史数据（时间区间）

每个请求在 Postman 里配好 环境变量，绝不写死域名和 token：

javascript
// Postman 的 Pre-request Script（集合级别，所有请求继承）
pm.environment.set("ts", Date.now());
pm.environment.set("sign", CryptoJS.MD5(
    pm.environment.get("appKey") + pm.environment.get("ts")
).toString());

javascript
// Tests 脚本：登录成功后把 token 存进环境变量，后续请求自动复用
pm.test("登录返回 200", function () {
    pm.response.to.have.status(200);
});
const body = pm.response.json();
if (body.data && body.data.token) {
    pm.environment.set("token", body.data.token);
    pm.test("token 非空", function () {
        pm.expect(body.data.token).to.be.a("string").and.not.empty;
    });
}

这一步的收益立刻可见：改一次环境变量，40 个请求全部跟着切环境，不用逐个改 URL。

第二步：用数据驱动跑参数化用例

"新增设备"这一个接口，要覆盖正常、必填缺失、超长名称、重复 SN 四类输入。手工点就是四遍，用 Postman 的 Collection Runner 一次跑完：

json
[
  { "case": "正常新增",   "devName": "测试设备A", "sn": "SN1001", "expect": 200 },
  { "case": "缺少名称",   "devName": "",          "sn": "SN1002", "expect": 400 },
  { "case": "名称超长",   "devName": "XXXXXXXX…(129字符)", "sn": "SN1003", "expect": 400 },
  { "case": "SN 重复",    "devName": "测试设备D", "sn": "SN1001", "expect": 409 }
]

请求体用变量占位，断言里读 expect 字段：

javascript
// Tests 脚本：断言状态码与数据文件里的期望值一致
const expectCode = parseInt(pm.iterationData.get("expect"));
pm.test(pm.iterationData.get("case") + " → 期望 " + expectCode, function () {
    pm.response.to.have.status(expectCode);
});

第三步：Newman 落地到 CI，每天自动巡检

Postman 里的 Collection 导出成 device-api.postman_collection.json，环境导出成 dev.postman_environment.json，放进代码仓库的 tests/ 目录。然后用 Newman 在命令行跑：

bash
# 本地先跑通
newman run tests/device-api.postman_collection.json \
       -e tests/dev.postman_environment.json \
       -d tests/cases/add-device.json \
       --reporters cli,htmlextra \
       --reporter-htmlextra-export reports/api-report.html \
       --timeout-request 10000 \
       --delay-request 200

放进 Jenkins 就是一个每天定时的 Pipeline：

groovy
pipeline {
    agent any
    triggers { cron('H 8 * * *') }        // 每天 08:00 自动巡检
    stages {
        stage('接口回归') {
            steps {
                sh 'npm install -g newman newman-reporter-htmlextra'
                sh 'newman run tests/device-api.postman_collection.json ' +
                   '-e tests/dev.postman_environment.json ' +
                   '--reporters cli,htmlextra ' +
                   '--reporter-htmlextra-export reports/api-report.html'
            }
        }
    }
    post {
        failure {
            emailext to: 'dev-team@company.com',
                     subject: "【接口回归失败】${env.BUILD_NUMBER}",
                     body: '详情见附件 HTML 报告'
        }
    }
}

实测对比

同一套 40 个接口的回归：

手工点测（1 人）                        : 约 40 分钟 / 轮，且不可重复
Postman Collection Runner（本地参数化） : 约  3 分钟 / 轮
Newman + Jenkins（每日定时 + 邮件）     :  0 人工，失败才介入

真正的价值不在"快了 13 倍"，而在于回归变得可信且可重复：同一份用例，谁跑、哪天跑，结果都一样。

踩过的坑

Newman 默认不校验 HTTPS 证书，内网自签证书没问题，但生产巡检要加 --ssl-client-cert 或干脆用域名白名单，否则证书过期你都发现不了。

环境变量的作用域要分清：environment（每个环境一套）和 globals（全局共享）混用会让 token 在并行跑多个环境时串号。我们的约定是只用一个 environment，绝不用 globals。

断言里不要只判 HTTP 200。业务错误也可能返回 200 包一个 {code: 500}，一定要同时断言 body.code。我们就因为这个漏过一个"查询返回空列表"的 bug。

CI 上跑要加 --delay-request，否则并发的请求会撞上后端的限流，出现一堆伪失败。

小结

接口自动化不是"上个工具"就完事，核心是把隐性的测试知识显性化成可执行、可版本管理的资产。Collection 进 Git、Environment 进 Git、用例数据进 Git，接口回归才真正从"看人"变成"看流水线"。
接口测试PostmanNewmanCI自动化