Program bug identification device

Abstract

To provide a program bug identification device with which it is possible to identify a bug in a program after migration generated by converting the program language of a program before migration.SOLUTION: A program bug identification device 1 comprises: an execution result comparison unit 23 which, on the basis of the dependency relation of instructions for the output variable of a program 11 before migration that is analyzed from an assumed per-test case execution result table T1 and the dependency relation of instructions for the output variable of a program 12 after migration that is analyzed from a per-test case execution result table T2, outputs, for each test case, the comparison result of variable values of output variables of the program 11 before migration and the program 12 after migration and the comparison result of instruction execution sequences of the program 11 before migration and the program 12 after migration; and an error probability calculation unit 24 which calculates error probability for each instruction of the program 12 after migration on the basis of the comparison results.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a program error identification device. [Background technology]

[0002] Conventionally, when creating a post-migration function, a test case table is generated to comprehensively execute the instructions in the pre-migration function. The user generates test code based on the test case table and collects the test results by executing the test code on the post-migration function. If the verification results indicate a failure, the user determines that there is a defect in the post-migration function.

[0003] Patent document 1 states that "a first variable is converted into a specific second lexical phrase corresponding to a specific first lexical phrase that matches the first variable, a destination second variable containing the specific second lexical phrase and its data type are obtained, the first variable that matches the specific first lexical phrase is replaced with the destination second variable, the data type of the destination second variable is added to the destination second variable, and the first test specification where the replacement and addition have been performed is output as a second test specification." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2022-90770 Summary of the Invention [Problem to be solved by the invention]

[0005] However, even if the user finds from the test execution results that there is an error in the migrated function itself, he or she cannot know where in the migrated function the defect that caused the error is located. In addition, the conventional technology described in Patent Document 1 aims to improve the efficiency of testing a new program that has been software-migrated from an old program, and is based on the premise that the logic of the old program is correctly copied into the new program. Therefore, even if a defect occurs in the new program, the defect cannot be identified.

[0006] The present invention has been made in view of the above circumstances, and has an object to identify defects in a post-migration program that is generated by converting the programming language of a pre-migration program. [Means for solving the problem]

[0007] The program defect identification device of the present invention includes an execution result comparison unit that outputs a comparison result of the variable values ​​of the output variables of the pre-migration program and the post-migration program and a comparison result of the instruction execution sequences of the pre-migration program and the post-migration program, compared for each test case, based on the instruction dependencies on the output variables of the pre-migration program analyzed from the assumed execution results of testing the pre-migration program created in a first programming language for each test case, and the instruction dependencies on the output variables of the post-migration program analyzed from the execution results of testing the post-migration program created in a second programming language for each test case, and an error probability calculation unit that calculates an error probability for each instruction of the post-migration program based on the comparison results. Effect of the Invention

[0008] According to the present invention, since the error probability is calculated for each instruction of the post-migration program, it is possible to identify instructions with a high error probability as having a defect. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0009] [Figure 1] 1 is a block diagram showing an example of the overall configuration of a program defect identifying device according to an embodiment of the present invention; [Diagram 2] 1A to 1C are diagrams illustrating examples of a pre-migration program, a post-migration program, and a post-migration program with an error probability according to an embodiment of the present invention. [Diagram 3] 1A and 1B are diagrams illustrating an example of a configuration of an assumed execution result table for each test case according to an embodiment of the present invention, and examples of commands executed for each test case. [Figure 4] 1A and 1B are diagrams illustrating an example of a configuration of a test case execution result table according to an embodiment of the present invention, and examples of commands executed for each test case. [Diagram 5] 11 is a diagram showing an example of the configuration of a dependency instruction classification table for each test case output variable according to an embodiment of the present invention; FIG. [Figure 6] 11 is a diagram showing an example of the configuration of an assumed dependency instruction table for each test case output variable according to an embodiment of the present invention; FIG. [Figure 7] FIG. 2 is a diagram showing an example of a configuration of a variable name correspondence table according to an embodiment of the present invention. [Figure 8] FIG. 11 is a diagram showing an example of the configuration of a row number correspondence table according to an embodiment of the present invention. [Figure 9] FIG. 13 is a diagram showing an example of a configuration of a comparison table of execution results for each test case output variable according to an embodiment of the present invention. [Figure 10] FIG. 2 is a diagram showing an example (1) of a row number error probability table according to an embodiment of the present invention. [Figure 11] FIG. 13 is a diagram showing a configuration example (2) of a row number error probability table according to an embodiment of the present invention. [Figure 12] FIG. 2 is a block diagram showing an example of the hardware configuration of a computer according to an embodiment of the present invention. [Figure 13] 2 is a flowchart illustrating an example of a program defect identification method according to an embodiment of the present invention. [Figure 14] FIG. 13 is a diagram illustrating an example of a pre-migration program and a post-migration program. [Figure 15]1A to 1C are diagrams illustrating examples of a conventional assumed execution result table for each test case, an execution result table for each test case, and an execution result comparison table for each test case. [Figure 16] 1A to 1C are diagrams illustrating examples of an expected execution result table for each test case, an execution result table for each test case, and an execution result comparison table for each test case output variable according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In this specification and the drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant description will be omitted.

[0011] [One embodiment] FIG. 1 is a block diagram showing an example of the overall configuration of a program defect identification device 1 according to an embodiment. In the following description, the pre-migration program language is COBOL language, and the post-migration program language is Java (registered trademark). A program written in COBOL language is called a pre-migration program, and a program written in Java language is called a post-migration program. An instruction written in the pre-migration program is written in the post-migration program in a format specified in the post-migration program, and is created so as to perform the same processing. Converting the pre-migration program to the post-migration program in this manner is called "migration." Conversion from the pre-migration program to the post-migration program is automated, but the user may convert manually.

[0012] The program defect identification device 1 has a function of detecting errors contained in a post-migration program 12 that has been program-converted based on a pre-migration program 11 shown in Fig. 2, which will be described later, and outputting it as a post-migration program 13 with an error probability. An error contained in the post-migration program 12 is called a "defect." By having the program defect identification device 1 identify defects in the post-migration program 12, a user can efficiently debug the post-migration program 12, etc.

[0013] FIG. 2 is a diagram showing examples of a pre-migration program 11, a post-migration program 12, and a post-migration program 13 with error probabilities.

[0014] The pre-migration program 11 is written in COBOL language. The pre-migration program 11 describes the process of initializing the variable A on the second line, calculating the variable A with an instruction after branching based on the magnitude relationship between the variable X and 0 on the third to seventh lines, and calculating the variable B with an instruction after branching based on the magnitude relationship between the variable Y and 0 on the eighth to 12th lines.

[0015] The post-migration program 12 has its processes written in Java. In converting from COBOL to Java, each command in COBOL must be realized as a method in Java, and then the COBOL program must be rewritten into a Java program using the Java methods. The contents of the processes written in the post-migration program 12 are the same as those written in the pre-migration program 11, but there are two places where there is a high possibility of errors.

[0016] In the migrated program with error probability 13, an error probability is assigned to each line of command in the migrated program 12. For example, the second line of the migrated program with error probability 13 should actually have 0 assigned to it. However, the implementation of the initialize command shown in the migrated program with error probability 13 is incorrect and the behavior of the initialize command is incorrect, so 2 is assigned to the output variable a. The cause of this is presumed to be that in the migrated program 12, the content in which the COBOL initialize command was realized as a Java method was incorrect. Therefore, the second line of the migrated program with error probability 13 is assigned an error probability of "error in command implementation" and is highlighted with highlight 13a.

[0017] Also, the 8th line of the post-migration program with error probability 13 should be written as "isGreaterThanEqual", but it is written as "isLessThanEqual". Therefore, the instruction on the 8th line is given an error probability of "error in the conversion result" and is highlighted with highlight 13b.

[0018] In this way, the command lines with the highest error probabilities for both the instruction implementation error and the conversion result error are highlighted with highlights 13a and 13b. In other words, the command lines with a relatively high error probability compared to other command lines are highlighted in the migrated program with error probabilities 13. Note that it is optional whether or not the command lines in the actual migrated program with error probabilities 13 are highlighted with highlights 13a and 13b.

[0019] 1, the program bug identification device 1 continues to be described. The program bug identification device 1 includes a test execution unit 21, a variable instruction dependency analysis unit 22, an execution result comparison unit 23, an error probability calculation unit 24, and an error probability display unit 25.

[0020] The test execution unit 21 reads the post-migration program 12 and executes a unit test corresponding to the post-migration program 12 for each test case. For example, the test execution unit 21 sets an input value for a method to be tested and executes the method to be tested. After executing a test, the test execution unit 21 collects an execution instruction sequence and an output value as an execution result. An execution instruction sequence is an arrangement of instructions extracted and executed in a test when the test is executed. Therefore, if only one instruction is executed, the execution instruction sequence corresponds to only that one instruction, but if multiple instructions are executed, the execution instruction sequence includes those multiple instructions. The results of the test executed by the test execution unit 21 for each test case are output as a test case execution result table T2.

[0021] Here, the expected execution result table T1 for each test case will be described with reference to FIG. 3 is a diagram showing an example of the configuration of a test case-specific expected execution result table T1 and an example of commands executed for each test case. Here, for each test case, various values ​​are input to the pre-migration program 11, and after the commands are executed, the expected output values ​​that are expected to be output will be described.

[0022] The test cases and input values ​​assumed in the table T1 of expected execution results for each test case are automatically created by a test tool or manually created by a user. The test tool, for example, traces the execution instructions of the post-migration program 12 for each conditional branch and creates valid input values ​​as test cases for each instruction executed according to the conditional branch.

[0023] The assumed execution result table T1 for each test case has fields for a test case ID, an input value input to the pre-migration program 11, an assumed execution instruction sequence indicating the order of instructions executed in the pre-migration program 11, and an assumed output value.

[0024] A test case ID is a unique ID assigned to each test case. In this example, three test cases are created, so the test case IDs are "#1", "#2", and "#3". The input values ​​are all capital letters X, Y, and B. The expected output values ​​are all capital letters A and B.

[0025] Next, the commands assumed to be executed in the post-migration program 12 and the assumed output values ​​will be described for each test case. (Test case ID=#1, input values: X=1, Y=0, B=2) In execution command line 2, A is initialized and 0 is assigned to A. In execution command line 3, it is determined whether X>0. Since the input X is 1, which is greater than 0, in execution command line 4, 1 is added to A and the output value A is calculated to be 1. Next, in execution command line 8, it is determined whether Y>0. Since the input Y is 0, in execution command line 9, 2 is added to B and the output value B is calculated to be 4.

[0026] (Test case ID=#2, input values: X=0, Y=0, B=2) In execution line 2, A is initialized and 0 is assigned to A. In execution line 3, it is determined whether X>0. Since the input X is 0, in execution line 6, 1 is subtracted from A and the output value A is calculated as -1. Next, in execution line 8, it is determined whether Y>0. Since the input Y is 0, in execution line 9, 2 is added to B and the output value B is calculated as 4.

[0027] (Test case ID=#3, input values ​​are X=0, Y=-1, B=2) In execution command line 2, A is initialized and 0 is assigned to A. In execution command line 3, it is determined whether X>0. Since the input X is 0, in execution command line 6, 1 is subtracted from A and the output value A is calculated as -1. Next, in execution command line 8, it is determined whether Y>0. Since the input Y is -1, in execution command line 11, 2 is subtracted from B and the output value B is calculated as 0.

[0028] The portion including the migrated program 12 and the test execution unit 21 may be provided as a test device 2 separate from the program bug identification device 1 .

[0029] FIG. 4 is a diagram showing an example of the configuration of the test case execution result table T2 and an example of an instruction executed for each test case.

[0030] Test case execution result table T2 has items of test case ID, input value input to post-migration program 12, execution instruction sequence indicating the instruction sequence of instructions executed in post-migration program 12, and output value.

[0031] The test case IDs are "#1", "#2", and "#3", the same as those in the expected execution result table T1 for each test case. The input values ​​are all lowercase x, y, and b. The input values ​​of x, y, and b for each test case are the same as the input values ​​of X, Y, and B in the expected execution result table T1 for each test case in Figure 3. The output values ​​are all lowercase a and b.

[0032] Next, the commands executed in the post-migration program 12 and the output values ​​are explained for each test case. All of the test cases explained below contain an "instruction implementation error" in which 0 should be assigned to execution command line 2, but 2 is assigned due to an error in the implementation of the initialize command.

[0033] (Test case ID=#1, input values ​​are x=1, y=0, b=2) In execution code line 2, a is initialized and 2 is assigned to a. In execution code line 3, it is determined whether x>0. Since the input x is 1, which is greater than 0, in execution code line 4, 1 is added to a and the output value of a is calculated to be 3. Next, in execution code line 8, it is determined whether y≦0. Since the input y is 0, in execution code line 9, 2 is added to b and the output value of b is calculated to be 4.

[0034] (Test case ID=#2, input values ​​are x=0, y=0, b=2) In execution code line 2, a is initialized and 2 is assigned to a. In execution code line 3, it is determined whether x>0. Since the input x is 0, in execution code line 6, 1 is subtracted from a and the output value a is calculated to be 1. Next, in execution code line 8, it is determined whether y≦0. Since the input y is 0, in execution code line 9, 2 is added to b and the output value b is calculated to be 4.

[0035] (Test case ID=#3, input values ​​are x=0, y=-1, b=2) In execution code line 2, a is initialized and 2 is assigned to a. In execution code line 3, it is determined whether x>0. Since the input x is 0, in execution code line 6, 1 is subtracted from a and the output value of a is calculated to be 1. Next, in execution code line 8, it is determined whether y≦0. Since the input y is -1, in execution code line 9, 2 is added to b and the output value of b is calculated to be 4.

[0036] Returning to FIG. 1, the description of the program error identifying device 1 will be continued. The variable instruction dependency analysis unit 22 analyzes the dependency of instructions for variables described in the pre-migration program 11 and the dependency of instructions on which variables described in the post-migration program 12 depend, based on the test case-specific assumed execution result table T1 and the test case-specific execution result table T2. The dependency between variable instructions will be described with reference to the test case-specific assumed execution result table T1 shown in FIG. 3. The "dependent instruction" includes two types of instructions: an instruction to manipulate the value of an output variable, and an instruction to control whether or not to execute the instruction to manipulate the value. The output variable A in the test case ID=#1 is assigned in instruction line 4, conditionally branched in instruction line 3, and initialized in instruction line 2. In other words, the instruction lines 4, 3, and 2, which are executed in reverse order from the perspective of the output variable A, are called dependent instructions. In this way, the dependent instructions are identified by tracing back the instructions to be traced until the output value is stored in the output variable.

[0037] The variable instruction dependency analysis unit 22 performs data flow analysis of the input test case execution result table T2 and test case assumed execution result table T1 to obtain instructions that depend on the variables of the specified instruction. After that, the variable instruction dependency analysis unit 22 outputs a test case output variable dependent instruction classification table T3 and a test case output variable assumed dependent instruction classification table T4.

[0038] 3 and 4, the expected output value for each test case expected in the pre-migration program 11 may differ from the output value for each test case executed in the post-migration program 12. Therefore, the variable instruction dependency analysis unit 22 analyzes the dependency between variable instructions. Since the expected execution results are defined for multiple variables in the test case, the variable instruction dependency analysis unit 22 verifies whether or not the expected execution results of the pre-migration program 11 and the execution results of the post-migration program 12 match.

[0039] Next, a configuration example of the dependency command classification table T3 for each test case output variable will be described with reference to FIG. 5, and a configuration example of the assumed dependency command classification table T4 for each test case output variable will be described with reference to FIG.

[0040] 5 is a diagram showing an example of the configuration of dependency command classification table T3 for each test case output variable. Dependency command classification table T3 for each test case output variable is a table in which commands related to output variables a and b output in the post-migration program 12 are classified by command class and test case. Dependency command classification table T3 for each test case output variable has the following items: command class ID, test case ID, output variable, dependency command, execution command sequence change command, and variable value change command.

[0041] The item "Command Classification ID" stores an ID assigned to each command classification. In Fig. 5, command classification IDs #1 to #6 are stored. The command classification classifies the relationship between the output variable and the command for each test case and each output variable. The Test Case ID field stores the test case ID that corresponds to the command classification ID. For example, when you look at the test case ID=#1, there are two types of output variables, a and b.

[0042] The output variables field stores output variables a and b for each test case ID. The dependent instruction field stores instructions on which the output variables a and b in the migrated program 12 depend. The dependent instructions are extracted, for example, by a data flow analysis performed by the variable instruction dependency analysis unit 22 on the execution instruction sequence of the migrated program 12. In addition, when the line number and variable to be analyzed are specified, the variable instruction dependency analysis unit 22 can also extract dependent instructions by using program slicing, which outputs instructions on which the result of the variable depends.

[0043] In addition, the variable instruction dependency analysis unit 22 separates the instructions on which the output variables depend by output variable, and classifies the instructions on which the output variables depend into conditional branch instructions that change the execution instruction sequence and variable value change instructions that change the variable values ​​of the output variables.

[0044] The item of the instruction to change the sequence of execution is stored with the instruction line of the last conditional branch instruction among the instructions on which the output variables a and b depend. Since the conditional branch instruction changes the sequence of execution instructions, this conditional branch instruction is called an instruction to change the sequence of execution instructions. The instruction for which the sequence of execution instructions is changed is extracted, for example, by the variable instruction dependency analysis unit 22 applying data flow analysis to the conditional branch instruction in the instructions on which the post-migration program 12 depends.

[0045] The item of the variable value change instruction stores an instruction sequence for changing the variable values ​​of the output variables a and b. The instruction sequence for changing the variable value is extracted, for example, by the variable instruction dependency analysis unit 22 applying data flow analysis to an instruction group excluding a conditional branch instruction among the dependency destination instructions.

[0046] Next, using test case ID=#1 as an example, an instruction on which output variable a in post-migration program 12 depends and an instruction on which output variable b depends will be described.

[0047] An example (1) of the migrated program 12 is shown in the lower left of Fig. 5. In the case of test case ID = #1, the dependent instructions of output variable a are 2, 3, and 4, and the dependent instructions of output variable b are 8 and 9. Therefore, the instruction lines 2, 3, 4, 8, and 9 stored in the dependent instruction items of instruction classification IDs #1 and #2 are highlighted as the dependent instructions of output variables a and b in the case of test case ID = #1.

[0048] In the instruction (2) on which the output variable a depends in FIG. 5, instruction lines 2, 3, and 4 stored in the item of the dependent instruction of instruction classification ID #1 are highlighted. In the instruction (3) on which output variable b depends in FIG. 5, instruction lines 8 and 9 stored in the item of the dependent instruction of instruction classification ID #2 are highlighted.

[0049] 6 is a diagram showing an example of the configuration of assumed dependency command classification table T4 for each test case output variable. Assumed dependency command classification table T4 for each test case output variable is a table in which commands related to output variables A and B assumed to be output in the pre-migration program 11 are classified for each command classification and test case. Assumed dependency command classification table T4 for each test case output variable has items for command classification ID, test case ID, output variable, and dependency command.

[0050] The command classification ID field stores IDs assigned to each command classification. In Fig. 5, command classification IDs #1 to #6 are stored. The Test Case ID field stores the test case IDs that correspond to the instruction classification. For example, if you look at test case ID=#1, there are two output variables, A and B, so there are two test case IDs.

[0051] The output variable field stores output variables A and B for each test case ID. The item of the dependent instruction stores the dependent instructions of the output variables A and B in the pre-migration program 11. The dependent instructions are extracted, for example, by data flow analysis or program slicing that the variable instruction dependency analysis unit 22 performs on the execution instruction sequence of the pre-migration program 11.

[0052] An example (1) of the pre-migration program 11 is shown in the lower left of Fig. 6. In the case of test case ID = #1, the dependent instructions of output variable A are 2, 3, and 4, and the dependent instructions of output variable B are 8 and 9. For this reason, the instruction lines 2, 3, 4, 8, and 9 stored in the dependent instruction items of instruction classification IDs #1 and #2 are highlighted as the dependent instructions of output variables A and B in the case of test case ID = #1.

[0053] In the instruction (2) on which output variable A depends in FIG. 6, instruction lines 2, 3, and 4 stored in the item of the dependent instruction of instruction classification ID #1 are highlighted. In the instruction (3) on which output variable B depends in FIG. 6, instruction lines 8 and 9 stored in the item of the dependent instruction of instruction classification ID #2 are highlighted.

[0054] Returning to FIG. 1, the description of the program error identifying device 1 will be continued. The execution result comparison unit 23 outputs a comparison result of the variable values ​​of the output variables of the pre-migration program 11 and the post-migration program 12, compared for each test case, and a comparison result of the instruction execution sequences of the pre-migration program 11 and the post-migration program 12. This comparison process is performed based on the dependency of instructions on the output variables of the pre-migration program 11 analyzed from a test case-by-test case assumed execution result table T1 in which tests of the pre-migration program 11 are assumed for each test case, and the dependency of instructions on the output variables of the post-migration program 12 analyzed from a test case-by-test case execution result table T2 in which tests of the post-migration program 12 are executed for each test case.

[0055] For example, the execution result comparison unit 23 uses the dependency command classification table T3 for each test case output variable, the assumed dependency command classification table T4 for each test case output variable, the variable name correspondence table T5, and the line number correspondence table T6 as inputs, and compares the output variables A and B of the pre-migration program 11 with the output variables a and b of the post-migration program 12. In this comparison process, the execution result comparison unit 23 checks corresponding variables in the pre-migration program 11 and the post-migration program 12 by referring to the variable name correspondence table T5. In addition, the execution result comparison unit 23 checks the line numbers of the execution instruction sequences in the pre-migration program 11 and the post-migration program 12 by referring to the line number correspondence table T6.

[0056] Here, examples of the configuration of the variable name correspondence table T5, the line number correspondence table T6, and the execution result comparison table for each test case output variable T7 will be described with reference to FIGS.

[0057] 7 is a diagram showing an example of the configuration of variable name correspondence table T5. Variable name correspondence table T5 is a table showing the correspondence between each variable described in pre-migration program 11 and post-migration program 12. Variable name correspondence table T5 has items for variable name ID, COBOL program, and Java program.

[0058] The variable name ID field stores an ID assigned to each variable name. In Fig. 7, variable name IDs #1 to #6 are stored. The COBOL program items store the variable names of MAIN SECTION, A, X, Y, and B. The Java program item stores the variable names main_section, a, x, y, and b.

[0059] 8 is a diagram showing an example of the configuration of line number correspondence table T6. Line number correspondence table T6 is a table showing the correspondence between line numbers for each instruction described in pre-migration program 11 and post-migration program 12. Line number correspondence table T6 has items for line number ID, COBOL program, and Java program.

[0060] The line number ID field stores IDs assigned to line numbers in the pre-migration program 11 and the post-migration program 12. In Fig. 8, line number IDs #1 to #12 are stored. The COBOL program item stores the line number of the instruction that corresponds to the line number ID. The Java program item stores the line number of the instruction that corresponds to the line number ID. In FIG. 8, the line numbers in the pre-migration program 11 (COBOL program) and the post-migration program 12 (Java program) match, but the line numbers may be different.

[0061] Fig. 9 is a diagram showing an example of the configuration of execution result comparison table T7 for each test case output variable. Execution result comparison table T7 for each test case output variable stores the result of comparing the dependency instructions for each instruction classification ID of dependency instruction classification table T3 for each test case output variable in Fig. 5 and assumed dependency instruction classification table T4 for each test case output variable in Fig. 6, and the result of comparing the output variables of assumed execution result table T1 for each test case in Fig. 3 and execution result table T2 for each test case in Fig. 4. Execution result comparison table T7 for each test case output variable has items of instruction classification ID, test case ID, output variable, execution instruction sequence, and variable value.

[0062] The command classification ID field stores a command classification ID. The test case ID field stores the test case ID. In the item of output variable, output variables a and b of the post-migration program 12 are stored. The contents of the command classification ID, the test case ID, and the output variables a and b are shown in the dependency command table classification table T3 for each test case output variable in FIG.

[0063] The execution instruction sequence field stores the result of whether the dependency instructions compared for each instruction classification ID match or not. The execution result comparison unit 23 compares the instruction on which the output variable described in the pre-migration program 11 depends with the instruction on which the output variable described in the post-migration program 12 depends, and stores the result of determining whether the execution instruction sequences of the pre-migration program 11 and the post-migration program 12 match or not in the execution instruction sequence field.

[0064] The variable value item stores the result of whether the variable values ​​of the output variables compared for each command classification ID match or mismatch. The execution result comparison unit 23 compares the command on which the output variable described in the pre-migration program 11 depends with the command on which the output variable described in the post-migration program 12 depends, and stores the result of determining whether the values ​​of the output variables described in the pre-migration program 11 and the post-migration program 12 match or mismatch in the variable value item.

[0065] Next, a comparison result between the execution instruction sequence and the variable value when the instruction classification ID is #1 or #2 and the test case ID is #1 will be described. Here, reference is made to the expected execution result table T1 for each test case in Fig. 3, the execution result table T2 for each test case in Fig. 4, the dependency command classification table T3 for each test case output variable in Fig. 5, and the expected dependency command classification table T4 for each test case output variable in Fig. 6.

[0066] (Instruction classification ID=#1) Focusing on output variable a in the migrated program 12, the execution instruction sequence of the instruction (2) on which output variable a in Figure 5 depends is 2, 3, 4, while the execution instruction sequence of the instruction (2) on which output variable A in Figure 6 depends is 2, 3, 4, so the execution instruction sequences match. On the other hand, the output value of output variable a in Figure 4 is 3, while the expected output value of output variable A in Figure 3 is 1, so the variable values ​​of output variable a do not match.

[0067] (Instruction classification ID=#2) Focusing on output variable b in the migrated program 12, the execution instruction sequence of the instruction (2) on which output variable b in Figure 5 depends is 8,9, and the execution instruction sequence of the instruction (2) on which output variable B in Figure 6 depends is 8,9, so the execution instruction sequences match. Also, the output value of output variable b in Figure 4 is 4, and the expected output value of output variable B in Figure 3 is 4, so the variable value of output variable a matches.

[0068] Returning to FIG. 1, the description of the program error identifying device 1 will be continued. The error probability calculation unit 24 calculates the error probability for each instruction of the post-migration program 12 relative to the pre-migration program 11 based on the comparison result using the execution result comparison table T7 for each test case output variable as input. The error probability calculation unit 24 also identifies defects in the post-migration program 12 based on the number of mismatches between the expected execution instruction sequence and the execution instruction sequence. For example, the error probability calculation unit 24 tallies up the instruction sequences executed in the post-migration program 12 that is the test target for all test cases, and identifies the instruction line number that is likely to contain an error.

[0069] The error probability calculation unit 24 calculates the lower limit of the confidence interval of the error probability as the error probability, and outputs an error probability table T8 for each line number including the error probability for each command line of the post-migration program 12. The user can check the error probability table T8 for each line number displayed on a display device 35 shown in Fig. 12, which will be described later. Here, a configuration example of the error probability table T8 for each line number will be described with reference to Fig. 10.

[0070] 10 is a diagram showing a configuration example (1) of error probability table T8 for each line number. Error probability table T8 for each line number is a table that stores, for each line number, the error probability calculated for each execution instruction of the migrated program 12 executed for each test case. Error probability table T8 for each line number has items for line number, total number of verifications, total number of errors, and lower limit of the confidence interval of the error probability. When the user does not want to check the sequence of execution instructions, but only wants to check the output values ​​of the total number of verifications, total number of errors, and the lower limit of the confidence interval of the error probability, the error probability table T8 for each line number is used.

[0071] The line number field stores the line numbers of the instructions for which test cases have been executed for each instruction classification in the pre-migration program 11 and the post-migration program 12. In the item of the total number of verifications, the item of "dependency command" in the dependency command classification table T3 for each test case output variable is referenced, and the number of line numbers stored in the dependency command is stored. The total number of errors item is the number of mismatches in the variable values ​​stored in the "execution instruction sequence" of the execution result comparison table T7 for each test case output variable.

[0072] The lower limit of the confidence interval of the error probability is stored in the field of the lower limit of the confidence interval of the error probability calculated based on the total number of verifications and the total number of errors. For example, the lower limit of the confidence interval of the binomial distribution calculated by Wilson's method is used as the lower limit of the confidence interval of the error probability. A confidence interval is an interval in which the probability that a certain instruction written in the post-migration program 12 is an error can be regarded as a reliable probability the larger the parameter for calculating the error probability is. For example, the probability of six errors for six events is more reliable than the probability of one error for one event.

[0073] 10 shows an example of a post-migration program 13 with an error probability. In the post-migration program 13 with an error probability, the instructions at line numbers 2 and 3, which are the maximum value of the lower limit of the confidence interval of the error probability, "43.85%, " are highlighted 13c and 13d.

[0074] 10 is displayed on the display device 35 of the program fault identification device 1. Based on the lines highlighted in the error probability table T8 for each line number, the user can easily check instructions with high error probabilities in the post-transition program 13 with error probabilities.

[0075] The total number of errors can be counted separately as "the number of errors in the execution instruction sequence" and "the number of errors in the variable value" based on the dependency instruction classification table T3 for each test case output variable. The reason for this is that an "error in the execution instruction sequence" is likely to be an error in the control syntax (such as an if conditional expression), whereas an "error in the variable value" is likely to be an error in a data assignment instruction (such as an instruction x=x-1). In other words, an instruction that is likely to contain an error is an instruction that will cause a discrepancy between the execution result and the expected result when the execution result of the pre-migration program 11 differs from the execution result predicted by executing the post-migration program 12.

[0076] Therefore, by counting the number of "errors in the execution instruction sequence" and the number of "errors in variable values" separately, as shown in the line number error probability table T8A in Fig. 11 described later, it becomes possible to identify the locations where there is a high possibility of an error and the errors for each content with high accuracy. Next, a configuration example (2) of the line number error probability table T8A will be described with reference to Fig. 11.

[0077] FIG. 11 is a diagram showing a configuration example (2) of a line number error probability table T8A. The line number error probability table T8A has the same contents as the line number error probability table T8 shown in FIG. 10, but the items are subdivided. The line number error probability table T8A is a table that stores, for each line number, the error probability calculated for each executable instruction of the post-migration program 12 executed for each test case. This line number error probability table T8A has items for line number, number of verifications when the executable instruction sequence is changed, number of errors in the executable instruction sequence, lower limit of the confidence interval of the error probability, number of verifications when the variable value is changed, number of errors in the variable value, and lower limit of the confidence interval of the error probability. Usually, the line number error probability table T8A is used.

[0078] The line number field stores the line numbers of the instructions verified by executing test cases in the pre-migration program 11 and the post-migration program 12. The number of verifications when an execution instruction sequence is changed is stored in the "execution instruction sequence change instruction" field in the dependency instruction classification table T3 for each test case output variable in FIG. 5. The number of verifications is, for example, the number of test cases that have passed a certain instruction. For example, the "execution instruction sequence change instruction" field in the dependency instruction classification table T3 for each test case output variable stores three line numbers 3 and three line numbers 8. Therefore, 3 is stored in line number 3 and 3 is stored in line number 8 for the number of verifications when an execution instruction sequence is changed.

[0079] In the item of the number of errors in the execution instruction sequence, the number of mismatches stored in the "execution instruction sequence" in the execution result comparison table T7 for each test case output variable in FIG. 9 is calculated and stored as the number of errors in the execution instruction sequence. For example, the number of mismatches stored in the "execution instruction sequence" in the execution result comparison table T7 for each test case output variable is 1. The fact that the number of errors in the execution instruction sequence is 1 is shown by the fact that the dependent instructions with the instruction classification ID #6 in the dependent instruction classification table T3 for each test case output variable shown in FIG. 5 are 8 and 9, and the dependent instructions with the instruction classification ID #6 in the assumed dependent instruction classification table T4 for each test case output variable shown in FIG. 6 are 8 and 11. And, since the number of line numbers 8 with errors in the item of the execution instruction sequence change instruction in the dependent instruction classification table T3 for each test case output variable is 1, the number of errors in the execution instruction sequence with the instruction classification ID #6 in the error probability table T8A for each line number is calculated as 1.

[0080] Note that if the migrated program 12 contains a rare case branch, this branch itself is not an instruction, and test cases that pass through the rare case branch are not counted in the verification count.The error probability calculation unit 24 extracts instructions on which each variable depends from the execution instruction sequence, counts the number of verifications and the number of matches for each instruction, and calculates the probability of an error for each instruction based on the number of verifications and the number of matches.

[0081] The lower limit of the confidence interval for error probability field stores the number of verifications when the executable instruction sequence is changed and the lower limit of the confidence interval for error probability calculated based on the number of errors in the executable instruction sequence. For example, in row number 8 of the error probability by row number table T8A, the number of verifications when the executable instruction sequence is changed is 3, and the number of errors in the executable instruction sequence is 1. Meanwhile, the number of errors in the executable instruction sequence for all other row numbers is 0. As a result, the lower limit of the confidence interval for the error probability for row number 8 is large.

[0082] The item of the number of verifications for variable value change stores a numerical value verified by the error probability calculation unit 24 with reference to the "variable value change instruction" in the dependency instruction classification table T3 for each test case output variable shown in Fig. 5. For example, the variable value change instruction in line number 2 is verified by three test cases with instruction classification IDs = #1, #3, and #5 in the dependency instruction classification table T3 for each test case output variable, so 3 is stored in the number of verifications for variable value change. On the other hand, the variable value change instruction in line number 3 is not verified by a test case with any instruction classification ID in the dependency instruction classification table T3 for each test case output variable, so 0 is stored in the number of verifications for variable value change. Thereafter, values ​​are stored in the number of verifications for variable value change for line numbers 4, 6, 8, 9, and 10, respectively.

[0083] The number of errors in the variable value field stores the number of errors in the variables a and b. The lower limit of the confidence interval for error probability field stores the number of verifications when a variable value is changed and the lower limit of the confidence interval for error probability calculated based on the number of errors in the variable value. For example, in row number 2 of error probability table T8A by row number, the number of verifications when a variable value is changed is 3, and the number of errors in the variable value is 3. On the other hand, in row number 6, the number of verifications when a variable value is changed is 2, and the number of errors in the variable value is 2. For this reason, row number 2, which has a larger number of verifications when a variable value is changed and a larger number of errors in the variable value, has a larger lower limit of the confidence interval for error probability than row number 6.

[0084] The total number of verifications in the error probability table T8 for each line number in Fig. 10 stores the total number of verifications for changes in the execution instruction sequence and the total number of verifications for changes in the variable values ​​in the error probability table T8 for each line number in Fig. 11. Also, the total number of errors in the error probability table T8 for each line number stores the total number of errors in the execution instruction sequence and the total number of errors in the variable values ​​in the error probability table T8 for each line number.

[0085] Here, a comparison result between the execution instruction sequence and the variable values ​​when the instruction classification ID is #6 and the test case ID is #3 will be described. Since the dependent instructions in the dependent instruction classification table T3 for each test case output variable in FIG. 5 are 8 and 9, and the dependent instructions in the assumed dependent instruction classification table T4 for each test case output variable in FIG. 6 are 8 and 11, the execution instruction sequence of the output variable b is different, and the variable value of the output variable b is also different. Therefore, in the instruction classification ID=#6 in the execution result comparison table T7 for each test case output variable, the item of the execution instruction sequence is not consistent. Therefore, when the execution instruction sequence in the execution result comparison table T7 for each test case output variable is not consistent, the error probability calculation unit 24 does not add it as the number of verifications at the time of the variable value change, and does not add it as the number of errors of the variable value even if the variable value of the output variable is not consistent. Instead, the error probability calculation unit 24 adds the number of verifications at the time of the execution instruction sequence change and the number of errors of the execution instruction sequence.

[0086] An example of the post-transition program 13 with error probabilities is shown at the bottom of Fig. 11. The post-transition program 13 with error probabilities is the same as the post-transition program 13 with error probabilities shown in Fig. 2, so a detailed description will be omitted. The instruction in line number 2, which is the maximum value of the lower limit of the confidence interval of the error probability, "43.85%", is highlighted 13a. Also, the instruction in line number 8, which is the maximum value of the lower limit of the confidence interval of the error probability, "6.15%", is highlighted 13a. In this way, instructions in line numbers that store a higher probability than the probabilities of other line numbers in each column are estimated to have a high error probability.

[0087] The line number error probability table T8A shown in Fig. 11 may be displayed on a display device 35 shown in Fig. 12, which will be described later. The program error identification device 1 may present the instructions to the user in order of the highest error probability.

[0088] Furthermore, the line number error probability table T8A may highlight the row with the maximum probability calculated from the number of errors in the execution instruction sequence by the error probability calculation unit 24 and the maximum probability calculated from errors in the variable value change. Based on the rows highlighted in the line number error probability table T8A, the user can easily check the instructions with high error probabilities in the post-transition program 13 with error probabilities.

[0089] Furthermore, in the error probability tables T8 and T8A for each line number, the lower limit of the confidence interval of the error probability may be highlighted in gradation in ascending order. The user can try to correct instructions with low error probabilities in ascending order of the error probability, starting from the instruction with the highest error probability, and can improve the quality of the migrated program 12.

[0090] Returning to FIG. 1, the description of the program error identifying device 1 will be continued. The error probability display unit 25 uses the error probability table T8 for each line number as an input, and displays the post-migration program 12 with an error probability added thereto, ie, the post-migration program 13, on the display device 35 (see FIG. 12 described later). The display contents of the post-migration program 13 with an error probability are as shown in FIG. 2, and the error probability display unit 25 can, for example, highlight command lines with a high error probability. This allows the user to check the command lines with a high error probability in the post-migration program 12 by looking at the post-migration program 13 with an error probability.

[0091] <Example of computer hardware configuration> Next, the hardware configuration of the computer 30 constituting each device of the program bug identification device 1 will be described. Fig. 12 is a block diagram showing an example of a hardware configuration of a calculator 30. The calculator 30 is an example of hardware used as a computer capable of operating as the program defect identification device 1 according to this embodiment. The program defect identification device 1 according to this embodiment realizes a program defect identification method performed by the respective functional blocks shown in Fig. 1 in cooperation with each other by the calculator 30 (computer) executing a program.

[0092] The computer 30 includes a CPU (Central Processing Unit) 31, a ROM (Read Only Memory) 32, and a RAM (Random Access Memory) 33, each of which is connected to a bus 34. The computer 30 further includes a display device 35, an input device 36, a non-volatile storage 37, and a network interface 38.

[0093] The CPU 31 reads out program code of software for realizing each function according to the present embodiment from the ROM 32, loads it into the RAM 33, and executes it. Variables, parameters, etc. generated during the arithmetic processing of the CPU 31 are temporarily written to the RAM 33, and these variables, parameters, etc. are read out by the CPU 31 as appropriate.

[0094] The display device 35 is, for example, a liquid crystal display monitor, and displays to the user the results of the processing performed by the computer 30. The input device 36 is, for example, a keyboard, a mouse, etc., and allows the user to input predetermined operations and give instructions.

[0095] The non-volatile storage 37 may be, for example, a hard disk drive (HDD), a solid state drive (SSD), an optical disk, a magneto-optical disk, or a non-volatile memory. In addition to an operating system (OS) and various parameters, a program for making the computer 30 function is recorded in the non-volatile storage 37. The tables shown in FIG. 1 are also recorded in the non-volatile storage 37. The ROM 32 and the non-volatile storage 37 record programs, data, and the like required for the CPU 31 to operate, and are used as an example of a computer-readable non-transient storage medium that stores a program executed by the computer 30.

[0096] The network interface 38 may be, for example, a network interface card (NIC), and various data may be transmitted and received between devices via a local area network (LAN) or dedicated line connected to a terminal of the NIC.

[0097] 13 is a flowchart showing an example of a program defect identification method. Each process shown in this flowchart is executed by each functional unit of the program defect identification device 1 (see FIG. 1).

[0098] First, the test execution unit 21 reads the migrated program 12 and executes a test of the migrated program 12 for each test case (S1). The test results of the migrated program 12 are recorded in the non-volatile storage 37 shown in FIG. 12 as an execution result table T2 for each test case.

[0099] Next, the variable instruction dependency analysis unit 22 reads the test case assumed execution result table T1 and the test case assumed execution result table T2 from the non-volatile storage 37, and analyzes the dependency between the output variables and the instructions (S2). The analysis result of the pre-migration program 11 is recorded in the non-volatile storage 37 as a dependency destination instruction classification table T3 for each test case output variable. On the other hand, the analysis result of the post-migration program 12 is recorded in the non-volatile storage 37 as a dependency destination instruction classification table T4 for each test case output variable.

[0100] Next, the execution result comparison unit 23 reads out the dependency command classification table T3 for each test case output variable, the assumed dependency command classification table T4 for each test case output variable, the variable name correspondence table T5, and the line number correspondence table T6 from the non-volatile storage 37. After that, the execution result comparison unit 23 compares the dependency command classification table T3 for each test case output variable and the assumed dependency command classification table T4 for each test case output variable (S3). The comparison result is recorded in the non-volatile storage 37 as the execution result comparison table T7 for each test case output variable.

[0101] Next, the error probability calculation unit 24 reads the execution result comparison table T7 for each test case output variable from the non-volatile storage 37, and calculates the error probability for each command line of the migrated program 12 (S4). The error probability calculated by the error probability calculation unit 24 is recorded in the non-volatile storage 37 as an error probability table T8 for each line number.

[0102] Next, the error probability display unit 25 reads out the error probability table T8 for each line number from the non-volatile storage 37, and displays the error probability table T8 for each line number on the display device 35 (S5). The error probability display unit 25 also outputs the post-migration program 13 with error probabilities, which is the post-migration program 12 with error probabilities added (S6), and ends this process.

[0103] Here, the difference between the conventional assumed execution result table for each test case and the execution result table for each test case according to the present embodiment will be described with reference to FIGS.

[0104] FIG. 14 is a diagram showing an example of the pre-migration program 11A and the post-migration program 12A. The pre-migration program 11A is a program written in the COBOL language, and the post-migration program 12A is a program written in the Java language. NUM (number of units) in the pre-migration program 11A represents an input value, and RISK represents an expected output value.

[0105] FIG. 15 is a diagram showing examples of a conventional assumed execution result table for each test case, an execution result table for each test case, and an execution result comparison table for each test case.

[0106] In the conventional table of expected execution results for each test case (1), when an input value with NUM of 5 units is input to the pre-migration program 11A for test case #1, the expected output value RISK is shown as 9. Also, when an input value with NUM of 4 units is input to the pre-migration program 11A for test case #2, the expected output value RISK is shown as 7.

[0107] In the conventional table of expected execution results for each test case (2), when an input value with NUM of 5 units is input to the migrated program 12A for test case #1, the output value risk is shown as 9. Also, when an input value with NUM of 4 units is input to the migrated program 12A for test case #2, the output value risk is shown as 9. Note that the input values ​​are omitted from the conventional table of expected execution results for each test case (2).

[0108] The conventional test case-specific expected execution result table (3) shows the comparison result between the expected output value of pre-migration program 11A and the output value of post-migration program 12A. As described above, the expected output value and output value of test case #1 are both 9 and match. On the other hand, the expected output value of test case #2 is 7, and the output value is 9, so they do not match. In this way, the conventional test case-specific execution result table only tells whether the expected output value and output value for each test case match or do not match.

[0109] FIG. 16 is a diagram showing examples of an expected execution result table T1 for each test case, an execution result table T2 for each test case, and an execution result comparison table T7 for each output variable of a test case according to this embodiment.

[0110] In the assumed execution result table T1 for each test case, when an input value with NUM of 5 units is input to the pre-migration program 11A for test case #1, the assumed execution instruction sequence is 2, 3, 4, and the assumed output value RISK is 9. Also, when an input value with NUM of 4 units is input to the pre-migration program 11A for test case #2, the assumed execution instruction sequence is 2, 3, and the assumed output value RISK is 7.

[0111] In the test case execution result table T2, when an input value with NUM of 5 units is input to the migrated program 12A for test case #1, the execution instruction sequence is 2, 3, 4 and the output value risk is 9. Also, when an input value with NUM of 4 units is input to the migrated program 12A for test case #2, the execution instruction sequence is 2, 3, 4 and the output value risk is 9. Note that the input values ​​are omitted from the test case execution result table T2.

[0112] In the execution result comparison table T7 for each test case output variable, in addition to the comparison result between the expected output value of the pre-migration program 11A and the output value of the post-migration program 12A, the comparison result of the execution instruction sequence and the final matching execution instruction are also shown. As described above, the expected output value and the output value of test case #1 are both 9 and match, and the expected execution instruction sequence and the execution instruction sequence are also both 2, 3, 4, so the execution instruction sequence comparison result matches. It is also shown that the final matching execution instruction is 4.

[0113] On the other hand, the expected output value of test case #2 is 7, and the output value is 9, so the output value comparison result is a mismatch. Also, the expected execution instruction sequence is 2,3, the execution instruction sequence is 2,3,4, and the final matching execution instruction is 3, so the execution instruction sequence comparison result is a mismatch. Therefore, not only is it shown that the output values ​​do not match, but also which execution instruction caused the mismatch. In this way, if the item for the final matching execution instruction shown in FIG. 16 is configured to be provided in the execution result comparison table T7 for each test case output variable shown in FIG. 9, the execution instruction that caused the mismatch can be clearly shown.

[0114] In the program defect identification device 1 according to the embodiment described above, the execution result of the post-migration program 12 is compared with the expected result of the pre-migration program 11 to calculate the error probability for each instruction of the post-migration program 12. Furthermore, the program defect identification device 1 not only indicates that the post-migration program 12 has an error, but also indicates the instruction execution sequence in the post-migration program 12 that is expected to have an error. When the output variables of the post-migration program 12 are inconsistent, the user can know which instruction execution sequence is erroneous. In this way, the instruction with a high error probability calculated for each instruction of the post-migration program 12 is identified as having a defect, so the user can focus on checking the instruction execution sequence with a high error probability and perform debugging.

[0115] In addition, the program defect identification device 1 identifies errors in instruction implementation and errors in the instruction conversion results in the migrated program 12. This makes it easier for the user to understand how to correct the migrated program 12 according to the type of error.

[0116] In addition, the assumed execution result table T1 for each test case includes an assumed execution instruction sequence, and the execution result table T2 for each test case includes an execution instruction sequence. This makes it easier for the user to identify the instruction line number that is likely to contain an error based on the assumed execution instruction sequence and the execution instruction sequence.

[0117] Furthermore, an error probability is assigned to an instruction execution sequence that is expected to have an error based on the results of executing the pre-migration program 11 and the post-migration program 12 using various test cases assumed in advance. The instruction lines of the post-migration program 13 with error probabilities are highlighted in order of decreasing error probability, allowing the user to make corrections starting from the instruction lines with the highest error probabilities, thereby suppressing the occurrence of unexpected errors due to corrections to other instruction lines.

[0118] [Variations] In the above embodiment, a case has been described in which the pre-migration program 11 and the post-migration program 12 are tested as unit tests. Furthermore, the program defect identification device 1 can also obtain an error probability for each executed program and show the error probability to the user in a combination test for a combined program in which multiple programs are combined, and in an integration test that is executed by transferring data between multiple programs.

[0119] In the above-described embodiment, the program bug identification device 1 includes the test execution unit 21, and all processing is performed by the program bug identification device 1. However, the test function of performing "test execution" to obtain the execution result and the analysis function of analyzing and comparing the inter-instruction dependencies to calculate the error probability may be separated. For example, only the test execution unit 21 in the program bug identification device 1 may be the test device, and the other processing units may be the program bug identification device.

[0120] Also, in the above-described embodiment, an item for assumed execution instruction sequence is provided in the assumed execution result table T1 for each test case in Fig. 3. The item for assumed execution instruction sequence is provided in order to determine whether the execution instruction sequences match or mismatch in the execution result comparison table T7 for each test case output variable in Fig. 9. If a form is used in which a match or mismatch in the execution instruction sequences is not required, it is not necessary to provide an item for assumed execution instruction sequence in the assumed execution result table T1 for each test case.

[0121] Moreover, the program language of the pre-migration program 11 may be C, and the program language of the post-migration program 12 may be Python. In this way, the combination of the program language of the pre-migration program 11 and the program language of the post-migration program 12 may be arbitrary.

[0122] Furthermore, if there is no pre-migration program 11 and only a post-migration program 12, the post-migration program 12 is not a conversion of the pre-migration program 11. However, even if only the post-migration program 12 exists, the program defect identification device 1 can detect errors in instruction implementation and assign error probabilities to the corresponding instruction strings. This makes it easier for the user to find instructions with a high error probability among the instructions written in the post-migration program 12.

[0123] Furthermore, the program bug identification device 1 may present to the user candidates for instructions that are expected to be correct for instructions with a high error probability detected in the migrated program 12. The user can use the presented candidate instructions as a clue to come up with a correct instruction.

[0124] Even if the programming language is the same, the command format may differ depending on the version. For example, Python version 2.X and version 3.X have different formats and are not compatible. In this case, the pre-migration program can be created in Python version 2.X (first programming language), and the post-migration program can be created in Python version 3.X (second programming language).

[0125] Furthermore, the present invention is not limited to the above-described embodiment, and it goes without saying that various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims. For example, the above-described embodiment describes the configuration of the program defect identification device in detail and specifically in order to explain the present invention in an easily understandable manner, and is not necessarily limited to having all of the described configurations. In addition, it is also possible to add, delete, or replace part of the configuration of the present embodiment with other configurations. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0126] 1...program defect identification device, 11...pre-migration program, 12...post-migration program, 13...post-migration program with error probability, 21...test execution unit, 22...variable instruction dependency analysis unit, 23...execution result comparison unit, 24...error probability calculation unit, 25...error probability display unit, 35...display unit, T1...assumed execution result table for each test case, T2...execution result table for each test case, T3...dependency instruction classification table for each test case output variable, T4...assumed dependency instruction table for each test case output variable, T5...variable name correspondence table, T6...line number correspondence table, T7...execution result comparison table for each test case output variable, T8, T8A...error probability table for each line number

Claims

1. an execution result comparison unit that outputs a comparison result of the variable values ​​of the output variables of the pre-migration program and the post-migration program and a comparison result of the instruction execution sequences of the pre-migration program and the post-migration program, compared for each test case, based on an instruction dependency relationship for output variables of the pre-migration program analyzed from an assumed execution result of testing the pre-migration program created in a first programming language for each test case, and an instruction dependency relationship for output variables of the post-migration program analyzed from an execution result of testing the post-migration program created in a second programming language for each test case; an error probability calculation unit that calculates an error probability for each instruction of the post-migration program based on the comparison result; Program malfunction identification device.

2. the assumed execution result includes an assumed execution instruction sequence representing an instruction order of instructions to be executed in the pre-transfer program, and the execution result includes an execution instruction sequence representing an instruction order of instructions to be executed in the post-transfer program; The error probability calculation unit identifies a defect in the migrated program based on the number of discrepancies between the expected execution instruction sequence and the execution instruction sequence. The program defect identification device according to claim 1 .

3. The error probability calculation unit calculates a lower limit value of a confidence interval of the error probability as the error probability, and outputs an error probability table including the error probability for each instruction line of the migrated program. The program defect identification device according to claim 2.

4. The execution result comparison unit compares an instruction on which a variable described in the pre-migration program depends with an instruction on which a variable described in the post-migration program depends, and determines whether the execution instruction sequences described in the pre-migration program and the post-migration program match or not with respect to the values ​​of the variables. The program defect identification device according to claim 3.

5. a variable instruction dependency analysis unit that analyzes dependency relationships between instructions for variables described in the pre-migration program and dependency relationships between instructions on which the variables described in the post-migration program depend, based on the assumed execution result and the execution result. The program defect identification device according to claim 4.

6. The variable instruction dependency analysis unit classifies the instructions on which the output variables depend into conditional branch instructions that change the sequence of execution instructions and variable value change instructions that change the variable values ​​of the output variables. The program defect identification device according to claim 5.

7. and an error probability display unit that displays a post-migration program with an error probability by adding the error probability to the post-migration program based on the error probability table. The program error identifying device according to claim 6.

Images