JP6268029B2 - Test case generation apparatus and test case generation method - Google Patents

Description

  The present invention relates to a test case generation apparatus and a test case generation method, and more specifically, a test that satisfies appropriate coverage in consideration of both an execution path base and an input / output base from a software specification related to a processing flow. The present invention relates to a technique that enables efficient generation of cases.

  In software development, customer requirements are summarized as a requirement definition, and necessary functions are designed and detailed based on the requirement definition and implemented. The software test developed in this way is a process for confirming whether the implementation is performed as specified, and is an important process for ensuring the quality of the software.

  Among the confirmation items in the above-described test process, a test that pays particular attention to the function of software is called a function test. In addition to the tests related to these functions, for example, there are a performance test and a load test for confirming the processing performance.

  In performing the function test, attention is paid to design information such as a flow of processing in software and constraints between input data, and it is confirmed whether the installed software operates as expected. At that time, when it is difficult to confirm all of the processing flow that can be taken by the function or all possible combinations of input data, a coverage standard is set and a test is performed to satisfy the coverage.

  Among such coverage standards, implementation code-based coverage standards include execution path coverage (C0 coverage) in which each execution statement is executed at least once, conditional branching, and at least each branch in each conditional branch. Conditional coverage (C1 coverage) for performing a test so as to pass once is known.

In addition, when a design document such as a state transition diagram is used as a base, the design information includes the transition path coverage that tests each state transition so that it passes at least once, or a combination of values that the input data can take. When given, various coverage criteria are known, such as n-wise coverage, in which attention is paid to possible combinations and a test is performed so that at least N combinations appear once.

Among these coverage standards, the above-mentioned test is performed by adopting the coverage standard in accordance with the description content of the design document created with software development or the development standard. Conventionally, the following techniques have been proposed as test case generation techniques for such software testing. In other words, based on a UML (Unified Modeling Language) sequence diagram, an OCL (Object Constraint Language) representation of the class diagram related to the sequence diagram is given, and the execution path extracted from the sequence diagram and the OCL of the class diagram A method of automatically generating test cases by evaluating coverage criteria for both execution path base and input / output base based on pre- and post-conditions given from expressions (see Non-Patent Document 1). Here, the execution path-based coverage standard is a coverage standard that focuses on the flow of processing and evaluates the coverage of execution statements and branch conditions, and the input / output-based coverage standard is an input, output, Alternatively, it is a coverage criterion for evaluating coverage with respect to possible combinations from input / output correspondences. The former is mainly used to evaluate the coverage of the white box test, and the latter is mainly used to evaluate the coverage of the black box test. For example, the above-described C0 coverage and C1 coverage are execution path-based, and n-wise coverage is an input / output-based coverage standard.

Li Bao-Lin, Li Zhi-shu, Li Qing, Chen Yan Hong, "Test case auto generation and encouraging enumeration ensemble co-expression", 2007 Int. 1048-1052, 2007.

  In the above-described conventional technology, a test case for performing a function test is automatically generated based on a UML sequence diagram and a class diagram. Further, in the automatic generation, it is possible to generate a test case considering the coverage of both the execution path and the input / output. However, it is necessary to design in advance both specifications (sequence diagram) indicating the flow of processing and pre- and post-conditions related to the sequence diagram by OCL expression of the sequence diagram and the class diagram. In addition, the specification showing the flow of processing is a sequence diagram, and the description of pre-conditions and post-conditions is premised on OCL (Object Constraint Language). Therefore, there are many items that should be designed and defined in advance when generating a test case, the applicability tends to be limited, the number of processes increases, and the development efficiency cannot be said to be good.

  Accordingly, an object of the present invention is to provide a technique that can efficiently generate a test case satisfying appropriate coverage in consideration of both an execution path base and an input / output base from a software specification related to a processing flow.

The test case generation apparatus of the present invention that solves the above-described problem is a condition item indicating a branch condition in the flow among the specification information relating to the flow of processing in software, the information on the coverage criteria of the test case, and the specification information And specifying each notation of the result item indicating the execution contents other than the condition item, an extraction rule for extracting the condition item and the result item and the item value from each notation, and the specification corresponding to the specification information a start condition and end condition in the execution path, a storage device for storing the extracted rule information, a containing, by the extraction rules in the extraction rule information, from the specification information, and the condition items, and the result item, Condition result item extraction that extracts the condition item and the item values that can be taken by the result item as condition result items and stores them in a storage device Execution and management, from the specification information, appropriate for the extracts each execution path in the specification, the basis of the specification information and the start condition of the shown extraction rule information, depending on the starting point specified in the flow Based on the execution path extraction process for starting path extraction and extracting up to the end point specified according to the end condition in the flow as one execution path , the condition result item and the item value, A rule that is a pattern of item value combinations of item values and corresponding item values of the result item is generated, and a correspondence relationship between the processing content indicated by each rule and the execution path is specified, and the rule and the execution path A condition result correspondence table generating process for generating a condition result correspondence table indicating the correspondence relationship between the rule and the execution path corresponding to the condition indicated by the information on the coverage criterion, A test case generation process for searching a condition result correspondence table, and generating a test case by a predetermined generation algorithm based on the searched rule or execution path and the specification information. Features.

In addition, the test case generation method of the present invention includes specification information relating to a process flow in software, coverage standard information of a test case, and condition items indicating branch conditions in the flow of the specification information and the conditions An extraction rule that identifies each notation of the result item indicating the execution content other than the item, extracts the condition item, the result item, and the item value from each notation, and an execution path in the specification corresponding to the specification information computer including a start condition and end condition, the extraction rule information including a storage device for storing a found by the extraction rules in the extraction rule information in, from the specification information, and the condition items, and the result item, A condition result for extracting the item value that can be taken by each of the condition item and the result item as a condition result item and storing it in a storage device Eye extraction processing, from the specification information, when extracts each execution path in the corresponding specifications, based on the said start condition indicated by the extracted rule information and the specification information, depending on the starting point specified in the flow Execution path extraction, based on the execution path extraction process for extracting up to the end point specified according to the end condition in the flow as one execution path , the condition result item and the item value, A rule which is a combination of item values of each condition item and a corresponding item value pattern of the result item is generated, the correspondence between the processing content indicated by each rule and the execution path is specified, and the rule and the rule A condition result correspondence table generating process for generating a condition result correspondence table indicating a correspondence relationship with the execution path and storing it in the storage device, and a rule or an execution path corresponding to the condition indicated by the information of the coverage criterion. And a test case generation process for generating a test case by a predetermined generation algorithm based on the searched rule or execution path and the specification information. .

  According to the present invention, it is possible to efficiently generate a test case satisfying appropriate coverage in consideration of both the execution path base and the input / output base from the software specifications related to the processing flow.

It is a figure which shows the hardware structural example of the test case production | generation apparatus in a 1st Example. It is a figure which shows the structure of the test case production | generation apparatus in a 1st Example. It is a figure which shows the flow of the whole process of the test case production | generation method in a 1st Example. It is a figure which shows the outline | summary of the test case production | generation process in a 1st Example. It is a figure which shows the example of the coverage reference | standard list in a 1st Example. It is a figure which shows the example of a specification regarding the flow of the process in a 1st Example. It is a figure which shows the outline | summary of the process for extracting a condition result item in a 1st and 2nd Example. It is a figure which shows the condition result item of the example of a specification in a 1st Example. It is a figure which shows the example of the execution path extracted of the example of a specification in a 1st Example. It is a figure which shows the example of the rule list in a 1st Example. It is a figure which shows an example of the conditions result corresponding table produced | generated based on the rule produced | generated from the example of a specification in a 1st Example, and a production | generation test case. It is a figure which shows the example of a specification regarding the flow of the process in a 2nd Example. It is a figure which shows the example of a condition result item in a 2nd Example. It is a figure which shows an example of the extraction rule for extracting an execution path from the example of a specification in a 2nd Example. It is a figure which shows the supplementary rule list | wrist in a 2nd Example. It is a figure which shows the outline | summary of the process for extracting an execution path in a 1st and 2nd Example. It is a figure which shows the example of the execution path extracted of the example of a specification in a 2nd Example. It is a figure which shows the example of the rule list in a 2nd Example. It is a figure which shows an example of the condition result corresponding table produced | generated based on the rule produced | generated from the example of a specification in a 2nd Example, and a production | generation test case.

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a diagram illustrating a hardware configuration example that implements the test case generation apparatus 100 according to the first embodiment. The test case generation device 100 includes a CPU (Central Processor Unit) 201 that is an arithmetic device, a RAM (Random Access Memory) 202 that includes a volatile storage device, an SSD (Solid State Drive), a hard disk drive, and other appropriate nonvolatile storage devices. An external storage device 203 constituted by the interface, an interface 204 as an internal path connecting the components 201 to 206 of the test case generation device 100, a display device 205 such as a display for displaying processing data, and a key input from a user An input device 206 that receives voice input is provided. In the external storage device 203, in addition to the program 210 for implementing functions necessary as the test case generation device 100 of the present embodiment, storage areas of storage units 111 to 117 described later are secured.

  In addition, the CPU 201 described above executes the program 210 held in the external storage device 203 by reading it into the RAM 202 to perform overall control of the device itself and perform various determinations, calculations, and control processes. By executing the program 210 loaded on the RAM 202 in this way, functional units described later, that is, a description format verification unit 101, a specification input unit 102, a condition result item extraction unit 107, a condition result item correction unit 103, a test specification generation Each processing unit of the unit 104, the test specification registration unit 105, the execution path extraction unit 108, the test case generation unit 109, and the condition result correspondence table generation unit 110 is embodied as a process.

  Next, each function provided in the test case generation device 100 having such a hardware configuration will be described with reference to FIG. FIG. 2 is a diagram illustrating a configuration example of the test case generation device 100 in the first embodiment. A test case generation apparatus 100 shown in FIG. 2 is a computer apparatus that can efficiently generate a test case that satisfies appropriate coverage in consideration of both an execution path base and an input / output base from a software specification related to a processing flow. is there.

  As described above, the test case generation device 100 includes the following functional units that are implemented by loading the program 210 provided in the external storage device 203 into the RAM 202 and executing it. That is, description format verification unit 101, specification input unit 102, condition result item correction unit 103, test specification generation unit 104, test specification registration unit 105, result item extraction unit 107, execution path extraction unit 108, test case generation unit 109, And each processing unit of the condition result correspondence generation unit 110.

  Of the above-described functional units, the specification input unit 102 has a function of accepting user input of specifications related to the processing flow of software to be generated as a test case from the input device 206 and storing it in the specification storage unit 111 of the external storage device 203. Fulfill. The description format verification unit 101 also has a function of verifying whether the specification description format related to the above-described processing flow input by the input device 206 is based on a predetermined desired format and grammar.

  In addition, the condition result item extraction unit 107 indicates a condition item indicating a branch condition in the flow and an execution content other than the condition item based on the specification related to the flow of processing input by the input device 206 as described above. The result item and the item value that can be taken by each of the condition item and the result item are extracted as the condition result item, and the function is stored in the condition result item storage unit 112. In addition, the condition result item correction unit 103 has a function of accepting user input by the input device 206 and correcting the condition result item extracted by the condition result item extraction unit 107.

  In addition, the execution path extraction unit 108 generates a test case from the condition result items stored in the above-described condition result item storage unit 112 and the specifications related to the above-described processing flow stored in the specification storage unit 111. The function of extracting the execution path for this purpose and storing it in the execution path storage unit 113 is achieved.

  The test case generation unit 115 also includes a specification indicating the flow of processing stored in the specification storage unit 111, a condition result item stored in the condition result item storage unit 112, and an execution path storage unit 113. The execution path stored therein is received, and a test case that satisfies the user-specified coverage criteria among the coverage criteria stored in the coverage criteria storage unit 115 is generated. The coverage reference storage unit 115 stores a test case generation by the test case generation unit 109 and a coverage evaluation method for evaluating the coverage of the generated test case.

  The test specification generation unit 104 performs a function of outputting the generated test case to a screen or paper, and the test specification registration unit 105 stores the generated test case in the test case storage unit 114. Fulfill.

  The actual procedure of the test case generation method in the first embodiment will be described below with reference to the drawings. Various operations corresponding to the test case generation method described below are realized by a program 210 that the test case generation apparatus 100 reads into the RAM 202 and executes. And this program 210 is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

  FIG. 3 is a flowchart showing an example of the entire process of the test case generation method in the first embodiment. Here, first, the processing flow of the test case generation method will be described using the outline of the processing flow shown in FIG.

  First, in step 300, the specification input unit 102 of the test case generation apparatus 100 receives a specification related to the flow of processing as a user input 310 via the input device 206 and stores it in the specification storage unit 111. When accepting the user input 310, the description format verification unit 101 stores a template in advance in the external storage device 203 of the test case generation device 100 (not shown) although the specification input by the user and a predetermined description format or grammar (not shown). May be accepted to verify that the specification conforms to the description format or grammar described above, and only specifications that satisfy the specified description format may be accepted.

  In addition, the specification accepted above is that dedicated software for creating a specification, office software, etc. are provided to the user by the input device 206 and the output device 205, the creation operation is accepted via these software, and the result is accepted. Alternatively, data created using these software may be accepted as the user input 310.

  Next, in step 302, the condition result item extraction unit 107 of the test case generation device 100 extracts the condition item and the result item from the specifications related to the flow of processing input by the user in step 301 described above.

  In step 303, the input / output correction unit 103 of the test case generation apparatus 100 performs the condition extracted from the above-described specification in response to the user input 311 for the condition item and the result item extracted in the above-described step 302. Modify items and result items and set default values for result items. Further, the input / output correction unit 103 could not be extracted from the description in the specification in the above-described step 302, but it is clear that the item value of the condition result item that is clearly present in the design or does not exist in advance in the design. Accept user input for a certain combination of inputs. The input / output correction unit 103 accepts a predetermined value when the user sets in advance when the extracted result item is indefinite on the execution path in the “execution path extraction” in the next step 304.

  By such processing in step 303, in the test case generation processing in step 307 described later, the combination of condition items that can be taken at the time of test case generation is clarified, the result items are clarified so that expected results are not indefinite, or By clarifying combinations of condition items that cannot be generated in advance, it is possible to prevent generation of unnecessary test cases. However, the step 303 can be omitted.

Next, in step 304, the execution path extraction unit 108 of the test case generation device 100 stores the specifications related to the above-described processing flow stored in the specification storage unit 111 and the conditions in the condition result item storage unit 112. Using the result items, all execution paths that can be taken from the specifications relating to the flow of processing are extracted, and the extraction results are stored in the execution path storage unit 113.

  In step 305, the condition result correspondence table creation unit 110 of the test case generation apparatus 100 includes specifications relating to the processing flow in the specification storage unit 111, condition result items in the condition result item storage unit 112, and From the execution path in the execution path storage unit 113, a correspondence table including combinations of item values of condition items and corresponding expected results is created for each execution path.

  Subsequently, in step 306, the test case generation unit 110 of the test case generation apparatus 100 accepts the user input 312 and specifies a user desired coverage criterion indicated by the user input 312 from the coverage criterion stored in the coverage criterion storage unit 115. To do. This coverage standard is a standard to be satisfied by the test case generated in the test case generation process in step 307.

Here, the test case generation processing in step 307 will be described with reference to FIG. In the test case generation process of step 307, the following process is performed based on the coverage standard described in the coverage standard list 410 (held in the coverage standard storage unit 115) shown in FIG. Generate test cases that meet the coverage criteria. A coverage criterion list 410 illustrated in FIG. 5 is a coverage identifier (ID column) 411 for uniquely identifying a coverage criterion, and coverage indicating whether the coverage criterion is evaluated on an execution path basis or an input / output basis. Type (type field) 412, coverage name (name (abbreviation) field) 413 for storing the name of the coverage standard, coverage generation process name (generation field) 414 for describing a processing program for generating a test case that satisfies the coverage standard , A coverage evaluation process name (evaluation column) 415 describing a program for coverage evaluation for evaluating the coverage, and a coverage summary (summary column) 416 explaining an overview of the coverage.
In this case, the test case generation unit 109 of the test case generation apparatus 100 starts processing in step 401, confirms the type of the generation parameter (coverage criterion) input from the user input 312 in step 402, and executes the execution path base. It is judged whether it is the coverage standard of. If it is an execution path based case (402: Yes), the test case generation unit 109 advances the process to Step 403, and if not (402: No), advances the process to Step 404.

  Next, in step 403, the test case generation unit 109 refers to the coverage generation process name field 413 of the above-described coverage standard list 410, and stores the specifications stored in the specification storage unit 111 and the execution path storage unit 113. A test case is generated using the execution path stored in. In step 404, the test case generation unit 109 refers to the coverage generation process name field 413 of the above-described coverage standard list 410, and stores the specifications stored in the specification storage unit 11 and the condition result item storage unit 112. , And generate a test case.

  Subsequently, in step 405, the test case generation unit 109 refers to a condition result correspondence table (stored in the condition result correspondence table storage unit 116) described later for details, and the test case generated in step 403 or step 404 described above. Remove duplicate test cases from

  Next, in step 406, the test case generation unit 109 evaluates the coverage of the test case generated up to the above, and if the coverage criterion is satisfied (406: Yes), the process proceeds to step 407. End the flow. On the other hand, when the coverage standard is not satisfied (406: No), the test case generation unit 109 returns the process to Step 402.

  Next, more specific contents of the condition result item extraction and test case generation described with reference to FIGS. 3 and 4 will be described with reference to the specification relating to the processing flow shown in FIG. FIG. 6 is a diagram illustrating an example of the specification 160 related to the flow of processing in the first embodiment. First, the flowchart 160 shown in FIG. 6, that is, the specification of the flow of processing will be described. This flowchart 160 is assumed to be input by the user input 310 and stored in the specification storage unit 111 in the specification input reception (FIG. 3) in step 301.

  In this flowchart 160, for example, the flow of processing when data is normally received (step 501 to step 508) starts processing in step 500, calls the data reception processing in step 502, and the above-described step 502 in step 503. It is determined whether or not the data reception process has exceeded the timeout time of 60 seconds. If it has exceeded, the process proceeds to step 508; In step 504, the received data check process is called, and the process proceeds to step 505. Next, in step 505, if the reception data state is normal as a result of the reception data check processing in step 504 described above, the process proceeds to step 509, and if not (abnormal), the process proceeds to step 510. In step 506, normal termination is substituted for the message, the retry count is reset to 0 in step 502, and the flow is terminated in step 507.

  On the other hand, in the data reception (step 502), the processing flow (step 509 to step 510) when the data reception is unsuccessful substitutes an error message as log information in step 509, and proceeds to step 510. In step 501, the reception failure is substituted for the message, and the process proceeds to step 501.

  In addition, when the received data state is abnormal and the received data has an error (Step 505: Abnormal), the flow of processing (Step 511 to Step 514) is as follows. If it is not (less than 3), go to step 513. In step 512, the reception data abnormality is substituted for the message, and the process proceeds to step 501. In step 513, a warning message is substituted into the log, and the process proceeds to step 514. In step 514, the number of retries is incremented by 1, and the flow ends in step 507.

  When the condition result item extraction unit 107 executes the condition result item extraction process in the procedure shown in FIG. 7 for the flowchart 160, the condition result item list 600 shown in FIG. This can be used. In this case, the condition result item extraction unit 107 starts the processing in step 1300, and in step 1301, if the type of each step in the flowchart 160 is “condition” (step 1301: condition), the process proceeds to step 1302, otherwise. (Step 1301: Result), the process proceeds to Step 1303.

  In step 1302, the condition result item extraction unit 107 extracts the value of the branch condition indicated by the corresponding condition item as the item value from the description of the corresponding step in the flowchart 160 and proceeds to step 1304. In the example of the flowchart 160 in FIG. 6, “timeout”, “reception data state”, and “retry count” are used as the condition item names from the description of the corresponding step of the conditional branch (step 503, step 505, step 511). Further, “> 60 seconds”, “≦ 60 seconds”, “normal”, “abnormal”, “≦ 3”, “> 3” are extracted as item values from the corresponding step.

  Next, in step 1303, the condition result item extraction unit 107 uses the description of the step other than the conditional branch step in the flowchart 160 as the result item, and uses the value specified by the description as the item of the result item, as in step 1303 described above. Extract as a value and go to step 1304. In the example of the flowchart 160 in FIG. 6, “retry count” as a result item from the processing (step 501, step 502, step 504, step 506, step 509, step 510, step 512, step 513, step 514), “Data reception”, “Reception data check”, “Log”, “Message” are extracted, and the result item values are “Reset to 0”, “With call”, “No call”, “Error message”, “Warning message” ”,“ Normal end ”,“ reception failure ”,“ reception data abnormal ”, and the like are extracted.

  In the step (process) included in the flowchart 160 described above, the notation of the corresponding process is described in the format “A: = B”. Thereby, in extraction of a result item and a result item value, "A" can be extracted as an item name and "B" can be extracted as an item value. In addition, in the predefined processing (steps 502, 504, and 509) in the flowchart 160, item values such as “calling present” and “calling absent” are determined in advance, and in the extraction of the result item and the result item value, The item name is extracted from the description, and “calling present” and “calling absent” are extracted as the result item values. The extraction rules for these condition items and result items can be defined in advance. The item extraction process based on this extraction rule will be described in the second embodiment.

  Then, it returns to description of the flow of FIG. In step 1304, the condition result item extraction unit 107 proceeds to step 1305 when each of the above-described steps 1301, 1302, and 1303 has been completed for all steps in the flowchart 160 (step 1304: Yes). The process ends. On the other hand, if not (step 1304: No), the condition result item extraction unit 107 returns the process to step 1301.

  As shown in FIG. 8, the condition result item list 600 thus obtained includes an item identifier (No column) 601 for identifying the condition item and the result item, and an item type (type column) indicating whether the item is a condition item or a result item. 602, an item name (name field) 603 for storing the name of the condition item or result item, an item value (candidate value field) 604 for describing a possible value of each condition item or result item, and each condition result It consists of an item summary (summary column) 605 that describes the item description.

  The item correction / specified value setting (FIG. 3: step 303) for the condition result item list 600 is performed, for example, by adding an item value not described in the flowchart 160 or a result item whose result is not fixed on the flowchart 160. On the other hand, the user sets a specified value.

  For example, in the flowchart 160 of FIG. 6, if the number of retries is 3 or less in the processing of step 511, the value assigned to the message is indefinite. In such a case, by adding “no output” as a result item and adding “no output” added as a default value, it is possible to prevent the expected result from becoming undefined when generating a test case. it can. In the condition result item list 600 of FIG. 8, the specified value is expressed using an underline in the item value column.

  Moreover, as an example in the case of correcting item values other than the above, it corresponds to a situation in which a word equivalent to an Else sentence is included in the branch condition, such as “other than that”. In this case, a specific item value may be set as an item value that can be taken by the corresponding condition item name, instead of using “other” as an extraction result as it is.

  Next, details of the execution path extraction in step 304 and the creation of the condition result correspondence table in step 305 will be described. In this case, the execution path extraction unit 108 starts a search that sequentially follows each step in accordance with a conditional branch or the like from the start symbol 500 in the flowchart 160, and extracts all execution paths in the flowchart 160, for example. As a result, as an example of the obtained execution path, for example, the execution path (1) 701 illustrated in FIG. 9 represents the following execution path in the flowchart 160.

Step 500: Start symbol Step 501: Number of retries: set to 0 Step 502: Data reception Step 503: Timeout? (Branch condition> 60 seconds)
Step 509: Log: = Error message Step 510: Message: = Reception failure Step 507: End Similarly, the execution path (2) 702 illustrated in FIG. 9 corresponds to the following execution path in the flowchart 160.

Step 500: Start symbol Step 501: Number of retries: set to 0 Step 502: Data reception Step 503: Timeout? (Branch condition ≤ 60 seconds)
Step 504: Receive data check Step 505: Receive data status? (Branch condition is normal)
Step 506: Message: = Normal end Step 507: End Similarly, the execution path (3) 703 illustrated in FIG. 9 corresponds to the following execution path in the flowchart 160.

Step 500: Start symbol Step 501: Number of retries: set to 0 Step 502: Data reception Step 503: Timeout? (Branch condition ≤ 60 seconds)
Step 504: Receive data check Step 505: Receive data status? (Branch condition is normal)
Step 506: Message: = Normal end Step 507: End In the flowchart 160 of FIG. 6, “retry count: set to 0 (step 501)”, “retry count: = increase by 1 (step 514)”, etc. Although described, the actual calculation result may be calculated by using an operator such as “retry count: = retry count + 1 (step 514)”. In the above execution path extraction, for example, when the execution path is a loop (when returning to the previously executed path), the loop may be extracted as one execution path, or after the loop ends The result may be calculated as an execution path.

On the other hand, the condition result correspondence table generation unit 110 converts each execution path obtained as described above into a rule in accordance with the above-described step 305 (creation of the condition result table), and the rule illustrated in FIG. A list 710 is generated. In the rule list 710, for example, a rule having a rule identifier 711 of “1” corresponds to the execution path (1). The condition / result correspondence table generation unit 110 sets, in each record of the rule list 710, the information on the conditional branch existing on the execution path corresponding to the left side 713 and the information of the result item corresponding to the right side 714 side. To convert the execution path to rules.

Such a rule list 710 describes a rule type (type column) 712 indicating the type of the corresponding rule, and the contents of the rule, using a rule identifier (# column) 711 describing an ID for identifying the rule as a key. The left side column 713 and the right side column 714 for this purpose. Of these, the left side column 713 and the right side column 714 are each composed of a name and value column for storing item values corresponding to the condition result items. Each rule in the rule list 710 has a data structure “the item value c1 of the condition item C1, the item value of the condition item C2 is c2, and..., The item value of the result item B1 is It corresponds to the specification description in a logical expression format such as “b1, and.

  The condition result correspondence table generation unit 110 creates a condition result correspondence table from the rule list table 710 generated as described above (FIG. 3: step 305). In this case, the condition result correspondence table generation unit 110 associates each condition item or result item with its item value, a combination of condition item values, and an item value of a result item corresponding to the combination in the rule list 710. Thus, the condition result correspondence table is generated.

  FIG. 11 is a diagram showing a configuration example of the condition result correspondence table 800 generated from the rule list 710 of FIG. As shown here, the condition result correspondence table 800 describes a condition result item column 803 in which condition items and result items and their item values are described, combinations of condition item values, and item values of result items corresponding to the combinations. The rule column 804 is composed of two columns.

  The condition result correspondence table 800 includes a condition line 801 for describing condition items, a result line 802 for describing result items, and an execution path corresponding line for describing the correspondence between each rule in the rule column and the execution path. Reference numeral 805 denotes a test case column 806 that describes the correspondence between each rule in the rule column and the generated test case.

  Each rule (1) to (8) in the condition result item correspondence table 800 shown in FIG. 11 uses “◯” as the corresponding item value. That is, all the rules are stored using the same symbols, but each rule may be stored so that the condition items and result items included in each execution path can be understood.

  For example, the rule corresponding to the execution path (2) 702 corresponds to the rule columns 1 and 2 in FIG. At this time, the corresponding column of the rule column corresponding to the condition item “timeout ≦ 60 seconds” and the result item “data reception: = present” included in the execution path is described with “○”, and the other condition item “retry” “Number of times” and “Log: = No output” may be described as “-”.

On the other hand, the test case generation unit 109 executes test case generation processing using the above-described condition result correspondence table 800 (FIG. 3: step 307). Although the outline of this process has already been described with reference to FIG. 4, it will be specifically described. The test case generation unit 109 determines whether it is an execution path base, an input / output base, or a coverage standard according to the type in the coverage standard (type field 412) selected by the user in the coverage standard list 410, Test cases are generated in accordance with the coverage standards. For example, when the user selection is an execution path-based coverage criterion, the coverage criterion list using the flowchart 160 (specifications relating to the flow of processing) described in FIG. 6 and the execution path generated in step 304 is used. A test case is generated using the test case generation process described in the column 410 of test case generation process 414 (step 403).

When generating a test case on an input / output basis, the test case generation unit 109 generates the test case in step 305 by using the test case generation process described in the test case generation process 414 column of the coverage standard list 410 in the same manner. The test case is generated using the condition result item list 600 and the generated condition result correspondence table 800 (step 404).

  The test case generation / evaluation processing that satisfies the coverage criteria is performed for each coverage criterion, and the test cases that satisfy each coverage within each processing specified by the coverage generation processing name 414 and the coverage evaluation processing name 415. It can be implemented arbitrarily so that it can be generated and evaluated. For example, for executable statement coverage (SC, C0), all extracted execution paths may be selected at random, and selection of execution paths may be repeated until processing is selected for all specifications related to the flow of processing. .

  In step 405, the test case generation unit 109 uses the execution path correspondence column 805 in the condition result correspondence table 800 to determine whether or not the generated execution path base test case and the input / output correspondence base test case overlap. Confirm and delete duplicate test cases.

  Next, in step 406, the test case generation unit 109 checks whether or not all the test case generation processing for the coverage criterion given as the setting parameter has been performed. If there is a coverage criterion that has not been generated, the process returns to step 402. The above process is repeated to generate a test case corresponding to an ungenerated coverage criterion.

  Whether the test case generated at this time complies with the coverage standard given as the setting parameter is determined using the processing in the coverage evaluation processing column 415, and the test case corresponding to the ungenerated coverage standard is determined. It may be determined whether or not it has been generated.

  Further, the deletion of the duplicate test case (step 405) is performed by confirming the generated test case on the condition result correspondence table 800 at the time of test case generation in step 403 and step 404. And in step 404.

  The coverage standard list 410 illustrated in FIG. 5 is an example of the coverage standard, and may include other coverage standards. Further, the coverage standard illustrated in the coverage standard list 410 of FIG. 5 is based only on the specification and execution path related to the flow of processing (in the case of execution path base) or the condition result item list (in the case of input / output base). Although only the criteria that allow coverage evaluation are illustrated, other coverage criteria may be included.

  For example, in the case where all execution paths passing through a specific process or conditional branch are used as test cases, the following may be performed. First, in the coverage standard list 410, as the above-mentioned coverage standards, the coverage type 412 is “execution path”, the coverage generation process name 413 is “specific statement coverage”, the coverage generation process name 414 and the coverage evaluation process name 415 are Add processing for test case generation and evaluation.

  In this case, in the generation parameter setting process in step 306, “specific statement coverage” is designated as the test case generation process to be generated from the user input 312, and the specific process or condition is specified from the specification representing the flow of the process. Should be input together. For example, in the flowchart of FIG. 6, any one of steps 500 to 514 may be input by user input 312.

Note that the test case column 806 in FIG. 11 includes the coverage of judgment criteria (DC) and the coverage of n conditions of the input / output base coverage criteria (n-wis) among the execution path-based coverage criteria.
An example of the result of test case generation based on e) is shown. As shown in the test case column 806 in FIG. 11, in the generated test case illustrated in FIG. 11, the test cases described in the rule column 1 are duplicated from the execution case base, the input / output base, and the test case generation results. Therefore, it is possible to prevent duplication of test execution related to this test case at the time of test execution. In this way, it is possible to perform a duplicate check between test cases when generating test cases corresponding to execution path and condition / result items and coverage. As a result, when test cases are generated so as to satisfy the respective coverages, it is possible to prevent the generation of duplicate test cases and to realize efficient test execution.

  In the above example, each item of condition / result is not actual program variables but design information used at the time of specification design. When conducting software tests for implementation, the actual test cases and actual values are assigned by assigning specific implementation variable names, variable values, etc. to each item of the condition / result and its item value. Corresponding to the input / output variables at the time of test execution.

  Next, a second embodiment will be described. In the second embodiment, based on the extraction rule list 1200 shown in FIG. 14, the extraction of condition result items (in accordance with the condition result item extraction process and the execution path extraction process shown in FIG. 7 and FIG. 16) Step 302) and execution path extraction (step 304).

  Here, FIG. 12 is a diagram showing an example of specifications related to the flow of processing for explaining the second embodiment, and is an example of specification description by a state transition diagram (state chart diagram) in the UML diagram. The state transition diagram 140 of FIG. 12 is a diagram showing a transition state of a program related to data reception processing. The start 900, the end 905, the reception wait 901, the data check 902, the message output 903, and the state between these states It consists of transition conditions that represent transitions.

  A procedure for the condition result item extraction unit 107 to execute the condition result item extraction process from the state transition diagram 140 of FIG. 12 will be described below based on the flow of FIG. 7 is a process executed by the condition result item extraction unit 107 of the test case generation apparatus 100 in step 302 of FIG. 3 and the condition result item extraction process as described above.

  Here, the condition result item extraction unit 107 starts processing in step 1300, and in step 1301, regarding the symbol elements in the state transition diagram 140 described above, the rule type item 1204 of the extraction rule list 1200 illustrated in FIG. The value is confirmed, and if the type of the symbol to be extracted is “condition”, the process proceeds to step 1302; otherwise, the process proceeds to step 1303.

  14 stores an extraction rule identifier (ID column) 1201 for identifying an extraction rule, an extraction rule name (name column) 1202 indicating the name of the extraction rule, and a notation that is an extraction source. From the notation column 1203 to be extracted, the extraction type (type column) 1204 indicating the extraction type of the condition result item, the extraction rule 1205 that defines the extraction rule of the condition result item and the item value, and the supplementary rule 1206 used when creating the rule in step 305 Composed. This supplementary rule 1206 is defined in the supplementary rule list 1210 shown in FIG. 15, and the constitution thereof is a supplementary rule identifier (ID column) 1211 for identifying the supplementary rule and a supplementary rule representing the name of the supplementary rule. Name (name field) 1212, supplementary rule notation (notation field) 1213 indicating notation corresponding to the supplementary rule, supplementary rule type (type field) 1214 indicating the extraction type of the supplementary rule, supplementary rule indicating the content of the supplementary rule (Supplementary rule column) 1215. The supplementary rule column 1215 includes a condition column describing a condition for applying the supplementary rule and an additional rule column describing the content of the rule to be added.

  In step 1302, the condition result item extraction unit 107 refers to the notation in the “condition” symbol to be extracted and the value in the extraction rule 1205 column of the extraction rule list 1200, and matches the extraction rule name column. The description is extracted as the condition item, and the description matching the value column is extracted as the item value of the extracted condition item. After this extraction, the condition result item extraction unit 107 advances the process to step 1304.

  In step 1303, the condition result item extraction unit 107 refers to the notation in the symbol and the extraction rule 1205 as in step 1303 described above, and uses a description that matches the name field of the extraction rule as a result item. The description that matches the column is extracted as the item value of the extracted result item. After this extraction, the condition result item extraction unit 107 advances the process to step 1304.

  Next, in step 1304, the condition result item extraction unit 107 proceeds to step 1305 and ends the processing when the processing is completed for all the symbols in the state transition diagram 140, that is, the specification (step 1304: YES). . On the other hand, if not (step 1304: NO), the condition result item extraction unit 107 returns the process to step 1301.

Of the condition result item list 910 obtained by the processing in this manner, for example, the sixth line “waiting for reception” in the condition result item list 910 is generated from the state in the state transition diagram 140, the waiting for reception 901. The In addition, the item value is described according to the rule described in the first line of the extraction rule list 1200 as to whether the reception wait state is reached (active) or not (inactive). As shown in FIG. 13, the condition result item list 910 is similar to the condition result item list 600 illustrated in the first embodiment, as an item identifier (ID column) 911 for identifying condition items and result items. Is an item type (type field) 912 indicating whether the item is a condition item or a result item, an item name (name field) 913 for storing the name of the condition and result item, and an item that describes candidates for values that each condition and result item can take It consists of a value (candidate value column) 914 and an item summary (summary column) 915 describing the description of each condition result item.

  It should be noted that the condition result item extracted as described above can be corrected and set with a specified value in accordance with a user instruction. This process is executed by the condition result item correction unit 103. In the above example, for example, it is determined as a pre-extraction rule that the specified value of the item value for the state is inactive, and some specified values are automatically set when extracting the condition result item. Yes.

  Next, the execution path extraction process (FIG. 3: step 304) by the execution path extraction unit 108 will be described with reference to FIG. In this case, the execution path extraction unit 108 starts processing in step 1401, searches for all symbols in the state transition diagram 170 in step 1402, and “start” in the extraction rule type 1204 in the extraction rule list 1200. Extract symbols that meet the conditions.

  Subsequently, in step 1403, the execution path extraction unit 108 proceeds to step 1409 if the search for all symbols in the state transition diagram 170 has been completed (step 1403: YES), otherwise (step 1403: NO), the process proceeds to Step 1404.

  Next, in step 1404, the execution path extraction unit 108 proceeds to step 1408 if the search of all symbols connected to the symbol extracted in step 1402 is completed (step 1403: YES), otherwise ( Step 1404: NO), the process proceeds to Step 1405.

In step 1405, the execution path extraction unit 108 extracts the above-mentioned connection destination components, and in step 1406, extracts the “end” extraction rule in the extraction rule type 1204 in the extraction rule list 1200 and becomes the target. Check that the symbol meets the termination condition. If the end condition is met (step 1406: YES), the execution path extraction unit 108 advances the process to step 1408, and if not (step 1406: NO), the process proceeds to step 1407.

  In step 1407, the execution path extraction unit 108 checks whether the condition or result in the extraction rule type 1204 in the extraction rule list 1200 is met. The target symbol is added, and the process proceeds to Step 1404. In step 1408, the execution path extraction unit 108 configures an execution path from the symbol string extracted up to step 1405, and proceeds to step 1403.

  The above-described flow shows an example of a method for realizing a process of sequentially searching for a connection destination symbol in order to start processing from a symbol that meets the start condition and extract each execution path that meets the end condition.

  Note that in the above-described step 1407, if the symbol does not match any of the extraction rules of the condition and the result, the execution path extraction unit 108 may stop the process and move on to search for the next execution path. As a result, even when, for example, a comment symbol is described in the execution path, only the intended execution path can be extracted.

  FIG. 17 shows a part of execution paths (execution path (1) 1001, execution path (2) 1002, execution path (3) 1003) generated by the execution path extraction process related to the state transition diagram 170.

  The condition result correspondence table generation unit 110 creates a rule from the execution path obtained as described above. The flow will be described using the execution path (1) 1001 in FIG. 17 as an example. The execution path (1) 1001 undergoes state transition from the state transition diagram 170 of FIG. 12 in the order of start 900, reception wait 901, data check 902, message output 903, and end 905 in accordance with the processing of FIG. Represents the case. Further, in the rule list 1010 of FIG. 18, the rule identifier 1011 corresponds to the rule of 1.

  First, the condition result correspondence table generation unit 110 refers to the extraction rule list 1200, and for each symbol in the execution path (1) 1001, the extraction type of the line that matches the symbol in the notation field 1203 in the extraction rule list 1200 1204 is divided into a symbol that is “condition” and a symbol that is “result”.

Next, the condition result correspondence table generation unit 110 configures the left side 1013 of the rule (see FIG. 18) for a symbol whose extraction type 1204 is “condition”. For example, “data reception” corresponds to a notation in which the rule identifier 1201 of the extraction rule list 1200 is 2. According to the notation field 1203, $ A = “data reception”, and $ B, $ b, $ C, and $ c have no corresponding notation. Therefore, the condition result correspondence table generation unit 110 describes “data reception” = “occurrence” as a rule according to the corresponding extraction rule 1205 (the extraction rule 1205 uses “, (comma)”). Two values (active and inactive) are listed. If the value cannot be specified here, the first value is extracted).

Next, the condition result correspondence table generation unit 110 refers to the supplementary rule 1206, and extracts a corresponding supplementary rule from the supplementary rule list 1210 when the supplementary rule column has a description. For “data reception”, since 1 is assigned to the supplementary rule 1206, the condition result correspondence table generation unit 110 acquires the supplementary rule from the supplementary rule list 1210.

  Further, the condition result correspondence table generation unit 110 extracts symbols related to the supplementary rule from the supplementary rule list 1210 from the notation column 1213 in the supplementary rule whose supplementary rule identifier 1211 is 1 and the state transition diagram of FIG. Here, the state “waiting for reception” 901 which is the transition source of “data reception” is referred to, and the event “timeout” is extracted.

Next, the condition result correspondence table generating unit 110 adds “timeout = occurrence” as an additional rule from “waiting for reception” ≠ “timeout” ($ A1 ≠ $ A2) according to the condition in the supplementary rule column 1215.
Timeout = None "," Timeout = None ⇒ Timeout = Occurrence "is generated. Here," ⇒ "
Indicates that an expression written on the left side of “⇒” is described in the left side column 1013 of the rule list 1010 and an expression written on the right side is described in the right side column 1014.

  In addition, the condition result correspondence table generation unit 110 adds a supplementary rule to be added from the type column 1214 of the supplementary rule list 1210 to the type column 1012 as a restriction when describing the rule in the rule list 1210 (rule as a constraint condition) That is, combinations of condition item values are limited to the conditions added here). Note that the rules added by the above processing correspond to the rules whose rule identifier 1011 of the rule list 1010 is 5 or 6.

  Similarly, the condition result correspondence table generation unit 110 performs the same process as described above for the event “check completed”, thereby adding the name column “check completed” and the value column “occurrence” to the right side 1013 and at the same time supplementary rules. From 1215, rules 7 and 8 are added to the rule identifier 1011.

Next, the condition result correspondence table generation unit 110 determines that the extraction type 1204 of the extraction rule list 1200 is “
The symbol “result” is processed in the same manner as described above to construct the right side.
For 014, the condition result item list 910 is searched, and if there is a result item that is not included in the execution path, a specified value is assigned to configure the right side.

  For example, “retry count” is not included in the execution path (1) 1001. In this case, the condition result correspondence table generation unit 110 adds the value “reset to 0” to the right side 1014 so that all result items are included in the right side.

  Note that the above processing is to prevent a column whose result is undetermined when the condition result correspondence table 1100 is configured, and a result item that is not necessarily included in the execution path is added to the right side 1014. There is no need. If the rule added by the above procedure has already been extracted, it is not necessary to add it to the rule list 1010 again.

  FIG. 18 shows a rule list 1010 obtained by converting the execution path into rules. The rule list 1010 is a result of converting the extracted execution path into a rule. As in the first embodiment, the rule list 1010 includes a rule identifier (# field) 1011 that describes an ID for identifying a rule, a rule type (type field) 1012 that represents the type of the rule, and a rule Is composed of a left side column 1013 and a right side column 1014. Of these, the left side column 1013 and the right side column 1014 are each composed of a name / value column for storing a condition / result item and a corresponding item value.

  The configuration of the extraction rule list 1200 in FIG. 14 and the supplementary rule list 1210 in FIG. 15 may not be the same as the configuration in the illustrated example. For example, in the above example, when a plurality of value candidates are described in the extraction rule 1205 and the value cannot be determined, the first candidate value is assigned. Of these, items to be assigned as values may be explicitly specified and described. In addition, in the notation fields 1203 and 1213, symbols are not used as they are, but identifiers for extracting symbols, conditions, and result items, and other notations for extracting written names and candidate values. A method may be used.

  Next, the process of generating the condition result correspondence table 1100 using the rule list 1010 by the condition result correspondence table generation unit 110 will be described. In this case, the condition result correspondence table generation unit 110 specifies the corresponding result item value for the rule type 1012 that satisfies the condition on the right side of the rule from among all the combinations of the condition items in the rule list 1010. Generate with This generation method is the same as in the first embodiment. At this time, if there is a rule whose rule type 1012 is “restriction”, the rule type 1012 is restricted only to the combination of the condition items (possible values are limited to the rule given as the restriction). Is shown. For this reason, when there are constraint rules in the rule list 1010, only the combination of the corresponding condition items may be left as a rule. In the condition result correspondence table 1100 shown in FIG. 19, a rule whose number is not described in the execution path row 1105 indicates that there is no condition combination due to the restriction of the rule list table 1010. By the above processing, the condition result item correspondence table 1100 is generated from the state transition diagram 170 of FIG.

  A test case can be obtained by executing generation parameter setting (step 306) and test case generation (step 307) as in the first embodiment. A test case row 1106 in FIG. 19 shows test cases in the case of judgment statement coverage (DC) and n-wise (n = 2) in the coverage standard list 410 shown in FIG. Judgment statement coverage (DC) indicates a case where a path that passes through each transition at least once is selected as a test case for all states on the state transition diagram 170, and n-wise is a condition item. Coverage is a case where all combinations of extracted item values of n items are used as test cases.

  The flow of test case generation processing from the specifications related to the flow of processing has been described above. In the second embodiment, the state transition diagram 170 has been described as an example. However, by preparing an extraction rule list for the flowchart, the same procedure is applied to the flowchart described in the first embodiment. Is possible.

  In each of the above-described embodiments, a state transition diagram and a flowchart are taken as an example of specifications related to a process flow along with test case generation. For example, a sequence diagram in UML and a BPEL ( With regard to (Business Process Execution Language) and the like, a test case can be obtained in the same manner by separately defining an extraction rule list. Further, not only the specification representing the processing flow in the diagram format but also the program language such as C language or JAVA language can be used to generate the test case by similarly defining the extraction rule list.

  In addition to the business system and financial system, each of the above-described embodiments includes a system development system, a software operation, or a user such as a control / monitoring system such as a power plant or train operation management, or an embedded system. It can be used regardless of a specific system development or development process, such as a use case scenario that represents the operation procedure.

  Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications can be made without departing from the scope of the invention.

  According to the present embodiment, it is possible to efficiently generate a test case that satisfies appropriate coverage considering both the execution path base and the input / output base from the software specifications related to the processing flow.

At least the following will be clarified by the description of the present specification. That is, in the test case generation device according to the present embodiment, the storage device specifies each notation of the condition item and the result item in the specification information related to the flow, and the condition item and the result are determined from each notation. Extraction rule information including an extraction rule for extracting an item and its item value, and a start condition and an end condition in the execution path are stored, and the arithmetic device is configured to extract the extraction rule information in the condition result item extraction process. In the extraction rule, the condition item, the result item, and each item value of the condition item and the result item are extracted and stored in the storage device as the condition result item. In the execution path extraction process, Based on the flow specification information and the start condition indicated by the extraction rule information, an execution path according to the start point specification in the flow Starts out, to extract the end point identified as one of the execution paths depending on the termination conditions in the flow may be those.

  According to this, for example, it is possible to flexibly correspond to the specification described in the state transition diagram in the UML diagram, and to efficiently generate the test case of the present embodiment.

  Further, in the test case generation device described above, the storage device further stores, as the extraction rule information, a supplementary rule that defines a constraint condition of a combination between the condition item and the result item related in the flow. In the condition result item extraction process, the arithmetic device uses the extraction rule and the supplementary rule in the extraction rule information to determine the condition item, the result item, and each item value of the condition item and the result item. May be extracted under the restriction satisfying the provisions of the supplementary rule and stored in the storage device as the condition result item.

  According to this, it is possible to extract condition result items in consideration of the relationship between events that occur exclusively among predetermined events, and as a result, the accuracy of the test case to be generated can be improved.

  In the above test case generation device, the storage device indicates whether the test case to be generated evaluates an execution path base coverage or an input / output base coverage as the information of the coverage criterion A coverage type may be further stored, and the arithmetic unit may execute the generation of the test case in accordance with the coverage type indicated by the coverage reference information in the test case generation process.

  According to this, for example, according to the coverage type specified by the user, it is possible to efficiently generate a test case that satisfies the corresponding coverage.

  Further, in the test case generation device described above, in the condition result item extraction process, the arithmetic device displays the extracted condition result item on a display device, receives a correction instruction related to the condition result item from the input device, The condition result item process for correcting the condition result item may be further executed.

  According to this, it becomes possible to correct the condition result item to the contents according to the user's knowledge or customer request, etc., and it is possible to generate test cases more efficiently and more flexibly to meet the needs.

  Further, in the test case generation device described above, the arithmetic device may include a combination of the condition item and the result item related in the flow as correction instructions received by the input device in the condition result item correction process. The supplementary rule that defines the constraint condition may be accepted.

  According to this, according to the knowledge of the user, it is possible to extract the condition result items based on the relationship of the events that occur exclusively among the predetermined processing, and as a result, the accuracy of the test case to be generated is improved. Can be good.

DESCRIPTION OF SYMBOLS 100 Test case production | generation apparatus 101 Description format verification part 102 Specification input part 103 Condition result item correction | amendment part 104 Test specification production | generation part 105 Test specification registration part 107 Condition result item extraction part 108 Execution path extraction part 109 Test case generation part 110 Condition result item Generation unit 111 Specification storage unit 112 Condition result item storage unit 113 Execution path storage unit 114 Test case storage unit 115 Coverage reference storage unit 116 Condition result correspondence notation unit 117 Extraction rule list storage unit 201 CPU (arithmetic unit)
202 RAM
203 External storage device (storage device)
204 Interface 205 Display device 206 Input device 210 Program

Claims (6)

Specification information related to the processing flow in software, coverage information of test cases, and condition items indicating branch conditions in the flow and result items indicating execution contents other than the condition items in the specification information An extraction rule that specifies a notation and extracts the condition item, the result item, and the item value from each notation, and an extraction condition that includes a start condition and an end condition in an execution path within the specification corresponding to the specification information A storage device storing rule information ;
By the extraction rules in the extraction rule information, from the specification information, and the condition item, the result item, the item value can take each of the condition item and the result item, the extracted storage device as a condition result item Condition result item extraction process to store,
When extracting each execution path in the corresponding specification from the specification information, execution path extraction is performed in accordance with the start point specification in the flow based on the specification information and the start condition indicated by the extraction rule information. An execution path extraction process that starts and extracts as one execution path up to the end point specified according to the end condition in the flow ;
Based on the condition result item and the item value, a rule that is a combination of the item value of each condition item and the item value pattern of the corresponding result item is generated, and the processing content indicated by each rule and the execution path A condition result correspondence table generation process for identifying a correspondence relationship, generating a condition result correspondence table indicating the correspondence relationship between the rule and the execution path, and storing the correspondence result correspondence table in a storage device;
A rule or execution path corresponding to the condition indicated by the coverage standard information is searched in the condition result correspondence table, and a test case is generated by a predetermined generation algorithm based on the searched rule or execution path and the specification information. A test case generation process to perform, an arithmetic device to execute,
A test case generation apparatus comprising: The storage device
As the extraction rule information, a supplementary rule that defines a constraint condition of a combination between the condition item and the result item related in the flow is further stored,
The arithmetic unit is
In the condition result item extraction process, the condition item, the result item, and each item value of the condition item and the result item are defined in the supplementary rule by the extraction rule and the supplementary rule in the extraction rule information. Is extracted under the restriction that satisfies the above, and is stored in the storage device as the condition result item.
The test case generation device according to claim 1, wherein the test case generation device is a device. The storage device
As the coverage standard information, a coverage type indicating whether a test case to be generated evaluates an execution path based coverage or an input / output based coverage is further stored,
The arithmetic unit is
In the test case generation process, the test case is generated according to the coverage type indicated by the information on the coverage criterion.
The test case generation device according to claim 1, wherein the test case generation device is a device. The arithmetic unit is
In the condition result item extraction process, a condition result item process is further performed in which the extracted condition result item is displayed on a display device, a correction instruction related to the condition result item is received from the input device, and the condition result item is corrected. What to do,
The test case generation device according to claim 1. The arithmetic unit is
In the condition result item process , as a correction instruction received by the input device, a supplementary rule that defines a constraint condition of a combination between the condition item and the result item related in the flow is received.
The test case generation apparatus according to claim 4. Specification information related to the processing flow in software, coverage information of test cases, and condition items indicating branch conditions in the flow and result items indicating execution contents other than the condition items in the specification information An extraction rule that specifies a notation and extracts the condition item, the result item, and the item value from each notation, and an extraction condition that includes a start condition and an end condition in an execution path within the specification corresponding to the specification information A computer comprising a storage device storing rule information ;
By the extraction rules in the extraction rule information, from the specification information, and the condition item, the result item, the item value can take each of the condition item and the result item, the extracted storage device as a condition result item Condition result item extraction process to store,
When extracting each execution path in the corresponding specification from the specification information, execution path extraction is performed in accordance with the start point specification in the flow based on the specification information and the start condition indicated by the extraction rule information. An execution path extraction process that starts and extracts as one execution path up to the end point specified according to the end condition in the flow ;
Based on the condition result item and the item value, a rule that is a combination of the item value of each condition item and the item value pattern of the corresponding result item is generated, and the processing content indicated by each rule and the execution path A condition result correspondence table generation process for identifying a correspondence relationship, generating a condition result correspondence table indicating the correspondence relationship between the rule and the execution path, and storing the correspondence result correspondence table in a storage device;
A rule or execution path corresponding to the condition indicated by the coverage standard information is searched in the condition result correspondence table, and a test case is generated by a predetermined generation algorithm based on the searched rule or execution path and the specification information. Test case generation process to
A test case generation method characterized by executing