Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation

该研究通过大规模实证评估，首次全面分析了四种大语言模型在生成类级别单元测试中的表现，发现尽管推理式提示（如 GToT）能显著提升测试的可读性和可靠性，但幻觉导致的编译失败率依然高企，表明结合自动化验证与搜索式优化的混合方法才是实现生产级测试生成的关键。

要点

这篇论文就像是一场**“超级大厨（AI）”与“老练的机械臂（传统工具）”之间的烹饪大赛**，比赛内容是：谁能更完美地写出“食谱”（单元测试代码），来确保一道菜（软件功能）不会做坏？

为了让你轻松理解，我们把这篇硬核的学术报告翻译成几个生动的故事：

1. 比赛背景：为什么需要这场大赛？

• 现状：写“食谱”（单元测试）是保证软件不崩盘的关键，但让程序员手写太累了，大家经常偷懒。
• 老对手（EvoSuite）：这是一个传统的“机械臂”工具。它非常勤奋，能写出覆盖所有角落的食谱，但写出来的东西像乱码，全是机器语言，人类根本看不懂，也没法维护。
• 新选手（LLM 大模型）：像 GPT-4 这样的 AI 大厨，它们很聪明，写出来的食谱人话多、逻辑顺、读起来像人写的。但是，它们有个大毛病：爱“瞎编”（幻觉）。比如，食谱里写着“加一勺魔法粉”，但厨房里根本没有这个粉，导致菜做不出来（代码编译失败）。

这篇论文的目的：就是要把这些 AI 大厨请进厨房，看看它们到底能不能真正帮上忙，以及怎么给它们下指令（提示词工程），才能让它们少犯傻，多干活。

---

2. 实验设置：怎么比的？

研究人员找了4 位顶级 AI 大厨（GPT-3.5, GPT-4, Mistral 7B, Mixtral 8x7B），让它们去给3 种不同的食材（Defects4J, SF110, CMD 三个数据集）写食谱。

为了测试 AI 的能力，研究人员用了5 种不同的“下指令”方式（提示词工程）：

1. 零样本（ZSL）：直接说“做这道菜”，不给任何例子。（像让厨师看天书）
2. 少样本（FSL）：给一个例子，“看，别人是这么做的，你照着做”。
3. 思维链（CoT）：让厨师“先想步骤，再动手”（比如：先切菜，再炒菜，最后调味）。
4. 思维树（ToT）：让厨师“想三条不同的做法，选最好的那条”。
5. 引导式思维树（GToT）：这是研究人员的独家秘籍。想象有三个专家厨师坐在一起讨论，互相挑错，最后合并成一个完美的方案。

---

3. 比赛结果：谁赢了？

🏆 第一回合：能不能把菜端上来？（生成能力）

• 机械臂（EvoSuite）：只要给它食材，它**100%**能端出一盘菜（生成代码），但有时候菜是生的（无法编译）。
• AI 大厨：它们端菜的能力很强，几乎90% 以上都能端出来。但是，Mixtral 8x7B 这位大厨在遇到新食材（CMD 数据集）时，有点手忙脚乱，端菜率只有 63%。

🏆 第二回合：菜能不能吃？（编译与正确性）

这是最惨烈的一关。

• 机械臂：端出来的菜，**98%**都能直接吃（编译通过），非常稳定。
• AI 大厨：虽然端出来的菜看起来很像样，但**只有不到 10%**能直接吃！
  • 原因：AI 太爱“瞎编”了。它会在食谱里写“放入不存在的调料（幻觉符号）”或者“用没有权限的锅（权限错误）”。
  • 好消息：用了**GToT（三个专家讨论）**这种指令后，AI 的瞎编行为减少了，菜能吃的比例稍微高了一点，但离机械臂的稳定性还有很大差距。

🏆 第三回合：菜谱好不好读？（可读性）

• 机械臂：它的食谱是天书，全是 test_1, test_2，变量名像乱码，人类看了想砸键盘。
• AI 大厨：它的食谱非常漂亮！变量名起得像人话（比如 testDivideByZero），逻辑清晰。
• 结论：如果你想要人类能看懂、好维护的食谱，AI 完胜。特别是用了 GToT 指令后，AI 写的食谱简直像教科书。

🏆 第四回合：菜的营养够吗？（代码覆盖率）

• 机械臂：它是强迫症，为了覆盖所有角落，它会把锅铲、盘子、甚至桌子腿都测一遍。覆盖率极高（94%+）。
• AI 大厨：它比较随性，只测它觉得重要的地方。覆盖率大概在 50%-70% 左右，远不如机械臂。
• 结论：如果你追求极致的安全，机械臂更靠谱；如果你追求效率，AI 能帮你快速覆盖核心功能。

🏆 第五回合：有没有“坏毛病”？（测试异味）

• 机械臂：喜欢用魔法数字（比如直接写 15 而不是 MAX_USERS），而且喜欢写很多废话测试（Lazy Test）。
• AI 大厨：虽然读起来顺，但也爱犯**“魔法数字”的毛病（几乎 100% 的测试里都有）。而且，如果指令没给好，它容易写出“断言轮盘赌”**（Assertion Roulette），就是测试失败了，你不知道到底是哪一步错了。
• 好消息：用了GToT指令，AI 的“断言轮盘赌”毛病大幅减少，变得更有条理。

---

4. 核心发现与启示（人话版总结）

1. AI 不是万能的，但它是好帮手：
   目前的 AI 还不能完全取代传统的测试工具（EvoSuite）。如果你只想要“能跑”的代码，机械臂更稳；如果你想要“人看得懂”的代码，AI 是首选。

2. 怎么指挥 AI 很重要（提示词工程）：
   直接让 AI 干活（零样本），它容易犯傻。如果你让它**“像三个专家一样讨论”（GToT），或者“一步步思考”（CoT），它写出来的代码质量会显著提升**，结构更清晰，瞎编的错误更少。

3. 最大的痛点是“幻觉”：
   AI 最大的问题还是**“不懂装懂”。它经常引用不存在的函数或库。这需要人类开发者或者自动化工具在后面“把关”**（验证和修复），不能直接拿来就用。

4. 未来的方向：混合双打：
   最好的方案是**“机械臂 + AI"**。

   • 用机械臂（EvoSuite）去疯狂扫雷，确保代码覆盖率，找出所有隐藏的 Bug。
   • 用AI（配合 GToT 指令）把这些冷冰冰的代码**“翻译”**成人类能看懂、好维护的漂亮代码。
   • 最后，让人类开发者做最后的审核。

一句话总结

这篇论文告诉我们：AI 写测试代码已经很像样了，特别是让它“多思考”一点，写出来的代码既漂亮又好读。但它还不够靠谱，容易“瞎编”导致代码跑不起来。所以，现在最好的办法是让人类牵着 AI 的手，让它当“创意助手”，而不是让它独自当“总指挥”。

技术摘要

这是一份关于论文《Prompt Engineering in LLMs for Automated Unit Test Generation: A Large-Scale Study》（大语言模型中提示工程在自动化单元测试生成中的应用：一项大规模研究）的详细技术总结。

1. 研究背景与问题 (Problem)

单元测试是软件可靠性的基石，但手动编写测试耗时且常被忽视。传统的基于搜索的软件测试（SBST，如 EvoSuite）虽然能提高代码覆盖率，但生成的测试用例往往可读性差、难以维护，且命名不直观。

近年来，大语言模型（LLM）在代码生成方面展现出潜力，初步研究表明 LLM 生成的测试用例在命名和可读性上优于 SBST。然而，现有研究存在以下局限性：

• 评估维度单一：缺乏对执行驱动评估、基于推理的提示策略（如 CoT, ToT）以及真实世界测试场景的综合评估。
• 粒度不足：多数研究集中在方法级（Method-level），而实际开发中通常以类级（Class-level）为单位生成测试，涉及复杂的依赖和状态管理。
• 幻觉问题：LLM 生成的测试常包含不存在的符号、错误的 API 调用或虚构的依赖，导致编译失败率高。
• 缺乏对比基线：缺乏与最先进的 SBST 工具（如 EvoSuite）在大规模数据集上的系统性对比。

2. 方法论 (Methodology)

本研究进行了大规模实证评估，旨在分析提示工程对 LLM 生成单元测试质量的影响。

2.1 实验设置

• 模型：评估了四种主流指令微调模型：
  • OpenAI 系列：GPT-3.5-turbo, GPT-4
  • MistralAI 系列：Mistral 7B, Mixtral 8x7B
• 数据集：为了评估泛化能力并减少训练数据泄露，使用了三个数据集：
  • Defects4J：包含真实世界软件缺陷的 Java 项目。
  • SF110：包含现有测试用例的 Java 程序集合。
  • CMD (Custom Mini Dataset)：专门构建的数据集，包含 2023 年 5 月之后发布的项目（OceanBase 和 Conductor OSS），以最大程度减少 LLM 预训练数据泄露的影响。
• 提示策略 (Prompt Engineering)：对比了五种提示技术：
  • ZSL (Zero-Shot Learning)：零样本学习。
  • FSL (Few-Shot Learning)：少样本学习。
  • CoT (Chain-of-Thought)：思维链。
  • ToT (Tree-of-Thought)：思维树。
  • GToT (Guided Tree-of-Thought)：引导式思维树（本研究提出的新方法，模拟三位测试专家协作迭代优化）。
• 基线：使用 EvoSuite 作为基于搜索的测试生成（SBST）的基准工具。

2.2 评估指标

研究从多个维度进行了评估：

1. 生成能力与提取性：
   • MSR (Match Success Rate)：检测输出中是否包含符合 JUnit 结构的代码片段。
   • CSR (Code Extraction Success Rate)：成功提取出结构化测试代码的比例（排除自然语言解释）。
2. 正确性与可编译性：
   • 语法正确性（Javalang 解析）。
   • 可编译性（JVM 编译），并分析编译错误类型（如“找不到符号”、“包不存在”等幻觉问题）。
3. 人类导向质量：
   • 可读性：使用 Scalabrino 等人提出的深度学习模型评估。
   • 复杂度：圈复杂度（Cyclomatic）和认知复杂度（Cognitive）。
   • 静态分析：Checkstyle, PMD, SpotBugs（检测潜在 Bug 和代码异味）。
4. 测试质量：
   • 代码覆盖率：行覆盖、指令覆盖、方法覆盖（使用 JaCoCo）。
   • 测试异味 (Test Smells)：使用 TsDetect 检测（如断言轮盘、魔术数字测试等）。

3. 主要贡献 (Key Contributions)

1. 系统性的提示工程研究：首次在大类级别（Class-level）上，系统性地评估了五种结构化提示技术（ZSL, FSL, CoT, ToT, GToT）对通用 LLM 生成测试的影响，超越了以往仅关注代码专用模型或方法级的研究。
2. 结构正确性与可提取性分析：引入了 MSR 和 CSR 指标，量化了 LLM 输出格式遵循程度及代码提取的可靠性，揭示了格式混乱是下游评估的主要障碍。
3. 可读性与可维护性的区分：深入分析了提示工程如何同时影响测试的可读性（人类理解）和可维护性（长期演进），指出可读性高并不等同于无测试异味。
4. 大规模多数据集评估：在 Defects4J, SF110, CMD 三个数据集上评估了 4 个模型和 5 种提示策略，生成了 216,300 个测试用例，提供了比现有研究更广泛的泛化性证据。
5. 开源基准：公开了包含提示模板、评估脚本和结果的基准数据集。

4. 关键结果 (Key Results)

4.1 生成能力与提取性 (RQ0 & RQ1)

• 生成率：LLM 的原始生成率很高（通常>90%），但在某些复杂数据集（如 Defects4J 的部分项目）上，EvoSuite 甚至无法生成测试。
• 提取性：OpenAI 模型（GPT-3.5, GPT-4）在 MSR 和 CSR 上表现最好。GToT 策略在所有模型中 consistently 实现了最高的 MSR，表明结构化推理能有效增强对指令的遵循。
• FSL 表现不佳：少样本学习（FSL）在结构遵循方面往往表现不如零样本（ZSL）或推理型提示。

4.2 语法正确性与可编译性 (RQ2)

• 巨大的编译差距：尽管约 90% 的 LLM 输出包含语法正确的代码，但可编译率极低（<10%）。主要原因是“找不到符号”（Cannot Find Symbol）和“包不存在”等幻觉错误。
• EvoSuite 的优势：EvoSuite 生成的测试 100% 语法正确，且编译成功率极高（Defects4J 上约 98.1%）。
• 提示工程的作用：推理型提示（CoT, GToT）显著减少了特定类型的错误（如私有访问权限问题），但无法完全消除符号解析错误。

4.3 可读性与可维护性 (RQ3 & RQ4)

• 可读性：LLM 生成的测试在可读性上显著优于 EvoSuite（高出 21%-40%）。推理型提示（特别是 GToT 和 CoT）进一步提升了可读性。
• 测试异味：
  • 魔术数字 (Magic Number)：在所有设置中（包括 LLM 和 EvoSuite）都普遍存在（85%-100%）。
  • 断言轮盘 (Assertion Roulette)：推理型提示（CoT, GToT）能显著降低断言轮盘的发生率（例如 GPT-3.5 + CoT 在 CMD 上降至 6.4%），而 FSL 和 EvoSuite 则较高。
  • 静态缺陷：GToT 虽然结构更好，但有时会引入更多隐蔽的静态分析警告（如 SpotBugs 中的"Scary"级别问题）。

4.4 代码覆盖率 (RQ5)

• EvoSuite 胜出：EvoSuite 在覆盖率（行、指令、方法）上全面碾压 LLM。EvoSuite 中位数行覆盖率达 94.34%，而 LLM 通常低于 50%（除 Defects4J 外）。
• 推理提示的提升：CoT 和 GToT 能显著提升 LLM 的覆盖率，缩小与 EvoSuite 的差距，但仍无法达到 SBST 的系统性探索水平。
• 数据集偏差：Defects4J 上的表现可能受到预训练数据泄露的影响，而 SF110 的复杂架构导致 LLM 表现较差。

4.5 测试异味分布 (RQ6)

• LLM 生成的测试通常更简单、状态更少（General Fixture 异味较少），而 EvoSuite 则表现出更多的状态依赖和异常处理异味。
• 推理型提示能有效减少断言相关的异味，但无法解决魔术数字问题。

5. 结论与意义 (Significance)

• LLM 的定位：LLM 目前尚不能完全替代传统的 SBST 工具（如 EvoSuite）用于生产环境的自动化测试生成，因为其在可编译性、依赖处理和覆盖率方面存在显著缺陷。
• 最佳实践：LLM 最适合作为辅助工具，用于生成可读性高、结构清晰的测试骨架（Scaffolding）。
• 提示工程的重要性：结构化推理提示（特别是 GToT 和 CoT）对于提升测试的结构正确性、减少幻觉、提高可读性和降低特定测试异味至关重要。
• 未来方向：研究应转向混合方法，结合 SBST 的覆盖率优势（用于输入生成和探索）与 LLM 的可读性优势（用于重构、命名和断言优化），并引入自动化验证和依赖解析机制来解决幻觉问题。

总结：这项研究通过大规模实证数据表明，虽然 LLM 生成的测试在“像人写的”方面表现出色，但在“能跑且可靠”方面仍有很大差距。提示工程是弥合这一差距的关键手段，但最终的解决方案需要结合传统搜索技术与大模型的协同工作。