企业官网建设流程全解析

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 AI+Postman 到底能带来什么

有人问，Postman 是接口测试工具，AI 是算法模型，两者叠加会变成什么？我的理解是三个能力：

1. AI 接口作为被测对象：你调用 ChatGPT、通义千问这类模型接口时，Postman 是你最轻量的调试和回归工具。
2. AI 辅助生成测试数据：利用 AI 生成测试语料、Prompt 集合、异常输入样本，直接导入 Postman 的 Data File。
3. AI 辅助生成断言代码：把响应内容甩给 AI，让 AI 帮你写 Postman Tests 脚本，再人工微调。

这三个能力覆盖了接口测试中“构造请求、构造数据、编写断言”三个核心环节。前期花 90 分钟把这些能力串起来，后面测试效率会有肉眼可见的提升。

2. 环境准备与版本说明

在开始写请求之前，先把环境准备好。这里的版本并不强制要求最新，但需要确保功能完整。

2.1 安装 Postman

Postman 支持 Windows、macOS 和 Linux。官网下载对应版本安装即可。安装完成后使用邮箱注册并登录工作区。

从实践角度看，目前建议安装 10.x 及以上的版本。较新的版本在 UI 上把接口测试和自动化执行整合得比较好，变量管理也更清晰。

下载安装后第一次进入 Postman，你会看到左侧是Collections、Environments、Mock Servers、Monitors等入口。这些在后续流程中都会用到。

# Windows 可以使用 winget 快速安装 winget install Postman.Postman

macOS 可以使用 Homebrew：

brew install --cask postman

2.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 接口失败，问题多半出在以下三个方面：

1. 请求头写错，比如少了Bearer。
2. 请求体中的 JSON 格式不正确，多了一个逗号。
3. model名称和服务商不匹配，比如在 OpenAI 接口上写了qwen-max。

因此，在动手写断言之前，先确保一个最基本的请求能够返回 200 响应。如果跑通一个最简单的对话请求都费劲，后面做自动化只会更加混乱。

4. 90 分钟实战流程：从手写请求到自动化断言

这一部分是文章的核心。我会把 90 分钟拆成阶段，你可以按顺序操作。每个阶段都能独立交付一个成果，不会出现“前面没做就完全卡住”的情况。

4.1 阶段一：编写第一个 Chat Completion 请求

打开刚才创建的集合，添加一个请求，命名为01-ChatCompletion-基础对话。

URL 填：

POST {{baseUrl}}/chat/completions

Headers 填：

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 批量测试多组 Prompt

AI 接口测试一个特殊场景是“针对同一个接口，用多组 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：

1. 点击左侧Mock Servers。
2. 点击+，创建 Mock 服务器。
3. 选择一个示例集合，或新建一个集合。
4. 创建完成后，你会得到一个 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 接口时遇到大致相同的问题。这里整理成一张排查表，按出现频率排序。

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_tokens=100足够。
• 使用 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 接口测试并不是一个独立的测试领域，而是整体接口测试体系中的一个模块。它既需要和功能测试配合，也需要和性能测试联动。只有把它放到研发流水线里去管理，才能形成闭环。

如果你对具体的问题排查和最佳实践有不同看法，欢迎在评论区交流。测试这条路上，每个人踩过的坑都是经验，分享出来，大家都能少走弯路。