A file exception test method and device, a storage medium and a computer device

Abstract

The file exception test method, device, storage medium and computer equipment provided by the application can obtain the compressed file package to be tested in the upgraded software development kit, and after each Class file in the compressed file package is decompiled into multiple Java files, the Class type in each Java file is identified and detected in turn to determine whether the definition exists in other Java files, to form the current test result. Then, the historical test result of the compressed file package before upgrading can be obtained to compare the two test results, and the final test result of the compressed file package can be determined according to the comparison result. The application compares and analyzes the test results generated before and after the software development kit is upgraded to obtain the final test result. In this way, the software development kit can realize comprehensive automatic testing before being released to production, thereby improving the test quality and efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and computer equipment for testing file anomalies. Background Technology

[0002] In the internet age, software has become a gateway for people to access the internet, and software development has become a widespread trend. Software development relies on SDKs (Software Development Kits). As technology continues to evolve, problems and defects may emerge in SDKs. To ensure software quality and stability, developers need to regularly upgrade SDK versions to utilize new features and fix known issues. Therefore, regularly upgrading SDK versions is an essential part of the software development process.

[0003] During SDK version upgrades, class files may be upgraded or new class files may be introduced. This can cause software developed based on this to fail to find the corresponding functions when calling class files. Therefore, after each SDK upgrade, the corresponding class files of the upgraded SDK need to be tested. Current testing methods require releasing the upgraded SDK to production so that testers can check the logs generated by the software after production for class type anomalies. If anomalies are found, an application rollback is performed, and developers are notified to fix them. This results in low efficiency for SDK file anomaly testing. Furthermore, production software does not fully utilize the SDK's class files; therefore, relying solely on logs for anomalies means that the SDK's class files are not fully tested, thus affecting the quality of SDK file anomaly testing. Summary of the Invention

[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency in the prior art where the upgraded SDK needs to be released to production so that testers can check the logs generated by the software after production to see if there are any Class type anomalies in the upgraded SDK, which leads to abnormal SDK file testing efficiency and quality disclosure.

[0005] This application provides a method for testing file anomalies, the method comprising:

[0006] Obtain the compressed file package to be tested from the upgraded software development kit, wherein the compressed file package contains multiple Class files;

[0007] After decompiling each Class file in the compressed file package to obtain multiple Java files, the Class type in each Java file is identified in turn, and it is checked whether the Class type in each Java file is defined in other Java files to form the current test result;

[0008] Obtain the historical test results of the compressed file package corresponding to the software development kit before the upgrade during the file anomaly test, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison result.

[0009] Optionally, obtaining the compressed file package to be tested from the upgraded software development kit includes:

[0010] Obtain the branch information to be tested, and determine the corresponding deployment branch in the upgraded software development kit based on the branch information;

[0011] The source files of the deployment branch are packaged to obtain a compressed file package to be tested.

[0012] Optionally, the process of decompiling the various Class files in the compressed file package to obtain multiple Java files includes:

[0013] Decompress the compressed file package and use reflection to traverse each Class file in the decompressed compressed file package;

[0014] Each Class file is decompiled into a corresponding Java file, resulting in multiple Java files.

[0015] Optionally, the step of sequentially identifying the Class type in each Java file includes:

[0016] Each Java file is parsed to obtain the variable statements in each Java file;

[0017] Extract the variable name and type information of each variable statement, and generate the corresponding ASM code based on the variable name and type information of each variable statement;

[0018] ASM is used to identify each ASM code and obtain the Class type in each Java file.

[0019] Optionally, the step of detecting whether the Class type in each Java file is defined in other Java files to form the current test result includes:

[0020] For each Java file, determine whether the Class type in that Java file is defined in other Java files;

[0021] If so, mark the Class type in the Java file as normal;

[0022] If not, mark the Class type in the Java file as an exception;

[0023] Obtain the Class type marking results from each Java file to form the current test results.

[0024] Optionally, comparing the historical test results with the current test results and determining the final test result of the compressed file package based on the comparison result includes:

[0025] The class types marked as abnormal are filtered from the current test results, and the filtered class types are compared with the corresponding class types in the historical test results. It is then determined whether there are any inconsistencies in the marking results of the class types in the comparison results.

[0026] If so, then the final test result of the compressed file package is determined to be abnormal;

[0027] If not, then the final test result of the compressed file package is determined to be normal.

[0028] Optionally, the method further includes:

[0029] When the final test result of the compressed file package is abnormal, determine the Class type of the inconsistent marking results in the comparison results;

[0030] Obtain the file information of the Java file containing the Class type with inconsistent marking results, and send the Class type and the file information to the corresponding developer.

[0031] This application also provides a document anomaly testing apparatus, including:

[0032] The file package acquisition module is used to acquire the compressed file package to be tested in the upgraded software development kit, wherein the compressed file package contains multiple Class files;

[0033] The file detection module is used to decompile each Class file in the compressed file package to obtain multiple Java files, then identify the Class type in each Java file in turn, and check whether the Class type in each Java file is defined in other Java files to form the current test result.

[0034] The file package testing module is used to obtain historical test results generated by the software development kit before the upgrade during the file anomaly testing process, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison result.

[0035] This application also provides a storage medium storing 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 described in any of the above embodiments.

[0036] This application also provides a computer device, including: one or more processors, and memory;

[0037] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the file anomaly testing method as described in any of the above embodiments.

[0038] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0039] This application provides a file anomaly testing method, apparatus, storage medium, and computer equipment. When performing file anomaly testing on a software development kit (SDK), it can obtain a compressed file package to be tested from the upgraded SSD. This compressed file package contains multiple Class files. Then, it can decompile each Class file in the compressed file package to obtain multiple Java files. The Class type in each Java file is then identified sequentially, and it is checked whether the Class type in each Java file is defined in other Java files, forming the current test result. If the Class type lacks a definition, it indicates that the corresponding Class file is abnormal and cannot be called. This application can also obtain historical test results generated by the compressed file package corresponding to the SSD before the upgrade during file anomaly testing, and compare the historical test results with the current test results. Based on the comparison results, the final test result of the compressed file package is determined. Here, by performing anomaly analysis on the test results before and after the SSD upgrade, it is possible to determine whether the anomalies in the Class files after the SSD upgrade affect the normal operation of the software. This application performs type anomaly testing on the Class files in the software development kit (SDK), compares and analyzes the test results with the test results before the upgrade, and obtains the final test results. In this way, the SSD can achieve comprehensive automated testing before being released to production, thereby improving test quality and testing efficiency. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 A flowchart illustrating a file anomaly testing method provided in this application embodiment;

[0042] Figure 2 A flowchart illustrating a Class type testing method provided in an embodiment of this application;

[0043] Figure 3 A flowchart illustrating a method for testing compressed file packages provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of a document anomaly testing device provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] In the internet age, software has become a gateway for people to access the internet, and software development has become a widespread trend. Software development relies on SDKs (Software Development Kits). As technology continues to evolve, problems and defects may emerge in SDKs. To ensure software quality and stability, developers need to regularly upgrade SDK versions to utilize new features and fix known issues. Therefore, regularly upgrading SDK versions is an essential part of the software development process.

[0048] During SDK version upgrades, class files may be upgraded or new class files may be introduced. This can cause software developed based on this to fail to find the corresponding functions when calling class files. Therefore, after each SDK upgrade, the corresponding class files of the upgraded SDK need to be tested. Current testing methods require releasing the upgraded SDK to production so that testers can check the logs generated by the software after production for class type anomalies. If anomalies are found, an application rollback is performed, and developers are notified to fix them. This results in low efficiency for SDK file anomaly testing. Furthermore, production software does not fully utilize the SDK's class files; therefore, relying solely on logs for anomalies means that the SDK's class files are not fully tested, thus affecting the quality of SDK file anomaly testing.

[0049] Based on this, this application proposes the following technical solution, as detailed below:

[0050] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a file anomaly testing method provided in an embodiment of this application. The application provides a file anomaly testing method, specifically including the following:

[0051] S110: Obtain the compressed file package to be tested from the upgraded software development kit. The compressed file package contains multiple Class files.

[0052] In this step, after upgrading the software development kit (SDK), it is necessary to perform anomaly testing on the source files in the upgraded SSD to determine whether the added or modified Class files in the upgraded SSD can be called normally. At this time, the compressed file package to be tested in the upgraded SSD can be obtained, and anomaly testing can be performed on each of the multiple Class files contained in the compressed file package.

[0053] As is understandable, a software development kit (SDK) refers to a collection of development tools used to build application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. It facilitates application creation through compilers, debuggers, software frameworks, etc., and includes utilities for debugging and other purposes, as well as sample code, supporting technical annotations, or other supporting documentation to clarify doubts for basic reference materials.

[0054] Furthermore, in a software development kit (SDK), a Class file refers to the bytecode file of a Java class, i.e., a binary file with the .class extension. It contains all the information about the Java class and is typically used to describe the functionality and interfaces of various libraries and components, making it easier for developers to use and integrate these components. This includes class definitions, methods, variables, etc. Class files can be interpreted and executed by the Java Virtual Machine (JVM), enabling features such as software plug-in functionality, hot deployment, and dynamic extensibility. Therefore, performing anomaly testing on an upgraded SSD is equivalent to testing the Class files within the SSD.

[0055] S120: After decompiling each Class file in the compressed file package to obtain multiple Java files, the Class type in each Java file is identified in turn, and the Class type in each Java file is checked to see if it is defined in other Java files, thus forming the current test result.

[0056] In this step, after obtaining the compressed file package containing multiple Class files through step S110, the Class files in the compressed file package can be filtered out first, and each Class file can be decompiled to obtain multiple Java files. Then, the Class type in each Java file can be identified in turn. After determining the Class type in each Java file, it can be checked whether the Class type in each Java file is defined in other Java files to form the current test result.

[0057] It is understandable that Class files store bytecode, while Java files store Java source code. There are certain differences between the two. Bytecode contains a lot of low-level instructions and metadata information, while Java source code contains more implementation details, such as class inheritance relationships, method implementation logic, and variable definitions. Therefore, it is possible to better analyze, debug, and optimize the source code. Thus, in this application, when testing Class files, the Class files can be decompiled into Java files first.

[0058] In Java files, the Class type refers to the type of a class, used to describe information such as the class's attributes and methods. In a Java program, each Java class corresponds to a Class type, representing its type. The Class type can be used to create instances of that class, access its attributes and methods, and perform operations such as class inheritance and polymorphism. Therefore, the Class type in a Java file is fundamental to Java programs, determining their structure and behavior.

[0059] For example, in a Java file, the definition of the `Class` type can include Java classes, interfaces, enumerations, and annotations. A Java class is the basic unit of a Java program; it defines the attributes and methods of an object and can be inherited, implemented through interfaces, or abstract classes. An interface is a special type of Java class that contains only abstract methods and constants, used to describe a set of related operations, and can be implemented by multiple Java classes. An enumeration is a special type of Java class that limits the number of objects; only a few predefined objects can be instantiated, typically used to represent a set of constants. An annotation is a special type of Java class that can be used to add additional information to program elements (such as classes, methods, variables, etc.), typically used in writing frameworks and plugins.

[0060] It's important to note that each Java file can define one or more classes. These classes can be referenced and used by code in other Java files, and relationships such as inheritance, interface implementation, and composition exist between them. If a class is not correctly defined or referenced, it may cause program errors or runtime exceptions. Java programs typically consist of multiple Java files with complex dependencies. If a Class type in one Java file is not defined or is incorrectly defined in another Java file, it will lead to compilation or runtime errors, affecting the correctness and reliability of the entire program. Therefore, when performing exception testing on Java files, it's essential to check whether the Class types in each Java file are defined in other Java files to ensure correct dependencies.

[0061] S130: Obtain the historical test results of the compressed file package corresponding to the software development kit before the upgrade during the file anomaly test, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison results.

[0062] In this step, after obtaining the current test results of the upgraded software development kit through step S120, the historical test results of the compressed file package corresponding to the software development kit before the upgrade during the file anomaly test can be obtained, and the historical test results can be compared with the current test results, so as to determine the final test result of the compressed file package based on the comparison results.

[0063] Specifically, historical test results of the compressed file package corresponding to the software development kit (SDK) during file anomaly testing can be retrieved from the stored historical records. By comparing the historical test results with the current test results, the degree of difference between the compressed file package before and after the upgrade can be determined. Furthermore, based on this difference, the changes in the Class type definitions in each Java file in the current test results can be analyzed to see if they affect the operation of software developed based on the SSD, thus obtaining the final test result of the compressed file package. Further, this application can also determine the reliability of the current test results by comparing the differences between the compressed file packages before and after the upgrade. When the difference exceeds a preset range, the greater the difference, the lower the reliability of the current test results. In this case, further analysis of the cause is needed, and the test should be repeated.

[0064] In the above embodiments, when performing file anomaly testing on the software development kit (SDK), a compressed file package to be tested in the upgraded SSD can be obtained. This compressed file package contains multiple Class files. Then, each Class file in the compressed file package can be decompiled to obtain multiple Java files. The Class type in each Java file is identified sequentially, and it is checked whether the Class type in each Java file is defined in other Java files to form the current test result. If the Class type is not defined, it indicates that the corresponding Class file is abnormal and cannot be called. This application can also obtain the historical test results generated by the compressed file package corresponding to the SSD before the upgrade during the file anomaly testing process, and compare the historical test results with the current test results. Then, the final test result of the compressed file package is determined based on the comparison results. Here, by performing anomaly analysis on the test results before and after the upgrade of the SSD, it can be determined whether the anomaly of the Class files after the upgrade of the SSD affects the normal operation of the software. This application performs type anomaly testing on the Class files in the software development kit (SDK), compares and analyzes the test results with the test results before the upgrade, and obtains the final test results. In this way, the SSD can achieve comprehensive automated testing before being released to production, thereby improving test quality and testing efficiency.

[0065] In one embodiment, obtaining the compressed file package to be tested from the upgraded software development kit in step S110 may include:

[0066] S111: Obtain the branch information to be tested, and determine the corresponding deployment branch in the upgraded software development kit based on the branch information.

[0067] S112: Package the source files of the deployment branch to obtain a compressed file package to be tested.

[0068] In this embodiment, the software development kit contains a main branch and multiple deployment branches. When testing the upgraded software development kit, the branch information to be tested after the upgrade can be obtained first, and the corresponding deployment branch in the upgraded software development kit can be determined according to the branch information. Then, the source files of each deployment branch can be packaged to obtain a compressed file package to be tested.

[0069] Understandably, in order to better deploy and manage software development kits, a branching approach is often used for team collaborative development. The main branch is the main line of the software development kit. During team collaboration, each member can create their own branch locally. After development is completed, the branch is merged into the main branch. This separates the development tasks of different functions, so as to better manage and control the quality of the code.

[0070] Specifically, after upgrading one of the deployment branches of the software development kit (SDK), it is necessary to perform file anomaly testing on that deployment branch. At this time, the branch information of that deployment branch can be obtained, such as the space ID, domain name, domain combination application type, etc., and then the corresponding deployment branch can be found in the upgraded SSD.

[0071] For example, in a software development kit, if a deployment branch has a space ID of "space123", a domain name of "www.example.com", and an application type of the domain combination of "web+tomcat", then the name of the deployment branch is "space123 / www.example.com / web+tomcat".

[0072] Furthermore, since different software development kits (SDKs) contain source files of varying formats and numbers, these source files are typically text files describing the source code of the software application. Common text formats include, but are not limited to, Java files (.java), C++ files (.cpp), and Python files (.py). To improve compatibility and efficiency in testing SSDs, after identifying the deployment branch to be tested from the SSD, the source files of that deployment branch can be obtained, converted into Class files, and then packaged into a compressed file package. This allows the acquisition of a compressed file package containing multiple Class files for that deployment branch.

[0073] In one embodiment, decompiling the various Class files in the compressed file package to obtain multiple Java files in step S120 may include:

[0074] S121: Decompress the compressed file package and use reflection to traverse each Class file in the decompressed compressed file package.

[0075] S122: Decompile each Class file into a corresponding Java file to obtain multiple Java files.

[0076] In this embodiment, after obtaining the compressed file package of the software development kit, the compressed file package can be decompressed first, and the decompressed compressed file package can be traversed using a reflection mechanism to obtain multiple Class files. In order to quickly identify the Class types in the Class files and then obtain the inheritance relationship and variable definitions of the classes, each Class file can be decompiled into the corresponding Java file in turn to obtain multiple Java files.

[0077] As we can understand, reflection is a mechanism for dynamically obtaining class information and manipulating class attributes and methods at runtime. In Java programs, classes and objects are static, meaning their attributes and methods are determined at compile time. Therefore, reflection can be used to dynamically obtain class information and manipulate class attributes and methods at runtime.

[0078] Specifically, when using reflection to traverse the decompressed compressed file package, we can first traverse each entry in the decompressed compressed file package and determine whether the entry is a Class file. Here, we can use the getName() method of the ZipEntry class to get the name of the entry and check whether the name ends with ".class". If the entry is a Class file, we can use reflection to load the Class and call its methods. This application can use the defineClass() method of the ClassLoader class to load the Class file and use the getMethods() method of the Class type to get the methods. After traversing the compressed file package through this method, we can obtain each Class file and determine the dynamic information of the Class type contained in each Class file.

[0079] In one embodiment, the step S120 of sequentially identifying the Class type in each Java file may include:

[0080] S123: Parse each Java file to obtain the variable statements in each Java file.

[0081] S124: Extract the variable name and type information of each variable statement, and generate the corresponding ASM code based on the variable name and type information of each variable statement.

[0082] S125: Use ASM to identify each ASM code and obtain the Class type in each Java file.

[0083] In this embodiment, when identifying the Class type in each Java file, each Java file can be parsed first to obtain the variable statements in each Java file. Then, the variable name and type information of each variable statement can be extracted, and corresponding ASM code can be generated based on the variable name and type information of each variable statement. Finally, ASM can be used to read the Class type in each Java file from each ASM code.

[0084] It's important to note that ASM refers to a framework based on Java bytecode manipulation. It can be used to generate, transform, and analyze Java bytecode. It provides a simple, lightweight application programming interface (API) for easy manipulation of Java bytecode and is characterized by high efficiency, flexibility, and scalability. In addition, ASM can be used to write Java bytecode enhancement tools, code generation tools, decompilers, and code analysis tools, and is widely used in various Java frameworks and libraries, such as Spring, Hibernate, and MyBatis. Through ASM, developers can implement various advanced features and optimizations.

[0085] Specifically, when parsing each Java file, a Java compiler or Java parser can be used to parse the source code in the Java file into an abstract syntax tree. In the abstract syntax tree, each variable statement can be represented as a variable node, which contains information such as variable name, variable type, and variable initialization expression. Then, the abstract syntax tree can be traversed to find all variable nodes and extract the variable name and type information from them. After obtaining the variable name and type information of each variable statement, the ClassWriter and FieldVisitor classes of the ASM framework can be used to convert the variable name and type information of each variable statement into ASM code. Finally, the ClassReader and ClassVisitor classes of the ASM framework can be used to identify each ASM code, thereby obtaining the Class type in each Java file.

[0086] In one embodiment, such as Figure 2 As shown, Figure 2 A flowchart illustrating a Class type testing method provided in an embodiment of this application; Figure 2 In step S120, checking whether the Class type in each Java file is defined in other Java files to form the current test result may include:

[0087] S126: For each Java file, determine whether the Class type in the Java file is defined in other Java files; if yes, proceed to step S127; otherwise, proceed to step S128.

[0088] S127: Marks the Class type in this Java file as normal.

[0089] S128: Mark the Class type in this Java file as an exception.

[0090] S129: Obtain the marking results of Class types in each Java file to form the current test results.

[0091] In this embodiment, when detecting whether the Class type in each Java file is defined in other Java files, it is possible to sequentially determine whether the Class type in each Java file is defined in other Java files, and mark the Class type in the corresponding Java file as abnormal or normal according to the judgment result. Finally, the marking results of the Class type in each Java file can be obtained to form the current test result.

[0092] Specifically, if the Class type in a Java file is defined in other Java files, it means that the Class type is defined and can be referenced normally by other Java files. In this case, the Class type in the Java file can be marked as normal. If the Class type in a Java file is not defined in other Java files, it means that the Class type is exception-prone. This exception is called "Class Not Found" when it is reported. In this case, the Java file cannot find the corresponding Class type when calling it, causing the software to malfunction. In this case, the Class type in the Java file can be marked as exception.

[0093] It is understood that the Class type marked in this application refers to the Class type referenced in various Java files. By determining whether the referenced Class type is defined, it can be determined whether the corresponding Java file can be called normally. Therefore, when a software development kit introduces a new Class type during an upgrade, in some cases, this new Class type is not referenced in other Java files, meaning that the Class type is not needed when developing the software. In this case, when performing exception testing on the Java files, it is not necessary to test the Class type that is not referenced by other Java files.

[0094] In one embodiment, such as Figure 3 As shown, Figure 3A flowchart illustrating a method for testing compressed file packages provided in an embodiment of this application; Figure 3 In step S130, comparing historical test results with current test results and determining the final test result of the compressed file package based on the comparison result may include:

[0095] S131: Filter out the Class types marked as abnormal from the current test results, compare the filtered Class types with the corresponding Class types in the historical test results, and determine whether there are any inconsistencies in the marking results of Class types in the comparison results. If yes, execute S132; otherwise, execute S133.

[0096] S132: The final test result of the compressed file package is determined to be abnormal.

[0097] S133: The final test result of the compressed file package is confirmed to be normal.

[0098] In this embodiment, after obtaining the historical test results and the current test results, the Class types marked as abnormal can be filtered out from the current test results, and the filtered Class types can be compared with the corresponding Class types in the historical test results. Then, it can be determined whether there is any inconsistency in the marking results of the Class types in the comparison results. If so, it can be determined that the final test result of the compressed file package is abnormal; if not, it can be determined that the final test result of the compressed file package is normal.

[0099] Specifically, if the comparison results show inconsistent Class type markings, it indicates that the Class type was normal in historical test results and could be called normally in the software development kit before the upgrade. Therefore, the anomaly of the Class type in the current test results is an error that occurred during the software development kit upgrade process. This error will affect the normal operation of the developed software. Therefore, it can be determined that the final test result of the upgraded compressed file package is abnormal. If the Class type markings in the comparison results are completely consistent, it indicates that the Class type was also abnormal in historical test results. Since the software development kit before the upgrade could support the normal operation of the developed software, the Class type markings in the upgraded software development kit do not affect the normal operation of the developed software. Therefore, it can be determined that the final test result of the upgraded compressed file package is normal.

[0100] In one embodiment, the method may further include:

[0101] S140: When the final test result of the compressed file package is abnormal, determine the Class type of the inconsistent marking results in the comparison results.

[0102] S150: Obtain the file information of the Java file containing the Class type with inconsistent marking results, and send the Class type and file information to the corresponding developer.

[0103] In this embodiment, when the final test result of the compressed file package is abnormal, it indicates that the abnormality of the compressed file package affects the normal operation of the developed software. At this time, the Class types with inconsistent marking results in the comparison results can be identified, and then the file information of the Java file where the Class types with inconsistent marking results are located can be obtained. The Class type and file information are sent to the corresponding developers so that the developers can troubleshoot and repair the abnormality based on the Class type and file information.

[0104] Understandably, the file information includes information such as filename, path, version number, and author. Therefore, the corresponding developer, i.e. the author who wrote the Java file, can be identified based on the file information. Then, the Class type and file information can be sent to the corresponding developer via email, instant messaging tools, pop-up reminders, or other means.

[0105] The document anomaly testing apparatus provided in the embodiments of this application is described below. The document anomaly testing apparatus described below can be referred to in correspondence with the document anomaly testing method described above.

[0106] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a file anomaly testing device provided in an embodiment of this application. The application provides a file anomaly testing device, including a file package acquisition module 210, a file detection module 220, and a file package testing module 230, specifically comprising the following:

[0107] The file package acquisition module 210 is used to acquire the compressed file package to be tested in the upgraded software development kit. The compressed file package contains multiple Class files.

[0108] The file detection module 220 is used to decompile each Class file in the compressed file package to obtain multiple Java files, identify the Class type in each Java file in turn, and detect whether the Class type in each Java file is defined in other Java files to form the current test result.

[0109] The file package testing module 230 is used to obtain the historical test results generated by the software development kit before the upgrade during the file anomaly test, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison results.

[0110] In the above embodiments, when performing file anomaly testing on the software development kit (SDK), a compressed file package to be tested in the upgraded SSD can be obtained. This compressed file package contains multiple Class files. Then, each Class file in the compressed file package can be decompiled to obtain multiple Java files. The Class type in each Java file is identified sequentially, and it is checked whether the Class type in each Java file is defined in other Java files to form the current test result. If the Class type is not defined, it indicates that the corresponding Class file is abnormal and cannot be called. This application can also obtain the historical test results generated by the compressed file package corresponding to the SSD before the upgrade during the file anomaly testing process, and compare the historical test results with the current test results. Then, the final test result of the compressed file package is determined based on the comparison results. Here, by performing anomaly analysis on the test results before and after the upgrade of the SSD, it can be determined whether the anomaly of the Class files after the upgrade of the SSD affects the normal operation of the software. This application performs type anomaly testing on the Class files in the software development kit (SDK), compares and analyzes the test results with the test results before the upgrade, and obtains the final test results. In this way, the SSD can achieve comprehensive automated testing before being released to production, thereby improving test quality and testing efficiency.

[0111] In one embodiment, the file package acquisition module 210 may include:

[0112] The deployment branch determination submodule is used to obtain the branch information to be tested and determine the corresponding deployment branch in the upgraded software development kit based on the branch information.

[0113] The file packaging submodule is used to package the various source files of the deployment branch to obtain a compressed file package to be tested.

[0114] In one embodiment, the file detection module 220 may include:

[0115] The file traversal submodule is used to decompress compressed file packages and use reflection to traverse each Class file in the decompressed compressed file package.

[0116] The file decompilation submodule is used to decompile each Class file into a corresponding Java file, resulting in multiple Java files.

[0117] In one embodiment, the file detection module 220 may further include:

[0118] The file parsing submodule is used to parse each Java file and obtain the variable statements in each Java file.

[0119] The ASM code generation submodule is used to extract the variable name and type information of each variable statement, and generate the corresponding ASM code based on the variable name and type information of each variable statement.

[0120] The type identification submodule is used to identify the Class type in each Java file by using ASM to identify each ASM code.

[0121] In one embodiment, the file detection module 220 may further include:

[0122] Define a conditional submodule to determine whether the Class type in each Java file exists in other Java files.

[0123] The first marker submodule is used to mark the Class type in the Java file as an exception.

[0124] The second marker submodule is used to mark the Class type in the Java file as normal.

[0125] The test result generation submodule is used to obtain the marking results of Class types in each Java file and form the current test result.

[0126] In one embodiment, the file package testing module 230 may include:

[0127] The test result comparison submodule is used to filter out Class types marked as abnormal from the current test results, compare the filtered Class types with the corresponding Class types in the historical test results, and determine whether there are any inconsistencies in the marking results of Class types in the comparison results.

[0128] The first determining submodule is used to determine that the final test result of the compressed file package is abnormal.

[0129] The first determining submodule is used to determine whether the final test result of the compressed file package is normal.

[0130] In one embodiment, the apparatus may further include:

[0131] The type determination module is used to determine the Class type of the inconsistent marking results in the comparison results when the final test result of the compressed file package is abnormal.

[0132] The information notification module is used to obtain the file information of the Java file where the Class type with inconsistent marking results is located, and send the Class type and file information to the corresponding developer.

[0133] In one embodiment, this application also provides a storage medium storing 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 described in any of the above embodiments.

[0134] In one embodiment, this application also provides a computer device storing 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 described in any of the above embodiments.

[0135] Indicatively, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 5 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the text recognition method of any of the above embodiments.

[0136] 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 on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0137] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0138] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0139] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0140] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not 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

1. A method for testing file anomalies, characterized in that, The method includes: Obtain the compressed file package to be tested from the upgraded software development kit, wherein the compressed file package contains multiple Class files; After decompiling each Class file in the compressed file package to obtain multiple Java files, the Class type in each Java file is identified in turn, and the Class type in each Java file is checked to see if it is defined in other Java files, thus forming the current test result; Obtain the historical test results of the compressed file package corresponding to the software development kit before the upgrade during the file anomaly test, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison results; The step of sequentially identifying the Class type in each Java file includes: Each Java file is parsed to obtain the variable statements in each Java file; Extract the variable name and type information of each variable statement, and generate the corresponding ASM code based on the variable name and type information of each variable statement; ASM is used to identify each ASM code and obtain the Class type in each Java file.

2. The file anomaly testing method according to claim 1, characterized in that, The process of obtaining the compressed file package to be tested from the upgraded software development kit includes: Obtain the branch information to be tested, and determine the corresponding deployment branch in the upgraded software development kit based on the branch information; The source files of the deployment branch are packaged to obtain a compressed file package to be tested.

3. The file anomaly testing method according to claim 1, characterized in that, The process of decompiling the various Class files in the compressed file package yields multiple Java files, including: Decompress the compressed file package and use reflection to traverse each Class file in the decompressed compressed file package; Each Class file is decompiled into a corresponding Java file, resulting in multiple Java files.

4. The file anomaly testing method according to claim 1, characterized in that, The process of detecting whether the Class type in each Java file is defined in other Java files to form the current test result includes: For each Java file, determine whether the Class type in that Java file is defined in other Java files; If so, mark the Class type in the Java file as normal; If not, mark the Class type in the Java file as an exception; Obtain the Class type marking results from each Java file to form the current test results.

5. The file anomaly testing method according to claim 4, characterized in that, The step of comparing the historical test results with the current test results and determining the final test result of the compressed file package based on the comparison result includes: The class types marked as abnormal are filtered from the current test results, and the filtered class types are compared with the corresponding class types in the historical test results. It is then determined whether there are any inconsistencies in the marking results of the class types in the comparison results. If so, then the final test result of the compressed file package is determined to be abnormal; If not, then the final test result of the compressed file package is determined to be normal.

6. The file anomaly testing method according to claim 5, characterized in that, The method further includes: When the final test result of the compressed file package is abnormal, determine the Class type of the inconsistent marking results in the comparison results; Obtain the file information of the Java file containing the Class type with inconsistent marking results, and send the Class type and the file information to the corresponding developer.

7. A file anomaly testing device, characterized in that, include: The file package acquisition module is used to acquire the compressed file package to be tested in the upgraded software development kit, wherein the compressed file package contains multiple Class files; The file detection module is used to decompile each Class file in the compressed file package to obtain multiple Java files, then identify the Class type in each Java file in turn, and check whether the Class type in each Java file is defined in other Java files to form the current test result. The file package testing module is used to obtain historical test results generated by the software development kit before the upgrade during the file anomaly testing process, compare the historical test results with the current test results, and determine the final test result of the compressed file package based on the comparison result; The process of sequentially identifying the Class type in each Java file in the file detection module includes: Each Java file is parsed to obtain the variable statements in each Java file; Extract the variable name and type information of each variable statement, and generate the corresponding ASM code based on the variable name and type information of each variable statement; ASM is used to identify each ASM code and obtain the Class type in each Java file.

8. A storage medium, characterized in that: The storage medium stores 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 described in any one of claims 1 to 6.

9. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the file anomaly testing method as described in any one of claims 1 to 6.

Images