JP2014021686A - Test data generation device, program and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the costs of a test posterior to program correction by using test resources prior to program correction.SOLUTION: A test data generation device acquires first test data to be used for the test of a pre-correction program and path condition information showing path conditions expressing an execution path shown by the combination of processing paths to be branched and made to pass under conditions included in the source code of a post-correction program by a logical formula, and stores the acquired first test data in a test data storage section, and stores the acquired path condition information in a path condition storage section, and extracts the path condition information which is not logically the same value as the first test data stored in the test data storage section from the path condition information stored in the path condition storage section, and generates second test data satisfying the path conditions shown by the extracted path condition information.

Description

  The present technology relates to a technology for generating test data for testing the operation of a program.

  A test is performed to verify that the business system is designed as specified. Such tests include various checks, such as checks related to business specifications (relationships and changes between items that have meaning as business), and rules of thumb that program errors such as boundary value tests are likely to occur at data boundaries. It is done from the viewpoint. Therefore, a plurality of test data is prepared for one business specification according to the check contents.

  As a technology for automatically generating test data from business specifications, it solves the satisfiability determination problem of constraint expressions (logical expressions using screens, database (DB) items and program variables) that express the situation to be tested. Therefore, there is a technique that uses the sufficiency value as test data. One technique for creating test data for testing such a program is symbolic execution. Symbolic execution refers to a mechanism in which a variable is not specified as a specific value but executed without specifying a single symbol value. In symbolic execution, test data that will flow through a certain series of transitions can be created for each of the series of transitions that the program can take.

  By the way, when an existing program is modified, the program is tested. In the test, data (input data) to be given to the processing to be tested and values (output data) obtained by processing by the program when the data is given are prepared. Then, when the input data is given to the test target process, the program performs the process according to the specification by comparing the value obtained by the process with the prepared output data. Determine if it is running.

  Also, when testing the program, change the value of the variable used in the process from the start to the end of the program and execute the test one or more times so that the test can cover all processing flows There are things to do.

  In such software development, for example, the following software test support technology is available in order to efficiently perform an operation test of the installed program.

  As a first technique, state transition information is extracted from the analysis result of the source code based on the input state variable, and the difference between the two is compared with the state transition information based on the design information provided by the test scenario. There is technology to detect.

  The second technique includes the following technique. A design model described only by a UML class diagram and an activity diagram is read from the user terminal, an activity diagram is extracted from the design model as a test target, and an execution path is extracted from the test target. The test data specification is updated based on the extracted constraint condition of each execution path. The test data specification is read, a “level” is generated for each factor, and an execution path for “input” which is a combination of the factor and the level is acquired. Expected depending on whether "input" is a normal input that is allowed for the execution path or an abnormal input that is not allowed for the execution path, and whether or not a post-condition is included in the execution path A value is obtained, and test data in which the expected value is assigned to “input” is generated.

  As a third technique, there is a regression system in which information about test cases of tests performed in the past is stored, and the test is performed by combining the information and the dependency obtained by analyzing the target program. .

JP 2005-316710 A JP 2010-267023 A JP 2008-204405 A

  When the modified program is comprehensively tested by symbolic execution, new symbolic execution is performed on the program, and the test data corresponding to the obtained test case is tested.

At this time, when the test data is given in the test case, the value (output value) that should be obtained based on the above-mentioned specifications is obtained by manual calculation, and therefore it takes time.
However, some of the obtained test cases are not affected by modification, and it is wasteful to generate test data and output values corresponding to such test cases again.

  Therefore, a technique is provided for reducing the cost of testing after program modification by using test assets before program modification.

  A test data generation device according to one aspect of the present embodiment includes an input information acquisition unit, a test data storage unit, a path condition storage unit, an extraction unit, and a generation unit. The input information acquisition unit acquires first test data and route condition information. The first test data is used for testing the program before correction. The route condition information indicates a route condition in which an execution route indicated by a combination of processing routes branched and passed by the condition included in the source code of the program after correction is expressed by a logical expression. The test data storage unit stores the acquired first test data. The route condition information storage unit stores the acquired route condition information. The extraction unit extracts route condition information that is not logically equivalent to the first test data stored in the test data storage unit from the route condition information stored in the route condition storage unit. The generation unit generates second test data that satisfies the route condition indicated by the extracted route condition information.

  According to one aspect of the present embodiment, it is possible to reduce the cost of testing after program correction by using test assets before program correction.

It is an example of source code. It is a figure for demonstrating the test case production | generation by symbolic execution. It is FIG. (1) for demonstrating the retest accompanying correction of a program. It is FIG. (2) for demonstrating the retest accompanying correction of a program. It is a figure for demonstrating matching of the path condition before and behind correction. 1 shows an example of a test data generation apparatus according to the present embodiment. 1 shows an example of a configuration of a test data generation apparatus according to the present embodiment (Example 1). It is a figure for demonstrating the input data in this embodiment (Example 1). An example of the test data condition table in this embodiment (Example 1) is shown. An example of the path condition table in this embodiment (Example 1) is shown. It is a figure for demonstrating the process of the matching part in this embodiment (Example 1). An example in which the data item “match flag” is added to the path condition table of FIG. 10 is shown. 13 shows an example of path condition information obtained by extracting a path condition to which no match flag is assigned from the path condition table shown in FIG. In this embodiment (Example 1), an example of the test data generated is shown. An example of a test data generation flow (part 1) in the present embodiment (Example 1) is shown. An example of a test data generation flow (part 2) in the present embodiment (Example 1) will be described. An example of a test data generation flow (part 3) in the present embodiment (Example 1) will be described. An example of a configuration of a test data generation apparatus according to the present embodiment (Example 2) will be described. In the path condition table 19 of FIG. 12, the rearrangement is performed so that the path condition to which the match flag is assigned is at the head of the table. It is a figure for demonstrating the processing content of the test case selection part in this embodiment (Example 2). It is a figure for demonstrating the test case selection process of this embodiment (Example 2). An example of an atomic logical formula table in this embodiment (Example 2) is shown. An example in which the data item “selection” 513 is added to the atomic formula table of FIG. 22 is shown. An example of the target logical expression table in this embodiment (Example 2) is shown. An example of the selection path condition table in this embodiment (Example 2) is shown. It is a figure for demonstrating the difference of the path condition stored in the selection path condition table in this embodiment (Example 2), and the path condition to which the match flag was provided. It is a figure for demonstrating the process of the data generation part 15 in this embodiment (Example 2). An example of a test data generation flow (part 1) in the present embodiment (Example 2) will be shown. An example of a test data generation flow (part 2) in the present embodiment (Example 2) will be shown. An example of a test data generation flow (part 3) in the present embodiment (Example 2) will be shown. An example of a test case selection flow (part 1) in the present embodiment (Example 2) will be described. An example of a test case selection flow (part 2) in the present embodiment (Example 2) will be described. An example of a test case selection flow (part 3) in the present embodiment (Example 2) will be shown. It is a block diagram of a hardware environment of a computer to which this embodiment is applied.

  As described above, symbolic execution is a technique for analyzing a program and extracting executable paths. An executable path is an execution path that branches to each transition destination according to a condition determination when symbolic execution is performed on the source code. Each path extracted by symbolic execution holds a conditional expression related to a program variable called a path condition (a conditional expression related to a branch condition involving a variable, an assignment expression, etc.), and a test case (test data) is obtained from this path condition. Can be generated. Here, symbolic execution will be described with reference to FIGS. 1 and 2.

  FIG. 1 is an example of source code. FIG. 2 is a diagram for explaining test case generation by symbolic execution. Symbolic execution is a technique in which, instead of inputting specific numerical values into variables included in the program, the program is simulated with symbols representing the numerical values, and the results are evaluated. When symbol values are used in a determination condition such as branching in a program, when symbolic execution is performed, the program is executed while taking into account combinations of logically possible symbol values (generation of symbolic execution trees).

  For example, consider a case where the source code shown in FIG. 1 is symbolically executed. In the source code of FIG. 1, two if statements are described. Symbolic execution is performed on the source code of FIG. Then, a symbolic execution tree is generated for the symbol values Sa, Sb, Sc corresponding to the values of the variables a, b, c as shown in FIG. For example, the code “a> = 0 & a <= 5” described in FIG. 1 is represented by “Sa> = 0 ∧ Sa <= 5”. Further, the code “b> 0 & c> 0” described in FIG. 1 is represented by “Sb> 0∧Sc> 0”.

  A path that branches from the determination condition in the symbolic execution tree represents a logical constraint (that is, a path condition) that should be satisfied when an assignment statement or a conditional statement is passed through symbolic execution. In symbolic execution, the path condition is accumulated every time an assignment statement or conditional statement is passed.

  The path from the root (root) to the leaf (leaf) in the symbolic execution tree is called an execution path. The execution path has a condition (path condition) for each symbol. For example, in the symbolic tree of FIG. 2, the path condition of the execution path P (the part surrounded by a broken line) is represented by “Sa> = 0∧Sa <= 5∧Sb> 0∧Sc> 0”.

  After such symbolic execution, whether or not there is a value satisfying the path condition, that is, the determination to show that the logical expression is not inconsistent is to make each logical expression true. It is only necessary to show that a combination of partial logical expressions is true or false. In order to determine whether or not a logical expression can be satisfied (can be true) as a process for checking consistency of logical expressions, a satisfiability determination processor, that is, SAT (satisfiability) or SMT (satisfiability) A constraint solver such as a modulo theory solver is used. The constraint solver can obtain a combination of solutions for obtaining a target value within the range of the constraint condition using a mathematical expression including a plurality of variables as the constraint condition. Note that symbolic execution may be used in combination with a model checking engine such as JPF (Java (registered trademark) Path Finder).

  Here, the execution path can be shown as a test case. In addition, the sufficiency value of the symbol value in the path condition can be shown as test data. Thus, by using symbolic execution, test case variations can be generated within a range of combinations of logically possible path conditions.

  Therefore, in symbolic execution, all the execution paths that can be satisfied in the conditional branch are automatically generated to enable comprehensive execution of the program. At this time, the number of test cases is reduced by selecting test cases based on a certain viewpoint and value (code coverage, similarity, etc.) from test cases generated mainly by test case automatic generation technology that tends to be redundant and enormous. It is required to do.

  Examples of code coverage include statement coverage, branch coverage, condition coverage, multi-condition coverage, and path coverage. Test cases generated by symbolic execution are based on path coverage.

  By the way, when a program that has been developed is corrected, the program is retested. In the retest, check that the functions that have been changed work in the same way for the part where the program has not been changed, and create a test specification for the changed function for the part where the program has been changed. To be tested.

  Therefore, a method of extracting a differential test case (test data) for testing a portion where the program has been changed using this symbolic execution technique can be considered. Specifically, it is possible to generate a path condition before and after the correction of the program, and to consider a path condition after correction that does not match the path condition before correction as a difference and generate an additional test case.

  FIG. 3 and FIG. 4 are diagrams for explaining the retest accompanying the correction of the program. FIG. 3A shows an execution path of the program before correction, and FIG. 3B shows a test case corresponding to the execution path. In FIG. 3, there are four execution paths (No. 1, No. 2, No. 3, No. 4).

  The test data of test case No. 1 is “a = -1, b = 0, c = 0, d = null”. The test data of test case No. 2 is “a = 0, b = 5, c = 0, d = null”. The test data of test case No. 3 is “a = 0, b = 5, c = 1, d =” ””. The test data of test case No. 4 is “a = 0, b = 4, c = 0, d = null”. The program of FIG. 3 is assumed to have already been tested using these test cases (branch coverage).

  FIG. 4A shows the modified program of FIG. 3, and FIG. 4B shows a test case corresponding to the execution path. In FIG. 3, the conditions “b> = 5” and “b <= 5” are changed to the conditions “b> = 10” and “b <= 10” in FIG. Compared to FIG. 3, the conditions “d.length <5” and “d.length> = 5” are added in FIG. 4. Here, test cases No. 1 to No. 4 can be reused. In this case, it is required to add a test case that passes a path (star) that is not covered by test cases No. 1 to No. 4.

  In this way, when a program that has been completely developed is corrected, it is necessary to retest the corrected portion. At this time, it is efficient to specify a test case to be newly added and retest the test case for the pre-correction program.

  Therefore, in order to generate an additional test case for the correction program, a path condition before and after correction is generated, and a path condition after correction that does not correspond to the path condition before correction is regarded as a difference, and an additional test case is generated. The method of doing is considered. However, as will be described with reference to FIG. 5, it is conceivable that reusable test cases cannot be associated.

  FIG. 5 is a diagram for explaining the association of path conditions before and after correction. As shown in FIG. 5, in the pass conditions before and after the correction, the same character strings can be associated with each other. However, in the path conditions before and after correction, it is not easy to associate the character strings that are not the same. For example, the path condition PC2 (test data: a = -1, b = 0, c = 0, d = “”) partially corresponds to PC'2 and PC'3 in the character string comparison. Judgment is possible. However, it cannot be determined by comparing the path conditions until the path condition PC2 corresponds to either PC'2 or PC'3.

  In addition, when a path condition that could not be matched due to character string comparison is added as a new test case even though the path conditions before and after correction are actually supported, an existing test case is added. This will make the test less efficient.

  Therefore, in the present embodiment, a technique for generating a differential test case (test data) for testing a portion where the program has been changed using test assets before the program is modified will be described.

  FIG. 6 shows an example of a test data generation apparatus in the present embodiment. The test data generation device 1 includes an input information acquisition unit 1-1, an extraction unit 1-2, a generation unit 1-3, a test data storage unit 1-8, and a path condition storage unit 1-9.

  The input information acquisition unit 1-1 acquires the first test data 2 and the route condition information 3. The first test data 2 is data used in the test of the program before correction. The route condition information 3 indicates a route condition (path condition) that expresses an execution route represented by a combination of processing routes branched and passed by a condition included in the source code of the program after correction by a logical expression. The input information acquisition unit 1-1 receives first test data that satisfies a path condition that expresses an execution path indicated by a combination of processing paths that are branched and passed by a condition included in the source code before the correction by a logical expression. get. An example of the input information acquisition unit 1-1 is the acquisition unit 13.

  The test data storage unit 1-8 stores the acquired first test data. An example of the test data storage unit 1-8 is the test data condition table 18.

  The route condition storage unit 1-9 stores the acquired route condition information. An example of the route condition storage unit 1-9 is a path condition table 19.

  The extraction unit 1-2 extracts route condition information that is not logically equivalent to the first test data stored in the test data storage unit 1-8 from the route condition information stored in the route condition storage unit 1-9. An example of the extracting unit 1-2 is the matching unit 14.

  The generation unit 1-3 generates second test data 4 that satisfies the route condition indicated by the extracted route condition information.

  With this configuration, it is possible to generate a differential test case (test data) for testing a portion where the program has been changed, using test assets before the program is modified. As a result, it is only necessary to prepare an output value corresponding to the difference test data among all the test cases obtained by symbolic execution, so that the man-hour for generating the output value can be saved. Therefore, it is possible to reduce the cost of the test after the program correction by using the test assets before the program correction.

  Further, the extraction unit determines whether the route condition information stored in the route condition storage unit 1-9 is first route condition information that is logically equivalent to the first test data 2. At this time, the test data generation device 1 further includes a decomposition unit 1-4, a target logical expression acquisition unit 1-5, a selection unit 1-6, and a difference acquisition unit 1-7.

  The decomposition unit 1-4 rearranges the route condition information stored in the route condition storage unit 1-9 in the order of logically equivalent information and non-equivalent information. Then, the decomposing unit 1-4 decomposes the rearranged path condition information into a target logical expression that is a logical expression including one or more atomic logical expressions. An example of the decomposition unit 1-4 includes the decomposition unit 41.

  The decomposition storage unit 1-10 stores path decomposition information that is information relating the decomposed target logical expression for each piece of route condition information. An example of the decomposition storage unit 1-10 is an atomic logical expression table.

  The target logical expression storage unit 1-11 stores the target logical expression. An example of the target logical expression storage unit 1-11 is a target logical expression table 52.

  The target logical expression acquisition unit 1-5 acquires path decomposition information from the decomposition storage unit 1-10. Then, the target logical expression acquisition unit 1-5, when the acquired path decomposition information includes a differential logical expression that is a target logical expression other than the target logical expression stored in the target logical expression storage unit 1-11, A logical expression is extracted and stored in the target logical expression storage unit 1-11. An example of the target logical expression acquisition unit 1-5 is the extraction unit 42.

  The selection unit 1-6 selects second route condition information corresponding to the route decomposition information from which the logical expression of the difference is extracted from the acquired route condition information. An example of the selection unit 1-6 is the selection unit 43.

  The difference acquisition unit 1-7 acquires a difference between the selected second route condition information and the first route condition information. An example of the difference acquisition unit is the difference acquisition unit 44.

  The generation unit 1-3 generates the second test data 4 from the path condition information acquired as the difference.

  By configuring in this way, it is possible not to select a test case composed of an atomic logical expression included in the target logical expression storage unit 1-11 among test cases (path conditions) to be added. . Thereby, redundant test cases can be eliminated.

The embodiment (Example 1) will be described in detail below.
Example 1
FIG. 7 shows an example of the configuration of the test data generation apparatus according to the present embodiment (Example 1). The test data generation device 11 includes a control unit 12 and a storage unit 17. The storage unit 17 includes a test data condition table 18, a path condition table 19, and an extracted path condition table 20.

  The test data condition table 18 stores test data (conditions) included in the test case for each test case used in the test of the program before correction. The path condition table 19 stores combinations of execution paths obtained by performing symbolic execution on the source code of the modified program, that is, combinations of path conditions (test cases). In the extracted path condition table 20, path conditions extracted by the data generation unit 15 among the path conditions included in the path condition table 19 are stored.

  The control unit 12 includes an acquisition unit 13, a matching unit 14, a data generation unit 15, and an output unit 16. The acquisition unit 13 acquires test data 31 and path condition information (test case) 34 by an input device (not shown), and stores them in the test data condition table 18 and the path condition table 19, respectively. The test data 31 is test data for each test case used in the test of the program before correction. The path condition information 34 is information including combinations of execution paths obtained by performing symbolic execution on the source code of the modified program, that is, combinations of path conditions (test cases).

  The matching unit 14 selects a path condition that is logically equivalent to each test data condition from the path condition table 19, and assigns a match flag to the selected path condition. The relation of logical equivalence will be described later.

  The data generation unit 15 extracts a path condition for which no match flag is set from the path condition table 19 and stores the extracted path condition in the extracted path condition table 20. The data generation unit 15 generates a test case 35 from the path condition stored in the extracted path condition table 20 using a constraint solver.

  The output unit 16 outputs the generated test case 35 to an output device such as a display or a printer. The test case 35 is a test case to be newly added for the test of the program after correction.

  FIG. 8 is a diagram for explaining input data in the present embodiment (Example 1). Test data 31 and a pass condition 34 are used as input data to the test data generation device 11. The test data 31 is test data used in the test of the program 32 before correction, and ensures branch coverage. Here, the corrected program 33 is, for example, the program shown in FIG. Test case 1 (TC1: a = -1, b = 0, c = 0, d = null) is test data for passing the execution path No. 01 (FIG. 3A) of the program 32. Test case 2 (TC2: a = 0, b = 5, c = 0, d = null) is test data for passing the execution path No. 02 (FIG. 3A) of the program 32. Test case 3 (TC3: a = 0, b = 5, c = 1, d = “”) is test data for passing the execution path No. 03 (FIG. 3A) of the program 32. Test case 4 (TC4: a = 0, b = 4, c = 0, d = null) is test data for passing the execution path No. 04 (FIG. 3A) of the program 32.

  The path condition information 34 is obtained by performing symbolic execution on the program 33 obtained by modifying the program 32. Here, the corrected program 33 is, for example, the program shown in FIG. The path condition information 34 includes 12 path condition information indicated by path conditions 1 to 12 (PC1 to PC12). In the path condition information 34, PC1 to PC12 are identification information for identifying the path condition.

  FIG. 9 shows an example of a test data condition table in the present embodiment (Example 1). The test data condition table 18 stores an expression obtained by concatenating the test data conditions (logical expressions) included in each test case of the test data 31 with a logical product by the acquisition unit 13.

  The test data condition table 18 includes data items “No.” 181 and “test data conditions” 182. “No.” 181 stores a No. corresponding to information for identifying the test data condition. “Test data” 182 stores test data condition information corresponding to the No. stored in “No.” 191.

  FIG. 10 shows an example of a path condition table in the present embodiment (Example 1). The path condition information 34 is a set of path conditions stored in the path condition table 19 by the acquisition unit 13. In FIG. 10, the symbol that connects the atomic logical expressions included in the path condition is indicated by a logical product “∧”. Here, the atomic logical formula is the minimum unit (single condition) of the logical formula or its negation. A logical expression is an expression that represents a condition (precondition or postcondition). The negation of a logical expression is a logical expression obtained by combining NOT with a logical expression.

  The path condition table 19 includes data items “No.” 191 and “path condition” 192. “No.” 191 stores a No. corresponding to information for identifying a path condition. In the “pass condition” 192, the path condition information corresponding to the No. stored in the “No.” 191 is stored.

  FIG. 11 is a diagram for explaining the processing of the matching unit in the present embodiment (Example 1). The matching unit 14 determines from the test data condition table 18 one test case (for example, “(a == − 1) ∧ (b == 0) ∧ (c == 0) ∧ (d == null)”). Is taken out (S1).

  Next, the matching unit 14 extracts one path condition (for example, “(a <0) ∧ (d == null)”) in the path condition table 19. Using the constraint solver, the matching unit 14 determines whether or not the extracted test data condition and the extracted path condition are logically equivalent (S2). Here, the logical expression A and the logical expression B are logically equivalent means that “(A if B) and (B if A) hold”). Therefore, in the above example, `` (a ==-1) = (b == 0) ∧ (c == 0) ∧ (d == null) → (a <0) ∧ (d == null) ∧ (a <0) ∧ (d == null) → (a ==-1) ∧ (b == 0) = 0 (c == 0) ∧ (d == null) '' Determined.

  When it is determined that the requirement that the test data condition and the path condition are logically equivalent can be satisfied, the matching unit 14 displays a match flag indicating that the test condition and the corresponding path condition in the path condition table 19 are matched. (S3). When it is determined that the requirement that the test data condition and the path condition are logically equivalent cannot be satisfied, the matching unit 14 extracts the next path condition from the path condition table 19.

  FIG. 12 shows an example in which a data item “match flag” 193 is added to the path condition table of FIG. As described with reference to FIG. 11, the matching unit 14 determines whether the test data condition retrieved from the test data condition table 18 and the path condition retrieved from the path condition table 19 are logically equivalent. As a result, if it is determined that the logically equivalent requirement can be satisfied, the matching unit 14 matches the corresponding path condition in the path condition table 19 as shown in FIG. Give a flag.

  In FIG. 12, the match flag is assigned to the No. 1 path condition because the test case TC01 and the path condition 01 match. In addition, since the test cases TC02 and TC04 and the path condition 10 are matched, a match flag is assigned to the No. 10 path condition. Further, because the test case TC03 and the pass condition 11 are matched based on the match flag, the match flag is assigned to the No. 11 pass condition.

  FIG. 13 shows an example of the extraction path condition table. The extracted path condition table stores path condition information obtained by extracting a path condition to which no match flag is assigned from the path condition table shown in FIG. The data generation unit 15 extracts a path condition to which no match flag is assigned from the path condition table shown in FIG. In the case of FIG. The path conditions indicated by 02 to 09 and 12 are extracted. The extraction result is shown in FIG.

  FIG. 14 shows an example of test data generated in the present embodiment (Example 1). The data generation unit 15 generates test data 35 from the path condition extracted in FIG. 13 using a constraint solver. The test data 35 is newly added test data in addition to the data used in the test of the program before correction in the test of the program after correction. Here, variables not appearing in the path condition are set to predetermined default values. For example, since “b” and “c” do not appear in the first path condition in FIG. 13, a predetermined default value 0 is set.

  15 to 17 show an example of a test case selection flow in the present embodiment (Example 1). The user uses the input device to input the test data 31 used in the test of the pre-correction program and the path condition information 34 obtained by the symbolic execution performed on the source code of the post-correction program using the input device. To enter.

  The acquisition unit 13 extracts the test data of one record test case from the test data 31 (S11, S12). The acquisition unit 13 converts the test data condition (logical expression) into a logical expression (test data conditional expression) concatenated by logical conjunction (S13), and stores it in the test data condition table 18 (S14). The acquisition unit 13 repeats the processing of S11 to S14 for the test data of the test case included in the input test data 31.

  The acquiring unit 13 stores the input path condition information in the path condition table 19 (S15).

  Next, the matching unit 14 extracts one record of the test data conditional expression from the test data condition table 18 (“Yes” in S16, S17). In addition, the matching unit 14 extracts one record of the path condition from the path condition table 19 (“Yes” in S18, S19).

  As described with reference to FIG. 11, the matching unit 14 creates a determination expression for determining whether or not both are logically equivalent from the extracted test data conditional expression and the extracted path condition (S20).

  The matching unit 14 uses the constraint solver to determine whether the test data conditional expression and the path condition are logically equivalent from the determination expression created in S20 (S21). When the test data conditional expression and the path condition are not logically equivalent (“No” in S21), the matching unit 14 takes out the record of the next path condition from the path condition table 19 (S18), and performs the processing of S19 to S21. I do. When there is no unprocessed path condition in the path condition table 19 (“No” in S18), the matching unit 14 extracts the record of the next test data conditional expression from the test data condition table 18 (“Yes” in S16, S17), the process after S18 is performed.

  When the test data conditional expression and the path condition are logically equivalent (“Yes” in S21), the matching unit 14 matches the corresponding path condition in the path condition table 19 as described in FIG. (S22). Thereafter, the matching unit 14 takes out the record of the next test data conditional expression from the test data condition table 18 (“Yes” in S16, S17), and performs the processes after S18.

  When the processing of S17 to S22 is completed for all the test data conditional expressions included in the test data condition table 18 ("No" in S16), the process proceeds to S23.

  The data generation unit 15 selects a record of one path condition from the path condition table 19 (“Yes” in S23, S24). When a match flag is given to the selected path condition (“No” in S25), the data generation unit 15 selects a record of the next path condition from the path condition table 19 (“Yes” in S23, S24). . If no match flag is given to the selected path condition (“Yes” in S25), the data generating unit 15 extracts the path condition and stores it in the extracted path condition table 20 (S26).

  When the processing of S24 to S26 is completed for all the test data conditional expressions included in the test data condition table 18 (“No” in S23), the data generation unit 15 performs the following processing. That is, the data generation unit 15 inputs the path condition stored in the extracted path condition table 20 to the constraint solver (S27).

  Then, the data generation unit 15 acquires a satisfaction value (test data 35) of the path condition from the constraint solver (S28). Here, the obtained test data 34 is test data of the program after correction, and is test data to be added to the test data used in the test case of the program before correction.

  According to this embodiment (Example 1), matching is performed between the path condition obtained from the symbolic execution of the source code of the corrected / changed program and the test data used before the correction. Thereby, the reusable test case in the test asset can be specified. That is, according to the present embodiment (Example 1), test cases (test data) corresponding to the corrected / changed differences are extracted, and an effect of reducing the cost of retesting can be obtained.

(Example 2)
In the first embodiment, test data that can complement a portion of the path condition obtained by performing symbolic execution on the source code of the corrected program that cannot be handled by the test data of the program before the correction is added.

  However, symbolic execution generates all path conditions that can be executed, resulting in an enormous number of combinations of path conditions. As a result, the number of test cases based on path coverage also becomes enormous.

In this case, these test cases may include many redundant test cases from the viewpoint of code coverage.
Therefore, in the second embodiment, a description will be given of selecting a test case that excludes redundant test cases while ensuring code coverage among the test cases determined as test cases to be added in the first embodiment.

  In this embodiment (Example 2), the path conditions (test cases) generated by symbolic execution in Example 1 are decomposed into atomic logical expressions so that all types of atomic logical expressions included in the path conditions can be executed. Select a pass condition (test case). At this time, when selecting a test case, a path condition including an atomic logical formula that is not included in any of the already selected path conditions is selected. A differential path condition between the selected path condition and a path condition to which no match flag is assigned in the first embodiment is extracted. Using the constraint solver, test data to be added is obtained from the path condition of the difference.

  FIG. 18 shows an example of the configuration of the test data generation apparatus according to the present embodiment (Example 2). The test data generation device 11 in FIG. 18 is obtained by adding a test case selection unit 40, an atomic logical formula table 51, a target logical formula table 52, and a selected path condition table 53 to the test data generation device 11 in FIG.

  The test data generation device 11 in FIG. 18 includes a control unit 12 and a storage unit 17. The storage unit 17 includes a table data condition table 18, a path condition table 19, an extracted path condition table 20, an atomic logical formula table 51, a target logical formula table 52, and a selected path condition table 53.

  Since the table data condition table 18, the path condition table 19, and the extracted path condition table 20 have been described in the first embodiment, description thereof will be omitted.

  The atomic logical formula table 51 stores the atomic logical formula included in the path condition for each path condition. In the target logical expression table 52, the atomic logical expressions constituting the path condition are stored for each type. The selected path condition table 53 stores the path conditions selected by the selection unit 43 among the path conditions included in the path condition table 19.

  The control unit 12 includes an acquisition unit 13, a matching unit 14, a test case selection unit 40, a data generation unit 15, and an output unit 16. The acquisition unit 13 acquires test data 31 and path condition information (test case) 34 by an input device (not shown), and stores them in the test data condition table 18 and the path condition table 19, respectively. The test data 31 is test data for each test case used in the test of the program before correction. The path condition information 34 is information including combinations of execution paths obtained by performing symbolic execution on the source code of the modified program, that is, combinations of path conditions (test cases).

  The matching unit 14 selects a path condition that is logically equivalent to each test data condition from the path condition table 19, and assigns a match flag to the selected path condition.

  The test case selection unit 40 includes a decomposition unit 41, an extraction unit 42, a selection unit 43, and a difference acquisition unit 44. The decomposing unit 41 sorts the path condition table 19 so that the path condition to which the match flag is assigned is at the head of the table. The decomposition unit 41 decomposes each path condition stored in the path condition table 19 after the sorting process into an atomic logical expression. The decomposition unit 41 stores the atomic logical formula in the atomic logical formula table 51 for each path condition.

  The extraction unit 42 extracts an atomic logical expression other than the atomic logical expressions held so far in the target logical expression table 52 from the atomic logical expressions of the focused path condition in the atomic logical expression table 51. The extraction unit 42 stores the extracted atomic logical formula in the target logical formula table 52. Further, the extraction unit 42 sets a selection flag for the path condition in the atomic logic formula table 51 in order to specify the path condition that includes the extracted atomic logic formula.

  The selection unit 43 detects a path condition in which a selection flag is set from the atomic logic formula table 51. The selection unit 43 selects a path condition corresponding to the detected path condition from the path condition table 19 and stores it in the selected path condition table 53.

  The difference acquisition unit 44 acquires the difference between the path condition to which the match flag is assigned in the path condition table 19 and the path condition stored in the selected path condition table 53 and stores the difference in the extracted path condition table 20.

  The data generation unit 15 generates a test case 35 from the path condition stored in the extracted path condition table 20 using a constraint solver.

  The output unit 16 outputs the generated test case 35 to an output device such as a display or a printer. The test case 35 is a test case to be newly added for the test of the program after correction.

The functions of the decomposition unit 41, the extraction unit 42, the selection unit 43, and the difference acquisition unit 44 will be described in detail below.
FIG. 19 shows how the path condition table 19 shown in FIG. 12 is rearranged so that the path condition to which the match flag is assigned is at the head of the table. As described above, the disassembling unit 41 sorts so that the path condition to which the match flag is assigned comes to the head of the path condition table 19.

  FIG. 20 is a diagram for explaining the processing contents of the test case selection unit in the present embodiment (Example 2). The test case selection unit 40 selects a path condition that ensures code coverage from the sorted path conditions (FIG. 19) depending on the presence or absence of the match flag.

  FIG. 21 is a diagram for describing test case selection processing according to the present embodiment (Example 2). The test case selection unit 40 searches for a test case satisfying a certain coverage from all test cases without actually executing the test case by analyzing the path condition of each test case. That is, the test case selection unit 40 satisfies the atomic logical expressions included in the path conditions as conditional expressions on the program, and how many atomic logical expressions among all kinds of atomic logical expressions (or combinations thereof) are satisfied for each path condition. It is analyzed on the pass condition. Code coverage is closely related to atomic conditions in conditional expressions in the program. Here, the atomic condition is a condition on the source code corresponding to the atomic logical expression.

  The table of FIG. 21 is a table in which path conditions (test cases) sorted according to the presence or absence of a match flag are decomposed into atomic logical expressions. In the column direction of the table of FIG. 21, atomic logical expressions on the path condition are arranged. When the path condition of No. 01 is “(a <0) ∧ (d == null)”, “o” is added to “a <0” and “d == null” in the table of FIG. ing.

  First, select the path condition No.01. The path condition of No. 01 includes the atomic logical expressions “a <0” and “d == null” as described above.

  Next, pay attention to No.10 pass condition. The path condition of No. 10 includes the atomic logical expressions “a> = 0” and “b <10” that are not included in the path condition of No. 01. Therefore, the path condition of No. 10 is selected.

  Next, pay attention to No.11 pass condition. The No. 11 path condition includes the atomic logical formulas “d! = Null” and “d.length <5” that are not included in either the No. 01 or No. 10 path condition. Select a condition.

  Next, focus on No.02 pass condition. Since all of the atomic logical expressions included in the No. 02 path condition are included in any of the No. 01, No. 10, and No. 11 path conditions, the No. 02 path condition is not selected.

  Next, focus on the No.03 pass condition. The path condition of No.03 includes the atomic logical formula “d.length> = 5” that is not included in any of the path conditions of No.01, No.10, No11, and No.02. Select a pass condition.

  Similarly, after the path condition of No. 04, if the target path condition includes an atomic logical formula different from the atomic logical formula included in the path condition selected so far, the target path condition is changed. select. Then, in the case of the table of FIG. 21, six No. 01, No. 10, No. 11, No. 03, No. 04, and No. 07 path conditions are selected from 12 test cases. . As a result, using the path conditions No.01, No.10, No.11, No.03, No.04, and No.07, a test that can satisfy all the atomic logical expressions of all path conditions is executed. can do.

  FIG. 22 shows an example of an atomic logical expression table in the present embodiment (Example 2). The atomic logical formula table 51 includes data items “No.” 511 and “atomic logical formula” 512. “No.” 51 stores a No. corresponding to the identification information of the path condition. The “atomic logical expression” 512 stores an atomic logical expression included in the path condition information corresponding to the No. stored in the “No.” 51.

  Here, the operation of the decomposition unit 41 related to the atomic logic formula table 51 will be described. The decomposition unit 41 reads path condition information from the sorted path condition table 19 (FIG. 19) depending on the presence or absence of a match flag, and decomposes the read path condition information into an atomic logical expression. The decomposition unit 41 stores the atomic logical formula in the atomic logical formula table 51 for each path condition.

  FIG. 23 shows an example in which the data item “selection” 513 is added to the atomic logical expression table of FIG. FIG. 24 shows an example of the target logical expression table in the present embodiment (Example 2). The target logical formula table 52 holds atomic logical formulas other than the atomic logical formulas held so far among the atomic logical formulas included in the focused path condition in the atomic logical formula table 51. As a result, all types of atomic logical expressions included in the atomic logical expression table 51 are finally stored in the target logical expression table 52. That is, in the target logical expression table 52, finally, atomic logical expressions included in all path conditions are stored for each type.

  Here, the operation of the extraction unit 42 regarding the target logical expression table 52 will be described. The extraction unit 42 extracts an atomic logical expression that is not held in the target logical expression table 52 from the atomic logical expression of the focused path condition in the atomic logical expression table 51. The extraction unit 42 stores the extracted atomic logical formula in the target logical formula table 52. Further, the extraction unit 42 sets a flag (selection flag) in the “selection” 513 corresponding to the path condition including the extracted atomic logical formula in the atomic logical formula table 51.

  FIG. 25 shows an example of the selected path condition table in the present embodiment (Example 2). The selection unit 43 detects the flag condition in which the flag is set from the atomic logic formula table 51. The selection unit 43 selects a path condition corresponding to the detected path condition from the path condition table 19 and stores it in the selected path condition table 53.

  FIG. 26 is a diagram for explaining the difference between the path condition stored in the selected path condition table and the path condition to which a match flag is assigned in the present embodiment (example 2). The path conditions stored in the selected path condition table 53 are No. = 01, 10, 11, 03, 04, 07. The path conditions to which the match flag is assigned are No. = 01, 10, 11. The difference acquisition unit 44 acquires a path condition (difference path condition) of difference No. = 03, 04, 07 between the path condition stored in the selected path condition table 53 and the path condition to which the match flag is assigned. The difference acquisition unit 44 stores the difference path condition in the extraction path condition table 20.

  FIG. 27 is a diagram for explaining the processing of the data generation unit 15 in the present embodiment (Example 2). The data generation unit 15 generates test data 35 from the differential path condition stored in the extracted path condition table 20 using a constraint solver.

  28 to 30 show an example of a test data generation flow in the present embodiment (Example 2). After the processes in FIGS. 15 and 16, the processes in FIGS. 28 to 30 are performed.

  The test case selection unit 40 (decomposition unit 41) sorts so that the path condition to which the match flag is assigned is at the head of the path condition table 19 (S31). The test case selection unit 40 performs a test case selection process (S32). The process of S32 will be described in detail with reference to FIGS. As a result, a path condition (test case) in which branch coverage is secured is stored in the selected path condition table 53 (FIG. 25).

  The difference acquisition unit 44 extracts a path condition of one record (referred to as “target path condition T1”) from the selected path condition table 53 (“Yes” in S33, S34).

  The difference acquisition unit 44 extracts a path condition of one record (referred to as “target path condition T2”) from the path condition table 19 (“Yes” in S35, S36).

  The difference acquisition unit 44 determines whether the target path condition T1 and the target path condition T2 are the same expression and the match flag of the target path condition T2 is not set (S37).

  If the target path condition T1 and the target path condition T2 are not the same expression, or the match flag of the target path condition T2 is set (“No” in S37), the difference acquisition unit 44 performs the following process. That is, the difference acquisition unit 44 retrieves the next path condition from the path condition table 19 and performs the processes after S36. If there is no unprocessed path condition in the path condition table 19, the process returns to S33.

  When the target path condition T1 and the target path condition T2 are the same expression and the match flag of the target path condition T2 is not set, the difference acquisition unit 44 sets a difference flag in the target path condition T2 in the path condition table ( S38). Thereafter, the process returns to S35.

  When the processes of S34 to S38 are completed for all the path conditions stored in the selected path condition table 53 ("No" in S33), the process proceeds to S39.

  The data generation unit 15 selects a path condition of one record from the path condition table 19 (“Yes” in S39, S40). When the difference flag is not given to the selected path condition (“No” in S41), the data generation unit 15 selects the next path condition from the path condition table 19 (“Yes” in S39, S40). When a difference flag is given to the selected path condition (“Yes” in S41), the data generation unit 15 extracts the path condition and stores it in the extracted path condition table 20 (S42).

  When the processes of S40 to S42 are completed for all the path conditions included in the path condition table 19 (“No” in S39), the data generation unit 15 performs the following process. That is, the data generation unit 15 inputs the path condition stored in the extracted path condition table 20 to the constraint solver (S43).

  Then, the data generation unit 15 acquires a satisfaction value (test data) of the path condition from the constraint solver (S28). Here, the obtained test data is test data of the program after correction, and is test data to be added to the test data used in the test case of the program before correction.

  FIGS. 31 to 33 show an example of a test case selection flow in the present embodiment (Example 2). 31 to 33 show a detailed flow of S32 of FIG.

  The disassembling unit 41 reads a record from the path condition table 19 (“Yes” in S51, S52). The decomposition unit 41 determines whether an atomic logical expression exists in the path condition of the read record (S53). If an atomic logical expression exists in the path condition of the read record (“Yes” in S53), the decomposition unit 41 extracts the atomic logical expression included in the path condition of the record and stores it in the atomic logical expression table 51 (S54). ). The decomposition unit 41 repeats the process of S54 until all the atomic logical expressions are extracted from the path condition of the record.

  If there is no atomic logical expression in the path condition of the read record (“No” in S53), and there is an unprocessed record in the path condition table 19 (“Yes” in S51), the decomposition unit 41 Process. That is, the decomposition unit 41 reads the next record from the path condition table 19 and performs the processes of S53 to S54. If there is no unprocessed record in the path condition table 19 (“No” in S51), the process transitions to the process of S55 in FIG.

  Next, the extraction unit 42 reads a record from the atomic logical formula table 51 (“Yes” in S55, S56). The extraction unit 42 determines whether there is an atomic logical expression that does not exist in the target logical expression table 52 among the atomic logical expressions included in the record read in S56 (S57).

  When there is an atomic logical formula (difference) that does not exist in the target logical formula table 52 among the atomic logical formulas included in the record read in S56, the extraction unit 42 sets the differential atomic logical formula in the target logical formula table 52. (S58). At this time, the extraction unit 42 sets a flag in the data item “selection” 513 of the read record in the atomic logical formula table 51.

  On the other hand, in S57, when all the atomic logical expressions included in the read record exist in the target logical expression table 52 (“No” in S57), or when the process of S59 ends, the process returns to S55. While there is an unprocessed record in the atomic logical formula table 51 (“Yes” in S55), the extraction unit 42 reads the next record from the atomic logical formula table 51 and performs the processing of S56 to S59. While there is no unprocessed record in the atomic logic formula table 51 (“No” in S55), the process transitions to the process of S60 in FIG.

  Next, the selection unit 43 reads a record from the atomic logical formula table 51 (“Yes” in S60, S61). The selection unit 43 determines whether or not the selection flag of the read record is set (S62).

  In S13, when it is determined that the selection flag of the read record is set (“Yes” in S62), the selection unit 43 determines from the path condition table 19 the path of the same No. as the record with the selection flag set. Get the condition. The selection unit 43 adds the acquired path condition to the selected path condition table 53 (S63).

  In S62, when it is determined that the selection flag of the target record is not set (“No” in S62), or when the process of S63 is completed, the process returns to S60. While there are unprocessed records for the processes of S61 to S63 in the atomic formula table 51 (“Yes” in S60), the extraction unit 42 reads the next record from the atomic formula table 51 (S61), and S62 to S62. The process of S63 is performed. If the processing is completed for all the records in the atomic formula table 51 (“No” in S60), this flow ends.

  According to the present embodiment (Example 2), among the test cases (path conditions) to be added in Example 1, a test case composed of the atomic formulas included in the target formula table is not selected. can do. Thereby, redundant test cases can be eliminated. Therefore, the more test cases that are configured from the atomic logical expressions included in the target logical expression table, the more test cases can be reduced than the method of measuring coverage while executing the test cases one by one. In other words, focusing on the test cases to be added in the first embodiment, the number of test cases to be added increases as the number of test cases to be added increases. As a result, it is possible to reduce the cost of the test after the program correction by using the test assets before the program correction.

  Further, according to the present embodiment (Example 2), the selection priority of the path condition corresponding to the test case before correction is increased. As a result, in the test case selection in accordance with the coverage of the corrected program, it is possible to obtain a test case to be added for ensuring the coverage while reusing the existing test case to the maximum extent.

  FIG. 34 is a block diagram showing the hardware environment of a computer to which this embodiment is applied. The computer 60 functions as the test data generation device 11 by reading a program for performing the processing (FIGS. 15 to 17 and FIGS. 28 to 33) of the present embodiment (Example 1 or 2).

  The computer 60 includes an output I / F 61, a CPU 62, a ROM 63, a communication I / F 64, an input I / F 65, a RAM 66, a storage device 67, a reading device 68, and a bus 69. The computer 60 can be connected to an output device 71 and an input device 72.

  Here, CPU indicates a central processing unit. ROM indicates a read-only memory. RAM indicates random access memory. I / F indicates an interface. An output I / F 61, a CPU 62, a ROM 63, a communication I / F 64, an input I / F 65, a RAM 66, a storage device 67, and a reading device 68 are connected to the bus 69. The reading device 68 is a device that reads a portable recording medium. The output device 71 is connected to the output I / F 61. The input device 72 is connected to the input I / F 65.

As the storage device 67, various types of storage devices such as a hard disk drive, a flash memory device, and a magnetic disk device can be used.
For example, the storage device 67 or the ROM 63 stores a program that realizes the processing described in the present embodiment. Alternatively, the test data condition table 18, the path condition table 19, the extracted path condition table 20, the atomic logic formula table 51, the target logic formula table 52, and the selected path condition table 53 are stored in the storage device 67 or the ROM 63.

  The CPU 62 reads a program that realizes the processing described in the present embodiment (Example 1 or 2) stored in the storage device 67 and executes the program. Specifically, the CPU 62 functions as the control unit 12 (the acquisition unit 13, the matching unit 14, the test data selection unit 40, the data generation unit 15, and the output unit 16) by executing the program.

  A program for realizing the processing described in the present embodiment may be stored in the storage device 67, for example, via the communication network 70 and the communication I / F 64 from the program provider side. Moreover, the program which implement | achieves the process demonstrated by this embodiment may be stored in the portable storage medium marketed and distribute | circulated. In this case, the portable storage medium may be set in the reading device 68 and the program read by the CPU 62 and executed. As the portable storage medium, various types of storage media such as a CD-ROM, a flexible disk, an optical disk, a magneto-optical disk, an IC (integrated circuit) card, and a USB (Universal Serial Bus) memory device can be used. The program stored in such a storage medium is read by the reading device 68.

  As the input device 72, a keyboard, mouse, electronic camera, web camera, microphone, scanner, sensor, tablet, touch panel, or the like can be used. The output device 71 can be a display, a printer, a speaker, or the like. The network 70 may be a communication network such as the Internet, a LAN, a WAN, a dedicated line, a wired line, and a wireless line.

  In addition, this embodiment is not limited to embodiment described above, A various structure or embodiment can be taken in the range which does not deviate from the summary of this embodiment.

1 Test Data Generation Device 1-1 Input Information Acquisition Unit 1-2 Extraction Unit 1-3 Generation Unit 1-4 Decomposition Unit 1-5 Target Logical Formula Acquisition Unit 1-6 Selection Unit 1-7 Difference Acquisition Unit 1-8 Test Data storage unit 1-9 Path condition storage unit 2 First test data 3 Path condition information 4 Second test data 11 Test data generation device 12 Control unit 13 Acquisition unit 14 Matching unit 15 Data generation unit 16 Output unit 17 Storage unit 18 Test Data Condition Table 19 Path Condition Table 20 Extracted Path Condition Table 40 Test Case Selection Unit 41 Decomposition Unit 42 Extraction Unit 43 Selection Unit 44 Difference Acquisition Unit 51 Atom Logical Formula Table 52 Target Logical Formula Table 53 Selected Path Condition Table

Claims (7)

A path condition that expresses, by a logical expression, an execution path indicated by a combination of the first test data used in the test of the program before correction and the processing path branched and passed by the condition included in the source code of the program after correction An input information acquisition unit for acquiring route condition information indicating
A test data storage unit for storing the acquired first test data;
A route condition storage unit for storing the acquired route condition information;
An extraction unit that extracts route condition information that is not logically equivalent to the first test data stored in the test data storage unit from the route condition information stored in the route condition storage unit;
A generating unit that generates second test data that satisfies the route condition indicated by the extracted route condition information;
A test data generation device comprising: The input information acquisition unit acquires the first test data that satisfies a path condition that expresses an execution path indicated by a combination of processing paths that are branched and passed by a condition included in the source code before correction by a logical expression. The test data generation device according to claim 1, wherein: The extraction unit determines whether the route condition information stored in the route condition storage unit is first route condition information that is logically equivalent to the first test data;
The test data generation device further includes:
The route condition information stored in the route condition storage unit is rearranged in the order of the logically equivalent information and the non-equivalent information, and the rearranged route condition information is a logical expression including one or more atomic logical expressions. A decomposition part to be decomposed into a target logical formula,
A decomposition storage unit that stores route decomposition information that is information relating the decomposed target logical expression for each of the route condition information;
A target logical expression storage unit for storing the target logical expression;
When the route decomposition information is acquired from the decomposition storage unit and the acquired route decomposition information includes a difference logical expression that is a target logical expression other than the target logical expression stored in the target logical expression storage unit, A target logical expression acquisition unit that extracts a logical expression of the difference and stores it in the target logical expression storage unit;
A selection unit that selects second route condition information corresponding to the route decomposition information from which the logical expression of the difference is extracted from the acquired route condition information;
A difference acquisition unit for acquiring a difference between the selected second route condition information and the first route condition information;
With
The test data generation device according to claim 1, wherein the generation unit generates the second test data from path condition information acquired as the difference. On the computer,
A path condition that expresses, by a logical expression, an execution path indicated by a combination of the first test data used in the test of the program before correction and the processing path branched and passed by the condition included in the source code of the program after correction And route condition information indicating
Storing the acquired first test data in a test data storage unit;
The acquired route condition information is stored in a route condition storage unit,
Extracting route condition information that is not logically equivalent to the first test data stored in the test data storage unit from the route condition information stored in the route condition storage unit;
Generating second test data that satisfies the route condition indicated by the extracted route condition information;
A test data generation program characterized by causing a process to be executed. In the acquisition of the route condition information, the first test data satisfying a route condition that expresses an execution route represented by a combination of processing routes that are branched by the condition included in the source code before correction and expressed by a logical expression. The test data generation program according to claim 4, wherein the test data generation program is acquired. In the extraction of the route condition information, it is determined whether the route condition information stored in the route condition storage unit is first route condition information that is logically equivalent to the first test data;
The computer further includes:
The route condition information stored in the route condition storage unit is rearranged in the order of the logically equivalent information and the non-equivalent information, and the rearranged route condition information is a logical expression including one or more atomic logical expressions. Is broken down into a target formula that is
Path decomposition information, which is information relating the decomposed target logical expression for each of the path condition information, is stored in the decomposition storage unit;
The route decomposition information is acquired from the decomposition storage unit, and the acquired route decomposition information is a target logical expression other than the target logical expression stored in the target logical expression storage unit in which the target logical expression is stored. If a logical expression is included, the logical expression of the difference is extracted and stored in the target logical expression storage unit;
From the acquired route condition information, select the route condition information corresponding to the route decomposition information from which the logical expression of the difference is extracted,
A process of acquiring a difference between the selected second route condition information and the first route condition information;
The test data generation program according to claim 4 or 5, wherein, in the generation of the test data, the second test data is generated from the path condition information acquired as the difference. A test data generation method executed by a computer,
The computer
A path condition that expresses, by a logical expression, an execution path indicated by a combination of the first test data used in the test of the program before correction and the processing path branched and passed by the condition included in the source code of the program after correction And route condition information indicating
Storing the acquired first test data in a test data storage unit;
The acquired route condition information is stored in a route condition storage unit,
Extracting route condition information that is not logically equivalent to the first test data stored in the test data storage unit from the route condition information stored in the route condition storage unit;
Generating second test data that satisfies the route condition indicated by the extracted route condition information;
A test data generation method that executes processing.

Images