WO2016027992A1

WO2016027992A1 - Method for measuring code coverage and computer-readable recording medium having program for executing same recorded thereon

Info

Publication number: WO2016027992A1
Application number: PCT/KR2015/007395
Authority: WO
Inventors: 배현섭; 윤광식; 조민성; 박재현; 곽충석
Original assignee: 슈어소프트테크주식회사
Priority date: 2014-08-18
Filing date: 2015-07-16
Publication date: 2016-02-25
Also published as: KR101667262B1; KR20160021585A

Abstract

One embodiment of the present invention relates to a method for measuring code coverage. The method for measuring code coverage, according to the embodiment, comprises the steps of: inserting a probe in a source code; generating an executable file by compiling the source code having the probe inserted therein; and measuring code coverage by using the generated executable file, wherein the step of inserting the probe in the source code comprises a step of generating an abstract syntax tree from the source code, a step of generating a control flow graph by interpreting the abstract syntax tree, and a step of inserting the probe in the source code by using the abstract syntax tree and the control flow graph.

Description

Computer-readable recording medium recording method of code coverage measurement and program for executing the same

The present invention relates to a method for measuring code coverage and a computer readable recording medium having recorded thereon a program for executing the same.

Code coverage is a measure used to measure the quality of a software test.

Code coverage refers to the rate at which the source code of any one program has been tested. Thus, code coverage is generally expressed as a percentage.

In order to measure code coverage, certain code coverage measurement tools are required, typically LDRA and VectorCAST.

The present invention provides a code coverage measuring method capable of efficiently inserting a probe into a source code for which code coverage is to be measured, and a computer readable recording medium having recorded thereon a program for executing the code coverage.

In addition, the present invention, after compiling the source code for coverage measurement, code coverage measurement method that can omit the repetitive process of compiling for the source code that does not change among the entire source code to generate an executable file and this A computer readable recording medium having recorded thereon a program for execution is provided.

In addition, the present invention, after measuring the code coverage of the source code, every time a change is made to the source code, an effective code coverage measurement method that can not measure the code coverage of the entire source code again and the computer for recording the program for executing the same It provides a recording medium that can be read.

In addition, the present invention, when the code coverage test is performed on a plurality of devices in which the predetermined source code is not one device, the code coverage test collected from the plurality of devices are collected to quickly improve the code coverage of the source code. A computer readable recording medium having recorded thereon a method for measuring code coverage and a program for executing the same are provided.

The problem to be solved of the present invention is not limited to those mentioned above, other problems to be solved not mentioned will be clearly understood by those skilled in the art from the following description.

Code coverage measurement method of the source code according to the embodiment, the step of inserting a probe into the source code; Compiling the source code into which the probe is inserted to generate an executable file; And measuring the code coverage using the generated executable file, wherein inserting a probe into the source code comprises: generating an abstract syntax tree from the source code; Interpreting the abstract syntax tree to generate a control flow graph; And inserting the probe into the source code using the abstract syntax tree and the control flow graph.

A code coverage measurement method of source code according to an embodiment includes: determining whether the source code has been substantially changed; If the source code has substantially changed, measuring code coverage of the changed source code; And if the source coat has not been substantially changed, outputting an existing code coverage value.

Code coverage measurement method of the source code according to the embodiment, the server receives the code coverage logs collected from a plurality of devices to measure the code coverage, the code coverage logs received from the plurality of devices Storing in a queue in chronological order; And measuring the code coverage using the code coverage logs stored in the queue.

Using a method of measuring code coverage according to the present invention and a computer-readable recording medium having recorded thereon a program for executing the code coverage, the probe can be efficiently inserted into the source code for which the code coverage is to be measured. Therefore, the binary size of the source code into which the probe is inserted can be reduced, thereby minimizing the performance side effects of measuring the code coverage value of the source code.

In addition, after compiling the source code, the repetitive process of generating an execution file for coverage measurement for the entire source code whenever a change is made to the source code can be omitted. Therefore, since the coverage measurement preparation process may be omitted for the unchanged source code, there is an advantage of reducing the code coverage measurement preparation time of the source code.

In addition, after the code coverage measurement of the source code, even if a change is made in the source code, the coverage value of the unchanged source code part may be maintained as it is, so that the code coverage of the entire source code may not be measured again. Therefore, since the code coverage test portion does not need to be tested again, there is an advantage that the time taken to achieve a specific coverage reference value can be reduced.

In addition, when a code coverage test is performed on a plurality of devices in which a given source code is not one device, the code coverage test collected in the plurality of devices is automatically collected to quickly measure the code coverage of the source code. can do.

1 is a flowchart showing a code coverage measuring method according to the first embodiment of the present invention.

2 is a flow chart embodying the step of inserting a probe into the source code shown in FIG.

3 is an example of a control flow graph for explaining a method of determining an insertion position of a probe.

4 is a block diagram of a probe insertion apparatus that may implement a method of inserting a probe into the source code shown in FIG.

5 is a flowchart illustrating a code coverage measurement method according to the second embodiment of the present invention.

FIG. 6 is a flowchart detailing step 10 of determining whether the corresponding source code shown in FIG. 5 is a source code that has been previously compiled.

7 is a flowchart showing a code coverage measurement method according to the third embodiment of the present invention.

FIG. 8 is a flow chart embodying step 20 for determining whether the changed source code shown in FIG. 7 has been substantially changed.

9 is a system diagram for explaining a code coverage measurement method according to the fourth embodiment.

10 is a flowchart for explaining a method for measuring code coverage according to the fourth embodiment.

FIG. 11 is a diagram for describing a first example of the method for measuring code coverage shown in FIG. 10. FIG.

FIG. 12 is a diagram for describing a second example of the code coverage measurement method shown in FIG. 10. FIG.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, detailed descriptions of preferred embodiments of the present invention will be described with reference to the accompanying drawings. It should be noted that reference numerals and like elements among the drawings are denoted by the same reference numerals as much as possible even if they are shown in different drawings. For reference, in the following description of the present invention, if it is determined that a detailed description of related known functions or configurations may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. Hereinafter, a method of measuring code coverage according to an embodiment of the present invention will be described with reference to the accompanying drawings.

1 is a flowchart showing a code coverage measurement method according to the first embodiment of the present invention.

Referring to FIG. 1, the method for measuring code coverage according to the first embodiment includes inserting a probe into source code 100, generating an executable file 300, and measuring code coverage ( 500).

Inserting a probe into the source code 100 is inserting a probe into the source code to measure code coverage. This step will be described later in detail with reference to FIG. 2.

Generating an executable file 300 is a step of generating an executable file by compiling source code into which a probe is inserted.

Measuring the code coverage 500 is a step of measuring the code coverage using the generated executable file.

FIG. 2 is a flowchart illustrating the steps of inserting a probe into the source code shown in FIG. 1.

Inserting the probe into the source code includes generating an abstract syntax tree (AST) (110), generating a control flow graph (CFG) (120) and inserting the probe Step 130 may include.

Generating an abstract syntax tree 110 may generate an abstract syntax tree from source code. An abstract syntax tree can be created using a parser. Here, the parser may be a C / C ++ parser, for example. By entering the source code into the C / C ++ parser, the C / C ++ parser can generate an abstract syntax tree.

Generating a control flow graph (120) generates a control flow graph by interpreting the abstract syntax tree generated above.

Inserting a probe 130 is a step of inserting a probe using the abstract syntax tree and the control flow graph generated above. Specific probe insertion method will be described in detail below.

Probes are inserted using abstract syntax trees and control flow graphs. Specifically, the probe may be inserted with reference to the control flow graph, and the probe may be inserted by determining the number of conditions of the branch statement in the abstract syntax tree.

A method of inserting a probe by referring to a control flow graph and a method of inserting a probe by determining the number of conditions of branch statements in an abstract syntax tree may be performed in parallel. The following description will be divided into each.

In the method of inserting the probe with reference to the control flow graph, after determining the insertion position of the probe in the control flow graph, the probe may be inserted.

The method for determining the insertion position of the probe in the control flow graph may be determined by searching for base paths in the control flow graph and then inserting one probe for each base path.

Here, the base path means a path from one branch of a branch statement until the next branch statement is met, and the base path is a minimum execution flow that can no longer be divided. An example of a method of determining an insertion position of a probe in a control flow graph will be described with reference to FIG. 3.

The base path is retrieved from the control flow graph shown in FIG. Since the base path is a path from one branch of the branch (if) to the next branch (if) as described above, five base paths in the control flow graph shown in FIG. 3 (path 1, path 2). , path 3, path 4, path 5).

One probe (P1, P2, P3, P4, P5) is inserted into each of the five base paths (path 1, path 2, path 3, path 4, and path 5).

Referring back to FIG. 2, a method of inserting a probe by determining the number of conditions of branch statements in the abstract syntax tree will be described.

The method of inserting a probe by determining the number of conditions of a branch statement in the abstract syntax tree is to search for a branch statement having two or more conditions in the abstract syntax tree, change the form of the found branch statement, and then insert a probe. Can be.

Here, the branch statement is a statement that determines the execution flow, and may include a for statement, an if statement, and a while statement. In addition, to change the form of the branch statement means to change the format so that the probe can be inserted, without changing the actual meaning of the searched branch statement.

Hereinafter, one method of changing the form of a branching statement (if statement) having two conditions will be described as an example.

[Example of Quarter]

If (A && B)

[Example of the branch statement] is an if statement, two conditions (A and B), and two conditions (A and B) are combined by one logical operator (&&). The truth table of [Example of Quarter] is shown in <Table 1> below.

AA	BB	DecisionDecision
1 (true)1 (true)	1 (true)1 (true)	1 (true)1 (true)
1 (true)1 (true)	0 (false)0 (false)	0 (false)0 (false)
0 (false)0 (false)	Don’t careDo n’t care	0 (false)0 (false)

The branching example has a form in which the probe cannot be inserted formally. Therefore, the [branch example] should be changed to a form in which the probe can be inserted. If the actual meaning of the [branch example] is changed to a form in which the probe can be inserted without changing, the probe may be inserted as shown in [Branch Modification Example 1] below.

[Variation Example 1]

If ((A? Probe (m), 1: probe (n), 0) && (B? Probe (o), 1: probe (p), 0))

In the [branch modification example 1], the logical operator & is still present, and each condition is changed to a ternary operator in order to insert a probe. Even if this change is made, the actual meaning of the [branch example] is the same. The branching modification example 1 has three branching points (?, &&,?) And four probes (m, n, o, p) in total.

Other modifications of the [branch example] may be the same as the following [branch variant 2].

[Variation Example 2]

If (A? (B? Probe (a), 1: probe (b), 0): probe (c), 0)

In [Branch Modification Example 2], the logical operator & is changed to a ternary operator. Even if this change is made, the actual meaning of the [branch example] is the same. In the above [Branch Modification Example 2], two branch points (?,?) Exist inside, and a total of three probes a, b, and c exist.

Compared to the above [Variation Modification Example 1], the [branch modification example 2] does not change the condition to the ternary operator, but rather changes the logical operator to the ternary operator to change the number of branch points and the number of probes, respectively. We can reduce one more. Since the number of branch points and the number of probes are the decisive factors for determining the performance load for the code coverage measurement, by changing the [branch example] to [branch variant 2] instead of [branch variant 1], Code coverage measurement performance can be improved.

FIG. 4 is a block diagram of a probe insertion apparatus that may implement a method of inserting a probe into the source code shown in FIG. 2.

Referring to FIG. 4, the probe insertion apparatus 400 may include a parser 410, a control flow graph generator 430, and a source code rewriter 450.

The parser 410 parses input source code to generate an abstract syntax tree. Here, the parser 410 may be a C / C ++ parser.

The control flow graph generator 430 receives the abstract syntax tree output from the parser 410 as an input and interprets it to generate the control flow graph 430.

The source code rewriter 450 outputs the source code into which the probe is inserted using the control flow graph output from the control flow graph generator 430 and the abstract syntax tree output from the parser 410. Since the method of inserting the probe using the control flow graph and the abstract syntax tree has been described in detail with reference to FIGS. 2 to 3, a description thereof will be omitted.

5 is a flowchart showing a code coverage measurement method according to the second embodiment of the present invention.

In the code coverage measurement method according to the second embodiment illustrated in FIG. 5, when the contents of source code (hereinafter, referred to as “previous source code”) that have been compiled at least once are changed by a developer or other program, A method for measuring code coverage of modified source code.

Referring to FIG. 5, in the code coverage measurement method according to the second embodiment, a step 10 of determining whether the source code has been previously compiled, a step 100 of inserting a probe into the source code, and an execution The method may include generating a file 300 and measuring code coverage 500.

Here, except for the step 10 of determining whether the source code has been previously compiled, inserting a probe into the source code 100, generating an executable file 300, and measuring code coverage Step 500 is the same as the step 100 of inserting the probe into the source code shown in FIG. 1, generating the executable 300, and measuring the code coverage 500, and thus will be compiled below. It will be described in detail step 10 for determining whether or not the source code was performed.

The step 10 of determining whether the source code has been previously compiled is to determine whether the source code has been previously compiled to generate an executable file before inserting the probe 100 into the source code. Step.

As a result of the determination, if the corresponding source code has not been compiled previously, the source code is recognized as a different source code from the existing one, the probe is inserted into the source code (100), and the source code into which the probe is inserted is generated to generate a new executable file (300). )do. After storing the new executable file 400, the code coverage of the new executable file is measured 500.

On the other hand, if the determination result, if the source code has been previously compiled, go to step (500) to measure the code coverage by performing a previously compiled to load a pre-stored executable file. Next, how to determine whether the changed source code has been previously compiled will be described with reference to FIG. 6.

FIG. 6 is a flowchart in which step 10 of determining whether the corresponding source code illustrated in FIG. 5 is the source code that has been previously compiled is illustrated.

Referring to FIG. 6, the step 10 of determining whether the changed source code is the source code that has been previously compiled may include generating the preprocessed source code (11), removing noise (12), and uniqueness. The method may include generating a value 13, determining whether the generated eigenvalue is the same as a previous eigenvalue 14, and outputting a pre-stored executable file 15. Here, step 12 of removing noise may be omitted.

The generating 11 of the preprocessed source code is a step of generating preprocessed source code by preprocessing the changed source code.

Here, the preprocessed source code is a source code having a fixed shape capable of inserting a probe or performing compilation.

Here, the preprocessing refers to a process of generating the source code for compilation reflecting the inclusion relationship and the macro definition by analyzing the changed source code. Reflecting the inclusion relationship means inserting the system header or the user header into the changed source code when the system header or the user header is included in the changed source code to be preprocessed. do. And, reflecting the macro definition means replacing the macro defined in the changed source code with an extension string that follows the macro definition.

Removing noise 12 is removing noise of preprocessed source code. Here, the noise means elements that depend on the preprocessing time point. The element that depends on the preprocessing time point may be, for example, information about the time when the preprocessing was performed and information about the date. Such noise can be removed using regular expressions. Here, regular expression means a formal language used to express a set of strings with specific rules.

Generating a eigenvalue 13 is a step of generating a eigenvalue capable of shape identification by performing normalization on the preprocessed source code from which noise is removed. Performing normalization means using a hash algorithm to generate eigenvalues throughout the preprocessed source code. Here, the hash algorithm may use a message-digest algorithm 5 (MD5) function. Intrinsic values of the entire source code are not changed by changing the actual meaning of the source code, such as commenting or spacing.

Determining whether or not the generated eigenvalue is equal to the previous eigenvalue is step 14 of determining whether the generated eigenvalue is the same as the previous eigenvalue previously stored in a given reservoir. Here, the predetermined storage stores predetermined eigenvalues and executable files corresponding to each of the eigenvalues.

If the generated eigenvalue is the same as the previous eigenvalue, the executable file stored in the predetermined storage is loaded (15). Then, the code coverage of the loaded executable file is measured (500).

If the generated eigenvalue is different from the previous eigenvalue, the probe is inserted into the preprocessed source code (100). As shown in FIG. 5, an executable file is generated 300, and the generated executable file is stored in the predetermined storage along with the generated unique value to be used again later (400). Finally, code coverage of the generated executable file is measured 500.

As described above, the method of measuring the code coverage shown in FIG. 5 is, when the source code that has been compiled at least once is changed by a developer, a program, or the like, whether the changed content is a substantial change or a substantial change in the source code. If the changed content is not a substantial change, the executable file, which has been previously compiled, is loaded and the code coverage of the loaded executable file is measured. Therefore, when substantial changes such as comments or spacing have been made to the source code that has been compiled at least once, there is no need to repeat the process of inserting the probe into the changed source code or generating the executable file again. Therefore, there is an advantage in that preparation time for measuring code coverage can be shortened for source code that has been compiled at least once.

In the code coverage measurement method according to the third embodiment shown in FIG. The present invention relates to a method for measuring code coverage of modified source code.

Referring to FIG. 7, in the code coverage measurement method according to the third embodiment, determining whether the changed source code is substantially changed (20), outputting an existing code coverage value (30), and performing code coverage It may include the step of measuring 40 and the step 50 of storing the eigenvalues and function coverage values of the changed function.

Determining whether or not the changed source code has been substantially changed is a step of determining whether the previous source code that measured the code coverage at least one or more times is substantially changed, not a formal change.

As a result of the determination, if the changed source code is not substantially changed, the code coverage value which has been previously measured is retrieved and output without the code coverage measurement of the changed source code (30).

Meanwhile, if the changed source code is substantially changed, the code coverage of the changed source code is measured (40), and the unique value and the function coverage value of the changed function in the source code are stored (50). Here, the changed eigenvalues and function coverage values may be stored in a predetermined repository for later use.

Hereinafter, a method of determining whether the changed source code is substantially changed will be described in detail with reference to FIG. 8.

FIG. 8 is a flowchart embodying step 20 for determining whether the changed source code shown in FIG. 7 has been substantially changed.

Referring to FIG. 8, the step 20 of determining whether the changed source code has previously measured code coverage includes generating 21 preprocessed source code, removing noise 22, and function. The method may include generating a star eigenvalue 23, determining whether at least one changed function exists 24, and classifying the changed and unchanged functions 25. Here, step 22 of removing noise may be omitted.

The step 21 of generating preprocessed source code and the step 22 of removing noise are the same as the step 11 of generating preprocessed source code and step 12 of removing noise shown in FIG. , The description is replaced by the foregoing.

The step 23 of generating a function-specific eigenvalue is a step of generating a function-specific eigenvalue whose shape can be identified by performing normalization for a plurality of functions existing in the preprocessed source code. Therefore, the number of eigenvalues for each function is determined according to the number of functions. Here, performing normalization means generating a unique value for each of a plurality of functions in the preprocessed source code using a hash algorithm. Intrinsic values of a function are not changed by a formal change, not by changing the actual meaning of the function, such as inserting a comment or spacing.

After generating eigenvalues for each of the plurality of functions in the preprocessed source code, it is determined whether at least one or more changed functions exist among the plurality of functions (24). Here, whether or not the changed function exists may be determined by comparing one-to-one unique values of functions of the previous source code previously stored in a predetermined storage with the unique values of each function of the generated changed source code.

As a result of the determination, if the function-specific eigenvalues of the changed source code are all the same as the function-specific eigenvalues of the previous source code, the existing code coverage value is output (30).

On the other hand, if at least one or more of the function-specific eigenvalues of the changed source code does not match the function-specific eigenvalues of the previous source code, a plurality of functions are classified into the changed function and the unchanged function (25), code coverage Measure (40). Here, the step 40 of measuring the code coverage loads the function coverage value of the unchanged function from the given repository and calculates the code coverage of the changed source code.

Comparing the code coverage measurement method according to the third embodiment with the conventional code coverage measurement method, for example, the previous source code includes 100 functions, and the code coverage value of the previous source code was 100 (%). When one of the 100 functions of the previous source code is substantially changed, according to the conventional code coverage measurement method, the code coverage value is 0 (%) (because the conventional code coverage measurement method is a Or if it is changed formally, it is recognized as a new source code). However, according to the code coverage measurement method according to the third embodiment, the code coverage value is 99 instead of 0. Therefore, since the function coverage of the unchanged function is maintained, there is an advantage that it is not necessary to retest the unchanged function later.

Referring to FIG. 9, the system in which the code coverage measuring method according to the fourth embodiment is performed may include a plurality of

devices

910 and 930 and a server 950.

The plurality of

devices

910, 930 may measure the code coverage of the source code transmitted from the server 950 or directly uploaded by the user.

Each of the plurality of

devices

910 and 930 may include a log collection agent.

The log collection agent may control code coverage measurement of each of the plurality of

devices

910 and 930. In detail, the log collecting agent may control the start and end of code coverage measurement of each of the plurality of

devices

910 and 930, and may perform code coverage measurement performance status information of each of the plurality of

devices

910 and 930. I can figure it out.

The log collection agent may transmit the collected code coverage log to the server 950. Here, the log collection agent may transmit the collected code coverage log according to the update request of the server 950, and automatically transmit the collected code coverage log to the server 950 at any predetermined time without the request of the server 950. You can also send. Here, the arbitrary time point may be when the code coverage measurement is finished, or may be any time point requested by the server 950.

The log collection agent may generate a unique value of the collected code coverage log by performing normalization on the collected code coverage log before transmitting the collected code coverage log to the server 950. In addition, when the collected code coverage log is transmitted to the server 950, the generated unique value may also be transmitted. Here, the eigenvalue may be a character string capable of shape identification generated by using a hash algorithm on the collected code coverage log.

The plurality of

devices

910 and 930 may be smartphones, tablet PCs, laptops, desktops, and the like, and may perform data communication with the server 950 by wire or wirelessly.

The server 950 may perform data communication with the plurality of

devices

910 and 930.

The server 950 may receive code coverage logs from the plurality of

devices

910 and 930, store the received code coverage logs, and collect the stored code coverage logs by a predetermined method to measure code coverage.

The server 950 may make an update request for requesting a code coverage log to the plurality of

devices

910 and 930.

Referring to FIG. 10, a method in which the server 950 collects code coverage logs collected from the plurality of

devices

910 and 930 to measure code coverage will be described in detail.

Referring to FIG. 10, in the code coverage measurement method according to the fourth embodiment, the server 950 receives a code coverage log from a plurality of

devices

910 and 930, and the server 950 receives code coverage. Saving logs 951 and server 950 may include measuring code coverage using stored code coverage logs.

Here, before the server 950 receives the code coverage log from the plurality of

devices

910 and 930, the server 950 may request an update request for the code coverage log from the plurality of

devices

910 and 930. have. The update request may be a request to change the current code coverage log from which the request was received, or may be a request to change the code coverage log at any point in time (at a specific time or at a specific time).

The step 951 in which the server 950 stores the received code coverage logs may be a step in which the server 950 stores the code coverage logs received from the plurality of

devices

910 and 930 in a queue. have.

The step 952 of the server 950 measuring code coverage may be a step of collecting code coverage logs stored in a queue in a predetermined method to measure code coverage of the source code to be measured.

The server 950 stores the received code coverage logs (951), and describes a specific method for measuring the code coverage (952) with two examples.

The first example is that the code coverage log from the plurality of devices (910, 930) by the server 950 after the code coverage test is performed on each of the plurality of devices (910, 930) individually for the entire source code to be measured If you receive a

In the second example, the source code to be measured is divided into a plurality of devices and distributed to the plurality of

devices

910 and 930 so that the code coverage test is performed on the plurality of

devices

910 and 930, and then the server 950 receives the plurality of source codes. This is the case when code coverage logs are received from the

devices

910 and 930.

The fundamental difference between the first example and the second example is whether the source codes tested in the plurality of

devices

910, 930 are the same or different. The first example is when the source codes tested in the plurality of

devices

910 and 930 are the same, and the second example is when the source codes tested in the plurality of

devices

910 and 930 are different. First, the code coverage measurement method according to the first example will be described below with reference to FIG. 11.

FIG. 11 is a diagram for describing a first example of the method for measuring code coverage shown in FIG. 10.

The first example shown in FIG. 11 is the first code from the first device 910 at certain times (9:00, 9:10, 9:20), as shown in the table shown in FIG. When the coverage logs log_1-1, log_1-2, log_1-3 are received, and the second code coverage logs log_2-1, log_2-2, log_2-3 are received from the second device 930. It is intended. Each of the code coverage logs of FIG. 11 (a) includes a plurality of parts, in which the plurality of parts are represented by boxes, and the checked box is the part where the code coverage test is performed, and the unchecked box is Code coverage test is not performed. Since the first code coverage log and the second code coverage log are for the same source code, it is assumed that the data length of each log is the same.

The server 950 illustrated in FIG. 10 may include the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2 as shown in the table of FIG. Upon receiving -1, log_2-2, log_2-3, the server 950 queues the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2. -1, log_2-2, log_2-3) are stored as shown in FIG. Specifically, the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2-1, log_2-2, log_2-3 are stored in the queue in the server 950. Stored in the order received. For convenience, it is assumed that the first code coverage log is received by the server 950 before the second code coverage log.

When the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2-1, log_2-2, log_2-3 are stored in the queue of the server 950, The server 950 collects the stored code coverage logs log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, and log_2-3 to measure the code coverage of the measurement target source code.

Here, one method of collecting code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) to measure the code coverage of the source code to be measured is code The code coverage is measured by accumulating coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) in order of being stored in a queue. Specifically, the code coverage value (40%) of the first code coverage log 1 (log_1-1) received first is calculated, and then the first code coverage log 1 (log_1-1) and the second code coverage log 1 are calculated. Accumulate (log_2-1) to calculate the code coverage value (60%). In this way, the code coverage value (100%) is calculated by accumulating up to the last stored second code coverage log 3 (log_2-3).

However, this method has a problem that the data of the code coverage log is not efficient when the data is large and long, and the calculation takes too long. Therefore, by calculating the code coverage value in the following way, it is possible to calculate the code coverage value more efficiently and quickly.

Another method of collecting code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) to measure code coverage of the source code to be measured is code stored in a queue. Create a virtual code coverage log with the same data size as the coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3), and create the generated virtual code coverage log. It is determined whether the code coverage test is performed for each of the plurality of components.

Specifically, the method for determining whether the code coverage test for each of the plurality of parts constituting the generated virtual code coverage log, all code coverage logs (log_1-1, log_1-2, log_1-3, log_2- 1, log_2-2, log_2-3, search for the first portions 1100 corresponding to the first portion of the virtual code coverage log, and code coverage tested at least one of the first portions 1100 If (checked) is present, the first portion of the virtual code coverage is determined to be tested. In the same way, the code coverage value is calculated by determining whether or not all parts of the virtual code coverage are tested. According to this method, in the case of FIG. 11B, since all parts of the generated virtual code coverage log will be checked, the code coverage value will be 100 (%).

FIG. 12 is a diagram for describing a second example of the method for measuring code coverage shown in FIG. 10.

The first example shown in FIG. 12 is the first code from the first device 910 at certain times (9:00, 9:10, 9:20), as shown in the table shown in FIG. When the coverage logs log_1-1, log_1-2, log_1-3 are received, and the second code coverage logs log_2-1, log_2-2, log_2-3 are received from the second device 930. It is intended. Each of the code coverage logs of FIG. 12A includes a plurality of parts, in which the plurality of parts are represented by boxes, and a checked box is a part where a code coverage test is performed, and an unchecked box is shown in FIG. Code coverage test is not performed. Since the first code coverage log and the second code coverage log target different source codes, it is assumed that the data length of each log is different.

The server 950 illustrated in FIG. 10 may include first code coverage logs log_1-1, log_1-2, log_1-3 and second code coverage logs log_2 as shown in the table of FIG. Upon receiving -1, log_2-2, log_2-3, the server 950 queues the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2. -1, log_2-2, log_2-3) are stored as shown in FIG. Specifically, the first code coverage logs log_1-1, log_1-2, log_1-3 and the second code coverage logs log_2-1, log_2-2, log_2-3 are stored in the queue in the server 950. Stored in the order received. For convenience, it is assumed that the first code coverage log is received by the server 950 before the second code coverage log.

Here, unlike the first example illustrated in FIG. 11, the second example illustrated in FIG. 12 is a different log because the first code coverage log and the second code coverage log target different source codes. Accordingly, the second example shown in FIG. 12 uses the same source code as the code coverage logs stored in the queue (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3). The step of classifying the targets should be performed before measuring the code coverage.

Here, the method of classifying the code coverage logs stored in the queue (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) with the same source code, You can sort by eigenvalues. When the plurality of

devices

910 and 930 illustrated in FIG. 10 transmit the code coverage log to the server 950, the plurality of

devices

910 and 930 may transmit a unique value of the corresponding code coverage log together with the code coverage log. The unique value of the corresponding code coverage log may be generated using a hash algorithm. The unique value of the corresponding code coverage log is a unique value that does not change regardless of whether each of the plurality of portions in the corresponding code coverage log has been tested. Thus, the server 950 uses the code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) and their respective intrinsic values to determine the code coverage logs ( log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) can be classified among the targets of the same source code. In this way, if all the code coverage logs stored in the queue (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) are classified, the first code coverage logs (log_1-1) , log_1-2, log_1-3) have the same eigenvalues, and since the second code coverage logs log_2-1, log_2-2, log_2-3 also have the same eigenvalues, they may be classified. .

After all the code coverage logs stored in the queue (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) are classified according to their eigenvalues, In this way, the code coverage value of the source code to be measured may be calculated.

The above-described embodiments may be implemented in the form of program instructions that can be executed by various computer components, and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination.

Program instructions recorded on the computer-readable recording medium may be those specially designed and configured for the present invention, or may be known and available to those skilled in the computer software arts.

Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical recording media such as CD-ROMs, DVDs, and magneto-optical media such as floptical disks. optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to carry out the process according to the invention, and vice versa.

The embodiments of the present invention have been described above with reference to the accompanying drawings, which are merely exemplary and are not intended to limit the present invention, and those skilled in the art do not depart from the essential characteristics of the present embodiment. It will be appreciated that various modifications and applications which are not illustrated above in the scope are possible. For example, each component specifically shown in embodiment can be modified and implemented. And differences relating to such modifications and applications will have to be construed as being included in the scope of the invention defined in the appended claims.

Claims

In the method of measuring the code coverage of the source code,

Inserting a probe into the source code;

Compiling the source code into which the probe is inserted to generate an executable file; And

Measuring the code coverage using the generated executable file;

Inserting a probe into the source code,

Generating an abstract syntax tree from the source code;

Interpreting the abstract syntax tree to generate a control flow graph; And

And inserting the probe into the source code using the abstract syntax tree and the control flow graph.
The method of claim 1,

Inserting the probe into the source code using the abstract syntax tree and the control flow graph,

Retrieving base paths from the control flow graph and inserting one first probe for each base path; And

Determining a number of conditions of a branch statement in the abstract syntax tree and inserting a second probe;

Including, the code coverage measurement method.
The method of claim 2,

Determining the number of conditions of the branch statement in the abstract syntax tree and inserting a second probe,

And replacing the logical operator existing in the branch statement having two or more conditions with a ternary operator and inserting the second probe.
The method of claim 1,

Before inserting the probe into the source code,

Determining whether the source code has been previously compiled;

If the source code has been previously compiled, skipping the preparation process for measuring the code coverage by reusing the existing executable file

, How to measure code coverage.
The method of claim 4, wherein

Determining whether or not the source code has been previously compiled,

Preprocessing the source code to generate preprocessed source code;

Removing noise of the preprocessed source code;

Generating an eigenvalue of the preprocessed source code from which the noise is removed;

Determining whether the generated eigenvalue is equal to a previously stored eigenvalue;

If the generated eigenvalue is the same as the previous eigenvalue, measure the code coverage using the existing executable file,

And inserting the probe into the source code if the generated eigenvalue is different from the previous eigenvalue.
In the method of measuring the code coverage of the source code,

Determining whether the source code has been substantially changed;

If the source code has substantially changed, measuring code coverage of the changed source code; And

If the source coat has not changed substantially, outputting an existing code coverage value;

Including, the code coverage measurement method.
The method of claim 6,

Determining whether the source code has been substantially changed,

Preprocessing the source code to generate preprocessed source code;

Generating unique values for each function in the preprocessed source code;

Comparing the generated unique values for each function with previously stored unique values for each function to determine whether at least one changed function exists; And

And classifying the changed function and the unchanged function if at least one or more of the generated function-specific eigenvalues have changed.

And if the source code has substantially changed, measuring code coverage of the changed source code retrieves the function coverage value of the unchanged function to calculate code coverage of the changed source code.
A method of measuring code coverage by a server receiving code coverage logs collected from a plurality of devices, the method comprising:

Storing code coverage logs received from the plurality of devices in a queue in the order in which they are received; And

Measuring the code coverage using code coverage logs stored in the queue;

Including, the code coverage measurement method.
The method of claim 8,

Prior to calculating the code coverage,

And classifying the code coverage logs stored in the queue among targets of the same source code.
A computer-readable recording medium having recorded thereon a program for executing the method for measuring code coverage according to any one of claims 1 to 9.