MIRAGE：面向微服务依赖测试的在线 LLM 仿真技术总结

1. 研究背景与问题定义

核心问题：
微服务集成测试依赖于下游服务的正确配置、数据库状态和行为语义。当依赖服务不可用、难以部署或成本过高时，开发人员通常使用依赖仿真（Dependency Simulation）技术，即通过轻量级代理（Mock）来模拟依赖行为。

现有方法的局限性：
当前的主流方法（如记录 - 回放、模式挖掘、规范驱动的存根）均属于编译时/测试前的静态 artifact 生成。

• **记录 - 回放 **(Record-Replay)：捕获生产流量并回放最匹配的请求。
• **模式挖掘 **(Pattern-mining)：从轨迹中提取状态规则。
• **规范驱动 **(Schema-driven)：基于 API 规范生成存根。

主要缺陷：这些方法生成的静态工件必须在生成时刻编码所有相关行为。任何未预见的场景（如未见的请求参数、错误条件、跨请求的状态依赖）都会导致响应错误或缺失。论文评估显示，记录 - 回放在未见场景下的状态码保真度仅为 62%，响应结构保真度仅为 16%。

本文提出的解决方案：
提出在线 LLM 仿真（Online LLM Simulation）范式。不同于生成静态工件，该方法在运行时将 LLM 保留在循环中。当每个依赖请求到达时，LLM 直接根据请求、依赖源码（可选）、调用者代码和生产轨迹进行推理，动态模拟依赖行为，并维护跨请求的交互状态。

---

2. 方法论：MIRAGE 系统

作者提出了 MIRAGE (Microservice Integration Runtime Agent for Generative Emulation) 系统来实现上述范式。

2.1 核心组件

1. **上下文构建器 **(Context Builder)：

   • 组装 LLM 的系统提示词，包含：
     • 依赖服务的源代码（白盒模式，截断至 8000 字符）。
     • 调用者服务的源代码（截断至 5000 字符）。
     • 按端点和状态码分布分组的轨迹交互摘要。
   • 指令 LLM 模拟依赖行为，跟踪跨请求状态，并以 JSON 格式返回状态码、Body 和可选 Header。

2. **每请求 LLM 服务器 **(Per-Request LLM Server)：

   • 基于 FastAPI 拦截 Mock 端点的 HTTP 请求。
   • 将请求序列化为 JSON 消息发送给 LLM。
   • 状态维护：将请求和响应追加到对话历史中（限制为最近 20 次交换），使 LLM 能够跟踪累积状态（如购物车添加、令牌发放、预订确认等）。
   • 支持多种 LLM 模型（Claude Opus/Sonnet, Kimi, MiniMax 等）。

3. **场景上下文 **(Scenario Context)：

   • 在测试场景开始前，向 LLM 注入场景名称和调用序列（HTTP 方法和路径），但不泄露预期的状态码或响应体，帮助 LLM 预判多步流程（如“先预订后确认”）。

2.2 运行模式

• **白盒模式 **(White-box)：提供依赖源码 + 调用者代码 + 轨迹。
• **黑盒模式 **(Black-box)：仅提供调用者代码 + 轨迹（模拟依赖由其他团队维护的情况）。
• 消融变体：仅依赖源码、仅调用者代码或仅轨迹，用于分析信号贡献。

---

3. 实验设置与基准

• 基准系统：
  1. Demo：自定义的四服务应用（订单、库存、支付、物流），包含乐观锁、令牌生命周期、异步轮询、Saga 编排等复杂模式。
  2. Online Boutique：Google 的微服务演示应用（11 个服务）。
  3. Sock Shop：Weaveworks 的微服务基准（6 个服务）。
• 测试规模：共 110 个测试场景，覆盖 14 对调用者 - 依赖关系，包含 9 种行为类别（如基本 CRUD、错误处理、状态生命周期、分页等）。
• 评估指标：
  • **状态码保真度 **(Status-code Fidelity)：所有 HTTP 状态码是否匹配。
  • **响应体形状保真度 **(Response-shape Fidelity)：状态码匹配且响应体顶层 JSON 键匹配（比状态码更难）。

---

4. 关键实验结果

4.1 总体性能 (RQ1)

• **MIRAGE **(白盒)：在 110 个场景中，状态码保真度达 99% (109/110)，响应体形状保真度达 99%。
• 对比基线：
  • 记录 - 回放：状态码 62%，响应体形状 16%。
  • 模式挖掘 (仅在 Demo 上评估)：61%。
  • 结构化 IR 生成 (仅在 Demo 上评估)：55%。
• 端到端验证：在 Demo 系统的 8 个端到端集成测试中，MIRAGE 产生的通过/失败结果与真实依赖完全一致 (8/8)。

4.2 结构化生成 vs. 自由形式生成 (RQ2)

• 尝试让 LLM 先生成中间表示（IR，如状态机），再编译为 Mock 服务器。
• 结果：在简单 API 上表现尚可（86%），但在复杂状态服务上表现糟糕（55%）。
• 原因：类型化的匹配条件无法表达隐式的跨请求状态跟踪（如“预订已确认”的状态转换），而在线 LLM 仿真通过对话历史隐式维护了这些状态。

4.3 信号贡献分析 (RQ3)

• **依赖源码 **(Dependency Source)：是最关键的信号。仅凭源码即可达到 100% 保真度。
• **无源码 **(黑盒模式)：状态码保真度仍高达 94%，但响应体形状保真度降至 75%。
• 结论：LLM 能从轨迹或调用者代码中推断出正确的错误决策（状态码），但若无源码，难以完全重构响应体的具体结构。

4.4 一致性与成本 (RQ4 & RQ5)

• 模型敏感性：三种前沿模型（Opus, Sonnet, Kimi）结果差异在 3% 以内。Claude Sonnet 在成本降低 80% 的情况下保持了同等性能。
• 成本：每个依赖仿真成本约为 $0.16 - $0.82。
• 延迟：单次调用约 3 秒，完整 110 个场景耗时约 9.4 分钟。虽然比真实服务慢（~100 倍），但省去了 2-5 分钟的 Docker 部署和数据库初始化时间，在 CI/CD 中净收益显著。

---

5. 主要贡献与意义

1. 范式转变：首次将“在线 LLM 仿真”作为微服务依赖测试的原语提出，从“预生成静态工件”转向“运行时动态推理”，有效解决了未见场景和复杂状态依赖的问题。
2. 实证验证：在三个不同复杂度的基准上证明了该方法的有效性，MIRAGE 在保真度上显著优于现有的记录 - 回放和模式挖掘方法。
3. 信号洞察：揭示了依赖源码在重构响应结构中的决定性作用，同时证明了在无源码情况下，LLM 仍能保持较高的状态码准确性，这对黑盒测试场景极具价值。
4. 工程实用性：
   • 无需基础设施：无需部署真实的下游服务、数据库或容器。
   • 成本可控：单次 CI 运行成本极低（约$1.60 对于 10 个依赖）。
   • 自动化程度高：无需手动编写 Prompt，系统自动从源码和轨迹组装上下文。

6. 局限性与未来工作

• 局限性：
  • 目前仅支持 HTTP/JSON，未测试 gRPC 或事件驱动架构。
  • 响应体形状保真度检查的是顶层 Key，未验证具体的值（Value-level correctness），虽然在决策逻辑上准确，但在数据量（如列表长度）上可能存在近似。
  • 依赖 LLM 的上下文窗口限制，对于超大型服务可能需要更多优化。
• 未来方向：扩展至值级验证、支持更多协议、探索“在线仿真 + 结构化验证”的混合架构。

总结：MIRAGE 证明了利用 LLM 的推理能力和状态跟踪能力进行运行时微服务依赖仿真是可行且高效的，为解决微服务集成测试中的“依赖地狱”问题提供了一种新的、高保真的解决方案。