Code coverage collection method, apparatus, and device

Abstract

This disclosure provides a code coverage acquisition method, apparatus, and device, relating to the field of artificial intelligence, specifically cloud computing and cloud-native technologies, and applicable to intelligent cloud scenarios. One specific implementation of the method includes: receiving dynamic parameters input by a user; performing coverage instrumentation based on the dynamic parameters; performing coverage statistics based on the dynamic parameters; and generating a coverage report. This implementation achieves seamless, automatic code coverage acquisition.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence, specifically cloud computing and cloud-native technologies, and can be applied in intelligent cloud scenarios. Background Technology

[0002] Code coverage is a metric in software testing that describes the proportion and extent to which source code in a program is tested. The resulting proportion is called code coverage ratio. Code coverage ratio is an important indicator reflecting the degree to which test cases cover the software under test. It is a reference value used to measure the completeness of testing, and code coverage ratio data can be used to evaluate whether the testing is sufficient.

[0003] Current technology utilizes coverage tools like JaCoCo to collect test coverage data. Common code coverage instrumentation methods include two main approaches: first, modifying the Docker image to add JaCoCo's JavaAgent; second, modifying the Docker-compose.yaml file to add JaCoCo's JavaAgent. JaCoCo stands for Java Code Coverage Library, a Java code coverage tool. Docker is an open-source application container engine. The JavaAgent is a parameter of the Java command. Docker-compose.yaml is a YAML template file. Summary of the Invention

[0004] This disclosure provides a code coverage acquisition method, apparatus, device, storage medium, and program product.

[0005] In a first aspect, embodiments of this disclosure propose a code coverage acquisition method, including: receiving dynamic parameters input by a user; performing coverage instrumentation based on the dynamic parameters; performing coverage statistics based on the dynamic parameters; and generating a coverage report.

[0006] Secondly, embodiments of this disclosure propose a code coverage acquisition device, comprising: a receiving module configured to receive dynamic parameters input by a user; an instrumentation module configured to perform coverage instrumentation based on the dynamic parameters; and a statistics module configured to perform coverage statistics based on the dynamic parameters and generate a coverage report.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform a method as described in any implementation of the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method as described in any of the implementations of the first aspect.

[0010] The code coverage acquisition method provided in this disclosure achieves fully automated, non-intrusive code coverage acquisition for Java containerized applications in a Kubernetes distributed environment based on Jacoco.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are provided for a better understanding of the invention and are not intended to limit the scope of this disclosure. Wherein:

[0013] Figure 1 This is a flowchart of an embodiment of the code coverage acquisition method according to this disclosure;

[0014] Figure 2 This is a flowchart of yet another embodiment of the code coverage acquisition method according to this disclosure;

[0015] Figure 3 This is a scenario diagram illustrating the code coverage acquisition method implemented in this embodiment of the present disclosure;

[0016] Figure 4 This is a schematic diagram of a structure of an embodiment of the code coverage acquisition device according to the present disclosure;

[0017] Figure 5 This is a block diagram of an electronic device used to implement the code coverage acquisition method of the embodiments of this disclosure. Detailed Implementation

[0018] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 A flowchart of one embodiment of the code coverage acquisition method according to this disclosure is shown. The code coverage acquisition method includes the following steps:

[0021] Step 101: Receive dynamic parameters input by the user.

[0022] In this embodiment, the coverage tool can receive dynamic parameters input by the user.

[0023] Typically, coverage tools run on a central control machine and are remotely operated via the Python third-party package paramiko. Users can input dynamic parameters, which the coverage tool running on the central control machine can retrieve from the continuous delivery platform (such as Ipipe). These dynamic parameters are in JSON string format and include: cluster login information, repository information (such as Icode repository information), branch information, commit identifier information (commitId information), service type (such as JAR, Tomcat), service process flag, path of compressed packages within containers (such as path of JAR / WAR packages within containers), path of startup scripts within containers (such as path of startup scripts within JAR / WAR containers), path of source code packages relative to the project root directory, files not included in coverage statistics, scanned package range, agent communication port, and project version information, etc.

[0024] Python is a computer programming language. Paramiko is a module used for remote control. The Ipipe platform provides continuous delivery capabilities, helping enterprises continuously improve the quality and efficiency of application delivery by automating the process from code submission to application delivery through build automation, test automation, and deployment automation. JSON (JavaScript Object Notation) is a lightweight data exchange format. The Icode platform is an enterprise-level code service platform that provides a series of code-centric functions such as code hosting, code review, code scanning, and code search. Tomcat is a lightweight application server. Both JAR and WAR are compressed files; a JAR is an archive of classes, while a WAR is a web application.

[0025] Step 102: Perform coverage instrumentation based on dynamic parameters.

[0026] In this embodiment, the coverage tool can perform coverage instrumentation based on dynamic parameters.

[0027] Typically, after obtaining the dynamic parameters input by the user, the coverage tool can pull the application source code from the Icode platform and communicate with the APP running in the Kubernetes cluster to complete the coverage instrumentation of multiple nodes.

[0028] Among them, k8s stands for Kubernetes, which is an open-source platform for building distributed cluster application environments. It is based on Docker and can be used with Docker to easily deploy distributed applications.

[0029] Step 103: Perform coverage statistics based on dynamic parameters and generate a coverage report.

[0030] In this embodiment, the coverage tool can perform coverage statistics based on dynamic parameters and generate a coverage report.

[0031] Typically, after obtaining the dynamic parameters input by the user, the coverage tool can pull the application source code from the Icode platform and communicate with the APP running in the Kubernetes cluster to complete the coverage instrumentation of multiple nodes and the final coverage data collection, generating a coverage report.

[0032] Typically, coverage tools can push coverage reports to the Cov platform for visualization. The Cov platform provides a unified, standardized, efficient, and intelligent unit test build infrastructure, offering comprehensive code coverage metrics for various test types, and supporting report data push, storage, and comparison functions.

[0033] In some embodiments, to enrich the ways in which coverage reports are pushed, coverage reports can be pushed through at least one of the following methods:

[0034] Firstly, coverage reports are pushed in real time by calling the email notification function.

[0035] Typically, real-time email notifications can be achieved by calling the email notification function on the Ipipe platform.

[0036] Secondly, coverage reports are pushed by calling the report push interface.

[0037] Typically, reports can be uploaded and managed by calling the report push interface provided by the Cov platform.

[0038] The code coverage collection method provided in this disclosure achieves fully automated, seamless code coverage collection for Java containerized applications in a Kubernetes distributed environment based on JaCoco. Furthermore, by combining the Ipipe, Icode, and Cov platforms, it achieves fully automated execution, resolving issues such as the complexity of JaCoco environment setup and its dependence on source code, requiring no manual intervention throughout the entire process.

[0039] Continue to refer to Figure 2 The diagram illustrates a flowchart of yet another embodiment of the code coverage acquisition method according to this disclosure. This code coverage acquisition method includes the following steps:

[0040] Step 201: Receive dynamic parameters input by the user.

[0041] In this embodiment, the specific operation of step 201 has been described. Figure 1 The steps in step 101 of the illustrated embodiment are described in detail and will not be repeated here.

[0042] Step 202: Retrieve the source code of each microservice in the project based on the code repository information.

[0043] In this embodiment, the source code of each microservice in the project can be retrieved based on the code library information in the dynamic parameters.

[0044] Typically, after obtaining the dynamic parameters input by the user from Ipipe, the coverage tool can pull the source code of all microservices involved in the project to the central control machine based on the Icode codebase information.

[0045] Step 203: Generate incremental code files based on the submission identifier information.

[0046] In this embodiment, an incremental code file can be generated based on the commit identifier information in the dynamic parameters.

[0047] Typically, dynamic parameters can include the commit IDs of two commits (commit ID1 and commit ID2) entered by the user. Since commit IDs record code change information, an incremental code file can be generated based on commit ID1 and commit ID2.

[0048] Step 204: Distribute the coverage tool and source code to each node in the cluster that contains the application process identifier, corresponding to the cluster login information.

[0049] In this embodiment, the coverage tool and source code are distributed to each node in the cluster corresponding to the cluster login information that contains the application process identifier.

[0050] Typically, the coverage tool and source code are compressed and remotely distributed to nodes in the cluster corresponding to the cluster login information that contain the application process identifier. The cluster corresponding to the cluster login information is the cluster under test. The node containing the application process identifier is the node with the application installed.

[0051] Step 205: Locate the container identifier based on the application process identifier, and copy the coverage tool and source code into the container corresponding to the container identifier.

[0052] In this embodiment, the container identifier is located based on the application process identifier, and the coverage tool and source code can be copied into the container corresponding to the container identifier.

[0053] Typically, the container identifier can be located using the `docker ps` command. The `docker cp` command copies coverage tools and source code into the container.

[0054] Step 206: Based on the service type, service process flag, path of the compressed package within the container, path of the startup script within the container, path of the source package relative to the project root directory, files for which coverage statistics are not performed, scan package range, and proxy communication port, dynamically replace the variables in the build template file within the container.

[0055] In this embodiment, variables in the build template file can be dynamically replaced within the container based on the service type, service process flag, path of the compressed package within the container, path of the startup script within the container, path of the source code package relative to the project root directory, files for which coverage statistics are not performed, scan package range, and proxy communication port.

[0056] Typically, based on the user-input service type (jar / tomcat), service process flag, jar / war package path within the container, jar / war container startup script path, source package path relative to the project root directory, files excluded from coverage statistics when generating the report, scanned package range, and agent communication port, variables in the build.xml template file are dynamically replaced within the container.

[0057] Step 207: Based on the startup script path inside the container, dynamically write the agent of the coverage tool into the startup script file inside the container, and restart the container.

[0058] In this embodiment, based on the startup script path inside the container, the agent of the coverage tool can be dynamically written into the startup script file inside the container, and the container can be restarted.

[0059] Typically, the jacocoagent is dynamically written into the startup script file inside the jar / war container provided by the user, and then the container is restarted using the docker restart command, thus completing the entire instrumentation process.

[0060] Step 208: Dynamically generate coverage file scripts and coverage report scripts within the container based on the service type.

[0061] In this embodiment, coverage file scripts and coverage report scripts can be dynamically generated within the container, depending on the service type.

[0062] Typically, depending on the service type (jar / tomcat), ant_dump.sh and ant_report.sh can be dynamically generated within the container.

[0063] Step 209: Execute the coverage file script on each node in the cluster that contains the application process identifier to obtain the coverage file for each node.

[0064] In this embodiment, a coverage file script can be executed on each node in the cluster that contains the application process identifier to obtain the coverage file for each node.

[0065] Typically, running ant_dump.sh on each node of the cluster will generate the jacoco.exec file on all nodes.

[0066] Step 210: Select a master node from the cluster and distribute the coverage files of the other nodes in the cluster to the master node.

[0067] In this embodiment, selecting a master node from the cluster allows the coverage files of other nodes in the cluster to be distributed to the master node.

[0068] Typically, the first node entered by the user is selected as the master node, and the jacoco.exec files on other nodes are transferred to the central control unit node, which then distributes them to the master node.

[0069] Step 211: Execute the coverage report script on the master node based on the coverage files of each node to generate full and incremental coverage reports for each microservice.

[0070] In this embodiment, a coverage report script is executed on the master node based on the coverage files of each node to generate full and incremental coverage reports for each microservice.

[0071] Typically, executing `ant_report.sh` on the master node generates full and incremental coverage reports for each microservice. Here, the incremental report generation functionality can utilize capabilities provided by the Cov platform.

[0072] Step 212: Summarize the full and incremental coverage reports of each microservice according to the project dimension to generate a project coverage report.

[0073] In this embodiment, the full and incremental coverage reports of each microservice are summarized according to the project dimension to generate a project coverage report.

[0074] Typically, the reports from the container are copied to the physical machine using Docker and then remotely uploaded back to the central control machine. On the central control machine, coverage data for all microservices is obtained by parsing HTML reports as strings, categorized by project. After aggregating all microservice data, the overall metric value is calculated using a formula and archived in a folder named after the project version.

[0075] In some embodiments, to avoid coverage data loss due to service instability or POD drift during testing, coverage file scripts can be executed periodically on each node. Simultaneously, the service process status of each node is scanned, and coverage instrumentation is re-performed on nodes whose service process status does not contain the target command parameters.

[0076] By setting up a scheduled task to periodically dump the jacoco.exec file, and simultaneously scanning the service process status for the keyword "javaagent," it's determined that the service is not instrumented or the instrumentation is ineffective, requiring re-instrumentation. Dynamic monitoring of the instrumentation status avoids significant code coverage data loss due to service restarts, crashes, or POD drift, thus improving availability.

[0077] from Figure 2 It can be seen from this that, with Figure 1Compared to the corresponding embodiments, the code coverage collection method in this embodiment emphasizes the instrumentation and statistical steps. Therefore, the solution described in this embodiment can automatically collect and merge the code coverage of multiple Java microservices in a Kubernetes distributed environment. It achieves container-insensitive instrumentation, eliminating the need to modify the Docekr image or docker-compose.yaml before image building, ensuring consistency across development, testing, and release without the developers' awareness. It supports project-level coverage reports; a project containing multiple microservices can have its overall coverage statistically analyzed by project. This effectively solves the challenge of backend code coverage statistics after migrating smart city products to a cloud-native environment. It achieves non-intrusive, seamless, and fully automated statistical capabilities in a Kubernetes distributed environment, significantly improving product quality and iteration efficiency. Currently, it has been applied in the Smart City Business Unit, including products such as the operation and management platform, vision workstation, one-person-one-file system, facial recognition system, and view library system.

[0078] For ease of understanding, Figure 3 This is a scenario diagram illustrating the code coverage acquisition method implemented in this embodiment of the disclosure. For example... Figure 3 As shown, the coverage tool includes four general modules: coverage instrumentation, coverage statistics, report push, and dynamic monitoring.

[0079] Coverage instrumentation: After obtaining the dynamic parameters input by the user from the Ipipe platform, the source code of all microservices involved in the project is pulled from the Icode code repository to the central control machine. Based on the commit IDs of the two commits input by the user, incremental code files are generated. Then, the coverage tool and source code are compressed and remotely distributed to the nodes of the cluster under test. After locating the container ID using the `docker ps` command, the coverage tool and source code are copied into the container using the `docker cp` command. Next, a `build.xml` template file is dynamically generated, and `jacocoagent` is dynamically written into the startup script file inside the JAR / WAR container input by the user. Finally, the container is restarted using the `docker restart` command, thus completing the entire instrumentation process.

[0080] Coverage Statistics: After obtaining dynamic parameters input by the user from the Ipipe platform, ant_dump.sh and ant_report.sh are dynamically generated within the container based on the service type (jar / tomcat). ant_dump.sh is executed on each node of the cluster, resulting in jacoco.exec files generated on all nodes. The first node with user input is selected as the master node, and the jacoco.exec files from other nodes are transferred to the central control machine, which then distributes them to the master node. ant_report.sh is executed on the master node to generate full and incremental coverage reports for each microservice. The reports from the container are then copied to a physical machine using Docker and remotely uploaded back to the central control machine. On the central control machine, coverage data for all microservices is obtained by parsing HTML reports by project dimension. After aggregating all microservice data, the overall metric value is calculated using a formula and archived in a folder named after the project version.

[0081] Report push: Real-time email notifications are achieved by calling the email notification function on the Ipipe platform; reports are uploaded and managed by calling the report push interface provided by the Cov platform.

[0082] Dynamic detection: Set up a scheduled task to periodically dump the jacoco.exec file and scan the service process status for the keyword "javaagent". If it is not found, notify the corresponding tester via email and perform coverage instrumentation.

[0083] Further reference Figure 4 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a code coverage acquisition device, which is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0084] like Figure 4 As shown, the code coverage acquisition device 400 of this embodiment may include: a receiving module 401, an instrumentation module 402, and a statistics module 403. The receiving module 401 is configured to receive dynamic parameters input by the user; the instrumentation module 402 is configured to perform coverage instrumentation based on the dynamic parameters; and the statistics module 403 is configured to perform coverage statistics based on the dynamic parameters and generate a coverage report.

[0085] In this embodiment, the specific processing of the receiving module 401, the instrumentation module 402, and the statistics module 403 in the code coverage acquisition device 400, and the resulting technical effects, can be found in the following references: Figure 1 The relevant descriptions of steps 101-103 in the corresponding embodiments will not be repeated here.

[0086] In some optional implementations of this embodiment, the dynamic parameters include: cluster login information, code repository information, branch information, commit identifier information, service type, service process flag, path of the compressed package within the container, path of the startup script within the container, path of the source code package relative to the project root directory, files for which coverage statistics are not performed, scan package range, proxy communication port, and project version information.

[0087] In some optional implementations of this embodiment, the instrumentation module 402 is further configured to: pull the source code of each microservice of the project according to the code repository information; generate incremental code files according to the commit identifier information; distribute the coverage tool and source code to each node in the cluster corresponding to the cluster login information that contains the application process identifier; locate the container identifier according to the application process identifier, and copy the coverage tool and source code into the container corresponding to the container identifier; dynamically replace the variables in the build template file in the container according to the service type, service process flag, path of the compressed package in the container, path of the startup script in the container, path of the source code package relative to the project root directory, files that are not included in coverage statistics, scan package range, and proxy communication port; dynamically write the proxy of the coverage tool into the startup script file in the container according to the startup script path in the container, and restart the container.

[0088] In some optional implementations of this embodiment, the statistics module 403 is further configured to: dynamically generate coverage file scripts and coverage report scripts within the container according to the service type; execute the coverage file scripts on each node in the cluster that contains the application process identifier to obtain the coverage files for each node; select a master node from the cluster and distribute the coverage files of the other nodes in the cluster to the master node; execute the coverage report scripts on the master node based on the coverage files of each node to generate full and incremental coverage reports for each microservice; and summarize the full and incremental coverage reports of each microservice according to the project dimension to generate a project coverage report.

[0089] In some optional implementations of this embodiment, the coverage file script is executed periodically on each node; and the code coverage acquisition device 400 further includes: a scanning module configured to scan the service process status of each node; and a re-instrumentation module configured to re-instrument the coverage for nodes whose service process status does not contain the target command parameters.

[0090] In some optional implementations of this embodiment, the code coverage acquisition device 400 further includes: pushing coverage reports in real time by calling the email notification function; and / or pushing coverage reports by calling the report push interface.

[0091] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0092] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0093] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0094] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0095] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0096] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the code coverage acquisition method. For example, in some embodiments, the code coverage acquisition method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the code coverage acquisition method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the code coverage acquisition method by any other suitable means (e.g., by means of firmware).

[0097] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0098] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0099] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer 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 of the foregoing.

[0100] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0101] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0102] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology.

[0103] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution provided in this disclosure can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A code coverage acquisition method, comprising: Receive dynamic parameters input by the user, including: cluster login information, code repository information, commit identifier information, service type, service process flag, path of the compressed package in the container, path of the startup script in the container, path of the source code package relative to the project root directory, files that are not included in coverage statistics, scan package range, and proxy communication port. Coverage instrumentation is performed based on the aforementioned dynamic parameters; Based on the dynamic parameters, coverage statistics are performed, and a coverage report is generated. The coverage instrumentation based on the dynamic parameters includes: Based on the code repository information, pull the source code of each microservice of the project; Based on the submission identifier information, generate an incremental code file; The coverage tool and the source code are distributed to each node in the cluster corresponding to the cluster login information that contains the application process identifier; Based on the application process identifier, locate the container identifier, and copy the coverage tool and the source code into the container corresponding to the container identifier; Based on the service type, the service process flag, the path of the compressed package within the container, the path of the startup script within the container, the path of the source code package relative to the project root directory, the files for which coverage statistics are not performed, the scan package range, and the proxy communication port, the variables in the build template file are dynamically replaced within the container. Based on the startup script path within the container, the agent of the coverage tool is dynamically written into the startup script file within the container, and the container is restarted.

2. The method according to claim 1, wherein, The dynamic parameters also include: branch information and project version information.

3. The method according to claim 1, wherein, The process of performing coverage statistics based on the dynamic parameters and generating a coverage report includes: Dynamically generate coverage file scripts and coverage report scripts within the container according to the service type; The coverage file script is executed on each node in the cluster that contains the application process identifier to obtain the coverage file for each node. Select a master node from the cluster and distribute the coverage files of the other nodes in the cluster to the master node; On the master node, the coverage report script is executed based on the coverage files of each node to generate full and incremental coverage reports for each microservice. The full and incremental coverage reports of each microservice are summarized according to the project dimension to generate a project coverage report.

4. The method according to claim 3, wherein, The coverage file script is executed periodically on each node; as well as The method further includes: Scan the service process status of each node; For nodes whose service process status does not contain the target command parameters, re-instrument the coverage.

5. The method according to any one of claims 1-4, wherein, The method further includes: The coverage report is pushed in real time by invoking email notification functionality; and / or The coverage report is pushed by calling the report push interface.

6. A code coverage acquisition device, comprising: The receiving module is configured to receive dynamic parameters input by the user. The dynamic parameters include: cluster login information, code repository information, submission identification information, service type, service process flag, path of the compressed package in the container, path of the startup script in the container, path of the source package relative to the project root directory, files for which coverage statistics are not performed, scan package range, and proxy communication port. The instrumentation module is configured to perform coverage instrumentation based on the dynamic parameters; The statistics module is configured to perform coverage statistics based on the dynamic parameters and generate a coverage report; The instrumentation module is further configured to: The coverage instrumentation based on the dynamic parameters includes: Based on the code repository information, pull the source code of each microservice of the project; Based on the submission identifier information, generate an incremental code file; The coverage tool and the source code are distributed to each node in the cluster corresponding to the cluster login information that contains the application process identifier; Based on the application process identifier, locate the container identifier, and copy the coverage tool and the source code into the container corresponding to the container identifier; Based on the service type, the service process flag, the path of the compressed package within the container, the path of the startup script within the container, the path of the source code package relative to the project root directory, the files for which coverage statistics are not performed, the scan package range, and the proxy communication port, the variables in the build template file are dynamically replaced within the container. Based on the startup script path within the container, the agent of the coverage tool is dynamically written into the startup script file within the container, and the container is restarted.

7. The apparatus according to claim 6, wherein, The dynamic parameters also include: branch information and project version information.

8. The apparatus according to claim 6, wherein, The statistics module is further configured to: Dynamically generate coverage file scripts and coverage report scripts within the container according to the service type; The coverage file script is executed on each node in the cluster that contains the application process identifier to obtain the coverage file for each node. Select a master node from the cluster and distribute the coverage files of the other nodes in the cluster to the master node; On the master node, the coverage report script is executed based on the coverage files of each node to generate full and incremental coverage reports for each microservice. The full and incremental coverage reports of each microservice are summarized according to the project dimension to generate a project coverage report.

9. The apparatus according to claim 8, wherein, The coverage file script is executed periodically on each node; as well as The device further includes: The scanning module is configured to scan the service process status of each node; The re-instrumentation module is configured to re-instrument coverage for nodes whose service process states do not contain the target command parameters.

10. The apparatus according to any one of claims 6-9, wherein, The device further includes: The coverage report is pushed in real time by invoking email notification functionality; and / or The coverage report is pushed by calling the report push interface.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-5.

12. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-5.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-5.

Images