1. AI 接口测试的底层逻辑与现状很多测试同学在业务迭代中接触 AI 接口时都有一种感受传统的那套“核对字段、对比数据库、验证返回码”的接口测试方法论放在 AI 模型上面经常失灵。模型的返回是自然语言同一个 Prompt 换一个问法返回结果就不一样模型响应有时候要 10 秒有时候要 30 秒超时时间设多少都不够安心。说得直接一点AI 接口测试的核心难点不是“怎么发请求”而是“怎么验证一个没有确定返回值的接口”。传统接口测试做的是一一对应AI 接口测试要验证的是“语义是否符合预期”“关键字段是否存在”“输出是否有害”“Token 消耗是否合理”。这时候引入 Postman 并叠加 AI 能力就是为了把“不确定”变成“可度量”。1.1 接口测试的基础概念接口测试是指针对服务端提供的 API通过构造 HTTP 请求来验证接口的功能、性能、安全性和稳定性。传统接口测试关注的点主要是这些请求参数格式是否合法。鉴权信息是否正确。业务逻辑是否产生预期结果。并发情况下接口是否稳定。异常输入下是否返回错误码。Postman 之所以能成为接口测试工具中的常青树是因为它把“请求构造 → 响应查看 → 断言编写 → 集合执行”这条链路做得非常顺手。测试人员和后端开发可以用同一套环境、同一个集合去协作调试和回归成本都低。1.2 AI 接口与传统接口的本质差异AI 接口是当前不少团队最头疼的一类待测对象。以 OpenAI 的 Chat Completion 接口为例一个最简单的对话请求会返回类似下面的 JSON 结构{ id: chatcmpl-xxx, object: chat.completion, created: 1699999999, model: gpt-4o-mini, choices: [ { index: 0, message: { role: assistant, content: 你好我是 AI 助手。 }, finish_reason: stop } ], usage: { prompt_tokens: 20, completion_tokens: 30, total_tokens: 50 } }表面上看这个接口的返回结构是固定的。但问题在于choices[0].message.content这个字段的内容永远不会完全一样。我们再来看传统接口的返回{ code: 200, data: { userId: 1001, userName: 张三 } }传统接口的data可以断言“等于张三”而 AI 接口你只能断言“内容是一个非空字符串”“内容包含关键词”“内容不包含敏感词”。这就是 AI 接口测试与传统接口测试最根本的区别。1.3 AIPostman 到底能带来什么有人问Postman 是接口测试工具AI 是算法模型两者叠加会变成什么我的理解是三个能力AI 接口作为被测对象你调用 ChatGPT、通义千问这类模型接口时Postman 是你最轻量的调试和回归工具。AI 辅助生成测试数据利用 AI 生成测试语料、Prompt 集合、异常输入样本直接导入 Postman 的 Data File。AI 辅助生成断言代码把响应内容甩给 AI让 AI 帮你写 Postman Tests 脚本再人工微调。这三个能力覆盖了接口测试中“构造请求、构造数据、编写断言”三个核心环节。前期花 90 分钟把这些能力串起来后面测试效率会有肉眼可见的提升。2. 环境准备与版本说明在开始写请求之前先把环境准备好。这里的版本并不强制要求最新但需要确保功能完整。2.1 安装 PostmanPostman 支持 Windows、macOS 和 Linux。官网下载对应版本安装即可。安装完成后使用邮箱注册并登录工作区。从实践角度看目前建议安装 10.x 及以上的版本。较新的版本在 UI 上把接口测试和自动化执行整合得比较好变量管理也更清晰。下载安装后第一次进入 Postman你会看到左侧是Collections、Environments、Mock Servers、Monitors等入口。这些在后续流程中都会用到。# Windows 可以使用 winget 快速安装 winget install Postman.PostmanmacOS 可以使用 Homebrewbrew install --cask postman2.2 准备 AI 接口的 API Key这一步需要一个可以调用的 AI 模型 API。如果你所在团队有自己部署的模型服务也可以使用自己服务的内网地址原理是一样的。以最为常见的 OpenAI 兼容接口为例你需要在模型服务商后台创建一个 API Key。在后续所有请求的Authorization请求头中统一使用下面这个格式Authorization: Bearer YOUR_API_KEY这里要注意一个很多人会踩的坑API Key 是敏感信息不要直接写在请求 URL 里也不要提交到 Git 仓库。在 Postman 中建议通过环境变量来引用。在接下来的示例中我会使用一个配置项变量名baseUrl 变量值https://api.openai.com/v1 变量名apiKey 变量值你的 API Key国内可用的模型服务商通常也提供 OpenAI 兼容的接口地址。你只需要把baseUrl改成对应服务的域名即可请求路径和请求结构大同小异。2.3 创建第一个测试工作区打开 Postman 后点击Workspaces创建一个新的个人工作区命名为AI-API-Testing。在工作区中再创建一个 Collection命名为AI 接口测试实战。后续所有请求都放在这个集合内。这样做有两个好处每个环境对应独立变量不影响其他项目。集合可以导出为 JSON 文件方便团队成员共享。如果你在团队中使用建议把 Collection 和 Environment 一起导出并提交到测试代码仓库。不要只在个人 Postman 里维护否则团队成员无法保持同一份测试基线。3. 在 Postman 中调用 AI 接口的核心配置在 Postman 中调用 AI 接口本质上就是构造一个 HTTPS 请求。但 AI 接口的请求头、请求体和参数解析有它自己的特点下面逐一拆解。3.1 请求 URL 与请求方法以 Chat Completion 为例请求方法为POST。POST {baseUrl}/chat/completions在 Postman 的 URL 输入框中你不需要直接写死域名。填入{{baseUrl}}/chat/completions其中{{baseUrl}}会引用环境变量里的值。这种方式在切换测试环境和生产环境时非常方便。如果你使用的是国内模型厂商的兼容接口可能会看到路径为/v1/chat/completions或/api/chat/completions这个完全取决于服务商的规定。建议先看服务商文档把 URL 写准确。3.2 Header 配置AI 接口一般需要以下请求头Content-Type: application/json Authorization: Bearer {{apiKey}}如果模型服务是在 Azure OpenAI 上还会额外需要api-key请求头格式略有差异。在 Postman 中你可以在Headers标签页手动添加第一行Content-Type→application/json。第二行Authorization→Bearer {{apiKey}}。注意Bearer后面有一个空格这个细节很容易抄错一旦少了空格会直接返回 401 鉴权失败。3.3 Body 结构与关键参数切换到Body标签选择raw和JSON格式。一个最简请求体如下{ model: gpt-4o-mini, messages: [ { role: system, content: 你是一个测试助手。 }, { role: user, content: 请用一句话介绍 Postman。 } ], temperature: 0.7 }在这个请求体中model指定模型名称。必须和服务商提供的模型名完全一致。messages对话消息列表每条消息包含role和content。role可以是system、user、assistant。temperature控制随机性。0 到 1 之间值越小输出越确定适合做接口测试时降低结果波动。除了这些还有两个参数会在测试中经常用到{ max_tokens: 1024, n: 1 }max_tokens限制了模型返回的最大 token 数n表示返回几个候选结果。在测试场景中一般把max_tokens设置得小一点既能满足验证诉求又不会产生过多费用。3.4 常见误区很多新手第一次调 AI 接口失败问题多半出在以下三个方面请求头写错比如少了Bearer。请求体中的 JSON 格式不正确多了一个逗号。model名称和服务商不匹配比如在 OpenAI 接口上写了qwen-max。因此在动手写断言之前先确保一个最基本的请求能够返回 200 响应。如果跑通一个最简单的对话请求都费劲后面做自动化只会更加混乱。4. 90 分钟实战流程从手写请求到自动化断言这一部分是文章的核心。我会把 90 分钟拆成阶段你可以按顺序操作。每个阶段都能独立交付一个成果不会出现“前面没做就完全卡住”的情况。4.1 阶段一编写第一个 Chat Completion 请求打开刚才创建的集合添加一个请求命名为01-ChatCompletion-基础对话。URL 填POST {{baseUrl}}/chat/completionsHeaders 填Content-Type: application/json Authorization: Bearer {{apiKey}}Body 填{ model: gpt-4o-mini, messages: [ { role: system, content: 你是一个智能助手。 }, { role: user, content: 你好请回答接口测试为什么重要 } ] }点击Send如果一切正常你会看到响应状态码为200 OK响应体是一个 JSON 对象里面有choices和usage字段。到这里第一个 AI 接口测试请求已经跑通。4.2 阶段二在 Tests 中编写自动断言请求跑通之后手工测试的价值只体现了一部分。真正值得做的是把“验证动作”固化到脚本里。Postman 的Tests标签页支持 JavaScript 脚本。在01-ChatCompletion-基础对话的Tests中粘贴以下代码// 1. 校验状态码 pm.test(接口返回 200 状态码, function () { pm.response.to.have.status(200); }); // 2. 校验响应 JSON 结构 pm.test(响应包含 choices 数组, function () { const jsonData pm.response.json(); pm.expect(jsonData.choices).to.be.an(array).that.is.not.empty; }); // 3. 校验模型返回的内容非空 pm.test(模型返回内容非空, function () { const jsonData pm.response.json(); const content jsonData.choices[0].message.content; pm.expect(content).to.be.a(string).and.to.have.lengthOf.at.least(1, content 不应该为空); }); // 4. 校验 token 消耗字段存在 pm.test(响应包含 usage 计费信息, function () { const jsonData pm.response.json(); pm.expect(jsonData.usage).to.be.an(object); pm.expect(jsonData.usage.total_tokens).to.be.a(number); }); // 5. 记录响应时间 pm.test(响应时间小于 30 秒, function () { pm.expect(pm.response.responseTime).to.be.below(30000); });这段代码完成了五个维度的校验。其中最重要的是第 3 条因为 AI 接口的内容是动态的你无法断言具体文字但必须确保它不是空字符串。在Test Results标签页中你会看到五个断言全部通过。如果某一个断言失败Postman 会明确告诉你失败在哪一行这比肉眼去扫响应体高效得多。4.3 阶段三使用环境变量管理模型版本与 Token继续点击集合右侧的...菜单选择Edit在Variables标签中配置集合级变量model gpt-4o-mini maxTokens 1024 temperature 0.5然后在请求 Body 中改为{ model: {{model}}, messages: [ { role: system, content: 你是一个智能助手。 }, { role: user, content: 你好请用一句话介绍自己。 } ], max_tokens: {{maxTokens}}, temperature: {{temperature}} }这样做的好处很直接如果你的测试环境突然要求使用新模型你只需要修改集合变量里的model值所有引用该变量的请求都会同步更新。避免了一个个请求去改 Body 的重复劳动。4.4 阶段四用 Data File 批量测试多组 PromptAI 接口测试一个特殊场景是“针对同一个接口用多组 Prompt 去验证”。在 Postman 中你可以使用Runner来运行集合。点击集合名称右侧的Run按钮进入 Collection Runner。先在本地创建一个 JSON 文件test_data.json内容如下[ { prompt: 请用一句话介绍 ChatGPT。 }, { prompt: 请用一句英文介绍 Postman。 }, { prompt: 请用一句中文介绍 API 测试。 } ]然后在 Collection Runner 界面选择Data File导入这个 JSON 文件。回到请求 Body把 user 消息的 content 改为{ role: user, content: {{prompt}} }运行集合时Postman 会把test_data.json中的每一行数据依次参数化填充到请求中每次执行都会跑一遍Tests中的断言。这样你就轻松完成了多 Prompt 的回归测试。后续如果需要扩大测试语料只需要往test_data.json里增加条目无需修改请求和断言。4.5 阶段五用 AI 辅助生成测试用例这里要说的不是让 AI 帮你生成一段“Demo 级别”的测试代码而是在编写 Postman 脚本时把需求描述清楚让 AI 生成可落地的断言脚本。比如你可以向一个 AI 助手发送这样的提示词我需要在 Postman 的 Tests 标签中编写一段断言脚本。 接口返回的内容是 JSON 格式结构如下 { choices: [{message: {content: 我是模型回的内容}}], usage: {total_tokens: 100} } 请帮我写一段校验脚本要求 1. 校验 HTTP 状态码为 200。 2. 校验 content 字段非空。 3. 校验 total_tokens 为数字且大于 0。 4. 把总耗时打印到控制台。AI 会返回类似下面的结果pm.test(状态码正确, () pm.response.to.have.status(200)); pm.test(content 非空, () { const body pm.response.json(); pm.expect(body.choices[0].message.content).to.be.a(string).and.not.empty; }); pm.test(total_tokens 合法, () { const body pm.response.json(); pm.expect(body.usage.total_tokens).to.be.a(number).and.greaterThan(0); }); console.log(耗时(ms):, pm.response.responseTime);你只需要把这段代码复制到 Postman再根据实际返回结构做微调。这个流程能够显著减少从零写脚本的时间尤其适合不熟悉 JavaScript 的测试人员。4.6 阶段六用 AI 辅助生成 Mock 服务在日常开发中前端同事经常会遇到“后端接口还没写好但前端需要先联调”的情况。Postman 的 Mock Server 可以帮你快速生成一个模拟接口而生成 Mock 响应数据时AI 同样可以帮上忙。在 Postman 中创建一个新的 Mock Server点击左侧Mock Servers。点击创建 Mock 服务器。选择一个示例集合或新建一个集合。创建完成后你会得到一个 Mock Server URL形如https://xxx.mock.pstmn.io。然后在 Mock 响应中你可以让 AI 先生成一段符合真实格式的 JSON 示例{ choices: [ { message: { role: assistant, content: 这是一个 Mock 返回的示例内容。 } } ], usage: { prompt_tokens: 10, completion_tokens: 20, total_tokens: 30 } }把这个 JSON 放到 Mock Server 的示例响应中前端同学在调用 Mock URL 时就能拿到和真实 AI 接口结构一致的数据后续联调真实接口时不需要大幅修改前端代码。4.7 阶段七批量断言与集合运行在所有请求都构造完毕之后你可以点击集合右侧的Run执行完整集合。在 Collection Runner 界面可以配置迭代次数。请求间隔时间。是否保存响应日志。数据文件路径。对于 AI 接口建议在迭代时设置一个合理的时间间隔比如 500ms 或 1000ms。因为 AI 接口通常有速率限制如果并发过快接口会返回 429 限流错误干扰测试结果。运行完成后Postman 会展示每个请求的通过率和失败详情。这个结果可以直接复制到测试报告中。5. 常见问题与排查思路在实际项目中我见过很多同事在测试 AI 接口时遇到大致相同的问题。这里整理成一张排查表按出现频率排序。问题现象常见原因解决思路返回 401 鉴权失败API Key 错误或请求头里少了 Bearer检查环境变量中的 apiKey 是否正确确保 Authorization 格式是 Bearer 空格 Key返回 404 请求路径不存在URL 中拼接了错误的路径确认请求路径是 /chat/completions 还是 /v1/chat/completions返回 400 参数错误请求体 JSON 格式异常或 model 名称拼写错误格式化请求体检查 model 名称与服务商文档是否一致返回 429 请求频率超限测试用例并发执行触发服务商限流在 Runner 中增加请求间隔时间或者降低并发数响应时间过长AI 模型推理本身耗时较长调整 max_tokens 参数使用更快的模型或放宽超时时间断言失败content 为空Prompt 返回了空内容或受到内容过滤机制影响检查请求是否触发内容审核换一组表达更明确的 Prompt本地接口请求超时网络环境限制访问外部模型服务后端代理或网关转发让请求走内网通道5.1 401 鉴权失败看到 401不要第一反应去改代码。先在 Postman 的Console中查看请求头。打开 Postman Console 的方式是点击左下角Console图标。确认一下请求头中的Authorization是不是变成了Bearer ********。如果看到 Key 没有正常替换说明环境变量没有选择正确。解决办法点击 Postman 右上角环境变量下拉框重新选择对应的环境。如果没有环境就创建一个并把apiKey填进去。5.2 429 限流问题AI 模型接口的限流策略通常不是根据并发量而是根据每分钟请求数和每分钟 Token 数。比如一个服务商限制100 requests per minute你在 Runner 中设置了 200 次迭代那么第 101 个请求开始就会出现 429。解决办法Runner 中设置Delay参数例如 600ms 到 1000ms。在 Tests 脚本中加入失败重试逻辑。将大批量数据拆成多个小批次执行。下面是一个简单的重试逻辑示例const retryCount 3; let attempt 0; function sendRequest() { pm.sendRequest({ url: pm.request.url, method: pm.request.method, header: pm.request.headers, body: pm.request.body.raw }, function (err, res) { if (res.code 429 attempt retryCount) { attempt; setTimeout(sendRequest, 2000); } else { pm.collectionVariables.set(lastResponse, res.text()); } }); }这段代码的思路是遇到 429 时等待 2 秒后重试最多重试 3 次。注意在 Postman 的Tests脚本中使用pm.sendRequest属于异步请求断言逻辑需要放在回调函数中处理。5.3 内容过滤导致返回异常AI 模型服务商通常都有内容安全审核机制。当你测试某个 Prompt 时如果模型返回了空内容或者返回的finish_reason是content_filter说明请求触发了内容过滤。这个问题的解决方式不是去硬规避过滤而是更换测试 Prompt。在做接口测试时尽量使用中性的业务场景语料避免使用边界词或攻击性语言。这也是测试规范的一部分。遇到finish_reason为content_filter时可以在断言中单独记录const finishReason pm.response.json().choices[0].finish_reason; if (finishReason content_filter) { console.warn(本次响应被内容过滤机制拦截); }把这类响应单独标记出来便于后续分析是否属于模型问题还是 Prompt 问题。5.4 响应时间波动大AI 接口的响应时间波动非常大最明显的原因是模型推理负载会动态变化。同一个请求有时 3 秒返回有时 20 秒返回。因此在设置断言时不要写死“必须小于 5 秒”建议采用分级策略P0 核心回归响应时间小于 60 秒保障可用性。P1 性能预警响应时间大于 30 秒时记录日志不阻断流程。P2 深度分析响应时间大于 60 秒时告警。这样既不会因为一次波动就误判接口故障又能在大规模回归时发现性能劣化趋势。6. AI 接口测试最佳实践到这里你已经能跑通完整的 AI 接口测试流程。接下来聊聊真正把它落到项目里需要注意的工程问题。6.1 密钥管理与安全边界API Key 是 AI 接口测试中最容易翻车的地方。不要做这些事把 API Key 直接写死在请求 URL 或代码中。把包含 API Key 的 Environment 文件直接提交到公开仓库。在截图或录屏中暴露 API Key。推荐做法使用 Postman 的环境变量和 Secret 变量。Postman 的 Secret 变量类型在导出时会被隐藏。本地维护一份env.private.json只提交模板文件。在 CI 流水线中通过环境变量注入 API Key不进入代码仓库。如果你的团队有统一的密钥管理平台比如 Vault那么可以把 Postman 环境变量的值通过脚本动态生成进一步减少密钥暴露面。6.2 成本控制AI 接口测试和传统接口测试有一个很大的区别调用是有计费成本的。尤其是大模型接口一次压力测试可能消耗几百甚至上千 Token。回归测试如果频繁跑全量用例账单会很难看。成本控制建议如下在测试环境使用较小规格的模型。比如日常回归用mini版本性能测试才用高规格模型。严格控制max_tokens。对只需验证流程的用例设置max_tokens100足够。使用 Postman 的脚本统计每次请求的usage并汇总到日志中。这样月底复盘时能清楚知道测试环境的成本账单由哪些用例产生。下面是统计 Token 的脚本片段const body pm.response.json(); if (body.usage) { pm.collectionVariables.set(totalTokens, body.usage.total_tokens); }在集合运行结束后通过日志查看totalTokens的累加值。6.3 响应结构校验与容错AI 模型的响应结构虽然在大部分情况下稳定但仍有小概率出现异常字段。比如choices数组为空、content字段缺失、网络超时无响应等。因此断言脚本要遵循分层原则第 1 层检查 HTTP 状态码。第 2 层检查 JSON 结构是否存在。第 3 层检查必要字段类型。第 4 层检查业务语义。不要把四层全部写到一个pm.test中否则一旦第一层失败后面三层全被跳过问题定位效率会很低。6.4 与 CI/CD 流水线集成Postman 的集合和测试脚本可以通过 Newman 命令行工具来执行从而实现接口测试自动化。先生成集合 JSON 和环境 JSON# 使用 postman cli 或直接导出 newman run AI接口测试实战.postman_collection.json \ -e 测试环境.postman_environment.json \ -d test_data.json \ --reporters cli,json \ --reporter-json-export report.json在 Jenkins 或 GitLab CI 中把这个命令放到测试阶段即可。GitLab CI 的示例test-api: stage: test script: - npm install -g newman - newman run AI接口测试实战.postman_collection.json -e 测试环境.postman_environment.json artifacts: paths: - report.json需要注意的是AI 接口测试涉及外部模型调用CI 环境中必须保证能够访问模型服务的域名。如果公司网络有隔离策略需要在防火墙上放行对应域名。6.5 数据隔离与测试数据管理AI 接口测试时不要直接把生产环境的 API Key 和 Prompt 数据拿到测试环境使用。生产环境含真实用户信息一旦发送给模型厂商就会涉及数据合规风险。最佳实践是测试环境使用独立的 API Key并设置独立的消费配额。测试 Prompt 中禁止包含真实手机号、身份证号、邮箱等敏感信息。对需要脱敏的字段在发送前通过脚本做替换。比如下面这段脚本会把 Prompt 中的真实手机号替换为测试号码const rawPrompt pm.variables.get(prompt); const maskedPrompt rawPrompt.replace(/1[3-9]\d{9}/g, 13800000000); pm.variables.set(prompt, maskedPrompt);在批量测试用户输入时这个习惯非常重要。6.6 建立测试基线AI 模型会迭代同一个 Prompt 在不同模型版本上的表现可能不同。为了追踪这些变化建议在每次模型版本升级时跑一遍同一个 Prompt 集合并把关键指标记录下来。可以记录的数据有total_tokens。响应耗时。finish_reason分布。核心关键词命中率。内容是否包含敏感词。这些数据构成 AI 接口测试的基线。后续某个版本如果出现关键指标大幅下降就能第一时间从测试报告中发现问题而不是等用户反馈后再去排查。7. 下一步可以继续学习的方向如果你已经按照上面的流程完成了 90 分钟的实战下一步可以把更多精力放在以下三个方向。7.1 从单接口测试转向场景化测试AI 接口很少是独立存在的。大多数业务是一个 AI 接口套在多个外部接口和数据库交互中。使用 Postman 的集合和请求顺序执行能力你可以设计一个场景用例第一步调用鉴权接口获取 Token。第二步调用 AI 接口生成文案。第三步调用内容审核接口检查合规性。第四步调用保存接口落库。通过集合脚本中的pm.collectionVariables传递参数把多个请求串联起来这就是从单接口测试到接口链路测试的进阶。7.2 把 AI 能力接入测试脚本管理流程很多团队已经在做测试用例的 AI 生成。你可以用 AI 辅助生成 Postman 脚本、生成数据文件、生成回归报告摘要。把这块能力固化到日常流程中测试效率的提升会非常明显。比如每次迭代结束后你可以把 Postman 导出的 JSON 报告提供给 AI让它自动生成一份问题摘要和风险提示。这比人工翻日志要快得多。7.3 把 AI 接口测试纳入整体质量保障体系最终你会发现AI 接口测试并不是一个独立的测试领域而是整体接口测试体系中的一个模块。它既需要和功能测试配合也需要和性能测试联动。只有把它放到研发流水线里去管理才能形成闭环。如果你对具体的问题排查和最佳实践有不同看法欢迎在评论区交流。测试这条路上每个人踩过的坑都是经验分享出来大家都能少走弯路。