文章总结： 本文针对GitHub问题报告中近90%缺乏故障复现测试用例的问题，提出一种基于大语言模型（LLM）与多元检索增强生成的自动化生成方法。该方法通过检索报错根函数、import语句及测试用例样本等上下文信息构建精确prompt，引导LLM生成有效测试用例。实验表明，该方法在SWE-benchlite数据集上将成功生成比例从6.57%提升至22.33%，消融实验证实测试用例样本贡献最大，未来可扩展至多语言并增强可解释性。 综合评分： 88 文章分类： 安全开发,应用安全,安全工具

基于大语言模型的故障复现测试用例生成方法 | jos佳文

CodeWisdom

2026年5月29日 20:30 上海

在小说阅读器读本章

去阅读

文章题目: 基于大语言模型的故障复现测试用例生成方法

全部作者: 汪莹, 字千成, 彭鑫, 娄一翎

第一单位: 复旦大学 计算机科学技术学院

出版时间: 2026, 37(4): 1690–1714

摘

/

要

ABSTRACT

ABSTRACT

GitHub是目前最流行的开源项目管理平台之一. 由于团队协作的需要, GitHub引入了问题报告跟踪功能以方便项目使用者提交和追踪项目中出现的问题或新功能请求. 问题报告贡献者在解决问题报告时, 通常需要执行故障复现测试用例来复现问题报告中提到的问题并验证问题报告是否解决. 然而, 在SWE-bench Lite数据集上进行实证研究发现, 有近90%的问题报告在用户提交时没有附带故障复现测试用例, 这导致问题报告贡献者在解决问题报告时还需额外编写故障复现测试用例, 带来了额外的工作负担. 现有的故障复现测试用例生成技术通常依赖错误栈信息, 然而GitHub问题报告中并未明确要求有这类信息. 因此, 提出基于大语言模型的故障复现测试用例生成方法, 旨在自动化地为GitHub问题报告生成故障复现测试用例, 帮助问题报告贡献者复现、理解并验证问题报告, 提升问题报告解决效率. 该方法首先通过检索与问题报告相关的多样化代码上下文信息, 包括报错根函数、import语句和测试用例样本, 随后构建精确的prompt, 以引导大语言模型生成有效的故障复现测试用例. 开展对比实验和消融实验, 验证所提方法在面向GitHub问题报告的故障复现测试用例生成任务上的有效性.

扫码阅读全文

内

/

容

/

精

/

选

CONTENT

CONTENT

1 方法概述

本文提出了一种基于大语言模型和多元检索增强生成的故障复现测试用例生成方法, 旨在为GitHub问题报告等类似的软件开发问题生成故障复现测试用例. 该方法的核心思想是基于给定的问题报告内容和代码仓库, 挖掘多元的上下文信息, 包括报错根函数、import语句和测试用例样本等, 通过使用提示工程技术, 构建prompt来引导大语言模型生成故障复现测试用例. 图1展示方法的框架.

图1 基于大语言模型和多元检索增强生成的故障复现测试用例生成方法框架图

① 报错根函数定位

本文将报错调用链中最后一个在代码仓库中的函数定义为报错根函数. 如图2所示, 展示了Django仓库的一个问题报告描述, 其中包含了相关的错误栈信息. 基于启发式经验, 本文认为只有在问题报告所在仓库中的函数才可能是导致问题的原因, 因此不考虑第三方库调用的函数.

图2 GitHub问题报告描述中错误栈举例图

本文采用基于规则的方法来实现报错根函数的定位, 分为两步: 抽取报错根函数信息和根函数定位.

• 在抽取报错根函数信息阶段, 首先使用字符串处理方法识别问题报告描述中的“Traceback”字符串, 以判断是否包含错误栈信息, 并提取所有相关的错误栈内容. 接着, 利用正则表达式逐行解析错误栈, 提取每一行中的报错文件、报错代码行和报错函数信息. 最后, 过滤掉第三方库调用的函数, 仅保留最后一个报错函数作为报错根函数.
• 在根函数定位阶段, 首先将问题报告所在的仓库克隆到本地, 并根据该问题报告的 base_commit信息切换到问题报告提出时的版本. 随后, 使用tree-sitter工具, 根据抽取出的报错文件和报错根函数名, 提取报错根函数的内容. 如图3所示, 后续将用于构建 prompt, 为大语言模型提供问题报告的报错信息.

图3 报错根函数定位示意图

② 测试文件选择与import语句抽取

本文设计了测试文件选择与import语句抽取的方法, 旨在通过检索与问题报告最相关的测试文件, 充分利用其中的现有信息, 从而提升大语言模型的故障复现测试用例生成效果.

(1) 测试文件选择

为了避免将代码文件错误地抽取出来, 本文为每个代码仓库人工设计了一套测试文件判断规则, 如表1所示. 基于这些规则, 本文遍历每个代码仓库中的所有Python文件, 抽取出所有符合条件的测试文件路径.

表1 SWE-bench Lite数据集中各个代码仓库测试文件判断规则

在prompt构建阶段, 本文决定仅将问题报告标题作为依据, 避免将所有描述信息纳入prompt, 以提升测试文件选择的准确率. 具体而言, 本文将GitHub问题报告的标题与经过截取的测试文件路径列表作为输入, 结合适当的提示信息, 构建结构化的prompt.

图4展示了一个具体的测试文件选择prompt的例子. 本文首先对Django仓库的所有测试文件进行了抽取, 并对每个测试文件的路径进行了截取处理, 将保留后的路径信息以列表形式嵌入到prompt中. 大语言模型在接收到该prompt后, 成功选择了正确答案. 这一结果不仅验证了大语言模型在处理粗粒度文件检索任务时的有效性, 也展示了通过合适的prompt设计, 可以显著提高模型的选择准确性.

图4 测试文件选择prompt示意图

(2) import语句抽取

故障复现测试用例生成任务面临的一个主要挑战在于, 输入的上下文是整个代码仓库, 这往往导致上下文信息过长, 使得大语言模型在理解整个文件结构时变得困难. 这种情况下, 模型可能无法正确调用仓库中已有的API接口, 从而影响生成故障复现测试用例的质量. 为了解决这一问题, 本文在选择出最可能测试给定问题报告的测试文件后, 特别提取了该测试文件中的import语句.

这一做法的双重目的在于:

• 提供给大语言模型可能使用的API信息, 增强其调用的准确性;
• 通过分析import语句中的引用路径, 帮助模型更好地理解代码仓库的结构和关系

在图4的基础上, 本文利用正则表达式匹配技术成功抽取了该测试文件中的所有import语句, 如图5所示. 在大语言模型生成故障复现测试用例后, 本文只需在该测试文件的相同路径下创建一个新的测试文件, 将生成的故障复现测试用例放入其中. 由于已抽取的import语句包含了所需的API, 这样的处理避免了潜在的语法错误. 本文通过这一方式, 旨在降低大语言模型在生成故障复现测试用例时出现的API调用语法错误, 从而提高故障复现测试用例生成的准确性和有效性.

图5 import语句抽取结果示意图

③ 基于相似度计算的测试用例样本选取

在选出最可能测试给定问题报告的测试文件后, 本文采用基于相似度计算的方法在该测试文件中选取测试用例样本, 旨在从已有的代码仓库中检索出与测试给定问题报告相关的测试函数. 该方法具体分为两个主要步骤:

• 测试函数的抽取. 首先, 将大语言模型选择出的截取后的测试文件路径还原为完整路径, 并根据问题报告的base_commit信息将克隆后的代码仓库恢复到问题报告提出时的版本. 然后, 根据还原后的文件路径定位到相应的测试文件, 并将该文件的全部内容读取为一个字符串. 获得测试文件中的完整代码后, 通过分析各个代码段的节点属性, 成功提取出测试文件中所有的测试函数. 这些提取的函数片段将以字符串列表的形式保存, 便于后续的相似度计算与排序过程.
• 基于相似度计算的测试用例样本选取. 本文采用稠密检索方法中的基于embedding的相似度计算. 具体而言, 对抽取出的每个测试函数的代码字符串与问题报告标题之间计算embedding相似度得分. 根据这些相似度得分, 对抽取出的测试函数进行排序, 最终选取得分最高的3个测试函数作为测试用例样本.

图6展示了本文抽取的测试用例样本, 将所有测试函数与问题报告标题进行了embedding相似度计算, 最终得分最高的3个测试函数见图6.

图6 测试用例样本示意图

④ 故障复现测试用例生成

在设计prompt时, 本文采用了多种提示工程领域的策略, 以提升大语言模型的理解能力和生成质量. 如prompt 2所示.

• 首先, 本文将prompt设计为结构化形式, 这样能够更清晰地描述多个方面的内容, 增强模型对问题的理解.
• 其次, 本文采用了few-shot方法, 通过在prompt中提供与期望输出类似的例子, 帮助大语言模型更好地理解需求, 从而生成高质量的结果.
• 此外, 本文还运用了大语言模型角色扮演策略, 明确告诉模型它是一位软件测试专家, 擅长根据需求生成故障复现测试函数, 通过这种角色设定来挖掘模型的潜在能力.
• 最后, prompt中还运用了思维链方法, 将故障复现测试用例生成这一复杂任务拆分为4个步骤: 理解问题的主要内容、分析造成问题的原因、思考预期的正常表现及其测试方式, 最终生成故障复现测试用例.

2 实验分析

本文将围绕以下3个问题展开实验验证.

• RQ1: 本文提出的方法是否优于现有方法?
• RQ2: 本文方法中检索增强生成的 3 部分内容各自的作用如何?
• RQ3: 本文检索增强生成的内容准确性如何?

① 测试用例生成效果对比 (RQ1)

表2详细展示了对比实验结果. 针对SWE-bench Lite数据集中的300个GitHub问题报告, 实验结果表明, 基于给定问题报告检索报错根函数、import语句和测试用例样本等内容的方法是有效的, 进一步证明了本文方法的有效性.

表2 本文方法与Libro方法的故障复现测试用例生成评估指标对比

②消融实验 (RQ2)

本文在使用检索增强生成策略时共检索了3部分内容, 包括报错根函数、import语句和测试用例样本. 消融实验结果如表3所示. 这些结果表明, 本文检索增强生成的3部分内容对故障复现测试用例生成均发挥了积极作用, 且其中测试用例样本的贡献最大.

表3 消融实验结果

本文观察到, 在某些情况下, 去除报错根函数的方法效果优于本文提出的方法. 该结果表明, 基于GitHub问题报告中的错误栈信息抽取报错根函数可能会误导大语言模型, 从而降低其测试用例生成的效果. 这进一步说明, GitHub问题报告中的错误栈根函数信息可能并不总是导致问题的根本原因, 反映出了GitHub问题报告的复杂性.

③ 检索增强生成内容准确性分析 (RQ3)

表4展示了本文在SWE-bench Lite数据集中检索测试文件和测试用例样本的准确性结果. 这些结果反映出本文检索方法的有效性, 能够为给定问题报告提供相关的代码上下文信息, 从而提升大语言模型对问题报告的理解能力, 进而增强故障复现测试用例的生成效果.

表4 检索到的测试文件和测试用例样本准确性结果

3 总结与展望

本文通过实证研究发现, 当前GitHub问题报告中普遍存在故障复现测试用例不足的问题, 导致开发者在提交解决问题报告的代码补丁时, 还需额外提交用于复现问题报告并验证问题报告是否解决的测试用例补丁, 从而增加了开发者的工作负担. 为了解决这一问题, 本文提出了一种结合大语言模型和检索增强生成的故障复现测试用例生成方法. 该方法首先通过检索与问题报告相关的多元代码上下文信息, 包括报错根函数、import语句和测试用例样本, 随后构建精确的prompt, 以引导模型生成有效的故障复现测试用例. 在与现有的Libro方法进行对比实验时, 本文的方法显著优于Libro, 成功生成故障复现测试用例的问题报告比例从6.57%提升至22.33%. 此外, 消融实验进一步表明, 本文检索增强生成的3部分内容对故障复现测试用例生成均发挥了积极作用, 其中测试用例样本的贡献最大. 尽管本文方法在故障复现测试用例生成任务中展现了有效性, 但仍有改进空间, 未来的展望如下.

(1) 提升方法的有效性. 未来可以挖掘更多有价值的信息, 当面对项目中测试函数样本不足的情况时, 可以检索其他与问题报告相关的上下文信息, 包括代码注释、项目历史提交记录、开发者评论以及项目文档等, 为大语言模型提供更丰富的背景信息和开发者意图, 从而提升故障复现测试用例的生成质量. 同时, 可以优化检索策略, 以提高检索内容的准确性, 从而更好地辅助模型理解问题报告, 提升故障复现测试用例生成效果.

(2) 提升方法的通用性. 未来, 可以考虑将本文方法扩展到其他编程语言的GitHub问题报告, 例如Java、C、C++等. 此外, 本文的方法也可考虑应用于本地代码仓库中, 用户只需提交问题报告描述和代码仓库路径, 便可自动生成故障复现测试用例.

(3) 提升方法的可解释性. 未来可以考虑在生成故障复现测试用例的同时, 让模型解释测试用例的信息来源及其与问题报告的关联. 此外, 还可以考虑建立用户反馈机制, 允许用户对生成的测试用例进行评价与反馈, 增强用户对测试用例的理解和信任.

作

/

者

/

简

/

介

AUTHOR

AUTHOR

汪莹, 硕士生, 主要研究领域为智能化软件开发.

字千成, 硕士生, 主要研究领域为智能化软件开发.

彭鑫, 博士, 教授, 博士生导师, CCF 杰出会员, 主要研究领域为智能化软件开发, 云原生与智能化运维, 泛在计算软件系统.

娄一翎, 博士, 副研究员, 主要研究领域为智能化软件工程, 软件测试与分析.

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CodeWisdom 《基于大语言模型的故障复现测试用例生成方法 | jos佳文》