KR20160021585A - Method for measuring code coverage and computer readable recording medium having program the same - Google Patents

Abstract

An embodiment of the present invention relates to a code coverage measurement method.
A method of measuring a code coverage according to an embodiment includes: inserting a probe into the source code; Generating an executable file by compiling the source code into which the probe is inserted; And measuring the code coverage using the generated executable file, wherein the step of inserting the probe into the source code comprises: generating an abstract syntax tree from the source code; Analyzing 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.

Description

[0001] METHOD FOR MEASURING CODE COVERAGE AND COMPUTER [0002] READABLE RECORDING MEDIUM HAVING PROGRAM THE SAME [0003]

The present invention relates to a code coverage measurement method and a computer-readable recording medium recording a program for executing the method.

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 is tested. Thus, code coverage is generally expressed as a percentage.

To measure code coverage, you need a certain code coverage measurement tool, typically LDRA and VectorCAST.

The present invention provides a code coverage measurement method capable of efficiently inserting a probe into a source code for measuring code coverage, and a computer readable recording medium recording a program for executing the method.

The present invention also provides a code coverage measurement method capable of omitting an iterative process of compiling source code that has not been changed among all the source codes and generating an executable file after compiling the source code for coverage measurement, There is provided a computer-readable recording medium storing a program for executing the program.

The present invention also provides an effective code coverage measurement method capable of not measuring the code coverage of the entire source code every time a change is made to the source code after measuring the code coverage of the source code and a computer The present invention provides a recording medium readable by a computer.

The present invention also relates to a method and apparatus for collecting code coverage tests collected from a plurality of devices and collecting code coverage of the source code quickly when a code coverage test is performed on a plurality of devices, And a computer readable recording medium recording a program for executing the method.

The problems to be solved by the present invention are not limited to those mentioned above, and other problems to be solved can be clearly understood by those skilled in the art from the following description.

A method of measuring a code coverage of a source code according to an embodiment includes: inserting a probe into the source code; Generating an executable file by compiling the source code into which the probe is inserted; And measuring the code coverage using the generated executable file, wherein the step of inserting the probe into the source code comprises: generating an abstract syntax tree from the source code; Analyzing 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 method of measuring a code coverage of a source code according to an embodiment includes: determining whether the source code has been substantially changed; Measuring the code coverage of the modified source code if the source code has substantially changed; And outputting an existing code coverage value if the source coat has not been substantially changed.

A method for measuring a code coverage of a source code according to an embodiment is a method for a server to measure code coverage by receiving collected code coverage logs from a plurality of devices, Storing them in a queue in chronological order; And measuring the code coverage using code coverage logs stored in the queue.

Using the method of measuring code coverage according to the present invention and the computer readable recording medium recording the program for executing the method, the probe can be efficiently inserted into the source code for measuring the code coverage. Therefore, it is possible to reduce the size of the binary of the source code into which the probe is inserted, which has the advantage of minimizing the performance adverse effect in measuring the code coverage value of the source code.

Also, after compiling the source code, it is possible to omit the iterative process of generating an executable file for coverage measurement for the entire source code whenever a change is made to the source code. Therefore, there is an advantage to reduce preparation time for code coverage measurement of source code, since the coverage measurement preparation process can be omitted for unchanged source code.

In addition, after measuring the code coverage of the source code, even if the source code changes, the coverage value of the unchanged source code portion may remain the same and the code coverage of the entire source code may not be measured again. Therefore, there is an advantage in that it is possible to reduce the time taken to achieve a specific coverage reference value, since there is no need to retest the portion subjected to the code coverage test.

In addition, when a code coverage test is performed on a plurality of devices in which a predetermined source code is not a single device, the code coverage test collected on a 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 measurement method according to a first embodiment of the present invention;
Figure 2 is a flow chart embodying the step of inserting a probe into the source code shown in Figure 1;
3 is an example of a control flow graph for explaining a method of determining the insertion position of a probe.
4 is a block diagram of a probe insertion device capable of implementing a method of inserting a probe into the source code shown in Fig.
5 is a flowchart showing a code coverage measurement method according to a second embodiment of the present invention;
FIG. 6 is a flow chart embodying the step (10) of determining whether the corresponding source code shown in FIG. 5 is a source code that has been compiled in the past.
7 is a flowchart showing a code coverage measurement method according to a third embodiment of the present invention;
FIG. 8 is a flow chart embodying the step 20 of determining whether the modified source code shown in FIG. 7 has substantially changed. FIG.
9 is a system diagram for explaining a code coverage measurement method according to a fourth embodiment.
10 is a flowchart for explaining a method of measuring code coverage according to the fourth embodiment;
11 is a diagram for explaining a first example of the code coverage measurement method shown in FIG. 10;
12 is a diagram for explaining a second example of the code coverage measurement method shown in FIG. 10;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a detailed description of preferred embodiments of the present invention will be given with reference to the accompanying drawings. It should be noted that in the drawings, the same reference numerals and the same elements are denoted by the same reference numerals even though they are shown on different drawings. In the following description, well-known functions or constructions are not described in detail to avoid unnecessarily obscuring the subject matter of the present invention. Hereinafter, a code coverage measurement method 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 a first embodiment of the present invention.

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

A step 100 of inserting a probe into the source code is a step of inserting a probe for measuring the code coverage into the source code. This step will be described in detail later with reference to Fig.

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

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

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

The step of inserting a probe into the source code includes generating an abstract syntax tree (AST) 110, creating a Control Flow Graph (CFG) 120, Step 130 may be included.

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

The step 120 of generating a control flow graph generates a control flow graph by interpreting the abstract syntax tree generated previously.

The step 130 of inserting the probe is a step of inserting the probe using the abstract syntax tree and the control flow graph generated previously. A specific probe insertion method will be described in detail below.

Probe is inserted using abstract syntax tree and control flow graph. Specifically, the probe can be inserted with reference to the control flow graph, and the probe can be inserted by determining the number of conditions of the branch statement in the abstract syntax tree.

The method of inserting the probe by referring to the control flow graph and the method of inserting the probe by discriminating the number of the condition of the branch statement in the abstract syntax tree can be performed in parallel. The following will be separately described below.

The method of inserting the probe with reference to the control flow graph can insert the probe after determining the insertion position of the probe in the control flow graph.

The method of determining the insertion position of the probe in the control flow graph can be determined by inserting one probe per each basis path after searching the basis paths in the control flow graph.

Here, the base path means a path from one brench of the branching query to the next branching, and the base path is the minimum execution flow that can not be further divided. An example of a method of determining the insertion position of the probe in the control flow graph will be described with reference to FIG.

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

The base path is retrieved in the control flow graph shown in FIG. Since the basis path is a path from one of the branch statements (if) to the next until the next branch statement (if) is encountered, the base path in the control flow graph shown in FIG. 3 is five (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, path 5).

Referring again to FIG. 2, a method of inserting probes by determining the number of branch condition conditions 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 an abstract syntax tree is as follows. A branch statement having two or more conditions in an abstract syntax tree is searched, and a probe is inserted .

Here, the branch statement is a statement for determining execution flow, and may include a for statement, an if statement, and a while statement. The meaning of changing the form of the branch query means that the form is changed so that the probe can be inserted without changing the actual meaning of the found branch query.

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

[Branching example]

If (A && B)

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

A B Decision 1 (true) 1 (true) 1 (true) 1 (true) 0 (false) 0 (false) 0 (false) Do not care 0 (false)

The [branching example] has a form in which a probe can not be inserted formally. Therefore, the [branching example] should be changed to a form in which the probe can be inserted. When the probe is inserted after changing the form of the probe to be inserted without changing the actual meaning of the above [branch statement example], it may be the same as the following [branch statement modification example 1].

[Branch Example Variation Example 1]

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

In [Branching Modification 1], the logical operator (&&) is present, and each condition is changed to a ternary operator in order to insert a probe. Even if such a change is made, the practical meaning is the same as that of the above [branch example]. In this branching variant example 1, there are three branch points (?, &&,?) Inside, and there are four probes (m, n, o, p) in total.

Another modified example of the above [Example of branch statement] may be the same as the following [modified example of branch statement 2].

[Branch Example Variation Example 2]

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

In [Branch Statement Variation Example 2], the logical operator (&&) was changed to a ternary operator. Even if such a change is made, the practical meaning is the same as that of the above [branch example]. In this branching variant example 2, there are two branch points (?,?) Inside and there are three probes (a, b, c) in total.

The [Branch Statement Variation Example 2], when compared with the above [Branch Statement Variation Example 1], does not change the condition to the ternary operator but changes the logical operator to the ternary operator so that the number of branch points and the number of probes are You can reduce one by one. Since the number of the branch points and the number of probes are decisive factors for determining the performance load for the code coverage measurement, by changing the above [branch statement example] to [branch instruction variant example 2] instead of [branch instruction variant example 1] The code coverage measurement performance can be improved.

4 is a block diagram of a probe insertion device capable of implementing a method of inserting a probe into the source code shown in 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 the input source code to generate an abstract syntax tree. Here, parser 410 may be a C / C ++ parser.

The control flow graph generator 430 inputs the abstract syntax tree output from the parser 410 and analyzes it to generate a control flow graph 430.

The source code rewriter 450 outputs the source code into which the probe is inserted by using the control flow graph output from the control flow graph generator 430 and the abstract syntax tree output from the parser 410. 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, and a description thereof will be omitted.

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

The method of measuring code coverage according to the second embodiment shown in FIG. 5 is a method of measuring a code coverage of a source code (hereinafter referred to as &quot; previous source code &quot;) that has been compiled at least once, And how to measure the code coverage of the changed source code.

5, a code coverage measurement method according to a second embodiment includes a step 10 of determining whether a source code has been previously compiled, a step 100 of inserting a probe into the source code, (Step 300) and measuring code coverage (step 500).

Here, except for the step 10 of determining whether the source code has been previously compiled, a step 100 of inserting a probe into the source code, a step 300 of generating an executable file, Step 500 is the same as step 100 of inserting a probe into the source code shown in FIG. 1, generating an executable file 300 and measuring code coverage 500, (Step 10) of determining whether the source code has been performed.

Step 10 of judging whether or not the source code has been previously compiled is determined whether or not the source code has already been compiled and generated an executable file before inserting the probe 100 into the source code .

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

On the other hand, if it is determined that the source code has been previously compiled, the compile operation is performed and the pre-stored executable file is loaded and the code coverage is measured (step 500). Hereinafter, how to determine whether the changed source code has been previously compiled or not will be described with reference to FIG.

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

Referring to FIG. 6, step (10) of determining whether the changed source code is the source code that has been previously compiled includes step (11) of generating preprocessed source code, step (12) (Step 14) of determining whether the generated eigenvalue is equal to the previous eigenvalue, and outputting the previously stored executable file (step 15). Here, step 12 of removing noise may be omitted.

The step 11 of generating the preprocessed source code is a step of preprocessing the modified source code to generate the preprocessed source code.

Here, the preprocessed source code is source code in which a probe can be inserted or a shape that can be compiled is fixed.

Here, the preprocessing means a process of analyzing the changed source code and generating a source code for compilation reflecting the inclusion relation and the macro definition. Reflecting the inclusion relation means that when the system header or the user header is included in the changed source code which is a subject of the preprocessing, the system header or the user header is inserted into the changed source code do. Reflecting the definition of a macro means replacing the macro defined in the changed source code with an extension string following the macro definition.

The noise removing step 12 is a step of removing noise of the preprocessed source code. Here, noise refers to elements that depend on the time of preprocessing. The element that depends on the preprocessing point may be, for example, information about the time at which the preprocessing was performed and information about the date. These noises can be removed using regular expressions. Here, a regular expression means a formal language used to express a set of strings having a specific rule.

The step 13 of generating eigenvalues is a step of performing normalization on the preprocessed source code from which noises have been removed to generate eigenvalues capable of shape identification. Performing normalization implies generating a unique value of the entire preprocessed source code using a hash algorithm. Here, the hash algorithm can use the MD5 (Message-Digest algorithm 5) function. The intrinsic value of the entire source code is unchanged by not annotating the source code or changing the actual semantics such as spacing.

The step (14) of determining whether the generated eigenvalue is the same as the previous eigenvalue is a step of determining whether or not the generated eigenvalue is the same as the previous eigenvalue previously stored in the predetermined repository. Herein, the predetermined repository stores executable files corresponding to predetermined eigenvalues and their eigenvalues.

If the generated eigenvalue is equal to the previous eigenvalue, the executable file stored in the predetermined repository is loaded (15). Then, the code coverage of the called executable file is measured (500).

On the other hand, if the generated eigenvalue differs from the previous eigenvalue, the probe is inserted (100) into the preprocessed source code. Then, as shown in FIG. 5, an executable file is generated (300), and the generated executable file is stored in the predetermined repository together with the generated eigenvalue (400). Finally, the code coverage of the generated executable file is measured (500).

5, if the source code for which compilation has been performed at least once has been changed by a developer, a program, or the like, whether the changed content is a substantial change in the source code or a non-substantial change And if the changed contents are not substantial changes, the executable file in which the compilation has been performed is called up, and the code coverage of the executable file called is measured. Therefore, when the source code that has been compiled at least once has been changed, such as annotation or spacing, there is no need to repeat the process of inserting the probe back into the changed source code or generating the executable again. Therefore, there is an advantage that the preparation time for measuring the code coverage can be shortened for the source code that has been compiled at least once.

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

The method of measuring a code coverage according to the third embodiment shown in Fig. 7 is a method of measuring a code coverage of a program in a case where a content of a source code (hereinafter referred to as a 'previous source code') whose code coverage has been measured at least once is changed by a developer or another program , And how to measure the code coverage of the changed source code.

Referring to FIG. 7, a code coverage measurement method according to a third embodiment includes a step 20 of determining whether a changed source code has been substantially changed, a step 30 of outputting an existing code coverage value, (Step 40) and storing the eigenvalues and function coverage values of the modified function (step 50).

Step 20 of determining whether the changed source code has been substantially changed is a step of determining whether the previous source code that has measured the code coverage at least once has been 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 of the changed source code is not measured, and the previously measured code coverage value is retrieved and output (30).

On the other hand, if the changed source code is substantially changed, the code coverage of the changed source code is measured 40, and the unique value of the changed function and the function coverage value are stored in the source code 50. Here, the eigenvalues of the changed function and the function coverage value may be stored in a predetermined repository so that they can be used again in the future.

Hereinafter, how to determine whether the changed source code has been substantially changed will be described in detail with reference to FIG.

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

Referring to FIG. 8, step 20 of determining whether the modified source code has previously measured code coverage includes generating 21 a source code that has been pre-processed, removing 22 a noise, (23) generating a star eigenvalue, (24) determining if there is at least one changed function, and (25) classifying the modified function and the unmodified function. Here, the noise removing step 22 may be omitted.

The step of generating the preprocessed source code 21 and the step of removing the noise 22 are the same as the step 11 of generating the preprocessed source code shown in Fig. 6 and the step of removing the noise 12 , The description is replaced with the one described above.

The step 23 of generating a function-specific eigenvalue is a step of generating a function-specific eigenvalue by performing normalization for each of a plurality of functions existing in the preprocessed source code. Therefore, the number of generated eigenvalues per function is determined by the number of functions. Here, performing the normalization means generating each eigenvalue for each of a plurality of functions in the preprocessed source code using a hash algorithm. The formal value of a function is not changed by changing the actual meaning, such as inserting comments or inserting comments into a particular function.

After generating eigenvalues for each of the plurality of functions in the preprocessed source code, it is determined whether or not at least one changed function among the plurality of functions exists (24). Here, whether or not the changed function exists can be determined by comparing one-by-one comparison of the eigenvalues of the generated source code with the function-specific eigenvalues of the previous source code previously stored in the predetermined repository.

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 of the function-specific eigenvalues of the changed source code does not match the function-specific eigenvalues of the previous source code, the plurality of functions are classified into the changed function and the unmodified function (25) (40). Here, the step of measuring code coverage 40 calculates the code coverage of the changed source code by calling the function coverage value of the unmodified function in the predetermined repository.

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 is 100 (%) , And if one of the 100 functions of the previous source code is substantially changed, then the code coverage value is 0 (%) according to the conventional code coverage measurement method Or if it is changed formally, it is recognized as new source code). However, according to the code coverage measurement method according to the third embodiment, the code coverage value is outputted as 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 in the future.

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

Referring to FIG. 9, a system in which a code coverage measurement method according to the fourth embodiment is performed may include a plurality of devices 910, 930 and a server 950.

The plurality of devices 910 and 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, 930 may include a log collection agent.

The log collection agent may control the code coverage measurements of each of the plurality of devices 910, 930. Specifically, the log collection agent can control the start and end of the code coverage measurement of each of the plurality of devices 910 and 930, and can perform the code coverage measurement execution status information of each of the plurality of devices 910 and 930 .

The log collection agent may send 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, or may transmit the collected code coverage log to the server 950 at a predetermined time without request from the server 950 . Here, an arbitrary point may be when the code coverage measurement is terminated, or may be any point requested by the server 950. [

The log collection agent may normalize the collected code coverage log to generate a unique value of the collected code coverage log before transmitting the collected code coverage log to the server 950. [ When transmitting the collected code coverage log to the server 950, the generated eigenvalues may be transmitted together. Here, the eigenvalue may be a character string capable of identifying the shape generated by using the hash algorithm in the collected code coverage log.

The plurality of devices 910 and 930 can be a smart phone, a tablet PC, a laptop, a desktop, and the like, and can 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 can receive code coverage logs from a plurality of devices 910, 930, store received code coverage logs, and collect code coverage logs in a predetermined manner to measure code coverage.

The server 950 may issue an update request to request a code coverage log to the plurality of devices 910 and 930. [

Referring to FIG. 10, a method for collecting code coverage logs collected by a plurality of devices 910 and 930 by a server 950 and measuring code coverage will be described in detail.

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

10, a method for measuring a code coverage according to the fourth embodiment includes the steps of a server 950 receiving a code coverage log from a plurality of devices 910 and 930, a server 950 receiving a code coverage Storing the logs 951 and the server 950 may include measuring 952 code coverage using stored code coverage logs.

Here, before the server 950 receives the code coverage log from the plurality of devices 910, 930, the server 950 may also request an update request to the plurality of devices 910, 930 for a code coverage log have. The renewal request may be a request to request the current code coverage log from which the request was received, or a request to request a code coverage log at any future point in time (a specific time or a specific time period).

The step 951 of storing the received code coverage logs by the server 950 is the step of the server 950 storing code coverage logs received from the plurality of devices 910 and 930 in a queue. have.

The step 952 of the server 950 to measure the code coverage may be a step of collecting the code coverage logs stored in the queue in a predetermined manner to measure the code coverage of the measurement target source code.

The server 950 stores 951 the received code coverage logs and 952 measures the code coverage.

In the first example, after the entire source code to be measured is individually subjected to a code coverage test on a plurality of devices 910 and 930, the server 950 receives a code coverage log from the plurality of devices 910 and 930, .

In the second example, after the source code to be measured is divided into a plurality of devices and distributed to a plurality of devices 910 and 930 to perform a code coverage test on the plurality of devices 910 and 930, It is the case that code coverage logs are received from the devices 910, 930.

The fundamental difference between the first example and the second example is whether the source codes tested in the plurality of devices 910 and 930 are the same or different. In the first example, the source codes tested in the plurality of devices 910 and 930 are identical to each other. In the second example, the source codes tested in the plurality of devices 910 and 930 are different. First, a code coverage measurement method according to the first example will be described below with reference to FIG.

11 is a diagram for explaining a first example of the code coverage measurement method shown in FIG.

The first example shown in FIG. 11 shows a case where the first code 910 is transmitted from the first device 910 at specific times (9:00, 9:10, 9:20) as shown in the table of FIG. 11 (a) When receiving the second code coverage logs (log_2-1, log_2-2, log_2-3) from the second device 930 and receiving the coverage logs (log_1-1, log_1-2, log_1-3) . Each of the code coverage logs of FIG. 11 (a) includes a plurality of portions, in which a plurality of portions are represented by boxes, a checked box is a portion in which a code coverage test is performed, This is where code coverage testing is not done. Since the first code coverage log and the second code coverage log are directed to the same source code, it is assumed that the data length of each log is the same.

The server 950 shown in FIG. 10 performs 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), the server 950 receives 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) as shown in FIG. 11 (b). 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) They are stored in the order they were received. For convenience, it is assumed that the first code coverage log is received in 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 measures the code coverage of the measurement target source code by combining the stored code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3).

One method of collecting the 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 measurement target source code is as follows: The code coverage is measured by accumulating the coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) in the order that they are stored in the 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 (log_2-1) to calculate a code coverage value (60%). In this way, the code coverage value (100%) is cumulatively accumulated up to the last stored second code coverage log 3 (log_2-3).

However, the above method is not effective when the data of the code coverage log is large and long, and the calculation time is too long. Therefore, by calculating the code coverage value in the following manner, the code coverage value can be calculated more efficiently and quickly.

Another way to gather 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 measurement source code is to use the code stored in the queue A virtual code coverage log having 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) is created, and the generated virtual code coverage log And determines whether the code coverage test is performed for each of the plurality of constituent parts.

Specifically, a method for determining whether or not a code coverage test is performed for each of a plurality of parts constituting the generated virtual code coverage log includes the steps of: extracting all code coverage logs (log_1-1, log_1-2, log_1-3, log_2- 1, log_2-2, log_2-3), the first portions 1100 corresponding to the first portion of the hypothetical code coverage log are searched, and if one of the first portions 1100 is code coverage tested (Checked), the first part 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 to test all parts of the virtual code coverage. According to this method, in the case of FIG. 11 (b), since all parts of the generated virtual code coverage log will be checked, the code coverage value will be 100 (%).

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

The first example shown in FIG. 12 shows a case where the first code 910 is transmitted from the first device 910 at specific time points (9:00, 9:10, 9:20) as shown in the table of FIG. 12 (a) When receiving the second code coverage logs (log_2-1, log_2-2, log_2-3) from the second device 930 and receiving the coverage logs (log_1-1, log_1-2, log_1-3) . Each of the code coverage logs of FIG. 12 (a) includes a plurality of portions, in which a plurality of portions are represented by boxes, a checked box is a portion in which a code coverage test is performed, This is where code coverage testing is not done. Since the first code coverage log and the second code coverage log are directed to different source codes, it is assumed that the data length of each log is different.

The server 950 shown in FIG. 10 performs 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), the server 950 receives 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) as shown in FIG. 12 (b). 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) They are stored in the order they were received. For convenience, it is assumed that the first code coverage log is received at 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 measures the code coverage of the measurement target source code by combining the stored code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3).

The second example shown in FIG. 12 is different from the first example shown in FIG. 11 because the first code coverage log and the second code coverage log are different source codes. 12, the code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) stored in the queues are stored in the same source code The step of classifying the objects should be performed before measuring the code coverage.

Here, the method of classifying the code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) stored in the queues for the same source codes as each other, You can classify by eigenvalue. When transmitting the code coverage log to the server 950, the plurality of devices 910 and 930 shown in FIG. 10 may transmit the unique value of the code coverage log together with the code coverage log. The eigenvalues 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 whether or not each of a plurality of portions in the code coverage log is tested. Thus, the server 950 can use code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) and their respective unique values to generate code coverage logs log_1 - 1, log_1 - 2, log_1 - 3, log_2 - 1, log_2 - 2, log_2 - 3). When classifying all the code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) stored in the queue in this manner, the first code coverage logs log_1-1 , log_1-2 and log_1-3 have the same eigenvalues and the second code coverage logs log_2-1, log_2-2, log_2-3 have the same eigenvalues, .

All the code coverage logs (log_1-1, log_1-2, log_1-3, log_2-1, log_2-2, log_2-3) stored in the queue are classified according to their eigenvalues, The code coverage value of the measurement target source code can be calculated.

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

The program instructions recorded on the computer-readable recording medium may be those specially designed and constructed for the present invention or may be those known to those skilled in the art of computer software.

Examples of the computer-readable recording medium include magnetic media such as a hard disk, a floppy disk and a magnetic tape, optical recording media such as CD-ROM and DVD, magneto-optical media such as a floptical disk, 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 machine language code such as those generated by a compiler, as well as 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 for performing the process according to the present invention, and vice versa.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of limitation, It will be understood that various changes and modifications may be made without departing from the spirit and scope of the invention. For example, each component specifically shown in the embodiments can be modified and implemented. It is to be understood that all changes and modifications that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims (10)

A method for measuring code coverage of a source code,
Inserting a probe into the source code;
Generating an executable file by compiling the source code into which the probe is inserted; And
And measuring the code coverage using the generated executable file,
Wherein inserting the probe into the source code comprises:
Generating an abstract syntax tree from the source code;
Analyzing 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 according to claim 1,
Wherein inserting the probe into the source code using the abstract syntax tree and the control flow graph comprises:
Inserting a first probe for each base path after searching the base paths in the control flow graph; And
Determining a number of branch condition conditions in the abstract syntax tree and inserting a second probe;
/ RTI &gt; 3. The method of claim 2,
Wherein the step of determining the number of branch condition conditions in the abstract syntax tree and inserting the second probe comprises:
Replacing a logical operator existing in a branch statement where the number of conditions is two or more with a ternary operator and inserting the second probe. The method according to claim 1,
Prior to inserting the probe into the source code,
Further comprising the step of determining whether the source code has previously performed compilation,
If the source code has already been compiled, the preparation process for measuring the code coverage by reusing the existing executable file is omitted
, Code coverage measurement method. 5. The method of claim 4,
Wherein the step of determining whether the source code has previously performed compilation comprises:
Preprocessing the source code to generate a preprocessed source code;
Removing noise of the preprocessed source code;
Generating an eigenvalue of the noise-removed preprocessed source code;
Determining whether the generated eigenvalue is equal to a previously stored previous eigenvalue;
If the generated eigenvalue is equal to the previous eigenvalue, the code coverage is measured using the existing executable file,
And inserting the probe into the source code if the generated eigenvalue differs from the previous eigenvalue. A method for measuring code coverage of a source code,
Determining whether the source code has substantially changed;
Measuring the code coverage of the modified source code if the source code has substantially changed; And
If the source coat has not substantially changed, outputting an existing code coverage value;
/ RTI &gt; The method according to claim 6,
Wherein the step of determining whether the source code has substantially changed comprises:
Preprocessing the source code to generate a preprocessed source code;
Generating function-specific eigenvalues in the preprocessed source code;
Comparing the generated function-specific eigenvalues with previously stored eigenvalues of each function to determine whether there is at least one changed function; And
And classifying the changed function and the unmodified function if at least one of the generated eigenvalues of each function is changed,
Wherein measuring the code coverage of the altered source code, when the source code has substantially changed, calls the function coverage value of the unaltered function to calculate the code coverage of the altered source code. A method for measuring code coverage by a server receiving code coverage logs collected from a plurality of devices,
Storing code coverage logs received from the plurality of devices in a queue in time sequence; And
Measuring the code coverage using the code coverage logs stored in the queue;
/ RTI &gt; 9. The method of claim 8,
Prior to calculating the code coverage,
Further comprising the step of classifying code coverage logs stored in said queue for those of the same source code. A computer-readable recording medium having recorded thereon a program for executing a code coverage measurement method according to any one of claims 1 to 9.

Images