JP2016173756A - Test case generation program, test case generation method, and test case generation device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the number of extractions of test cases.SOLUTION: A program conversion unit 16 of a test case generation device 10 converts an object program including check processing for determining whether input data satisfies prescribed conditions into an object program excluding the check processing. A check condition controller 17 controls an addition of prescribed check conditions into pass conditions following a prescribed instruction when a symbolic execution is conducted on the object program which has been converted to the program excluding the check processing. A symbolic execution controller 19 conducts the symbolic execution and outputs results of the execution to the symbolic execution output unit 20. A test case output unit 21 stores pass and pass conditions that were outputted from the symbolic execution output unit as a test case in a test case DB12.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a test case generation program, a test case generation method, and a test case generation apparatus.

  Conventionally, in software development, symbolic execution is known as a technique for generating a test case for a program to be developed. Symbolic execution is a technique for analyzing a program by setting a symbol value such as a symbol value in an input variable and emulating the execution of the program.

  For example, when a COBOL program including an IF statement is symbolically executed, executable paths and path conditions for each path are extracted. Here, the path is a sequence of executed statements, and the path condition is a conditional expression related to an indefinite variable value among the conditions that are passed until the path ends. That is, a path that passes the test target corresponds to the test case, and the value of the program variable that satisfies the path condition becomes the test data of the test case.

  In general, in a program, various processes are described for external variables and local variables as inputs, and a desired function is executed by executing the processes. Such a program includes pre-processing (hereinafter may be described as check processing) and main processing (hereinafter may be described as main processing). The preprocess is an input check process for determining that an input satisfies a desired condition, and the main process is a main process describing a process for realizing a desired function.

  When symbolic execution is performed on a program including preprocessing and main processing, a path branch occurs at a conditional branch in each processing, so test the test case and main processing for testing the preprocessing. Test cases for are generated.

JP 2000-339192 A JP 2007-41804 A JP 2013-143067 A

  However, the above technique generates more test cases for input check processing than necessary.

  In general, the check process is a standard process commonly used in many programs, so the importance of the test for the check process itself is lower than the test for the main process. For this reason, it is considered that the number of test cases for the check process is smaller than that for the main process. However, the symbolic execution cannot distinguish between the check process in the program and the main process, and therefore cannot generate the test case for the check process and the main process separately.

  It is also possible to reduce the number of test cases by excluding duplicate test cases from the entire test cases generated by symbolic execution. However, since the number of test cases generated by symbolic execution does not change, the test case extraction time increases. It is also possible to comment out the check process and make only the main process an analysis target for symbolic execution, but the check process as a premise of the main process is ignored. For this reason, test cases in which the main process is not executed are excluded, and the generated test data is insufficient.

  It is also conceivable to comment out the check process and specify the input check path condition as a symbolic execution precondition. However, in a program that has a main process before the input check, if the pass condition of the input check is a precondition of the program, the logic of the program will change and it will not be possible to generate test cases and test data properly. .

  An object of one aspect is to provide a test case generation program, a test case generation method, and a test case generation apparatus that can reduce the number of extracted test cases.

  The test case generation program causes a computer to execute a process of converting a target program including a check process for determining that input data satisfies a predetermined condition into a target program excluding the check process. When the symbolic execution is performed on the converted target program, the test case generation program causes the computer to execute a process of controlling to add a predetermined check condition to the path condition in a predetermined instruction.

  According to one embodiment, the number of test case extractions can be reduced.

FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to the first embodiment. FIG. 2 is a functional block diagram illustrating a functional configuration of the test case generation device according to the first embodiment. FIG. 3 is a diagram illustrating an example of information stored in the input information DB. FIG. 4 is a diagram illustrating another example of information stored in the input information DB. FIG. 5 is a diagram illustrating an example of check specification analysis. FIG. 6 is a diagram illustrating an example of check condition generation. FIG. 7 is a diagram for explaining an example of program conversion. FIG. 8 is a diagram for explaining path output upon failure. FIG. 9 is a diagram for explaining path output upon success. FIG. 10 is a diagram for explaining the test case output. FIG. 11 is a flowchart for explaining the overall processing flow. FIG. 12 is a flowchart for explaining the flow of processing of check specification analysis and check condition generation. FIG. 13 is a flowchart for explaining the flow of the program conversion process. FIG. 14 is a flowchart for explaining the flow of the check condition adding process. FIG. 15 is a flowchart for explaining the flow of the test case output process. FIG. 16 is a diagram illustrating an example when there are a plurality of check conditions. FIG. 17 is a diagram illustrating a hardware configuration example.

  Hereinafter, embodiments of a test case generation program, a test case generation method, and a test case generation device disclosed in the present application will be described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

[overall structure]
FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to the first embodiment. As illustrated in FIG. 1, the test case generation device 10 is an example of a server or a personal computer that generates a test case by executing symbolic execution.

  The test case generation apparatus 10 receives a test case generation target program, a check specification that is a specification of a check process for determining whether input data satisfies a predetermined condition in the program, and check partial information indicating a corresponding part of the check process. And the test case production | generation apparatus 10 produces | generates a test case using such input information. In the present embodiment, the COBOL program will be described as an example. However, the present invention is not limited to this, and other programs such as C language can be similarly executed.

  Specifically, the test case generation device 10 converts a target program including a check process for determining that input data satisfies a predetermined condition into a target program excluding the check process. Then, the test case generation apparatus 10 controls to add a predetermined check condition to the path condition in a predetermined instruction when symbolic execution is performed on the converted target program.

  That is, the test case generation apparatus 10 converts the program into a success type and a failure type from which the conditional branch of the input check is excluded, and executes symbolically while adding the input check success condition and the failure condition to the path condition. As a result, the test case generation device 10 can reduce the number of test cases obtained as an execution result.

[Function configuration]
FIG. 2 is a functional block diagram illustrating a functional configuration of the test case generation device according to the first embodiment. As illustrated in FIG. 2, the test case generation apparatus 10 includes an input information DB 11, a test case DB 12, an input unit 13, a check specification analysis unit 14, a check condition generation unit 15, a program conversion unit 16, and a check condition control unit 17. . In addition, the test case generation apparatus 10 includes a symbolic execution input unit 18, a symbolic execution control unit 19, a symbolic execution output unit 20, and a test case output unit 21.

  The input information DB 11 and the test case DB 12 are databases stored in a storage device such as a memory or a hard disk. Input unit 13, check specification analysis unit 14, check condition generation unit 15, program conversion unit 16, check condition control unit 17, symbolic execution input unit 18, symbolic execution control unit 19, symbolic execution output unit 20, test case output unit 21 Is an example of an electronic circuit included in the processor and an example of a process executed by the processor. In addition, the input unit 13, the check specification analysis unit 14, the check condition generation unit 15, the program conversion unit 16, and the check condition control unit 17 are processing units that perform preprocessing before performing symbolic execution.

  The input information DB 11 is a database that stores a test case generation target program, check specifications, and check partial information. The information stored here may be stored, for example, by an administrator or the like, or information generated by a CASE (Computer Aided Software Engineering) tool or the like may be stored. The CASE tool has a function of automatically generating a software product such as a program from design information. Further, the input information DB 11 can store one piece of the above information and can also store each piece of information.

  FIG. 3 is a diagram illustrating an example of information stored in the input information DB. The example of FIG. 3 is an example in which each piece of information is described together in a test case generation target program. The program shown in FIG. 3 is a program in which two IF statements are described and includes a check process and a main process.

  The check process is an input check section from the 39th line to the 45th line, and it is checked that the three input characters are uppercase letters, that is, between ‘A’ and ‘Z’. On the other hand, the main process is a main process SECTION from the 23rd line to the 28th line, and it is determined whether or not the input of the three uppercase letters that have passed the check process is equal to ‘ABC’, and the result is output. In the execution path, first, the check process is called at the 15th line, and then the success or failure of the check is determined by the IF statement at the 16th line. When the check is successful, the main process is called at the 17th line.

  Further, in the program shown in FIG. 3, a check specification and a mark indicating a check processing part are described using comments. Specifically, the 15th to 18th lines are check specification information, and the 19th to 21st lines are check processing portions. In the check specification information, “check type” that describes what type of check is to be performed, “check condition” that describes the specific check condition of the check type, and “check target” that allows the variable to be checked to be identified In addition, a “check failure operation” describing the processing contents to be executed in the case of a check failure is described. Further, “$ CHECKSTART” on the 19th line means the start of the check process, and “$ CHECKEND” on the 21st line means the end of the check process.

  The input information DB 11 can also store each information separately. FIG. 4 is a diagram illustrating another example of information stored in the input information DB. The example of FIG. 4 is an example in which a test case generation target program, a check specification, and a check processing part are stored separately.

  4A is a test case generation target program, and FIG. 4B is an example of a table describing check specifications and check processing portions. 3 and 4 show the same contents. Specifically, “start line” − “end line” shown in FIG. 4B corresponds to the 20th line in the input check process in FIG. Also, “CHECK” shown in FIG. 4B corresponds to the 15th line in FIG. 3, “ITEM” corresponds to the 16th line in FIG. 3, and “COND” corresponds to the 17th line in FIG. “ERROR” corresponds to the 18th line in FIG.

  The test case DB 12 is a database that stores test cases generated by symbolic execution. The information stored here stores each path condition that passes through the branch of the input check. Moreover, since the information memorize | stored here is memorize | stored in the test case output part 21 mentioned later, the detail is mentioned later.

  The input unit 13 is a processing unit that acquires information on a test case generation target program, a check specification, and a check processing part in the preprocessing. Specifically, when the input unit 13 receives a symbolic execution start instruction by, for example, input from a keyboard, the input unit 13 reads information stored in the input information DB 11 and outputs the information to the check specification analysis unit 14 and the program conversion unit 16. .

  The check specification analysis unit 14 is a processing unit that analyzes the check specification information and acquires the contents of the check specification. Specifically, the check specification analysis unit 14 extracts the check type, the check condition, the check target, and the check failure operation from the check specification information and the program input from the input unit 13.

  FIG. 5 is a diagram illustrating an example of check specification analysis. As illustrated in FIG. 5, the check specification analysis unit 14 specifies that the check type is the character type check from the description of “$ CHECKTYPE character type” on the 15th line. The check specification analysis unit 14 specifies that the variable to be checked is the “input OF argument” from the description of “$ ITEM input OF argument” on the 16th line of the target program. From the description of “$ COND uppercase letters” on the 17th line, the check specification analysis unit 14 specifies that the check condition is “uppercase letters”. The check specification analysis unit 14 specifies that the numerical value 1 is assigned to the variable “check result” when the check fails from the description of “$ ERROR check result = 1” on the 18th line. Further, the check specification analysis unit 14 specifies that the input is given from the outside and is a three-digit character string (X (3)) from the descriptions of the fifth and sixth lines.

  Then, as shown in FIG. 5, the check specification analysis unit 14 generates information having “line number, item, type, check type (character type, minimum value, maximum value, enumerated value), error”. Specifically, the check specification analysis unit 14 sets “15” to “line number” since the start of the check specification information is the 15th line. In addition, since the input of the argument is described in the ITEM, the check specification analysis unit 14 sets “input” in the “item”, and “X (3)” is described as the input in the sixth line. Therefore, “X (3)” is set in “Type”.

  Furthermore, since the uppercase alphabetic characters are described in COND, the check specification analysis unit 14 sets “uppercase alphabetic characters” to “check type (character type)”. Other check types are left blank because they are not described in the program check process. Further, since it is described that the numerical value 1 is assigned to the variable “check result”, the check specification analysis unit 14 sets “check result = 1” to “error”. Thereafter, the check specification analysis unit 14 outputs the generated analysis result to the check condition generation unit 15.

  The check condition generation unit 15 is a processing unit that generates a success condition in which the check process is successful and a failure condition in which the check process fails based on the program and the specification of the check process. Specifically, when the analysis result is input from the check specification analysis unit 14, the check condition generation unit 15 determines whether the “type” succeeds or fails from the “type” and “check type” of the analysis result. Is generated.

  FIG. 6 is a diagram illustrating an example of check condition generation. In the example of FIG. 6, the check condition generation unit 15 includes the input three characters because the “type” of the analysis result is “X (3)” and the check type is the character type “English capital letter”. A condition in which the character string is all capital letters is a success condition, and a condition in which any of the inputted three character strings is not a capital letter is a failure condition. That is, the check condition generation unit 15 sets a condition that the input character string is all capital letters as a success condition and a condition that the input character string is not capital letters as a failure condition.

  Specifically, as shown in FIG. 6, the check condition generation unit 15 generates information having “No, line number, success / failure, check condition” and outputs the information to the program conversion unit 16 and the check condition control unit 17. To do.

  Here, “No.” indicates the No. of the input check specification. No. associated with Is set. In the “line number”, the line number of the input check specification is set. “Success / failure” is set to “success” if it is a success condition, and “failure” if it is a failure condition. In the “check condition”, a success condition or a failure condition is set.

  In the example of FIG. 6, the check condition generation unit 15 sets “('A' <= input (1: 1) AND input (1: 1) <= 'Z') AND (' A '<= input (2: 1) AND input (2: 1) <=' Z ') AND (' A '<= input (3: 1) AND input (3: 1) <=' Z ') " Is generated. Further, the check condition generation unit 15 generates a NOT success condition as a failure condition that satisfies the above conditions. That is, the check condition generation unit 15 generates “NOT (('A' <= input (1: 1) AND input (1: 1) <= 'Z') AND ('A' <= input (2: 1) AND input (2: 1) <= 'Z') AND ('A' <= input (3: 1) AND input (3: 1) <= 'Z')) "is generated.

  The program conversion unit 16 is a processing unit that converts a program including a check process for determining that input data satisfies a predetermined condition into a program excluding the check process. Specifically, the program conversion unit 16 duplicates a success program for which the check process is successful and a failure program for which the check process fails from the target program, and outputs the duplicated program to the check condition control unit 17. .

  FIG. 7 is a diagram for explaining an example of program conversion. As illustrated in FIG. 7, the program conversion unit 16 sets the program read by the input unit 13 to be excluded from the execution of the check process, and adds a command statement for executing the subsequent process after the check process is successful. Convert to a successful program. For example, the program conversion unit 16 rewrites the 15th line, which is the start of the check specification information of the program and is commented out, with the instruction “CONTINUE”. Furthermore, the program conversion unit 16 has a check process start mark on the 19th line and a check process end mark on the 21st line, so the 20th line between them is commented out and excluded from the processing target. In this way, the program conversion unit 16 generates a success program.

  In addition, the program conversion unit 16 converts the program read by the input unit 13 into a failure program in which a check process is set to be excluded from execution targets and an instruction sentence to be executed when the check process fails is added. For example, the program conversion unit 16 rewrites the comment line “15th line”, which is the start of the check specification information of the program, to the statement “MOVE 1 TO check result”. Furthermore, the program conversion unit 16 has a check process start mark on the 19th line and a check process end mark on the 21st line, so the 20th line between them is commented out and excluded from the processing target. In this way, the program conversion unit 16 generates a failure program.

  The check condition control unit 17 is a processing unit that controls to add a predetermined check condition to a path condition in a predetermined instruction when symbolic execution is performed on the converted program. Specifically, the check condition control unit 17 controls to add the success condition to the path condition when the symbolic execution is performed on the success program, and the symbolic execution is performed on the failure program. Control to add a failure condition to the path condition.

  That is, the check condition control unit 17 manages the check conditions corresponding to the converted program, monitors the command sentence executed by symbolic execution, and adds the specified check condition to the path condition using the specified command sentence. The check condition control unit 17 outputs the success program and the failure program input from the program conversion unit 16 to the symbolic execution input unit 18.

  The symbolic execution input unit 18 is a processing unit that receives a success program and a failure program as targets of symbolic execution from the check condition control unit 17 and outputs them to the symbolic execution control unit 19.

  The symbolic execution control unit 19 is a processing unit that sets a symbol value in an external variable of a program, emulates program execution with the symbol value, and executes a path in a simulated manner. Here, the symbolic execution control unit 19 executes symbolic execution for each of the success program and the failure program input from the symbolic execution input unit 18, and outputs the result to the symbolic execution output unit 20.

  The symbolic execution output unit 20 is a processing unit that outputs executable paths and path conditions to the test case output unit 21. The test case output unit 21 is a processing unit that stores the path and path condition output from the symbolic execution output unit 20 as a test case in the test case DB 12. One set of paths and path conditions correspond to one test case.

  Here, an output example of the path condition during symbolic execution will be described with reference to FIGS. 8 and 9. FIG. 8 is a diagram for explaining path output upon failure, and FIG. 9 is a diagram for explaining path output upon success.

  As shown in FIG. 8, the check condition control unit 17 monitors the symbolic execution control unit 19 to emulate the execution of the command statement according to the prescribed execution order, and the monitoring target line number “15” is executed. Then, a check condition for failure corresponding to the line number “15” is extracted.

  Specifically, when the symbolic execution output unit 20 executes symbolic execution of the program for failure under the monitoring of the check condition control unit 17, the instruction sentence “MOVE 1 TO check result” rewritten in the 15th line indicates “ 1 is set in the “check result” item. At the same time, the check condition control unit 17 adds the check failure condition generated by the check condition generation unit 15 to the path condition when executing the command statement on the 15th line.

  Subsequently, when the symbolic execution is performed by the symbolic execution output unit 20, the ELSE is executed with the branch condition of the IF statement on the 23rd line being False, and one path that ends by executing the “check failure” section is extracted. Is done. From this execution path, one test case with failed check is generated.

  In other words, the check condition control unit 17 determines that “NOT (('A' <= input (1: 1) AND input (1: 1) <= 'Z') AND ('A' <= input (2: 1) AND input (2: 1) <= 'Z') AND ('A' <= input (3: 1) AND input (3: 1) <= 'Z')) "is extracted. Here, the symbolic execution output unit 20 is a program in the case where the check process fails, and since there are no more branches, the test case that satisfies the check failure condition is output.

  As shown in FIG. 9, the check condition control unit 17 monitors the symbolic execution control unit 19 to emulate the execution of the command statement in the prescribed execution order, and the line number “15” to be monitored is When executed, a check condition for success corresponding to the line number “15” is extracted.

  Specifically, when the symbolic execution output unit 20 performs symbolic execution of the success program under the monitoring of the check condition control unit 17, the check success condition is added to the path condition by the CONTINUE statement on the 15th line. Next, THEN is executed when the branch condition of the IF statement on the 23rd line is True. Furthermore, since the conditional branch of the IF statement on the 30th line in the main process can be satisfied both true and false, two paths are extracted and two test cases are generated.

  In other words, the check condition control unit 17 reads “('A' <= input (1: 1) AND input (1: 1) <= 'Z') AND ('A' <= input (2: 1) AND input. (2: 1) <= 'Z') AND ('A' <= input (3: 1) AND input (3: 1) <= 'Z') "is extracted. Here, the symbolic execution output unit 20 includes a test case that satisfies “(check success condition) AND (30th line IF statement condition is True)” and “(check success condition) AND ( A test case that satisfies “Not (true) in IF statement condition on line 30” is output.

  Next, the output of the test case will be described with reference to FIG. FIG. 10 is a diagram for explaining the test case output. As illustrated in FIG. 10, the test case output unit 21 receives one check condition described in the input 1 from the symbolic execution output unit 20 when performing symbolic execution on a program for failure. In addition, the test case output unit 21 receives two check conditions described in the input 2 from the symbolic execution output unit 20 when performing symbolic execution on a success program. Then, the test case output unit 21 merges these check conditions and stores them in the test case DB 12.

[Process flow]
Next, processing executed by each processing unit described above will be described. Since symbolic execution is the same processing as general symbolic execution, detailed description is omitted.

(Overall processing flow)
FIG. 11 is a flowchart for explaining the overall processing flow. As shown in FIG. 11, the test case generation device 10 reads the correspondence between the input check specification and the program part from the input information DB 11 (S101).

  Subsequently, the test case generation apparatus 10 generates pass conditions for success and failure of the input check (check process) from the check specification information associated with the program (S102). Then, the test case generation apparatus 10 converts the program into a success check for input check and a failure check using the check processing part mark (comment) associated with the program (S103).

  Subsequently, the test case generation device 10 performs symbolic execution for each of the success program and the failure program, and adds a path condition for input check when a specific command statement is reached (S104). Thereafter, the test case generation apparatus 10 aggregates the test cases for success and failure and sets them as test cases for the test target program (S105).

(Check specification analysis, check condition generation)
FIG. 12 is a flowchart for explaining the flow of processing of check specification analysis and check condition generation. As illustrated in FIG. 12, the check specification analysis unit 14 acquires a program or the like in which the check specification is described (S201). The input is a program in which the check specification is described in a comment, a file in which the check specification is described in a table format, or the like.

  Subsequently, the check specification analysis unit 14 extracts check specification information from the check specification (S202), and outputs the extracted check specification information to the check condition generation unit 15 (S203). For example, the check specification analysis unit 14 extracts the line number of the check process, the target item, the item type, the check type, the check condition, and the operation information at the time of error.

  Thereafter, the check condition generation unit 15 acquires check specification information from the check specification analysis unit 14 (S204). Subsequently, the check condition generation unit 15 generates a success and failure check condition according to the check type based on the check specification information (S205), and the program conversion unit displays the generated success check condition and failure check condition. 16 and the check condition control unit 17 (S206).

(Program conversion)
FIG. 13 is a flowchart for explaining the flow of the program conversion process. As shown in FIG. 13, the program conversion unit 16 acquires a program and check specification information from the input unit 13 or the like (S301), and determines whether or not there is an unprocessed check process in the program (S302).

  When there is an unprocessed check process (S302: Yes), the program conversion unit 16 selects one unprocessed check process and duplicates the program (S303). Subsequently, the program conversion unit 16 rewrites the line number of the check process into a statement of the check failure based on the error (failure) information (S304).

  Then, the program conversion unit 16 rewrites the line number of the check process other than the check process to the command statement “CONTINUE” indicating the success of the check (S305), and comments out (excludes) the program part of all the check processes (S306). ). Thereafter, the program conversion unit 16 records the converted program in a memory or the like in association with the failure of the check process (S307).

  On the other hand, when there is no unprocessed check process (S302: No), the program conversion unit 16 duplicates the program (S308). Subsequently, the program conversion unit 16 rewrites all check processing line numbers to a command statement “CONTINUE” indicating a successful check (S309).

  Thereafter, the program conversion unit 16 records the converted program in a memory or the like in association with the success of all the check processes (S310).

(Check condition added)
FIG. 14 is a flowchart for explaining the flow of the check condition adding process. As shown in FIG. 14, the check condition control unit 17 acquires the converted program and the check condition (S401), and determines whether there is an unprocessed check process in the program (S402).

  Subsequently, when there is an unprocessed check process (S402: Yes), the check condition control unit 17 acquires a check condition corresponding to the unprocessed program, and starts an analysis of symbolic execution for the program (see FIG. S403). Here, the symbolic execution control unit 19 starts symbolic execution of the program.

  Then, if the symbolic execution control unit 19 is not an instruction sentence for ending the program (S404: No), it emulates the processing of the instruction sentence (S405). Subsequently, when the check condition control unit 17 is the command statement of the line number of the check condition (S406: Yes), the check condition control unit 17 adds the specified check condition to the path condition by the command statement of the line number of the check condition (S407).

  Thereafter, the symbolic execution control unit 19 acquires the next command statement (S408), and repeats S404 and subsequent steps. On the other hand, when it is not the command statement of the line number of the check condition (S406: No), S408 is executed without executing S407.

  In S404, the symbolic execution output unit 20 records a test case when the instruction is a program end command (S404: Yes) (S409). In S402, if there is no unprocessed check process (S402: No), the symbolic execution output unit 20 outputs the generated test case in association with the program (S410).

(Test case output)
FIG. 15 is a flowchart for explaining the flow of the test case output process. As illustrated in FIG. 15, the test case output unit 21 acquires a test case list (pass condition) for each post-conversion program from the symbolic execution output unit 20 (S501).

  Subsequently, when there is an unprocessed test case list (S502: Yes), the test case output unit 21 sequentially extracts path conditions from the selected test case list (S503). Then, when there is an unprocessed path condition (S504: Yes), the test case output unit 21 determines whether or not the path condition of the total test case matches (S505).

  Thereafter, when the test condition output unit 21 does not match the pass condition of the total test case (S505: Yes), the test case output unit 21 adds the test case of the pass condition to the total test case (S506), and repeats S504 and subsequent steps. Further, when the test case output unit 21 matches the pass condition of the total test case (S505: No), S504 and the subsequent steps are repeated without executing S506.

  On the other hand, in S504, when there is no unprocessed path condition (S504: No), the test case output unit 21 repeats S502 and subsequent steps. In S502, when there is no unprocessed test case list (S502: No), the test case output unit 21 outputs the total test case to the test case DB 12 (S507).

  The part of the flow that determines whether or not the path conditions of the total test cases do not match is a process of totaling so that the path conditions are the same, that is, the same test cases are not duplicated. The test case generation apparatus 10 extracts a test case by executing a plurality of converted programs symbolically under the control of the check condition control unit 17. Here, before a check process (input check process), when a program in which another process other than the input check exists is input and a conditional branch exists in another process, the program is input to the test case output unit 21. Since duplication occurs in the test condition path conditions, duplication is eliminated by this processing.

[effect]
According to the first embodiment, the test case generation apparatus 10 excludes the input check process without changing the logic content of the entire program for the program including the input check process and the main process, and passes the path in the symbolic execution. An input check pass condition can be added with an appropriate statement at the time of tracking. Further, the test case generation apparatus 10 can generate a test case by excluding test cases that excessively test the input check. As a result, the test case generation apparatus 10 can reduce the number of test cases and further reduce the test case generation time.

[Multiple check conditions]
The test case generation device 10 can perform the same processing even when there are a plurality of check conditions. FIG. 16 is a diagram illustrating an example when there are a plurality of check conditions. The upper diagram of FIG. 16 illustrates information on general check conditions.

  As shown in FIG. 16, when the check type is “character type”, the check condition includes alphabetic characters, alphanumeric characters, numbers, and the like. When the check type is “value range”, the check conditions include a minimum value and a maximum value of a numerical value, a range of a specified character set, and the like. When the check type is “enumerated value”, the check condition includes, for example, designation of an enumerated value that specifically enumerates a plurality of numerical values such as “1, 10, 20”. When the check type is “digit range”, the check condition includes the minimum number of digits and the maximum number of digits of the character string.

  Then, the input unit 13 reads check specification information in a table format, for example. In the example of FIG. 16, No = 1 is the check specification information from the 100th line to the 110th line of the program, the check type is the value range, the check target is item 1, and the check condition is the minimum value “0 <=”. In this example, only (0 or more) is specified. For No = 2, the 200th to 220th lines of the program are the check specification information, the check type is the value range, the check target is item 2, and the check condition is the minimum value “0 <=” (0 or more) and the maximum In this example, both values “<100” (less than 100) are specified. In No = 3, the 300th to 330th lines of the program are check specification information, the check type is an enumerated value, the check target is item 3, and the check condition is an enumerated value {'A', 'B', 'C '} Is an example included. In both cases, the error processing is “check result = 1” in which 1 is assigned to the check result.

  Subsequently, the check specification analysis unit 14 analyzes the check specification information and extracts a check type, a check condition, a check target, and a check failure operation. For No = 1, line number = 100, item = item 1, type = 9 (3), the minimum value is 0 or more as the check type, and “check result = 1” is extracted as error processing. For No = 2, line number = 200, item = item 2, type = 9 (3), the minimum value is 0 or more and the maximum value is less than 100 as the check type, and “check result = 1” is extracted as error processing. The For No = 3, line number = 300, item = item 3, type = X (2), check type (enumerated value) = “A, B, C”, “check result = 1” is extracted as error processing The Type = 9 (3) means a three-digit number.

  Then, the check condition generation unit 15 generates a success condition and a failure condition. The failure condition is a NOT success condition. In the above example, the check condition generation unit 15 generates a success condition and a failure condition for each extracted line number for the target program, and thus generates a total of six conditions.

  As an example, for row number 100, “0 <= item 1” is generated as a success condition, and “NOT (0 <= item 1)” is generated as a failure condition. For the line number 200, “(0 <= item 2) AND (item 2 <100)” is generated as a success condition, and “NOT ((0 <= item 2) AND (item 2 <100) is set as a failure condition. )) "Is generated.

  Thereafter, the program conversion unit 16 generates a program that satisfies the conditions for each condition. For example, the program conversion unit 16 is No. 1-1, a program that satisfies the success condition 1-1. A program that satisfies the failure condition 1-2, No. A program or the like that satisfies the success condition of 2-1 is generated.

  Then, the check condition control unit 17 monitors the instruction when the generated program is symbolically executed, and when the instruction of the corresponding line number is executed, the corresponding check condition is set as a path condition. Extract. For example, in the success program of item 1, the check condition control unit 17 extracts “0 <= item 1” when the 100th line is executed. As described above, the test case generation apparatus 10 monitors check statements executed by symbolic execution by managing check conditions corresponding to each converted program even when there are multiple check processing check conditions and the branch is complicated. Thus, a specified check condition can be added to the path condition with a specified command statement.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above.

[Generator and Executor]
In the above embodiment, the test case generation apparatus 10 has been described as having both the processing unit that generates the test case and the processing unit that executes symbolic execution. However, the present invention is not limited to this. For example, the input unit 13, the check specification analysis unit 14, the check condition generation unit 15, the program conversion unit 16, the check condition control unit 17, and the test case output unit 21 are generated, a symbolic execution input unit 18, and a symbolic execution control unit 19. It can also be divided into a symbolic execution device having a symbolic execution output unit 20.

[system]
Further, each configuration of the illustrated apparatus does not necessarily need to be physically configured as illustrated. That is, it can be configured to be distributed or integrated in arbitrary units. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

  In addition, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

  Note that the test case generation apparatus 10 described in the present embodiment can execute the same function as the process described in FIG. 2 and the like by reading and executing the test case generation program. For example, the test case generation apparatus 10 includes an input unit 13, a check specification analysis unit 14, a check condition generation unit 15, a program conversion unit 16, a check condition control unit 17, a symbolic execution input unit 18, a symbolic execution control unit 19, and a symbolic execution. A program having functions similar to those of the output unit 20 and the test case output unit 21 is expanded in the memory. The test case generation apparatus 10 includes an input unit 13, a check specification analysis unit 14, a check condition generation unit 15, a program conversion unit 16, a check condition control unit 17, a symbolic execution input unit 18, a symbolic execution control unit 19, and a symbolic execution. By executing a process for executing processing similar to that performed by the output unit 20 and the test case output unit 21, processing similar to that in the above-described embodiment can be performed.

  This program can be distributed via a network such as the Internet. The program can be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD, and being read from the recording medium by the computer.

[Hardware configuration]
The test case generation apparatus 10 can be realized by the following hardware configuration, for example. FIG. 17 is a diagram illustrating a hardware configuration example. As shown in FIG. 17, the test case generation apparatus 10 includes a communication interface 10a, an HDD (Hard Disk Drive) 10b, a memory 10c, and a processor 10d.

  Examples of the processor 10d include a central processing unit (CPU), a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic device (PLD). Examples of the memory 10c include a RAM (Random Access Memory) such as SDRAM (Synchronous Dynamic Random Access Memory), a ROM (Read Only Memory), a flash memory, and the like.

  Various processing functions performed by the test case generation apparatus 10 may be realized by executing a program stored in various memories such as a nonvolatile storage medium by a processor included in the control device. That is, the input unit 13, check specification analysis unit 14, check condition generation unit 15, program conversion unit 16, check condition control unit 17, symbolic execution input unit 18, symbolic execution control unit 19, symbolic execution output unit 20, test case output A program corresponding to each process executed by the unit 21 may be recorded in the memory 10c, and each program may be executed by the processor 10d.

10 Test case generator 11 Input information DB
12 Test case DB
DESCRIPTION OF SYMBOLS 13 Input part 14 Check specification analysis part 15 Check condition production | generation part 16 Program conversion part 17 Check condition control part 18 Symbolic execution input part 19 Symbolic execution control part 20 Symbolic execution output part 21 Test case output part

Claims (6)

On the computer,
Converting a target program including a check process for determining that input data satisfies a predetermined condition into a target program excluding the check process;
A test case generation program that executes a process of controlling a predetermined instruction to add a predetermined check condition to a path condition when symbolic execution is performed on the converted target program. Based on the target program and the specification of the check process, the computer further executes a process for generating a success condition for the check process to succeed and a failure condition for the check process to fail,
The converting process converts the target program into a first target program in which the check process succeeds and a second target program in which the check process fails,
The control process controls to add the success condition to the pass condition when the symbolic execution is performed on the first target program, and the symbolic execution is performed on the second target program. The test case generation program according to claim 1, wherein the failure condition is controlled to be added to the path condition.   The test case generation program according to claim 2, wherein the process of generating the failure condition outputs a negative sentence of the success condition as the failure condition.   The conversion process generates the first target program in which the check process is set to be excluded from the execution target for the target program, and a statement that adds the instruction that the check process succeeds and the subsequent process is executed is added. The test case generation program according to claim 2, wherein the second target program to which an instruction to be executed when the check process fails is added. Computer
Converting a target program including a check process for determining that input data satisfies a predetermined condition into a target program excluding the check process;
A test case generation method, comprising: a process of controlling a predetermined instruction to add a predetermined check condition to a path condition when symbolic execution is performed on the converted target program. A conversion unit that converts a target program including a check process for determining that the input data satisfies a predetermined condition into a target program excluding the check process;
A test case comprising: an additional control unit that controls to add a predetermined check condition to a path condition in a predetermined instruction when symbolic execution is performed on the target program converted by the conversion unit Generator.

Images