在接口测试里AIPostman 的组合正在把最耗时的用例生成和断言维护变成可自动化的环节。Postman 本身负责请求组织、环境变量、Tests 脚本和批量执行AI 则负责把接口描述快速转换成测试脚本、参数组合和边界场景。很多团队不是没有接口文档而是缺少把接口文档变成可运行测试资产的自动化链路。本文围绕这个链路从概念、环境、Prompt 设计、脚本生成、批量验证到排查给出一个可以照着落地的最小工程示例。下面会用到 Postman、大模型 API、本地 Mock 服务、Collection 脚本和 Newman 命令。读者最好已经用过 Postman 的基本请求调试但不需要会写复杂的测试脚本。文章最终目标是让读者完成一次“接口描述 - AI 生成用例和断言 - Postman 执行 - Newman 批量回归”的完整流程并理解每一步为什么要这样做。1. 先理解 Postman 接口自动化里最耗时的三个环节1.1 手工维护用例和断言的瓶颈接口测试在功能上并不复杂难的是维护成本。一个接口通常有正常返回、参数缺失、字段类型错误、无权限、数据不存在等场景。每个场景在 Postman 里都对应一个请求或一次数据驱动运行而每个请求的 Tests 标签里都要写断言。如果完全手工维护会出现三种情况断言只写了状态码 200接口字段发生变化时测试没有反应。同一个接口的正向用例和异常用例分散在不同 Collection 里维护时容易漏。接口数量达到几十个后光是浏览用例、确认断言是否需要更新就要花掉大量时间。AI 能介入的不是“测试设计思想”而是“从已有接口信息到可执行脚本”的转换过程。接口定义、响应示例、字段含义都在的话AI 可以稳定生成第一版脚本再由人来补充业务规则。1.2 Postman 在自动化回归里的职责边界Postman 在接口自动化体系中负责的是执行编排而不是用例设计。它的能力可以拆成四层Collection管理请求、文件夹、请求顺序和数据依赖。环境变量与 Collection 变量解决不同环境切换、参数传递、敏感信息外置。Pre-request Script 与 Tests 脚本负责造数、签名、断言和结果输出。Collection Runner 与 Newman负责批量运行、数据驱动和 CI 集成。AI 生成的测试脚本最终都要落到 Tests 标签和 Pre-request Script 标签里。也就是说AI 不能替代 Postman 的执行模型但可以极大缩短脚本编写时间。1.3 AI 在 Postman 流程中的三个切入点实际项目里AI 可以从三个位置介入请求用例生成根据接口路径、参数、请求体示例生成正反向请求参数组合。断言脚本生成根据接口响应示例生成状态码、业务码、字段存在性、字段类型、数组边界等断言。脚本排错与解释当 Postman 执行失败把响应体、脚本和错误日志交给 AI让 AI 给出可能原因和修改建议。Postman 新版本内置的 AI 助手可以针对当前请求生成测试脚本本质上也是把请求信息送给大模型。如果当前账号没有相关功能或者团队需要统一管理 Prompt可以直接调用大模型 API 来生成脚本。2. 环境准备Postman、本地接口服务和大模型 API2.1 Postman 安装与运行环境检查先从 Postman 官网下载对应系统的安装包安装后打开建议登录账号。登录主要是为了同步 Collection纯本地调试即使不登录也能创建请求但部分功能会受限。运行前确认三件事能正常发送 HTTP 请求到外网或内网测试环境。能创建 Collection、Environment 和 Request。能打开 Tests 标签页编写脚本。Postman 官方版本界面默认是英文。网上流传的汉化包大多来自第三方版本升级后很容易失效不建议在正式环境使用第三方汉化包。英文界面里的 Collection、Environment、Tests 这几个词识别清楚后面操作基本没有障碍。2.2 准备一个本地 Mock 接口服务为了演示 AI 生成用例和断言需要一个响应结构稳定的服务。这里用 Node.js 写一个最小接口服务读者可以自己搭也可以换成团队已有的测试接口。先初始化项目并安装 Expressmkdir ai-postman-demo cd ai-postman-demo npm init -y npm install express创建server.jsconst express require(express); const app express(); app.use(express.json()); const users [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin }, { id: 2, name: 李四, email: lisiexample.com, role: user } ]; app.get(/api/users, (req, res) { res.json({ code: 0, data: users }); }); app.get(/api/users/:id, (req, res) { const user users.find(u u.id Number(req.params.id)); if (!user) { return res.status(404).json({ code: 404, message: 用户不存在 }); } res.json({ code: 0, data: user }); }); app.post(/api/users, (req, res) { const { name, email, role } req.body || {}; if (!name || !email) { return res.status(400).json({ code: 400, message: name 和 email 为必填项 }); } const user { id: Date.now(), name, email, role: role || user }; users.push(user); res.status(201).json({ code: 0, data: user }); }); app.listen(3000, () { console.log(mock api running at http://localhost:3000); });启动服务node server.js先用 curl 验证接口可访问curl http://localhost:3000/api/users curl -X POST http://localhost:3000/api/users \ -H Content-Type: application/json \ -d {name:王五,email:wangwuexample.com}正常情况下列表接口返回用户数组创建接口返回 201 状态码。这个服务只做演示没有加鉴权和持久化。生产项目里要造测试数据时建议使用独立测试库避免污染真实数据。2.3 大模型 API 调用方式AI 生成脚本有两种落地方式在 Postman 内置 AI 助手里直接触发。使用大模型 API把接口描述发给模型拿到脚本后粘贴或写回 Collection JSON。第二种更通用也方便批量处理多个接口。先确认项目能访问哪个大模型 API不同平台的接口格式有差异但基本都包含 model、messages、apiKey 这几个要素。需要设置两个环境变量不要把密钥写死在脚本或提交到 Gitexport LLM_API_KEYyour-api-key export LLM_API_URLhttps://your-llm-api.example.com/v1/chat/completions下面的 curl 示例用来验证 API 是否可用curl $LLM_API_URL \ -H Content-Type: application/json \ -H Authorization: Bearer $LLM_API_KEY \ -d { model: your-model, messages: [ {role: system, content: 你只输出 Postman Tests 脚本不要解释。}, {role: user, content: 请为 GET /api/users 接口生成测试脚本。} ] }实际项目里需要把your-llm-api.example.com和your-model替换成当前可用服务的地址和模型名。如果公司内部有大模型网关直接用网关地址即可。3. 完成一次 AI 自动生成用例和断言的完整流程3.1 把接口信息整理成结构化输入AI 生成结果的质量首先取决于输入是否结构化。不要只写一句话让 AI “生成用户接口测试脚本”而是把请求方法、路径、请求头、请求体、响应示例、环境变量都写清楚。这里以获取用户列表接口为例整理成 JSON{ name: 获取用户列表, method: GET, url: {{baseUrl}}/api/users, headers: { Authorization: Bearer {{token}} }, responseExample: { code: 0, data: [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin } ] } }使用{{baseUrl}}和{{token}}而不是硬编码是为了让脚本在不同环境之间迁移。这样后续执行 Newman 时只需要切换环境文件。3.2 设计生成测试脚本的 Prompt给大模型的 Prompt 应该包含以下部分角色告诉模型它是 Postman 测试脚本工程师。接口定义完整提供接口信息。输出要求只输出脚本不解释。断言维度明确要求覆盖状态码、业务码、字段存在性、字段类型、数组长度等。技术约束只使用 Postman Sandbox 支持的语法不写 Node.js require不使用 mock 数据。示例 Prompt你是一名熟悉 Postman 的接口测试工程师。 下面是接口定义 - 请求方法: GET - 请求路径: {{baseUrl}}/api/users - 请求头: Authorization: Bearer {{token}} - 响应示例: { code: 0, data: [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin } ] } 请只输出 Postman 的 Tests 标签页可以运行的 JavaScript 脚本。 要求 1. 使用 pm.test 和 pm.expect。 2. 检查状态码为 200。 3. 检查响应中的 code 字段为 0。 4. 检查 data 是数组且非空。 5. 检查数组中每个元素都包含 id、name、email、role 字段。 6. 不使用 mock 数据变量只能使用 {{baseUrl}} 和 {{token}}。 7. 不要输出任何解释性文字。AI 生成的结果大致如下pm.test(状态码为 200, function () { pm.response.to.have.status(200); }); pm.test(业务码 code 为 0, function () { const json pm.response.json(); pm.expect(json.code).to.eql(0); }); pm.test(data 是非空数组, function () { const json pm.response.json(); pm.expect(json.data).to.be.an(array); pm.expect(json.data.length).to.be.greaterThan(0); }); pm.test(每个用户包含关键字段, function () { const json pm.response.json(); json.data.forEach(function (user) { pm.expect(user).to.have.property(id); pm.expect(user).to.have.property(name); pm.expect(user).to.have.property(email); pm.expect(user).to.have.property(role); }); });这段脚本可以直接粘贴到 Postman 请求的 Tests 标签页。如果模型返回的内容带有 Markdown 代码块标记粘贴前要去掉。3.3 把生成结果导入 Postman手工粘贴适合单个请求接口数量多时要考虑批量处理。比较常见的方式是维护一份 Postman Collection 的 JSON 文件然后用脚本把 AI 生成的结果写入对应的event[].script.exec字段。Collection JSON 结构里每个请求可以带一个测试事件{ info: { name: 用户接口, schema: https://schema.getpostman.com/json/collection/v2.1.0/collection.json }, item: [ { name: 获取用户列表, request: { method: GET, url: http://localhost:3000/api/users }, event: [ { listen: test, script: { type: text/javascript, exec: [ pm.test(状态码为 200, function () {, pm.response.to.have.status(200);, }); ] } } ] } ] }在上面的exec数组里每一行是一个字符串。AI 返回多行脚本时需要按换行拆分成数组。可以用 Node.js 写一个批量生成脚本遍历 Collection 的每一个请求调用大模型 API然后把返回内容写入exec。下面是一段用于说明思路的 Node.js 脚本实际使用时需要根据模型接口和 Collection 结构调整const fs require(fs); const collection JSON.parse(fs.readFileSync(user-api.postman_collection.json, utf-8)); async function generateTest(requestInfo) { const response await fetch(process.env.LLM_API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${process.env.LLM_API_KEY} }, body: JSON.stringify({ model: process.env.LLM_MODEL || your-model, messages: [ { role: system, content: 你只输出 Postman Tests 脚本不要解释。 }, { role: user, content: 请为以下接口生成测试脚本\n JSON.stringify(requestInfo) } ] }) }); const data await response.json(); return data.choices[0].message.content; } (async () { for (const item of collection.item) { const requestInfo { name: item.name, method: item.request.method, url: typeof item.request.url string ? item.request.url : item.request.url.raw }; const script await generateTest(requestInfo); item.event [ { listen: test, script: { type: text/javascript, exec: script.split(\n) } } ]; } fs.writeFileSync(generated-collection.json, JSON.stringify(collection, null, 2), utf-8); })();这个脚本没有处理模型返回异常、脚本长度超限、请求头传递等情况只适合作为批量生成的起点。生产环境使用前需要补上重试、日志、失败补偿和人工审批环节。3.4 用 Collection Runner 和 Newman 批量验证生成脚本后先手动发送一次请求查看 Tests 标签页里的测试结果。确认无误后再跑批量。Postman 里的 Collection Runner 可以选中 Collection 或某个 Folder选择环境点击 Run。大规模回归时更推荐使用 Newman。Newman 是 Postman Collection 的命令行运行器可以直接进入 CI 流程。安装并运行npx newman run generated-collection.json \ -e test.postman_environment.json \ --reporters cli,json \ --reporter-json-export newman-report.jsontest.postman_environment.json是环境文件内容大致如下{ name: test, values: [ { key: baseUrl, value: http://localhost:3000, enabled: true }, { key: token, value: test-token, enabled: true } ] }Newman 运行结束后会在终端输出每个请求的断言结果。JSON 报告可以交给 Jenkins、GitLab CI 或其他报告平台解析。注意不要只验证程序能启动还要验证断言是否真的生效。最简单的方法是故意把一个字段名改错确认测试失败再恢复成正确结果。4. 关键脚本拆解让 AI 生成的断言真正可维护4.1 pm.test 和 pm.expect 的基础关系Postman 的 Tests 标签运行在 Postman Sandbox 中语法以 JavaScript 为主。核心 API 是pm.test和pm.expect。pm.test接收两个参数第一个是测试名称第二个是断言函数。pm.expect来自 Chai.js 断言库支持链式调用。例如pm.test(响应时间低于 500ms, function () { pm.expect(pm.response.responseTime).to.be.below(500); });AI 生成脚本时容易出现的问题是它可能会生成 Node.js 服务端的语法比如require(assert)或者fetch搭配顶层 await。这些在 Postman 的脚本环境里不一定可用。所以在 Prompt 里必须限制“只使用 pm 对象和标准 JavaScript 语法”。4.2 让 AI 生成可维护断言的 Prompt 约束好的 Prompt 不是列一个接口而是把断言规范也传进去。下面这个表可以用来检查自己的 Prompt 是否完整Prompt 维度推荐做法容易出现的坑接口信息给 method、url、headers、body、response 示例只说接口名AI 只能猜测断言范围要求检查状态码、业务码、字段、类型、数组、错误分支只检查状态码断言形同虚设变量约束明确指出使用 {{token}}、{{baseUrl}}生成硬编码 token 或本机地址输出格式只输出 JavaScript 脚本不带解释输出带 Markdown 解释需要人工清理技术边界限制使用 Postman Sandbox 语法生成 Node.js 服务端代码运行报错异常覆盖要求考虑 4xx 和 5xx 场景只写正向用例异常场景靠手工补例如针对创建用户接口可以使用下面的 Prompt请为 POST /api/users 接口生成测试脚本。 请求体示例 { name: 测试用户, email: testexample.com, role: user } 响应示例 { code: 0, data: { id: 123, name: 测试用户, email: testexample.com, role: user } } 要求 1. 状态码为 201。 2. 业务码 code 为 0。 3. data.id 是数字。 4. data.name 等于请求体中的 name 字段。 5. 如果状态码为 400则检查响应中包含 message 字段。这样生成出来的脚本会更接近真实测试场景。4.3 参数化、环境变量和断言之间的关系断言脚本不是孤立存在的。请求中的数据来自环境变量、Collection 变量或数据文件断言也要根据这些输入做动态判断。创建用户的接口可以用数据文件里的expectedStatus作为期望值name,email,role,expectedStatus 张三,zhangsanexample.com,admin,201 ,missingexample.com,user,400 李四,lisiexample.com,,201Postman 使用数据文件运行时可以通过pm.iterationData读取当前行的数据pm.test(状态码符合数据文件预期, function () { const expectedStatus pm.iterationData.get(expectedStatus); pm.expect(pm.response.code).to.eql(expectedStatus); });这种数据驱动模式适合接口数量少但参数组合多的场景。AI 在这里的作用是生成 CSV 文件里需要的边界值组合而不是把每一个组合都写成一个独立请求。5. AI 生成结果不靠谱时的排查链路5.1 现象测试通过但断言没有真正生效最危险的情况不是测试失败而是测试通过了但断言根本没执行。检查方式打开 Postman 的 Console确认请求有没有发出。在 Tests 标签里加一个console.log(pm.response.json())。故意改错一个字段名例如把data改成data2看测试是否失败。如果测试仍然通过说明断言代码没被正确加载或者exec数组里的脚本被截断。原因通常是脚本粘贴时漏了行或者在 Collection JSON 的exec数组里没有按行正确拆分。AI 返回的代码块如果被整体当成一行某些 Postman 版本可能会执行异常。解决方案是统一采用“粘贴到 Tests 标签 - 手动发送一次 - 故意制造失败 - 恢复”的验证流程。5.2 现象AI 生成的脚本引用了不存在的变量Postman 在执行脚本时如果遇到{{token}}未定义不会直接报错而是把变量当作字符串传入。这样请求头就会变成Bearer {{token}}接口返回 401断言却还在检查 200。检查步骤查看请求右侧的变量名是否拼写正确。检查当前选择的环境是否正确。在 Console 里查看pm.environment.get(token)的值。如果是 Newman 执行检查是否传入了环境文件。在 Prompt 中最好明确写出允许使用的变量名。生成脚本后用文本搜索检查是否存在token、appId等硬编码值。5.3 现象同一个接口在不同环境执行结果不一致本地接口返回的数据是固定的但测试环境可能因为存量数据多导致断言data.length大于某个值失败或者返回了 null。这种情况下AI 生成的静态断言不能直接用到所有环境。需要把断言改成相对判断pm.test(data 为数组, function () { const json pm.response.json(); pm.expect(json.data).to.be.an(array); }); pm.test(分页字段符合规范, function () { const json pm.response.json(); if (json.data json.data.list) { pm.expect(json.data.list).to.be.an(array); pm.expect(json.data.pageNum).to.be.a(number); } });生产环境建议在 Prompt 里强调“不要断言具体的数据条数除非接口契约明确固定”。把易变数据从断言中排除只保留稳定的契约字段。5.4 排查优先级AI 生成脚本出问题时按照这个顺序排查最快接口本身是否通。先用 Postman 发送请求看响应是否符合预期。环境变量和变量名。检查 baseUrl、token 是否生效。脚本语法。打开 Console查看是否有 JavaScript 报错。断言逻辑。把断言拆成最小用例逐步确认哪一条失败。生成结果。检查 AI 是否遗漏了字段或者引入了不存在的变量。6. 接口测试中 AIPostman 的最佳实践6.1 明确 AI 负责什么人负责什么AI 适合做信息转换不适合做业务决策。接口字段变更、错误码含义、订单状态的流转规则这些必须由熟悉业务的人确认。建议的职责划分AI 负责根据接口文档生成第一版请求、脚本和参数组合。人负责确认断言是否覆盖核心业务规则。AI 负责生成的数据文件只作为候选不能直接用于生产数据造数。人负责把 AI 生成结果纳入代码评审和测试评审。6.2 维护接口描述文件收益大于维护脚本AI 生成脚本的质量取决于接口描述的质量。与其让 AI 猜接口字段不如维护一份 OpenAPI 或自定义 JSON 描述文件。接口描述文件至少包含请求方法、路径。请求头、请求体字段类型。响应示例。错误码含义。字段约束比如必填、长度、枚举值。接口描述文件还有一个好处当接口变更时可以重新生成脚本而不是逐个人工修改。这也让 AI 生成的脚本有了可重复执行的输入源。6.3 从学习环境到生产环境需要补齐的能力本地 Mock 服务只适合跑通流程生产环境的接口自动化还需要额外考虑维度学习环境生产环境数据固定 mock 数据独立测试库测试前后清理数据密钥本地环境变量密钥管理服务禁止明文入库执行手动点击 RunNewman 接入 CI定时触发报告看终端输出解析 JSON 报告推送失败通知回滚不需要脚本和 Collection 都需要版本管理监控不关注记录失败率、响应时间、错误分布注意Postman 脚本运行环境不是 Node.js很多服务端能力不可用。AI 生成的代码如果引用了path、fs、child_process都不能在 Tests 标签里运行。6.4 从单接口用例扩展到业务链路单接口断言只能证明独立接口正常不能证明业务链路正常。更可靠的做法是让请求之间传递数据。例如创建用户接口返回后把返回的id保存到环境变量下一个查询用户详情的请求直接用{{userId}}const json pm.response.json(); if (json.code 0 json.data json.data.id) { pm.environment.set(userId, json.data.id); }这种写法在 Collection Runner 中按顺序执行时非常有用。AI 生成单接口脚本时不会自动处理这种依赖需要人工在 Prompt 中补充“把创建接口返回的 id 保存到环境变量 userId”。7. 常见问题速查与可复用检查清单7.1 常见问题速查表问题现象常见原因检查方式处理建议测试通过但断言未执行exec脚本被截断或脚本语法错误被跳过Console 查看报错故意改错字段从 Postman UI 重新粘贴脚本并发送请求返回 401断言还在检查 200token 变量未设置或拼写错误检查环境变量和 Console 请求头修正变量名确认当前环境AI 脚本使用了require模型把 Postman 当成 Node.js 环境查看 Console 报错在 Prompt 中限制只使用 pm 对象断言过度依赖具体数据测试环境数据不稳定观察不同环境的执行结果把数据条数、ID 等改为相对判断Collection 导入后脚本丢失只导入了请求没有导出事件查看 Collection JSON 的 event 字段确认导出时包含 Tests 脚本Newman 运行找不到环境变量未指定环境文件检查命令行-e参数传入环境文件或使用--env-var7.2 AI 生成脚本前检查清单在把接口描述交给 AI 之前先过一遍这份清单[ ] 接口方法、路径、请求体字段是否完整。[ ] 响应示例是否包含正常返回和异常返回。[ ] 环境变量名是否确定例如 baseUrl、token。[ ] 是否列出了断言维度状态码、业务码、字段类型、数组边界。[ ] 是否正确区分了稳定字段和易变字段。[ ] 是否要求 AI 只输出脚本不输出解释文字。[ ] 是否要求 AI 不生成 mock 数据。7.3 发布到 CI 前的检查清单[ ] Collection 和环境文件已经提交到 Git不在 Git 中出现密钥。[ ] Newman 命令可以本地跑通并生成 JSON 报告。[ ] 至少有一个故意失败用例被验证过确认报告能捕捉失败。[ ] 测试数据具备独立性和可清理性不依赖共享库脏数据。[ ] 接口变更后重新生成脚本并经过人工评审而不是直接覆盖。8. 下一步扩展方向8.1 从请求级生成扩展到链路级生成现在 AI 生成的是单个请求的断言下一步可以让 AI 根据整条业务链路生成 Collection。比如“用户登录 - 创建订单 - 查询订单 - 支付回调”这种链路AI 需要理解接口之间的数据依赖。实现方式是提供每个接口的描述文件和字段映射规则让 AI 生成包含pm.environment.set的脚本。8.2 把 AI 生成的脚本纳入代码评审AI 生成脚本不是一次性产物。每次接口变更、响应结构调整后都应该重新生成并对比差异。有条件的话把 Collection JSON、Prompt 模板和接口描述文件放在同一个仓库里方便 Review。8.3 结合接口变更自动维护用例更成熟的方案是监听接口文档的变更事件自动触发 AI 重新生成受影响接口的测试脚本。比如 Swagger 文档里某个响应字段从 string 变成 number系统自动给测试人员生成一条待确认记录再由人确认是否更新断言。这样可以把 AI 从“单次提效工具”变成“持续维护用例的自动化环节”。AIPostman 不是银弹。它解决的是脚本编写和用例整理的低效问题但测试目标、接口契约、业务规则和异常场景的判断仍然需要人来完成。把这套流程跑通之后最大的收益是让接口测试从“每次手工改断言”变成“接口变了自动给出新脚本人只需要做确认”。 
长河君 · 2026/8/30 18:29:52 · 阅读 1.2k AI+Postman 自动化接口测试：从用例生成到批量回归的落地指南
在接口测试里AIPostman 的组合正在把最耗时的用例生成和断言维护变成可自动化的环节。Postman 本身负责请求组织、环境变量、Tests 脚本和批量执行AI 则负责把接口描述快速转换成测试脚本、参数组合和边界场景。很多团队不是没有接口文档而是缺少把接口文档变成可运行测试资产的自动化链路。本文围绕这个链路从概念、环境、Prompt 设计、脚本生成、批量验证到排查给出一个可以照着落地的最小工程示例。下面会用到 Postman、大模型 API、本地 Mock 服务、Collection 脚本和 Newman 命令。读者最好已经用过 Postman 的基本请求调试但不需要会写复杂的测试脚本。文章最终目标是让读者完成一次“接口描述 - AI 生成用例和断言 - Postman 执行 - Newman 批量回归”的完整流程并理解每一步为什么要这样做。1. 先理解 Postman 接口自动化里最耗时的三个环节1.1 手工维护用例和断言的瓶颈接口测试在功能上并不复杂难的是维护成本。一个接口通常有正常返回、参数缺失、字段类型错误、无权限、数据不存在等场景。每个场景在 Postman 里都对应一个请求或一次数据驱动运行而每个请求的 Tests 标签里都要写断言。如果完全手工维护会出现三种情况断言只写了状态码 200接口字段发生变化时测试没有反应。同一个接口的正向用例和异常用例分散在不同 Collection 里维护时容易漏。接口数量达到几十个后光是浏览用例、确认断言是否需要更新就要花掉大量时间。AI 能介入的不是“测试设计思想”而是“从已有接口信息到可执行脚本”的转换过程。接口定义、响应示例、字段含义都在的话AI 可以稳定生成第一版脚本再由人来补充业务规则。1.2 Postman 在自动化回归里的职责边界Postman 在接口自动化体系中负责的是执行编排而不是用例设计。它的能力可以拆成四层Collection管理请求、文件夹、请求顺序和数据依赖。环境变量与 Collection 变量解决不同环境切换、参数传递、敏感信息外置。Pre-request Script 与 Tests 脚本负责造数、签名、断言和结果输出。Collection Runner 与 Newman负责批量运行、数据驱动和 CI 集成。AI 生成的测试脚本最终都要落到 Tests 标签和 Pre-request Script 标签里。也就是说AI 不能替代 Postman 的执行模型但可以极大缩短脚本编写时间。1.3 AI 在 Postman 流程中的三个切入点实际项目里AI 可以从三个位置介入请求用例生成根据接口路径、参数、请求体示例生成正反向请求参数组合。断言脚本生成根据接口响应示例生成状态码、业务码、字段存在性、字段类型、数组边界等断言。脚本排错与解释当 Postman 执行失败把响应体、脚本和错误日志交给 AI让 AI 给出可能原因和修改建议。Postman 新版本内置的 AI 助手可以针对当前请求生成测试脚本本质上也是把请求信息送给大模型。如果当前账号没有相关功能或者团队需要统一管理 Prompt可以直接调用大模型 API 来生成脚本。2. 环境准备Postman、本地接口服务和大模型 API2.1 Postman 安装与运行环境检查先从 Postman 官网下载对应系统的安装包安装后打开建议登录账号。登录主要是为了同步 Collection纯本地调试即使不登录也能创建请求但部分功能会受限。运行前确认三件事能正常发送 HTTP 请求到外网或内网测试环境。能创建 Collection、Environment 和 Request。能打开 Tests 标签页编写脚本。Postman 官方版本界面默认是英文。网上流传的汉化包大多来自第三方版本升级后很容易失效不建议在正式环境使用第三方汉化包。英文界面里的 Collection、Environment、Tests 这几个词识别清楚后面操作基本没有障碍。2.2 准备一个本地 Mock 接口服务为了演示 AI 生成用例和断言需要一个响应结构稳定的服务。这里用 Node.js 写一个最小接口服务读者可以自己搭也可以换成团队已有的测试接口。先初始化项目并安装 Expressmkdir ai-postman-demo cd ai-postman-demo npm init -y npm install express创建server.jsconst express require(express); const app express(); app.use(express.json()); const users [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin }, { id: 2, name: 李四, email: lisiexample.com, role: user } ]; app.get(/api/users, (req, res) { res.json({ code: 0, data: users }); }); app.get(/api/users/:id, (req, res) { const user users.find(u u.id Number(req.params.id)); if (!user) { return res.status(404).json({ code: 404, message: 用户不存在 }); } res.json({ code: 0, data: user }); }); app.post(/api/users, (req, res) { const { name, email, role } req.body || {}; if (!name || !email) { return res.status(400).json({ code: 400, message: name 和 email 为必填项 }); } const user { id: Date.now(), name, email, role: role || user }; users.push(user); res.status(201).json({ code: 0, data: user }); }); app.listen(3000, () { console.log(mock api running at http://localhost:3000); });启动服务node server.js先用 curl 验证接口可访问curl http://localhost:3000/api/users curl -X POST http://localhost:3000/api/users \ -H Content-Type: application/json \ -d {name:王五,email:wangwuexample.com}正常情况下列表接口返回用户数组创建接口返回 201 状态码。这个服务只做演示没有加鉴权和持久化。生产项目里要造测试数据时建议使用独立测试库避免污染真实数据。2.3 大模型 API 调用方式AI 生成脚本有两种落地方式在 Postman 内置 AI 助手里直接触发。使用大模型 API把接口描述发给模型拿到脚本后粘贴或写回 Collection JSON。第二种更通用也方便批量处理多个接口。先确认项目能访问哪个大模型 API不同平台的接口格式有差异但基本都包含 model、messages、apiKey 这几个要素。需要设置两个环境变量不要把密钥写死在脚本或提交到 Gitexport LLM_API_KEYyour-api-key export LLM_API_URLhttps://your-llm-api.example.com/v1/chat/completions下面的 curl 示例用来验证 API 是否可用curl $LLM_API_URL \ -H Content-Type: application/json \ -H Authorization: Bearer $LLM_API_KEY \ -d { model: your-model, messages: [ {role: system, content: 你只输出 Postman Tests 脚本不要解释。}, {role: user, content: 请为 GET /api/users 接口生成测试脚本。} ] }实际项目里需要把your-llm-api.example.com和your-model替换成当前可用服务的地址和模型名。如果公司内部有大模型网关直接用网关地址即可。3. 完成一次 AI 自动生成用例和断言的完整流程3.1 把接口信息整理成结构化输入AI 生成结果的质量首先取决于输入是否结构化。不要只写一句话让 AI “生成用户接口测试脚本”而是把请求方法、路径、请求头、请求体、响应示例、环境变量都写清楚。这里以获取用户列表接口为例整理成 JSON{ name: 获取用户列表, method: GET, url: {{baseUrl}}/api/users, headers: { Authorization: Bearer {{token}} }, responseExample: { code: 0, data: [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin } ] } }使用{{baseUrl}}和{{token}}而不是硬编码是为了让脚本在不同环境之间迁移。这样后续执行 Newman 时只需要切换环境文件。3.2 设计生成测试脚本的 Prompt给大模型的 Prompt 应该包含以下部分角色告诉模型它是 Postman 测试脚本工程师。接口定义完整提供接口信息。输出要求只输出脚本不解释。断言维度明确要求覆盖状态码、业务码、字段存在性、字段类型、数组长度等。技术约束只使用 Postman Sandbox 支持的语法不写 Node.js require不使用 mock 数据。示例 Prompt你是一名熟悉 Postman 的接口测试工程师。 下面是接口定义 - 请求方法: GET - 请求路径: {{baseUrl}}/api/users - 请求头: Authorization: Bearer {{token}} - 响应示例: { code: 0, data: [ { id: 1, name: 张三, email: zhangsanexample.com, role: admin } ] } 请只输出 Postman 的 Tests 标签页可以运行的 JavaScript 脚本。 要求 1. 使用 pm.test 和 pm.expect。 2. 检查状态码为 200。 3. 检查响应中的 code 字段为 0。 4. 检查 data 是数组且非空。 5. 检查数组中每个元素都包含 id、name、email、role 字段。 6. 不使用 mock 数据变量只能使用 {{baseUrl}} 和 {{token}}。 7. 不要输出任何解释性文字。AI 生成的结果大致如下pm.test(状态码为 200, function () { pm.response.to.have.status(200); }); pm.test(业务码 code 为 0, function () { const json pm.response.json(); pm.expect(json.code).to.eql(0); }); pm.test(data 是非空数组, function () { const json pm.response.json(); pm.expect(json.data).to.be.an(array); pm.expect(json.data.length).to.be.greaterThan(0); }); pm.test(每个用户包含关键字段, function () { const json pm.response.json(); json.data.forEach(function (user) { pm.expect(user).to.have.property(id); pm.expect(user).to.have.property(name); pm.expect(user).to.have.property(email); pm.expect(user).to.have.property(role); }); });这段脚本可以直接粘贴到 Postman 请求的 Tests 标签页。如果模型返回的内容带有 Markdown 代码块标记粘贴前要去掉。3.3 把生成结果导入 Postman手工粘贴适合单个请求接口数量多时要考虑批量处理。比较常见的方式是维护一份 Postman Collection 的 JSON 文件然后用脚本把 AI 生成的结果写入对应的event[].script.exec字段。Collection JSON 结构里每个请求可以带一个测试事件{ info: { name: 用户接口, schema: https://schema.getpostman.com/json/collection/v2.1.0/collection.json }, item: [ { name: 获取用户列表, request: { method: GET, url: http://localhost:3000/api/users }, event: [ { listen: test, script: { type: text/javascript, exec: [ pm.test(状态码为 200, function () {, pm.response.to.have.status(200);, }); ] } } ] } ] }在上面的exec数组里每一行是一个字符串。AI 返回多行脚本时需要按换行拆分成数组。可以用 Node.js 写一个批量生成脚本遍历 Collection 的每一个请求调用大模型 API然后把返回内容写入exec。下面是一段用于说明思路的 Node.js 脚本实际使用时需要根据模型接口和 Collection 结构调整const fs require(fs); const collection JSON.parse(fs.readFileSync(user-api.postman_collection.json, utf-8)); async function generateTest(requestInfo) { const response await fetch(process.env.LLM_API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${process.env.LLM_API_KEY} }, body: JSON.stringify({ model: process.env.LLM_MODEL || your-model, messages: [ { role: system, content: 你只输出 Postman Tests 脚本不要解释。 }, { role: user, content: 请为以下接口生成测试脚本\n JSON.stringify(requestInfo) } ] }) }); const data await response.json(); return data.choices[0].message.content; } (async () { for (const item of collection.item) { const requestInfo { name: item.name, method: item.request.method, url: typeof item.request.url string ? item.request.url : item.request.url.raw }; const script await generateTest(requestInfo); item.event [ { listen: test, script: { type: text/javascript, exec: script.split(\n) } } ]; } fs.writeFileSync(generated-collection.json, JSON.stringify(collection, null, 2), utf-8); })();这个脚本没有处理模型返回异常、脚本长度超限、请求头传递等情况只适合作为批量生成的起点。生产环境使用前需要补上重试、日志、失败补偿和人工审批环节。3.4 用 Collection Runner 和 Newman 批量验证生成脚本后先手动发送一次请求查看 Tests 标签页里的测试结果。确认无误后再跑批量。Postman 里的 Collection Runner 可以选中 Collection 或某个 Folder选择环境点击 Run。大规模回归时更推荐使用 Newman。Newman 是 Postman Collection 的命令行运行器可以直接进入 CI 流程。安装并运行npx newman run generated-collection.json \ -e test.postman_environment.json \ --reporters cli,json \ --reporter-json-export newman-report.jsontest.postman_environment.json是环境文件内容大致如下{ name: test, values: [ { key: baseUrl, value: http://localhost:3000, enabled: true }, { key: token, value: test-token, enabled: true } ] }Newman 运行结束后会在终端输出每个请求的断言结果。JSON 报告可以交给 Jenkins、GitLab CI 或其他报告平台解析。注意不要只验证程序能启动还要验证断言是否真的生效。最简单的方法是故意把一个字段名改错确认测试失败再恢复成正确结果。4. 关键脚本拆解让 AI 生成的断言真正可维护4.1 pm.test 和 pm.expect 的基础关系Postman 的 Tests 标签运行在 Postman Sandbox 中语法以 JavaScript 为主。核心 API 是pm.test和pm.expect。pm.test接收两个参数第一个是测试名称第二个是断言函数。pm.expect来自 Chai.js 断言库支持链式调用。例如pm.test(响应时间低于 500ms, function () { pm.expect(pm.response.responseTime).to.be.below(500); });AI 生成脚本时容易出现的问题是它可能会生成 Node.js 服务端的语法比如require(assert)或者fetch搭配顶层 await。这些在 Postman 的脚本环境里不一定可用。所以在 Prompt 里必须限制“只使用 pm 对象和标准 JavaScript 语法”。4.2 让 AI 生成可维护断言的 Prompt 约束好的 Prompt 不是列一个接口而是把断言规范也传进去。下面这个表可以用来检查自己的 Prompt 是否完整Prompt 维度推荐做法容易出现的坑接口信息给 method、url、headers、body、response 示例只说接口名AI 只能猜测断言范围要求检查状态码、业务码、字段、类型、数组、错误分支只检查状态码断言形同虚设变量约束明确指出使用 {{token}}、{{baseUrl}}生成硬编码 token 或本机地址输出格式只输出 JavaScript 脚本不带解释输出带 Markdown 解释需要人工清理技术边界限制使用 Postman Sandbox 语法生成 Node.js 服务端代码运行报错异常覆盖要求考虑 4xx 和 5xx 场景只写正向用例异常场景靠手工补例如针对创建用户接口可以使用下面的 Prompt请为 POST /api/users 接口生成测试脚本。 请求体示例 { name: 测试用户, email: testexample.com, role: user } 响应示例 { code: 0, data: { id: 123, name: 测试用户, email: testexample.com, role: user } } 要求 1. 状态码为 201。 2. 业务码 code 为 0。 3. data.id 是数字。 4. data.name 等于请求体中的 name 字段。 5. 如果状态码为 400则检查响应中包含 message 字段。这样生成出来的脚本会更接近真实测试场景。4.3 参数化、环境变量和断言之间的关系断言脚本不是孤立存在的。请求中的数据来自环境变量、Collection 变量或数据文件断言也要根据这些输入做动态判断。创建用户的接口可以用数据文件里的expectedStatus作为期望值name,email,role,expectedStatus 张三,zhangsanexample.com,admin,201 ,missingexample.com,user,400 李四,lisiexample.com,,201Postman 使用数据文件运行时可以通过pm.iterationData读取当前行的数据pm.test(状态码符合数据文件预期, function () { const expectedStatus pm.iterationData.get(expectedStatus); pm.expect(pm.response.code).to.eql(expectedStatus); });这种数据驱动模式适合接口数量少但参数组合多的场景。AI 在这里的作用是生成 CSV 文件里需要的边界值组合而不是把每一个组合都写成一个独立请求。5. AI 生成结果不靠谱时的排查链路5.1 现象测试通过但断言没有真正生效最危险的情况不是测试失败而是测试通过了但断言根本没执行。检查方式打开 Postman 的 Console确认请求有没有发出。在 Tests 标签里加一个console.log(pm.response.json())。故意改错一个字段名例如把data改成data2看测试是否失败。如果测试仍然通过说明断言代码没被正确加载或者exec数组里的脚本被截断。原因通常是脚本粘贴时漏了行或者在 Collection JSON 的exec数组里没有按行正确拆分。AI 返回的代码块如果被整体当成一行某些 Postman 版本可能会执行异常。解决方案是统一采用“粘贴到 Tests 标签 - 手动发送一次 - 故意制造失败 - 恢复”的验证流程。5.2 现象AI 生成的脚本引用了不存在的变量Postman 在执行脚本时如果遇到{{token}}未定义不会直接报错而是把变量当作字符串传入。这样请求头就会变成Bearer {{token}}接口返回 401断言却还在检查 200。检查步骤查看请求右侧的变量名是否拼写正确。检查当前选择的环境是否正确。在 Console 里查看pm.environment.get(token)的值。如果是 Newman 执行检查是否传入了环境文件。在 Prompt 中最好明确写出允许使用的变量名。生成脚本后用文本搜索检查是否存在token、appId等硬编码值。5.3 现象同一个接口在不同环境执行结果不一致本地接口返回的数据是固定的但测试环境可能因为存量数据多导致断言data.length大于某个值失败或者返回了 null。这种情况下AI 生成的静态断言不能直接用到所有环境。需要把断言改成相对判断pm.test(data 为数组, function () { const json pm.response.json(); pm.expect(json.data).to.be.an(array); }); pm.test(分页字段符合规范, function () { const json pm.response.json(); if (json.data json.data.list) { pm.expect(json.data.list).to.be.an(array); pm.expect(json.data.pageNum).to.be.a(number); } });生产环境建议在 Prompt 里强调“不要断言具体的数据条数除非接口契约明确固定”。把易变数据从断言中排除只保留稳定的契约字段。5.4 排查优先级AI 生成脚本出问题时按照这个顺序排查最快接口本身是否通。先用 Postman 发送请求看响应是否符合预期。环境变量和变量名。检查 baseUrl、token 是否生效。脚本语法。打开 Console查看是否有 JavaScript 报错。断言逻辑。把断言拆成最小用例逐步确认哪一条失败。生成结果。检查 AI 是否遗漏了字段或者引入了不存在的变量。6. 接口测试中 AIPostman 的最佳实践6.1 明确 AI 负责什么人负责什么AI 适合做信息转换不适合做业务决策。接口字段变更、错误码含义、订单状态的流转规则这些必须由熟悉业务的人确认。建议的职责划分AI 负责根据接口文档生成第一版请求、脚本和参数组合。人负责确认断言是否覆盖核心业务规则。AI 负责生成的数据文件只作为候选不能直接用于生产数据造数。人负责把 AI 生成结果纳入代码评审和测试评审。6.2 维护接口描述文件收益大于维护脚本AI 生成脚本的质量取决于接口描述的质量。与其让 AI 猜接口字段不如维护一份 OpenAPI 或自定义 JSON 描述文件。接口描述文件至少包含请求方法、路径。请求头、请求体字段类型。响应示例。错误码含义。字段约束比如必填、长度、枚举值。接口描述文件还有一个好处当接口变更时可以重新生成脚本而不是逐个人工修改。这也让 AI 生成的脚本有了可重复执行的输入源。6.3 从学习环境到生产环境需要补齐的能力本地 Mock 服务只适合跑通流程生产环境的接口自动化还需要额外考虑维度学习环境生产环境数据固定 mock 数据独立测试库测试前后清理数据密钥本地环境变量密钥管理服务禁止明文入库执行手动点击 RunNewman 接入 CI定时触发报告看终端输出解析 JSON 报告推送失败通知回滚不需要脚本和 Collection 都需要版本管理监控不关注记录失败率、响应时间、错误分布注意Postman 脚本运行环境不是 Node.js很多服务端能力不可用。AI 生成的代码如果引用了path、fs、child_process都不能在 Tests 标签里运行。6.4 从单接口用例扩展到业务链路单接口断言只能证明独立接口正常不能证明业务链路正常。更可靠的做法是让请求之间传递数据。例如创建用户接口返回后把返回的id保存到环境变量下一个查询用户详情的请求直接用{{userId}}const json pm.response.json(); if (json.code 0 json.data json.data.id) { pm.environment.set(userId, json.data.id); }这种写法在 Collection Runner 中按顺序执行时非常有用。AI 生成单接口脚本时不会自动处理这种依赖需要人工在 Prompt 中补充“把创建接口返回的 id 保存到环境变量 userId”。7. 常见问题速查与可复用检查清单7.1 常见问题速查表问题现象常见原因检查方式处理建议测试通过但断言未执行exec脚本被截断或脚本语法错误被跳过Console 查看报错故意改错字段从 Postman UI 重新粘贴脚本并发送请求返回 401断言还在检查 200token 变量未设置或拼写错误检查环境变量和 Console 请求头修正变量名确认当前环境AI 脚本使用了require模型把 Postman 当成 Node.js 环境查看 Console 报错在 Prompt 中限制只使用 pm 对象断言过度依赖具体数据测试环境数据不稳定观察不同环境的执行结果把数据条数、ID 等改为相对判断Collection 导入后脚本丢失只导入了请求没有导出事件查看 Collection JSON 的 event 字段确认导出时包含 Tests 脚本Newman 运行找不到环境变量未指定环境文件检查命令行-e参数传入环境文件或使用--env-var7.2 AI 生成脚本前检查清单在把接口描述交给 AI 之前先过一遍这份清单[ ] 接口方法、路径、请求体字段是否完整。[ ] 响应示例是否包含正常返回和异常返回。[ ] 环境变量名是否确定例如 baseUrl、token。[ ] 是否列出了断言维度状态码、业务码、字段类型、数组边界。[ ] 是否正确区分了稳定字段和易变字段。[ ] 是否要求 AI 只输出脚本不输出解释文字。[ ] 是否要求 AI 不生成 mock 数据。7.3 发布到 CI 前的检查清单[ ] Collection 和环境文件已经提交到 Git不在 Git 中出现密钥。[ ] Newman 命令可以本地跑通并生成 JSON 报告。[ ] 至少有一个故意失败用例被验证过确认报告能捕捉失败。[ ] 测试数据具备独立性和可清理性不依赖共享库脏数据。[ ] 接口变更后重新生成脚本并经过人工评审而不是直接覆盖。8. 下一步扩展方向8.1 从请求级生成扩展到链路级生成现在 AI 生成的是单个请求的断言下一步可以让 AI 根据整条业务链路生成 Collection。比如“用户登录 - 创建订单 - 查询订单 - 支付回调”这种链路AI 需要理解接口之间的数据依赖。实现方式是提供每个接口的描述文件和字段映射规则让 AI 生成包含pm.environment.set的脚本。8.2 把 AI 生成的脚本纳入代码评审AI 生成脚本不是一次性产物。每次接口变更、响应结构调整后都应该重新生成并对比差异。有条件的话把 Collection JSON、Prompt 模板和接口描述文件放在同一个仓库里方便 Review。8.3 结合接口变更自动维护用例更成熟的方案是监听接口文档的变更事件自动触发 AI 重新生成受影响接口的测试脚本。比如 Swagger 文档里某个响应字段从 string 变成 number系统自动给测试人员生成一条待确认记录再由人确认是否更新断言。这样可以把 AI 从“单次提效工具”变成“持续维护用例的自动化环节”。AIPostman 不是银弹。它解决的是脚本编写和用例整理的低效问题但测试目标、接口契约、业务规则和异常场景的判断仍然需要人来完成。把这套流程跑通之后最大的收益是让接口测试从“每次手工改断言”变成“接口变了自动给出新脚本人只需要做确认”。