使用等价类划分和边界值评估大型语言模型生成单元测试的能力_单元测试等价类

Martín Rodríguez 1[0009−0001−2755−3575]{ }^{1[0009-0001-2755-3575]}1[0009−0001−2755−3575], Gustavo Rossi 1[0000−0002−3348−2144]{ }^{1[0000-0002-3348-2144]}1[0000−0002−3348−2144], 和 Alejandro Fernandez 1[0000−0002−7968−6871]{ }^{1[0000-0002-7968-6871]}1[0000−0002−7968−6871]
LIFIA, 计算机科学学院, UNLP, La Plata, 阿根廷

摘要

设计和实现单元测试是一项复杂任务，许多程序员往往忽视。本研究评估了大型语言模型（LLMs）自动生成测试用例的潜力，并将其与手动测试进行比较。开发了一种优化的提示语，将代码和需求集成在一起，涵盖关键案例，如等价类划分和边界值。通过定量指标和人工定性分析，比较了LLMs与经过训练的程序员的优缺点。结果显示，LLMs的有效性依赖于精心设计的提示语、稳健的实现和精确的需求。尽管灵活且有前景，LLMs仍需要人类监督。这项工作强调了手动定性分析作为单元测试评估中自动化的重要补充的重要性。

关键词：评估 $\cdot$ 单元测试 $\cdot$ LLM

1 引言

软件测试是软件开发中的一个基本阶段。它允许在产品进入生产环境之前识别和纠正错误，确保其质量和预期性能。测试自动化通过减少时间和资源优化了这一过程，提供了一致和可重复的结果 [10]。在这一方法中，单元测试起到了关键作用，通过独立评估小代码单元，便于早期修复漏洞并确保每个组件在集成到完整系统前正常工作 [9]。

编写单元测试和识别相关测试用例是一项繁琐的任务。这导致许多程序员完全跳过这一步骤。研究表明，GitHub上的众多项目缺乏测试文件 [6]。缺少单元测试会损害软件质量，加重质量保证团队的工作负担，限制他们执行其他必要检查的能力。面对这一挑战，越来越多地利用大型语言模型（LLMs）进行自动代码生成和测试，以优化流程并减少手动工作量。

AI工具在软件开发中的使用显著增加。在2024年Stack Overflow开发者调查 [18] 中，60,907名开发者中有76%表示他们
计划到2025年在其工作流程中使用或打算使用AI。在34,168名受访者中，关于其在不同领域的影响力，81%预计在代码文档中会有更多整合，80%在测试中，76%在编写代码中。这一趋势也反映在对管理开发团队的企业家的采访中，他们指出开发者希望将重复性任务委托给AI，例如测试创建，然后专注于更具创造性的活动 [12]。此外，他们指出生成更多的代码行并不保证更好的质量；产生清晰、高效的代码并减少错误更为重要。

LLMs有潜力更快地生成单元测试，提高代码覆盖率，识别难以检测的情况，并动态适应源代码的变化。虽然开发人员手动设计、编写和验证每个测试，这些模型可以在几秒钟内生成多个测试用例。这种能力已经在其他上下文中的大规模内容生成中得到证明 [19]，表明它也可以应用于单元测试自动化。随着LLMs在该领域研究的进展，它们与人类专家相比如何的问题仍然悬而未决。本文讨论了LLMs在测试生成中的准确性、一致性和局限性，重点关注两种特定的测试用例选择策略：边界值和等价类划分。

传统上，软件工程师从系统的功能和非功能需求分析中手动设计和编写单元测试，确保软件符合用户的规格和需求。他们创建详细的测试用例，包括输入条件、执行步骤、输出期望和成功或失败标准。有几种识别有效测试用例的策略 [2]。在这项工作中，其中两种特别值得关注：等价类划分和边界值。等价类划分将输入数据划分为具有相似行为的类，通过为每个分区选择一个代表值来减少测试数量。如果一个案例失败，则假定同一类中的其他案例也会失败 [7]。边界值分析补充了这一技术，因为错误通常集中在输入域的边界上 [14]。测试最大值和最小值，包括有效和无效值，以检测边界条件中的故障 [7]。这些策略不仅优化了测试用例的选择，还优先考虑测试质量和有效性，而不仅仅是增加代码覆盖率。尽管简单，这些策略既有效又广泛采用，实践中往往足够具有挑战性，因此值得使用AI辅助。

本文的贡献如下：

1. 一组适用于多种场景的单元测试软件工件。
2. 2. 由专业程序员基于边界值和等价类划分创建的基准测试。
3. 3. 自动化测试生成的LLM提示（基于通用模板）。
4. 4. 对LLM生成的测试与手动开发的测试进行定量和定性比较评估。
5. 5. 对LLMs在测试生成中的优缺点进行批判性讨论。
6. 贡献1至3已公开作为一个Git存储库 [15]，位于La Plata国立大学的数据存储库中。
   本文组织如下：第2节概述了LLMs及其在代码生成中的应用，并将其与软件工程师用于编写单元测试的传统方法进行了比较。此外，回顾了自动测试生成的相关工作，并确定了本研究试图解决的差距。第3节描述了实验设置、工具、参与者和用于比较人工生成测试和LLMs的评估指标。第4节关注定量评估，而第5节则关注定性评估。第6节讨论了研究可能存在的局限性。最后，第7节总结了文章的主要贡献，并提出了未来使用LLMs进行自动测试生成的研究方向。

2 相关工作

Guilherme等人 [8] 使用GPT-3.5-turbo在33个程序上以全自动方式生成单元测试。在他们的研究中，他们设计了一个提示语，请求为整个类生成测试，尝试了不同级别的“温度”。他们使用的提示语仅包含有关测试格式和要求的指示，简要提到边界值的使用，但并未在最终评估中考虑。在本研究中，更严格地处理了等价类划分和边界值的应用，并且通过一个衡量覆盖效率的标准目录评估了结果。

尽管Guilhermes等人的结果显示在代码覆盖率、变异得分和测试成功率方面表现良好，但他们在提示语中没有包含需求规范，这可能是LLMs准确性的关键。本文认为在提示语中包含这样的规范至关重要，以便模型更好地解释上下文，而不依赖于可能存在错误的代码本身。与Guilhermes等人的方法不同，后者不比较自动生成的测试与手动测试，本文认为这种比较是必不可少的。程序员创建的测试可以捕捉到自动化工具可能忽略的问题域的具体细微差别。

Max Schafer等人 [16] 通过TestPilot解决了Guilhermes等人工作中的一些局限性，这是一个使用商业LLMs生成单元测试的工具。在这种情况下，测试针对的是特定函数。除了指定测试格式外，提示语还包括有关函数的详细信息，包括其签名、文档注释、使用示例、源代码和测试框架。如果测试失败，会重新提出请求，结合错误消息和失败的测试以寻求修复。这种方法评估了语句和分支的覆盖率，以及成功率和失败原因。虽然这项工作克服了Guilherme方法的一些局限性，但它仍然没有应用等价类划分和边界值，也没有比较自动生成的测试与手动测试。
有些情况考虑了人类开发者的视角。Siddiq等人 [17] 研究了LLMs在生成软件单元测试方面的有效性，探索了它们理解功能需求并生成相关测试用例的能力。LLM被提供了一个包含类代码（包括导入）的上下文，以及一个提示语，指定了测试文件名称、待测方法（MUT）和生成测试的数量及类型细节。该研究分析了从humanEval数据语料库 [4] 中生成的测试的质量、多样性和覆盖率。与先前的工作不同，它将这些测试与EvoSuite [5] 等技术生成的测试和手动测试进行了比较。然而，与先前的工作一样，它没有考虑测试中的等价类划分或边界值标准。

大多数研究集中于最大化代码覆盖率。然而，Guilherme和他的团队是唯一提到包含边界值的人，尽管只是浅显提及且无具体分析。相比之下，Schafer和Siddiq值得注意的地方在于他们在提示语中包含了程序规范，这使得方法更加详细和扎实。

Siddiq和他的团队是唯一像本工作一样比较了LLMs生成的测试与人类生成的手动测试的人，而其他研究则以不同方式评估测试的有效性。Guilhermes和他的团队通过使用EvoSuite和其他传统工具的参考集进行比较，使用PiTest [3] 进行变异评分和代码覆盖率报告。另一方面，Schafer和他的团队通过Nessie [1] 评估他们的测试所达到的覆盖率，使用诸如istanbul/nyc (https://istanbul.js.org/) 等工具测量语句和分支覆盖率，并通过CodeQL 20 检查是否存在琐碎断言。

本工作旨在结合各种方法以获得更完整和有意义的结果。它依赖于商用通用LLMs生成基于等价类划分和边界值的单元测试的能力，开发了一个包含所有必要信息的提示语，如需求规范和待测代码。此外，所获得的结果与经过培训的开发人员生成的手动测试进行了比较，以验证自动生成测试的效率和质量。

3 实验设计

本文比较了由LLM自动生成的测试与开发人员手动编写的测试的质量，针对一系列特选的软件工件。图1展示了实验的一般设计。

参考技术是Java语言和JUnit框架，用于单元测试自动化。JUnit是Java中最广泛使用的单元测试自动化工具之一，对于采用测试驱动开发（TDD）等方法论起到了基础作用。

选择OpenAI的GPT-4-0613模型作为LLM案例研究，因为它能够处理自然语言和复杂概念，便于根据每个工件的要求生成测试。此外，其API允许

图1. 实验设计概览
灵活集成和快速调整提示语，使实验得以系统化。

需要一套具有代表性的Java工件作为研究等价类划分和边界值的基础。尽管评估了使用之前文献中研究过的软件工件的可能性，但文献分析并未得出合适的候选者。因此，决定开发一套特制的测试工件。

提示语的设计是这类实验的关键阶段。迭代开发了一种提示语模板，直到提示语能产生有效、高效和稳健的测试（图1左侧）。模板以工件的规范和实现作为输入，并返回一个提示语，要求LLM生成测试。使用模板（而不是每个工件一个提示语）旨在获得可推广的结果。同时，熟悉测试用例设计的程序员按照等价类划分和边界值的标准为相同的工件编写测试（图1右侧）。

复制类似研究中使用的评估方法，测试在代码覆盖率、变异得分和坏味道检测方面进行比较。此外，与其他研究不同的是，进行手动定性分析以评估在检测等价类划分、边界值、异常处理等方面的有效性，以及更主观的方面，如代码清晰度。

3.1 待测试工件

在面向对象编程中，方法是最小的可测试单元。一个方法的测试用例搜索空间由方法参数和对象的内部状态（包括所有可能的组合）定义。测试的后置条件（在asserts中控制）由测试后的对象最终状态、方法返回值以及异常的发生与否给出。定义测试用例的人必须在该宇宙中识别等价类划分和边界值。

为了当前的实验，必须有一组软件工件来捕获代表性、非冗余、完整但简单的测试情况。在这项工作中，我们认识到五个场景来评估LLM和开发人员识别和开发测试用例的能力。

1. 单一参数的变化：评估LLM如何检测单一输入的等价类划分和边界值。
2. 2. 两个参数的相关变化：引入复杂性，要求处理两个参数之间的交互，需要在创建分区和选择边界值时的精确性。
3. 3. 单个实例变量的变化：将对象状态引入方程，评估LLM正确定义和实例化对象并考虑内部状态对结果影响的能力。
4. 4. 参数和实例变量的相关变化：结合外部输入和内部状态，增加复杂性。评估LLM是否正确处理这种交互并为两者（和/或相关性）选择正确的边界值。
5. 5. 两个实例变量的相关变化：这是最复杂的场景，两个变量都是内部状态的一部分。检查LLM是否正确处理其随时间的交互并覆盖所有边界值组合。
      此外，对于每个场景，识别出两种变体：一种是程序在两条替代执行路径之间选择，另一种是选择执行一条路径或抛出异常。这允许评估LLM是否覆盖所有执行路径并正确处理异常。

开发了一套特制的软件工件，涵盖了上述10个场景。这些模块化和最小化的工件包含处理输入、输出和异常的方法，具有明确的功能目的，如检查奇偶性、验证密码、操作银行账户或操作集合。除了生成输出外，它们在某些条件下还会抛出异常。

这些场景的源代码被组织在一个Git存储库中。每个场景，从场景01到场景10，都位于命名清晰且一致的文件夹中。在每个文件夹中，包含一个Markdown文件，其中包含其相应的功能规范。

3.2 提示语的迭代开发

本研究中采用的方法旨在使提示语清晰准确，并尽量减少生成测试中的错误。提示语经过特定指令工程设计，并通过反复改进其表述以提高准确性。通过代码覆盖率、变异评分、坏味道检测和定性（手动）分析评估测试套件的质量。

角色提示法被用作提示设计的策略，赋予LLM拥有25年JUnit、等价类划分和边界值测试经验的Java开发者的角色。遵循OpenAI的提示建议，如包含上下文、任务、示例和[11]格式。上下文表明请求者已经实现了类，但没有时间编写测试。任务是通过应用等价类划分和边界值生成JUnit测试，并附带清晰的文档。此外，提供了一个识别这些值和测试应遵循的结构的例子。

提示语包括待测工件的规范和实现，以确保适当的测试。尽管实现并非在早期阶段（如TDD中）必不可少，但它为LLM提供了生成更完整测试的上下文。规范定义了要测试的内容，确保测试验证系统的预期行为。

Git存储库包括一个基础模板（promptTemplate.md），每次迭代都会手动调整，并有一个Python脚本，将模板自动转换为每个工件（实现和规范）的提示语。通过将模板转换为特定提示语，脚本将提示发送到GPT-4 API，并将生成的测试存储在相应文件夹下，格式为ClassNameTest_GPT.java。

主要挑战之一是让模型正确识别等价类划分和边界值，避免无关测试。尽管在某些情况下它可以正确检测，但在其他情况下，即使经过多次提示模板改进，选择中间值的趋势依然存在。经过多次改进后，达到了存储库中包含的版本（并且无法再获得实质性的改进）。

最后，在使用优化后的提示模板运行多次脚本后，随机选择了三次以确保样本无偏（在本文其余部分中，我们将选定的运行分别称为运行1、2和3）。最终集由40个测试类组成：10个手动和30个自动生成（每个场景三个）。存储库分为四个分支：main，包含手动测试，以及branch01、branch02和branch03，记录运行结果。每个API查询都在单独的上下文中执行，以避免场景间的偏差。此外，使用0.3的温度以确保准确性并减少生成代码中的意外变化。

3.3 参与者的选拔与指导

为了手动开发测试（与LLM生成的测试进行比较），邀请了一位在识别等价类划分和边界值方面具有专业知识的开发人员。开发人员得到了具体的指示，以避免偏差并标准化测试，优先考虑质量而非数量。他/她被要求应用等价类划分和边界值的技术，使用JUnit，保持类命名的一致性（classWhichIsTesting_Human.java），并充分记录每个测试。开发人员不是追求最大化代码覆盖率，而是被指示专注于设计系统行为的代表性案例。开发人员可以访问Git存储库。

3.4 指标与评估

为了比较自动生成的测试用例与手动设计的测试用例，我们首先从定量指标开始，这些指标允许客观评估它们的质量。特别是，结合了覆盖率分析、变异测试和自动检测坏味道。覆盖率分析和变异测试的结合不仅能够检测未测试的代码，还能评估测试在识别缺陷方面的有效性。测试气味是指测试中的设计问题，这些问题可能会影响其可靠性。这些问题包括不稳定性、误报或漏报、代码重复和断言中缺乏文档，这些问题会影响检测缺陷的能力。

对于覆盖率分析，我们使用了JaCoCo（https://www.eclemma.org/jacoco/）工具，它测量执行代码的百分比，包括分支覆盖率，以识别未测试和潜在易出错的区域。对于变异测试，我们使用了PIT [3] 工具，它引入有意的代码更改（变异）以评估测试的鲁棒性：如果测试未能检测到变异，变异就会存活下来，表明可能存在弱点；如果测试检测到变异并失败，变异就被认为已被消除。使用TsDetect [13] 来检测测试气味。

定量分析通过作者手动进行的定性分析加以补充，由于其主观性质，这部分分析由作者手动完成。这种分析旨在通过提供更深入的测试性能评估来解决自动化指标的固有限制。融入人类判断有助于识别测试命名和文档中的微妙问题，如可读性、清晰性和一致性。

手动分析的比较标准如下：

• 等价类划分：评估两种方法是否正确识别并覆盖输入分区。
• • 边界值：检查是否测试了每个分区的上下限值。
• • 异常处理：分析是否适当考虑了超出范围或无效值的异常。
• • 数值不准确：评估是否正确处理了double或float等数据类型的精度误差（例如，assertEquals中使用delta）。
• • 代码结构：检查测试代码组织的清晰性和一致性。
• • 一致且描述性的名称：确保测试类反映了被测试功能，方法名称清楚表达被测试的行为。
• • 文档：审查是否包含有助于理解测试的注释和文档。

4 定量评估

分析覆盖率测试结果（表1），GPT生成和手动测试在所有评估场景中均达到$100\%$分支覆盖率。这表明所有等价类划分都被正确识别并执行。然而，Run 1中的场景06因调用不存在的’setValue’方法出错，导致覆盖率仅为$0.0\%$，阻止了测试运行。

在线覆盖率方面，某些场景未达到$100\%$，如Run 1中的场景06，仅执行配置和’setUp’行，未覆盖功能代码。然而，在其他情况下，较低的覆盖率并非负面，而是源于排除了如上下文之类的类，这对评估逻辑而言并不重要。例如，在场景02中，主要逻辑位于’passwordStrategy’策略中，测试集中于此，忽略了上下文。

观察到，在场景01至04中，GPT不必要地包含上下文，导致因隔离错误达到$100\%$覆盖率。相反，手动测试和Run 1和Run 3中的场景04避免测试上下文，专注于策略，从而减少了行覆盖率。这不影响分支覆盖率，因为上下文不含分支。

场景 Run 1 Run 2 Run 3 手动 分支覆盖率 行覆盖率 分支覆盖率 行覆盖率 分支覆盖率 行覆盖率 分支覆盖率 行覆盖率 01 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $50\%$ 02 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $33.3\%$ 03 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $73.3\%$ 04 $100\%$ $69.2\%$ $100\%$ $100\%$ $100\%$ $69.2\%$ $100\%$ $69.2\%$ 05 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 06 $0.0\%$ $75\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 07 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 08 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 09 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 10 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$

表1. 每次运行和场景的分支和行覆盖率分析。

表2中的变异测试结果分析显示，在大多数场景中，GPT生成和手动测试均达到$100\%$变异覆盖率，表明所有可能的代码变异都被检测并适当处理。

然而，有些运行未生成变异，因为PIT仅在所有测试无错误完成时才执行变异。在此背景下，四个GPT测试
存在问题：Run 1中的场景06已经提到，还有三个由于浮点值比较错误。

此外，在场景01至04中，手动测试由于上下文类覆盖率不足而显示较低百分比，正如JaCoCo结果所示。尽管如此，其他情况下的$100\%$覆盖率表明每个变异至少被测试一次，表明测试在检测代码中的意外变更方面有效且可靠。

场景 Run 1 Run 2 Run 3 手动 行覆盖率 变异覆盖率 行覆盖率 变异覆盖率 行覆盖率 变异覆盖率 行覆盖率 变异覆盖率 01 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $50\%$ $63\%$ 02 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $33\%$ $63\%$ 03 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $73\%$ $88\%$ 04 $69\%$ $89\%$ $100\%$ $100\%$ $69\%$ $78\%$ $69\%$ $88\%$ 05 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 06 - - $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 07 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 08 $100\%$ $100\%$ - - - - $100\%$ $100\%$ 09 $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ 10 - - $100\%$ $100\%$ $100\%$ $100\%$ $100\%$ $100\%$

表2. 每次运行和场景的行和变异覆盖率。

测试气味分析识别了测试代码中的不良气味，检查了21种类型，其中四种被检测到：断言轮盘（测试方法包含多个没有文档的断言，影响可读性并使识别缺陷变得困难）；通用装置（测试装置过于通用且仅在测试方法中部分使用）；魔法数字测试（在断言中使用数值字面量而无上下文，使其难以理解和维护代码）；重复断言（一个测试在单个方法中多次检查相同条件，产生冗余）。

结果如表3所示。断言轮盘在GPT生成和手动生成的测试中都被检测到，表明这是一个反复出现的问题。通用装置在两次手动测试中被报告，其中’setUp’方法在所有测试中实例化未使用的字段。魔法数字测试在GPT和手动测试的所有场景中都被发现，表明这是一个常见问题。重复断言在两个GPT运行的同一场景中被识别，表明自动测试生成的一个趋势。

5 定性评估

两种方法（自动和手动）都能正确识别等价类划分。然而，手动分析揭示了边界值处理的差异。总体而言，手动测试倾向于更加详尽，使用尽可能接近每个分区边缘的值，这使得对系统的验证更加准确。另一方面，GPT生成的测试倾向于使用

场景 断言轮盘 通用装置 魔法数字测试 重复断言 B1 B2 B3 Man B1 B2 B3 Man B1 B2 B3 Man B1 B2 B3 Man 01 2 0 2 1 0 0 0 0 4 4 2 3 0 0 0 0 02 0 0 2 0 0 0 0 0 3 3 3 2 0 0 0 0 03 0 0 0 2 0 0 0 3 3 3 3 3 0 0 0 0 04 0 0 0 0 0 0 0 3 3 3 3 3 0 0 0 0 05 3 2 1 2 0 0 0 0 4 4 4 4 1 0 1 0 06 0 0 0 0 0 0 0 0 5 5 5 4 0 0 0 0 07 3 3 4 2 0 0 0 0 3 3 4 4 2 0 0 0 08 4 4 5 2 0 0 0 0 4 4 5 2 0 0 0 0 09 3 2 4 2 0 0 0 0 3 4 4 2 0 0 0 0 10 5 3 3 2 0 0 0 0 5 3 3 2 0 0 0 0

表3. 自动运行和手动分析之间的不良气味比较。
分区内的代表性值，通常位于范围的中间，这提供了可接受的覆盖率，但不能准确捕捉到立即边缘的情况。这一差异很重要，因为接近边缘的值可能会产生与中心值不同的行为，突出了适当覆盖率的重要性。

在某些情况下，当GPT测试边界值时，由于微小的小数差异，浮点数比较中检测到失败。这些错误源于断言中缺乏适当的容差（delta），这是避免浮点计算不准确的重要实践。相比之下，手动测试不会遇到浮点值问题，因为它们避免直接比较这种格式，而GPT生成的测试则不然。这揭示了方法上的差异：手动测试更窄且精确，而GPT测试覆盖范围更广。例如，GPT测试低于、等于和高于边缘的值，而手动测试仅关注等于和高于边缘的值。因此，手动测试优先考虑准确性而非数量，避免不必要的案例并提高效率。

在场景01至04中，GPT生成的测试并不总是直接测试实现逻辑的类，而是实例化带有策略的上下文类（这些场景是策略设计模式的实现）。虽然这确保了足够的覆盖率并评估了等价类划分和边界值，但并没有遵循单独测试每个类的良好实践。上下文类协调策略，而主要逻辑位于策略类中，因此单元测试必须专注于每个类的独立性。GPT在某些情况下实现了这一点，但不一致，而手动测试在所有场景中都是准确的，确保了更严格的验证并与良好实践一致。

两种方法在测试类和方法名称上保持一致性，便于识别测试功能。例如，在BankAccount测试中，手动和GPT生成的测试都使用BankAccountTest这样的名称。

两种方法在结构上都有清晰的代码，但手动测试遵循更有组织的模式，有更好的分离和分类案例。相比之下，GPT测试可能会包含冗余或将测试分组得令人困惑
的方式，使得理解和检测错误变得困难。因此，尽管两种方法都有结构，但手动测试因其更高的清晰度和组织性而脱颖而出。

两种方法都能正确处理异常，但手动测试通过使用assertEquals验证异常发生和确切消息，确保严格验证，特别是在消息至关重要的情况下。相比之下，虽然检查异常时，GPT生成的测试并不总是准确比较消息。当它们这样做时，它们使用更多步骤，如中间变量和assertTrue与contains，这提供了灵活性但降低了严谨性并可能引入不必要的复杂性。

两种方法都很好地记录了测试，有解释其目的和验证的注释。然而，一些由GPT生成的测试缺乏注释，尽管这似乎是一个孤立的错误，因为模型通常生成适当的文档。尽管有这些偶尔的遗漏，大多数自动生成的测试中的注释都是准确的并履行了其解释功能。

图2. 手动定性分析比较

6 有效性线程

用于评估生成集的指标包括代码覆盖率、变异分数和坏味检测，所有这些指标在以前的研究中都已被使用，支持其有效性。然而，手动定性分析并未在类似研究中使用，因此被纳入。这种方法允许识别自动化指标可能遗漏的方面，但也引入了人类解释固有的可能主观偏差。尽管这种偏差被最小化，但仍构成定性分析的局限性。

尽管这种方法的结合允许对测试质量进行更全面的分析，但某些测试效果的方面可能尚未完全捕捉到。未来的研究可以探索额外的指标或更具体的准则，以加强结果的有效性。

通过表格和统计分析手动获取的指标数据，允许对评估的不同方法进行结构化比较
评估。未发现所用指标中的任何不一致或重大变化，表明结果稳定。

这项研究基于10个场景，这限制了结果的普遍性。选择较小的集合允许进行更详细的手动分析，但这意味着研究结果可能无法推广到更大的测试集或其他领域。

此外，结果仅限于Java语言和JUnit测试框架，因此其在其他语言和工具中的推论并不保证。具有不同范式的语言，如Python的pytest或JavaScript的Jest，可能需要方法论调整。

评估的场景集中在等价类划分和边界值上，未涉及其他策略，如结构性、功能性、基于错误或组合测试。这可能会影响研究结果在需要更广泛测试技术覆盖的情境中的适用性。尽管所使用的LLM在这些场景中没有遇到代码结构方面的困难，但尚未在其他环境中进行测试，以评估其在不同软件架构或测试类型上的表现。

7 结论和未来工作

本文介绍了使用GPT-4 API进行自动单元测试生成的初步研究。它评估了通过识别等价类划分和边界值生成高质量测试用例的能力。结果显示，在一种情况下，LLM在无人工干预的情况下无法生成可执行测试。同时，在三个场景中，由于浮点和双精度类型断言的不准确而出现错误。总体而言，手动和自动化测试的覆盖率、质量和坏味指标相似。然而，手动定性分析是检测自动化分析可能遗漏方面的关键。

基于观察到的结果，我们认为LLM无法完全自主地编写单元测试；它仍然需要人类监督。然而，具备扎实技术知识的测试人员可以通过精确指示引导LLM生成有效的测试。这表明，未来测试人员可以专注于设计提示和脚本，将测试代码生成委托给人工智能，从而减少对高级技术技能的需求。

未来工作的方向可以探索LLM分析和纠正自身错误的能力，并评估其自我调整能力。还可以研究提示语言对测试质量的影响，考虑某些语言在训练数据中具有更高的代表性。此外，建议探索采样温度（本研究中为0.3）对生成测试的准确性和创造性的影响。

参考文献

1. Arteca, E., Harner, S., Pradel, M., Tip, F.: Nessie: 自动化测试JavaScript API的异步回调。在：2022 IEEE/ACM 第44届国际软件工程会议 (ICSE)。pp. 1494-1505 (2022). https://doi.org/10.1145/3510003.3510106
2. 2. Basili, V., Selby, R.: 比较软件测试策略的有效性。IEEE 软件工程学报 SE-13(12), 1278-1296 (1987). https://doi.org/10.1109/TSE.1987.232881
3. 3. Coles, H., Laurent, T., Henard, C., Papadakis, M., Ventresque, A.: Pit: Java的实用变异测试工具 (演示)。在：第25届国际软件测试与分析研讨会论文集。p. 449-452. ISSTA 2016, 计算机协会, New York, NY, USA (2016). https://doi.org/10.1145/2931037.2948707, https://doi.org/10.1145/2931037.2948707
4. 4. Du, X., Liu, M., Wang, K., Wang, H., Liu, J., Chen, Y., Feng, J., Sha, C., Peng, X., Lou, Y.: 在类级代码生成中评估大型语言模型。在：IEEE/ACM 第46届国际软件工程会议论文集。ICSE \'24, 计算机协会, New York, NY, USA (2024). https://doi.org/10.1145/3597503.3639219, https://doi.org/10.1145/3597503.3639219
5. 5. Fraser, G., Arcuri, A.: Evosuite: 面向对象软件的自动测试套件生成工具。在：第19届ACM SIGSOFT研讨会和第13届欧洲软件工程基础大会论文集。p. 416-419. ESEC/FSE \'11, 计算机协会, New York, NY, USA (2011). https://doi.org/10.1145/2025113.2025179, https://doi.org/10.1145/2025113.2025179
6. 6. Gonzalez, D., Santos, J.C.S., Popovich, A., Mirakhorli, M., Nagappan, M.: 关于维护属性测试模式的大规模研究（易于修改、诊断和理解的模式）。CoRR abs/1704.08412 (2017), http://arxiv.org/abs/1704.08412
7. 7. Graham, D., van Veenendaal, E., Evans, I., Black, R.: 软件测试基础：ISTQB认证。Cengage Learning, Boston, 第1版 (2008)
8. 8. Guilherme, V., Vincenzi, A.: ChatGPT单元测试生成能力的初步研究。在：Fontão, A.L., Paiva, D.M.B., Borges, H., Cagnin, M.I., Fernandes, P.G., Borges, V., Melo, S.M., Durelli, V.H.S., Canedo, E.D. (编) 第8届巴西系统化和自动化软件测试研讨会，SAST 2023, Campo Grande, MS, Brazil, September 2529, 2023. pp. 15-24. ACM (2023). https://doi.org/10.1145/3624032.3624035, https://doi.org/10.1145/3624032.3624035
9. 9. Koomen, T., Pol, M.: 测试过程改进：结构化测试的实践分步指南。Addison-Wesley Longman Publishing Co., Inc., USA (1999)
      10.10. Gómez del Mónaco, A.P.: Web应用中的自动化测试：国际旅游企业案例。博士论文，拉普拉塔国立大学 (2021), http://sedici.unlp.edu.ar/handle/10915/123972, 访问日期: 2024-11-05
10. OpenAI: 提示工程 (2024), https://platform.openai.com/docs/guides/promptengineering, 访问日期: 2024-10-31
11. 12. Overflow, S.: Gen-AI和LLMs如何帮助开发者编写软件测试 (2024), https://stackoverflow.blog/2024/09/10/gen-ai-llm-create-test-developers-coding-software-code-quality/, 访问日期: 2024-10-11
12. 13. Peruma, A., Almalki, K., Newman, C.D., Mkaouer, M.W., Ouni, A., Palomba, F.: TsDetect: 开源测试气味检测工具。在：第28届ACM欧洲软件工程会议和软件工程基础研讨会论文集。p. 1650-1654. ESEC/FSE 2020, 计算机协会, New York, NY, USA (2020). https://doi.org/10.1145/3368089.3417921, https://doi.org/10.1145/3368089.3417921
13. 14. Pressman, R.S.: 软件工程：实用方法。McGraw-Hill, 第6版 (2005)
14. 15. Rodriguez, M.E.: 数据集用于评估LLMs在边界值和等价类划分测试生成中的表现 (2025). https://doi.org/10915/datasetSJL5HU, https://datos.unlp.edu.ar/citation?persistentId=perma:10915datasetSJL5HU
15. 16. Schäfer, M., Nadi, S., Eghbali, A., Tip, F.: 使用大型语言模型进行自动化单元测试生成的经验评估 (2023), https://arxiv.org/abs/2302.06527
16. 17. Siddiq, M.L., Da Silva Santos, J.C., Tanvir, R.H., Ulfat, N., Al Rifat, F., Carvalho Lopes, V.: 使用大型语言模型生成JUnit测试：一项经验研究。在：第28届国际软件工程评估与评估会议论文集。EASE 2024, 卷25, p. 313-322. ACM (2024年6月). https://doi.org/10.1145/3661167.3661216, http://dx.doi.org/10.1145/3661167.3661216
17. 18. Stack Overflow: AI | 2024 Stack Overflow 开发者调查 (2024), https://survey.stackoverflow.co/2024/ai, 访问日期: 2025-03-29
18. 19. Tamkin, A., Brundage, M., Clark, J., Ganguli, D.: 理解大型语言模型的能力、局限性和社会影响 (2021), https://arxiv.org/abs/2102.02503
19. 20. Youn, D., Lee, S., Ryu, S.: 使用CodeQL进行多语言程序的声明性静态分析。软件：实践与经验 53(7), 1472-1495 (2023年7月). https://doi.org/10.1002/spe.3199, https://onlinelibrary.wiley.com/doi/10.1002/spe.3199 , 出版商: Wiley
        参考论文：https://arxiv.org/pdf/2505.09830