从接口文档到测试用例：我用在线 AI 工具跑通了一条生成链路（实操记录）

发布时间：2026/7/29 20:38:25

一、背景：接口写完了，测试用例还没影

上周联调一个后端项目，接口文档评审通过了，代码也提测了，结果测试同事问我：“这个接口的边界场景你自测过吗？”

老实说，没有。

不是不想测，是写测试用例这件事太磨人。一个普通的 POST 接口，参数校验、业务错误码、边界长度、异常分支，随便列列就是七八个场景。手写 Jest 用例，一个接口小半天没了。项目里二十多个接口，全写一遍不现实，最后往往变成"主干流程跑通就算完"。

之前试过让 AI 聊天窗口直接生成，问题是每次都要把接口文档、返回结构、错误码约定重新描述一遍，提示词写得比用例还累。后来我开始找一个固定入口：粘贴接口文档 → 选测试框架 → 直接出可运行的用例代码。这篇文章就是把这条链路完整跑一遍的记录，用的是项目里一个真实接口，不是玩具示例。

二、测试对象：一个真实的 AI 对话接口

被测接口是项目后端里所有文本/代码类 AI 工具共用的统一入口，逻辑上不算复杂，但错误分支不少，正好适合检验生成质量：

POST /api/ai/chat Content-Type: application/json

请求体：

{"toolCode":"ai_api_test_generator","messages":[{"role":"user","content":"帮我生成这个接口的测试用例"}]}

字段约束和错误码约定：

toolCode：必填，必须是已上线的工具编码
messages：必填，不能为空数组；所有content合计不能超过 30000 字符
成功返回：{"code":200,"message":"success","data":{"reply":"...","remaining":4}}
错误码：400（缺参/空内容/超长）、404（工具不存在）、503（工具维护中）、429（当日额度不足）

注意一个细节：这个接口的业务状态码在响应体的code字段里，不是 HTTP 状态码。这一点如果生成工具读不懂文档约定，断言就会写错，也是我重点观察的地方。

三、实操过程

1. 粘贴接口文档

打开工具页面后，把上面这段接口描述（URL、方法、请求体、字段约束、错误码）整体粘贴进「API 描述」输入框。如果手头有现成的 Swagger 文档，也可以直接导入 OpenAPI JSON，会自动解析接口和参数，我这次走的是手动粘贴路线。

2. 选择目标框架

框架支持六种：Jest、Mocha/Chai、Postman Collection、cURL、Python requests、Java RestAssured。项目前端是 Node 技术栈，我选了默认的 Jest。

3. 生成并检查结果

点「生成测试用例」，等十几秒出结果。生成结果直接渲染成代码块，右上角可以复制全部、下载.md文件。

四、生成质量分析：比我预期细心

拿到代码后我没有直接用，先逐条审了一遍。几个让我觉得"可以省下自己动手"的点：

1. Mock 姿势正确。生成代码用jest.mock('axios')拦截了 HTTP 层，并且自己封装了一个chatAI调用函数，注释里明确写了"实际测试中请替换为真实的 API Client 代码"。没有假装能直接连后端跑，这个分寸感是对的：

constaxios=require('axios');jest.mock('axios');// 假设的 API 调用封装函数// 实际测试中请替换为真实的 API Client 代码asyncfunctionchatAI(payload){try{constresponse=awaitaxios.post('/api/ai/chat',payload);returnresponse.data;}catch(error){if(error.response){returnerror.response.data;}throwerror;}}

2. 业务码断言没搞错。前面提到的坑——业务状态码在响应体里——它处理对了，断言全部打在result.code上，而不是 HTTP status。

3. 场景覆盖比我手列的全。一共 7 个用例：正常成功、缺 toolCode（400）、空 messages（400）、超长内容（400）、工具不存在（404）、维护中（503）、额度不足（429）。其中超长场景直接构造了 30001 字符的字符串去压边界，这个我自己写的时候多半会用"随便拼个长字符串"糊弄过去。

/** * 场景 7: 业务异常 - 额度不足 (429) */test('业务异常：当日额度不足返回 429',async()=>{constinvalidPayload={toolCode:validToolCode,messages:[validMessage]};axios.post.mockResolvedValue({code:429,message:'当日额度不足'});constresult=awaitchatAI(invalidPayload);expect(result.code).toBe(429);});

4. 也有要改的地方。Mock 的是 axios，但项目里实际用的是封装过的 request 实例，所以接入时要把 mock 对象换成本项目的请求模块；另外错误消息文案的断言（message字段）它没有写死匹配，只断言了 code，严格一点的团队规范可能要求补上。这些改动五分钟内能搞定，比从零写省太多。