Page 252 - 《软件学报》2026年第4期

汪莹 等: 基于大语言模型的故障复现测试用例生成方法 1693

都有对应的故障复现测试用例, 从而提高了数据集的可验证性和完整性. 同时, Jimenez 等人 [8] 还提出了一个评估
框架, 给定一个代码库以及要解决的问题描述, 大语言模型的任务是编辑代码库以解决问题, 并在与该问题报告相
关的故障复现测试用例上进行测试, 验证问题报告是否解决. 解决 SWE-bench 中的问题通常需要同时理解和协调
多个函数、类甚至文件的更改, 要求模型与执行环境交互, 处理极长的上下文并执行远远超出传统代码生成的复
杂推理. 因此, SWE-bench 数据集中每个数据实例的运行需要消耗大量时间和计算资源. SWE-bench Lite 是 SWE-
bench 数据集的子集, 其在 SWE-bench 数据集中挑选了 300 个典型实例, 侧重评估独立的功能性错误修复, 降低了
实验开销.
SWE-bench 数据集凭借其高度的挑战性和实际应用价值, 吸引了众多研究者在其上开展自动化代码修复的研
[9]
究. 首先, Jimenez 等人 [8] 在构建 SWE-bench 数据集的同时, 提出了一种微调 Code LLaMA 模型以生成解决
GitHub 问题报告的代码补丁的方法. 该方法将 GitHub 问题报告的问题描述和相关代码文件作为输入, 以解决给
定问题报告的代码补丁作为输出, 从而对 Code LLaMA 模型进行微调, 实现自动化代码修复. 随着大语言模型能力
的不断提升, 许多研究开始将大语言模型作为智能代理 (agent), 利用其解决 GitHub 问题报告中的问题. 例如,
Yang 等人 [10] 提出了 SWE-agent 方法, 这是一种利用大语言模型与计算机交互来完成软件工程任务的自主系统.
SWE-agent 通过为智能代理提供丰富的接口, 使其能够与计算机深度互动, 执行创建和编辑文件、定位代码仓库
中的问题、执行测试用例等操作. 该系统能够在接收到相关需求后, 自主决策并逐步生成代码补丁. 另一方面,
Zhang 等人 [11] 提出了 AutoCodeRover 方法, 将大语言模型与代码搜索结合, 用于自动生成解决问题报告的代码补
丁. AutoCodeRover 的核心包括两个阶段: 上下文检索和补丁生成. 在上下文检索阶段, 智能代理根据问题报告信
息, 通过检索接口搜索与问题报告高度相关的 API, 以获取丰富的上下文信息. 在补丁生成阶段, 智能代理依据补
丁应用的反馈结果, 判断生成的补丁是否合适, 并进一步优化, 直到补丁成功解决问题报告或达到优化次数上限.
除了智能代理方法外, Xia 等人 [12] 提出了 Agentless 方法, 这是一种简化的解决方案, 采用了两阶段过程: 定位和修
复. 与复杂的基于智能代理的方案不同, Agentless 不需要让大语言模型做出未来行动的决策或使用复杂的工具.
具体来说, 在定位阶段, 系统从粗粒度到细粒度地检索信息; 而在修复阶段, 利用检索到的信息生成多个补丁, 并借
助 SWE-bench 数据集中的测试函数进行筛选, 最终通过重排序选取最佳补丁作为代码修复方案. 通过这种简化流
程, Agentless 在保证修复效果的同时, 显著降低了系统的复杂度.
由上述研究可见, GitHub 问题报告的自动修复任务引起了研究者们的广泛关注. 然而, 在生成给定 GitHub 问
题报告的代码补丁后, 现有的研究通常需要依赖 SWE-bench 数据集中提供的故障复现测试用例 (在 SWE-bench
数据集中为 fail-to-pass 测试用例) 来复现问题报告中描述的问题, 并验证生成的代码补丁是否正确. 这一过程突显
了故障复现测试用例在解决 GitHub 问题报告任务中的重要性. 因此, 为了进一步探讨 GitHub 问题报告中故障复
现测试用例的现状, 本文在 SWE-bench Lite 数据集上进行了实证研究. 研究结果表明, 在 SWE-bench Lite 数据集
的 300 个 GitHub 问题报告中, 有 268 个在报告时未附带故障复现测试用例, 占比高达 89.33%. 在这些问题报告中,
大多数故障复现测试用例是由问题报告贡献者在解决问题报告时额外编写, 或是在原有的代码仓库测试用例基础
上修改而来. 这一现象反映出 GitHub 问题报告在故障复现测试用例方面存在明显的不足, 给问题报告贡献者带来
了额外的工作负担. 针对这一问题, 本文展开了深入研究, 并提出了自动生成 GitHub 问题报告故障复现测试用例
的有效解决方案.
1.2 相关工作
1.2.1 测试用例生成
在软件开发过程中, 测试用例是验证软件功能和性能是否符合预期的重要工具, 发挥着至关重要的作用. 通过
对各个功能模块执行测试用例, 开发团队能够有效发现并修复潜在的缺陷, 从而提升软件的质量和可靠性. 然而,
手动编写测试用例既费时又费力, 并且需要大量的人力成本. 因此, 许多研究工作集中于自动化生成测试用例, 以
便开发者可以专注于更具创新性的任务, 从而提升软件开发效率.
传统的测试用例生成技术通常使用基于搜索、基于约束和基于随机等策略来提高测试覆盖率. 基于搜索的测