最近在 leadhi.cn 这类 AI 工具聚合平台上，我把市面上主流的模型拉出来比了一圈，重点考察它们编写接口测试脚本的能力。最终我选用 Gemini 3.5 在团队的后端项目里实际跑了两个星期。这篇文章不讲理论，全是实操流程和踩过的坑，希望能给正在补接口测试的同行一些参考。 ## 先说为什么盯上这个事儿 我们项目后端有 120 多个 REST 接口，手动编写的接口测试覆盖率长期徘徊在 55% 左右。算了一笔账：一个接口的测试用例，从理解接口文档到写完断言，平均需要 15 到 20 分钟。120 个接口全部补完，至少需要三到四个工作日——这还不算中间被打断、反复调度的损耗。 在微服务架构下，API 已经成为系统交互的核心枢纽。传统接口测试依赖手工编写用例、固定脚本回放，面对高频变更和复杂依赖，确实有些力不从心。这个痛点并非个例，整个行业都在面临类似挑战。 ## 核心思路：喂文档，不喂代码 很多人用 AI 写接口测试时，第一反应是把源代码整个儿甩给模型。坦白说，这个方向从一开始就偏了。 接口测试的核心依据不是代码实现，而是接口契约。正确的做法是把 Swagger、OpenAPI 或者手写的接口说明直接喂给 Gemini，让它先理解每个接口的请求方法、路径、参数类型、返回结构，再基于这些信息生成测试用例。 AI 可以通过解析接口文档，自动生成覆盖边界条件、异常场景和正常流程的测试用例，这比让它看代码瞎猜接口行为准确得多。 当然，如果你的项目没有规范的接口文档，也可以先把 Controller 层的代码喂给它，让它反向生成接口文档，然后再基于文档生成用例——相当于多走一步。 ## 四个实操技巧，亲测有效 **技巧一：分层生成，别一把梭。** 120 个接口一次性喂给 Gemini，出来的用例质量会参差不齐。正确的做法是分成三层。 第一层，正常路径测试。为每个接口生成最基本的正常请求和响应断言。这一步最快，模型基本一次就能输出可运行的代码。 第二层，参数校验测试。针对每个接口的参数生成边界值和异常值测试——必填参数缺失、类型错误、超长字符串、空值。AI 可以根据接口的参数约束自动生成有效的测试数据，比手动设计更全面，也更不容易遗漏。 第三层，业务逻辑测试。根据业务场景生成组合测试——比如先创建订单再查询订单、先登录再调用需要鉴权的接口等等。 每一层生成完后，先 review 一轮，确认没问题再进入下一层。把功能描述和具体需求喂给 AI 生成用例，再人工 review 和修改，这可能是目前最简单高效的用法。 **技巧二：断言要写到字段级别，别只查状态码。** Gemini 生成的用例最常见的问题是断言太粗糙——只检查 HTTP 状态码是不是 200，完全不看返回体里的具体内容。 提示词里必须明确要求：“除了断言 HTTP 状态码之外，还需要断言返回体中关键字段的存在性和类型。对于创建类接口，断言返回的 ID 不为空；对于查询类接口，断言返回的列表不为空且每个元素包含必填字段。” 把这个约束加上之后，断言质量直接上了一个台阶。以前只断状态码的测试基本是“假通过”——接口返回了 200，但数据结构完全变了，测试也发现不了。 **技巧三：让模型自动生成测试矩阵。** 手动写接口测试最容易漏掉的是组合场景。一个接口有 5 个参数，每个参数有正常值、空值、边界值三种状态，全组合就是 243 种。手动不可能全覆盖。 告诉 Gemini 每个参数的取值范围和约束条件，让它根据等价类划分和边界值分析，挑选出最有价值的用例。5 个参数的接口，它通常会给出 15 到 20 个有代表性的测试用例，基本能覆盖主要边界场景。 **技巧四：准备一个结构化的提示词模板。** 提示词的质量直接决定输出质量。花 5 分钟打磨一个清晰的提示词，远比花半小时去修改一份模糊指令生成的输出高效得多。 常用的模板分为四段：角色设定（你是一名专业的 API 测试工程师）、API 文档（端点、请求头、请求体、响应格式）、任务要求（生成全面的测试用例，重点关注参数校验和异常路径）、输出格式（Markdown 表格，包含用例 ID、类别、描述、预期结果）。 ## 三个必须注意的坑 **坑一：认证处理不好。** 接口测试绕不开 Token。Gemini 生成的用例经常把 Token 写死，或者干脆省略认证步骤。解决方式很简单：在提示词里明确要求包含认证信息，并且说明 Token 的获取方式或传递方式。 **坑二：AI 不了解你系统的具体实现。** AI 可以生成大量用例，但它对你的业务规则一无所知。比如“回调延迟”这类测试，需要研发配合模拟，AI 没法告诉你具体怎么操作。解决方案是：把 AI 生成的用例当作与开发人员的沟通清单，而不是最终的测试脚本。 **坑三：不要直接复制粘贴。** AI 的输出永远是初稿。它完成了 80% 的重复性劳动，剩下的 20% 需要你结合实际业务去调整。另外需要注意的是：不要在 AI 工具中输入公司真实的代码或敏感的业务逻辑。 ## 和其他方案的简单对比 对比**手动编写**：手动写一个中等复杂度的接口测试平均需要 15 到 20 分钟。用 Gemini 3.5 辅助后，基础用例生成只要几分钟，加上人工 review 和业务断言补充，每个接口总共 5 到 8 分钟。 对比 **Postman、RestAssured** 等传统工具：这些工具的自动化优势在于执行，不在于用例生成。Gemini 能帮你跳过用例设计这个最耗时的环节，相当于给了你一个起点。 对比 **Apipost** 等 AI 测试工具：Apipost 已经支持 AI 自动生成接口测试用例，选择维度后自动生成正向和反向用例。这类工具降低了使用门槛，适合不想写代码的测试人员。Gemini 的优势在于灵活度更高，适合需要深度定制的场景。 ## 一个趋势判断 AI 技术在自动化测试中的应用正在变得越来越成熟。通过 AI 模型，可以根据接口定义快速生成高质量的测试用例，还可以实时监控接口的响应时间、错误率等指标，自动调整测试策略。 但以辅助形式在工作流程中不断生成或优化细节，才是目前比较靠谱的落地形态。AI 无法取代测试工程师的批判性思维和领域知识，它能做的，是把我们从那些繁琐、重复的劳动中解放出来。 ## 写在最后 Gemini 3.5 在接口测试场景中的核心价值，是帮你跳过最耗时的两个环节：理解接口文档和生成基础用例骨架。效率翻倍不是因为模型写得多好，而是它把重复劳动自动化了。 不过也得清醒地认识到，AI 模型的准确性依赖数据质量，复杂场景下 AI 的决策过程可能不够透明。业务逻辑层面的断言、异步场景的处理、数据依赖的管理——这些仍然需要人工把关。下次写接口测试之前，先把接口文档整理规范，再让 AI 帮你搭骨架——这个顺序不能反。