一、背景接口写完了测试用例还没影上周联调一个后端项目接口文档评审通过了代码也提测了结果测试同事问我“这个接口的边界场景你自测过吗”老实说没有。不是不想测是写测试用例这件事太磨人。一个普通的 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 代码。没有假装能直接连后端跑这个分寸感是对的constaxiosrequire(axios);jest.mock(axios);// 假设的 API 调用封装函数// 实际测试中请替换为真实的 API Client 代码asyncfunctionchatAI(payload){try{constresponseawaitaxios.post(/api/ai/chat,payload);returnresponse.data;}catch(error){if(error.response){returnerror.response.data;}throwerror;}}2. 业务码断言没搞错。前面提到的坑——业务状态码在响应体里——它处理对了断言全部打在result.code上而不是 HTTP status。3. 场景覆盖比我手列的全。一共 7 个用例正常成功、缺 toolCode400、空 messages400、超长内容400、工具不存在404、维护中503、额度不足429。其中超长场景直接构造了 30001 字符的字符串去压边界这个我自己写的时候多半会用随便拼个长字符串糊弄过去。/** * 场景 7: 业务异常 - 额度不足 (429) */test(业务异常当日额度不足返回 429,async(){constinvalidPayload{toolCode:validToolCode,messages:[validMessage]};axios.post.mockResolvedValue({code:429,message:当日额度不足});constresultawaitchatAI(invalidPayload);expect(result.code).toBe(429);});4. 也有要改的地方。Mock 的是 axios但项目里实际用的是封装过的 request 实例所以接入时要把 mock 对象换成本项目的请求模块另外错误消息文案的断言message字段它没有写死匹配只断言了 code严格一点的团队规范可能要求补上。这些改动五分钟内能搞定比从零写省太多。五、这条链路适合什么场景跑完一遍我的结论是这类文档 → 用例的生成链路价值不在于替代测试设计而在于把每个接口的基础覆盖成本降到接近零。参数校验、错误码遍历、边界长度这类机械场景交给生成人只补业务语义相关的复杂场景比如涉及多表状态的、有时序依赖的那些它确实生成不了也不该指望它生成。我现在固定在用的入口是工具派上的 AI API 测试用例生成器除了 Jest 也支持直接出 Postman Collection 和 cURL 脚本联调阶段导一份 cURL 给后端对参数也挺顺手。六、小结接口测试用例的机械部分参数、错误码、边界适合交给文档 → 用例的生成链路验收生成结果时重点看三点Mock 方式、业务码断言位置、边界场景是否真的压了边界生成结果接入项目时要替换成本项目的请求封装别直接跑相关工具地址https://gjupai.com/
