[Paper] 生成具有描述性名称的 REST API 测试

Source: arXiv - 2512.01690v1

概述

本文解决了一个出乎意料常见的开发者烦恼：使用自动生成的 REST‑API 测试时，测试往往带有 test0、test1 之类不透明的名称。通过提出产生 人类可读、描述性名称 的确定性技术，作者展示了测试套件可以变得更易理解、维护，并在实际项目中更易采用。

关键贡献

• 三种确定性命名算法（基于规则的启发式），专为 EvoMaster 模糊测试生成的 REST‑API 测试设计。
• 全面的实证比较，涵盖八种命名方法（三种新规则、五种已有方法，包括 Gemini、GPT‑4o、GPT‑3.5 等 LLM 模型）。
• 两项大规模调查（最多 39 名参与者），评估生成名称的清晰度和实用性。
• 工业验证：与 Volkswagen AG 开发者合作，对四个 API 的 74 条测试用例进行评估，确认了真实环境下的可读性提升。
• 证据表明轻量级确定性方法在命名质量上可匹配或超越重量级 LLM，且避免了调用外部 AI 服务的成本、延迟和安全顾虑。

方法论

1. 测试生成 – 开源的 REST‑API 模糊测试工具 EvoMaster 为九个开源 API 各生成 10 条测试用例（≈ 90 条测试）。
2. 命名技术 –
   • 基于规则：提取 HTTP 方法、端点路径、状态码和关键负载字段，构建简洁句子（例如 GET_UserById_Returns200_WithName）。
   • 基于 LLM：将原始测试代码作为提示，询问 GPT‑3.5、GPT‑4o、Gemini 等模型建议名称。
   • 混合/启发式：结合简单字符串操作和基于频率的 token 选择。
3. 人工评估 – 两次独立调查让参与者在 5 分 Likert 量表上对每个名称的 清晰度、简洁性 和 调试实用性 进行评分。
4. 工业案例研究 – 四位 Volkswagen 开发者在四个内部 API 上使用 EvoMaster，随后填写问卷，评价生成名称的可读性和维护影响。
5. 统计分析 – 使用非参数检验（Wilcoxon signed‑rank）比较各技术的中位数得分；报告效应量以衡量实际意义。

结果与发现

• 确定性基于规则的名称在非 LLM 方法中实现了最高的清晰度，并且在统计上与顶级 LLM 不相上下。
• LLM 成本：基于规则的命名耗时 < 1 ms/条测试，而 GPT‑4o 调用平均约 250 ms 并产生 API 使用费用。
• 工业反馈：92 % 的 Volkswagen 参与者同意描述性名称“更容易定位失败的测试”，并“减少了新成员的上手时间”。

实际意义

• 即时采用 – 已使用 EvoMaster（或类似 API 模糊测试工具）的项目只需一次配置更改即可接入基于规则的命名模块；无需外部 API 密钥或延迟惩罚。
• 更佳的 CI/CD 诊断 – 描述性测试名称会出现在构建日志和仪表盘中，使开发者无需深入生成代码即可定位失败场景。
• 促进测试维护 – 当测试存入版本控制时，有意义的名称在重构后仍然保留，便于追踪是哪个 API 合约变更导致了哪项行为失效。
• 成本效益的 LLM 替代方案 – 对于数据隐私要求严格的行业（如汽车、金融），可避免将专有请求/响应负载发送至云端 LLM 服务，同时仍获得大部分可读性收益。
• 可扩展到其他领域 – 基于规则的模式（方法 + 端点 + 状态 + 关键字段）可适配 GraphQL、gRPC，甚至 UI 级测试生成工具。

局限性与未来工作

• 范围仅限于 REST‑style API；对事件驱动或流式服务的命名启发式可能需要重新设计。
• 调查参与者为自选（通过 LinkedIn 招募），可能导致对清晰度的评分偏向更积极的开发者。
• 规则覆盖 – 极其复杂的端点（深层嵌套资源、动态路径参数）有时会生成过长的名称；需要截断策略。
• 作者提出的未来方向包括：
  1. 融入静态分析以捕获业务层面的意图（例如 “创建具有管理员角色的用户”）。
  2. 在更大规模的工业测试套件上评估该方法。
  3. 探索使用轻量级本地 LLM 处理基于规则命名不足的边缘案例的混合模型。

作者

• Philip Garrett
• Juan P. Galeotti
• Andrea Arcuri
• Alexander Poth
• Olsi Rrjolli

论文信息

• arXiv ID: 2512.01690v1
• Categories: cs.SE
• Published: December 1, 2025
• PDF: Download PDF