💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

本文介绍了 e-Otter++，一种通过利用异构提示和执行反馈来自动创建复现测试，从而克服软件工程问题中代码缺失或错误挑战的新型测试生成器，在 TDD-Bench Verified 基准测试上实现了 63% 的最先进失败转通过率。

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

发布于 2026-01-26

📖 1 分钟阅读☕ 轻松阅读

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

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

想象一下你是一名正在一个庞大且混乱的图书馆（即软件代码）中破解谜题的侦探。一位读者（开发者）来到你面前说：“这本书出了点问题，但我无法准确说明是什么，我也拿不出具体的错误发生实例。”

在软件世界中，这被称为 SWE 问题。通常，为了修复一个 Bug，你需要一个“复现测试”（reproduction test）——即一个特定的脚本，它能说明：“如果你执行 X 操作，库就会崩溃。”这能证明 Bug 的存在。但通常情况下，这些脚本尚未存在。

这篇论文介绍了一种新的侦探工具，名为 e-Otter++。它的任务是仅仅通过阅读对问题的混乱描述，就能自动编写出那个“崩溃脚本”（测试），甚至在实际修复方案被写出来之前。

以下是 e-Otter++ 的工作原理，通过简单的类比进行解释：

1. 问题所在：“盲目”的侦探

通常，如果你要求一个聪明的 AI（大语言模型）编写一个测试，它会尝试进行猜测。如果你只问它一次，它可能会猜错。如果你用完全相同的指令问它 10 次，它可能只会给你 10 个略有不同的、错误的猜测版本。这就像问一个朋友描述一部他们只看过一次的电影；如果你问他 10 次，他可能只是在重复同一个错误。

2. 第一个技巧：“异质提示词”（化装舞会）

为了获得更好的猜测，e-Otter++ 不仅仅是向 AI 提出 10 次相同的问题。相反，它会改变提问的方式，就像给 AI 换上不同的服装或赋予不同的视角。

“面具”（Masks）： 想象 AI 正在观察一个拼图。有时，e-Otter++ 会遮住拼图的一部分（代码上下文），让 AI 必须基于更少的信息进行猜测。其他时候，它则只展示特定的碎片。这迫使 AI 以不同的方式观察问题。
“变形”（Morphs）： 想象 Bug 报告是用晦涩的术语编写的。e-Otter++ 会要求 AI 以不同的风格重写报告：
- “标准化者”（The Standardizer）： 将混乱的笔记转化为正式、结构化的报告。
- “简化者”（The Simplifier）： 移除令人困惑的技术术语，使其易于理解。
- “丢弃者”（The Dropper）： 移除可能具有误导性的特定代码片段（例如告诉 AI 使用一个该库实际上并不拥有的工具）。
- “预思考者”（The Pre-Thinker）： 先要求 AI 猜测一个解决方案，然后利用这个猜测来编写测试。

通过混合这些“面具”和“变形”，e-Otter++ 生成了一个庞大且多样化的潜在测试池。这就像让 10 个不同的人描述一个犯罪现场，但给每个人提供不同的线索和不同的说话方式。这增加了其中至少有一个人猜对的可能性。

3. 第二个技巧：“执行反馈”（试运行）

一旦 AI 生成了一个测试，e-Otter++ 并不会盲目信任它。它会在“旧代码”（有 Bug 的版本）上运行该测试。

目标： 测试必须失败。但它必须因为“正确的原因”而失败。
问题： 有时测试失败是因为低级错误（比如拼写错误），而不是因为真正的 Bug。
解决方法： e-Otter++ 有一个“评论家”（另一个 AI）来观察失败情况。如果测试失败的原因不对，评论家会说：“不，那不是 Bug。这是出错的具体行，以及你需要额外查看的一些代码。”然后，系统会利用这些新信息重写测试。它会不断循环这个过程，直到测试能够完全按照 Bug 描述的要求发生失败。

4. 第三个技巧：“替代补丁”（虚拟修复）

这是最难的部分：要判断一个测试是否“好”，它需要在“新代码”（修复后的版本）上通过。但修复方案还没写出来！如何挑选出最好的测试呢？

e-Otter++ 使用了一个聪明的变通方法：

它要求另一个 AI 系统（称为 Agentless）生成一系列“虚拟修复”（surrogate patches）。这些并不是完美的修复，但已经很接近了。
它将所有候选测试在这些虚拟修复上运行。
如果一个测试在虚拟修复上通过了，那么它很可能是一个好的测试。
最后，e-Otter++ 根据哪个测试覆盖了代码中最重要的部分，来选出唯一的最佳测试。

结果：巨大的飞跃

该论文在两个主要基准测试（TDD-Bench 和 SWT-bench）上测试了该系统。

此前的最优水平： 顶尖系统只能在 37% 到 38% 的时间内生成有效的测试。
e-Otter++： 通过使用这些新技巧（改变提问方式并使用虚拟修复来过滤答案），e-Otter++ 在一个基准测试中将成功率提高到了 63%，在另一个基准测试中提高到了 52.5%。

为什么这很重要

作者表示，这主要在两个方面提供了帮助：

对于人类： 它自动化了“测试驱动开发”（在修复 Bug 之前编写测试）中枯燥的部分，使开发者更容易确认 Bug 并修复它们。
对于 AI Agent： 许多 AI 编程 Agent 依赖这些测试来了解它们是否修复了 Bug。通过提供更好的测试，e-Otter++ 也在帮助其他 AI Agent 更好地完成工作。

简而言之，e-Otter++ 是一种更聪明、更具创造力且更严谨的方式，用于要求 AI 在无需人类预先编写证明的情况下，编写出“软件 Bug 存在且已被修复”的证据。

技术摘要：用于软件工程（SWE）问题测试生成与选择的异构提示与执行反馈

问题陈述
软件工程（SWE）问题（描述缺陷或缺失功能的条目）通常伴随着缺乏自动化复现测试的非正式描述。这种测试的缺失阻碍了问题的验证和代码补丁的接受。本文解决的具体挑战是：如何直接从问题描述和现有的（补丁前）代码库（ $c_{old}$ ）中，自动生成“从失败到通过”（ $F \to P$ ）的复现测试，且无需访问解决该问题的代码补丁（ $c_{new}$ ）。一个有效的 $F \to P$ 测试必须在执行于 $c_{old}$ 时失败（复现问题），并在执行于 $c_{new}$ 时通过（确认修复）。由于问题描述是非正式的，且测试的目标代码尚不存在，这项任务具有很高的难度。

方法论：e-Otter++
作者引入了 e-Otter++，这是一个扩展了先前 Otter++ 框架的系统。该系统通过三个主要组件运行：测试生成器、代码补丁生成器和测试选择器。

通过异构提示进行测试生成：
不同于仅仅依赖提高大语言模型（LLM）解码温度来生成多样化候选方案（这是一种常见的做法，但往往缺乏多样性），e-Otter++ 采用了异构提示（heterogeneous prompting）。这包括两种系统的变体：
- 问题描述变形（Issue Description Morphs）： 在生成测试之前，LLM 以五种不同的方式重写原始问题描述：标准型（格式化）、简化型（简化术语）、dropCode（移除可能具有误导性的代码片段）、initTest（合并初始测试）以及 initPatch（合并初始补丁提案）。
- 上下文掩码（Context Masks）： 修改测试生成提示，以包含或排除特定的定位上下文（例如：规划器输出、测试定位、补丁定位），从而创建五种不同的提示变体。
  通过结合这些手段，系统为每个问题生成 10 个候选测试组成的集合。
基于执行增强的测试修复：
生成的候选测试会在 $c_{old}$ 上执行。虽然它们预期会失败，但可能会因为错误的原因（例如：语法错误或无关的异常）而失败，而不是复现所述的具体问题。e-Otter++ 引入了一个**评论家（critic）**机制：
- LLM 分析问题描述和执行日志，以判断测试是否因“正确的原因”而失败。
- 如果失败原因是错误的，评论家会识别必要的上下文（例如：特定的缺陷行、相关的代码片段或函数签名），并增强修复提示。
- 系统使用这种富含上下文的信息迭代修复测试（最多尝试 10 次），直到测试因正确的原因而失败，或者达到迭代限制。
通过代理补丁进行测试选择：
由于 $c_{new}$ 不可用，e-Otter++ 无法直接验证测试是否在真实的修复程序上通过。为了解决这个问题，系统使用 Agentless 生成 40 个候选代码补丁（作为 $c_{new}$ 的代理），并将它们筛选至出现频率最高的 5 个。
- 测试选择器在这些代理补丁上执行候选测试。
- 在代理补丁上实现 $F \to P$ 的测试会被优先考虑。
- 基于规则的选择器对失败类型进行分类（断言失败 vs. 错误），并使用代码覆盖率（补丁新增/删除行中被测试覆盖的比例）作为平局决胜规则，以选择最终的单个测试。

核心贡献
本文做出了三项新颖的贡献：

执行增强型测试修复： 一种通过利用执行反馈来检索相关代码并增强修复提示，从而提高测试正确性的方法，确保测试是因所述问题而失败。
用于多样性的异构提示： 通过问题描述变形和上下文掩码来增加测试候选方案的多样性，而非仅仅依赖高温度采样。
基于代理补丁的选择技术： 使用来自不完美生成的代码补丁的执行反馈，作为真实修复程序的代理，来进行最终测试的选择。

结果
该系统在 TDD-Bench Verified（449 个样本）和 SWT-bench Lite（276 个样本）上进行了评估，两者均源自 SWE-bench。

性能表现： e-Otter++ 在 TDD-Bench Verified 上实现了 63.0% 的状态最优（SOTA）从失败到通过（ $F \to P$ ）率，在 SWT-bench Lite 上实现了 52.5%（使用 Claude-3.7-Sonnet 模型）。这显著优于此前发表的最佳结果（Otter++ 分别为 37.0% 和 29.0%）。
组件有效性：
- 执行增强修复使不同配置下的 $F \to P$ 率提升了 11.1% 至 74.3%。
- 异构提示（变形 + 掩码）相比仅使用掩码，使 $F \to P@N$ （ $N$ 个候选方案中至少有一个成功的速率）提升了 13% 以上。
- 使用生成的代码补丁作为测试选择的预过滤器提供了显著的性能提升（例如，在 TDD-Bench Verified 上使 $F \to P$ 提升了 32.9%）。
泛化能力： 该方法在无污染基准测试 SWE-rebench 上得到了验证，在该测试中，它比基础 Otter 系统相对提升了 75% 的 $F \to P$ 率，证明了其对数据污染的鲁棒性。
验证效用： 研究表明，生成的测试能有效验证其他 SWE Agent 的代码补丁，显著提高了顶级排行榜系统所提方案的精确度。

意义与主张
作者声称 e-Otter++ 代表了从 SWE 问题生成复现测试领域的重大飞跃。论文指出，通过将异构提示与执行反馈相结合——特别是利用代理补丁进行选择以及上下文增强修复的创新用法——克服了以往方法在测试多样性和缺乏目标代码库进行验证方面的局限性。

这项工作旨在通过自动化创建复现测试这一繁琐过程，来巩固测试驱动开发（TDD）的实践，从而为人类工程师和自动化 SWE Agent 解决问题及长期质量保证提供帮助。作者对研究范围保持了谦逊，指出系统目前处理单文件测试且主要在 Python 上进行评估，但强调相对的改进表明这些技术即使在非污染、多样化的数据集上也是有效的。