Code coverage rate statistical method, device and equipment

Abstract

The invention relates to the technical field of software testing, provides a code coverage rate statistical method, device and equipment, is applied to a test server, and is used for efficiently and reliably carrying out code coverage rate statistics and ensuring software quality. The method comprises the following steps: receiving a trigger instruction for a test service assembly line, and constructing and deploying a tested service code through the test service assembly line; when the tested service code is started, a probe used for recording the code execution condition is loaded; receiving a test request triggered for the tested service code, and obtaining the execution condition of the tested service code in real time through a probe; and receiving an execution instruction for code coverage rate statistics, and executing by testing a coverage rate statistics assembly line, calling a pre-configured construction automation tool and combining a corresponding script configuration file: connecting a probe to obtain an execution condition, and performing code coverage rate data statistics based on the execution condition to generate a corresponding coverage rate statistics file.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and provides a method, apparatus, and device for code coverage statistics. Background Technology

[0002] In software testing, code coverage statistics are an important means of evaluating software quality. Therefore, how to conduct code coverage statistics is crucial in software testing.

[0003] Currently, two common methods for code coverage statistics are intrusive instrumentation and non-intrusive instrumentation; among them:

[0004] Intrusive instrumentation methods require modification of the source code, intermediate code (such as assembly or bytecode), or binary files of the software under test. This not only increases development workload but also introduces code pollution due to its "intrusiveness," potentially introducing new code risks. Therefore, using intrusive instrumentation methods for code coverage statistics suffers from high workload, low efficiency, and poor reliability.

[0005] Non-intrusive instrumentation methods dynamically modify bytecode during class loading or runtime, rather than modifying the source code of the software under test. In this case, to ensure the instrumentation logic takes full effect—covering all class instances—and to avoid compatibility issues between old and new logic and data, it is often necessary to stop and restart the application during the statistical process. However, stopping and restarting the system renders it unavailable, severely impacting the stability and continuity of the production environment, and consequently reducing efficiency.

[0006] Therefore, how to efficiently and reliably perform code coverage statistics to ensure software quality is a technical problem that needs to be solved. Summary of the Invention

[0007] This application provides a code coverage statistics method, apparatus, and device for efficient and reliable code coverage statistics to ensure software quality.

[0008] This application provides a code coverage statistics method applied to a test server, the method comprising:

[0009] Receive trigger commands for the test service pipeline, and build and deploy the code of the service under test through the test service pipeline;

[0010] When the code under test starts, a probe is loaded to record the code execution status;

[0011] Receive test requests triggered by the code under test, and obtain the execution status of the code under test in real time through probes;

[0012] It receives execution instructions for code coverage statistics, calls pre-configured build automation tools through the test coverage statistics pipeline, and executes them in conjunction with the corresponding script configuration files: it obtains execution status through connection probes, performs code coverage data statistics based on the execution status, and generates corresponding coverage statistics files.

[0013] This application provides a code coverage statistics device applied to a test server. The device includes: a build and deployment unit, a loading unit, an acquisition unit, and an execution unit; wherein:

[0014] The build and deployment unit is used to receive trigger instructions for the test service pipeline, and build and deploy the code of the service under test through the test service pipeline;

[0015] The loading unit is used to load probes for recording code execution when the code under test starts.

[0016] The acquisition unit is used to receive test requests triggered by the code under test and to obtain the execution status of the code under test in real time through probes.

[0017] The execution unit receives execution instructions for code coverage statistics, calls pre-configured build automation tools through the test coverage statistics pipeline, and executes them in conjunction with the corresponding script configuration files: it obtains execution status through connection probes, performs code coverage data statistics based on the execution status, and generates corresponding coverage statistics files.

[0018] In one possible implementation, the image file of the service under test (SUT) code built by the test service pipeline contains probe startup parameters. These parameters instruct that when the SUT code starts, a probe for recording code execution should be loaded. The loading unit specifically handles:

[0019] When the code under test starts, a toolkit for recording the code execution status of a probe is loaded from the specified directory of the service under test corresponding to the code under test.

[0020] In one possible implementation, the configuration file specifies the installation path of the code coverage tool on the test server; the execution unit is specifically used for:

[0021] Connect the probe according to the installation path to obtain the execution status.

[0022] In one possible implementation, the test coverage statistics pipeline defines statistical parameters corresponding to coverage statistics; the statistical parameters are used to indicate at least one of incremental statistics and full statistics.

[0023] In one possible implementation, if the statistical parameters indicate incremental statistics, the test coverage statistics pipeline also defines the corresponding pattern parameters for incremental statistics. These pattern parameters include: incremental branch, incremental tag, commit ID, comparison benchmark, and comparison object. The execution unit is specifically used for:

[0024] The benchmark is compared with the object of comparison based on at least one of incremental branches, incremental tags, and commit identifiers, and incremental statistics are performed on the code coverage data based on the comparison results.

[0025] In one possible implementation, if the statistical parameter indicates full statistics, the execution unit is specifically used for:

[0026] Perform full statistics on the code coverage data of the entire tested service code.

[0027] In one possible implementation, the test coverage statistics pipeline defines generation parameters related to the coverage statistics file; the generation parameters include at least one of the following: an append parameter indicating whether to append code coverage data to the historical coverage data file, and a reset parameter indicating whether to delete coverage data from the historical coverage data file.

[0028] In one possible implementation, the generated parameters include appended parameters; the execution unit is specifically used for:

[0029] If the append parameter indicates that code coverage data is appended to the historical coverage data file, then the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the appended historical coverage data file.

[0030] If the append parameter indicates that code coverage data should not be appended to the historical coverage data file, a new coverage data file will be created and the code coverage data will be written. Based on the new coverage data file, the corresponding coverage statistics file will be generated.

[0031] In one possible implementation, the generated parameters are reset parameters; the execution unit is specifically used for:

[0032] If the reset parameter indicates that the coverage data in the historical coverage data file is deleted, then the coverage data in the historical coverage data file will be automatically deleted in conjunction with the data cleanup task configured in the script configuration file, and code coverage data will be written. Based on the historical coverage data file after the reset and writing, the corresponding coverage statistics file will be generated.

[0033] If the reset parameter indicates that coverage data in the historical coverage data file should not be deleted, then determine whether the historical coverage data file exists, and generate the corresponding coverage statistics file based on the determination result and the code coverage data.

[0034] In one possible implementation, the execution unit is specifically used for:

[0035] If the results indicate the existence of a historical coverage data file, the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the written historical coverage data file.

[0036] If the result indicates that no historical coverage data file exists, a new coverage data file is created and code coverage data is written to it. Based on the new coverage data file, the corresponding coverage statistics file is generated.

[0037] In one possible implementation, the execution unit is specifically used to: integrate coverage statistics files into the test server via the test coverage statistics pipeline;

[0038] In one possible implementation, the test server uses a pre-installed code coverage tool plugin to present coverage statistics files via a web interface and saves the coverage statistics files as build artifacts.

[0039] An electronic device provided in this application includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of any of the above-described code coverage statistics methods.

[0040] In one possible implementation, when a computer program is executed by a processor, the processor performs the following process:

[0041] Receive trigger commands for the test coverage statistics pipeline and execute them through the test coverage statistics pipeline:

[0042] Build and deploy the code of the service under test;

[0043] When the code under test starts, a probe is loaded to record the code execution status;

[0044] Receive test requests triggered by the code under test, and obtain the execution status of the code under test in real time through probes;

[0045] It receives execution instructions for code coverage statistics, calls pre-configured build automation tools, and executes them in conjunction with the corresponding script configuration files: it uses a connection probe to obtain execution status, performs code coverage data statistics based on the execution status, and generates the corresponding coverage statistics file.

[0046] This application provides a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, the computer program is used to cause the electronic device to perform the steps of any of the above-described code coverage statistics methods.

[0047] This application provides a computer program product, which includes a computer program stored in a computer-readable storage medium. When the processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any of the above-described code coverage statistics methods.

[0048] The beneficial effects of this application are as follows:

[0049] This application provides a code coverage statistics method, apparatus, and device, relating to the field of software testing technology and applied to test servers. The implementation of code coverage statistics provided in this application includes:

[0050] By combining the test service pipeline and the test coverage statistics pipeline, code coverage statistics are achieved. The test service pipeline is integrated with probes and build automation tools to realize a fully automated process from deployment of the service under test to generation of coverage statistics files. It supports parameterized configuration, reduces manual intervention, and improves testing efficiency.

[0051] Specifically, it receives trigger commands for the test service pipeline, builds and deploys the code of the service under test through the test service pipeline, loads probes to record code execution when the code of the service under test starts, and dynamically loads probes to record code execution when the code of the service under test runs. This achieves non-intrusive instrumentation, that is, without modifying the code of the service under test, reducing development workload, improving efficiency, reducing maintenance costs, and avoiding code pollution and the introduction of new code risks caused by instrumentation, thereby improving the reliability of statistics.

[0052] It receives test requests triggered by the code under test and uses probes to obtain the execution status of the code under test in real time. This allows for subsequent code coverage statistics based on the execution status, generating corresponding coverage statistics files. Real-time data collection using probes ensures the accuracy and timeliness of coverage data.

[0053] The system receives execution commands for code coverage statistics, utilizes a test coverage statistics pipeline, and invokes pre-configured build automation tools. These tools, combined with corresponding script configuration files, execute the commands: a connection probe acquires execution data, and based on this data, code coverage data is statistically analyzed, generating corresponding coverage statistics files. This ensures the accuracy of the code coverage data statistics, thereby guaranteeing the accuracy of the generated coverage statistics files. In summary, without modifying the code of the service under test, this system achieves real-time collection of runtime coverage data while ensuring continuous service operation. This improves the feasibility and efficiency of code coverage statistics in production environments, providing more reliable support for software quality assurance.

[0054] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0055] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0056] Figure 1 A schematic diagram of the preparation of a pre-conditioning environment provided for an embodiment of this application;

[0057] Figure 2 A structural diagram of a test server provided in an embodiment of this application;

[0058] Figure 3 A flowchart of a code coverage statistics method provided in this application embodiment;

[0059] Figure 4 This is a schematic diagram illustrating the generation of a coverage statistics file, as provided in an embodiment of this application.

[0060] Figure 5 This is a schematic diagram of a non-disruptive service mechanism provided in an embodiment of this application;

[0061] Figure 6 A flowchart of an overall method for code coverage statistics provided in this application embodiment;

[0062] Figure 7 A structural diagram of a code coverage statistics device provided in this application embodiment;

[0063] Figure 8 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0065] The following describes some of the concepts involved in the embodiments of this application.

[0066] Instrumentation is an important technique in software engineering, program analysis, and testing. Its core idea is to insert specific code snippets (called "stubs" or "probes") into the program code to monitor, analyze, debug, or trace the program's execution process. These inserted code snippets do not affect the program's core functionality and are primarily used to collect various information during program execution (such as variable values, function call order, and execution path).

[0067] The test server is Jenkins, an open-source automation server primarily used to automate software building, testing, and deployment processes. It is one of the core tools in the fields of continuous integration (CI) and continuous deployment (CD). It supports various plugin extensions and can integrate with various development tools, version control systems, cloud services, etc., helping teams efficiently manage the software development lifecycle.

[0068] A code coverage tool could be Java Code Coverage (Jacoco). Jacoco is an open-source code coverage analysis tool used to measure code execution during testing. Jacoco supports various coverage metrics (such as line coverage, branch coverage, and method coverage) to help developers understand the extent to which test cases cover the code, assess the adequacy of tests, and identify uncovered code segments. Specifically, it analyzes bytecode using bytecode instrumentation (inserting monitoring code into compiled class files) to record the code execution trajectory, thereby determining which code was executed and which was not, generating a coverage statistics file (.exec), which is then parsed into a visual report. In one possible implementation, Jacoco is suitable for: code coverage analysis in unit tests and integration tests, as well as automatically generating code coverage statistics files in continuous integration (CI).

[0069] JavaAgent is a special mechanism provided by Java that allows developers to intercept and modify class bytecode when a class is loaded, or to dynamically intervene in class behavior at runtime, without modifying the target application's source code.

[0070] The word “exemplary” as used below means “serving as an example, embodiment, or illustration.” Any embodiment illustrated as an “exemplary” need not be construed as superior to or better than other embodiments.

[0071] The terms "first" and "second" used in this document are for descriptive purposes only and should not be construed as indicating, explicitly or implicitly, relative importance or specifying the number of technical features indicated. Therefore, a feature marked "first" or "second" may explicitly or implicitly include one or more features.

[0072] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more. For example, if there are multiple sample questions in the embodiments of this application, it means that there are two or more sample questions in the input question-answering model of this application.

[0073] The design concept of the embodiments of this application is briefly introduced below:

[0074] In related technologies, code coverage statistics typically employ intrusive instrumentation methods, requiring modification of the code under test. This not only increases development workload but may also introduce new code risks. Therefore, using intrusive instrumentation methods for code coverage statistics suffers from high workload, low efficiency, and poor reliability. Furthermore, non-intrusive instrumentation methods often require service interruption during the statistics process, leading to system unavailability that severely impacts the stability and continuity of the production environment, thereby reducing efficiency.

[0075] Therefore, how to efficiently and reliably perform code coverage statistics to ensure software quality is a technical problem that needs to be solved.

[0076] In view of this, in order to solve the problems of low efficiency and poor reliability caused by the need to modify code for instrumentation and the difficulty in real-time continuous high coverage monitoring, this application provides a non-intrusive, uninterrupted code coverage statistics solution based on a four-fold innovative architecture of "JavaAgent non-intrusive probe + Ant hot control engine + dynamic file management + CI / CD automation". This solution achieves real-time collection of runtime coverage data without modifying the code of the service under test, while ensuring continuous service operation, thereby improving the feasibility and efficiency of code coverage statistics in the production environment and providing more reliable support for software quality assurance.

[0077] Without interrupting business operations, the following can be achieved: runtime switching of coverage statistics strategies, i.e., free selection of full / incremental coverage; zero-downtime operation for resetting monitoring data; continuous integration of production environment monitoring, i.e. end-to-end automation of the Jenkins pipeline; and continuous operation of coverage statistics in the production environment.

[0078] Meanwhile, the code coverage statistics scheme provided in this application has strong scalability and low coupling. In core probe management, it can be seamlessly compatible with traditional coverage formats such as JaCoCo, and can also support the expansion of custom monitoring indicators, ensuring the continuous evolution of coverage monitoring capabilities in the production environment.

[0079] The embodiments of this application are applicable to at least the following scenarios:

[0080] Scenario 1: The code volume is large and there are many functional scenarios. Simply covering test cases cannot fully guarantee the quality of the version. Coverage statistics can be performed by executing the code.

[0081] Scenario 2: Production environment monitoring scenarios for all Java applications, including security platforms, microservice architectures, high-availability online services, and other areas with stringent stability requirements;

[0082] Scenario 3 is suitable for testing scenarios involving repeated version regressions and high operational complexity.

[0083] The code coverage statistics method provided by the exemplary embodiments of this application is described below with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way.

[0084] In this embodiment of the application, in order to accurately perform code coverage statistics, it is necessary to prepare the environment for code coverage statistics. See [link to relevant documentation]. Figure 1 , Figure 1 A schematic diagram of a pre-construction environment provided for an embodiment of this application includes:

[0085] Step 1: Install and configure the code coverage tool (Jacoco) plugin and the build automation tool (Ant) on the test server (Jenkins server). Confirm the installation path to ensure that Jacoco and Ant are accurately invoked during the code coverage statistics process.

[0086] For example, the Jacoco plugin and Ant tool are installed and configured on the Jenkins server, with the installation paths set to / usr / local / ant and / usr / local / jacoco.

[0087] Since the Jenkins server itself does not generate code coverage data, it can receive code coverage statistics files generated by external tools (such as JaCoCo). This process requires calling JaCoCo through Ant's script configuration file to achieve automatic code coverage collection and file generation.

[0088] Step 2: Create the script configuration file (Ant build.xml) corresponding to the Ant tool. The specific script configuration file can be configured according to the service type or a unified template can be used to achieve the statistical needs of different services by replacing parameters.

[0089] For example, Ant build.xml can be created manually, automatically generated by an Integrated Development Environment (IDE), created using Ant's built-in tools, or created using a template generation tool / website. Among these:

[0090] Creating it manually means writing it directly using a text editor while following Ant's XML syntax specifications;

[0091] The IDE can automatically generate Ant build files when creating a Java project; or it can automatically generate build.xml and related configuration files by default when creating a Java project.

[0092] Creating a project using Ant's built-in tools and executing `ant-projecthelp` will display the goals and descriptions in the current `build.xml` file (if they already exist). This is combined with Ant's... <echo>The task can generate basic template code, which can then be manually improved.

[0093] Create a general template like "Ant build.xmltemplate" using template generation tools / websites. Some online tools or code template libraries provide this template. You can then customize the build steps and generate the configuration file using the code generation tool.

[0094] In one possible implementation, the script configuration file includes: root element and attribute definitions, task definitions, and target definitions; for example:

[0095] root element <project>This defines the root element of the Ant project, including: name: the project name. In this application, name="coverage" means coverage statistics are performed; default: the default target to execute (this target is executed if not specified). In this application, default="report" specifies that the default task to execute is report; basedir: the base directory. basedir="." indicates that the base directory is the current directory.

[0096] Property Definition <property>This defines several attribute values ​​used to define variables, including the location of the JaCoCo Ant task library (jacoco.ant.path), whether to reset coverage information after collection (reset), whether to append new data to an existing executable file (append), the path to the execution statistics file (coverage.exec), and the file generation directory (report.dir), etc.

[0097] Task definition <taskdef>This defines a new task or type, used here to load the Ant task provided by JaCoCo. It finds the JaCoCo Ant task implementation class through the specified classpath(${jacoco.ant.path}).

[0098] Target definition<target name="collect"> This defines a target named `collect`, which retrieves code coverage data from a target JVM (port 6300) running on localhost and saves it to the file specified by `${coverage.exec}`. If the `reset` property is set to `true`, the coverage information in the target JVM will be reset after collection is complete.

[0099] Target definition<target name="report"depends="collect"> Another goal named `report` is defined, which depends on the `collect` goal being executed first. This goal uses... <jacoco:report>The `<script>` tag is used to generate code coverage statistics files. It specifies: the path to previously collected execution statistics files, the path to the .class files of the analyzed application, and the path to the source code files, used to correlate coverage data and source code; ultimately, it...<htmldestdir="${report.dir}" / > Generate an HTML report and store it in the directory specified by ${report.dir}.

[0100] Step 3: Add the JavaAgent:Jacoco startup parameter to the Dockerfile of the deployment pipeline (also known as the test service pipeline) of the service under test. This parameter loads a probe (JaCoCo probe) to record code execution when the service under test starts, enabling dynamic collection of code coverage. The format is:

[0101] -javaagent: / app / jacocoagent.jar=output=tcpserver, address=0.0.0.0, port=6300, destfile= / app / coverage.exec.

[0102] Step 4: Add the Jacoco agent runtime.jar file to the specified directory of the service under test to ensure that it can be loaded when the service starts. For example, copy the Jacoco agent.jar file to the / app directory of the service container.

[0103] Step 5: Configure the deployment pipeline, add operations for packaging and collecting build artifacts, and save coverage-related artifacts to the Jenkins server.

[0104] For example, define a Jenkins declarative pipeline that can run on any available Jenkins Agent (execution node). All stages of the entire pipeline include:

[0105] Phase 1 - Build: Run Maven commands in the shell environment to clean up old build artifacts and package the project (e.g., generate .jar or .war files) to generate the code for the service under test.

[0106] Phase 2 - Deployment: Package the built service code under test into a Docker image and run the container.

[0107] Phase 3 - Coverage Statistics: The coverage statistics phase consists of three steps, including:

[0108] Step a: Input step.

[0109] Before performing the coverage phase, pause the pipeline and wait for user confirmation. The user can choose to "Execute" to continue or stop the pipeline, so this step is used to determine whether to perform coverage statistics.

[0110] Step b: sh command.

[0111] Invoke the Ant build automation tool to execute the report target in the script configuration file located at / path / to / build.xml.

[0112] Pass the Pipeline parameter RESET to the Ant build automation tool to control whether coverage data is reset.

[0113] Pass the Pipeline parameter APPEND to the Ant build automation tool to control whether data is appended.

[0114] This typically triggers JaCoCo to pull .exec coverage data from a running Java application (via the Java Agent) and generate a coverage statistics file.

[0115] Step c: archiveArtifacts.

[0116] `archiveArtifacts` is a core step in the Jenkins pipeline, used to save important files generated during the build process (i.e., "build artifacts") to the Jenkins server, making them viewable and downloadable through the Jenkins web interface. It archives the generated coverage statistics files for easy viewing or downloading later. With fingerprinting enabled, Jenkins tracks the change history of these files.

[0117] Step d: Parameter definition.

[0118] RESET: Whether to reset historical data when collecting coverage (default is false);

[0119] APPEND: Whether to append new data to existing data (default is true);

[0120] covType: A single-option parameter that specifies the coverage calculation method (full coverage / incremental coverage);

[0121] incMode: A single-option parameter that specifies the incremental statistics mode (branch, tag, commitID);

[0122] baseLine: String input, incremental comparison baseline (branch, tag, commitID, defaults to HEAD~1);

[0123] current: String input, the information currently being compared (branch, tag, commitID, defaults to HEAD);

[0124] The test server used for code coverage statistics, as seen in steps 1-5, mainly includes: a Java Agent integration module, an Ant script control module, and a pipeline integration module; for example, see [link to example]. Figure 2 , Figure 2 A structural diagram of a test server provided in an embodiment of this application, wherein:

[0125] Java Agent Integration Module: Utilizing JavaAgent technology, Jacoco startup parameters are added when the service starts, enabling non-intrusive instrumentation of the service under test and collecting coverage data without modifying the service source code.

[0126] Ant script control module: Configure coverage statistics parameters through the Ant build.xml file, including reset (clear historical data) and append (incremental statistics), to achieve flexible control over the statistical process.

[0127] Pipeline Integration Module: Deeply integrated with Jenkins pipelines, enabling full automation from service deployment and coverage data collection to report generation.

[0128] After completing steps 1-5 above, the preparation of the pre-construction environment is complete. Next, code coverage statistics can be performed based on this pre-construction environment.

[0129] See Figure 3 , Figure 3 A flowchart of a code coverage statistics method provided in this application embodiment, applied to a test server, includes the following steps:

[0130] Step S3001: Receive the trigger command for the test service pipeline, and build and deploy the code of the service under test through the test service pipeline.

[0131] Step S3002: When the service code under test starts, load the probe used to record the code execution status.

[0132] The image file of the service under test (SUT) code built by the test service pipeline contains probe startup parameters. These parameters instruct that probes used to record code execution status be loaded when the SUT code starts. These probes include:

[0133] When the code under test starts, a toolkit for recording the code execution status of a probe is loaded from the specified directory of the service under test corresponding to the code under test.

[0134] In this application, probes are dynamically inserted during the loading phase without modifying the code of the service under test, which reduces development workload, improves efficiency, reduces maintenance costs, avoids code pollution and the risk of introducing new code due to instrumentation, and improves statistical reliability.

[0135] Step S3003: Receive a test request triggered by the code under test, and obtain the execution status of the code under test in real time through a probe.

[0136] For example, the probe captures the code execution path in real time.

[0137] In one possible implementation, test requests include, but are not limited to: manual testing, automated testing, and API automation;

[0138] Manual testing involves personnel accessing interfaces or pages, triggering code execution; automated testing involves using scripts to execute regression tests; and automated testing involves calling test scripts within the Jenkins Pipeline.

[0139] Step S3004: Receive the execution instruction for code coverage statistics, call the pre-configured build automation tool through the test coverage statistics pipeline, and execute it in conjunction with the corresponding script configuration file: connect probe to obtain execution status, and perform code coverage data statistics based on the execution status to generate the corresponding coverage statistics file.

[0140] In one possible implementation, a pre-configured build automation tool is invoked based on the installation path of the build automation tool.

[0141] In one possible implementation, the script configuration file sets the installation path of the code coverage tool on the test server; the connection probe is used to obtain execution status according to the installation path.

[0142] In one possible implementation, the execution instructions for code coverage statistics can be manually triggered or implemented by defining parameters in the test coverage statistics pipeline.

[0143] In this embodiment of the application, the test coverage statistics pipeline defines statistical parameters corresponding to coverage statistics; the statistical parameters are used to indicate at least one of incremental statistics and full statistics; and the test coverage statistics pipeline defines generation parameters related to coverage statistics files; the generation parameters include at least one of appending parameters for indicating whether to append code coverage data to the historical coverage data file and resetting parameters for indicating whether to delete coverage data in the historical coverage data file.

[0144] The process involves calling a pre-configured build automation tool, executing it in conjunction with the corresponding script configuration file, connecting probes to obtain execution status, and performing code coverage data statistics based on the execution status to generate the corresponding coverage statistics file: First, code coverage data is statistically analyzed based on the execution status according to the statistical parameters, which are transmitted to the build automation tool from the test coverage statistics pipeline. At this point, the build automation tool can determine whether to perform full or incremental statistics on the code coverage data based on the statistical parameters. Then, based on the parameters for generating the coverage statistics file, the corresponding coverage statistics file is generated. These parameters are also transmitted to the build automation tool from the test coverage statistics pipeline. At this point, the build automation tool can determine whether to append code coverage data to the historical coverage data file or delete coverage data from the historical coverage data file, and then write the code coverage data to generate the corresponding coverage statistics file.

[0145] In one possible implementation, when performing code coverage data statistics based on execution status, if the statistical parameters indicate incremental statistics, the test coverage statistics pipeline also defines the corresponding mode parameters for incremental statistics. The mode parameters include: incremental branch, incremental tag, commit ID, comparison benchmark, and comparison object. Then, according to at least one of the incremental branch, incremental tag, and commit ID, the comparison benchmark and the comparison object are compared, and incremental statistics are performed on the code coverage data based on the comparison results.

[0146] For example, code coverage data statistics based on incremental branches: how many lines of code were added / modified in the feature / login branches compared to the main branch;

[0147] Code coverage data statistics based on incremental tags: How many features were added and how many bugs were fixed in v2.0 compared to v1.0;

[0148] Code coverage data is compiled based on the commit identifier: which files were modified in this commit, and how many lines of code were added or deleted (+ / - lines).

[0149] In one possible implementation, when performing code coverage data statistics based on execution status, if the statistical parameters indicate full statistics, then full statistics are performed on the code coverage data of the entire tested service code.

[0150] In this application, code coverage statistics are performed based on execution status according to statistical parameters, and corresponding coverage statistics files are generated. The statistical parameters can be dynamically switched between full and incremental statistics, which can not only comprehensively evaluate code coverage, but also efficiently perform statistics on changed code.

[0151] In one possible implementation, the generation parameters include appended parameters when generating the corresponding coverage statistics file:

[0152] If the append parameter indicates that code coverage data is appended to the historical coverage data file, then the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the appended historical coverage data file.

[0153] If the append parameter indicates that code coverage data should not be appended to the historical coverage data file, a new coverage data file will be created and the code coverage data will be written. Based on the new coverage data file, the corresponding coverage statistics file will be generated.

[0154] For example, when the append parameter is configured to true or 1, code coverage data will be appended to the historical coverage data file; when the append parameter is configured to false or 0, code coverage data will not be appended to the historical coverage data file, but a new coverage data file will be created, and the corresponding coverage statistics file will be generated based on the new coverage data file.

[0155] It should be noted that if the append parameter indicates that code coverage data should not be appended to the historical coverage data file, the code coverage data may be discarded.

[0156] In one possible implementation, the generation parameters are reset parameters; when generating the corresponding coverage statistics file:

[0157] If the reset parameter indicates that the coverage data in the historical coverage data file is deleted, then the coverage data in the historical coverage data file will be automatically deleted in conjunction with the data cleanup task configured in the script configuration file, and code coverage data will be written. Based on the historical coverage data file after the reset and writing, the corresponding coverage statistics file will be generated.

[0158] If the reset parameters indicate that coverage data in the historical coverage data file should not be deleted, then it is determined whether a historical coverage data file exists. Based on the determination result and the code coverage data, a corresponding coverage statistics file is generated. When generating the corresponding coverage statistics file based on the determination result and the code coverage data, if the determination result indicates that a historical coverage data file exists, then the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the written historical coverage data file. If the determination result indicates that a historical coverage data file does not exist, then a new coverage data file is created and code coverage data is written to it. The corresponding coverage statistics file is generated based on the new coverage data file.

[0159] For example, when the reset parameter is configured to true or 1, it is determined that the coverage data in the historical coverage data file will be deleted; when the reset parameter is configured to false or 0, it is determined that the coverage data in the historical coverage data file will not be deleted.

[0160] See Figure 4 , Figure 4 A schematic diagram illustrating the generation of a coverage statistics file provided in this application embodiment includes the following steps:

[0161] Step S400: Receive execution instructions for code coverage statistics;

[0162] Step S401: Determine whether it is a full-scale statistics based on the statistical parameters corresponding to the obtained coverage statistics. If yes, proceed to step S402; otherwise, proceed to step S403.

[0163] Step S402: Using a full statistical method, perform a full statistical analysis on the code coverage data of the entire tested service code to obtain the corresponding code coverage data;

[0164] Step S403: Using an incremental statistical method, the benchmark is compared with the object of comparison according to at least one of incremental branch, incremental tag, and commit identifier, and incremental statistics are performed on the code coverage data based on the comparison results to obtain the corresponding code coverage data.

[0165] Step S404: Based on the generation parameters related to the obtained coverage statistics file, determine whether to generate the corresponding coverage statistics file in append mode. If yes, proceed to step S405; otherwise, proceed to step S408.

[0166] Step S405: Based on the append parameters corresponding to the append mode, determine whether to append code coverage data to the historical coverage data file. If yes, proceed to step S406; otherwise, proceed to step S407.

[0167] Step S406: Write the code coverage data to the historical coverage data file, and use the historical coverage data file with the code coverage data appended to it as the new coverage data file;

[0168] Step S407: Create a new coverage data file and write code coverage data to generate a new coverage statistics file;

[0169] Step S408: Based on the reset parameters corresponding to the reset mode, determine whether to delete the coverage data in the historical coverage data file. If yes, proceed to step S409; otherwise, proceed to step S410.

[0170] Step S409: Combined with the data cleanup task configured in the script configuration file, automatically delete the coverage data in the historical coverage data file, and write the code coverage data, and use the historical coverage data file with the reset code coverage data as the new coverage data file.

[0171] Step S410: Determine if a historical coverage data file exists. If it does, proceed to step S411; otherwise, proceed to step S412.

[0172] Step S411: Write the code coverage data to the historical coverage data file, and use the historical coverage data file containing the code coverage data as the new coverage data file;

[0173] Step S412: Create a new coverage data file and write code coverage data to generate a new coverage data file;

[0174] Step S413: Generate the corresponding coverage statistics file based on the new coverage data file.

[0175] It should be noted that the technical solution provided in this application embodiment is implemented through two pipelines. When two pipelines are set up, one pipeline is used for the deployment of the code service under test, and the other pipeline is used for the statistics of test code coverage.

[0176] In this embodiment of the application, after the corresponding coverage statistics file is generated, the test service pipeline is executed to integrate the coverage statistics file into the test server; the test server, based on the pre-installed code coverage tool plugin, presents the coverage statistics file through a web interface and saves the coverage statistics file as a build artifact, thereby realizing artifact management.

[0177] In this embodiment of the application, to improve the efficiency of code coverage statistics, a non-disruptive code coverage statistics solution is also provided. Specifically, by manually or automatically deleting the coverage statistics file (.exec file) using a script, the statistics status can be reset without restarting the service, ensuring continuous service operation.

[0178] See Figure 5 , Figure 5 This application provides a schematic diagram of a non-disruptive service mechanism, the specific process of which is as follows:

[0179] Step S500: Receive the historical coverage statistics file cleanup instruction.

[0180] This cleanup command is triggered after the test is completed and can be controlled via parameters or manually.

[0181] Step S501: Call the script configuration file of the automated tool and execute the data cleanup task based on the configuration file: delete historical coverage statistics files.

[0182] In step S502, when the statistics process is restarted, a new coverage statistics file will be collected based on the current service status.

[0183] In this application, the statistical status is reset by deleting the coverage statistics file instead of restarting the service, ensuring the continuous operation of the service during the statistical process and enabling the management of historical outputs. It supports coverage statistics while the service is running, without affecting the system's normal external service provision, making it particularly suitable for production environments.

[0184] See Figure 6 , Figure 6 A flowchart for code coverage statistics provided in this application includes the following steps:

[0185] Step S600: Prepare the prerequisite environment.

[0186] For details on how to accurately implement the pre-processing environment, please refer to [link / reference]. Figure 1 This will not be repeated here.

[0187] Step S601, Perform deployment and statistics:

[0188] Step S6010: Build and deploy the code of the service under test through the test service pipeline;

[0189] Step S6011: When the code under test starts, load a probe to record the code execution status; Step S6012: Receive a test request triggered by the code under test, execute the test, and obtain the execution status of the code under test in real time through the probe.

[0190] Step S6013: Receive the execution instruction for code coverage statistics, and call the pre-configured build automation tool through the test coverage statistics pipeline to start the script configuration file;

[0191] Step S6014: Determine whether to use the full statistical method to obtain code coverage data or the incremental statistical method to obtain code coverage data based on the statistical parameters corresponding to the obtained coverage statistics.

[0192] Step S6015: Based on the generation parameters related to the obtained coverage statistics file, determine whether to generate the corresponding coverage statistics file in append mode. If yes, proceed to step S6016; otherwise, proceed to step S6017.

[0193] Step S6016: Generate a new coverage statistics file based on the append parameters corresponding to the append mode;

[0194] Step S6017: Generate a new coverage statistics file based on the reset parameters corresponding to the reset mode;

[0195] Step S6018: Integrate the coverage statistics file into the test server and save the build artifacts.

[0196] It should be noted that the specific implementation methods of steps S6014-S6017 can be found in [reference needed]. Figure 4 This will not be elaborated upon here.

[0197] Step S602: Implement the non-stop service mechanism.

[0198] For details on the implementation of the non-stop service mechanism, please refer to [link / reference]. Figure 5 This will not be repeated here.

[0199] In this application, code coverage statistics are achieved by working together with a test service pipeline and a test coverage statistics pipeline. The test service pipeline is integrated with probes and build automation tools to realize a fully automated process from deployment of the service under test to generation of coverage statistics files. It supports parameterized configuration, reduces manual intervention, and improves testing efficiency.

[0200] Specifically, it receives trigger commands for the test service pipeline, builds and deploys the code of the service under test through the test service pipeline, loads probes to record code execution when the code of the service under test starts, and dynamically loads probes to record code execution when the code of the service under test runs. This achieves non-intrusive instrumentation, that is, without modifying the code of the service under test, reducing development workload, improving efficiency, reducing maintenance costs, and avoiding code pollution and the introduction of new code risks caused by instrumentation, thereby improving the reliability of statistics.

[0201] It receives test requests triggered by the code under test and uses probes to obtain the execution status of the code under test in real time. This allows for subsequent code coverage statistics based on the execution status, generating corresponding coverage statistics files. Real-time data collection using probes ensures the accuracy and timeliness of coverage data.

[0202] It receives execution instructions for code coverage statistics, calls pre-configured build automation tools through the test coverage statistics pipeline, and executes them in conjunction with the corresponding script configuration files: it obtains execution status through connection probes, performs code coverage data statistics based on the execution status, and generates corresponding coverage statistics files.

[0203] In summary, without modifying the code of the service under test, we can achieve real-time collection of runtime coverage data while ensuring continuous service operation. This improves the feasibility and efficiency of code coverage statistics in the production environment and provides more reliable support for software quality assurance.

[0204] Based on the same inventive concept, this application also provides a code coverage statistics device, applied to a test server, see [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram of the code coverage statistics device 700, which includes: a build and deployment unit 7011, a loading unit 7012, an acquisition unit 7013, and an execution unit 7014; wherein:

[0205] The build and deployment unit 7011 is used to receive trigger instructions for the test service pipeline, and build and deploy the code of the service under test through the test service pipeline;

[0206] The loading unit 7012 is used to load a probe for recording code execution when the code under test starts.

[0207] The acquisition unit 7013 is used to receive test requests triggered by the code under test and to acquire the execution status of the code under test in real time through probes.

[0208] The execution unit 7014 is used to receive execution instructions for code coverage statistics, call the pre-configured build automation tools through the test coverage statistics pipeline, and execute them in conjunction with the corresponding script configuration files: connect probes to obtain execution status, and perform code coverage statistics based on the execution status according to the preset statistical mode, and generate corresponding coverage statistics reports.

[0209] In one possible implementation, the image file of the service under test (SUT) code built by the test service pipeline contains probe startup parameters. These parameters instruct that when the SUT code starts, a probe for recording code execution should be loaded. The loading unit 7012 is specifically used for:

[0210] When the code under test starts, a toolkit for recording the code execution status of a probe is loaded from the specified directory of the service under test corresponding to the code under test.

[0211] In one possible implementation, the configuration file specifies the installation path of the code coverage tool on the test server; execution unit 7014 is specifically used for:

[0212] Connect the probe according to the installation path to obtain the execution status.

[0213] In one possible implementation, the test service pipeline defines statistical parameters corresponding to coverage statistics; the statistical parameters are used to indicate at least one of incremental statistics and full statistics.

[0214] In one possible implementation, if the statistical parameters indicate incremental statistics, the test coverage statistics pipeline also defines the corresponding pattern parameters for incremental statistics. These pattern parameters include: incremental branch, incremental tag, commit ID, comparison benchmark, and comparison object. Execution unit 7014 is specifically used for:

[0215] The benchmark is compared with the object of comparison based on at least one of incremental branches, incremental tags, and commit identifiers, and incremental statistics are performed on the code coverage data based on the comparison results.

[0216] In one possible implementation, if the statistical parameter indicates full statistics, the execution unit 7014 is specifically used for:

[0217] Perform full statistics on the code coverage data of the entire tested service code.

[0218] In one possible implementation, the test coverage statistics pipeline defines generation parameters related to the coverage statistics file; the generation parameters include at least one of the following: an append parameter indicating whether to append code coverage data to the historical coverage data file, and a reset parameter indicating whether to delete coverage data from the historical coverage data file. In one possible implementation, the generation parameters include an append parameter; execution unit 7014 is specifically used for:

[0219] If the append parameter indicates that code coverage data is appended to the historical coverage data file, then the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the appended historical coverage data file.

[0220] If the append parameter indicates that code coverage data should not be appended to the historical coverage data file, a new coverage data file will be created and the code coverage data will be written. Based on the new coverage data file, the corresponding coverage statistics file will be generated.

[0221] In one possible implementation, the generated parameter is a reset parameter; the execution unit 7014 is specifically used for:

[0222] If the reset parameter indicates that the coverage data in the historical coverage data file is deleted, then the coverage data in the historical coverage data file will be automatically deleted in conjunction with the data cleanup task configured in the script configuration file, and code coverage data will be written. Based on the historical coverage data file after the reset and writing, the corresponding coverage statistics file will be generated.

[0223] If the reset parameter indicates that coverage data in the historical coverage data file should not be deleted, then determine whether the historical coverage data file exists, and generate the corresponding coverage statistics file based on the determination result and the code coverage data.

[0224] In one possible implementation, execution unit 7014 is specifically used for:

[0225] If the results indicate the existence of a historical coverage data file, the code coverage data is written to the historical coverage data file, and the corresponding coverage statistics file is generated based on the written historical coverage data file.

[0226] If the result indicates that no historical coverage data file exists, a new coverage data file is created and code coverage data is written to it. Based on the new coverage data file, the corresponding coverage statistics file is generated.

[0227] In one possible implementation, execution unit 7014 is specifically used to: integrate coverage statistics files into the test server via the test service pipeline.

[0228] In one possible implementation, the test server uses a pre-installed code coverage tool plugin to present coverage statistics files via a web interface and saves the coverage statistics files as build artifacts.

[0229] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0230] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0231] Having introduced the code coverage statistics method and apparatus according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0232] Those skilled in the art will understand that various aspects of this application can be implemented as systems, methods, or computer program products. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0233] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device. In one embodiment, the electronic device may be a server, and in this embodiment, the structure of the electronic device may be as follows: Figure 8 As shown, it includes a memory 801, a communication module 803, and one or more processors 802.

[0234] The memory 801 is used to store computer programs executed by the processor 802. The memory 801 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0235] Memory 801 may be volatile memory, such as random-access memory (RAM); memory 801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 801 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 801 may be a combination of the above-described memories.

[0236] Processor 802 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 802 is used to implement the above-mentioned code coverage statistics method when calling computer programs stored in memory 801.

[0237] The communication module 803 is used to communicate with terminal devices and other servers.

[0238] This application embodiment does not limit the specific connection medium between the memory 801, communication module 803, and processor 802 described above. This application embodiment... Figure 8 The memory 801 and the processor 802 are connected via a bus 804, and the bus 804 is in Figure 8 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 804 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 8 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0239] In some possible implementations, memory 801 stores a computer storage medium containing a computer program that implements the steps of the code coverage statistics method of this application embodiment. Processor 802 is used to execute the above-described code coverage statistics method.

[0240] In some possible implementations, various aspects of the code coverage statistics method provided in this application can also be implemented in the form of a computer program product, which includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps in the code coverage statistics method according to the various exemplary embodiments of this application described above.

[0241] Computer program products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0242] The computer program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. However, the computer program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0243] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0244] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0245] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's electronic device, partially on the user's electronic device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0246] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0247] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0248] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.< / jacoco:report> < / taskdef> < / property> < / project> < / echo>

Claims

1. A code coverage statistics method, characterized in that, Applied to a test server, the method includes: Receive trigger commands for the test service pipeline, and build and deploy the code of the service under test through the test service pipeline; When the tested service code starts, a probe for recording code execution is loaded; Receive test requests triggered by the code under test, and obtain the execution status of the code under test in real time through the probe; The system receives execution instructions for code coverage statistics, calls pre-configured build automation tools through the test coverage statistics pipeline, and executes them in conjunction with the corresponding script configuration files: it connects to the probe to obtain the execution status, performs code coverage data statistics based on the execution status, and generates the corresponding coverage statistics file.

2. The method as described in claim 1, characterized in that, The test service pipeline builds a test service code image file containing probe startup parameters, which indicate that when the test service code starts, a probe for recording code execution is loaded. When the tested service code starts, a probe for recording code execution is loaded, including: When the code under test is started, a toolkit for recording the code execution status of a probe is loaded from the specified directory of the service under test corresponding to the code under test.

3. The method as described in claim 1, characterized in that, The configuration file specifies the installation path of the code coverage tool on the test server. Connecting the probe to obtain the execution status includes: Connect the probe according to the installation path to obtain the execution status.

4. The method as described in claim 1, characterized in that, The test coverage statistics pipeline defines the statistical parameters corresponding to the coverage statistics; the statistical parameters are used to indicate at least one of incremental statistics and full statistics.

5. The method as described in claim 4, characterized in that, If the statistical parameters indicate incremental statistics, the test coverage statistics pipeline also defines the mode parameters corresponding to the incremental statistics. The mode parameters include: incremental branch, incremental tag, commit ID, comparison benchmark, and comparison object. The code coverage data statistics based on the execution status include: The benchmark is compared with the object of comparison according to at least one of the incremental branch, the incremental tag, and the commit identifier, and incremental statistics are performed on the code coverage data based on the comparison results.

6. The method as described in claim 4, characterized in that, If the statistical parameters indicate full statistics; The code coverage data statistics based on the execution status include: Perform full statistics on the code coverage data of the entire tested service code.

7. The method according to any one of claims 1-6, characterized in that, The test coverage statistics pipeline defines generation parameters related to coverage statistics files; the generation parameters include at least one of the following: an append parameter indicating whether to append the code coverage data to the historical coverage data file, and a reset parameter indicating whether to delete coverage data from the historical coverage data file.

8. The method as described in claim 7, characterized in that, The generated parameters include appended parameters; Generate the corresponding coverage statistics file, including: If the append parameter indicates that code coverage data is appended to the historical coverage data file, then the code coverage data is written to the historical coverage data file, and a corresponding coverage statistics file is generated based on the appended historical coverage data file. If the append parameter indicates that code coverage data should not be appended to the historical coverage data file, a new coverage data file is created and code coverage data is written. Based on the new coverage data file, a corresponding coverage statistics file is generated.

9. The method as described in claim 7, characterized in that, The generated parameters are reset parameters; Generate the corresponding coverage statistics file, including: If the reset parameter indicates that coverage data in the historical coverage data file is deleted, then in conjunction with the data cleanup task configured in the script configuration file, the coverage data in the historical coverage data file is automatically deleted, and code coverage data is written. Based on the historical coverage data file after the reset and writing, a corresponding coverage statistics file is generated. If the reset parameter indicates that coverage data in the historical coverage data file should not be deleted, then it is determined whether a historical coverage data file exists, and based on the determination result, combined with the code coverage data, a corresponding coverage statistics file is generated.

10. The method as described in claim 9, characterized in that, Based on the determined results and combined with code coverage data, a corresponding coverage statistics file is generated, including: If the determination result indicates that the historical coverage data file exists, then the code coverage data is written into the historical coverage data file, and a corresponding coverage statistics file is generated based on the written historical coverage data file. If the determination result indicates that the historical coverage data file does not exist, a new coverage data file is created and code coverage data is written. Based on the new coverage data file, a corresponding coverage statistics file is generated.

Images