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

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

试 (search-based testing) 利用搜索算法生成测试用例, 旨在通过智能搜索策略提升测试效率与覆盖率. 其核心思想
是将测试用例生成视为一个优化问题, 通过定义适应度函数 (fitness function) 来评估测试用例的质量, 以引导搜索
过程. 例如, Fraser 等人 [13] 提出的 EvoSuite 工具通过遗传算法生成测试用例, 首先定义适应度函数以评估测试用例
质量, 然后随机生成一组初始测试用例, 接着通过选择、交叉和变异操作不断优化适应度函数, 迭代生成新的测试
用例, 直到达到预设的覆盖率或迭代次数. Baars 等人 [14] 提出了一种构建适应度函数的算法, 该算法将符号信息与
动态分析相结合, 可在尝试生成分支充分测试数据时提高基于搜索的测试的效率. 基于约束的测试 (constraint-
based testing) 通过定义特定约束条件生成测试用例, 其核心在于使用约束求解器自动生成满足约束的输入, 从而
确保测试用例覆盖了特定的程序行为或代码路径. 例如, Blasi 等人 [15] 提出的 CallMeMaybe 方法使用自然语言处
理技术分析 Javadoc 注释, 从中识别时间约束, 并指导测试用例生成器执行遵守时间约束的方法调用序列. DeMilli
等人 [16] 开发的 Godzilla 工具则使用代数约束描述旨在发现特定类型故障的测试用例, 自动生成并解决约束以创建
单元和模块测试用例. 基于随机测试 (random-based testing) 则主要通过随机生成输入数据来测试程序行为. 这种
随机生成测试用例的方法通常效果不佳, 因此 Pacheco 等人 [17] 通过结合从执行测试输入中获得的反馈改进了生成
效果. 传统的 3 类测试用例生成方法都旨在提升测试用例的测试覆盖率, 测试覆盖率工具主要关注的是代码路径,
然而由于 GitHub 问题报告均来自实际软件开发场景, 往往只提供问题描述和上下文信息, 缺少必要的代码路径信
息, 难以用测试覆盖率来进行测试. 因此, 传统测试用例生成方法在面向 GitHub 问题报告时存在较大的局限性.
随着深度学习技术的发展, 近年来许多研究在传统测试用例生成技术的基础上, 引入模型作为辅助, 取得了显
著效果. Dinella 等人 [18] 提出了 TOGA 方法, 这是一种基于 Transformer 的神经方法 (neural approach), 可以根据焦
点方法的上下文推断异常和断言测试预言. Schafer 等人 [19] 则尝试利用 API 文档的信息来增强模型对代码的理解,
通过在模型输入中添加额外的文档信息, 从而生成更有效的单元测试. 上述方法利用深度学习技术, 将模型在大量
代码数据上进行训练, 使模型具备了从上下文推断潜在异常和测试预言的能力, 在一定程度上克服了传统测试用
例生成方法中对特征依赖较强、难以泛化的问题. 随着大语言模型的出现, Yuan 等人 [20] 采用大语言模型技术, 通
过迭代反馈生成测试函数, 不断将报错信息反馈给模型, 直到没有错误反馈或达到迭代次数上限. 然而, 由于 GitHub
问题报告没有明确的内容规范要求, 其通常缺乏明确的报错信息或 API 文档, 无法直接给模型提供额外上下文信
息. 此外, 在解决 GitHub 问题报告时, 模型需要同时理解和协调多个函数、类甚至文件的更改, 并处理极长的上下
文, 推理难度远远超出模型的能力范围, 因此这些方法在实际应用中并不十分适用.
针对故障复现测试用例生成的问题, 已有一些研究提出了相应的解决方案. Soltani 等人 [3] 提出了基于搜索的
EvoCrash 方法, 用于生成复现崩溃的测试用例. 该方法通过一个适应度函数引导搜索过程, 适应度函数结合了 3
种启发式方法: 代码覆盖率、崩溃覆盖率以及错误栈相似度. 此外, EvoCrash 还探索了多目标优化方法, 以提高生
成测试用例的多样性. Nayrolles 等人 [4] 提出的 JCHARMING 方法结合崩溃追踪和模型检查, 旨在通过自动化手段
复现软件崩溃. 该方法首先分析崩溃堆栈数据, 识别与崩溃相关的程序状态, 并利用模型检查技术进一步确认哪些
程序语句是复现崩溃所必需的, 进而复现程序崩溃. Chen 等人 [5] 则提出了一种基于收集到的崩溃栈追踪的崩溃复
现框架, 该框架结合了高效的逆向符号执行和创新的序列方法组合技术, 生成能够复现原始崩溃的单元测试用例,
并且避免了增加额外的运行时开销. 在该框架中, 逆向符号执行用于分析崩溃栈, 识别复现崩溃所需的关键执行路
径, 而序列方法组合则帮助生成准确的单元测试用例. 上述研究均聚焦于程序崩溃的复现技术, 其方法都依赖于崩
溃栈追踪信息, 然而 GitHub 问题报告中并不直接提供此类信息, 因此这些方法不适用于解决 GitHub 问题报告中
的故障复现测试用例生成问题.
[7]
为解决这一问题, Kang 等人 [6] 提出的 Libro 方法使用大语言模型和 few-shot 技术生成故障复现测试用例. 该
方法通过在 prompt 中提供固定的问题描述和对应的故障复现测试用例, 帮助大语言模型理解如何生成测试用例.
然而, Libro 方法仅为大语言模型提供简单且固定的输入输出样本, 缺乏与 GitHub 问题报告相关的上下文信息, 未
能从根本上帮助模型更好地理解问题报告内容. 此外, 现有一些基于智能代理 (agent) 的研究, 如 SWE-agent [10] 、
OpenDevin [21] 、CodeR [22] 等, 也在解决 GitHub 问题报告的过程中关注了故障复现问题. 这些方法均依赖于大语言
模型和 prompt 技术, 通过向智能代理提供 GitHub 问题报告的问题描述, 要求其生成复现问题报告的代码, 进而帮