当前位置:   article > 正文

【AI赋能万物】一文综述:大模型在软件测试领域的探索_测试大模型

测试大模型

大家好,我是 同学小张,+v: jasper_8017 一起交流,持续学习C++进阶、OpenGL、WebGL知识技能AI大模型应用实战案例,持续分享,欢迎大家点赞+关注,共同学习和进步。


关注大模型在各个领域的应用,看大模型如何重构世界。本文以一篇论文,来看下大模型在软件测试行业的一些探索。这篇文论为我们提供了关于LLMs在软件测试中应用的全面回顾。这篇论文分析了102项相关研究,从软件测试和LLMs的角度进行了深入探讨。

论文原文:https://arxiv.org/pdf/2307.07221

文章目录

  • 0. 意义
  • 1. 论文内容
    • 1.1 收集论文的方法
    • 1.2 从软件测试视角的分析
      • 1.2.1 测试用例生成
        • 1.2.1.1 单元测试
        • 1.2.1.2 测试断言
        • 1.2.1.3 系统测试输入
          • 1.2.1.3.1 软件类型方面的输入生成
          • 1.2.1.3.2 测试技术方面的输入生成
          • 1.2.1.3.3 输入输出方面的输入生成
      • 1.2.2 Bug分析
      • 1.2.3 调试
      • 1.2.4 程序修复
  • 2. 总结

0. 意义

在数字化时代,软件测试是保障产品质量的坚实盾牌,它通过细致的检验揭示潜在缺陷,确保用户获得可靠体验。然而,随着软件系统日益庞大复杂,传统测试方法面临覆盖率不足、自动化难度大等挑战。此时,大型语言模型(LLMs)以其卓越的理解和生成能力,展现出在自动化测试、缺陷预测等方面的巨大潜力,为软件测试领域带来革命性的创新机遇。

下面来看下论文中的内容和结论。

1. 论文内容

1.1 收集论文的方法

这篇论文分析了102项相关研究。那么,他们首先要做的就是收集这102项相关研究。他们收集论文的方法如下::

(1)自动搜索:使用四个流行的科学数据库进行广泛的搜索,包括ACM数字图书馆、IEEE Xplore数字图书馆、arXiv和DBLP。搜索条件是论文标题中包含与软件测试任务和测试技术相关的关键词,以及与大型语言模型(LLMs)相关的关键词。

(2)手动搜索:为了补充自动搜索可能遗漏的相关论文,作者还在软件工程和人工智能领域的顶级会议记录和期刊文章中进行了手动搜索。选择了基于Google Scholar h5指数的前十个相关会议,排除了三个计算机视觉会议。

(3)纳入和排除标准:为了确保收集的论文与研究范围和问题相符,定义了一套具体的纳入和排除标准。满足纳入标准的研究将被包括在内,而不满足排除标准的研究将被排除。

(4)质量评估:建立了质量评估标准,以排除低质量的研究。每项研究根据一系列问题进行评分,得分低于特定值的论文将被排除。

(5)滚雪球搜索:在完成数据库和会议的搜索、应用纳入/排除标准和质量评估后,作者还进行了滚雪球搜索,检查已收集论文引用的参考文献,以减少遗漏相关文献的风险。

通过上述过程,从14,623篇初步检索的论文中,最终收集了102篇涉及使用LLMs进行软件测试的论文。收集到的论文中,47%发表在软件工程领域,2%发表在人工智能领域,5%发表在程序分析或安全领域,还有46%的论文尚未在arXiv上发表。

1.2 从软件测试视角的分析

从软件测试的角度来看,软件测试的步骤为:制定测试计划阶段、测试计划设计、准备测试用例、执行测试用例、产出测试报告、修复bug和回归测试,如下图:

在这里插入图片描述

论文中总结出,大模型一般用于以下三个阶段:

(1)测试用例生成

(2)产出测试报告

(3)bug修复和回归测试

下面我们来看下在这三个阶段中,大模型的具体作用。

1.2.1 测试用例生成

1.2.1.1 单元测试

传统的单元测试生成技术利用基于搜索的、基于约束的或基于随机的策略来生成一套单元测试,其主要目标是最大限度地扩大被测软件的覆盖范围。

利用大模型来生成单元测试,目前主要有以下方向:

(1)预训练和微调(fine-tuning)大模型来生成单元测试
(2)设计有效的提示来让大模型生成单元测试
(3)提供额外的文档(例如API接口描述文档)来辅助大模型生成单元测试
(4)先使用传统的单元测试生成方法生成单元测试,然后利用大模型来提高覆盖不足的功能的单元测试

篇幅原因,这里仅列出应用方向,具体应用实施方法请参考原论文中的参考文献。

论文中提到,目前大模型生成单元测试用例的性能还很低,有待进一步研究。

1.2.1.2 测试断言

测试断言是关于软件系统(或程序、功能或方法)的输出是否正确的信息来源,大多数研究都是针对单元测试用例的测试断言生成。

相关的研究中,有利用源代码或断言数据集来微调LLM以提高断言匹配率的。也有利用提示工程自动检索相似代码,通过少样本提示来提高断言匹配率的。目前最优的匹配率可达到 76%。

1.2.1.3 系统测试输入

这一部分是利用大模型来创建系统测试、功能测试、模块测试的测试输入,以实现测试执行的自动化。

1.2.1.3.1 软件类型方面的输入生成

不同软件测试需要不同系统级测试输入,如移动应用需多样化文本或操作组合;深度学习则需覆盖多样化API的程序。

在移动应用测试方面,大模型主要有三方面的细分应用场景:根据GUI来生成测试的文本输入、按钮动作、生成有效的测试脚本(包括点击按钮的顺序、操作路径等)。

在深度学习库测试方面,需同时满足编程语言(如Python)语法/语义和API输入输出/形状约束。传统技术有局限性,如缺乏多样化的API序列、无法生成任意代码,使用生成式和填充式LLM来生成和变异有效的多样化DL程序输入进行测试,后续研究进一步利用历史漏洞触发程序中的代码来提升漏洞检测性能。

还有一些其它类型的输入生成,例如Simulink系统、SMT求解器、编译器、JavaScript程序等,详情可参考原论文。下图是当前大模型在软件类型方面的测试生成研究的热度:

在这里插入图片描述

1.2.1.3.2 测试技术方面的输入生成

这一部分是利用LLM增强传统测试技术。如 通用模糊化测试框架、特定软件的模糊化测试技术、GUI测试、渗透测试等。

1.2.1.3.3 输入输出方面的输入生成

除将源代码或软件作为输入直接输出来测试外,还有其他输入输出形式。个人觉得最有启发性的一个场景是通过自然语言描述来利用大模型生成相应的测试输入

1.2.2 Bug分析

这部分的方向有:

  • 针对缺陷报告生成相关问题答案,帮助缺陷分类。

  • 将缺陷组件分类转化为多分类与生成任务,提升分类性能。

  • 利用LLM零样本设置提取缺陷报告关键信息,检测重复报告。

  • 用LLM解释软件缺陷,通过学习大量修复提交生成自然语言解释。

  • 自动生成缺陷标题,助力开发者撰写问题标题。

1.2.3 调试

这一类别指的是识别和定位软件问题(即bug)原因的过程。它包括分析代码、跟踪执行流程、收集错误信息以了解问题的根本原因以及修复问题。目前有的研究方向:

(1)总体调试:利用大模型覆盖调试的全过程
(2)Bug定位
(3)Bug复现
(4)错误解释:针对每个错误生成独特的解释

1.2.4 程序修复

LLM具有先进的自然语言处理和理解能力,能够处理和分析源代码,是执行代码相关任务(如修复错误)的理想工具。

(1)修复单行错误(已知错误)
(2)修复多行错误(已知错误)
(3)结合静态代码分析器一边检测一边修复(先检测错误,再修复错误)
(4)特定bug的修复:通过自然语言描述生成补丁、性能问题修复、特定程序如Rust程序修复

下图是一些程序修复的实验数据:

在这里插入图片描述

2. 总结

简单总结一下本文的内容。本文通过一篇论文来罗列了当前大模型在软件测试领域中的一些探索。从软件测试的角度看,目前大模型一般应用于测试用例生成、Bug分析、程序调试、Bug修复等过程中。

本文是对论文中提到的应用方向的罗列,不涉及具体的实现方法。直观的让读者看到有哪些应用方向可以参考,如果读者对某一个方向感兴趣,可以快速地找到参考文献。

如果觉得本文对你有帮助,麻烦点个赞和关注呗 ~~~


  • 大家好,我是 同学小张,持续学习C++进阶、OpenGL、WebGL知识技能AI大模型应用实战案例
  • 欢迎 点赞 + 关注
    声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小惠珠哦/article/detail/760954
推荐阅读
相关标签