JP5404720B2 - Test item generation apparatus, method, and program for executing single abnormal scenario any number of times - Google Patents

Description

  The present invention relates to a test item generation apparatus, method, and program for executing a single abnormal scenario any number of times, and particularly for a test that executes a specific single abnormal scenario any number of times based on a use case description. The present invention relates to a test item generation apparatus, method, and program for executing a single abnormal scenario for generating test items an arbitrary number of times.

  As a method for extracting test items for scenario tests based on conventional use case descriptions, UML activity diagrams (the same flow structure as use case descriptions) are used as input, and the permutation of routes that pass once through the loop There is a method of generating (see, for example, Non-Patent Document 1).

  In addition, there is a technique capable of extracting a test path (test item) that always passes through each edge of a screen transition diagram (the same flow structure as the use case description) at least once (see, for example, Patent Document 1).

JP-A-9-223040

Akira Zhang, Takashi Hoshino. “Test Item Extraction and Test Data Generation Method Using Design Model”, IEICE Technical Report. KBSE, Intelligent Software Engineering, Technical report of IEICE. KBSE 109 (41) pp. 37-42 , 20090514.

  However, the technique of Non-Patent Document 1 cannot extract a test path for executing a specific above-described scenario a plurality of times (two or more times).

  In addition, the technique of Patent Document 1 guarantees that the test path extracted by the technique includes a test path that executes only a specific abnormal scenario, and a test case that executes only a specific abnormal scenario multiple times. There is no warranty included.

  In this way, in the test item extraction for scenario tests based on use case descriptions, other abnormal scenarios are executed in the normal coverage test using existing coverage criteria such as node coverage and edge coverage. There is a problem that a specific abnormal scenario is executed only once, or the like cannot be detected.

  The present invention has been made in view of the above points, and provides a single abnormal scenario for generating a test item for scenario testing that can detect an error that occurs when only a specific abnormal scenario is executed a plurality of times. An object of the present invention is to provide a test item generation apparatus, method, and program which are executed an arbitrary number of times.

In order to solve the above-described problem, the present invention (Claim 1) provides a single abnormal scenario for extracting test items for scenario testing based on a use case description indicating a flow of interaction between a user and a system. A test item generation device that is executed an arbitrary number of times,
A design model input means for obtaining a use case description from the input design model;
Extracting all test paths that do not include loop paths from the use case description (hereinafter referred to as “loop without loops”), and adding the test path extraction means without loops to the test path set;
A test path including a loop path (hereinafter referred to as “path with loop”) is extracted from the use case description, and a new test path is generated by connecting the path without loop and the path with loop of the test path set. , A test path complementing means with a loop to be added to the newly added test path set,
Filtering means for extracting a test path including only a specific abnormal system scenario as a target abnormal system test path from the newly added test path set, and adding it to the abnormal system test path set;
Loop path duplicating means for duplicating and storing the loop location in each abnormal test path of the abnormal test path set in the execution path storage means;
Execution path extraction means having
Test item generation means for reading the test path from the execution path storage means and generating test items for the test path.

Further, the present invention (Claim 2) provides the test path complementing means with a loop,
Means for adding, to the loop path edge queue, an edge that does not exist in the loop-less path among edges corresponding to the arrow portion of the use case description;
The process of extracting the leading edge X of the loop path edge queue, connecting the edge X to the loopless test path to generate the new test path, and marking the loop path is performed by the loop path edge queue. Means to repeat until is empty,
Including
In the filtering means,
Wherein the newly added partial test path set, including means for extracting a test path containing only target the abnormal system edge the mark loop path is assigned as the target abnormal based test path.

Further, according to the present invention (Claim 3), the loop path duplicating means includes:
Means for replicating the loop portion in the abnormal test path for the number of times designated by the user;

  According to the present invention, a route that does not include a loop route, a loop route is extracted from the use case description, and a loop route is generated by connecting the loop route to a route that does not include the loop route. New test paths can be created for the number of combinations of patterns that connect n types (L1, L2,..., Ln) and patterns that do not connect. In other words, 2 n new test paths can be generated for one path that does not include a loop.

  Also, by filtering, it is possible to obtain a route that includes only an arbitrary abnormal scenario, and an error that occurs when only a specific abnormal scenario is executed multiple times (used when executing an abnormal scenario) It is possible to extract a test path that can detect an error that causes the system to operate differently from the expected when the variable X has an incorrect value.

  Furthermore, in a test path including a loop path, a loop path including an abnormal scenario is duplicated as many times as specified by the user and inserted into the test path, so that only a specific abnormal scenario is executed multiple times. It is possible to extract a test path capable of detecting an error.

It is a block diagram of the test item generation apparatus of the scenario test in one embodiment of this invention. It is a block diagram of the execution path | route extraction part in one embodiment of this invention. It is a flowchart of the outline | summary operation | movement in one embodiment of this invention. It is a detailed flowchart of step 130 in one embodiment of the present invention. It is an example of the data structure of the input (use case description) in one embodiment of this invention. It is an image of the use case description in one embodiment of this invention. It is a detailed flowchart of step 230 in one embodiment of the present invention. It is a detailed flowchart of step 320 in one embodiment of the present invention. It is a detailed flowchart of step 440 in one embodiment of this invention. It is a detailed flowchart of step 330 in one embodiment of this invention. It is a detailed flowchart of step 660 in one embodiment of this invention. It is an example of the data structure of the output (test path | route) in one embodiment of this invention. It is a detailed flowchart of step 340 in one embodiment of this invention. It is a detailed flowchart of step 350 in one embodiment of the present invention. It is an example which extracts an abnormal path | route from the use case description in one embodiment of this invention. It is an example which complements the test path with a loop in one embodiment of the present invention.

  Embodiments of the present invention will be described below with reference to the drawings.

  First, terms used in this specification will be described first.

  ・ Scenario test: A test that confirms whether the system behaves according to the assumed scenario by creating a scenario based on the requirements defined by the user.

  Test items: Test items in the scenario test include a test scenario and a confirmation viewpoint. “Test scenario” is a sequence composed of screens and operations, and “confirmation viewpoint” includes correctness of screen transitions, correctness of screen display contents, presence / absence of database destruction, and the like.

  Screen transition diagram: A type of design document. Shows transitions between screens within a specific function.

  Use case description: A type of design document. It is also a notation to clarify requirements. The flow of interaction between the user and the system is shown. The flow proceeds along the “basic flow”, but may branch into an “alternate flow” and an “exception flow”.

  ・ Normal scenario: Refers to the basic flow in use case description. Consists of one or more edges.

  ・ Abnormal scenario: A generic term for alternative flows and exception flows in use case descriptions. It consists of one or more edges, branches from the normal scenario, and returns to the normal scenario.

  -An error that occurs when only a specific abnormal scenario is executed multiple times: An error that causes the system to operate differently than expected when the variable X used when executing an abnormal scenario is an invalid value is there. If another abnormal scenario that modifies the value of variable X is executed together, variable X will not be an invalid value and an error may not be detected, so other abnormal scenarios are not executed. There is a need.

  Example 1) In the abnormal scenario “cancel in the middle of shopping”, the shopping basket variable is referenced, but the shopping basket variable is not correctly initialized and the program stops due to a NULL reference error. However, if there is another abnormal scenario that determines whether the shopping basket variable is the correct initial value, it is necessary not to execute it.

  Example 2) When the error log is retained in the abnormal scenario “login failure”, and the program stops after exceeding the limit value that can record the error log after repeated login failures. However, if there is another abnormal scenario that deletes all error logs, it is necessary not to execute it.

  Loop path: Consists of one or more edges. There are two cases:

1) Two or more edges E0, E1, ..., En
(Provided that E0 ≠ Ei (i = 1,..., N), and a partial path in which E0 is included in any of the next edges of En;
2) a partial path composed of one edge E0 and including E0 at the next edge of E0;
Edge: Arrow part of use case description. Nodes are connected to both sides (start point and end point) (however, only the start edge, no node is connected to the start point).

  Node: A section in a use case description. Holds the edge (connection to the start point) group.

  Start edge: An edge that exists in the use case description and represents the start of a route.

  End edge: One or more edges in the use case description that represent the end of the route.

  Edge stack: A stack for storing the edges traced in the use case description in order.

  Next development edge group: A candidate group of edges to be traced next (edges connected to the own node at the start point).

  Stack for next expanded edge group: A stack for storing the next expanded edge group that has not been traced in the path traced so far.

  Front edge group: An edge group connected to its own node at its end point.

  Current next developed edge group: the top of the next developed edge group stack.

  Current loop route: This is a route from the top edge of the stack to the current edge closest to the top of the previous routes (edges stacked on the edge stack).

  Loop appearance count: The number of times the loop has appeared in the route.

  FIG. 1 shows a configuration of a test item generation apparatus according to an embodiment of the present invention.

  The test item generation apparatus shown in FIG. 1 includes a design information reading unit 1, a design model analysis unit 2, an execution path extraction unit 3, a time path storage unit 5, and a test item generation unit 6, and is connected to a user terminal 20. Yes.

  The design information reading unit 1 reads the design model (XMI file) input from the user terminal 20 and passes it to the design model analysis unit 2.

  The design model analysis unit 2 extracts a use case description (UML Activity) screen transition diagram from the input design model, generates a design model (XML format), and passes it to the execution path extraction unit 3.

  As illustrated in FIG. 2, the execution path extraction unit 3 includes a design model input unit 31, a loopless path extraction unit 32, a looped test path complementation unit 33, a filtering unit 34, and a loop path replication unit 35. When the use case description is input from the design model input unit 31, the loop-less route extraction unit 32 extracts all the test routes that do not include the loop route from the use case description, and the test route supplement unit 33 with the loop extracts the loop route. Then, the test path including only an arbitrary abnormal scenario is extracted by the filtering unit 34, and the loop path including the abnormal scenario is duplicated by the number of times designated by the user in the loop path duplicating unit 35 and is stored in the execution path storage unit 5. Store.

  The execution path storage unit 5 stores the test path extracted by the execution path extraction unit 3.

  The test item generation unit 6 reads the test path from the execution path storage unit 5, generates a test item table, and outputs it to the user terminal 20.

  FIG. 3 is a flowchart of an outline operation in one embodiment of the present invention.

  Step 110) The design information reading unit 1 reads a design document group from the user terminal 20.

  Step 120) The design model analysis unit 2 generates a design model (XML format) from the read design document group. Here, “XStream http://xstream.codehaus.org/tutorial.html” is used as a method for generating a design model (XML format). The generated design model is output to the execution path extraction unit 3.

Step 130) The execution path extraction unit 3 extracts a test path without a loop and a loop path from the design model, duplicates a specified number of loop paths including an abnormal scenario (alternate flow / exception flow), and the test path ( Test item) is extracted and stored in the execution path storage unit 5. Detailed processing will be described in detail with reference to FIG.

  Step 140) The test item generation unit 6 reads the test path from the execution path storage unit 5, generates a test item table, and outputs it to the user terminal 20.

  Next, the processing of step 130 in the execution path extraction unit 3 will be described in detail.

  FIG. 4 is a detailed flowchart of step 130 in one embodiment of the present invention.

  Step 210) The design model input unit 31 of the execution path extraction unit 3 reads the design model (XML file) generated by the design model analysis unit 2, extracts use case descriptions in the design model, and uses case description list Is generated and stored in a memory (not shown). As shown in FIG. 5, the use case description includes a node ID, intra-node text, previous edge group, next expanded edge group, edge ID, start point connection node ID, end point connection node ID, transition condition, and type. Yes. A structural image of the use case description of FIG. 5 is shown in FIG.

  Step 220) The loopless route extraction unit 32 of the execution route extraction unit 3 reads the use case description list.

  Step 230) The loopless path extraction unit 32 and the looped test path complementation unit 33 of the execution path extraction unit 3 extract an abnormal test path from the use case description list. Detailed processing will be described in detail with reference to FIG.

  Step 240) The filtering unit 34 of the execution path extracting unit 3 performs filtering, and performs a process for collecting the abnormal system paths of the test items after filtering as test items on all the abnormal test paths.

  Step 250) The filtering unit 34 creates a test item table having the test item group as an element and stores it in the execution path storage unit 5.

  Next, processing for extracting an abnormal test path from the use case description list in step 230 will be described.

  FIG. 7 is a detailed flowchart of step 230 in one embodiment of the present invention.

  Step 310) The loopless route extraction unit 32 of the execution route extraction unit 3 reads the use case description.

  Step 320) The loopless path extraction unit 32 extracts a loopless path from the use case description and adds it to a test path set on a memory (not shown). Detailed processing will be described in detail with reference to FIG.

  Step 330) The test path complementing unit with loop 33 extracts the test path with loop from the use case description and adds it to the test path set on the memory (not shown). Detailed processing will be described in detail with reference to FIG.

  Step 340) The filtering unit 34 reads a test path set from a memory (not shown), and extracts a test path including only a specific abnormal scenario from the test path set. Details will be described in detail with reference to FIG.

  Step 350) The loop path duplicating unit 35 acquires the abnormal test path set extracted in Step 340 and the number of loops as an external parameter from the user terminal 20, and in each abnormal test path of the abnormal test path set. The loop portion is duplicated as many times as specified by the user and stored in the execution path storage unit 5 as an abnormal test path set. Detailed processing will be described in detail with reference to FIG.

  The loopless route extraction process by the loopless route extraction unit 32 in step 320 will be described.

  FIG. 8 is a detailed flowchart of step 320 in one embodiment of the present invention.

  Step 410) The loopless path extracting unit 32 loads the initial next expanded edge group (added only the initial edge) from the use case description into the next expanded edge group stack of the memory (not shown).

  Step 415) If the next developed edge group stack is empty, the process is terminated. If not, the process proceeds to Step 416.

  Step 416) If there is an element in the next development edge group at the top of the stack for the next development edge group, the process proceeds to step 420. If there is no element, the process proceeds to step 480.

  Step 420) One edge is obtained from the element (current (next development edge group)) at the top of the next development edge group stack of the memory (not shown) and is set as the current edge.

  Step 430) Remove the current edge group from the current edge group.

  Step 440) Calculate the number of occurrences of the loop in the path (a sequence of edges stacked on the edge stack). Details will be described in detail with reference to FIG.

  Step 445) If the number of occurrences of the loop obtained in Step 440 is greater than 0, the process returns to Step 415, and if it is 0 or less, the process proceeds to Step 450.

  Step 450) Stack the current edge onto the edge stack.

  Step 460) Based on the end point connection node ID of the current edge, the node is acquired from the use case description, the edge (connection with the start point) group of the node is acquired, and the acquired edge (connection with the start point) The group is loaded on the next expansion edge group stack as the next expansion edge.

  Step 470) The path (sequence of edges stacked on the edge stack) is added as a test path to the test path set, and the process returns to Step 415.

  Step 480) If there is no element in the next development edge group at the top of the next development edge group stack in Step 416, the next development edge group stack is hopped.

  Step 490) If the edge stack is not empty, the edge stack is hopped and the process is terminated.

  Next, a process of calculating the number of appearances of the current loop path in the path of the above-described step 440 (sequence of edges stacked on the edge stack) in the loopless path extraction unit 32 will be described.

  FIG. 9 is a detailed flowchart of step 440 in one embodiment of the present invention.

  Step 510) The loopless path extraction unit 32 reads the current edge selected in Step 420.

  Step 520) Read a path (a sequence of edges stacked on the edge stack).

  Step 530) The route is duplicated, and the duplicated route is set as a search-in-progress route.

  Step 540) The current loop route is extracted from the beginning of the route being searched to the nearest current edge.

  Step 550) How many times the current loop path appears in the search path (the number of loop occurrences) is described in Reference 1 “RS Boyer; JS Moore (1977).“ A fast string searching algorithm ”. Comm. ACM 20: 762 -772 "etc.

  The process of the looped test route complementing unit 33 in step 330 of FIG. 7 will be described.

  FIG. 10 is a detailed flowchart of step 330 in one embodiment of the present invention.

  Step 610) The test path complement unit 33 with loop reads the use case description.

  Step 620) The test path set generated in Step 320 is read from a memory (not shown).

  Step 630) A loop path edge queue for storing edges is prepared on a memory (not shown).

  Step 640) Among the edges constituting the use case description, all edges that do not exist in the test path in the test path set, in other words, all edges that exist in the loop path are added to the loop path edge queue.

  Step 650) Extract one edge (loop path edge) from the loop path edge queue.

  Step 660) When the loop path edge is included in the loop path edge queue, the loop path including the loop path edge is connected to the test path included in the test path set, and a plurality of new test paths are created, and this is newly added test. Let it be a route set. Detailed processing will be described in detail with reference to FIG.

  Step 670) Remove all edges included in the test path of the newly added test path set from the loop path edge queue.

  Step 680) Add the newly added test path set to the test path set.

  Step 690) In step 650, if the loop path edge queue does not include the loop path edge, the loop path edge is re-entered in the loop path edge queue.

  Next, a process of creating a new test path by connecting the loop path including the loop path edge in step 660 to the test path in the test path complementing unit 33 with loop will be described.

  FIG. 11 is a detailed flowchart of step 660 in one embodiment of the present invention.

  Step 710) The test route complementing unit with loop 33 reads the use case description.

  Step 720) Read test path set.

  Step 730) Read the loop path edge from the loop path edge queue.

  Step 740) From the test path set, a test path (a certain edge E exists in the path and a loop path edge is included in the next developed edge group of the node corresponding to the end point connection node ID of the edge E) is used for the first half path. Select all as test path set.

  Step 750) Extract the second half path set related to the loop path edge from the test path set. The latter half route set is a set of test routes (second half route) starting from the loop route edge based on the use case description.

  Step 760) A newly added test path set (initially empty) is prepared on the memory.

  Step 770) The partial path from the loop path edge closest to the end edge to the end edge is taken out as the first half path.

  Step 780) The first half path and the second half path are connected by the loop path edge X to create a new path (newly added test path).

  Step 785) Mark the newly added test path created above. Specifically, the newly added test path and the loop path edge are acquired, and all edges constituting the partial path from the loop path edge of the newly added test path to the edge having the loop path edge as the next development edge group are obtained. Mark it as a loop path.

  Step 790) Add the newly added test path to the newly added test path set. An example of the result is shown in FIG.

  As described above, the test path complementing unit with loop 33 generates a new test path (new added test path) by connecting the loop path to the test path not including the extracted loop path.

  Next, the filtering process in step 340 of FIG.

  FIG. 13 is a detailed flowchart of step 340 in one embodiment of the present invention.

  Step 810) The filtering unit 34 reads a use case description from a memory (not shown).

  Step 820) The newly added test path set output in Step 330 is read from a memory (not shown).

  Step 830) An abnormal test path set is prepared on a memory (not shown). The first time is an empty set.

  Step 840) A set of all abnormal system edges (hereinafter referred to as “abnormal system edge set”) is acquired from the use case description. If it cannot be obtained, the process proceeds to step 350.

  Step 850) If the abnormal system edge set is not empty, one abnormal system edge is extracted from the abnormal system edge set as a target abnormal system edge.

  Step 860) One test path including only the target abnormal system edge is selected as the target abnormal system test path from the newly added test path set read in Step 820. Here, when there is no test path that satisfies the condition (test path including only the target abnormal system edge), a test path that includes the target abnormal system edge and that includes the minimum number of abnormal system edges is selected.

  Step 870) The abnormal system edge included in the target abnormal system test path is removed from the abnormal system edge set.

  Step 880) Add the target abnormal test path to the abnormal test path set. However, it is not added when the loop path is not marked on the target abnormal system edge.

  Next, the process of duplicating the loop path by the loop path duplicating unit 35 in step 350 will be described.

  FIG. 14 is a detailed flowchart of step 350 in one embodiment of the present invention.

  Step 910) The loop path duplicating unit 35 reads the abnormal test path set generated in Step 340 (Step 880) from a memory (not shown).

  Step 920) The user-specified loop count is acquired from the user terminal 20.

  Step 930) Duplicated portions of the loop path mark of the abnormal test path are duplicated by the number of times specified by the user and stored in the execution path storage unit 5.

  The abnormal system test path extraction process in step 230 will be specifically described.

  FIG. 15 shows an example in which an abnormal test path is extracted from the use case description according to the embodiment of the present invention. In the figure, a thick arrow indicates a normal edge, and a broken arrow indicates an abnormal edge.

From the use case description, normal scenario ABCD
As an abnormal scenario,
(1) X
(2) YZ
(3) W
There is. In the loopless route extraction unit 32, as a loopless route,
・ ABCD
・ ABCW
Are extracted as a test path set (step 320).

  As a result, all test paths that do not include a loop path are a minimum set of test paths that cover all combinations of “abnormal system scenarios that are not included in the loop path”, and all combinations of multiple types of abnormal system scenarios. The minimum set of test paths that cover

  Next, the looped test route complementing unit 33 supplements the following looped route (step 330).

-ABCD (no loop)
・ ABCW (no loop)
・ ABAXBCD (with loop)
・ ABYZBCD (with loop)
・ ABXBYZBCD (with loop)
・ ABXBCW (with loop)
・ ABAYZBCW (with loop)
・ ABXBYZBCW (with loop)
Of the above paths, ABCD is a normal scenario and is removed by filtering 34 (step 340). As a result, as an abnormal test path set,
・ A⇒B⇒C⇒W (no loop)
・ A⇒B⇒A⇒X⇒B⇒C⇒D (with loop)
・ A⇒B⇒Y⇒Z⇒B⇒C⇒D (with loop)
・ A⇒B⇒X⇒B⇒Y⇒Z⇒B⇒C⇒D (with loop)
・ A⇒B⇒X⇒B⇒C⇒W (with loop)
・ A⇒B⇒A⇒Y⇒Z⇒B⇒C⇒W (with loop)
・ A⇒B⇒X⇒B⇒Y⇒Z⇒B⇒C⇒W (with loop)
Remains. Since these are all combinations of the above three abnormal system scenarios (1) to (3), the following seven patterns are obtained.

・ (1)
(2)
・ (3)
・ (1) (2)
・ (2) (3)
・ (1) (3)
・ (1) (2) (3)
The above seven patterns form an abnormal test set and are stored in the execution path storage unit 5.

  Next, an example of complementing the looped test path in step 330 of FIG.

  FIG. 16 shows an example of complementing the looped test path according to the embodiment of the present invention.

  In the use case description, it is assumed that the following two routes are extracted as loopless test routes.

・ A⇒B⇒C⇒D
・ A⇒B⇒C⇒W
The test path complementing unit with loop 33 prepares a loop path edge queue on the memory and adds all the edges that do not exist in the test path without a loop. In the example of FIG. 16, the loop path edge queue includes
[X, Y, Z, W]
Is added (steps 630 and 640).

Next, the head X of the loop picture path edge queue is extracted (step 650). The loop path edge X is connected to the paths ABCD and ABCW to generate a new path (step 660). In the example of FIG. 14, by connecting the loop path edge X between the first half path A⇒B, the second half path B⇒C⇒D, and the second half path B⇒C⇒W, the newly added test path A⇒B⇒X⇒ B⇒C⇒D
A⇒B⇒X⇒B⇒C⇒W
Are generated and added to the test path set,
・ A⇒B⇒C⇒D
・ A⇒B⇒C⇒W
・ A⇒B⇒X⇒B⇒C⇒D
・ A⇒B⇒X⇒B⇒C⇒W
It becomes. The above processing is performed for each of the loop path edge queues [Y, Z, W] (step 680).

Each test path extracted by the above-described loop-less test path extraction unit 32 is a minimum set of test paths covering a combination of “abnormal system scenarios not included in the loop path”. In 33, since all abnormal scenarios included in the loop route are connected to each other, the resulting test route is the minimum set of test routes that cover the combinations of “all abnormal scenarios”. That is, the number of combinations A obtained by the test path extraction unit 32 without loop and the number B of combinations obtained by the test path complementing unit 33 with loop
A × B = total number of combinations. This is because only test paths of all combinations of abnormal scenarios are extracted, so that it is possible to obtain test items with a memory usage that is overwhelmingly smaller than in the conventional technique that extracts all permutations.

  The operation of each component of the test item generation device 10 shown in FIG. 1 can be constructed as a program, installed on a computer used as the test item generation device, executed, or distributed via a network. It is.

  The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.

DESCRIPTION OF SYMBOLS 1 Design information reading part 2 Design model analysis part 3 Execution path extraction part 5 Execution path storage part 6 Test item generation part 10 Test item generation apparatus 20 User terminal 31 Design model input part 32 Loop without path extraction part 33 Test path complement with a loop Unit 34 filtering unit 35 loop path duplicating unit

Claims (7)

A test item generation device that executes a single abnormal scenario that extracts test items for scenario testing based on a use case description indicating a flow of interaction between a user and a system,
A design model input means for obtaining a use case description from the input design model;
Extracting all test paths that do not include loop paths from the use case description (hereinafter referred to as “loop without loops”), and adding the test path extraction means without loops to the test path set;
A test path including a loop path (hereinafter referred to as “path with loop”) is extracted from the use case description, and a new test path is generated by connecting the path without loop and the path with loop of the test path set. , A test path complementing means with a loop to be added to the newly added test path set,
Filtering means for extracting a test path including only a specific abnormal system scenario as a target abnormal system test path from the newly added test path set, and adding it to the abnormal system test path set;
Loop path duplicating means for duplicating and storing the loop location in each abnormal test path of the abnormal test path set in the execution path storage means;
Execution path extraction means having
A test item generation unit that reads the test path from the execution path storage unit and generates a test item for the test path;
A test item generation device that executes a single abnormal scenario any number of times. The looped test path complement means is:
Means for adding, to the loop path edge queue, an edge that does not exist in the loop-less path among edges corresponding to the arrow portion of the use case description;
The process of extracting the leading edge X of the loop path edge queue, connecting the edge X to the loopless test path to generate the new test path, and marking the loop path is performed by the loop path edge queue. Means to repeat until is empty,
Including
The filtering means includes
2. The single abnormal system scenario according to claim 1, further comprising means for extracting, from the newly added test path set, a test path including only a target abnormal system edge having the mark added to a loop path as a target abnormal system test path. Is a test item generation device that executes the number of times. The loop path duplicating means includes
2. The test item generating apparatus for executing a single abnormal system scenario an arbitrary number of times according to claim 1, further comprising means for duplicating a loop portion in the abnormal system test path by the number of times designated by a user. A test item extraction method for extracting test items for scenario testing based on a use case description indicating a flow of interaction between a user and a system,
A design model input step in which the design model input means obtains a use case description from the input design model;
A test path extraction means without a loop extracts all test paths that do not include a loop path from the use case description (hereinafter referred to as `` path without loop ''), and adds a test path without loop to add to the test path set;
A test route complementing means with a loop extracts a test route including a loop route from the use case description (hereinafter referred to as a “route with a loop”), and connects the route without the loop and the route with the loop of the test route set. A test path complementing step with a loop that generates a new test path and adds it to the newly added test path set,
A filtering step for extracting a test path including only a specific abnormal system scenario as a target abnormal system test path from the newly added test path set, and adding the test path to the abnormal system test path set;
A loop path duplicating step, wherein the loop path duplicating means duplicates and stores the loop location in each abnormal test path of the abnormal test path set in the execution path storage means;
An execution path extraction process including
A test item generating step for reading the test path from the execution path storage unit and generating a test item for the test path;
A test item generation method for executing a single abnormal scenario characterized by performing an arbitrary number of times. In the looped test path completion step,
Of the edges corresponding to the arrow part of the use case description, an edge that does not exist in the loop-less path is added to the loop path edge queue,
The process of extracting the leading edge X of the loop path edge queue, connecting the edge X to the loopless test path to generate the new test path, and marking the loop path is performed by the loop path edge queue. Repeat until is empty,
In the filtering step,
5. The single abnormal system scenario according to claim 4, wherein a test path including only a target abnormal system edge in which the mark is given to a loop path is extracted as a target abnormal system test path from the newly added test path set any number of times. Test item generation method to be executed. In the loop path duplication step,
5. The test item generation method for executing a single abnormal scenario according to claim 4, wherein the loop location in the abnormal test path is duplicated as many times as specified by the user. Computer
A test item generation program for causing each of the means of the test item generation apparatus according to any one of claims 1 to 3 to function.

Images