[Paper] 基于 LLM 的测试生成技术在更新的 LLM 版本中的表现如何？

Source: arXiv - 2601.09695v1

（请提供需要翻译的正文内容，我将为您翻译成简体中文。）

概述

本文研究了在底层语言模型显著增强的情况下，最近基于 LLM 的单元测试生成器中使用的巧妙工程技巧是否仍然重要。通过使用最新的 LLM 重新实现四个最先进的工具（HITS、SymPrompt、TestSpark、CoverUp），并将其与直接使用“plain LLM”方法进行比较，作者展示了仅凭更新的模型就能在覆盖率和变异测试指标上超越这些工程化方案——而所使用的 API 调用量大致相同。

关键贡献

• 经验复制四个领先的基于 LLM 的测试生成系统，使用最新的 LLM（例如 GPT‑4 系列模型）。
• 全面基准在 393 个 Java 类（3,657 个方法）上进行，覆盖行、分支和变异测试的有效性。
• 发现一个朴素提示（纯 LLM）在所有有效性指标上比工程化流水线高出约 18‑20 %。
• 成本感知分析显示，LLM 调用的粒度（类级别 vs. 方法级别）对 API 请求数量影响巨大。
• 提出两阶段策略：先在类级别生成测试，然后仅针对未覆盖的方法进行，能够在不牺牲质量的前提下将 LLM 查询量削减约 20 %。

方法论

1. 工具重新实现 – 作者重新实现了 HITS、SymPrompt、TestSpark 和 CoverUp，将它们原来的（较旧的）大语言模型后端替换为现代的高性能模型。
2. 普通 LLM 基线 – 一个简单的提示，要求 LLM 为给定的类或方法生成 JUnit 测试，不进行任何后处理、编译检查或反馈循环。
3. 评估语料库 – 393 个开源 Java 类，涵盖多种领域，共计 3,657 个方法。
4. 指标 –
   • 行覆盖率（执行的源代码行的百分比）。
   • 分支覆盖率（执行的控制流分支的百分比）。
   • 变异分数（测试捕获注入错误的有效性）。
5. 成本测量 – 生成测试套件所需的 LLM API 调用次数（查询次数），作为金钱和延迟成本的代理。
6. 粒度实验 – 比较类级生成（每个类一个提示）与方法级生成（每个方法一个提示）以及一种混合的“先生成类，再生成未覆盖的方法”方法。

结果与发现

• 普通 LLM 始终生成可编译的、更高质量的测试，驳斥了现代模型需要复杂反馈回路的假设。
• 在按类生成测试时，API 调用次数显著下降；仅对仍未覆盖的方法进行第二遍处理即可节省约 20 % 的查询，同时略微提升了效果。

实际意义

• 工具构建者：如果您在复杂的编译反馈流水线中投入时间，直接升级到最新的 LLM 并专注于提示工程可能会获得更好的投资回报率。
• CI/CD 集成：可以在构建流水线中加入类级别的测试生成步骤，开销极小；随后可以以较低频率（例如夜间）执行方法级别的检查，以控制成本。
• 成本管理：由于 LLM 查询次数是 API 费用的主要来源，两阶段策略提供了一种务实的方式，在保持最先进覆盖率的同时控制预算。
• 开发者采纳：团队可以先采用“直接让 LLM 生成测试”的工作流，然后根据需要迭代优化提示或添加轻量级后处理，从而降低使用门槛。

限制与未来工作

• 语言与生态系统范围：本研究聚焦于 Java 和 JUnit；对其他语言、测试框架或动态类型代码库的结果可能不同。
• 提示敏感性：纯 LLM 的成功依赖于精心设计的提示；论文并未详尽探讨提示的变化或自动化提示调优。
• 模型访问：实验使用了特定的高性能 LLM；随着不同供应商或未来模型的发布，性能差距可能会缩小或扩大。
• 长期维护：论文未涉及生成的测试随被测代码随时间变化而演进的方式——这是持续测试生成流水线的自然下一步。

结论：在当今的 LLM 时代，曾经拯救测试生成质量的“智能工程”正失去优势。一个简单、提示得当的 LLM 已经能够提供更优的测试套件，尤其是当你将其与成本感知的两阶段生成策略结合时。开发者和工具制造者应重新考虑投入精力的方向——是模型与提示，还是重量级的反馈回路。

作者

• Michael Konstantinou
• Renzo Degiovanni
• Mike Papadakis

论文信息

• arXiv ID: 2601.09695v1
• 分类: cs.SE
• 发表日期: 2026年1月14日
• PDF: 下载 PDF