LLM 与人工单元测试：在真实 Python 缺陷上的故障检测能力

LLM 与人工单元测试：在真实 Python 缺陷上的故障检测能力（中文全译）

翻译说明：本文是 arXiv 论文 LLM vs. Human Unit Tests: Fault Detection on Real Python Bugs（arXiv:2606.08588）的中文全译，由智测团队翻译。原作者：Phouvadeth Vathana、Prapti Bhatt、Rishi Patel、Nasir U. Eisty。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

摘要

大型语言模型（LLM）在自动化单元测试生成方面已展现出相当大的潜力，但相对于人工编写测试的实际有效性仍然缺乏充分理解。现有评估通常依赖于面向覆盖率的基准测试，这些基准并不直接评估故障检测能力。我们提出了一项对 LLM 生成的测试和人工编写的测试在三个互补的 Python 基准上的实证比较：来自 BugsInPy 的 29 个真实历史缺陷、一个来自 python-slugify 和 packaging 的函数级基准，以及一个受控配对基准。我们的生成管道将 Gemini 2.5 Flash 与轻量级词法检索机制相结合，在生成时提供与缺陷相关的上下文。在八个质量维度上，带有检索增强上下文的 LLM 生成测试在 69% 的案例中检测到故障，而通用人工编写测试仅为 17.2%（Fisher 精确检验，p<0.001，Cohen's h=1.10）。关键在于，两种方法的行覆盖率和分支覆盖率几乎相同（84.8% 对 88.5%，75.2% 对 82.1%），这证实了覆盖率不足以作为故障检测能力的代理指标。我们讨论了每种方法表现优异的条件，描述了它们的互补优势，并指出了检索上下文和可复现基准构建在有意义的测试质量评估中的关键作用。

I 引言

软件测试是软件质量保证的基石，然而编写单元测试是开发者工作流中最重复且最耗时的活动之一。单元测试在隔离状态下验证单个函数的行为，记录预期行为，并在代码变更时构成防止回归的第一道防线。尽管单元测试很重要，但实践中的测试套件经常不完整：开发者在进度压力下工作，边界情况被忽视，针对特定故障条件的测试往往在发现缺陷之后才编写。这种差距的成本是显著的；逃到生产环境的缺陷比在开发阶段捕获的缺陷修复成本高出一个数量级 [12]。

大型语言模型（LLM）已成为自动化单元测试生成的有前景的技术。最近的工作表明，GPT-4 和 Gemini 等模型可以在很少或没有手动提示的情况下为真实世界的函数生成语法有效、可编译的测试 [6, 7, 2]。商业工具现在将基于 LLM 的测试生成直接嵌入到开发者工作流中，这使得人们期望自动化生成能够显著减少维护高质量测试套件所需的人力投入。这些发展使得对 LLM 测试质量的严格、基于证据的理解既及时又重要。

然而，该领域的主导评估框架是不充分的。大多数现有研究测量结构覆盖率和可编译性，这些指标评估生成的代码是否能够无错误执行，但不评估其是否真正检测到故障 [7, 6]。Inozemtseva 和 Holmes [15] 通过实证表明，覆盖率与测试套件有效性之间没有强相关性，Cai 和 Lyu [5] 证明测试可以实现高行覆盖率，同时完全未测试关键的故障条件。尽管有这些发现，覆盖率仍然是 LLM 测试生成研究中的主要衡量标准，产生的评估文献可能显著高估了实际测试质量。一个执行了函数 90% 的行但对其输出没有任何有意义断言的测试，对于试图防止回归的开发者来说几乎没有价值。

现有研究的第二个局限性在于，它们很少在自动化生成最自然有价值的背景下评估 LLM 生成的测试：即在修复缺陷时的回归测试。当开发者解决缺陷时，他们恰好拥有 LLM 生成精确的、针对故障的测试所需的信息：缺陷报告、补丁差异和周围的源代码上下文。在这种背景下评估 LLM——即通过检索增强生成（RAG）管道在生成时检索并提供与缺陷相关的信息——比单独评估直接提示更加现实且更具信息量。然而，很少有研究系统地比较 RAG 增强的 LLM 测试与真实历史缺陷上的现有人工编写测试。

第三个挑战是基准质量。真实的软件仓库是嘈杂且异质的。必须仔细选择缺陷以确保可复现性，必须正确检出仓库版本，并且在进行任何公平比较之前必须隔离相关的代码和测试工件。将数据集构建视为预处理细节的研究会引入混淆结果并阻止复现的不一致性。我们认为基准构建本身是一项方法论贡献，并以足够的细节描述我们的管道以支持独立复现。

本文解决了这三个挑战。我们设计并执行了一项多基准实证研究，评估 LLM 生成的测试在检测真实 Python 缺陷方面的能力，而不仅仅是实现覆盖率。我们的生成管道将 Gemini 2.5 Flash [18] 与轻量级词法 RAG 机制相结合，该机制在生成时检索补丁差异、缺陷描述和周围的源代码上下文。我们在八个质量维度上将生成的测试与现有的通用人工编写测试进行比较，并将我们的发现置于对 LLM 生成何时提供最大价值的清晰描述中。

我们的结果揭示了一个引人注目且重要的发现。带有检索增强上下文的 LLM 生成测试在 29 个真实历史缺陷中的 69% 检测到故障，而人工编写测试仅为 17.2%，这是一个四倍的差异，在 p<0.001 水平上显著，效应量大（Cohen's h=1.10）。然而，两种方法之间的行覆盖率和分支覆盖率在统计上没有区别（84.8% 对 88.5%，75.2% 对 82.1%）。这种覆盖率相近但故障检测率截然不同的组合提供了迄今为止最清晰的实证证据，表明覆盖率指标是测试质量的不可靠代理，它指向一个具体的部署策略：LLM 测试生成在有缺陷上下文可用的修复时最有价值。

研究问题。 三个问题指导本研究：

RQ1 与通用人工编写测试相比，上下文感知的 LLM 生成测试在检测真实历史缺陷方面有多有效？

RQ2 在什么条件下 LLM 生成的测试优于或落后于人工编写的测试？

RQ3 LLM 生成的测试和人工编写的测试在覆盖率、断言密度、文档和测试模式方面有何不同？

贡献。 本文做出四项贡献：

• 一个多基准评估管道，整合了来自 BugsInPy 的 29 个真实历史缺陷、一个函数级开源基准和一个受控配对基准，以及一个复现包。
• 实证证据表明，带有检索增强上下文的 LLM 生成测试比通用人工测试实现了四倍更高的故障检测率，同时在结构覆盖率上接近平衡，直接挑战了覆盖率作为测试质量主要评估标准的地位。
• 对 LLM 生成测试和人工编写测试各自表现优异的条件的特征化，为考虑在持续集成工作流中采用基于 LLM 的测试生成的团队提供实用指导。
• 将基准构建阐述为测试质量研究中的一流方法论关注点，并提供可复现基准设计的具体建议。

II 相关工作

II-A 基于 LLM 的测试生成

Schäfer 等人 [6] 对跨多种语言的基于 LLM 的单元测试生成了大规模实证评估，发现生成的测试实现了有竞争力的分支覆盖率，但与开发者编写的测试相比存在语义差距和测试异味。Yang 等人 [7] 在 EvoEval 基准上评估了多个 LLM，报告称虽然通过率和覆盖率合理，但 LLM 在深度行为断言方面存在困难。Ouédraogo 等人 [2] 大规模研究了 310 个 Python 项目，发现生成的测试质量根据函数复杂度和项目类型存在很大差异；他们的配套研究 [8] 分类了 LLM 输出中反复出现的测试异味。这些评估的一个持续局限性是它们依赖结构覆盖率作为主要质量标准。我们的工作将核心标准转移到真实历史缺陷上的故障检测，遵循 Inozemtseva 和 Holmes [15] 的实证论点，即覆盖率和测试套件有效性之间没有强相关性。Haroon 等人 [3] 最近研究了软件演化下的 LLM 测试生成，发现随着代码变化，生成的测试在故障检测能力方面会退化；我们的研究通过在固定的历史缺陷上检查基线比较来补充这一点。

II-B 传统自动化测试生成

在 LLM 出现之前，EvoSuite [17] 等基于搜索的工具已经证明自动化方法可以为 Java 实现高结构覆盖率。然而，这些工具主要优化覆盖率和行执行，往往产生语义断言薄弱或缺失的测试 [9]。Watson 等人 [9] 专门研究了学习有意义的断言语句的问题，发现这对于自动化方法来说是一个重大挑战。我们的研究通过将基于 LLM 的生成置于这一格局中，询问上下文指导是否能够解决面向覆盖率的工具留下的故障检测差距。

II-C 人工测试实践

Bai 等人 [1] 检查了学生 and 开发者的测试实践，发现人类开发者经常优先考虑常见执行路径，同时忽视边界情况和失败条件，将良好的测试主要与高覆盖率联系在一起，即使覆盖率不能预测故障检测。这些观察结果使我们的发现具有情境意义：BugsInPy 数据集中的人工编写测试倾向于针对预期行为而非引发故障的边界情况。

II-D 检索增强生成

Lewis 等人 [16] 引入了检索增强生成作为一种在推理时为 LLM 提供外部文档的机制，提高了事实准确性并减少了幻觉。Shin 等人 [4] 专门针对测试生成研究了 RAG，发现即使是轻量级检索也能提高生成相关性。我们的实现基于这些思想，但使用词法重叠而非基于嵌入的检索，降低了基础设施要求，同时保留了实际效益。我们实验中的一个关键发现与 RAG 文献一致：过多的上下文会稀释提示焦点并降低输出质量。

II-E 挖掘软件仓库以构建基准

BugsInPy [14] 提供了一个精心策划的可复现 Python 缺陷集合，这些缺陷来自真实的开源项目。使用类似数据库（包括用于 Java 的 Defects4J [13]）的研究已将它们确立为自动化修复、测试生成和故障定位研究的标准评估工具。Zheng 等人 [12] 更广泛地认为，LLM 代码评估必须超越正确性，考虑多个质量维度，这一动机直接影响了我们的指标设计。代码质量研究 [10, 11] 进一步表明，LLM 生成的代码经常引入与功能正确性正交的可维护性问题，加强了对多维评估的需求。

III 研究设计与实现

III-A 整体设计

我们在三个互补的基准设置中评估 LLM 生成的测试和人工编写的测试。BugsInPy 通过可复现的历史缺陷贡献生态效度；开源基准实现更干净的函数级比较，减少仓库噪声；受控基准提供最大的实验对称性。单一基准不足以单独表征测试质量，因此多数据集设计是深思熟虑的：它确保发现不是任何单一数据集特征的产物。

研究管道分为三个阶段：（1）结构化基准构建，其中每个缺陷或函数被转换为可复现的任务包；（2）使用 RAG 增强管道的 LLM 测试生成；（3）跨八个质量指标的比较评估。

III-B 基准构建

#### III-B1 BugsInPy 基准

我们使用 BugsInPy [14] 作为历史 Python 缺陷的主要来源。从完整数据库开始，我们应用了三个纳入标准：缺陷必须在 Python 3 环境中可复现，修复前仓库中必须存在至少一个失败的测试，并且更改的源代码行必须能够通过干净的统一差异识别。过滤后，保留 29 个缺陷作为冻结基准集。表 I 总结了基准组成。

对于每个选定的缺陷，我们检出了有缺陷和已修复的仓库版本，提取了统一差异，识别了包含修改行的函数和类（补丁上下文），并定位了与失败行为相关的所有测试文件。这些工件被打包成每个缺陷的上下文文件夹，供生成和评估阶段使用。建立冻结的、版本化的基准集至关重要：它确保所有后续阶段都在稳定、共享的任务集合上运行，而不是变化的候选池。

#### III-B2 开源函数基准

为了补充历史缺陷设置，我们从 python-slugify 和 packaging 构建了一个函数级基准。选择这些项目是因为它们包含紧凑、文档良好的实用函数，具有现有的开发者编写测试，可作为高质量基线。每个任务由目标函数、其模块级导入和对应的人工测试文件组成。人工编写的测试被视为锁定基线：LLM 在生成期间仅接收函数源和生成提示，无法访问人工测试。

#### III-B3 受控配对基准

受控基准由一组较小的函数组成，研究人员在与 LLM 相同的信息条件下独立编写了参考测试（仅函数源，无缺陷上下文）。此设置将生成方法的影响与可用上下文的差异分离开来。

表 I：基准组成

III-C LLM 测试生成管道

我们使用 Gemini 2.5 Flash [18] 作为生成模型，选择它是因其在代码生成质量、推理速度和 API 可访问性之间的平衡，适合在许多基准任务上进行迭代实验。

管道不仅仅依赖直接提示，还集成了一个轻量级词法 RAG 机制。每个任务的上下文存储包含缺陷补丁差异、周围源代码上下文和相关测试侧工件。在生成时，系统按以下步骤进行：

1. 将目标函数的源代码标记化为关键词集 K。
2. 上下文存储中的每个文档 d 通过归一化关键词重叠评分：score(d) = |K ∩ tokens(d)| / |K|。
3. 选择前 k=3 个文档并作为参考材料附加到提示中。
4. 最终提示包括系统角色（"专家 Python 测试工程师"）、目标函数、检索到的上下文以及明确的生成约束：只生成一个 pytest 测试函数，仅针对提供的源，避免无关的辅助代码。
5. 解析 LLM 响应并提取代码块。

初步实验显示，k>3 会导致提示稀释，增加冗长性并降低输出一致性。约束提示结构来自迭代细化：初始宽泛提示经常产生冗长、偏离目标的输出，包含幻觉的辅助函数和与目标函数无关的样板代码。

III-D 评估指标

表 II 定义了用于比较的八个指标。故障检测是主要指标：如果测试在有缺陷的版本上失败并在已修复的版本上通过，则记为检测到故障，作为已知缺陷的回归测试。这一操作化遵循实证测试研究的标准实践 [15, 5]。覆盖率使用 pytest-cov 在行和分支粒度上测量。断言计数、代码行数和边界情况计数通过测试源的静态分析计算。文档存在性（docstring）和测试模式分类也通过静态方式确定。

表 II：评估指标

III-E 统计分析

二元结果（故障检测、docstring 存在）使用 Fisher 精确检验和 Cohen's h 作为效应量进行比较。连续和有序指标（代码行数、断言计数、边界情况计数、覆盖率百分比）使用双侧 Mann-Whitney U 检验和秩二列相关 r 作为效应量进行比较。所有检验使用显著性阈值 α=0.05。效应量遵循 Cohen 的惯例：|h| 或 |r| ≥ 0.5 表示大效应。

IV 结果

IV-A RQ1：故障检测

LLM 生成的测试在 29 个案例中的 20 个（69.0%）检测到故障，而人工编写的测试仅为 29 个中的 5 个（17.2%）（图 1）。Fisher 精确检验确认差异高度显著（p<0.001，Cohen's h=1.10，大效应）。

解释比较。 这一结果需要仔细框架化。LLM 测试使用检索到的缺陷上下文生成，包括补丁差异和缺陷描述，使其成为专门针对性的回归测试。BugsInPy 仓库中的人工编写测试是在特定缺陷之前或独立编写的，代表通用断言。因此，该比较回答了以下问题：当缺陷上下文可用时，LLM 能否比预先存在的通用测试更可靠地生成捕获已知故障的回归测试？答案显然是肯定的。实际意义在第 V 节中进一步讨论，即 LLM 生成在有缺陷上下文自然存在的修复时最有价值。

图 1： 29 个 BugsInPy 缺陷上的故障检测比较。带有 RAG 上下文的 LLM 测试检测到 29 个缺陷中的 20 个（69%）；人工编写的通用测试检测到 29 个中的 5 个（17.2%）。Fisher 精确检验：p<0.001，Cohen's h=1.10。

IV-B RQ2：LLM 优势或劣势的条件

我们的分析确定了 LLM 测试始终优于人工基线的四种条件，以及人工测试保持实际优势的三种条件。

LLM 生成的测试在以下情况下更强：

• 缺陷上下文可用。 RAG 管道对观察到的故障检测优势至关重要。寻求采用 LLM 测试生成的组织应该围绕其缺陷跟踪系统和补丁审查工作流程构建检索基础设施。
• 需要穷尽输入覆盖。 LLM 轻松发出覆盖广泛输入范围的参数化测试，人类较少使用这种模式（分别为 24% 对 10% 的测试）。
• 重视全面文档。 LLM 测试在 65.5% 的案例中包含 docstring，而此基准中人工编写测试为 0%（Fisher 精确检验，p<0.001，Cohen's h=1.28）。
• 边界情况多样性是目标。 LLM 每个测试平均生成 5.0 个不同的输入场景，而人工测试为 3.0 个。

人工编写的测试在以下情况下更强：

• 没有先验缺陷知识可用。 如果没有缺陷上下文，LLM 测试不太可能针对特定于故障的代码路径，RAG 优势消失。
• 简洁性和长期可维护性是优先事项。 人工测试平均 9.6 行代码，而 LLM 测试为 31.0 行，使其在活动代码库中更容易阅读和修改（Mann-Whitney U 检验，p<0.001，大效应）。
• 需要深层领域或行为知识。 人类开发者编码了对可接受行为的隐式理解，这可能无法仅从函数源中恢复。

IV-C RQ3：覆盖率、断言和测试模式

#### IV-C1 覆盖率分析

表 III 报告了所有 52 个任务的质量和覆盖率指标。最引人注目的发现是覆盖率平价：人工和 LLM 测试实现了几乎相同的行覆盖率（84.8% 对 88.5%，Mann-Whitney p=0.28）和分支覆盖率（75.2% 对 82.1%，Mann-Whitney p=0.17）。这些差异在统计上不显著。尽管存在这种相似性，故障检测率却相差四倍（17.2% 对 69%）。这一结果为以下观点提供了直接的实证支持：覆盖率是测试质量的不足代理 [15]：测试套件可能执行几乎所有代码路径，但仍然错过将在故障行为上失败的特定断言。

表 III：质量和覆盖率结果（52 个任务的平均值；29 个 BugsInPy 缺陷上的故障检测）

图 2： 所有 52 个任务的覆盖率比较。行和分支覆盖率差异在统计上不显著（两者 p>0.15），尽管故障检测率存在四倍差异。

#### IV-C2 冗长度和断言

LLM 生成的测试明显更冗长：平均 31.0 行，而人工测试为 9.6 行，差异为 3.2 倍，在 p<0.001 水平上显著，效应量大。断言计数也存在显著差异（5.5 对 3.2，p<0.01），边界情况覆盖也是如此（5.0 对 3.0，p<0.01）。虽然较高的断言密度和更广泛的输入覆盖通常是理想的属性，但在偏好简洁、可读测试的代码库中，冗长度增加引发了对可维护性的合理担忧。

#### IV-C3 测试模式和质量概况

图 4 显示了测试模式的分布。人工编写的测试主要依赖简单断言（72%），参数化测试（10%）、mock 对象（7%）和 try/except 块（7%）的使用适度。LLM 生成的测试呈现出明显不同的概况：高级复合模式占主导（41%），其次是参数化测试（24%）、简单断言（14%）、pytest.raises 异常测试（7%）和 mock 对象（7%）。

图 3 中的质量概况雷达直观地总结了这些差异。LLM 测试在大多数维度上得分较高，但人工测试用显著更少的代码实现了其故障检测率，表明就每行测试代码捕获的缺陷而言效率更高。

图 3： 比较人工和 LLM 测试在五个维度上的质量概况雷达。LLM 概况在大多数轴上更大；人工概况更紧凑，反映了对简洁性的强调。

图 4： 测试模式分布。人类偏好简单断言（72%）；LLM 更频繁地使用高级复合模式（41%）和参数化测试（24%）。

图 5： 五个指标的摘要比较。LLM 测试在断言、代码行数、边界情况、故障检测和 docstring 率上得分较高；人工测试更简洁。

V 讨论

V-A 回归测试作为自然的 LLM 用例

故障检测差距不应被解读为 LLM 在所有情况下都是更好的测试编写者的证据。它反映了一个特定且实际重要的场景：当缺陷已被识别且其补丁正在审查时，能够访问该上下文的 LLM 可以比在没有缺陷先验知识的情况下编写的通用测试更可靠地生成有针对性的回归测试。这一框架对团队应如何部署 LLM 测试生成有直接影响。最高价值的集成点是在修复时，作为补丁审查工作流的一部分：与修复一起生成 LLM 测试，为其提供差异和缺陷报告，并将其用作自动回归保护。

人工编写的测试对于通用覆盖和捕获仅从函数源中不明显的行为期望仍然不可或缺。我们的数据显示，两种方法之间的覆盖率水平几乎相同，这意味着 LLM 回归测试并没有实质性地扩展超出人工测试已覆盖的代码路径。这两种方法是互补的：人工测试提供广泛的行为验证；LLM 回归测试在缺陷解决时提供有针对性的故障检测。

V-B 定性示例：parse_dfxp_time_expr

为了将汇总统计数据 grounding 在具体案例中，我们检查了 youtube-dl 中 parse_dfxp_time_expr() 函数生成的测试，该函数解析 DFXP 字幕时间表达式并将有效字符串转换为浮点秒值。

人工编写的测试（图 6）验证常见的整数和浮点输入、标准时间后缀处理以及少量明确无效的 case。LLM 生成的测试（图 7）涵盖了更广泛的格式错误输入，包括原始正则表达式未处理的前导小数格式（.5s）和双小数表达式（10..5s）。这些输入中的几个揭示了解析器中的静默失败，这正是汇总统计中可见的那种故障检测差距。

此示例还说明了冗长度权衡。LLM 测试包含额外的断言和 docstring，提高了自文档化，但测试长度超过人工版本的三倍，包含开发者可能会为生产使用而修剪的样板代码。

图 6： parse_dfxp_time_expr() 的人工编写测试，专注于常见有效和无效输入。

图 7： parse_dfxp_time_expr() 的 LLM 生成测试，涵盖人工测试未处理的边界情况和格式错误输入。

V-C 实用建议

研究结果提出了三项建议。

1. 在修复时部署 LLM 生成。 当缺陷被确认且补丁正在审查时，生成附带缺陷差异和描述的 LLM 测试。检索到的上下文足以生成高精度回归测试，无需嵌入或向量数据库基础设施。

2. 不要用 LLM 输出替换人工测试套件。 人工测试编码了 LLM 无法仅从源中推断的行为知识。方法之间的覆盖率平价表明，LLM 测试并没有实质性地扩展现有人工套件之外的行为覆盖。

3. 基于故障检测而非仅覆盖率评估测试。 我们的数据证实，覆盖率掩盖了故障检测能力的巨大差异。将突变测试或回归测试有效性纳入持续集成质量门提供了比行或分支覆盖率强得多的信号。

VI 对效度的威胁

VI-A 内部效度

最重要的内部威胁是 LLM 和人工测试之间的信息不对称。LLM 测试通过 RAG 管道接收缺陷补丁差异和描述；人工编写的测试是在没有特定缺陷先验知识的情况下开发的。这种不对称意味着故障检测比较反映了在生成时拥有缺陷上下文的价值，而不是生成能力的无混淆正面比较。我们通过将 RQ1 明确框架化为上下文感知回归生成与通用测试的比较来缓解这一问题，并在第 V 节中指出，直接能力比较需要人类测试者获得相同的上下文信息。

次要的内部威胁是测试集合的不一致性。不同的基准组件由不同的团队成员使用略有不同的提取程序准备，可能引入格式或上下文深度变化。我们通过标准化传递和共享注释方案缓解了这一问题，但不能完全排除残留的不一致性。

VI-B 外部效度

BugsInPy 组件涵盖了来自有限 Python 开源项目的 29 个缺陷。研究结果可能无法推广到其他编程语言、专有代码库或缺陷分布明显不同的领域。开源基准仅限于两个小型实用库，限制了功能多样性。扩展到更大、更多样的仓库，以及通过 Defects4J [13] 扩展到 Java，将增强泛化性。

所有结果都基于单个 LLM（Gemini 2.5 Flash）。不同的模型，尤其是那些具有更强形式推理或代码理解能力的模型，可能会产生实质不同的结果。

VI-C 构念效度

故障检测被操作化为在有缺陷版本上失败并在已修复版本上通过的测试。这是标准且经过充分论证的 [14, 15]，但没有捕获那些正确描述函数不同方面预期行为而未触发补丁中特定突变的测试。边界情况计数和测试模式分类通过静态分析计算，可能会错误分类结构非典型的测试。Docstring 存在性是文档质量的弱代理；一行 docstring 与全面的 docstring 计数相同。

VI-D 结论效度

在故障检测分析中使用 29 个缺陷，研究的统计功效对于子组比较（例如，按项目或按模式分解）有限。我们全程使用 Fisher 精确检验和 Mann-Whitney U 检验，因为它们适用于小样本且无需正态性假设。尽管如此，子组分析应被视为探索性而非验证性。

VII 结论

我们提出了跨三个互补 Python 基准的 LLM 生成测试和人工编写测试的实证比较。使用带有轻量级词法 RAG 管道的 Gemini 2.5 Flash，我们发现上下文感知的 LLM 测试在 29 个真实历史缺陷中的 69% 检测到故障，而通用人工编写测试仅为 17.2%（Fisher 精确检验，p<0.001，Cohen's h=1.10）。优势不能归因于更高的覆盖率：两种方法的行覆盖率和分支覆盖率在统计上没有区别，直接证明了覆盖率是故障检测能力的不足代理。

核心的实际见解是，LLM 测试生成在回归测试上下文中最有价值，其中缺陷上下文可用于生成管道。在这种设置下，LLM 测试比预先存在的通用测试提供更强的故障检测保证。对于没有先验缺陷上下文的通用测试，优势减弱；人工测试更简洁、更可维护，并且在代码覆盖率方面同样有效。因此，这两种方法是互补的：人工测试用于持续的行为验证，LLM 测试用于修复时的针对性回归覆盖。

未来工作方向包括在同一基准套件上比较多个 LLM，扩展到 Java 和 Defects4J [13]，进行对照实验，其中人类开发者获得与 LLM 相同的缺陷上下文，并研究结合人类和 LLM 测试以捕获两种方法优势的混合工作流。

署名与许可

本文是 arXiv 论文 LLM vs. Human Unit Tests: Fault Detection on Real Python Bugs（arXiv:2606.08588）的中文全译，由智测团队翻译。原文以 CC BY 4.0 许可发布。

原文链接：https://arxiv.org/abs/2606.08588

译者：智测团队