💻 computer science

Reproduction Test Generation for Java SWE Issues

本文通过引入 TDD-Bench-Java（首个包含来自开源仓库的 250 个实例的该任务基准）以及 e-Otter++（一种在该基准和专有行业数据集上均展现出高性能的适配方案），解决了 Java 领域缺乏复现测试生成工具的问题。

原作者： Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

发布于 2026-05-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一家大型公司的软件侦探。一名用户报告了一个漏洞：“嘿，当我点击这个按钮时，应用程序崩溃了！”在修复代码之前，你需要证明该漏洞确实存在。你会编写一个小型自动化测试脚本来尝试点击该按钮。如果脚本崩溃，你就确认了漏洞的存在。一旦你修复了代码，再次运行该脚本；如果它现在完美运行，你就知道修复是有效的。

本文旨在教导人工智能自动编写这些特定的“漏洞猎捕”脚本，但有一个转折：它是针对 Java 进行的，这是一种被大型公司广泛使用的编程语言，而此前的人工智能工具大多仅对 Python 表现良好。

以下是他们工作的分解，使用了一些日常类比：

1. 问题：缺失的“漏洞猎手”

在软件世界中，编写这些漏洞猎捕测试既枯燥又常被跳过。最近，人工智能在编写 Python（一种在初创公司和数据科学中流行的语言）的此类测试方面已表现出色。但 Java 是企业界的“重型机械”（银行、航空公司、大型科技公司）。人工智能在 Java 方面表现挣扎，因为它更加严格且复杂。

作者表示：“我们需要一种更好的方法来教导人工智能在 Java 中猎捕漏洞。”

2. 新地图：TDD-Bench-Java

为了训练和测试他们的人工智能，他们需要一张地图。他们创建了一个名为 TDD-Bench-Java 的新基准。

类比：将其想象成一个巨大的“人工智能健身房”。它包含来自著名开源 Java 项目的 250 份真实漏洞报告。每次“锻炼”由一个漏洞描述和修复前的代码组成。人工智能的任务是编写一个测试，使其在损坏的代码上失败，而在修复后的代码上通过。
重要性：在此之前，没有标准化的方法来评估人工智能是否真的能在 Java 上做到这一点。该基准是首个此类基准。

3. 解决方案：e-Otter++（智能侦探）

他们利用了一个现有的人工智能侦探 e-Otter（它在 Python 方面表现出色），并为其进行了 Java 改造，将新版本称为 e-Otter++。

以下是这位人工智能侦探逐步解决案件的方式：

步骤 1：定位器（寻找犯罪现场）
人工智能查看漏洞报告和庞大的代码库。它必须猜测问题隐藏在哪里。这就像侦探看着城市地图和模糊的犯罪描述，猜测要调查哪栋具体的建筑和房间。
- Java 转折：在 Java 中，你通常必须为测试构建一个全新的文件。人工智能必须确切地弄清楚将这个新文件放在哪里，以免破坏建筑的结构。
步骤 2：上下文构建器（收集线索）
一旦它知道了位置，它就会收集正确的工具（导入项）并设置场景（包名）。这就像侦探在进入房间之前确保拥有正确的徽章和正确的楼层平面图。
步骤 3：初始测试生成器（进行首次尝试）
人工智能编写一个测试脚本草稿。这是一份粗略的草图。
步骤 4：优化器（反馈循环）
这是秘诀所在。人工智能在其损坏的代码上运行自己的测试。
- 情景 A：测试崩溃了，但原因错误（例如，它崩溃是因为拼写错误，而不是漏洞）。
- 修复：人工智能查看错误消息，意识到自己的错误，重写测试，然后再次尝试。它会这样做多达 10 次，从每次失败中学习，直到找到一个恰好因报告的漏洞而崩溃的测试。
步骤 5：异构提示（用六种方式问同一个问题）
为了确保不遗漏解决方案，人工智能以六种不同的方式重写漏洞报告（简化它、移除令人困惑的代码、添加“提示”等），并生成六个不同的测试候选项。这就像让六名不同的侦探从不同角度解决同一个案件。
步骤 6：选择器（选出获胜者）
最后，一个“法官”人工智能查看所有六个候选项，并选出单个最佳测试进行提交。

4. 结果：它有多好？

在公共健身房（TDD-Bench-Java）上：人工智能的成功率约为 44% 到 46%。这意味着在将近一半的案例中，它成功编写了一个能够捕捉漏洞并确认修复的测试。对于如此困难的任务来说，这被认为是一个强有力的结果。
在“现实世界”（专有数据）上：作者还在他们自己的私人公司（IBM）的 150 个漏洞上测试了这一点。
- 挑战：这些漏洞更难处理。描述更短、更模糊，并且通常涉及创建尚不存在的品牌新文件。
- 结果：在没有帮助的情况下，人工智能的成功率仅为 4%。
- 修复：当他们给人工智能一个“提示”（告诉它需要创建的新文件的名称）时，成功率跃升至 20%。

5. 结论

该论文得出结论，虽然人工智能在编写 Java 的漏洞猎捕测试方面正在变得更好，但与开源项目中发现的更干净的数据相比，它仍然难以应对企业软件中混乱、模糊的现实。

简而言之：他们建立了一个新的训练场（TDD-Bench-Java）和一个更聪明的侦探（e-Otter++），现在可以在 Java 代码中猎捕漏洞。它在标准问题上表现良好，但当线索模糊或代码全新时，仍然需要一点人类的帮助（提示）。

技术摘要：Java 软件工作（SWE）问题的复现测试生成

问题陈述

本文解决了 Java 自动化软件工程（SWE）中的一个关键缺口：复现测试的生成。复现测试被定义为在当前代码库上失败（确认问题存在）并在问题修复后通过（确认问题消失）的测试。尽管近期进展已为 Python 提供了基准测试和解决方案，但作为企业软件主导语言的 Java 却仍未得到充分服务。现有的 Java 专用工具要么缺乏故障定位能力，要么依赖简化的问题变体，要么遭受数据集污染和过拟合的困扰。此外，企业级 Java 错误在分布和复杂性上往往与开源 Python 错误不同，因此需要专门的方法来处理 Java 的静态类型系统和面向对象特性。

方法论

作者提出了e-Otter++ for Java，这是对最先进的 Python 复现测试生成器的改编。该方法论是一个多阶段流水线，旨在处理仓库级复杂性，且在生成过程中无需访问修复代码（ $c_{new}$ ）。

1. 流水线架构

工作流程由四个主要组件构成：

定位器（Localizer）： 识别“焦点函数”（最可能被修改的函数）及相关回归测试。与将这两项任务分离的 Python 版本不同，Java 版本将它们合并为单一步骤，以应对 Java 项目中新测试文件频率较高的情况。它采用三步大语言模型（LLM）流程：按名称选择相关文件、按名称选择函数，最后基于函数体进行过滤。
上下文构建器（Contextualizer）： 为新测试文件构建必要的脚手架，这在 Java 中很常见。它通过查询仓库并从现有选项中选择合适的包名、导入语句和文件路径，以最大限度地减少幻觉。
初始测试生成器（Initial Test Generator）： 根据问题描述和定位后的上下文，生成一个初始测试候选项（ $t_{ot}$ ），作为新文件中的新类。
优化器（Refiner）： 利用执行反馈迭代改进测试。它在旧代码（ $c_{old}$ ）上执行测试，通过基于 LLM 的批评器分析日志，如果测试因错误原因失败，则重写测试。该循环最多运行 10 次，累积更改以防止重复错误。

2. 通过异构提示进行推理扩展

为了增加测试候选项的多样性，系统采用异构提示而非基于温度的采样。问题描述被重写为六种不同的变体（morphs）：

标准（Standard）： 重写为结构化格式。
简单（Simple）： 去除术语并简化文本。
dropCode： 移除可能具有误导性的代码片段。
initTest： 将生成的初始测试纳入提示中。
initPatch： 将建议的代码补丁纳入提示中。
默认（Default）： 使用原始问题描述。

随后，测试选择器（Test Selector） 评估生成的六个候选项（及其执行日志），并选择单个最佳测试进行提交。

主要贡献

TDD-Bench-Java： 首个专门针对 Java 复现测试生成的仓库级基准测试。它包含源自流行开源仓库（如 Trino、Jackson、RocketMQ）的 250 个实例，经过筛选以确保“由失败转为通过”的行为。该数据集包含多样的构建工具（Maven、Gradle）和项目结构。
e-Otter++ for Java： 一个从 Python 工作流改编而来的稳健解决方案，在新基准测试上实现了高性能。它是首个包含故障定位的仓库级 Java 复现测试生成的完整解决方案。
专有行业评估： 本文在来自内部 IBM Java 项目的 150 个问题的无污染专有数据集上评估了该系统。这提供了关于将这些模型应用于现实世界企业代码所面临挑战的见解，这些代码通常与开源数据显著不同。

结果

公共基准测试（TDD-Bench-Java）

使用 Claude-Sonnet-4.5 和 GPT-5.2 模型，e-Otter++ 实现了：

使用 Claude-Sonnet-4.5 时，43.6% 的由失败转为通过率。
使用 GPT-5.2 时，46.4% 的由失败转为通过率。

关键发现：

优化影响： 优化步骤（e-Otter）显著优于初始生成器（Otter），相对提升幅度根据模型和变体不同，在 26.2% 到 64.3% 之间。
异构提示： 与单一变体方法相比，使用六种变体将 N=6（至少一个候选项成功）时的由失败转为通过率提高了 32% 以上。
统计显著性： McNemar 检验证实，从 Otter 到 e-Otter 的改进具有统计显著性（ $p < 0.01$ ）。

专有数据集结果

在内部 IBM 数据集上的表现较低，凸显了企业代码的难度：

默认表现： 使用默认问题描述时，由失败转为通过率仅为 4%（6/150）。
带有提示： 当系统获得“提示”（源自代码补丁的新类名和函数签名）时，该比率提升至 20%（30/150）。
数据特征： 专有问题更短，缺乏代码片段，且涉及的代码补丁显著更大（平均 362 行，而公共数据为 55 行）。此外，84% 的专有问题是功能请求而非错误修复，通常涉及引入模型难以预见的新文件。

意义与主张

本文声称对该领域做出了重要贡献，具体体现在：

弥合语言差距： 提供了首个专门针对 Java 的基准测试和解决方案，Java 是企业软件的关键语言，但此前在复现测试生成研究中被忽视。
行业相关性： 超越开源基准测试，评估专有数据上的性能，揭示出虽然模型在精心策划的公共数据上表现良好，但在面对现实世界企业问题的“噪声”和复杂性（如简短描述、新文件生成）时面临重大挑战。
方法论严谨性： 证明了通过异构提示进行推理扩展以及执行驱动的优化是 Java 的有效策略，即使静态类型系统引入了与 Python 运行时错误不同的构建时错误。

作者总结道，虽然当前基于大语言模型的方法显示出前景，但要为 Java 软件开发带来可靠的诊断和验证，仍需进一步创新，特别是在处理描述不清的问题和为新代码结构生成准确上下文方面。