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

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


                 代码库进行索引, 然后根据给定的代码片段在构建的代码库中搜索相关方法体, 最后对搜索出的多个方法体进行
                 聚类和交叉, 得到最终推荐的一组方法体.
                  1.2.4    提示工程
                    提示工程    (prompt engineering) 是一种通过设计和优化输入提示       (prompt) 来引导大语言模型生成所需输出的
                 技术. 它的主要目标是在与大语言模型进行交互时, 通过精心设计的提示, 使模型能够准确理解任务要求, 并生成
                 高质量的响应, 从而实现高效的人机交互. 通过设计合适的提示, 提示工程可以显著提升模型在文本生成、问题回
                 答、代码生成、翻译等任务中的表现.
                    近年来, 研究者们提出了一系列优化             prompt 的策略, 以提升大语言模型的能力. Wei 等人          [34] 提出了思维链
                 (chain-of-thought, CoT) 策略, 通过将问题分解为一系列逻辑步骤, 引导大语言模型逐步完成中间推理过程, 从而提
                 高模型在解决复杂问题时的表现, 并让问题的解决过程更加系统和透明. White 等人                       [35] 提出了结构化提示模式的
                 框架, 这一框架通过将提示按照一定的逻辑结构组织成结构化形式, 让模型能够更清晰地理解任务要求, 并生成高
                 质量的回答. Xu   等人  [36] 提出了  ExpertPrompting  方法, 旨在挖掘大语言模型作为杰出专家回答问题的潜力. 该方法
                 利用上下文学习自动合成每个特定指令的专家身份, 并要求大语言模型以特定专家身份回答问题, 从而提升模型
                 的回答效果. 此外, Brown    等人  [7] 提出了少样本学习    (few-shot learning) 策略, 通过在提示中提供少量示例, 让模型
                 能够学习任务的结构和要求, 从而在执行任务时表现得更加准确和有效. Zhao                       等人  [37] 进一步研究发现, 少样本学
                 习存在不稳定因素, 即样本的选择和顺序都会显著影响大语言模型的准确度. 通过这些不同的优化策略, 提示工程
                 在不断推动大语言模型的能力提升, 扩大了其在各类任务中的应用范围. 本文也在上述研究基础上, 在构建
                 prompt 时, 使用了结构化指令、思维链、设定专家身份、少样本学习等策略, 帮助大语言模型理解问题需求, 充
                 分挖掘大语言模型的能力, 以提升其在故障复现测试用例生成任务上的效果.

                  2   关于  GitHub  问题报告故障复现测试用例不足问题的实证研究

                    为了深入研究      GitHub  问题报告故障复现测试用例不足问题, 本文在            SWE-bench Lite 数据集上进行了实证研
                 究. 本节首先介绍实证研究的方法设计, 然后介绍实证研究的数据来源, 最后介绍实证研究的结果.
                  2.1   实证研究的方法设计
                    本文希望通过对       SWE-bench Lite 数据集中  300  个  GitHub  问题报告进行实证研究, 探索    GitHub  问题报告的
                 故障复现测试用例的数量情况及构建方式. 为此, 本节围绕以下两个核心研究问题                           (research question, RQ) 展开
                 研究.
                    RQ1: GitHub  问题报告在提交时, 缺乏故障复现测试用例的比例如何?
                    RQ2: 若  GitHub  问题报告在提交时没有故障复现测试用例, 开发人员以什么样的方式生成故障复现测试
                 用例?
                    为探究   RQ1, 本文基于   SWE-bench Lite 数据集, 对  300  个  GitHub  问题报告在提交时是否已包含故障复现测
                 试用例进行了统计与分析. 具体而言, 首先, 通过数据集中的                 base_commit 字段, 将问题报告所在的代码仓库回溯
                 至问题报告提交时的代码版本, 以获取问题报告提交时的真实软件环境, 从而避免后续代码修改对测试用例状况
                 的影响. 在此基础上, 进一步检查         base_commit 版本下是否已存在与该问题报告相关的故障复现测试用例. 具体方
                 法是分析   FAIL_TO_PASS  字段, 判断其中列出的测试函数是否已在             base_commit 版本中存在. 如果该版本下至少
                 包含一个与问题报告相关的故障复现测试用例, 则认为该问题报告在提交时已具备故障复现测试用例; 反之, 则判
                 定该问题报告提交时缺乏故障复现测试用例. 最后, 本文统计了                   300  个问题报告中缺乏故障复现测试用例的问题
                 报告数量, 并计算其占比, 以量化        GitHub  问题报告在提交时的故障复现测试用例覆盖情况.
                    为探究   RQ2, 本文针对   RQ1 中发现的提交时缺乏故障复现测试用例的问题报告, 进一步研究其在修复                        commit
                 提交后新增的故障复现测试用例, 旨在探讨问题报告贡献者是如何生成这些故障复现测试用例的. 具体而言, 首
                 先, 通过对比   base_commit 状态的代码仓库版本与问题报告关联的             commit (patch  字段) 提交后的代码仓库版本,
   250   251   252   253   254   255   256   257   258   259   260