JP2007041804A - Program generation device, program verification device, and verification program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program generation device and a program verification device 1 for supporting verification without omission whether or not an output value to an input value has not been changed. <P>SOLUTION: An input value computing means 16 computes input values to make a condition formula included in a source code be true and faulty, respectively. A program generation means generates a test program outputting an output value based on the computed true and faulty input values. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an apparatus for verifying a defect in a program whose contents have been changed.

  In recent years, in software development, for the purpose of maintaining and improving software maintainability, refactoring has been implemented to improve source code without changing software functions, for example, without changing output values for input values. . In this refactoring, there is a case where the function of the software is changed due to an error in rewriting the source code, and it is necessary to verify whether the function of the software is changed.

  Conventionally, various methods have been used as verification tests for verifying whether the function of a module constituting a part of a program has been changed before and after refactoring, that is, whether the identity of an output value with respect to an input value is not impaired. Is used. As a representative test, a module is simulated before and after refactoring to calculate an output value, and the user verifies the identity of the output value with respect to the input value based on the calculated output value. . In such a method, it is necessary to generate a test program for executing the module in a pseudo manner. This test program is generated by a programmer. The user verifies the identity of the output value with respect to the input value by executing the test program on the module generated after refactoring.

  A conventional module test support apparatus is an apparatus that can generate a test program for supporting verification of an output value with respect to an input value of a module after refactoring. When the test program generated by the module test support device is executed, the user is prompted for the input value necessary for the module, and the output value is output based on the input value input. Based on the output value, it can be verified whether the function of the module is changed and the output value for the input value is not changed (see Patent Document 1).

JP 2000-109644 A

  As in the prior art, when generating a test program, a test program is generated for each module. Therefore, in addition to the programmer creating a plurality of modules, it is also necessary to generate a test program corresponding to each module, increasing the burden on the programmer. In addition, the programmer generates a test program that can be verified for various possible input values. However, it cannot be said that all the processing paths of the program are covered by these input values, and it cannot be said that it is a test program that can verify whether or not the output value is changed with respect to the input value. Therefore, it is difficult to detect all bugs without omission by the test program, and it is difficult to correct all bugs of the program based on the verification result.

  A conventional module test support apparatus generates a test program based on each module. Therefore, it is not necessary for the programmer to generate a test program, and the burden on the programmer can be reduced. However, since the user inputs an input value in the test program, it cannot be said that this apparatus is a verification that covers all processing paths. The test program generated by the module test support device cannot be said to be a test program for verifying whether or not the output value is changed with respect to the input value. Therefore, it is difficult to detect all bugs without omission by the test program, and it is difficult to correct all bugs of the program based on the verification result.

  An object of the present invention is to provide a program generation device and a program verification device that assist in verifying whether an output value with respect to an input value has not been changed.

The present invention relates to a conditional expression included in the source code of a program to be verified that outputs an output value based on an input value that is input, and the conditional expression for which processing branches depending on whether the conditional expression is true or false. Input value calculation means for calculating the input value
A program generation apparatus comprising: a program generation means for generating a test program for outputting an output value based on an input value calculated by an input value calculation means using a verification target program.

Further, the present invention is a program verification device that verifies whether or not output values for input values of a plurality of verification target programs that output output values are the same based on input values that are input,
An input value calculation means for calculating, for each verification target program, an input value that is a conditional expression included in the source code of each verification target program and whose conditional expression is true or false depending on whether the conditional expression is true or false When,
Based on the input value calculated by the input value calculation means, program execution means for executing each verification target program used for calculation of the input value and outputting an output value;
Output value comparison means for comparing the output values of each verification target program output by the program execution means;
And a verification unit that verifies whether the output values of the verification target programs are the same based on the comparison result of the output comparison unit.
The present invention is a verification program for controlling the program verification apparatus.

  According to the present invention, an input value that is true for a conditional expression included in the source code (hereinafter may be referred to as “true input value”) and an input value that is false (hereinafter “false input”). Value)). The program generation means generates a test program that outputs an output value based on the true and false input values. By executing the test program, the output value output based on the true and false input values can be calculated. By similarly generating and executing test programs for a plurality of verification target programs, true and false input values of each verification target program and output values based on these input values can be calculated. By comparing the output values of the verification target programs calculated in this way, it is possible to easily verify whether or not the output values based on the true and false input values of the verification target programs are the same. Thus, since the identity of the output value can be easily verified, for example, the identity of the output value with respect to the input value of the program after the change changed by refactoring and the program before the change can be verified. By calculating the true and false input values of all the conditional expressions, it is possible to verify all the processing paths (flows) that can be traced by each verification target program, and it is possible to verify all the output values that can be output. This makes it possible to realize a leak-free verification. Based on such a complete verification result, the user can detect the bug included in the changed program without omission and easily correct the bug.

  According to the present invention, the input value calculation means calculates the true input value that makes the conditional expression included in the source code true and the false input value that makes false. The program execution means executes the verification target program in which these input values are calculated based on each true and false input value, and outputs an output value based on the true and false input values. The output value comparison unit compares the output values of the verification target programs output by the program execution unit with each other. The verification means verifies whether or not the output values based on the true and false input values of each verification target program are the same based on the comparison result of the output value comparison means. By verifying whether or not the output values based on the true and false input values are the same, for example, the user can determine the identity of the output values with respect to the input values of the changed program and the changed program that have been changed by refactoring. The time and effort for verification can be saved. Since there is no human intervention for verification, it is possible to prevent a user from omission of verification. Further, by calculating the true and false input values of all the conditional expressions, it is possible to verify all the processing paths (flows) that can be traced by each verification target program, and it is possible to verify all the output values that can be output. This makes it possible to realize a leak-free verification. It is possible to detect bugs included in the program after the change without omission based on such omission-free verification results and to promote the user to correct the bug without omission.

  According to the present invention, it is possible to realize an apparatus that can easily verify whether or not the true and false output values of each verification target program are the same.

  Hereinafter, a plurality of embodiments for carrying out the present invention will be described with reference to the drawings. Portions corresponding to the matters described in the preceding forms in each embodiment are denoted by the same reference numerals, and overlapping description may be omitted. When only a part of the configuration is described, the other parts of the configuration are the same as those described in the preceding section. In addition to the combination of the parts specifically described in each embodiment, the embodiments may be partially combined as long as the combination is not particularly troublesome.

  FIG. 1 is a block diagram showing functions of the program verification apparatus 1 according to the present embodiment separately for each block. The program verification apparatus 1 is an apparatus that verifies the identity of the functions of a plurality of verification target programs that output output values based on input values. Specifically, the program verification apparatus 1 is an apparatus that verifies whether or not the output values for the input values of the verification target program are the same. The program verification device 1 is a device that verifies whether the output values for the input values of the program before and after refactoring are the same, for example. When the program verification apparatus 1 stores the programs before and after refactoring and executes the verification program for performing the verification as described above, the program verification apparatus 1 verifies the identity of the output value with respect to the input value of each program.

  In the following, verification of modules constituting a part of a program based on the C language is described. However, it is not limited to programs and modules based on the C language, but may be programs and modules based on procedural languages and object-oriented languages such as FORTRAN, JAVA (registered trademark), C ++, etc., and the language is not limited. The program verification apparatus 1 is a personal computer, for example. The program verification device 1 includes a device main body 2, a storage unit 3, an input unit 4, and an output unit 5. The apparatus main body 2 is constituted by, for example, a central processing unit (abbreviated as CPU). The apparatus main body 2 is electrically connected to the storage unit 3, the input unit 4, and the output unit 5. The apparatus body 2 includes an output extraction unit 7, an identification number addition unit 8, a branch condition extraction unit 9, a processing path extraction unit 10, an input variable search unit 11, a test input value generation unit 12, a test generation unit 13, and a test execution unit 14. And an output value comparison verification unit 15.

  The output extraction unit 7 is electrically connected to the identification number adding unit 8 and the test generation unit 13. The output extraction unit 7 has a function of extracting module information based on the source code. The module information includes functions and arguments that the module to be verified (hereinafter may be referred to as “verification target module”) affects other modules (hereinafter may be referred to as “external module”). It is information indicating the presence or absence. The module information includes four pieces of information. The four types of information are (1) presence / absence of functions included in the module, (2) variables whose values change in the module, and whether or not there are variables passed by reference in arguments, (3) presence / absence of global variables, And (4) information on the presence / absence of a function (hereinafter referred to as “external function”) present in an external module called from the verification target module. These functions and variables are extracted because their values are maintained in the external module when their values change in the verification target module.

  The identification number adding unit 8 is electrically connected to the test generation unit 13. The identification number adding unit 8 has a function of extracting an external function based on the source code and assigning an identification number to the external function. Further, the identification number adding unit 8 has a function of adding the assigned identification number to the argument of the external function. The identification number adding unit 8 assigns different identification numbers to the external functions described at different positions in the source code even if they are the same external functions.

  The branch condition extraction unit 9 is electrically connected to the processing path extraction unit 10 and the input variable search unit 11. The branch condition extraction unit 9 has a function of extracting a branch point for branching the processing path of the module and a branch condition for branching based on the source code. The processing path is a so-called flow indicating the order in which each sentence is executed. Specifically, the branch condition extraction unit 9 has a function of extracting a branch point based on a conditional statement such as an if statement and a switch statement and a conditional expression of the conditional statement. The processing path extraction unit 10 is electrically connected to the input variable search unit 11. The processing path extraction unit 10 has a function of extracting all processing paths derived from the branch points in the module based on the source code.

  The input variable search unit 11 is electrically connected to the test input value generation unit 12. The input variable search unit 11 is based on information extracted by the source code, the branch condition extraction unit 9 and the processing path extraction unit 10 and variables and external functions (hereinafter referred to as “input variables”) to be input to the verification target module. And a function for searching for a condition necessary for calculating an input value to be input to the input variable (hereinafter sometimes referred to as “variable input value”). The test input value generation unit 12 is electrically connected to the test generation unit 13. The test input value generation unit 12 has a function of calculating a variable input value based on variables and conditions searched by the input variable search unit 11.

  The test generation unit 13 is electrically connected to the test execution unit 14. The test generation unit 13 has a function of generating a test program for executing and testing the verification target module in a simulated manner based on the source code, module information, identification number, input variable, and variable input value. The test program is a program that calculates and outputs an output value based on each variable input value.

  The test execution unit 14 is electrically connected to the output value comparison verification unit 15. The test execution unit 14 has a function of executing the test program generated by the test generation unit 13 and calculating the output value of each verification target module. The output value comparison / verification unit 15 compares the output value of each verification target module output from the test execution unit 14, the variable input value obtained by calculating different output values for the same variable input value, and the output value thereof And the like (hereinafter, sometimes referred to as “verification result”). Further, the output value comparison verification unit 15 has a function of outputting the extracted verification result to the output unit 5.

  The storage unit 3 has a function of storing source codes, module information, conditional expressions, processing paths, variable input values, output values, verification results, and the like of a plurality of verification target modules. Each component performs an operation based on the source code stored in the storage unit 3. Hereinafter, unless otherwise specified, the constituent unit in which each constituent unit stores various information is the storage unit 3. The input unit 4 is provided for giving a command to the apparatus main body 2 when a user performs an operation such as input. The input unit 4 is a keyboard, for example. The output unit 5 has a function of displaying or printing an output value based on a variable input value, a verification result, and the like to notify the user of the output value and the verification result. The output unit 5 is a display unit such as a display and a printing apparatus such as a printer.

  In the program verification apparatus 1, the branch condition extraction unit 9, the processing path extraction unit 10, the input variable search unit 11, and the test input value generation unit 12 correspond to the input value calculation unit 16. The test generation unit 13 corresponds to a program generation unit. The test generation unit 13 and the test execution unit 14 correspond to the program execution unit 17. The output value comparison / verification unit 15 corresponds to an output value comparison unit and a verification unit.

  Hereinafter, the processing operation of the apparatus main body 2 of the program verification apparatus 1 will be described. First, the verification target module will be described. In the present embodiment, the identity of output values with respect to input values of two verification target modules is verified. The two verification target modules are a module after refactoring the module (hereinafter may be referred to as “module after change”) and a module before being refactored (hereinafter may be referred to as “module before change”). It is. In the following, description contents of source codes of these two verification target modules (hereinafter sometimes referred to as “verification target source code”) will be described.

  First, the source code of the module before change (hereinafter may be referred to as “source code before change”) will be described. Table 1 shows the source code before the change. Hereinafter, for convenience of explanation, line numbers are given to the respective lines in the source code and the output result, but the line numbers are not necessarily required. It does not have to be line numbers and is merely for ease of explanation.

  The pre-change source code is a source code of a module in which a function func having a variable a and an array b [10] as arguments is described, and the function func is calculated based on the argument. The function func is defined in the first line of the source code before change. In lines 3 to 9, variables c, d, and cnt are type-declared, and values are assigned to these variables. In the 10th line, a value is assigned to the variable a. In the 12th to 17th lines, the if statement of the control statement is described, and the if statement branches the processing path based on the truth of the conditional expression “a ≧ 100 and a <200”. In the 18th to 24th lines, the while statement of the control statement is described. The while statement causes the control to be repeated until it does not have the expression “cnt <10”. The if statement is described in the 19th to 21st lines in the while statement. Based on the truth of the conditional expression “cnt ≧ c”, the processing path is branched. In the 26th to 35th lines, the switch statement of the control statement is described. The switch statement branches the processing path based on the value of the conditional expression “sub (a)”.

  Next, the source code of the module after change (hereinafter sometimes referred to as “source code after change”) will be described. Table 2 shows the changed source code.

  The post-change source code is a source code of a module in which a function func having a variable a and an array b [10] as arguments is described, and the function func is calculated based on the argument, similarly to the pre-change source code. In the changed source code, the function func is defined in the first line. In the third line, the type is declared for the variable d. The if statement is described in the sixth to eighth lines, and the if statement branches the processing path based on the truth of the conditional expression “a ≦ 100 or a> 200”. In line 10, a value is assigned to variable d, and in line 12, function func2 is called with 5 and array b as arguments. The if statement is described in the 14th to 21st lines. The “if” statement branches the processing path based on the truth of the conditional expression “sub (a−1) = 1”. In the 23rd to 35th lines, the function func2 is defined with the variable c and the array b [10] as arguments. In the function func2, the variable cnt is type-declared on the 25th to 27th lines, and a value is assigned to the variable cnt. In the 28th line to the 35th line, the while statement of the control statement is described. The while statement causes the control to be repeated until it does not have the expression “cnt <10”. The if statement is described in the 29th to 31st lines in the while statement, and the if statement branches the processing path based on the truth of the conditional expression “cnt ≧ c”. In the present embodiment, in order to facilitate the description of the program verification process of the program verification apparatus 1, the source code before and after the change is input to a predetermined identical input value when a certain input value is input. The output values are different from each other. Next, a specific processing operation of the specific program verification apparatus 1 will be described.

  FIG. 2 is a flowchart showing the procedure of the program verification process. The program verification process of the program verification apparatus 1 includes a syntax analysis process, an output extraction process process, an identification number addition process process, a branch condition extraction process process, a process path extraction process process, an input variable search process process, and a test input value generator process. A process, a test generation process, a test execution process, an output value comparison verification process, and a verification result notification process. In the program verification process, when the verification source code is stored in the storage unit 3 and the verification target source code is designated by the input unit 4, the process proceeds to step s1. In the present embodiment, the verification target source code is the source code before and after the change, and may be simply referred to as “source code” hereinafter.

  FIG. 3 is a flowchart showing the procedure of the output extraction process. In the output extraction processing step of step s1, output extraction processing is started, and the module information of each verification target module is extracted by the output extraction unit 7 based on each source code. In the output extraction process, the operation subject is the output extraction unit 7. Hereinafter, in the output extraction process, when the output extraction unit 7 is a control subject, the description may be omitted.

  Hereinafter, the output extraction process will be specifically described. When the process proceeds to the output extraction process step s1, the output extraction process starts, and the process proceeds to step a1. In step a1, whether or not the highest function returns a return value is searched based on each source code, and the search result is stored. The top-level function is a function positioned at the top of the program structure in the verification target module, and is a function called from an external module. The return value of the function changes depending on the processing in the verification target module. Since the return value of the function changes in this way, the calculation process of the calling module is affected. By searching whether or not the function returns a return value, it is possible to determine whether or not the verification target module is a module that affects the external module. In the source code before change, the function func is defined to return a return value on the first line, and in the source code after change, the function func is defined to return a return value on the first line. Therefore, it is detected and stored that the function returns a return value in the source code before and after the change. When the function search ends, the process proceeds from step a1 to step a2.

  Step a2 is a step of searching for the presence or absence of assignment to a variable passed by reference. In step a2, based on each source code, the presence / absence of assignment to a variable passed by reference is searched, and the search result is stored. A variable passed by reference is a variable whose value is maintained in the external module when the value is changed in the module, such as an address reference using an operator “&”, a pointer variable, and an array element. If the value of a variable passed by reference is changed in the module, the value is maintained in the external module, which affects the calculation in the external module. By searching for the presence / absence of assignment to a variable passed by reference, it is possible to determine whether the verification target module is a module that affects the external module.

  In the source code before change, a value is assigned to the array b [10] on the 22nd line, and in the source code after change, a value is assigned to the array b [10] on the 33rd line. Therefore, in the source code before and after the change, it is determined that there is an assignment to the variable passed by reference, and the array b [10] is extracted and stored. When the array b [10] is extracted, the array element is also extracted and stored. When the search for the presence / absence of assignment to a variable passed by reference is completed, the process proceeds from step a2 to step a3.

  In step a3, a global variable is searched based on each source code, and the search result is stored. The global variable is an effective variable in the verification target module and the external module. Therefore, when the value is changed to the global variable in the verification target module, the value is maintained in the external module, which affects the calculation in the external module. By searching for the presence or absence of a global variable, it can be determined whether or not the verification target module is a module that affects the external module. Global variables are not described in the source code before and after the change. Therefore, it is determined that there is no global variable in the source code before and after the change and stored. When the search for the global variable is completed, the process proceeds from step a3 to step a4.

  In step a4, the presence / absence of an external function called from the verification target module is searched based on each source code, and the search result is stored. Calling an external function itself affects the external module. By searching for the presence or absence of an external function, it can be determined whether or not the verification target module is a module that affects the external module. In the source code before change, the external function “sub (a)” is called on the 26th line, and in the source code after change, the external function “sub (a-1)” is called on the 14th line. Accordingly, it is determined that there is an external function in the source code before change, and the external function “sub (a)” is extracted. In the changed source code, it is determined that there is an external function, and the external function “sub (a-1)” is extracted and stored. Tables 3 and 4 show modules extracted by searching in steps a1 to a4 in this way. Table 3 shows module information of the module before change, and Table 4 shows module information of the module after change.

  When the search for the external function ends, the output extraction process ends, and the process proceeds from step s1 to step s2.

  FIG. 4 is a flowchart showing the procedure of the identification number addition process. FIG. 5 is a diagram showing a part of source code before and after assigning an identification number to an external function. In the identification number addition processing step which is step s2, the identification number addition processing is started, and the identification number addition unit 8 assigns an identification number to the external function based on each source code, Add to function argument. In the identification number addition process, the operation subject is the identification number addition unit 8. Hereinafter, in the identification number adding process, when the identification number adding unit 8 is a control subject, the description may be omitted.

  Hereinafter, the identification number adding process will be specifically described. When the process proceeds from the output extraction process step s1 to the identification number addition process step s2, the identification number addition process starts, and the process proceeds to step b1. In step b1, external functions are searched in order from the first line of each source code. In the source code before change, the external function sub (a) is detected on the 26th line, and in the source code after change, the external function sub (a-1) is detected on the 14th line. When the external function is detected, the process proceeds from step b1 to step b2.

  In step b2, an identification number is assigned to the detected external function. An identification number is assigned to the external function, and this identification number is added as the first argument of the external function. Therefore, for the argument of the external function, the identification number is input as the first argument, and the argument previously given after the second argument is input. The identification number is given to clarify at which position in the source code the external function is called. When the assignment of the identification number is completed, the process proceeds from step b2 to step b1, and the search for the external function is started again from the line next to the line where the external function is detected.

  In the source code before change, identification number 1 is assigned to the external function sub (a) on the 26th line, and this identification number 1 is added to the first argument. Therefore, in the source code before change, as shown in FIG. 5, the external function sub (a) is changed to the external function sub (1, a). In the changed source code, identification number 1 is assigned to the external function sub (a-1) on the 14th line, and this identification number 1 is added to the first argument. Therefore, in the changed source code, the external function sub (a-1) is changed to the external function sub (1, a-1). When the assignment of the identification number is completed, the search starts from the 27th line in the source code before the change and from the 15th line in the source code after the change, and the process returns to step b1.

  In step b1, the search is made up to the last line of the source code, and if no external function is detected, the identification number addition process is terminated. In the source code before and after the change, the external function is not called on the 27th line and the 15th line and thereafter, the identification number addition process ends, and the process proceeds from step s2 to step s3.

  If another external function is detected in step b1, identification number 2 is assigned to the external function and added to the first argument. Similarly, for other external functions, identification numbers are assigned as sequential numbers 3, 4, 5,... In the order of detection and added to the first argument. At this time, even if the external function and the argument are the same, if the place to be called, that is, the line describing the external function is different, these external functions are assigned different identification numbers. Specifically, different identification numbers such as external functions sub (1, a), sub (2, a), bus (3, a)... Are assigned to the same external function, and the first argument is set. Add. The identification number is not limited to being assigned to the external function with a serial number, and may be any number different from each other.

  FIG. 6 is a flowchart showing a procedure of branch condition extraction processing. In the branch condition extraction processing step, which is step s3, branch condition extraction processing is started, and branch points for branching the processing path of each verification target module and branch conditions for branching are extracted and stored based on each source code. . In the branch condition extraction process, the operating subject is the branch condition extraction unit 9. Hereinafter, in the branch condition extraction process, when the branch condition extraction unit 9 is a control subject, the description may be omitted.

  Hereinafter, the branch condition extraction process will be specifically described. When the process proceeds from the identification number addition process step s2 to the branch condition extraction process step s3, the branch condition extraction process starts, and the process proceeds to step c1. In step c1, a sentence describing a process to be executed first in each verification target module is detected. In the following, when a statement that describes a process to be executed is detected as the first statement that may be referred to as a “command”, the process proceeds from step c1 to step c2.

  In the branch number detection step, which is step c2, the detected command statements (hereinafter sometimes referred to as “detected statements”) are classified based on the number of branches that branch the processing path. Specifically, the branch condition extraction unit 9 repeats the process until a statement that declares the type of a variable, a function, an assignment expression, an instruction statement that does not branch the processing path, such as a return statement and a break statement, and a condition are satisfied. An instruction statement that performs repeated processing such as a while statement and a for statement is classified as a non-branch processing statement. Also, an instruction statement such as an if statement that branches the processing path based on the truth of the conditional expression is classified as a two-branch processing statement. Further, a command statement that branches the processing path based on the value of the conditional expression such as a switch statement is classified as a multi-branch processing statement. When the detected sentence is classified as a non-branch process sentence, the process proceeds from step c2 to step c3. In step c3, for each source code, detection is performed for another command statement. If no other statement is detected, the branch condition extraction process ends. When the branch condition extraction process ends, the process proceeds from step s3 to step s4. When another command sentence is detected, the process returns to step c2, and the next detected sentence is classified.

  When the detected sentence is classified into the two-branch process sentence in step c2, the process proceeds to step c4. In the condition extraction step, which is step c4, the conditional expression of the detected sentence is extracted and stored. When the conditional expression includes a logical operator, the conditional expression is divided into a plurality of expressions by the logical operator, and each expression is stored. For example, if the conditional expression of the “if” statement is “a> = 100 && a <200”, the conditional expression is divided into two conditional expressions “a> = 100” and “a <200” based on the logical operator “&&”. Remember. When the conditional expression is stored, the process proceeds from step c4 to step c3.

  When the detected sentence is classified into the multi-branch process sentence in step c2, the process proceeds to step c5. In the condition extracting step, which is step c5, the conditional expression and its value are extracted and stored for each value for which the conditional expression of the detected sentence is classified. For example, when the switch statement conditional expression “sub (a)” is “1” and the first command statement is executed, and the switch statement conditional expression “sub (a)” is “2” and the second command statement is executed, Conditional expressions “sub (a) == 1” and “sub (a) == 2” are stored. When the conditional expression is stored, the process proceeds from step c5 to step c3.

  Hereinafter, this branch condition extraction processing will be specifically described using source code before and after the change. In the pre-change source code, in step c1, the type declaration sentence “int c” on the third line is detected, and the process proceeds to step c2. In step c2, the type declaration statement “int c” is classified as a non-branch processing statement, and the process proceeds to step c3. In step c3, the type declaration sentence “int d” on the fourth line is detected. Similarly to the type declaration statement “int c” on the third line, the processes of step c2 and step c3 are performed for each type declaration statement and expression on the fourth line to the tenth line. In step c2, these detected sentences are classified as non-branch process sentences.

  After classification of the substitution expression “a = a−1” on the 10th line, the if statement on the 12th line is detected in step c3, and the process proceeds to step c2. In step c2, the detected if sentence is classified into a two-branch process sentence, and the process proceeds to step c4. In step c4, the conditional expression “a> = 100 && a <200” of the if statement is detected. Further, since the conditional expression of the if statement includes a logical operator, the conditional expression of the if statement is divided by the logical operator, and two conditional expressions “a> = 100” and “a <200” are extracted and stored. Let When the two conditional expressions are stored, the process proceeds to step c3.

  Since the substitution expression “c = 5” on the 13th line, the return statement on the 15th line, and the while statement on the 18th line are non-branch processing statements, they are detected in step c3 and the process returns to step c2. . In step c2, it is classified as a non-branch processing statement, and the process proceeds to step c3. After this process is performed on each line and the while sentence on the 18th line is classified, the if sentence on the 19th line is detected in step c3. In step c2, the detected if sentence is classified into a two-branch process sentence, and the process proceeds to step c4. In step c4, the conditional expression “cnt> = c” of the if statement is detected. Conditional expression “cnt> = c” is extracted and stored, and the process proceeds to step c3.

  The substitution expression “b [cnt] = cnt * 10” on the 22nd line and the substitution expression “cnt = cnt + 1” on the 23rd line are detected in step c3 because these sentences are non-branch processing sentences. Return to c2. In step c2, it is classified as a non-branch processing statement, and the process proceeds to step c3. After performing this process on each line and classifying the substitution expression on the 23rd line, in step c3, the switch statement on the 26th line is detected, and the process returns to step c2. In step c2, the detected switch statement is classified as a multi-branch processing statement, and the process proceeds to step c5. In step c5, based on the conditional expression “sub (a)” of the switch statement and its values “1” and “2”, the conditional expressions “sub (a) == 1” and “sub (a) == 2”. Is extracted and stored, and the process proceeds to step c3.

  For the assignment expression “d = 30000” on the 28th line, the assignment expression “d = d + 10000” on the 30th line, the break statement on the 31st line, and the return statement on the 34th line, these statements are non-branch processing statements. Therefore, it is detected in step c3 and returns to step c2. In step c2, it is classified as a non-branch processing statement, and the process proceeds to step c3. After this process is performed on each line and the return sentence on the 34th line is classified, in step c3, no other sentence can be detected up to the last line, so the branch condition extraction process ends. When the branch condition extraction process ends, the process proceeds from step s3 to step s4. Table 5 shows the conditional expressions (hereinafter sometimes referred to as “branch conditional expressions”) extracted by this branch condition extraction process in the source code before change. The first column shows the row number in which the branching conditional expression is described, and the second column shows the branching conditional expression.

  The post-change source code is subjected to the same branch condition extraction process as that of the pre-change source code, and is classified and extracted for each detected sentence. As a result, the branch condition expression shown in Table 6 is extracted and stored. The first column shows the row number in which the branching conditional expression is described, and the second column shows the branching conditional expression. As in the case of the source code before change, when the processing path extraction process is completed, the process proceeds from step s3 to step s4.

  FIG. 7 is a flowchart showing the procedure of the processing path extraction process. In the processing route extraction processing step, which is step s4, processing route extraction processing is started, and all processing routes derived from branch points are extracted based on each source code. In the processing path extraction process, the operation subject is the processing path extraction unit 10. Hereinafter, when the processing path extraction unit 10 is a controlling entity in the processing path extraction process, the description may be omitted.

  Hereinafter, the processing path extraction process will be specifically described. When the branch condition extraction process step s3 shifts to the process path extraction process step s4, the process path extraction process starts, and the process moves to step d1. In the processing block extraction step, which is step d1, processing blocks are extracted from each source code. A processing block extraction method for extracting processing blocks will be described below. First, delimiters are inserted immediately before the control statement, immediately before the logical operator, immediately before the branch destination block branched according to the control statement, immediately before the return statement, immediately before the goto statement, and immediately before the break statement. The immediately preceding branch destination block branched according to the control statement means that if the branch destination is not described in the control statement, for example, if the else clause is not included in the if statement, the block immediately after the control statement is the branch destination block. Or just before the label in the goto statement. A declaration statement, an assignment expression, a conditional expression, and a block combining these in each section are extracted as processing blocks, and each processing block is given a name and stored. Also, empty sentences are extracted as processing blocks, stored with names. As described above, by extracting a section including no sentence as a processing block, it is possible to clarify which conditional expression is used to process the processing path. When a processing block is extracted and stored by such a processing block extraction method, the process proceeds from step d1 to step d2.

  In the processing path search start step, which is step d2, detection of processing blocks is started in order from the first line of the source code. When a processing block is detected, the detected processing block (hereinafter sometimes referred to as “detection processing block”) is stored as a processing block to be executed first in the processing path. When the detection processing block is stored, the process proceeds from step d2 to step d3.

  In step d3, it is determined whether the sentence immediately before the detection process block is a non-branch process sentence, a two-branch process sentence, or a multi-branch process sentence. If there is no statement immediately before the processing block, it is determined that the statement is a non-branch processing statement. If it is determined that the statement is a non-branch processing statement, the process proceeds from step d3 to step d4.

  If it is determined in step d3 that the sentence is a two-branch processing statement, the process proceeds to step d5. In step d5, it is determined whether or not a logical operator is described immediately after the processing block. If it is determined that the logical operator is not described, the process proceeds from step d5 to step d6. In step d6, two processing paths are detected when the detection processing block becomes true and false. Specifically, first, the processing block at the branch destination when the conditional expression of the two-branch processing statement becomes true (hereinafter sometimes referred to as “true processing block”) and each branch when the conditional expression becomes false A previous processing block (hereinafter may be referred to as a “fake processing block”) is detected. Next, detected true and false processing blocks are added as processing blocks to be executed next to the detection processing block, respectively, and two processing paths when the detection processing block becomes true and false are detected. The two processing paths are stored, and one of the detected two branch destination processing blocks is selected as a detection processing block, and the process proceeds from step d6 to step d3.

  If it is determined in step d5 that a logical operator is described, the process proceeds from step d5 to step d7. In step d7, two processing paths are detected when the detection processing block becomes true and false. Specifically, first, a true processing block, a false processing block, and a processing block immediately after the logical operator are detected. Next, based on the logical operator, a detected true processing block, a false processing block, and a processing block immediately after the logical operator are added as processing blocks to be executed next to the detection processing block. Two processing paths are detected when it becomes true and when it becomes false. For example, when the logical operator is a logical product, a false processing block and a processing block immediately after the logical operator are added as a processing block to be executed next. The next processing block is added as a processing block to be executed next. In each case, two processing paths are stored, the processing block immediately after the detected logical operator is set as a detection processing block, and the process returns from step d7 to step d5.

  If it is determined in step d3 that the statement is a multi-branch processing statement, the process proceeds to step d8. In step d8, processing paths corresponding to the number of branches in the multi-branch processing statement are detected. Specifically, first, a branch destination processing block (hereinafter sometimes referred to as a “branch destination processing block”) is detected. The number of branch destination processing blocks is the same as the number of branches. Next, each detected branch destination processing block is added as a processing block to be executed next to the detection processing block, and all processing paths branched according to the value of the detection processing block are detected. All these processing paths are stored, one of the plurality of branch destination processing blocks is selected as a verification processing block, and the process proceeds from step d8 to step d3.

  In step d4, it is determined whether or not a return statement is detected immediately after the detection processing block. If no return statement is detected, detection of the next processing block is started. The next processing block is the first processing block of the function if the detection processing block contains a function and the function is defined in the module. In other cases, the processing block is immediately after the verification processing block. That is, the processing block is detected in the order of module processing. However, in a loop statement such as a “while” statement, when it is detected once, the next processing block is detected on the assumption that the loop processing has been completed.

  When the next processing block is detected, this processing block is stored in the processing path as a processing block to be executed next to the detected processing block. The next processing block is selected as a detection processing block, and the process returns from step d4 to step d3. When a return statement is detected, the process proceeds from step d4 to step d9. In step d9, the search is terminated for the processing path for storing the detection processing block as the processing block to be executed, and the execution order of the processing blocks is determined for this processing path. When the processing path is determined, the process proceeds from step d9 to step d10.

  In step d10, it is determined whether or not the execution order of the processing blocks has been determined for all the processing paths. Specifically, a processing block that is not selected as a detection processing block among the true processing block, the false processing block, and the plurality of branch destination processing blocks is detected. When an unselected processing block is detected, it is determined that there is a processing path whose execution order of the processing blocks is not fixed, and an unselected processing block (if multiple processing blocks are not selected, Any one of the processing blocks) is selected as a detection processing block, and the process returns from step d10 to step d3. When a processing block that has not been selected is not detected, it is determined that the execution order of the processing blocks has been determined for all processing paths, and the processing path extraction process ends. When the processing path extraction process ends, the process proceeds from step s4 to step s5.

  Hereinafter, the processing path extraction processing will be specifically described using source code before and after the change. In the pre-change source code of the present embodiment, processing blocks are extracted based on the processing block extraction method in step d1. First, the source code before change is separated. Specifically, immediately before “int = c” on the third line, immediately before the if statement on the 12th line, immediately before the logical operator “&&” on the 12th line, immediately before “c = 5” on the 13th line. , 2 immediately before the return statement on the 15th line, 2 immediately before the while statement on the 18th line, 2 immediately before the if statement on the 19th line, 2 immediately before the break statement on the 20th line, and “b“ cnt ”on the 22nd line. "= Cnt * 10", immediately before the switch statement on the 26th line, immediately before the case statement on the 27th line, immediately before the case statement on the 29th line, immediately before the break statement on the 31st line, and return on the 34th line. Insert a total of 16 breaks immediately before the sentence.

  Next, based on these delimiters, the type declaration sentence of the section delimited by the delimiters is extracted as each processing block. Specifically, the type declaration statements and assignment expressions on the 3rd to 10th lines are processed in the processing block A1, the 12th line "a> = 100" is processed in the processing block B1, and the 12th line "a <200" is processed. Block C1, 13th line “c = 5” is processed block D1, 15th line empty statement immediately before the return statement is processed block E1, 18th line “cnt <10” is processed block F1, 19th line “Cnt> = c” is the processing block G1, the empty sentence immediately before the break statement in the 20th line is the processing block H1, the two substitution expressions from the 22nd line to the 23rd line are the two substitution expressions in the processing block I1, 26th line “sub” (A) "is the processing block J1," d = 30000 "on the 28th line is the processing block K1," d = d + 10000 "on the 30th line is the processing block L1, and the empty sentence immediately before the return statement on the 34th line is a processing block Extract as M1 . Table 7 shows the source code before change described using the extracted processing blocks. When each processing block is extracted in this way, the process proceeds from step d1 to step d2.

  In step d2, the processing block A1 detected first is stored as the processing block to be executed first in the processing path. When the processing block A1 is stored, the process proceeds from step d2 to step d3. In step d3, since there is no statement immediately before the processing block A1, it is determined as a non-branch processing statement. As a result, the process proceeds from step d3 to step d4. In step d4, since no return statement is described immediately after the processing block, detection of the next processing block is started. When the processing block B1 is detected as the next processing block, it is added to the processing path and stored as a processing block to be executed next to the processing block A1. As a result, the processing path A1-B1 is detected. This processing block B1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  In step d3, the statement immediately before the processing block B1 is determined to be a two-branch processing statement because the statement immediately before the processing block B1 is an if statement. As a result, the process proceeds from step d3 to step d5. In step d5, it is determined that a logical operator is described immediately after the processing block B1. As a result, the process proceeds from step d5 to step d7. In step d7, a processing block C1 that is a processing block immediately after the logical operator of the processing block B1 and a processing block E1 that is a false processing block are detected. The processing blocks C1 and E1 are added to the processing path A1-B1, respectively, and the processing paths A1-B1-C1 and A1-B1-E1 are detected. The processing block C1 is selected as a detection processing block, and the process returns from step d7 to step d5.

  In step d5, it is determined that no logical operator is described immediately after the processing block C1. As a result, the process proceeds from step d5 to step d6. In step d6, a processing block D1 that is a true processing block and a processing block E1 that is a false processing block are detected. The processing blocks D1 and E1 are added to the processing paths A1-B1-C1, respectively, and the processing paths A1-B1-C1-D1 and A1-B1-C1-E1 are detected. One of the processing blocks D1 and E1, that is, the processing block D1 in this embodiment is selected as a detection processing block, and the process returns from step d7 to step d3.

  In step d3, it is determined that the sentence immediately before the processing block D1 is a non-branching process. As a result, the process proceeds from step d3 to step d4. In step d4, since no return statement is described immediately after the processing block D1, detection of the next processing block is started. When the processing block F1 is detected as the next processing block, the processing block F1 is added to the processing path and stored as a processing block to be executed next to the processing block D1. As a result, the processing path A1-B1-C1-D1-F1 is detected. The processing block F1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  Also in the processing block F1, since the immediately preceding statement is a non-branching process and there is no return statement immediately after that, the process proceeds from step d3 to step d4, and the processing block G1 is detected as the next processing block. The processing block G1 is stored in the processing path as a processing block to be executed next to the processing block F1, and the processing path A1-B1-C1-D1-F1-G1 is detected. This processing block G1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  In step d3, since the sentence immediately before the processing block G1 is an if sentence, it is determined as a two-branch processing sentence. As a result, the process proceeds from step d3 to step d5. In step d5, it is determined that no logical operator is described immediately after the processing block. As a result, the process proceeds from step d5 to step d6. In step d6, a processing block H1 that is a true processing block and a processing block I1 that is a false processing block are detected. The processing blocks H1 and I1 are added to the processing paths A1-B1-C1-D1-F1-G1, respectively, and the processing paths A1-B1-C1-D1-F1-G1-H1 and A1-B1-C1-D1-F1 are added. -G1-I1 is detected. One of the processing blocks D1 and E1, that is, the processing block H1 in this embodiment is selected as a detection processing block, and the process returns from step d7 to step d3.

  Also in the processing block H1, the process proceeds from step d3 to step d4, and the processing block J1 is detected as the next processing block. The processing block J1 is stored in the processing path as a processing block to be executed next to the processing block H1, and the processing path A1-B1-C1-D1-F1-G1-H1-J1 is detected. This processing block J1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  In step d3, since the statement immediately before the processing block J1 is a switch statement, it is determined as a multi-branch processing statement. As a result, the process proceeds from step d3 to step d8. In step d8, the processing block K1 and the processing block L1, which are two branch destination processing blocks, are detected. The processing blocks K1 and L1 are added to the processing paths A1-B1-C1-D1-F1-G1-H1-J1, respectively, and the processing paths A1-B1-C1-D1-F1-G1-H1-J1-K1 and A1 are added. -B1-C1-D1-F1-G1-I1-L1 is detected. One of the processing blocks K1 and L1, in this embodiment, the processing block K1 is selected as a detection processing block, and the process returns from step d8 to step d3.

  The processing block K1 also moves from step d3 to step d4, and the processing block L1 is detected as the next processing block. The processing block L1 is stored in the processing path as a processing block to be executed next to the processing block K1, and the processing path A1-B1-C1-D1-F1-G1-H1-J1-K1-L1 is detected. This processing block L1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  The processing block L1 also moves from step d3 to step d4, and the processing block M1 is detected as the next processing block. The processing block M1 is stored as a processing block to be executed next to the processing block L1, and the processing path A1-B1-C1-D1-F1-G1-H1-J1-K1-L1-M1 is detected. This processing block M1 is selected as a detection processing block, and the process returns from step d4 to step d3.

  The processing block M1 also moves from step d3 to step d4. Since the statement immediately after the processing block M1 is a return statement, the process proceeds from step d4 to step d9. In step d9, the search for the processing path A1-B1-C1-D1-F1-G1-H1-J1-K1-L1-M1 is terminated, and the execution order of the processing blocks in the processing path is determined. When confirmed, the process proceeds from step d9 to step d10. In step d10, since there is an undefined processing path, one of the unselected processing blocks is selected, for example, the processing block B1 of the processing path A1-B1 is selected as a detection processing block. If selected, the process proceeds to step d3.

  Similarly, processing path detection is executed until all processing paths are determined. Table 8 shows the processing paths detected as a result of the processing path detection. When all the processing paths are determined in step d10, the processing path extraction process ends, and the process proceeds from step s5 to step s6. In the following, for the convenience of explanation, each processing path shown in Table 8 is referred to with an ordinal number and “before change” characters, such as a first pre-change processing path and a second pre-change processing path, from the top. There is. In Table 8, the first column indicates the name of the processing path, and the second column indicates the processing blocks included in the processing path and the processing order of the processing blocks.

  When the processing path extraction process is executed on the post-change source code as in the case of the pre-change source code, 14 processing blocks A2, B2, C2,. D2, E2, F2, G2, H2, I2, J2, K2, L2, M2, and N2 are extracted. Specifically, “int d” in the third line is the processing block A2, “a <= 100” in the sixth line is processing block B2, “a> 200” in the sixth line is processing block C1, and the seventh line. The empty statement immediately before the return statement is processed in block D2, the assignment expression on line 10, the function call on line 12, processing block E2, the type declaration statement on line 25, and the assignment expression on line 27 are processed in blocks F2, 28. “Cnt <c” in the row is the processing block G2, “cnt> = c” in the 29th row is the processing block H2, the empty sentence immediately before the break statement in the 30th row is the processing block I2, and the 32nd to 33rd rows. The second assignment expression of the second is the processing block J2, “sub (a−1) == 1” of the 14th row is the processing block K2, “d = 30000” of the 15th row is the processing block L2, “ d = d + 10000 ”as processing block M Extracts empty statements 20 line return Bunchokuzen as processing blocks N2. Table 9 shows the modified source code described using these extracted processing blocks. When each processing block is extracted, the process proceeds from step d1 to step d2.

  Similar to the source code before change, when the processing path is detected based on steps d2 to d10, the processing path shown in Table 10 is detected. When all the processing paths are determined, the processing path extraction process ends, and the process proceeds from step s4 to step s5. In this way, all processing paths of the source code before and after the change are detected. In the following, for the convenience of explanation, each processing path shown in Table 10 is referred to with an ordinal number and a “post-change” character, such as a first post-change processing path and a second post-change processing path in order from the top. There is. In Table 10, the first column indicates the name of the processing path, and the second column indicates the processing blocks included in the processing path and the processing order of the processing blocks.

  FIG. 8 is a flowchart showing the procedure of the input variable search process. FIG. 9 is a flowchart showing the procedure of the branch condition expression expansion method. In the input variable search process step that is step s5, the input variable search process is started to calculate the input variable and variable input value of each verification target module based on the source code, the branch condition expression, and each processing path. Search for the necessary conditions. In the input variable search process, the operation subject is the input variable search unit 11. Hereinafter, when the input variable search unit 11 is a control subject in the input variable search process, the description may be omitted.

  Hereinafter, the input variable search process will be specifically described. When the process path extraction process step s4 is shifted to the input variable search process step s5, the input variable search process is started, and the process shifts to step e1. In step e1, one of the plurality of branch conditional expressions is selected. When a branching conditional expression is selected, the process proceeds from step e1 to step e2. In step e2, one of the plurality of processing paths is selected. When the processing path is selected, the process proceeds from step e2 to step e3. In step e3, it is determined whether or not the selected branch conditional expression is included in any processing block of the selected processing path. If it is determined that the selected branching conditional expression is included, the process proceeds from step e3 to step e4.

  In step e4, it is detected whether or not the instruction statement to be executed before the selected branch conditional expression has a value assigned to the variable included in the branch conditional expression and whether the variable is referenced. In other words, it is detected whether a command statement to be executed before the selected branch condition expression includes a conversion expression such as an assignment expression and a function relating to the variable included in the selected branch condition expression. When a plurality of conversion expressions are detected, the conversion expression executed last is detected. When the conversion formula is detected, the process proceeds from step e4 to step e5.

  In step e5, it is determined whether or not the detected conversion formula has at least one of the three specific conditions. The first specific condition S1, which is one of the three specific conditions, is that the detected conversion expression includes an external function, and the variable included in the branch condition expression is passed by reference in the argument of the external function. . A specific description will be given based on the source code shown in Table 11. When “a == 1” is selected as the branch condition expression, “sub (& a)” is detected as a conversion expression. Since the selected variable a of the branch condition expression is passed by reference as an argument of the external function of the conversion expression, this conversion expression has the first specific condition S1.

  The second specific condition S2, which is one of the three specific conditions, is that the detected conversion expression is included in the block of the loop sentence. A specific description will be given based on the source code shown in Table 12. When “a == 1” is selected as the branch condition expression, “a = b” is detected as the conversion expression. Since the detected conversion formula is included in the block of the for sentence, this conversion formula has the second specific condition S2.

  The third specific condition S3, which is one of the three specific conditions, is that a variable included in the branch condition expression is passed by reference in the detected conversion expression. A specific description will be given based on the source code shown in Table 13. When “a == 1” is selected as the branch condition expression, “b = & a” is detected as the conversion expression. Since the variable a of the branch condition expression is passed by reference in the detected conversion expression, this conversion expression has the third specific condition S1.

  There is a possibility that the value of the variable of the conversion formula having these specific conditions changes due to the influence of an external function or the like. By detecting in advance as the specific condition in this way, it is possible to clarify factors that affect the certainty of the verification result in advance.

  If it is determined that any one of these three specific conditions is satisfied, the process proceeds from step e5 to step e6. In step e6, the conversion formula is classified into which specific condition among the three specific conditions is included. The classified specific conditions are stored in association with variables having the conversion formula, the position such as the number of lines in which the conversion formula is described, and the specific conditions. When the specific conditions are classified and stored, the process proceeds to step e7.

  In step e7, when the detected conversion expression includes the specific condition S2, a branching conditional expression is developed based on the detected conversion expression in the same manner as in step e8 described later. When the detected conversion formula has specific conditions S1 and S3, the value of the variable to which the reference is passed in the detected conversion formula changes due to the external function and processing not directly related to the variable There is. When the specific conditions S1 and S3 are provided, the branch condition expression that will not be expanded in the future in the input variable search process related to this branch condition expression and the branch condition expression that will be expanded as usual are extracted and stored. . For example, when a conversion expression “a = c” is detected after this, the former branching conditional expression remains in the form of “a == 1” and does not change, but the latter is expanded and “c == 1”. Is expanded. The stored branch condition expressions are processed as subsequent branch condition expressions. When the branch conditional expression that does not expand the variable and the expanded branch conditional expression are extracted and stored in this way, the process proceeds from step e7 to step e9.

  If it is determined in step e5 that the three specific conditions are not satisfied, the process proceeds to step e8. Note that the detected conversion formula may be a substitution of a value for a variable included in the branch condition formula or a reference to a variable included in the branch condition formula. The latter satisfies the specific conditions S1 and S3, and shifts from step e5 to step e6. Therefore, when the process proceeds to step e8, the detected conversion expression is always a value substitution for the variable included in the branch condition expression. In step e8, if the branch conditional expression is stored as not to be expanded in the future for a specific variable, and if the detected conversion expression is an assignment to the variable, nothing is performed. If it is not stored as not expanded, the branch condition expression is expanded based on the detected conversion expression. The expanded branch conditional expression is stored. When the branching conditional expression is expanded and stored, the process proceeds from step e8 to step e9.

  In step e9, it is detected whether or not there is an assignment of a value or the like to a variable included in the expanded branch condition expression in a command statement to be executed before the detected conversion expression. In other words, it is detected whether or not a conversion expression such as an assignment expression and a function related to a variable included in the expanded branch condition expression is included in an instruction statement to be executed before the detected conversion expression. When the conversion formula is detected, the conversion formula is set as the detected conversion formula, and the process returns from step e9 to step e5.

  Returning to step e5 and proceeding to step e7 or step e8, in step e7 or step e8, based on the conversion expression detected in step e9, the stored expanded branch conditional expression is expanded, and further expanded branch Stores conditional expressions. When the branching conditional expression thus expanded is further expanded and stored, the process proceeds from step e8 to step e9, and the same processing is performed in the same step e9. If it is determined in step e9 that the conversion formula is not detected, detection of the conversion formula is terminated, and the process proceeds from step e9 to step e10.

  Based on the source code shown in Table 14, branch condition expression expansion processing will be described with reference to FIG. For convenience of explanation, it is assumed that “b == 1” is selected as the branching conditional expression, and the description starts from step e4.

  In step e4, since the variable b is included in the selected branch conditional expression, “b = a + 1” is detected as the conversion expression. As a result, the process proceeds from step e4 to step e5. In step e5, it is determined that the conversion formula “b = a + 1” does not have any of the three specific conditions. As a result, the process proceeds from step e5 to step e8. In step e8, based on the conversion formula “b = a + 1”, the branch conditional expression “b = 1” is expanded and the expanded branch conditional expression “a + 1 = 1” is extracted and stored. As a result, the process proceeds from step e8 to step e9. In step e9, a statement describing the processing to be executed before the conversion expression “b = a + 1”, which includes the variable a of the expanded branch condition expression, the conversion expression “a = sub (3, x, y) "is detected. As a result, the process proceeds from step e9 to step e5.

  In step e5, it is determined that the conversion formula “a = sub (3, x, y)” does not have any of the three specific conditions. As a result, the process proceeds from step e5 to step e8. In step e8, based on the conversion expression “a = sub (3, x, y)”, the branch conditional expression “a + 1 = 1” is expanded and the branch conditional expression “sub (3, x, y) +1” is expanded. = 1 ”is extracted and stored. In this verification, the external function needs a value that it can take, and does not need to know what variable is used as an argument. Therefore, the expanded branch conditional expression is “sub () + 1 = 1”, and the argument does not have to be stored. In the following, arguments may not be described for external functions. As a result, the process proceeds from step e8 to step e9. In step e9, an assignment expression or function including the variable sub () cannot be detected in a statement describing a process executed before the conversion expression “sub () + 1 = 1”. As a result, the process proceeds from step e9 to step e10.

  In step e10, it is classified as to which of the two detection end conditions the end of detection of the conversion formula has been completed. The first detection end condition T1, which is one of the two detection end conditions, is a case where there is no variable in the expanded branch conditional expression. The second detection end condition T2, which is the other of the two detection end conditions, is a case where there is no command statement to be executed before the conversion formula. If it is classified that the detection has been completed with the first verification end condition T1, the process proceeds to step e11.

  In step e11, it is determined whether or not the expanded branch conditional expression includes an external function. If it is determined that an external function is included, the expanded branch conditional expression is stored as an expanded branch conditional expression, and the process proceeds to step e13. If it is determined that the external function is not included, nothing is processed and the process proceeds to step e13.

  If it is determined in step e10 that the second end condition T2 is satisfied and the detection is completed, the process proceeds to step e12. In step e12, it is determined whether or not a local variable is included in the expanded branch conditional expression. If it is determined that a local variable is included, the fact that a local variable having no value is detected is stored as local variable detection information, and a value of 0 is assigned to the local variable. The local variable for which the value is not set is set to 0 at the time of execution. Therefore, by setting the local variable to 0, an output value similar to that when actually executed is calculated. When 0 is substituted into the local variable and the detection end condition T1 is satisfied, the same processing as step e11 is performed, and the process proceeds to step e13. If it is determined that the detection end condition T1 is not satisfied even if a value of 0 is substituted, or that no local variable is included, the fact that there is no local variable that is not set as local variable detection information is stored, The expanded branch conditional expression that is included is stored as the expanded branch conditional expression. When the expanded branch conditional expression is stored, the process proceeds from step e12 to step e13.

  In step e13, it is determined whether or not processing has been performed on all processing paths in the selected branching conditional expression. If it is determined that the processing has been performed on all the processing paths, the process proceeds from step e13 to step e14. In step e14, it is determined whether all branch conditional expressions have been selected. If it is determined that all branching conditional expressions have been selected, the input variable search process ends, and the process proceeds from step s5 to step s6.

  If it is determined in step e3 that the selected branch conditional expression is not included in any of the processing blocks of the selected processing path, the process proceeds from step e3 to step e13. If it is determined in step e4 that there is no conversion formula, the process proceeds from step e4 to step e10. If it is determined in step e13 that at least one of the processing paths is unprocessed, one of the unprocessed processing paths is selected, and the process returns to step e4. If it is determined in step e14 that at least one of the branch conditional expressions is not selected, one of the unselected branch conditional expressions is selected, and the process returns to step e3.

  Hereinafter, the input variable search process will be described in detail using pre-change and post-change source code. In the pre-change source code of the present embodiment, in step e1, among the five branch conditional expressions shown in Table 5, the branch conditional expression “a> = 100” described in the 12th line of the pre-change source code is changed. elect. This shifts from step e1 to step e2. In step e2, the first change pre-processing path is selected. As a result, the process proceeds from step e2 to step e3. In step e3, since the selected branch conditional expression is included in the processing block B1, it is determined that the selected branch conditional expression is included. As a result, the process proceeds from step e3 to step e4.

  In step e4, “a = a−1” described in the 10th line of the source code before change is detected as a conversion formula. Since the conversion formula is detected, the process proceeds from step e4 to step e5. In step e5, since the detected conversion formula does not have any of the three specific conditions S1, S2, and S3, the process proceeds to step e8. In step e8, the selected branch conditional expression is expanded based on the detected conversion expression, and the expanded branch conditional expression “a-1> = 100” is extracted and stored. When the expanded branch conditional expression is stored, the process proceeds from step e8 to step e9.

  In step e9, it is determined that a conversion expression including the variable a cannot be detected. As a result, the process proceeds from step e9 to step e10. In step e10, the detection ends because it is impossible to detect the conversion expression including the variable a, and therefore it is determined that the detection end condition T2 is satisfied. As a result, the process proceeds from step e10 to step e12. In step e12, since no local variable is included in the expanded branch conditional expression, the expanded branch conditional expression “a-1> = 100” is stored as the expanded branch conditional expression. As a result, the process proceeds from step e12 to step e13.

  In step e13, in the selected branching conditional expression, the processing paths other than the first pre-change processing path are unprocessed, so any one of the unprocessed processing paths, for example, the second pre-change processing path. And returns to step e3. When processing is performed for the second pre-change processing route to the eighth pre-change processing route in the same manner as in the case of the first pre-change processing route, in step e13, processing is performed on all the processing routes in the selected branch conditional expression. It is determined that it has been broken, and the process proceeds to step e14.

  In step e14, since no branch conditional expression other than the branch conditional expression “a> = 100” is selected, any one of the unselected branch conditional expressions, for example, the 12th line of the source code before change is selected. Branch condition expression “a <200” is selected, and the process returns to step e2. In the same manner as in the case of the branch conditional expression “a> = 100”, the extracted branch conditional expressions are extracted and stored based on all the branch conditional expressions, and in step e14, all branch conditional expressions are selected. The input variable search process for the source code before change ends. Table 15 shows expanded branching conditional expressions extracted and stored in each processing path by this input variable search processing. In Table 15, the vertical axis indicates the processing path, and the horizontal axis indicates the branching conditional expression. “-” Indicates that the expanded branch conditional expression is not stored.

  Even in the modified source code of the present embodiment, when the input variable search process is performed in the same manner as the unmodified source code, the expanded branch conditional expression is shown in Table 10 based on the branch conditional expression shown in Table 6. Each of the processing paths shown is extracted and stored, and the input variable search process ends. Table 16 shows expanded branch conditional expressions extracted and stored in each processing path. In Table 16, the vertical axis represents the processing path, and the horizontal axis represents the branching conditional expression. In addition, “-” in Table 16 indicates that the expanded branch conditional expression is not stored. When the input variable search process for both the pre-change source code and the post-change source code is completed, the process proceeds from step s5 to step s6.

  FIG. 10 is a flowchart showing the procedure of the input value generation process. FIG. 11 is a flowchart showing the procedure of the input value determination process. In the test input value generation process step which is step s6, the test input value generation process is started, and the variable input value is calculated by the test input value generation unit 12 based on the expanded branch conditional expression. In the test input value generation processing, the operation subject is the test input value generation unit 12. Hereinafter, in the test input value generation process, when the test input value generation unit 12 is a control subject, the description may be omitted.

  Hereinafter, the test input value generation process will be specifically described. When the process proceeds from the input variable search process step s5 to the test input value generation process step s6, the test input value generation process is started, and the process proceeds to step f1. In step f1, in each verification target module, a developed branch conditional expression having the same content is detected among the stored developed branch conditional expressions. When an expanded branch conditional expression having the same contents is detected, one of the expanded branch conditional expressions is left and the rest is deleted. When deleted, the process proceeds from step f1 to step f2.

  In the input value determination processing step which is step f2, the input value determination processing is started and the input value is determined. Hereinafter, the input determination process will be specifically described with reference to the flowchart of FIG. When the process proceeds from step f1 to step f2, the input value determination process starts and the process proceeds to step g1. In step g1, a developed branch conditional expression including only one input variable, that is, a developed branch conditional expression of one variable is detected. If detected, the process proceeds from step g1 to step g2. In step g2, a branching conditional expression for one variable is subjected to constant separation, and a solution for the input variable is calculated. When the solution of the input variable is calculated, the process proceeds from step g2 to step g3.

  In step g3, it is determined whether or not an equal sign is included in the relational operator of the expanded branch conditional expression of one variable. In other words, it is determined whether the relational operator is “<=”, “==”, or “> =”. When it is determined that an equal sign is included in the relational operator, the process proceeds from step g3 to step g4.

  In step g4, the solution of the input variable is detected as a true input value that is an input value for which the branch condition expression is true. When a true input value is detected, the process proceeds from step g4 to step g5. In step g5, it is determined whether the relational operator is “<=”, “==”, or “> =”. If it is determined that the relational operator is “==” or “<=”, the process proceeds from step g5 to step g6. If it is determined that the relational operator is “> =”, the process proceeds from step g5 to step g7.

  In step g6, a value obtained by adding 1 to the solution of the input variable is detected as a false input value that is an input value for which the branch condition expression is false. The detected true and false input values are stored. When the true and false input values are stored, the process proceeds from step g6 to step g8. In step g7, a value obtained by subtracting 1 from the solution of the input variable is detected as a false input value. The detected true and false input values are stored. When the true and false input values are stored, the process proceeds from step g7 to step g8.

  If it is determined in step g3 that the relational operator does not include an equal sign, the process proceeds from step g3 to step g9. In step g9, the solution of the input variable is detected as a false input value. When a false input value is detected, the process proceeds from step g9 to step g10. In step g10, it is determined whether the relational operator is “<”, “! =”, Or “>”. If it is determined that the relational operator is “! =” Or “>”, the process proceeds from step g10 to step g11. If it is determined that the relational operator is “<”, the process proceeds from step g10 to step g12.

  In step g11, a value obtained by adding 1 to the solution of the input variable is detected as a true input value. The detected true and false input values are stored. When the true and false input values are stored, the process proceeds from step g11 to step g8. In step g12, a value obtained by subtracting 1 from the solution of the input variable is detected as a true input value. The detected true and false input values are stored. When the true and false input values are stored, the process proceeds from step g12 to step g8.

  In step g8, it is determined whether true and false input values have been determined for all expanded branch conditional expressions of one variable. If it is determined that it has not been calculated, the expanded branch conditional expression of one variable for which the true and false input values are not calculated is detected, and the process returns from step g8 to step g2. If it is determined that the input value has been determined, the input value determination process ends, and the process proceeds from step f2 to step f3.

  In step f3, it is determined whether or not there is an input variable whose true and false input values are not determined. If it is determined that there is an input variable that has not been determined, the process proceeds from step f3 to step f4.

  In step f4, the number of undetermined input variables is determined in a developed branch conditional expression including input variables whose true and false input values are undetermined (hereinafter may be referred to as “undetermined input variables”). To do. For example, in the expanded branch conditional expression including three input variables, if the true and false input values of two variable inputs are determined in step f2, it is determined that there is one undecided input variable. To do. If the true and false input values of one variable input are determined in step f2, it is determined that there are two undecided input variables. In this way, the number of undetermined input variables is determined. If it is determined that there is an expanded branch conditional expression in which the number of undetermined input variables is one, the process proceeds to step f5.

  In step f5, an input value of an undetermined input variable is determined. Specifically, first, an undecided input variable is used as a variable, an input variable detected by true and false input values is regarded as a constant, and a developed branch conditional expression is separated into constants. Next, the true and false input values are assigned to the input variables detected by the true and false input values, respectively. Substitution results in a one-variable expanded branch conditional expression of only undecided input variables, and returns from step f5 to step f2. Returning to step f2, the solution of the undetermined input variable is calculated, and the true input value and false input value of the undetermined input variable are detected.

  In the following, for a series of flows from step f4 to step f5 and returning to step f2, the expanded branch conditional expression is “a + b + c = 0”, and the combination of input values of the input variables a and b is (a , B) = (0, 2), (0, 3), and the case where the input variable c is an undetermined input variable will be described as an example. First, in step f4, the number of undetermined input variables is set to 1, and the process proceeds to step f5. In step f5, constant separation is performed for the input variable c, and the expression “c = −a−b” is calculated. Next, the input variables a and b are substituted for each combination to obtain two expressions “c = −2” and “c = −3”. When substituted, the process proceeds from step f5 to step f2 of the input variable c, and the true input value and false input value of the input variable c are detected. The combination of the detected true and false input values and the input variables a and b is (a, b, c) = (0, 2, -2), (0, 3, 2) when the variable c becomes true. -3), and the combinations that are false are (a, b, c) = (0, 2, −1), (0, 3, −2). The true and false input values calculated in this way are determined as the true and false input values of the input variable c.

  If it is determined in step f4 that there is no unfolded branch conditional expression having an undetermined input variable, the process proceeds to step f6. In step f6, one of the plurality of undecided input variables is selected, and the input value of this input variable is determined to be 1. As the selection method, for example, an input variable that is least used in the detected branching conditional expression is selected. When the input value of the undetermined input variable is determined to be 1 in this way, the process returns from step f6 to step f4.

  If it is determined in step f3 that there are no undetermined input variables, the process proceeds from step f3 to step f7. In step f7, the false input value of each input variable is stored as a variable input value. Among the detected variable input values, variable input values having the same true and false results for all expanded branch conditional expressions delete all other variable input values except for one variable input value. Further, a combination of variable input values for each input variable (hereinafter sometimes simply referred to as “combination”) is detected. In this way, a variable input value is generated. When the variable input value is generated, the input value generation processing step ends, and the process proceeds from step s6 to step s7.

  In this test input value generation processing, the input variable whose variable name is changed is regarded as the same input variable in the source code before and after the change, and the variable input value is detected. The detected variable input value is stored as the variable input value of each input variable considered to be the same. Specifically, for example, in the same function, when the variable names of the source code before the change and the source code after the change are different, the test input value generation process considers these input variables to be the same input variable, and these Are assumed to be input values to be input to each input variable.

  Hereinafter, the input variable search process will be described in detail with reference to the expanded branch conditional expressions in Tables 15 and 16 using the source code before and after the change. In step f1, six expanded branch conditional expressions are acquired based on the expanded branch conditional expressions obtained from the source code before and after the change. The six expanded branching conditional expressions are “a <= 100”, “a> = 101”, “a> 200”, “a <201”, “sub (1) = 1”, “sub (1)”. = 2 ". Here, 1 in “sub (1)” is an identification number. When these six expanded branch conditional expressions are acquired, the process proceeds from step f1 to step f2.

  When the process proceeds to step f2, the test input value generation process starts. In step g1, a branch conditional expression “a <= 100” of one variable is detected. If detected, the process proceeds from step g1 to step g2. In step g2, it is determined that an equal sign is included in the relational operator “a <= 100”. As a result, the process proceeds from step g2 to step g3. In step g3, 100, which is a constant of “a <= 100”, is stored as the true input value of the input variable a. As a result, the process proceeds to step g5.

  In step g5, it is determined that the relational operator of “a <= 100” is “<=”. As a result, the process proceeds from step g5 to step g6. In step g6, 101, which is a value obtained by adding 1 to 100, which is a constant of “a <= 100”, is stored as a false input value of the input variable a. As a result, the process proceeds from step g6 to step g8. In step g8, since there is a developed branch conditional expression of one variable for which true and false input values are not detected, the process returns from step g8 to step g1.

  Returning to step g1, the expanded branch conditional expression “a> = 100” of the next one variable is detected, and the true and false input values of the input variable a are detected based on this branch conditional expression. Since the other four expanded branch conditional expressions are also one variable expanded branch conditional expressions, they are similarly detected in step g1, and the true and false input values of each input variable are detected and stored. . Table 17 shows the true and false input values of each input variable detected based on each expanded branch conditional expression. When the expanded branching conditional expressions for all the one variables are detected, the test input value generation process ends, and the process proceeds from step f2 to step f3.

  In step f3, it is determined that there is no input variable whose variable input value has not been determined. As a result, the process proceeds from step f3 to step f8. In step f8, variable input values shown in Table 18 are detected based on the true and false input values of the input variables shown in Table 17. At this time, “a = 200” is deleted from the variable input values “a = 101” and “a = 200” in which the true / false results of all the expanded branch conditional expressions are the same. Each combination of variable input values shown in Table 18 is detected. The detected combinations are shown in Table 19. When the variable input value is generated in this way, the process proceeds from step s6 to step s7.

  In Table 19, the input variable is shown in the vertical line, and the combination number of each combination is shown in the horizontal line. For example, the combination number of (a, sub (1)) = (100, 1) is P1.

  FIG. 12 is a flowchart of the generated test program. In the test generation process which is step s7, the test generation unit 13 generates a test program based on a combination of the source code before and after the change, module information, identification number, input variable, and variable input value. The test program flow will be described with reference to FIG.

  First, in step h1, a combination of variable input values generated in the test input value generation processing step is selected, and the variable input value is substituted for each input variable. After selection and substitution, the process proceeds from step h1 to step h2. In step h2, the verification target module is called and an output value based on each substituted variable input value is calculated. When calculated, the process proceeds from step h2 to step h3. In step h3, each substituted variable input value and the calculated output value are output in association with each other. When output is performed, the process proceeds from step h3 to step h4.

  In step h4, it is determined whether all combinations have been selected. If it is determined that all combinations have been selected, the test program flow ends. If it is determined in step h4 that all combinations have not been selected, the process returns to step h1, a combination not selected is selected, and the variable input value is substituted for each input variable.

  Such a cycle that shifts from step h1 to step h4 and returns to step h1 is referred to as a test cycle. By repeating this test cycle, output values for the variable input values of all combinations are output.

  The test program further calculates the number of calls of the external function to which the same identification number is assigned, and assigns a variable input value of a different external function to each call. The verification may be insufficient due to the external function having the same variable input value. For example, an external function may be described in a loop statement such as a for statement, and the loop statement may be terminated based on the value of the external function. In this case, if the value of the external function does not change, it may fit into an infinite loop and verification may not end. By changing the input variable value of the external function for each call, it is possible to prevent the verification from being completed, and the module can prevent insufficient verification. However, this module is not necessarily required, and when there is no loop statement like the source code before and after the change, such a statement may be omitted. Further, when a certain number of calls are made, the loop sentence may be escaped.

  Table 20 shows test programs generated by the test generation unit 13 in such a test generation process. Hereinafter, the source code of the test program generated in the present embodiment (hereinafter sometimes referred to as “test source code”) will be described.

  In the test source code, first, input is made to each array of the input variable a and the variable input value of the external function sub () (from the first line to the 13th line). All variable input values of the input variable a are input to the array va [aNum], and all variable input values of the external function are input to the array vsub [subNum].

  The 14th to 53rd lines describe the source code of the test cycle flow, that is, the main function in the test program. The main function is assigned a function name (test in this embodiment) that does not overlap with a function name (func (), sub (), etc.) included in the source code before and after the change by the test generation unit 13. Has been. As a result, it is possible to prevent verification because the function names are the same.

  Lines 16 to 20 declare the type of each local variable. In the 22nd to 50th lines, each combination (combination of P1 to P9) is selected, and the output value of the function func is calculated based on the selected combination (40th line). The selected combination and the output value are associated with each other and output. All combinations of variable input values are output in association with the combination and output value. Specifically, the combination of the input variable a and the external function sub (), the function func that is the output value, and the function are output in association with the array b [10] before and after the operation. Get this output for all combinations.

  From the 55th line to the 75th line, every time an external function having the same identification number is called, the variable input value of the external function is changed. Specifically, when the variable input value “sub (1) = 1” is selected, when the external function “sub (1)” is first requested to input a value, the external function “sub (1)” is selected. ) "Is entered. Next, when input of the external function “sub (1)” is requested, another variable input value “sub (1) = 2” is input. Next, when input of the external function “sub (1)” is requested, another variable input value “sub (1) = 3” is input. When the detected variable input value is “sub (1) = 1, 2, 3”, the variable input value “sub (1) = 3” is input and then the external function “sub (1)” is input. Is requested, the variable input value “sub (1) = 1” is input again. Such a cycle is repeated to prevent insufficient verification due to an infinite loop or the like. When 2 is selected as the value to be input, the values are input in the order of “2”, “3”, and “1” starting from 2.

  When such a test source code is generated by the test generation unit 13, the process proceeds from step s7 to step s8.

  In the test execution process which is step s8, the test program generated in the test generation process s7 is executed. When the test program is executed, the output result is calculated for each combination for all combinations. The test execution unit 14 stores these output results. When the output result is stored, the process proceeds from step s8 to step s9. Table 21 shows the output result calculated by executing the test program based on the pre-change source code.

  Output results are shown for each combination. For example, the output result of the combination P1 of “a = 100, sub () = 1” is shown in the first to sixth lines as “Pattern1”. Similarly, from the seventh line to the 57th line, output results of the combinations P2 to P9 are shown as “Pattern2” to “Pattern9”.

  In the combinations P4 to P6, “call sub (100)” is shown as an output result. This indicates that in the combinations P4 to P6, the external function “sub ()” is called with the argument “a = 100”. In this way, the output value based on each combination P1 to P9 and whether or not an external function is called are output.

  Table 22 shows an output result obtained by executing the test program based on the changed source code. Similarly to the case of the source code before change, the post-change source code is output regarding the output value based on each combination P1 to P9 and whether or not the external function is called.

  FIG. 13 is a flowchart showing the procedure of the output value comparison verification process. In the output comparison verification process step that is step s9, the output comparison verification process is started, and the output value comparison verification unit 15 compares the output results output based on each verification target module with each other, and inputs the verification target module. Verifies the identity of the output value to the value. In the comparison verification process, the operation subject is the output value comparison verification unit 15. Hereinafter, in the comparison verification process, when the output value comparison verification unit 15 is a control subject, the description may be omitted.

  Hereinafter, the comparison verification process will be specifically described. When the process proceeds from the test execution process s8 to the comparison verification process process s9, the comparison verification process starts and the process proceeds to step j1. In step j1, the output results of the source code before and after the change are compared for each combination. When the comparison is made, the process proceeds from step j1 to step j2.

  In step j2, in the output results of the source code before and after the change, combinations in which the variable input values are the same and different output values are output are detected. If it is determined that the combination cannot be detected, the output value comparison verification process ends, and the process proceeds from step s9 to step s10. If it is determined that a combination is detected, the process proceeds from step j2 to step j3. In step j3, the detected combination and the pre-change and post-change source code output values are stored and output as verification results. When the verification result is output, the process proceeds from step j3 to step j4.

  In step j4, based on the module information, the specific conditions S1, S2, S3 and the local variable detection information, it is determined whether any one of the four insufficient conditions is met. The four inadequate conditions are (1) module information of each verification target module is different (including a case where only array elements are different), (2) having specific conditions S1 and S3, and (3) specifying condition S2. And (4) local variable detection information for detecting a local variable for which no value is set is stored. If any of these four inadequate conditions is met, verification may be inadequate. The corresponding insufficiency condition, which is determined to correspond to any of the four insufficiency conditions, is stored and output as a verification result, and the output value comparison verification process ends. If it is determined that none of the four inadequate conditions is met, the output value comparison verification process is terminated. When the output value comparison verification process ends, the output value comparison verification process step ends, and the process proceeds from step s9 to step s10.

  In the verification result notifying step, which is step s10, the output unit 5 notifies the user of the output result of the test execution processing step and the verification result of the output value comparison verification processing step. When notified, the program verification process ends.

  Table 23 shows the verification results verified by comparing the output results of the source code before and after the change in the verification result notification step. In the verification result, it is detected that the output values are different in the combination of P4 and P6.

  The user corrects a bug in the source code based on the verification result. Table 24 shows the changed source code in which the bug is corrected based on the verification result. The part corrected based on the verification result is the 15th to 22nd lines of the corrected source code, and the remarkable change part is that the if sentence on the 19th line is added. Correcting based on the verification result in this way makes it possible to obtain a normally refactored source code.

  The apparatus body 2 performs a program verification process by executing a verification program.

  Below, the effect which such a program verification apparatus 1 show | plays is demonstrated. According to the program verification apparatus 1 of the present embodiment, the input value calculation means 16 calculates a true input value and a false input value. The test generation unit 13 generates a test program that outputs an output value based on true and false input values. By executing the test program, the output value output based on the true and false input values can be calculated. By generating and executing test programs in the same way for the modules before and after the change, the true and false input values of the modules before and after the change and the output values based on these input values can be calculated. By comparing the calculated output values, it is possible to easily verify whether the output values based on the true and false input values of the pre-change module and the post-change module are the same. Thus, since the identity of the output value can be easily verified, for example, the identity of the output value with respect to the input value of the module after change and the module before change can be verified. By calculating the true and false input values of all conditional expressions, it is possible to verify all processing paths that can be traced by the module before and after the change, and it is possible to verify all output values that can be output. This makes it possible to realize a leak-free verification. Based on such a complete verification result, the user can detect the bug included in the module after the change without omission and easily correct the bug.

  According to the program verification apparatus 1 of the present embodiment, the input value calculation means 16 calculates a true input value and a false input value. Based on the true and false input values, the program execution means 17 executes the pre-change and post-change modules in which these input values are calculated, and outputs an output value based on the true and false input values. The output value comparison / verification unit 15 compares the output values of the pre-change module and the post-change module output by the program execution means 17 with each other. The output value comparison / verification unit 15 verifies whether the output values based on the true and false input values of the pre-change module and the post-change module are the same based on the comparison result. By verifying whether the output values based on the true and false input values are the same, for example, it is possible to save the user from verifying the identity of the output values with respect to the input values of the post-change module and the pre-change module. it can. Since there is no human intervention for verification, it is possible to prevent a user from omission of verification. Further, by calculating the true and false input values of all the conditional expressions, it is possible to verify all the processing paths (flows) that can be traced by each verification target program, and it is possible to verify all the output values that can be output. This makes it possible to realize a leak-free verification. It is possible to detect bugs included in the program after the change without omission based on such omission-free verification results and to promote the user to correct the bug without omission.

  According to the verification program of the present embodiment, it is possible to realize an apparatus that can easily verify whether or not the output values based on the true and false input values of each verification target program are the same.

  According to the program verification apparatus 1 of the present embodiment, whether or not four insufficient conditions are met is output. Accordingly, the user can easily determine whether or not the verification result is output based on sufficient verification. Further, when the verification result is insufficient, it is possible to notify the user that there is a possibility that a bug is included in a portion corresponding to the insufficient condition. By informing the user, the user is allowed to examine a portion corresponding to the insufficient condition, and also plays an auxiliary role in bug detection.

  According to the program verification apparatus 1 of the present embodiment, the test input value generation unit 12 deletes a combination of variable input values that have the same true / false result for all expanded branch conditional expressions. . As a result, combinations of variable input values to be calculated by the test execution unit 14 can be reduced, and the verification speed can be increased.

  According to the program verification apparatus 1 of the embodiment of the present invention, the input value of an undetermined input variable is set to 1. As a result, even if there is an input value of an undetermined input variable, it is possible to continue the verification of the source code and to prevent the verification from becoming impossible. In addition, by setting the input value of an undetermined input variable to 1, there are few cases where computation is impossible in an elementary function or the like, and the occurrence of cases where computation is impossible in conditional expressions and conversion formulas can be reduced. As a result, the source code can be verified to the end. In addition, when calculating the solution of the input value of the undecided input variable based on the all-branch conditional expression, it is often impossible to calculate the solution of the input value. Verification can be performed without doing it.

  In the present embodiment, the processing route extraction processing is performed according to the procedure described above, but the processing route may be extracted by a method described in Japanese Patent Laid-Open No. 2001-109644.

  In the present embodiment, when a loop statement is detected in the processing path extraction process, the processing block in the loop statement is extracted as the next processing block. However, depending on the conditional expression of the loop statement, the processing block in the loop statement may be processed continuously any number of times, including the case where the processing block in the loop statement is not the next processing block. It is also preferable to generate a processing path that does not set the processing block as the next processing block or a path that performs processing a plurality of times.

  In the present embodiment, the test generation unit 13 deletes the same expanded branch conditional expression and true and false input values that result in the same true / false result, leaving one branch conditional expression and the input value. However, it is not always necessary to delete. This is for speeding up the program verification processing of the program verification apparatus 1 and does not have to be deleted.

  In the present embodiment, when the true and false input values are determined by the input value determination process, 1 is added to or subtracted from the true or false input value, but the value to be added or subtracted is not necessarily limited to 1. Any positive integer may be used. In the source code of the present embodiment, since the input variable is an integer type, the value to be added or subtracted is 1. However, if the input variable is a real type input variable, the value to be added or subtracted may be a positive real number. . In this case, adding or subtracting 1 is effective when the value is declared and exceeds the possible value of the input variable due to type restrictions.

  The variable input values are only true and false input values, but are not necessarily limited thereto. For example, the maximum value (32767 in the case of 16-bit int type) and the minimum value (-32768 in the case of 16-bit int type) that can be taken by the input variable may be used as the variable input value due to restrictions of the declared type. Good. Similarly, 0 may be used as a variable input value. These values are values that tend to cause problems when the program is executed, and it is preferable that these verifications are also performed at the same time.

  Further, in the case of enumerated type (enum type) input variables, all of the enumerated input values may be used as variable input values.

  In the present embodiment, the output unit 5 notifies the output result and the verification result, but is not limited to notifying only such a result. For example, the module information may be notified, and if this is notified, the user can know the influence of the verification target module on the external module.

  In the present embodiment, the identity of two verification target modules is verified, but the present invention is not limited to two verification target modules. There may be three or more verification target modules. In this case, if the output value comparison / verification unit 15 has a function of outputting which verification target module calculates a different output result, it becomes clear which output result of the verification target module is different.

  In the present invention, the conditional expression of the control statement, for example, the “if” statement is delimited by each branch conditional expression, but is not necessarily limited to such a delimiter, and may be delimited for each conditional expression. In this case, in the processing route extraction processing, each conditional expression is determined to be true or false, and this conditional expression is added to the processing route as a detection processing block. As a result, even if the conditional expression is complicated, the processing path of the program can be easily searched.

  Furthermore, in the present invention, although the mathematical expression corresponding to the branch condition expression is one mathematical expression, the branch condition expression may include a plurality of expressions and logical operators. For example, as shown in Table 25, when the conditional expression of the if statement is “((a == 1 || b == 1) && c == 1)”, (a == 1 && b == 1) One processing block is assumed, and c == 1 is one processing block. Thus, even when the branch condition expression includes a branch condition as shown in Table 25, the processing condition is detected by dividing the branch condition expression into processing blocks including a plurality of mathematical expressions and logical operators. it can.

It is a block diagram which divides and shows the function of the program verification apparatus 1 of this Embodiment for every block. It is a flowchart which shows the procedure of a program verification process. It is a flowchart which shows the procedure of an output extraction process. It is a flowchart which shows the procedure of an identification number addition process. It is a figure which shows a part of source code before giving an identification number to an external function, and after giving. It is a flowchart which shows the procedure of a branch condition extraction process. It is a flowchart which shows the procedure of a process path | route extraction process. It is a flowchart which shows the procedure of an input variable search process. It is a flowchart which shows the procedure of the expansion | deployment method of a branch conditional expression. It is a flowchart which shows the procedure of an input value production | generation process. It is a flowchart which shows the procedure of an input value detection process. It is a flowchart of the generated test program. It is a flowchart which shows the procedure of an output value comparison verification process.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Program verification apparatus 2 Apparatus main body 13 Test production | generation part 15 Output value comparison verification part 16 Input value calculation means 17 Program execution means

Claims (3)

A conditional expression included in the source code of the verification target program that outputs an output value based on the input value that is input, and an input value that makes the conditional expression true and false that branches depending on whether the conditional expression is true or false Input value calculating means for calculating;
A program generation apparatus comprising: a program generation unit that generates a test program that outputs an output value based on an input value calculated by an input value calculation unit using a verification target program. A program verification device that verifies whether or not output values for input values of a plurality of verification target programs that output an output value are the same based on an input value that is input,
An input value calculation means for calculating, for each verification target program, an input value that is a conditional expression included in the source code of each verification target program and whose conditional expression is true or false depending on whether the conditional expression is true or false When,
Based on the input value calculated by the input value calculation means, program execution means for executing each verification target program used for calculation of the input value and outputting an output value;
Output value comparison means for comparing the output values of each verification target program output by the program execution means;
A program verification apparatus comprising: verification means for verifying whether or not the output values of the respective verification target programs are the same based on the comparison result of the output comparison means.   A verification program for controlling the program verification device according to claim 2.

Images