Page 24 - 《软件学报》2026年第7期
P. 24

赵英全 等: 基于大语言模型的        Java 新特性测试程序生成                                           2709


                  4.2.4    方法实现及实验过程
                    本文基于广泛被使用的         OpenJDK 8  来实现  LumiX. 为了识别种子程序中可复用的程序元素, LumiX               使用
                 JavaParser [42] 对种子程序进行分析. JavaParser 是一个开源的  Java 源码分析工具, 支持将      Java 源码解析为   AST, 并
                 提供了丰富的     API 用于对  AST  的操作. 具体来说, LumiX   使用  JavaParser 将  Java 源码解析为  AST, 提取出其中可
                 复用的程序元素信息, 最后将插入新代码片段的                AST  转换为源代码, 从而生成新的测试程序. 为了总结新特性使
                 用描述以及生成新的代码片段, LumiX          使用通义千问-Max (Qwen-Max-0125) 大模型     [43,44] . 通义千问  2.5  是阿里云
                 发布的大语言模型, 是本实验进行时通义千问系列效果最好的大模型, 具有强大的文本理解、代码生成以及逻辑
                 推理能力. 为了避免生成不合法或包含死循环、无限递归等容易引入误报的程序特征, LumiX                            一方面在构造的提
                 示词中加入严格的约束条件; 另一方面设置程序的编译和执行时间为                       30 s, 当生成的测试程序执行时间超过时间
                 限制时, LumiX  将会终止编译或执行并输出超时报告.
                    为了回答研究问题        1, 本实验对比了    LumiX、LumiJ、JavaFuzzer 以及  Fuzz4All 在  4  个  OpenJDK  历史版本
                 上的缺陷检测效果, 包含编译阶段           (javac、ECJ) 和执行阶段   (HotSpot、OpenJ9) 的唯一不一致缺陷数量. 为保证
                 实验的公平性, 本文对       Fuzz4All 进行了适配: 在其文档中补充        JEP  增强提案, 使其具备对语言新特性的支持; 同
                 时, 实验统一采用通义千问-Max (Qwen-Max-0125) 作为大语言模型. 对于所有方法, 测试时间统一设置为                        24 h.
                 为了回答研究问题       2, 本实验选择    OpenJDK 21  作为测试对象的代表, 在     OpenJDK 21  上收集不同方法的      Java 编
                 译器代码覆盖率以及        JVM  代码覆盖率. 考虑到分支覆盖与函数覆盖通常与代码行覆盖表现为相似的分布, 因此
                 本文仅对比不同方法在代码行覆盖上的差异. 覆盖率实验的运行时间同样为                          24 h, 在不同方法运行过程中, 本实
                 验以  1 h  为间隔分别收集    Java 编译器和  JVM  的代码覆盖率. 为了回答研究问题           3, 本实验将  LumiX  应用于最新
                 版本  Java 编译器和  JVM  的测试中, 即表    3  中“最新版本”列对应的      Java 编译器和   JVM  版本, 并统计检测到的未
                 知缺陷数量. 为了回答研究问题          4, 本实验以   OpenJDK17  以及  OpenJDK 21  作为测试对象, 对  LumiX  的不同关键
                 组件进行消融. 消融实验针对         LumiX  的关键部分, 即新特性使用描述总结及代码片段生成进行消融. 此外, 本实
                 验通过替换使用的大模型, 来探索不同大模型对                LumiX  效果的影响. 本实验使用的大模型均通过相应厂商提供
                 的  API 进行访问. 除了   LumiX  使用的通义千问-Max (Qwen-Max-0125) 大模型, 在研究问题         4  中, 本实验还对比
                 了  DeepSeek-V3 [45] 、Qwen2.5-72b、Qwen2.5-7b  来对比不同模型以及不同参数大小对       LumiX  效果的影响. 需要
                 注意的是, 为了确保公平性, 本实验参数设置均参考已有研究的最佳实践                        (如模型温度设为      0.7) 进行设置  [46] . 已
                 有研究表明, 更优的参数设置或提示词设计, 如               CoT  推理及 In-context learning  等策略能够提升模型表现    [47–50] ,
                 这些手段同样有望增强         LumiX  的效果. 本文将在后续研究中探索和引入这些策略, 以更进一步地提升方法性能.
                    本文所有实验均在同一台服务器上进行, 服务器具有两个                 12 核  CPU Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40 GHz,
                 125 GB  内存, 操作系统为   Ubuntu 20.04.6 LTS (64  位).
                  4.3   结果分析
                    基于上述实验设置, 本节将对         LumiX  与其他对比方法的实验结果进行分析, 以回答本文的研究问题.
                  4.3.1    研究问题  1: 历史缺陷检测效果分析
                    表  4  展示了  LumiX、JavaFuzzer、Fuzz4All 和  LumiJ 在  4  个  OpenJDK  版本上不同测试对象上的检测效果.
                 本实验对每个方法检测到的不一致缺陷做了进一步的区分, 分别包括                     Java 编译器不一致缺陷以及       Java 虚拟机  (JVM)
                 不一致缺陷, 其中加粗数字为在对应测试对象下表现最优的方法                     (下同). 需要注意的是, 表     4  中的不一致缺陷数量
                 均为去重后的不一致缺陷数量.
                    从表  4  中可以看出, LumiX  在所有   OpenJDK  版本上的效果均优于现有工作, 在          4  个  OpenJDK  版本的  Java 编
                 译器和   JVM  上累计检测到    25  个不一致缺陷. 而   JavaFuzzer 在所有的  OpenJDK  版本上仅检测到    3  个  JVM  不一致
                 缺陷, 且未在    Java  编译器上检测到不一致缺陷. Fuzz4All 在所有的版本上仅检测到               6  个编译器不一致, 但未在
                 JVM  上检测到任何不一致缺陷. LumiJ 则在所有的           OpenJDK  版本上一共检测到      17  个不一致缺陷. 首先, 通过对
                 比  LumiX  和  JavaFuzzer 的结果可以发现, LumiX  比  JavaFuzzer 多检测出  22  个不一致缺陷, LumiX  效果显著优于
   19   20   21   22   23   24   25   26   27   28   29