持续交付2.0

如何用 AI 自动化批量补写单元测试

Image

关注我,每天收获一个新技能!

1

引言 :为什么               

在现代软件开发中,软件测试作为关键环节,却面临资源消耗大、任务重复等问题。

为解决这些痛点,相关团队开发出AI驱动的单元测试代码生成器,为软件测试领域带来新变革。

在2024年5月,我写了一篇关于 Facebook 使用 AI 补写单元测试的文章。

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

今天,我们再来介绍一下,如何设计一个批量补定自动化测试的框架。

为什么是“补写”呢?

因为这种方法的前提假设是:你的生产代码本身没有错误,可以正确运行。而生成的自动化测试用例都是以“可以测试通过”为验收条件的。

2

工作流程解析

系统工作流程清晰有序。

Image
1. 初始化阶段,用户发起扫描请求,系统开始查找未测试代码。
2. 针对目录函数查找更多的上下文,如它所在的文件,目录,调用的函数等
3. 测试生成阶段,测试生成器处理未测试函数,大语言模型生成高质量测试用例。
4. 执行和分析阶段,测试运行器执行测试,错误收集器标记问题,测试分析器评估错误并生成报告
5. 最后,自我修复代理依据报告进行自动修复,若三次修复失败则向用户提供详细报告,避免AI陷入无限循环。

3

核心架构与组件功能

该系统采用基于代理的架构,各组件分工明确。

Image
  1. 仓库扫描器负责扫描代码库,精准定位未测试函数并存储相关数据,为后续测试明确重点。
  2. 上下文获取器获取未测试函数的关键信息,为测试生成提供有力支撑。
  3. 由大语言模型驱动的测试生成代理,依据获取的上下文,全面测试各种可能场景,并将测试结果存储。
  4. 测试运行器和错误收集器负责执行测试、收集错误,为后续分析提供依据
  5. 测试分析代理评估测试结果,生成详细报告。
  6. 自我修复代理最为创新,能利用AI自动处理失败测试,通过不断学习和适应进行修复。              

4

提升测试准确性的策略

为确保生成测试的准确性与相关性,要精心设计详细提示,明确任务定义,如要求大语言模型生成函数描述及对应单元测试。通过顺序指令规范大语言模型的推理过程,避免步骤混乱。

在单元测试生成阶段,给出具体的测试框架使用要求、模拟外部依赖项的方法、处理异步函数的要点等,还规定了代码格式、导入要求等,并提供示例和模板作为参考,最终明确期望的JSON输出格式,多次迭代改进,大幅提升测试准确性。


5

实际应用与意义

系统的强大功能,如快速扫描代码库、生成全面测试用例,以及处理复杂模拟场景和自我修复错误等。

该工具将AI与测试自动化结合,减少人工干预,加快开发周期,保障代码质量,让开发者专注于功能开发,尤其适用于敏捷和DevOps工作流程。

AI驱动的单元测试代码生成器在当前已展现出显著优势,未来发展潜力巨大,有望推动软件测试领域朝着更智能、高效、全面的方向迈进。 


6

优势在哪里

与传统单元测试方法相比,AI驱动的单元测试代码生成器在效率、准确性、适应性等多方面具有显著优势,为软件测试带来了新的变革。

 1.大幅提升测试效率:传统单元测试需要开发人员手动编写大量测试代码,过程繁琐且耗时。而AI驱动的单元测试代码生成器能在短时间内自动扫描代码库,快速定位未测试函数并生成全面的单元测试用例。在演示视频中,系统可在几秒内完成代码库扫描和测试生成,极大地缩短了测试用例编写时间,加快了软件开发周期。

 2. 增强测试准确性:传统测试方法依赖人工编写,容易出现疏漏,导致测试覆盖不全面或测试代码本身存在错误。AI驱动的生成器借助大语言模型和精心设计的提示工程,能考虑到各种复杂场景,生成高度准确且符合实际开发标准的测试用例。通过迭代优化和详细的提示指令,如对测试框架使用、异步函数处理、代码格式等方面的要求,确保生成的测试全面且可靠。 

3. 具备自我修复能力:传统单元测试中,若测试出现失败,开发人员需花费大量时间和精力去排查和修复问题。AI驱动的单元测试代码生成器配备自我修复代理,能利用AI自动分析错误报告,尝试自主修复失败的测试。这种自我修复功能不仅节省了人力,还能使测试随着代码的变化及时调整,适应敏捷和DevOps工作流程。 

4. 减少人工干预:传统单元测试过程中,开发人员需投入大量精力编写、维护测试代码,这占据了他们开发新功能的时间。而AI驱动的工具实现了测试代码生成和部分修复的自动化,开发人员无需再专注于编写繁琐的样板测试代码,可将更多精力投入到核心功能的开发上。 


7

不足有哪些

AI驱动的单元测试代码生成器虽优势明显,但也存在一些缺点,主要体现在对AI技术的依赖、测试准确性的局限以及对复杂场景处理能力的不足等方面。

对AI技术的高度依赖
:该生成器依赖大语言模型(LLM),若模型出现故障、性能下降或遭受攻击,生成器的功能会受严重影响。大语言模型在训练时可能存在数据偏差,若训练数据不全面或不准确,生成的测试用例也会出现问题,难以发现代码中的潜在缺陷。而且模型训练和运行成本高,大规模应用时,企业需承担高昂的计算资源费用和技术维护成本 。
测试准确性存在局限
:尽管通过提示工程等手段提高了测试准确性,但生成的测试用例仍可能存在漏洞。一些复杂业务逻辑和边界条件难以被AI精准识别和覆盖,导致部分缺陷无法在测试中暴露。在处理特定领域或具有复杂依赖关系的代码时,生成器可能无法理解代码的深层含义,生成的测试用例质量不高。 
复杂场景处理能力不足
:当涉及外部实体如API、数据管道时,AI驱动的生成器处理能力有限。API的调用规则、数据管道的数据流转逻辑复杂多变,生成器难以模拟各种真实场景进行全面测试。对于使用面向对象编程(OOP)构建的复杂代码库,尤其是包含多层继承、复杂类关系和动态绑定的情况,生成器生成的测试用例难以满足测试需求。
缺乏对业务逻辑的深度理解
:AI生成器主要基于代码结构和模式生成测试用例,缺乏对软件业务逻辑的深度理解。它无法像经验丰富的测试人员那样,根据业务目标和用户需求来设计具有针对性的测试场景,可能遗漏一些对业务功能有重要影响的测试点。
结果可解释性差
:AI生成测试用例的过程是基于模型的学习和推理,生成结果的可解释性较差。开发人员难以理解为什么生成特定的测试用例,当测试结果出现问题时,增加了排查和调试的难度,不利于快速定位和解决问题。 

原文链接:AI Meets Software Testing: The Future of Unit Test Generation                      

© 2025 技术文章 | 更多内容请关注我们