CN117472757A - 一种文件异常测试方法、装置、存储介质及计算机设备 - Google Patents
一种文件异常测试方法、装置、存储介质及计算机设备 Download PDFInfo
- Publication number
- CN117472757A CN117472757A CN202311438011.3A CN202311438011A CN117472757A CN 117472757 A CN117472757 A CN 117472757A CN 202311438011 A CN202311438011 A CN 202311438011A CN 117472757 A CN117472757 A CN 117472757A
- Authority
- CN
- China
- Prior art keywords
- file
- java
- class
- test results
- package
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- 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/53—Decompilation; Disassembly
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Stored Programmes (AREA)
Abstract
本申请提供的一种文件异常测试方法、装置、存储介质及计算机设备,在对软件开发工具包进行文件异常测试时,可以获取升级后的软件开发工具包中待测试的压缩文件包,并在将压缩文件包中的各个Class文件反编译为多个Java文件后,依次识别并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,之后可以获取升级前的压缩文件包的历史测试结果,以将两次测试结果进行比较,并根据比较结果确定压缩文件包的最终测试结果。本申请通过对软件开发工具包升级前后分别产生的测试结果进行对比分析,得到最终测试结果,这样软件开发工具包可以在发布到生产前实现全面的自动化测试,进而提高测试质量和效率。
Description
技术领域
本申请涉及计算机技术领域,尤其涉及一种文件异常测试方法、装置、存储介质及计算机设备。
背景技术
在互联网时代,软件成了人们进入互联网的一个通道,各类软件开发已成为大众趋势所需,而软件的开发需要依靠SDK(Software Development Kit,软件开发工具包)完成。随着技术的不断发展和变化,SDK可能存在的一些问题或缺陷逐步出现,为了保证软件的质量和稳定性,开发人员需要定期升级SDK版本,以便利用新的功能和修复已知的问题。因此,定期升级SDK版本是软件开发过程中必不可少的一部分。
在SDK版本升级的过程中,可能会对其中的Class文件进行升级或引入新的Class文件,导致以此开发的软件在调用Class文件时找不到相应的功能,因此每次对SDK进行升级后,需要对升级后的SDK对应的Class文件进行测试。目前的测试方法需要将升级后的SDK发布到生产,以使测试人员可以从生产后软件产生的日志查看升级后的SDK是否存在Class类型异常,并在存在异常后执行回滚应用操作,进而通知开发人员进行修复,导致SDK的文件异常测试的效率较低,此外,软件的生产并没有全面调用到SDK的Class文件,因此至只根据软件产生的日志查看异常,将导致SDK的Class文件没能完全被测试到,进而影响SDK的文件异常测试质量。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一,特别是现有技术中需要将升级后的SDK发布到生产,以使测试人员可以从生产后软件产生的日志查看升级后的SDK是否存在Class类型异常,导致SDK的文件异常测试的效率和质量交底的技术缺陷。
本申请提供了一种文件异常测试方法,所述方法包括:
获取升级后的软件开发工具包中待测试的压缩文件包,所述压缩文件包中包含有多个Class文件;
对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果;
获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果。
可选地,所述获取升级后的软件开发工具包中待测试的压缩文件包,包括:
获取待测试的分支信息,并根据所述分支信息确定升级后的软件开发工具包中对应的部署分支;
对所述部署分支的各个源文件进行打包处理,得到待测试的压缩文件包。
可选地,所述对压缩文件包中的各个Class文件进行反编译得到多个Java文件,包括:
解压所述压缩文件包,并采用反射机制遍历解压后的压缩文件包中的各个Class文件;
将每一Class文件反编译为对应的Java文件,得到多个Java文件。
可选地,所述依次识别每一Java文件中的Class类型,包括:
对每一Java文件进行解析,得到各个Java文件中的变量语句;
提取每一变量语句的变量名和类型信息,并根据各个变量语句的变量名和类型信息生成对应的ASM代码;
采用ASM对各个ASM代码进行识别,得到每一Java文件中的Class类型。
可选地,所述检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,包括:
针对每一Java文件,判断该Java文件中的Class类型在其他Java文件中是否存在定义;
若是,则标记该Java文件中的Class类型为正常;
若否,则标记该Java文件中的Class类型为异常;
获取各个Java文件中Class类型的标记结果,形成当前测试结果。
可选地,所述将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果,包括:
从所述当前测试结果中筛选出标记结果为异常的Class类型,并将筛选后的Class类型与所述历史测试结果中对应的Class类型进行比较,并判断比较结果中是否存在Class类型的标记结果不一致;
若是,则确定所述压缩文件包的最终测试结果为异常;
若否,则确定所述压缩文件包的最终测试结果为正常。
可选地,所述方法还包括:
当所述压缩文件包的最终测试结果为异常时,确定比较结果中标记结果不一致的Class类型;
获取标记结果不一致的Class类型所在的Java文件的文件信息,并将所述Class类型和所述文件信息发送给对应的开发人员。
本申请还提供了一种文件异常测试装置,包括:
文件包获取模块,用于获取升级后的软件开发工具包中待测试的压缩文件包,所述压缩文件包中包含有多个Class文件;
文件检测模块,用于对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果;
文件包测试模块,用于获取升级前的软件开发工具包在文件异常测试过程中产生的历史测试结果,并将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果。
本申请还提供了一种存储介质,所述存储介质中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述文件异常测试方法的步骤。
本申请还提供了一种计算机设备,包括:一个或多个处理器,以及存储器;
所述存储器中存储有计算机可读指令,所述计算机可读指令被所述一个或多个处理器执行时,执行如上述实施例中任一项所述文件异常测试方法的步骤。
从以上技术方案可以看出,本申请实施例具有以下优点:
本申请提供的一种文件异常测试方法、装置、存储介质及计算机设备,在对软件开发工具包进行文件异常测试时,可以获取升级后的软件开发工具包中待测试的压缩文件包,该压缩文件包中包含有多个Class文件,接着可以对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,若Class类型缺乏定义,则说明对应的Class文件存在异常,无法调用;本申请还可以获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,进而根据比较结果确定压缩文件包的最终测试结果,此处通过对软件开发工具包升级前后的测试结果进行异常分析,可以判断软件开发工具包升级后Class文件的异常情况是否对软件的正常运转产生影响。本申请通过对软件开发工具包中的Class文件进行类型异常测试后,将测试结果与升级前的测试结果进行对比分析,从而得到最终测试结果,这样软件开发工具包可以在发布到生产前实现全面的自动化测试,进而提高测试质量和测试效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1为本申请实施例提供的一种文件异常测试方法的流程示意图;
图2为本申请实施例提供的一种Class类型测试方法的流程示意图;
图3为本申请实施例提供的一种压缩文件包测试方法的流程示意图;
图4为本申请实施例提供的一种文件异常测试装置的结构示意图;
图5为本申请实施例提供的一种计算机设备的内部结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在互联网时代,软件成了人们进入互联网的一个通道,各类软件开发已成为大众趋势所需,而软件的开发需要依靠SDK(Software Development Kit,软件开发工具包)完成。随着技术的不断发展和变化,SDK可能存在的一些问题或缺陷逐步出现,为了保证软件的质量和稳定性,开发人员需要定期升级SDK版本,以便利用新的功能和修复已知的问题。因此,定期升级SDK版本是软件开发过程中必不可少的一部分。
在SDK版本升级的过程中,可能会对其中的Class文件进行升级或引入新的Class文件,导致以此开发的软件在调用Class文件时找不到相应的功能,因此每次对SDK进行升级后,需要对升级后的SDK对应的Class文件进行测试。目前的测试方法需要将升级后的SDK发布到生产,以使测试人员可以从生产后软件产生的日志查看升级后的SDK是否存在Class类型异常,并在存在异常后执行回滚应用操作,进而通知开发人员进行修复,导致SDK的文件异常测试的效率较低,此外,软件的生产并没有全面调用到SDK的Class文件,因此至只根据软件产生的日志查看异常,将导致SDK的Class文件没能完全被测试到,进而影响SDK的文件异常测试质量。
基于此,本申请提出了如下技术方案,具体参见下文:
在一个实施例中,如图1所示,图1为本申请实施例提供的一种文件异常测试方法的流程示意图;本申请提供了一种文件异常测试方法,具体包括如下:
S110:获取升级后的软件开发工具包中待测试的压缩文件包,压缩文件包中包含有多个Class文件。
本步骤中,在软件开发工具包进行升级后,需要对升级后的软件开发工具包中的源文件进行异常测试,从而判断该升级后的软件开发工具包中增加或修改过的Class文件是否可以正常调用。此时,可以获取升级后的软件开发工具包中待测试的压缩文件包,以对压缩文件包中包含的多个Class文件逐一进行异常测试。
可以理解的是,软件开发工具包指的是为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合,它通过编译器、调试器、软件框架等来促进应用程序的创建,包括了用于调试和其他用途的实用工具以及示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。
另外,在软件开发工具包中,Class文件指的是Java类的字节码文件,即以.class为后缀名的二进制文件,它包含了Java类的所有信息,通常用于描述各种库和组件的功能和接口,以便开发人员可以更方便地使用和集成这些组件,其中包括了类的定义、方法、变量等,Class文件可以通过Java虚拟机进行解释和执行,实现软件的插件化、热部署、动态扩展等功能。因而对升级后的软件开发工具包进行异常测试,即为对软件开发工具包中的Class文件进行测试。
S120:对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果。
本步骤中,通过步骤S110得到包含有多个Class文件的压缩文件包后,可以先筛选出压缩文件包中的Class文件,以将各个Class文件进行反编译,得到多个Java文件,进而可以依次识别每一Java文件中的Class类型,在确定每一Java文件中的Class类型后,可以检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果。
可以理解的是,Class文件存储的为字节码,Java文件存储的为Java源代码,两者之间存在着一定的差异,字节码中包含了很多底层的指令和元数据信息,而Java源代码则包含了更多代码的实现理解,例如类的继承关系、方法的实现逻辑、变量的定义等,因此可以更好地进行源代码的分析、调试和优化等工作,因此,本申请中在对Class文件进行检测时,可以先将Class文件反编译为Java文件。
在Java文件中,Class类型指的是类的类型,其用于描述类的属性和方法等信息。在Java程序中,每个Java类都对应着一个Class类型,用于表示该类的类型,Class类型可以用于创建该类的实例对象,访问该类的属性和方法,以及进行类的继承和多态等操作。因此Java文件中的Class类型是Java程序的基础,它决定了Java程序的结构和行为。
举例来说,在Java文件中,Class类型的定义可以包括Java类、接口、枚举、注解。其中,Java类指的是Java程序的基本单位,它定义了一个对象的属性和方法,其可以被继承、实现接口和抽象类;接口指的是一种特殊的Java类,它只包含抽象方法和常量,可以用于描述一组相关的操作,也可以被多个Java类实现;枚举指的是一种特殊的Java类,它限制了对象的数量,只有预定义的几个对象可以被实例化,通常用于表示一组常量;注解指的是一种特殊的Java类,它可以用来为程序元素(如类、方法、变量等)添加额外的信息,通常用于编写框架、插件等。
需要说明的是,每个Java文件中可以定义一个或多个类,这些类可以被其他Java文件中的代码所引用和使用,并且这些类之间存在着继承、实现接口、组合等关系,如果一个类没有正确定义或引用,可能会导致程序出错或运行异常。而Java程序通常由多个Java文件组成的,这些Java文件之间存在着复杂的依赖关系,如果某个Java文件中的Class类型在其他Java文件中没有定义或定义错误,将会导致编译错误或运行错误,影响整个程序的正确性和可靠性。因此,在对Java文件进行异常测试时,可以检测每一Java文件中的Class类型在其他Java文件中是否存在定义,以确保依赖关系正确。
S130:获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,根据比较结果确定压缩文件包的最终测试结果。
本步骤中,通过步骤S120得到升级后的软件开发工具包的当前测试结果后,可以获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,从而可以根据比较结果确定压缩文件包的最终测试结果。
具体地,可以从存储的历史记录中获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,通过将历史测试结果与当前测试结果进行比较,可以判断升级前后压缩文件包的差异度,进而可以根据该差异度分析得到当前测试结果中的各个Java文件中的Class类型的定义变化,以查看是否对基于软件开发工具包开发的软件的运行产生影响,从而可以得到压缩文件包的最终测试结果。进一步地,本申请通过升级前后压缩文件包的差异比较,还可以判断当前测试结果的可靠性,当差异度超出预设范围后,差异度越大,说明当前测试结果的可靠性越低,此时需要进一步分析原因,并重新进行测试。
上述实施例中,在对软件开发工具包进行文件异常测试时,可以获取升级后的软件开发工具包中待测试的压缩文件包,该压缩文件包中包含有多个Class文件,接着可以对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,若Class类型缺乏定义,则说明对应的Class文件存在异常,无法调用;本申请还可以获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,进而根据比较结果确定压缩文件包的最终测试结果,此处通过对软件开发工具包升级前后的测试结果进行异常分析,可以判断软件开发工具包升级后Class文件的异常情况是否对软件的正常运转产生影响。本申请通过对软件开发工具包中的Class文件进行类型异常测试后,将测试结果与升级前的测试结果进行对比分析,从而得到最终测试结果,这样软件开发工具包可以在发布到生产前实现全面的自动化测试,进而提高测试质量和测试效率。
在一个实施例中,步骤S110中获取升级后的软件开发工具包中待测试的压缩文件包,可以包括:
S111:获取待测试的分支信息,并根据分支信息确定升级后的软件开发工具包中对应的部署分支。
S112:对部署分支的各个源文件进行打包处理,得到待测试的压缩文件包。
本实施例中,软件开发工具包中存在着一个主分支和多个部署分支,在对升级后的软件开发工具包进行测试时,可以先获取升级后需要测试的分支信息,并根据分支信息确定升级后的软件开发工具包中对应的部署分支,接着可以对部署分支的各个源文件进行打包,得到待测试的压缩文件包。
可以理解的是,为了更好地对软件开发工具包进行部署和管理,通常采用分支的方式进行团队协作开发,其中,主分支为软件开发工具包的主线,在团队协作过程中,每个成员都可以在本地创建自己的分支,在完成开发后,将分支合并到主分支上,这样可以将不同功能的开发任务分离开来,以便更好地管理和控制代码的质量。
具体地,在对软件开发工具包其中一个部署分支升级后需要对该部署分支进行文件异常测试,此时可以获取该部署分支的分支信息,如空间ID、域名、域组合应用类型等信息,进而可以在升级后的软件开发工具包中查找对应的部署分支,
举例来说,在一个软件开发工具包中,其中一个部署分支的空间ID为“space123”,域名为“www.example.com”,域组合的应用类型为“web+tomcat”,则该部署分支的名称为“space123/www.example.com/web+tomcat”。
进一步地,由于不同的软件开发工具包存在着不同格式和数量的源文件,该源文件通常以文本文件的形式存在,用于描述软件应用程序的源代码,常见的文本格式包括但不限于Java文件(.Java)、C++文件(.cpp)、Python文件(.py)等。为提高对软件开发工具包测试的兼容性以及提高测试效率,从软件开发工具包中确定待测试的部署分支后,可以获取该部署分支的各个源文件,并将其转换为Class文件,进而打包为压缩文件包,通过这样可以获取到该部署分支中包含多个Class文件的压缩文件包。
在一个实施例中,步骤S120中对压缩文件包中的各个Class文件进行反编译得到多个Java文件,可以包括:
S121:解压压缩文件包,并采用反射机制遍历解压后的压缩文件包中的各个Class文件。
S122:将每一Class文件反编译为对应的Java文件,得到多个Java文件。
本实施例中,在获取到软件开发工具包的压缩文件包后,可以先解压压缩文件包,并采用反射机制遍历解压后的压缩文件包,得到多个Class文件,为快速识别Class文件中的Class类型,进而得到类的继承关系和变量的定义,此时可以依次将每一Class文件反编译为对应的Java文件,得到多个Java文件。
可以理解的是,反射机制是指在运行时动态获取类的信息和操作类的属性和方法等的一种机制。在Java程序运行时,类和对象是静态的,即它们的属性和方法在编译时就已经确定,因此在需要在运行时动态获取类的信息和操作类的属性和方法等,可以使用反射机制。
具体地,在采用反射机制遍历解压后的压缩文件包,可以先遍历解压后的压缩文件包中的每一个条目,并判断该条目是否为Class文件,在此可以采用ZipEntry类的getName()方法来获取条目的名称,并判断名称是否以“.class”结尾;若条目是Class文件,则可以使用反射机制加载该Class,并调用其中的方法,本申请可以使用ClassLoader类的defineClass()方法来加载Class文件,并使用Class类型的getMethods()方法来获取其中的方法。通过该方法遍历压缩文件包后,在获取到各个Class文件的同时还可以确定每一Class文件中包含的Class类型的动态信息。
在一个实施例中,步骤S120中依次识别每一Java文件中的Class类型,可以包括:
S123:对每一Java文件进行解析,得到各个Java文件中的变量语句。
S124:提取每一变量语句的变量名和类型信息,并根据各个变量语句的变量名和类型信息生成对应的ASM代码。
S125:采用ASM对各个ASM代码进行识别,得到每一Java文件中的Class类型。
本实施例中,在识别每一Java文件中的Class类型时,可以先对每一Java文件进行解析,得到各个Java文件中的变量语句,接着可以提取每一变量语句的变量名和类型信息,并根据各个变量语句的变量名和类型信息生成对应的ASM代码,最后可以采用ASM从各个ASM代码进行读取每一Java文件中的Class类型。
需要说明的是,ASM指的是一个基于Java字节码操作的框架,它可以用于生成、转换和分析Java字节码,它提供了一个简单、轻量级的应用程序编程接口,可以方便地操作Java字节码,并且具有高效、灵活和可扩展的特点。除此之外,ASM还可以用于编写Java字节码增强工具、代码生成工具、反编译工具、代码分析工具等,被广泛应用于各种Java框架和库中,如Spring、Hibernate、MyBatis等。通过ASM,开发人员可以实现各种高级的功能和优化。
具体地,在对每一Java文件进行解析时,可以使用Java编译器或Java解析器,将Java文件中的源代码解析为抽象语法树,在抽象语法树中,每个变量语句都可以表示为一个变量节点,其中包含了变量名、变量类型、变量初始化表达式等信息,接着可以遍历抽象语法树,查找所有的变量节点,并提取其中的变量名和类型信息;在得到各个变量语句的变量名和类型信息后,可以采用ASM框架的ClassWriter类和FieldVisitor类将每一变量语句的变量名和类型信息转化为ASM代码,最后可以采用ASM框架的ClassReader类和ClassVisitor类对各个ASM代码进行识别,从而得到每一Java文件中的Class类型。
在一个实施例中,如图2所示,图2为本申请实施例提供的一种Class类型测试方法的流程示意图;图2中,步骤S120中检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,可以包括:
S126:针对每一Java文件,判断该Java文件中的Class类型在其他Java文件中是否存在定义;若是,则执行步骤S127,若否,则执行步骤S128。
S127:标记该Java文件中的Class类型为正常。
S128:标记该Java文件中的Class类型为异常。
S129:获取各个Java文件中Class类型的标记结果,形成当前测试结果。
本实施例中,在检测每一Java文件中的Class类型在其他Java文件中是否存在定义时,可以依次判断每一Java文件中的Class类型在其他Java文件中是否存在定义,并根据判断结果依次将对应的Java文件中的Class类型标记为异常或正常,最后可以获取各个Java文件中Class类型的标记结果,形成当前测试结果。
具体地,若Java文件中的Class类型在其他Java文件中存在定义,则说明该Class类型存在定义,可以被其他Java文件正常引用,对此可以将该Java文件中的Class类型标记为正常;若Java文件中的Class类型在其他Java文件不存在定义,则说明该Class类型存在异常,该异常在报错时被称为“类未找到异常”,此时Java文件在调用时无法找到对应的Class类型,导致软件无法正常运转,对此可以将该Java文件中的Class类型标记为异常。
可以理解的是,本申请中标记的Class类型指的是各个Java文件中引用的Class类型,通过判断引用的Class类型是否存在定义,可以确定对应的Java文件是否可以正常调用。因此,软件开发工具包在升级时引入了新的Class类型,在某些情况下,该新的Class类型仍未在其他Java文件中引用,即在开发软件时不需要使用到该Class类型,此时在对Java文件进行异常测试时,不需要对该未被其他Java文件引用的Class类型进行测试。
在一个实施例中,如图3所示,图3为本申请实施例提供的一种压缩文件包测试方法的流程示意图;图3中,步骤S130中将历史测试结果与当前测试结果进行比较,根据比较结果确定压缩文件包的最终测试结果,可以包括:
S131:从当前测试结果中筛选出标记结果为异常的Class类型,并将筛选后的Class类型与历史测试结果中对应的Class类型进行比较,并判断比较结果中是否存在Class类型的标记结果不一致,若是,则执行S132,若否,则执行S133。
S132:确定压缩文件包的最终测试结果为异常。
S133:确定压缩文件包的最终测试结果为正常。
本实施例中,在获取到历史测试结果与当前测试结果后,可以从当前测试结果中筛选出标记结果为异常的Class类型,并将筛选后的Class类型与历史测试结果中对应的Class类型进行比较,接着可以判断比较结果中是否存在Class类型的标记结果不一致;若是,则可以确定压缩文件包的最终测试结果为异常,若否,则可以确定压缩文件包的最终测试结果为正常。
具体地,若比较结果中存在Class类型的标记结果不一致,则说明该Class类型在历史测试结果中为正常,在升级前的软件开发工具包中可以正常调用,因此该Class类型在当前测试结果中的异常为软件开发工具包升级过程中出现的错误,该错误将会影响开发软件的正常运行,对此可以确定该升级后的压缩文件包的最终测试结果为异常;若比较结果中的Class类型的标记结果完全一致,则说明该Class类型在历史测试结果中同样为异常,由于升级前的软件开发工具包可以支持开发软件的正常运行,因此升级后软件开发工具包中Class类型的标记结果并不影响开发软件的正常运行,对此可以确定该升级后的压缩文件包的最终测试结果为正常。
在一个实施例中,方法还可以包括:
S140:当压缩文件包的最终测试结果为异常时,确定比较结果中标记结果不一致的Class类型。
S150:获取标记结果不一致的Class类型所在的Java文件的文件信息,并将Class类型和文件信息发送给对应的开发人员。
本实施例中,当压缩文件包的最终测试结果为异常时,说明压缩文件包存在的异常影响到开发软件的正常运行,此时可以确定比较结果中标记结果不一致的Class类型,进而获取标记结果不一致的Class类型所在的Java文件的文件信息,并将Class类型和文件信息发送给对应的开发人员,以便开发人员基于该Class类型和文件信息进行异常排查和修复。
可以理解的是,文件信息中包括了文件名、路径、版本号、作者等信息,因此可以根据文件信息确定对应的开发人员,即编写Java文件的作者,之后可以使用邮件、即时通讯工具、弹窗提醒等方式将Class类型和文件信息发送给对应的开发人员。
下面对本申请实施例提供的文件异常测试装置进行描述,下文描述的文件异常测试装置与上文描述的文件异常测试方法可相互对应参照。
在一个实施例中,如图4所示,图4为本申请实施例提供的一种文件异常测试装置的结构示意图;本申请提供了一种文件异常测试装置,包括文件包获取模块210、文件检测模块220和文件包测试模块230,具体包括如下:
文件包获取模块210,用于获取升级后的软件开发工具包中待测试的压缩文件包,压缩文件包中包含有多个Class文件。
文件检测模块220,用于对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果。
文件包测试模块230,用于获取升级前的软件开发工具包在文件异常测试过程中产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,根据比较结果确定压缩文件包的最终测试结果。
上述实施例中,在对软件开发工具包进行文件异常测试时,可以获取升级后的软件开发工具包中待测试的压缩文件包,该压缩文件包中包含有多个Class文件,接着可以对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,若Class类型缺乏定义,则说明对应的Class文件存在异常,无法调用;本申请还可以获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将历史测试结果与当前测试结果进行比较,进而根据比较结果确定压缩文件包的最终测试结果,此处通过对软件开发工具包升级前后的测试结果进行异常分析,可以判断软件开发工具包升级后Class文件的异常情况是否对软件的正常运转产生影响。本申请通过对软件开发工具包中的Class文件进行类型异常测试后,将测试结果与升级前的测试结果进行对比分析,从而得到最终测试结果,这样软件开发工具包可以在发布到生产前实现全面的自动化测试,进而提高测试质量和测试效率。
在一个实施例中,文件包获取模块210可以包括:
部署分支确定子模块,用于获取待测试的分支信息,并根据分支信息确定升级后的软件开发工具包中对应的部署分支。
文件打包子模块,用于对部署分支的各个源文件进行打包,得到待测试的压缩文件包。
在一个实施例中,文件检测模块220可以包括:
文件遍历子模块,用于解压压缩文件包,并采用反射机制遍历解压后的压缩文件包中的各个Class文件。
文件反编译子模块,用于将每一Class文件反编译为对应的Java文件,得到多个Java文件。
在一个实施例中,文件检测模块220还可以包括:
文件解析子模块,用于对每一Java文件进行解析,得到各个Java文件中的变量语句。
ASM代码生成子模块,用于提取每一变量语句的变量名和类型信息,并根据各个变量语句的变量名和类型信息生成对应的ASM代码。
类型识别子模块,用于采用ASM对各个ASM代码进行识别,得到每一Java文件中的Class类型。
在一个实施例中,文件检测模块220还可以包括:
定义判断子模块,用于针对每一Java文件,判断该Java文件中的Class类型在其他Java文件中是否存在定义。
第一标记子模块,用于标记该Java文件中的Class类型为异常。
第二标记子模块,用于标记该Java文件中的Class类型为正常;
测试结果生成子模块,用于获取各个Java文件中Class类型的标记结果,形成当前测试结果。
在一个实施例中,文件包测试模块230可以包括:
测试结果比较子模块,用于从当前测试结果中筛选出标记结果为异常的Class类型,并将筛选后的Class类型与历史测试结果中对应的Class类型进行比较,并判断比较结果中是否存在Class类型的标记结果不一致。
第一确定子模块,用于确定所述压缩文件包的最终测试结果为异常。
第一确定子模块,用于确定所述压缩文件包的最终测试结果为正常。
在一个实施例中,装置还可以包括:
类型确定模块,用于当压缩文件包的最终测试结果为异常时,确定比较结果中标记结果不一致的Class类型。
信息通知模块,用于获取标记结果不一致的Class类型所在的Java文件的文件信息,并将Class类型和文件信息发送给对应的开发人员。
在一个实施例中,本申请还提供了一种存储介质,所述存储介质中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述文件异常测试方法的步骤。
在一个实施例中,本申请还提供了一种计算机设备,所述计算机设备中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述文件异常测试方法的步骤。
示意性地,如图5所示,图5为本申请实施例提供的一种计算机设备的内部结构示意图,该计算机设备300可以被提供为一服务器。参照图5,计算机设备300包括处理组件302,其进一步包括一个或多个处理器,以及由存储器301所代表的存储器资源,用于存储可由处理组件302的执行的指令,例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件302被配置为执行指令,以执行上述任意实施例的文本识别方法。
计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理,一个有线或无线网络接口304被配置为将计算机设备300连接到网络,和一个输入输出(I/O)接口305。计算机设备300可以操作基于存储在存储器301的操作系统,例如WindowsServer TM、Mac OS XTM、Unix TM、Linux TM、Free BSDTM或类似。
本领域技术人员可以理解,图5中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间可以根据需要进行组合,且相同相似部分互相参见即可。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种文件异常测试方法,其特征在于,所述方法包括:
获取升级后的软件开发工具包中待测试的压缩文件包,所述压缩文件包中包含有多个Class文件;
对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果;
获取升级前的软件开发工具包在文件异常测试过程中对应的压缩文件包产生的历史测试结果,并将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果。
2.根据权利要求1所述的文件异常测试方法,其特征在于,所述获取升级后的软件开发工具包中待测试的压缩文件包,包括:
获取待测试的分支信息,并根据所述分支信息确定升级后的软件开发工具包中对应的部署分支;
对所述部署分支的各个源文件进行打包处理,得到待测试的压缩文件包。
3.根据权利要求1所述的文件异常测试方法,其特征在于,所述对压缩文件包中的各个Class文件进行反编译得到多个Java文件,包括:
解压所述压缩文件包,并采用反射机制遍历解压后的压缩文件包中的各个Class文件;
将每一Class文件反编译为对应的Java文件,得到多个Java文件。
4.根据权利要求1所述的文件异常测试方法,其特征在于,所述依次识别每一Java文件中的Class类型,包括:
对每一Java文件进行解析,得到各个Java文件中的变量语句;
提取每一变量语句的变量名和类型信息,并根据各个变量语句的变量名和类型信息生成对应的ASM代码;
采用ASM对各个ASM代码进行识别,得到每一Java文件中的Class类型。
5.根据权利要求1所述的文件异常测试方法,其特征在于,所述检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果,包括:
针对每一Java文件,判断该Java文件中的Class类型在其他Java文件中是否存在定义;
若是,则标记该Java文件中的Class类型为正常;
若否,则标记该Java文件中的Class类型为异常;
获取各个Java文件中Class类型的标记结果,形成当前测试结果。
6.根据权利要求5所述的文件异常测试方法,其特征在于,所述将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果,包括:
从所述当前测试结果中筛选出标记结果为异常的Class类型,并将筛选后的Class类型与所述历史测试结果中对应的Class类型进行比较,并判断比较结果中是否存在Class类型的标记结果不一致;
若是,则确定所述压缩文件包的最终测试结果为异常;
若否,则确定所述压缩文件包的最终测试结果为正常。
7.根据权利要求6所述的文件异常测试方法,其特征在于,所述方法还包括:
当所述压缩文件包的最终测试结果为异常时,确定比较结果中标记结果不一致的Class类型;
获取标记结果不一致的Class类型所在的Java文件的文件信息,并将所述Class类型和所述文件信息发送给对应的开发人员。
8.一种文件异常测试装置,其特征在于,包括:
文件包获取模块,用于获取升级后的软件开发工具包中待测试的压缩文件包,所述压缩文件包中包含有多个Class文件;
文件检测模块,用于对压缩文件包中的各个Class文件进行反编译得到多个Java文件后,依次识别每一Java文件中的Class类型,并检测每一Java文件中的Class类型在其他Java文件中是否存在定义,形成当前测试结果;
文件包测试模块,用于获取升级前的软件开发工具包在文件异常测试过程中产生的历史测试结果,并将所述历史测试结果与所述当前测试结果进行比较,根据比较结果确定所述压缩文件包的最终测试结果。
9.一种存储介质,其特征在于:所述存储介质中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如权利要求1至7中任一项所述文件异常测试方法的步骤。
10.一种计算机设备,其特征在于,包括:一个或多个处理器,以及存储器;
所述存储器中存储有计算机可读指令,所述计算机可读指令被所述一个或多个处理器执行时,执行如权利要求1至7中任一项所述文件异常测试方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311438011.3A CN117472757A (zh) | 2023-10-31 | 2023-10-31 | 一种文件异常测试方法、装置、存储介质及计算机设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311438011.3A CN117472757A (zh) | 2023-10-31 | 2023-10-31 | 一种文件异常测试方法、装置、存储介质及计算机设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117472757A true CN117472757A (zh) | 2024-01-30 |
Family
ID=89626974
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202311438011.3A Pending CN117472757A (zh) | 2023-10-31 | 2023-10-31 | 一种文件异常测试方法、装置、存储介质及计算机设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117472757A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN119376741A (zh) * | 2024-12-26 | 2025-01-28 | 麒麟软件有限公司 | Java迁移兼容性处理方法、装置及存储介质 |
-
2023
- 2023-10-31 CN CN202311438011.3A patent/CN117472757A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN119376741A (zh) * | 2024-12-26 | 2025-01-28 | 麒麟软件有限公司 | Java迁移兼容性处理方法、装置及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6287549B2 (ja) | ソースコードをポーティングする方法及び装置 | |
US20090055804A1 (en) | Method and device for automatically evaluating the quality of a software source code | |
Li et al. | Self-inferencing reflection resolution for Java | |
US20120159443A1 (en) | System and method for reducing test effort by object risk analysis | |
Acharya et al. | Mining API error-handling specifications from source code | |
CN108984416B (zh) | 一种评估Maven环境中依赖冲突危险级别的方法 | |
CN112181858B (zh) | Java软件项目依赖冲突语义一致性的自动化检测方法 | |
US10083029B2 (en) | Detect application defects by correlating contracts in application dependencies | |
Soares et al. | Analyzing refactorings on software repositories | |
CN117472757A (zh) | 一种文件异常测试方法、装置、存储介质及计算机设备 | |
Bartolomei et al. | Study of an API migration for two XML APIs | |
Nokhbeh Zaeem et al. | History-aware data structure repair using SAT | |
CN117235746B (zh) | 一种基于多维ast融合检测的源代码安全管控平台 | |
Pasala et al. | Selection of regression test suite to validate software applications upon deployment of upgrades | |
Mukelabai et al. | Semi-automated test-case propagation in fork ecosystems | |
Cazzola et al. | Dodging unsafe update points in java dynamic software updating systems | |
US20140289712A1 (en) | Effective Lifetime Dependency Analysis and Typestate Analysis | |
van de Laar et al. | Custom static analysis to enhance insight into the usage of in-house libraries | |
Paltoglou et al. | Automated refactoring of client-side JavaScript code to ES6 modules | |
Mahmud et al. | APICIA: An API Change Impact Analyzer for Android Apps | |
Ponomarenko et al. | A combined technique for automatic detection of backward binary compatibility problems | |
Isemann | Beyond debug information: Improving program reconstruction in LLDB using C++ modules | |
Pasala et al. | An approach for test suite selection to validate applications on deployment of COTS upgrades | |
Sui et al. | Demand-driven pointer analysis with strong updates via value-flow refinement | |
Gargantini et al. | AURORA: automatic robustness coverage analysis tool |
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 |