使用大语言模型进行自动化基于模型的测试生成的实证评估

使用大语言模型进行自动化基于模型的测试生成的实证评估（中文全译）

翻译说明：本文是 arXiv 论文 An Empirical Evaluation of Using Large Language Models for Automated Model-Based Test Generation（arXiv:2608.27094）的中文全译，由智测团队翻译。原作者：Hafize Sanli、Onur Kilincceker、Cihat Cetinkaya。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

Hafize Sanli

Onur Kilincceker

Cihat Cetinkaya

摘要

大语言模型（LLM）在自动化、分析和解释软件工程任务（如软件测试）方面展现出强大的潜力。基于模型的测试（MBT）是一种软件测试技术，其广泛的规模化挑战阻碍了工业界的采用。本文提出了一项关于使用大语言模型进行自动化基于模型测试生成的实证评估，以应对规模化挑战，并与最先进的基于模型测试工具及其内置算法进行比较。我们的评估表明，在四个真实系统（两个 Web 应用程序和两个硬件应用程序）上使用最新的大语言模型优化和缩短测试路径及步长具有强大的潜力。

关键词：实证评估、大语言模型、基于模型的测试生成、基于模型的测试

自动基于模型测试生成中大语言模型使用的实证评估

摘要

大语言模型（LLM）在自动化、分析和解释软件工程任务（如软件测试）方面展现出强大的潜力。基于模型的测试（MBT）是一种对工业界采用提出广泛规模化挑战的软件测试技术。本文提出了针对自动基于模型测试生成使用大语言模型（LLM）的实证评估，以解决规模化挑战，并与最先进的基于模型测试工具及其内置算法进行比较。我们的评估表明，在四个真实系统（两个 Web 应用程序和两个硬件应用程序）上使用最新的大语言模型来优化和缩短测试路径和步骤大小具有强大的潜力。

关键词：实证评估、大语言模型、基于模型的测试生成、基于模型的测试

1 引言

大语言模型在自动化、分析和解释软件工程任务方面展现出显著的潜力 Hou et al. (2025); Fan et al. (2023)。作为软件工程活动的一部分，它们也积极参与到软件测试过程中 Wang et al. (2024); Molina et al. (2025); Li et al. (2025); Schäfer et al. (2023)。

基于模型的测试（MBT）是一种使用模型来描述被测系统（SUT）预期行为的软件测试方法 Dalal et al. (1999); Utting and Legeard (2010)。自动化测试生成是基于模型测试的基本组成部分，测试人员可以生成抽象测试用例（离线模式）或直接在被测系统上运行自动化测试用例（在线模式）。它已经显著发展，大量研究将其应用扩展到 Web、移动和嵌入式系统 Garousi et al. (2021); Karlsson et al. (2021); Zafar et al. (2021)。许多研究和分类法对广泛的 MBT 工具和技术进行了分类 Utting et al. (2016); Li et al. (2017); Gurbuz and Tekinerdogan (2018); Ahmad et al. (2019)。

可扩展性对 MBT 的工业采用提出了广泛的挑战 Dalal et al. (1999); Hemmati et al. (2010b); Hemmati et al. (2010a); Koroglu et al. (2025)。常见实践表明，较长的测试更可取 Arcuri (2010)；然而，先前关于测试缩减的工作表明，实现相同覆盖目标的更紧凑测试用例可增强可扩展性 Rothermel et al. (2002); Coutinho et al. (2016)。

在本研究中，我们对用于自动化基于模型测试生成的大语言模型（LLM）进行实证评估，以应对可扩展性挑战。具体而言，我们研究了 LLM 在生成较短测试方面与具有内置算法的最先进基于模型测试工具（GraphWalker[^1]）相比的表现如何。

[^1]: 参见 https://graphwalker.github.io

基于上述所有讨论，我们向文献提供以下贡献：

• 我们提出了一个自动化管道（称为 LLM4MBT），用于通过 LLM 自动化基于模型的测试生成过程。
• 我们引入了关于使用最新 LLM 进行自动化基于模型测试生成的实证评估。
• 我们在四个真实的 SUT 上进行实验：两个 Web 应用程序（Parabank 和 Testinium）和两个硬件应用程序（TLC 和 RISC-V），以回答 5 个研究问题，并展示 LLM4MBT 的可行性。
• 我们在 https://github.com/hafizesanli/LLM4MBT（Version 1）公开分享我们的数据集、LLM4MBT 管道实现和复现说明。

本文的其余部分组织如下：第 2 节介绍我们提出的方法，第 3 节介绍研究问题和评估设置，第 4 节介绍我们的实证评估。第 5 节描述了对有效性的潜在威胁，包括其缓解方法。第 6 节讨论相关工作，第 7 节总结论文并分享未来工作。

2 方法

我们的工作提出了一个系统框架，用于评估大语言模型（LLM）为 GraphWalker 模型生成有效基于模型测试套件的能力。与依赖算法遍历或启发式探索的传统自动化测试生成方法不同，我们研究 LLM 是否能够利用其学到的软件测试原理和 GraphWalker 规范知识，生成满足特定覆盖标准的测试路径。

我们的方法论评估了五个最先进的 LLM（GPT-5.1、GPT-5.2、Claude Opus 4.5、Claude Sonnet 4.5 和 Gemini 2.5 Pro），针对四个复杂度递增的 GraphWalker 模型。这些模型的范围从简单的交通灯控制器（TLC）到高度复杂的企业测试管理平台（Testinium），后者包含 129 个顶点和 259 条边。主要目标是确定单个结构良好的提示是否能够引出满足预定义覆盖目标的语法和逻辑上有效的测试套件。

图 1：LLM4MBT 管道架构

2.1 LLM4MBT 管道架构

我们提出的 LLM4MBT 框架实现了一个多层管道架构，用于在基于模型测试生成的背景下对 LLM 进行系统评估。图 1 展示了完整的系统架构，该架构由遵循 C4 模型架构原则 Vázquez-Ingelmo et al. (2020) 的四个不同容器组成：输入层、测试生成层、处理层以及评估与报告层。

输入层：

管道始于输入层（图 1 中的容器 1），该层管理实验框架的所有输入数据源。该层包括两个主要组件：(i) 图模型，由四个以 JSON 格式表示的 GraphWalker 模型组成——TLC（10 个顶点，18 条边）、Risc-V（16 个顶点，36 条边）、Parabank（75 个顶点，144 条边）和 Testinium（129 个顶点，259 条边）——它们的复杂度差异显著，以便在不同规模上进行全面评估；(ii) 提示，存储在 prompts.json 中，其中包含针对三种不同路径生成策略的手动制作提示模板：随机边覆盖（REC）、快速随机边覆盖（QEC）和顶点覆盖（VC）。这些输入组件被分发到后续层，以促进所有实验条件下的系统测试生成。

测试生成层：

测试生成层（图 1 中的容器 2）代表了我们评估框架的核心实验对象。该层纳入了五个最先进的 LLM 作为外部系统：来自 OpenAI 的 GPT-5.1 和 GPT-5.2、来自 Anthropic 的 Claude Opus 4.5 和 Claude Sonnet 4.5，以及来自 Google 的 Gemini 2.5 Pro。每个 LLM 接收相同的输入，包括图模型和特定于策略的提示，确保实验一致性。该层的组合设计（5 个 LLM × 3 种策略 × 4 个模型）生成 60 个不同的测试套件，这些套件被系统地组织到特定于策略的目录（REC-、QEC-、VC-*）中，以便后续处理和分析。

处理层：

处理层（图 1 中的容器 3）实现了测试执行和覆盖分析的核心计算逻辑。该层由四个相互连接的组件组成：

模型解析器：在 graph_conversions.py 中通过 generate_graph_from_graphwalker_json() 函数实现，该组件将 JSON 模型规范转换为内部图表示，提取顶点、边及其关系以供后续处理。

测试解析器：位于 main.py 中并通过 parse_test_suite_from_file() 实现，该组件处理 LLM 生成的测试套件，以 GraphWalker 的原始格式提取各个测试用例，其中每个元素都表示为包含 currentElementName 字段的 JSON 对象。

执行引擎：负责路径验证和测试执行，该组件（main.py 中的 apply_test_execution_on_model()）验证生成的路径是否符合模型的图结构。它结合了智能回退机制（find_fallback_vertex()）来处理无效转换，从而即使 LLM 生成部分错误的测试序列也能进行公平评估。

覆盖分析器：通过 graph_conversions.py 中的 calculate_coverage() 实现，该组件计算两个基本指标：边覆盖（EC）和顶点覆盖（VC），定义为：

$$EC = \frac{|E_{visited}|}{|E_{total}|} \times 100, VC = \frac{|V_{visited}|}{|V_{total}|} \times 100$$

(1)

其中 $E_{visited}$ 和 $V_{visited}$ 分别表示 traversed 边和顶点的集合。

为确保有效性，覆盖分析器的计算会针对 GraphWalker 原生测试生成引擎生成的参考基线进行验证，如图 1 中的虚线验证箭头所示。

评估与报告层：

最后一层（图 1 中的容器 4）实现了评估逻辑和报告生成机制。决策组件根据条件：$EC \geq 70\%$ 或 $VC \geq 85\%$ 将每个测试套件分类为 PASS 或 FAIL。这些阈值是基于基于模型测试充分性的行业标准建立的。

报告生成器组件（main.py 中的 save_single_test_report() 和 save_comparison_reports()）生成两类输出：(i) 个人报告，存储在 test_reports/ 中，以 JSON 和可读文本格式独立记录每个测试套件的性能；(ii) 比较报告，存储在 comparison_reports/ 中，汇总所有 LLM 和策略的结果，以促进比较分析。这些报告为所有 60 个实验条件提供了覆盖指标、执行统计数据和通过/失败结果的全面文档。

图 1 所示的模块化架构在保持关注点清晰分离的同时实现了系统评估：数据管理（输入层）、测试生成（测试生成层）、执行和测量（处理层）以及结果聚合（评估与报告层）。这种设计促进了可重复性和可扩展性，以便未来研究纳入额外的模型、LLM 或覆盖策略。

2.2 算法详情

评估框架采用严格的验证算法来评估 LLM 生成路径的质量。核心逻辑围绕路径验证和覆盖分析。

执行逻辑和回退机制：

执行引擎迭代生成测试套件中的每个转换。对于每一步，算法验证当前顶点 $V_n$ 和目标顶点 $V_{n+1}$ 之间是否存在边 $E$。为了考虑 LLM 的随机性质，我们实现了回退恢复机制：

如果遇到无效转换，引擎不会终止整个套件。相反，它会尝试从已知稳定顶点（例如"start"或"v_Login"）重新启动遍历。这允许测量"部分成功"并确保套件的有效部分仍计入总覆盖范围。

覆盖指标：

我们的框架计算两个主要指标来评估 LLM 生成测试套件的质量，成功标准定义为边覆盖 $\geq 70\%$ 或顶点覆盖 $\geq 85\%$：

边覆盖（EC）：量化测试执行期间遍历的唯一边占模型中总边数的比例。正式定义见公式 (1)，其中 $E_{visited}$ 表示测试套件遍历的边集，$E_{total}$ 表示模型中定义的所有边。

顶点覆盖（VC）：测量测试执行期间访问的唯一顶点占模型中总顶点数的比例。该指标定义见公式 (1)，其中 $V_{visited}$ 表示测试套件访问的顶点集，$V_{total}$ 表示模型中的所有顶点。

这些指标提供了测试充分性的互补视角：边覆盖强调转换测试（状态之间的交互），而顶点覆盖专注于状态空间探索。双重标准确保实现高转换覆盖或全面状态覆盖的测试套件都被视为成功，适应不同的测试优先级和模型特征。覆盖分析器针对 GraphWalker 原生测试生成引擎生成的参考基线验证这些计算，以确保测量准确性。

示例

为了演示 LLM4MBT 管道的端到端操作，我们使用 TLC 模型（10 个顶点，18 条边）和应用随机边覆盖（REC）策略的 GPT-5.1 呈现一个具体的执行场景。

阶段 1：输入准备。框架加载 TLC.json，它定义了一个具有 10 个顶点（start、q0 到 q8）和 18 条边（标记为 a 到 s）的有限状态机，表示一个确定性有限自动机。同时，从 prompts.json 检索 REC 策略提示，指示 LLM 通过随机探索生成实现 100% 边覆盖的测试路径。

阶段 2：测试生成。GPT-5.1 接收模型规范和提示，生成测试套件文件 REC-GPT-5.1/TLC.txt。输出由 91 个以空格分隔的 JSON 对象组成，采用 GraphWalker 的原始格式：

{"currentElementName":"start"}
{"currentElementName":"s"}
{"currentElementName":"q0"}
{"currentElementName":"h"}
{"currentElementName":"q8"} ...

该序列表示通过状态机的遍历路径，试图系统地执行所有转换。

阶段 3：模型解析。模型解析器组件（generate_graph_from_graphwalker_json()）将 TLC.json 转换为具有邻接表的内部图表示，从而实现高效的路径验证。例如，它识别出 start 通过边 s 连接到 q0，q0 通过边 h 连接到 q8。

阶段 4：测试解析。测试解析器（parse_test_suite_from_file()）从生成的文件中提取 91 个元素名称，生成顺序列表：[start, s, q0, h, q8, a, q1, b, q2, ...]，表示通过自动机的完整路径。

阶段 5：执行引擎。框架验证序列中的每个转换。当处理 start → s → q0 → h → q8 时，它确认每条边都存在于模型中并连接指定的顶点。在此执行中，所有 45 个路径转换都成功验证，无需任何回退机制，表明 GPT-5.1 生成了完全有效的测试序列（all_paths_valid: true, success_rate: 100.0%）。

阶段 6：覆盖分析。执行后，覆盖分析器（calculate_coverage()）确定遍历了 18 条边中的 17 条（$EC = 94.44\%$），并且访问了所有 10 个顶点（$VC = 100\%$）。分析器识别出模型中的一条边从未被执行，提供了覆盖缺口的诊断洞察。

阶段 7：评估。决策组件应用成功标准：由于 $EC = 94.44\% \geq 70\%$，尽管缺少一条边，测试套件仍获得 PASS 判定。这一灵活的阈值适应了随机路径生成的随机性，同时保持了质量标准。

阶段 8：报告生成。报告生成器生成两个输出：

• test_reports/TLC_20260206_145837.json：机器可读记录，包含详细指标，包括执行统计信息（total_paths: 45, successful_paths: 45, failed_paths: 0）、覆盖指标（covered_edges: 17/18, covered_vertices: 10/10）和通过/失败状态。
• test_reports/TLC_20260206_145837.txt：可读摘要，显示"PASSED — Edge: 94.44% — Vertex: 100%"。

阶段 9：比较分析。在完成个人测试套件评估后，研究人员可以通过命令行界面调用比较功能：python main.py --compare REC-GPT-5.1/ REC-Claude-Opus-4.5/ REC-Gemini-2.5-Pro/。此命令执行 compare_llm_outputs() 函数，该函数聚合指定 LLM 目录的结果并生成 comparison_reports/llm_comparison_20260206_150000.json。比较报告揭示了 LLM 之间的性能变化：虽然 GPT-5.1 在 TLC 模型上实现了 94.44% 的边覆盖率和完美的路径有效性（45/45 成功路径），但其他 LLM 可能表现出不同的覆盖模式，或者需要回退机制来处理无效转换。这种选择性比较方法使研究人员能够专注于感兴趣的特定实验条件，例如比较单一策略（REC）上的所有五个 LLM，或评估一个 LLM 在所有三种策略（REC、QEC、VC）上的表现，为基于模型的测试生成任务中 LLM 能力差异提供灵活、定量的证据。

这种模块化工作流设计将测试执行与比较分析分离，允许研究人员自主运行所有 60 个测试套件，然后根据其分析目标执行有针对性的比较，确保可重复评估，而无需为每个比较场景进行完全重新执行。

3 研究问题和评估设置

本节介绍我们的研究问题、动机以及进行实验以解决这些问题的实验设置。

3.1 研究问题

我们的实证评估旨在解决以下研究问题（RQ）。

覆盖评估

RQ1：LLM4MBT 在基于模型的测试生成中在多大程度上实现了顶点和边覆盖？

在 GraphWalker 中，我们将边的覆盖率和顶点的覆盖率设置为 100%。在我们使用的 LLM 提示中，我们也设置了 100% 的覆盖目标；然而，由于失败的测试路径，我们通常不期望任何 LLM 达到 100% 的覆盖率。

比较分析

RQ2：LLM4MBT 生成的测试步骤的覆盖率与 GraphWalker 基线相比如何？

如 RQ1 所述，虽然我们不期望 100% 的覆盖率，但总体测试步骤长度预计会比 GraphWalker 基线短。我们的动机是突出这些比较。

消融研究

RQ3：特定提示组件如何影响 LLM4MBT 生成的测试步骤的有效性？

作为我们消融研究的一部分，我们旨在检查 LLM 在不同提示下的行为，并量化它们对整体性能的个体贡献。

模型依赖性

RQ4：LLM4MBT 实现的覆盖率在多大程度上与底层 LLM 的能力相关？

实验结果可能会因使用的五个最先进的 LLM 而异，我们旨在量化这些结果在多大程度上依赖于底层 LLM。

3.2 评估设置

我们的评估涵盖了两个领域（嵌入式系统和 Web 应用程序）的 4 个真实 GraphWalker 模型。交通灯控制器（TLC）[^2] 是一个简单的嵌入式系统，是一个表示交通灯控制器的有限状态机，具有状态 q0-q8 和一个起始顶点 Kilinccceker et al. (2018); Kilincceker et al. (2022)。RISC-V[^3] 是一个嵌入式 CPU 模型，具有各种指令集和流水线 Kilinccceker et al. (2018); Kilincceker et al. (2022)。Parabank[^4] 是一个多模块银行 Web 应用程序，具有登录、注册和账户概览模块 Koroglu et al. (2025)。Testinium[^5] 是一个企业测试管理 Web 平台，具有多个模块：登录、仪表板、报告、项目、场景和套件 Garousi et al. (2021); Garousi et al. (2024)。

[^2]: 参见 https://github.com/kilincceker/MBIT4HW [^3]: 参见 https://github.com/openhwgroup/cv32e40p [^4]: 参见 https://github.com/parasoft/parabank [^5]: 参见 https://github.com/vgarousi/MBTofTestinium

如表 1 所示，我们的评估包括五个最先进的 LLM 作为外部系统：来自 OpenAI 的 GPT-5.1 和 GPT-5.2、来自 Anthropic 的 Claude Opus 4.5 和 Claude Sonnet 4.5，以及来自 Google 的 Gemini 2.5 Pro。

表 1：实验中使用的 LLM 的特征

4 评估结果

在本节中，我们通过对表 1 中给出的四个真实 GraphWalker 模型和五个最先进的 LLM 的实验来回答四个 RQ。

4.1 RQ1：LLM4MBT 的覆盖率

为了评估 LLM4MBT 的覆盖有效性，我们在四个不同的基于模型测试项目（交通灯控制器（TLC）、RISC-V、Parabank 和 Testinium）上进行了实验，并将其与 GraphWalker 的基线策略进行比较。

如表 2 所示，LLM4MBT 实现了 100.0% 的平均顶点覆盖率和 96.3% 的平均边覆盖率，展示了全面的覆盖指标。

表 3 显示了不同 LLM 提供商之间的性能差异，表 3 显示了所有 LLM 的平均性能。这些结果表明，LLM4MBT 可以以比传统基于行走的方法更高的效率生成全面的测试套件，同时实现与基线工具相当或超过的覆盖水平。表 3 进一步证明，这种效率模式在不同 LLM 提供商之间保持一致，所有模型所需的步骤都明显少于 GraphWalker，同时实现了相当的覆盖率。

表 2：LLM4MBT 和 GraphWalker 的覆盖率和测试结果

4.2 RQ2：LLM4MBT 与 GraphWalker

虽然 RQ1 确立了 LLM4MBT 的覆盖能力，但 RQ2 检查了相对于 GraphWalker 的覆盖率与测试套件大小之间的效率权衡。表 2 揭示了 LLM4MBT 的显著效率优势。值得注意的是，LLM4MBT 仅产生约 300 个平均测试步骤，而 GraphWalker 的快速随机策略为 524 步，这在保持可比覆盖率的同时，相对于随机方法代表了实质性的效率改进。此外，表 2 显示我们表现最佳的 LLM 及其算法（Claude Opus 4.5-快速随机）对 GraphWalker 表现最佳的算法（快速随机）的平均贡献为 29.7%，基于公式 (2) 中给出的公式。此外，一旦模型规模增长，贡献差距和百分比也会增加。

$$Contribution = \frac{|TestSteps_{GraphWalker}| - |TestSteps_{LLM4MBT}|}{|TestSteps_{GraphWalker}|} \times 100$$

(2)

以平均 300 个测试步骤实现 96.3% 的平均边覆盖率，相比之下，GraphWalker 的 100.0% 覆盖率需要 6916 步（随机）或 524 步（快速随机）。这相当于相对于随机策略减少了 23.0 倍的测试套件大小，相对于快速随机策略减少了 1.7 倍，同时保持了接近完整的覆盖率。

4.3 RQ3：提示效果

作为我们消融研究的一部分，我们研究了不同的提示结构和组件如何影响 LLM 行为及其对测试生成性能的贡献。对 'prompts.json' 的分析揭示了关键的提示工程见解，如角色定义、覆盖策略规范、输出格式示例和约束指令。

术语精确性：使用"quick_random"而不是"quick random"显著提高了所有 LLM 的成功率。最初使用"quick random"的尝试经常失败或产生不正确的输出。

提供商特定行为：GPT 模型最初尝试生成 Python 脚本而不是直接的测试套件，需要明确的否定指令。Claude 模型在没有此类约束的情况下更直接地处理任务。

指令清晰度：添加明确的约束可以防止文件复制行为并提高生成质量，特别是对于 GPT 5.1，它对指令歧义表现出更高的敏感性。

模型批处理：在单个提示中生成多个模型对 Claude 模型可靠地工作，但会导致 GPT 模型失败，因此需要对每个模型使用单独的提示以获得一致的结果。

我们数据集中的 'prompts.json'（公开可用 at https://github.com/hafizesanli/LLM4MBT）包含了这些提示工程见解。

4.4 RQ4：不同 LLM 的效果

我们评估了五个最先进的 LLM，以量化模型能力如何影响测试生成性能。表 3 显示了不同 LLM 提供商之间的显著性能变化。对于快速随机边覆盖，Claude Opus 4.5 实现了最一致的高性能，在 RISC-V 和 Parabank 上获得了 100% 的边覆盖率；GPT 5.1 在 RISC-V 性能上展示了 100% 的边覆盖率，但在复杂模型上表现出变异性。Gemini 2.5 Pro 表现出最高的方差，在 TLC 和 Parabank 模型上实现了 100% 的边覆盖率，但在 RISC-V 上完全失败。对于随机边覆盖，Claude 模型和 GPT 5.2 在 TLC 和 RISC-V 上实现了 100.0% 的覆盖率。Claude Sonnet 4.5 在复杂模型上表现出优异的性能，而 Gemini 2.5 Pro 再次表现出高变异性。

表 3：模型能力排行榜：LLM4MBT 覆盖率的比较分析

Anthropic 的 Claude 模型在所有模型和策略中表现出最可靠和最一致的性能。OpenAI 的 GPT 模型显示出中等的一致性，在较简单模型上表现更好。Google 的 Gemini 2.5 Pro 表现出模型特定的优势，但缺乏泛化能力，这表明 LLM 推理能力与测试生成有效性之间存在强相关性。这些结果表明，LLM 架构差异和训练范式（表 1）显著影响测试生成质量，对于 MBT 任务，推理一致性比原始模型大小更为关键。

5 对有效性的威胁

本节介绍对我们实证评估的潜在威胁，并概述缓解这些威胁的策略。

内部有效性：

由于 LLM（Claude、GPT 和 Gemini）的生成性质，相同的提示在不同运行中可能产生不同的测试路径。我们计划通过多次迭代/种子并使用特定的温度设置（例如 $T=0$）来缓解这一问题。然而，由于我们的结果依赖于 GitHub Copilot 的能力，我们无法在当前工作中指定这些温度参数。

GraphWalker 的结果在很大程度上取决于所使用的遍历策略（例如，随机、快速随机）。因此，由于随机效应，每次运行都会产生不同的测试路径。LLM 输出本质上是随机的；对每种配置进行多次试验将产生更可靠的结果。作为未来工作，我们将通过执行多次迭代（至少 30 次）或使用种子来解决这些问题。

如 RQ4 所示，即使提示结构的微小变化也会显著影响覆盖率。然而，这些发现可能特定于我们使用的提示工程策略。为了缓解这一点，我们在实证评估中对五个最先进的 LLM 进行了消融研究。

构念有效性：

尽管高顶点和边覆盖率是标准的 MBT 性能指标，但它们并不总是与发现真实世界软件缺陷的能力相关。如果预言较弱，测试套件可能实现 100% 覆盖率而未捕获逻辑缺陷。为了解决这个问题，我们计划在模型和代码级别使用突变测试来评估它们的相关性 Belli et al. (2016); Kilincceker et al. (2021); Kilincceker et al. (2022)。因此，我们将把测试执行阶段集成到我们现有的管道架构中。

外部有效性：

我们评估了四个不同的 GraphWalker 模型（交通灯、RISC-V、Parabank、Testinium）。这些结果可能无法推广到具有数千个状态或高度非确定性行为的更大工业系统。为了解决这个问题，我们从两个不同的领域（硬件和 Web 应用程序）选择了 GraphWalker 模型。

LLM4MBT 的有效性可能因不同的建模语言（例如，Statecharts、Petri 网、BPMN）而异。为了缓解这种威胁，我们采用了学术界和工业界广泛使用的最先进的基于模型测试工具 GraphWalker。

6 相关工作

大语言模型（LLM）在软件工程中的作用已经从简单的代码助手转变为在整个软件开发生命周期（SDLC）所有阶段都活跃的战略合作伙伴。LLM 在软件测试中实现了显著的生产力提升，该领域正从手动脚本编写向自主测试代理和智能预言转变。Schäfer et al. (2023) 进行了一项关于使用 LLM 进行自动化单元测试生成的关键实证评估，其中证明了可以实现与传统工具相当的覆盖目标，同时识别复杂的边缘情况。他们的工作强调了 LLM 在自动化、分析和解释软件工程任务方面的显著潜力。

除了简单的脚本生成，LLM 现在被用作决策者来验证系统是否行为正确。Li et al. (2025) 中的实证研究支持了这一点，这些研究表明基于 LLM 的方法在检测关键缺陷方面非常有效，并且在实现覆盖目标方面与传统工具表现一样好。LLM 的实际效用已在专业领域得到实证验证；例如，Wang et al. (2025) 展示了汽车行业完整软件测试流程的成功自动化。研究表明，LLM 可以处理复杂、安全关键环境中的端到端测试生命周期。

据我们所知，没有研究系统地评估最新的 LLM 在基于图的规范下对 Web 和硬件应用程序的自动化基于模型的测试（MBT）的能力。虽然 LLM 在单元测试和一般工业过程中的有效性已得到证明，但它们在导航复杂图结构以实现优化覆盖方面的能力仍有待探索。在本研究中，引入了 LLM4MBT 管道来填补这一空白。研究表明，与传统算法相比，可以用显著更少的测试步骤维持接近完整的覆盖率，从而直接解决 MBT 中固有的可扩展性挑战。

7 结论

大语言模型在软件工程任务，特别是软件测试方面展现出强大的潜力。基于模型的测试（MBT）是一种软件测试技术。为了解决 MBT 工业采用的广泛可扩展性挑战，我们的论文提出了关于使用大语言模型进行自动化基于模型测试生成的实证评估，并与最先进的基于模型测试工具（GraphWalker）及其内置算法（用于边和顶点覆盖设置的随机和快速随机）进行比较。我们的评估表明，使用最近的五个最先进的 LLM（GPT-5.1、GPT-5.2、Claude Opus 4.5、Claude Sonnet 4.5 和 Gemini 2.5 Pro）对抗四个复杂度递增的 GraphWalker 模型（两个 Web 应用程序（Parabank 和 Testinium）和两个硬件应用程序（TLC 和 RISC-V））来优化和缩短测试路径和步骤大小具有强大的潜力。

数据可用性

数据集、LLM4MBT 管道实现和复现说明可在 https://github.com/hafizesanli/LLM4MBT（Version 1）获取。

生成式 AI 声明

在准备本作品的过程中，作者使用了 Grammarly 和 Bing Microsoft Translator 来检查语法和拼写。作者根据需要审查和编辑了内容，并对出版物的内容承担全部责任。

署名与许可

本文翻译自 arXiv 论文 An Empirical Evaluation of Using Large Language Models for Automated Model-Based Test Generation，原文以 CC BY 4.0 许可发布。

译者：智测团队

许可：CC BY 4.0