Method for collecting test coverage rate, related device and computer program product

Abstract

The invention provides a method for collecting a test coverage rate, a related device and a computer program product, and the method comprises the steps: generating a user-defined access interface for a coverage rate collection tool, and enabling the coverage rate collection tool to be used for collecting test coverage rate information generated when a micro-service system program is tested by a tested script; in response to a test coverage rate providing request sent by target equipment for the target micro-service system program in the process of testing the target micro-service system program by using the test script, reading test coverage rate information collected by a coverage rate collection tool by calling a user-defined access interface; and analyzing the test coverage rate information, and generating test coverage rate feedback information used for being fed back to the target equipment. Therefore, in the process of testing the micro-service system program, the test coverage rate can be collected under the condition that the micro-service system program is not closed, and the test coverage rate can be collected more flexibly, conveniently and efficiently.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and apparatus for collecting test coverage, an electronic device, a computer-readable medium, and a computer program product. Background Art

[0002] Microservices Architecture is a software architectural style that can split a large, complex monolithic application into a set of small, independent, loosely coupled services that can interact through lightweight communication protocols, and then each service is responsible for implementing specific business functions.

[0003] In this context, to ensure the quality of microservice-based systems, developers utilize test scripts to test the various functions and interactions between them during the development process. Consequently, test coverage, as a key testing metric, is gaining increasing attention among code developers, as it can be used to measure the coverage of microservice-based systems by test cases and scripts, helping developers assess whether they have effectively tested each component of the microservice-based system. Therefore, the need for more flexible, convenient, and efficient test coverage collection during microservice-based system testing is a pressing concern. Summary of the Invention

[0004] Multiple aspects of the present application provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for collecting test coverage, which enable test coverage to be collected without shutting down the microservice system program during testing of the microservice system program, thereby enabling more flexible, convenient, and efficient collection of test coverage.

[0005] In one aspect of the present application, a method for collecting test coverage is provided, comprising: generating a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect test coverage information generated by a microservice system program when the microservice system program is tested by a test script; in response to receiving a test coverage provision request sent by a target device for a target microservice system program during the process of testing the target microservice system program using a test script, reading the test coverage information collected by the coverage collection tool by calling the custom access interface; parsing the test coverage information, and generating test coverage feedback information for feedback to the target device.

[0006] Another aspect of the present application provides an apparatus for collecting test coverage, comprising: an access interface generation module configured to generate a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect test coverage information generated by a microservice system program when the program is tested by a test script; a coverage information reading module configured to respond to a test coverage provision request sent by a target device for a target microservice system program during testing of the target microservice system program using a test script, and to read the test coverage information collected by the coverage collection tool by calling the custom access interface; and a feedback information generation module configured to parse the test coverage information and generate test coverage feedback information for feedback to the target device.

[0007] Another aspect of the present application provides an electronic device, comprising: 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for collecting test coverage provided above.

[0008] In another aspect of the present application, a computer-readable storage medium is provided, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the method for collecting test coverage as provided above.

[0009] In another aspect of the present application, a computer program product includes a computer program having computer program instructions stored thereon. When the computer program is executed by a processor, the method for collecting test coverage as provided above can be implemented.

[0010] In the solution provided by the embodiment of the present application, first, a custom access interface for the coverage collection tool is generated, wherein the coverage collection tool is used to collect the test coverage information generated by the microservice system program when the test script is tested. Then, in response to receiving a test coverage provision request sent by the target device for the target microservice system program during the process of testing the target microservice system program using the test script, the test coverage information collected by the coverage collection tool is read by calling the custom access interface. Finally, the test coverage information is parsed, and test coverage feedback information for feedback to the target device is generated. As a result, it is possible to collect test coverage without shutting down the microservice system program during the process of testing the microservice system program, and the test coverage can be collected more flexibly, conveniently and efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings: Figure 1 A flowchart of a process for collecting test coverage provided in an embodiment of the present application; Figure 2 A flowchart of another process for collecting test coverage provided in an embodiment of the present application; Figure 3 A flowchart illustrating a process for collecting test coverage in a specific application scenario provided by an embodiment of the present application; Figure 4 A schematic diagram of the structure of a device for collecting test coverage provided in an embodiment of the present application; Figure 5 The figure is a schematic diagram of the structure of an electronic device suitable for implementing the solution in the embodiment of the present application.

[0013] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0014] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0015] In a typical configuration of the present application, the terminal and the equipment of the service network each include one or more processors (CPUs), input / output interfaces, network interfaces and memories.

[0016] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0017] Computer-readable media include both permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology for information storage. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc-read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0018] As discussed above, in the process of testing microservice system programs, how to collect test coverage more flexibly, conveniently and efficiently is worthy of attention and urgent need.

[0019] In some solutions, you can configure collection tools for each part of the microservice system program to collect test coverage during testing. However, these collection tools often only output the collected test coverage after the test is complete. This makes it difficult for developers to obtain test coverage flexibly and in real time, seriously affecting their testing efficiency.

[0020] To this end, an embodiment of the present application provides a method for collecting test coverage. The method first generates a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect the test coverage information generated by the microservice system program when the test script is tested. Then, in response to receiving a test coverage provision request sent by the target device for the target microservice system program during the process of testing the target microservice system program using the test script, the test coverage information collected by the coverage collection tool is read by calling the custom access interface. Finally, the test coverage information is parsed, and test coverage feedback information for feedback to the target device is generated. As a result, it is possible to collect test coverage without shutting down the microservice system program during the process of testing the microservice system program, and the test coverage can be collected more flexibly, conveniently and efficiently.

[0021] In practical scenarios, the method can be executed by a user device, a device formed by integrating a user device and a network device via a network, or an application running on such a device. User devices include, but are not limited to, computers, mobile phones, tablets, smart watches, wristbands, and other terminal devices. Network devices include, but are not limited to, network hosts, single network servers, multiple network server clusters, or cloud computing-based computer collections. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a group of loosely coupled computers forming a virtual computer.

[0022] When the execution subject is software, it can be installed in the electronic devices listed above. It can be implemented as multiple software or software modules, or as a single software or software module, and is not specifically limited here.

[0023] Figure 1 A process 100 for collecting test coverage provided by an embodiment of the present application is shown. The process 100 includes at least the following processing steps: (Step) S101, generating a custom access interface for a coverage collection tool; In an embodiment of the present application, the execution entity may first determine a coverage collection tool for collecting test coverage information generated by the microservice system program when being tested by the test script.

[0024] The execution entity then generates a custom access interface for accessing and accessing the coverage collection tool. For example, within the business container used to complete the aforementioned test, the execution entity can generate a custom access interface within the business container for accessing the coverage collection tool, which can be exposed outside the business container. For example, this custom access interface can be an HTTP (HyperText Transfer Protocol) interface, an RPC (Remote Procedure Call) interface, or even port 2233.

[0025] Coverage collection tools can have different forms based on the operating environment of different microservice system programs.

[0026] In some embodiments, if the microservice system program runs in a Golang environment, that is, the microservice system program is developed based on the Go programming language, then the "coverage collection tool" can be provided by the testing tool kit (Tesing) in the Go software development kit (Software Development Kit, referred to as SDK), for example, the "coverage collection tool" can be the code coverage (Code Coverage) function provided in the Go SDK.

[0027] In such a case, the execution entity may choose to generate at least a Cover / Dump interface in the main test file including the coverage collection tool, so as to utilize the Cover / Dump interface as a custom access interface for the coverage collection tool.

[0028] For example, the execution entity can create a new main test file, such as main_test.go, in the Command Prompt (CMD) directory to wrap the original main method. Then, by appending the Cover / Dump interface to the main test file, a custom access interface for the coverage collection tool is generated and provided.

[0029] Therefore, based on the added Cover / Dump interface, the execution entity can dynamically control and obtain the test coverage information collected by the coverage collection tool in real time during the testing of the microservice system program by calling the Cover / Dump interface. For example, through the Cover / Dump interface, the execution entity can export or "dump" the test coverage information currently collected by the coverage collection tool.

[0030] In some embodiments, in order to provide more management functions for test coverage information in the Golang environment, the execution entity can also add a Cover / Reset interface in addition to the Cover / Dump interface. The Cover / Reset interface can be used to clear the currently collected test coverage information and restart the collection of coverage information.

[0031] In some embodiments, the microservice system program can also run in a Java environment, that is, the microservice system program is developed based on the Java programming language. In this case, when performing this step, the execution entity can choose to add a JaCoCo agent (e.g., Jacocoagent.jar) to the business container used to test the microservice system program as a coverage collection tool. JaCoCo can be used to analyze the code coverage of test cases and scripts. For example, JaCoCo can dynamically collect execution data through instrumentation technology to determine and collect test coverage information.

[0032] Accordingly, in such an embodiment, after inserting jacocoagent.jar into the business container, the execution entity may modify the (native startup instruction) of the business container to add or append a Java agent for the JaCoCo agent (eg, -Javaagent).

[0033] The added Java agent can serve as a custom access interface for the JaCoCo agent, which is a coverage collection tool (for example, it can also be the above-mentioned "port 2233"), so that it can be called externally in a way such as Jacococli access to obtain the test coverage information collected in, for example, jacocoagent.jar.

[0034] Therefore, by introducing additional Java agents, the execution entity can obtain the test coverage information generated by the microservice system program running in the Java environment during the test process in real time according to needs and instructions, without having to interrupt the test process of the microservice system program.

[0035] S102, in response to receiving a test coverage provision request for the target microservice system program sent by the target device during the process of testing the target microservice system program using the test script, reading test coverage information collected by the coverage collection tool by calling a custom access interface; In an embodiment of the present application, because the test coverage can be collected without shutting down the microservice system program and without interrupting the testing of the microservice system, during the testing of the target microservice system program, the execution entity can receive a test coverage provision request sent to the target microservice system program by, for example, a target device used by a user, and provide test coverage information for it accordingly.

[0036] In some embodiments, a user (i.e., the user of a target device) can indicate their desire to monitor and manage the target microservice system program and collect test coverage by providing at least one of the following: the microservice system's operating address, a custom access interface description, and environmental information. For example, an execution entity can generate a test coverage provision request based on the aforementioned description information and provide it to the execution entity.

[0037] Accordingly, if the execution entity receives such a test coverage request, it can respond by obtaining the descriptive information corresponding to the test coverage request. The execution entity can then compare this descriptive information with control system information, such as Git information, SVN (Subversion) information, or Mercurial information, of the target microservice system program currently being tested.

[0038] If the two match, the execution entity can determine that the user wishes to collect test coverage for the target microservice system program being tested. The execution entity can then utilize the custom access interface generated in S101 to correspondingly collect test coverage information. That is, if the description information matches the control system information of the target microservice system program, the execution entity can respond by reading the test coverage information collected by the coverage collection tool through the custom access interface.

[0039] In other words, after receiving a test coverage request, the execution entity can search and locate the "microservice system program" indicated by the user based on the descriptive information included therein. Accordingly, if the "microservice system program" found and located is the "target microservice system program" being tested, the execution entity can collect test coverage information during the testing of the "target microservice system program" by calling the "custom access interface" without shutting down the "target microservice system program" or interrupting the test.

[0040] In some embodiments, if the "microservice system program" located by the user's description information is not being tested, that is, it is not the "target microservice system program" being tested as mentioned above, the execution entity can generate "test coverage feedback information" based on its historically generated test coverage information as discussed below.

[0041] In some embodiments, for example, the control system information of Git information may include group information, project information, and commit hash (Commit_SHA (Secure Hash Algorithm, SHA for short)) information to indicate the corresponding microservice system program.

[0042] In some embodiments, the execution entity can also pre-collect a relatively comprehensive amount of Git information associated with the microservice system program (for example, the file name and image name of the microservice system program). The execution entity can then store this collection result in a snapshot database in the form of a "snapshot." For example, the snapshot database can be built based on a B-tree or B+-tree structure, such as an LSM (Log-Structured Merge Tree) log structure. In some scenarios, the snapshot database can also choose to store Git information in a key-value table format.

[0043] Therefore, the "snapshot" method is used to collect information about microservice system programs in an overall and batch manner, and while realizing the concatenation of different types of data, the control system information and description information can be compared more accurately and efficiently.

[0044] Furthermore, in some embodiments, for the process of reading the test coverage information collected by the coverage collection tool by calling a custom access interface, if the (target) microservice system program runs in a Golang environment, then during the execution of this step, the execution entity may choose to read the test coverage information collected by the above-mentioned Cover / Dump interface to obtain the test coverage information in real time during the testing of the target microservice system program implemented in the Golang environment.

[0045] If the (target) microservice system program runs in a Java environment, then during the execution of this step, the execution entity can call the JaCoCo agent through the Java agent using Jacococli to read the test coverage information collected by the JaCoCo agent, so as to obtain the test coverage information in real time during the test of the target microservice system program implemented in the Java environment.

[0046] Therefore, based on the above method, the execution subject can read and obtain test coverage information in real time and flexibly in different operating environments, so that the process of collecting test coverage has high compatibility with scenarios and operating environments.

[0047] S103: parse the test coverage information and generate test coverage feedback information for feeding back to the target device.

[0048] In an embodiment of the present application, after reading the test coverage information collected by the coverage collection tool based on the above S102, the execution entity can rewrite and unify the test coverage information into the target format in this step to obtain test coverage feedback information that can be read by the user and used to feed back to the target device.

[0049] For example, in the test coverage information, indicators corresponding to codes and functions are used to indicate whether the corresponding codes and functions have been tested (for example, whether they have been "tested" is indicated by the difference in indicators. For example, when the indicators are expressed in binary, "1" can be used to indicate "tested", and "0" can be used to indicate "not tested").

[0050] For example, for the Golang environment, the execution entity can choose to traverse the test coverage information after reading the test coverage information by calling the Cover / Dump interface, and then convert the basic information included therein, such as the file name of the target collection microservice system program, the test coverage starting row and column, the test coverage ending row and column, the number of runs, the branch coverage status, etc., into the target format to complete the "parsing" and obtain the test coverage feedback information.

[0051] For example, in a Java environment, after obtaining test coverage information using Jacococli.jar, the execution entity can determine the source code, class files, and .exec files required for test coverage feedback. The execution entity can then process the test coverage information using the JaCoCo SDK to obtain test coverage feedback in the target format.

[0052] Then, the method for collecting test coverage provided by the present application first generates a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect the test coverage information generated by the microservice system program when the test script is tested. Then, in response to receiving a test coverage provision request sent by the target device for the target microservice system program during the process of testing the target microservice system program using the test script, the test coverage information collected by the coverage collection tool is read by calling the custom access interface. Finally, the test coverage information is parsed to generate test coverage feedback information for feedback to the target device. As a result, it is possible to collect test coverage without shutting down the microservice system program during the process of testing the microservice system program, and the test coverage can be collected more flexibly, conveniently and efficiently.

[0053] In some embodiments, if the (target) microservice system program runs in a Golang environment, the execution entity can also directly encapsulate the aforementioned "parsing" parsing tool within a custom access interface to improve integration performance. Accordingly, when reading the test coverage information collected by the Cover / Dump interface, the execution entity can alternatively or alternatively use the parsing tool to complete the reading. After the parsing tool completes the reading, it can complete the subsequent parsing steps based on the "parsing functionality" it provides.

[0054] In some embodiments, the parsing tool may be configured with a desired file format for the test coverage feedback information, thereby enabling the parsing tool to efficiently and conveniently obtain test coverage feedback information that meets the requirements.

[0055] Accordingly, in order to facilitate understanding of the embodiment using the analysis tool, you can also refer to Figure 2 . Figure 2 Another process 200 for collecting test coverage provided by an embodiment of the present application is shown. The process 200 can be applied to a (target) microservice system program running in a Golang environment.

[0056] Process 200 includes at least the following processing steps: S201, generating a Cover / Dump interface in a main test file including a coverage acquisition tool; Specifically, as discussed above, if the microservice system program is running in a Golang environment, the execution entity can "generate a custom access interface for the coverage collection tool" by generating a Cover / Dump interface in the main test file that includes the coverage collection tool. The explanation will not be repeated here.

[0057] S202, in response to receiving a test coverage provision request for the target microservice system program from a target device during testing of the target microservice system program using a test script, reading test coverage information collected by the Cover / Dump interface using a parsing tool encapsulated in the custom access interface; Specifically, if a test coverage provision request is received from the target device for the target microservice system program during the process of testing the target microservice system program using the test script, the execution entity can respond to this by using the parsing tool encapsulated in the custom access interface to read the test coverage information collected by the Cover / Dump interface, as discussed above.

[0058] For example, the parsing tool can be responsible for converting the initial test coverage information returned by the Cover / Dump interface (e.g., in JSON, XML, or other formats) into the pre-configured target format described above (in some embodiments, the target format can be a "unified format" used to unify test coverage feedback information for microservice system programs in different operating environments). For example, the parsing tool can classify the test coverage information by file, function, or line, extract the execution status of each code segment, and generate a file in the target format (e.g., a text file) based on these results.

[0059] In some embodiments, based on different needs, the parsing tool can be further configured to calculate, for example, the percentage of functions of the collection microservice system program that have completed testing based on the statistics and analysis above, so that the parsing tool can output information from multiple dimensions and angles in the test coverage feedback information, thereby facilitating user supervision and management of the testing process.

[0060] S203: Using a parsing tool, the test coverage information is processed into test coverage feedback information in a target format for feeding back to a target device.

[0061] Specifically, in this step, the execution subject actually only uses the parsing tool to provide corresponding services and functions by calling the parsing tool. The corresponding content can be referred to the content discussed in S202 above, and will not be repeated here.

[0062] Based on any of the above embodiments, after the execution entity generates the test coverage feedback information, it can choose to provide it to cloud storage to reduce its occupancy of local storage space, while allowing the execution entity to generate a large amount of test coverage feedback information for users, and allowing users to obtain test coverage feedback information according to their needs and expected acquisition timing.

[0063] That is, after generating the test coverage feedback information for feeding back to the target device, the execution entity may provide the test coverage feedback information to the cloud storage.

[0064] Accordingly, after completing the upload, the execution entity may control the cloud storage to respond when the target device requests the cloud storage for test coverage feedback information, thereby sending the test coverage feedback information to the target device.

[0065] In some embodiments, when utilizing cloud storage, the executing entity may further control the cloud storage to provide test coverage feedback information by, for example, generating a visual page to provide the user with such a visual page, so as to facilitate the user to read the specific content of the test coverage feedback information.

[0066] Accordingly, when utilizing cloud storage, the executing entity may generate a Uniform Resource Locator (URL) link corresponding to the storage location of the test coverage feedback information in the cloud storage, so that the user may request the test coverage feedback information from the cloud storage by accessing the URL link, which is convenient for the user.

[0067] In order to deepen the understanding, this application also combines a specific application scenario. Figure 3 A flowchart of the process of collecting test coverage in this specific application scenario is given. Figure 3 Process 300 is shown.

[0068] In the process 300 , a business container 310 may be used to implement a test process of a microservice system program 312 using a test script 311 . Accordingly, a coverage collection tool 313 may be configured in the business container 310 .

[0069] Next, the execution subject (not shown in the figure, for example, it can be a server for implementing the process of set test coverage, etc.) can generate a custom access interface for the coverage collection tool 313 by executing S301, for example, the custom access interface 314.

[0070] Then, the execution subject may start “testing” by executing S302 , for example, using the test script 311 to test the microservice program system 312 .

[0071] Accordingly, in the “test process”, the coverage collection tool 313 may collect test coverage information (eg, test coverage information 320 to be exemplified later) in the test process.

[0072] Accordingly, the test coverage information collected by the coverage collection tool 313 can be provided to the outside in real time through the custom access interface 314, or in other words, can be obtained externally.

[0073] Next, if during the test process of S302, a test coverage provision request is received from a target device (not shown in the figure) for the microservice system program 312, the execution entity can respond to this and read the test coverage information (for example, test coverage information 320) collected by the coverage collection tool 313 by calling the custom access interface 314 by executing S302.

[0074] After obtaining the test coverage information 320 , the execution entity may further execute S304 to parse the test coverage information 320 to generate test coverage feedback information 325 for feeding back to the target device.

[0075] In addition, as discussed above, in order to reduce the occupation of the local storage space of the execution entity and allow the execution entity to generate a large amount of test coverage feedback information for the user, the execution entity can also choose to execute S305 to provide and upload the test coverage feedback information 325 to the cloud storage 350, so as to facilitate the subsequent use of the cloud storage 350 to store the test coverage feedback information 325 for a long time, and use the cloud storage 350 to provide the test coverage feedback information 325 to the above-mentioned target device.

[0076] The embodiment of the present application also provides a device for collecting test coverage, the structure of which is as follows: Figure 4 The device 400 shown. The device 400 includes: an access interface generation module 410, configured to generate a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect test coverage information generated by the microservice system program when the test script is tested; a coverage information reading module 420, configured to respond to a test coverage provision request sent by a target device for the target microservice system program during the process of testing the target microservice system program using the test script, by calling the custom access interface to read the test coverage information collected by the coverage collection tool; a feedback information generation module 430, configured to parse the test coverage information and generate test coverage feedback information for feedback to the target device.

[0077] In some embodiments, the microservice system program runs in a Golang environment, and the access interface generation module 410 is further configured to generate a Cover / Dump interface in a main test file including a coverage collection tool, wherein the Cover / Dump interface is a custom access interface for the coverage collection tool, and the coverage collection tool is provided by a test toolkit of the Golang environment.

[0078] In some embodiments, the test coverage information collected by the coverage collection tool is read by calling a custom access interface, including: using a parsing tool encapsulated in the custom access interface to read the test coverage information collected by the Cover / Dump interface; and the feedback information generation module 430 is further configured to use the parsing tool to process the test coverage information into a target format for test coverage feedback information to be fed back to the target device.

[0079] In some embodiments, the microservice system program runs in a Java environment, and the access interface generation module 410 includes: a tool adding submodule, which is configured to add a JaCoCo agent as a coverage collection tool to the business container used to test the microservice system program; an agent adding submodule, which is configured to modify the startup instructions of the business container and add a Java agent for the JaCoCo agent, wherein the Java agent is a custom access interface for the coverage collection tool.

[0080] In some embodiments, the JaCoCo agent is called by the Java agent using Jacococli to read the test coverage information collected by the JaCoCo agent.

[0081] In some embodiments, the coverage information reading module 420 includes: a description information acquisition sub-module, which is configured to obtain at least one of the following description information included in the test coverage provision request in response to receiving a test coverage provision request sent by the target device during the process of testing the target microservice system program using a test script: the running address of the microservice system, the custom access interface description information, and the environment information; a coverage information reading sub-module, which is configured to read the test coverage information collected by the coverage collection tool by calling the custom access interface in response to the description information matching the control system information of the target microservice system program.

[0082] In some embodiments, the device 400 also includes: a feedback information storage module, configured to provide test coverage feedback information to cloud storage; a cloud storage control module, configured to control the cloud storage to respond to the target device requesting test coverage feedback information and send the test coverage feedback information to the target device.

[0083] The embodiment of this device corresponds to the method embodiments shown in the above figures. This device enables the collection of test coverage without shutting down the microservice system program during testing of the microservice system program, and can collect test coverage more flexibly, conveniently and efficiently.

[0084] Based on the same inventive concept, an electronic device, a readable storage medium, and a computer program product are also provided in an embodiment of the present application. The method corresponding to the electronic device can be the method for collecting test coverage in the aforementioned embodiment, and its principle of solving the problem is similar to that of the method. The electronic device provided in an embodiment of the present application includes: at least one processor; and 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the methods and / or technical solutions of the aforementioned multiple embodiments of the present application.

[0085] An electronic device can be a user device, or a device formed by integrating a user device and a network device via a network, or an application running on any of the above devices. User devices include, but are not limited to, computers, mobile phones, tablets, smart watches, wristbands, and other terminal devices. Network devices include, but are not limited to, network hosts, single network servers, multiple network servers, or a collection of computers based on cloud computing, and can be used to implement some of the processing functions required for setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a group of loosely coupled computers forming a virtual computer.

[0086] Figure 5 The structure of an electronic device suitable for implementing the methods and / or technical solutions in the embodiments of the present application is shown. The electronic device 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 502 or programs loaded from a storage unit 508 into a random access memory (RAM) 503. RAM 503 also stores various programs and data required for system operation. CPU 501, ROM 502, and RAM 503 are interconnected via a bus 505. An input / output (I / O) interface 504 is also connected to bus 505.

[0087] The following components are connected to the I / O interface 504: an input section 506 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, and the like; an output section 507 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, and the like, as well as speakers; a storage section 508 including one or more computer-readable media such as a hard disk, an optical disk, a magnetic disk, and a semiconductor memory; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 509 performs communication processing via a network such as the Internet.

[0088] In particular, the methods and / or embodiments of the present application can be implemented as computer software programs. For example, the embodiments disclosed herein include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the method illustrated in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, the aforementioned functions defined in the method of the present application are performed.

[0089] Another embodiment of the present application further provides a computer-readable storage medium and a computer program product, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of the present application.

[0090] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may, for example, be a system, device, or component including, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device.

[0091] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0092] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0093] The computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0094] The flow chart or block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the equipment, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code include one or more executable instructions for realizing the logical function of the specification. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs the function or operation of the specification, or can be implemented with a combination of dedicated hardware and computer instructions.

[0095] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0096] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules and units is only a logical function division. There may be other division methods in actual implementation. For example, with units as an example, for example, multiple units or page components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0097] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, the functional modules and units in the various embodiments of the present application may be integrated into a single processing module or unit, or each module or unit may exist physically separately, or two or more units may be integrated into a single module or unit. The aforementioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional modules or units.

[0099] The above-mentioned integrated modules and units implemented in the form of software functional modules and units can be stored in a computer-readable storage medium. The above-mentioned software functional modules and units are stored in a storage medium and include a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform some steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: USB flash drives, mobile hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media that can store program code.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0101] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. Terms such as "first" and "second" are used to indicate names and do not imply any particular order.

Claims

1. A method for collecting test coverage, comprising: Generate a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect test coverage information generated by the microservice system program when the test script is tested; In response to receiving a test coverage provision request for the target microservice system program sent by the target device during the process of testing the target microservice system program using the test script, reading the test coverage information collected by the coverage collection tool by calling the custom access interface; The test coverage information is parsed to generate test coverage feedback information for feeding back to the target device.

2. The method according to claim 1, wherein: The microservice system program runs in a Golang environment, and the generation of a custom access interface for the coverage collection tool includes: A Cover / Dump interface is generated in a main test file including the coverage acquisition tool, wherein the Cover / Dump interface is a custom access interface for the coverage acquisition tool, and the coverage acquisition tool is provided by a test toolkit of the Golang environment.

3. The method according to claim 2, wherein: The calling of the custom access interface to read the test coverage information collected by the coverage collection tool includes: Using a parsing tool encapsulated in the custom access interface to read the test coverage information collected by the Cover / Dump interface; and parsing the test coverage information to generate test coverage feedback information for feeding back to the target device, including: The parsing tool is used to process the test coverage information into test coverage feedback information in a target format for feeding back to the target device.

4. The method according to claim 1, wherein The microservice system program runs in a Java environment, and the generation of a custom access interface for the coverage collection tool includes: Adding a JaCoCo agent as a coverage collection tool to the business container used to test the microservice system program; The startup instruction of the business container is modified to add a Java agent for the JaCoCo agent, wherein the Java agent is a custom access interface for the coverage collection tool.

5. The method according to claim 4, wherein The calling of the custom access interface to read the test coverage information collected by the coverage collection tool includes: The JaCoCo agent is called by the Java agent using Jacococli to read the test coverage information collected by the JaCoCo agent.

6. The method according to claim 1, wherein The response to receiving a test coverage provision request for the target microservice system program sent by the target device during the process of testing the target microservice system program using the test script, reading the test coverage information collected by the coverage collection tool by calling the custom access interface includes: In response to receiving a test coverage provision request sent by a target device during the process of testing the target microservice system program using the test script, obtaining at least one of the following descriptive information included in the test coverage provision request: a running address of the microservice system, custom access interface description information, and environment information; In response to the description information matching the control system information of the target microservice system program, the test coverage information collected by the coverage collection tool is read by calling the custom access interface.

7. The method according to any one of claims 1 to 6, further comprising: Providing the test coverage feedback information to cloud storage; The cloud storage is controlled to send the test coverage feedback information to the target device in response to the target device requesting the test coverage feedback information.

8. A device for collecting test coverage, comprising: An access interface generation module is configured to generate a custom access interface for a coverage collection tool, wherein the coverage collection tool is used to collect test coverage information generated by the microservice system program when the test script is tested; a coverage information reading module configured to, in response to receiving a test coverage provision request for the target microservice system program sent by the target device during the process of testing the target microservice system program using the test script, read the test coverage information collected by the coverage collection tool by calling the custom access interface; The feedback information generating module is configured to parse the test coverage information and generate test coverage feedback information for feeding back to the target device.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

10. A computer-readable medium, characterized in that Computer program instructions are stored thereon, and the computer program instructions can be executed by a processor to implement the method according to any one of claims 1 to 7.

11. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images