CN115269418A

CN115269418A - Coverage rate acquisition method, device, equipment and storage medium

Info

Publication number: CN115269418A
Application number: CN202210921985.6A
Authority: CN
Inventors: 韩照光; 王雪怡; 王亚楠; 石雪岩
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2022-08-02
Filing date: 2022-08-02
Publication date: 2022-11-01

Abstract

The disclosure provides a coverage rate acquisition method, a coverage rate acquisition device, coverage rate acquisition equipment and a storage medium, and relates to the technical field of computers, in particular to the technical field of software testing. The specific implementation scheme is as follows: determining an increment code and determining test submission information of the increment code; performing instrumentation on the incremental code and pre-burying the test submission information to obtain a preprocessed code; compiling the preprocessing codes and executing the test to generate pile data corresponding to the test submission information of the incremental codes, wherein the pile data represents the coverage rate parameters of the incremental codes. The method and the device only carry out instrumentation on the incremental codes, reduce the data volume of the instrumented codes and further reduce the compiling time, and because the test submission information of the incremental codes is pre-embedded while the instrumentation is carried out, testers do not need to manually input information in a plug-in mode. And the whole testing process supports real machine testing, namely, the coverage rate collection is supported on the real machine through plug-in removal. The usability and the timeliness of the acquisition coverage rate are improved.

Description

Coverage rate acquisition method, device, equipment and storage medium

Technical Field

The present disclosure relates to the field of computer technology, and more particularly, to the field of software testing technology.

Background

In recent years, with the rapid development of business platforms, research related to front-end testing of business platforms has received more and more attention, and among them, coverage testing of front-end JS (JavaScript) codes is crucial.

Disclosure of Invention

The disclosure provides a coverage rate acquisition method, a coverage rate acquisition device, a coverage rate acquisition equipment and a storage medium.

According to an aspect of the present disclosure, there is provided a coverage acquisition method, including:

determining an incremental code and determining test submission information of the incremental code;

performing pile inserting on the incremental code and pre-burying the test submission information to obtain a preprocessing code;

compiling the preprocessing code and executing a test to generate pile data corresponding to test submission information of the incremental code, wherein the pile data represent coverage rate parameters of the incremental code.

According to an aspect of the present disclosure, there is provided a coverage acquisition apparatus including:

the determining module is used for determining the incremental code and determining the test submission information of the incremental code;

the preprocessing module is used for performing pile inserting on the incremental codes and pre-embedding the test submission information to obtain preprocessed codes;

and the test module is used for compiling the preprocessing codes and executing tests to generate pile data corresponding to the test submission information of the incremental codes, wherein the pile data represents the coverage rate parameters of the incremental codes.

According to another aspect of the present disclosure, there is provided an electronic device including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform any of the methods described above.

According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform any of the methods described above.

According to another aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements any of the methods described above.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

fig. 1 is a schematic flow chart of a coverage rate acquisition method according to an embodiment of the present disclosure;

FIG. 2 is a schematic diagram of determining a delta code in an embodiment of the present disclosure;

fig. 3 is another schematic flow chart of a coverage rate acquisition method provided in the embodiment of the present disclosure;

FIG. 4 (a) is a schematic diagram of prior art upload pile data; FIG. 4 (b) is a schematic diagram of uploading pile data in an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a prior art coverage acquisition method;

fig. 6 is a schematic diagram of a coverage rate acquisition method provided by an embodiment of the present disclosure;

FIG. 7 is a block diagram of an apparatus for implementing the coverage acquisition method of an embodiment of the present disclosure;

fig. 8 is a block diagram of an electronic device for implementing a coverage acquisition method of an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

At present, for the front-end JS coverage acquisition, the following solutions are generally adopted: and (3) inserting piles and executing a test aiming at the code to be tested, collecting pile data during the test, and uploading the pile data to a server by a tester after the test is finished so as to generate a coverage rate report.

However, with the above solution, there are several disadvantages:

1) Due to the fact that pile inserting is conducted on the full-amount codes to be detected, pile inserting codes are more, compiling time is longer, timeliness is poor, the data volume of the collected pile data is larger, and stability in the data transmission process is poor.

2) In the testing process, a tester needs to manually input a large amount of information through a plug-in, such as the branch name and the module name of a code to be tested, so that the labor cost is high, and the usability is poor.

3) The current front-end test comprises two types of pages facing a B end and a C end, wherein the page facing the B end means that: directly opening a code to be tested in a browser for testing, wherein the C-end-oriented page means that: and (3) performing function and compatibility related tests on the browser and a real machine (such as a mobile phone) aiming at the code to be tested. For the two front-end test types, in the prior art, when a test needs to be performed by means of a plug-in mode, coverage rate collection on a real machine cannot be supported.

In order to solve the above technical problem, the present disclosure provides a coverage rate acquisition method, including:

compiling the preprocessing code and executing a test to generate stub data corresponding to the test submission information of the incremental code, wherein the stub data represents a coverage parameter of the incremental code.

Therefore, in the embodiment of the disclosure, only the incremental code is instrumented, so that the data volume of the instrumented code is reduced, the compiling time is further shortened, the data volume of the generated pile data is reduced, and the stability in the pile data transmission process is improved; in addition, because the test submission information of the incremental code is pre-embedded while the pile is inserted, a tester does not need to manually input information in a plug-in mode, and the labor cost is reduced. And the whole testing process supports real machine testing, namely, the coverage rate collection is supported on the real machine through plug-in removal. Therefore, the usability and the timeliness of the acquisition coverage rate are improved.

The coverage rate acquisition method provided by the embodiment of the disclosure is described in detail below.

Referring to fig. 1, fig. 1 is a schematic flow chart of a coverage rate acquisition method provided in an embodiment of the present disclosure, and as shown in fig. 1, the method may include the following steps:

s101: determining the incremental code and determining test submission information for the incremental code.

In the embodiment of the disclosure, the code to be tested may be compared with the reference code to determine the incremental code. Wherein the reference code may be a code that has completed the test.

Specifically, referring to fig. 2, fig. 2 is a schematic diagram of determining an incremental code in the embodiment of the present disclosure. And determining the code to be detected and the reference code, and then identifying the newly added code of the code to be detected compared with the reference code as an incremental code.

As an example, a programmer adds a functional module to a certain branch of the reference code, and the newly added code corresponding to the functional module is the incremental code.

In the disclosed embodiment, after the incremental code is determined, test submission information of the incremental code is determined. The test submission information is information to be submitted in the test process, and the information is used for identifying the affiliation of the incremental code in the whole project, such as the affiliated branch, module and the like.

Specifically, in the testing process, information of a branch, a module and the like to which the incremental code belongs needs to be determined, otherwise, even if pile data corresponding to the incremental code is obtained, which branch and module the pile data corresponds to cannot be determined, and then a correct coverage rate report cannot be generated according to the pile data.

S102: and (4) performing instrumentation on the incremental code and pre-burying test submission information to obtain a preprocessing code.

In the description of the embodiments of the present disclosure, the technical term "instrumentation", also called "program instrumentation", refers to inserting "probe code" into a program on the basis of ensuring the original logic integrity of the program under test, and may also be called instrumentation code. Program operation characteristic data are obtained through execution of probe codes, and through analysis of the characteristic data, control flow and data flow of a program are obtained, and then coverage rate information is obtained. The probe code is essentially a code segment for information acquisition, and can be a value assignment statement or a function call for acquiring coverage information.

In the embodiment of the present disclosure, instrumentation is performed only for incremental codes, i.e., precise instrumentation. Specifically, a "probe code" set for the incremental code is inserted in the source code.

In addition, the test submission information of the incremental code is pre-embedded in the source code, that is, the obtained test submission information of the incremental code is automatically inserted into a specific position in the source code in a mode of presetting a function, and the specific position can be called a code segment.

As an example, a code segment is set before the incremental code, so that test submission information is automatically inserted into the code segment before the incremental code by a preset function, and the test submission information is read from the code segment during the test. Of course, the embodiment of the present disclosure does not limit the position of the code segment in the source code.

S103: the pre-processed code is compiled and a test is performed, producing stub data corresponding to the test submission information of the incremental code.

In the embodiment of the disclosure, after test submission information of the accurate instrumentation and embedded incremental codes, the test can be executed, that is, compiling is performed first, and then the compiled codes are run in a test environment, so that the instrumentation data is generated.

Those skilled in the art will understand that the stub data generated by the test process may characterize the coverage parameter of the code, and may include multiple types of coverage, which may include, for example, conditional coverage, method coverage, statement coverage, and the like, and the meaning of each type of coverage may be specifically referred to below.

Because the test submission information of the incremental code is pre-embedded, the test submission information of the incremental code can be automatically read from the code segment in the test process, so that a user does not need to manually input information required by the test through a plug-in.

In the embodiment of the present disclosure, because instrumentation is performed only on the incremental code, the instrumentation data generated by the test process is also for the incremental code and is instrumentation data corresponding to the test submission information of the incremental code.

As an example, the test submission information includes a branch name of the incremental code, and the test generated data includes stub data of the incremental code under the branch, such as method coverage, statement coverage, and the like of the incremental code under the branch.

As another example, the test submission information includes a module name of the incremental code, and the data generated by the test includes stub data of the incremental code under the module, such as method coverage, statement coverage, etc. of the incremental code under the module.

In one embodiment of the present disclosure, the test submission information includes: the branch name of the branch to which the incremental code belongs, the module name of the module to which the incremental code belongs and/or code submission information of the preset type of the incremental code.

Specifically, in order to identify the relationship of the incremental code in the whole project, the test submission information may include the branch name of the branch to which the incremental code belongs and the module name of the module to which the incremental code belongs.

In addition, after the code is added, the programmer additionally adds commit (code submission information) of the newly added code, where the commit may include multiple types of information.

Therefore, in the embodiment of the present disclosure, before the test is performed, the pre-embedded test submission information may include a branch name and a module name of the incremental code and preset type code submission information, where the information can identify a dependency relationship of the code to be tested in the whole project, and after the stub data is generated, the branch or the module corresponding to the stub data can be accurately identified. Because the information is pre-buried before testing, manual input in a plug-in mode is not needed, plug-in removal is achieved, labor cost is reduced, and silent collection without manual intervention is achieved.

In an embodiment of the present disclosure, referring to fig. 3, fig. 3 is another schematic flow chart of a coverage rate acquiring method provided in the embodiment of the present disclosure, and on the basis shown in fig. 1, after step S103, the method further includes the following steps:

s104: the stub data is uploaded to a server such that the server generates a coverage report from the stub data.

Specifically, although the stake data can represent the coverage rate parameter, the stake data is often complicated and has poor readability, and therefore, the stake data needs to be integrated.

Therefore, the client sends the stake data to the server, integrates and processes the stake data by means of the strong data processing capacity of the server, and then generates a coverage rate report with stronger readability.

In one embodiment of the present disclosure, after generating stub data corresponding to the test submission information of the incremental code, the method further includes:

under the triggering of a preset timer, filtering the generated pile data;

correspondingly, the step of uploading the stub data to the server may specifically include:

judging whether the filtered pile data is incremental pile data or not, and if so, uploading the incremental pile data to a server; if not, returning to the step of filtering the generated pile data under the next triggering of the timer.

Specifically, in the embodiment of the present disclosure, a timer for triggering to filter pile data may be set, and under the triggering of the timer, the generated pile data is filtered, so as to avoid uploading invalid pile data, reduce the uploading amount of the pile data, and determine whether the filtered pile data is incremental pile data, if so, upload the pile data, otherwise not upload the pile data.

Therefore, in the embodiment of the disclosure, invalid pile data is screened out by filtering the pile data to obtain incremental pile data, and only the incremental pile data is uploaded, so that the uploading of the pile data is reduced, and the stability in the pile data transmission process is improved. And the operation is executed under the trigger of the timer, manual intervention is not needed, the generation, the filtration and the uploading of the pile data and the generation of the coverage rate report are automatically completed, and the method is very efficient and convenient. Compared with the mode of uploading pile data by using plug-ins in the prior art, the method reduces the labor cost and realizes silent collection without manual intervention.

In one embodiment of the present disclosure, the stub data may include: statement pile data, branch pile data, method pile data, and/or condition pile data.

Accordingly, the step of filtering the generated stub data may comprise:

and filtering the pile data based on a preset filtering rule, and screening out target type pile data.

Correspondingly, the step of judging whether the filtered pile data is incremental pile data comprises the following steps:

and comparing the screened target type pile data with historically stored target type pile data, and if the screened target type pile data is different from any historically stored target type pile data, determining the filtered pile data as incremental pile data.

Specifically, the type of the pile data is briefly described first.

The statement pile data is pile data used for representing statement coverage, wherein the statement coverage is also called row coverage and refers to the proportion of executed statements in executable statements.

The branch stub data is stub data representing branch coverage, which is also called decision coverage, for measuring whether each decided branch in the program is executed.

Method pile data is pile data used to represent method coverage, which measures the proportion of a method (function) in a program that is executed.

The condition stub data is stub data representing a condition coverage rate for measuring a ratio of executed conditions in the program to executable conditions.

In embodiments of the present disclosure, preset filtering rules may be used to filter particular types of stub data.

As an example, if the current test requirement emphasizes the execution of functions in the test code, then the filtering rules may be set as: the method pile data is screened out and used as target type pile data, namely, other types of pile data are filtered out and do not need to be uploaded to a server.

In addition, in the embodiment of the present disclosure, the filtering operation is triggered under a timer, that is, the pile data is filtered once at intervals, however, the pile data may not be updated in this period, so to determine the incremental pile data, the screened target type pile data may be compared with the historically stored target type pile data, and if the screened target type pile data is different from any historically stored target type pile data, the filtered pile data is determined to be the incremental pile data.

Correspondingly, if the screened target type pile data is different from any historically stored target type pile data, the screened target type pile data is acquired and does not belong to incremental pile data, and therefore uploading is not performed.

As an example, reference may be made to fig. 4 (a) and 4 (b), where fig. 4 (a) is a schematic diagram of uploading stub data in the prior art, and fig. 4 (b) is a schematic diagram of uploading stub data in the embodiment of the present disclosure.

It is obvious that in the prior art, the plug-in unit needs to be clicked to upload pile data, the whole quantity of pile data is uploaded, and the pile data is not filtered, so that the data quantity is large, the timeliness is poor, and the pile data is easy to lose.

For example, in the test process, there may be a situation where a page route is changed, which may cause pile data information to be emptied, and if an operator does not have time to upload pile data, pile data may be lost, which may cause insufficiency of the acquired coverage rate information.

Referring to fig. 4 (b), in the embodiment of the present disclosure, in the non-test operation, there is no incremental code, and the uploading of stub data is not performed. Under the test operation, determining an increment code, further determining all pile data corresponding to the increment code, then under the trigger of a timer, filtering the pile data based on a preset filtering rule to obtain target type pile data, then performing historical comparison to obtain the increment pile data, and only uploading the increment pile data.

Therefore, in the embodiment of the disclosure, the incremental pile data which are really required to be uploaded to the server are screened out by filtering and comparing the pile data, so that the transmission and frequency of the uploaded data are reduced, and the stability is further improved.

And because the operation of filtering, uploading under the trigger of timer, can guarantee that stake data in time uploads to the server, avoid artificial reason to cause stake data loss, further improve stability.

In the prior art, when a large amount of pile data are uploaded to a server for processing, tasks are accumulated, and timeliness is poor.

In order to further improve the timeliness of generating the coverage rate report, in the embodiment of the present disclosure, the server may send the received stub data to the distributed containers for processing, and receive the coverage rate report returned by each container.

As an example, the server receives 5 batches of pile data, and needs to generate coverage reports based on the pile data, respectively, then distributed dynamic resources may be created for the 5 batches of pile data, and the 5 tasks are issued to the dynamic resources, respectively, so as to implement distributed parallel processing.

Therefore, the tasks are issued to the distributed containers for processing, centralization can be achieved, parallel processing of the tasks is achieved, the concurrence amount which can be supported by the tasks is increased, and timeliness of generating coverage rate reports is greatly improved.

For ease of understanding, the improvement point of the embodiment of the present disclosure with respect to the prior art will be further described below with reference to fig. 5 and 6.

First, a coverage rate acquisition method in the prior art is described with reference to fig. 5, and fig. 5 is a schematic diagram of the coverage rate acquisition method in the prior art.

Referring to S501-S509 in fig. 5, in the prior art, in the testing process, a source code is obtained, instrumentation processing is performed on the source code, compiling and packaging are performed, a test environment is created, a test is executed, stub data is obtained, the stub data is uploaded to a server, an incremental code is determined, and a coverage report for the incremental code is generated.

Next, a coverage rate acquisition method provided by the embodiment of the present disclosure is described with reference to fig. 6, and fig. 6 is a schematic diagram of the coverage rate acquisition method provided by the embodiment of the present disclosure.

Referring to S600-S610 in fig. 6, in the test process, in the embodiment of the present disclosure, a source code is determined, an incremental code is further determined, test submission information is pre-embedded for the incremental code, accurate instrumentation processing is performed, then compiling and packaging are performed, a test environment is created, a test is executed, after stub data is obtained, filtering and comparing the stub data is automatically performed under the trigger of a timer, only the incremental stub data is uploaded to a server, and a coverage report is generated in a distributed manner by decentralization in the server.

Therefore, in the embodiment of the disclosure, the coverage collection capability of the B-end page and the C-end page on the browser and the real machine is realized by constructing and transforming the accurate capability of the JS coverage front end, and the execution efficiency, the usability and the timeliness are improved while the coverage collection is ensured.

Through actual measurement and calculation, the compiling time is shortened by 50%, the output increment coverage rate report is improved from the original 10min to the current 30s, and the effect is improved by 90%.

And moreover, the usability is strong, the coverage rate report is generated from the pile insertion, the user is not sensed in the whole process, manual intervention is not needed, and silent acquisition is realized.

Referring to fig. 7, fig. 7 is a block diagram of an apparatus for implementing a coverage rate acquisition method according to an embodiment of the present disclosure, including the following modules:

a determining module 701, configured to determine an incremental code and determine test submission information of the incremental code;

a preprocessing module 702, configured to perform instrumentation on the incremental code and embed the test submission information to obtain a preprocessed code;

a testing module 703, configured to compile and execute a test on the preprocessed code, and generate stub data corresponding to the test submission information of the incremental code, where the stub data represents a coverage parameter of the incremental code.

Therefore, in the embodiment of the disclosure, only the incremental code is instrumented, so that the data volume of the instrumented code is reduced, the compiling time is further shortened, the data volume of the generated pile data is reduced, and the stability in the pile data transmission process is improved; in addition, because the test submission information of the incremental code is pre-embedded while the pile is inserted, a tester does not need to manually input information in a plug-in mode, and the labor cost is reduced. And through the plug-in removal, the whole testing process supports real machine testing, namely, the coverage rate collection is supported on the real machine. Therefore, the usability and the timeliness of the acquisition coverage rate are improved.

In an embodiment of the present disclosure, the test submission information includes: the code submitting information comprises the branch name of the branch to which the incremental code belongs, the module name of the module to which the incremental code belongs and/or the preset type of the incremental code.

In an embodiment of the present disclosure, on the basis of the apparatus shown in fig. 7, the apparatus further includes:

and the uploading module is used for uploading the pile data to a server so that the server generates a coverage rate report according to the pile data.

the filtering module is used for filtering the generated pile data under the triggering of a preset timer;

the upload module comprises: a judgment sub-module and an uploading sub-module;

the judgment submodule is used for:

judging whether the filtered pile data is incremental pile data or not;

the upload sub-module is configured to:

if the judgment result of the judgment submodule is yes, uploading the incremental pile data to a server; and if the judgment result of the judgment submodule is negative, triggering the filtering module under the next triggering of the timer.

In one embodiment of the present disclosure, the stub data includes statement stub data, branch stub data, method stub data, and/or condition stub data;

the filtering module is specifically configured to:

filtering the pile data based on a preset filtering rule, and screening out target type pile data;

the judgment submodule is specifically configured to:

And, owing to filter, upload the operation under the trigger of timer, can guarantee that stake data in time uploads to the server, avoid artificial reason to cause stake data loss, further improve stability.

In the technical scheme of the disclosure, the collection, storage, use, processing, transmission, provision, disclosure and other processing of the personal information of the related user are all in accordance with the regulations of related laws and regulations and do not violate the good customs of the public order.

The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.

The present disclosure provides an electronic device, including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a coverage acquisition method.

The present disclosure provides a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to execute a coverage acquisition method.

The present disclosure provides a computer program product comprising a computer program which, when executed by a processor, implements a coverage acquisition method.

FIG. 8 illustrates a schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 8, the apparatus 800 includes a computing unit 801 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 802 or a computer program loaded from a storage unit 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the device 800 can also be stored. The calculation unit 801, the ROM 802, and the RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.

A number of components in the device 800 are connected to the I/O interface 805, including: an input unit 806, such as a keyboard, a mouse, or the like; an output unit 807 such as various types of displays, speakers, and the like; a storage unit 808, such as a magnetic disk, optical disk, or the like; and a communication unit 809 such as a network card, modem, wireless communication transceiver, etc. The communication unit 809 allows the device 800 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.

Computing unit 801 may be a variety of general and/or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The calculation unit 801 performs the various methods and processes described above, such as the coverage acquisition method. For example, in some embodiments, the coverage acquisition method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and/or installed onto device 800 via ROM 802 and/or communications unit 809. When loaded into RAM 803 and executed by the computing unit 801, a computer program may perform one or more steps of the coverage acquisition method described above. Alternatively, in other embodiments, the computing unit 801 may be configured to perform the coverage acquisition method by any other suitable means (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), complex Programmable Logic Devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, 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 compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a 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 may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server with a combined blockchain.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel or sequentially or in different orders, and are not limited herein as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved.

The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A coverage acquisition method, comprising:

2. The method of claim 1, wherein the test submission information includes: the branch name of the branch to which the incremental code belongs, the module name of the module to which the incremental code belongs and/or code submission information of a preset type of the incremental code.

3. The method of claim 1, further comprising:

and uploading the stake data to a server so that the server generates a coverage rate report according to the stake data.

4. The method of claim 3, after generating stub data corresponding to test submission information for the incremental code, further comprising:

under the triggering of a preset timer, filtering the generated pile data;

the step of uploading the stub data to a server includes:

judging whether the filtered pile data is incremental pile data or not, and if so, uploading the incremental pile data to a server; if not, returning to the step of filtering the generated pile data under the next trigger of the timer.

5. The method of claim 4, wherein the stub data comprises statement stub data, branch stub data, method stub data, and/or condition stub data; the step of filtering the generated pilar data includes:

the step of judging whether the filtered pile data is incremental pile data comprises the following steps:

and comparing the screened target type pile data with the historically stored target type pile data, and if the screened target type pile data is different from any one of the historically stored target type pile data, determining the filtered pile data as incremental pile data.

6. The method of claim 3, wherein,

and the server is used for sending the received pile data to distributed containers for processing and receiving coverage rate reports returned by the containers.

7. A coverage acquisition device comprising:

the preprocessing module is used for inserting piles into the incremental codes and pre-embedding the test submission information to obtain preprocessed codes;

8. The apparatus of claim 7, wherein the test submission information comprises: the branch name of the branch to which the incremental code belongs, the module name of the module to which the incremental code belongs and/or code submission information of a preset type of the incremental code.

9. The apparatus of claim 7, further comprising:

10. The apparatus of claim 9, further comprising:

the upload module comprises: the judgment submodule and the uploading submodule;

the judgment submodule is used for:

judging whether the filtered pile data is incremental pile data or not;

the upload sub-module is configured to:

if the judgment result of the judgment submodule is yes, uploading the incremental pile data to a server; if the judgment result of the judgment submodule is negative, the filtering module is triggered under the next triggering of the timer.

11. The apparatus of claim 10, wherein the stub data comprises statement stub data, branch stub data, method stub data, and/or condition stub data;

the filtering module is specifically configured to:

the judgment submodule is specifically configured to:

12. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

13. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-6.

14. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-6.