AI驱动的零代码API测试：Hive + OInfer 自动化测试生成计划全解析

为什么？

我们现在的现状是完全没有接口自动化，所有东西全靠手点。两周一个迭代的节奏，不定时还有临时上线，回归只能挑最核心的三五个功能跑一遍。结果就是线上问题频发。 更头疼的是，我们根本抽不出时间来改变这个现状。

• • 没人有空从零搭自动化框架
• • 没人有空写几百条用例
• • 新人来了也帮不上忙，光熟悉业务就要两三个月

有没有什么办法，能让我们不用写一行测试代码，就能先把最基础的接口回归跑起来？

思考

我们要实现一个真正的"全自动测试"体验： 自动触发：自动部署后直接触发 自动生成：根据项目代码，自动解析API定义并生成测试场景 自动执行：自动触发测试计划，无需手动配置环境和参数 自动分析：智能解读测试报告，输出结构化的问题和改进建议

V1版本范围：优先支持OpenAPI规范的单服务单环境，覆盖核心Happy Path。测试数据隔离、Fixture管理、非幂等写操作保护等高级功能将在V2版本实现。

🏗️ 整体架构设计

整个系统采用模块化设计，以Hive Agent为核心，通过MCP协议与GitHub和OInfer进行交互，实现端到端的自动化测试流程。

用户 → Hive agent (skill: oinfer-test)
         │
         ├─ 记忆检索 → 检查是否已有该服务的测试上下文
         │
         ├─ [首次/强制重建] GitHub MCP → 读取代码 → 解析API定义
         │
         ├─ OInfer MCP → 创建API定义、测试场景和自动化计划
         │
         ├─ OInfer MCP → 触发测试执行（注册回调地址）
         │
         ├─ [OInfer 回调] → 测试完成后主动通知 Hive
         │
         ├─ LLM分析 → 生成结构化结论
         │
         └─ 记忆更新 → 持久化测试上下文

这个架构的核心优势在于： 完全解耦：Hive负责智能决策和流程编排，OInfer负责测试执行 事件驱动：采用回调机制而非轮询，更高效、更实时 幂等性：所有写入操作都先查后建，避免重复创建资源 可追溯：所有测试上下文都持久化在Hive记忆中，支持增量更新

详细设计方案

OInfer MCP 工具集

我们定义了一套完整的MCP工具接口，覆盖测试全生命周期的所有操作。Hive Agent通过调用这些工具与OInfer系统进行交互。

查询类工具（上下文获取）

写入类工具

执行类工具

报告类工具

V1最小可用工具集：我们优先实现以下10个工具，即可完成完整的自动化测试流程：

oinfer_list_teams → oinfer_list_folders → oinfer_list_envs → oinfer_list_targets
→ oinfer_save_target → oinfer_save_scene → oinfer_save_flow → oinfer_save_auto_plan
→ oinfer_attach_scene_to_plan → oinfer_run_auto_plan → [回调通知] → oinfer_get_report_detail

命名规范：所有由Hive创建的资源都遵循统一的命名格式，避免与手动创建的资源冲突：

hive/{repo_name}/{branch}/{resource_type}/{name}

例如：hive/api-service/main/scene/用户登录流程

Hive 记忆结构设计

Hive的记忆系统是实现增量测试和幂等操作的关键。每个被测服务对应一条记忆记录，以repo_url + branch作为唯一标识。

{
  "operation": "save",
  "type": "project",
  "tags": ["oinfer-service", "api-service", "main", "test-context"],
  "content": "{\"service_name\":\"api-service\",\"repo\":\"github.com/vast/api-service\",\"branch\":\"main\",\"commit_sha\":\"abc123\",\"spec_hash\":\"sha256:def456\",\"team_id\":\"xxx-team-id\",\"folder_id\":\"yyy-folder-id\",\"auto_plan_id\":\"yyy-plan-id\",\"scenes\":[{\"name\":\"用户登录流程\",\"source_scene_id\":\"aaa\",\"cloned_scene_id\":\"aaa-clone\"}],\"last_report_id\":\"zzz-report-id\",\"last_run_at\":\"2026-04-14T10:00:00Z\",\"known_issues\":[]}"
}

关键字段说明：

• • commit_sha：检测代码变更，决定是否需要重新生成测试
• • spec_hash：OpenAPI规范的内容哈希，比commit更精确
• • memory_id：Hive记忆记录ID，用于后续更新操作
• • folder_id：所有测试资源都放在同一个文件夹下，便于统一管理和清理
• • cloned_scene_id：关联到计划后的克隆场景ID，不是原始场景ID

查询方式：使用精确匹配查询，避免模糊搜索带来的误匹配：

{ "operation": "search", "query": "oinfer-service api-service main test-context" }

Hive Skill 执行流程

oinfer-test是Hive Agent的核心技能，它负责协调所有工具调用，完成从代码到报告的整个流程。

输入参数

完整执行步骤

记忆检索：查询是否已有该服务的测试上下文

• • 找到且代码未变更且不强制重建：直接执行已有计划
• • 找到但代码已变更或强制重建：覆盖更新已有资源
• • 未找到：走完整的创建流程

代码解析：通过GitHub MCP读取仓库代码

• • 优先查找openapi.yaml或swagger.json（最可靠）
• • 降级方案：解析路由文件（尽力而为，不保证完整性）
• • 记录spec_hash和commit_sha用于变更检测

资源创建：调用OInfer MCP创建测试资源（先查后建）

• • 确认团队、文件夹和环境
• • 创建所有API定义（跳过已存在的）
• • LLM自动分析接口依赖关系，生成Happy Path测试场景
• • 创建自动化计划并关联场景

记忆保存：将测试上下文持久化到Hive记忆

• • 写入部分成功时先存为草稿状态
• • 全部成功后更新为已确认状态

测试执行：触发自动化计划执行，注册回调地址

• • 调用oinfer_run_auto_plan时传入callback_url参数
• • 获取report_id并记录到记忆中
• • Hive技能进入等待状态，释放资源

回调处理：OInfer测试完成后主动通知Hive

• • Hive接收回调，验证回调签名和report_id
• • 调用oinfer_get_report_detail获取完整报告
• • 超时保护：若30分钟未收到回调，标记为"执行超时"，主动拉取报告（若存在）

智能分析：LLM解读测试报告，输出结构化结论

• • 总体通过率统计
• • 失败接口列表及原因分类（测试失败/环境错误/生成问题）
• • 针对性改进建议

记忆更新：更新最后执行时间、报告ID和已知问题列表

项目分工与进度

✅ 已确定决策

为了保证项目顺利推进，我们已经就以下关键问题达成一致：

• • GitHub访问：优先使用GitHub MCP，webfetch raw URL作为降级方案
• • 认证方式：OInfer MCP的token配置在Hive MCP server中（V2支持多租户）
• • 场景编排：LLM自动判断接口依赖关系，V1仅支持Happy Path
• • 服务标识：使用repo_url + branch作为唯一标识，精确匹配
• • 环境ID：使用string类型，而非int类型
• • 命名规范：统一使用hive/{repo_name}/{branch}/{type}/{name}格式
• • 通知机制：采用回调方式，OInfer完成测试后主动通知Hive，辅以30分钟超时保护

待确认事项（需OInfer终端确认）

• •oinfer_get_report_detail返回的status枚举值
• •oinfer_attach_scene_to_plan是否返回cloned_scene_id
• •oinfer_save_target的同名幂等性行为（覆盖还是报错）
• •OInfer MCP server地址和token的配置key名称
• •回调机制的具体实现：oinfer_run_auto_plan的callback_url参数格式、回调签名验证方式

V1版本限制与V2规划

V1已知限制

• • 无测试数据隔离，有状态测试会污染共享环境
• • 不支持Fixture管理和补偿操作
• • 全局共享token，无用户级权限控制
• • 路由文件解析为尽力而为模式，不支持GraphQL、gRPC和动态路由
• • 写入失败无自动回滚，孤立资源需手动清理
• • 无跨系统链路追踪

V2规划方向

• • 实现测试数据隔离和namespace机制
• • 支持Fixture管理和自动回滚
• • 增加用户级权限控制
• • 支持更多协议（GraphQL、gRPC）
• • 实现写入失败的自动补偿
• • 增加跨系统可观测性

写在最后

传统的API测试是一个耗时费力的重复性工作，而AI的出现为我们提供了彻底改变这一现状的机会。Hive + OInfer的组合，不仅能将测试人员从繁琐的用例编写中解放出来，更能让测试左移成为现实——每次代码提交都能自动生成并执行测试，在开发早期就发现问题。

采用回调机制而非轮询，不仅让系统架构更加优雅高效，也为未来的流式输出和实时反馈打下了基础。这只是我们的第一步。未来，我们还将探索更智能的测试场景生成、异常路径自动覆盖、基于历史数据的风险预测等高级功能，让AI真正成为测试人员的得力助手。

你在API测试中遇到过哪些痛点？你觉得AI还能在哪些方面帮助提升测试效率？欢迎在评论区分享你的想法！

往期精选：

【质量内建】测试之“君子以器养之”

五千二百字深度讲解我的-Harness Engineering七层架构设计

一万五千字深度解读OpenClaw大龙虾：冷静思考下的AI浪潮