CN117472757A - File abnormality testing method and device, storage medium and computer equipment - Google Patents

File abnormality testing method and device, storage medium and computer equipment Download PDF

Info

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
class
java
package
test result
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
CN202311438011.3A
Other languages
Chinese (zh)
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.)
Vipshop Guangzhou Software Co Ltd
Original Assignee
Vipshop Guangzhou Software Co Ltd
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 Vipshop Guangzhou Software Co Ltd filed Critical Vipshop Guangzhou Software Co Ltd
Priority to CN202311438011.3A priority Critical patent/CN117472757A/en
Publication of CN117472757A publication Critical patent/CN117472757A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • 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—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • 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

According to the file exception testing method, the device, the storage medium and the computer equipment, when the file exception test is carried out on the software development kit, a compressed file package to be tested in the updated software development kit can be obtained, after each Class file in the compressed file package is decompiled into a plurality of Java files, whether definition exists in other Java files or not in Class types in each Java file is sequentially identified and detected, a current testing result is formed, then a historical testing result of the compressed file package before updating can be obtained, the two testing results are compared, and a final testing result of the compressed file package is determined according to the comparison result. According to the method and the device, the final test result is obtained by comparing and analyzing the test results respectively generated before and after the software development kit is upgraded, so that the software development kit can realize comprehensive automatic test before being released to production, and further the test quality and efficiency are improved.

Description

File abnormality testing method and device, storage medium and computer equipment
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method and apparatus for testing file abnormality, a storage medium, and a computer device.
Background
In the internet age, software forms a channel for people to enter the internet, various software development is required for the trend of the public, and the development of the software needs to be completed by means of an SDK (Software Development Kit ). With the continuous development and change of technology, some problems or defects possibly existing in the SDK gradually appear, and in order to ensure the quality and stability of software, developers need to upgrade the SDK version periodically so as to utilize new functions and fix known problems. Thus, periodic upgrades to the SDK version are an essential part of the software development process.
In the process of upgrading the SDK version, the Class files in the SDK version can be upgraded or new Class files can be introduced, so that the software developed by the method cannot find corresponding functions when the Class files are called, and therefore after the SDK is upgraded, the Class files corresponding to the upgraded SDK are required to be tested. The current test method needs to issue the updated SDK to production, so that a tester can check whether the updated SDK has Class type abnormality from a log generated by software after production, and execute rollback application operation after abnormality exists, and further inform a developer to repair the SDK, so that the efficiency of file abnormality test of the SDK is lower.
Disclosure of Invention
The present application aims to solve at least one of the above technical drawbacks, and particularly, in the prior art, it is necessary to issue an upgraded SDK to production, so that a tester can check from a log generated by software after production whether the upgraded SDK has a Class type abnormality, which results in technical defects of efficiency and quality of file abnormality test of the SDK.
The application provides a file anomaly testing method, which comprises the following steps:
obtaining a compressed file package to be tested in an upgraded software development kit, wherein the compressed file package comprises a plurality of Class files;
decompiling each Class file in the compressed file package to obtain a plurality of Java files, sequentially identifying Class types in each Java file, and detecting whether definition exists in other Java files or not in the Class types in each Java file to form a current test result;
and acquiring a historical test result generated by a compressed file package corresponding to the software development kit before upgrading in the file exception test process, comparing the historical test result with the current test result, and determining a final test result of the compressed file package according to the comparison result.
Optionally, the obtaining the compressed file package to be tested in the upgraded software development kit includes:
acquiring branch information to be tested, and determining a corresponding deployment branch in the upgraded software development kit according to the branch information;
and packaging each source file of the deployment branch to obtain a compressed file package to be tested.
Optionally, decompiling each Class file in the compressed file packet to obtain a plurality of Java files includes:
decompressing the compressed file package, and traversing each Class file in the decompressed compressed file package by adopting a reflection mechanism;
decompiling each Class file into a corresponding Java file to obtain a plurality of Java files.
Optionally, the identifying the Class type in each Java file in turn includes:
analyzing each Java file to obtain variable statements in each Java file;
extracting variable name and type information of each variable statement, and generating corresponding ASM codes according to the variable name and type information of each variable statement;
and identifying each ASM code by adopting ASM to obtain Class type in each Java file.
Optionally, the detecting whether the Class type in each Java file has a definition in other Java files, to form a current test result includes:
Judging whether definition exists in other Java files of Class type in each Java file;
if yes, marking the Class type in the Java file as normal;
if not, marking the Class type in the Java file as abnormal;
and obtaining the mark result of Class type in each Java file to form the current test result.
Optionally, the comparing the historical test result with the current test result, and determining the final test result of the compressed file packet according to the comparison result includes:
screening out Class types with abnormal marking results from the current test results, comparing the Class types after screening with corresponding Class types in the historical test results, and judging whether the marking results of the Class types are inconsistent or not in the comparison results;
if yes, determining that the final test result of the compressed file packet is abnormal;
if not, determining that the final test result of the compressed file packet is normal.
Optionally, the method further comprises:
when the final test result of the compressed file packet is abnormal, determining a Class type with inconsistent marking results in the comparison result;
and acquiring file information of Java files in which the Class types with inconsistent marking results are located, and transmitting the Class types and the file information to corresponding developers.
The application also provides a file abnormality testing device, which comprises:
the file package acquisition module is used for acquiring a compressed file package to be tested in the upgraded software development kit, wherein the compressed file package comprises a plurality of Class files;
the file detection module is used for carrying out decompilation on each Class file in the compressed file packet to obtain a plurality of Java files, sequentially identifying Class types in each Java file, and detecting whether definition exists in other Java files or not in the Class types in each Java file to form a current test result;
the file package testing module is used for acquiring a historical testing result generated in the file abnormality testing process of the software development kit before upgrading, comparing the historical testing result with the current testing result, and determining a final testing result of the compressed file package according to the comparison result.
The present application also provides a storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the file anomaly testing method as set forth in any one of the embodiments above.
The present application also provides a computer device comprising: one or more processors, and memory;
the memory has stored therein computer readable instructions which, when executed by the one or more processors, perform the steps of the file anomaly testing method as in any one of the embodiments above.
From the above technical solutions, the embodiments of the present application have the following advantages:
according to the file exception testing method, the device, the storage medium and the computer equipment, when the file exception test is carried out on the software development kit, a compressed file package to be tested in the updated software development kit can be obtained, the compressed file package comprises a plurality of Class files, then after decompiling can be carried out on each Class file in the compressed file package to obtain a plurality of Java files, class types in each Java file are sequentially identified, whether definition exists in other Java files or not in the Class types in each Java file is detected, a current testing result is formed, and if the definition is absent in the Class types, the fact that the corresponding Class files are abnormal and cannot be called is indicated; the method and the device can also obtain the historical test result generated by the compressed file package corresponding to the software development kit before upgrading in the file exception test process, compare the historical test result with the current test result, and further determine the final test result of the compressed file package according to the comparison result. According to the method and the device, after the type exception test is carried out on the Class files in the software development kit, the test result is compared and analyzed with the test result before upgrading, so that the final test result is obtained, and therefore the software development kit can realize comprehensive automatic test before being released to production, and further the test quality and the test efficiency are improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive faculty for a person skilled in the art.
Fig. 1 is a flow chart of a file anomaly testing method according to an embodiment of the present application;
FIG. 2 is a schematic flow chart of a Class type test method according to an embodiment of the present application;
FIG. 3 is a flow chart of a method for testing a compressed file packet according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of a file abnormality testing device according to an embodiment of the present application;
fig. 5 is a schematic diagram of an internal structure of a computer device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
In the internet age, software forms a channel for people to enter the internet, various software development is required for the trend of the public, and the development of the software needs to be completed by means of an SDK (Software Development Kit ). With the continuous development and change of technology, some problems or defects possibly existing in the SDK gradually appear, and in order to ensure the quality and stability of software, developers need to upgrade the SDK version periodically so as to utilize new functions and fix known problems. Thus, periodic upgrades to the SDK version are an essential part of the software development process.
In the process of upgrading the SDK version, the Class files in the SDK version can be upgraded or new Class files can be introduced, so that the software developed by the method cannot find corresponding functions when the Class files are called, and therefore after the SDK is upgraded, the Class files corresponding to the upgraded SDK are required to be tested. The current test method needs to issue the updated SDK to production, so that a tester can check whether the updated SDK has Class type abnormality from a log generated by software after production, and execute rollback application operation after abnormality exists, and further inform a developer to repair the SDK, so that the efficiency of file abnormality test of the SDK is lower.
Based on this, the following technical scheme is proposed in the present application, see specifically below:
in one embodiment, as shown in fig. 1, fig. 1 is a flow chart of a file anomaly testing method provided in an embodiment of the present application; the application provides a file abnormality testing method, which specifically comprises the following steps:
s110: and obtaining a compressed file package to be tested in the upgraded software development kit, wherein the compressed file package comprises a plurality of Class files.
In this step, after the software development kit is updated, an exception test is required to be performed on the source file in the updated software development kit, so as to determine whether the Class file added or modified in the updated software development kit can be normally called. At this time, the compressed file package to be tested in the upgraded software development kit can be obtained, so that the plurality of Class files contained in the compressed file package are subjected to abnormal test one by one.
It is to be understood that a software development kit refers to a collection of development tools that are used to build application software for a particular software package, software framework, hardware platform, operating system, etc., that facilitates application creation via compilers, debuggers, software frameworks, etc., including utilities for debugging and other uses as well as example code, supporting technical notes, or other supporting documents that clarify erasures for basic references.
In addition, in the software development kit, the Class file refers to a byte code file of a Java Class, namely a binary file taking Class as a suffix name, and the Class file contains all information of the Java Class and is generally used for describing functions and interfaces of various libraries and components, so that developers can use and integrate the components more conveniently, wherein the Class file comprises Class definitions, methods, variables and the like, and can be interpreted and executed through a Java virtual machine to realize functions of software plug-in, hot deployment, dynamic expansion and the like. And thus, the upgraded software development kit is subjected to abnormal test, namely, the Class files in the software development kit are tested.
S120: after decompiling each Class file in the compressed file package to obtain a plurality of Java files, sequentially identifying Class types in each Java file, and detecting whether definition exists in other Java files or not in the Class types in each Java file to form a current test result.
In this step, after obtaining a compressed file packet including a plurality of Class files through step S110, class files in the compressed file packet may be screened first to decompil each Class file to obtain a plurality of Java files, and then Class types in each Java file may be sequentially identified, and after determining Class types in each Java file, whether definitions exist in other Java files for Class types in each Java file may be detected, so as to form a current test result.
It can be understood that the Class file stores byte codes, the Java file stores Java source codes, certain difference exists between the byte codes and the Java source codes, the byte codes contain a plurality of bottom instructions and metadata information, and the Java source codes contain realization understanding of more codes, such as inheritance relation of classes, realization logic of methods, definition of variables and the like, so that the analysis, debugging, optimization and the like of the source codes can be better performed, and therefore, when the Class file is detected, the Class file can be decompiled into the Java file.
In the Java file, class type refers to a type of Class, which is used to describe information such as attributes and methods of the Class. In a Java program, each Java Class corresponds to a Class type, which is used to represent the Class type, and the Class type can be used to create an instance object of the Class, access the attribute and method of the Class, and perform operations such as inheritance and polymorphism of the Class. The Class type in a Java file is thus the basis of a Java program, which determines the structure and behavior of the Java program.
For example, in a Java file, definition of Class type may include Java Class, interface, enumeration, annotation. Wherein, java class refers to the basic unit of Java program, which defines the property and method of an object, and can be inherited, interface realized and abstract class; the interface refers to a special Java class, which only contains abstract methods and constants, can be used for describing a group of related operations, and can also be realized by a plurality of Java classes; enumeration refers to a special Java class that limits the number of objects, only a predefined few objects can be instantiated, typically to represent a set of constants; annotations refer to a special Java class that can be used to add additional information to program elements (e.g., classes, methods, variables, etc.), typically for writing frameworks, plug-ins, etc.
It should be noted that, one or more classes may be defined in each Java file, these classes may be referenced and used by codes in other Java files, and there are relationships among these classes such as inheritance, implementation interfaces, combinations, etc., which may cause program errors or abnormal operation if a class is not defined or referenced correctly. A Java program is usually composed of a plurality of Java files, and there is a complex dependency relationship between these Java files, if a Class type in a certain Java file is not defined or defined in other Java files, a compiling error or a running error will be caused, which affects the correctness and reliability of the whole program. Therefore, when the Java files are subjected to exception test, whether the Class type in each Java file has definition in other Java files can be detected, so that the dependency relationship is correct.
S130: the method comprises the steps of obtaining a historical test result generated by a compressed file package corresponding to a software development kit before upgrading in a file exception test process, comparing the historical test result with a current test result, and determining a final test result of the compressed file package according to the comparison result.
In this step, after the current test result of the updated software development kit is obtained in step S120, the historical test result generated by the compressed file package corresponding to the software development kit before the update in the file exception test process may be obtained, and the historical test result is compared with the current test result, so that the final test result of the compressed file package may be determined according to the comparison result.
Specifically, a history test result generated by a compressed file package corresponding to a software development kit before upgrading in a file exception test process can be obtained from a stored history record, the difference degree of the compressed file package before and after upgrading can be judged by comparing the history test result with a current test result, and further definition changes of Class types in each Java file in the current test result can be obtained according to the difference degree analysis, so that whether the operation of software developed based on the software development kit is influenced or not can be checked, and a final test result of the compressed file package can be obtained. Further, the reliability of the current test result can be judged through the difference comparison of the compressed file packages before and after upgrading, and when the difference exceeds the preset range, the higher the difference is, the lower the reliability of the current test result is indicated, at the moment, the further analysis of the reasons is needed, and the test is carried out again.
In the above embodiment, when a software development kit is subjected to file exception test, a compressed file package to be tested in the updated software development kit can be obtained, the compressed file package includes a plurality of Class files, then each Class file in the compressed file package can be decompiled to obtain a plurality of Java files, then Class types in each Java file can be sequentially identified, whether definition exists in other Java files of the Class types in each Java file is detected, a current test result is formed, and if the definition exists in the Class types, it is indicated that the corresponding Class file is abnormal and cannot be called; the method and the device can also obtain the historical test result generated by the compressed file package corresponding to the software development kit before upgrading in the file exception test process, compare the historical test result with the current test result, and further determine the final test result of the compressed file package according to the comparison result. According to the method and the device, after the type exception test is carried out on the Class files in the software development kit, the test result is compared and analyzed with the test result before upgrading, so that the final test result is obtained, and therefore the software development kit can realize comprehensive automatic test before being released to production, and further the test quality and the test efficiency are improved.
In one embodiment, the obtaining the compressed file package to be tested in the upgraded software development kit in step S110 may include:
s111: and acquiring the branch information to be tested, and determining the corresponding deployment branch in the upgraded software development kit according to the branch information.
S112: and packaging each source file of the deployment branch to obtain a compressed file package to be tested.
In this embodiment, a main branch and a plurality of deployment branches exist in a software development kit, when testing an upgraded software development kit, the method can firstly obtain branch information to be tested after upgrading, determine corresponding deployment branches in the upgraded software development kit according to the branch information, and then package each source file of the deployment branches to obtain a compressed file package to be tested.
It can be appreciated that, for better deployment and management of the software development kit, team collaborative development is generally performed in a branching manner, where a main branch is a main line of the software development kit, during team collaborative process, each member can locally create its own branch, and after development is completed, the branches are merged onto the main branch, so that development tasks with different functions can be separated to better manage and control quality of codes.
In particular, after one deployment branch of the software development kit is upgraded, file exception test is required to be carried out on the deployment branch, at this time, the branch information of the deployment branch, such as information of a space ID, a domain name, a domain combination application type and the like, can be obtained, and then the corresponding deployment branch can be searched in the upgraded software development kit,
for example, in a software development kit, where the space ID of one deployment branch is "space123", the domain name is "www.example.com", and the application type of the domain combination is "web+tomcat", then the deployment branch is named "space123/www.example.com/web+tomcat".
Further, because different software development kits exist in different formats and numbers of source files, the source files are typically in the form of text files that describe the source code of the software application, common text formats include, but are not limited to, java files (.Java), C++ files (.cpp), python files (.py), and the like. In order to improve the compatibility of the software development kit test and the test efficiency, after the deployment branch to be tested is determined from the software development kit, each source file of the deployment branch can be obtained and converted into a Class file, and then the Class file is packaged into a compressed file package, so that the compressed file package containing a plurality of Class files in the deployment branch can be obtained.
In one embodiment, decompiling each Class file in the compressed file package in step S120 to obtain a plurality of Java files may include:
s121: decompressing the compressed file package, and traversing each Class file in the decompressed compressed file package by adopting a reflection mechanism.
S122: decompiling each Class file into a corresponding Java file to obtain a plurality of Java files.
In this embodiment, after obtaining the compressed file package of the software development kit, the compressed file package may be decompressed first, and the decompressed compressed file package may be traversed by adopting a reflection mechanism to obtain a plurality of Class files, so as to quickly identify Class types in the Class files, and further obtain the inheritance relationship of the classes and the definition of the variables, and at this time, each Class file may be decompiled into a corresponding Java file in turn to obtain a plurality of Java files.
It is understood that the reflection mechanism refers to a mechanism that dynamically acquires information of a class and operates the attribute and method of the class at runtime, etc. When Java programs run, classes and objects are static, i.e. their properties and methods are determined at compile time, so reflection mechanisms can be used when it is necessary to dynamically acquire information of the class and to manipulate properties and methods of the class at run time, etc.
Specifically, when traversing the decompressed compressed file package by adopting a reflection mechanism, each item in the decompressed compressed file package can be traversed first, and whether the item is a Class file or not is judged, wherein the name of the item can be obtained by adopting a getName () method of ZipEntry Class, and whether the name ends with ". Class" can be judged; if the item is a Class file, the Class can be loaded using a reflection mechanism and the method therein can be invoked, the present application can use the defineClass () method of the Class loader Class to load the Class file and the getMethods () method of the Class type to obtain the method therein. After traversing the compressed file package by the method, dynamic information of Class types contained in each Class file can be determined while each Class file is acquired.
In one embodiment, identifying the Class type in each Java file in sequence in step S120 may include:
s123: and analyzing each Java file to obtain variable statements in each Java file.
S124: and extracting the variable name and type information of each variable statement, and generating a corresponding ASM code according to the variable name and type information of each variable statement.
S125: and identifying each ASM code by adopting ASM to obtain Class type in each Java file.
In this embodiment, when identifying the Class type in each Java file, each Java file may be parsed first to obtain variable statements in each Java file, then variable name and type information of each variable statement may be extracted, corresponding ASM codes may be generated according to the variable name and type information of each variable statement, and finally the Class type in each Java file may be read from each ASM code by using ASM.
It should be noted that ASM refers to a framework based on Java bytecode operation, which can be used to generate, convert, and analyze Java bytecode, and provides a simple, lightweight application programming interface, which can conveniently operate Java bytecode, and has the characteristics of high efficiency, flexibility, and scalability. In addition, ASM can be used to write Java bytecode enhancement tools, code generation tools, decompilation tools, code analysis tools, etc., and is widely used in various Java frameworks and libraries, such as Spring, hibernate, myBatis, etc. Through ASM, developers can implement various advanced functions and optimizations.
Specifically, when each Java file is parsed, a Java compiler or a Java parser may be used to parse source codes in the Java file into an abstract syntax tree, in the abstract syntax tree, each variable statement may be represented as a variable node, where information such as a variable name, a variable type, a variable initialization expression, etc. is included, and then the abstract syntax tree may be traversed to find all the variable nodes, and extract the variable names and the type information therein; after obtaining the variable name and type information of each variable statement, the Class writer Class and the field tester Class of the ASM framework can be used to convert the variable name and type information of each variable statement into ASM codes, and finally the Class reader Class and the Class tester Class of the ASM framework can be used to identify each ASM code, so that Class type in each Java file is obtained.
In one embodiment, as shown in fig. 2, fig. 2 is a schematic flow chart of a Class type test method provided in the embodiment of the present application; in fig. 2, in step S120, detecting whether a Class type in each Java file has a definition in other Java files, to form a current test result may include:
s126: judging whether definition exists in other Java files of Class type in each Java file; if yes, step S127 is executed, and if no, step S128 is executed.
S127: the Class type in the Java file is marked as normal.
S128: the Class type in the Java file is marked as abnormal.
S129: and obtaining the mark result of Class type in each Java file to form the current test result.
In this embodiment, when detecting whether a definition exists in other Java files in a Class type in each Java file, whether the definition exists in other Java files in the Class type in each Java file can be sequentially determined, the Class type in the corresponding Java file is sequentially marked as abnormal or normal according to the determination result, and finally, the marking result of the Class type in each Java file can be obtained to form the current test result.
Specifically, if the Class type in the Java file has a definition in other Java files, the Class type is indicated to have a definition, and the definition can be normally referenced by other Java files, so that the Class type in the Java file can be marked as normal; if the Class type in the Java file is not defined in other Java files, the Class type is indicated to have an exception, the exception is called as 'Class not found exception' when the exception is reported, at the moment, the Java file cannot find the corresponding Class type when the Java file is called, so that software cannot normally operate, and the Class type in the Java file can be marked as the exception.
It can be understood that the Class type marked in the application refers to the Class type cited in each Java file, and whether the corresponding Java file can be normally called can be determined by judging whether the definition exists in the cited Class type. Therefore, the software development kit introduces a new Class type at the time of upgrading, and in some cases, the new Class type is not yet referred to in other Java files, that is, the Class type does not need to be used when developing software, and at the time of performing exception testing on the Java files, the Class type which is not referred to by other Java files does not need to be tested.
In one embodiment, as shown in fig. 3, fig. 3 is a flow chart of a method for testing a compressed file packet according to an embodiment of the present application; in fig. 3, comparing the historical test result with the current test result in step S130, determining the final test result of the compressed file packet according to the comparison result may include:
s131: and screening out the Class type with the abnormal marking result from the current test result, comparing the Class type after screening with the corresponding Class type in the historical test result, judging whether the comparison result has inconsistent marking result of the Class type, if so, executing S132, and if not, executing S133.
S132: and determining the final test result of the compressed file package as abnormal.
S133: and determining the final test result of the compressed file package as normal.
In this embodiment, after the historical test result and the current test result are obtained, a Class type with an abnormal marking result can be screened from the current test result, the screened Class type is compared with a Class type corresponding to the historical test result, and then whether the marking result of the Class type is inconsistent or not can be judged; if so, the final test result of the compressed file packet can be determined to be abnormal, and if not, the final test result of the compressed file packet can be determined to be normal.
Specifically, if the comparison result has inconsistent mark results of the Class type, the Class type is normal in the historical test result, and can be normally called in the software development kit before upgrading, so that the abnormality of the Class type in the current test result is an error in the upgrading process of the software development kit, the error can influence the normal operation of the development software, and the final test result of the upgraded compressed file package can be determined to be abnormal; if the mark results of the Class type in the comparison result are completely consistent, the result indicates that the Class type is abnormal in the historical test result, and the final test result of the upgraded compressed file package can be determined to be normal because the software development kit before upgrading can support the normal operation of the development software, and therefore the mark results of the Class type in the software development kit after upgrading do not influence the normal operation of the development software.
In one embodiment, the method may further comprise:
s140: and when the final test result of the compressed file packet is abnormal, determining the Class type with inconsistent marking results in the comparison result.
S150: and acquiring file information of Java files in which the Class types with inconsistent marking results are located, and transmitting the Class types and the file information to corresponding developers.
In this embodiment, when the final test result of the compressed file packet is abnormal, it is indicated that the normal operation of the development software is affected by the abnormality of the compressed file packet, and at this time, the Class type with inconsistent marking results can be determined, so as to obtain the file information of the Java file with inconsistent marking results and send the Class type and the file information to the corresponding developer, so that the developer can perform abnormality detection and repair based on the Class type and the file information.
It can be understood that the file information includes information such as a file name, a path, a version number, an author, etc., so that a corresponding developer can be determined according to the file information, that is, the author writing the Java file, and then the Class type and the file information can be sent to the corresponding developer by means of mail, an instant messaging tool, a popup window reminding, etc.
The file abnormality testing device provided in the embodiment of the present application is described below, and the file abnormality testing device described below and the file abnormality testing method described above may be referred to correspondingly to each other.
In one embodiment, as shown in fig. 4, fig. 4 is a schematic structural diagram of a file abnormality testing device provided in the embodiment of the present application; the application provides a file exception testing device, which comprises a file package acquisition module 210, a file detection module 220 and a file package testing module 230, and specifically comprises the following steps:
The package obtaining module 210 is configured to obtain a compressed package to be tested in the upgraded software development kit, where the compressed package includes a plurality of Class files.
The file detection module 220 is configured to decompil each Class file in the compressed file packet to obtain a plurality of Java files, sequentially identify a Class type in each Java file, and detect whether a definition exists in other Java files for the Class type in each Java file, so as to form a current test result.
The file package testing module 230 is configured to obtain a historical testing result generated by the software development kit before upgrading in the file exception testing process, compare the historical testing result with a current testing result, and determine a final testing result of the compressed file package according to the comparison result.
In the above embodiment, when a software development kit is subjected to file exception test, a compressed file package to be tested in the updated software development kit can be obtained, the compressed file package includes a plurality of Class files, then each Class file in the compressed file package can be decompiled to obtain a plurality of Java files, then Class types in each Java file can be sequentially identified, whether definition exists in other Java files of the Class types in each Java file is detected, a current test result is formed, and if the definition exists in the Class types, it is indicated that the corresponding Class file is abnormal and cannot be called; the method and the device can also obtain the historical test result generated by the compressed file package corresponding to the software development kit before upgrading in the file exception test process, compare the historical test result with the current test result, and further determine the final test result of the compressed file package according to the comparison result. According to the method and the device, after the type exception test is carried out on the Class files in the software development kit, the test result is compared and analyzed with the test result before upgrading, so that the final test result is obtained, and therefore the software development kit can realize comprehensive automatic test before being released to production, and further the test quality and the test efficiency are improved.
In one embodiment, the package retrieval module 210 may include:
the deployment branch determination submodule is used for acquiring the branch information to be tested and determining the corresponding deployment branch in the upgraded software development kit according to the branch information.
And the file packing sub-module is used for packing each source file of the deployment branch to obtain a compressed file packet to be tested.
In one embodiment, the file detection module 220 may include:
the file traversing sub-module is used for decompressing the compressed file package and traversing each Class file in the decompressed compressed file package by adopting a reflection mechanism.
And the file decompiling sub-module is used for decompiling each Class file into a corresponding Java file to obtain a plurality of Java files.
In one embodiment, the file detection module 220 may further include:
and the file analysis sub-module is used for analyzing each Java file to obtain variable statements in each Java file.
And the ASM code generation sub-module is used for extracting the variable name and the type information of each variable statement and generating a corresponding ASM code according to the variable name and the type information of each variable statement.
And the type identification sub-module is used for identifying each ASM code by adopting ASM to obtain the Class type in each Java file.
In one embodiment, the file detection module 220 may further include:
and the definition judging sub-module is used for judging whether the Class type in each Java file has definition in other Java files or not according to each Java file.
And the first marking submodule is used for marking the Class type in the Java file as abnormal.
The second marking submodule is used for marking that the Class type in the Java file is normal;
and the test result generation sub-module is used for acquiring the Class type marking result in each Java file to form a current test result.
In one embodiment, the package testing module 230 may include:
the test result comparison sub-module is used for screening out Class types with abnormal marking results from the current test results, comparing the screened Class types with corresponding Class types in the historical test results, and judging whether the marking results of the Class types are inconsistent or not in the comparison results.
And the first determining submodule is used for determining that the final test result of the compressed file packet is abnormal.
And the first determining submodule is used for determining that the final test result of the compressed file packet is normal.
In one embodiment, the apparatus may further include:
And the type determining module is used for determining the Class type with inconsistent marking results in the comparison result when the final test result of the compressed file packet is abnormal.
The information notification module is used for acquiring file information of Java files in which the Class types with inconsistent marking results are located and sending the Class types and the file information to corresponding developers.
In one embodiment, the present application also provides a storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the file anomaly testing method as set forth in any one of the embodiments above.
In one embodiment, the present application also provides a computer device having stored therein computer readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the file anomaly testing method as set forth in any one of the embodiments above.
Schematically, as shown in fig. 5, fig. 5 is a schematic internal structure of a computer device according to an embodiment of the present application, and the computer device 300 may be provided as a server. Referring to FIG. 5, computer device 300 includes a processing component 302 that further includes one or more processors, and memory resources represented by memory 301, for storing instructions, such as applications, executable by processing component 302. The application program stored in the memory 301 may include one or more modules each corresponding to a set of instructions. Further, the processing component 302 is configured to execute instructions to perform the text recognition method of any of the embodiments described above.
The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input output (I/O) interface 305. The computer device 300 may operate based on an operating system stored in memory 301, such as Windows Server TM, mac OS XTM, unix TM, linux TM, free BSDTM, or the like.
It will be appreciated by those skilled in the art that the structure shown in fig. 5 is merely a block diagram of some of the structures associated with the present application and is not limiting of the computer device to which the present application may be applied, and that a particular computer device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.
Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
In the present specification, each embodiment is described in a progressive manner, and each embodiment focuses on the difference from other embodiments, and may be combined according to needs, and the same similar parts may be referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A method for testing file anomalies, the method comprising:
obtaining a compressed file package to be tested in an upgraded software development kit, wherein the compressed file package comprises a plurality of Class files;
decompiling each Class file in the compressed file package to obtain a plurality of Java files, sequentially identifying Class types in each Java file, and detecting whether definition exists in other Java files or not in the Class types in each Java file to form a current test result;
And acquiring a historical test result generated by a compressed file package corresponding to the software development kit before upgrading in the file exception test process, comparing the historical test result with the current test result, and determining a final test result of the compressed file package according to the comparison result.
2. The method for testing file abnormality according to claim 1, wherein the obtaining the compressed file package to be tested in the upgraded software development kit includes:
acquiring branch information to be tested, and determining a corresponding deployment branch in the upgraded software development kit according to the branch information;
and packaging each source file of the deployment branch to obtain a compressed file package to be tested.
3. The method for testing file abnormality according to claim 1, wherein decompiling each Class file in the compressed file package to obtain a plurality of Java files, includes:
decompressing the compressed file package, and traversing each Class file in the decompressed compressed file package by adopting a reflection mechanism;
decompiling each Class file into a corresponding Java file to obtain a plurality of Java files.
4. The method for testing file abnormality according to claim 1, wherein said identifying Class type in each Java file in turn comprises:
Analyzing each Java file to obtain variable statements in each Java file;
extracting variable name and type information of each variable statement, and generating corresponding ASM codes according to the variable name and type information of each variable statement;
and identifying each ASM code by adopting ASM to obtain Class type in each Java file.
5. The method for testing file exception according to claim 1, wherein said detecting whether the Class type in each Java file has a definition in other Java files, forming a current test result, comprises:
judging whether definition exists in other Java files of Class type in each Java file;
if yes, marking the Class type in the Java file as normal;
if not, marking the Class type in the Java file as abnormal;
and obtaining the mark result of Class type in each Java file to form the current test result.
6. The method of claim 5, wherein comparing the historical test results with the current test results and determining the final test result of the compressed package based on the comparison results comprises:
Screening out Class types with abnormal marking results from the current test results, comparing the Class types after screening with corresponding Class types in the historical test results, and judging whether the marking results of the Class types are inconsistent or not in the comparison results;
if yes, determining that the final test result of the compressed file packet is abnormal;
if not, determining that the final test result of the compressed file packet is normal.
7. The method of claim 6, further comprising:
when the final test result of the compressed file packet is abnormal, determining a Class type with inconsistent marking results in the comparison result;
and acquiring file information of Java files in which the Class types with inconsistent marking results are located, and transmitting the Class types and the file information to corresponding developers.
8. A document anomaly testing device, comprising:
the file package acquisition module is used for acquiring a compressed file package to be tested in the upgraded software development kit, wherein the compressed file package comprises a plurality of Class files;
the file detection module is used for carrying out decompilation on each Class file in the compressed file packet to obtain a plurality of Java files, sequentially identifying Class types in each Java file, and detecting whether definition exists in other Java files or not in the Class types in each Java file to form a current test result;
The file package testing module is used for acquiring a historical testing result generated in the file abnormality testing process of the software development kit before upgrading, comparing the historical testing result with the current testing result, and determining a final testing result of the compressed file package according to the comparison result.
9. A storage medium, characterized by: the storage medium having stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the file anomaly testing method of any one of claims 1 to 7.
10. A computer device, comprising: one or more processors, and memory;
stored in the memory are computer readable instructions which, when executed by the one or more processors, perform the steps of the file anomaly testing method of any one of claims 1 to 7.
CN202311438011.3A 2023-10-31 2023-10-31 File abnormality testing method and device, storage medium and computer equipment Pending CN117472757A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311438011.3A CN117472757A (en) 2023-10-31 2023-10-31 File abnormality testing method and device, storage medium and computer equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311438011.3A CN117472757A (en) 2023-10-31 2023-10-31 File abnormality testing method and device, storage medium and computer equipment

Publications (1)

Publication Number Publication Date
CN117472757A true CN117472757A (en) 2024-01-30

Family

ID=89626974

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311438011.3A Pending CN117472757A (en) 2023-10-31 2023-10-31 File abnormality testing method and device, storage medium and computer equipment

Country Status (1)

Country Link
CN (1) CN117472757A (en)

Similar Documents

Publication Publication Date Title
JP6287549B2 (en) Method and apparatus for porting source code
US10691808B2 (en) Vulnerability analysis of software components
US9208057B2 (en) Efficient model checking technique for finding software defects
US20070169027A1 (en) Methods and systems for complete static analysis of software for building a system
US9880832B2 (en) Software patch evaluator
US7614040B2 (en) System and method for efficiently analyzing and building interdependent resources in a software project
Mirzaaghaei et al. Supporting test suite evolution through test case adaptation
US8381175B2 (en) Low-level code rewriter verification
US8122440B1 (en) Method and apparatus for enumerating external program code dependencies
US20070256069A1 (en) Dependency-based grouping to establish class identity
Zhong et al. Boosting complete-code tool for partial program
Neitsch et al. Build system issues in multilanguage software
Chen et al. Extracting and studying the Logging-Code-Issue-Introducing changes in Java-based large-scale open source software systems
Soares et al. Analyzing refactorings on software repositories
Sun et al. Automatically assessing and extending code coverage for NPM packages
CN117472757A (en) File abnormality testing method and device, storage medium and computer equipment
Borodin et al. Deterministic static analysis
Chen et al. Tracking down dynamic feature code changes against Python software evolution
Sotiropoulos et al. The additional testsuite framework: facilitating software testing and test management
CN117235746B (en) Source code safety control platform based on multidimensional AST fusion detection
US11829751B1 (en) System and method for automatically capturing source code and associated artifacts for static analysis
Kodhai et al. Detecting and investigating the source code changes using logical rules
Kester CheckMerge: A System for Risk Assessment of Code Merges
JALILI KORDKANDI Towards Change Validation in Dynamic System Updating Frameworks
van de Laar et al. Custom static analysis to enhance insight into the usage of in-house libraries

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