Program verification support system and program verification support method

Abstract

To generate stubs efficiently and to the extent required for verifying a program.SOLUTION: A program verification support system 1 executes a stub generation process which: identifies a conditional branch command, a condition clause variable of the conditional branch command, and a call command that is present before the conditional branch command from a call unit including one or more call commands, and a call unit of source code including a called unit that is called by the call command, respectively; retrieves a command that sets a prescribed value to the identified condition clause variable, or a non-variable setting command that sets the prescribed value to a variable that determines the value of the identified condition clause variable when the identified call command is excluded, from commands prior to the identified call command; and if the non-variable setting command is found, generates data that associates the identified condition clause variable with the called unit that is called by the identified call command.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a program verification support system and a program verification support method. [Background technology]

[0002] Due to changes in the times or changes in the execution environment, it may be necessary to change (convert) the source code of a program written in one language into another language. After conversion, it is necessary to test whether the converted program works in the same way as the unconverted program (confirmation of consistency between the current and new programs).

[0003] One method for such testing is to execute all instructions at the destination of each conditional branch instruction in the program (C0 coverage). In this case, test data is created that sets the initial values ​​of the program, and stub data (return values ​​of the subroutine) is created that corresponds to the subroutine called by the program's functions (such as a call instruction in the main routine).

[0004] Patent Document 1 discloses a test case generation program that causes a computer to execute the following processes: performing symbolic execution for each of a plurality of functions executed in a target program, and generating, for each of the plurality of functions, a path condition table including at least one of a first condition representing a history of branching related to a symbol variable and a second condition for an argument and a return value of the function; determining a match between a first function that calls one of the plurality of functions and a second function that is called by the first function; integrating the path condition tables for each function in parallel by logical AND for each of the first and second functions for which a match greater than at least one of the determined matches is determined; and calculating the value of a symbol variable that satisfies the path condition table after the integration, and generating a test case including the calculated value of the symbol variable. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2016-9344 A Summary of the Invention [Problem to be solved by the invention]

[0006] Patent Document 1 discloses a technique for shortening the time required to generate test cases by integrating the path conditions (range of values ​​of symbols that become return values) of functions (subroutines) that are called multiple times by taking the logical product of the path conditions. However, various types of processing are performed in subroutines that are replaced by stubs. For example, when a subroutine performs processing that reflects an arbitrary external condition, such as accepting user input, the return value of the subroutine may be different even when the variables in the source code are the same, depending on the position of the subroutine or the timing at which the subroutine is called. As a result, there is a risk that C0 coverage will be insufficient. In other words, there is a risk that sufficient coverage testing will not be performed by only considering the path conditions after the stub is called.

[0007] The present invention has been made in consideration of the above circumstances, and its purpose is to provide a program verification support system and a program verification support method that are capable of generating stubs to the necessary extent and efficiently, even for programs that have called parts that may have different return values ​​depending on the timing of the call. [Means for solving the problem]

[0008] One aspect of the present invention for solving the above problem includes a storage device that stores source code including a calling section including a plurality of call instructions and a called section that is called by each of the plurality of call instructions, and a statement extraction process that extracts, from the call section of the source code, a conditional branch instruction and a call instruction that exists before the conditional branch instruction in association with each other, and searches for a non-variable setting instruction that is an instruction that sets a predetermined value to a condition clause variable that is a variable that determines a conditional branch by the conditional branch instruction, or an instruction that sets a predetermined value to a variable that determines the value of the condition clause variable when the extracted call instruction is excluded, from instructions prior to the extracted call instruction, and when the non-variable setting instruction is found, extracts first stub data that is data that associates information indicating the position of the call instruction and the condition clause variable with the plurality of call instructions. a control device that executes a first stub data generation process for generating, for a plurality of call instructions, second stub data in which a value of a condition clause variable of the first stub data is determined based on a condition content related to the condition clause variable and the determined value is added to the first stub data as a return value of the called unit; and a third stub data generation process that analyzes each instruction of the call unit to identify an execution path of the call unit that executes a conditional branch instruction that executes a call instruction related to the second stub data and executes processing of a predetermined branch destination based on the value of the condition clause variable related to the second stub data, and generates, for the plurality of call instructions, third stub data, which is data indicative of the identified execution path and associated with the second stub data. Effect of the Invention

[0009] According to the present invention, stubs can be generated efficiently to the required extent even for a program having a called part that may have a different return value depending on the timing of the call. Configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0010] [Figure 1]FIG. 1 is a diagram illustrating an example of a configuration of a program verification support system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram showing an example of source code of a first program for explaining the present embodiment. [Diagram 3] FIG. 2 is a diagram illustrating an example of main functions of the language conversion support device. [Figure 4] FIG. 2 is a diagram illustrating an example of a hardware configuration of each information processing device in the program verification support system. [Diagram 5] FIG. 11 is a flow diagram illustrating an example of a stub generation process. [Figure 6] FIG. 11 is a flow diagram illustrating details of a command statement extraction process. [Figure 7] FIG. 13 is a diagram illustrating an example of an assignment statement table. [Figure 8] FIG. 13 is a diagram showing an example of a call command statement table. [Figure 9] FIG. 2 is a diagram illustrating an example of a branch instruction table. [Figure 10] FIG. 13 is a diagram showing an example of a region division table. [Figure 11] FIG. 13 is a diagram illustrating an example of a chain table for each variable in a condition clause. [Figure 12] FIG. 13 is a flowchart illustrating details of a process of analyzing dependency relationships for each variable in a condition clause. [Figure 13] FIG. 13 is a diagram illustrating an example of a table of branch instructions affected by each call instruction; [Figure 14] FIG. 13 is a diagram for explaining an example of a trace process for each variable in a condition clause. [Figure 15] FIG. 13 is a diagram showing an example of a first stub entry table. [Figure 16] FIG. 11 is a flow diagram illustrating details of a simplex stub item table generation process. [Figure 17] FIG. 13 is a flow diagram illustrating details of a multiple call stub item table generation process. [Figure 18] FIG. 13 is a diagram for explaining a specific example of a multiple call corresponding stub item table generation process. [Figure 19] FIG. 13 is a diagram showing an example of a generated second stub entry table. [Figure 20]FIG. 13 is a diagram showing an example of a data format of a call instruction line number in the second stub item table. [Figure 21] FIG. 11 is a flow diagram illustrating details of a scenario corresponding stub item table generating process. [Figure 22] FIG. 13 is a diagram illustrating an example of a scenario table. [Figure 23] FIG. 13 is a diagram showing an example of a third stub entry table. [Figure 24] FIG. 13 is a diagram showing another example of the third stub entry table. [Diagram 25] FIG. 13 is a diagram showing another example of the third stub entry table. [Figure 26] FIG. 13 is a diagram showing an example of a third stub item table generated when a main routine has a while-type (infinite loop type) loop process. [Figure 27] FIG. 13 is a diagram showing an example of a third stub item table generated when a main routine has a for-type (counter-type) loop process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described in detail with reference to the drawings. FIG. 1 is a diagram showing an example of the configuration of a program verification support system 1 according to the present embodiment. The program verification support system 1 includes a user terminal 10 that stores a program written in a first language (first program 100), a language conversion device 20 that converts the first program 100 into a program written in a second language (second program 200) and generates test case data 300, a language conversion support device 40 that generates a first stub item table 400 (single stub item table), a second stub item table 420 (multiple call corresponding stub item table), and a third stub item table 440 (scenario corresponding stub item table) based on the first program 100, a test code generation device 30 that generates test code 500 that defines the contents of tests for the second program 200 based on the test case data 300 and the third stub item table 440, and a verification device 50 that verifies whether the conversion from the first program 100 to the second program 200 executed by the language conversion device 20 has been correctly performed based on the second program 200 and the test code 500.

[0012] The user terminal 10, the language conversion device 20, the language conversion support device 40, the test code generation device 30, and the verification device 50 may be connected by a wired or wireless communication network such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line, or may be connected directly by a communication line.

[0013] The first language and the second language are not particularly limited as long as they support at least an assignment instruction, a conditional branch instruction, and a call instruction, such as COBOL, Java (registered trademark), or C++. In this embodiment, the first language is COBOL, and the second language is Java (registered trademark).

[0014] (Source Code) 2 is a diagram showing an example of source code of a first program 100 for explaining this embodiment. The source code of the first program includes a main routine 110 (calling portion) that is executed first when the program is executed, and a first subroutine 130 and a second subroutine 140 that are called portions that are called and executed by a first call instruction 111 and a second call instruction 112 from the main routine 110, respectively.

[0015] The main routine 110 includes a first assignment instruction 116 for assigning (setting) a constant value (source constant value 114) to an assigned variable 115, a second assignment instruction 119 for assigning (setting) the value of a variable (source variable 117) to an assigned variable 118, and a conditional branch instruction 120.

[0016] The first call instruction 111 (hereinafter also referred to as a simple call instruction or PERFORM) does not have an argument to be passed to the first subroutine 130. Therefore, in the first subroutine 130, all variables in the source code can be referenced, set, or changed. As a result, the values ​​of all variables in each instruction after the first call instruction 111, at least until the next first call instruction appears, may be changed by the execution of the first call instruction 111 (hereinafter, such variables that may be changed by the execution of a call instruction are referred to as dirty variables. Also, variables that are not dirty variables are referred to as non-dirty variables).

[0017] On the other hand, the second call instruction 112 (hereinafter also referred to as an argument-specified call instruction or CALL) has one or more arguments 121 to be passed to the second subroutine 140. Therefore, in the second subroutine, only the passed arguments 121 are referenced, set, or changed. As a result, after the second call instruction 112, among the variables in each instruction until the next second call instruction (or the next first call instruction) with the same variable as an argument appears, only the variables related to the argument 121 of the second call instruction 112 may have their values ​​set or changed by the execution of the second call instruction 112 (dirty variables).

[0018] A conditional branch instruction 120 includes a condition clause 122 and action clauses 124 which are processes at the branch destination that are executed when the condition indicated by the condition clause 122 is satisfied and when it is not satisfied. Here, the condition clause 122 is a part that judges whether or not the value of a variable (condition clause variable 125) constituting the condition satisfies (true or false) the condition indicated by a relational operator 126 and a parameter to be judged 127 (variable or constant). Also, there may be only one action clause 124 (there is only one action part that is executed when the condition indicated by the condition clause 122 is satisfied (or not satisfied)).

[0019] In the first program 100 of this embodiment, at least one called section (subroutine) is called by a plurality of call instructions in the main routine 110. Such a called section has, for example, a process of accepting input from a user, or a process of accepting input or reception of data from an independent program other than the first program 100. In other words, such a called section may return different return values ​​to the main routine depending on the timing of calling or the position of the call instruction, even if the values ​​of each variable in the first program 100 are the same.

[0020] The source code of the second program 200 is also configured to include a main routine, a subroutine, and various types of instructions, like the source code of the first program 100, although the language and detailed grammar are different.

[0021] When a test is conducted on the second program 200 to execute all instructions in the conditional branch instruction in the main routine (covering C0), the language conversion device 20 generates test case data 300 corresponding to the main routine as well as a third stub item table 440 corresponding to the subroutine.

[0022] Specifically, the test case data 300 output by the language conversion device 20 is data that defines a pattern of initial input data to the second program 200. In other words, the test case data 300 is data that defines a pattern of initial values ​​of the main routine of the second program 200.

[0023] On the other hand, the third stub item table 440 is data that stores return values ​​of variables of a subroutine together with a list of the variables (a list of stubs of the called part). In other words, the third stub item table 440 is data that defines the pattern of the execution result of a subroutine of the second program 200.

[0024] Conventionally, when generating such a stub, it was necessary to analyze the subroutine, or an unnecessary stub was generated. Therefore, the language conversion support device 40 of this embodiment can generate a stub (third stub item table 440) having only the data necessary for the C0 coverage of the second program 200 by only analyzing the main routine without referring to the processing contents of the subroutine. Also, as described above, the called part may return a different return value to the main routine depending on the timing of the call even if the value of the variable in the first program 100 is the same. Even in such a case, the language conversion support device 40 of this embodiment can generate a stub that enables the testing of the C0 coverage of the second program 200.

[0025] 3 is a diagram illustrating an example of main functions of the language conversion support device 40. The language conversion support device 40 includes a command statement extraction unit 41, a first stub data generation unit 43, a second stub data generation unit 44, and a third stub data generation unit 45.

[0026] The command statement extraction unit 41 extracts a conditional branch instruction and a call instruction that exists before the conditional branch instruction from a call portion (main routine) of the source code, in association with each other.

[0027] The first stub data generation unit 43 searches for an instruction that sets a predetermined value (hereinafter referred to as a literal in this specification) to a condition clause variable, which is a variable that determines the conditional branch due to the conditional branch instruction extracted by the command statement extraction unit 41, or a non-variable setting instruction, which is an instruction that sets a predetermined value (literal) to a variable that determines the value of the condition clause variable when the call instruction extracted by the command statement extraction unit 41 is excluded, from instructions preceding the call instruction extracted by the command statement extraction unit 41.

[0028] Specifically, first stub data generation unit 43 sets constant values ​​as literals and searches for non-variable setting instructions from instructions preceding the extracted call instruction. Also, first stub data generation unit 43 sets values ​​of variables that do not depend on initial input variables for the source code (input variables for the main routine) as literals and searches for non-variable setting instructions from instructions preceding the extracted call instruction.

[0029] Then, when the first stub data generation unit 43 is able to search for a non-variable setting instruction, it generates first stub data (first stub item table 400, standalone stub item table) for a plurality of call instructions in the main routine, which is data associating information indicating the position of the call instruction extracted by the command statement extraction unit 41 (specifically, the line number) with the above-mentioned condition clause variable (the condition clause variable in the conditional branch instruction extracted by the command statement extraction unit 41). In other words, the first stub data is data in which the return value of the call section called by the call instruction whose position has been identified is set as the value of the above-mentioned condition clause variable.

[0030] Next, the second stub data generation unit 44 determines the value of the condition clause variable of the first stub data based on the condition content related to the condition clause variable, and generates second stub data (second stub item table 420, multiple call compatible stub item table) for multiple call instructions, which is data in which the determined value is added to the first stub data as a return value of the called part. That is, the second stub data is data in which the return value of each variable (condition clause variable of the condition branch instruction) of each call part is added to the first stub data.

[0031] The third stub data generating unit 45 analyzes each instruction of the calling part (main routine) to identify an execution path of the main routine that executes the calling instruction related to the second stub data and further executes a conditional branch instruction that executes a process of a predetermined branch destination based on the value of the conditional variable related to the second stub data, and generates third stub data (third stub item table 430, scenario-corresponding stub item table) for a plurality of calling instructions, which is data that associates information indicating the identified execution path with the second stub data. That is, the third stub data is data in which an execution scenario including a calling instruction and a branch according to the value of the conditional variable of the conditional branch instruction, which is indicated by the second stub data, is added to the second stub data. The third stub data is data that corresponds to a specific processing scenario of the source code (corresponding to the specific status of each variable when the called part is called).

[0032] 4 is a diagram showing an example of a hardware configuration of each information processing device (the language conversion device 20, the language conversion support device 40, the test code generation device 30, and the verification device 50) in the program verification support system 1. Each information processing device includes a control device 91 such as a CPU (Central Processing Unit), a main storage device 92 such as a RAM (Random Access Memory) or a ROM (Read Only Memory), an auxiliary storage device 93 such as a HDD (Hard Disk Drive) or an SSD (Solid State Drive), an input device 94 such as a keyboard, a mouse, or a touch panel, an output device 95 such as a display or a touch panel, and a communication device 96 configured of a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Interface) module, a serial communication module, or the like.

[0033] The functions of the functional units of each information processing device in the program verification support system 1 described above are realized by the control device 91 reading out a program from the main storage device 92 or the auxiliary storage device 93. Each program can be recorded on a portable or fixed recording medium and distributed, for example. Note that all or a part of these programs may be realized using virtual information processing resources provided using a virtualization technology, a process space separation technology, or the like, such as a virtual server provided by a cloud system. Also, all or a part of these programs may be realized by a service provided by a cloud system via an API (Application Programming Interface), for example. Next, the processing performed by the program verification support system 1 will be described.

[0034] <Stub generation process> 5 is a diagram illustrating an example of a stub generation process (stub generation process) performed by the language conversion support device 40. The stub generation process is started, for example, when the language conversion support device 40 receives the first program 100 from the user terminal 10.

[0035] First, the command statement extraction unit 41 executes a command statement extraction process s11 to obtain a main routine of the first program 100, extract command statements (assignment commands, call commands, conditional branch commands) from the obtained main routine, and divide the main routine into each area.

[0036] <Command sentence extraction process> FIG. 6 is a flow diagram illustrating the command statement extraction process s11 in detail. First, the command statement extraction unit 41 generates each of the following tables: an assignment command statement table 600 that consolidates information about assignment commands, a call command statement table 700 that consolidates information about call commands, and a branch command statement table 800 that consolidates information about conditional branch commands (s111).

[0037] Then, the command statement extraction unit 41 generates an area division table 1300 based on each table generated in s111 (s112-s113).

[0038] The area division table 1300 is a table that sets out each area (hereinafter referred to as a large area) whose starting position is each first call instruction in the call section (main routine) of the source code, and each area (hereinafter referred to as a small area) within each large area whose starting position is each second call instruction.

[0039] Specifically, the command statement extraction unit 41 sets a large area based on a simple call command (PERFORM) (s112). Specifically, the command statement extraction unit 41 extracts all the first rows of the row number list 702 of the records whose type 703 is a simple call command (PERFORM) among the records of the call command statement table 700 described later. Then, for each simple call command, the command statement extraction unit 41 sets a large area name (e.g., 0, 1, 2, 3, ...) for each row in the call section from the row in which the simple call command exists to the row immediately preceding the row in which the next simple call command exists.

[0040] The command statement extraction unit 41 sets small areas based on the argument-specified call command (CALL) in each large area set in s112 (s113). Specifically, first, the command statement extraction unit 41 specifies the range of line numbers of each large area specified in s1311. Then, within the specified range of line numbers, the command statement extraction unit 41 extracts all first lines of the line number list 702 of records whose type 703 is the argument-specified call command (CALL) among the records in the call command table 700 described later. Then, for each argument-specified call command, the command statement extraction unit 41 sets small area names (e.g., 0, 1, 2, 3, ...) for each line in the call section from the line in which the argument-specified call command exists to the line immediately preceding the line in which the next argument-specified call command exists.

[0041] (Assignment statement table) 7 is a diagram showing an example of an assignment command statement table 600. As shown in the figure, the assignment command statement table 600 has data items of record number 601 in which the serial number of the command statement is set, line number list 602 in which a list of line numbers of the source program in which the assignment command is described is set, S variable 603 in which the variable to be substituted (source variable) is set, fixed value 604 in which the constant value to be substituted (source constant value) is set, and D variable list 605 in which a list of substituted variables to which the value of the source variable or the source constant value is substituted is set. Note that the records of the assignment command statement table 600 are sorted in ascending order of the line number of the source program (i.e., from the first line to the last line of the source program).

[0042] A constant value indicated by the fixed value 604 or a variable indicated by the S variable 603 that is not set in the test case data 300 can be a literal. For convenience of explanation, this embodiment will describe a case where the literal is only a constant value.

[0043] (Call command statement table) 8 is a diagram showing an example of a call command statement table 700. As shown in the figure, the call command statement table 700 has data items of a record number 701 in which the number of the call command is set, a line number list 702 in which a list of line numbers of the source program in which the call command is written is set, a type 703 in which the type of the call command is set, and a call destination argument list 704 in which a list of information (such as the name and arguments of the call destination) of the called part (subroutine) that is the call destination by the call command is set. Note that the records of the call command statement table 700 are sorted in ascending order of the line numbers of the source program (i.e., from the first line to the last line of the source program).

[0044] (Branch statement table) 9 is a diagram showing an example of a branch command statement table 800. As shown in the figure, the branch command statement table 800 has data items of a record number 801 in which the number of a conditional branch command is set, a line number list 802 in which a list of line numbers of a source program in which a conditional branch command is described is set, a type 803 in which the type of the conditional branch command is set, and a condition clause variable execution clause line number list 804 in which a list of line numbers in a source program of each execution clause executed according to a condition and a condition clause variable in a condition clause in a conditional branch command is set. Note that the records in the branch command statement table 800 are sorted in ascending order of line numbers of the source program (i.e., from the first line to the last line of the source program).

[0045] (Area classification table) 10 is a diagram showing an example of an area partition table 1300. The area partition table 1300 has data items of a line number 1301 in which the line number of the calling part (main routine) of the source code is set, a command statement 1302 in which the command statement in the line of the line number is set, a PERFORM area division 1303 in which the name of the large area associated with the line of the line number is set, a CALL area division 1304 in which the name of the small area associated with the line of the line number is set, and an area name 1305 in which the name of the partition area formed by combining the large area and the small area is set.

[0046] As shown in the figure, a large area (the area whose starting position is the first call command) is divided into a first small area within the large area (e.g., area name "1-0", "2-0"), which is the area from the starting position of the large area to just before the start of the first small area within the large area (the area whose starting position is the second call command), and subsequent small areas within the large area (e.g., area name "1-1"), which are the small areas after the first small area within the large area. In this way, there is one call instruction in each partitioned area (first small area in a large area, subsequent small areas in a large area), and there is a called part that is called by that call instruction.

[0047] Next, as shown in FIG. 5, the setting command search unit 42 executes a dependency relationship analysis process s13 for each variable in a condition clause to generate a chain table 900 for each variable in a condition clause based on the tables generated in the command statement extraction process s11.

[0048] Chain table 900 for variables in a condition clause is information on the contents of a trace when tracing starts with a conditional branch instruction in a main routine (call part), straddling the call instructions that precede it, toward the beginning of the main routine, and tracing the variables that determine the value of the conditional branch instruction's conditional variable (link the value of the conditional variable) when the call instruction is excluded, until a non-variable setting instruction that assigns a literal to a variable appears. Chain table 900 for variables in a condition clause is generated for each conditional branch instruction's conditional variable.

[0049] (Chain table for each variable in a condition clause) FIG. 11 is a diagram showing an example of a chain table 900 for each variable in a condition clause generated in the process s13 for analyzing dependency relationships for each variable in a condition clause.

[0050] Chain table 900 for each variable in a condition clause has the following data items: record number 901; starting line number 902, in which the starting line number of each traced command statement is set; type 903, in which the type of command statement (e.g., conditional branch command (condition clause), assignment command, first call command, second call command) is set; and attribute list 904, in which a list of the processing targets of the command statement (e.g., source constant value, source variable, assigned variable, condition clause variable, uncalled part) is set.

[0051] In chain table 900 for variables in a condition clause, records are arranged in reverse order of line numbers of the main routine of the source code, starting with a record whose type 903 is a conditional branch instruction (condition clause). The last record in chain table 900 for variables in a condition clause is a record related to a non-variable setting instruction (a record in which an assignment instruction is set in type 903 and a literal (such as a source constant value) is set in attribute list 904), or a record related to the first line of the main routine (when no non-variable setting instruction is found even after tracing to the beginning of the main routine).

[0052] <Analysis of dependency relationships for each variable in a condition clause> 12 is a diagram for explaining the details of the dependency relationship analysis process s13 for each variable in a condition clause. The setting command search unit 42 executes an affecting branch command extraction process s131 for each call command to generate an affecting branch command table 1400 for each call command based on the branch command table 800, the call command table 700, and the area partition table 1300 generated in the command statement extraction process s11. The affecting branch command table 1400 for each call command is a table that stores, for each small area of ​​each large area in the area partition table 1300, whether or not each variable present in that small area is a dirty variable with respect to the execution of the first call command of the large area to which the small area belongs.

[0053] Specifically, the setting command search unit 42 refers to the area division table 1300, identifies the first small area in a large area (the first small area in the large area), and stores information indicating that all variables in the identified small area are dirty variables in association with the small area.

[0054] Thereafter, the setting instruction search unit 42 refers to the area division table 1300, identifies the i-th (i=2, 3, . . .) small area in the large area (i.e., the area from the line number of the i-th argument-specified call instruction (CALL) to the line number immediately before the i+1-th argument-specified call instruction (CALL)), and identifies the argument (variable) of the argument-specified call instruction (CALL) related to the i-th small area for the identified small area. Then, if the called part of the argument-specified call instruction (CALL) related to the identified argument is different from the called part of the simple call instruction (PERFORM) related to the large area, the setting instruction search unit 42 determines that the argument is a non-dirty variable in the i-th small area, and the other variables are dirty variables. Note that the setting instruction search unit 42 stores the argument (variable) that was determined to be a non-dirty variable in the i-1-th small area as a non-dirty variable in the i-th small area as well.

[0055] In other words, after a PERFORM statement, all variables that appear in that large region are dirty variables, and in the next PERFORM statement (next large region), all variables become dirty again. On the other hand, after a CALL statement, all variables specified as its arguments are dirty. In other words, because a CALL statement occurs after a PERFORM statement, there is a possibility that the CALL statement will overwrite variables that have been made dirty by the PERFORM statement and that are related to the arguments of the CALL statement. Therefore, the arguments related to the CALL statement become dirty variables. Thereafter, the dirty variables will be different each time a CALL statement appears.

[0056] (Table of branch instructions that affect each call instruction) 13 is a diagram showing an example of a call instruction-by-call instruction affected branch instruction table 1400. The call instruction affected branch instruction table 1400 stores dirty variable information 1403 indicating whether a variable 1402 processed by each command statement set in a command statement of each small area 1401 is a dirty variable in each small area. In the example shown in the figure, the dirty variable information 1403 is set to "◯" if the target variable is a dirty variable, and set to "×" if the target variable is a non-dirty variable.

[0057] Next, as shown in FIG. 12, the setting command search unit 42 executes a trace process for each variable in a condition clause s133 to generate a chain table for each variable in a condition clause 900 based on the assignment command statement table 600 generated in the command statement extraction process s11 and the impact branch command table for each call command 1400 generated in the impact branch command extraction process for each call command s131.

[0058] <Tracing process for each variable in a condition clause> FIG. 14 is a diagram for explaining an example of the process s133 for tracing each variable in a condition clause. First, the setting command search unit 42 refers to the branch command statement table 800, identifies a conditional branch command in the main routine, and creates a record 1501 in the conditional variable chain table 900 relating to the identified conditional branch command (s1331).

[0059] Specifically, the setting command search unit 42 sets the first line number in the source code of the condition clause of the identified condition branch command (line number list 802 of branch command statement table 800) to the start line number 902 of the chain table 900 for each variable in the condition clause, sets the type 903 to "condition clause" (type 803 of branch command statement table 800), and sets the condition clause variable to the attribute list 904 (the condition clause variable in the condition clause variable execution clause line number list 804 of the branch command statement table 800).

[0060] Next, the setting command search unit 42 refers to the assignment command statement table 600, searches for variables that have a dependency on the condition clause variable identified above by going back to each command prior to the command related to the condition clause variable, and creates records 1502, 1503 in the chain table 900 for variables in condition clauses related to each of the searched variables and the commands related to the variables (s1333).

[0061] Specifically, the setting command search unit 42 acquires variables in the attribute list of the record in the chain table 900 for variables in a condition clause generated above. The setting command search unit 42 then refers to the assignment command statement table 600 from the last record to the first record (i.e., going backwards through the line numbers of the source code). The setting command search unit 42 then finds a record 1505 in which the acquired variable is set in the D variable list, and sets the contents of the D variable list (assigned variables) of the found record 1505 and the contents of the S variable (assigned variable) of the found record 1505 in the attribute list of a record 1502 newly generated in the chain table 900 for variables in a condition clause, sets the type to "assignment", and sets the minimum line number in the line number list of the found record 1504 as the start line number.

[0062] Furthermore, the setting command search unit 42 continues to refer to the assignment command statement table 600 and finds a record 1504 in which the assigned variable in the attribute list of the record 1502 in the newly generated chain table 900 for each variable in a condition clause is set to the assigned variable in the D variable list. The setting command search unit 42 sets the contents of the D variable list (assigned variable) of the found record 1504 and the contents of the S variable (assigned variable) or fixed value (constant value) of the found record 1504 in the attribute list of the record 1504 further generated in the chain table 900 for each variable in a condition clause, sets the type to "assignment", and sets the minimum row number in the row number list of the found record 1504 to the start row number. The setting command search unit 42 repeats such a reference to the assignment command statement table 600 until a constant value (literal) is set in the attribute list of the record 1504 in the chain table 900 for each variable in a condition clause further generated.

[0063] In this way, the setting instruction search unit 42 identifies the value (constant value) of the condition clause variable that determines the conditional branch destination of a certain conditional branch instruction, excluding (ignoring) the call instruction that precedes the conditional branch instruction.

[0064] Next, the setting command search unit 42 refers to the call command table 700, and inserts the records 1506 and 1507 relating to the call command into the chain table 900 for variables in a condition clause generated as described above (s1335).

[0065] Specifically, the setting command search unit 42 selects one record 1508 from the call command statement table 700, and identifies the first row number indicated by the row number list of the selected record 1508. Then, the setting command search unit 42 identifies consecutive records 1502 and 1503 whose identified row number is between the row numbers indicated by the start row numbers of consecutive records 1502 and 1503 in the chain table 900 for each variable in a condition clause, and generates a new record 1506 between the identified consecutive records 1502 and 1503. The setting command search unit 42 sets the identified row number as the start row number of the generated new record 1506, sets the content of the type of the record 1508 of the selected call command statement table 700 as the type, and sets the content of the call destination argument list of the record 1508 of the selected call command statement table 700 as the attribute list. The setting command search unit 42 repeats such processing for each record in the call command statement table 700.

[0066] The setting instruction searching unit 42 repeats the above process for all the conditional branch instructions in the branch instruction statement table 800 .

[0067] 5, the first stub data generation unit 43 refers to the chain table for each variable in a condition clause 900 for each condition clause variable generated by the setting command search unit 42. Then, when the first stub data generation unit 43 can search for a non-variable setting command from the chain table for each variable in a condition clause 900, it executes a standalone stub item table generation process s15 for generating first stub data (first stub item table 400, standalone stub item table) in which information indicating the position of a call command (line number of source code) and a condition clause variable are associated with the non-variable setting command.

[0068] (First stub item table) FIG. 15 is a diagram showing an example of the first stub item table 400. In the first stub item table 400, the data of each record is the first stub data. Specifically, each record in the first stub item table 400 has the following data items: record number 401, stub name 402 in which the name of the called part (subroutine) is set, call instruction line number 404 in which information (line number) indicating the position of the call instruction calling the called part is set, and variable list 403 in which a list of names of condition clause variables whose values ​​may be changed by the called part (list of condition clause variables that become return values ​​in the stub) is set. The first stub item table 400 may have multiple records (i.e., records of multiple call instruction line numbers) for a certain combination of a called part and a variable. If a non-variable setting instruction cannot be found, null data is set in the variable list 403.

[0069] <Extraction of variables set for each subroutine> FIG. 16 is a flow diagram for explaining the details of the standalone stub item table generation process s15. The first stub data generation unit 43 selects one condition clause variable by tracing back from the beginning of the source code, and sets this as the processing target variable (s151). Specifically, the first stub data generation unit 43 refers to the affected branch instruction table for each call instruction 1400, selects one small area in which a condition clause variable whose argument is a dirty variable ("O") exists, and selects one condition clause variable related to that argument.

[0070] Then, the first stub data generation unit 43 refers to the chain table 900 for each variable in a condition clause related to the variable to be processed, and determines whether or not there is a non-variable setting instruction that sets a literal to the variable to be processed or to the variable that is the source of the variable to be processed (s153).

[0071] Specifically, the first stub data generation unit 43 determines whether or not a literal (constant value) is set as a substitution variable in the attribute list 904 of the last record in the chain table 900 for each variable in a condition clause.

[0072] If there is another small area between the small area in which the literal (constant value) is set and the small area related to the condition clause variable selected in s151 (in the example of the figure, there is another small area starting from a CALL statement between "area 1-0" and "area 1-1"), the first stub data generation unit 43 may refer to the affected branch instruction table for each call instruction 1400 and confirm that the condition clause variable selected in s151 is a non-dirty variable ("x") in the other small area. This makes it possible to confirm that the condition clause variable selected in s151 determines (is directly linked to) the literal (constant value) even if a call instruction (CALL statement) is present in the other small area.

[0073] If a non-variable setting instruction is present (s153: YES), first stub data generation unit 43 executes s155, and if a non-variable setting instruction is not present (s153: NO), first stub data generation unit 43 executes s159.

[0074] In s159, the first stub data generation unit 43 adds null information related to the processing target variable to the first stub item table 400. For example, the first stub data generation unit 43 generates a new record in the first stub item table 400, sets null information to the stub name 402 of the generated record, sets the processing target variable (conditional clause variable) to the variable list 403, and sets null information to the call command statement line number 404. After that, the processing of s161 is executed.

[0075] Meanwhile, in S155, first stub data generation unit 43 identifies a subroutine (called part) that corresponds to the variable to be processed and is located closest to the conditional branch instruction related to the variable to be processed, and a call instruction that is the caller of the subroutine. Specifically, first stub data generation unit 43 acquires attribute list 904 and start line number 902 of the first record in chain table 900 for each variable in a condition clause where a call instruction appears in type 903.

[0076] Then, first stub data generation unit 43 adds stub information related to the subroutine (called part) identified in s155 and the call instruction of the caller of the call instruction to first stub item table 400 (s157). For example, first stub data generation unit 43 generates a new record in first stub item table 400, sets the name of the called part in attribute list 904 obtained in s155 to stub name 402 of the generated record, sets the processing target variable (condition clause variable) to variable list 403, and sets the content of start line number 902 obtained in s155 to call instruction statement line number 404. After that, the processing of s161 is performed.

[0077] In s161, the first stub data generation unit 43 determines whether or not there is a condition clause variable that has not been selected in s151. If there is a condition clause variable that has not been selected in s151 (s161: YES), the first stub data generation unit 43 selects one condition clause variable that has not been selected (one that is further down in the row number) and repeats the processing from s151 onwards. If there is no condition clause variable that has not been selected in s151 (s161: NO), the first stub data generation unit 43 ends the single stub item table generation processing s15.

[0078] Next, as shown in FIG. 5, the second stub data generation unit 44 executes a multiple-call compatible stub item table generation process s17 to determine the value of the condition clause variable of the first stub data in the first stub item table 400, and generate second stub data (second stub item table 420, multiple-call compatible stub item table) using the determined value as the return value of the called part.

[0079] <Stub item table generation process for multiple calls> 17 is a flow diagram illustrating the details of the multiple call corresponding stub item table generation process s 17. The second stub data generation unit 44 acquires the first stub item table 400 generated in the single unit stub item table generation process s15 (s171).

[0080] The second stub data generating unit 44 selects one of the segmented areas set in the command statement extraction process s11 (s173).

[0081] The second stub data generation unit 44 generates new data by merging the first stub item tables 400 (first stub data) for the called parts (stubs) called from the call instruction of the partition area selected in s173 (s175). For example, the second stub data generation unit 44 generates new data (data made up of a plurality of first stub item tables 400) by merging the first stub item tables 400 whose stub names 402 are common to the stubs of the selected partition area.

[0082] The second stub data generation unit 44 determines the pattern of the return value of the stub by identifying all patterns of the return value of each variable by the called part corresponding to the call instruction of the partitioned area selected in s173 (s177).

[0083] For example, the second stub data generation unit 44 performs symbolic execution of the segmented area selected in s173 to determine which target process each conditional branch instruction following a call instruction in that segmented area will branch to depending on the value of its condition clause variable.

[0084] The second stub data generation unit 44 generates combinations of each variable and its return value determined in s177, and generates records for the second stub item table 420 by adding the generated combinations to the data generated in s175 (s179).

[0085] The second stub data generating unit 44 checks whether the processes of s175 to 179 have been executed for all segmented areas (s181). If the processes of s175 to 179 have been executed for all segmented areas (s181: Yes), the multiple call corresponding stub item table generating process s17 ends, and if the processes of s175 to 179 have not been executed for all segmented areas (s181: No), the process repeats the process of s173 to select the next segmented area.

[0086] 18 is a diagram for explaining a specific example of the multiple call corresponding stub item table generation process s17. Here, it is assumed that multiple large areas 1801 are generated by the command statement extraction process s11, and that a first small area 1802 in the large area and multiple subsequent small areas 1803 in the large area are identified as partitioned areas in the first large area 1801A. It is assumed that a first stub item table 400A is generated for the first small area 1802 in the large area, in which line number 50 of a call instruction (PERFORM) is associated with condition clause variables {A, B} whose values ​​may be changed by the execution of PERFORM (dirty variables). It is also assumed that a first stub item table 400B is generated for the subsequent small area 1803 in the large area, in which line number 80 of a call instruction (CALL) is associated with condition clause variables {A} whose values ​​may be changed by the execution of CALL (dirty variables).

[0087] First, the second stub data generation unit 44 merges the first stub item table 400A and the first stub item table 400B with respect to a predetermined called part (not shown) called in the first large region 1801A, using the called part (stub name 402) as a key. The second stub data generation unit 44 executes the first large region 1801A symbolically, thereby determining that the branch destination of the conditional branch instruction 1804 in the first small region 1802 in the large region differs depending on whether the values ​​of the conditional clause variables A and B are 10 and 0, respectively, or whether the values ​​of the conditional clause variables A and B are 11 and 1, respectively. The second stub data generation unit 44 also determines that the branch destination of the conditional branch instructions 1805 and 1806 in the subsequent small region 1803 in the large region differs depending on whether the value of the conditional clause variable A is 201 or 200, and whether the value of the conditional clause variable B is 0 or 1, respectively.

[0088] (Second stub item table) 19 is a diagram showing an example of the generated second stub item table 420. As shown in the diagram, the second stub item table 420 has data items including a stub number 421 in which the number of the called part (stub) called from the call instruction of the partitioned area is set, a call instruction statement line number 422 in which information (line number) indicating the position of each call instruction that calls the stub is set, one or more return values ​​424 in which the value of each variable (condition clause variable) after the execution of the called part called by each call instruction is set, and a shot number 423 in which a number assigned to each combination of each variable and its return value (i.e., a number assigned to each branch destination (shot) of the condition branch instruction after the called part) is set.

[0089] In the example shown in the figure, for the called part (stub #1) called from the call instruction in the first small area 1802 in the large area, two shots are set as the return values ​​of each variable after execution of the called part (the condition clause variables and their values ​​of the conditional branch instruction existing in the first small area 1802 in the large area): "A's return value 10 and B's return value 0" and "A's return value 11 and B's return value 1."

[0090] Furthermore, even if the condition clause variables of a conditional branch instruction include variables that are not set as the return value of the called part (stub) (return value 424 of second stub item table 420), such variables are set in test case data 300, so there is no problem with testing using test code 500 generated based on the second stub item table 420 (and third stub item table 440).

[0091] In addition, with regard to the called part (stub #2) called from the call instruction in the subsequent small area 1803 within the large area, four shots are set as the return values ​​of each variable after execution of the called part (the condition clause variables and their values ​​of the conditional branch instruction existing in the first small area 1802 within the large area): “A's return value 201 and B's return value 0”, “A's return value 200 and B's return value 1”, “A's return value 201 and B's return value 1”, and “A's return value 200 and B's return value 0”.

[0092] 20 is a diagram showing an example of a data format of the call instruction statement line number 422 of the second stub item table 420. First, in this example, it is assumed that a first small area 2002 in a large area and two subsequent small areas 2003A and 2003B in a large area are specified as partitioned areas in a large area 2001 of a source code. Then, it is assumed that a first stub item table 400A is generated for the first small area 2002 in a large area, in which a line number 50 of a call instruction (PERFORM) in the called part F0 is associated with a condition clause variable {A, B, C} whose value may be changed by execution of PERFORM (a dirty variable). It is also assumed that a first stub item table 400B is generated for the subsequent small area 2003A in a first large area, in which a line number 80 of a call instruction (CALL) in the called part F1 is associated with a condition clause variable {A} whose value may be changed by execution of CALL of an argument A (a dirty variable). Also, for the subsequent small area 2003B within the second large area, a first stub item table 400C has been generated that associates the line number 350 of the call instruction (CALL) of the called part F1 of argument B with the condition clause variable {B} whose value may be changed by the execution of the CALL (it is a dirty variable). In this case, the line number "50" of the call instruction (PERFORM) in the first small region 2002 in the large region, the line number "80" of the call instruction (CALL) in the subsequent small region 2003A in the first large region, and the line number "350" of the call instruction (CALL) in the subsequent small region 2003B in the second large region (i.e., in its own segmentation region) are listed and set in the order of the source code in the call instruction statement line number 422 of the second stub item table 420 related to a certain segmentation region. In this way, the line numbers of the call instructions existing in segmentation regions far from the certain segmentation region may be set in the call instruction statement line number 422 of the second stub item table 420 related to a certain segmentation region.

[0093] Next, as shown in FIG. 5, the third stub data generation unit 45 executes a scenario-corresponding stub item table generation process s19 to identify each execution path (scenario) by analyzing each instruction of the calling section (main routine) and generate third stub data (third stub item table 440) that corresponds the scenario to the second stub data (second stub item table 420).

[0094] <Scenario-compatible stub item table generation process> FIG. 21 is a flow diagram illustrating the details of the scenario-corresponding stub item table generation process s19. First, the third stub data generation unit 45 generates a scenario table 2200 that records the contents of each execution path by identifying the patterns of all execution paths of the code for a certain partitioned area in the calling part (main routine) of the source code (s191).

[0095] For example, the third stub data generation unit 45 identifies an execution path in a certain partitioned area that includes a call instruction, a conditional branch instruction following the call instruction (there may be multiple conditional branch instructions), and processing of the branch destination depending on the value of the condition clause variable in the conditional branch instruction.

[0096] In the case of the first small area (first partitioned area) within a large area, the third stub data generation unit 45 executes a first call instruction (PERFORM) and then executes a conditional branch instruction that executes processing of a specified branch destination based on the values ​​of the condition clause variables related to the second stub item table 420 for that PERFORM (all condition clause variables in the conditional branch instruction after the PERFORM), thereby identifying the execution path (execution path) of the first partitioned area.

[0097] In the case of a subsequent small area (second partitioned area) within a large area, the third stub data generation unit 45 executes a second call instruction (CALL) and then executes a conditional branch instruction that executes processing of a specified branch destination based on the value of a condition clause variable related to the second stub data for that CALL (the same condition clause variable as the argument of the CALL in the conditional branch instruction after the CALL), thereby identifying an execution path for the second partitioned area.

[0098] (Scenario table) 22 is a diagram showing an example of a scenario table. Scenario table 2200 has the following data items: record number 2201, scenario number 2202 in which a number assigned to each execution path (scenario) is set, call order 2203 in which the order in which call instructions of each scenario appear is set, stub number 2204 in which the number of a stub corresponding to a called part called by the call instruction is set, and shot number 2205 in which the number assigned to each branch destination (shot) of a conditional branch instruction following the called part is set.

[0099] Next, as shown in FIG. 21, the third stub data generation unit 45 selects one of the scenarios identified in s191 (s193).

[0100] The third stub data generator 45 checks each process in the scenario selected in s193, starting from the top of the source code, and identifies all conditional branch instructions (s195).

[0101] The third stub data generation unit 45 selects one conditional branch instruction from the conditional branch instructions identified in s195, starting from the side closest to the beginning of the source code (s197).

[0102] The third stub data generation unit 45 identifies the called part (stub) and its shot associated with the conditional branch instruction selected in s197 (s199).

[0103] Specifically, the third stub data generation unit 45 identifies the condition clause variable of the conditional branch instruction selected in s197, identifies the call instruction (in the same partition area) that exists before the conditional branch instruction, and obtains the contents of the stub number 2204 and shot number 2205 of the record related to the call instruction in the scenario table 2200.

[0104] The third stub data generation unit 45 adds information relating to the called part (stub) and shot identified in s199 to the third stub item table 440 in association with the scenario selected in s193 (s201).

[0105] For example, the third stub data generation unit 45 acquires the contents of the return value 424 of the record in the second stub item table 420 in which the contents of the stub number 2204 and shot number 2205 acquired in s199 are set to the stub number 421 and shot number 423, respectively, and sets the acquired contents and the scenario number selected in s193 in a new record in the third stub item table 440.

[0106] (Scenario-compatible stub item table) 23 is a diagram showing an example of the third stub item table 440. This third stub item table 440A has records each having each data item of record number 441A, scenario number 442A in which the number of each scenario is set, call order 443A in which the order in which the call instructions in each scenario appear (the order in which the call instructions appear from the beginning of the source code) is set, and return value 444A, which is one or more data items in which the return value of each variable by the called part called by the call instruction in each scenario (the return value of the stub) is set.

[0107] 24 is a diagram showing another example of the third stub item table 440. This third stub item table 440B has the data items of record number 441B, scenario number 442B in which the number of each scenario is set, and return value 443B in which the return value (stub return value) of each variable by the called part called by each call instruction in each scenario is set. In this way, even if the data item of call order 443A is omitted, the number of records related to each scenario is fixed, so the appearance order of the call instructions can be specified by record number 441B.

[0108] 25 is a diagram showing another example of the third stub item table 440. This third stub item table 440C has data items of record number 441C, scenario number 442C in which the number of each scenario is set, and return value 443C in which the return value of each variable by the called part called by each call instruction in each scenario (stub return value) is set. In this way, in the return value 443C, data is set in which pairs of variable names and their return values ​​are combined for the number of variables, such as {[variable name, return value of that variable", [variable name, return value of that variable", ...}. This makes it possible to minimize the number of data items in the third stub item table 440 even when the stub has return values ​​for many variables.

[0109] 5, the test code generation device 30 generates test code 500 based on the third stub item table 440 and the test case data 300. For example, the test code generation device 30 generates data for executing the second program 200 according to each scenario and the return value of each stub, as the test code 500, based on the test case data 300, the scenario table 2200, and the third stub item table 440.

[0110] The above-described third stub item table 440 can be applied even when the main routine has a loop process using a conditional branch instruction. An example of this will be described below.

[0111] (If the main routine has a while-type loop) FIG. 26 is a diagram showing an example of the third stub item table 440 generated when the main routine has a while-type (infinite loop type) loop process. As shown in the figure, a loop process 2602 is performed at the branch destination of TRUE by a conditional branch instruction 2601 of this main routine. This loop process 2602 has a call instruction 2603 of argument A that calls F0 (stub #3) and a conditional branch instruction 2604 related to argument A, and is repeatedly executed until argument A becomes a predetermined value. After this loop process 2602, the subsequent process is executed (scenario #3). In addition, as records related to stub #3 in the second stub item table 420, there are records 2605 and 2606 of two shots (return values ​​201 and 200 of A) specified by symbolic execution. In this case, the third stub item table 440D generated has records 2607 and 2608 of the above two shots as records related to scenario #3. In this way, even if the main routine has a while-type (infinite loop) loop, the third stub item table 440D can properly generate stubs that cover the execution paths related to the loop.

[0112] (When the main routine has a for-type loop) 27 is a diagram showing an example of the third stub item table 440 generated when the main routine has a for type (counter type) loop process. As shown in the figure, at the branch destination of TRUE by a conditional branch instruction 2701 of this main routine, a loop process 2702 by a counter I is performed. This loop process 2702 has a call instruction 2703 of an argument A that calls F0 (stub #3) and a conditional branch instruction 2704 of a counter I that is a conditional variable, and is executed three times based on the conditional variable. After this loop process 2702, there are a first branch destination process (scenario #3) and a second branch destination process (scenario #4) by a conditional branch instruction 2705 with the argument A as a conditional variable. The second stub item table 420 has records 2706, 2707, 2708 of three shots identified by symbolic execution as records related to stub #3. However, since the shot caused by a conditional branch instruction 2704 of a conditional clause variable I related to counter I does not depend on argument A, no value is set to the return value A of the first record 2706, and the second and third records 2707, 2708, which are two shots caused by a conditional branch instruction 2705 with argument A as a conditional clause variable, have return values ​​201, 200 of A corresponding to scenarios #3 and #4 set. The third stub item table 440D generated in this case has three records 2709, 2710, 2711 related to the above loop processing 2702 as records related to scenario #3. Of these, the return values ​​of the first and second records 2709, 2710 corresponding to the call instructions 2703 executed the first and second times are not set in accordance with the first record 2706 of the second stub item table 420, and the return value (201) is set in the record 2711 corresponding to the call instruction 2703 executed the third time. The third stub item table 440D also has three records 2712, 2713, and 2714 relating to the above loop processing 2702 as records relating to scenario #4. Of these, the return values ​​of the two records 2712, 2713 corresponding to the call instruction 2703 executed the first and second times are not set in accordance with the first record 2706 in the second stub item table 420, and the return value (200) is set in the record 2711 corresponding to the call instruction 2703 executed the third time.In this way, the third stub item table 440D contains data that enables stubs to be generated correctly even if the main routine has a counter-type loop process such as a for statement.

[0113] As described above, the program verification support system 1 of this embodiment first (1) extracts a conditional branch instruction and a call instruction existing before it from the call part of the source code in association with each other, and if an assignment instruction for setting a literal to the condition variable of the conditional branch instruction or a non-variable setting instruction, which is an assignment instruction for setting a literal to a variable that determines the value of the condition variable when the call instruction is excluded, can be found from an instruction before the call instruction, the program verification support system 1 generates first stub data (first stub item table 400, single stub item table) in which the line number of the call instruction and the condition variable are associated with each other for multiple call instructions. Next, the program verification support system 1 (2) determines the value of the condition variable of the first stub data based on the condition content related to the condition variable, and generates second stub data (second stub item table 420, multiple call corresponding stub item table) for multiple call instructions in which the determined value is added to the first stub data as the return value of the called part (return value of the stub). Then, the program verification support system 1 (3) analyzes each instruction of the main routine to identify an execution path of the main routine that executes a call instruction related to the second stub data and a conditional branch instruction that executes processing of a predetermined branch destination based on the value of the condition clause variable related to the second stub data, and generates third stub data (third stub item table 440, scenario-corresponding stub item table) for multiple call instructions that associates information indicating the identified execution path with the second stub data.

[0114] That is, the program verification support system 1 of this embodiment generates stub data (third stub item table 440) targeting a called part (subroutine) called from multiple calling parts, and the third stub item table 440 has data corresponding to an execution path having a call instruction and processing of a branch destination based on the value of a condition clause variable of a conditional branch instruction, i.e., an execution scenario of a main routine.

[0115] Therefore, the program verification support system 1 of this embodiment can generate stubs efficiently to the necessary extent even for a program that has a called part that may have a different return value depending on the timing of the call.

[0116] If a non-variable setting instruction is followed by a call instruction, which is followed by a conditional branch instruction, the subroutine called by the call instruction is likely to rewrite the value of the variable related to the non-variable setting instruction, thereby determining the execution node to be executed based on the conditional branch instruction. Therefore, each stub data generated by the program verification support system 1 of this embodiment is data that can generate stubs required for verifying the main routine, without checking the specific contents of the subroutine.

[0117] In addition, the program verification support system 1 of this embodiment generates second stub data (second stub item table 420, multiple call compatible stub item table) by determining the value of the condition clause variable of the first stub data by identifying the value of the variable that determines each branch destination by the conditional branch instruction related to the condition clause variable.

[0118] This makes it possible to generate the second stub entry table 420 that reliably captures the processing of each branch that may be executed by the conditional branch instruction.

[0119] In addition, the program verification support system 1 of this embodiment identifies an execution path (scenario) from the main routine that includes a call instruction, a conditional branch instruction following the call instruction, and processing of the branch destination depending on the value of the condition clause variable in the conditional branch instruction, identifies second stub data (second stub item table 420, multiple call-compatible stub item table) that includes the call instruction corresponding to the identified scenario, the condition clause variable in the conditional branch instruction, and the value of the condition clause variable, and generates third stub data (third stub item table 440, scenario-compatible stub item table) that associates the identified second stub data with information indicating the above scenario.

[0120] In this way, by identifying a scenario and second stub item table 420 in which a call instruction and a subsequent conditional branch instruction and a branch destination pattern correspond to each other, and generating a third stub item table 440 that associates them, it is possible to generate a stub that corresponds to the situation in which the called unit is called.

[0121] Furthermore, the program verification support system 1 of this embodiment extracts from the main routine the first small area in the large area whose starting position is PERFORM and the subsequent small area in the large area whose starting position is CALL, and generates first stub data, second stub data, and third stub data for each of these divided areas.In this case, the program verification support system 1 searches for non-variable setting instructions for each variable of the condition clause variables in the case of PERFORM, and searches for non-variable setting instructions for the variables (arguments) of the condition clause variables in the case of CALL.

[0122] In this way, by setting different partition areas according to the type of call instruction (specifically, according to the type of variables that may be rewritten by the called part called by the call instruction) and searching for non-variable setting instructions, and then generating third stub data for each partition area, it is possible to generate stubs that appropriately reflect the effects on variables (condition clause variables) that are due to different types of call instructions.

[0123] The present invention is not limited to the above-described embodiment, and can be implemented using any components without departing from the scope of the present invention. The above-described embodiments and modifications are merely examples, and the present invention is not limited to these contents as long as the features of the invention are not impaired. In addition, although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of ​​the present invention are also included in the scope of the present invention.

[0124] For example, part of the hardware included in each device of this embodiment may be provided in another device.

[0125] Furthermore, each program of each device may be provided in another device, a program may consist of multiple programs, or multiple programs may be integrated into one program. [Explanation of symbols]

[0126] 1 Program verification support system, 40 Language conversion support device, 41 Statement extraction unit, 43 First stub generation unit, 44 Second stub generation unit, 45 Third stub generation unit

Claims

1. A storage device that stores a source code including a calling part including a plurality of calling instructions and a called part that is called by each of the plurality of calling instructions; a statement extraction process for extracting, from a call portion of the source code, a conditional branch instruction and a call instruction existing before the conditional branch instruction in association with each other; a first stub data generation process for searching for a non-variable setting instruction, which is an instruction for setting a predetermined value to a condition variable that is a variable that determines a conditional branch by the conditional branch instruction, or an instruction for setting a predetermined value to a variable that determines the value of the condition variable when the extracted call instruction is excluded, from instructions preceding the extracted call instruction, and when the non-variable setting instruction is found, generating first stub data for the multiple call instructions, which is data that associates information indicating a position of the call instruction with the condition variable; a second stub data generation process for generating second stub data for a plurality of call instructions by determining a value of a condition variable of the first stub data based on a condition content related to the condition variable and adding the determined value to the first stub data as a return value of the called unit; a control device that executes a third stub data generation process for generating, for the plurality of call instructions, third stub data, which is data that associates information indicating the identified execution path with the second stub data, by analyzing each instruction of the call section and executes a conditional branch instruction that executes a call instruction related to the second stub data and executes processing of a predetermined branch destination based on a value of a condition clause variable related to the second stub data, and Program verification support system.

2. the control device determines, in the second stub data generation process, a value of a condition clause variable of the first stub data by identifying a value of a variable that determines each branch destination of a conditional branch instruction related to the condition clause variable; 2. The program verification support system according to claim 1.

3. In the third stub data generation process, the control device identifies, from the call unit, an execution path including a call instruction, a conditional branch instruction following the call instruction, and a branch destination process according to a value of a condition variable in the conditional branch instruction, identifies second stub data including the call instruction corresponding to the identified execution path, the condition variable in the conditional branch instruction, and the value of the condition variable, and generates third stub data in which the identified second stub data is associated with information indicating the identified execution path.

2. The program verification support system according to claim 1.

4. the storage device stores source code including in the calling portion a first calling instruction for calling a called portion capable of setting or changing all variables of the source code, and a second calling instruction for calling a called portion capable of setting or changing only variables designated as arguments; The control device includes: In the statement extraction process, a first segmented area having the first call instruction as a starting position and a second segmented area having the second call instruction subsequent to the first call instruction as a starting position are identified from a call portion of the source code, a conditional branch instruction in the first segmented area is extracted in association with the first call instruction that exists before the conditional branch instruction, and a conditional branch instruction in the second segmented area is extracted in association with the second call instruction that exists before the conditional branch instruction, in the first stub data generation process, a non-variable setting instruction which is an instruction for setting a predetermined value to each variable of a condition clause variable related to a conditional branch instruction in the first section area, or an instruction for setting a predetermined value to a variable which determines the value of each variable of the condition clause variable when the extracted first call instruction is excluded, is searched for among instructions in the first section area prior to the extracted first call instruction, and if the non-variable setting instruction is found, first stub data is generated in which information indicating the position of the call instruction and the condition clause variable are associated with each other; in the first stub data generation process, a non-variable setting instruction is searched for from instructions in the second segment area prior to the extracted second call instruction, the non-variable setting instruction being an instruction for setting a predetermined value to a variable related to the extracted second call instruction among condition clause variables related to conditional branch instructions in the second segment area, or an instruction for setting a predetermined value to a variable that determines the value of the variable related to the extracted second call instruction among the condition clause variables when the extracted second call instruction is excluded, and if the non-variable setting instruction is found, first stub data is generated in which information indicating the position of the call instruction and the condition clause variable are associated with each other; In the second stub data generation process, second stub data is generated for each of the first call instruction and the second call instruction based on first stub data for the first call instruction and the second call instruction; In the third stub data generation process, an execution path of the first segmented area is identified by analyzing each instruction of the first segmented area, the execution path of the first segmented area being a conditional branch instruction that executes the first call instruction and executes processing of a predetermined branch destination based on a value of a condition variable related to second stub data for the first call instruction, and third stub data is generated in which information indicating the identified execution path corresponds to the second stub data for the first call instruction; In the third stub data generation process, an execution path of the second segment area is identified by analyzing each instruction of the second segment area, the execution path of the second segment area being a conditional branch instruction that executes the second call instruction and executes processing of a predetermined branch destination based on a value of a condition variable related to the second stub data for the second call instruction, and third stub data is generated in which information indicating the identified execution path corresponds to the second stub data for the second call instruction.

2. The program verification support system according to claim 1.

5. A program verification support method using an information processing device including a control device and a storage device that stores source code including a calling section including a plurality of call instructions and a called section that is called by each of the plurality of call instructions, the control device comprising: a statement extraction process for extracting, from a call portion of the source code, a conditional branch instruction and a call instruction existing before the conditional branch instruction in association with each other; a first stub data generation process for searching for a non-variable setting instruction, which is an instruction for setting a predetermined value to a condition variable that is a variable that determines a conditional branch by the conditional branch instruction, or an instruction for setting a predetermined value to a variable that determines the value of the condition variable when the extracted call instruction is excluded, from instructions preceding the extracted call instruction, and when the non-variable setting instruction is found, generating first stub data for the multiple call instructions, which is data that associates information indicating a position of the call instruction with the condition variable; a second stub data generation process for generating second stub data for a plurality of call instructions by determining a value of a condition variable of the first stub data based on a condition content related to the condition variable and adding the determined value to the first stub data as a return value of the called unit; a third stub data generation process for generating, for the plurality of call instructions, third stub data, which is data that associates information indicating the identified execution path with the second stub data, and a conditional branch instruction that executes a process of a predetermined branch destination based on a value of a conditional variable associated with the second stub data, by analyzing each instruction of the call section; A method for supporting program verification.

6. the control device determines, in the second stub data generation process, a value of a condition clause variable of the first stub data by identifying a value of a variable that determines each branch destination of a conditional branch instruction related to the condition clause variable; 6. The program verification support method according to claim 5.

7. In the third stub data generation process, the control device identifies, from the call unit, an execution path including a call instruction, a conditional branch instruction following the call instruction, and a branch destination process according to a value of a condition variable in the conditional branch instruction, identifies second stub data including the call instruction corresponding to the identified execution path, the condition variable in the conditional branch instruction, and the value of the condition variable, and generates third stub data in which the identified second stub data is associated with information indicating the identified execution path.

6. The program verification support method according to claim 5.

8. the storage device stores source code including in the calling portion a first calling instruction for calling a called portion capable of setting or changing all variables of the source code, and a second calling instruction for calling a called portion capable of setting or changing only variables designated as arguments; The control device includes: In the statement extraction process, a first segmented area having the first call instruction as a starting position and a second segmented area having the second call instruction subsequent to the first call instruction as a starting position are identified from a call portion of the source code, a conditional branch instruction in the first segmented area is extracted in association with the first call instruction that exists before the conditional branch instruction, and a conditional branch instruction in the second segmented area is extracted in association with the second call instruction that exists before the conditional branch instruction, in the first stub data generation process, a non-variable setting instruction which is an instruction for setting a predetermined value to each variable of a condition clause variable related to a conditional branch instruction in the first section area, or an instruction for setting a predetermined value to a variable which determines the value of each variable of the condition clause variable when the extracted first call instruction is excluded, is searched for among instructions in the first section area prior to the extracted first call instruction, and if the non-variable setting instruction is found, first stub data is generated in which information indicating the position of the call instruction and the condition clause variable are associated with each other; in the first stub data generation process, a non-variable setting instruction is searched for from instructions in the second segment area prior to the extracted second call instruction, the non-variable setting instruction being an instruction for setting a predetermined value to a variable related to the extracted second call instruction among condition clause variables related to conditional branch instructions in the second segment area, or an instruction for setting a predetermined value to a variable that determines the value of the variable related to the extracted second call instruction among the condition clause variables when the extracted second call instruction is excluded, and if the non-variable setting instruction is found, first stub data is generated in which information indicating the position of the call instruction and the condition clause variable are associated with each other; In the second stub data generation process, second stub data is generated for each of the first call instruction and the second call instruction based on first stub data for the first call instruction and the second call instruction; In the third stub data generation process, an execution path of the first segmented area is identified by analyzing each instruction of the first segmented area, the execution path of the first segmented area being a conditional branch instruction that executes the first call instruction and executes processing of a predetermined branch destination based on a value of a condition variable related to second stub data for the first call instruction, and third stub data is generated in which information indicating the identified execution path corresponds to the second stub data for the first call instruction; In the third stub data generation process, an execution path of the second segment area is identified by analyzing each instruction of the second segment area, the execution path of the second segment area being a conditional branch instruction that executes the second call instruction and executes processing of a predetermined branch destination based on a value of a condition variable related to the second stub data for the second call instruction, and third stub data is generated in which information indicating the identified execution path corresponds to the second stub data for the second call instruction.

6. The program verification support method according to claim 5.

Images