Report generation method and device, first server, storage medium and program product
By creating the target storage space on the first server and establishing logical associations, the physical isolation problem between different servers is solved, and a simplified process for generating incremental code coverage reports between different servers is achieved, thereby improving efficiency and system stability.
Patent Information
- Application Number
- CN202410294701.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-03-14
- Publication Date
- 2025-09-16
AI Technical Summary
Existing technologies cannot generate incremental code coverage reports between different servers, especially in scenarios where code coverage files and source code are stored on different servers, and reports cannot be generated automatically.
A target storage space is created on the first server, and a logical association relationship is established between multiple second servers and the target storage space. The multiple second servers are connected to the target storage space through the logical association, and the test files are stored and analyzed to generate an incremental code coverage report.
It enables the generation of incremental code coverage reports through a single script command under the condition of physical isolation between different servers, simplifies the report generation process, and improves efficiency and system stability.
Smart Images

Figure CN120653542A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to, but is not limited to, the field of computer vision technology, and in particular to a report generation method, device, first server, storage medium, and program product. Background Art
[0002] Code coverage report is an important tool in the software development process. It provides the code execution status under the test case, which can help developers understand which code is covered by the test case and which part of the code may have insufficient testing, thereby guiding developers to improve test cases and improve code quality.
[0003] In the related technology, when an instruction to generate an incremental code coverage report is received, the source code, bytecode of the program under test and one or more code coverage files generated during the test process are obtained; the first task encapsulated in the code coverage tool is called and executed to merge one or more code coverage data files; the second task encapsulated in the code coverage tool is called and executed to read the merged code coverage data file, and generate an incremental code coverage report based on the source code and bytecode of the program under test and the merged code coverage data file.
[0004] The above method is only applicable to the scenario where the source code, bytecode, and code coverage files of the program under test are all on the same server. For scenarios where different files are on different servers, the incremental code coverage report cannot be automatically generated due to the physical isolation of the files. Summary of the Invention
[0005] In view of this, embodiments of the present disclosure at least provide a report generating method, apparatus, first server, storage medium, and program product.
[0006] The technical solution of the embodiment of the present disclosure is implemented as follows:
[0007] On the one hand, an embodiment of the present disclosure provides a reporting method, which includes: creating a target storage space required for analyzing the code of a target product on a first server; establishing a logical association relationship between multiple second servers and the target storage space to connect the first server with the multiple second servers; based on the logical association relationship, storing the test files required for analyzing the code of the target product in the multiple second servers to the target storage space; performing coverage analysis on the test files to obtain an incremental code coverage report for the target product.
[0008] It can be understood that by creating a target storage space required for analyzing the code of the target product on the first server and establishing a logical association relationship between multiple second servers and the target storage space, multiple second servers can be connected to the target storage space, so that the target storage space can be used as a private storage space to store the test files required for analyzing the code of the target product, so as to solve the physical isolation problem between multiple servers. In addition, in the related art, it is necessary to call different tasks multiple times to generate an incremental code coverage report; and after receiving the report generation instruction, the embodiment of the present disclosure can automatically execute the generation logic (script command), determine the test files related to the target product, perform coverage analysis on the test files to obtain the incremental code coverage report of the target product, and realize the generation of the incremental code coverage report by a single script command, so as to simplify the generation process of the incremental code coverage report and shorten the report generation process from three steps (the first step is to obtain the source code, bytecode and code coverage file of the program under test based on the generation instruction, the second step is to call the first task to merge the code coverage data file, and the third step is to call the second task to read the code coverage data file) to one step.
[0009] In some embodiments, the creation of a target storage space required for analyzing the code of the target product on the first server includes: creating a first storage volume on the first server whose life cycle is independent of the container, and using the first storage volume as the target storage space; or, creating a second storage volume on the first server whose life cycle is the same as the container, and using the first storage volume as the target storage space; or, creating an NFS file system on the first server, and using the NFS file system as the target storage space.
[0010] It can be understood that the present disclosure provides three different methods for creating target storage spaces to cope with different scenarios.
[0011] In some embodiments, establishing a logical association relationship between multiple second servers and the target storage space to connect the first server with the multiple second servers includes: determining a configuration file that can reference the target storage space; based on the configuration file, the address information of the target storage space and the address information of the multiple second servers, establishing a logical association relationship between the multiple second servers and the target storage space to connect the first server with the multiple second servers.
[0012] It can be understood that based on the configuration file that can reference the target storage space, the address information of the target storage space and the address information of multiple second servers, a logical association relationship can be established between multiple second servers and the target storage space, thereby achieving connectivity between the first server and multiple second servers.
[0013] In some embodiments, based on the logical association relationship, the test files required for analyzing the code of the target product in the multiple second servers are stored in the target storage space, including: determining the code coverage data file of the target product; determining the bytecode file of the current version and the bytecode file of the baseline version of the target product; based on the storage identifier of the target product, the code coverage data file, the bytecode file of the current version and the bytecode file of the baseline version are stored as the test files in the target storage space.
[0014] It can be understood that, according to the storage identifier of the target product (name of the target product), the code coverage data file and the bytecode file (class file) of the current version can be stored in the private storage space (target storage space).
[0015] In some embodiments, determining the code coverage data file of the target product includes: determining test cases for each interface in the target product based on the interface document of the target product; testing the code of the target product based on the test cases; during the test, calling a code coverage tool to analyze the code of the target product and generate a code coverage data file for the target product.
[0016] It can be understood that when the code of the target product is tested according to the test case, a code coverage tool can be called to analyze the code of the target product and generate a code coverage data file of the target product.
[0017] In some embodiments, determining the bytecode file of the current version and the bytecode file of the baseline version of the target product includes: determining a first storage path of the bytecode file of the current version and a second storage path of the bytecode file of the baseline version from the attribute information of the target product; obtaining the bytecode file of the current version based on the first storage path; and obtaining the bytecode file of the baseline version based on the second storage path.
[0018] It can be understood that from the attribute information of the target product (the configuration task information of the product), the class file path of the current version (the first storage path) and the class file path of the baseline version (the second storage path) can be determined, and then the class file of the current version and the class file of the baseline version can be obtained.
[0019] In some embodiments, the coverage analysis of the test file to obtain the incremental code coverage report of the target product includes: determining the code line coverage status data file of the target product based on the bytecode file of the current version and the code coverage data file in the test file; determining the incremental code lines of the target product in comparison between the current version and the baseline version based on the bytecode file of the current version and the bytecode file of the baseline version in the test file; and determining the incremental code coverage report based on the incremental code lines and the code line coverage status data file.
[0020] It can be understood that the code line coverage status data file of the target product can be determined based on the current version of the class file and the code coverage data file; based on the current version of the class file and the baseline version of the class file, the incremental code lines of the target product in the comparison between the current version and the baseline version can be determined; further, based on the incremental code lines and the code line coverage status data file, the incremental code coverage report can be determined.
[0021] In some embodiments, determining the code line coverage status data file of the target product based on the current version of the bytecode file and the code coverage data file in the test file includes: performing a global coverage analysis on the current version of the bytecode file and the code coverage data file to obtain the code line coverage status data file.
[0022] It can be understood that performing global coverage analysis on the current version of the bytecode file and code coverage data file can perform comprehensive coverage testing on all codes of the target product to ensure that every part of all codes of the target product has been executed at least once, thereby improving software quality and reliability.
[0023] In some embodiments, the determining of the incremental code lines of the target product in comparison between the current version and the baseline version based on the bytecode file of the current version and the bytecode file of the baseline version in the test file includes: decompiling the bytecode file of the current version to obtain the byte array file of the current version; decompiling the bytecode file of the baseline version to obtain the byte array file of the baseline version; and comparing the byte array file of the current version with the byte array file of the baseline version to obtain the incremental code lines.
[0024] It can be understood that decompiling the bytecode file of the current version and the bytecode file of the baseline version can convert the compiled bytecode file (usually a binary file, such as an executable file or bytecode) into a more understandable form, making it easier to determine the incremental code lines.
[0025] On the other hand, an embodiment of the present disclosure provides a report generating device, which includes: a configuration module for creating a target storage space required for analyzing the code of a target product on a first server; the configuration module for establishing a logical association relationship between multiple second servers and the target storage space to connect the first server with the multiple second servers; a storage module for storing the test files required for analyzing the code of the target product in the multiple second servers to the target storage space based on the logical association relationship; and an analysis module for performing coverage analysis on the test files to obtain an incremental code coverage report for the target product.
[0026] On the other hand, an embodiment of the present disclosure provides a first server, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.
[0027] On the other hand, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which implements part or all of the steps in the above method when executed by a processor.
[0028] On the other hand, an embodiment of the present disclosure provides a computer program, including computer-readable code. When the computer-readable code is executed in a first server, a processor in the first server executes some or all of the steps for implementing the above method.
[0029] On the other hand, an embodiment of the present disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method.
[0030] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] The accompanying drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and, together with the specification, are used to explain the technical solutions of the present disclosure.
[0032] Figure 1 A schematic diagram of the implementation process of a report generation method provided in an embodiment of the present disclosure Figure 1 ;
[0033] Figure 2 A schematic diagram of the implementation process of a report generation method provided in an embodiment of the present disclosure Figure 2 ;
[0034] Figure 3 A schematic diagram of the composition structure of units involved in a report generation method provided in an embodiment of the present disclosure;
[0035] Figure 4 A schematic diagram of the implementation process of a report generation method provided in an embodiment of the present disclosure Figure 3 ;
[0036] Figure 5 A schematic diagram of the structure of a report generating device provided in an embodiment of the present disclosure;
[0037] Figure 6 A schematic diagram of a hardware entity of a first server provided in an embodiment of the present disclosure. DETAILED DESCRIPTION
[0038] In order to make the purpose, technical solutions and advantages of the present disclosure clearer, the technical solutions of the present disclosure are further elaborated in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limiting the present disclosure. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.
[0039] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0040] The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that "first / second / third" can be interchanged with a specific order or sequence where permitted so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein.
[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present disclosure pertains. The terms used herein are for the purpose of describing the present disclosure only and are not intended to limit the present disclosure.
[0042] In order to better understand the report generation method provided by the embodiment of the present disclosure, the solution in the related art is first described below.
[0043] Related technologies: Generating incremental code coverage reports requires repeatedly reading git diff files, comparing the code in the read git diff files with the source code to obtain a data structure of incremental code lines, and finally calculating the incremental code coverage based on the obtained data structure of incremental code lines. However, this method has certain limitations. The process of comparing the code in the read gitdiff files with the source code requires maintaining a copy of the git code repository locally, which is not applicable for scenarios where the service has no network or no git permissions. Git diff is a command in Git that is used to compare the differences between different versions of code. The files compared using git diff are called git diff files.
[0044] Therefore, the related technology not only has the problem of not being applicable to scenarios where different files are on different servers, but also has the problem of requiring a local git code library to be maintained, which results in high costs.
[0045] The technical problems to be solved by the present disclosure include: for scenarios where code coverage files and source code and bytecode are stored on different servers, by creating a private storage space related to the environment, logically associating files on different physical servers, aggregating and processing files on different servers, generating coverage reports, and simplifying the coverage report generation process to shorten the report generation time.
[0046] In addition, by comparing the current version byte file with the baseline version byte file of the current version, incremental code lines are obtained, eliminating the dependence on the git local repository and improving comparison efficiency and system stability.
[0047] The embodiment of the present disclosure provides a report generation method, which can be executed by a processor of a first server. Figure 1 As shown, the report generation method includes the following steps 101 to 104:
[0048] Step 101: Create a target storage space required for analyzing the code of a target product on a first server.
[0049] The first server refers to a physical server that can directly run an operating system and applications. The multiple second servers can refer to multiple physical servers or multiple virtual servers. The multiple virtual servers can be servers virtualized on the first server or servers virtualized on servers other than the first server. This disclosure does not limit this.
[0050] The target product is the product for which code coverage needs to be checked. More specifically, the target product is the product for which incremental code coverage reports are required. A target product is a product written in code; for example, it can be a webpage, an application, or office, entertainment, or leisure software. Code can be any form of text, including source code (human-readable code) and compiled machine code (binary instructions directly executed by a computer).
[0051] The target storage space is a private storage space that can meet the needs of report generation.
[0052] In a feasible implementation, in order to solve the problem of physical isolation between different servers, a target storage space can be created according to the requirements of the test method (report generation method) and the test scale (the amount of code of the target product).
[0053] Step 102: Establish a logical association relationship between the plurality of second servers and the target storage space to connect the first server with the plurality of second servers.
[0054] The purpose of establishing a logical association between multiple second servers and the target storage space is to connect the first server and the multiple second servers so that the first server and the multiple second servers can communicate with each other, thereby allowing the data in the multiple second servers to be stored in the target storage space.
[0055] In a feasible implementation, a logical association relationship between the multiple second servers and the target storage space may be established based on the address information of the multiple second servers and the address information of the target storage space, so as to connect the first server with the multiple second servers.
[0056] Step 103: Based on the logical association relationship, the test files required for analyzing the code of the target product in the multiple second servers are stored in the target storage space.
[0057] Test files are files required to generate incremental code coverage reports for the target product. In one implementation, test files can include the target product's YAML file, code coverage data files, source code, and bytecode. YAML (YAML Ain't Markup Language) is a highly readable format for expressing data serialization. It is primarily used for data serialization and configuration management, and its design goal is to improve human readability while maintaining a clear data structure.
[0058] In a feasible implementation method, after the first server receives the report generation instruction, it can issue data acquisition instructions to multiple second servers based on the logical association relationship, so that the multiple second servers store their own code coverage data files, source code, bytecode and other test files related to the target product to the target storage space.
[0059] In another feasible implementation method, multiple second servers can also actively store their own code coverage data files, source code, bytecode and other test files related to the target product to the target storage space, so that the first server can generate incremental code coverage reports based on the test files.
[0060] Step 104: Perform coverage analysis on the test file to obtain an incremental code coverage report for the target product.
[0061] In one feasible implementation, the incremental code coverage report generation logic can be written into the server. Upon receiving a report generation command, the report generation logic can be automatically executed, identifying the test files relevant to the target product, and performing coverage analysis on the test files to generate an incremental code coverage report for the target product. This allows the server to automatically generate an incremental code coverage report for the target product by simply running the command once.
[0062] In the embodiment of the present disclosure, by creating a target storage space required for analyzing the code of the target product on a first server and establishing a logical association relationship between multiple second servers and the target storage space, it is possible to connect multiple second servers with the target storage space, so that the target storage space is used as a private storage space to store the test files required for analyzing the code of the target product, thereby solving the physical isolation problem between multiple servers. In addition, in the related art, it is necessary to call different tasks multiple times to generate an incremental code coverage report; however, after receiving the report generation instruction, the embodiment of the present disclosure can automatically execute the generation logic (script command), determine the test files related to the target product, perform coverage analysis on the test files to obtain the incremental code coverage report of the target product, and realize the generation of the incremental code coverage report by a single script command, thereby simplifying the generation process of the incremental code coverage report and shortening the report generation process from three steps (the first step is to obtain the source code, bytecode and code coverage file of the program under test based on the generation instruction, the second step is to call the first task to merge the code coverage data file, and the third step is to call the second task to read the code coverage data file) to one step.
[0063] The embodiment of the present disclosure provides a report generation method, which can be executed by a processor of a first server. Figure 2 As shown, the method includes the following steps 201 to 208:
[0064] Step 201: Create a target storage space required for analyzing the code of a target product on a first server.
[0065] There are three ways to create a target storage space:
[0066] The first method is to create a first storage volume whose life cycle is independent of the container on the first server, and use the first storage volume as the target storage space.
[0067] The first storage volume is a volume whose lifecycle is independent of the container. In one possible implementation, the first storage volume can be a hostPath volume whose lifecycle is independent of the pod (container). This type of storage volume maps files or directories from the host's file system to the pod, with the specific location specified by the path field. This type of storage volume ensures that the data remains stored on the host even after the pod is destroyed.
[0068] In one feasible implementation, a first storage volume can be created based on the address (Path) of the first server. Specifically, the path of the file on the first server that is used as the hostPath volume is determined; a container and a container configuration file are created; and the container is associated with the hostPath volume based on the container configuration file to obtain the target storage space.
[0069] The second method is to create a second storage volume with the same life cycle as the container on the first server, and use the first storage volume as the target storage space.
[0070] The second storage volume is a storage volume with the same lifecycle as the container. In one feasible implementation, the second storage volume can be an EmptyDir volume with the same lifecycle as the pod. This type of storage volume is created when the pod is assigned to a node. Its initial content is empty, and there is no need to specify a corresponding directory file on the host, because Kubernetes automatically assigns a directory. When the pod is destroyed, the data in the EmptyDir is also permanently deleted.
[0071] EmptyDir is used for the following purposes: 1. Temporary space, such as temporary directories required for the operation of certain applications, which do not need to be retained permanently; 2. Directories where one container needs to obtain data from another container (shared directories).
[0072] A third method is to create an NFS file system on the first server and use the NFS file system as the target storage space.
[0073] The Network File System (NFS) is a distributed file system built on Node that provides file sharing services. It allows clients to transparently access files on remote servers through the network.
[0074] In a feasible implementation, an NFS service is installed, a directory is created on the first server and configured as an NFS share, thereby obtaining an NFS file system.
[0075] It should be noted that the third creation method is more stable than the other two methods and can solve the problem of data loss when a node fails.
[0076] Step 202: Establish a logical association relationship between the plurality of second servers and the target storage space to connect the first server with the plurality of second servers.
[0077] In some embodiments, the specific implementation method of step 202 may be: determining a configuration file that can reference the target storage space; based on the configuration file, the address information of the target storage space and the address information of the multiple second servers, establishing a logical association relationship between the multiple second servers and the target storage space to connect the first server with the multiple second servers.
[0078] The configuration file refers to a yaml file deployed for multiple second servers, which contains a reference to the target storage space, and is then used to establish a logical association relationship between the multiple second servers and the first server.
[0079] In a feasible implementation, a logical association relationship between multiple second servers and the target storage space can be established based on the path and serve of the target storage space. The specific implementation is:
[0080] (volumes:
[0081] -name:vol-e2mc8
[0082] nfs:
[0083] path: / data / nfs / jacoco
[0084] server:10.175.132.64)
[0085] Step 203: Determine the code coverage data file of the target product.
[0086] A code coverage data file is a file containing code coverage data. Code coverage data is usually generated during testing. The code coverage data file records which lines of code are executed and which are not executed during the test process, as well as possible other coverage indicators such as branch coverage, condition coverage, etc.
[0087] In a feasible implementation, the specific implementation method of step 203 can be: based on the interface document of the target product, determine the test cases for each interface in the target product; based on the test cases, test the code of the target product; during the test, call the code coverage tool to analyze the code of the target product and generate the code coverage data file of the target product.
[0088] API documentation is a technical document that describes in detail the interactive interfaces between software components or systems. It usually includes information such as the interface's request format, response format, parameter descriptions, error codes, usage examples, etc., so that developers can understand and use these interfaces.
[0089] Code coverage tools are used to measure the execution of code during software testing. They help developers understand which code is covered and which is not, thereby improving software quality and reducing potential bugs. Exemplary code coverage tools include Jacoco, Istantibul, CodeCov, and Coveralls.
[0090] In one feasible implementation, when testing the target product's code based on test cases, you can call the jacoco tool to obtain code coverage data files. Specifically, when calling the corresponding server interface, the jacoco tool will detect how many lines of code are executed within each server interface through instrumentation and generate an exec file to count the server code execution information. This exec file is the code coverage data file.
[0091] Step 204: Determine the bytecode file of the current version and the bytecode file of the baseline version of the target product.
[0092] In a feasible implementation, the specific implementation method of step 204 can be: determining the first storage path of the bytecode file of the current version and the second storage path of the bytecode file of the baseline version from the attribute information of the target product; based on the first storage path, obtaining the bytecode file of the current version; based on the second storage path, obtaining the bytecode file of the baseline version.
[0093] The target product's attribute information may be the target product's configuration task information. The configuration task information describes detailed information about the target product's code, including the product name, the storage location of the product code, the storage path of the product code's bytecode files (class files), the storage path of the product code's source code files (src files), the storage path of the Jacoco tool, the storage path of the code coverage data, and the storage path of the code coverage data report.
[0094] The first storage path is the storage path of the bytecode file of the current version, and the second storage path is the storage path of the bytecode file of the baseline version. The bytecode file refers to the class file.
[0095] In a feasible implementation method, the class file path (first storage path) of the current version can be obtained from the configuration task information of the target product, and the class file of the current version can be obtained based on the class file path of the current version; similarly, the class file path (second storage path) of the baseline version can be obtained from the configuration task information of the target product, and the class file of the baseline version can be obtained based on the class file path of the baseline version.
[0096] Step 205: Based on the storage identifier of the target product, the code coverage data file, the bytecode file of the current version, and the bytecode file of the baseline version are stored as the test files in the target storage space.
[0097] The storage identifier of the target product may be the name of the target product.
[0098] In a feasible implementation, the code coverage data file, the bytecode file of the current version, and the bytecode file of the baseline version may be stored as test files in the target storage space based on the name of the target product.
[0099] Step 206: Determine the code line coverage status data file of the target product based on the bytecode file of the current version and the code coverage data file in the test file.
[0100] The code line coverage status data file is used to record which code lines have been executed during the software testing process.
[0101] In one feasible implementation, a global coverage analysis can be performed on the current version's class files and code coverage data files to generate a code line coverage status data file (info file). Global coverage analysis involves comprehensive coverage testing of all code in the target product to ensure that every part of the target product's code has been executed at least once, improving software quality and reliability.
[0102] Step 207: Based on the bytecode file of the current version and the bytecode file of the baseline version in the test file, determine the incremental code lines of the target product when the current version is compared with the baseline version.
[0103] In some embodiments, the specific implementation method of step 207 can be: decompiling the bytecode file of the current version to obtain the byte array file of the current version; decompiling the bytecode file of the baseline version to obtain the byte array file of the baseline version; comparing the byte array file of the current version and the byte array file of the baseline version to obtain the incremental code line.
[0104] A byte array file is a byte file. A byte file is a binary file, containing data in bytes. A byte is the basic unit of computer storage, and each byte consists of 8 bits. Binary files can contain various types of data, such as images, audio, video, executable programs, and databases. Decompilation is the process of converting a compiled program (usually a binary file, such as an executable file or bytecode) into a more understandable form, usually source code. This process is the opposite of compilation, which converts human-readable source code into machine-executable binary code.
[0105] In a feasible implementation, the class file of the baseline version can be decompiled to obtain the byte file of the baseline version; the class file of the current version can be decompiled to obtain the byte file of the current version; and the byte file of the current version and the byte file of the baseline version can be compared to obtain the incremental code lines of the current version.
[0106] Step 208: Determine the incremental code coverage report based on the incremental code lines and the code line coverage status data file.
[0107] In one feasible implementation, for each service in the target file, the incremental code coverage of each service is statistically analyzed to obtain an incremental code coverage report. Specifically, the incremental code lines can be used to obtain a dictionary consisting of the incremental package name, class, method, and number of new lines; the incremental code lines, the incremental number of code lines, the covered lines, and the number of covered lines can be obtained from the code line coverage status data file; the index.html and class name.html files in each directory are read in a loop and modified; the number of new lines, the number of covered lines, and the coverage rate are displayed; the class name.java.html file is read in a loop and modified, with a mark added before the number of new lines; and the incremental code coverage is summarized to obtain the incremental code coverage report.
[0108] In a feasible implementation, the incremental code lines and code line coverage status data files may be analyzed using an open source computing tool to determine an incremental code coverage report.
[0109] In some embodiments, the target storage space also provides a report viewing function. After generating the incremental code coverage report, the user can issue a report viewing instruction to view the incremental code coverage report. Specifically, the application where the target storage space is located can provide a HyperText Transfer Protocol (HTTP) service for the user to view the incremental code coverage report through a browser.
[0110] In the embodiment of the present disclosure, by creating a target storage space required for analyzing the code of the target product on a first server and establishing a logical association relationship between multiple second servers and the target storage space, it is possible to connect multiple second servers with the target storage space, so that the target storage space is used as a private storage space to store the test files required for analyzing the code of the target product, thereby solving the physical isolation problem between multiple servers. In addition, in the related art, it is necessary to call different tasks multiple times to generate an incremental code coverage report; however, after receiving the report generation instruction, the embodiment of the present disclosure can automatically execute the generation logic (script command), determine the test files related to the target product, perform coverage analysis on the test files to obtain the incremental code coverage report of the target product, and realize the generation of the incremental code coverage report by a single script command, thereby simplifying the generation process of the incremental code coverage report and shortening the report generation process from three steps (the first step is to obtain the source code, bytecode and code coverage file of the program under test based on the generation instruction, the second step is to call the first task to merge the code coverage data file, and the third step is to call the second task to read the code coverage data file) to one step.
[0111] The following describes the application of the report generation method provided by the embodiment of the present disclosure in a practical scenario.
[0112] The embodiments of the present disclosure are applicable to the situation where different files are on different machines under the NFS file system, and the incremental code coverage report cannot be automatically generated due to the physical isolation of the files. In addition, the embodiments of the present disclosure obtain the incremental coverage by comparing the byte files of the current version with the byte files of the baseline version, thereby solving the problem that the git repository cannot be maintained on the server under the NFS file system due to network failure or permission issues, and thus the incremental code coverage cannot be calculated through git file comparison.
[0113] like Figure 3As shown, the report generation method involves a container environment variable configuration unit 301, a Jacoco command execution unit 302, a file acquisition unit 303, a coverage analysis unit 304, a code decompilation unit 305, and an incremental coverage calculation unit 306. The container environment variable configuration unit 301 is used to create a private storage space (target storage space) required for analyzing the target product code; the Jacoco command execution unit 302 is used to call the Jacoco tool; the file acquisition unit 303 is used to obtain the current version of the class text and the baseline version of the class file based on the product's task information; the coverage analysis unit 304 is used to perform coverage analysis on the test file; the code decompilation unit 305 decompiles the current version of the class file to obtain the current version of the byte file, and decompiles the baseline version of the class file to obtain the baseline version of the byte file; the incremental coverage calculation unit 306 is used to determine the incremental code coverage report based on the incremental code lines and the code line coverage status data file.
[0114] like Figure 4 As shown, the report generation method may include the following steps 401 to 409:
[0115] Step 401: Create a private storage space related to the environment variables.
[0116] To solve the problem of physical isolation between different servers, first create a private storage space that meets the test requirements according to the test method and test scale requirements.
[0117] There are three ways to create a private storage space:
[0118] The first one is the empty directory (emptyDir).
[0119] EmptyDir is a type of volume in Kubernetes that solves the problem of sharing data between containers in a Pod, and between a Pod and the host. This type of volume is created when a Pod is assigned to a Node. Its initial content is empty, and there is no need to specify a corresponding directory file on the host, as Kubernetes automatically assigns a directory. When the Pod is destroyed, the data in EmptyDir is also permanently deleted.
[0120] EmptyDir can be used as a temporary directory, for example, a temporary directory required by some applications during runtime that does not need to be permanently retained. It can also be used as a shared directory for multiple containers, where one container needs to obtain data from another container.
[0121] The second type is hostPath.
[0122] HostPath is another type of volume in Kubernetes. This type of volume maps files or directories in the Node.js file system to a Pod. This design ensures that even if the Pod is destroyed, the data remains on the Node host. The Node.js file system provides a set of APIs that allow developers to interact with the file system in a server-side JavaScript environment. These APIs include operations such as reading, writing, updating, and deleting files and directories.
[0123] The third type is the NFS file system.
[0124] The NFS system is a network file system built on the Node that provides file sharing services.
[0125] It should be noted that the third method is more stable than the other two methods and can solve the problem of data loss when a node fails.
[0126] Step 402: Configure the YAML file of the application container and deploy the application.
[0127] Based on step 401, logical relationships are established between different servers to enable interconnection between them. By configuring the YAML files for each application deployment, private storage spaces are referenced and deployed. The YAML file contains a reference to the private storage space created in step 401. A specific example is:
[0128] volumes:
[0129] name:vol-e2mc8 (storage volume name)
[0130] nfs:
[0131] path: / data / nfs / jacoco (path to private storage space)
[0132] server:10.175.132.64 (the address of the private storage space).
[0133] Step 403: Use the jacoco command to generate a code coverage file.
[0134] Execute interface automated test cases. Specifically, first design test cases for each input and output parameter of the interface according to the interface documentation, then implement the test cases through code, and then store the code corresponding to the automated test cases on the server side, and run the code of these automated test cases on the server side at a scheduled time.
[0135] After the automated use case is executed, the jacoco tool is called to generate a code coverage data file for this automated use case execution, and the code coverage data file is stored in the private storage space specified in step 401 based on the application name.
[0136] The Jacoco tool is an open source code coverage tool for Java. When running tests, the Jacoco tool runs in Java agent mode, instrumenting the bytecode, delving into each instruction, and displaying the lines that are executed during each test. The command line to invoke the Jacoco tool is as follows:
[0137] java -jar jacococli.jar dump --address 127.0.0.1 --port 2014 --destfile / private storage space / jacoco.exec.
[0138] The application name refers to the names of a series of services. The data is stored based on the application name because the coverage data statistics include multiple services. The final code coverage report is counted based on the service dimension.
[0139] In a feasible implementation, the specific implementation of calling the jacoco tool to generate the code coverage data file can be: calling the server interface, the jacoco tool will detect how many lines of code are executed in each interface of the server through the instrumentation method, and generate an exec file to count the information of the server code execution. This exec file is the code coverage data file.
[0140] Step 404: Obtain the current version class file path from the product configuration task information, and obtain the current version class file based on the current version class file path.
[0141] The product configuration task information refers to the detailed information of the relevant code of the product; the product configuration task information includes: the name of the service, the storage location of the service code, the storage path of the service code class file, the storage path of the service code src file, the storage path of the jacoco tool, the storage path of the code coverage information, the storage path of the code coverage report, etc.
[0142] Step 405: Perform global coverage analysis based on the current version of the class file and the exec file to obtain the line coverage information file info.
[0143] Step 406: Obtain the baseline version from the product configuration task information, and decompile the baseline version to obtain a byte file of the baseline version.
[0144] Step 407: Decompile the current version class file to obtain the current version byte file.
[0145] Step 408: Compare the byte file of the current version with the byte file of the baseline version to obtain incremental code lines.
[0146] Step 409: Obtain an incremental code coverage report using an open source calculation tool based on the line coverage information file info and the incremental code lines.
[0147] It should be noted that the embodiments of the present disclosure include at least the following innovations:
[0148] 1. Process optimization of the report generation method: The disclosed embodiment provides a method for generating an incremental code coverage report under the condition that the code coverage file, source code, and bytecode file are physically isolated. This method creates a private storage space related to the environment, and the private storage space can be used to store relevant data required for the report generation method. This method uses an independent storage space to store data including yaml files, code coverage files, source code and bytecode of the application container, instead of storing them on a single server. In the subsequent report generation method, the application where the storage space is located provides an http service for users to view the report through a browser. This method generates an incremental code coverage report by running a code command, shortening the operation steps for generating an incremental code coverage report from three steps in the conventional process to one step;
[0149] 2. Perform global coverage analysis based on the current version class files and the data obtained during runtime to obtain line coverage status information; decompile the current version class files to obtain the current version byte files; compare the current version byte files with the baseline version byte files obtained by decompiling the obtained baseline package to obtain a comparison report; analyze the comparison report to obtain the incremental code lines of the product under test; and calculate the incremental code coverage of the product under test based on the line coverage status information and incremental code lines. Compared to traditional solutions that require establishing a local Git repository and using the git diff command to compare the current version and the baseline version to calculate incremental coverage, this eliminates the reliance on maintaining a copy of the local Git repository and solves the problem of being unable to obtain incremental code coverage when the server has no network connection or lacks Git permissions.
[0150] It should be noted that the embodiments of the present disclosure can at least achieve the following technical effects:
[0151] 1. This solves the problem of not being able to generate incremental code coverage reports with one click when the code coverage file, source code, and bytecode files are not on the same server. It also simplifies the generation process of incremental code coverage reports, reducing the report generation time to 1 / 3 of the conventional process.
[0152] 2. By comparing the byte files of the current version with the byte files of the baseline version, the incremental coverage is obtained, eliminating the dependency on maintaining a copy of the local Git repository. This eliminates the blocking effects of scenarios such as unstable Git repositories and the inability to establish local Git repositories. The statistical time for incremental code coverage is reduced by an average of more than 20%.
[0153] Based on the foregoing embodiments, the embodiments of the present disclosure provide a report generation device, which includes the units included and the modules included in the units, and can be implemented by a processor in the first server; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.
[0154] Figure 5 A schematic diagram of the structure of a report generating device provided in an embodiment of the present disclosure is shown in FIG. Figure 5 As shown, the report generating apparatus 500 includes: a configuration module 510, a storage module 520 and an analysis module 530, wherein:
[0155] Configuration module 510, configured to create a target storage space required for analyzing the code of the target product on the first server;
[0156] The configuration module 510 is configured to establish a logical association relationship between the plurality of second servers and the target storage space, so as to connect the first server with the plurality of second servers;
[0157] A storage module 520 is configured to store, based on the logical association, the test files required for analyzing the code of the target product in the plurality of second servers into the target storage space;
[0158] The analysis module 530 is used to perform coverage analysis on the test file to obtain an incremental code coverage report for the target product.
[0159] In some embodiments, the configuration module 510 is specifically used to: create a first storage volume whose life cycle is independent of the container on the first server, and use the first storage volume as the target storage space; or, create a second storage volume whose life cycle is the same as the container on the first server, and use the first storage volume as the target storage space; or, create an NFS file system on the first server, and use the NFS file system as the target storage space.
[0160] In some embodiments, the configuration module 510 is specifically used to: determine a configuration file that can reference the target storage space; establish a logical association relationship between the multiple second servers and the target storage space based on the configuration file, the address information of the target storage space and the address information of the multiple second servers to connect the first server with the multiple second servers.
[0161] In some embodiments, the storage module 520 is specifically used to: determine the code coverage data file of the target product; determine the bytecode file of the current version and the bytecode file of the baseline version of the target product; and based on the storage identifier of the target product, store the code coverage data file, the bytecode file of the current version and the bytecode file of the baseline version as the test files in the target storage space.
[0162] In some embodiments, the storage module 520 is specifically used to: determine test cases for each interface in the target product based on the interface document of the target product; test the code of the target product based on the test cases; during the test, call the code coverage tool to analyze the code of the target product and generate a code coverage data file for the target product.
[0163] In some embodiments, the storage module 520 is specifically used to: determine the first storage path of the bytecode file of the current version and the second storage path of the bytecode file of the baseline version from the attribute information of the target product; obtain the bytecode file of the current version based on the first storage path; and obtain the bytecode file of the baseline version based on the second storage path.
[0164] In some embodiments, the analysis module 530 is specifically used to: determine the code line coverage status data file of the target product based on the current version of the bytecode file and the code coverage data file in the test file; determine the incremental code lines of the target product in comparison between the current version and the baseline version based on the current version of the bytecode file and the baseline version of the bytecode file in the test file; determine the incremental code coverage report based on the incremental code lines and the code line coverage status data file.
[0165] In some embodiments, the analysis module 530 is specifically configured to perform global coverage analysis on the bytecode file of the current version and the code coverage data file to obtain the code line coverage status data file.
[0166] In some embodiments, the analysis module 530 is specifically used to: decompile the bytecode file of the current version to obtain the byte array file of the current version; decompile the bytecode file of the baseline version to obtain the byte array file of the baseline version; compare the byte array file of the current version with the byte array file of the baseline version to obtain the incremental code line.
[0167] The description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided by the embodiment of the present disclosure can be used to perform the method described in the above method embodiment. For technical details not disclosed in the device embodiment of the present disclosure, please refer to the description of the method embodiment of the present disclosure for understanding.
[0168] It should be noted that, in the embodiments of the present disclosure, if the above-mentioned report generation method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present disclosure is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for enabling a first server (which can be a physical server) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiments of the present disclosure are not limited to any specific hardware, software or firmware, or any combination of hardware, software and firmware.
[0169] An embodiment of the present disclosure provides a first server, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.
[0170] The present disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above method. The computer-readable storage medium may be transient or non-transient.
[0171] An embodiment of the present disclosure provides a computer program, including computer-readable code. When the computer-readable code is run in a first server, a processor in the first server executes some or all of the steps for implementing the above method.
[0172] The present disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method. The computer program product can be implemented specifically by hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium. In other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.
[0173] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between the embodiments, and reference can be made to the similarities or similarities between them. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above-mentioned method embodiments and have similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product disclosed herein, please refer to the description of the method embodiments disclosed herein for understanding.
[0174] It should be noted that Figure 6 A schematic diagram of a hardware entity of the first server in an embodiment of the present disclosure is shown in FIG. Figure 6 As shown, the hardware entity of the first server 600 includes: a processor 601, a communication interface 602 and a memory 603, wherein:
[0175] The processor 601 generally controls the overall operations of the first server 600 .
[0176] The communication interface 602 enables the first server to communicate with other terminals or servers through a network.
[0177] The memory 603 is configured to store instructions and applications executable by the processor 601, and can also cache data to be processed or processed by the processor 601 and various modules in the first server 600 (for example, image data, audio data, voice communication data, and video communication data). This can be implemented using flash memory (FLASH) or random access memory (RAM). Data can be transmitted between the processor 601, the communication interface 602, and the memory 603 via a bus 604.
[0178] It should be understood that “one embodiment” or “an embodiment” mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present disclosure. Therefore, “in one embodiment” or “in an embodiment” appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present disclosure, the size of the serial numbers of the above-mentioned steps / processes does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present disclosure. The serial numbers of the embodiments of the present disclosure are for description only and do not represent the advantages and disadvantages of the embodiments.
[0179] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.
[0180] In the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.
[0181] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, the functional units in the various embodiments of the present disclosure may all be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.
[0182] The above is only an embodiment of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the present disclosure, and they should all be covered by the protection scope of the present disclosure.
Claims
1. A report generation method, characterized in that: The report generation method comprises: Creating a target storage space required for analyzing the code of the target product on the first server; Establishing a logical association relationship between the plurality of second servers and the target storage space to connect the first server with the plurality of second servers; Based on the logical association relationship, the test files required for analyzing the code of the target product in the plurality of second servers are stored in the target storage space; Perform coverage analysis on the test file to obtain an incremental code coverage report for the target product.
2. The report generation method according to claim 1, characterized in that: The step of creating a target storage space on the first server required for analyzing the code of the target product includes: Create a first storage volume whose lifecycle is independent of the container on the first server, and use the first storage volume as the target storage space; or Create a second storage volume on the first server with the same life cycle as the container, and use the first storage volume as the target storage space; or An NFS file system is created on the first server, and the NFS file system is used as the target storage space.
3. The report generation method according to claim 1 or 2, characterized in that: The establishing of a logical association relationship between the plurality of second servers and the target storage space to connect the first server with the plurality of second servers includes: Determining a configuration file that can reference the target storage space; Based on the configuration file, the address information of the target storage space and the address information of the multiple second servers, a logical association relationship is established between the multiple second servers and the target storage space to connect the first server and the multiple second servers.
4. The report generation method according to claim 1 or 2, characterized in that: The storing, based on the logical association, the test files required for analyzing the code of the target product in the plurality of second servers into the target storage space includes: Determine a code coverage data file of the target product; Determine the bytecode file of the current version and the bytecode file of the baseline version of the target product; Based on the storage identifier of the target product, the code coverage data file, the bytecode file of the current version, and the bytecode file of the baseline version are stored as the test files in the target storage space.
5. The report generation method according to claim 4, characterized in that: The determining of the code coverage data file of the target product includes: Determining test cases for each interface in the target product based on the interface document of the target product; Testing the code of the target product based on the test case; During testing, a code coverage tool is called to analyze the code of the target product and generate a code coverage data file of the target product.
6. The report generation method according to claim 4 or 5, characterized in that: The determining of the bytecode file of the current version and the bytecode file of the baseline version of the target product includes: Determining, from the attribute information of the target product, a first storage path of the bytecode file of the current version and a second storage path of the bytecode file of the baseline version; Based on the first storage path, obtaining the bytecode file of the current version; Based on the second storage path, the bytecode file of the baseline version is obtained.
7. The report generation method according to claim 1 to 2 or 5, characterized in that: The performing coverage analysis on the test file to obtain an incremental code coverage report for the target product includes: Determining a code line coverage status data file of the target product based on the bytecode file of the current version and the code coverage data file in the test file; Determining, based on the bytecode file of the current version and the bytecode file of the baseline version in the test file, the incremental code lines of the target product when the current version is compared with the baseline version; The incremental code coverage report is determined based on the incremental code lines and the code line coverage status data file.
8. The report generation method according to claim 7, characterized in that: The determining of the code line coverage status data file of the target product based on the bytecode file of the current version and the code coverage data file in the test file includes: A global coverage analysis is performed on the bytecode file of the current version and the code coverage data file to obtain the code line coverage status data file.
9. The report generation method according to claim 7, characterized in that: The determining, based on the bytecode file of the current version and the bytecode file of the baseline version in the test file, the incremental code lines of the target product when the current version is compared with the baseline version, includes: Decompiling the bytecode file of the current version to obtain a byte array file of the current version; Decompiling the bytecode file of the baseline version to obtain a byte array file of the baseline version; The byte array file of the current version is compared with the byte array file of the baseline version to obtain the incremental code line.
10. A report generating device, characterized in that: The report generating device comprises: A configuration module, configured to create, on the first server, a target storage space required for analyzing the code of the target product; The configuration module is configured to establish a logical association relationship between the plurality of second servers and the target storage space, so as to connect the first server with the plurality of second servers; a storage module, configured to store, based on the logical association, the test files required for analyzing the code of the target product in the plurality of second servers into the target storage space; The analysis module is used to perform coverage analysis on the test file to obtain an incremental code coverage report for the target product.
11. A first server comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 9 are implemented.
12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.
13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.