CN116661953A - 一种基于代码片段向量化的jvm测试方法 - Google Patents

一种基于代码片段向量化的jvm测试方法 Download PDF

Info

Publication number
CN116661953A
CN116661953A CN202310800176.4A CN202310800176A CN116661953A CN 116661953 A CN116661953 A CN 116661953A CN 202310800176 A CN202310800176 A CN 202310800176A CN 116661953 A CN116661953 A CN 116661953A
Authority
CN
China
Prior art keywords
code
test
program
jvm
code component
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310800176.4A
Other languages
English (en)
Inventor
陈俊洁
高天畅
赵英全
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianjin University
Original Assignee
Tianjin University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tianjin University filed Critical Tianjin University
Priority to CN202310800176.4A priority Critical patent/CN116661953A/zh
Publication of CN116661953A publication Critical patent/CN116661953A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/23—Clustering techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/436—Semantic checking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/72—Code refactoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

本发明公开了一种基于代码片段向量化的JVM测试方法，直接使用了JavaTailor手机的历史测试程序。种子测试程序将作为合成中的载体，对获得的代码成分语义向量进行语义相似的代码成分聚类，将选择出来的代码成分合成到给定的种子程序中得到新的测试程序；待测的不同JVM输入新的测试程序，通过匹配不同JVM在同一个测试程序上执行结果的一致性来判断是否触发JVM错误。本发明通过将语义相似的代码成分聚类到同一组，极大地减少了代码成分空间，将庞大空间中的代码成分选择问题转化为较小空间中的组选择问题，从而提高了代码成分的探索效率和测试性能。

Description

一种基于代码片段向量化的JVM测试方法
技术领域
本发明涉及软件以及编译器测试领域，特别是涉及一种利用程序向量化技术提高JVM测试方法。
背景技术
自从1995年Java语言问世以来，其通用性、高效性、平台无关性和安全性等优势给开发人员带来了极大的便利，Java语言当前已经成为了世界上最流行的语言之一。并且随着Java的发展，目前已经形成了庞大且完善的Java生态系统，比如基于Java进行开发的数据库系统MySQL、服务器系统Tomcat和程序框架Spring一系列应用。Java程序能够拥有“一次编写，随处运行”的特性得益于Java程序运行的基石——Java虚拟机(Java VirtualMachine，简称JVM)。当前已经有很多公司开发了不同的JVM实现，比如Oracle的HotSpot,IBM的OpenJ9,GNU的GIJ，华为的BiSheng JDK，并且各个公司也花费了大量的资源来维护JVM实现的正确性。
对于一个Java程序而言，整体的生命周期需要经过三个过程：
1)使用前端编译器(javac)将Java源程序编译为Java字节码文件；
2)Java字节码通过加载、链接等阶段输入到JVM当中；
3)JVM针对下层的操作系统将相同的字节码转化为不同的机器码。
如图1所示，是现有的Java程序执行阶段示意图。其中Java字节码文件是一种描述源程序的二进制文件，它包含一系列操作码和数据，作为源码与机器码之间的中间码存在。字节码的存在将Java程序编译阶段与执行阶段分离，从而达到屏蔽不同操作系统的差异。基于这一特性，Kotlin和Scala等语言将自身的源码编译为字节码文件，从而直接使用JVM执行。虽然不同的开发商已经花费了大量的资源来测试和维护JVM，但是由于JVM其相当复杂的功能和巨大的代码量导致其仍然存在缺陷。而JVM作为支撑整个Java语言庞大生态系统的重要基础组件，JVM错误可能会导致任何由它们处理的Java应用程序出现意外行为，确保JVM的正确性是非常重要的。假设JVM存在缺陷也就意味着依赖JVM的生态都可能受到不同程度的攻击，特别是当攻击涉及到金融与安全领域时后果是不堪设想的。因此，确保JVM的正确性和健壮性对于整个Java语言生态是至关重要的。
在先前的研究中，已经提出了一些JVM测试的相关技术，包括基于变异的方法classfuzz和classming，还有基于合成的方法JavaTailor。其中classfuzz设计了一系列的变异规则对字节码进行变异，但是因为在变异过程中没有关心变异后程序的正确性，导致测试程序往往在生命周期的第二阶段被终止。这代表classfuzz只能测试第二阶段中与加载、链接有关的JVM功能，这极大的限制了classfuzz的有效性。在此之后，classming尝试利用代码的控制流图，希望通过改变控制流的方向从而生成更加复杂的控制流。在这一基本的方向之上，classming提出了活字节码变异的概念，从而生成能够达到第三阶段的测试程序。但是classming改变控制流的思想与发现缺陷之间并没有直接关联，所以研究人员开辟了基于变异之外的一个方向，JavaTailor通过合成各种代码片段来构造测试程序，也就是从专家设计的历史错误测试程序中提取的各种代码成分放入给定的种子程序提供的新上下文中，从而生成更加复杂的测试程序。代码成分是由完整的测试程序定制的小代码片段，因此它们中的许多很可能具有相似的语义，从而导致相似的错误揭示能力。目前基于JVM综合的测试工作更多地关注于保证合成测试程序的有效性，而忽略了合成测试程序中巨大的代码成分空间对测试性能的影响。面对巨大的代码成分空间，JavaTailor只是将每个代码成分平等地、单独地进行随机搜索，这在很大程度上限制了代码成分的探索效率和测试性能。而且JavaTailor通常采用差异测试作为测试预言，比较测试程序在多个JVM中的输出，但是保证合成后种子程序中代码成分与输出语句之间有依赖关系是很难的。因此其可能会错过已经被触发但是无法被发现的测试程序。综上所述，当前最先进的方法在探索的效率以及捕获的准确度上远远不够。
现有技术包含以下缺点和不足：
缺点一、现有技术更多地关注于保证合成测试程序的有效性，而忽略了合成测试程序中巨大的代码成分空间对测试性能的影响，很大程度上限制了代码成分的探索效率和测试性能。
缺点二、现有技术中，不同的代码成分在生成测试程序时具有不同的揭错能力，如果对每一个代码成分的选择概率都是相同的，可能会导致频繁生成无用的测试程序，进一步影响探索效率和测试性能。
缺点三、现有技术无法将程序中的全部结果传播到输出语句当中，所以可能会错过已经被触发但是无法被发现的测试程序。
发明内容
为了突破现有方法的技术局限性、解决当前JVM测试当中面临的探索效率和测试性能低下以及缺陷发现能力不足的问题，本发明提出一种利用向量化程序片段优化JVM测试的方法，首次通过程序代码成分向量化来测量代码成分之间的语义相似性，从而实现了提高对巨大代码成分空间的探索效率的JVM测试方法。
为了实现上述目的，本发明利用了以下技术方案：
一种基于代码片段向量化的JVM测试方法，包括：
步骤1、输入历史测试程序以及种子测试程序，其中，对所述历史测试程序进行代码成分提取以及对所述种子测试程序进行初始化处理；
步骤2、将提取的代码成分转换为Java源码，使用社区中训练好的代码表示预训练模型实现代码成分向量化，获得代码成分语义向量；
步骤3、基于所述代码成分语义向量，将语义相似的代码成分聚类到同一组中；具体通过聚类算法AGNES采用自底向上迭代地进行聚类的策略，得到语义相似的代码成分语义向量聚类结果为代码成分类组G＝{g1,g2,...,gr}；
步骤4、重构代码成分，将步骤1中提取的代码成分按照步骤3得到的聚类结果重新划分，属于同一个代码成分组的代码成本分配到相同的列表当中；
步骤5、对于步骤3得到的代码成分组集合G，通过选择有助于合成缺陷测试程序的组和被选择得少的组以更大的概率被选择的反馈驱动的组选择策略，实现了从所有的代码成分组中选择满足缺陷揭示能力和多样性的代码成分组，然后在代码成分组中先随机选择一个代码成分组，再从组内选择一个代码成分，将选择出来的代码成分合成到给定的种子程序中得到新的测试程序；
步骤6、将待测的不同JVM输入步骤4得到的所述新的测试程序，通过匹配不同JVM在同一个测试程序上执行结果的一致性来判断是否触发JVM错误。
进一步的，对于所述种子测试程序，获取种子程序中可访问的变量以及可进行合成的位置。
进一步的，聚类策略包括以下执行阶段：在每次迭代中，计算每对组之间的距离，并将聚类最接近的两个组合并为一个组，直到所有代码成分放入同一类中，即r等于1，获得整个聚类过程中的迭代树，利用每次聚类迭代对应的结果，分析在不同的聚类类数的情况下的轮廓系数，从中获取每个组集合的质量最接近1的聚类结果。
进一步的，测试程序合成的过程是直接将被选择的代码成分插入到种子程序代码当中，分析代码成分中缺少的变量声明，向上遍历寻找能够重用的变量，对于无法重用的变量声明直接新建变量。
该方法进一步包括增强测试预言的处理，对新创建的所有基础变量计算哈希值，累加到全局变量CHECKSUM中，将全局变量CHECKSUM在程序正常终止时输出。
进一步的对待测的JVM实现执行增强后的测试程序，判断是否能够捕获差异，被捕获差异的测试程序通过人工分析来确定缺陷发生的位置，未发现差异的测试程序则添加到种子文件池中等待后续的高阶变异。
进一步的，将得分值SC作为指标，输出聚类树中具有最高质量层次的代码成分组集合作为最终聚类结果。
在现有技术的基础上，本发明能够获得以下有益技术效果：
1)本发明能够极大地提高基于综合的JVM测试的效率以及测试的有效性；
2)利用代码表示方法对代码成分进行向量化实现发现更多样且容易致错测试程序，使用选择算法提高合成的有效性，最后增强测试预言，以此来达到发现更多样且容易致错测试程序的目的。
附图说明
图1为Java程序执行阶段；
图2为本发明的一种基于代码片段向量化的JVM测试方法方法流程图；
图3为本发明实施例图；
图4为语法语义相似的代码成分示例图；
图5为HotSpot缺陷JDK-8290451示例图。
具体实施方式
以下结合附图对本发明作进一步详细说明。
为了突破现有方法的技术局限性，本发明提出一种利用向量化程序片段优化JVM测试的方法(VECT)。
如图2所示，本发明的一种基于代码片段向量化的JVM测试方法具体步骤如下：
步骤1、输入历史测试程序以及种子测试程序；
步骤1.1、对种子测试程序进行处理；首先需要对其进行初始化处理，将种子程序中的访问标志修改为public，以便合成过程中能够尽可能的拓展上下文的交互；静态的遍历程序中每一条语句，从而获取种子程序中可访问的变量以及可进行合成的位置；
步骤1.2、对历史测试程序进行代码成分提取，根据给定的历史测试程序，利用Java代码分析工具Soot将字节码文件转化为Jimple格式文件，从而将代码分解成五种基本块，这些基本块暂时以独立的形式存在，不进行任何的处理；
步骤2、将提取的代码成分转换为Java源码，以精确编码每个代码成分的语义，直接使用社区中训练好的代码表示预训练模型实现代码成分向量化，获得代码成分语义向量；具体来说，将步骤1提取的Jimple格式文件基本块转化为Java源码，使用代码表示模型例如Python拷贝代码表示预训练模型PLBART镜像(可以使用其他代码表示模型，将Java源码输入到预训练模型中，模型的输出结果是每个代码成分的语义向量；
通过使用4种最先进的预训练代码表示模型来进行代码成分向量化，分别是CodeBERT、InferCode、Code5和PLBART；并且经过最终实验证明，使用PLBART和InferCode的实验效果是最好的；
步骤3、基于所述代码成分语义向量，将语义相似的代码成分聚类到同一组中，本步骤采用层次聚类算法(AGNES)来实现代码成分聚类任务。选择AGNES聚类主要有以下三个原因：(1)代码成分分布广泛，几乎不可能事先知道聚类数目。因此，需要预先设定聚类个数的聚类算法不再适用，如广泛使用的K-means算法。(2)聚类的代码成分个数较多，对大量样本聚类效果不好的算法不适用，如基于密度的算法(如DBSCAN)。(3)与许多广泛使用的聚类算法(如K-means和DBSCAN)相比，AGNES需要设置的参数数量更少，更易于在实际中使用。
代码成分聚类过程包括：
假设给定n个代码成分组I＝{i1,i2,...,in}，ik表示代码成分组I中的任意一个代码成分，并且通过代码表示模型将其向量化为代码成分语义向量组V＝{v1,c2,...,cn}，vx、,vy表示代码成分语义向量组V中的任意两个代码成分语义向量，然后通过聚类算法AGNES采用自底向上迭代地进行聚类的策略，得到代码成分语义向量聚类结果为代码成分类组G＝{g1,g2,...,gr}，聚类策略包括以下执行阶段：
在初始阶段，将每一种代码成分视为一个组，即代码成分类总数r等于代码成分语义向量总数n；
然后，在每次迭代中，计算每对组之间的距离，并将聚类最接近的两个组合并为一个组，直到所有代码成分放入同一个聚类中，即r等于1，如此完成从叶节点(初始组)到根节点(包含所有代码成分的组)构建层次嵌套聚类树的过程，测量聚类树中层次结构中每个组集合的质量；
最后，将得分值SC作为指标，输出聚类树中具有最高质量层次的代码成分组集合G作为最终聚类结果。
在迭代聚类过程中，(1)测量组与组之间的距离，(2)测量聚类树中层次结构中每个组集合的质量是两个核心步骤。
代码成分类组之间的距离davg(gp,gq)的计算公式如下：
其中，dist(vx,vy)表示两个代码成分语义向量vx、vy之间的欧几里得距离；
采用轮廓系数作为度量标准，综合衡量一个组的组内相似度与组间相似度，其得分值SC越接近1，聚类质量越高，具体公式如下：
其中，K表示代码成分总数，ak表示代码成分ik与同组其他代码成分之间的平均距离，bk表示代码成分代码成分ik与其他组代码成分之间的平均距离。使用该指标，获得质量最高(最接近1)的聚类结果，n表示代码成分组总数；
步骤4、重构代码成分，将步骤1中提取的代码成分按照步骤3得到的聚类结果重新划分；此外，因为存在Java代码处理工具保存一小部分Java代码失败和代码表示预训练模型对代码成分长度的限制，所以本发明做出了一定的妥协，对于无法保存的代码成分本发明将其归属于同一类，而代码无法向量化的代码则单独归为一类，因为代码成分的长度往往对应了更加复杂的上下文，这有助于本发明发现新的缺陷；
步骤5、对于步骤3得到的代码成分组集合G，通过执行以较大的概率选择有助于合成缺陷测试程序的组和被选择得更少的组应该以更大的概率被选择的反馈驱动的组选择策略，实现了缺陷揭示能力和多样性的代码成分组选择，将选择出来的代码成分合成到给定的种子程序中得到新的测试程序；其中，种子程序的选择是从种子程序池中随机选择一个种子程序，并且从种子程序可进行合成的位置中随机选择合成位置；通过反馈驱动策略选择代码成分后，将该代码成分合成到给定的种子程序中，合成新的测试程序。也就是说，在合成测试程序时，属于同一组的代码成分更有可能具有相同或相似的缺陷揭示能力。
在这里，没有固定一种代码成分作为测试程序合成的组的代表，因为在所选组中重复使用一种代码成分可能会导致比随机代码成分选择方法更少的多样性；
为了避免了随机组选择的低效、提高测试性能，在选择策略中考虑了：(1)缺陷揭示能力-以较大的概率选择有助于合成缺陷测试程序的组；(2)多样性-被选择得更少的组应该以更大的概率被选择。根据这两个标准，通过记录在执行过程中被选择的组生成的新测试程序是否检测到JVM不一致，以指导后续的组选择过程。具体来说，计算每个组在进行合成测试程序之前的权重，然后给予不同的选择概率。
权重的计算公式如下：
其中，si表示任意代码成分类组gi被选择的总次数，ti代表成任意代码成分类组gi成功发现缺陷的总次数。
表2
如表2所示的选择阶段的相关算法中，基于上述权重的计算公式，使用轮盘赌算法对每组的选择权重进行归一化处理，以平衡不同权重的比例(行5-7)。选择阶段的相关算法过程如下：
计算每个代码成分类组被选择的概率，计算公式如下所示：
其中，weight(gp)表示任意代码成分类组gp的权重，表示所有代码成分类组的权重的总和；
根据每个代码成分类组的选择概率，在构合成测试程序之前，首先选择一个代码成分类组例如gp(第8行)；
进一步从代码成分类组中选择一个代码成分，即由于同一组中的代码成分具有相似的语义，从其中随机选择一种代码成分作为用于测试程序合成的代码成分(第9行)。
步骤6、将待测的不同JVM输入步骤4得到的所述新的测试程序，比较不同JVM通过所述新的测试程序的输出来判断JVM是否出现错误，即通过匹配不同JVM在同一个测试程序上执行结果的一致性来判断是否触发JVM错误。
如表1所示，为种子程序的基本信息描述。显示了用作种子程序的测试项目的基本信息。前六个测试项目中的每一个都只包含一个种子程序(即包含main函数的类文件)。后两个测试项目包含更多的测试程序，它们分别是从HotSpot和OpenJ9的存储库中收集的历史错误揭示测试程序。由于增强测试预言会计算中间变量的校验和，因此从测试项目中删除了涉及多线程机制的种子程序。因此，后两个测试项目中的种子程序数量小于JavaTailor评估中使用的种子程序数量。在表1中，第四列表示每个测试项目中种子程序的Jimple指令总数，第五列表示设置的每个测试项目所花费的测试时间。对于历史测试程序，要求其能够有较高的缺陷发现能力，所以从HotSpot的一组历史缺陷揭示测试程序中提取了五类代码成分作为研究的代码成分池，总共包含31571个代码成分，包括16973个Sequential代码成分、8362个If代码成分、5812个Loop代码成分、397个Try-Catch代码成分和27个Switch代码成分。
表1
序号 项目名称 种子程序数量 指令数量 测试时间/秒
1 avrora 1 294 39017
2 eclipse 1 2057 144000
3 pmd 1 806 86400
4 jython 1 369 120783
5 fop 1 186 17168
6 Sunflow 1 305 34809
7 HotSpot-tests 563 116427 259200
8 Openj9-tests 653 246370 259200
尽管历史测试程序通常具有不同的语义，但是代码成分可能彼此共享相似的语义，从而导致相似的缺陷揭示能力。如图4所示，该示例图中展示了四个代码成分(ingredient)，代码成分1和代码成分2在语义上相似，代码成分3和代码成分4在语义上相似。这些具有相似语义的代码成分更有可能具有相似的漏洞揭示功能。通过将语义相似的代码成分放到同一个组中，使代码成分空间很大程度上缩减为较小的组空间，例如：将四个代码成分分为两组进行聚类，得到{代码成分-1，代码成分-2}和{代码成分-3、代码成分-4}。因此，本发明中的一个关键任务是精确编码每个代码成分的语义。
所述步骤2中，因为程序本身是包含大量严格的约束的，而将代码成分合成到种子程序的过程可能会破坏种子程序上下文的约束导致程序无法正常执行。为了解决这个问题，本发明沿用了JavaTailor中提出的相关策略。首先将代码片段中的所有函数调用都修改为public，这样能够使得种子程序能够成功的访问来自历史测试程序的代码片段中涉及到的函数。除此之外，代码成分中包含的参数和对象也是缺少定义的，为了能够增加合成后种子程序和代码成分的耦合性，尽可能使用种子程序中的类型相同的变量来替换代码成分中缺失的变量。而对于无法从上文中获取的变量则会获取对象的构造函数自动声明。
所述步骤5中，现有的JVM测试技术(包括最先进的JavaTailor)采用差异测试作为测试预言。具体来说，它们比较同一个测试程序在几个JVM(例如，HotSpot和OpenJ9)上的输出；如果输出不同，则表明测试程序在JVM之间触发了不一致。考虑两类输出：(1)测试程序异常终止时的异常消息或崩溃消息；(2)测试程序正常终止时的执行结果(根据测试程序中的输出变量产生)。在测试过程中，本发明采用了目前比较主流的JVM测试方法实现，即Hotspot、Openj9和BiSheng JDK。如表2所示，为本发明中使用的测试对象的信息。本发明选择目前使用人数最多的两个OpenJDK版本(即OpenJDK8及OpenJDK11)作为测试对象。对应的JVM及JVM版本如2-3列所示。
表2
然而，当将代码成分合成到种子程序时，代码成分很可能与种子程序中的输出语句没有依赖关系。因此，目前广泛使用的测试预言无法捕捉合成测试程序所触发的不一致性。也就是说，当不一致被代码成分中的变量触发并捕获时，由于它们之间没有依赖关系，它可能不会传播到输出语句。用一个例子来说明上述的情况，图4显示了一个HotSpot缺陷(ID：JDK-8290451，它在从C1编译器切换到C2编译器进行栈上替换时产生了不正确的结果)，通过将代码成分(图5中带阴影的代码)合并到种子程序(图5中没有阴影的代码)，可以合成出揭示缺陷的测试程序(没有用于校验和计算的第3行和第15行)。然而，原始的种子程序没有任何输出变量，因此无法通过输出比较来捕获此缺陷。这种情况在实践中很常见，同时代码成分中的变量与种子程序中的输出变量之间可能不存在依赖关系，也可能导致触发的缺陷无法通过输出比较捕获。在这个例子中，当在第15行监视var4的结果(或受其影响的变量，如var5和var6)时，可以通过差异测试来捕获这个缺陷。这促使测试程序合成的特点需要对各种中间变量的结果进行监控以进行差异测试，从而增强测试预言的错误捕获能力。
结合图3，在本发明实施例中：
上述的本发明整体流程进一步包括：为了解决当前因为测试预言不完备导致部分揭错测试用例被错过的问题，使新的测试程序在JVM测试中真正发挥作用，对合成测试程序中各种中间变量的执行结果进行监控，计算校验和作为差异测试的程序输出：
为了提高基于JVM的测试性能，结合测试程序合成的特点，对测试预言进行增强。也就是说，增强的测试预言不只是观察种子程序中输出变量的结果，而是监视合成测试程序中各种中间变量的结果。通过这种方式，受代码成分影响的程序状态也可以从差异测试的输出中反映出来。具体来说，本发明借鉴已有的工作，在合成测试程序中计算中间变量的校验和，而不是使用多条print语句来记录中间变量的运行结果(这会带来额外的I/O开销)。事实上，添加额外的校验和计算可能会对综合测试程序的执行效率产生负面影响。因此，在增强的测试预言中设计了一些妥协，以平衡测试的有效性和效率。首先，在计算校验和时考虑所有基本类型的全局变量和局部变量，而忽略引用类型的变量。这是因为后者可能具有递归引用的关系，分析和监控其中的所有成员变量可能代价高昂。其次，在测试程序中，每个变量的值往往会被更新多次，因此每次更新都执行校验和计算的开销可能很大。因此，通过静态分析确定了每个变量的最后一次访问，然后使用每个变量的最终值进行校验和计算。此外，一些变量涉及不确定性，如随机性和时间戳，这可能导致增强的测试预言不准确，从而导致误报。因此，本发明通过分析变量和不确定性指令(例如，系统指令和系统指令)之间的依赖关系，将它们从校验和计算中剔除。
上述本发明整体流程还进一步包括增强测试预言的处理，对新创建的所有基础变量计算哈希值，累加到全局变量CHECKSUM中，将全局变量CHECKSUM在程序正常终止时输出。通过增强测试预言，可以在合成测试程序正常终止时，通过校验和输出更好地捕获触发的不一致性。此外，当测试程序异常终止时，也根据异常消息或崩溃消息捕获测试程序的不一致性。在测试过程中捕获到不一致的测试程序往往包含大量的程序间依赖，如果直接提交给开发人员将会带来大量的分析成本，所以需要再提交之前经过人工简化之后提交给开发人员。
上述本发明整体流程中的合成测试程序执行还进一步包括：使用表2中提到的四个JVM实现执行增强后的测试程序，判断是否能够捕获差异。被捕获差异的测试程序需要后续的人工分析来确定缺陷发生的位置，并且简化测试程序，而未发现差异的测试程序则添加到种子文件池中等待后续的高阶变异。
如表3所示，为本发明的测试结果验证。
表3
J.T.：JavaTailor E.D.：Exception/Crash Difference C.D.：ChecksumDifference
针对五个JVM版本在8个测试集上进行实验，对比本发明方法和JavaTailor能够发现的唯一缺陷的数量。首先，JavaTailor检测到的不一致都是由于异常或崩溃(即测试程序异常终止)引起的，因为种子程序中的输出变量不能有效捕获合成后测试程序因为变量触发的错误。相比之下，本发明方法既能检测因异常或崩溃引起的不一致，也能检测正常执行引起的输出不一致。并且，后者在所有数据集上的唯一不一致数量更多，即在五个差异测试实验中，范围从62到123。实验结果表明，改进的测试预言通过检查和提高了基于合成的JVM测试的有效性。就异常/崩溃导致的独特不一致数量而言，本发明方法在所有5个差异测试实验中也优于JavaTailor。在相同的测试时间内，本发明方法的5次实验平均唯一不一致数为80.8次，JavaTailor为51.2次。在5个实验中，本发明方法相对JavaTailor的性能提升幅度为43.93％-223.08％。实验结果表明，与JavaTailor相比本发明方法通过代码表示和聚类对代码成分空间进行缩减，并设计了反馈驱动的代码成分选择策略，提高了JVM缺陷检测速度。总的来说，在相同的测试时间内，本发明方法在5个差异测试实验中比JavaTailor多检测出115.03％～776.92％的独特不一致，包括异常不一致性和输出不一致性。如表3所示，为JavaTailor和VECT在唯一不一致数量方面的比较结果。
进一步比较了本发明方法和JavaTailor在最新构建上的差异测试实验中发现先前未知的缺陷数量。JavaTailor在评估时发现了6个以前未知的错误，由开发人员确认或修复。在测试中使用了与JavaTailor相同的JVM构建，在相同的测试时间内，本发明方法也发现了所有的6个缺陷，同时进一步比较又发现了26个新的缺陷，其中15个已经被开发人员确认或修复。如表4所示，为利用本发明方法检测到的未知错误。其中显示了15个已确认/修复的先前未知的缺陷的信息。
表4
其中，由于异常/崩溃的不一致性，捕获了7个缺陷。理论上，如果运行JavaTailor足够长的时间，它们也可以被它检测到。在本发明方法和JavaTailor使用了相同的种子程序和代码片段的情况下，进一步证明了本发明方法能够极大地提高基于综合的JVM测试的效率。剩余的8个缺陷由于校验和结果不一致被本发明方法捕获，因此即使提供更长的测试时间，JavaTailor也无法检测到它们。这进一步表明，本发明方法也能够提高基于综合的JVM测试的有效性。
综上所述，本发明方法通过将语义相似的代码成分聚类到同一组，极大地减少了代码成分空间。通过这种方法，可以将庞大空间中的代码成分选择问题转化为较小空间中的组选择问题，从而提高了代码成分的探索效率和测试性能。虽然通过代码成分向量化和聚类可以大大减少搜索空间，但随机选择一组代码成分进行测试程序合成仍然限制了性能。这是因为不同的代码成分组可以有不同的生成缺陷揭示能力，平等对待它们可能会导致频繁生成无用的测试程序。因此，为了使提出的向量化JVM测试技术完整和有效，VECT在选择一个代码成分组后，根据测试结果设计了一个反馈驱动的组选择策略，目的是了解哪些组可以用更少的选择次数生成更多揭示错误的测试程序。最后，为了解决当前因为测试预言不完备导致部分揭错测试用例被错过的问题，使合成的测试程序在JVM测试中真正发挥作用，VECT监控合成测试程序中各种中间变量的执行结果，并计算校验和作为差异测试的程序输出。方法整体流程图如图2所示，将在下面介绍发明的详细内容。
需要说明的是，以上所述仅为本发明的优选实施例，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之下所做的任何修改、等同替换或改进等，均应落入本发明的保护范围之内。

Claims (8)

1.一种基于代码片段向量化的JVM测试方法，其特征在于，包括：
步骤1、输入历史测试程序以及种子测试程序，其中，对所述历史测试程序进行代码成分提取以及对所述种子测试程序进行初始化处理；
步骤2、将提取的代码成分转换为Java源码，使用社区中训练好的代码表示预训练模型实现代码成分向量化，获得代码成分语义向量；
步骤3、基于所述代码成分语义向量，将语义相似的代码成分聚类到同一组中；具体通过聚类算法AGNES采用自底向上迭代地进行聚类的策略，得到语义相似的代码成分语义向量聚类结果为代码成分类组G＝{g1,g2,...,gr}；
步骤4、重构代码成分，将步骤1中提取的代码成分按照步骤3得到的聚类结果重新划分，属于同一个代码成分组的代码成本分配到相同的列表当中；
步骤5、对于步骤3得到的代码成分组集合G，通过选择有助于合成缺陷测试程序的组和被选择得少的组以更大的概率被选择的反馈驱动的组选择策略，实现了从所有的代码成分组中选择满足缺陷揭示能力和多样性的代码成分组，然后在代码成分组中先随机选择一个代码成分组，再从组内选择一个代码成分，将选择出来的代码成分合成到给定的种子程序中得到新的测试程序；
步骤6、对待测的不同JVM输入步骤4得到的所述新的测试程序，通过匹配不同JVM在同一个测试程序上执行结果的一致性来判断是否触发JVM错误。
2.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，对于所述种子测试程序，获取种子程序中可访问的变量以及可进行合成的位置。
3.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，聚类策略包括以下执行阶段：在每次迭代中，计算每对组之间的距离，并将聚类最接近的两个组合并为一个组，直到所有代码成分放入同一类中，即r等于1，获得整个聚类过程中的迭代树，利用每次聚类迭代对应的结果，分析在不同的聚类类数的情况下的轮廓系数，从中获取每个组集合的质量最接近1的聚类结果。
4.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，测试程序合成的过程是直接将被选择的代码成分插入到种子程序代码当中，分析代码成分中缺少的变量声明，向上遍历寻找能够重用的变量，对于无法重用的变量声明直接新建变量。
5.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，该方法进一步包括增强测试预言的处理，对新创建的所有基础变量计算哈希值，累加到全局变量CHECKSUM中，将全局变量CHECKSUM在程序正常终止时输出。
6.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，对待测的JVM实现执行增强后的测试程序，判断是否能够捕获差异，被捕获差异的测试程序通过人工分析来确定缺陷发生的位置，未发现差异的测试程序则添加到种子文件池中等待后续的高阶变异。
7.如权利要求1所述的一种基于代码片段向量化的JVM测试方法，其特征在于，将得分值SC作为指标，输出聚类树中具有最高质量层次的代码成分组集合作为最终聚类结果。
8.如权利要求7所述的一种基于代码片段向量化的JVM测试方法，其特征在于，
其中，K表示代码成分总数，ak表示代码成分ik与同组其他代码成分之间的平均距离，bk表示代码成分代码成分ik与其他组代码成分之间的平均距离，n表示代码成分组总数。
CN202310800176.4A 2023-06-30 2023-06-30 一种基于代码片段向量化的jvm测试方法 Pending CN116661953A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310800176.4A CN116661953A (zh) 2023-06-30 2023-06-30 一种基于代码片段向量化的jvm测试方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310800176.4A CN116661953A (zh) 2023-06-30 2023-06-30 一种基于代码片段向量化的jvm测试方法

Publications (1)

Publication Number Publication Date
CN116661953A true CN116661953A (zh) 2023-08-29

Family

ID=87715337

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310800176.4A Pending CN116661953A (zh) 2023-06-30 2023-06-30 一种基于代码片段向量化的jvm测试方法

Country Status (1)

Country Link
CN (1) CN116661953A (zh)

Similar Documents

Publication Publication Date Title
Watson et al. On learning meaningful assert statements for unit test cases
White et al. Sorting and transforming program repair ingredients via deep learning code similarities
Messaoudi et al. A search-based approach for accurate identification of log message formats
Krishnan et al. Boostclean: Automated error detection and repair for machine learning
Xuan et al. Nopol: Automatic repair of conditional statement bugs in java programs
Le Goues et al. Current challenges in automatic software repair
US20190138731A1 (en) Method for determining defects and vulnerabilities in software code
JP2017519300A (ja) ソフトウェアアナリティクスのためのシステム及び方法
Xu et al. Largescale system problem detection by mining console logs
Zhang et al. Repairing bugs in python assignments using large language models
Kapdan et al. On the structural code clone detection problem: a survey and software metric based approach
Meng et al. Improving fault localization and program repair with deep semantic features and transferred knowledge
CN113468525A (zh) 针对二进制程序的相似漏洞检测方法及装置
CN115129591A (zh) 面向二进制代码的复现漏洞检测方法及系统
Pârțachi et al. Flexeme: Untangling commits using lexical flows
CN114969755A (zh) 一种跨语言的未知可执行程序二进制漏洞分析方法
Zhang et al. An empirical study on clone consistency prediction based on machine learning
Akimova et al. Pytracebugs: A large python code dataset for supervised machine learning in software defect prediction
Richter et al. Can we learn from developer mistakes? Learning to localize and repair real bugs from real bug fixes
Guan et al. A comprehensive study of real-world bugs in machine learning model optimization
Garcia et al. Hindsight logging for model training
Haben et al. The importance of discerning flaky from fault-triggering test failures: a case study on the Chromium CI
Le et al. Refixar: Multi-version reasoning for automated repair of regression errors
Ufuktepe et al. Tracking code bug fix ripple effects based on change patterns using markov chain models
Zhou et al. Deeptle: Learning code-level features to predict code performance before it runs

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination