CN112699011A

CN112699011A - Method and device for counting incremental code coverage rate, electronic equipment and storage medium

Info

Publication number: CN112699011A
Application number: CN201911011651.XA
Authority: CN
Inventors: 王伯龙; 田星星
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2019-10-23
Filing date: 2019-10-23
Publication date: 2021-04-23

Abstract

The application provides a method and a device for counting incremental code coverage rate, electronic equipment and a storage medium, which relate to the technical field of computers, and the method comprises the following steps: comparing the main branch with the file of the branch to be tested, determining the file of the branch to be tested, which is changed relative to the main branch, wherein the changed file comprises a newly added file and/or a modified file, and determining the method name of a changing method aiming at the changed file, wherein the changing method comprises the newly added method and/or the modified method, the method name of the changing method is used as a parameter of a probe instrumentation method, and the instrumentation test is carried out on the changing method to obtain the coverage rate of the incremental code. By the method, which codes are newly added codes can be visually distinguished, and the coverage rate of the incremental codes is obtained.

Description

Method and device for counting incremental code coverage rate, electronic equipment and storage medium

Technical Field

The invention relates to the technical field of computers, in particular to a method and a device for counting incremental code coverage rate, electronic equipment and a storage medium.

Background

In the software testing process, the total code coverage rate can be used as a standard for measuring the test coverage degree, and refers to the ratio of codes operated by a program to the total codes. However, there are some problems, for example, in the case of a historical code missing single test, the full-scale statistics cannot be performed according to the code access control with the standard coverage rate, and it is impossible to visually distinguish which codes are newly added codes in the statistical report, which results in that it is extremely tedious to query the coverage condition of the iteration single test.

Disclosure of Invention

The application provides a method, a device and electronic equipment for counting the coverage rate of incremental codes, which are used for visually distinguishing whether the codes are the newly added codes, so that the covering loss positioning speed and accuracy are increased, and the working efficiency is improved.

According to a first aspect of embodiments of the present application, there is provided a method for counting incremental code coverage, including:

comparing the main branch with the files of the branches to be tested, and determining the files of the branches to be tested, which are changed relative to the main branch, wherein the changed files comprise newly added files and/or modified files;

determining a method name of a changed method for the changed file; wherein, the changed method comprises a new method and/or a modified method;

and taking the method name of the changed method as the parameter of the probe instrumentation method, and performing instrumentation test on the changed method to obtain the incremental code coverage rate.

Optionally, determining a method name of the changed method for the changed file includes:

if the changed file comprises a newly added file, adding a method name included in the newly added file into a newly added method list;

if the changed file comprises a modified file, analyzing the method name in the main branch as a reference method name;

aiming at the method name to be compared analyzed from the modified file, executing the following steps:

if the name of the method to be compared is not in the name of the reference method, adding the name of the method to be compared to the new method list;

if the method name of the to-be-compared party is in the reference method name, comparing the code content of the to-be-compared method name with the code content of the reference method name with the same name;

and if the code content of the method name to be compared is different from that of the reference method name with the same name, adding the method name to be compared to the newly added method list.

Optionally, the comparing the name of the method to be compared with the code content of the name of the reference method with the same name includes:

comparing the code line number of the method name to be compared with the reference method name with the same name;

if the code line numbers are different, adding the name of the method to be compared to the newly added method list;

if the number of code lines is the same, checking character strings of the method name of the comparison to be made and the reference method name of the same name;

and if the check result shows that the character strings are different and the character string of the name of the method to be compared does not contain a code representing the test type annotation, adding the name of the method to be compared to the newly added method list.

Optionally, the list of the newly added methods is used as a method for inserting the probe into the pile.

Optionally, before determining the method name of the changed method for the changed file, the method further includes:

filtering out specified files in the changed files, wherein the specified files comprise at least one of the following files: configuration files, automatically generated code files, and test files.

parsing the changed file to a method dimension; and

removing annotations in the changed file.

Optionally, before comparing the files of the main branch and the branch to be tested, the method further includes:

displaying a management interface; the management interface comprises options for program branches;

in response to a user-selected operation instruction for the program branch, a main branch and the branch to be tested are determined.

According to a second aspect of the embodiments of the present application, there is provided an apparatus for counting incremental code coverage, including:

the first determining module is configured to compare the main branch with a file of a branch to be tested and determine a file of the branch to be tested, which is changed relative to the main branch, wherein the changed file comprises a newly added file and/or a modified file;

a second determination module configured to perform determining a method name of the changed method for the changed file; wherein, the changed method comprises a new method and/or a modified method;

and the statistical module is configured to execute the method name of the changed method as a parameter of the probe instrumentation method, and instrumentation test is carried out on the changed method to obtain the incremental code coverage rate.

Optionally, the second determining module is configured to perform:

Optionally, the method further includes:

a filtering module configured to perform filtering out a specified file of the changed files before the second determining module determines the method name of the changed method for the changed files, the specified file including at least one of: configuration files, automatically generated code files, and test files.

Optionally, the apparatus further comprises:

a parsing module configured to perform parsing of the changed file into a method dimension before the second determining module determines, for the changed file, a method name of a changed method; and

removing annotations in the changed file.

Optionally, the apparatus further comprises:

a selection module configured to execute a display management interface; the management interface comprises options for program branches;

in response to a user-selected operation instruction for the program branch, the main branch and the branch to be tested are determined.

According to a third aspect of embodiments of the present application, there is provided an electronic apparatus, 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 the method of the first aspect.

According to a fourth aspect of embodiments herein, there is provided a computer storage medium having stored thereon computer-executable instructions for performing the method of the first aspect.

The technical scheme provided by the embodiment of the application at least has the following beneficial effects:

through the embodiment of the application, newly added files and/or modified files of the to-be-tested branch relative to the main branch can be distinguished. And further analyzing the branches to be tested and the main branches to the method dimension, and accurately finding out a new method and/or a modified method, thereby obtaining the method to be tested. Incremental code coverage reports are obtained from method dimension implementation statistics by naming the method requiring testing as the entry to the method owning probe instrumentation for testing.

In addition, through the main branch and the branch to be tested, developers can only pay attention to the newly added method code, namely the incremental code, and do not need to carry out error positioning through a full code coverage rate statistical report, so that the working accuracy rate and the working efficiency can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application and are not to be construed as limiting the application.

Fig. 1 is a schematic flowchart of a method for counting incremental code coverage according to an embodiment of the present disclosure;

FIG. 2 is a management interface of a method for counting incremental code coverage according to an embodiment of the present disclosure;

fig. 3 is a schematic flowchart of a method for counting incremental code coverage according to an embodiment of the present disclosure;

fig. 4 is a schematic flowchart of generating a list of new methods according to an embodiment of the present application;

FIG. 5 is a block diagram illustrating an implementation module of a method for counting incremental code coverage in an embodiment of the present application;

fig. 6 is a schematic structural diagram of an apparatus for counting incremental code coverage according to an embodiment of the present disclosure;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present application better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that "and/or" in the specification and claims of the present application and the above drawings describes an association relationship of associated objects, and indicates that three relationships may exist, for example, a and/or B may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.

The method for counting the coverage rate of the incremental code is provided by the application, aiming at the problems that the code is continuously updated in an iterative manner, and the coverage condition of the iterative single test is very complicated when the related technology is inquired.

In the method, a file of a main branch is compared with a file of a branch to be tested, a file which is changed relative to the main branch in the branch to be tested is found out, then a changing method is found out according to the changed file and is added into a new method list, finally the new method is tested based on the new method list, and an obtained test report is a test report based on an incremental code, so that the coverage rate of the incremental code can be conveniently obtained.

The foregoing solution is described with reference to fig. 1, and provides a schematic flow chart of a method for counting incremental code coverage according to the present application, including the following steps:

step 101: and comparing the main branch with the files of the branches to be tested, and determining the files of the branches to be tested, which are changed relative to the main branch, wherein the changed files comprise newly added files and/or modified files.

In one embodiment, before comparing the files of the main branch and the branch to be tested, the client may first provide a management interface, which may be operated by the developer, so that the developer may autonomously select an application of interest and the branch of the application to be tested. Therefore, through the management interface, developers can only care about the branch of the newly added codes as the branch to be tested, and personalized selection of the developers is realized. As shown in fig. 2, may be implemented as a display management interface; the management interface comprises options for application and program branches; if the application is selected in area 1 and the corresponding application branch is selected in area 2 in fig. 2, and then the developer can select the developed branch based on the management interface, the client can determine the main branch and the branch to be tested in response to the user selection operation instruction for the program branch. For example, after selecting application 1 in region 1 in FIG. 2, a region is popped up that selects an optional program branch as region 2, and selects the main branch of region 2 and branch 1 to be tested. The management interface is not to be construed as the only interface for realizing the present function.

Furthermore, Shell is executed by scheduling Jenkins, the main branch of the application to be tested and the branch to be tested are pulled to the local (and the equipment where the client is located), and comparison and testing are waited. Jenkins is an open source software project, is a continuous integration tool developed based on Java, is used for monitoring continuous and repeated work, and aims to provide an open and easy-to-use software platform to enable continuous integration of software to be possible. Shell is commonly called Shell, which is used to distinguish it from core, and refers to software that provides an operation interface for users. It receives a user command and then invokes the corresponding application.

Optionally, when comparing the main branch with the branch to be tested, respective tree objects may be constructed for the files in the main branch and the branch to be tested, the difference between the two tree objects may be compared, and the difference between the work directory, the index, and the object tree of the file may also be compared. Based on the compared differences, a file of the changes of the branch to be tested relative to the main branch can be obtained.

In addition, for some designated files which are not concerned, such as configuration files, automatically generated code files and test files and the like, the designated files can be filtered after changed files are obtained so as to be convenient for testing only aiming at the service codes during testing, and unnecessary testing is reduced.

After filtering out files that are not of interest, the method to be tested can be extracted based on the changed files. For example, the subsequent step 102 may be continued to achieve this.

Step 102: determining a method name of a changed method for the changed file; wherein the changed method comprises a new method and/or a modified method.

In one embodiment, to accurately compare the files of the main branch and the branch to be tested so as to find out the method to be tested, the files of the main branch and the branch to be tested can be firstly analyzed to the dimension of the method. The scheme for analyzing the files to be selectable in method dimension may be that the Java source code is analyzed into a syntax tree, then the Java code is analyzed and modified based on the syntax tree, and the method names of all main branches are recorded through analysis of Java parser (an open source tool for analyzing the Java files, obtaining class names in the Java code, parameter names in a method profile parameter list, and the like).

In one embodiment, the annotations in the file may also be removed prior to performing step 102. The annotations in the removed file may be annotations about the code author, the version used, or other annotations. By removing the comments in the file, the accuracy of the subsequent incremental code coverage statistics can be improved.

In which, the changed files include newly added files and/or modified files as described above, and how to analyze and identify the changed files is described below:

(1) newly added file

For example, the file names of the main branch and the file to be tested may be compared with each other through a git diff (git diff is a command supported by a git system and is used to query the code differences between 2 branches, where the git system is an open-source distributed version control system, and the codes of each item are hosted on git), and if the file name of the file to be tested is found not to be included in the file name of the main branch, the file to be tested may be obtained as a new file. And then analyzing the newly added file to the method dimension, so that all method names of the file to be tested can be added into the newly added method list, and the incremental code to be tested can be maintained through the newly added list.

In the embodiment of the application, which method is the new adding method can be conveniently determined through the file type, namely the new adding file, and the complex method comparison is not needed, so that the realization logic for extracting the new adding method is simple and convenient, and the implementation is convenient.

(2) Modifying a file

The file name in the branch to be tested is included in the main branch file name through comparison and analysis of a gitdiff tool, but the file name of the modified file is obtained, and then the method name is further compared to obtain the method for changing the modified file.

All method names in the main branch can be resolved by the Javaparser tool and recorded as reference method names. In one embodiment, a list of reference method names may be maintained by Table 1 to facilitate determination of the method name of the method of modifying the change in the file via the list.

Table 1 list of reference method names

Serial number	Name of method
		1	Reference method name 1
2	Reference method name 2
		3	Reference method name 3

For ease of presentation, the method name included in the modification file will be referred to hereinafter simply as the compare method name to facilitate distinguishing the source of the method name, i.e., whether it originates from the main branch or the branch to be tested. Then, whether the method corresponding to the name of the method to be compared is the method to be tested is determined based on table 1. The method may be implemented by comparing the name of the method to be compared in the modified file of the branch to be tested with the name of the reference method of the main branch, and adding the name of the method to be compared to the new method list if the name of the method to be compared is not in the name of the reference method. Correspondingly, if the name of the method to be compared is in the name of the reference method, the code content of the name of the method to be compared and the name of the reference method with the same name are compared to further analyze whether the name of the method to be compared is a changed method. In implementation, if the code content of the name of the method to be compared is different from that of the reference method name with the same name, the name of the method to be compared is added to the new method list although the code content of the reference method name with the same name is the same.

In this embodiment, for the modified file, the modified method can be located only by comparing the names of the methods.

When the method name cannot be well determined whether the method name to be compared needs to be added into the new method list or not, the method name to be compared can be accurately and comprehensively found, so that the incremental code can be conveniently tested by writing. If the method name of the file to be tested is compared with the method name of the main branch recorded, the method content is further verified, and the method can be implemented as follows:

step A1: comparing the code line number of the method name to be compared with the reference method name with the same name;

step A2: if the code line numbers are different, adding the name of the method to be compared to the newly added method list;

step A3: if the number of code lines is the same, checking character strings of the method name of the comparison to be made and the reference method name of the same name;

step A4: and if the check result shows that the character strings are different and the character string of the name of the method to be compared does not contain a code representing the test type annotation, adding the name of the method to be compared to the newly added method list.

In one embodiment, the verification of the strings of the names of the methods to be compared and the reference method of the same name can be achieved by MD5 (message digest algorithm) verification of the strings of the entire methods; in addition to using MD5, the hash value of the method name to be compared and the reference method name of the same name may be checked.

(3) Newly added file and modified file

And (3) adding all method names in the file to the newly added method name according to the newly added file in the step (1) when the file is compared as the newly added file, and comparing the file as the modified file in the step (2) to determine the newly added method and add the newly added method to the newly added method list. And will not be described in detail herein for specific implementations.

Step 103: and taking the method name of the changed method as the parameter of the probe instrumentation method, and performing instrumentation test on the changed method to obtain the incremental code coverage rate.

Here, the method name of the changed method is the name of the new method included in the new method list in step 102, and therefore the new method list is included as a method for probe instrumentation.

By the method and the device, developers can accurately distinguish the newly added method submitted in the main branch, and the coverage rate of the incremental codes is counted according to the new method, so that the actual positioning speed and accuracy rate of the coverage are increased, and the efficiency of daily work is improved.

To better understand the specific implementation of the present application, the scheme is further described with reference to fig. 3, which includes:

step 301: a management interface is provided for selectively uploading the main branch and the branch to be tested.

It should be noted that, through the management interface, different developers can only care about the incremental code of themselves. Referring to the management interface of fig. 2, in one embodiment, the interface may be selected from an application name, a main branch, a branch to be tested 1, and a branch to be tested 2 …, a branch to be tested n. The application to be tested by the developer is accurately found according to the application name, the main branch is established in the application, the branch to be tested 1 is established by the developer 1, and the branch to be tested 2 is … established by the developer 2 and is established by the developer n. Therefore, for example, the developer 1 wants to count the incremental code coverage of itself, and only needs to select the corresponding application name, the program branch corresponding to the application name, such as the main branch, and the branch to be tested 1.

Step 302: the main branch and the branch to be tested are pulled locally.

In one embodiment, when executing Shell through Jenkins, developer 1 pulls the main branch 1 of the needed application and the branch 1 to be tested to local waiting for contrast and testing.

Step 303: a list of the files of the changes found.

In one embodiment, all files of the main branch 1 and the branch 1 to be tested are compared by a difference comparison tool such as gitdiff, a new file and/or a modified file of the branch 1 to be tested relative to the main branch 1 is found, and files which are not concerned such as a configuration file, an automatically generated code, a test file and the like are filtered out.

Step 304: and generating a new method list.

In the specific implementation of this step, refer to fig. 4, which is a flowchart of generating a new method list according to the embodiment of the present application.

Step 3041: the file names of the main branch and the branch to be tested and the name of the method after analysis.

In one implementation, the main branch 1 and the file of branch 1 to be tested are first split into method dimensions by a parsing tool such as Javaparser and the annotations in both branch files are removed and all method names in the main branch are recorded.

Step 3042: it is determined whether the file name of branch 1 to be tested is present in the file name of main branch 1.

And if not, determining the file as a newly added file, and adding all methods in the newly added file into a newly added method list. For example, if the file a in the branch to be tested is compared with the file a not found in the main branch 1, the method a1 and the method a2 … an in the file a are added to the new method list.

If yes, the file is determined to be a modified file, and step 3043 is continued.

Step 3043: it is determined whether the method name of the file in branch 1 to be tested is in the method name recorded in main branch 1.

And if the method does not exist, determining the method to be a new method, and adding the new method into a new method list. For example, the method b and the method c for modifying the file in the branch 1 to be tested do not exist in the method name recorded in the main branch 1, the method b and the method c are added to the new method list.

If yes, the method is determined to be a modified method, and step 3044 is continued.

Step 3044: and judging whether the code line numbers of the two methods are the same or not.

And if not, determining that the method is the new method, and adding the method into a new method list. For example, the branch to be tested 1 and the main branch 1 both have a method name d, but the method of the method name d in the main branch 1 includes 100 lines of code, while the method name d in the branch to be tested 1 includes 300 lines of code, and the code does not include code representing a test class annotation, so that the developer 1 can add 200 lines of code to the method. So method d is determined to be the new method and added to the list of new methods.

If yes, go to step 3045.

Step 3045: it is determined whether the character strings MD5 of the two methods are the same.

And if not, determining the method as a new method and writing the method into a new method list. For example, the branch 1 to be tested and the main branch 1 both have the method name e, and the number of code lines is the same, but different results are obtained through MD5 verification of the character string of the whole method e, and then the developer 1 can obtain that the code in the method is modified. So method e is determined to be the new method and method e is added to the new method list.

If they are the same, it is determined that the method is a method already recorded in the primary branch 1, for which the coverage is not counted anymore.

In summary, in the new method list, there are currently a method a1, a method a2 …, a method b, a method c, a method d, and a method e for the alignment of the main branch 1 and the branch 1 to be tested.

Step 305: and (5) entering the reference aiming at the newly added method list.

The new method list is obtained through step 304, and method a1, method a2 …, method name b, method name c, method name d, and method name e in the list are imported as entries. Optionally, the new methods are instrumented with probes.

Step 306: statistical delta code coverage reporting.

And generating a coverage report by using a coverage file, a source code and a compiling file in the unit test operation process to obtain an incremental code statistical result and view the incremental code statistical result.

For example, if the sum of the code line numbers of the methods in the new method list is 1000 lines, and the code to which the program runs during the test is 700 lines, the new code coverage can be calculated as 700/1000.

Fig. 5 is a functional diagram of an implementation module of a method for counting incremental code coverage in this application embodiment. The schematic diagram shows that the present application can be divided into two parts, one of which is Report Collection (Report Collection) and includes a general Coverage, and the general Coverage correspondingly implements the function of step 301, i.e. provides management of selectively uploading main branches and branches to be tested; file Manager can read the files of the main branch and the branch to be tested remotely, and corresponding to the function of step 302, the main branch and the branch to be tested are pulled to the local and the File management is performed. The optional Jenkins for realizing the part of functions are used for monitoring continuous repeated work and aiming at providing an open and easy-to-use software platform so that continuous integration of software becomes possible.

The other part is Report Show (Report collection) and contains Code Diff Manager (Code difference Manager), which can correspondingly realize the function of finding the changed file list in step 303; a Report Manager correspondingly realizes the function of generating the new method list in the step 304; diff Report may implement the functions of participating in the list of new methods in step 305 and step 306, and counting the incremental code coverage Report. Where the option of implementing this part of the complete functionality is similar to routing, which assumes the task of collecting information from different users, processing it and then distributing it to different users.

Referring to fig. 6, a schematic structural diagram of an apparatus for counting incremental code coverage in an embodiment of the present application is shown, where the apparatus includes: a first determining module 601, a second determining module 602, and a counting module 603.

A first determining module 601 configured to perform comparison between a main branch and a file of a branch to be tested, and determine a file in which the branch to be tested is changed relative to the main branch, wherein the changed file includes a newly added file and/or a modified file;

a second determining module 602 configured to execute determining, for the changed file, a method name of the changed method; wherein, the changed method comprises a new method and/or a modified method;

a statistical module 603 configured to perform a method name of the changed method as an entry parameter of the probe instrumentation method, and perform instrumentation test on the changed method to obtain incremental code coverage.

Optionally, the second determining module 602 is configured to perform:

Optionally, the method further includes:

a parsing module configured to perform parsing the altered file to a method dimension; and

removing annotations in the changed file.

Optionally, the apparatus further comprises:

Having described the method and apparatus for statistical incremental code coverage in an exemplary embodiment of the present application, an electronic device of another exemplary embodiment of the present application is described next.

As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or program product. Accordingly, various aspects of the present application may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

In some possible implementations, an electronic device according to the present application may include at least one processor, and at least one memory. Wherein the memory stores program code which, when executed by the processor, causes the processor to perform the steps in the image processing method according to various exemplary embodiments of the present application described above in the present specification. For example, the processor may perform steps 101-103 as shown in FIG. 1.

The electronic device 130 according to this embodiment of the present application is described below with reference to fig. 7. The electronic device 130 shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 7, the electronic device 130 is in the form of a general purpose computing device. The components of the electronic device 130 may include, but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 that connects the various system components (including the memory 132 and the processor 131).

Bus 133 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

The memory 132 may include readable media in the form of volatile memory, such as Random Access Memory (RAM)1321 and/or cache memory 1322, and may further include Read Only Memory (ROM) 1323.

Memory 132 may also include a program/utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

The electronic device 130 may also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), with one or more devices that enable target objects to interact with the electronic device 130, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 130 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interfaces 135. Also, computing device 130 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via network adapter 136. As shown, network adapter 136 communicates with other modules for electronic device 130 over bus 133. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

In some possible embodiments, the various aspects of the material display method provided by the present application may also be implemented in the form of a program product comprising program code for causing a computer device to perform the steps in the image processing method according to various exemplary embodiments of the present application described above in this specification when the program product is run on the computer device, for example, the computer device may perform steps 101-103 as shown in fig. 1.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product for material display of the embodiments of the present application may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a computing device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a 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.

Program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the target object computing device, partly on the target object apparatus, as a stand-alone software package, partly on the target object computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the target object electronic equipment through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to external electronic equipment (e.g., through the internet using an internet service provider).

It should be noted that although several units or sub-units of the apparatus are mentioned in the above detailed description, such division is merely exemplary and not mandatory. Indeed, the features and functions of two or more units described above may be embodied in one unit, according to embodiments of the application. Conversely, the features and functions of one unit described above may be further divided into embodiments by a plurality of units.

Further, while the operations of the methods of the present application are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in the particular order shown, or that all of the operations shown must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for counting incremental code coverage, comprising:

2. The method of claim 1, wherein determining a method name of the changed method for the changed file comprises:

3. The method of claim 2, wherein said comparing the code content of the comparison method name with the same reference method name comprises:

4. The method of claim 2, wherein the list of newly added methods is entered as a method of probe placement.

5. The method of claim 1, wherein before determining a method name of the changed method for the changed file, the method further comprises:

6. The method of claim 1, wherein before determining a method name of the changed method for the changed file, the method further comprises:

parsing the changed file to a method dimension; and

removing annotations in the changed file.

7. The method of claim 1, wherein prior to comparing the files of the main branch and the branch under test, the method further comprises:

8. An apparatus for counting incremental code coverage, comprising:

9. The apparatus of claim 8, wherein the second determining module is configured to perform:

10. The apparatus of claim 9, wherein the second determining module is configured to perform:

11. The apparatus of claim 9, wherein the list of new methods is entered as a method of probe placement.

12. The apparatus of claim 8, further comprising:

13. The apparatus of claim 8, further comprising:

removing annotations in the changed file.

14. The apparatus of claim 8, further comprising:

15. 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-7.

16. A computer storage medium having computer-executable instructions stored thereon for performing the method of any one of claims 1-7.