Page 250 - 《软件学报》2026年第4期
P. 250

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


                    GitHub 是目前最流行的开源项目管理平台之一, 凭借其完整的版本控制、便捷的协作工具和丰富的社区资
                          [1]
                 源, 吸引了大量开发者和团队的参与, 汇聚了大量的开源项目. 为了满足团队协作的需求, GitHub                         引入了问题报告
                 (issue) 跟踪功能, 开发者可以便捷地报告、追踪、管理问题和功能请求. GitHub                 中的问题报告通常包含标题、问
                 题描述、代码上下文、问题报告状态和评论等内容, 开发者可以根据这些信息编写代码补丁, 以解决问题报告中
                 提出的问题或实现新的功能特性. 问题报告跟踪功能极大地简化了团队间的沟通并降低协作开销, 提高了软件开
                 发的整体效率和质量.
                    在解决   GitHub  问题报告时, 测试用例起着至关重要的作用. 一方面, 测试用例需要复现问题报告中描述的问
                 题场景, 帮助问题报告贡献者更好地理解该问题; 另一方面, 测试用例通过设置断言等方式来预测正确的执行结
                 果, 从而验证问题报告是否得到解决. 本文将用于复现问题报告所描述问题并验证问题报告是否解决的测试用例
                 称为“故障复现测试用例”. 当故障复现测试用例在补丁提交前的代码上运行失败, 而在补丁提交后的代码上运行
                 通过时, 表明问题报告贡献者提交的代码补丁成功地解决了给定的问题报告.
                    然而, 由于   GitHub  中问题报告的报告格式和内容缺乏固定的约束, 许多问题报告在提交时通常未附带故障复
                 现测试用例. 因此, 问题报告贡献者在提交解决该问题报告的代码补丁之外, 还需额外编写故障复现测试用例补
                 丁, 以复现并验证该问题报告是否解决, 这无疑增加了开发人员的工作负担. 为了进一步验证                            GitHub  问题报告中
                 故障复现测试用例不足的现象, 本文在             SWE-bench Lite 数据集上进行了实证研究, 分析并统计了该数据集中
                                                             [2]
                 300  个  GitHub  问题报告中缺乏故障复现测试用例的数量. 结果表明, 300           个  GitHub  问题报告中有  268  个在提交时
                 未包含故障复现测试用例, 反映出           GitHub  问题报告在故障复现测试用例方面存在显著不足. 为了解决这一问题,
                 本文提出了一种基于大语言模型的故障复现测试用例生成方法, 旨在自动化地为                           GitHub  问题报告生成故障复现
                 测试用例, 从而减轻问题报告贡献者的工作负担, 并提高                GitHub  问题报告的解决效率.
                    现有的故障复现测试用例生成方法主要采用基于覆盖率                    [3] 、模型检查  [4] 和符号执行  [5] 等技术方法, 这些方法
                 通常依赖于错误栈追踪信息. 然而, GitHub          问题报告中并不直接提供此类信息, 因此这些方法无法直接应用于
                 GitHub  问题报告中的故障复现测试用例生成任务. 为了解决这一问题, Kang                 等人  [6] 提出的  Libro  方法采用大语言
                 模型和   few-shot 技术生成故障复现测试用例. 该方法通过在            prompt 中提供固定的问题描述和对应的故障复现测
                             [7]
                 试用例, 帮助大语言模型理解故障复现测试用例的内容. 然而, Libro                 方法仅为大语言模型提供简单且固定的输入
                 输出样本, 缺乏与     GitHub  问题报告相关的上下文信息, 未能从根本上提高模型对问题报告内容的理解, 并不能很
                 好地解决复杂的问题报告.
                    为了解决面向      GitHub  问题报告的故障复现测试用例生成问题, 尤其是针对问题报告复杂性和缺乏上下文信
                 息等难点, 本文提出了一种基于大语言模型的故障复现测试用例生成方法. 该方法结合大语言模型、检索增强生
                 成和提示工程技术, 旨在自动化地为           GitHub  问题报告生成故障复现测试用例. 具体来说, 给定一个              GitHub  问题报
                 告, 本文在其所在代码仓库中检索           3  类关键信息: 问题报告描述中的报错根函数、与问题报告相关的                   import 语句
                 和与问题报告相关的测试用例样本. 首先, 对于问题报告描述中的报错根函数, 本文通过抽取错误栈并找到最后一
                 个项目本身的函数代码, 将其视为问题报告最终出错的位置, 从而实现问题的定位. 其次, 本文通过检索与问题报
                 告最相关的测试文件, 提取其中的          import 语句, 以帮助大语言模型理解项目中实际            API 的调用方式. 最后, 本文从
                 代码仓库中逐级检索与问题报告相关的测试用例样本. 具体而言, 先抽取仓库中的所有测试文件, 并利用大语言模
                 型筛选出与问题报告最相关的测试文件, 然后提取其中的测试函数, 计算测试函数和问题报告标题的                                 embedding
                 相似度, 最终筛选出最相关的测试函数作为样例, 提供给大语言模型以提高测试用例生成的质量. 通过获得上述                                  3
                 类信息, 本文利用提示工程技术将这些信息整合, 构建精确的                   prompt, 引导大语言模型生成能够复现问题报告并
                 验证问题报告是否解决的故障复现测试用例. 该方法通过结合上下文检索和大语言模型生成, 显著提升了故障复
                 现测试用例生成的准确性和有效性.
                    为验证本文方法的可行性和有效性, 本文在               SWE-bench Lite 数据集上与  Libro  方法进行了对比实验. 实验结
                 果显示, 在  SWE-bench Lite 数据集的  300  个  GitHub  问题报告中, Libro  方法仅成功为  20  个问题报告生成了故障
                 复现测试用例, 占比      6.57%; 而本文的方法成功为       67  个问题报告生成了故障复现测试用例, 占比提升至               22.33%.
   245   246   247   248   249   250   251   252   253   254   255