JPH06103113A - Differential test debugging support method - Google Patents

Abstract

PURPOSE:To efficiently execute debug by excluding the whole or a part of a program whose reliability is secured already from the object of test debug. CONSTITUTION:In the correction step 208 of a source program, the source program is corrected by setting a source program 207 as input information. Subsequently, in an object module generation step 210, the object module 211 of the corrected program is generated by setting a corrected source program 209 as input information. Also, in a test execution step 212, a test is executed by using an existing test debug supporting program. In this case, in coverage information before the test is executed, by instructing information generated by the object module 211, in the value of the number of times of execution which is set immediately after a coverage information accumulation file 205 is generated, the value to an unconnected part is preserbed continuously after it is complied, and only the instruction sentence of the corrected part is executed.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a differential test debug support method for testing program reliability,
In particular, when reusing or maintaining an existing completed or semi-completed program, labor saving of the test debug of the part where reliability is already guaranteed, the difference test designed to improve work efficiency. It relates to a debugging support method.

[0002]

2. Description of the Related Art Conventionally, as one of the methods for efficiently testing the reliability of a created program,
There is a program for test debug support called "COBOL85 / TD".

This "COBOL85 / TD" has a function of acquiring and accumulating test coverage information. The test coverage information is information such as the number of times each statement is executed after the program is executed.

In a test using such a test debug support program, the test coverage information is analyzed,
It has a function to quantitatively show the progress of debugging by using the execution status of the statement of the program under test as the coverage measurer. Therefore, when performing test debugging, it is general to grasp the execution status of each statement based on the coverage information and recognize the statement that needs to be tested in the future.

In this case, however, when the program is modified, it is important to store the coverage information before the modification. This is because if the information of the already tested (confirmed) portion is lost by the correction of a very small part of the program, it is necessary to test all the command statements of the program every time the program is modified. If the coverage information before the correction is not stored, it means that the test for the same statement is repeated, which is a major obstacle to improving the efficiency of test debugging. Become.

As one method for solving this problem, when the program is modified, the coverage information of the uncorrected portion is stored in addition to the existing information, and only the coverage information of the modified portion is replaced with the existing information. As for an uncorrected and executed statement, there is a statement in which the coverage information is saved to prevent the duplication of the test and improve the efficiency of the test debug.

On the other hand, as one of the methods for efficiently developing a program, there is a method of using a program generator using a dictionary in which data items and data names are defined.

Generally, this kind of program generator prepares a standard pattern as a skeleton of a program,
Based on this, by adding the program specification information, the target program is automatically generated.

However, in this generation method, from the viewpoint of the input / output unit of the program, it is possible to generate the processing in file and record units, but it is impossible to generate the processing in item unit, which is the minimum unit. Is. For this reason,
A general program generator has a low rate of automatic program generation, and it is difficult to improve work efficiency of program development.

As one method for solving this problem, the IPSJ 41st (second half of 1990) National Conference Proceedings, 5th volume, pages 5-205 to 5-206, is discussed. There is a program generator that automatically generates a process for each item by developing a dictionary that defines a process related to an item and acquiring information of this dictionary when generating a program.

According to this program generator, a program with a high degree of perfection and a highly reliable guarantee is generated.

[0012]

However, according to the conventional test debug support program in which only the coverage information of the corrected portion is replaced with the existing information, the program to be tested is proposed in the Information Processing Society of Japan. For example, when you want to reuse a complete or semi-complete program with a high degree of completeness and a high degree of reliability, which is generated by a program generator such as However, even though the reliability of the generated part and the reusable part is already guaranteed, it is necessary to execute all the statement statements as the target of test debug. In terms of "do", it was impossible to avoid duplication of test debugging work.

An object of the present invention is to provide a differential test debug support method capable of efficiently debugging by removing all or part of a program whose reliability is already guaranteed from the target of test debug.

[0014]

In order to achieve the above object, the differential test debug support method of the present invention provides a coverage information storage file for an existing completed or semi-finished program, and the coverage information storage file is provided. After setting the information that the test execution has been completed for each command statement, when the program is changed, only the coverage information of the changed part is set to the test unexecuted state, and only the changed statement is executed as the test target. It was made to let.

[0015]

According to the above means, when the program is automatically generated or the existing program is reused, the information of the test execution has been set for each command statement in the coverage information storage file.

Therefore, in the coverage information of the test target program immediately after generation or immediately after copying the existing program for reuse, it is recognized that all the command statements have been executed, and the test of the automatically generated portion or unmodified portion is performed. Is omitted.

As a result, it is possible to improve the efficiency of the test work when the program is automatically generated or the existing program is reused, and it is possible to improve the efficiency of the program development.

Furthermore, when a correction is made to an automatically generated program or a program obtained by copying an existing program, the coverage information up to the present is stored for the uncorrected portion, and the correction contents for the corrected portion are stored. Accordingly, the coverage information up to the previous time is set to the test non-execution state by, for example, invalidating, deleting, or adding. Therefore, after the program is modified, only the modified statement does not have coverage information, so the modified statement is executed as a test target, which improves the efficiency of test debugging and, in turn, the efficiency of program development. it can.

[0019]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described in detail below with reference to illustrated embodiments.

FIG. 1 is a general equipment configuration diagram of a computer for carrying out the present invention, which comprises a CPU 1, a memory 2, an external storage device 3, an input device 4, a display device 5, and a printer 6.

FIG. 2 is a flow chart showing the processing procedure of the first embodiment of the present invention, and FIG. 3 is a functional schematic diagram for realizing this embodiment. Based on the flow chart of FIG. Each step will be described.

First, in the object module generation step 202, the source program 201 is used as input information and the object module 203 is generated using an existing compiler (step 101 in FIG. 2).

Next, in the coverage information storage file generation step 204, the coverage information storage file 205 is generated by starting the existing test debug support program using the object module 203 as input information (step 102 in FIG. 2). ). This uses the "function of automatically generating a coverage information storage file of the program under test when it is started up" built in an existing test debug support program.

Further, the execution count setting processing step 20
In step 6, in the coverage information storage file 205, a value of "1" or more is set as the number of times of execution for all command statements according to the command type (step 103 in FIG. 2). This means that the executed information is set in all the command statements immediately after the coverage information storage file 205 is generated.

Then, it is judged whether or not the program needs to be modified (step 104 in FIG. 2), and if it does not need to be modified, the process ends, and if it needs to be modified, the following steps are continued.

First, the correction step 2 of the source program
In 08, the source program 207 is used as input information,
The source program is modified using an existing editor (step 105 in FIG. 2).

Next, in the object module generation step 210, the modified source program 209 is used as input information to generate an object module 211 of the modified program using a compiler (step 106 in FIG. 2).

When the compiler is executed, the "differential coverage function" of the compiler is used. As a result, the object module 211 has, in the coverage information storage file 205, instruction information to save the existing coverage information for the uncorrected portion and delete the existing coverage information for the corrected portion. Is generated.

Further, in the test execution step 212,
A test is performed using an existing test debug support program (step 107 in FIG. 2). In this case, in the coverage information before the test execution, the object module 21
According to the instruction information generated in step 1, among the values of the number of executions set immediately after the coverage information storage file 205 is generated, the one for the uncorrected part is saved even after compiling, and the command statement for the corrected part is deleted. Therefore, only the modified statement is executed. As a result, in the coverage information storage file 213 after the test execution, the value of the number of execution times of all the command statements is set to "1" or more, all the commands are executed, and the command statements of the entire program are recognized as already executed. it can.

Finally, it is judged whether or not the test debug is completed (step 108 in FIG. 2), and if completed, the process is ended.

When the test debug is not completed, there are two cases, that is, there is an unexecuted statement, and there is a case where the program needs to be corrected.

If there is an unexecuted statement, the test is repeated until there is no unexecuted statement, and if the program needs to be modified, the steps from the program modification to the test are repeated.

FIG. 4 shows the coverage information storage file 205.
It is a figure which shows the example of a structure of the coverage information storage file 2
05 is a master table 401 and a count table 404
It is composed of two tables.

Of these, as shown in FIG. 5, the master table 401 has a program name 501 and a test count 502.
In addition to the above information, the number of executable statements 503, which is the number of executable statements in the entire program, the number of executed statements 504, which is the number of executed statements, in the entire program, Number of executable branches 505 that is the number of executable branches, Number of executed branches 506 that is the number of executed branches, C0 measure 507 that is the ratio of the number of executed statements to the number of executable statements, and Number of executed branches It is composed of a C1 major 508 which is a ratio to the number of executable branches.

On the other hand, the count table 402, as shown in FIG. 6, is an element 60 for storing information for each statement.
It is an aggregate of 1,602 .... Therefore, the size of the count table 402 is not fixed because it depends on the number of command statements of the program.

The element 601 includes a location column 603 for storing a location number indicating the position of an instruction sentence in a program, an instruction type column 604 for storing a code indicating the type of instruction, and a count entry column 605 for storing the number of times the instruction sentence is executed. Composed of. Count entry column 6 at the time of generation of the coverage information storage file 205
In 05, “0” is set as the initial value of the number of executions. Note that some command statements do not need to count the number of executions depending on the type, and the element 602 for such a command statement does not have a count entry column, and only the location column 606 and the instruction type column 607 are used. Composed.

FIG. 7 shows an example of the source program, and FIG. 8 shows the count table 402 of the coverage information storage file 205 for the source program of FIG.
Is an example of.

In this example, in the execution count setting processing step 206 of FIG. 3, the source program is analyzed for the value of the count entry column 605 in which the initial value “0” is set, and the value is determined according to the instruction type of each statement. Reset to the value in Figure 8
Make a count entry as shown in. The present processing focuses on the fact that the count entry is based on the value of the count entry when determining whether or not an instruction statement that needs to count the number of executions has been executed.

For example, in FIG. 7, nine command statements 7
There are 01 to 709. Therefore, nine elements 801 to 809 are generated in the count table of FIG. Of these nine elements 501-809, 4,
The sixth and eighth elements 804, 806, and 808 have no count entry column because it is determined that it is not necessary to count the number of executions depending on the instruction type. Other elements 801, 802, 803, 805, 807, 80
In 9, after analyzing the source program, a value of "1" or more is set in the count entry column according to the value of the instruction type column of each element.

By this processing, it is possible to recognize that all the command statements have been executed without actually testing the program.

FIG. 9 shows an example in which the source program shown in FIG. 7 is modified, and FIG. 10 shows an example of the contents of the count table 402 of the coverage information storage file 205 for the source program shown in FIG.

In the object module generation processing step 210 of FIG. 3, of the count entries of the count table 402 of FIG. 8 in which all instructions are set as already executed, the count entry corresponding to the modified statement is “not executed”. Set to.

The present invention focuses on the differential coverage function of the test debug support program, that is, "preserves uncovered coverage information and deletes or invalidates existing coverage information and newly obtains it." It was done.

For example, the source program shown in FIG.
In the source program, the second statement 702 is deleted, and the fifth and seventh statement 705, 707 are changed.
This is a modification in which one statement is added after the eighth statement 708.

With the modification of this program, the count table 402 shown in FIG. 8 is deleted from the second element 802 and the fifth and seventh elements 80.
5, 807 is changed, and a new element is added after the eighth element. As a result, the count table 402 shown in FIG. 8 is changed to the count table 402 shown in FIG. .

Here, the element 1 (801) of FIG.
3 (803), 4 (804), 5 (805), 6 (80
6), 7 (807), 8 (808), 9 (809)
Elements 1 (1001) and 2 (100 in FIG.
2), 3 (1003), 4 (1004), 5 (100
5), 6 (1006), 7 (1007), 9 (100
It corresponds to 9).

On the other hand, the element corresponding to the element 2 (802) in FIG.
, And element 8 (100
8) is newly created by the addition of the imperative sentence, the corresponding element does not exist in FIG.
Then, in the count table 402 of FIG. 10, the value (1012, 1013, 1014) of the count entry of the element for the changed and added statement is “0”.
, And the element count entry values (1010, 1011, 1015) for the unmodified statement are stored.

As described above, in the count table 402, the element corresponding to the deleted statement is deleted. Also, the value of the count entry of the element corresponding to the changed statement is set to the value "0" indicating that the previous execution count value is invalid. Further, with respect to the added statement, a corresponding element is newly created, and the count entry value is set to the initial value “0”. Then, as for the count entry of the uncorrected portion, the information set from before is stored as it is.

Therefore, in this processing, only the value of the number of executions of the corrected instruction becomes "0" among the values of the number of executions set immediately after the coverage information storage file 205 is generated.

FIG. 11 shows an example of the contents of the count table 402 after the test execution of the source program shown in FIG. 9. In the test execution step 212 of FIG. 3, the differential coverage of the test debug support program is held. With the function, the number of executions of each actually executed statement is added to the count entry of each corresponding element of the count table.

For example, the test execution step 212 of FIG.
, The first, second, fourth, eighth and ninth command statements 901, 902, 904, 908 and 909 shown in FIG. 9 are executed once and the sixth command statement 906 is not executed. Count table 40 after program modification of 10
2, 1, 2, 4, 8, corresponding to the executed statement
9th element 1101, 1102, 1104, 1
Count entry values 1110,1 of 108,1109
111, 1112, 1114, 1115 are all "1"
Value of the count entry of the sixth element 1106 corresponding to the unexecuted statement
Only 3 is “0”, which is the same as before the test execution. That is, in the count table 402 shown in FIG. 10, only the value 1113 of the count entry of the element 1106 corresponding to the modified portion and corresponding to the sixth statement 906 that is not actually executed is “0”. .

As described above, by actually performing the test and executing the command statement corresponding to the modified portion, it becomes possible to set the numerical value of "1" or more to the count entry of the element for all the command statements. . Therefore, by executing only the command statement corresponding to the modified part, all the command statements can be recognized as already executed.

According to this embodiment, before executing the test, all the command statements are set by setting the count entry of each element of the count table 402 to a value of "1" or more as the execution count of the command statement. By combining the process of making it recognized as execution and the existing differential coverage function, it becomes possible to recognize all the command statements as already executed only by actually executing the modified statement, and test debugging in program development. The efficiency of can be improved.

FIG. 12 is a flow chart showing the second embodiment. This embodiment is step 101 shown in the example of FIG.
This is the same as the embodiment shown in the example of FIG. 1 except that step 100 is added as a step before the step.

In this embodiment, step 100 is an existing program generation tool. According to the embodiment, by linking the existing program automatic generation tool with the first embodiment, in the new development of the program, it is possible to save labor by linking a series of steps from generation to testing. In addition, development efficiency can be improved by efficient test debugging utilizing the high program generation rate.

In the above-described embodiment, the case where the value of the count entry is set to "1" or more is assumed to have been executed, but it may be indicated by a flag whether or not it has been executed.

[0057]

As described above, according to the differential test debug support method of the present invention, for a program whose reliability has already been assured, the test execution information is set for each statement in the coverage information storage file. However, when a change is made to the program, only the coverage information of the changed part is set to the test unexecuted state, and only the changed part's statement is executed as the test target. Alternatively, when the existing program is reused, the test of the automatically generated part or the unmodified part is omitted, and the statement of only the modified part is executed as the test target. As a result, it is possible to improve the efficiency of the test work when the program is automatically generated or the existing program is reused.

[Brief description of drawings]

FIG. 1 is a schematic configuration diagram of a computer system that implements the present invention.

FIG. 2 is a flowchart showing a processing procedure in the first embodiment of the present invention.

FIG. 3 is a functional schematic diagram showing a system configuration for realizing the first embodiment.

FIG. 4 is an explanatory diagram showing a structural example of a coverage information storage file.

FIG. 5 is an explanatory diagram showing a structural example of a master table.

FIG. 6 is an explanatory diagram showing a structure example of a count table.

FIG. 7 is an explanatory diagram showing an example of a source program.

8 is an explanatory diagram showing an example of a count table of coverage information storage files for the source program of FIG. 7. FIG.

FIG. 9 is an explanatory diagram showing an example of a corrected source program.

10 is an explanatory diagram showing an example of a count table of coverage information storage files for the source program of FIG.

FIG. 11 is an explanatory diagram showing an example of a count table after a test is executed.

FIG. 12 is a flowchart showing a processing procedure in the second embodiment of the present invention.

[Explanation of symbols]

201 ... Source program, 205 ... Coverage information storage file, 206 ... Execution count setting process step, 21
2 ... Test execution step, 401 ... Master table, 4
02 ... Count table, 606, 607 ... Count entry.

Front Page Continuation (72) Inventor Yosuke Morioka 12 890 Kashimada, Saiwai-ku, Kawasaki-shi, Kanagawa 12 Information Systems Development Division, Hitachi, Ltd.

Claims (1)

[Claims] 1. A coverage information storage file is provided for an existing completed or semi-completed program, and after the test execution information is set for each command statement in this coverage information storage file, the program is changed. Is a differential test debugging support method characterized in that only the coverage information of the changed portion is set to the test non-execution state, and only the statement of the changed portion is executed as the test target.