接口数量增长之后，接口测试的复杂度就指数级上升。每个版本迭代，接口一旦更新，测试团队总是会反复面临这样的问题：

• 哪些接口已经被测试场景覆盖了，哪些还没有？
• 测试场景前两天还能运行成功，现在怎么失败了？
• 测试失败来自接口、测试数据，还是运行环境？

对这些问题，我们使用 HiFox 中的一个任务就完成了这个大工程：我们围绕 HiFox 的约 1008 个接口，在 Apifox 中建设了 62 个测试场景，把接口覆盖率提升到了 99% 以上。Agent 运行总消耗 25 小时，消耗了 848 万 token。

基本架构

我们使用 HiFox 中的 Agent 来驱动 Apifox 中保存的接口资产和场景运行能力，把接口测试建设拆成了一套可追踪、可重复、可对账的工作流程。

在这套方法中，Apifox 负责保存接口定义、场景步骤、断言和运行报告；HiFox 负责拆分任务、调度 Agent、记录过程和跟踪交付；Agent 负责分析接口、编排场景、执行测试和反馈结果。

HiFox 作为人和 Agent 的控制平面，而 Apifox 作为存储和运行底座。

实施过程

整个方案写下来很复杂，但实际的实施过程其实并不复杂。简单来说就是几步：

第一步，在 HiFox 中创建测试 Agent。这其实是最复杂的一步，但我们已经把 agent 的指令完善好了，你需要使用的话，只需要粘进去就可以了。

第二步，跟 Agent 聊天，让 Agent 分析你的接口覆盖情况，创建一个提升接口覆盖的任务。

第三步，指派 Agent 执行这个任务，自动完善接口和测试场景。

第四步，跟 Agent 聊天，让 Agent 再次分析接口覆盖情况，确认完成效果。

以下是对这四步的详细解说。

第一步：创建测试 Agent

我们在 HiFox 里创建了“测小口”Agent 来负责接口测试，维护其工作守则和使用的 Skill。

这个 Agent 的定位是“接口测试用例维护”，负责分析、编排、执行和报告。它不承担 UI 测试、需求审批和缺陷创建，遇到疑似产品问题时先输出结论和证据，由团队决定后续动作。

在“测小口”的配置中重点设置了四类内容。

第一类是​工作边界​。Agent 通过 apifox-cli 维护接口资产和场景用例，目标仓库是后端服务代码，接口全集以服务端路由注册为重要依据。它需要同时检查接口定义和场景步骤，避免只补录接口、没有形成可执行覆盖。

第二类是​工具纪律​。Agent 每次进行 Apifox 操作前，先读取官方 skill 文档，确认 CLI、场景组件和写入格式；涉及复杂实体时，先读取实体级 schema；构造 JSON 后执行 cli-schema validate，校验通过后再创建或更新资源。

第三类是​固定资源​。 Agent 预先知道测试项目、测试环境、接口代码仓库，以及公共 Setup 和清理场景的位置。这样，任务执行时可以直接把注意力放在接口对账、场景设计和运行验证上。

第四类是​交付标准​。 Agent 每完成一个业务批次，都需要回报接口总数、覆盖数量、新增场景、运行结果、契约修正、受限接口和下一步建议。

Agent 创建完成后，HiFox 任务就可以持续把不同业务域交给同一个执行角色处理，减少重复沟通和标准漂移。

测小口运行在我们的共享测试机上，保证它 24 小时可用，这样测试团队中的每个人都可以方便地使用它。

第二步：任务计划

我们通过跟测小口的 5 次对话，建立了一个完整的测试计划。

 

具体来说，测小口把整个任务拆成了三步：首先是基础设施，然后分批运行，最后全局收尾。

我们让 Agent 按业务域拆分接口建设批次，例如任务管理、空间与项目、组织基础、客户管理、聊天与消息、Agent 与小队、机器与运行时、集成能力等。这样做可以避免一次性让 Agent 处理上千个接口，也方便在测试失败时快速定位业务范围。

按业务域拆分之后，Agent 才能够理解完整的业务链路，也方便我们把失败定位到具体领域。

例如客户管理批次中，我们先完成接口清单比对，再围绕客户生命周期、客户请求与关系、参数校验设计场景。最终，客户域的绝大部分接口进入场景覆盖，唯一受限的 Logo 上传接口则单独记录为运行器能力限制。

Agent 总共把 1008 个接口分成了 14 个批次，分别在 HiFox 创建成了子任务。

第三步：任务执行

接下来，这个任务被安排给测小口，正式开始测试场景建设。

具体来说，测小口做了以下这几件事。

1. 盘点：先建立接口全集，再做双向对账

我们不能只依赖 Apifox 中已有的接口列表来做覆盖。接口可能已经在服务端注册，但尚未录入 Apifox；也可能已经录入 Apifox，但服务端路由已经变更或删除。即使接口两边都存在，路径、参数和响应定义也可能不一致。

因此，我们会把服务端路由作为接口全集的重要来源，再与 Apifox 的接口列表和测试场景步骤做三方对账，三方分别回答三个问题：

1. 服务端实际提供哪些接口？
2. 这些接口是否已经录入 Apifox？
3. 已录入的接口是否进入至少一个可执行场景？

实际操作中，我们让 Agent 从服务端路由注册文件中解析接口，得到方法、路径和业务域，然后执行双向比对。比对结果通常分为四种：

• 服务端有、Apifox 没有：补录接口；
• Apifox 有、服务端没有：检查是否废弃或定义过期；
• 两边都有，但参数不同：以服务端代码和实际请求结果校正；
• 接口定义存在，但没有场景步骤引用：补充场景覆盖。

以上的处理都直接由 Agent 完成。

2. 准备：用 Setup 和清理场景搭建测试地基

很多测试场景都依赖登录、创建组织等基础步骤。如果每个业务场景都从零开始操作，维护成本会快速增加。公共初始化逻辑发生变化时，我们还需要同步修改大量场景。

另一方面，可重复运行的场景，依赖稳定的数据准备和数据清理。如果场景只负责创建数据，不负责删除数据，下一次运行就可能遇到名称重复、旧数据干扰和资源数量持续增长等问题。

因此，我们会把“​公共准备​”和“​残留清理​”分别集中到专用场景中：

• Setup 场景负责准备公共变量和基础资源；
• 业务场景通过场景引用复用 Setup；
• 清理场景负责清除测试账号中的残留数据；
• 业务场景自身负责清理本轮创建的资源。

业务场景结束时，按照资源创建的逆序执行删除。删除步骤允许继续执行，避免单个清理错误阻塞后续资源清理。

账号级清理则交给统一的“残留清理”场景。我们会在每个批次执行前后运行它，确保测试不是建立在上一次运行留下的数据之上。

跨场景运行时，我们会通过测试套件串行执行，并显式开启运行时变量传递。单独运行场景时，则由场景引用重新执行 Setup，避免依赖其他场景的历史变量。

3. 设计：让 Agent 按业务流程分层设计场景

一个场景不应该只是接口列表。

如果场景只按照接口顺序排列，通常只能证明请求能够返回，却无法证明业务链路完整。我们会让 Agent 按业务目标设计场景，并按照风险层次逐步扩展：

主流程回答“正常业务能否完成”。边界场景回答“输入异常时系统如何处理”。权限场景回答“不同用户、组织和资源之间是否隔离”。兼容场景回答“接口结构变化后，旧数据和旧调用方是否仍然能够工作”。

实际操作中，我们会要求 Agent 先设计主流程，再补充边界和权限场景。

一个完整的主流程通常包含：

测试套件也按场景类型组织。主流程进入主流程回归套件，边界场景进入边界与异常套件，权限场景进入权限安全套件，Setup 和清理场景放入环境与清理套件。

在整体建设中，我们按任务管理、空间与项目、组织基础、客户管理、聊天与消息、Agent 与小队、评论与协作、机器与运行时、技能市场、自动化工作流、认证与用户、集成能力和杂项等业务域拆分 14 个批次，共建设了 62 个场景。

4. 运行：先校验结构，再运行、清理和对账

接口测试建设包含两类正确性：一类是测试场景结构正确，能够被 Apifox 正确保存和执行；另一类是接口定义与服务端真实行为一致，断言不会因为错误契约产生误报。

我们会让 Agent 在写入 Apifox 之前先读取官方 skill 和实体级 schema，再进行结构校验。场景写入之后，还要通过实际运行确认请求、变量、鉴权、断言和清理逻辑都能工作。

最终交付标准不是“成功运行一次”，而是“清理后仍能重复运行”。

实际操作中，Agent 的标准写入流程是：

每个批次的交付还需要满足运行标准：新场景单独运行全绿，清理残留后再次单独运行全绿，连续运行三次不产生残留，并更新覆盖率对账和增量报告。

我们在实际批次中观察到几类有代表性的结果。

• 客户管理批次覆盖了 40 个接口中的 39 个，新增 3 个场景，清理后连续运行三轮全部通过。唯一未覆盖的客户 Logo 上传接口受到场景运行器 multipart 能力限制，单独登记为人工或桌面端验证项。
• 评论与附件批次覆盖了 15 个接口中的 14 个，新增 2 个场景，清理后连续运行三轮全绿。建设过程中同步修正了响应码、纯文本响应、二进制响应和 404 响应定义。
• 杂项批次完成了 34 个接口的全覆盖，新增 4 个场景，清道夫清理后串跑并连续运行三轮全部通过，同时修正了多个响应码、request body 和可空字段定义。

每轮运行的失败都要分类记录：数据准备失败、接口定义失真、测试环境不可用、runtime 离线、产品行为异常，或者当前能力无法自动化验证。不同类型的问题需要不同的处理路径。

等到所有子任务运行完成，所有接口被补齐，测试场景也完全齐备。

第四步：结果验收

接口和场景创建完成，只代表建设动作结束，不能直接代表测试交付完成。我们把验收流程固定为：

我们要求 Agent 在 HiFox 任务中提交一份结构化结果，至少包含以下内容：

结果验收还需要检查场景层级是否完整。主流程作为 L1，边界场景覆盖 L2/L3，权限场景覆盖 L4，接口结构发生变化时补充 L5 兼容场景。对于无法通过 staging 或当前运行器验证的接口，我们保留在受限台账中，并记录人工确认或其他验证方式。

最终，测小口给出全量场景和套件评审报告，我们根据报告完善所有遗漏问题。

值得注意的经验

覆盖率口径要写在任务里

我们把“接口出现在至少一个场景步骤中”写成任务的统一口径，并用覆盖率对账脚本持续计算。这样，接口总量、已有覆盖、待补覆盖和受限接口可以在每个批次中保持一致。

OAuth 回调、WebSocket、Webhook 接收、daemon 运行和部分 feed 更新接口受到环境或协议限制，需要进入受限台账。它们可以暂时无法自动化，但不能从统计中无声消失。

Agent 的职责边界决定交付质量

接口测试 Agent 适合负责分析、编排、执行和报告。需求审批、UI 测试和缺陷创建交给对应的团队流程处理。

边界清晰之后，Agent 的输出更容易审核：它需要证明接口范围、场景覆盖、运行结果和失败依据，不需要替团队做未经授权的产品决策。

写入 Apifox 前必须先校验结构

场景包含变量、处理器、鉴权、断言和嵌套步骤，字段结构较复杂。只根据命令帮助或历史记忆拼接 payload，容易出现“创建成功、运行失败”的情况。

我们固定采用“skill → 实体级 schema → validate → create/update → 回读”的顺序。它把结构错误尽量拦截在写入之前，也能减少反复试错。

清理和重复运行比一次通过更重要

一次运行成功只能说明场景在某个时间点可用。清理后重复运行，才能验证数据准备、变量传递、资源生命周期和断言设计是否稳定。

我们统一采用下面的验证顺序：

接口测试会反过来推动契约变准确

测试场景运行时，经常能够发现接口定义与真实行为之间的差异。例如创建接口实际返回 201，定义写成 200；删除接口实际返回 204，定义仍包含响应正文；下载和预览返回二进制，定义却写成 JSON；某些字段实际可以为空，schema 没有设置 nullable。

我们把这些问题作为接口资产修正项同步记录。这样，测试报告既能说明场景是否通过，也能持续提升接口文档和契约的准确度。

增量报告让 Agent 运行可审计

Agent 累计运行了约 25 小时，如果没有统一报告，最终只能留下一个“测试做过了”的模糊结论。

我们要求每个批次回报：接口总数、覆盖数、新增场景、单独运行结果、连续运行结果、契约修正、受限接口和下一步建议。HiFox 任务时间线因此成为测试建设的进度账本，团队可以从批次报告中看到覆盖率如何逐步增长。

结语：把接口测试建设变成可持续的工作流

这套方法可以浓缩为一条工作链路：

HiFox 负责把目标拆成可以推进的任务，Agent 负责把代码、接口资产和测试运行连接起来，Apifox 负责保存并执行可复用的测试资产。

当每个接口都能进入有业务意义的场景，每个场景都具备数据准备和清理能力，每个批次都能通过报告说明覆盖范围和限制原因，接口自动化测试就从一次性补用例工作，变成了团队可以长期维护的质量资产。

💡

HiFox 团队 AI-native 实践经验

我们把更多 HiFox 团队的 AI-native 实践经验整理成了公开文档，并会长期维护、持续补充新内容。欢迎前往查看及收藏！

关注 HiFox AI，及时获取 最新 AI 资讯~