Multi-module multi-round test coverage rate report generation method, device and equipment
By deploying JaCoCo probes in containers to collect and merge coverage data from various application modules, the problem of JaCoCo's inability to generate multi-round test coverage reports was solved, enabling effective evaluation of changed code and improved coverage.
Patent Information
- Application Number
- CN202411411019.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-10
- Publication Date
- 2025-01-24
Smart Images
Figure CN119357051A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computers, and in particular to a method, device, equipment and storage medium for generating a multi-module multi-round test coverage report. Background Art
[0002] Jacoco is an open source Java code coverage tool that uses instrumentation technology to collect coverage data to help developers measure the testing of functional codes, including line coverage, branch coverage, etc.
[0003] However, jacoco can only generate coverage reports for one round of testing. For multiple rounds of test code with changes, jacoco cannot use the merge coverage function to generate coverage reports. Software testing usually requires multiple rounds of testing to ensure the quality of software delivery. Moreover, jacoco can only generate coverage reports for the entire code, and the development of new functions is more concerned with the impact of changed code on delivery quality. Testers cannot evaluate the scope of testing through full coverage reports. Summary of the invention
[0004] The main purpose of the present invention is to solve the technical problem of how to obtain and merge multiple rounds of test coverage reports of application modules and improve the coverage of application tests.
[0005] A first aspect of the present invention provides a method for generating a multi-module multi-round test coverage report, the method comprising:
[0006] Enable each application module and load the jacoco probe. Each application module and the jacoco probe are deployed in a container to collect coverage data of each application module.
[0007] Obtain coverage data of each round of testing of each application module and difference codes of each round of testing of each application module, and calculate the method line number of each application module changed in each round of testing according to the difference codes, and generate changed method line data;
[0008] Obtain the jar files of the respective application modules, and generate coverage files of multiple rounds of tests for each application module through jacococli according to the jar files, the changed method line data, and the coverage data;
[0009] The coverage files of the multiple rounds of tests of each application module are merged to generate a multi-module multi-round test coverage report.
[0010] Optionally, in a first implementation of the first aspect of the present invention, the obtaining of coverage data of each round of testing of each application module and difference codes of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference codes, and generating the changed method line data includes:
[0011] Obtaining coverage data of each round of testing of each application module;
[0012] Determining whether each of the application modules is a re-release;
[0013] If yes, redeploy the re-released application module and the jacoco probe;
[0014] If not, then the difference codes of each round of testing of each application module are obtained, and according to the difference codes, the method line number of each application module changed in each round of testing is calculated to generate changed method line data.
[0015] Optionally, in a second implementation of the first aspect of the present invention, if yes, then redeploying the re-released application module and the jacoco probe includes:
[0016] If yes, close the re-released application module, and before closing the application module, store the coverage data in a designated directory to save the coverage data of the previous version of the application module;
[0017] Redeploy the re-released application module and the jacoco probe.
[0018] Optionally, in a third implementation of the first aspect of the present invention, obtaining the difference code of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference code, and generating the changed method line data includes:
[0019] Use the git command to switch the feature branch of each application module, where the feature branch is created to develop new features;
[0020] When each round of testing switches to the corresponding feature branch of each application module, the difference code of each round of testing of each application module is obtained by using the git diff command;
[0021] According to the difference code, the method line number of each application module changed in each round of testing is calculated to generate changed method line data.
[0022] Optionally, in a fourth implementation of the first aspect of the present invention, before obtaining the difference code of each round of testing of each application module by using the git diff command, the method further includes:
[0023] Get the class files of the previous version of the application module and the class files of the current version of the application module;
[0024] According to the class file of the previous version application module and the class file of the current version application module, obtaining the offset of the method of the previous version application module in the class file and the offset of the method of the current version application module in the class file;
[0025] If the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is determined that the method of the current version application module has changed compared to the method of the previous version application module.
[0026] Optionally, in a fifth implementation of the first aspect of the present invention, if the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, then determining that the method of the current version application module has changed compared to the method of the previous version application module includes:
[0027] If the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is determined that the method of the current version application module has changed compared with the method of the previous version application module;
[0028] Delete the coverage data of the previous version of the application module and calculate the coverage data of the current version of the application module.
[0029] Optionally, in a sixth implementation of the first aspect of the present invention, obtaining the jar files of the respective application modules, and generating coverage files for multiple rounds of testing of each application module through jacococli according to the jar files, the change method line data, and the coverage data includes:
[0030] Add input parameters in jacococli;
[0031] Obtain the jar files of each application module;
[0032] Call the preset interface, pass the jar file, the changed method line data, and the coverage data into the jacococli through the input parameters, and generate coverage files for multiple rounds of testing for each application module.
[0033] A second aspect of the present invention provides a multi-module multi-round test coverage report generation device, comprising: a memory and at least one processor, the memory storing instructions, the memory and the at least one processor being interconnected via lines; the at least one processor calling the instructions in the memory so that the multi-module multi-round test coverage report generation device executes the above-mentioned multi-module multi-round test coverage report generation method.
[0034] A third aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the above-mentioned multi-module multi-round test coverage report generation method.
[0035] In an embodiment of the present invention, each application module is enabled, and a jacoco probe is loaded. Each application module and the jacoco probe are deployed in a container to collect coverage data of each application module; the coverage data of each round of testing of each application module and the difference code of each round of testing of each application module are obtained, and the method line number of each round of testing change of each application module is calculated according to the difference code to generate the change method line data; the jar file of each application module is obtained, and the coverage file of multiple rounds of testing of each application module is generated through jacococli according to the jar file, the change method line data, and the coverage data; the coverage file of multiple rounds of testing of each application module is merged to generate a multi-module multi-round test coverage report. In the present invention, by deploying the jacoco probe and each application module in the container, the coverage data of each round of testing of each application module can be collected, and the coverage file of multiple rounds of testing of each application module can be generated through jacococli according to the change method line data and the coverage data, so that the test case can be adjusted for the change method to improve the coverage of the application test. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] Figure 1 A schematic diagram of an embodiment of a method for generating a multi-module multi-round test coverage report in an embodiment of the present invention;
[0037] Figure 2 A schematic diagram of an embodiment of a device for generating a multi-module multi-round test coverage report according to an embodiment of the present invention;
[0038] Figure 3 The figure is a schematic diagram of an embodiment of a device for generating a multi-module multi-round test coverage report in an embodiment of the present invention. DETAILED DESCRIPTION
[0039] The embodiments of the present invention provide a method, device, equipment and storage medium for generating a multi-module multi-round test coverage report.
[0040] The embodiments disclosed in the present invention will be described in more detail below with reference to the accompanying drawings. Although certain embodiments disclosed in the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present invention. It should be understood that the drawings and embodiments disclosed in the present invention are only for exemplary purposes and are not intended to limit the scope of protection disclosed in the present invention.
[0041] In the description of the embodiments disclosed in the present invention, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.
[0042] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 , an embodiment of the method for generating a multi-module multi-round test coverage report in an embodiment of the present invention includes:
[0043] S100, enable each application module and load the jacoco probe.
[0044] In this embodiment, the application is divided into multiple modules, wherein the multiple modules refer to a microservice architecture. The microservice architecture is a distributed architecture pattern based on service splitting, which is achieved by splitting the application into a set of smaller, more independent service units. The code coverage analysis using jacoco is usually analyzed at the microservice application level, and each microservice is usually an independent code repository. First, modify the jacoco code to determine the combined coverage of the same class file, deploy each application module and the modified jacoco probe into the container, the jacoco probe is usually a jar file, and when starting the application module, it is necessary to add the JVM startup parameter to load the jacoco probe, which usually requires adding the jacoco agent parameter javaagent in the startup command to specify the location of the jacoco probe so that the jacoco probe can be loaded when the application module is running. Optionally, the container of the application module can be built or run through other container orchestration tools (such as Kubernetes). When each application module runs in the container, the jacoco probe will start collecting code coverage data. In addition, you can also configure the TCP Server mode provided by jacoco, or use other tools (such as jacoco's command line tool) to collect and analyze these coverage data. There is no restriction here.
[0045] S200, obtaining coverage data of each round of testing of each application module and difference codes of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference codes, and generating changed method line data.
[0046] In this embodiment, when the jacoco probe is deployed into the container together with the application module, its main purpose is to insert the Java bytecode at runtime to collect code coverage data. There are two main ways of inserting jacoco: Offline mode and On-the-fly mode. In Offline mode, jacoco inserts the Java bytecode, which needs to be done before the code runs. This mode involves modifying the JAR package and generating coverage information to the file during operation; unlike the Offline mode, the On-the-fly mode allows the bytecode to be modified dynamically while the program is running. This mode uses javaagent to dynamically modify the bytecode, and can automatically generate an exec file after the program is closed. When each application module is enabled, the jacoco probe is loaded to obtain the code coverage data of each round of testing of each application module, wherein each application module can be started successively or simultaneously. If the method code of the application module is changed, the code coverage data can be tested for the changed method, and the difference code in the changed method is obtained, the line number of the difference code in the changed method is calculated, and the changed method line data is generated.
[0047] S300, obtaining the jar file of each application module, and generating a coverage file of multiple rounds of testing of each application module through jacococli according to the jar file, the changed method line data, and the coverage data.
[0048] In this embodiment, the algorithm for jacoco to determine the coverage of the same class file is modified. For the new function test of the same application, it is usually necessary to change the code on a feature branch. Therefore, the class files generated by java compilation each time may be inconsistent. For inconsistent class files, calling the merge command of jacoco cannot be merged. When the original jacoco calculates the method level coverage, if the code is changed, the offset of the method in the class file is inconsistent, resulting in the inability to merge when calling jacoco merge when the code is changed. Therefore, in the improved code, the offset is inconsistent but the method signature is consistent. The method is considered to be modified. Then compile the modified jacoco code, obtain the jar file of each application module, and then use the jar file, the change method line data, and the coverage data to generate the coverage file of multiple rounds of testing for each application module through jacococli, wherein jacococli is an open source coverage tool that provides a command line interface that allows users to perform basic operations in the command line. This tool and all its dependencies are packaged in jacococli.jar and provided for download with jacoco.
[0049] S400, merging the coverage files of multiple rounds of tests of each application module to generate a multi-module multi-round test coverage report.
[0050] In this embodiment, for Spring Boot applications, class files only contain files of the current startup project. If the jacococli command is used for analysis, the code of some public packages cannot be analyzed. Therefore, the jar file in the SpringBoot application is parsed to achieve the purpose of multi-module coverage analysis. First, the class files and coverage data of multiple rounds of tests of each application module are merged into a coverage file in chronological order. Then, the coverage file of each application module, the compiled jar file, and the change method line data are passed to jacococli. The coverage files of multiple rounds of tests of each application module are merged through jacococli to generate a multi-module multi-round test coverage report.
[0051] In an optional implementation of the first aspect of the present invention, coverage data of each round of testing of each application module and difference codes of each round of testing of each application module are obtained, and according to the difference codes, the method line number of each application module changed in each round of testing is calculated, and the changed method line data is generated, including:
[0052] Get the coverage data of each round of testing for each application module; determine whether each application module is a re-release; if so, redeploy the re-released application module and jacoco probe; if not, get the difference code of each round of testing for each application module, and calculate the method line number of each application module that has been changed in each round of testing based on the difference code, and generate the changed method line data.
[0053] In this embodiment, after deploying each application module and jacoco probe, copy the compiled jar file of the application module to the specified directory. By copying the jar file to the specified directory, the jacoco service can be easily deployed to different environments, such as test environment, production environment, etc., and call the preset interface to periodically obtain coverage data to the specified directory. Then, determine whether each application module is a re-released version. If an application module is a re-released version, it means that the application module has code changes, then redeploy the re-released application module and jacoco probe, increase the jacoco agent parameters through the java application startup parameters, and call the interface periodically to obtain the coverage data of the re-released application module; if the application module is not a re-released version, then obtain the difference code of each application module in each round of testing, calculate the line number of the method changed in each round of testing of each application module, and generate the changed method line data.
[0054] In an optional implementation of the first aspect of the present invention, if yes, then redeploying the re-released application module and the jacoco probe includes:
[0055] If so, close the re-released application module, and before closing the application module, store the coverage data in the specified directory to save the coverage data of the previous version of the application module; redeploy the re-released application module and jacoco probe.
[0056] In this embodiment, if an application module is re-released, the re-released application module is closed, and before closing the application module, the acquired coverage data is also stored in a designated directory to compare the coverage data of different versions of application modules.
[0057] In an optional implementation of the first aspect of the present invention, obtaining the difference code of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference code, and generating the changed method line data includes:
[0058] Use the git command to switch the feature branch of each application module. The feature branch is a branch created to develop new functions. When each round of testing switches to the corresponding feature branch of each application module, use the git diff command to obtain the difference code of each round of testing for each application module. Based on the difference code, calculate the line number of the method changed in each round of testing for each application module, and generate the changed method line data.
[0059] In this embodiment, by loading the jacoco probe when each microservice is started, the coverage report is output regularly, and the difference code between the feature branches and the trunk branches of multiple code repositories is obtained at the same time, and passed to jacoco for differential code coverage analysis, where the trunk branch and the feature branch are the two main branch types in version control, and they play different roles in the software development process. The trunk branch usually contains the stable version of the project and is the basic branch of the project. All new features are first developed on the feature branch and then merged into the trunk after development. The trunk should always remain in a deployable state and represent the latest stable version of the project. The feature branch is a branch created from the trunk for developing new features or fixing bugs. When the work on the feature branch is completed and tested, it will be merged back to the trunk so that team members can perform independent development work without affecting other developers. After adding a new function to the feature branch of each application module, the corresponding feature branch can be tested to obtain the corresponding coverage data to determine whether to execute the new function. Specifically, the feature branch of each application module is switched through the git command. When each round of testing switches to the corresponding feature branch of each application module, the git diff command is used to obtain the difference code of each round of testing of each application module. For example, assuming that the name of the new feature branch is feature-abc and the main branch name is master, the branch is switched through the command git checkoutfeature-abc, and the changed code is obtained through the command git diff master. Then, the code change lines in the git diff command are extracted, the modified java code methods are calculated, and the code is colored according to the changed methods.
[0060] In an optional implementation of the first aspect of the present invention, before obtaining the difference code of each round of testing of each application module through the git diff command, the method further includes:
[0061] Get the class file of the previous version application module and the class file of the current version application module; according to the class file of the previous version application module and the class file of the current version application module, get the offset of the method of the previous version application module in the class file and the offset of the method of the current version application module in the class file; if the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is determined that the method of the current version application module has changed compared with the method of the previous version application module.
[0062] In this embodiment, it is determined whether the method of the current version of the application module has changed compared with the method of the previous version of the application module. If there is a change, jacococli is used to obtain the corresponding coverage file based on the class file of the method and the coverage data of the corresponding test of the current version of the application module. Specifically, it is determined whether the method of the current version of the application module has changed compared with the method of the previous version of the application module, including: determining whether the offset of the method of the previous version of the application module in the class file is consistent with the offset of the method of the current version of the application module in the class file, and whether the method signatures are consistent. If the offsets are inconsistent and the method signatures are consistent, it means that the Java code method has changed.
[0063] In an optional implementation of the first aspect of the present invention, if the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signature is consistent, then determining that the method of the current version application module is changed from the method of the previous version application module includes:
[0064] If the offset of the method of the previous version of the application module in the class file is inconsistent with the offset of the method of the current version of the application module in the class file, and the method signature is consistent, it is determined that the method of the current version of the application module has changed compared with the method of the previous version of the application module; delete the coverage data of the previous version of the application module, and calculate the coverage data of the current version of the application module.
[0065] In this embodiment, if the offset of the application module method of the previous version in the class file is inconsistent with the offset of the application module method of the current version in the class file, and the method signature is consistent, it is considered that the method has been modified. At this time, the coverage data calculated by the previous version is discarded, and the coverage data is recalculated using the current version, so as to achieve the purpose of generating a method-level coverage report even when the code is modified.
[0066] In an optional implementation of the first aspect of the present invention, obtaining the jar file of each application module, and generating a coverage file of multiple rounds of testing of each application module through jacococli according to the jar file, the change method line data, and the coverage data includes:
[0067] Add input parameters to jacococli; obtain the jar files of each application module; call the preset interface, pass the jar files, change method line data, and coverage data to jacococli through input parameters, and generate coverage files for multiple rounds of tests for each application module.
[0068] In this embodiment, when using the jacococli tool, its behavior can be changed by adding input parameters. Since jacococli cannot automatically obtain historical class files and changed method line data, input parameters - historical class files and changed line json data - are added to jacococli. Through the input parameters of jacococli, the compiled jar file, changed method line data, and coverage data are passed to jacococli, and coverage files for multiple rounds of tests for each application module are generated through jacococli.
[0069] See also Figure 2 A second aspect of the present invention provides a multi-module multi-round test coverage report generation device, the multi-module multi-round test coverage report generation device comprising:
[0070] The probe loading module 10 is used to enable each application module, load the jacoco probe, and deploy each application module and the jacoco probe in a container to collect coverage data of each application module;
[0071] The change data generation module 20 is used to obtain the coverage data of each round of testing of each application module and the difference code of each round of testing of each application module, and calculate the method line number of each application module changed in each round of testing according to the difference code, and generate the change method line data;
[0072] The coverage file generation module 30 is used to obtain the jar file of each application module, and generate the coverage file of multiple rounds of testing of each application module through jacococli according to the jar file, the change method line data, and the coverage data;
[0073] The coverage file synthesis module 40 is used to merge the coverage files of multiple rounds of tests of each application module to generate a multi-module multi-round test coverage report.
[0074] In an optional implementation of the second aspect of the present invention, the change data generation module 20 is also used to obtain the coverage data of each round of testing of each application module; determine whether each application module is a re-released version; if so, redeploy the re-released application module and jacoco probe; if not, obtain the difference code of each round of testing of each application module, and calculate the method line number of each application module changed in each round of testing based on the difference code, and generate the changed method line data.
[0075] In an optional implementation of the second aspect of the present invention, the change data generation module 20 is also used to, if yes, close the re-released application module, and before closing the application module, store the coverage data in a designated directory to save the coverage data of the previous version of the application module; and redeploy the re-released application module and jacoco probe.
[0076] In an optional implementation of the second aspect of the present invention, the change data generation module 20 is also used to switch the feature branch of each application module through the git command, and the feature branch is a branch created for developing new functions; when each round of testing switches to the corresponding feature branch of each application module, the difference code of each round of testing of each application module is obtained through the git diff command; based on the difference code, the method line number of each application module changed in each round of testing is calculated, and the change method line data is generated.
[0077] In an optional implementation manner of the second aspect of the present invention, the multi-module multi-round test coverage report generation device further includes:
[0078] The method judgment module is used to obtain the class file of the previous version application module and the class file of the current version application module; according to the class file of the previous version application module and the class file of the current version application module, obtain the offset of the method of the previous version application module in the class file and the offset of the method of the current version application module in the class file; if the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is judged that the method of the current version application module has changed compared with the method of the previous version application module.
[0079] In an optional implementation of the second aspect of the present invention, the method judgment module is also used to determine that the method of the current version of the application module has changed compared with the method of the previous version of the application module if the offset of the method of the previous version of the application module in the class file is inconsistent with the offset of the method of the current version of the application module in the class file, and the method signature is consistent; delete the coverage data of the previous version of the application module, and calculate the coverage data of the current version of the application module.
[0080] In an optional implementation of the second aspect of the present invention, the coverage file generation module 30 is also used to add input parameters to jacococli; obtain the jar file of each application module; call the preset interface, pass the jar file, change method line data, and coverage data to jacococli through input parameters, and generate coverage files for multiple rounds of testing for each application module.
[0081] Figure 3It is a structural schematic diagram of a multi-module multi-round test coverage report generation device provided by an embodiment of the present invention. The multi-module multi-round test coverage report generation device 500 may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 510 (for example, one or more processors) and a memory 520, and one or more storage media 530 (for example, one or more mass storage devices) storing application programs 533 or data 532. Among them, the memory 520 and the storage medium 530 can be short-term storage or permanent storage. The program stored in the storage medium 530 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the multi-module multi-round test coverage report generation device 500. Furthermore, the processor 510 can be configured to communicate with the storage medium 530 to execute a series of instruction operations in the storage medium 530 on the multi-module multi-round test coverage report generation device 500.
[0082] The multi-module multi-round test coverage report generation device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input and output interfaces 560, and / or one or more operating systems 531, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will appreciate that Figure 3 The structure of the multi-module multi-round test coverage report generation device shown does not constitute a limitation on the multi-module multi-round test coverage report generation device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.
[0083] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are executed on a computer, the computer executes the steps of the multi-module multi-round test coverage report generation method.
[0084] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0085] In addition, although each operation is described in a specific order, this should be understood as requiring such operation to be performed in the specific order shown or in a sequential order, or requiring that all illustrated operations should be performed to obtain desired results. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single implementation in combination. On the contrary, the various features described in the context of a single implementation can also be implemented in multiple implementations individually or in any suitable sub-combination mode.
[0086] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.
Claims
1. A method for generating a multi-module multi-round test coverage report, characterized in that: The multi-module multi-round test coverage report generation method comprises: Enable each application module and load the jacoco probe. Each application module and the jacoco probe are deployed in a container to collect coverage data of each application module. Obtain coverage data of each round of testing of each application module and difference codes of each round of testing of each application module, and calculate the method line number of each application module changed in each round of testing according to the difference codes, and generate changed method line data; Obtain the jar files of the respective application modules, and generate coverage files of multiple rounds of tests for each application module through jacococli according to the jar files, the changed method line data, and the coverage data; The coverage files of the multiple rounds of tests of each application module are merged to generate a multi-module multi-round test coverage report.
2. The method for generating a multi-module multi-round test coverage report according to claim 1, characterized in that: The obtaining of the coverage data of each round of testing of each application module and the difference code of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference code, and generating the changed method line data includes: Obtaining coverage data of each round of testing of each application module; Determining whether each of the application modules is a re-release; If yes, redeploy the re-released application module and the jacoco probe; If not, then the difference codes of each round of testing of each application module are obtained, and according to the difference codes, the method line number of each application module changed in each round of testing is calculated to generate changed method line data.
3. The method for generating a multi-module multi-round test coverage report according to claim 2, characterized in that: If so, redeploying the re-released application module and the jacoco probe includes: If yes, close the re-released application module, and before closing the application module, store the coverage data in a designated directory to save the coverage data of the previous version of the application module; Redeploy the re-released application module and the jacoco probe.
4. The method for generating a multi-module multi-round test coverage report according to claim 2, characterized in that: The obtaining of the difference codes of each round of testing of each application module, and calculating the method line number of each application module changed in each round of testing according to the difference codes, and generating the changed method line data includes: Use the git command to switch the feature branch of each application module, where the feature branch is created to develop new features; When each round of testing switches to the corresponding feature branch of each application module, the difference code of each round of testing of each application module is obtained by using the git diff command; According to the difference code, the method line number of each application module changed in each round of testing is calculated to generate changed method line data.
5. The method for generating a multi-module multi-round test coverage report according to claim 4, characterized in that: Before obtaining the difference code of each round of testing of each application module by using the git diff command, the method further includes: Get the class files of the previous version of the application module and the class files of the current version of the application module; According to the class file of the previous version application module and the class file of the current version application module, obtaining the offset of the method of the previous version application module in the class file and the offset of the method of the current version application module in the class file; If the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is determined that the method of the current version application module has changed compared to the method of the previous version application module.
6. The method for generating a multi-module multi-round test coverage report according to claim 5, characterized in that: If the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, then determining that the method of the current version application module has changed compared to the method of the previous version application module includes: If the offset of the method of the previous version application module in the class file is inconsistent with the offset of the method of the current version application module in the class file, and the method signatures are consistent, it is determined that the method of the current version application module has changed compared with the method of the previous version application module; Delete the coverage data of the previous version of the application module and calculate the coverage data of the current version of the application module.
7. The method for generating a multi-module multi-round test coverage report according to claim 1, characterized in that: The obtaining of the jar files of the respective application modules and generating the coverage files of multiple rounds of testing of each application module through jacococli according to the jar files, the change method line data, and the coverage data comprises: Add input parameters in jacococli; Obtain the jar files of each application module; Call the preset interface, pass the jar file, the changed method line data, and the coverage data into the jacococli through the input parameters, and generate coverage files for multiple rounds of testing for each application module.
8. A multi-module multi-round test coverage report generation device, characterized in that: The multi-module multi-round test coverage report generating device comprises: A probe loading module is used to enable each application module and load a jacoco probe. Each application module and the jacoco probe are deployed in a container to collect coverage data of each application module. A change data generation module, used to obtain the coverage data of each round of testing of each application module and the difference code of each round of testing of each application module, and calculate the method line number of each application module changed in each round of testing according to the difference code, and generate change method line data; A coverage file generation module is used to obtain the jar files of the respective application modules, and generate coverage files of multiple rounds of testing of each application module through jacococli according to the jar files, the change method line data, and the coverage data; The coverage file synthesis module is used to merge the coverage files of multiple rounds of tests of each application module to generate a multi-module multi-round test coverage report.
9. A multi-module multi-round test coverage report generation device, characterized in that: The multi-module multi-round test coverage report generating device comprises: a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor calls the instructions in the memory to enable the multi-module multi-round test coverage report generation device to execute the multi-module multi-round test coverage report generation method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for generating a multi-module multi-round test coverage report according to any one of claims 1 to 7 is implemented.