用于软件测试的大语言模型：研究路线图·下

用于软件测试的大语言模型：研究路线图·下（中文全译）

本文是下篇，内容为第 6–7 节与署名许可。上篇（摘要至第 5 节）：用于软件测试的大语言模型：一份研究路线图·上。翻译说明与许可信息见上篇开头及本篇结尾。

6. 基于 LLM 的测试研究挑战与预期影响

下面，我们分析 LLM 给软件测试研究带来的挑战和机会。具体来说，我们的分析组织在 6.1 和 6.2 两节中，分别处理 RQ3 和 RQ4。

6.1 基于 LLM 的测试研究路线图

基于我们对基于 LLM 的软件测试文章的概览，我们在本节提出一份研究路线图。图 9 描绘了一个概念框架，建模我们路线图覆盖的主要行动者和它们可被卷入的阶段。

确切地说，行动者代表在基于 LLM 的测试活动中协作的主要实体，即：Ⓐ LLM，Ⓑ 测试工程师（或简称测试者），Ⓒ 交互中所指的环境。我们还考虑三个主要阶段，在图 9 中表示为蓝框：准备、交互和验证。准备阶段（图 9 ①）指在任何行动者间协作开始之前执行的设置活动。接着，交互阶段（图 9 ②）涉及要求不同行动者通过相互影响来协作的活动。最后，验证阶段（图 9 ③）检查所达成的结果和所暴露的行为是否符合预期。图 9 中每个箭头建模我们识别的一个特定研究挑战，它在给定阶段影响给定行动者。实线箭头表示与技术方面相关的挑战，虚线箭头表示与人为因素相关的社会挑战。

下面我们详细讨论所有这些挑战：首先按阶段报告技术挑战（即 6.1.1、6.1.2 和 6.1.3 节）；然后概述我们遇到的社会挑战（即 6.1.4 节）。

#### 6.1.1 准备

准备阶段涉及配置模型，如恰当设置它们的参数、为在特定测试语境中改进性能而微调它们，以及处理用于训练和测试的数据。虽然标准配置的通用 LLM 在基于 LLM 的测试中展示了有前景的能力，但为改进其性能和结果出现三个关键挑战：（1）选择最优配置设定，（2）如何有效微调模型，（3）如何管理数据问题以确保公平可靠的评估。详述如下：

• 配置：虽然用特定配置已得到有前景的结果，若干作者明确把探索更多配置识别为开放挑战。具体来说，一些研究者指出需要在更广范围模型上做更多研究。相反，其他聚焦于其 LLM 模型的参数化。例如，温度值和窗口大小等设定的影响被指出是需要进一步研究的领域。类似地，超参数调优对模型性能的影响代表另一个需要调查的方向。一个相关研究挑战是评估在更多编程语言或测试框架内使用 LLM。一些研究报告 LLM 用于测试某些语言的软件时表现好，但其他语言时不好。其他研究暗示语言相关的性能退化可通过最小微调来缓解。理解不同配置和编程语言之间的交互，包括参数调优和不同模型的选择，及其对结果的影响，仍是基于 LLM 的测试中的开放挑战。

• 微调：关于基于 LLM 的测试中微调的研究仍在进行。虽然微调模型已在所有类别中被探索并有有前景的结果，若干挑战仍未解决。若干文章把微调识别为基于 LLM 的测试的关键研究前沿。一方面，若干作者预期从其基于 LLM 的方法中精炼和微调模型得到未来改进。另一方面，人们普遍承认不正确的微调会损害模型性能并导致灾难性遗忘，即模型失去先前获得的知识。最决定性的因素常是微调期间使用的数据：高质量且相关的输入数据仍是若干作者承认的挑战。这些工作也承认，如果数据收集是人工策划的（如为其标注）或需要领域特定知识，开发模型的成本会急剧增加。在性能方面，一些发现表明更小的微调模型能超越更大的通用 LLM。这一竞争优势有缺点：微调通常需要访问专门硬件或云基础设施，而特定知识并不总存在于测试团队中。减少 LLM 所用资源的一个研究方向，是用为解决一个任务（如一种编程语言）而获得知识的计算来解决一个不同但相关的任务。这意味着探索一个语境中微调模型在另一语境的适用性。微调中的权衡涉及平衡精度、成本和灵活性，带来未来研究机会。这一挑战的研究可调查是为特定任务开发专门工具，还是开发通过提示工程跨各种语境适配的通用模型。

• 数据问题：基于 LLM 的测试中的一个关键挑战在于数据泄漏问题，在文献中被广泛承认。传统上，常见评估方法依赖在训练和验证之间拆分数据以确保公平评估。在训练数据可用或可复现时，一个增长趋势是在测试时复现原始训练-验证拆分。然而，对大多数商业 LLM，这不可能，因为它们不公开训练期间使用的数据集，阻碍了用真正「未见」数据评估。用开发中所用的相同数据验证模型会导致一个在开发中表现出色、但在生产中面对未见数据时表现不佳的模型。这种不透明削弱了 LLM 的可靠性，并对可复现性和信任引发严重关切。而且，由于不透明，一个要求 LLM 生成测试套件的测试者可能在不知不觉中承担侵犯知识产权的风险，如果 LLM 返回受专有权保护的代码。为应对上述数据问题，若干研究者承认需要新的、多样的、标准化的基准，导致新数据集和评估基准的发布。一些作者提出用自定义或私有数据集评估方法以最小化数据泄漏风险。然而这样做时，我们应意识到潜在安全威胁，因为众所周知 LLM 可能泄露敏感或私有数据。相反，其他建议用较旧模型评估基于 LLM 的测试方法，假设新基准或数据集未在它们训练期间被使用。这造成一种跑步机效应：随着模型演化，基准也必须演化，导致一场耗尽学术界和工业界的无尽竞赛。随着基于 LLM 的测试研究成熟，新方面正成为其结果可靠性和可复现性的核心。其中，文献促进对管理数据泄漏、数据集隐私、知识产权和计算过程公平性的调查。

#### 6.1.2 交互

现在考虑一个已配置好、准备使用的模型实例。我们识别了若干与测试工程师如何引导与 LLM 交互相关的挑战。具体来说，文献凸显了请求的措辞方式与 LLM 产出结果之间的强烈影响。类似地，测试工程师表达额外上下文信息以有效达成某目标的方式显得相当核心。最后，如何检索外部知识、如何动态支持 LLM 以整合它也很重要。这些挑战的详细呈现如下：

• 提示工程：指引导生成式 AI 系统产出期望输出的过程。越来越多的研究，既有一般的也有测试特定的，凸显了提示词制作在 LLM 性能中的重要作用。挑战在于系统地设计引导模型走向有用、有效、在上下文中输出的提示词。为应对这一挑战，出现了若干有前景的方向。一条未来工作线提出探索多提示策略，旨在通过多样化提示输入来改进模型性能。其他提出采用上下文学习，通过直接在输入中包含代表性示例来增强提示准确率。其他提出采用记忆内编程，其中先前的 LLM 输出被纳入下一次交互。另一个方向是所谓的自我精炼，其中 LLM 被提示去增强提示词的相关性和清晰度。这些策略反映了把提示设计变成非静态、迭代、自适应过程的日益增长的兴趣。一些作者表明，用精心制作的提示词，通用模型能达到与微调模型相当的性能。这些挑战强调需要引入 Promptware 测试方法来处理提示设计和验证，旨在更可靠、可维护、可测试的基于 LLM 的测试方法。提示工程和提示质量在与 LLM 合作的软件测试界吸引了日益增长的兴趣。尽管如此，在这一领域评估、验证和改进提示质量方面仍有创新方法的空间。

• 上下文：指提供给模型以执行特定任务的信息。若干工作强调了丰富它以改进性能的潜力。挑战是如何提供更广的相关测试知识库来增强 LLM 性能。然而，一些作者也凸显更多上下文并不总保证更好性能。增加上下文有时适得其反，降低模型准确率。一些作者也承认由于输入约束导致上下文有限的挑战，或自动化数据选择和提取过程。多少上下文才够、哪种上下文有效，这一问题在很大程度上仍开放。许多作者的另一个共同目标是上下文质量，通过改进输入、整合领域知识，或增强信息提供方式来实现。另一位作者未来工作的目标不是上下文的数量而是质量，聚焦于通过整合领域知识改进输入，或改进信息提供方式。这些工作认识到努力不仅应放在上下文的量上，还应放在其质量和与测试目标的对齐上。一些工作不假设高质量输入，而是提出即使在最小、无关或噪声上下文场景下也改进模型性能。这个方法凸显了 LLM 需要在真实世界约束下稳健，那里理想输入并不总能保证。上下文大小、质量和模型稳健性之间的关系勾勒出一个丰富而宽广的研究图景，其中权衡必须被仔细协商。

• 检索增强生成（RAG）：已在若干基于 LLM 的软件测试研究中被探索，以丰富提供给模型的输入上下文。一些工作凸显，尽管扩展了模型的输入窗口，RAG 的挑战之一是处理检索上下文超出模型处理能力的情况。另一方面，RAG 也用于在提示限制内处理那些长上下文。另一条未来研究线是如何处理 RAG 对用作输入的数据（如检索源）的质量和相关性的依赖，这一主题在一般和测试特定研究中都被讨论。最后，一些作者也凸显了 RAG 捕捉测试所需信息的挑战。为应对这些挑战，一些作者提出纳入人在回路来监督和精炼 RAG 流水线。其他指出了改进空间，发现 RAG 替代品被 SOTA 工具超越。如何检索与测试目标对齐的相关且准确的信息，仍是 RAG 使用中的主要挑战。未来方向涉及信息的质和量，以及把其内容裁剪到测试需求。

#### 6.1.3 验证

评估 LLM 如何表现是若干工作承认的开放挑战。在不同挑战中，我们凸显两个：（1）可能阻碍输出质量的幻觉现象，（2）缺乏稳健的、领域特定的评估指标。这些挑战对基于 LLM 的测试的正确性、可信性和可复现性有直接影响，讨论如下：

• 幻觉：基于 LLM 的测试的主要挑战是处理幻觉现象。若干作者承认这是一个关键问题，尤其因为它对生成输出的正确性和有效性的影响。当幻觉产生时，它们常导致有缺陷的代码，或不精确的输出/计算。这在用 LLM 做测试时对可靠性、正确性和可信性引发重大关切。然而，幻觉并非在所有测试领域都被负面看待。一批新兴研究开始正面考虑幻觉。特定作者凸显了 LLM 作为「跳出框架」测试思考者的能力，能生成逃脱常见启发式、可能有价值的非显而易见的配置、输入或策略，例如在测试探索中。这一视角表明，恰当驾驭幻觉可能通过提供暴露测试工程师可能忽略的边界情况的多样输入和场景，来扩展测试的创造性边界。然而，不受控幻觉的风险需要有效的缓解策略。为此，一些作者认识到一条未来工作线，通过分析 token 级概率作为输出可靠性指标来内省模型。作为补充，其他方法呈现了后处理过滤器，丢弃幻觉生成的那些无效输出。幻觉作为可靠性问题和创造力来源的双重角色呈现了一个丰富的研究途径。用不仅移除幻觉、还理解和引导它们的策略来处理它们，对测试生命周期中的某些应用会有益。

• 指标：尽管从业者和研究界日益关注，基于 LLM 的测试方法的评估仍是开放挑战。若干作者明确承认缺乏稳健、有效的评估指标。所面临的问题取决于 LLM 生成输出的性质。例如，当输出是自然语言时，现有 NLP 领域指标如 BLEU、ROUGE 和 METEOR 已被成功应用于衡量 LLM 与人类测试者输出之间的语法相似度。然而，这些指标最初用于评估代码生成，揭示了若干局限：它们常通过未能捕捉语法不同但语义正确的代码段之间的功能等价性，产生误导性评估。作为回应，研究界提出了更细腻、领域特定的指标，与人类程序员的正确性和效用感对齐。新兴提案包括 CodeBLUE、匹配成功率（MSR）、代码提取率（CSR），以及更细粒度的标准如后置条件完整性和正确性。基于 LLM 的测试的评估指标面临技术和认识论挑战：定义什么对人类和工具是「好」的，并一致有效地衡量它们。随着 LLM 在测试中的采用，这一空白成为验证、信任和进一步进展的基础步骤。

#### 6.1.4 社会挑战

除技术挑战外，在软件测试中采用 LLM 有若干以人为中心的挑战。在这些挑战中，我们识别了对模型的信任、从业者的经济/技术/性能进入壁垒，以及确保负责任有效使用 LLM 的教育框架的需要。这些挑战较不可见，但在基于 LLM 的测试的未来中起关键作用，在下面的信任、采用和教育小节中覆盖和讨论：

• 信任：它仍是 LLM 在软件测试中适用性和采用的大挑战。问题的根源是常见的歧义：「当测试失败时，是由于 PUT 中的真实缺陷，还是模型的失败？」由于 LLM 在人工产生的数据上训练，这些模型易于不仅复制最佳实践，还复制常见错误和代码反模式。许多研究对生成输出（如代码片段、测试用例或变异体）的正确性以及计算的准确性提出关切。若干开放方向已被提出以缓解这些问题并强化信任。一个方向聚焦于用更多上下文丰富模型的输入，例如提供错误反馈来引导生成过程。另一个涉及把 LLM 与更可靠的 SOTA 工具整合的混合系统。进一步的提案包括增强可解释性、简化和澄清复杂的生成输出，甚至在流水线中链接多个模型以迭代精炼输出。另一个削弱信任的因素是 LLM 常在需要高级推理或语义理解的复杂或特定场景下难以表现好。这些复杂场景的例子有生成处理异常的 oracle、生成多断言测试用例或完整程序状态、生成复杂变异，或识别微妙的系统级缺陷。许多研究者提出引入「人在回路」来弥合这一空白。通过让测试者引导、检查或增强模型的决策，这个方法增强了可信性并使模型考虑可能被忽略的情形。测试者可验证输出、引入缺失的领域知识，甚至增加输入的创造性以补充模型能力。最后，毫不奇怪，信任本身也依赖社会方面。因此，在使用 LLM 的开发者社群内，信任可通过集体意义建构来培养，其中开发者基于他人经验和共享意见（如投票）建立信任。虽然 LLM 对自动化测试有潜力，信任是一个壁垒，源于歧义的失败解读、易错的输出，以及复杂场景的困难。增强人类与可靠 SOTA 工具之间的协作能提升对 LLM 生成结果的信心。

• 采用：把 LLM 整合进所有软件测试过程有前景，但远非无缝。采用面临四个挑战：性能、成本、隐私和可用性。第一是性能挑战，它被提及为上述许多挑战的相关因素。虽然 LLM 展示了潜力，其应用常耗时、资源低效（如频繁 API 调用，或为达成正确而生成大量输出），或需要大量人工后处理。若干研究表明孤立的 LLM 常超越为此目的明确打造的 SOTA 工具（如改进覆盖率）。这引发了把 LLM 与传统 SOTA 工具结合以利用两者优势的日益增长的兴趣。然而，这种整合在某些情况下仍受缺乏插件和工具支持的负面影响。第二个壁垒是成本和基础设施。本地运行 LLM 或微调它们需要昂贵且专门的硬件，LLM 即服务也可能昂贵或受数据法规政策限制。这使得大多数初创和中小组织无法利用这些模型的潜力。第三，已提及的隐私关切仍然重大。通过外部服务使用 LLM 引发数据泄漏和不清晰使用政策的风险，阻碍其采用，尤其在处理敏感数据的受监管行业。最后，第四个挑战涉及可用性。采用 LLM 意味着处理两个方面。前者是关于与现有开发工作流的无缝技术整合。后者需要更好地理解人-AI 交互，洞察测试者如何解读和利用 LLM 输出。应对采用 LLM 测试的挑战需要在性能调优、工具支持、成本降低、隐私保护、技术整合和人-AI 协作上的协调努力。

• 教育：在软件测试中负责任有效地使用 LLM 需要把它们整合进教育和培训项目。用 LLM 做测试在智力上有挑战，需要特定知识和提示技能，而这些未包含在当前学习路线图中。另一个障碍是缺乏标准化，正通过新分类的发展开始被处理。总之，弥合教育空白对扩展 LLM 在测试中的实际使用至关重要。这将需要在课程设计、工具开发和标准化上的协调努力。

6.2 LLM 将如何影响软件测试研究

除上述识别的挑战外，LLM 当前的势头正影响整个软件测试研究。在本节中，我们尝试对这种影响给出一个视角，为此我们利用先前一篇高引用的软件测试研究路线图中已引入的概念。

具体来说，那篇路线图把软件测试研究的成就和挑战投射向四个「梦想」，定义为研究「最终趋向、但仍像梦一样无法触及」的最终目的地。事实上，虽然那项工作已近 20 年，且它讨论的某些成就/挑战无疑需要根据更近期的结果修订，四个梦想（忠于其定义）仍显得现实和相关。因此，在本工作中我们提出关于 LLM 能否及如何促进软件测试研究更接近其梦想的展望。

四个软件测试梦想以某种层级效用相关（见图 10 左侧）：第一个梦想可被利用来接近第二个梦想「基于测试的建模」；恰当的模型允许推进自动化，走向第三个梦想「100% 自动测试」；最后，自动化对成本有效的测试过程是工具性的，走向最顶层的梦想「效能最大化的测试工程」。本节余下部分详细讨论 LLM 如何能贡献于这些梦想。

#### 6.2.1 通用测试理论

测试是一项务实活动，其工业应用仍要解决复杂挑战并缺乏一个通用理论。路线图的愿景是，测试技术和工具的假设、局限和能力可被收集进一个连贯而严格的框架，它告知并引导测试者选择、组合和应用最适合其情形的测试方法，从而减少成功对测试者技能和背景的依赖。

从我们对当前基于 LLM 的测试研究的综述，我们迄今未发现明确处理利用 LLM 潜力构建这样一个理论框架的工作：是的，我们能提及若干聚焦于基于 LLM 的方法自身的局限和潜力的研究，大多通过实证研究。例如 Ouédraogo 等人和 Li 等人都做了深入分析，用各种类型的提示词和上下文信息实证评估和比较不同 LLM。前者把结果与 EvoSuite 基线比较，后者把它们与手工测试比较。两项研究都对所分析模型各自的优劣提供了有洞察的反思。也存在少数分析基于 LLM 的测试文献、旨在提出对 LLM 能达成什么的合理化的研究。值得注意的是，Braberman 等人回顾了用于软件测试和分析的 LLM 使能架构，并提出了一个由 LLM 提示可达成的「下游任务」的广泛分类。

这类实证或分析研究当然有启发，但这不是我们这里感兴趣的：我们问 LLM 能否支持对现有技术和工具的分析，以帮助理解和编纂它们相互的适用性、可组合性和可达成结果。即使 LLM 的这一潜在用途尚未被探索，我们仍乐观地预期未来 LLM 分析和关联事实的形式能力会揭示自己为接近这一梦想的有用工具。我们预期基于 LLM 的测试确实将作为间接和直接的杠杆来强化软件测试的理论基础。间接是因为在我们概览的大多数工作中，可观察到一种认真努力去寻找最佳方法和最有效信息来提示 LLM；例如 Gao 等人的测试用例生成提示生成方法包含一个领域上下文知识提取模块，帮助优化测试用例的准确率。换句话说，聚焦于优化基于 LLM 的测试的研究要求我们更好地理解测试活动所需的本质且正确的信息，这显然与我们梦想的通用测试理论的表述非常相关。作为直接杠杆，我们预测 LLM 强大的推理能力，加上它们处理和综合海量数据的能力，可用于生成测试假设——这是理解测试准则实际有效性所要处理的主要挑战之一。如前所述，我们在这一领域未发现工作，但利用 LLM 做假设生成的想法已在其他领域被使用。

当前基于 LLM 的测试研究没有影响，但未来它可能帮助奠定通用测试理论的基础，既间接地（如通过研究最有效的提示词），也直接地（借助 LLM 形式推理能力，如推导测试假设）。

#### 6.2.2 基于测试的建模

在这个梦想中，被测软件配有一个为便利测试而构想的模型，以结构良好的方式携带测试目的所需的全部信息。这将包括所提供的功能、关于执行环境的假设、可能的输入约束、每个给定输入的期望行为等。

LLM 当然能推进朝这个梦想的进展：一方面，若干工作利用 LLM 的抽象和摘要能力为软件推导一个（形式）规格；另一方面，如我们在 5.3 节呈现的，大量研究已致力于测试 oracle 的推导，而在路线图中这被呈现为达成这个梦想所必须处理的最难挑战之一。此外，LLM 已证明能产生巨大创造性，借此它们也可被利用来提供高表达力、人类可理解的模型，通过把文本、图形和其他交流形式组合进一个多模态（且更自然）的被测软件规格。

然而，展望未来，视角似乎是 LLM 很可能在测试用例生成、执行和验证任务上取代人类测试者，而测试者的任务将是提示 LLM 并检查其答案。在这一视野中，我们预期基于测试的建模的梦想会失去相关性，鉴于 LLM 处理自然语言或非正式输入的能力。如果我们再加上被测代码也由 LLM 生成的相关可能性，中间制品的效用/必要性将会下降。

LLM 能通过综合函数行为的形式或图形规格，以及推导测试 oracle，来便利为测试目的编写更好的模型。但从长远看，LLM 的使用很可能使模型制品变得不那么重要。

#### 6.2.3 100% 自动测试

梦想是一个强大的集成测试环境，它监控软件开发或维护的进展以检测测试需求，并能自主管理测试的设置、配置、执行、报告，以及需要时的缺陷定位和修复。

显然 LLM 已经在每一项测试活动中影响对这个梦想的追求：确实，把自动化推进到超越现有工具所达水平，正是使用 LLM 的终极动机。我们在第 5 节回顾了许多呈现自动化测试活动的工具的工作：具体来说，LLM 支持单元测试和系统层面的测试生成，如我们分别在 5.1 和 5.2 节讨论的；其他工作依赖 LLM 赋能的 agent 做测试配置或执行，如我们在 5.5 节概览的；基于 LLM 的方法也便利自动化 oracle 的推导，如我们在 5.3 节所示。展望未来，进行中的研究表明 LLM 必将促进软件测试自动化。

然而，研究也警告，在改进测试自动化的同时，LLM 也引入新问题和新挑战，需要仔细关注。我们在前一节凸显了若干开放挑战：即使用于软件测试，LLM 也会受幻觉之苦，因此 LLM 响应需要恰当的评估和验证指标。此外，若干研究表明 LLM 的性能严重依赖测试者提供的提示词，因此借测试自动化省下的人力应被重定向到提示工程阶段。作为最后一个重要观察，在我们对文献的回顾中，我们还注意到基于 LLM 的测试研究正在分离的筒仓内推进，但最终软件测试者需要通过组合所有不同活动来自动化整个过程，而不是分离地自动化各个活动：事实上这个梦想设想一个集成测试环境，但我们迄今未发现整合不同活动的努力。

LLM 已经在推进自动测试，但同时也带来新挑战，并要求测试者改变其专长。此外，迄今研究在分离的筒仓内推进，我们离接近一个集成的基于 LLM 的测试环境还很远。

#### 6.2.4 效能最大化的测试工程

这被提出为软件测试研究的终极目标，定义为工程化可行方法、过程和工具以成本有效方式开发高质量软件这一理想——同时又实用——的目标。梦想名称中的「效能」一词用于表示效率和有效性两种属性。

严格来说，LLM 迄今未被利用来评估或改进测试活动的成本效益，意即我们在所回顾文献中未发现对用 LLM 减少测试高成本的明确关注。若干工作用 LLM 改进测试覆盖率；然而，如 Mathews 和 Nagappan 所讨论，当前解决方案可能未被很好地构思来改进失败检测有效性。当然，存在各种基于 LLM 的方法显示相对传统基线改进了缺陷检测有效性。然而，一些作者也警告使用 LLM 隐含的高成本。

展望未来，我们有信心一旦基于 LLM 的测试生成和执行方法获得更高成熟度，LLM 能为处理先前在 Bertolino 路线图中识别的一些挑战提供好的支持。具体来说，LLM 赋能的 agent 能支持对演化软件的自适应和自主测试，从而把测试者从理解软件演化时何时、测什么的负担中解放出来。此外，显然 LLM 能对软件测试者的教育产生潜在影响，这也被指出为走向更成本有效测试过程的一个有前景方向。

长远看，如果我们能在开发能监控执行中软件、发起测试用例（也许还在现场）、甚至在检测到缺陷时自主修复软件的多 agent 解决方案上取得重大进展，我们某种程度上可能见证现实超越这个梦想。然而，我们再次需要也考虑所涉及的成本，推进利用 LLM 评估软件测试直接和隐含成本的研究。

LLM 尚未被利用来评估或减少测试成本，某些情况下它们的使用反而增加了那些成本。然而，展望未来，我们预期 LLM 在改进测试过程成本效益方面有巨大潜力，无论通过多 agent 框架，还是通过改进测试者教育。

7. 结语

受近期对 LLM、更具体地说对其日益增长的支持软件测试活动用途的兴趣爆发的触发，在本工作中我们 旨在 为基于 LLM 的测试研究带来秩序。本研究并非意在作为系统性文献综述；相反我们提出一份当前研究成果和开放挑战的路线图，建立在一个半系统性综述之上。我们把进行中的研究收集在七个类别下，即：单元测试生成、高层测试生成、Oracle 生成、测试扩充或改进、非功能测试、测试 agent，以及反思。对每个类别（除反思类别的工作，它们转而启发了我们的路线图方向），我们提供了底层过程的通用示意和对进行中研究的概览。我们研究的最终产品由一个凸显开放挑战、设想 LLM 对软件测试研究学科可能影响的讨论构成。

我们还讨论了 LLM 能否及如何帮助软件测试研究者更接近其软件测试梦想。LLM 代表了对测试活动的有效支持，并频繁地与传统 SOTA 工具整合或并列使用。虽然它们的采用能产生可观的成本和资源节省，这些收益必须与确保高测试质量所需的互补活动（如提示工程和微调）所需的额外努力权衡。许多与自动化、LLM 输出可靠性、社会方面和教育相关的挑战仍需被仔细处理。

虽然许多开放问题仍摆在我们面前，正如我们在文中讨论的，我们相信 LLM 和生成式 AI 在软件测试中的兴起不是一时的浪潮，而是一场将产生永久影响的革命。我们承认基于 LLM 的测试的方法和工具仍远未成熟，并确实预期在不久的将来会有巨大进展。尽管如此，我们确信 LLM 分析和综合自然语言与代码的能力将为开发者提供对自主、系统、严格验证的可靠支持：注意我们是从长远视角而非当前状态（仍在演化中）主张这一点。从本文凸显的发现和开放挑战中可勾勒出若干未来工作线，与研究者的专长和研究线对齐，例如系统测试、强化学习测试、测试生成或云测试。我们希望我们的路线图能帮助研究者更好地引导其未来对基于 LLM 的测试的调查。反过来，我们相信对新兴工作的持续监控能为我们路线图提供验证和可能的修订。

署名与许可：原文 Large Language Models for Software Testing: A Research Roadmap，作者 Cristian Augusto、Jesús Morán（University of Oviedo）、Antonia Bertolino（GSSI）、Guglielmo De Angelis（IASI-CNR）、Francesca Lonetti（ISTI-CNR），arXiv:2509.25043v1，2025-09。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布；图 1 及原文图 3–10 版权归原作者。原文地址：https://arxiv.org/abs/2509.25043 。本研究部分受欧盟 HORIZON-KDT-JU MATISSE 项目、西班牙 PID2022-137646OB-C32 项目及 PNRR MUR FAIR 项目支持。译文中省略了参考文献列表、文内引注编号及部分表格的逐条论文编号；模型名、工具名、基准名、指标名保留英文。如译文与原文有出入，以英文原文为准。