终于看到一个 AI 大语言模型在软件工程上的规模化应用啦！

今年（2024年），Facebook 母公司 Meta 正式开始在 Facebook 和 Instagram 的 Kotlin 代码上应用AI 大语言模型工具 TestGen-LLM 以全自动方式补充单元测试代码，提高单元覆盖率。

TestGen-LLM 使用了一种名为“Assured LLM-based Software Engineering（简称Assured LLMSE）”方法。

尽管TestGen-LLM 中使用的两个 LLM 模型并没有开源，但是这是一个比较好的思路，主要有四点：

（1）定位为回归测试用例（测试用例要能自动运行并成功通过）

（2）可衡量的改进（测试用例要增加行覆盖率）

（3）多个LLM 集成使用。LLM生成的是代码组件，而不是整个程序。组件是可组合的，因此可以由多个不同的LLM提供，作为一个集成体工作。

（4） 最后由工程师Review。帮助人类，而不是取代他们。通过寻求改进现有代码和测试，而不是从头开始构建它们。

具体内容如下。

----

TestGen-LLM使用Meta的两个大型语言模型(LLMs)通过生成额外的测试用例来扩展现有的、人工编写的Kotlin测试类，这些测试用例覆盖了之前可能被遗漏的边缘用例，并提高了整体测试覆盖率。

其工作过程如下：

1.  通过 LLM 生成自动化单元测试用例候选列表
   

2.  提取测试用例代码

3. 第一次过滤：编译测试代码。若某个测试无法编译通过，就丢弃它。

4. 第二次过滤：运行测试用例。若某个测试运行失败，就丢弃它。

5. 第三次过滤：如果某个测试用例没有提高原有的测试覆盖率，就放弃。

6. 重构测试用例类。

7. 提交Diff，交给工程师Review。如果 Review 通过，就进入代码库。

在第一次测试竞赛期间，36 名工程师落地了 105 个单元测试 diff，其中 16 个由 TestGen-LLM 生成。TestGen-LLM 创建了总共 17 个 diff。其中：

    只有一个 diff 被放弃了，因为测试用例没有包含任何断言。这个 被拒绝的 diff 中的测试用例试图测试一个部分实现的函数，LLM 代码留下了一个注释，指示要添加一个断言作为“TODO”。该测试用例确实扩展了覆盖范围（仅通过执行之前未执行的测试方法），但它被审查 diff 的工程师拒绝，因为它没有包含断言。最大的覆盖范围改进是由一个 TestGen-LLM diff 实现的，它涵盖了一个之前未被覆盖的方法，因此生成了许多额外的覆盖范围，包括：

• 28 个新文件被覆盖，之前未被覆盖。

• 13 个文件之前部分被覆盖，但改进的测试类扩展了覆盖范围。

• 3 个 A/B 测试门卫（生成的 A/B 决策代码也被额外覆盖）。

与倾向于在单个 diff 中编写一整类测试的测试工程师不同，TestGen-LLM 每个测试都作为一个单独的 diff 提交。

在 86 个已有人工编写测试类的 Kotlin 组件上（Stories 31 个，Reels 55 个）的实验结果如下：

(1) 75% 的测试类至少有一个新建的测试用例构建正确。

(2) 57% 的测试类至少有一个测试用例构建正确并且可靠通过。

(3) 25% 的测试类至少有一个测试用例构建正确、通过并且与共享同一构建目标的所有其他测试类相比增加了行覆盖率。

如下图所示。

在 2023 年 12 月 18 日至 20 日期间，使用进一步改进的 TestGen-LLM 工具对 11 月份 test-a-thon 更新过的相同目录进行了操作。选择这些目录是因为它们最近经过了人类开发，所以它们提出了一个挑战：在最近人类和之前 TestGen-LLM 测试工作的组合上进一步改进。

这次部署是完全自动化的，TestGen-LLM 现在自动运行在这些目录上，无需人类干预。TestGen-LLM 自动生成了 42 个 diff 并提交审查。在 42 个 diff 中：

• 36 个被审查的工程师接受。

• 4 个被拒绝和/或放弃。

• 2 个被撤回。

两个被撤回的 diff 都增加了覆盖范围，但我们认识到所覆盖的文件并不重要。四个被拒绝的 diff 的原因如下：

• 为被测试的简单方法（一个 getter 方法）生成测试。

• 未遵循“每个测试用例单一责任”原则（因此原因拒绝了 2 个）。

• 测试用例中未包括断言。

另外，Facebook 平台的成功率比Instagram 的成功率高，可能源于这样一个事实：与 Instagram 相比，Facebook 由工程师手工编写的测试案例比Instagram 多10 倍有余。

其它要点如下：