JP6533484B2 - Test data generation program and test data generation method - Google Patents

Description

  The present invention relates to a test data generation program and a test data generation method, and more particularly, to a technology for generating test data corresponding to a branch condition of a character string in a genetic algorithm of Search-Based Software Testing (SBST).

  Tests in the software development process require test cases to check whether the program executes as designed. If you can prepare test cases automatically instead of manually, you can improve development costs.

  A test case is composed of a test scenario representing a test procedure and test data which is specific data for realizing the test scenario.

  In order to generate test cases, methods for automatically generating test scenarios and test data based on program design are being considered.

  In Non-Patent Document 1, it is proposed to generate a test scenario and test data (integer type, character string type) by using input value definition and processing flow diagram as input.

  In addition, Non-Patent Document 2 proposes that test data be generated using a genetic algorithm as a search algorithm of SBST.

  In addition, Non-Patent Document 3 proposes a test data generation technique in which Concolic Testing and SBST are combined.

Zhang Jingyi, Hoshino Takashi, "Test Item Extraction and Test Data Generation Method Using Design Model", IEICE Technical Report, Volume 109, SS 2009-7, pp. 37-42, 2009 "Evolutionary Generation of Whole Test Suites", 2011 11th International Conference on Quality Software, pp. 31-40, 2011 "A Hybrid Directed Test Suite Augmentation Technique", 2011 22nd International Symposium on Software Reliability Engineering, pp. 150-159, 2011

  In order to confirm whether the program executes as designed, both the test scenario of how to execute the test and the test data, which are specific input values used in the test scenario, are used. It will be necessary. Here, given a test scenario, it is required to efficiently generate a set of test data that comprehensively passes through a branch on the source code. There are two types of branches: those that branch based on comparison of numerical values and those that branch based on comparison of character strings. However, it is necessary to improve the coverage also for the branch condition based on comparison of character strings.

  According to the technique of Non-Patent Document 1, it is difficult to generate test scenarios and test data efficiently because it is necessary to manually create input value definitions and process flow diagrams.

  Further, according to the technique of Non-Patent Document 2, test data is generated using a constant acquired in advance by static analysis in a method to be tested, but coverage can not be improved at the joint test level. In addition, since the place for obtaining the constant is not considered, it is possible to select a constant that is less related to the branch to be solved.

  Further, according to the technique of Non-Patent Document 3, generation of test data takes time because only two techniques, Concolic Testing and SBST, are executed in order. Furthermore, in general, it is difficult for SBST to generate test data for a branch including a data type of a character string.

  An object of the present invention is to efficiently generate an exhaustive set of test data for a branch including a data type of a string given a test scenario.

A test data generation program according to an aspect of the present invention is
A test data generation program for generating test data for a specified test scenario, the computer comprising:
A character string set acquisition function for acquiring a set of character strings used to generate test data;
A code insertion function for inserting into the program to be tested a code that outputs a branch result including an evaluation value for quantitatively evaluating the determination of the branch;
A first test data generation function of generating test data for a specified test scenario and generating a branch result output from the inserted code;
A target branch result that matches the path halfway to the generated branch result is generated, and a character string selected from among the acquired character string set is used in a genetic algorithm, and the target branch result is generated. A second test data generation function for generating test data to be satisfied;
To realize.

In addition, a test data generation method according to an aspect of the present invention is
A test data generation method in a test data generation apparatus for generating test data for a specified test scenario, comprising:
The test data generation device acquiring a set of character strings used for generation of test data;
Inserting, in the program to be tested, a code that outputs a branch result including an evaluation value for quantitatively evaluating the determination of a branch, into the program to be tested;
The test data generator generating test data for a specified test scenario and generating a branch result output from the inserted code;
The test data generation device generates a target branch result that matches the path halfway to the generated branch result, and uses a character string selected from the acquired character string set in a genetic algorithm Generating test data satisfying the target branch result;
It is characterized by having.

  According to the present invention, given a test scenario, it is possible to efficiently generate an exhaustive set of test data for a branch including a data type of a character string.

Diagram showing an example of branching result Diagram showing the relationship between branch coverage and condition coverage Functional block diagram of test case generation apparatus according to an embodiment of the present invention Diagram showing View transition diagram and example VC scenario Diagram showing predetermined coverage criteria for state transition diagrams Outline flowchart of test case generation method according to an embodiment of the present invention Detailed Flowchart of Step S001 in FIG. Detailed Flowchart of Step S002 of FIG. 6 Detailed Flowchart of Step S003 in FIG. Detailed flowchart of step S 004 of FIG. 6 Detailed Flowchart of Step S005 of FIG. 6 Detailed flowchart of step S 007 in FIG. Detailed Flowchart of Step S008 of FIG. 6 Detailed flowchart of step S205 of FIG. 13 Detailed flowchart of step S305 in FIG. Detailed flowchart of step S306 in FIG. 14 Detailed flowchart of step S602 in FIG.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  In the embodiment of the present invention, a test case generation program and a test case generation method for generating a test case which is a combination of a test scenario of a program and test data will be described. In addition, for convenience of the description regarding a test case production | generation program, the test case production | generation apparatus which implement | achieved each function of the program on the computer is mentioned as an example, and is demonstrated.

  Although the following embodiment will be described from the generation of a test scenario, the embodiment of the present invention is a test data generation program and test data generation method for generating test data for a specified test scenario when a test scenario is specified. Can also be realized.

  The test case generation apparatus generates a test scenario with a program of an application having a user interface such as a Web application as a test target. Such an application is designed in accordance with a model view controller (MVC), and is configured with at least a view and a controller. Model is an element for expressing data and logic handled by the application, View is an element for performing input / output and display, and Controller is for executing the necessary logic according to the input from View. It is an element to ask for and ask for View to display the result. In a program designed according to MVC, the connection between Views can be extracted using the information of Controller. The test case generation apparatus generates a VC scenario representing the connection of View and Controller based on a predetermined coverage criterion for the state transition diagram from the transition diagram of View representing the connection between Views.

  The test case generation device generates test data that satisfies the generated VC scenario while moving a program to be tested. On the other hand, VC scenario information consisting of a list of View and Controller names alone does not know what to do. Therefore, the test case generation apparatus generates a test scenario by adding View operation information to a VC scenario by a crawler or user operation.

  Next, the test case generation apparatus generates test data as follows by specifying one of the generated test scenarios.

  The test case generation apparatus generates test data using a test data generation method of generating test data by analyzing evaluation values for branches. A specific example of such a test data generation method is SBST. The SBST is a test data generation method that generates test data by analyzing an evaluation value for quantitatively evaluating the determination of a branch. For example, an evaluation function of (0-input value) is designed for a branch of input value> 0, and the evaluation value of the evaluation function is analyzed to generate test data satisfying the branch condition.

  Hereinafter, a specific example using SBST will be described.

  In SBST, since the evaluation value of the branch is used, the test case generation apparatus first inserts a code for outputting a branch result including an evaluation value for quantitatively evaluating the determination of the branch into the program to be tested. . Then, the test case generation apparatus generates test data for the specified test scenario by Concolic Testing or SBST, and generates a branch result output from the inserted code. Concolic Testing is a test data generation method for generating test data by analyzing a constraint expression obtained by replacing input values with symbols. For example, instead of using a specific numerical value for the branch of input value> 0, test data satisfying the branch condition is generated by replacing the numerical value with the symbol x and analyzing the constraint expression of x> 0.

  On the other hand, it is difficult to analyze a branch including the data type of a character string using only the evaluation value of the branch. Therefore, the test case generation apparatus generates a String Pool, which is a set of character strings generated by static analysis, dynamic analysis or preliminary preparation, for the program to be tested. Static analysis means to analyze a constant used to determine a data type match in a source code or byte code of a program. Also, dynamic analysis means analyzing a constant used to determine whether the data type of the character string matches when the program to be tested is being executed. For example, when there is a match determination of String type A.equals (B), constant B is added to String Pool by static analysis or dynamic analysis. Preparation means preparing in advance a string that may be used as an input value or a branch. For example, when an address is used as an input value, a string such as “Chiyoda-ku, Tokyo” is added to the String Pool in advance.

  Next, the test case generation device generates a target branch result that matches the path halfway to the generated branch result, and generates test data that satisfies the target branch result. A genetic algorithm is used as a search algorithm for test data that satisfies this target bifurcation result. The genetic algorithm considers a set of test data as a set of genes, and generates new test data by manipulating genes by selection, crossover and mutation. The test case generator generates new test data using a string selected from the String Pool in genetic algorithm mutation. At this time, by considering the string pool acquisition location of String Pool, select a string with high relevance to the branch.

  However, if concoric testing or SBST is performed on the source code of the size to be subjected to the binding test, a test explosion may occur, and test data may be generated with the specified user-descriptive class as an analysis target. That is, the calculation explosion may be avoided by not generating a test case that improves coverage for a portion such as a framework or a library that is not described.

  Finally, the test case generation apparatus outputs a test case that is a combination of a test scenario and test data.

<Explanation of terms>
First, terms used in the embodiments of the present invention will be described.

  The test suite is composed of a plurality of test cases and branching results when each test case is executed. A test suite consisting of a test case as a final output in the embodiment of the present invention and a branch result of the test case is called an output test suite, and a test suite used to execute SBST is a material test suite. . For example, a test suite is defined as [test case 1, branch result 1], [test case 2, branch result 2],.

  A test case is one that possesses the information necessary to execute a program test, and is composed of one test scenario and one test data.

  The test scenario represents a procedure for executing a test, and is composed of a set of steps that are VC scenario and View operation information. For example, a test scenario is defined as [VC scenario], [step 1, step 2, ...].

  Test data is a set of specific values for realizing a test scenario. If a genetic algorithm is used to determine this specific value in SBST, then the test data is considered to be a collection of genes. For convenience, test data is defined as a set of genes, even if Concolic Testing etc. are used. For example, test data is defined as gene 1, gene 2,.

  The view transition diagram is a transition diagram showing the connection between the views. In a program designed in accordance with MVC, since the Controller communicates the input from the View to the Model and the execution result of the Model to the View, the controller's information can be used to generate a transition diagram of the View, which is a connection between the Views.

  The VC scenario is a series of View names and Controller names generated from the View transition diagram. The VC scenario starts with the view name and ends with the view name. For example, a VC scenario is defined as View name → Controller name → View name →.

  A step represents a minimum unit of a test scenario which is a procedure for executing a test, and in the case of a Web application, it is composed of an id given to a form or button in html and proc showing an operation.

  A gene represents each element of test data, and in the case of a Web application, it is composed of an id of a form in html and a value which is a specific value.

  For example, consider an example of testing a web application in which an ID and a PW are input in View 1 and a "login" button to which an id "transmit" is assigned is pressed. In this example, one test case is composed of the combination of the following test scenario and test data.

test scenario:
VC scenario: View 1 → Controller 1 → ...
Step 1: id = "ID", proc = "input"
Step 2: id = "PW", proc = "input"
Step 3: id = "transmit", proc = "press"
...
test data:
Gene 1: id = "ID", value = "aaaa"
Gene 2: id = "PW", value = "1234"
...
That is, in this test case, (1) enter "aaaa" in the form in which id = "ID" in View 1, and (2) enter "1234" in the form in which id = "PW". , (3) id = "transmit" means pressing a button.

  The branch result is composed of branch result elements which are the result of each branch on the code when the test case is executed. For example, the branch result is defined as branch result element 1, branch result element 2,.

  The branch result element is composed of a judgment branch, a judgment order, a judgment result, and an evaluation value. The judgment branch indicates a branch to be judged, that is, which branch is judged. The determination order indicates the order in which the determination branch is determined among all the branches in the program. The determination result represents the determination result (True / False) of the determination branch. The evaluation value represents a value that quantitatively represents the determination of branching.

  The evaluation value will be described more specifically. The evaluation value represents the degree to which the branch condition is satisfied or the degree to which the branch condition is not satisfied, and can be acquired by the evaluation function set for the determination branch. For example, if there is a branch if (x> 0), the same True is returned in the case of x = 1 and in the case of x = 100, but it is more than 0 when x = 100 compared to when x = 1 Because the size is large, the degree of meeting the branching condition can be evaluated as being strong. The evaluation value has a negative value when the branch condition is satisfied, and has a positive value when the branch condition is not satisfied. The evaluation function is set for a branch, for example, if the branch condition is a == b, the evaluation function may be defined as abs (ab), if the branch condition is a! = B, evaluation The function may be defined as -abs (ab), and if the branching condition is a <b or a <= b, the evaluation function may be defined as ab, and the branching condition is a> b or a> = If b, the evaluation function may be defined as ba.

  The final branch result element indicates the branch result element having the largest value in the determination order among the branch result elements of a certain branch result. Also, a set of branch results excluding the final branch result element is defined as an intermediate branch result. The determination branch of the final branch result element, the determination order, the determination result, and the evaluation value are respectively defined as a final determination branch, a final determination order, a final determination result, and a final evaluation value.

  FIG. 1 shows an example of the branching result. Taking a branch result α consisting of three branch result elements in which the judgment branch is branch a, branch b, and branch c as an example, the final branch result element is the branch result element of branch c [c, 3, True , -2], and the halfway branch result is [a, 1, True, -1], [b, 2, False, 1] which is the branch result elements of the branch a and the branch b.

  Path matching means that, when branch result A and branch result B exist, all the branch result elements of branch result A match any of the branch result elements of branch result B except for the evaluation value, Branch result A is defined as path match for branch result B.

  Taking the branch result α, the branch result β, and the branch result γ shown in FIG. 1 as an example, the branch result elements of the branch result α coincide with any of the branch result elements of the branch result β except for the evaluation value Therefore, the branch result α matches the path with respect to the branch result β. Further, since the branch result element of the branch result α does not match any of the branch results γ except for the evaluation value, the branch result α does not match the path with the branch result γ.

  String Pool is a set of strings used to generate test data in genetic algorithm mutation. In genetic algorithm mutation, it is necessary to generate a constant at random, but it exists in String Pool by storing constant considered to be useful for solving branch in String Pool beforehand. Can be used to improve the completeness for conditional branches including the String type. For example, String Pool is defined as Pool element 1, Pool element 2.

  The Pool element is an element stored in String Pool, and is composed of a constant and a source.

  A constant is an element that stores values acquired by static analysis, dynamic analysis, or preparation.

  The source is an element indicating the place where the constant is obtained. In static analysis or dynamic analysis, a constant is obtained from a source code or byte code, so for example, "class name # method name # number of lines" represents a source. If the constant has been acquired by preparation, the source will be "prepare".

  The coverage indicates the rate at which the program source code was tested. The unit is%. There are a plurality of coverage criteria, for example, branch coverage and condition coverage exist, but in the embodiment of the present invention, branch coverage is called coverage, unless otherwise specified. A set of test data with high coverage is called exhaustive test data or highly comprehensive test data.

  FIG. 2 shows the relationship between the branch coverage rate and the condition coverage rate. Branch coverage is also called C1 coverage and indicates the percentage of branches tested in the program. For example, in a program having two branches A and B as shown in FIG. 2, in order to set C1 coverage to 100%, the case of branch A = False and branch B = True, branch A = True and branch B We need to test two things in the case of = False.

  Condition coverage is also called C2 coverage, and indicates the rate at which conditions in the program were tested. For example, in order to set C2 coverage to 100% in a program having two branches A and B as shown in FIG. 2, branch A = False and branch B = True, branch A = True and branch B. It is necessary to test four cases: = False, branch A = True and branch B = True, and branch A = False and branch B = False.

<Configuration of Test Case Generation Device>
Next, the configuration of a test case generation apparatus according to an embodiment of the present invention will be described. FIG. 3 is a functional block diagram of a test case generation apparatus 100 according to an embodiment of the present invention.

  The test case generation apparatus 100 may be a computer configured from a processor such as a central processing unit (CPU), a memory device such as a random access memory (RAM) or a read only memory (ROM), a storage device such as a hard disk. For example, the functions and processing of the test case generation apparatus may be realized by a processor executing data or a program stored in a storage device or a memory device.

  The test case generation apparatus 100 receives a source code as an input, and outputs a test case which is a combination of a test scenario and test data.

  The test case generation device 100 includes a VC scenario generation unit 101, a test scenario generation unit 103, and a test data generation unit 105. The embodiment of the present invention may be realized as a test data generation apparatus including the test data generation unit 105 without including the VC scenario generation unit 101 and the test scenario generation unit 103. For example, a test scenario generated from a process flow diagram or the like may be specified, and the test data generation apparatus may generate test data for the specified test scenario.

  The VC scenario generation unit 101 generates a View transition diagram using the information of the Controller in the source code when the program of the application designed according to MVC is to be tested. The example of the transition diagram of View is shown on the left side of FIG. A transition diagram is made up of transitions that are lines representing states and relationships between states. View in source code is considered as one state, and Controller is also considered as one state. Since the Controller conveys the input from the View to the Model and the result of execution of the Model to the View, the controller's information can be used to extract the transition diagram of the View, which is a connection between the Views. Furthermore, the VC scenario generation unit 101 generates a VC scenario representing the connection between the view and the controller based on a predetermined coverage standard for the state transition diagram from the view transition diagram. As shown on the left side of FIG. 4, when Controller1, Controller2, and Controller3 can generate a view transition diagram that is a connection of View1, View2, and View3, as shown on the right side of FIG. Multiple VC scenarios ending with the View name can be generated. Since the number of VC scenarios is huge depending on the number of states, VC scenarios are generated based on predetermined coverage criteria for the state transition diagram.

  FIG. 5 is a diagram showing coverage criteria for the state transition diagram. For example, All-states, All-transitions, All-transition-pairs, All-loop-free-paths, All-one-loop-paths, All-paths etc. exist as predetermined coverage criteria for the state transition diagram. All-states is a criterion that all states are included in some scenario. For example, taking the state transition diagram shown in FIG. 5 as an example, the scenario of state A → state B → state D → state E → state B → state C satisfies All-states. All-transitions is a criterion that scenarios of which all lengths are 1 or less (1 transition) are covered. For example, taking the state transition diagram shown in FIG. 5 as an example, the scenarios of state A → state B, state B → state C, state B → state D, state D → state E, and state E → state B are All- Meet the transitions. All-transition-pairs is a criterion that paths (transition pairs) with all lengths of 2 or less are covered. For example, taking the state transition diagram shown in FIG. 5 as an example, in addition to the scenario satisfying All-transitions, state A → state B → state C, state A → state B → state D, state B → state D → state The scenario of E, state D → state E → state B, state E → state B → state D, state E → state B → state C satisfies All-transition-pairs. The All-loop-free-paths is a criterion that all scenarios (referred to as prime paths) in which the same state does not appear twice or more and which is not partially included in other scenarios are covered. Note that All-loop-free-paths does not guarantee All-transitions. For example, taking the state transition diagram shown in FIG. 5 as an example, the scenario of state A → state B → state C, state A → state B → state D → state E satisfies All-loop-free-paths. All-one-loop-paths is a criterion that, in addition to All-loop-free-paths, a scenario in which only one loop travels only once is covered. For example, taking the state transition diagram shown in FIG. 5 as an example, the scenario of state A → state B → state C, state A → state B → state D → state E → state B → state C is All-one-loop Meet -paths. All-paths is a criterion that all scenarios are covered. Note that since there is usually a loop, there is no limit to the scenario that satisfies All-paths, so it is not useful.

  The test scenario generation unit 103 adds View operation information to the generated VC scenario. For example, view operation information that satisfies the generated VC scenario is added by a crawler or user operation. View operation information is represented by a set of steps. Specifically, by moving the program to be tested by a crawler or user operation, the test scenario generation unit 103 acquires View operation information that makes the same transition as the generated VC scenario, and acquires View operation information. Obtain initial test data, which is test data when the The test scenario generation unit 103 generates an initial test case in which View operation information and initial test data are added to the VC scenario.

  The test data generation unit 105 generates test data by designating one of the generated test scenarios. Here, first, a configuration example will be described in which test data and branch results are generated by Concolic Testing and test data and branch results obtained by Concolic Testing are used to generate new test data by SBST. The test data generation method for generating data and branching results is not limited to Concolic Testing. When a combination of Concolic Testing and SBST is used, the test data generation unit 105 has a code insertion unit 111, Concolic Testing unit 113, and SBST unit 115.

  The code insertion unit 111 inserts, into the program to be tested, a code that outputs a branch result including an evaluation value for quantitatively evaluating the determination of the branch. As described above, the code insertion unit 111 inserts a code for acquiring necessary information in advance in the SBST while executing the Concolic Testing. The code insertion unit 111 may insert a code that outputs a branch result at a branch point in the user-descripted class to be analyzed. The code insertion unit 111 may insert a code for analyzing a branch of a program into a user-descripted class to be analyzed, but a portion such as a framework or library not described is an analysis target. It is not necessary to insert code for analyzing branches of a program.

  In addition, the code insertion unit 111 inserts a code that outputs the Pool element at the location of the data type match determination of the character string of the program to be tested. As described above, the code insertion unit 111 inserts a code for acquiring a character string by dynamic analysis while executing SBST.

  The Concolic Testing unit 113 generates test data by analyzing the constraint expression obtained by replacing the input value with a symbol, and generates a branch result output from the inserted code. Thus, the Concolic Testing unit 113 collects branch results, which are information necessary for SBST, while generating test data. That is, in the process of generating test data for a specified test scenario, the Concolic Testing unit 113 adds the specified test scenario, the test data, and the branching result to the material test suite used to execute the SBST. Do. Since there is a possibility that there is a branch result matching the path in the material test suite, the Concolic Testing unit 113 tests the designated test when the coverage is improved by the test data generated for the designated test scenario. Add the scenario and the relevant test data and branch results to the output test suite.

  The SBST unit 115 uses a genetic algorithm to generate test data. The SBST unit 115 includes a selection unit 121, a crossover unit 123, and a mutation unit 125 to perform selection of genetic algorithm, crossover, and mutation, respectively. In particular, the mutation unit 125 acquires a String Pool, which is a set of character strings used to generate test data, by static analysis, dynamic analysis or preliminary preparation for a program to be tested. including. The mutation unit 125 generates new test data using a character string selected from String Pool in the String Pool unit 131 in mutation. Specifically, the SBST unit 115 generates a target branch result that matches the route halfway along the branch result generated in the Concolic Testing unit 113, and the mutation unit 125 selects the character string selected from the String Pool. Use to generate test data that satisfies the target branch result.

  In this manner, the SBST unit 115 generates a target branch result that matches the path halfway to the branch result of the output test suite, and when there is no test data that matches the path with the target branch result in the output test suite, Generate test data that satisfies the target branch result using the test suite and add it to the output test suite. Furthermore, the String Pool unit 131 of the SBST unit 115 acquires a Pool element output from the code inserted by the code insertion unit 111 in the process of generating test data that satisfies the target branch result.

  In addition, the mutation unit 125 of the SBST unit 115 selects a character string having a high relevance to a branch by considering the acquisition location of the character string acquired in the String Pool unit 131. The Pool element of the String Pool portion 131 also stores a source indicating the location where the character string has been acquired. The character string of the String Pool section 131 is, according to the source, (1) a first character string generated from a class and method to which the final judgment branch of the target branch result belongs by dynamic analysis or static analysis, (2) dynamic The second character string generated from the class to which the final decision branch of the target branch result belongs by analysis or static analysis but generated from a different method, (3) final decision of the target branch result by dynamic analysis or static analysis It is classified into a third character string generated from a class to which a branch does not belong, and (4) a fourth character string generated by preliminary preparation. In this case, it is considered that the relation with the branch is high in the order of (1) first character string, (2) second character string, (3) third character string, and (4) fourth character string. . Therefore, the mutation unit 125 sets the probability that the first character string is selected to be higher than the probability that the second character string is selected, and the probability that the second character string is selected is the third character string Is set higher than the probability that the third character string is selected, and the probability that the third character string is selected is set higher than the probability that the fourth character string is selected.

<Procedure of test case generation method>
Next, a test case generation method according to an embodiment of the present invention will be described. FIG. 6 is a flowchart of a test case generation method according to an embodiment of the present invention.

  First, in step S001, the VC scenario generation unit 101 receives the source code of the program to be tested as an input, and uses the information of the Controller in the source code to generate a transition diagram of View representing the connection between the Views.

  Step S001 will be further described with reference to FIG.

  In step S101, the VC scenario generation unit 101 receives the source code of the program to be tested as an input, and extracts the View in the source code.

  In step S102, the VC scenario generation unit 101 receives the source code of the program to be tested as an input, and detects the connection between the views using the information of the controller. Specifically, the VC scenario generation unit 101 selects one of the extracted Views as a target View, and acquires a controller of a transition destination of the View specified by the target View name. Then, the acquired transition destination View of the transition destination Controller is set as the transition destination View of the target View. By repeating the above processing for each View extracted in step S101, the view names of all transition destinations of each target View and the Controller name existing between them are output.

  In step S103, the VC scenario generation unit 101 receives, as inputs, the view names of all transition destinations of each target View and the Controller names existing therebetween, and creates a transition diagram of the View. Not only the View name but also the Controller name is recorded in the View transition diagram. If a view transition diagram is generated, the process returns to step S002 in FIG.

  Next, in step S002 of FIG. 6, the VC scenario generation unit 101 receives the transition diagram of View as an input, and generates a VC scenario for the transition diagram of View based on a predetermined coverage criterion for the state transition diagram. .

  Step S002 will be further described with reference to FIG.

  In step S104, the VC scenario generation unit 101 treats the view transition diagram as a state transition diagram, and creates a plurality of VC scenarios based on predetermined coverage criteria for the state transition diagram such as All-states. If a VC scenario is generated, the process returns to step S003 in FIG.

  Next, in step S003 in FIG. 6, the test scenario generation unit 103 receives a VC scenario as an input, and generates a test case satisfying the VC scenario for each VC scenario using a technique such as crawler. Then, test scenarios and test data for realizing the VC scenario are output as one test case (initial test case).

  Step S003 will be further described with reference to FIG.

  In step S105, the test scenario generation unit 103 receives the program to be tested and the VC scenario as input, and operates the program to be tested by the crawler etc., and accesses the html file represented by the first View of the VC scenario. Move to The operation of the program to be tested can be substituted by an operation by the user other than the crawler or the like.

  In step S106, the test scenario generation unit 103 generates an empty test case TC0. The empty test case TC0 does not contain concrete values of the test scenario VC scenario and the set of steps, and does not contain test data.

  In step S107, the test scenario generation unit 103 receives the program to be tested and the test case TC0 as an input, and the crawler or the like actually operates the program to be tested and operates the program to be tested. The id and its value are added to the test data of the test case TC0, and the input form id and the pressed button id etc. are added to the test scenario of the test case TC0. The operation of the program to be tested can be substituted by an operation by the user other than the crawler or the like. Also, it acquires the transition of View and Controller during operation and adds it to the test scenario of test case TC0. After transitioning to a new view, the process proceeds to the next step S108.

  In step S108, the test scenario generation unit 103 receives the test case TC0 and the VC scenario as inputs, and determines whether the transition of the VC scenario View and Controller and the test case TC0 make the same transition halfway or to the end. Do. If the same transition is not performed, the process proceeds to step S109. If the same transition is performed, the process proceeds to step S110.

  In step S109, test scenario generation section 103 receives test case TC0 as an input, and when the transition of the VC scenario and the transition of test case TC0 are different, test case TC0 is discarded because test case TC0 does not satisfy the VC scenario. , Shift to step S105.

  In step S110, the test scenario generation unit 103 receives the test case TC0 and the VC scenario as inputs, and determines whether the transition of the VC scenario View and Controller and the test case TC0 make the same transition to the end. If the same transition is not performed until the end, that is, the same transition is performed halfway, but the same transition is not performed until the end, it is necessary to further operate the program to be tested. Migrate to If the same transition is made, the process proceeds to step S111.

  In step S111, the test scenario generation unit 103 receives the test case TC0 as an input, and outputs the test case TC0 as an initial test case. If an initial test case is output, the process returns to step S 004 of FIG.

  Next, in step S 004 of FIG. 6, the String Pool unit 131 of the test data generation unit 105 receives the prepared constant as an input, creates a String Pool, and adds the prepared constant to the String Pool. The source at this time is "prepare".

  Step S 004 will be further described with reference to FIG.

  In step S701, the String Pool unit 131 receives the prepared constant as an input, and adds a Pool element whose source is prepared in advance to the String Pool, with the constant being a constant value and the source being prepared for each constant. If the Pool element is added to the String Pool by the preliminary preparation, the process returns to step S005 in FIG.

  Next, in step S005 in FIG. 6, the code insertion unit 111 of the test data generation unit 105 receives the byte code of the program to be tested as an input, and performs test data on the byte code on the method in the user description class. Insert code to get the information needed for generation. Note that source code may be received as input instead of byte code. In Concolic Testing, since it is necessary to replace input values with symbols and analyze the resulting constraint expression, a code is inserted to replace input values with symbols. Also, the code insertion unit 111 inserts a code for acquiring necessary information in advance in the SBST while executing the Concolic Testing. In SBST, since it is necessary to analyze the evaluation value of the branch, a code for outputting the value of the evaluation function for the branch is inserted. The code insertion unit 111 outputs the byte code inserted into the user description class. Furthermore, the code insertion unit 111 inserts code for acquiring a Pool element by dynamic analysis while executing the SBST.

  The code insertion unit 111 may receive the user-descripted class name to be analyzed as an input, and may receive the user-descripted class name not to be analyzed as an input. The user-descripted class name to be analyzed and the user-descripted class name not to be analyzed may be designated by a namespace. In this case, the code insertion unit 111 inserts a code for acquiring information necessary for test data generation into the byte code on the method in the user-descripted class to be analyzed.

  Step S005 will be further described with reference to FIG.

  In step S112, the code insertion unit 111 may receive the user-descripted class name to be analyzed input by the user as an input. In addition, the code insertion unit 111 may receive, as an input, a user-descripted class name not to be analyzed that has been input by the user. If the user-descripted class name is specified in the namespace, the code insertion unit 111 acquires the name of the class having the specified namespace by checking the bytecode. However, when there is a user class name not to be analyzed, the code insertion unit 111 excludes the user description class having the user class name not to be analyzed.

  In step S113, the code insertion unit 111 checks each field of the user-descripted class to be analyzed and each line of the byte code on the method, and inserts a code for acquiring information necessary for test data generation. The code insertion unit 111 is a code for replacing the input value with a symbol in a line and a branch line in which an operation is performed on the input value in the user description class to be analyzed in order to obtain information necessary in Concolic Testing. Insert In addition, the code insertion unit 111 inserts a code that outputs a branch result at a branch location in the user-descripted class to be analyzed, in order to acquire information necessary for SBST. Do nothing for lines that do not need to insert code on methods in user-written classes.

  In step S114, the String Pool unit 131 of the test data generation unit 105 performs static analysis on each field of the user description class to be analyzed and each line of the byte code on the method, and outputs the obtained operand or constant as a String. Add to Pool The source at this time is "class name # method name # number of lines" which is the place where the operand or constant is acquired.

  In step S115, the code insertion unit 111 checks each field of the user description class to be analyzed and each line of the byte code on the method, and determines whether or not there is a String type match determination. The match determination of the String type indicates, for example, a place where the character strings A.equals (B) are compared with each other. If there is no String type match determination, the next line is checked, and if there is a String type match determination, the process proceeds to step S116.

  In step S116, when the program to be tested is actually operated, the code insertion unit 111 adds the operands to which the characters are to be compared (for example, B in the case of A.equals (B)) and the source to the String Pool Insert code that can be done. The source at this time is "class name # method name # number of lines" which is the place where the operand is acquired. For example, if the tenth line in the fuga method of the hoge class is A.equals (B), the code insertion unit 111 sets the Pool element to be “constant: B, source: hoge # fuga # 10” to String Pool Implement code insertion so that you can add it. Do nothing for lines that do not require code insertion on fields and methods in user-written classes. If the code is inserted, the process returns to step S006 in FIG.

  Next, one test case is specified from the initial test cases, and test data is generated as follows.

  In step S006 in FIG. 6, the Concolic Testing unit 113 of the test data generation unit 105 creates an empty output test suite. The empty output test suite contains no concrete values for the test scenario VC scenario and the set of steps, and neither test data nor branch results.

  Next, in step S 007 in FIG. 6, the Concolic Testing unit 113 receives the inserted bytecode, the initial test case, and the output test suite as input, and generates test data according to the Concolic Testing based on the initial test case. And add the obtained test cases to the output test suite.

  Step S007 will be further described with reference to FIG.

  In step S114, the Concolic Testing unit 113 receives the initial test case as an input, duplicates the initial test case, and defines it as a test case TCN.

  In step S115, the Concolic Testing unit 113 receives the test case TCN and the inserted bytecode as input, and generates new test data according to Concolic Testing. With Concolic Testing, it is necessary to actually execute the test case TCN, but since the test case TCN contains test scenarios including View operation information and concrete test data, create a script and create a script. It is possible to automatically execute Concolic Testing by using Selenium or the like which is a tool to be executed. In addition, since the code inserting unit 111 inserts a code for outputting a branch result which is information necessary for the SBST, the Concolic Testing unit 113 can acquire the branch result together with the test data.

  In step S116, the Concolic Testing unit 113 receives the generated test data and the initial test case as input, replaces the generated test data with the test data in the initial test case, and outputs a new test case TCN.

  In step S117, the Concolic Testing unit 113 receives the test case TCN, the branch result and the material test suite as inputs, and adds the test case TCN and the branch result to the material test suite.

  In step S118, the Concolic Testing unit 113 receives the test case TCN and the output test suite as inputs, and determines whether the coverage is improved by adding the test case TCN to the output test suite. If the coverage is improved, the process proceeds to step S119. If the coverage is not improved, the process proceeds to step S120.

  In step S119, the Concolic Testing unit 113 receives the test case TCN, the branch result and the output test case as inputs, and adds the test case TCN and the branch result to the output test suite.

  In step S120, if the analysis has not been completed, the Concolic Testing unit 113 proceeds to step S115 and repeats the generation of test data. If the analysis is completed, the process returns to step S008 in FIG.

  Next, in step S008 in FIG. 6, the SBST unit 115 of the test data generation unit 105 inputs the byte code, the output test suite, and the material test suite into which the code for outputting the branch result, which is information necessary in SBST, is inserted. Receive as. The SBST unit 115 executes SBST to analyze the program to be tested actually by using each gene of test data as input to the byte code into which code is inserted, and the test data generated by the Concolic Testing unit 113 passes Generate test data that passes through branches that can not be made. The SBST unit 115 strengthens the output test suite by adding test data to improve the coverage in this manner to the output test suite. The test data used in the SBST unit 115 is selected from the material test suite.

  Step S008 will be further described with reference to FIG.

  In step S201, the SBST unit 115 sets the number of branch result elements of the branch result BR0 to n for each branch result BR0 of the output test suite.

  In step S202, the SBST unit 115 receives the branch result BR0 as an input, and creates a new branch result BR in which all branch result elements whose judgment order value is larger than n are deleted from the branch result BR0.

  In step S203, the SBST unit 115 receives the branch result BR as an input, creates a new branch result obtained by inverting the final determination result for the branch result BR, and uses it as a target branch result. For example, when the final determination result of the branch result BR is True, the final determination result is False, and when the final determination result of the branch result BR is False, the final determination result is True.

  In step S204, the SBST unit 115 determines whether there is a branch result matching the target branch result in the output test suite. As described with reference to FIG. 1, the evaluation values may be different here to determine the path match of the branch result. If there is no branch result matching the target branch result in the output test suite, the process proceeds to step S205, and if there is, the process proceeds to step S206.

  In step S205, the SBST unit 115 receives the material test suite and the target branch result as inputs, and generates test data that satisfies the target branch result by SBST.

  Step S205 will be further described with reference to FIG.

  In step S301, a maximum generation number when executing SBST using a genetic algorithm is G, and a current generation g is 1.

  In step S302, the SBST unit 115 receives the material test suite and the target branch result as inputs, and sorts each branch result of the material test suite by the evaluation value of the branch result element having the final determination branch of the target branch result. For example, if the final judgment branch of the target branch result is True, it is judged that the smaller the evaluation value is, the better. If the final judgment branch of the target branch result is False, the larger the evaluation value is, the better. It is determined that However, it is judged that the branch result having no final judgment branch of the target branch result is not the best. The SBST unit 115 arranges and sorts the branch results judged to be excellent and the corresponding test cases in order from the top.

  In step S303, the SBST unit 115 generates an empty test suite TS. The empty test suite TS does not contain the concrete values of the test cases and does not contain the branching results.

  In step S304, the selection unit 121 of the SBST unit 115 receives the sorted material test suite and the test suite TS as inputs, and selects a plurality of test cases in order from the top of the sorted material test suite. The number of test cases to be selected is a predetermined constant. The selection unit 121 generates a test case in which the gene of the selected test case is manipulated. For example, the selection unit 121 may randomly add 1 or subtract 1 to one gene included in the selected test case if it is int type. For example, the selection unit 121 may randomly add one character or delete one character for a single gene included in the selected test case in the case of the String type. By performing this operation on all the genes, the selection unit 121 generates test cases that are as new as the number of genes for one test case, and adds new test cases to the test suite TS.

  In step S305, the crossover section 123 of the SBST unit 115 receives the sorted material test suite and the test suite TS as inputs, and selects a plurality of test cases in order from the top of the sorted material test suite. The number of test cases to be selected is a predetermined constant. The crossover portion 123 generates a new test case including the selected test case gene. For example, the crossover 123 randomly extracts two test cases from the selected test cases, and generates a new test case in which the genes possessed by the two test cases are randomly blended. The crossover section 123 repeats this operation to generate a predetermined number of new test cases and add new test cases to the test suite TS.

  Step S305 will be further described with reference to FIG.

  In step S401, the crossover section 123 receives the sorted material test suite as an input, and extracts a plurality of test cases in order from the top of the sorted material test suite.

  In step S402, the crossover section 123 receives the extracted test case group as an input, randomly extracts two test cases from the test case group, and generates a new test case in which respective genes are randomly blended. For example, the crossover 123 extracts the test case A and the test case B from the test case group. Here, since the test scenarios of test case A and test case B are the same, test case A and test case B each possess a gene having the same id. The crossover section 123 creates a new test case by randomly extracting a gene from the test case A and the test case B for each id. For example, the gene of test case A is [[id = 1, value = 0], [id = 2, value = 1]], and the gene of test case B is [[id = 1, value = 10], [ Assuming that id = 2, value = 5]], [[id = 1, value = 0], [id = 2, value = 1]], [[id = 1, value = 0], [id = 2, value = 5]], [[id = 1, value = 10], [id = 2, value = 1]], [[id = 1, value = 10], [id = 2, value = 5] ] Can be generated.

  In step S403, the crossover section 123 receives the created test case and test suite TS as inputs, and adds the created test case to the test suite TS.

  In step S404, the crossover section 123 determines whether or not a predetermined number of new test cases have been created. If not, the process returns to step S402 and repeats the above process. If a fixed number of new test cases are created, the process returns to step S306 in FIG.

  Next, in step S306 of FIG. 14, the mutation unit 125 of the SBST unit 115 receives the sorted material test suite and the test suite TS as inputs, and a plurality of tests are sequentially performed from the top of the sorted material test suite. Choose a case. The number of test cases to be selected is a predetermined constant. The mutation unit 125 generates a new test case in which the gene of the selected test case is mutated. For example, the mutation unit 125 gives a new value with a certain probability to one gene of the selected test case, and gives a value quoted from the String Pool with a certain probability, thereby giving a new test case. Generate This operation is performed on all the genes, and as many test cases as the number of genes are generated for one test case. The mutation unit 125 generates a plurality of new test cases by mutation, and adds the new test cases to the test suite TS.

  Step S306 will be further described with reference to FIG.

  In step S601, the mutation unit 125 receives the sorted material test suite as an input, and extracts a plurality of test cases in order from the top of the sorted material test suite.

  In step S602, the mutation unit 125 receives the extracted test case as an input, and for each gene of each test data of the test case, the value of the value of the gene is obtained at a constant probability by either of two types of operation change. One of the two types of operations is an operation that changes the value of value to a random value. For example, the mutation unit 125 changes value = "aaa" of the gene to value = "hoge" with a certain probability. The value to be changed may be any value. The other of the two types of operations is an operation that substitutes the value of value using a constant in String Pool.

  Step S602 will be further described with reference to FIG.

  In step S702, the mutation unit 125 moves randomly to step S703 or step S704.

  In step S703, the mutation unit 125 receives the extracted test case as an input, and changes the value of the value of the gene to a random value with a certain probability for each gene of each test data of the test case. For example, the mutation unit 125 changes value = "aaa" of the gene to value = "hoge" with a certain probability. The value to be changed may be any value. Also, the remaining probability does not change the gene. The probability is a predetermined constant.

  In step S704, the mutation unit 125 creates an empty String Pool (1), an empty String Pool (2), an empty String Pool (3), and an empty String Pool (4).

  In step S 705, the mutation unit 125 receives String Pool as an input, and determines whether the source of each Pool element of String Pool is “prepare”. If the source is "preparing", the process proceeds to step S706, and if the source is not "preparing", the process proceeds to step S707.

  In step S706, the mutation unit 125 receives String Pool and String Pool (4) as inputs, and adds each Pool element whose source is "pre-prepared" to String Pool (4).

  In step S 707, mutation section 125 receives String Pool and the target branch result as input, and whether or not the class to which the final determination branch of the target branch result belongs matches the class name of the source of each Pool element of String Pool To judge. If they do not match, the process proceeds to step S708, and if they match, the process proceeds to step S709.

  In step S 708, mutation section 125 receives String Pool and String Pool (3) as input, and determines the respective Pool elements for which the class to which the final determination branch of the target branch result belongs does not match the source class name String Pool (3) Add to

  In step S 709, mutation section 125 receives String Pool and the target branch result as input, and whether or not the method to which the final determination branch of the target branch result belongs matches the method name of the source of each Pool element of String Pool To judge. If they do not match, the process proceeds to step S710. If they match, the process proceeds to step S711.

  In step S710, mutation section 125 receives String Pool and String Pool (2) as input, and the class to which the final determination branch of the target branch result belongs matches the class name of the source, but the final determination branch of the target branch result Add each Pool element to String Pool (2) that the method to which does not match the source method name.

  In step S711, mutation section 125 receives String Pool and String Pool (1) as input, the class to which the final determination branch of the target branch result belongs matches the class name of the source, and the final determination of the target branch result Add each Pool element to String Pool (1) where the method to which the branch belongs matches the source method name.

  In step S712, the mutation unit 125 receives String Pool (1), String Pool (2), String Pool (3), and String Pool (4) as inputs, and String Pool (1), String Pool (2), Select one from String Pool (3) and String Pool (4).

  In step S713, the mutation unit 125 receives the extracted test case and the selected String Pool as inputs, and selects one Pool element from the selected String Pool for each gene of each test data of the test case, Assign the constant of Pool element to the value of gene. The probability of selecting String Pool is set to be String Pool (1)> String Pool (2)> String Pool (3)> String Pool (4), so the final judgment branch of the target branch result is taken. There is a high probability that a Pool element having a value close to the number of rows of will be selected. The correlation between the number of rows and the probability is set in advance.

  If the gene is manipulated by mutation, the process returns to step S603 in FIG.

  In step S603, the mutation unit 125 receives the genetically manipulated test case and the test suite TS as inputs, and adds the genetically engineered test case to the test suite TS. If a genetically manipulated test case is added to the test suite TS, the process returns to step S307 in FIG.

  Next, for each test case of the test suite TS, an output test suite is generated as follows.

  In step S307 in FIG. 14, the SBST unit 115 receives the test case in the test suite TS as an input, and causes the program to be tested to execute the test case in the test suite TS. Since the code insertion unit 111 inserts the code that outputs the branch result, the corresponding branch result can be acquired for the test case.

  In step S308, the String Pool unit 131 of the SBST unit 115 receives the test case in the test suite TS as an input, and causes the program to be tested to execute the test case in the test suite TS. Since the code insertion unit 111 inserts a code for outputting a Pool element at the location of the String type match determination, the corresponding Pool element can be acquired for the test case. The String Pool unit 131 of the SBST unit 115 adds an operand to be compared with a character string and a source to the String Pool when there is a String type match determination. Step S308 may be performed simultaneously with step S307.

  In step S309, the SBST unit 115 receives the test case in the test suite TS, the corresponding branch result, and the material test suite as inputs, and adds the test case and the corresponding branch result to the material test suite.

  In step S310, the SBST unit 115 receives the test case in the test suite TS, the corresponding branch result, and the output test suite as inputs, and the path result matches the path result obtained by the SBST unit 115 executing the test case. It is determined whether or not the result of branching is present in the output test suite. If it does not exist, the process proceeds to step S311. If it does exist, the process returns to step S307, the process for the next test case is performed, and if the process for all test cases is completed, the process proceeds to step S313.

  In step S311, the SBST unit 115 receives the test case in the test suite TS, the corresponding branch result, and the output test suite as inputs, and adds the test case and the corresponding branch result to the output test suite.

  In step S312, the SBST unit 115 determines whether the branch result obtained by the SBST unit 115 executing the test case matches the route with the target branch result. If the routes do not match, the process proceeds to step S313. If the routes match, the process returns to step S206 in FIG.

  In step S313, g = g + 1, and in step S314, the process returns to step S302 until g reaches the maximum generation number G, and the above process is repeated. If g has reached the maximum number of generations, the process returns to step S206 in FIG.

  Next, in step S206 in FIG. 13, n = n−1, and in step S207, the process returns to step S202 until n becomes 0, and the above process is repeated. If n becomes 0, the process returns to step S201, the process for the next branch result is performed, and when the process for all the branch results is completed, the process returns to step S009 in FIG.

  Next, in step S009 in FIG. 6, the test data generation unit 105 outputs all test cases in the output test suite to a file or the like.

According to the above procedure, the test case generation device 100 can output a test case which is a combination of a test scenario and test data.
<The effect of the embodiment of the present invention>
According to an embodiment of the present invention, given a test scenario, it is possible to efficiently generate a comprehensive set of test data for a branch including a data type of a character string.

  In particular, in mutation of genetic algorithm which is one of search algorithm of SBST, character strings are conventionally generated at random, but the character string considered to be useful for solving a branch is saved as String Pool By storing in a place, it is possible to improve the completeness to conditional branches including the String type by using a string existing in String Pool in mutation.

  In addition, since the acquisition location of the String Pool string is managed as a source, there is a high possibility that a string highly relevant to the branch to be solved will be selected from the String Pool.

  Also, by combining two methods with different properties of Concolic Testing and SBST, test data with higher coverage can be generated. However, if two methods are executed in order, it takes a considerable amount of time to generate test data, so by acquiring necessary information in SBST beforehand while executing Concolic Testing, the efficiency of the test data in SBST can be increased. Search is possible. As a result, the ability to detect bugs due to structural defects in the program is improved.

  Also, by generating a test scenario from the view transition diagram, it is possible to automatically generate an exhaustive test case for screen transition in the Web application. Since the View in the Web application has a granularity very close to the screen, extracting the test scenario using the predetermined coverage criteria for the state transition diagram with respect to the transition diagram of the View makes it close to the granularity of the screen transition and It is possible to automatically generate a comprehensive test scenario for screen transition.

  Furthermore, when test data is generated by Concolic Testing or SBST, computational explosion can be avoided by not analyzing branches to locations not described by the user, such as frameworks and libraries, and thus combining Test level test cases can also be generated. Do not generate test cases that improve coverage for areas not described by users such as frameworks and libraries, but instead, use computational resources to generate test cases with high coverage for the user description class to be analyzed It can be assigned.

  Although the test case generation apparatus according to the embodiment of the present invention is described using a functional block diagram for convenience of explanation, the test case generation apparatus according to the embodiment of the present invention may be hardware, software, or theirs. It may be realized in combination. For example, an embodiment of the present invention is a program that causes a computer to realize each function of a test case generation device according to an embodiment of the present invention, and each procedure of a test case generation method according to an embodiment of the present invention for a computer May be realized by a program or the like that executes. Also, each functional unit may be used in combination as needed. In addition, the test case generation method according to the embodiment of the present invention may be performed in an order different from the order shown in the embodiment.

  The above describes the method for efficiently generating a comprehensive test data set for a branch including a data type of a string when given a test scenario. Various modifications and applications are possible within the scope of the claims, without being limited to the embodiments of the invention.

100 test case generation apparatus 101 VC scenario generation unit 103 test scenario generation unit 105 test data generation unit 111 code insertion unit 113 concolic testing unit 115 SBST unit 121 selection unit 123 crossover unit 125 mutation unit 131 String Pool unit

Claims (7)

A test data generation program for generating test data for a specified test scenario, the computer comprising:
A character string set acquisition function for acquiring a set of character strings used to generate test data;
A code insertion function for inserting into the program to be tested a code that outputs a branch result including an evaluation value for quantitatively evaluating the determination of the branch;
A first test data generation function of generating test data for a specified test scenario and generating a branch result output from the inserted code;
A target branch result that matches the path halfway to the generated branch result is generated, and a character string selected from among the acquired character string set is used in a genetic algorithm, and the target branch result is generated. A second test data generation function for generating test data to be satisfied;
Test data generator for realizing.   The test data generation program according to claim 1, wherein the string collection acquisition function acquires the collection of strings by static analysis, dynamic analysis or preliminary preparation.   The second test data generation function includes a first character string generated from a class and method to which the final decision branch of the target branch result belongs by dynamic analysis or static analysis, and by the dynamic analysis or static analysis From the second character string generated from the class to which the final judgment branch of the target branch result belongs but generated from a different method, and from the class to which the final judgment branch of the target branch result does not belong by dynamic analysis or static analysis 3. The method according to claim 2, wherein one string is selected from the generated third string and the fourth string generated by the preparation, and test data satisfying the target branch result is generated. Test data generator.   The second test data generation function sets the probability that the first character string is selected to be higher than the probability that the second character string is selected, and the probability that the second character string is selected The method according to claim 3, wherein the third character string is set to be higher than the probability that the third character string is selected, and the probability that the third character string is selected is set to be higher than the probability that the fourth character string is selected. Test data generator. The code insertion function inserts a code for outputting a character string at a position where the data type of the character string of the program to be tested matches.
The character string set acquisition function according to any one of claims 1 to 4, wherein, in the process of generating test data satisfying the target branch result, the character string outputted by the inserted code is acquired. Test data generator. If the program to be tested consists of at least View and Controller,
On the computer
A VC scenario generation function of generating a transition diagram of a view using controller information, and generating a VC scenario representing a connection between the view and the controller based on a predetermined coverage criterion for the state transition diagram from the view transition diagram;
A test scenario generation function of generating a test scenario in which View operation information is added to the generated VC scenario;
To realize
The test data generation program according to any one of claims 1 to 5, wherein the specified test scenario is selected from the test scenario generated by the test scenario generation function. A test data generation method in a test data generation apparatus for generating test data for a specified test scenario, comprising:
The test data generation device acquiring a set of character strings used for generation of test data;
Inserting, in the program to be tested, a code that outputs a branch result including an evaluation value for quantitatively evaluating the determination of a branch, into the program to be tested;
The test data generator generating test data for a specified test scenario and generating a branch result output from the inserted code;
The test data generation device generates a target branch result that matches the path halfway to the generated branch result, and uses a character string selected from the acquired character string set in a genetic algorithm Generating test data satisfying the target branch result;
A test data generation method having:

Images