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

1698 软件学报 2026 年第 37 卷第 4 期

报告时新编写的, 还是基于仓库中已有测试函数进行修改的. 基于上述 3 个关键字段, 本文将围绕 GitHub 问题报
告的故障复现测试用例是否充足这一问题展开实证研究, 以探讨现有测试用例的覆盖情况及其改进方向.

表 1 SWE-bench Lite 数据集中字段含义

字段名称 字段含义
instance_id 格式化的数据实例标识符, 通常为repo_owner__repo_name-PR-number
repo 问题报告在GitHub中所在仓库, 格式为owner/name
created_at 问题报告所在pull request (PR)创建的日期
version 用于运行评估的安装版本
base_commit 在问题报告解决前, 问题报告所在仓库的commit hash
hints_text 在解决方案PR首次提交日期之前对问题报告所发表的评论
patch 解决方案PR生成的补丁
test_patch 解决方案PR生成的测试文件补丁
problem_statement 问题报告的标题和正文
一个测试用例字符串列表, 测试用例在解决方案PR应用前不通过, 应用后通过, 用来验证问题报告是
FAIL_TO_PASS
否解决
PASS_TO_PASS 一个测试用例字符串列表, 测试用例在解决方案PR应用前后都应通过
environment_setup_commit 环境设置和安装的commit hash

2.3 实证研究的结果分析

在深入探讨两个研究问题之前, 本文首先对 SWE-bench Lite 数据集中的问题报告及其对应的故障复现测试
用例进行了整体分析. 该数据集中的每个问题报告均可通过修改单个代码文件进行修复, 反映了问题报告本身具
有适中的复杂程度. 此外, 与这些问题报告相关的故障复现测试用例均为单元测试, 体现出其关注代码层面功能的
精细验证. 进一步统计发现, 这些故障复现测试用例平均长度为 19.5 行代码, 平均涉及约 2.4 个外部库或内部 API
的调用, 表明其在结构上具有一定的实现复杂度, 需要调用多个组件协同工作. 这些特征为自动化生成故障复现测
试用例提出了挑战, 也为本文方法的设计提供了依据.
针对研究问题 1 (RQ1), 本文对 SWE-bench Lite 数据集进行分析, 统计发现该数据集 300 个问题报告中, 有
268 个问题报告在提交时没有故障复现测试用例, 占比高达 89.33%. 这一现象反映了 SWE-bench Lite 数据集中问
题报告存在故障复现测试用例不足的问题, 也映射出整个 GitHub 问题报告中可能普遍存在类似问题. 许多问题报
告在提交时缺乏相关的故障复现测试用例, 这可能导致开发人员在修复问题报告时无法准确复现和验证问题, 从
而影响软件质量的提升.
进一步分析 GitHub 问题报告缺乏故障复现测试用例的原因, 可以归结为两个主要因素. 首先, GitHub 问题报
告机制本身并未明确要求问题报告提交者在提交时提供相应的故障复现测试用例. 这一机制的缺失使得问题报告
提交者缺乏明确的动机和指引去准备详尽的故障复现步骤. 其次, 编写故障复现测试用例往往是一个相对耗时且
复杂的过程, 涉及对问题的深入理解和对测试环境的精确还原. 因此, 许多问题报告提交者倾向于直接提出问题,
而不愿意投入额外的时间和精力来编写相应的验证方法. 这种情况下, 故障复现测试用例的缺失成为影响问题修
复效率和质量的一个重要因素. 基于此, 本文将深入研究面向 GitHub 问题报告的故障复现测试用例生成方法, 探
索如何自动生成适用于 GitHub 问题报告的故障复现测试用例, 以解决这一关键问题.
针对研究问题 2 (RQ2), 本文对问题报告提交后新生成的故障复现测试用例进行了分析. 结果显示, 在 300 个
问题报告中, 共有 440 个新生成的故障复现测试用例. 其中, 179 个故障复现测试用例是通过修改代码仓库中已有
的测试函数生成的, 占比 40.68%; 261 个故障复现测试用例是由开发人员全新编写的, 占比 59.32%. 这一结果表
明, 在为问题报告生成故障复现测试用例时, 几乎有一半的机会可以通过修改现有的测试函数来实现, 反映出了现
有相关测试用例对于生成故障复现测试用例的作用.
进一步分析这一现象, 本文发现可以通过复用原有测试文件中的 import 语句和已有的测试用例来生成新的