先说我踩的坑：300个接口手动测到凌晨2点

2024年4月，我们后台服务从单体拆微服务，接口从80个涨到300+。我还在用Postman最原始的用法：手点、复制token、手动替换路径参数、看着响应猜逻辑。

那周发版本，我测核心交易链路的接口，测到凌晨2点。眼花了，把的订单号复制到了<生产环境>的充值接口上。结果是线上产生了一笔测试订单，被业务方投诉。

复盘原因就三条：

• 环境变量全靠手动改，一不留神就从sandbox切到了prod
• 请求签名每次要手算，在代码里查半小时才能拼对
• 接口依赖关系（A的响应是B的请求体）靠人肉复制

后来我用三个月时间把整套API测试流程重做了一遍。下面是完整方案，工具版本：Postman 11.1.0（桌面版）、Insomnia 10.0.0（桌面版）、Newman 6.1.2、Inso CLI 4.0.0。

两条路线对比：Postman还是Insomnia

先横向比一下这两个工具的定位差异，这决定你选哪条路。

维度	Postman 11.1	Insomnia 10.0
请求生命周期钩子	pre-request script + tests（两个阶段）	pre-request + on-response（两个阶段，对应Postman的tests）
脚本语言	JavaScript（内置postman对象，沙箱环境）	JavaScript（内置insomnia对象，Node.js运行时）
环境变量管理	global + environment + collection，支持继承和动态变量	Environment + Tag，按文件夹隔离，支持子环境继承
Runner	Collection Runner（GUI） + Newman（CLI）	Run Collection（GUI） + Inso CLI + Jest式断言
YAML/OpenAPI导入	支持，但细粒度控制一般	原生支持OpenAPI 3.0，导入即生成文件夹结构
离线性	需要登录，偶尔同步慢	完全本地，可离线

我的结论：

• 如果你们团队已经有Postman的Collection资产，且要求CLI跑回归，选Postman + Newman，生态最成熟，网上案例最多，遇到问题容易搜到解法。
• 如果你们从零开始，又没有强制登录的需求，选Insomnia。它原生支持OpenAPI导入，环境变量隔离更干净，Inso CLI运行速度快，内存占用稳定在80MB左右，而Postman桌面版经常吃到500MB。

下面两条路线的代码实现都给你，你按需取用。

方案一：Postman 11 + Newman 6 完整落地

1. 环境变量体系：全局变量 + 环境组

Postman的变量作用域从上到下是：global（全局） → collection（集合） → environment（环境） → data（本地数据文件）。我用两层就够：全局放常量，环境放差异变量。

在Postman中，点击左下角「环境管理」，创建以下配置：

// 全局变量（global）：所有环境共享
base_url_scheme: https
api_version: v1
timeout_ms: 30000

// 环境：sandbox
env_name: sandbox
base_url_host: api.sandbox.example.com
merchant_id: sandbox_merchant_001
app_key: sandbox_app_key_8f8f
app_secret: sandbox_secret_3f3f

// 环境：production
env_name: production
base_url_host: api.example.com
merchant_id: prod_merchant_009
app_key: prod_app_key_5f5f
app_secret: prod_secret_8b8b

注意：app_secret永远不要写死在请求里。我们用的是签名机制，secret只参与签名计算，不传明文。具体见下一步。

2. pre-request Script：每次请求自动做签名+动态参数

这是Postman的核心玩法。在Collection根目录添加pre-request script，这样下面所有请求都会自动执行签名逻辑，无需每个请求单独配置。

// Postman Collection 级别的 Pre-request Script
// 运行环境：Postman 11.x Sandbox (基于Node.js 18)
// 功能：自动生成sign、timestamp、nonce，注入请求头

// 只在第一次发送时生成nonce，重试时复用
if (!pm.variables.get('nonce')) {
    // 生成32位随机nonce
    const nonce = require('crypto').randomBytes(16).toString('hex');
    pm.variables.set('nonce', nonce);
}

// timestamp：秒级时间戳
const timestamp = Math.floor(Date.now() / 1000).toString();
pm.variables.set('timestamp', timestamp);

// 读取环境变量里的app_secret（不参与网络传输）
const appSecret = pm.environment.get('app_secret');
if (!appSecret) {
    throw new Error('缺少app_secret环境变量，请检查当前环境配置');
}

// 从请求中提取原始路径（不做URL解码）
const path = pm.request.url.getPath();
// 从请求中提取查询参数（排除sign本身）
const queryParams = pm.request.url.query.all();
const filteredParams = queryParams.filter(p => p.key !== 'sign' && p.key !== 'nonce' && p.key !== 'timestamp');
// 排序后拼接
filteredParams.sort((a, b) => a.key.localeCompare(b.key));
let paramString = filteredParams.map(p => `${encodeURIComponent(p.key)}=${encodeURIComponent(p.value)}`).join('&');

// 拼接签名原文：HTTP方法 + 路径 + 查询参数串 + timestamp + nonce + secret
const signString = `${pm.request.method}\n${path}\n${paramString}\n${timestamp}\n${nonce}\n${appSecret}`;
const fs = require('fs');
// 计算MD5签名
const crypto = require('crypto');
const sign = crypto.createHash('md5').update(signString, 'utf8').digest('hex').toUpperCase();

// 注入请求头
pm.request.headers.upsert({
    key: 'X-Timestamp',
    value: timestamp
});
pm.request.headers.upsert({
    key: 'X-Nonce',
    value: nonce
});
pm.request.headers.upsert({
    key: 'X-Sign',
    value: sign
});

// 日志：便于调试签名问题
console.log('签名原文:', signString);
console.log('生成的sign:', sign);

3. Logic 依赖：把上一个请求的响应自动塞进下一个请求

接口之间有依赖，比如创建订单要返回orderId，然后支付接口需要orderId。传统做法是复制粘贴，我们改用脚本自动读取。

在Collection根目录tests脚本里做公共后处理：

// Collection 级别的 Tests 脚本
// 当订单创建成功时，自动提取orderId并存入环境变量
// 这样后续所有请求都能直接引用{{orderId}}，省去手动复制

// 检查当前请求是否是创建订单接口
if (pm.request.url.getPath().includes('/orders') && pm.request.method === 'POST') {
    const jsonData = pm.response.json();
    if (jsonData.code === 0 && jsonData.data && jsonData.data.order_id) {
        pm.environment.set('orderId', jsonData.data.order_id);
        console.log('已自动捕获orderId:', jsonData.data.order_id);
    } else {
        console.error('创建订单失败，响应body:', JSON.stringify(jsonData));
    }
}

// 用户登录接口自动保存token
if (pm.request.url.getPath().includes('/auth/login') && pm.request.method === 'POST') {
    const jsonData = pm.response.json();
    if (jsonData.data && jsonData.data.token) {
        pm.environment.set('authToken', jsonData.data.token);
        // 自动给后续请求设置Authorization头
    }
}

设置了之后，你在别的请求的Header或者Body里直接用{{orderId}}、{{authToken}}这样的变量名。Postman会在发送前自动填充。

4. 断言：Tests脚本里沉淀逻辑

只测HTTP 200远远不够。我的建议是每个接口至少做四类断言：状态码、业务码、关键字段非空、响应时效。

// Postman 请求级 Tests 脚本（可直接复制）
// 用途：标准响应结构断言模板

// 1. HTTP状态码断言
pm.test('HTTP状态码应为200', function () {
    pm.response.to.have.status(200);
});

// 2. 响应时间断言（超过800ms告警）
pm.test('响应时间应小于800ms', function () {
    pm.expect(pm.response.responseTime).to.be.below(800);
});

// 3. 业务码断言（假定结构 {code, message, data}）
const jsonData = pm.response.json();
pm.test('业务码应为0', function () {
    pm.expect(jsonData.code).to.eql(0);
});

// 4. 关键字段断言（按接口修改field名）
pm.test('返回data不为空', function () {
    pm.expect(jsonData.data).to.not.be.undefined;
});
// 常见额外断言：
// 列表接口容量断言
// pm.test('列表长度>0', function() {
//     pm.expect(jsonData.data.items.length).to.be.greaterThan(0);
// });
// 金额精度断言（避免科学计数法）
// pm.test('金额为2位小数', function() {
//     pm.expect(String(jsonData.data.amount)).to.match(/^\d+\.\d{2}$/);
// });

5. Collection Runner 全量回归

在Postman里点击Runner，选择Collection，选数据文件（可选），设置iteration为1。记得勾选「Keep variable values」防止跑完把环境变量给清了。

Production环境跑回归前，我建议把Runner的「Delay」设置一个300ms，避免接口被限流。sandbox环境不需要。

6. Newman 6 接入CI：命令行跑集合

Newman是Postman的命令行Runner。我们在Jenkins流水线里跑回归，产出JUnit报告和HTML报告。

#!/bin/bash
# 该脚本在Jenkins Agent上执行，实现API回归自动化
# Newman版本：6.1.2
# 安装命令：npm install -g newman newman-reporter-html newman-reporter-junit

# 定义变量
COLLECTION_FILE="api-regression.postman_collection.json"
ENV_FILE="production.postman_environment.json"
REPORT_DIR="./api-test-reports"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
mkdir -p $REPORT_DIR

# 执行newman，-n代表迭代次数（这里跑2轮，第一轮warmup缓存，第二轮正式计数据）
newman run "$COLLECTION_FILE" \
    -e "$ENV_FILE" \
    -n 2 \
    --delay-request 300 \
    --timeout-request 5000 \
    --timeout-script 10000 \
    --suppress-exit-code 1 \
    --reporters junit,html,cli \
    --reporter-junit-export "$REPORT_DIR/junit_$TIMESTAMP.xml" \
    --reporter-html-export "$REPORT_DIR/report_$TIMESTAMP.html"

# 输出结果
EXIT_CODE=$?
if [ $EXIT_CODE -eq 0 ]; then
    echo "✅ API回归全部通过"
else
    echo "❌ API回归存在失败用例，请查看报告 $REPORT_DIR/report_$TIMESTAMP.html"
    exit $EXIT_CODE
fi

注意：--suppress-exit-code 1这个参数很关键。默认Newman只要有一个断言挂了，进程退出码就是1，直接导致Jenkins构建失败。加上这个参数后，即使有失败，Newman也返回0，但报告里会标记失败。这样你可以先看报告再决定是否要阻断发布，而不是盲目阻断。

7. 效果数据（Postman方案实测）

我们原本是纯手动测试300个接口，耗时约45分钟。用上面这套方案之后，Newman跑全量300个接口，耗时6分58秒。

指标	手动测试	Newman自动化	提升
全量接口耗时	45分钟 ± 5分	6分58秒	快84.5%
环境变量错误	每轮平均2-3次	0次	100%消除
签名错误	每轮1-2次	0次（脚本自动算）	100%消除
遗漏断言	30%接口无断言	100%接口有断言	全覆盖

有一次我的断言配错了字段名（把order_id写成了orderId），Newman在回归时直接抓出来了。行吧，自动化测试的价值不是省时间，是让错误尽早暴露。

方案二：Insomnia 10 + Inso 4 落地

Insomnia的用户体验我个人觉得比Postman干净，左树右编辑区，没有社区噪音。核心差异是脚本生命周期等价，但语法有些区别。

1. 环境与标签：用Tag做环境隔离

Insomnia用环境标签（Environment Tag）来做变量管理。创建环境时，左上角选「Manage Environments」，点击「Create」，写JSON：

# Insomnia 环境配置
# Base Environment（全局）
{
  "base_url_scheme": "https",
  "api_version": "v1"
}

# Sub Environment: sandbox
{
  "env_name": "sandbox",
  "base_url_host": "api.sandbox.example.com",
  "merchant_id": "sandbox_merchant_001",
  "app_key": "sandbox_app_key_8f8f",
  "app_secret": "sandbox_secret_3f3f"
}

# Sub Environment: production
{
  "env_name": "production",
  "base_url_host": "api.example.com",
  "merchant_id": "prod_merchant_009",
  "app_key": "prod_app_key_5f5f",
  "app_secret": "prod_secret_8b8b"
}

在请求编辑区，地址栏输入{{ base_url_scheme }}://{{ base_url_host }}/api/{{ api_version }}/orders，Insomnia会自动补全。

2. pre-request Script（Insomnia语法）

Insomnia的pre-request script和Postman不同，它用的是insomnia全局对象，脚本本身跑在Node.js环境，所以require是可以直接用的。但是有个重要区别：Insomnia不支持pm.request.headers.upsert这种API，你要用insomnia.request.addHeader。

// Insomnia 10 pre-request script
// 功能：自动生成签名请求头

// 获取当前请求的原始路径
const request = insomnia.request;
const path = request.url.getPath();
// 获取查询参数
const queryParams = request.url.getQueryString();
const params = new URLSearchParams(queryParams);

// 移除sign和timestamp自身，避免签名递归
params.delete('sign');
params.delete('timestamp');
params.delete('nonce');

// 排序
const sortedKeys = Array.from(params.keys()).sort();
let paramString = sortedKeys.map(key => `${encodeURIComponent(key)}=${encodeURIComponent(params.get(key))}`).join('&');

// 从当前环境读取app_secret
const appSecret = insomnia.environment.get('app_secret');
if (!appSecret) {
    throw new Error('app_secret不存在，请检查环境');
}

const timestamp = Math.floor(Date.now() / 1000).toString();
const nonce = require('crypto').randomBytes(16).toString('hex');

// 摘要算法同上
const signString = `${request.method}\n${path}\n${paramString}\n${timestamp}\n${nonce}\n${appSecret}`;
const crypto = require('crypto');
const sign = crypto.createHash('md5').update(signString, 'utf8').digest('hex').toUpperCase();

// 添加请求头
insomnia.request.addHeader({
    name: 'X-Timestamp',
    value: timestamp
});
insomnia.request.addHeader({
    name: 'X-Nonce',
    value: nonce
});
insomnia.request.addHeader({
    name: 'X-Sign',
    value: sign
});
console.log('sign原文:', signString);
console.log('sign结果:', sign);

3. on-response 自动化：保存token和依赖数据

// Insomnia 10 on-response 脚本
// 功能：自动提取登录token + 订单号

// 获取响应体
const response = insomnia.response;
const statusCode = response.status;
// 注意：Insomnia的bodyText可能是个Promise，需要用async
(async () => {
    const bodyText = await response.body.getBody();
    const jsonData = JSON.parse(bodyText.toString('utf8'));
    
    // 自动提取token
    if (insomnia.request.url.includes('/auth/login')) {
        if (jsonData.data && jsonData.data.token) {
            insomnia.environment.set('authToken', jsonData.data.token);
            console.log('token已保存到环境变量');
        }
    }
    
    // 自动提取orderId
    if (insomnia.request.url.includes('/orders') && insomnia.request.method === 'POST') {
        if (jsonData.data && jsonData.data.order_id) {
            insomnia.environment.set('orderId', jsonData.data.order_id);
            console.log('orderId已保存:', jsonData.data.order_id);
        }
    }
    
    // 通用业务断言
    if (jsonData.code !== 0) {
        console.error('业务返回错误:', jsonData.message);
    }
})();

4. 用Inso CLI跑回归

#!/bin/bash
# Inso CLI 4.0.0 运行 Insomnia 集合
# 安装：npm install -g insomnia-inso
# 需要先导出设计文档为本地文件，或者使用--src指定远端API

# Inso使用工作区级别的设计文档
# 导出collection: inso collection:export "认证中心" -o ./auth-suite.yaml

INSPEC_ID="api-regression"  # 这里是你在Inso中定义的Collection名

inso run collection "$INSPEC_ID" \
    --env production \
    --request-timeout 5000 \
    --concurrency 4 \
    --verbose \
    --report junit --output ./insomnia-reports/

注意：Inso要求collection先用design模式创建，然后在文档右上角点击「Generate Collection」。直接在调试页签里手写的请求是没法用inso run collection跑的，只能跑OpenAPI生成的那些。

5. Insomnia效果数据

指标	Insomnia + Inso
全量接口耗时（300个）	5分40秒
内存占用	稳定在85MB左右
启动速度	2秒（vs Postman 7秒）

速度快的部分原因是Inso是Node.js CLI，没有浏览器内核拖累。如果你要跑更大量级的压力测试，这个优势会更明显。

进阶技巧：Test Data 数据驱动

很多时候响应断言取决于输入参数。最简单的例子：测试创建订单接口，需要传入不同的金额（0元、负数、超大数），每个case期望结果不同。手工造二十组数据在Collection里堆Request不现实，数据驱动是正解。

Postman 数据驱动做法

// 数据文件: test_data.json
// 与Collection Runner的"Data"选项对应
[
  {
    "case_name": "正常订单",
    "amount": 100,
    "expected_code": 0
  },
  {
    "case_name": "金额为0",
    "amount": 0,
    "expected_code": 20001
  },
  {
    "case_name": "金额为负",
    "amount": -5,
    "expected_code": 20001
  },
  {
    "case_name": "金额超限",
    "amount": 99999999,
    "expected_code": 20002
  }
]

然后在Tests脚本里这么写：

// Postman Tests脚本（数据驱动模式）
// 结合Runner导入的data文件，用data.xxx引用当前行的字段
pm.test(`业务码验证 - ${data.case_name}`, function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.code).to.eql(data.expected_code);
});

pm.test(`金额回显验证 - ${data.case_name}`, function () {
    const jsonData = pm.response.json();
    if (data.expected_code === 0) {
        pm.expect(jsonData.data.amount).to.eql(data.amount);
    }
});

跑Runner时，选上这个JSON文件，迭代次数会自动变成4。每条数据的报告会单独展示case_name。

Insomnia 数据驱动做法

Insomnia没有内置的数据文件选项。我们做法是写一个Node.js脚本，在脚本里循环调用Inso CLI，每次传入不同的环境变量。

// insomnia-data-drive.js
// 用Node.js驱动Inso跑多组数据
// 执行方式: node insomnia-data-drive.js

const { execSync } = require('child_process');
const datasets = [
    { amount: 100, expectedCode: 0, name: 'normal' },
    { amount: 0, expectedCode: 20001, name: 'zero' },
    { amount: -5, expectedCode: 20001, name: 'negative' },
    { amount: 99999999, expectedCode: 20002, name: 'exceed' }
];

let failedCount = 0;
for (const ds of datasets) {
    const cmd = `inso run collection "api-regression" --env production --var amount:${ds.amount} --var expected_code:${ds.expectedCode}`;
    console.log(`\n===== 执行用例: ${ds.name} =====`);
    try {
        execSync(cmd, { stdio: 'inherit', shell: '/bin/bash' });
        console.log(`✅ ${ds.name} 通过`);
    } catch (error) {
        failedCount++;
        console.error(`❌ ${ds.name} 失败`);
    }
}
console.log(`\n完成，失败数: ${failedCount}/${datasets.length}`);

避坑指南（这五个坑我都踩过）

坑1：Postman的沙箱不完整支持Node.js API。在pre-request script里，fs.writeFileSync是可以用的，但读文件只能用require('fs')之后路径要写相对路径。我在Windows上用过绝对路径直接EOF错误，因为沙箱里fs的cwd指向Postman安装目录，不是你的工作目录。解决办法：用pm.environment.set('filePath', 'C:/test/data.json')然后脚本里const rawData = pm.helpers.readFile(pm.variables.get('filePath'))这是pm.helpers暴露的专用方法。

坑2：Newman的--env-var优先级高于环境文件。如果你想在Jenkins里临时覆盖某个变量，用--env-var "base_url_host=test-internal.example.com"，但注意这个值只对当次运行生效。问题在于环境文件里同名变量不会报错，而是被静默覆盖。我踩过的是：Jenkins环境变量里写了一个旧的app_secret，覆盖了环境文件里的新secret，导致所有请求签名401。排查了半小时。解法：在Newman跑的时候加--bail参数，遇到第一个失败就停，快速定位。

坑3：Postman的变量替换发生在脚本执行之前还是之后？这问题坑了我两次。答案：请求头里写的{{variable}}是在pre-request script结束后进行替换的。所以如果你在pre-request script里pm.environment.set('authToken', xxx)，然后请求头里写Authorization: Bearer {{authToken}}，这个变量能取到，因为pre-request script先执行。但是反过来，如果你在pre-request script里用pm.request.headers.add添加了一个headers，那这个headers还没有被变量替换。需要手动调用pm.variables.replaceIn()手动替换。这是很多人不知道的。

// 在pre-request script里手动完成变量替换
// 场景：动态添加Header时必须主动替换变量
const headerValue = 'Bearer {{authToken}}';
const replacedValue = pm.variables.replaceIn(headerValue);
pm.request.headers.add({
    key: 'Authorization',
    value: replacedValue
});

坑4：Insomnia的脚本执行是异步的。在on-response脚本里，如果你在脚本中await一个Promise，脚本顶层的return不会停止整个脚本的执行。我在做「请求失败时自动重试」的时候，把重试逻辑写在on-response里，结果因为异步时序问题，重试请求跑了2次。解法：在on-response脚本中，尽量用同步方式，或者用顶层async IIFE把所有逻辑包起来，然后用一个标志位防止重复执行。如下：

// Insomnia on-response 避免异步重入的写法
if (insomnia.response.status === 500) {
    if (!insomnia.environment.get('_retried')) {
        insomnia.environment.set('_retried', 'true');
        // 重新发送请求
    }
}

坑5：测试环境与生产环境的隔离。最危险的操作就是在配置环境变量时，把base_url_host写错了。我给Postman的Environment加了一个「锁定」功能：在环境管理页面右上角点锁图标，可以防止环境变量被意外修改。但这只是UI层面的，Newman跑的时候还是会用文件里的值。所以我的终极方案是：在pre-request script里加一个硬保护：

// 终极保护：防止误操作生产环境
if (pm.environment.get('env_name') === 'production' && pm.request.url.getHost().includes('sandbox')) {
    throw new Error('检测到生产环境与sandbox URL混用，已阻止请求');
}
if (pm.environment.get('env_name') === 'sandbox' && pm.request.url.getHost().includes('api.example.com')) {
    throw new Error('检测到sandbox环境请求生产URL，已阻止请求');
}

这招一次就治好了我「从sandbox切换到生产手动改URL结果忘了改host」的毛病。

什么时候你该放弃Postman/Insomnia？

这套方法适合中小团队、API数量在千级以内、变更频率不高的场景。一旦你的接口数量到几千个，需要持续集成在每次代码提交时跑回归，并且要做复杂的参数组合生成，还是老老实实上自动化测试框架吧。我个人推荐用Python的pytest + requests，或者Java的RestAssured。工具类软件的价值在于快速启动、灵活调试，一旦你的需求变成「持续构建 + 复杂数据流 + 断言复用」，脚本代码能提供更大的自由度。

但话说回来，如果你人肉测接口要花一下午，先花点时间把上面这套流程跑起来，收益绝对值得。