理解 LLM 驱动的测试 Oracle 生成

理解 LLM 驱动的测试 Oracle 生成（中文全译）

翻译说明：本文是 arXiv 论文 Understanding LLM-Driven Test Oracle Generation（arXiv:2601.05542，2026-01-09 提交）的中文全译，由智测团队翻译。原作者：Adam Bodicoat、Valerio Terragni（University of Auckland，新西兰）、Gunel Jahangirova（King's College London，英国）。该文是已被 AIware 2025（第 2 届 ACM/IEEE AI-Powered Software 国际会议）接收的作者版本。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节、数据与结论；参考文献列表与文内引注编号从略，模型名、工具名、基准名、指标名保留英文。原文的图 1、2、4、5 为代码清单，译文以代码块保留；图 3（结果柱状图）为位图，未在 arXiv HTML 中提供，从略。

摘要

自动化单元测试生成旨在提升软件质量，同时减少手工创建测试所需的时间和精力。然而，现有技术主要生成回归 oracle——它们以被测类的已实现行为为断言依据，并不解决 oracle 问题：区分正确与错误程序行为的挑战。

随着基础模型（FM），特别是大语言模型（LLM）的兴起，出现了生成反映预期行为的测试 oracle 的新机会。这使 LLM 成为 Promptware 的赋能者——软件的创建和测试由自然语言提示驱动。

本文呈现一项关于 LLM 生成能暴露软件失败的测试 oracle 之有效性的实证研究。我们调查不同的提示策略和不同层级的上下文输入如何影响 LLM 生成 oracle 的质量。我们的发现揭示了 FM 时代基于 LLM 的 oracle 生成的优势与局限，加深我们对其能力的理解，并促进该领域的未来研究。

索引词：大语言模型，基础模型，软件测试，测试 Oracle 问题，自动化测试生成，提示工程，Promptware，AI4SE

I 引言

软件测试对确保软件质量和可靠性至关重要。然而，手工创建测试 oracle 是劳动密集的。虽然像 EvoSuite 和 Randoop 这样的自动化测试生成工具通常依赖回归 oracle——它们假设当前版本是正确的——这限制了它们检测给定版本中缺陷的能力。这就是测试自动化中长期存在的 oracle 问题。

在基础模型（FM）时代，大语言模型（LLM）提供了解决这一问题的新机会。凭借自然语言理解、模式识别和上下文推理能力，LLM 可以帮助弥合自动化测试生成与有意义的 oracle 创建之间的鸿沟。通过提示解读开发者意图，LLM 能生成与预期行为而非已实现行为对齐的 oracle。

近期研究已开始探索用 LLM 生成测试和 oracle，但关键问题仍未解决，特别是提示策略和输入上下文如何影响 oracle 质量。当我们转向 Promptware——软件验证可能由开发者和非开发者提示专家共同设计的自然语言提示驱动——理解这些因素至关重要。

为填补这一空白，本文呈现一项实证研究：提示技术（zero-shot、few-shot、思维链 [CoT] 和思维树 [ToT]）与上下文输入（仅测试前缀、测试前缀加被测方法 [MUT]、测试前缀加被测类 [CUT]）如何影响 LLM 生成测试 oracle 的质量。我们的研究隔离了 LLM 的 oracle 生成能力，而非更宽泛的缺陷复现任务。因此我们不在提示中包含失败描述或缺陷报告——纳入这类输入会把任务转向缺陷复现或定位，它们与 oracle 问题正交。据我们所知，这是第一项做此类分析的研究。

我们使用 GitHub Recent Bugs（GHRB）基准——一个为在真实 Java 缺陷上评估 LLM 同时缓解数据泄漏风险而设计的数据集。对每个缺陷，我们向 LLM 提供有缺陷的代码及其触发测试输入——省略原始 oracle——并基于编译成功和缺陷暴露来分析 oracle 质量。我们的实验涉及 36 个有代表性的 GHRB 缺陷和两个 LLM：GPT-4o 和 StarCoder。

我们的结果揭示了几个重要趋势：

① 用更多上下文生成的 oracle 编译和检错更可靠。CUT 级上下文显著优于其他配置，达到 53.64% 准确率，对比 40.74%（MUT）和 40.38%（仅测试前缀）。这是预期中的结果。

② 提示风格很重要：zero-shot 和 few-shot 提示产生比 CoT 和 ToT 更高的编译率（67.38% 和 72.96%）与准确率（54.56% 和 51.30%）；CoT 和 ToT 的编译率都低于 50%，表现挣扎。

③ 在输入提示中纳入 CUT，配合 zero-shot 和 few-shot 提示技术，能产出最稳定准确的 LLM 生成测试 oracle。然而我们的发现也显示，基于推理的提示技术（CoT、ToT）有潜力产出准确的测试 oracle——当它们确实产出可编译断言时，其准确率很高。

④ 虽然 StarCoder 在平均准确率上略胜 GPT-4o，但 GPT-4o 配 CUT 上下文在全部组合中交付了最稳定准确的 oracle。

⑤ 提示策略对 oracle 有效性的影响强于 LLM 选择。

这些发现表明，提示设计和上下文在基于 LLM 的 oracle 生成的有效性中起关键作用。虽然推理驱动的提示（如 CoT、ToT）在能编译时显示出潜力，zero-shot 和 few-shot 提示目前在准确率和稳健性之间提供最佳权衡。我们的研究为 FM 时代测试专家和提示专家都能使用的 AI 辅助测试工具提供指导。

综上，本文做出以下贡献：

• 一项关于提示类型和上下文输入如何影响 LLM 生成测试 oracle 质量的实证研究。
• 为支持 Promptware，一系列关于 LLM 生成测试 oracle 有效性的洞察，为 LLM 驱动 oracle 生成的未来提供指导。
• 公开发布代码以确保可复现性并支持该领域的未来研究。

II 实验设计

我们的研究旨在评估 LLM 用不同输入提示变体生成准确、正确的测试 oracle 的能力。这些变体分两类：提示的内容和提示技术。具体来说，我们的实证研究调查以下研究问题：

• RQ1 - 输入上下文：提示内的内容和上下文对 LLM 生成测试 oracle 的准确率有什么影响？
• RQ2 - 提示工程：不同提示工程技术相对彼此如何影响 LLM 生成测试 oracle 的准确率？
• RQ3 - 模型比较：不同 LLM 如何影响 LLM 生成测试 oracle 的准确率？
• RQ4 - 影响分析：哪个因素对 LLM 生成的测试 oracle 影响最大？

RQ1 研究提示内容如何影响 LLM 生成的测试 oracle，帮助确定什么内容为测试 oracle 生成提供最佳上下文。我们用三个上下文层级：测试前缀（Test Prefix）、测试前缀加被测方法（MUT）、测试前缀加被测类（CUT）。

RQ2 调查提示技术对 LLM 生成测试 oracle 准确率的影响，让我们能比较不同提示技术从现有测试前缀生成测试 oracle 的有效性。本研究使用四种提示技术：zero-shot、few-shot、思维链和思维树。

RQ3 检查不同 LLM 基于其训练差异如何影响测试 oracle 生成。

RQ4 分析提示内容、提示技术和 LLM 对生成测试 oracle 准确率的相对影响，让我们能确定每个因素对 LLM 驱动测试 oracle 生成的相对重要性。本研究中，我们用每个变量的平均准确率极差来衡量其影响，并比较每个结果以找出贡献最高平均准确率的因素。

为回答这些 RQ，我们做了一个实验：让所选 LLM 为每个提示生成测试 oracle，其中提示是提示上下文和提示技术的独特组合。所用测试用例在有缺陷版本上失败、在修正版本上通过。我们移除测试 oracle，把修改后的测试用例和有缺陷代码作为输入提供给 LLM，然后提示 LLM 生成合适的测试 oracle。我们基于生成的 oracle 是否让有缺陷版本失败、让正确版本通过来评估正确性。这让我们能分析提示内容、提示技术和 LLM 如何影响 oracle 性能。

II-A 数据集

本研究使用 GitHub Recent Bugs（GHRB）基准，一个为在真实代码上评估 LLM 性能而设计的数据集。GHRB 确保缺陷和修复来自流行 LLM（包括 StarCoder 和 GPT-4o）训练期之后更新的真实仓库，从而避免数据泄漏和模型记忆。截至 2024 年 12 月，GHRB 包含来自 16 个流行开源 Java 仓库的 107 个缺陷。我们基于确保实验一致性和有效性的标准，从该数据集选择了 36 个缺陷。

1. 无编译错误：所选仓库的有缺陷和正确版本都被验证无编译期错误。这一标准对消除可能扭曲生成测试 oracle 评估的混杂因素至关重要。确保可编译性让分析能 solely 聚焦生成 oracle 的语义正确性。编译错误很可能源于基准数据集中某些仓库存在的不完整修复、缺失依赖或构建配置问题。

2. 随机抽样：为最小化选择偏差并增强发现的可泛化性，缺陷子集从基准中无编译错误的缺陷里随机抽取。这一方法确保所选缺陷代表数据集的一个多样且无偏的子集。由于更大子集所需的高计算成本，我们只选择 36 个缺陷。

与 Defects4J 等既定缺陷基准类似，数据集中每个仓库包含一个有缺陷版本（暴露缺陷的测试用例在其上失败）和对应的正确版本（同样的测试用例在其上通过）。我们还确保缺陷需要测试断言才能暴露，且不会导致不需要的异常——后者会让测试无需断言就失败。

原文图 1 和图 2 展示了 GHRB 基准中 JSoup 仓库的一个具体示例。图 1 呈现一个暴露缺陷的测试用例，设计来验证 Safelist 类拷贝构造器的正确性。测试用例先创建一个 Safelist 实例（safelist1），把它拷贝进第二个实例（safelist2），随后通过添加一个额外属性（"invalidAttribute"）修改原始对象。断言显式检查：原始对象中新加的这个属性在拷贝实例中不应被识别为安全，从而确认拷贝构造器正确地创建了独立副本。

@Test
public void testCopyConstructor_noSideEffectOnAttributes() {
    Safelist safelist1 = Safelist.none().addAttributes(TEST_TAG, TEST_ATTRIBUTE);
    Safelist safelist2 = new Safelist(safelist1);
    safelist1.addAttributes(TEST_TAG, "invalidAttribute");

    assertFalse(safelist2.isSafeAttribute(TEST_TAG, null, new Attribute("invalidAttribute", TEST_VALUE)));
}

图 1：暴露 Jsoup Safelist 类错误拷贝行为的测试用例（GHRB 基准）

然而，拷贝构造器的有缺陷实现（图 2）没有执行深拷贝。相反，它只是复用了对内部集合（attributes、tagNames 等）的引用，导致意外副作用。结果，对原始实例的任何后续修改都错误地传播到拷贝实例，使测试用例失败。我们研究的目标是调查影响 LLM 生成能准确检测软件缺陷的测试 oracle 之有效性的关键因素。

/**
 * Deep copy an existing Safelist to a new Safelist.
 * @param copy the Safelist to copy
 */
public Safelist(Safelist copy) {
    this();
    tagNames.addAll(copy.tagNames);
    attributes.putAll(copy.attributes);
    enforcedAttributes.putAll(copy.enforcedAttributes);
    protocols.putAll(copy.protocols);
    preserveRelativeLinks = copy.preserveRelativeLinks;
}

图 2：Safelist 拷贝构造器的有缺陷实现，导致意外副作用（GHRB 基准）

II-B 提示构造

本研究评估四种提示技术对测试 oracle 生成的影响：zero-shot、few-shot、思维链和思维树。选择它们是因为能捕捉模型推理和泛化的不同维度。

Zero-Shot 提示（Z）：要求模型执行任务而不提供任何先前示例或结构化引导。对测试 oracle 生成，这一技术给模型一个任务描述，让它为给定测试前缀生成测试 oracle。该方法仅基于提示内容和模型预训练来评估模型对任务的内在理解。

Few-Shot 提示（F）：给模型提供少量说明手头任务的示例。本研究中，我们用与测试前缀同仓库的三个测试 oracle 示例，以平衡提示长度与相关上下文。使用同仓库示例确保一致性，且对该仓库的所有缺陷使用相同示例，以减少变异性、聚焦提示变化。

思维链（CoT）提示（Ch）：引导模型走过一个结构化推理过程。遵循先前工作，用于生成 oracle 的 CoT 提示包含以下步骤：

• 识别测试前缀和被测代码（若提供）的目的
• 确定代码和测试的预期结果
• 构造正确的测试 oracle

这一方法旨在鼓励逻辑推理以改进生成 oracle 的准确率。

思维树（ToT）提示（Tr）：通过在收敛到最合理方案前探索多条潜在求解路径来扩展思维链推理。按先前工作，在测试 oracle 生成的语境中，构造 ToT 提示包含以下步骤：

• 根思想：对测试前缀和被测代码（若提供）的初始理解
• 分支：探索不同推理路径
• 扩展：进一步发展每条推理路径
• 剪枝：移除无效或冗余路径
• 组合：把有效分支的洞察组合成一组连贯、准确的测试 oracle

这一方法利用模型考虑多样推理路径的能力，有望改进复杂或模糊提示场景下的稳健性。

为进一步分析不同提示配置的影响，每种提示技术都在三个输入内容层级上测试：

测试前缀（T）：最小上下文，由不含测试 oracle 的测试代码组成。图 1 是一个用于提示输入的暴露缺陷测试示例，但移除了第七行的测试 oracle。

测试前缀 + MUT（M）：加入被测方法，为 oracle 生成提供额外上下文。图 2 是对应图 1 测试用例、要加入提示输入的被测方法示例。

测试前缀 + CUT（C）：加入包含测试和方法的类，提供更全面的上下文。

在提示中，所有测试断言 oracle 都从测试前缀移除——前缀可能包含多个断言。提示让 LLM 决定应生成多少断言。所提供的 CUT 和 MUT 来自有缺陷版本，但我们不在提示中说明测试暴露了一个缺陷。这反映一个现实场景：目标是在不知道测试是否揭示缺陷的情况下生成 oracle。我们遵循既定的提示工程指南和先前关于 LLM 驱动测试 oracle 生成的工作，迭代精炼提示。我们通过检查 GHRB 仓库中对应修正版本的代码变更，人工识别 MUT 和 CUT。由于篇幅限制，提示词从略，但可在补充材料中获取。

II-C 模型

本研究选择两个 LLM：StarCoder 和 GPT-4o，以在提示对测试 oracle 生成的影响方面，比较一个领域特定模型和一个通用模型。选择这些模型是因为它们的流行度，以及 GHRB 基准避免了它们的数据泄漏。

StarCoder（S）（v1.0）是用于代码补全的领域特定 LLM，作为 BigCode 项目的一部分在大型代码语料上训练。它对代码生成的聚焦使其非常适合从测试前缀生成测试 oracle。

GPT-4o（G）（gpt-4o-mini-2024-07-18）是在跨领域多样数据（包括源代码）上训练的通用 LLM，能处理代码生成等任务。纳入 GPT-4o 允许探索提示输入如何影响通用模型中的 oracle 生成，为比较专用与非专用模型的性能提供有用基准。

虽然还有其他先进的推理导向模型（如 GPT-4o1）可用，我们有意选择 StarCoder 和 GPT-4o，因为它们在代码相关任务中有记录在案的有效性。虽然纳入推理聚焦的 LLM 可能提供额外洞察，但使用这些较新模型是否可行仍不确定。GHRB 基准是专门为防止 StarCoder 和 GPT-4o 的数据泄漏而设计的，但并未显式考虑更新的模型。此外，StarCoder 是编码任务的最先进专用模型，而 GPT-4o 常被用作代码生成的基线。

II-D 实验设置

我们实现了一个自动化框架来运行实验。它首先在有缺陷和正确的 GHRB 仓库上运行测试，记录哪些测试失败或通过以确认预期行为。然后它从两个版本的暴露缺陷测试中移除测试 oracle，把无 oracle 的测试连同其他相关信息追加到 LLM 输入。框架把 LLM 生成的 oracle 插入两个版本，编译并运行测试。它检查测试是否编译、哪些通过或失败，并把结果与原始输出比较以评估准确率和正确性。每个实验重复五次以考虑 LLM 输出的变异性。

这一受控配置模拟了如下工作流：一个自动化测试生成器（如 EvoSuite）产出大量无断言测试。EvoSuite 通常生成的断言是复现现有行为的回归 oracle，因此不适合检测当前版本中的缺陷。在我们的设置中，LLM 通过生成新的、可能暴露缺陷的断言来补充这类工具。先前工作（如 TOGLL）已探索过类似的混合流水线。因此，虽然我们的设置是人工的，它紧密贴近 LLM 融入现代自动化测试工作流的一种合理整合方式。

每个实验组合一个 LLM、一种提示技术和一种提示内容。由于 StarCoder 仅支持代码，它支持 zero-shot 和 few-shot 提示。具备 NLP 能力的 GPT-4o 还支持 CoT 和 ToT。这产生总计 2,160 次运行 = 36 个缺陷 × 3 种提示上下文 × (2+4) 种技术 × 5 次重复。

在所有实验中，遵循先前研究，我们把 LLM 温度设为 0、top-p 设为 1。确实，生成代码时较低温度通常更可取。

II-E 指标

我们通过比较「替换 oracle 后的测试输出」与「原始 oracle 的测试输出」（在有缺陷和正确两个版本上）来评估生成测试 oracle 的准确率。为评估正确性，我们测量：

• Accuracy（准确率）：正确区分有缺陷和正确版本的测试——oracle 表现出一致行为（对有缺陷版本正确失败、对正确版本正确通过）的案例数。这是最优结果。
• Buggy Accuracy：在有缺陷版本上正确失败的测试——生成 oracle 正确识别有缺陷版本失败的测试用例数。
• Correct Accuracy：在正确版本上正确通过的测试——生成 oracle 让正确版本相关测试正确通过的测试用例数。
• Compilation Rate（编译率）：生成测试 oracle 能编译的比率。

这些指标评估 LLM 生成 oracle 的准确率和性能，支持跨各种提示配置的比较分析。

III 结果

III-A RQ1 - 输入上下文

表 I 呈现了每种提示内容场景下、全部 36 个缺陷所有实验的平均准确率。我们报告五次运行的平均值，因为观察到的运行间差异极小。结果表明，在提示中提供更多上下文能改进编译率。具体来说，只含测试前缀的提示达到平均 49.36% 编译率，加入 MUT 把该比率提升到 59.23%，纳入 CUT 进一步升到 76.26%。

表 I 还显示，LLM 生成的 oracle 让有缺陷版本正确失败的频率，高于让正确版本正确通过的频率。例如，仅用测试前缀时，有缺陷版本正确失败的时间占 47.78%，而正确版本正确通过占 42.22%。纳入 MUT 后，这两个比率分别升至 53.08% 和 43.85%。纳入 CUT 带来进一步改进：有缺陷版本正确失败率 70.84%，正确版本正确通过率 58.13%。这些发现表明，虽然 LLM 能生成暴露缺陷的 oracle，生成的 oracle 仍可能在正确版本上错误失败，说明一些被识别的「缺陷」可能与预期程序行为不符。

结果显示，加入 CUT 比加入 MUT 带来更大改进。从测试前缀到 MUT，有缺陷版本失败率增加 5.30%，正确版本通过率增加 1.63%。然而从 MUT 到 CUT 的收益大得多：有缺陷失败率增加 17.76%，正确通过率增加 14.28%。这些发现表明，虽然 MUT 提供了一些有用上下文，CUT 提供的信息远更关键，显著增强了 LLM 生成准确测试 oracle 的能力。

考虑总体准确率时，仅用测试前缀生成的测试 oracle 达到 40.74%，加入 MUT 后略降至 40.38%。然而纳入 CUT 带来显著上升，准确率达到 53.64%。测试前缀与 MUT 场景之间变化可忽略，而引入 CUT 时改进 substantial——这强化了结论：提示中更多上下文信息增强了 LLM 生成正确、准确测试 oracle 的能力。这一结果表明，缺乏 CUT 上下文可能阻碍 LLM 对被测代码的理解，降低生成 oracle 的质量。

RQ1 的答案：当提示包含 CUT 时，LLM 更稳定地生成可编译且准确的测试 oracle。

表 I：提示内容比较（RQ1）

III-B RQ2 - 提示工程

表 II 呈现每种提示技术下所有缺陷的平均准确率（五次运行平均，运行间差异极小）。结果表明，few-shot 和 zero-shot 提示技术产生的 LLM 生成 oracle 编译率高于 CoT 和 ToT 技术。具体来说，zero-shot 场景达到 67.38% 编译率，few-shot 场景达到 72.96%，而 CoT 和 ToT 技术的编译率较低，分别为 44.44% 和 44.81%。

数据还揭示，在所有提示技术下，有缺陷版本正确失败的比率都显著高于正确版本正确通过的比率。zero-shot 提示下，该比率从正确版本通过的 57.28% 升到有缺陷版本正确失败的 64.47%。类似地，few-shot 提示下从 55.00% 升到 68.33%。CoT 和 ToT 提示表现出较小但仍 notable 的增长：CoT 从 32.59% 到 38.52%，ToT 从 32.22% 到 41.11%。这些结果与 RQ1 的发现一致，表明 LLM 生成的测试 oracle 可能不完全符合预期行为，导致在有缺陷和正确版本上都失败。

zero-shot 提示达到最高准确率 54.56%，其次是 few-shot 的 51.30%。CoT 和 ToT 的准确率显著更低，分别为 31.11% 和 29.26%。从 zero-shot 到 few-shot 的轻微下降可能源于 few-shot 提示中的示例导致 LLM 偏离预期行为。CoT 和 ToT 的低性能可能源于它们更宽的推理范围，这会导致 LLM 生成处理一般场景而非特定测试前缀的 oracle。

然而，只考虑能编译的 oracle 时：zero-shot 场景准确率 80.97%，few-shot 70.31%，CoT 70.00%，ToT 65.30%。这表明在生成能编译的 oracle 时，CoT 和 ToT 场景虽然准确率仍低于 zero-shot 和 few-shot，但差距并不像原始准确率显示的那么大。因此，除了 CoT 和 ToT 提示的范围过宽问题，一个主要问题是确保 LLM 用这些提示技术产出可编译的 oracle。

RQ2 的答案：与 CoT、ToT 等基于推理的技术相比，LLM 用 zero-shot 和 few-shot 提示技术更稳定地生成可编译且准确的测试 oracle。

表 II：提示技术比较（RQ2）

III-C RQ3 - 模型比较

表 III 显示每个 LLM 用 zero-shot 和 few-shot 提示的平均结果。StarCoder 达到比 GPT-4o 高得多的平均编译率——鉴于 StarCoder 聚焦代码生成（不同于更通用的 GPT-4o），这在预期之内。这限制了 GPT-4o 的性能：平均准确率 49.63%，对比 StarCoder 的 56.31%。在这些提示技术下，StarCoder 在平均 buggy 和 correct 准确率上也优于 GPT-4o。

表 IV 纳入了只用于 GPT-4o 的 CoT 和 ToT 场景（StarCoder 无法使用）。这里我们看到 CoT 和 ToT 提示显著降低了 GPT-4o 的平均编译率和准确率——GPT-4o 的平均编译率和准确率分别降到 51.02% 和 39.54%。

表 III：LLM 比较 - Zero-Shot 与 Few-Shot（RQ3）

表 IV：LLM 比较 - 全部提示（RQ3）

然而，只考虑成功编译的测试 oracle 时，GPT-4o 展示了生成准确 oracle 的竞争力。具体来说，在 zero-shot 和 few-shot 场景下，GPT-4o 可编译测试 oracle 的准确率是 86.45%，对比 StarCoder 的 67.28%。即使纳入 CoT 和 ToT 提示的可编译 oracle，GPT-4o 也达到 77.50% 准确率。虽然低于 zero-shot 和 few-shot 的准确率，这显示了 GPT-4o 在特定条件下可靠生成 oracle 的潜力。

RQ3 的答案：StarCoder 生成的测试 oracle 展示出比 GPT-4o 更高的平均编译率，从而带来更高准确率。

III-D RQ4 - 影响分析

表 V：每种配置的平均结果（RQ4）（Config 表示 LLM.提示策略.输入内容；S=StarCoder，G=GPT-4o，Z=zero-shot，F=few-shot，Ch=CoT，Tr=ToT，T=测试前缀，M=+MUT，C=+CUT）

表 I 显示，包含测试前缀和 CUT 的平均准确率最高（53.64%），包含测试前缀和 MUT 的平均准确率最低（40.38%），极差 13.26%。考虑提示技术，从表 II，zero-shot 准确率最高（54.56%），ToT 最低（29.26%），极差 25.30%。考虑所用 LLM，从表 IV，在使用相同提示技术的情况下，StarCoder 准确率最高（56.31%），GPT-4o 最低（49.63%），极差 6.68%。这些发现表明，提示技术是三者中最显著的因素，因为观察到的结果极差远大于内容和 LLM。其次是提示内容，然后是 LLM。

表 V 对每个场景的平均准确率排名。「Acc. Rank」列给出按「Acc.%」列排序的配置排名。从这一列我们可以计算每个不同组件的平均排名。在进行的 18 个场景中，StarCoder 场景的平均排名是 5.67，GPT-4o 场景是 11.42。zero-shot 的平均排名是 7.17，few-shot 是 7.00，CoT 是 14.33，ToT 场景也是 14.33。仅测试前缀场景的平均排名是 11.17，测试前缀加 MUT 场景是 10.5，测试前缀加 CUT 场景是 6.83。由于 StarCoder 未用 CoT 和 ToT 技术测试，如果移除这六个场景：StarCoder 平均排名 5.67，GPT-4o 7.33，zero-shot 场景 6.17，few-shot 场景 6.83，测试前缀场景 8，测试前缀加 MUT 场景 7.5，测试前缀加 CUT 场景 4.00。

原文图 3 按平均准确率降序排列表 V 的数据。由此我们计算每个因素在 18 个组合中的平均排名。StarCoder 场景排名最高（平均 5.67），其次是带 CUT 的提示（6.83）和 few-shot 提示（7）。相比之下，CoT 和 ToT 的平均排名最低（14.33）。这些结果表明提示技术是最有影响力的因素，因为它在排名中显示最大的性能变化。

我们预期 StarCoder 因代码聚焦训练和未参与 CoT/ToT 提示而位居准确率前列。不含这些场景时，StarCoder 仍优于 GPT-4o（5.67 对 7.33），但 CUT 场景现在排名最高（4），凸显其对生成准确测试 oracle 的重要性。

RQ4 的答案：提示技术对 LLM 生成测试 oracle 的准确率影响最大。

IV 讨论

IV-A 用 CUT 的改进（RQ1）

RQ1 的发现表明，纳入 CUT 显著改进 LLM 生成 oracle 的准确率和编译率。虽然加入 MUT 相比仅测试前缀提升了编译率（可能由于加入的方法上下文），但它导致更低的总体准确率。这表明 MUT 提供的引导有限，而 CUT 提供了准确 oracle 生成所必需的功能上下文和使用模式。

IV-B 提示策略（RQ2）

对 RQ2，显然 zero-shot 和 few-shot 提示场景在所有指标上都优于 CoT 和 ToT 策略。我们把这归因于 CoT 和 ToT 鼓励更宽的推理，这常导致 oracle 包含无关或非预期的行为。这些发现表明，虽然对一般推理有用，这些策略可能阻碍简洁的、行为特定的 oracle 生成。未来工作可以把 CoT/ToT 与和预期行为对齐的 few-shot 示例结合，以平衡推理强度与改进的准确率和编译率。

IV-C 模型特定性能（RQ3）

StarCoder 与 GPT-4o 在 zero-shot 和 few-shot 场景下的比较分析揭示了关键差异。StarCoder 专门在代码上训练，达到比 GPT-4o 更高的准确率和编译率，更稳定地产出可编译代码。然而，尽管编译率较低，GPT-4o 更好地反映预期程序行为。应对这些相反的强弱项，可以结合两个模型的洞察来设计提示技术或混合方法，利用 StarCoder 的编译强度和 GPT-4o 准确行为表示的能力。

IV-D 其他考量（RQ4）

RQ4 的发现表明，整体上使用 StarCoder 给出最准确的测试 oracle。然而 StarCoder 未用 CoT 和 ToT 测试——这两者表现很差，拉低了其他场景的平均准确率。当我们移除 CoT 和 ToT，会看到加入 CUT 对准确率的正面影响大于使用 StarCoder。

从图 3 我们看到，最高平均准确率来自 GPT-4o 配 CUT。RQ3 也显示，对可编译的 oracle，GPT-4o 的平均准确率高于 StarCoder。这在图 3 中很清楚，尤其在 S.Z.C.、S.F.C. 和 S.F.M. 情形中——oracle 编译良好但准确率较低。上下文更多时，GPT-4o 生成比 StarCoder 更准确的 oracle；上下文更少时，StarCoder 表现更好。因此，最佳 LLM 取决于提示的上下文层级。

虽然评估场景是受控的，它对理解提示和上下文如何影响 oracle 合成仍然有用。我们假设缺陷区域已被定位、测试前缀演练了该区域。这一抽象移除了缺陷定位或测试生成等混杂因素，转而聚焦 LLM 补全一个潜在暴露缺陷测试的能力。

IV-E 进一步的 LLM 输出分析

我们人工检查了 StarCoder 的八个和 GPT-4o 的八个测试 oracle 生成子集，以进一步洞察它们的行为。

对 StarCoder，oracle 正确识别有缺陷代码的失败、却错误标记正确代码的情形，倾向于落入两大类：oracle 过度生成和输入上下文不足。关于过度生成，StarCoder 常产出多于必要的 oracle。虽然这组 oracle 可能包含正确的，它也包含由于测试前缀提供的有限上下文而失败的无关 oracle。例如，常见到测试多个无关功能的 oracle。这一局限很可能源于我们实验所用输入提示的狭窄范围。提供更宽的上下文（如整个测试类或套件）可以帮助模型把 oracle 分配给正确的测试用例并改进其相关性。第二个问题涉及输入本身缺乏上下文。当只提供测试前缀时，StarCoder 缺乏足够信息来生成可靠 oracle。没有关于代码目的和用法的足够细节，模型难以创建有代表性的 oracle。图 4 展示了一个 StarCoder 生成的 oracle 因缺失 isSafe 方法而无法编译。

public void testCopyConstructor_noSideEffectOnAttributes() {
    Safelist safelist1 = Safelist.none().addAttributes(TEST_TAG, TEST_ATTRIBUTE);
    Safelist safelist2 = new Safelist(safelist1);
    safelist1.addAttributes(TEST_TAG, "invalidAttribute");

    // 原始 Oracle
    assertFalse(safelist2.isSafeAttribute(TEST_TAG, null, new Attribute("invalidAttribute", TEST_VALUE)));
    // 生成的 Oracle
    assertFalse(safelist2.isSafeTag(TEST_TAG));
}

图 4：缺乏上下文的 LLM 生成 oracle 示例

GPT-4o 常因与 StarCoder 类似的原因让正确代码失败，但也频繁过度复杂化比较。图 5 是一个例子：它不用 assertEquals 比较两个值，而用 assertArrayEquals。这很可能源于 GPT-4o 试图比较整个对象而非仅方法结果，追求基于内容的比较。然而这会导致假阳性和假阴性结果，因为它们比较的对象并非该测试用例本来要比较的。例如，对象的构造器和重写的 equals 方法可能意味着被比较的两个实例被视为相等——尽管测试真正想比较的值不同——从而潜在导致假阳性。反过来，如果被比较对象的 equals 方法未被重写或使用对象引用比较，被比较的两个实例（如果是不同实例）将被返回为不相等，从而导致假阴性。

public void testLazilyParsedNumberDeserialization() {
    LazilyParsedNumber expected = new LazilyParsedNumber("1.5");
    LazilyParsedNumber actual = gson.fromJson("1.5", LazilyParsedNumber.class);

    // 原始 Oracle
    assertEquals(expected, actual);
    // 生成的 Oracle
    assertArrayEquals(new LazilyParsedNumber[]{expected}, new LazilyParsedNumber[]{actual});
}

图 5：过度复杂化的 LLM 生成 oracle 示例

StarCoder 和 GPT-4o 都在生成无法编译的 oracle 上挣扎，主要由于上下文缺失和代码过度生成。当只给测试前缀时，模型缺乏关于方法、参数或期望输出的细节，导致猜测和编译错误。纳入 MUT 有帮助但未完全解决问题，因为它只提供单个方法的上下文。不纳入 CUT 时，让输出与完整测试场景对齐仍然困难。代码过度生成在思维链和思维树提示下尤其如此——模型常添加不必要的测试逻辑。

为解决这些局限，未来工作可以探索提供更全面的提示，例如包含测试类或套件，让 LLM 更清楚地理解更宽的上下文。这可能使模型把 oracle 分配给恰当的测试用例并减少无关测试逻辑的过度生成。此外，确保提示引导 LLM 走向更简单、更直接的断言，可以帮助避免过度复杂的 oracle 逻辑，改进生成测试 oracle 的准确率和可靠性。

V 有效性威胁

数据泄漏。 为降低数据泄漏风险，我们使用 GHRB 数据集，它包含在 StarCoder 和 GPT-4o 训练截止日期之后报告的缺陷，确保模型没见过这些故障。

样本量与泛化。 我们用了从 GHRB 随机选择的 36 个缺陷。这些缺陷的性质可能影响我们的发现，结果可能无法泛化到此样本之外。

暴露缺陷的测试用例前缀。 我们的研究使用已知能暴露缺陷的测试用例前缀。这限制了我们评估 LLM 能否在没有此类前缀、或在正确代码场景中生成有效 oracle 的能力。

缺乏假阳性分析。 我们只评估有缺陷场景。然而在实践中，多数代码是正确的。检查 LLM 是否生成假阳性——在正确代码上错误失败的断言——同样重要。为无缺陷单元评估 oracle 生成是未来工作的一个重要方向。

LLM 输出的随机性。 为考虑 LLM 的非确定性本质，我们对每个参数组合运行提示五次。我们的结果表明这些运行间的方差很低。此外，我们为温度和 top-p 参数使用了固定值。我们承认探索这些参数更宽的值域可能影响结果，并视此为未来工作的一个途径。

提示配置范围。 一个潜在的有效性威胁在于所探索输入提示配置的有限范围。我们只评估了三种场景（仅测试前缀、测试前缀加 MUT、测试前缀加 CUT），排除了其他可能的变体，如移除注释、包含依赖，或只用方法和类签名。这些替代配置可能以我们未捕捉的方式影响 LLM 行为和所得 oracle 生成。因此，我们的发现可能无法完全泛化到不同提示结构。

LLM 选择范围。 最后，我们的研究只评估了每个类别的一个代表性 LLM——一个代码专用（StarCoder）和一个通用（GPT-4o）。这一选择出于可行性原因，也因为 GHRB 数据集是专门为处理与这些模型相关的数据泄漏关切而设计的。未来研究应探索更广范围的 LLM 以评估我们发现的普遍性。

VI 相关工作

自动化单元测试和 oracle 生成是一个已获得显著关注的研究领域。像 EvoSuite 和 Randoop 这样的工具生成带回归断言的测试，而近期方法用神经模型从测试前缀生成断言。由于篇幅限制，本节只凸显关于基于 LLM 的测试和 oracle 生成的关键研究。

用于测试用例/套件生成的 LLM。 近期研究探索了用 LLM 做自动化测试生成，聚焦其有效性、提示设计和局限。Yang 等人发现 LLM 生成的单元测试相比 EvoSuite 编译率和覆盖率更低。Alshahwan 等人引入了部署于 Meta 的 TestGen-LLM，它改进了 11.5% 的测试用例，其中 73% 在生产中被接受。Siddiq 等人分析了 Codex、GPT-3.5 和 StarCoder，凸显代码上下文的影响。Schäfer 等人从代码覆盖率和失败检测方面评估了 LLM 驱动的测试工具 TestPilot。Lops 等人引入 AgoneTest，指出低编译率和提示策略的影响。Ouédraogo 等人发现结构化提示改进了测试质量，但在复杂代码上挣扎。

上述所有研究都聚焦用 LLM 生成完整测试用例。相比之下，我们的研究处理一个更具体的挑战：自动化测试 oracle 生成。这一聚焦有充分理由，因为 oracle 问题是实现完全测试自动化的主要瓶颈之一。通过隔离测试 oracle 生成，我们移除了与测试前缀相关的混杂因素（如覆盖率、代码质量），solely 聚焦测试 oracle 的缺陷检测有效性。

用于测试 oracle 生成的 LLM。 与用 LLM 做测试 oracle 生成相关的研究已显著推进，各种方法探索了 LLM 自动化和改进软件测试过程的潜力。Molina 等人的工作呈现了 LLM 用于测试 oracle 自动化的未来研究路线图。Hossain 等人引入 TOGLL，一个利用 LLM 生成测试断言、同时依赖 EvoSuite 工具生成测试前缀的方法，作者评估了六个不同层级的上下文信息。Hayet 等人引入 ChatAssert，一个基于 LLM 的测试 oracle 生成工具，有两种执行模式：生成和修复。在生成模式中，它用带固定提示的 ChatGPT，提示包含测试前缀中所用方法的摘要，以及来自同一测试文件的其他测试形式的相似示例。Konstantinou 等人研究了 LLM 生成的测试 oracle 是聚焦代码的已实现行为，还是能产出捕捉预期行为的非回归 oracle。作者复用了先前工作（如 TOGLL 和 ChatTester）中表现最好的提示。Zhang 等人从缺陷检测方面调查了基于 LLM 的断言生成性能，作者采用的提示包含测试前缀和 MUT。

我们的研究是同类中的第一项，与先前工作有实质差异。第一，多数先前研究评估单一提示类型，只改变关于 MUT 或 CUT 的固定信息。例外是 Hossain 等人，他们探索了带不同 MUT 上下文层级的多个提示。然而，没有研究检查输入与提示策略两者的组合。第二，我们是第一个把 GHRB 数据集——为减少数据泄漏而设计——用于 oracle 生成的研究，解决了早期基于 Java 研究的一个关键局限。

VII 结论与未来工作

本研究为 LLM 驱动的暴露缺陷测试 oracle 生成提供了一个基线——这是走向可靠 Promptware 的关键一步。我们评估了两个 LLM（StarCoder 和 GPT-4o），跨四种提示技术（zero-shot、few-shot、CoT、ToT）和多种输入上下文（测试前缀、被测方法、完整类）。我们的大规模评估（超过 2,000 次运行）凸显了能帮助改进 FM 时代 oracle 生成的关键挑战和洞察。断言可编译性仍是一个主要障碍；纳入完整类上下文把 oracle 质量改进 12.9%；更简单的提示技术比 CoT 和 ToT 高出 23%；StarCoder 稳定优于 GPT-4o。提示技术成为影响最大的因素。

未来工作应聚焦改进断言可编译性，可能通过静态分析或 LLM 驱动的精炼提示。此外，把结构化推理（如 CoT）与更简单方法（如 zero-shot 或 few-shot）结合的混合提示策略，可能同时改进准确率和可靠性。

致谢

本工作受 ITEA GENIUS 基金（项目编号 23026）支持。

署名与许可：原文 Understanding LLM-Driven Test Oracle Generation，作者 Adam Bodicoat、Valerio Terragni（University of Auckland）、Gunel Jahangirova（King's College London），arXiv:2601.05542v1 [cs.SE]，2026-01-09，AIware 2025（第 2 届 ACM/IEEE AI-Powered Software 国际会议）接收的作者版本。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布。原文地址：https://arxiv.org/abs/2601.05542 。译文中省略了参考文献列表与文内引注编号；图 1、2、4、5 为代码清单已保留，图 3（柱状图）未随 HTML 提供、从略；模型名、工具名、基准名、指标名保留英文。如译文与原文有出入，以英文原文为准。