通过人类测试启发工作流实现单元测试生成的多智能体大语言模型协作

通过人类测试启发工作流实现单元测试生成的多智能体大语言模型协作（中文全译）

翻译说明：本文是 arXiv 论文 Multi-Agent LLM Collaboration for Unit Test Generation via Human-Testing-Inspired Workflows（arXiv:2607.09101）的中文全译，由智测团队翻译。原作者：Quanjun Zhang、Ye Shang、Siqi Gu、Jianyi Zhou、Chunrong Fang、Zhenyu Chen、Liang Xiao。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2607.09101v1 [cs.SE] 2026年7月10日

许可：CC BY 4.0

作者

Quanjun Zhang

单位：南京理工大学（Nanjing University of Science and Technology），中国 邮箱：quanjunzhang@njust.edu.cn

Ye Shang

单位：南京大学（Nanjing University），中国 邮箱：yeshang@smail.nju.edu.cn

Siqi Gu

单位：南京大学（Nanjing University），中国 邮箱：siqi.gu@smail.nju.edu.cn

Jianyi Zhou

单位：华为云计算技术有限公司（Huawei Cloud Computing Technologies Co., Ltd.） 邮箱：zhoujianyi2@huawei.com

Chunrong Fang

单位：南京大学（Nanjing University），中国 邮箱：fangchunrong@nju.edu.cn

Zhenyu Chen

单位：南京大学（Nanjing University），中国 邮箱：zychen@nju.edu.cn

Liang Xiao

单位：南京理工大学（Nanjing University of Science and Technology），中国 邮箱：xiaoliang@mail.njust.edu.cn

摘要

近年来，大语言模型（Large Language Models, LLMs）的出现推动了自动化单元测试生成研究的迅速增长，取得了令人瞩目的性能，并减少了人工投入。然而，现有基于大语言模型的方法仍存在两项主要局限：（1）它们遵循僵化的过程式工作流，未能充分利用大语言模型的自主推理潜力，因而难以依据实时反馈动态调整测试策略；（2）它们依赖并非为测试生成量身定制的、基于规则的上下文抽取，无法捕获推导测试需求所需的细粒度代码依赖与测试特有知识。

本文提出 TestAgent，一种基于大语言模型的测试生成方法。它通过多智能体协作机制模拟人类测试实践，以应对上述局限。具体而言，TestAgent 设计了三类专门智能体，即需求规划器、测试生成器与测试评审器，用以模拟开发者如何理解、构造并验证单元测试。为释放大语言模型的自主能力，我们为 TestAgent 配备一组工具 API，使其能够按需、自适应地动态调用。为进一步支持仓库级推理，TestAgent 借助静态分析构建面向测试的专用知识图谱：该图谱捕获项目中的代码实体及其依赖，并持久化存储生成过程中产生的测试制品（例如测试报告与失败分析）。

实验结果表明，在六个 Java 项目上，TestAgent 达到 97.46% 的执行率、92.34% 的行覆盖率、90.24% 的分支覆盖率以及 83.69% 的变异分数，在全部指标上优于基于大语言模型的基线，并且变异分数显著高于基于搜索的工具。我们还将 TestAgent 适配到 Python 项目，取得 88.85% 的行覆盖率与 78.89% 的分支覆盖率，表明其可推广性并不局限于 Java 生态。此外，在工业项目上的实验以及一项受控用户研究，证实了 TestAgent 在真实开发场景中的实用适用性。另外，TestAgent 通过非回归测试检出 154 个真实缺陷，精确率为 92.22%。总体而言，本研究凸显了受人类测试启发的多智能体工作流在产出更可靠、可扩展且实用的测试用例方面的前景。

索引词： 软件测试，测试生成，大语言模型，面向软件工程的人工智能（AI for SE）

I 引言

软件测试是现代软件质量保证的基石 [1]。在测试的各个阶段（例如集成测试与系统测试）之中，单元测试扮演着尤为关键的角色：它在开发生命周期的早期验证各个软件组件的正确性 [2, 3]。由于修复软件缺陷的成本会随时间显著上升，通过单元测试进行早期检测能够大幅降低维护开销并提高开发效率。因此，随着软件系统持续演化并支撑众多关键行业，单元测试已成为一项标准化、且往往是强制性的实践 [4]。

然而，由开发者手工构造高质量单元测试，从根本上说既困难又耗费人力 [5]。为减轻编写单元测试的人工投入，已有多种技术被提出以自动化测试生成 [6, 7, 8, 9]，包括基于启发式的方法 [7]、基于随机的方法 [6] 以及符号执行 [10, 11, 12]。尽管这些方法颇有前景，它们所生成的测试用例通常在可读性、可维护性与有意义性上受限，从而阻碍其在真实开发中的实际采用。例如，已有工作 [13] 表明，在工业场景中，传统工具（如 EvoSuite [7] 与 Randoop [6]）生成的断言，不如人工编写的断言那样有意义、有帮助。

近来，大语言模型的快速发展标志着软件工程的新里程碑，在多种任务上展现出令人印象深刻的能力，例如代码生成 [14, 15, 16, 17, 18]、摘要 [19, 20] 以及程序修复 [21, 22, 23]。这一进展促使研究者从两个方向探索基于大语言模型的单元测试生成：（1）训练大语言模型，即通过收集高质量测试生成训练数据并选择高效训练策略，对大语言模型进行预训练或微调；（2）提示大语言模型，即通过抽取代码上下文、检索相似的测试生成示例并设计任务指令来构造有效提示。其中，基于提示的技术，尤其是采用“生成—验证”循环的技术，代表当前最优（state-of-the-art, SOTA）：它们先生成初始测试用例，再借助动态反馈加以精炼。尽管颇有前景，这些技术仍受两项主要局限制约。

图 1： 开发者编写单元测试时的常见工作流

❶ 挑战：过程式框架。 现有方法通常遵循预先定义且静态的生成流水线，不会依据实时反馈调整测试生成策略（例如，是精炼已生成的测试用例，还是重新抽取更相关的上下文）。因此，无论中间结果如何，生成过程都保持固定，限制了其探索替代生成路径的能力，也削弱了大语言模型处理复杂或不断演化的测试需求时的有效性。

❷ 挑战：粗粒度上下文抽取。 大多数现有方法使用固定规则检索上下文（例如整个焦点方法或整个焦点类），而没有显式建模语言特有的结构，如面向对象层次、方法分派以及类间依赖。例如，仅抽取焦点方法可能遗漏关键的外部调用信息，而纳入整个类或包又可能引入无关细节，甚至超出大语言模型的输入长度限制。尽管近期的软件工程智能体（例如 RepoGraph [24] 与 AutoCodeRover [25]）已探索仓库级代码表示以支持上下文检索，这些表示是为问题修复等通用软件工程任务设计的：它们既不建模测试特有的实体与关系（例如测试类、测试方法以及测试—焦点链接），也不积累生成过程中产生的测试制品（例如测试报告与失败分析）。因此，它们对推导测试需求以及推理焦点方法预期行为的支持有限。

本文工作。 为应对这些挑战，我们提出 TestAgent，一种用于自动化单元测试生成的、基于大语言模型的新型智能体框架。TestAgent 的动机来自开发者编写单元测试的实践经验，并旨在借助多智能体协作与面向仓库的知识图谱，把这一领域知识与大语言模型的能力结合起来。如图 1 所示，在真实的单元测试生成场景中，开发者通常遵循三步过程：（1）理解程序的预期行为并推导相应的测试需求；（2）编写初始测试用例，并依据执行反馈加以精炼；（3）用充分性指标（例如代码覆盖率）评审测试用例质量，并决定是否将其部署到生产环境。受这一开发者实践启发，我们为 TestAgent 设计三个协作智能体（即需求规划器、测试生成器与测试评审器），各自模拟开发者测试工作流中的一个具体角色。具体而言，需求规划器对目标函数进行语义分析以推断预期行为，并据此生成结构化测试需求，指明函数的哪些方面应当被测试。生成器智能体借助思维链推理生成可执行测试用例，并在沙箱环境中依据执行反馈迭代精炼。它还对失败测试用例进行根因分析，并采用三个不同大语言模型之间基于投票的确认机制，判定某次失败是否暴露了真实缺陷，从而为下一轮测试精炼提供反馈。评审器智能体从多个维度（例如覆盖率、正确性以及与测试需求的一致性）评估所生成测试用例的质量，并给出可执行建议（例如推导新需求以覆盖尚未测试的场景）。

为模拟开发者在整个测试过程中对外部工具的依赖，我们构建一组工具 API（例如上下文检索与测试验证），供智能体自主调用，使其能够按需与外部资源交互，并以自适应方式调整测试策略，从而克服 ❶ 过程式流水线这一挑战。为克服 ❷ 上下文抽取这一挑战，我们通过静态分析构建知识图谱，以建模整个仓库内程序实体（例如函数、类、字段与文件）之间的细粒度依赖。与通用仓库表示不同，我们的知识图谱专用于单元测试：它引入测试特有的节点与关系（例如测试类、测试方法以及测试—焦点链接），并进一步作为动态生成的测试制品（例如函数摘要、测试报告与根因分析）的持久化存储，使智能体能够在整个生成过程中积累并复用测试知识。

我们开展了广泛实验，在三个基准、六项指标、五个基线、三种底层大语言模型以及两种编程语言上评估 TestAgent。结果表明，TestAgent 达到 97.46% 的执行率、92.34% 的行覆盖率、90.24% 的分支覆盖率以及 83.69% 的变异分数；在相同的 GPT-4o 骨干下，它在全部六项指标上持续优于基于大语言模型的基线（即 ChatUniTest 与 HITS）；与基于搜索的 EvoSuite 相比，TestAgent 在正确性上与之相当，同时交付显著更高的变异分数（83.69% 对 43.59%）。消融研究证实了核心组件的影响，例如引入知识图谱使行覆盖率、分支覆盖率与变异分数分别提升 22.31%、24.52% 与 26.83%。使用不同骨干大语言模型的实验表明该框架具有很强的可扩展性，例如即便使用开源的 Qwen3-30B-A3B，TestAgent 仍优于使用 GPT-4o 的 ChatUniTest，凸显其在不依赖专有模型时仍具有很强的适应性。我们进一步把 TestAgent 扩展到 Python 项目，取得 88.85% 的行覆盖率与 78.89% 的分支覆盖率，优于包括 CodaMosa 与 CoverUp 在内的、专门面向 Python 的基于大语言模型的方法。我们还在工业项目上开展实验，以展示 TestAgent 在真实开发环境中的有效性，并通过用户研究展示其实际适用性。最后，我们评估其生成非回归测试用例的能力，发现它以 92.22% 的精确率成功检出 154 个真实缺陷。

贡献。 本文作出如下贡献：

1. 受人类测试启发的多智能体单元测试生成框架。 我们提出 TestAgent，一种由需求规划器、测试生成器与测试评审器组成的新型多智能体框架，共同模拟人类测试工作流。

2. 面向基于智能体的上下文检索的结构化代码表示。 我们构建专用于单元测试的仓库级知识图谱，使智能体能够通过测试特有的节点与关系（例如测试类、测试方法以及测试—焦点链接）与代码库交互，并持久化存储过程中生成的测试制品（例如函数摘要与测试报告），从而在整个测试生成过程中提供细粒度、依赖感知的上下文。

3. 广泛评估。 我们开展包含六个研究问题与两项讨论的大规模实验，展示 TestAgent 的总体有效性、其核心组件的影响，以及它在不同底层大语言模型上的可扩展性。

4. 多语言支持。 我们把 TestAgent 应用于 Python 项目，相对基于大语言模型的语言专用方法取得更优性能，从而展示其跨越语言边界的可推广性。

5. 工业场景中的适用性。 我们通过工业项目评估与用户研究，在实际环境中验证 TestAgent，确认其有效性与可读性。

II 背景与相关工作

II-A 单元测试生成

现有单元测试生成方法可大致分为两类：传统方法与基于大语言模型的方法。

传统方法。 传统方法通常采用软件分析技术来自动化单元测试生成，包括基于启发式的方法 [7]、基于随机的方法 [6] 以及符号执行 [10, 11, 12]。一类突出方法是基于搜索的软件测试（search-based software testing, SBST），它使用启发式进化算法，把测试生成表述为优化问题。尽管传统方法常常能达到较高的代码覆盖率，它们倾向于生成可读性与可用性较差的测试 [26, 13]。

基于大语言模型的方法。 早期基于大语言模型的方法 [26, 27] 通常把该任务视为带监督微调的神经机器翻译问题：以焦点方法为输入，输出为所生成的单元测试代码。例如，Tufano 等人 [26] 提出 AthenaTest，它利用一个基于 BART 的模型，在 Methods2Test 数据集 [28] 上分两阶段训练。近来，ChatGPT 等强大闭源大语言模型的出现，推动了面向测试生成的提示工程方法的更多探索 [29, 30, 31, 32, 33, 34, 35, 36, 37]。例如，Chen 等人 [30] 提出 ChatUniTest，采用“生成—验证—修复”框架迭代精炼所生成的单元测试。Wang 等人 [31] 开发了 HITS，利用大语言模型把焦点方法分解为代码切片，并增量式地生成测试。尽管颇有前景，当前基于大语言模型的方法仍受局限，例如过程式生成流水线以及粗粒度的上下文检索机制。

II-B 基于大语言模型的智能体

大语言模型的快速发展为构建具有广泛适应性的智能体开辟了新的可能。智能体被定义为能够感知环境、作出决策并采取行动的人工实体，被视为通向通用人工智能（Artificial General Intelligence, AGI）的一条有前景的路径 [38]。

基于大语言模型的智能体所展现的出色性能，激发了代码相关领域的大量研究。在代码修复领域，Jimenez 等人 [39] 开发了 SWE-Bench，这是一个评估框架，包含从 GitHub 收集的 2,294 个真实软件工程问题。它此后成为日益增多的基于智能体的方法的基准 [40, 25, 41, 42, 43]。例如，Yang 等人 [41] 提出 SWE-Agent，采用定制的智能体—计算机接口，使智能体能够创建并编辑代码文件、浏览整个仓库并执行测试。在代码生成领域，也已开展大量基于智能体的研究 [44, 45, 46, 47]。

尽管在基于智能体的仓库理解这一高层思想上与既有工作相同，TestAgent 在三个方面不同于先前的软件工程智能体。第一，现有仓库表示（如 RepoGraph [24]）是为通用软件工程任务（例如问题修复）设计的，只捕获静态代码结构；相比之下，我们的知识图谱专用于单元测试，引入测试特有的节点与关系（例如测试类、测试方法以及测试—焦点链接），并进一步作为动态生成的测试制品（例如函数摘要、测试报告与根因分析）的持久化存储。第二，与 AutoCodeRover [25] 通过文件路径和基于规则的匹配来浏览仓库不同，我们的智能体—计算机接口直接在知识图谱上解析代码实体并遍历过程间关系（例如调用图与继承），并支持基于依赖的相似测试检索以便复用测试。第三，据我们所知，TestAgent 是第一项把需求规划、测试生成与测试评审纳入多智能体单元测试流水线、并模拟人类测试工作流的工作。

III 方法

图 2： TestAgent 总览

III-A 概览

图 2 给出 TestAgent 的整体工作流。TestAgent 是一个基于大语言模型智能体的单元测试生成框架。给定被测焦点方法及其项目仓库，TestAgent 由三个主要部分组成：（1）用于仓库级代码理解的知识图谱；（2）编排智能体与项目环境之间通信的一组工具；（3）以交互方式合成、精炼并评审高质量单元测试的多智能体协作框架。

首先，TestAgent 利用静态程序分析抽取程序实体与语义关系，从而构建知识图谱。该结构化图表示类层次、方法调用与变量依赖，构成仓库理解与智能体推理的语义基础。其次，TestAgent 基于知识图谱构建一组智能体—计算机接口，使智能体能够高效查询仓库级上下文信息。这些工具提供对整个项目仓库的动态、细粒度访问，支持在测试需求建模、生成与评估阶段进行精确的上下文获取。第三，TestAgent 设计一个三阶段多智能体框架，每个阶段由一个专门智能体协调。需求规划器对被测方法进行语义分析，并推导相应的测试需求，指明功能的哪些方面应当被测试。测试生成器依据代码上下文与所推导的需求，产出语法正确且可执行的测试用例。它还进行失败根因分析，并采用基于投票的确认机制，以识别该失败是否检出目标函数中的实际缺陷。测试评审器从多个维度评估测试用例，并给出可执行建议，以引导其他智能体的后续行为，从而实现持续迭代。

III-B 知识图谱构建

为支持大语言模型的仓库级推理，我们基于静态代码分析构建实体级知识图谱，以捕获项目内部的语义与关系。该图作为显式、可查询的表示，弥合原始源代码与大语言模型之间的鸿沟。该过程的输入是完整代码仓库，包括其全部文件夹与文件；输出是一张结构化图，其节点对应程序实体（例如包、类、方法、变量），边编码这些实体之间的语义依赖。形式化地，给定由源文件 \(p_i \in \mathcal{P}\) 组成的项目 \(\mathcal{P}\)，构建过程包含三个主要步骤：

① 代码实体抽取。 对每个文件 \(p_i\)，我们使用 SPOON [48] 生成其抽象语法树（AST）。

\[ AST_i = \mathrm{BuildAST}(p_i) \tag{1} \]

然后，我们通过遍历全部 AST，按层次抽取实体集合 \(\mathcal{E}\)。

\[ \mathcal{E} = \bigcup_i \mathrm{ExtractEntities}(AST_i) \tag{2} \]

这些实体被组织为四个主要类别，从粗粒度模块到细粒度元素：包、类、方法与变量。每个类别再依据其编程语义进一步细化。例如，类实体被划分为若干子类型，如普通类、抽象类、接口、枚举、装饰器以及测试类。

② 依赖关系抽取。 在识别实体定义之后，我们通过中间表示（Intermediate Representation, IR）与指针分析，识别项目内的实体间依赖 \(\mathcal{R}\)。

\[ \mathcal{R} = \bigcup_{e \in \mathcal{E}} \mathrm{AnalyzeDependencies}(\mathrm{IR}(e), \mathcal{E}) \tag{3} \]

为捕获这些实体之间的语义关系，我们在 \(\mathcal{R}\) 中定义一组丰富的依赖类型，包括继承、实现、方法调用与引用，以反映真实软件中的核心语义结构。

③ 图组装。 最后，我们把知识图谱 \(\mathcal{KG}\) 构造为 \((h, r, t)\) 三元组的集合，其中 \(h\) 与 \(t\) 为实体，\(r\) 表示它们之间的关系：

\[ \mathcal{KG} = \{(h, r, t) \mid h, t \in \mathcal{E},\ r \in \mathcal{R}\} \tag{4} \]

该图对每个项目构建一次，并在所有焦点方法之间共享；随着测试推进，由图谱操作工具增量维护。

III-C 基于图的工具集构建

表 I： TestAgent 所调用的已实现工具

在作为整个仓库之结构化表示的知识图谱之上，我们设计一组工具，以便利智能体与外部资源之间的高效交互。

该工具集在测试过程中为智能体提供对整个仓库的准确、高效访问。总体而言，它支持三类工具：（1）图谱操作工具。 这些工具使智能体能够依据测试进展更新知识图谱。例如，需求规划智能体可以调用 add_method_summarization，为特定焦点方法插入语义摘要。（2）信息检索工具。 这些工具使智能体能够从知识图谱中抽取细粒度的仓库级上下文。例如，实体查找工具（如 find_method_definition 与 find_variable_definition）支持基于全限定名与函数签名的精确查询，以确保消歧。依赖追踪工具（如 find_method_calls）返回给定函数实体的调用者与被调用者关系。模糊匹配工具（如 fuzzy_search）在精确标识符不可用时支持近似查询，并依据语义相似度返回排名靠前的候选。测试推荐工具（如 search_similar_test_class）识别并按语义相似度排序相似测试用例，以供复用或适配。（3）运行时交互工具。 这些工具使智能体能够通过动态分析验证所生成的测试用例，包括正确性检查（check_syntax 与 compile_test_cases）与充分性检查（例如 calculate_coverage）。

由于篇幅限制，我们省略全部单个工具的详细实现。作为替代，我们详细说明一个代表性工具 search_similar_test_class。它旨在依据定义在知识图谱上的、基于实体依赖的相似度度量来推荐相关测试用例。其直觉是：共享依赖的测试往往共享测试逻辑——针对同一接口的不同实现的测试，尽管表层代码不同，却常常遵循相同的测试逻辑；而词法上相似的测试却可能执行无关行为。因此，我们在测试所依赖的实体上度量相似度，而不是在其表层代码上度量。给定目标测试用例实体 \(tc\) 与知识图谱 \(\mathcal{KG}\)，我们首先抽取所有其他测试用例实体作为候选集：

\[ \mathcal{TC} = \{ e \in \mathcal{E} \mid \mathrm{type}(e) = \mathrm{TestCase},\ e \neq tc \} \]

其中 \(\mathcal{E}\) 表示 \(\mathcal{KG}\) 中的全部实体，\(\mathrm{type}(e)\) 返回实体 \(e\) 的类型。然后，我们依据 \(tc\) 的出边关系计算其依赖集：

\[ D(tc) = \{(r, e') \mid (tc, r, e') \in \mathcal{KG}\} \tag{5} \]

其中 \(r \in \mathcal{R}\) 为关系类型（例如 calls、defines、uses），\(e' \in \mathcal{E}\) 为相关实体。类似地，我们为每个候选测试用例 \(t \in \mathcal{TC}\) 抽取依赖集：\(D(t) = \{(r, e') \mid (t, r, e') \in \mathcal{KG}\}\)。随后计算 \(tc\) 与每个 \(t\) 之间的 Jaccard 相似度：

\[ \mathrm{sim}(tc, t) = \frac{|D(tc) \cap D(t)|}{|D(tc) \cup D(t)|} \]

最后，全部候选测试用例按相似度排序，并选取 \(\mathrm{sim}(tc, t) \geq k\)（\(k\) 为预定义阈值）的那些作为推荐集：

\[ \mathcal{TC}_{\mathrm{related}} = \{ t \mid t \in \mathcal{TC},\ \mathrm{sim}(tc, t) \geq k \} \tag{6} \]

三类工具都向每个智能体开放，智能体依据当前状态自主选择适当的工具。

III-D 多智能体框架

为自主引导大语言模型利用知识图谱与外部工具，并受开发者通常采用的三阶段单元测试生成过程所启发，我们设计三个专门智能体（即需求规划器、测试生成器与评审器）来模拟这一开发实践。每个智能体负责过程中的一个特定阶段，反映人工驱动的测试创建中任务的自然分工。

#### III-D1 需求规划智能体

需求规划智能体负责分析目标函数的语义行为，并规划结构化测试需求，以引导大语言模型探索有意义且多样的测试场景。为自动化这一过程，该智能体在两个内部状态中运作：函数摘要与测试需求。

在函数摘要状态中，TestAgent 设计一个提示模板，对目标函数进行语义分析与抽象。输出是一份结构化函数摘要，捕获函数的目的、输入参数、返回值以及值得注意的行为。摘要生成后，TestAgent 调用知识图谱更新接口，把摘要与对应的函数实体关联起来，确保语义信息在后续阶段易于检索。

在测试需求分析状态中，以函数摘要为输入，TestAgent 沿三个测试维度分析该函数：正常输入、边界情形与异常场景。它考虑语义角色、参数类型、边缘行为与异常处理，以构造一组全面的测试需求点。每个测试需求点指明测试意图、输入类型以及预期输出行为。

#### III-D2 测试生成智能体

测试生成智能体负责产出并迭代精炼满足指定测试需求的高质量单元测试用例。为自动化这一过程，该智能体依据“观察—思考—行动”的认知决策范式，通过一系列自适应状态运作。给定焦点函数及其测试需求，智能体经过如下主要状态：

❶ 上下文检索。 智能体首先利用外部检索工具集，主动从知识图谱中查询与焦点方法相关的上下文信息（例如程序实体与依赖）。随后，智能体评估当前上下文是否足以支持有意义的测试生成。若足够，则转入下一状态；否则，它停留在检索状态以收集更多上下文信息。为约束这一循环，TestAgent 采用弹性控制策略：在 30 轮交互之后显式询问智能体上下文是否充分，并在 40 轮之后强制进入测试生成，该上限位于第 IV-A 节所述的最大递归深度之内。

❷ 测试生成。 在确认上下文充分之后，智能体使用基于思维链的推理提示来合成候选测试用例。该提示引导智能体逐步推理，构造结构合理、语义有意义、并满足给定测试需求的测试用例。

❸ 执行验证。 所生成测试用例的正确性通过一条自动化流水线加以验证：智能体调用外部工具进行语法检查、编译与沙箱执行。通过全部检查的测试用例被直接加入最终套件；失败的测试用例则触发智能体进入根因分析阶段。

❹ 根因分析。 对任何失败的测试用例，智能体进行根因分析以确定底层原因：（1）测试用例问题。 若失败由测试用例中的轻微缺陷引起，例如错误的参数、薄弱的断言或对边缘条件的不当处理，智能体将其视为可恢复。此时，测试用例被精炼，并带着详细的验证反馈重新进入生成—验证循环。（2）焦点方法问题。 若失败很可能由被测函数中的缺陷引起，智能体启动缺陷确认机制。该机制调用三个训练流水线不同的大语言模型，各自独立检查测试用例、错误信息与推理轨迹。若三者一致认为该失败揭示了真实缺陷，则该测试用例被标记为缺陷揭示型，并加入最终测试套件。

❺ 生成终止。 一旦某个测试用例要么成功通过全部验证，要么被确认为暴露了真实缺陷，智能体就生成一份结构化报告，记录测试结果，包括行覆盖率、分支覆盖率与变异分数。这些结果被格式化为 JSON 报告，作为评审器智能体的反馈，或在部署时供开发者检查的文档。若在重试预算耗尽之前，仍未能为某个高度复杂的焦点方法产出可编译测试，智能体把最后一次尝试记录为尽力而为的结果，而不是丢弃该方法。

#### III-D3 测试评审智能体

测试评审智能体负责从多个视角评估所生成测试用例的质量，并提供可执行建议；这些建议被迭代反馈给上述两个智能体，以引导它们在测试用例与测试需求两方面的后续行为。为自动化这一过程，该智能体在两个内部状态中运作：质量评估与建议推导。

在质量评估状态中，智能体接收评估所需的完整上下文，包括函数定义、函数摘要、相关测试需求、所生成的测试用例以及执行报告。随后，它依据多项准则分析每个测试用例，包括语法有效性、编译成功、运行时行为、结构覆盖（例如行覆盖率与分支覆盖率）、与测试需求的一致性，以及缺陷检测能力（例如变异分数），从而生成评估摘要。

在反馈分析状态中，智能体把评估结果转化为针对测试用例与测试需求的可执行决策。对每个测试用例，它指定四种反馈动作之一：（1）接受（Accept）。 测试用例满足预期需求，达到有意义的覆盖，并表现出较强的故障检测能力（例如杀死变异体或揭示缺陷）。因此，它被保留以便部署，不作修改。（2）丢弃（Discard）。 测试用例未能满足预期需求，且含有不可恢复的缺陷。因此，它被从所生成的测试套件中移除，其相关图条目被删除（即调用表 I 中的 delete_test_cases 工具）。（3）更新（Update）。 测试用例部分有价值但不完整，例如存在轻微语法或编译错误、部分覆盖或薄弱断言。因此，它被保留，并附带具体的改进建议。（4）增补（Augment）。 若某个测试用例因测试需求不足而覆盖或故障检测不充分，智能体推断针对未测试场景的新测试需求，例如未覆盖路径、未处理异常或存活的变异体。

III-E 实现

我们把 TestAgent 实现为 VSCode 单元测试生成插件，以支持在真实工作流中的实际采用与开发者交互。开发者可以在编辑器中选择一个焦点方法或整个项目来启动该插件。插件输出：（1）具有高覆盖率与高变异分数的可执行测试用例，适合直接用作回归测试；（2）揭示缺陷的失败测试，用于检查当前项目版本中的潜在缺陷。同时提供一份 JSON 报告，详述每个测试用例、其目标需求、覆盖率与变异表现，以便透明检查与持续集成（CI）接入。全部中间智能体推理步骤显示在交互面板中，开发者可以按需预览、编辑或插入测试用例。

IV 实验与结果

IV-A 实验设置

#### IV-A1 研究问题

我们的评估考察如下研究问题（RQ）。

RQ1：有效性比较。 在包括正确性、覆盖率与变异在内的标准指标上，TestAgent 相对于基线表现如何？

RQ2：消融研究。 各个组件（包括测试检索、测试评审器与知识图谱）对 TestAgent 的总体性能贡献如何？

RQ3：模型适应性。 TestAgent 在不同底层大语言模型上表现如何？

RQ4：工业项目性能。 TestAgent 为真实工业项目生成单元测试的有效性如何？

RQ5：可读性与可用性。 TestAgent 的测试用例是否比基线提供更高的实用性？

RQ6：语言可推广性。 TestAgent 在为 Python 生成测试用例时能否保持其有效性？

表 II： 评估数据集详情

#### IV-A2 数据集

我们使用三个不同的数据集评估 TestAgent，以便从多个视角全面考察其性能。首先，在 RQ1–RQ3 中，与先前研究一致，我们从 GitHub 收集六个 Java 项目，得到包含 1,454 个焦点方法的数据集。其中五个项目来自 Defects4J [49]，这是先前评估中经常使用的、被广泛认可的基准数据集；我们采用先前基于大语言模型的测试生成研究 [27, 30, 31] 所使用的同样五个项目，以确保与基线的比较一致。由于资源限制，我们从 Lang 与 Chart 项目中各自随机选取 200 个方法，这两个项目原本都包含数千个方法。为评估 TestAgent 在复杂方法上的性能，我们还纳入另一个项目 Ruler，HITS 将其识别为特别具有挑战性。其次，在 RQ4 中，我们引入一个名为 UTXXX 的内部数据集，以评估 TestAgent 在此前未见的工业方法上的表现。该数据集来自工业界，包含从四个 Java 项目收集的 658 个焦点方法。最后，在 RQ6 中，为评估 TestAgent 对 Python 程序的适用性，我们遵循 CodaMosa 的做法，从三个 Python 项目中选取九个模块。这些模块构成称为 CM 的 Python 数据集，共包含 141 个焦点方法。由于开源对象主要是库项目，RQ4 中的工业数据集用更能反映工业实践的项目对其加以补充。这些数据集的详情与统计汇总于表 II。

#### IV-A3 基线

为回答 RQ1–RQ5，我们把 TestAgent 与三个当前最优基线进行比较：（1）EvoSuite [7] 把静态分析与遗传算法相结合以最大化覆盖率，在学术与工业评估中都是强基线。（2）ChatUniTest [30] 纳入自适应焦点上下文以提供语义依据，并利用“生成—验证—修复”循环来保证测试的正确性与可执行性。（3）HITS [31] 把每个复杂焦点方法分解为更小的程序切片，并提示大语言模型为每个切片独立生成测试。

为回答 RQ6，我们用 Python 实现 TestAgent，并与两个面向 Python 的、基于大语言模型的基线进行比较：（1）CodaMosa [35] 在覆盖率进入平台期时向大语言模型查询种子测试，从而增强 SBST，把探索导向未覆盖路径。（2）CoverUp [33] 迭代地向大语言模型提供执行反馈与未覆盖代码区域，直至覆盖率收敛。

#### IV-A4 指标

为评估所生成测试的有效性，我们采用六项定量指标：（1）语法正确率（Sy. Rate）：语法正确的生成测试所占比例。（2）编译成功率（Co. Rate）：无错误编译的生成测试所占比例。（3）执行成功率（Exe. Rate）：无运行时错误而成功运行的测试所占比例。（4）行覆盖率（Li Cov.）：被执行的代码行所占比例。（5）分支覆盖率（Br Cov.）：被执行的代码分支所占比例。（6）变异分数（Mut Sc.）：测试检测人工注入故障的有效性。

为考察面向开发者的反馈，遵循 ChatTester，我们在 RQ5 中引入四项可读性与可用性指标：命名直观性（NI）、代码布局（CL）、断言质量（AQ）与采用成本（AE），并加以汇总。为探索检测真实缺陷的能力，我们在讨论部分进行缺陷检测有效性分析。该分析以精确率衡量（\(P = \frac{TP}{TP+FP}\)），已确认的真阳性再沿两条正交轴进一步分类：根因与所观察到的影响，每条轴分为五个子类型（见表 IX）。我们还考虑两项指标：货币成本与时间成本，以评估 TestAgent 的成本效益。

#### IV-A5 配置设置

我们主要以 OpenAI 的 GPT-4o [50]（gpt-4o-2024-05-13）作为基础大语言模型来评估 TestAgent。为公平比较，基于大语言模型的基线（即 ChatUniTest 与 HITS）使用与 TestAgent 相同的 GPT-4o 版本运行，且全部基线采用其原作者推荐的配置。具体而言，EvoSuite 以每个类 300 秒的搜索预算运行。为评估与模型无关的能力，我们使用两种替代大语言模型评估 TestAgent：DeepSeek-V3 [51] 与 Qwen3-30B-A3B [52]。全部模型使用默认参数，不限制输出词元。具体而言，Qwen3-30B-A3B 使用 vLLM 部署在两块 Nvidia A100 GPU 上。实验中，我们采用 Neo4J [53] 进行图管理。为避免过长上下文，我们只选取规划智能体所生成的前 5 条测试需求用于后续处理，并把最大递归深度设为 50。缺陷确认机制采用 o3-mini、DeepSeek-R1 与 Qwen3-235B-A22B 作为三个投票模型。

IV-B RQ1：有效性比较

表 III： TestAgent 所生成测试用例的有效性

括号中的百分比为 TestAgent 相对该基线总计的变化（原文标注）。

设计。 RQ1 旨在考察 TestAgent 所生成测试用例的总体有效性。我们考虑六项指标，并与三个当前最优基线（EvoSuite、ChatUniTest 与 HITS）比较，以全面评估 TestAgent 的性能。

结果与分析。 表 III 给出 TestAgent 与三个基线在六个 Java 项目上的比较结果。总体而言，TestAgent 相对于基线方法表现出更优性能。尽管 EvoSuite 达到完美的编译率（100.00%）与较高的执行率（98.07%），TestAgent 以 99.11% 的编译率与 97.46% 的执行率与之接近，并大幅超过 ChatUniTest（编译 81.29%、执行 66.09%）与 HITS（编译 91.54%、执行 81.71%）。残余的编译失败（0.89%）来自重试预算耗尽的高度复杂焦点方法；对此，TestAgent 把最后一次尝试记录为尽力而为的结果。此外，TestAgent 取得显著更高的行覆盖率（92.34%）、分支覆盖率（90.24%）与变异分数（83.69%），相比 EvoSuite（82.11%、80.81% 与 43.59%）、ChatUniTest（72.40%、71.44% 与 51.79%）以及 HITS（82.39%、81.22% 与 63.14%），凸显其在生成能够有效检测故障的高质量测试用例方面的有效性。

就单个项目而言，我们观察到一些项目（例如 Cli、Csv、Chart 与 Lang）相对直接，而另一些（例如 Gson 与 Ruler）挑战更大。尽管如此，即便在这些更具挑战性的项目上，TestAgent 也持续取得稳健性能，表明其能够适应并有效应对多样的项目复杂度。

对 RQ1 的回答：

TestAgent 在全部六项指标上持续优于基于大语言模型的基线，并且在正确性上与基于搜索的 EvoSuite 相当，同时取得显著更高的覆盖率与变异分数。它在多样项目（包括具有挑战性的场景）上的一致表现，凸显其稳健性与实际适用性。

IV-C RQ2：消融研究

设计。 RQ2 探索 TestAgent 中每个主要组件的单独贡献。我们通过移除（i）相似测试检索、（ii）测试评审器与（iii）知识图谱来开展消融研究。它们对应 TestAgent 的三个架构层次：一个代表性检索工具、一个协作智能体，以及底层的仓库表示，从而得到系统的三个变体。

表 IV： TestAgent 的消融研究

括号中的 ↑ 为完整 TestAgent 相对该变体的提升（原文标注）。

结果与分析。 表 IV 报告完整 TestAgent 及其三个消融变体的结果。在所有配置下，语法正确率均保持 100%，表明生成器始终能够产出语法正确的测试用例。尽管如此，省略特定组件会在不同程度上降低其余指标。第一，移除检索模块只造成适度下降，例如编译成功率下降 0.50%，执行成功率下降 0.64%，行覆盖率与分支覆盖率大约下降 1–2%，变异分数下降 2.87%。第二，去掉评审器造成更大缺口，例如执行成功率下降 2.69%，行覆盖率与分支覆盖率分别下降 4.52% 与 5.25%，变异分数下降 8.09%。这些结果表明，由评审器实现的反馈回路对于过滤无效测试、并把生成导向预期行为是必不可少的。第三，最严重的退化出现在移除知识图谱模块时。执行成功率骤降 12.11%，行覆盖率与分支覆盖率分别降至 75.65% 与 72.62%，变异分数降至 66.12%。这些发现强调了知识图谱在建模程序上下文与依赖方面的核心作用：它显著拓宽覆盖范围，并加强在多模块或依赖丰富的代码库中的故障检测。

对 RQ2 的回答：

全部组件都对 TestAgent 的总体有效性作出正向贡献。值得注意的是，知识图谱带来最大增益，因为其对过程间依赖的结构化视图为大语言模型提供了精确上下文。

IV-D RQ3：TestAgent 的模型适应性

设计。 RQ3 考察 TestAgent 在不同基础大语言模型上的可推广性。我们选取三个有代表性的大语言模型：GPT-4o、DeepSeek-V3 与 Qwen3-30B-A3B。这些模型既包括闭源也包括开源大语言模型，模型规模各异，通过 API 访问或部署在独立硬件上。这一设置展示 TestAgent 与模型无关的特性，以及它对多样部署场景的适应性。

表 V： TestAgent 在不同大语言模型上的性能

结果与分析。 表 V 汇总所选大语言模型之间的性能比较。GPT-4o 持续取得最佳总体性能，其次是 DeepSeek-V3，Qwen3-30B-A3B 表现最低。这一排序与它们相应的部署成本与能力相一致。就测试正确性而言，三个模型的语法正确率均为 100%，表明语言建模能力稳健。就编译与执行成功率而言，GPT-4o 与 DeepSeek-V3 均超过 97%，而 Qwen3-30B-A3B 出现明显的性能下降，编译成功率降至 94.57%，执行成功率进一步降至 85.63%。就测试充分性而言，GPT-4o 大幅领先，达到 92.34% 的行覆盖率、90.24% 的分支覆盖率与 83.69% 的变异分数，反映出在生成高质量测试用例方面的更强能力。DeepSeek-V3 在行覆盖率与分支覆盖率上大约落后 GPT-4o 6%，在变异分数上大约落后 11%。Qwen3-30B-A3B 的充分性最低，行覆盖率为 81.25%，分支覆盖率为 78.21%，变异分数为 60.44%。然而，它仍大幅超过 ChatUniTest（即便后者使用 GPT-4o），凸显 TestAgent 的有效性并不依赖于底层大语言模型。

我们还观察到，使用 Qwen3-30B-A3B 的 TestAgent 在行覆盖率与分支覆盖率上落后于 EvoSuite（分别落后 0.86% 与 2.60%），这主要源于这一较小开源模型在上下文理解与需求分析能力上的局限。尽管如此，它在变异分数上仍明显领先于 EvoSuite（60.44% 对 43.59%），并且由于本地部署，API 成本为零。据此，我们把 TestAgent 与 EvoSuite 视为互补而非严格竞争的方法：EvoSuite 擅长以极低成本最大化结构覆盖率，而 TestAgent 贡献更高的变异分数以及更可读、与需求对齐的测试（见 RQ5）。把二者结合起来，例如用 EvoSuite 生成的测试为 TestAgent 提供种子以填补残余覆盖缺口，是未来工作中有前景的方向。

对 RQ3 的回答：

TestAgent 在多样的大语言模型后端上表现出很强的适应性。虽然性能与模型能力相关，所有被评估的模型都受益于 TestAgent 的框架。这确认了 TestAgent 与模型无关的设计，以及它在多样部署场景中的稳健性。

IV-E RQ4：工业项目性能

设计。 为减轻潜在的数据泄漏风险，RQ4 使用 UTXXX 评估 TestAgent 与基线方法的性能。UTXXX 是一个真实工业数据集，包含来自四个不同项目的 658 个目标方法。由于公司保密政策，我们隐藏内部对象的信息。UTXXX 采用统一的 Maven 架构与 JUnit 4 测试框架。这些项目从未公开发布，从而大幅降低在大语言模型预训练期间被暴露的风险。这一设置与主流开发实践相一致，并为衡量在当代 Java 项目中生成测试用例的能力提供更准确的尺度。具体而言，我们使用托管在本地服务器上的 Qwen3-30B-A3B。然而，由于该模型能力有限，它无法执行代码切片——而这是 HITS 方法所要求的关键步骤。因此，我们把 HITS 排除在本次比较之外。为客观衡量每种测试方法的有效性，我们使用三项被广泛采用的指标：行覆盖率、分支覆盖率与变异分数。

表 VI： 工业项目上的比较结果

结果与分析。 表 VI 给出各方法在 UTXXX 数据集上的性能结果。如表所示，TestAgent 在全部三项指标上持续取得最高性能。具体而言，TestAgent 达到 84.21% 的行覆盖率、82.12% 的分支覆盖率与 55.38% 的变异分数，明显优于其他方法。ChatUniTest 在行覆盖率与分支覆盖率上与 EvoSuite 表现相当，但取得明显更高的变异分数。总体而言，这些结果表明 TestAgent 大幅优于基线方法，凸显其在为工业 Java 项目生成高质量单元测试用例方面的有效性。

对 RQ4 的回答：

TestAgent 在真实工业项目中表现出很强的实际有效性。尽管配备的是较小的大语言模型（Qwen3-30B-A3B），它在覆盖率与变异分数上仍大幅优于既有基线，展示其稳健性与真实世界适用性。

IV-F RQ5：可读性与可用性评估

设计。 RQ5 通过一项用户研究，评估 TestAgent 与基线（即 EvoSuite、ChatUniTest 与 HITS）所生成测试用例的可读性与可用性，遵循 ChatTester [29] 的方法。具体而言，我们随机选取 100 个焦点方法，四种方法都能为其生成可执行测试用例，共计 400 个测试用例。我们邀请十名参与者，每人具有 3–5 年 Java 开发经验，依据四项准则独立评估测试用例，即可读性方面的命名直观性与代码布局，以及可用性方面的断言质量与采用成本。每项准则按 1–3 分评分，分数越高表示质量越好。为保证公正，参与者对每个测试用例的来源不知情。

表 VII： 可读性与可用性表现

结果与分析。 表 VII 给出 TestAgent 与基线的比较结果。总体而言，TestAgent 取得最高的可读性与可用性分数。ChatUniTest 排名第二，主要因其测试用例简洁而获得最高的代码布局分数。相比之下，HITS 得分较低，主要由于不必要的导入语句与不清晰的代码结构。EvoSuite 表现最差，主要由于注释不足、无意义的字符串取值以及测试意图不清晰。

对 RQ5 的回答：

我们的用户研究表明，TestAgent 所生成的测试用例持续取得最高的可读性与可用性分数，表明 TestAgent 产出的测试不仅有效，而且对开发者友好。

IV-G RQ6：语言可推广性

设计。 在本工作中，我们用 Java 实现 TestAgent，因为 Java 是单元测试中被最广泛采用的语言，提供丰富的基准项目生态以及可供比较的强基线。事实上，TestAgent 的核心方法与语言无关，可以以最小的工程代价扩展到其他编程语言。主要适配位于知识图谱构建阶段，此时需要语言专用的 AST 解析器来抽取代码实体与关系。为便于与 CodaMosa、CoverUp 等当前最优的基于 Python 的测试生成方法公平比较，我们实现了 TestAgent 的 Python 版本。考虑到 Python 与 Java 的差异，我们为 Python 重新设计知识图谱，移除与编译相关的组件，并相应适配其他模块，以确保与 Python 兼容。

表 VIII： Python 项目上的比较结果

结果与分析。 我们在来自三个 Python 项目的九个模块上评估全部方法；在这些模块上，CodaMosa 与 CoverUp 的表现均不够理想。结果见表 VIII。TestAgent 在全部九个模块上持续取得最高性能。平均而言，相对于最强基线 CoverUp，它将行覆盖率提高 26.86%，将分支覆盖率提高 50.81%。尽管我们的主要实验聚焦于 Java 项目，这一补充研究表明 TestAgent 在 Python 环境中同样保持有效。这些发现提示，TestAgent 所依据的核心原则能够很好地跨编程语言推广，表明其有潜力成为一种与语言无关的测试生成框架。

对 RQ6 的回答：

TestAgent 表现出很强的跨语言适应性。当为 Python 重新实现时，它在行覆盖率与分支覆盖率上均大幅优于 CodaMosa 与 CoverUp 等当前最优的 Python 基线。这确认了它作为通用、与语言无关的测试生成框架的潜力。

V 讨论

V-A 成本效益分析

图 3： TestAgent 各变体的成本效益

设计。 在 RQ2 与 RQ3 的发现之上，我们进一步分析 TestAgent 各种配置的成本效益。具体而言，我们分析不同变体的货币成本与时间成本，并把其性能（效用）量化为行覆盖率、分支覆盖率与变异分数的平均值。

结果与分析。 图 3 展示不同测试生成方法的成本效益格局；散点越大，表示时间成本越长。结果表明，使用 GPT-4o 的 TestAgent 取得最高效用，但每个方法的成本也最高。减少组件的变体，例如省略相似测试检索或评估阶段，会大幅降低成本，但牺牲部分性能。在这些简化变体中，去掉测试评审器的 TestAgent 在成本降低与性能保持之间取得更好的平衡。值得注意的是，使用 DeepSeek-V3 的 TestAgent 表现出卓越的成本效益：它保持 GPT-4o 性能的 91.44%，同时把货币成本降至仅 5.35%。此外，使用 Qwen3 的 TestAgent 因本地部署而 API 货币成本为零，仍然大幅优于 EvoSuite，尽管它需要更多计算时间（大约每个方法 300 秒，而 EvoSuite 为每个方法 19 秒）。去掉知识图谱的变体以及 ChatUniTest，在所评估配置中效用最差。

V-B 通过非回归测试进行缺陷检测

设计。 如第 IV 节所讨论，我们已经表明 TestAgent 取得较高的变异分数，表明它在生成回归测试方面具有很强潜力：这类测试通过比较跨版本的行为来暴露缺陷。在本节中，我们评估 TestAgent 生成非回归测试的能力，即直接在代码当前版本中检测故障的测试。与把所有失败都视为测试代码问题并反复修复的现有方法不同，TestAgent 识别并保留有效的、会诱发失败的测试，从而能够生成可以揭示真实缺陷的非回归测试。为此，我们对 TestAgent 在 RQ1 的六个项目上识别出的 167 个疑似故障揭示测试用例进行人工评估。

结果与分析。 通过由两位作者进行的三轮评审过程，我们发现 167 个测试用例中有 154 个被确认为实际缺陷，精确率为 92.22%。这一结果凸显了 TestAgent 在生成能够检测真实软件缺陷的非回归测试用例方面的潜力。我们进一步分析这些已确认缺陷的根因与影响，以理解 TestAgent 的实用价值。我们还考察三个投票模型在进入投票的失败用例上的独立性：它们的成对一致性仅为尚可到中等（Cohen’s \(\kappa\) 介于 0.39 与 0.55 之间），并且它们把一次失败标为真实缺陷的个体倾向差异相当大（21.26%、45.89% 与 23.97%），表明三个模型并非以系统性地完全相同的方式失败。

表 IX： 根因与缺陷影响的分类

表 IX 给出所检出缺陷的分类与分布。就根因而言，最常见的问题是输入验证不足（58.44%），通常涉及缺失的边界检查、类型约束或对方法参数的逻辑验证。其次常见的原因是未处理的边界条件与状态不一致，分别占 20.13% 与 14.29%。它们反映了在处理特殊输入值以及内部状态管理不当方面的常见疏忽。就缺陷影响而言，健壮性缺陷占主导（70.13%），表明大多数失败源于对非法输入或异常情形的不当处理，影响系统稳定性与容错能力。功能缺陷占 18.83%，表明一些缺陷直接阻碍功能按预期运作。其余问题，如稳定性（5.19%）、性能（1.30%）与可用性（4.55%）缺陷，较为少见，但在某些条件下仍可能降低用户体验或效率。

V-C 效度威胁

数据泄漏。 由于大语言模型在大量公开数据上预训练，我们的基准可能与其训练语料重叠。为减轻这一风险，我们在包含未见方法的私有工业数据集（UTXXX）上评估 TestAgent。在公开数据集与内部数据集上的一致表现提示，改进来自我们的先进框架，而不是记忆。

多语言支持。 我们的方法主要以 Java 评估，这引发了对其适用于其他语言的担忧。为应对这一点，我们用 Python 重新实现工作流，并针对两种当前最优的、面向 Python 的测试生成方法（CodaMosa 与 CoverUp）进行比较评估。一致的行覆盖率与分支覆盖率结果表明，TestAgent 能够有效地跨编程语言推广。

大语言模型选择。 我们的主要评估使用 GPT-4o，这可能引入模型特有的偏置并限制可推广性。为应对这一点，我们在相同条件下用替代大语言模型（即 DeepSeek-V3 与 Qwen3-30B）开展平行实验。结果表明，在黑盒模型与开源模型上相对性能趋势一致，说明 TestAgent 能够很好地推广到单一大语言模型之外。

大语言模型的非确定性。 由于可观的货币与时间成本，我们的结果来自每种方法的单次运行，而大语言模型固有的随机性可能给单项指标引入方差。在六个项目、三种大语言模型、两种语言以及一个工业数据集上的一致趋势减轻了这一威胁。

VI 结论

本文提出 TestAgent，一种用于基于大语言模型的单元测试生成的新型多智能体框架。它以三个协作智能体模拟人类测试实践：需求规划器、测试生成器与评审智能体。我们进一步为这些智能体配备外部工具 API 与仓库级知识图谱，使智能体能够以细粒度、自适应的方式与代码库交互。在 Java 与 Python 项目上的广泛实验表明，TestAgent 在多个维度上优于当前最优的基于大语言模型的方法，并且变异分数显著高于基于搜索的工具。此外，TestAgent 在不同大语言模型骨干上表现出很强的可扩展性，并在工业场景中具有实际适用性。

署名与许可

本文译文由 智测团队 翻译。原文 Multi-Agent LLM Collaboration for Unit Test Generation via Human-Testing-Inspired Workflows（arXiv:2607.09101）以 CC BY 4.0 许可发布。原作者：Quanjun Zhang、Ye Shang、Siqi Gu、Jianyi Zhou、Chunrong Fang、Zhenyu Chen、Liang Xiao。

CC BY 4.0：https://creativecommons.org/licenses/by/4.0/