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

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

翻译说明：本文是 arXiv 论文 Large Language Models for Software Testing: A Research Roadmap（arXiv:2509.25043，2025-09 提交）的中文全译，由智测团队翻译。原作者：Cristian Augusto、Jesús Morán（University of Oviedo，西班牙）、Antonia Bertolino（GSSI，意大利）、Guglielmo De Angelis（IASI-CNR，意大利）、Francesca Lonetti（ISTI-CNR，意大利）。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节、分类与结论；参考文献列表与文内引注编号从略，模型名、工具名、基准名、指标名保留英文。图 1（2020–2025 年发表分布）随文保留，版权归原作者。

摘要

大语言模型（LLM）正开始被定位为软件测试领域最重大的颠覆之一。具体来说，它们已被成功应用于生成测试代码、摘要文档等软件测试任务。这一潜力吸引了数百名研究者，每月产出数十项新贡献，使研究者难以跟上浪潮的前沿。然而据我们所知，此前没有工作对基于 LLM 的测试的进展和最相关研究趋势给出一个结构化的视野。在本文中，我们旨在提供一份路线图，说明它的当前状态，把贡献归入不同类别，并勾勒该领域最有前景、最活跃的研究方向。为达成这一目标，我们做了一次半系统性文献综述，收集文章并把它们映射到最突出的类别，回顾当前和进行中的状态，分析基于 LLM 的软件测试的开放挑战。最后，我们概述了 LLM 对整个软件测试领域的若干预期长期影响。

关键词：软件测试，大语言模型，路线图

1. 引言

基于 Transformer 的大语言模型（LLM）已经彻底改变了自然语言处理（NLP）领域，并进而成为广泛领域技术进步奠基石，甚至挑战了当前最先进的智能测试。LLM 是通过从海量人工文本语料中学习模式来模仿人类推理技能的神经架构。LLM 已在各种任务中展示潜力，例如生成叙事和对人类问题的详细回答、纠正和改进语法、摘要并简化对复杂信息的理解。

在软件工程（SE）领域，LLM 正在重塑重复性、低价值任务（也称 TOIL）的管理方式：LLM 正被集成进大多数 IDE（如 IntelliJ、VSCode），提供工具帮助开发者做代码合成、解释代码功能、检测软件缺陷并给出修复，以及协助撰写文档和报告。来自 AWS、Meta 等大型科技公司的首批报告开始认识到 LLM 驱动自动化的优势，作为对人类工程师的支持和补充。

软件测试是 SE 的基本要素，占项目总预算的 15% 到 80%。这引发了在不同软件测试任务和层次上使用 LLM 的日益增长的兴趣。近期研究已显示 LLM 加速和自动化各种任务的潜力，如 oracle 生成、自动程序修复、测试套件扩充、测试输入生成，以及单元测试和系统测试用例生成。

在软件测试中运用 LLM 的研究（下称「基于 LLM 的测试」）在过去几年非常活跃，每月甚至每周发表数十篇新文章。在这样一个快速演化的图景中，感兴趣的研究者很难跟上研究的进展和成果，尤其难以把握最相关研究趋势的结构化视野。在本文中，我们旨在提供一份路线图，说明基于 LLM 的测试研究的当前状态，按我们从文献研究中得出的一组文章类别来组织；我们还旨在勾勒最有前景的未来研究方向。虽然为达成这些目标我们做了广泛的文献研究，但我们强调这项工作并非严格意义上的系统性文献综述（SLR），那超出了我们研究的范围：正如我们在第 3 节更好解释的，我们目前认为路线图比严格的 SLR 更实用、更有用。

本工作的总体目标分为以下子目标（SO）：

• SO1：推导出基于 LLM 的测试的最相关研究类别的结构化图谱；
• SO2：沿所识别的类别概述基于 LLM 的测试研究的进行中状态；
• SO3：分析投射到所描绘路线图中的最突出开放挑战；
• SO4：外推 LLM 对整个软件测试领域的预期长期影响。

本文余下部分结构如下：第 2 节回顾相关工作。第 3 节概述检索文献的过程。第 4 节呈现检索到的文章并描述如何对它们分类以解决 SO1。第 5 节呈现 LLM 在所考虑的不同软件测试类别中如何被使用，每个类别用一个单独小节（SO2）。第 6 节分析相关的基于 LLM 的测试挑战并概述未来研究方向（SO3），并尝试预测这一新研究浪潮将如何影响测试研究（SO4）。最后，第 7 节给出本文结论。

2. 相关工作

如前所述，基于 LLM 的测试领域近年非常活跃，已有若干研究试图回顾现有的基于 LLM 的测试技术和工具，或分析 LLM 的性能和交互方法，以及综合研究挑战和视角。

在撰写本文时，已有的最新系统性综述覆盖了 2019 到 2023 年的 102 项研究，按 LLM 被用于的软件测试任务、所用 LLM 模型、提示工程类型和 LLM 输入来分类，并呈现了挑战和潜在机会。另一篇关于基于 LLM 的测试的综述首先呈现了 2003 到 2021 年 LLM 发展的演化，然后分析了 19 项用 LLM 优化测试技术的研究，按两个维度分类：如何高效生成自动化测试代码，以及如何生成多样化的测试输入。最后，有作者依赖基于问卷的调查来收集关于 LLM 在各种测试活动中实际使用的定量数据。我们的文章与前述不同，因为我们不旨在提供又一篇基于 LLM 的测试文献的系统性综述。我们的主要目标是构建一份路线图，概述基于 LLM 的测试领域的当前状态，连同对该领域研究方向和长期视角的结构化概述。我们遵循一种半系统性综述（SSLR）方法——一种仍然严格但不那么全面的综述，使我们能识别和分类基于 LLM 的测试方法，并发现文献中的知识空白。

其他综述聚焦于用 LLM 做测试 oracle 自动化。特别是有工作提供了一份路线图，覆盖常见的自动推断 oracle 类型，并讨论用 LLM 做 oracle 自动化的潜力和威胁。类似工作处理了基于 LLM 的 oracle 生成模型的评估、其性能和评估指标问题。Oracle 生成是我们在路线图中用于分类文章的一个类别，我们把上述文章纳入路线图中与 oracle 生成相关的反思类别。

聚焦更广的研究处理了在软件工程和软件测试中采用 LLM 的更一般问题。例如，有作者呈现了一项系统性综述，旨在理解 LLM 如何在不同软件工程任务中被利用，包括软件质量保证和测试生成——这些也在我们工作中处理。类似地，有作者呈现了一篇一般而近期的系统性综述，处理 LLM 在不同软件工程活动中的角色，包括代码评估，分析了基于 LLM 的测试用例生成、新测试框架和 LLM 测试模型相关的研究。还有综述回顾了 LLM 用于软件工程活动（含软件测试）的现有工作，处理测试生成、测试充分性评估、测试最小化和测试输出预测，并凸显该领域的开放问题和挑战。有工作呈现了软件工程问题（含软件测试相关问题）的系统性分类，以及这些问题到用于解决它们的基于 LLM 的方法和工具的映射。最后，一项涉及 100 名软件工程师、关于在软件开发中采用生成式 AI 的问卷调查结果显示，开发者对 LLM 采用相关方面的看法，如感知有用性、复杂性、技术优势、社会影响、环境因素等。与这些横跨整个软件工程方面的综述不同，我们聚焦软件测试，深入研究基于 LLM 的软件测试的相关研究。

近期研究日益聚焦于评估 LLM 驱动的测试过程，尤其在单元测试语境中，提出了评估和分析基于 LLM 的测试有效性的框架和流水线，以及改进测试结果的实践指南和建议。具体来说，有工作引入了一个基准测试框架，用于在多个维度上比较 LLM 与手工测试的能力，包括测试用例生成、缺陷检测和错误追踪，以开源软件项目为参考语境。有作者对 37 个广泛采用的 LLM 提供了全面的实证评估，讨论了软件工程界评估 LLM 的关键问题，如数据泄漏、生成测试用例的缺陷检测能力，以及评估指标的比较和选择。类似地，有作者评估了不同模型（如 GPT 和 Mistral）在生成单元测试用例上的有效性，以及不同提示工程技术如何影响其性能。有作者调查了基于 LLM 的测试与传统自动化测试生成技术（如基于搜索的软件测试 SBST 和符号执行）的比较性能，凸显相对优势和局限。最后，其他工作按输入输出、执行的自动化软件测试类型、产出能有效识别缺陷的测试的能力，以及应用领域，对软件测试中最常用的 LLM 做了分类。单元测试生成是我们路线图的主要研究类别之一，而基于 LLM 的测试中的关键挑战，如提示工程、数据泄漏和评估指标，在我们工作中被检视。在这一扩展的全景中，本研究的原创贡献在于我们旨在提供一份进行中研究的结构化图谱，可用于更好地理解和定位该主题的文章，甚至能为框定未来出现的研究工作所用；同时，我们从文献趋势研究中提出未来研究最相关的开放问题。

3. 文献映射

在本工作中，我们旨在勾勒软件测试研究界就 LLM 采用正在探索的主要方向。鉴于对该主题兴趣的巨大爆发，我们预期文献尚未成熟到能清晰凸显有效、长期的结论，也不够稳定到允许一次全面综述。尽管如此，我们相信在如此令人印象深刻的想法和提案产出中，开始勾勒那些看起来最有前景的结果、报告它们指出的挑战，然后预测它们对软件测试研究未来的预期影响，是有价值的。因此，我们想到把文献研究做成一次半系统性文献综述（SSLR）。成果以一份路线图呈现给对基于 LLM 的测试感兴趣的研究者。

SSLR 提供一个宽泛研究领域的概览，其中，引用 Snyder 的话，回顾「每一篇可能与主题相关的文章根本不可能」。因此，更严格的系统性文献综述背后的严格要求可以适度放宽。尽管如此，必须遵循一个透明的过程，让读者有信息从方法论角度判断论点和结论是如何得出的。下面解释我们 SSLR 遵循的过程。

具体来说，基于引言中陈述的四个目标 SO1–SO4，我们的文献回顾由以下研究问题引导（括号内是处理它们的章节的前向引用）：

• RQ1：基于 LLM 的测试的主要研究类别是什么？（见第 4 节）
• RQ2：这些类别目前取得了哪些结果？（见第 5 节）
• RQ3：基于 LLM 的测试中的挑战、趋势和研究机会有哪些？（见 6.1 节）
• RQ4：LLM 如何影响软件测试研究图景？（见 6.2 节）

为回答这些问题，我们规划了跨多个数字图书馆（DL）的搜索过程，并对检索到的工作做了结构化、自底向上的分类，如同系统性综述。然而，我们的 SSLR 放宽了系统性研究通常遵循的两个标准。第一，我们没有强烈追求识别所调查主题所有代表性工作的可复现闭合集，承认在这些条件下我们可能漏掉一些相关文章。第二，我们通过纳入尚未经同行评审的科学工作（如发表在 arXiv 上的）放宽了调查的严格性。尽管如此，我们有信心所定义的半系统性过程能导出对过去几年被如此快速讨论的新兴想法的概览，以及对基于 LLM 的测试研究路线图的首次定义，更广义地还有它对未来软件测试研究的影响。

我们应用的方法结构为三个主要步骤：规划（见 3.1 节）、实证收集（见 3.2 节）和增量式临时滚雪球（见 3.3 节）。

3.1 映射计划

研究聚焦于用英文撰写、且被以下至少一个 DL 索引的文章：ACM-DL（ACM 计算文献指南）和 IEEExplore。两个 DL 都覆盖软件测试的相关科学期刊和会议，也索引 IEEE 和 ACM 之外出版商发行的科学期刊/合集中的工作。就此而言，我们期望触及可能发表范围内工作的相当大（虽不完整）一部分场所。

然后我们识别出引导两个 DL 查询的宏 token。具体来说，为触及一个宽泛且相关的集合，我们做了一个通用搜索，聚焦于在标题中呈现 token「test」与 token「llm」或「large language model*」组合的工作。

为分析收集到的工作，我们设计了一个分类模式来凸显其主要特征。具体来说，该模式预期报告：关于工作的一般信息（标题、摘要、撰写年份、出版类型、贡献类型），来自评审者的一些反馈（自己的简要总结、一份关于什么由 LLM 驱动而什么需要人做的清单、相关研究视角），关于所用技术的信息（所指的具体 LLM、实现所提方法的工具的任何发布），关于方法如何被验证的信息（所指基准、对所观察结果的所指指标），外加一个供评审者报告任何额外评论的空间。最后，该模式包含另外两个字段（类别和 LLM 方法类型），我们用来基于一组关键维度给每项工作打标签。具体来说，「类别」字段旨在描述工作相对于软件测试活动的主要目标；从一组受 Wang 等人综述启发的初始备选出发，我们计划遵循对收集到的工作证据的自底向上观察，迭代地精炼出连贯的测试目标类别，直到达成一个商定的一致完整集合。而「LLM 方法类型」旨在建模所预见的与 LLM 交互的种类：我们最初考虑区分仅通过抛出恰当提示词与预训练 LLM 交互的方法，和相反地执行专门微调的方法。读了一些工作后，明显这两类不足以分类所有工作，我们增加了另外两种「混合」交互类型，如第 4 节所解释。

3.2 实证收集与分析

在 2025 年 3 月底，我们用 3.1 节报告的宏 token 查询所识别的 DL。这些结果代表我们用来构建语料、以精炼路线图的初始文章池。如 3.3 节所报告，随后我们利用了一个增量滚雪球过程，把我们的探索也扩展到其他工作。

每篇检索到的文章至少由两位作者回顾。第一轮迭代中，文章仅通过分析标题和摘要来处理。这一初步分析旨在丢弃明显超出我们研究范围的工作：例如偶然在标题中匹配宏 token，或处理不想要的主题（如硬件测试）。所有作者集体对被标记为丢弃的文章做出最终决定。第二轮迭代中，评审者通过考虑完整内容来处理剩余工作；分类模式的所有信息都被修订和细化。此外，评审者提出了相对于上述研究维度对文章的初始自底向上打标签。定期地，所有作者开会一起修订当前采用的标签集，精炼/对齐它们的定义，泛化/特化新兴的分类和 LLM 方法类型。在这些会议中，作者还讨论了进一步存疑的文章，其中一些经更深分析后被丢弃。

3.3 滚雪球

所应用方法的最后一步旨在纳入逃脱了 DL 查询的相关工作。我们构建了一个增量式临时滚雪球程序，覆盖任何种类的科学出版物，也包括来自 arXiv 的未经同行评审的文章：鉴于该主题的快速增长，以及为了在我们的路线图中拥有对进行中研究的最新视野，我们做了这个决定。具体来说，对当前纳入语料、尚未被处理的每项工作，我们应用了后向和前向滚雪球。前者中，我们处理它的所有参考文献。后者中，我们查找 GScholar 在「被引用」合集中报告的所有工作（在 2025 年 3–5 月间于 Google Scholar 上执行）。两种情况下，我们都只考虑标题暗示与研究路线图目标有某种相关性的工作。

每次滚雪球迭代产生的所有文章都被视为可能纳入本研究语料的新文章。因此，它们由至少两位评审者按 3.1 节描述的通用分类模式分类。此外，作者定期开会讨论被提议丢弃的工作，并基于自底向上分类程序修订标签的当前状态。因此，在滚雪球期间，作者迭代地分析文章在潜在类别中的当前聚类，并协作处理每个识别出的标签的定义（例如通过精炼或提出新标签）。

我们把所采用的滚雪球程序归类为临时性的，因为所实现的停止条件。确实，我们认为滚雪球完成（就我们路线图的目的而言）是在语料中所有文章都已被处理时，或在我们观察到「类别」字段所指标的标签集收敛时。具体来说，经过几轮迭代后，我们观察到通过滚雪球找到的新工作没有导致「类别」维度组织的任何进一步变化，因此我们认为我们的语料能充分代表当前文献中正在调查的主要主题。

4. 文章语料

在本节中，我们提供对上述过程收集的 130 篇文章的分类，基于出版年份或它们被纳入 arXiv 的年份，以及贡献类型（期刊、会议或 arXiv）。图 1 展示了 2020 到 2025 年的出版分布，凸显来自期刊（绿色）、会议（蓝色）和 arXiv（红色）的贡献比例。2019 年未发现出版物，2020 到 2022 年识别出四项不同工作。2023 年，检索到的出版物数量增加了近 470%（14 篇），2024 年是其五倍（84 篇），到收集日期为止 2025 年收集了 25 篇文章。

贡献类型差异显著。在最初几年，大多数出版物出现在会议上，特别是 ICSE、FSE、AST 和 ASE 等核心场所，以及 arXiv 上。然而自 2023 年起，发表在期刊上的关于基于 LLM 的测试的文章显著增加，包括 TSE、IST、ACM TOSEM 和 JSS 等高排名期刊。此外，在撰写本文时，我们观察到一个明确趋势，表明我们最初在 arXiv 上找到的许多出版物在各种会议和期刊上被呈现。这一发现凸显了定期更新我们文章语料以维持研究材料准确性和相关性的重要性。

5. 基于 LLM 的测试研究结果

在本节中，我们简要总结基于 LLM 的测试研究的状态，从 5.1 到 5.6 节分别覆盖六个类别（第七个类别「反思」在第 6 节覆盖）：单元测试生成、高层测试生成、Oracle 生成、测试扩充或改进、非功能测试，以及测试 agent。对每个类别，我们包含一个尝试给出该类别工作中 LLM 如何被使用的通用过程的示意。这个示意本身作为把握该主题快速概览的贡献而提供。

5.1 单元测试生成

从一开始，LLM 就在很大程度上被用于单元测试的自动生成。原文表 1 分类了 40 篇关于基于 LLM 的单元测试生成的文章。图 3 描绘了单元测试用例生成的过程。

基于 LLM 的单元测试生成的输入（图 3 Ⓐ）可属于三种类型（以不同方式组合）：（1）被测程序（PUT，最常见），（2）功能文本描述，如缺陷报告、文档、提交信息、缺陷补丁或自然语言请求，或（3）预先存在的测试用例。一些工作用更多上下文整合这些输入以增强单元测试生成。提供到上下文中的额外信息的例子有文档、期望输出的示例、额外源码（如测试方法签名、PUT 内部被调用方法的代码）、错误反馈或测试用例示例。

这个上下文被放入精心设计的提示词（图 3 Ⓑ），用于查询 LLM 生成单元测试用例。LLM（图 3 Ⓒ）可以是通用模型（如 ChatGPT、CodeLlama、Gemini）或微调版本（图 3 Ⓓ）。单元测试用例生成中的微调用测试用例示例、PUT、PUT 与测试用例的配对来完成。

LLM 产出一个或多个测试用例（图 3 Ⓔ）。一些方法包含一个验证阶段（图 3 Ⓕ），用以（1）丢弃无效测试用例（图 3 Ⓗ），或（2）用 LLM-in-the-loop 迭代地修复或改进测试用例生成。在单元测试用例生成中，验证阶段生成的额外上下文被纳入 LLM（图 3 Ⓖ）以引导和改进生成的测试用例。纳入上下文的额外信息的例子有测试覆盖率、测试语法错误、测试坏味道、失败追踪、编译问题或缺陷检测率。最终输出是一个到若干个经过验证的单元测试用例（图 3 Ⓘ）。

单元测试生成中的一个明确趋势是 LLM 与现有工具的整合以做增强。例如一些作者把 LLM 与数据生成工具结合，用 ML 方法增强 LLM 以检测幻觉并改进 LLM 输出，补充现有方法（例如使其能达到 SOTA 工具无法覆盖的情形），把 LLM 与现有变异测试工具结合，或补充增强这些工具所用的算法。

不同方法和工具采用了广泛的 LLM：GPT 系列占主导，但也有开源模型如 Llama 系列、代码专用 LLM 如 CodeLlama 和 StarCoder，还引入了为特定单元测试生成任务量身定制的新模型，如 TECO、CAT-LLM 或 AthenaTest。这些模型的性能用不同指标评估：作为单元测试生成，它们能访问 PUT 代码，可用测试覆盖率、变异率、缺陷检测率和测试坏味道数量等指标。然而它们也用 LLM 制作的指标，如 NLP 指标 BLEU、ROUGE 和 XMatch，或执行指标，如正确运行、构建和通过的测试用例百分比。

一般而言，单元测试生成的文章使用 SOTA 方法所用的数据集和基准，取决于生成测试用例所用的编程语言。这些基准的例子有 Defects4J、Pynguin、BugsInPy、Codesearchnet、Apps、SF11 或 MBPP。此外，若干基准已为基于 LLM 的单元测试生成的特定目的而发布，如 TESTEVAL（人工制作的 Python 程序，用于评估单元生成性能）、Classes2Test（从 Methods2Test 派生，用整个类而非仅测试方法），或 Testsuite V&V。

最后，一些作者呈现了工具，如 CasModaTest、JSONTestGen、A3Test、CodeT、AgoneTest、ChatUnitTest、exLong 或 TestPilot，它们利用 LLM 生成单元测试或改进现有测试套件。

5.2 高层测试生成

高层测试生成是贡献第二多的类别，在所回顾的 130 篇中有 28 篇。高层测试验证整个软件系统，从用户与界面的交互或对 API 端点的调用，到像数据库插入或删除这样的持久化操作。基于 LLM 的高端测试文章可分三组：测试场景与数据生成、测试脚本推导，以及其他用法。图 4 表示高层测试生成过程，黄色是①场景与数据生成，红色是②测试脚本推导，紫色表示③在测试脚本生成中使用 LLM-in-the-loop。需说明，由于其异质性，归入「其他用法」的工作未在过程模型中表示。

#### 5.2.1 测试场景与数据生成

涵盖旨在输出一个或多个测试场景（「用作生成测试用例基础的、针对某测试项的情形或设定」，用自然或人机可读语言）的方法和工具。在图 4 中以黄色表示，这些方法和工具使用纯提示的 LLM 方法，用提示技术提供示例，如 Few-Shot 或思维链。所提供的需求（图 4 Ⓐ）示例是规格，如系统需求、用户需求，但也有结构化程度更低的输入，如缺陷报告。期望输出是要执行的动作集（图 4 Ⓓ），可用自然语言或像 Gherkin 这样的结构化语言表达。生成场景的 LLM 的性能以覆盖的需求、自然语言下的传统 NLP 指标（如 METEOR、BLEU 或 ROUGE）、语法错误，以及金钱或时间成本来衡量。

数据生成涵盖那些严格聚焦于生成测试输入或参数以测试应用的文章。用于生成测试数据的输入也是需求（图 4 Ⓑ），但还有作为待变异-改进上下文的有效输入，或上下文信息（如控件细节、父级、叶子）。这些输入被直接提示给 LLM 以检索数据（图 4 Ⓔ），但一些工作也在期望的输入-输出对中用它们来微调模型（图 4 Ⓒ）并改进性能。这些生成输入的质量以测试正确性、测试通过和检测到的缺陷数来衡量。

测试数据和场景生成中没有 SOTA 基准，所用 LLM 属于 GPT 和 Llama 系列，以及较不流行的 LLM 如 ChatGLM、FinBert 或 Palm2。

#### 5.2.2 测试脚本推导

基于 LLM 的端到端测试中的测试脚本推导更异质；我们设想三个不同组：测试生成、用 LLM-in-the-loop 的测试生成，以及数据生成方法。测试脚本推导描绘在图 4 右侧，分为测试脚本推导（图 4 ②，红色）和 LLM-in-the-loop（图 4 ③，紫色）。

测试生成方法以应用应如何行为作为输入（图 4 Ⓓ），可用自然语言场景、文档/规格或使用模式来指定，它们连同期望输出的示例（图 4 Ⓖ）被提示给 LLM。其他工作用带领域知识的测试用例示例，或编程语言或自然语言中的测试用例示例来微调模型（图 4 Ⓗ）。脚本推导过程的输出是编程语言或自然语言中的不同测试用例（图 4 Ⓘ，带步骤、输入和期望输出）。

这些方法的性能以不同方式衡量：无法访问应用代码的黑盒方法用输入所提供场景的覆盖好坏、金钱-时间成本、所需人力、NLP 指标或生成测试用例的正确性来衡量。能拿到应用代码的方法大多用覆盖率的不同变体（如行、方法、分支）。

用 LLM-in-the-loop 的测试生成（图 4 ③）与标准测试生成方法的不同在于 LLM 被使用的方式，采用所谓的 LLM-in-the-loop。这个方法包括多次迭代模型，增加上下文（图 4 Ⓙ），而不是「带示例的单次射击」，在每次交互中增强可用信息。LLM-in-the-loop 方法以 GUI 图像或其上下文描述、每次交互的上下文，或其功能描述作为输入。

这些信息被提示给通用 LLM，但一些方法也用期望输入和答案微调 LLM（图 4 Ⓗ）。这些方法的输出（图 4 Ⓘ）是要执行的一系列活动任务，其性能以覆盖-探索的活动或状态数、缺陷、成本和生成行数，以及正确通过的测试数来衡量。

一般而言，高层测试生成中没有确立良好的基准；一些文章提出了新基准来评估基于 LLM 的高端测试技术的性能。就所用 LLM 而言，GPT 系列（GPT 3.5、4、4o）占主导，但也有开源模型如 Llama 系列、Llava、Mistral 或 Chat-GLM。

#### 5.2.3 其他用法

其他用法涵盖那些因其性质属于高层测试、但无法归入前两组的文章。在其他用法中，我们发现有文章覆盖用 LLM 做测试迁移，迁移到新框架或应用。在所考虑的文章中，有两项工作探索了测试迁移能力：一项探索跨框架和跨应用的 LLM 迁移能力，以及提供输入代码、上下文或 GUI 信息的测试生成；另一项提出把集成-E2E 测试用例迁移到契约测试用例。模型的输出是那些被迁移的测试用例，其性能以测试覆盖率或依赖-幻觉数来衡量。

其他工作用 LLM 生成一组初始测试用例，然后变异它们以发现缺陷，或微调 LLM 以优化另一种 AI 技术的超参数。这些方法的性能以缺陷检测率评估。这些类别中没有确立良好的基准，因此所有贡献都用自定义基准。所用 LLM 属于 GPT 系列，但也有其他较不流行的模型如 Qwen2、Mistral 或 Gemini。

5.3 Oracle 生成

软件测试的一个困难部分是 oracle 的生成。即使像 EvoSuite 这样的测试生成工具能检测大多数缺陷，它们仍依赖 oracle。这些非 LLM 工具的用户并不总是喜欢生成的 oracle，某些情况下更愿手工生成它们。这些非 LLM 工具有时生成回归 oracle，而不是利用文档。注意大多数 GitHub 项目有自然语言文档。LLM 能补充传统工具来生成分析文档等的测试 oracle。

原文表 2 分类了 26 篇用 LLM 处理 oracle 问题的文章。大多数贡献通过类断言语句（58%）和蜕变关系（19%）生成 oracle。其余 23% 的文章是关于当前基于 LLM 的方法的综述或实证研究。图 5 描绘了 20 种基于 LLM 的方法如何以断言（图 5 Ⓐ）或蜕变关系（图 5 Ⓑ）的形式生成 oracle。

表 3 指出了基于 LLM 的方法用来生成 oracle 的输入。一般而言，提示词是被测程序（75%）、测试前缀（60%）、一些上下文信息（55%）和示例（10%）的组合。测试前缀向 LLM 指明测试用例的目标。提示词通常包含被测程序以帮助 LLM 理解正在测什么，有时带焦点方法的代码（60%）、签名（20%），或提供其他方法/类（25%）。LLM 也用不直接在程序代码中的上下文信息，如文档（20%）、规格（30%）或依赖（10%）。提示词也可包含 oracle 示例（15%）以引导 LLM 生成新的。

根据图 5，提示词只是整个基于 LLM 的方法的一部分，因为它们通常用其他工具或测试者经验来补充。为生成断言（图 5 Ⓐ），LLM 接收程序/测试信息并生成断言、后置条件或不变式形式的 oracle。这个断言与测试前缀组装以得到完整测试用例。接着，测试用例可通过纳入库/包并解决小的语法问题（如未闭合时加括号）来改进。最后，测试用例被编译和执行以检测断言中的问题。如果测试有编译/执行问题，可再次提示 LLM 基于错误信息精炼测试用例。

另一方面，旨在推导和生成蜕变关系的基于 LLM 的方法遵循图 5 Ⓑ 的过程。首先，LLM 只接收程序规格并推导若干蜕变关系。如果它们不够好，测试者再次提示 LLM 提供反馈以增强它们。一旦蜕变关系被推导，LLM 考虑被测程序和一些示例生成可执行代码。

与 oracle 相关的第三组文章（表 2）是关于反思的。Molina 等人综述了 2020 到 2024 年关于 LLM 和 oracle 的 37 篇文章。注意我们的研究更广，我们把这 37 篇中的一些归入其他类别。例如，我们把那些主要聚焦于生成测试结构而非处理断言的关于测试补全的文章归为「单元测试生成」（5.1 节）。在 Molina 等人的综述中，他们分析了挑战和未来方向。其中一个挑战是基于 LLM 的方法检测缺陷的能力。Zhang 等人做了一项广泛研究，结论是基于 LLM 的方法在生成 oracle 上优于其他最先进技术。他们还分析了使用微调的潜力。在这个方向上，Yibo 等人研究焦点方法并提出一个可用于微调模型的数据集。评估基于 LLM 的方法是有挑战的，Jiho 等人比较了常用指标。他们发现文本指标（如 BLEU）和测试充分性指标（如变异分数）之间关系薄弱，因此作者不推荐用文本指标来评估 oracle 的有效性。评估的另一个问题是使用不恰当的设定。Soneya 等人发现一些缺陷仅由测试前缀代码的异常触发，与生成的 oracle 无关。如果这在实验中不受控，它会高估缺陷能力。为此，Zhongxin 等人提出用一个叫 NoException 的基线来检查测试前缀不抛异常。

若干文章把 TOGA 和 ATLAS 当作最先进技术并用它们作基线。一方面，TOGA 在 Defects4J 上检测到的缺陷方面优于 AthenaTest 和其他预训练 BART。同时，TOGA 被若干其他方法超越：检测到更多缺陷的方法（n2postcond 和 TOGLL）；改进成功率的方法（AugmenTest）；有更高准确率和 BLEU 相似度的方法（AssertT5、TECO 和 ChatAssert）。尽管超越 TOGA，它们中一些是互补的，因为检测不同缺陷。另一方面，ATLAS 是另一个常用作基线的基于 LLM 的方法。CEDAR 等方法改进了准确率。AssertT5、TECO 和 ChatAssert 不仅改进准确率还改进 BLEU。最后，有方法同时改进了准确率和缺陷检测。

其他文章不用 TOGA 或 ATLAS 作基线。A3Test 生成比 AthenaTest 和 ChatUnitTest 更好的断言。同时，A3Test 在准确率上也被某方法超越，后者也超越 CAT-LM。

用于评估断言的常用指标可分为与文本相似度相关的或与测试充分性相关的。这些指标通常与人工创建的真值 oracle 比较。精确匹配准确率比较两者是否相等，而 ROUGE、METEOR 和 BLEU 指标计算它们有多相似/相异。另一个指标是 EditSim，衡量在 oracle 中得到真值所需的更改数。另一方面，最常用的充分性指标是找到的缺陷数/百分比和变异分数。一些文章还测量执行时间、覆盖率和编译/执行的成功率。

评估中常用的基准是 Defects4J、Methods2Test、ATLAS 和 CodeSearchNet。然而，用来自 GitHub 或其他仓库的自定义基准评估断言也很常见。

5.4 测试扩充或改进

这一类别工作的共同目标是利用 LLM 增强针对基准或工业应用的现有测试套件。我们认为这类增强通过遵循若干策略达成：扩充现有测试套件，或对整体测试过程带来一些改进。

图 6 描绘了基于 LLM 的测试扩充方法的高层交互示意。该示意是迭代的，由基于某些质量属性的充分性分析引导。总体而言，过程可总结如下：首先，针对所考虑的 PUT 评估当前测试套件的质量；对所观察结果的充分性分析引导将提交给 LLM 的提示词的工程。与 LLM 交互的期望产出是一组新测试用例；因此评估它们的质量（可能也考虑原始测试套件）。这几步被迭代重复，直到满足期望的充分性标准。所得的扩充测试套件随后用于验证 PUT，并可能通过利用额外迭代进一步改进。

在这个交互示意下，充分性分析可指若干（替代的）质量标准。例如有工作使用覆盖率信息；而其他工作指基于变异体的缺陷检测能力。两种情况下，充分性分析结果都可用于提示 LLM 生成覆盖 PUT 特定且尚未被考虑的功能或部分的测试用例。

在其他工作中，LLM 被用作现有自动化测试用例生成方法的补充；例如，为克服它们在所考虑充分性指标达到局部最优时的已知问题。具体来说，有工作利用传统 SBST 方法直到其覆盖率改进停滞，然后该方法调用 LLM 来提供处理考虑不足的函数的测试用例。这些新测试用例被用作 SBST 后续迭代的种子。类似地，有工作通过灰盒模糊测试方法生成测试输入，当它不再能成功增加覆盖率时，提示 LLM 生成一个能克服任何覆盖率平台期的新输入。

测试扩充中的一些方法自主运行或只有有限人工交互；其他则明确预见人在回路。例如在某工作中，人收集/定义为基于特定游戏引擎构建的游戏的测试用例集。这些测试也用于微调一个面向代码的 LLM。所得模型随后用于生成额外的单元测试用例。在这个具体工作中，生成过程主要由覆盖率改进引导。它仍利用 RAG 来保持合成的单元测试与特定开发实践对齐。

测试改进中的工作调查采用 LLM 如何能影响既定的软件测试实践。例如，有工作研究如何通过更接近开发者真实缺陷的变异体来改进变异测试。类似地，一些工作支持为领域特定语言（如某工作中的 Simulink 模型）生成变异体，与基于变异模式的规范变异体不同，它们更容易追踪到需求违规。

LLM 也能贡献于测试过程的改进。例如，它们已被用于支持与给定 PUT 相关的制品（如规格、测试代码）的演化。在这个方向上，有工作提出用与 LLM 交互返回的信息（如数据约束、示例和规则）增强 REST 服务的 OpenAPI 规格。那里，提示由原始 OpenAPI 规格的机器可读和人类可读部分中都明确可用的数据引导。不同地，也有工作处理测试用例和目标 PUT 的协同演化：例如有工作利用来自 PUT 或其使用的给定上下文信息，来自动更新可能过时的测试用例。

不稳定（Flakiness）通常指同一组测试用例在演练未变代码时表现出的间歇性通过和失败结果。理解不稳定的根本原因是一个主要问题，过去几年被深入研究。LLM 也已被用于解析测试用例实现以预测它是否不稳定。如某工作所报告，预见的优势是（微调的）LLM 能达到好的分类准确率，同时避免多次重跑测试的需要。值得注意的是，这些工作把测试改进作为主要关注点，因为它们聚焦于测试本身，而非现场可能最终经历的操作条件。一旦某个特定的不稳定测试被揭示，LLM 也可用于基于所识别的不稳定类别引导其演化。

5.5 测试 Agent

测试 agent 是与用户交互并自动化测试任务的轻量客户端，如测试套件配置和执行、测试生成、安全测试，或充当人类与广泛测试任务之间的接口。图 7 描绘了基于 LLM 的测试 agent 的过程。测试 agent 的特征是有「测试者在回路」，即发起第一次交互或与 agent 执行任务的个体。测试工程师把上下文给 agent（图 7 Ⓐ-Ⓑ），要求 agent 执行某任务，例如带对项目或其 URI 的引用，或发起某过程。在所回顾的文章中，测试 agent（图 7 Ⓒ）可提示 LLM，用自定义提示词并检索答案。另一项工作提出采用最合适的 agent，重定向请求（图 7 Ⓓ）并等待其响应。

LLM 或 agent 的答案可被重定向给用户，或派生成特定动作（图 7 Ⓖ），如配置和执行测试套件或其他系统、生成测试用例、检查系统的非功能质量。

这些 agent 的评估使用依赖上下文的基准（如移动测试用例针对 Themis 应用基准执行）和指标（如生成测试用例时用通过或构建的测试用例百分比，而安全测试中用成功的漏洞利用）。大多数工作采用 GPT 系列模型、开源模型如 Llama，以及代码专用模型如 CodeLlama。

5.6 非功能测试

非功能的基于 LLM 的测试类别有 8 篇文章，主要聚焦安全和可用性测试。其中一些工作遵循测试 agent 过程（见图 7）、用 LLM-in-the-loop 的高层测试生成（见图 4），而其他遵循图 8 描绘的简单过程。

安全文章用系统规格作为输入，如 OpenAPI（用 API 片段和历史测试数据增强）、状态图、抓取应用的上下文和 UI，或测试者提供的上下文。这些工作用通用 LLM，但也有用需求和示例微调模型的方法。检索到的可用性文章用 UI 上下文作为输入来提示 LLM，并检索出可用性测试中要执行的不同任务作为输出。

在安全和可用性中，模型都被给予必要上下文来提示，遵循不同过程中描绘的策略，并输出执行某动作（如一次攻击）的不同步骤、若干测试用例，并执行该动作。

这些方法用特定于其领域和期望结果的指标和基准评估。大多数利用 GPT 系列的 LLM，以及 Llama 系列、Mistral、Gemini 或 Qwen 2 的 LLM。

本文因篇幅分为上下两篇。下篇（第 6 节挑战与路线图、第 7 节结语、署名与许可）：用于软件测试的大语言模型：研究路线图·下