Code coverage rate report generation method and system

Abstract

The invention provides a code coverage rate report generation method and system, and belongs to the field of software test.The code coverage rate report generation method comprises the steps that a command line interface tool is called to initiate a data dump request to a target server side, and coverage rate execution data returned by the target server side is received; wherein the target server runs a tested application loaded with a coverage rate agent program, and the coverage rate agent program is configured to be in a network monitoring mode; obtaining a source code file path and a byte code file path corresponding to the tested application; and generating a code coverage rate report according to the source code file path, the byte code file path and the coverage rate execution data. According to the invention, the command line interface tool is adopted to remotely pull the coverage rate data from the server configured to be in the network monitoring mode, and the report is generated locally based on the dynamically acquired source code and byte code path, so that the coverage rate statistics and decoupling of the server file system and the specific construction tool are realized; and the universality and the flexibility of a code coverage rate statistical scheme are improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and system for generating code coverage reports. Background Technology

[0002] In continuous integration and automated testing processes, efficiently collecting code execution data from server-side applications and generating coverage reports is a key means of ensuring software quality.

[0003] Existing technologies typically employ a JaCoCo tool combined with the Ant build tool to generate reports. The main process involves configuring the coverage agent for the application under test on the server to output data to a local file, writing execution data to the server's local disk; then copying this data file locally, and relying on a written Ant build script containing fixed path configurations to parse the data and generate the report. However, this approach has the following drawbacks: First, in containerized or cloud-native environments, the server-side local file storage method is highly susceptible to data loss due to container restarts or destruction. Second, relying on the Ant build script tightly couples the report generation process with the specific build tool and its static configuration files, making it inflexible in the face of multi-module projects or directory structure changes, resulting in poor versatility and flexibility in code coverage statistics solutions. Summary of the Invention

[0004] This invention provides a code coverage report generation method and system to address the shortcomings of existing technologies and improve the versatility and flexibility of code coverage statistics schemes.

[0005] This invention provides a method for generating code coverage reports, comprising the following steps: The command-line interface tool is invoked to initiate a data dump request to the target server and receive coverage execution data returned by the target server; wherein, the target server is running the application under test with the coverage proxy program loaded, and the coverage proxy program is configured to network listening mode. Obtain the source code file path and bytecode file path corresponding to the application under test; A code coverage report is generated based on the source code file path, the bytecode file path, and the coverage execution data.

[0006] According to a code coverage report generation method provided by the present invention, obtaining the source code file path and bytecode file path corresponding to the application under test includes: Identify at least one submodule under the project directory of the application under test; For each of the sub-modules, the corresponding source code storage path and bytecode generation path are determined respectively; By concatenating the source code storage paths of all the sub-modules, a source code parameter list is obtained; By concatenating the bytecode generation paths of all the submodules, a bytecode parameter list is obtained; The source code parameter list is determined as the source code file path, and the bytecode parameter list is determined as the bytecode file path.

[0007] According to a code coverage report generation method provided by the present invention, determining the corresponding source code storage path and bytecode generation path includes: Obtain the directory specifications of the project build tool used by the application under test; According to the directory specification, the root directory of the submodule is concatenated with the preset source code directory identifier to obtain the source code storage path; According to the directory specification, the root directory of the submodule is concatenated with a preset compilation output directory identifier to obtain the bytecode generation path.

[0008] A code coverage report generation method provided by the present invention further includes: Check if a historical report directory exists under the specified output path; If the historical report directory exists, execute the deletion command to remove the historical report directory; Create a target directory under the specified output path to store the newly generated code coverage report.

[0009] According to a code coverage report generation method provided by the present invention, the step of initiating a data dump request to the target server by calling a command-line interface tool includes: Obtain the IP address of the target server and the port number that the coverage proxy program is listening on; The command-line interface tool is invoked to perform a dump command, using the IP address and port number as connection parameters to establish a TCP connection with the coverage proxy program; The system receives coverage execution data in binary format output by the coverage agent via the TCP connection and saves it locally.

[0010] According to a code coverage report generation method provided by the present invention, the step of generating a code coverage report based on the source code file path, the bytecode file path, and the coverage execution data includes: Determine the target output format and character encoding parameters for the code coverage report; The report generation command of the command-line interface tool is invoked, and the source code file path, the bytecode file path, the coverage execution data, and the character encoding parameters are passed to the command-line interface tool as input parameters. Based on the target output format, generate a report file in Hypertext Markup Language (HTML), Extensible Markup Language (XML), or comma-separated value format.

[0011] This invention also provides a code coverage report generation system, comprising the following modules: The first processing module is used to call the command-line interface tool to initiate a data dump request to the target server and receive the coverage execution data returned by the target server; wherein, the target server runs the application under test with the coverage proxy program loaded, and the coverage proxy program is configured to network listening mode. The second processing module is used to obtain the source code file path and bytecode file path corresponding to the application under test. The third processing module is used to generate a code coverage report based on the source code file path, the bytecode file path, and the coverage execution data.

[0012] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the code coverage report generation method as described above.

[0013] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the code coverage report generation method as described above.

[0014] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the code coverage report generation method as described above.

[0015] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: By invoking a command-line interface tool to initiate a data dump request to the target server running a coverage agent configured to listen for network traffic, and receiving the returned coverage execution data, the decoupling of coverage data acquisition from the server's local file system is achieved. This avoids the disk I / O overhead and data loss risks caused by container destruction resulting from generating files on the server, and eliminates the need to deploy a complex build environment on the server. Furthermore, by obtaining the source code and bytecode file paths of the application under test, and combining them with the remotely obtained execution data, a report is generated locally using the command-line interface tool. This eliminates the reliance on specific integrated build tools such as Ant and fixed build scripts for report generation, enabling flexible configuration of multi-module path parameters for report generation locally. This significantly improves the versatility and flexibility of the code coverage statistics solution. Attached Figure Description

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

[0017] Figure 1 This is one of the flowcharts illustrating the code coverage report generation method provided by this invention.

[0018] Figure 2 This is the second flowchart of the code coverage report generation method provided by the present invention.

[0019] Figure 3 This is the third flowchart of the code coverage report generation method provided by the present invention.

[0020] Figure 4 This is the fourth flowchart of the code coverage report generation method provided by the present invention.

[0021] Figure 5 This is the fifth flowchart of the code coverage report generation method provided by the present invention.

[0022] Figure 6 This is the sixth flowchart of the code coverage report generation method provided by this invention.

[0023] Figure 7 This is a schematic diagram of the code coverage report generation system provided by the present invention.

[0024] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0026] It should be noted that in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The terms "upper," "lower," etc., indicating orientation or positional relationships according to the accompanying drawings, are only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the system or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0027] The terms "first," "second," etc., used in this invention are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0028] The following is combined with Figures 1 to 8 This invention describes the code coverage report generation method, system, electronic device, storage medium, and computer program product provided by the present invention.

[0029] This application provides a method for generating a code coverage report. The method can be executed by any computer device with computing and network communication capabilities, such as a desktop computer, laptop computer, or server (especially a continuous integration / continuous deployment CI / CD server). This computer device is connected to the target server running the application under test via a network.

[0030] Figure 1 This is one of the flowcharts illustrating the code coverage report generation method provided by this invention. For example... Figure 1 As shown, the method includes the following steps: Step 101: Call the command-line interface tool to initiate a data dump request to the target server and receive the coverage execution data returned by the target server.

[0031] In this embodiment, a Command Line Interface Tool (CLI) refers to a standalone executable package that interacts via text commands and does not depend on a specific integrated build environment (such as the Ant environment). For example, in practical applications, this command line interface tool may specifically be the jacococli.jar toolkit provided by the JaCoCo open-source project.

[0032] Before performing this step, the application under test is already running on the target server. To achieve code coverage statistics for the application under test, a coverage agent (e.g., jacocoagent.jar) is loaded upon startup. It is worth noting that in this embodiment, the coverage agent is configured in network listening mode (e.g., output=tcpserver is configured in the startup parameters). In this mode, the target server exposes its service through a specific Transmission Control Protocol (TCP) port, waiting for external connections, without actively generating statistical files locally on the target server. This design separates the generation and storage of statistical data, reducing the disk I / O pressure on the target server.

[0033] Specifically, the computer device invokes the dump command of the command-line interface tool via the operating system console or a script. The command-line interface tool initiates a remote connection request to the target server based on the target server's network address specified in the command. Once the connection is established, the coverage agent packages the probe execution information recorded in memory and returns it to the computer device as a network stream. The computer device receives this data stream and saves it as binary coverage execution data (usually named a .exec file).

[0034] Step 102: Obtain the source code file path and bytecode file path of the application under test.

[0035] After obtaining the coverage execution data, in order to restore the abstract binary data into visual code logic, the computer device needs to locate the project file of the application under test.

[0036] Specifically, the bytecode file path refers to the directory location of the .class files generated after the application under test is compiled by the Java compiler. The source code file path refers to the directory location of the .java source files written by the developer. In this embodiment, the computer device can pull and compile the source code from the local file system or through a version control system (such as Git), thereby determining the specific storage path of the aforementioned files on the local disk.

[0037] It should be noted that these paths can be obtained by the user manually specifying them or by automatic identification through preset script logic. This embodiment does not impose specific restrictions on this, as long as it can provide accurate file index addresses for subsequent steps.

[0038] Step 103: Generate a code coverage report based on the source code file path, bytecode file path, and coverage execution data.

[0039] After all the necessary materials are prepared, the computer device once again invokes the command-line interface tool to execute the report generation command.

[0040] Specifically, the computer device uses the coverage execution data obtained in step 101 as the data source, the bytecode file path obtained in step 102 as the basis for class structure parsing, and the source code file path as the basis for source code highlighting, all of which are passed as input parameters to the command-line interface tool. Upon receiving the above input, the command-line interface tool performs internal data analysis, mapping the binary probe data to specific classes and methods, and combining this with the source code content to ultimately synthesize a human-readable code coverage report. This report can be generated according to requirements, allowing testers to directly view the coverage of each line of code in a browser.

[0041] The code coverage report generation method provided in this embodiment decouples the coverage statistics process from the server environment by employing a command-line interface tool that supports remote dumping. On the one hand, the target server only needs to load a lightweight agent program and start listening, without having to undertake the heavy task of report generation or install build tools such as Ant, thereby reducing the intrusion into the production environment. On the other hand, computer devices can flexibly complete data retrieval and report generation locally using the command-line interface tool, eliminating the strong dependence on specific build scripts (such as build.xml), and significantly improving the flexibility and versatility of the code coverage statistics process.

[0042] As a further refinement of the above embodiments, Figure 2This is the second flowchart illustrating the code coverage report generation method provided by this invention. In actual enterprise-level software development, the application under test is often not a monolithic application, but a multi-module project managed by build tools such as Maven or Gradle. To accurately calculate the coverage of the entire project, it is necessary to uniformly identify each sub-module within the project. For example... Figure 2 As shown, step 102 above specifically includes the following sub-steps: Step 201: Identify at least one submodule under the project directory of the application under test.

[0043] The computer device first identifies the root project directory of the application under test. This root project directory typically contains one or more functionally independent submodules. For example, a project named "push-center" might contain multiple submodules such as "push-center-core," "push-center-validation," and "push-center-rest-api." The computer device can parse the names and locations of all submodules within this project directory by reading the project configuration file (such as pom.xml) or scanning the directory structure.

[0044] Step 202: For each submodule, determine the corresponding source code storage path and bytecode generation path.

[0045] After identifying each submodule, the computer device needs to traverse each submodule to locate the location where the Java source files are stored (i.e., the source code storage path) and the location where the compiled Class files are stored (i.e., the bytecode generation path). For example, for the "push-center-core" module, the computer device determines that its source code is stored in a specific source code directory within the module folder, and determines that the bytecode generated by its compilation is stored in a specific output directory within the module folder.

[0046] Step 203: Concatenate the source code storage paths of all submodules to obtain the source code parameter list; and concatenate the bytecode generation paths of all submodules to obtain the bytecode parameter list.

[0047] Since the command-line interface tool needs to read all relevant class definitions and source code in a single execution, this embodiment uses a parameter list construction method to avoid multiple manual inputs.

[0048] Specifically, the computer device initializes two string variables in memory (corresponding to the source code parameter list and the bytecode parameter list, respectively). Then, following the traversal order, the computer device sequentially appends the source code storage path of each submodule determined in step 202 to the source code parameter list, and sequentially appends the bytecode generation path of each submodule to the bytecode parameter list.

[0049] In a preferred embodiment, to adapt to the parameter parsing rules of command-line interface tools, the computer device adds a corresponding parameter identifier before each path when concatenating paths. For example, the computer device uses Shell script logic to add the "--classfiles" identifier before each bytecode generation path and the "--sourcefiles" identifier before each source code storage path, thereby forming a long string list containing complete path information.

[0050] Step 204: Determine the source code parameter list as the source code file path and the bytecode parameter list as the bytecode file path.

[0051] After concatenating the paths of all submodules, the computer device uses the generated list of source code parameters as the final identified "source code file path" and the generated list of bytecode parameters as the final identified "bytecode file path". This means that in the subsequent step 103, the computer device passes these two aggregated lists containing the path information of all submodules to the command-line interface tool, thereby instructing the tool to analyze all submodules at once.

[0052] This embodiment effectively solves the problem of cumbersome code coverage statistics configuration in large, multi-module projects by identifying the multi-module structure of a project and constructing a parameter list using path concatenation. This method eliminates the need to hardcode the path of each module in the XML configuration file; instead, it dynamically generates a unified parameter list. This allows the solution to flexibly adapt to complex project scenarios where the number or names of modules change, further improving the efficiency and accuracy of automated report generation.

[0053] As a further refinement of the above embodiments, Figure 3 This is the third flowchart illustrating the code coverage report generation method provided by this invention. In modern software engineering, to simplify configuration, most projects follow the principle of "convention over configuration" and adopt standardized project structures. Based on this, step 202 above can be implemented in the following way: Step 301: Obtain the directory specifications of the project build tool used by the application under test.

[0054] The computer device first identifies the type of project build tool used by the application under test (e.g., Apache Maven or Gradle). Different build tools typically have fixed default directory structure specifications. In this embodiment, taking the widely used Maven build tool as an example, its default directory specification usually stipulates that Java source code should be stored in the src / main / java directory, while the compiled bytecode files should be stored in the target / classes directory. The computer device can pre-configure these specifications in scripts or dynamically obtain them by reading the project's build configuration file.

[0055] Step 302: According to the directory specification, concatenate the root directory of the submodule with the preset source code directory identifier to obtain the source code storage path; and concatenate the root directory of the submodule with the preset compilation output directory identifier to obtain the bytecode generation path.

[0056] Once the directory specification is defined, computer devices use this specification to automatically deduce the specific path of each submodule without requiring the user to manually enter the absolute location of each file.

[0057] Specifically, the computer device first determines the root directory of the submodule currently being processed (e.g., push-center / push-center-core).

[0058] Next, to obtain the source code storage path, the computer device calls a preset source code directory identifier (e.g., / src / main / java) and appends it directly to the root directory of the submodule. For example, the resulting path is push-center / push-center-core / src / main / java.

[0059] Similarly, to obtain the bytecode generation path, the computer device calls a predefined compiler output directory identifier (e.g., / target / classes) and appends it directly to the root directory of the submodule. For example, the resulting path would be push-center / push-center-core / target / classes.

[0060] The following explanation uses specific scenarios as examples: Assuming the `$sourcefiles` variable is defined in the script to store source code paths and the `$classfiles` variable is defined to store bytecode paths, when the script iterates through the `push-center-validation` submodule: The computer device identifies the root directory of this submodule as push-center / push-center-validation. It automatically appends / src / main / java to generate the source code path push-center / push-center-validation / src / main / java and adds it to the $sourcefiles variable. It also automatically appends / target / classes to generate the bytecode path push-center / push-center-validation / target / classes and adds it to the $classfiles variable.

[0061] The path determination method provided in this embodiment fully utilizes the directory specification features of standard build tools. Through simple string concatenation logic (i.e., "module root directory" + "standard relative path"), key files in deep directories can be accurately located. This method avoids using complex file system scanning algorithms, greatly improving the speed of path resolution. Furthermore, because it adheres to common industry standards, this script logic is highly portable and can be directly reused in other Java projects that follow the same directory specification, without requiring rewriting the path configuration code for each project.

[0062] To ensure the accuracy of the final code coverage report and avoid interference from older report files in the statistical results, Figure 4 This is the fourth flowchart of the code coverage report generation method provided by this invention. Before performing step 103 above, the method also includes the following preprocessing steps: Step 401: Check if a historical report directory exists under the specified output path.

[0063] The computer device first reads the pre-defined report output path configuration (e.g., the variable `report_dir=report` defined in the script). Then, the computer device checks if a folder with the same name already exists under that path using file system instructions. This folder is the "historical report directory," which may contain older report files in HTML or XML format generated previously or even earlier.

[0064] Step 402: If a historical report directory exists, execute the delete command to remove the historical report directory.

[0065] If the directory already exists in step 401 (e.g., a conditional statement in a shell script such as `if [ -d $report_dir ]` returns true), the computer will execute a deletion command (e.g., the `rm -r` command) to prevent newly generated files from merging or conflicting with old files. This command recursively removes the entire history report directory and all its subfiles, thoroughly cleaning up old statistics and ensuring a clean output environment.

[0066] Step 403: Create a target directory under the specified output path to store the newly generated code coverage report.

[0067] If it is confirmed that the history directory has been removed, or if it is directly detected in step 401 that the directory did not originally exist, the computer device will create a brand new folder under the specified output path as the "target directory". The code coverage report file generated in subsequent step 103 will be written directly to this target directory.

[0068] The following explanation uses the script logic as an example: For example, in a practical Shell script implementation, the computer device executes the following logic: 1. Define the variable report_dir=report.

[0069] 2. Determine [ -d $report_dir ].

[0070] 3. If the condition is true, output the message `echo 'Delete previous report...'` and execute `rm -r $report_dir`. This logic ensures that each time the script is executed, the user receives a newly generated `report` directory, which will inevitably contain reports generated based on the latest `.exec` data.

[0071] This embodiment achieves automated reset of the report output environment by automatically detecting and cleaning up the historical directory before generating the report. This mechanism effectively prevents data confusion caused by residual old files (e.g., old web page files not being overwritten, misleading users), ensuring that the coverage report output by each automated build remains strictly consistent with the current latest code state, thus enhancing the robustness of the automation script.

[0072] As a further refinement of the above embodiments, Figure 5This is the fifth flowchart illustrating the code coverage report generation method provided by this invention. In the traditional JaCoCo usage mode (output=file), coverage data is directly written to the server's local disk, which requires file operations on the server side. This application employs a remote dump mechanism, and step 101 above can be implemented in the following ways: Step 501: Obtain the IP address of the target server and the port number that the coverage proxy program is listening on.

[0073] Before initiating a connection, the computer device needs to know the network location of the application under test. Specifically, the IP address (Internet Protocol address) identifies the location of the host running the target server on the network; the port number identifies the TCP listening service started by the coverage agent (Java Agent) on that host. For example, the target server might be configured to listen for requests on port 6300 of 192.168.1.100. This connection information can be configured as parameters in the execution script.

[0074] Step 502: Invoke the dump command of the command-line interface tool, using the IP address and port number as connection parameters, to establish a TCP connection with the coverage agent program.

[0075] The computer device invokes the dump function provided by the command-line interface tool (e.g., the jacococli.jar dump command). When invoking, the IP address and port number obtained in step 501 are passed as command-line parameters (e.g., --address192.168.1.100 --port 6300).

[0076] Based on these parameters, the command-line interface tool initiates a TCP (Transmission Control Protocol) handshake request to the target server. At this point, the coverage agent running on the target server (configured in tcpserver mode) listens for this request and establishes a stable full-duplex network connection with the computer device.

[0077] Step 503: Receive the coverage execution data in binary format output by the coverage agent via TCP connection and save it locally.

[0078] Once the TCP connection is successfully established, the command-line interface tool sends a dump command. The coverage agent responds to this command by serializing all probe execution status data currently recorded in memory by the application under test and sending it to the computer device via the TCP connection.

[0079] The computer device receives this data stream over the network and writes it to a file on the local disk. This file is typically stored in binary format, i.e., the aforementioned overwrite execution data (e.g., named jacoco.exec). It should be noted that the generation of this file occurs entirely on the computer device (i.e., the client) side; the target server is only responsible for sending the data stream and does not perform any file writing operations.

[0080] This embodiment fully leverages the network monitoring capabilities of the coverage proxy to transmit memory data across network boundaries via TCP connections, successfully achieving "zero file writes on the server side." This improvement offers significant technical advantages: First, it solves the problem of local data loss caused by the destruction of server-side containers in containerized or cloud-native environments; second, it avoids the complex operation of mounting additional storage volumes on production servers, making the acquisition of coverage data as simple and secure as accessing a webpage.

[0081] As a further refinement of the above embodiments, Figure 6 This is the sixth flowchart illustrating the code coverage report generation method provided by this invention. After collecting all necessary metadata (source code, bytecode) and execution data (.exec file), step 103 above can be implemented in the following way: Step 601: Determine the target output format and character encoding parameters for the code coverage report.

[0082] To meet the viewing needs in different scenarios, computer equipment first needs to determine the output format of the report.

[0083] Target output format: This refers to the organization of the report file. For example, HTML format is usually chosen for interactive viewing by testers; XML format is usually chosen for automated parsing by CI tools such as Jenkins; and CSV format is usually chosen for data analysis and statistics.

[0084] Character encoding parameter: This refers to the character set standard (e.g., UTF-8 or GBK) used when parsing the source file and generating the report. Since the source code may contain Chinese characters, if the correct encoding is not specified, the generated report may contain garbled characters.

[0085] Step 602: Call the report generation command of the command-line interface tool, and pass the source code file path, bytecode file path, coverage execution data, and character encoding parameters as input parameters to the command-line interface tool.

[0086] The final execution command for assembling computer equipment. In conjunction with the aforementioned embodiments, the "source code file path" and "bytecode file path" passed here can specifically be a concatenated list of parameters (i.e., $sourcefiles and $classfiles).

[0087] Specifically, the computer device executes the `report` command of the command-line interface tool, passing in the following four types of key parameters: Execution data: Specifies the locally saved binary data file (e.g., exec / *.exec).

[0088] Structure data: A list of bytecode paths for all submodules passed in via the --classfiles parameter.

[0089] Source code data: A list of source code paths for all submodules is passed in via the --sourcefiles parameter.

[0090] Configuration parameters: Pass the specified character encoding (e.g., utf-8) through the --encoding parameter.

[0091] Step 603: Generate a report file in Hypertext Markup Language (HTML), Extensible Markup Language (XML), or comma-separated value format according to the target output format.

[0092] After receiving all the above parameters, the command-line interface tool begins executing the analysis engine. It reads the probe status from the .exec file, maps it to the class structure specified by classfiles, and attempts to read the source files specified by sourcefiles to render code line coverage details.

[0093] Finally, based on the target output format determined in step 601 (e.g., the command-line parameter --html report), the tool will generate a file in the corresponding format in the specified directory: If you choose the Hypertext Markup Language (HTML) format, a set of web page files will be generated, including an index page and a details page, with support for highlighting code coverage in the browser.

[0094] If you choose the Extensible Markup Language (XML) format, a structured XML file will be generated, which will be easily read and displayed by quality management platforms such as SonarQube or Jenkins.

[0095] If you choose the comma-separated value format (CSV), tabular data will be generated, which is easy to import into Excel for statistical analysis.

[0096] This embodiment details the complete parameterization process for generating reports using command-line tools. In particular, by explicitly specifying character encoding parameters, it solves the common problem of garbled Chinese characters when generating reports across platforms (Windows / Linux); and by supporting multiple output formats, it expands the application scenarios of the solution.

[0097] Reference Figure 7 , Figure 7 This is a schematic diagram of the code coverage report generation system provided by the present invention. The system includes: The first processing module is used to call the command-line interface tool to initiate a data dump request to the target server and receive the coverage execution data returned by the target server; wherein, the target server runs the application under test with the coverage proxy program loaded, and the coverage proxy program is configured to network listening mode. The second processing module is used to obtain the source code file path and bytecode file path of the application under test. The third processing module is used to generate a code coverage report based on the source code file path, bytecode file path, and coverage execution data.

[0098] In one possible implementation, the second processing module is further configured to: Identify at least one submodule under the project directory of the application being tested; For each submodule, determine the corresponding source code storage path and bytecode generation path; Concatenate the source code storage paths of all submodules to obtain the source code parameter list; Concatenate the bytecode generation paths of all submodules to obtain the bytecode parameter list; The source code parameter list is set to the source code file path, and the bytecode parameter list is set to the bytecode file path.

[0099] In one possible implementation, the second processing module is further configured to: Obtain the directory specifications of the project build tools used by the application under test; According to the directory specification, the root directory of the submodule is concatenated with the preset source code directory identifier to obtain the source code storage path; According to the directory specification, the root directory of the submodule is concatenated with the preset compilation output directory identifier to obtain the bytecode generation path.

[0100] In one possible implementation, the system further includes a fourth processing module; the fourth processing module is configured to: Check if a historical report directory exists under the specified output path; If a historical report directory exists, execute the delete command to remove the historical report directory; Create a target directory under the specified output path to store the newly generated code coverage report.

[0101] In one possible implementation, the first processing module is further configured to: Obtain the target server's IP address and the port number that the coverage proxy program is listening on; The command-line interface tool's dump command is invoked, using the IP address and port number as connection parameters to establish a TCP connection with the coverage agent. The system receives coverage execution data in binary format from the coverage agent via a TCP connection and saves it locally.

[0102] In one possible implementation, the third processing module is further configured to: Determine the target output format and character encoding parameters for the code coverage report; The report generation command calls the command-line interface tool and passes the source code file path, bytecode file path, coverage execution data, and character encoding parameters as input parameters to the command-line interface tool. Based on the target output format, generate report files in Hypertext Markup Language (HTML), Extensible Markup Language (XML), or comma-separated value format.

[0103] It should be noted that the code coverage report generation system provided by the present invention can execute the code coverage report generation method of any of the above embodiments during specific operation, which will not be elaborated in this embodiment.

[0104] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 8 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a code coverage report generation method. This method includes: invoking a command-line interface tool to initiate a data dump request to the target server and receiving coverage execution data returned by the target server; wherein the target server runs an application under test with a coverage proxy program loaded, and the coverage proxy program is configured in network listening mode; obtaining the source code file path and bytecode file path corresponding to the application under test; and generating a code coverage report based on the source code file path, bytecode file path, and coverage execution data.

[0105] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the code coverage report generation method provided in the above embodiments.

[0107] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the code coverage report generation method provided in the above embodiments.

[0108] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0110] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A code coverage report generation method characterized by, include: The command-line interface tool is invoked to initiate a data dump request to the target server and receive coverage execution data returned by the target server; wherein, the target server is running the application under test with the coverage proxy program loaded, and the coverage proxy program is configured to network listening mode. Obtain the source code file path and bytecode file path corresponding to the application under test; A code coverage report is generated based on the source code file path, the bytecode file path, and the coverage execution data.

2. The code coverage report generation method according to claim 1, characterized in that, The step of obtaining the source code file path and bytecode file path corresponding to the application under test includes: Identify at least one submodule under the project directory of the application under test; For each of the sub-modules, the corresponding source code storage path and bytecode generation path are determined respectively; By concatenating the source code storage paths of all the sub-modules, a source code parameter list is obtained; By concatenating the bytecode generation paths of all the submodules, a bytecode parameter list is obtained; The source code parameter list is determined as the source code file path, and the bytecode parameter list is determined as the bytecode file path.

3. The code coverage report generation method according to claim 2, characterized in that, Determining the corresponding source code storage path and bytecode generation path includes: Obtain the directory specifications of the project build tool used by the application under test; According to the directory specification, the root directory of the submodule is concatenated with the preset source code directory identifier to obtain the source code storage path; According to the directory specification, the root directory of the submodule is concatenated with a preset compilation output directory identifier to obtain the bytecode generation path.

4. The code coverage report generation method according to claim 1, characterized in that, Also includes: Check if a historical report directory exists under the specified output path; If the historical report directory exists, execute the deletion command to remove the historical report directory; Create a target directory under the specified output path to store the newly generated code coverage report.

5. The code coverage report generation method according to claim 1, characterized in that, The step of invoking the command-line interface tool to initiate a data dump request to the target server includes: Obtain the IP address of the target server and the port number that the coverage proxy program is listening on; The command-line interface tool is invoked to perform a dump command, using the IP address and port number as connection parameters to establish a TCP connection with the coverage proxy program; The system receives coverage execution data in binary format output by the coverage agent via the TCP connection and saves it locally.

6. The code coverage report generation method according to claim 1, characterized in that, The step of generating a code coverage report based on the source code file path, the bytecode file path, and the coverage execution data includes: Determine the target output format and character encoding parameters for the code coverage report; The report generation command of the command-line interface tool is invoked, and the source code file path, the bytecode file path, the coverage execution data, and the character encoding parameters are passed to the command-line interface tool as input parameters. Based on the target output format, generate a report file in Hypertext Markup Language (HTML), Extensible Markup Language (XML), or comma-separated value format.

7. A code coverage report generation system, characterized in that, include: The first processing module is used to call the command-line interface tool to initiate a data dump request to the target server and receive the coverage execution data returned by the target server; wherein, the target server runs the application under test with the coverage proxy program loaded, and the coverage proxy program is configured to network listening mode. The second processing module is used to obtain the source code file path and bytecode file path corresponding to the application under test. The third processing module is used to generate a code coverage report based on the source code file path, the bytecode file path, and the coverage execution data.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the code coverage report generation method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the code coverage report generation method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the code coverage report generation method as described in any one of claims 1 to 6.

Images