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

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


                  3.4   故障复现测试用例生成
                    随着大语言模型的不断发展, 其在代码理解和生成任务上的表现日益出色. 与此同时, 提示工程技术在应用大
                 语言模型时发挥着重要作用, 通过精心设计的提示, 引导模型产生期望的输出. 基于这一背景, 本文使用了大语言
                 模型和提示工程技术生成面向           GitHub  问题报告的故障复现测试用例, 所选用的大语言模型为                  OpenAI 提供的
                 GPT-4  模型. 具体而言, 如上文所述, 本文首先检索与给定问题报告相关的报错根函数                      (如问题报告描述中包含错
                 误栈)、import 语句以及测试用例样本. 随后, 结合提示工程领域的相关策略, 构建一个引导大语言模型生成故障
                 复现测试用例的      prompt. 最终, 将该  prompt 输入大语言模型, 以生成复现给定问题报告并验证问题报告是否解决

                 的故障复现测试用例.
                    在设计   prompt 时, 本文采用了多种提示工程领域的策略, 以提升大语言模型的理解能力和生成质量. 如
                 prompt 2  所示, 首先, 本文将  prompt 设计为结构化形式, 这样能够更清晰地描述多个方面的内容, 增强模型对问题
                 的理解. 其次, 本文采用了      few-shot 方法, 通过在  prompt 中提供与期望输出类似的例子, 帮助大语言模型更好地理
                 解需求, 从而生成高质量的结果. 在         prompt 2  中, 本文包含了一个   example_tests 字段, 列出了在代码仓库中检索出
                 的与给定问题报告相关的         3  个测试函数, 作为已有测试用例的参考信息. 此外, 本文还运用了大语言模型角色扮演
                 策略, 明确告诉模型它是一位软件测试专家, 擅长根据需求生成故障复现测试函数, 通过这种角色设定来挖掘模型
                 的潜在能力. 最后, prompt 中还运用了思维链方法, 将故障复现测试用例生成这一复杂任务拆分为                          4  个步骤: 理解
                 问题的主要内容、分析造成问题的原因、思考预期的正常表现及其测试方式, 以及最终生成故障复现测试用例.
                 通过这种方式, 大语言模型能够逐步完成复杂的任务, 提升测试用例生成的质量. 总之, 为解决故障复现测试用例
                 生成这一复杂任务, 本文在        prompt 中采用了多种提示工程策略, 期望通过一系列的优化, 能够让大语言模型更好
                 地理解用户需求、生成准确且高质量的测试用例, 从而提升故障复现软件测试的效率和效果.

                 prompt 2. 生成测试给定问题报告的故障复现测试用例.
                 # {issue_title}
                 ## Issue Description
                 {issue_description}
                 ## Bug Context
                 {bug_context}
                 ## Imports List
                 {imports_list}
                 ## Example Tests
                 {example_tests}
                 ## Introduction of a Test Case
                 A test function can be thought of as containing three parts:
                 The first part is the preconditions that the test case must meet. For a certain test case, you must first build the
                 preconditions it needs to use. For example, you must create an object of a certain class and set some properties on it.
                 Otherwise, subsequent tests will not be able to proceed or the expected results will be obtained.
                 The second part is the steps required to execute the current test case, which usually includes necessary assignments, a
                 series of API calls, etc. The lines of code that exist in steps that can trigger bugs are called critical lines of code.
                 The third part is the expected execution result of the test case, usually corresponding to the assert statement
                 ## Generate one test.
                 You are an expert in software testing, you are really good at writing test cases and test functions given a requirement.
                 Now I will offer you an issue from GitHub as well as the code context the issue relates to.
   259   260   261   262   263   264   265   266   267   268   269