ChatUniTest: a ChatGPT-based automated unit test generation tool
Zhuokui Xie1, Yinghao Chen1, Chen Zhi1, Shuiguang Deng1, Jianwei Yin1
1 Zhejiang University, Hangzhou, China
引用
Xie Z, Chen Y, Zhi C, et al. ChatUniTest: a ChatGPT-based automated unit test generation tool[J]. arXiv preprint arXiv:2305.04764, 2023.
论文：https://arxiv.org/abs/2305.04764
仓库：https://github.com/ZJU-ACES-ISE/ChatUniTest
摘要
单元测试在软件开发中至关重要，但常显繁琐耗时。为减轻开发人员负担，已有自动生成技术，如EvoSuite和Randoop，但其测试可读性差、断言有限。本文介绍了ChatUniTest，基于ChatGPT，采用生成-验证-修复框架。ChatUniTest通过解析项目、提取基本形态，创建自适应焦点上下文，生成测试，使用ChatGPT生成原始测试。评估显示，ChatUniTest优于EvoSuite，超过AthenaTest和A3Test，并有效生成断言，利用模拟对象和反射实现测试目标。
1 引言
背景。在当今世界，软件的广泛应用和复杂性日益增加，即使是微小的缺陷也可能给大型企业带来重大的经济损失和声誉损害。因此，软件测试在软件开发生命周期中的作用日益关键，其目标是确保产品在交付前具备高质量的软件。软件测试的基本组成部分是单元测试，即对单个代码单元进行测试。单元测试有助于开发人员在开发过程中尽早发现缺陷和错误，从而降低整体开发成本。此外，单元测试还有助于提高软件应用程序的可维护性和可扩展性，使其更易于未来进行修改和扩展。然而，手动编写单元测试需要大量的时间和精力，因此常常被开发人员所忽视。
为了解决这一问题，人们开发了自动单元测试工具，以减轻开发人员编写简单但繁琐的单元测试的负担。这些工具旨在生成调用JUnit和Mockito中测试 API 的单元测试，以尽可能广泛地覆盖被测代码，从而通过单元测试捕捉程序中的大部分缺陷。自动单元测试生成工具可以分为两个主要方向：传统单元测试生成工具和深度学习单元测试生成工具。EvoSuite 是一种传统的单元测试生成工具，它使用进化算法生成新的测试用例，并通过适应度函数指导搜索过程，以实现高代码覆盖率标准，如分支覆盖率和行覆盖率。然而，EvoSuite生成的单元测试与人类编写的测试在本质上存在差异，因此难以阅读和理解。AthenaTest是一款基于深度学习的工具，它在英语和代码语料库上对BART模型进行预训练，并在Methods2Test数据集上进行微调。它试图直接将源代码转化为单元测试。A3Test在AthenaTest的基础上进行了改进，纳入了断言知识并验证了命名一致性和测试签名，在正确性和方法覆盖率方面取得了更好的结果。然而，这两种基于深度学习的先进工具都存在局限性，因为它们无法通过与深度学习模型的交互来修复简单错误，导致生成的大多数测试都是不正确的。ChatGPT的出现可能会改变这一现状。
动机。 ChatGPT 在多个领域展示了其能力，包括生成单元测试。然而，我们的初步分析显示，尽管 ChatGPT 有时能够生成清晰易懂的单元测试，但在许多情况下无法完成生成过程。此外，仅有不到 20% 的成功回复能够生成正确的单元测试。为了深入了解这些问题，我们对生成过程进行了检查，并发现了两个关键的局限性。首先，ChatGPT 受到标识符数量的限制（例如 GPT-3.5 的 4096 个标识符），这些标识符包括提示和补全。这一限制限制了 ChatGPT 获取生成有效回复所需的全部相关信息。我们建议采用根据测试单元自适应生成上下文的方法，以缓解这一限制。其次，如果缺乏适当的编译器和测试执行器，ChatGPT 将无法验证生成的单元测试，这导致了各种错误，包括编译时的“找不到符号”和运行时的“断言失败错误”（AssertionFailedError）。其中一些错误可以通过进行几轮连续验证和微小修改来纠正。我们建议在ChatGPT中引入验证组件和修复组件，这将大大提高ChatGPT生成单元测试的效率。
方法。在初步分析的基础上，我们采用了生成-验证-修复框架，开发了ChatUniTest1。为了解决第一个限制，我们将测试单元定义为方法，并设计了一种自适应焦点上下文生成机制。该机制旨在生成包含焦点方法所需尽可能多信息的上下文，并同时为ChatGPT生成完整响应留出足够的空间。针对第二个限制，我们实施了验证组件和修复组件。验证组件包括解析器、编译器和测试执行器。而修复组件则包括基于规则的修复和基于ChatGPT的修复。基于规则的修复能够解决简单的错误，例如语法错误和缺少的导入语句。如果基于规则的修复无法成功，ChatUniTest将采用基于ChatGPT的修复方法。在这种情况下，它会构建一个提示，其中包含错误信息、有问题的单元测试以及自适应焦点上下文，以便从ChatGPT中获取修正后的单元测试。如果一个测试在经过几轮验证和修复后仍未修复，那么它将被标识为废弃。
评估结果。在实验中，我们旨在验证ChatUniTest的有效性。结果显示，在30%的尝试中，ChatUniTest成功生成了正确的测试。在10个项目中，有7个项目的分支覆盖率和8个项目的行覆盖率超过了EvoSuite。相较于AthenaTest，ChatUniTest表现出了卓越的性能，其测试正确率与A3Test相当。此外，在焦点方法覆盖率方面，ChatUniTest取得了令人瞩目的成绩，达到了79.67%，远高于AthenaTest（43.75%）和A3Test（46.80%）。在Defects4J Lang-1-f修订版中的NumberUtils类别的18个方法中，ChatUniTest在16个方法上表现出色，在方法行覆盖率方面也显示出显著优势，相比之下，AthenaTest和A3Test则略显不足。
贡献。本文介绍了基于ChatGPT的自动单元测试生成工具 ChatUniTest，它在以下方面做出了显著贡献：
ChatUniTest是首个基于ChatGPT的自动单元测试生成工具，在分支覆盖率和行覆盖率方面优于EvoSuite。此外，在焦点方法覆盖率和方法行覆盖率方面，它也超越了 AthenaTest 和 A3Test。ChatUniTest引入了自适应焦点上下文生成算法，能够灵活生成具有所需上下文的提示，同时保持在最大提示标识符限制范围内，从而避免了ChatGPT的截断式响应。ChatUniTest利用其基于规则的修复组件有效修复单元测试中的语法错误和简单编译错误。此外，通过与ChatGPT进行交互，基于ChatGPT的修复组件还能够解决约 50% 的困难问题。2 技术介绍
如前所述，ChatGPT在生成单元测试时面临两个限制：标识符限制以及缺乏验证和修复组件。本节将概述ChatUniTest的设计，并解释它如何克服这些限制，从而促进高质量单元测试的自动生成并提高成功率。
图1展示了 ChatUniTest 的概览，它采用了“生成-验证-修复”框架。为了实现并行化，ChatUniTest 首先需要进行一些预处理，包括项目分析、Java文件解析和必要信息的提取，以便在生成过程中使用。焦点方法的生成需要以下组件：
图1：ChatUniTest整体工作流程
生成：在生成阶段，ChatUniTest 根据焦点方法和预定义的最大提示标识符限制生成自适应焦点上下文。然后，它将上下文渲染成提示标识符，并从ChatGPT获取响应。验证：在验证阶段，ChatUniTest 从 ChatGPT 的响应中提取一个测试，并检查其是否存在语法错误、编译错误或运行时错误。修复：在修复阶段，ChatUniTest 尝试使用基于规则的修复来解决单元测试中的简单错误。如果错误仍然存在，ChatUniTest 将采用基于 ChatGPT 的修复方法来解决。2.1 预处理
为了简化和并行处理整个过程，对被测项目进行预处理是必要的。ChatUniTest首先会遍历项目文件夹，找到所有的Java文件，然后将每个类文件解析为抽象语法树（AST）。在遍历AST时，ChatUniTest收集两个层次的信息：类级别和方法级别。
类级别的信息包括包、导入、类签名、字段以及方法签名。而方法级别的信息包括方法主体、字段访问、getter/setter调用、依赖类名称以及方法调用（例如 max(byte,byte,byte)）。
2.2 生成
生成组件的目的是生成自适应焦点上下文，并将其整合到提示语中，同时确保提示语的长度保持在最大提示语块的限制范围内，以确保 ChatGPT 有足够的空间生成完整的回答。我们提出了一种自适应焦点上下文生成算法，详见算法1。为清晰起见，表1中提供了缩写词。
表1：缩略语表
算法1：自适应焦点语境生成
ChatUniTest 首先会验证是否能将所需上下文转化为满足最大提示标识符限制的提示。如果不能，ChatUniTest 将终止进程，因为缺少所需上下文信息会导致单元测试无效。接着，ChatUniTest 会尝试按照重要程度向当前上下文添加更多信息，同时验证每个新添加的信息是否符合最大提示标识符限制。对于具有依赖关系的方法，依赖类签名、依赖类构造函数和调用方法签名将被添加到上下文中，以更好地理解如何实例化依赖类、在不出现编译错误的情况下调用其方法，并提供返回类型信息。对于没有依赖关系的方法，ChatUniTest 会考虑添加焦点方法调用的方法签名，因为它提供了参数类型和返回类型信息。如果标识符限制允许，ChatUniTest 会尝试将焦点类内的所有方法签名添加到上下文中，以全面了解方法的作用和目的。
在生成自适应焦点上下文后，ChatUniTest 将其渲染为提示语。如果上下文中没有依赖类信息，则采用图2中的提示模板；如果存在依赖类信息，则使用图3中的模板。成功生成的提示标识符符合最大提示标识符限制，并通过 OpenAI 的 API 发送给 ChatGPT。
图2：无依赖性的焦点方法提示语
图3：有依赖关系的焦点方法提示语
2.3 验证
收到ChatGPT的响应后，ChatUniTest将提取并验证测试。如果在验证过程中发现任何错误，则会选择不同的修复组件。
摘录：在初步分析中，我们发现 ChatGPT 有时无法满足提示中列出的所有要求，即使在明确指示“无需解释”的情况下也是如此。因此，我们开发了两种通用方法来从响应中提取测试。测试通常以两种格式提供：以三重回车键分隔的或不带分隔符的纯代码。对于前一种格式，ChatUniTest使用正则表达式来识别以三重回车键分隔的字符串，并过滤掉没有“@Test”注释的代码片段。对于后一种格式，ChatUniTest 会查找响应中包含关键字“public *Test”的行，并尝试通过验证行中的第一个字符是否在 Java 语法中有效来确定测试边界。如果 ChatUniTest 无法从 ChatGPT 的响应中提取任何测试，整个过程就会立即终止。
解析：一旦成功提取测试，ChatUniTest 将使用 Java 解析器验证测试的语法。如果在此阶段检测到语法错误，ChatUniTest 将将测试转发给基于规则的修复组件进行更正。
编译和运行： 接下来，在编译和运行阶段，ChatUniTest 将编译并执行测试。如果测试编译失败或在执行过程中遇到错误，则会进入修复流程。只有在没有语法错误、编译成功且运行无误的情况下，测试才算通过。
2.4 修复
图 4：修复错误提示语
在整个过程中，ChatUniTest 努力修复验证过程中检测到的任何错误。修复组件分为两部分：基于规则的修复和基于 ChatGPT 的修复。基于规则的修复组件侧重于纠正简单和常见的错误，无需使用任何标识符，而基于 ChatGPT 的修复组件则针对需要修改代码结构的更复杂和更具挑战性的错误。修复成功后，测试将被发送到验证组件，以进一步验证其正确性。
语法修复：当从 ChatGPT 的响应中提取测试时，可能会因超过 4096 个字节的限制而导致语法错误，使得测试被截断。在这种情况下，ChatUniTest 将执行语法修复方法。首先，它会识别最后一个分号或结尾大括号，并添加必要的结尾大括号，以确保开头大括号的数量平衡。然后，ChatUniTest 将验证测试的语法正确性。如果第一种方法失败，ChatUniTest 将尝试删除最后一个测试，方法是找到“@Test”注释，截断注释前的代码，然后添加结尾大括号以完成测试结构。如果修复过程失败或删除后没有测试，整个过程将终止。
Imports 修复：从 ChatGPT 获取的大量原始测试可能会导致编译错误，如“找不到符号”（cannot find symbol）。为解决此问题，ChatUniTest 将执行导入修复，以确保焦点类中的依赖关系存在于测试中。
ChatGPT修复：如果基于规则的修复无法纠正错误，ChatUniTest将采用基于ChatGPT的修复。ChatUniTest将提取有关错误类型和信息的信息，并结合焦点方法上下文，通过将信息渲染到提示模板中生成提示。但有些错误信息可能冗长而繁琐，导致提示超过最大提示限制。在这种情况下，ChatUniTest将尝试截断错误信息，以确保提示不超出限制。如果提示仍超出限制，或者测试在六轮后仍无法修复，整个过程将终止。
3 实验评估
3.1 实验设置
在实验中，ChatUniTest 被配置为在六次尝试内为每个焦点方法生成单元测试，同时将最大轮数限制为六轮。如果提示标识符上限超过2700，尝试将被中止。此外，如果尝试未能在六轮内生成通过的测试，则该尝试将被废弃。GPT-3.5-turbo 模型的温度将设置为 0.5，以生成多样化的单元测试。
为了评估 ChatUniTest 的有效性，我们提出了四个研究问题：
问题 1：生成的测试用例质量如何？
为了解决这个问题，我们将使用 ChatUniTest 为表2中列出的十个 Java 项目自动生成单元测试。我们将使用 Cobertura和 Jacoco来测量测试覆盖率。这些项目不仅涵盖了广泛的领域，如实用程序、中型软件和分布式计算平台，还涵盖了各种 Java 版本，包括 Java 11 和 Java 17。值得注意的是，ChatGPT 的训练数据中排除了五个选定项目，因为它们是在 2021 年12月1日之后创建的，以防止可能的数据泄露。
在评估生成测试用例的质量时，我们考虑了几个因素，例如：
语法正确性：语法正确性是指测试代码是否遵守 Java 语法规则，我们将使用 Java 解析器来验证。编译正确性：如果测试在使用 Java 编译器编译时未产生任何错误，则视为编译正确。通过：我们将使用 JUnit 作为测试执行器来验证测试是否通过，这意味着测试在执行过程中不会产生任何运行时错误。测试应用程序接口的调用：写好的单元测试用例应通过调用测试应用程序接口来验证 MUT 的预期行为。例如，测试用例应使用 JUnit Assert API（如 assertEqual()、assertTrue()）来检查 MUT 的返回值，并使用 Mockito Framework API（如 mock()、verify()、when()）来模拟外部延迟的行为。正确：我们将语法准确、编译和运行无误、调用被测方法、包含断言并能使目标代码通过测试的测试定义为正确。问题 2：ChatUniTest 的性能与 EvoSuite、AthenaTest 和 A3Test 相比如何？
在这一研究问题中，我们将ChatUniTest与其他三种方法进行了比较：EvoSuite（基于程序分析的测试生成）、AthenaTest（基于语言模型的测试生成）和A3Test（基于语言模型的测试生成）。我们在十个Java项目（见表2）中根据分支和行覆盖率对ChatUniTest和EvoSuite进行了比较评估。
为了比较ChatUniTest、AthenaTest和A3Test，我们使用了Defects4J数据集。具体来说，我们首先比较它们在Defects4J Lang-1-f修订版中对NumberUtils类的方法行覆盖率。然后，我们将比较它们在整个Defects4J数据集中的测试用例正确率和焦点方法覆盖率。
正确测试百分比：正确测试百分比表示在所有尝试中正确编写测试的百分比。重点方法覆盖率：重点方法覆盖率表示在生成单元测试时所覆盖的重点方法的百分比。如果一个重点方法在给定的尝试中被正确测试，则认为该方法已被覆盖。表2：项目数据集
问题 3：ChatUniTest 不同组件的贡献是什么？
在这个研究问题中，我们将 ChatUniTest 分成三个部分，并分别评估它们对整个测试用例的贡献。我们根据测试正确率和方法代码覆盖率来评估它们的贡献。
问题 4：生成单元测试的成本是多少？
对于这个研究问题，我们的目标是深入了解使用ChatUniTest所产生的成本。实验将评估不同项目中每种方法的标识符成本。我们还将探索生成和修复过程中提示标识符和补全标识符的分布情况。请注意，目前gpt-3.5-turbo模型每1000个标识符收费0.002美元。
RQ1 生成的测试用例质量如何？
在表3中，我们列出了ChatUniTest在10个Java项目中的表现，总共处理了16362个方法，并进行了98172次单元测试生成尝试。在这些尝试中，有294次由于超过了提示标识符的最大限制而中止。
关于语法错误，有 2.18% 的尝试成功解决了这一问题。语法错误比例最高的是 Lang 项目（6.16%）。在对结果进行人工调查后，我们发现这些错误最常见的原因是生成了过长的测试，这些测试随后被截断，无法通过语法修复组件进行修复。
在 39.55% 的单元测试生成尝试中出现了编译错误。编译错误比例最高的是 Datafaker 项目（73.22%）。最常见的错误类型是“找不到符号”或“类型不兼容”，主要原因是 ChatUniTest 生成了不存在的方法或类，或在使用时出现错误。
在运行时错误方面，Lang 项目所占比例最高（37.44%）。最常见的错误类型是“org.opentest4j.AssertionFailedError: expected: ... but was: ...”和“cannot invoke ... because ... is null”。这些错误主要是由于错误使用断言或反射造成的。
至于通过和正确的测试用例，30.86%的测试通过，29.98%的测试正确。这从总体上证明了ChatUniTest的潜力，因为无论项目大小或Java版本如何，它在大多数项目中都表现出了良好的性能。此外，ChatUniTest还能利用模拟对象或反射来实现所需的测试目标。总体性能表明，ChatUniTest是为各种Java项目生成测试用例的宝贵资产。
测试 API 的使用对于确保单元测试的质量至关重要。为了调查 ChatUniTest 生成的单元测试中 TestAPI 的使用情况，我们检查了所有成功执行的测试文件，并记录了它们的 TestAPI 调用情况。图5显示了断言的分布情况，其中包括调用次数最多的 15 种非零断言类型。ChatUniTest 可以成功调用所有 15 种断言类型，每个单元测试平均调用 3 个断言。此外，图6显示了模拟调用的分布情况，突出显示了 34 种模拟 API 中调用最多的 15 种。最常用的 API 包括 mock()、when() 和 thenReturn()，而 ChatUniTest 也能成功调用不常用的 API，如 doNothing() 和 verifyNoMoreInteractions()。这些发现强调了 ChatUniTest 生成的单元测试在 TestAPI 调用方面的丰富性，ChatUniTest 有效地利用了断言和模拟来提高测试质量。
结果。在ChatUniTest的97878次成功测试中，通过率为30.86%，测试用例的正确率为 29.98%。这些通过的测试展现了丰富的断言和模拟使用情况，平均每个单元测试含有三个断言。这些结果有力地证明了ChatUniTest生成高质量单元测试的能力。
表3：ChatUniTest在10个Java项目上的性能：测试用例生成尝试的结果
图5：已通过测试中断言调用的分布情况
图6：已通过测试中模拟调用的分布情况
RQ2 ChatUniTest的性能与EvoSuite、AthenaTest和A3Test相比如何？
在表4中，我们对比了ChatUniTest和EvoSuite在10个不同的Java项目中的分支和行覆盖率。从表中可以看出，在大多数项目中，ChatUniTest的分支覆盖率都高于EvoSuite。例如，在Cli项目中，ChatUniTest的分支覆盖率和行覆盖率（分别为96.36%和93.52%）均高于EvoSuite（分别为90.90%和90.93%）。其他项目也呈现了类似的趋势，如Csv、Gson和Event。
然而，也存在EvoSuite在分支或行覆盖率方面略高于ChatUniTest的情况，尽管优势不明显。例如，在Datafaker项目中，EvoSuite的分支覆盖率高达91.12%，而ChatUniTest为89.76%。此外，在Chart项目中，EvoSuite的行覆盖率为85.90%，略高于ChatUniTest的84.03%。
尽管存在这些例外情况，但在大多数项目中，ChatUniTest在行覆盖率方面表现优于EvoSuite。总体而言，ChatUniTest在分支覆盖率和行覆盖率方面都展现出优势，其平均分支覆盖率为90.61%，而EvoSuite为86.59%；平均行覆盖率为89.36%，而EvoSuite为80.02%。ChatUniTest结果的一致性突显了其作为单元测试生成工具的可靠性和有效性。
表4：EvoSuite和ChatUniTest在10个Java项目中的分支和行覆盖率比较
在表5中，我们评估了AthenaTest、A3Test和ChatUniTest在Defects4J Lang-1-f修订版中的NumberUtils类上的方法行覆盖性能。表中AthenaTest和A3Test的数据来自A3Test中的结果，而ChatUniTest的数据则源自我们的实验。从表中可以看出，在17个方法中的15个方法的行覆盖率方面，ChatUniTest总体上优于AthenaTest和A3Test。值得注意的是，在toInt(String, int)方法中，ChatUniTest的覆盖率达到了惊人的20.0%（75行），而AthenaTest和A3Test的覆盖率分别为6.1%（23行）和6.4%（24行）。然而，在createLong(String)和min(int, int, int)这两种方法中，A3Test的表现优于ChatUniTest。
表5：方法行覆盖率比较，与AthenaTest和A3Test对Defects4J Lang-1-f中的NumberUtils类进行的比较
在表6中，我们对三种工具在Defects4J数据集上的性能进行了评估，重点关注测试用例的正确率和重点方法的覆盖率。我们在Defects4J数据集上对三种工具进行了比较，其中AthenaTest和A3Test的数据也来自A3Test。从表中我们可以看出，在除Lang项目之外的所有项目中，ChatUniTest在测试用例的正确率方面始终优于A3Test和AthenaTest。在重点方法覆盖率方面，ChatUniTest在所有五个项目中都优于AthenaTest和A3Test。
表6：A3Test、AthenaTest 和 ChatUniTest 在 Defects4J 数据集上的测试用例正确率和焦点方法覆盖率。
结果。在比较ChatUniTest和EvoSuite的性能时，我们发现ChatUniTest在10个Java项目中的分支覆盖率和行覆盖率始终优于EvoSuite。ChatUniTest的平均分支覆盖率达到了90.61%，行覆盖率达到了89.36%。相比之下，与AthenaTest和A3Test相比，ChatUniTest在NumberUtils类（Lang-1-f修订版，Defects4J数据集）的17个方法中的15个方法行覆盖率表现出色。此外，ChatUniTest在正确的测试用例和重点方法覆盖率方面也优于这两个工具。这些结果突显了ChatUniTest相对于最先进工具的鲁棒性和优越性。
RQ3 ChatUniTest不同组件的贡献是什么？
为了探究基因迭代、基于规则的修复和基于ChatGPT的修复组件各自的贡献，我们对每个组件处理后的测试分布进行了分析，结果如图7所示。从图中可以观察到，生成组件产生的正确测试较少，而语法错误测试较多。经过基于规则的修复组件处理后，语法错误大幅减少了89.19%，编译错误显著减少了10.50%，正确测试的数量从13391个增加到15472个，增加了15.54%，这主要归功于导入修复。
图7：不同组成部分的总体测试分布
基于ChatGPT的修复组件（以最后一组柱形图为代表）显示了其作为最重要贡献者的有效性，导致编译错误测试大幅减少，通过测试的次数显著增加了90.63%，从15,846次增加到30,208次。值得注意的是，如果语法错误不能被修复组件修复，尝试就会被终止，因此不会被基于ChatGPT的组件处理。
为了进一步研究基于ChatGPT的修复的有效性，我们在图8中列出了每轮成功通过测试的次数。每一轮表示ChatGPT被查询的次数，这意味着一个测试有机会通过一次生成组件和五次基于ChatGPT的修复。从图8中，我们可以看到近一半的测试是通过基于ChatGPT的修复修复的。此外，我们还发现第二轮到第六轮修复的测试数量大约是上一轮的一半。这表明，基于ChatGPT的修复组件在增强测试用例生成方面发挥了关键作用，显著提高了ChatUniTest的整体质量和效率。
图8：每轮通过测试的分布情况
结果。在对ChatUniTest组件的研究中，生成组件产生了较少的正确测试和一些语法错误测试。基于规则的修复大幅减少了89.19%的语法错误，增加了15.54%的正确测试。然而，基于ChatGPT的修复是最重要的贡献者，它使通过的测试增加了90.63%，并大大减少了编译错误。分析表明，基于ChatGPT的修复在增强测试用例生成方面发挥了关键作用，显著提高了ChatUniTest的整体质量和效率。
RQ4 生成单元测试的成本是多少？
在本研究问题中，我们从多个角度报告了成本。
图 9 展示了不同项目中每种方法的总成本。我们可以观察到，生成单元测试的总成本在不同项目中各不相同，其中电子商务项目的成本最低，为0.084美元，而Flink项目的成本最高，为0.128美元。这表明不同项目生成测试的复杂程度不同。修复过程占总成本的最大部分，约为83%。在这些项目中，Flink每个方法的修复成本最高，约为0.109美元，而Ecommerce最低，约为0.073美元。总体而言，所有项目的生成成本都明显低于修复成本。
图9：多个项目中每种方法的总成本、修复成本和生成成本的比较
图10 展示了生成组件的提示和补全标识符成本之间的相关性。红色回归线代表平均趋势。绿色线表示提示标识符和补全标识符成本的总和等于4096个标识符，表明该线上的任何一点都超过了提示标识符的最大限制，从而导致截断响应。垂直虚线表示最大提示标识符阈值为2700个，99.95%的提示标识符都低于此阈值。大部分数据点位于0到1000个标识符的范围内。回归线的斜率约为0.077，提示标识符与补全标识符之间的相关系数为0.09。这种低相关性表明，无论提示标记数多少，补全标记数都保持相对稳定。
图10：生成组件中提示标识符和补全标识符成本之间的关系
图11 展示了ChatGPT修复组件中提示标识符和补全标识符成本之间的相关性。回归线的斜率为0.23，相关系数为0.44，表明在修复过程中，提示标识符和补全标识符之间存在适度的正相关关系。之所以会出现这种关系，是因为ChatGPT的任务是在收到错误版本后，返回一个完整的、经过更正的单元测试。
图11：修复组件中提示标识符和补全标识符成本之间的关系
为了解决这个问题，一种更有效的方法是要求ChatGPT提供修改原始测试的说明，而不回复整个测试。这可以简化修复流程，减少标识符数量，提高整体效率，并有可能优化基于ChatGPT的修复组件和增强测试生成流水线。
结果。 各项目生成单元测试的成本各不相同，修复成本约占总成本的83%。在生成组件中，提示和补全标识符成本之间的相关性很低（0.09），表明补全标识符数量保持相对稳定。在修复组件中，提示标识符和补全标识符之间存在适度的正相关关系（0.44）。更有效的方法可能是要求ChatGPT提供修改测试的说明，而不是返回整个更正后的测试。
转述：程钰鑫
