💻 computer science

IssueExec: A Test-Driven Approach for Localizing Software Engineering Issues

本文提出了 IssueExec，这是一种新颖的测试驱动方法，它利用领域增强的测试表示和层级化追踪分析来弥合问题描述与代码之间的语义鸿沟，通过显著提高召回率和解决率，在定位软件工程问题方面达到了最先进的性能。

原作者： Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

发布于 2026-07-21

📖 1 分钟阅读☕ 轻松阅读

原作者： Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

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

想象一下你是一名侦探，正试图在一个庞大且混乱的图书馆里破解一个谜题。这座图书馆代表着一个巨大的计算机软件，而这个谜题是一个“缺陷”（bug）——一个让软件表现异常的错误。通常，当有人报告一个缺陷时，他们会写下一段简单的英文笔记，比如“点击这里时地图无法加载”。你的任务是找到图书馆中隐藏错误的准确页面，以便修复它。这被称为“问题定位”（issue localization）。

长期以来，侦探们一直试图通过阅读这段简单的英文笔记并猜测它对应图书馆中的哪个页面来解决这个问题。但这就像是通过寻找单词“地图”来寻找一本特定的书，而你的图书馆是按“地理”、“制图学”和“导航”来分类书籍的，而笔记里只写了“地图”。单词并不匹配，而且图书馆太大，无法搜索每一层书架。你即将阅读的论文提出了一种全新的、更聪明的方法来解决这个问题：不要仅仅靠猜测，而是利用图书馆自身的“练习测试”。这些测试就像是图书管理员运行的排练剧本，用来确保书籍按正确的顺序排列。作者建议，这些剧本充当了一个秘密的桥梁，将人类杂乱的笔记翻译成图书馆书架上精确的语言，从而使搜索缺陷的过程变得更快、更准确。

问题所在：“词汇鸿沟”

来自中国和新加坡的研究团队注意到，计算机在尝试修复软件缺陷时存在一种令人沮闹的模式。当人类说“无服务器功能（serverless feature）无法工作”时，计算机通常会寻找名为“serverless”的代码。但在现实世界中，代码的名字可能非常技术化，例如 _get_db_cluster_kwargs（这仅仅是“获取数据库集群设置”的一种花哨说法）。

这就像是你向图书管理员询问一本“关于太空的书”，而他们只会在标题中寻找带有“太空”一词的书籍，从而错过了那些实际上关于“天文学”或“宇宙学”的书籍。这种人类语言（需求）与程序员命名方式（代码）之间的不匹配，造成了巨大的“语义鸿沟”。现有的工具试图直接跨越这一鸿沟，但它们经常失误，导致漫长且昂贵的搜索过程，且计算机往往猜错。

新思路：测试即“可执行需求”

论文提出了一个聪明的迂回方案。作者建议，不要直接从缺陷报告跳到代码，而是通过测试进行中转。

把软件测试看作是一次“演习”或“排练”。程序员编写测试来检查某个功能是否正常工作。至关重要的是，测试的名称通常听起来与缺陷报告完全一致。如果缺陷与“Serverless”有关，那么测试的名字可能是 test_create_serverless_db_cluster。

作者认为，测试是完美的中间人，因为它们是可执行的需求。它们是用人类可读的语言编写的（类似于缺陷报告），但同时也与实际代码紧密相连（因为它们必须运行并成功通过）。通过先找到正确的测试，你就创建了一个“两步走”的路径：

缺陷报告 $\rightarrow$ 测试（容易匹配：两者都使用像“serverless”这样的词汇）。
测试 $\rightarrow$ 代码（保证匹配：测试实际上会运行该代码）。

理论基础：减少“困惑度”

在构建工具之前，作者通过数学计算来验证这个想法是否合理。他们使用了“熵”（entropy）的概念，这是一种衡量困惑度或不确定性的高级概念。想象你在草堆里找一根针：

直接搜索： 如果你仅根据缺陷报告进行猜测，你可能需要查看 10,000 根针。这是高困惑度。
基于测试的搜索： 如果你先找到包含那根针的正确“盒子”（即测试），你可能只需要查看 100 根针。

他们的计算表明，使用测试作为中间人可以将“困惑度”平均降低 7.73 bit。用通俗的话说，这意味着搜索空间变得显著缩小且更加聚焦，使得寻找正确位置变得容易得多。

解决方案：IssueExec

为了将这一理论付诸实践，团队构建了一个名为 IssueExec 的工具。它分为三个主要步骤：

智能测试检索： 该工具查看缺陷报告并尝试找到匹配的测试。但它知道程序员会使用缩写或内部梗。因此，它会深入挖掘项目的历史记录（例如阅读旧的提交信息），以学习到“tz”代表“timezone”（时区）或“ovr”代表“OneVsRestClassifier”。这有助于它比标准的计算机搜索更深刻地理解测试名称。
追踪分析： 一旦找到正确的测试，它并不会止步于此。它会运行该测试，并观察该测试具体触及了哪些代码行。这会产生一个“追踪”（trace），就像一条面包屑路径。然而，测试往往会触及过多的代码，包括一些与缺陷无关的乏味的基础设施部分。
噪声过滤： 该工具使用一种智能 AI 来观察这条面包屑路径并过滤掉噪声。它会询问：“这些被触及的行中，哪些真正导致了问题？”它会忽略无聊的部分，并突出显示极有可能是罪魁祸首的具体函数。

结果：巨大的胜利

团队在名为 SWE-bench Lite 的著名基准测试上测试了 IssueExec，该测试包含 300 个真实的软件缺陷。结果令人印象深刻：

更高的准确性： 与之前的最佳方法相比，IssueExec 找到正确代码位置（在函数级别）的频率提高了 41.57%。
更多的修复： 当他们将 IssueExec 接入一个自动化修复系统（称为 Agentless）时，该系统比之前多解决了 17.72% 的缺陷。
成本效率： 尽管它做了额外的工作（运行测试和分析追踪），但与其它复杂方法相比，它实际上更省钱，平均每个缺陷的成本降低了约 35%。

局限性（它做不到的事）

作者坦诚地说明了该工具可能失效的地方。

缺失测试： 如果软件项目中没有涵盖特定缺陷代码的测试，IssueExec 就无法找到它。研究显示，现有测试覆盖了约 96.98% 需要修复的文件，但仍留有一个小缺口（约 33.30% 的特定函数）会让工具陷入困境。
深层迷宫： 有时，代码路径非常长且曲折（就像一个深层的地下隧道系统），工具会在中间层迷失方向，从而错过最终目的地。

为什么这很重要

这篇论文表明，我们不需要教计算机如何更好地猜测人类语言。相反，我们应该教它们利用开发者已经拥有的工具：测试。通过将测试视为人类投诉与计算机代码之间的桥梁，IssueExec 将一场混乱的搜索变成了一次引导式的参观。它表明，修复软件缺陷的未来不在于使用更大的 AI 模型进行盲目猜测，而在于利用现有的证据进行更智能、循序渐进的推理。

技术摘要：IssueExec —— 一种用于定位软件工程问题的测试驱动方法

1. 问题陈述

自动化软件维护高度依赖于问题定位（issue localization），即识别需要修改以解决报告问题的特定代码位置（文件、模块或函数）的任务。现有方法主要遵循直接的“问题–代码”对齐范式，试图将自然语言描述的问题直接与代码元素进行匹配（例如，通过检索或 LLM 智能体）。

然而，这些方法往往因**抽象鸿沟（abstraction gap）**而难以奏效：问题描述表达的是行为预期（需求），而代码标识符反映的是技术实现细节。正如论文中所阐述的，一个请求“支持 ServerlessV2”的问题可能在语义上无法与名为 _get_db_cluster_kwargs（参数提取）的函数对齐，从而导致弱语义对齐和定位失败。虽然需求文档理论上可以弥补这一鸿沟，但其往往会偏离实际实现。作者认为，**测试套件（test suites）**由于必须与实现保持同步以通过测试，因此可以作为一种更优的中间信号。

2. 方法论：IssueExec 框架

作者提出了 IssueExec，这是一个将测试套件视为“可执行需求”的测试中介定位框架。该框架采用两跳路径运行：问题 $\rightarrow$ 测试 $\rightarrow$ 代码。它由三个主要阶段组成：

A. 理论与实证动机

在详细介绍框架之前，作者确立了该方法的可行性：

理论分析： 利用哈特利熵（Hartley entropy），作者对定位不确定性进行了建模。他们证明，与直接检索相比，两跳路径（问题 $\rightarrow$ 测试 $\rightarrow$ 受追踪约束的代码）平均减少了 7.73 bit 的不确定性，这主要是通过压缩搜索空间实现的。
实证研究： 对 18 个 Python 仓库（929 个问题）的研究表明：
- 现有测试覆盖了 96.98% 的真实文件和 66.70% 的真实函数。
- 在 82.4% 的案例中，两跳路径比直接匹配具有更强的语义连通性。

B. IssueExec 的核心组件

为了应对语义鸿沟和执行噪声带来的挑战，IssueExec 实现了以下流水线：

领域知识增强（离线预处理）：
- 挑战： 通用嵌入无法捕捉领域特定术语（例如，用 "tz" 表示时区）或项目特定的别名。
- 解决方案： 系统挖掘历史提交记录，为每个测试提取领域知识 ( $D_t$ $D_{t}$ )。这包括：
  - 引入该测试的提交信息（提供需求层面的上下文）。
  - 共变实体（经常与该测试同时被修改的代码）。
- 结果： 得到增强的测试表示 $repr(t) = [sig(t); doc(t); D_t]$ ，从而弥合了问题与测试之间的术语鸿沟。
相关测试检索（两阶段过滤）：
- 词法过滤： 使用 BM25 将搜索空间从数千个测试缩减到可控的候选集 ( $N$ )。
- 语义选择： 通过 LLM 分析增强后的表示，从中选出与问题意图最相关的少量高质量测试子集 ( $k \ll N$ )。
追踪引导的定位：
- 挑战： 单个测试可能会执行数千个函数，包括无关的基础设施代码，从而产生噪声。
- 解决方案： 系统在容器化环境中执行选定的测试，以收集动态执行追踪。系统构建一个代表调用者-被调用者关系的有向追踪图 ( $G_t$ )。
- 去噪： LLM 结合问题描述分析追踪图，以识别“可疑位置”。它会过滤掉偶然的基础设施代码，并突出显示需求核心代码，分配置信度等级（关键、高、中）。
精炼与重排序：
- 通过检索包含可疑位置的文件所对应的结构化上下文（模块骨架），扩展初始的可疑集合。
- 最终的 LLM 引导重排序步骤利用完整源代码来优先排序候选对象，通过推理根因、因果关系和架构合理性，生成最终的排序编辑位置列表 ( $L^*$ )。

3. 主要贡献

将可执行需求形式化： 论文将使用测试套件作为需求的“可执行代理”的概念进行了形式化，展示了如何在测试层面实现语义对齐，并通过运行时执行落地来共同弥合“问题–代码”的鸿沟。
IssueExec 框架： 一个基于过程的框架，它整合了通过提交挖掘获得的领域知识增强型测试表示，以及通过动态执行图进行的层次化追踪分析，以实现问题定位。
达到最先进水平的性能： 通过实证验证，证明该方法在定位准确度和下游问题解决能力方面均显著优于现有基准。

4. 实验结果

该框架在 SWE-bench Lite（来自 11 个 Python 仓库的 300 个问题）上进行了评估。

定位性能 (RQ1)：
- IssueExec 实现了 70.07% 的文件级 Recall@1，比最强基准（Agentless）高出 17.78%。
- 在函数级别，它实现了 41.07% 的 Recall@1，比最强基准（MoatlessTools）提升了 41.57%。
- 这种提升在不同的 LLM 后端（GPT-4o 和 Claude-3.5-Sonnet）上均保持一致。
问题解决性能 (RQ2)：
- 当集成到 Agentless 流水线中时，IssueExec 多解决了 17.72% 的问题（解决率为 37.67% vs. 32.00%）。
- 作者将其归功于提供了高度聚焦的函数级上下文，这减少了下游补丁生成模型的干扰。
成本效率 (RQ3)：
- 与复杂的基于智能体的方案（如 SWE-Agent, OrcaLoca）相比，IssueExec 将每个问题的平均成本降低了约 35.47%，同时保持了卓越的准确性。
- 由于存在追踪分析的开销，它比程序化基准 Agentless 略贵，但作者认为这种投入对于性能提升是值得的。
消融实验 (RQ4)：
- 移除基于测试的中间步骤（“w/o Tests”）会导致 F1 分数显著下降（例如，函数级别下降了 12.94%），证实了测试中介方法的中心地位。
- 移除追踪分析或领域知识也会导致性能大幅下降，验证了动态执行落地和语义增强的必要性。

5. 重要性与局限性

重要性：
论文指出，精确且具备需求感知能力的定位是自动化软件维护的关键赋能因素。通过从直接的“问题–代码”匹配转向“测试中介”的方法，IssueExec 有效地降低了抽象鸿沟和搜索空间的熵。结果表明，利用现有的测试套件作为可执行需求，为解决复杂的多文件问题提供了一条稳健且具成本效益的路径。

局限性与失效模式：
作者明确承认了两个主要的失效模式：

测试覆盖不足： 如果仓库现有的测试未执行到存在 Bug 的代码（研究中 33.30% 的真实函数处于全量测试覆盖之外），则追踪引导的定位无法触达目标。这是依赖既有测试的一个结构性限制。
长调用链： 在具有深层执行流水线的项目中（例如构建系统），真实的故障位置可能被埋在频繁调用的编排节点之下。追踪图可能会被这些基础设施层所主导，尽管该位置在技术上是被覆盖的，但会被掩盖。

作者建议未来的工作可以将 IssueExec 与**“问题到测试生成”**技术相结合，以针对测试覆盖不足的情况合成触发 Bug 的测试，从而扩展该范式的适用性。