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

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

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

老实说，没有。

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

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

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

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

http 复制代码

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

请求体：

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 代码"。没有假装能直接连后端跑，这个分寸感是对的：

javascript 复制代码

const axios = require('axios');
jest.mock('axios');

// 假设的 API 调用封装函数
// 实际测试中请替换为真实的 API Client 代码
async function chatAI(payload) {
  try {
    const response = await axios.post('/api/ai/chat', payload);
    return response.data;
  } catch (error) {
    if (error.response) {
      return error.response.data;
    }
    throw error;
  }
}

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

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

javascript 复制代码

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

  const result = await chatAI(invalidPayload);

  expect(result.code).toBe(429);
});

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

五、这条链路适合什么场景

跑完一遍我的结论是：这类"文档 → 用例"的生成链路，价值不在于替代测试设计，而在于把每个接口的"基础覆盖"成本降到接近零。参数校验、错误码遍历、边界长度这类机械场景交给生成，人只补业务语义相关的复杂场景（比如涉及多表状态的、有时序依赖的），那些它确实生成不了，也不该指望它生成。

我现在固定在用的入口是工具派上的 AI API 测试用例生成器，除了 Jest 也支持直接出 Postman Collection 和 cURL 脚本，联调阶段导一份 cURL 给后端对参数也挺顺手。

六、小结

接口测试用例的机械部分（参数、错误码、边界）适合交给"文档 → 用例"的生成链路
验收生成结果时重点看三点：Mock 方式、业务码断言位置、边界场景是否真的压了边界
生成结果接入项目时要替换成本项目的请求封装，别直接跑

相关工具地址：https://gjupai.com/