上下文至关重要：提升基于大语言模型的单元测试生成的实用可靠性（经验论文）（上篇）

上下文至关重要：提升基于大语言模型的单元测试生成的实用可靠性（经验论文）（中文全译·上篇）

本文超长，分上下两篇。下篇：https://openqa.cn/articles/context-matters-unit-tests-zh-part2

翻译说明：本文是 arXiv 论文 Context Matters: Improving the Practical Reliability of LLM-Based Unit Test Generation（arXiv:2607.19682）的中文全译，由智测团队翻译。原作者：Junjie Chen、Ziqi Wang、Lin Yang、Chen Yang、Xiao Chu、Jianyi Zhou、Guangtai Liang、Qianxiang Wang、Dong Wang。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2607.19682v1 [cs.SE] 2026 年 7 月 22 日

英文标题：Context Matters: Improving the Practical Reliability of LLM-Based Unit Test Generation (Experience Paper)

CCS：软件及其工程—软件测试与调试；计算方法论—自然语言生成；软件及其工程—软件维护工具

作者与单位

• Junjie Chen，天津大学，天津，中国；邮箱：junjiechen@tju.edu.cn
• Ziqi Wang，天津大学，天津，中国；邮箱：wangziqi123@tju.edu.cn
• Lin Yang，天津大学，天津，中国；邮箱：linyang@tju.edu.cn
• Chen Yang，天津大学，天津，中国；邮箱：yangchenyc@tju.edu.cn
• Xiao Chu，华为云，北京，中国；邮箱：chuxiao1@huawei.com
• Jianyi Zhou，华为云，北京，中国；邮箱：zhoujianyi2@huawei.com
• Guangtai Liang，华为云，北京，中国；邮箱：liangguangtai@huawei.com
• Qianxiang Wang，华为云，北京，中国；邮箱：wangqianxiang@huawei.com
• Dong Wang（通讯作者），天津大学，天津，中国；邮箱：dong_w@tju.edu.cn

2026

关键词：单元测试生成、大语言模型、代码上下文

摘要

自动化单元测试生成近来受益于大语言模型（LLM）的进展，但我们的工业部署表明，有前景的研究结果与实际可用性之间仍存在持续差距。在具有复杂框架与跨文件依赖的真实项目中，LLM 生成的测试经常无法编译、需要高成本的人工修复，或只能带来不稳定的覆盖率提升。本文报告我们设计、部署并评估 CATGen 的经验。CATGen 是一种面向基于 LLM 的单元测试生成的上下文感知工作流，其设计来自反复出现的工业失败与后续改进。我们发现，编译稳健性并不取决于让 LLM 去推断不完整的项目上下文，而关键在于：把项目级依赖显式化、稳定测试类脚手架，以及用轻量静态分析取代迭代式的基于 LLM 的修复。这些由经验驱动的认识塑造了 CATGen 的多阶段设计，它把结构化上下文检索、确定性测试骨架构造，以及基于程序分析的后处理结合起来。我们在来自专有工业项目的真实复杂被测方法上评估 CATGen，并额外在 Defects4J 基准上评估其可泛化性。在两种设定下，相对现有基于 LLM 的方法，CATGen 都显著提高了编译成功率与结构覆盖率，同时显著降低了生成时间与 token 消耗。我们的结果表明，实践中可靠的基于 LLM 的单元测试生成，较少取决于单纯的提示工程，而更多取决于植根于真实开发约束的系统性工程支撑。

1. 引言

单元测试是软件质量保障的基石，通过验证每个程序单元的功能来尽早发现缺陷（Zhu et al., 1997；Runeson, 2006；Almasi et al., 2017；Yang et al., 2025c）。手工为被测方法（focal method，即待测方法）编写高质量单元测试可能枯燥且耗时（Kumar and Mishra, 2016）。为减少这一工作量，过去数十年已发展出众多自动化测试生成方法。传统方法往往依赖基于随机的策略（Pacheco et al., 2007）、约束驱动技术（Csallner et al., 2008；Xiao et al., 2013）以及基于搜索的方法（Harman and McMinn, 2009；Fraser and Arcuri, 2011；Blasi et al., 2022）。基于深度学习的方法也已出现（Mastropaolo et al., 2021；Dinella et al., 2022；Nie et al., 2023），它们把单元测试生成表述为神经机器翻译问题。尽管各有所长，这些方法在充分理解代码意图、并生成语法正确且有效的测试方面仍有局限。

近来，基于大语言模型（LLM）的技术显著流行，并在自动化测试生成中展现出潜力。已提出若干基于 LLM 的方法，包括 ChatTester（Yuan et al., 2024）、ChatUniTest（Chen et al., 2024）、HITS（Wang et al., 2024b）、TELPA（Yang et al., 2024a）和 RATester（Yin et al., 2025）。这些工具从经验上表明，相对传统方法，LLM 具备生成高覆盖率测试的较强能力。例如，ChatTester 包含初始测试生成器与迭代测试精炼器，在其数据集上把语句覆盖率从 EvoSuite 的 68.0% 提高到 82.3%。HITS 专门把复杂被测方法分解为切片再交给 LLM，证明其在生成高覆盖率单元测试上的优势。

然而，既有实证研究与我们的工业经验都表明，编译失败仍是基于 LLM 的测试生成走向实际采用的主要障碍。大规模评估（Yang et al., 2024b）显示，无论采用何种提示策略，LLM 生成的单元测试中都有相当一部分无法编译（Wang et al., 2024b；Schäfer et al., 2023）。在实践中，这类失败严重限制了生成测试的 usefulness：开发者必须先诊断并修复编译错误，覆盖率或缺陷检测方面的收益才可能实现。通过与一家大型全球工业伙伴合作，并在真实项目上部署现有基于 LLM 的测试生成（详见第 4 节），我们系统分析了反复出现的失败案例。调查表明，项目级上下文不足且利用不当是首要的底层挑战，它表现为若干反复出现的形式：

• （I）工业项目环境中的上下文失配。 真实软件项目涉及复杂的项目级依赖，包括测试框架、mock 库以及跨文件交互，现有方法往往难以充分捕捉。结果是，LLM 不得不在上下文不足的情况下推断这些依赖，经常导致错误的 import、无法解析的符号，或不兼容的框架用法。在我们的部署中，这些失配经常使测试在第一次编译时就失败，而与测试逻辑质量无关。

• （II）测试脚手架的脆弱性。 构造正确的测试类骨架——包括 import、注解、类声明、mock 定义与初始化逻辑——需要严格遵守框架特定约定，并依赖精确的上下文信息（Yang et al., 2024b）。然而现有方法通常要求 LLM 从零生成骨架；即便测试逻辑看似合理，骨架上的细微偏差（例如缺少生命周期钩子，或 mock 注解不匹配）也常常使整个测试类失效。

• （III）生成后修复成本不断上升。 为弥补缺失的上下文，现有方法往往依赖迭代式的基于 LLM 的精炼或生成后修复（Pan et al., 2025；Alshahwan et al., 2024；Liu et al., 2025；Ni et al., 2024）。在我们的工业部署中，这些策略经常带来可观的时间与 token 开销，而对编译稳健性的改善有限。

在发布周期紧张的大规模工业场景中，这些局限会被放大：手工修正编译错误代价高昂，并削弱自动化测试生成所承诺的生产力收益。在此类场景中，有效利用项目级上下文对于规模化的实际采用至关重要。

受这些观察推动，本文报告我们设计并应用一种上下文感知的、基于 LLM 的单元测试生成工作流的经验，我们称之为 CATGen。我们的目标是，从工业使用中反复出现的失败模式中提炼一组由实践驱动的设计原则，以推进基于 LLM 的单元测试生成的实用可靠性与适用性。核心洞见是：当 LLM 得到显式、结构化上下文的系统性支撑，而不是被要求隐式推断上下文时，编译稳健性会提高。具体而言，CATGen 由三条源于经验、围绕通过确定性程序分析来获取与利用上下文的原则所指导：

（I）CATGen 并不把不完整或缺失的项目级依赖留给 LLM 推断，而是从项目结构与构建配置中显式检索上下文信息，从而准确捕捉框架用法与外部依赖。

（II）CATGen 并不强迫 LLM 从零生成脆弱的测试脚手架代码，而是使用上下文感知模板与系统性 mock 策略构造有效的测试类骨架，使 LLM 只专注于生成测试逻辑。

（III）为避免高成本的迭代精炼，CATGen 应用来自开发者反馈的、基于轻量程序分析的后处理规则，以确定性方式修复常见编译错误并增强测试充分性。

为展示所提方法的实用价值与可泛化性，我们在工业环境与开源环境中评估 CATGen。在工业设定中，我们基于全球工业伙伴的八个专有项目构建基准，覆盖高级 Java 特性、常见设计模式以及框架密集系统等多样的真实场景。我们与伙伴工程师共同遴选了 183 个被测方法，按维护风险（演化中的逻辑）与回归风险（易失败的交互）联合排定优先级；这两个概念在实践中有重叠，但并非同一集合。这些方法反映出可观的工业复杂度：57.38% 涉及复杂依赖，平均每个方法与 3.05 个外部文件交互。所有方法都来自正在积极维护的生产代码，代表真实测试需求，而不是人为构造的困难用例。此外，由于代码库为专有，该基准避免了开源数据集中常见的 LLM 数据泄漏顾虑。我们把 CATGen 与六种有代表性或先进的基线比较，其中包括一种基于搜索的技术与五种基于 LLM 的方法，指标为编译成功率、行覆盖率、分支覆盖率与通过率。结果表明，CATGen 持续取得显著更高的编译成功率，提升幅度为 24.72%–38.05%；覆盖率也显著提高，行覆盖率增益为 17.27%–22.17%，分支覆盖率增益为 15.31%–18.24%；同时时间与 token 消耗下降，时间减少 51.27%–69.00%，token 用量减少 66.83%–83.86%。在开源设定中，我们在 Defects4J 上实验，以考察同样的设计原则能否泛化到专有项目之外。CATGen 呈现一致的性能趋势：相对现有基于 LLM 的方法，编译成功率提高 10.42%–14.33%，行覆盖率提高 6.11%–8.39%，分支覆盖率提高 3.27%–10.56%。综合来看，这些发现说明，由实践驱动的系统设计选择可以显著增强基于 LLM 的单元测试生成在工业场景中的实用性，同时也展现出在开源生态中被采用的较强潜力。

贡献。 本经验论文做出如下贡献：

❶ 我们基于真实经验，识别出限制工业部署中自动化单元测试生成的关键瓶颈。为应对这些瓶颈，我们与伙伴共同整理了一个植根于工业的基准，并设计了 CATGen——一种把 LLM 生成与确定性程序分析相结合的上下文感知工作流。

❷ 我们在工业与开源两种设定下开展广泛评估，相对先进的基于 LLM 的方法考察 CATGen 的有效性与效率。结果表明，CATGen 在全部评估指标上持续优于基线。

❸ 我们认识到，实用的基于 LLM 的测试生成较少取决于单纯的提示工程，而更多取决于系统性工程支撑：（i）显式检索项目级上下文，而不是依赖模型推断依赖关系；（ii）构造稳定的测试类骨架，而不是从零生成脆弱的初始化代码；（iii）应用确定性的、由分析驱动的后处理，以避免高成本的迭代式 LLM 修复循环。

2. 相关工作

自动化单元测试生成是自动创建测试用例以验证代码功能的过程（Yang et al., 2024b）。通常，它包括分析源代码以识别被测方法，然后生成输入与期望输出以验证其行为。过去十年中，已提出众多自动化单元测试生成方法，以减少开发者所需的手工工作。传统技术包括基于随机的策略、基于搜索的方法以及模型检验。例如，EvoSuite（Fraser and Arcuri, 2011）是最具影响力的测试生成技术之一，它采用进化算法生成初始测试用例，再通过变异与选择策略迭代精炼。

为应对传统方法在可读性与可维护性上的挑战，基于深度学习（DL）的测试生成技术把测试生成表述为神经机器翻译问题（Wang et al., 2024a；Wang et al., 2025）。例如，Watson et al.（2020）提出 ATLAS，利用神经机器翻译为测试方法自动生成有意义的断言语句。类似地，Tufano et al.（2020）提出 ATHENATEST，一种基于 BART Transformer 的方法，通过学习真实被测方法与开发者编写的测试用例来生成单元测试。尽管基于 DL 的技术显示出前景，其有效性受限于对较小的、通用预训练模型的依赖，并且在复杂项目设定中往往难以保证语法正确性与可执行性。

在大规模语料上训练的 LLM 已在生成单元测试方面展现出令人印象深刻的能力。若干基于 ChatGPT 的技术被开发出来，以利用其强大的语言理解与代码生成能力来生成有效的单元测试。例如，Yuan et al.（2024）提出 ChatTester，通过与 ChatGPT 的交互式对话迭代生成单元测试。El Haji et al.（2024）研究了 GitHub Copilot 在开发者工作流中为 Python 生成测试的情况，Lemieux et al.（2023）把基于搜索的测试与预训练 LLM 结合，以摆脱覆盖率平台期。Wang et al.（2024b）通过把被测方法分解为切片、并让 LLM 逐切片生成测试用例，提出了 HITS。TELPA（Yang et al., 2024a）、RATester（Yin et al., 2025）与 WiseUT（Yang et al., 2026）进一步纳入跨文件上下文，旨在提高对复杂行为的覆盖率。在以覆盖率为导向的生成之外，RTED（Yang et al., 2025a）通过反思式测试生成与类型约束改进类型错误检测，SEGA（Yang and Chen, 2026）通过从需求文档中抽取业务语义来针对业务逻辑缺陷，CLAST（Yang et al., 2025b）增强所生成测试的语义清晰度。另一方面，Yang et al.（2024b）开展了首个大规模研究，考察多个开源 LLM，突出了提示设计与模型选择的影响。

尽管有这些进展，基于 LLM 的方法在实际设定中仍面临重大挑战。尤其是，许多方法报告了覆盖率或测试质量的改进，但往往难以生成在真实项目中能够可靠编译并执行的测试。与基准数据集（例如 Defects4J）相比，工业项目涉及更复杂的依赖、框架约束与跨文件交互，这经常导致编译失败与不稳定的测试行为，限制了实际可用性，因为开发者必须在测试能够执行之前手工修复错误。

在学术基准之外，近期的工业部署包括 Meta 的 TestGen-LLM（Alshahwan et al., 2024）、Google 的 BRT-Agent（Cheng et al., 2025）以及 Mozilla 的 BLAST（Kitsios et al., 2025）。这些工作强调把 LLM 集成进大规模开发者工作流，并报告以生产力为导向的结果。它们很少把「为什么生成的测试在框架密集的代码库中无法编译」的系统性分析放在前景位置。我们的经验论文通过研究专有部署中反复出现的编译失败，并在 CATGen 中以结构化上下文检索、确定性脚手架以及面向可执行性与覆盖率的分析驱动修复来编码缓解措施，从而对它们形成补充。

3. 面向基于 LLM 的单元测试生成的实践驱动工作流

图 1. 所提出的 CATGen 概览

图 1 描绘了我们在生产仓库上试点之后收敛得到的工作流：我们迭代地把编译失败与运行时失败追溯到缺失的上下文或脚手架。一旦在显式阶段下反复出现的失败类别趋于稳定，我们便冻结了这一布局。在部署中，限制因素很少是「在某一个方法上获得更多覆盖率」，而是生成能够在框架、依赖与跨文件交互之下编译并执行的测试——在没有显式项目上下文的设定中，生成经常失败。我们把生成组织为四个阶段。给定一个被测方法，CATGen：（1）检索项目级上下文，包括构建配置与相关代码元素，从而使框架、import 与跨文件调用不被留给模型推断（第 3.1 节）；（2）构造适配项目测试/mock 设置的测试类骨架，避免从零生成脆弱脚手架（第 3.2 节）；（3）通过以骨架为条件的补全来生成测试方法，固定骨架锚定模型输出并减少结构漂移（第 3.3 节）；（4）应用基于程序分析的后处理，确定性修复常见编译问题并提高稳健性，而不依赖高成本的迭代式 LLM 精炼（第 3.4 节）。

3.1. 上下文信息检索

在早期试验中，我们观察到：仅把被测方法提示给 LLM，对真实项目往往不够。生成的测试经常忽略框架特定约定（例如注解与 import），使用不兼容的 mock API，或以不匹配的签名调用外部方法。这些问题通常表现为编译失败，并使下游修复代价高昂。因此我们收敛到一个轻量检索步骤，把项目级依赖与跨文件行为显式化，而不是留给模型推断。具体而言，CATGen 收集五类互补的上下文：

• 内部类上下文。 被测类的结构与语义元素，包括 import、构造函数、字段与公有方法。这有助于模型构造有效实例、管理对象状态，并触发预期的逻辑路径。

• 被测方法上下文。 被测方法的细节，包括其参数/返回类型与实现。这有助于减少类型不匹配与语义上无效的调用，从而降低编译错误与常见运行时问题的可能性。

• 外部方法调用信息。 对于被测方法所调用的方法，CATGen 抽取其签名、类型、返回值与方法体。这为一致的打桩（stubbing）以及对可达路径的推理提供行为与类型约束。

• 测试框架。 项目的测试框架决定正确的注解与断言约定。CATGen 解析构建配置文件（例如 pom.xml），以检测诸如 JUnit 5 之类的框架关键词。

• Mock 框架。 mock 库（例如 Mockito）对依赖隔离以及避免混用错误至关重要，先前研究也表明了这一点（Spadini et al., 2017；Zhu et al., 2025）。与测试框架类似，CATGen 通过解析构建配置文件来推断 mock 框架。

为落实这五类上下文，CATGen 首先扫描项目构建描述文件中声明的测试与 mock 构件，再使用与 PSI 兼容的结构把被测文件解析为抽象语法树（AST），从而使签名、字段与类内成员忠实于工作区视图。对于被测方法的出站调用，CATGen 遍历调用表达式，在符号解析成功处解析目标；它记录可见性与修饰符，因为它们约束某个依赖日后必须被 mock、被注入，还是经由反射来行使。无法解析的符号或仅属于库的符号被保守保留，以便骨架中的 import 与 mock 挂钩仍与编译器必须看到的内容对齐。综合来看，检索到的上下文为骨架构造与后处理提供依据；抽取使用轻量静态分析。

3.2. 上下文感知的测试类骨架构造

图 2. CATGen 生成的示例被测方法及其对应测试类骨架。（a）被测方法；（b）测试类骨架。

在工业项目中，我们发现测试类骨架往往是可用性的决定性因素，因为它为所有测试方法建立执行环境。即便是细微遗漏，例如缺少 import、框架注解不正确或不完整的初始化，也可能使整个测试类失效，无论生成的断言本身是否合理。在早期尝试中，当要求 LLM 从零生成骨架时，它们经常幻觉出框架特定模式或依赖配置。基于这些观察，我们把骨架视为构造任务而非自由形式的生成问题，并改用检索到的项目上下文来确定性地构建它。

CATGen 通过框架到模板的映射构造可靠骨架。每个模板编码框架所要求的注解、生命周期方法与配置模式，这些内容整理自官方文档，从而使骨架始终符合框架约定。如图 2(a) 所示，我们以工业基准中的被测方法 RestTemplateService.postForEntry(String, String, String) 作为贯穿示例。该方法与外部依赖交互并包含错误处理逻辑，因而代表脚手架错误常见的情形。图 2(b) 展示 CATGen 构造的对应骨架，它由三部分组成：

测试类配置。 骨架模板抽象出框架级结构模式（import、生命周期钩子与 mock API），并按检测到的技术栈实例化。该配置建立测试类的结构与注解基础，并确保与所选测试框架和 mock 框架兼容。CATGen 通过在被测类名后追加 “Test” 得到测试类名，并按框架约定设置可见性（例如在 JUnit 5 下为 public），以支持测试发现。然后它根据检测到的依赖添加类级注解：对基于 Mockito 的测试，@ExtendWith(MockitoExtension.class) 启用 @Mock 与 @InjectMocks；对基于 PowerMock 的测试，当需要静态 mock 时，把待声明的类加入 @PrepareForTest。在字段级，Mockito 模板为依赖引入 @Mock，并用 @InjectMocks 把它们装配进被测对象。最后加入生命周期钩子（例如 @BeforeEach、@AfterEach），以标准化搭建/拆卸，保证隔离与可重复。我们在复现包中提供详细构造规则。图 2(b) 中的绿色区域展示了所得配置。

测试上下文初始化。 除配置之外，骨架必须正确初始化被测对象及其依赖，生成的测试方法才能可靠执行。CATGen 通过把被测类成员变量映射到测试类字段，并确保构造函数被适当调用或配置，来构造测试上下文。在该示例中（图 2(b) 蓝色区域），使用 JUnit 5 与 Mockito 时，CATGen 将被测类实例声明为带 @InjectMocks 注解的字段（第 13–14 行），并为依赖引入带 @Mock 注解的字段（第 11 行）。一个 @BeforeEach 方法（第 16–19 行）初始化 mock，并通过反射设置不可 mock 或依赖配置的字段。同时生成一个 @AfterEach 方法（第 21 行），以保持骨架完整并便于清理。

导入语句。 脚手架 import 由三个来源确定性地组装：（i）由检测到的测试/mock 技术栈所隐含的框架 import；（ii）所选框架的标准断言与工具 import；（iii）经由静态分析与类路径信息、从被测方法与被测类类型解析得到的依赖 import，而不是由 LLM 推断（图 2(b)，黄色）。当解析存在歧义时，我们保守地优先选择项目本地且与框架一致的符号；仅在 LLM 补全的方法体中出现的类型，其 import 在第 3.4 节中补充或校正。

3.3. 以骨架为条件的补全以生成测试

常见的基于 LLM 的测试生成工作流遵循对话式范式：用户提供自然语言查询，模型输出候选测试（Wang et al., 2024b；Yuan et al., 2024；Chen et al., 2024）。这种方式直截了当，但我们的经验表明，这种交互模式在实践中很脆弱。在一项试点研究中，我们观察到：即便提供了预先构造的测试骨架，LLM（包括 GPT-4 等先进模型）也常常偏离给定结构，产生不完整或无效的测试用例。这种漂移经常表现为缺少必需的样板代码、不一致地重新定义类级元素，或返回难以编译与集成的局部片段。为缓解这些问题，我们把测试生成重新表述为以骨架为条件的补全任务，而不是从零生成整个测试类。具体而言，我们把输入分解为两个互补部分：

上下文提示。 提示为生成测试方法提供结构化指导。它包含类级信息（类名、构造函数、成员字段）以支持实例化与状态管理，随后是被测方法实现及相关方法，以支持行为推理。它还指明检测到的测试框架与 mock 框架，并指示对静态与非静态依赖进行一致处理。最后，提示要求模型在编写测试之前先分析被测方法的分支结构，以鼓励系统探索控制流并提高分支覆盖率。

预填充内容。 我们用第 3.2 节构造的测试类骨架预填充响应。然后要求模型在这一固定脚手架下补全其余部分：编写测试方法、配置 mock 行为并插入断言，同时保持骨架结构。根据我们的经验，以这种方式锚定生成可以减少语法错误与结构漂移，并提高输出可直接编译的可能性。完整提示见我们的复现包。

图 3. CATGen 生成的测试类

3.4. 基于程序分析的后处理

LLM 生成的测试在变得可用之前往往需要后处理，一种常见策略是用编译器反馈迭代地重新提示模型（Chen et al., 2024）。在早期部署中，我们采用了同样的反馈驱动修复循环，并运行多轮 LLM 修复来改正编译错误。然而，这种方法在实践中被证明脆弱且成本不稳定：当幻觉持续存在，或项目级依赖只被部分捕捉时，相似错误会在各轮迭代中反复出现，而随着循环继续，token 用量与延迟迅速上升。为使修复可预测且成本稳定，CATGen 改为采用植根于程序分析与所检索项目上下文的确定性轻量后处理。该过程包含两个阶段：

静态编译错误修复。 我们观察到，在 LLM 补全的测试方法体中，编译失败有三类主导情形：（I）未解析的依赖，包括缺失的 import、不正确的包限定名，或有歧义的简单名；（II）对未定义类型、方法或变量的引用；（III）不正确的初始化或框架用法（例如 Mockito 设置或构造函数误用）。CATGen 在第 3.1 节的项目上下文以及来自 AST 检查的、编译器可见事实之上实现一条轻量修复流水线，从而使修复依据与骨架构造相同的依赖与签名信息，而不是额外的 LLM 轮次。

遵循对工业开发者修复工作流的经验观察以及先前工作的洞见（Yuan et al., 2024），我们实现一套有针对性的策略：

（1）包声明补全，使测试类的包与被测方法的源码位置对齐；

（2）导入语句补充，对照被测编译单元、同一模块中的邻近文件，以及上下文检索得到的类路径切片，解析简单名与静态成员，并在解析唯一时插入或调整 import 声明；

（3）类注解校正，修正 JUnit 与 Mockito 的注解配置；

（4）无效引用消解，移除或改写无法绑定到静态分析可见符号的引用；

（5）私有成员访问适配，当必须行使私有成员时引入基于反射的访问；

（6）方法签名对齐，使方法名以及参数或返回类型与其实际签名一致；

（7）异常规约增强，在编译或一致的异常处理所要求之处添加显式异常声明或断言；

（8）兜底断言机制，引入默认断言，使测试方法保留最低限度的行为检查。

全部八项策略共享同一主干：每条规则由编译器诊断以及对第 3.1 节项目上下文的轻量 AST 检查驱动，按固定优先级顺序触发，并且从不重新调用 LLM，从而使重复运行确定且成本有界。在此主干之上，三类失败被分派到互补规则。对于（I），import 补充把第 3.2 节的脚手架 import 扩展到仅在 LLM 补全方法体中出现的类型；当绑定有歧义时，它保守地优先选择项目本地、与框架一致的符号，否则把该情形交给无效引用消解，而不是编造包名。在此基础上，类别（II）由同一无效引用消解与方法签名对齐共同解决，二者一起对照从被测类及其依赖恢复的签名，调和未绑定调用以及不匹配的名称或参数/返回类型。最后，类别（III）由类注解校正、私有成员访问适配、异常规约增强以及兜底断言机制来处理，它们修复 JUnit/Mockito 脚手架、私有访问模式以及 throws/断言结构，使合并后的类能够编译并表现出最低限度的一致行为。总体而言，这一阶段被有意限制为恢复可编译性与结构一致性；更广泛的测试充分性在后文通过覆盖率与变异分析评估，完整的规则顺序与演算示例见复现包。

基于程序分析的覆盖率增强。 即便测试能够编译，它们仍可能遗漏边界情形。为在不额外调用 LLM 的情况下弥补这一缺口，CATGen 使用静态分析识别关键决策点，例如空值检查、空字符串校验以及显式抛出异常。对每个未覆盖条件，CATGen 按 Given–When–Then 范式合成一条附加测试（Yuan et al., 2024；Wang et al., 2024b）：在 Given 阶段，它分析异常处理结构与外部依赖，并通过 mock 加以模拟；在 When 阶段，它注入边界/无效输入（例如 null 或空字符串）以触发目标路径；在 Then 阶段，它生成基于值的、感知异常的断言（例如 assertTrue、assertThrows）以验证期望行为。图 3 展示了一个例子：LLM 生成的测试遗漏了空输入场景，增强模块自动添加一条有针对性的测试，以行使并验证相应的异常处理。最后，CATGen 把分析驱动的测试合并进 LLM 补全的类。一个确定性的归并步骤解决冲突的 @Test 名称（必要时为仅由增强产生的方法添加后缀），移除近乎重复的方法体，并为可读性排序方法；随后静态修复在合并后的类上调和 import 与签名。

下篇继续：上下文至关重要：提升基于大语言模型的单元测试生成的实用可靠性（下）。