JP5504212B2 - Test case automatic generation system, test case automatic generation method, and test case automatic generation program - Google Patents

Description

  The present invention relates to a test case automatic generation system, a test case automatic generation method, and a test case automatic generation program. Specifically, a test case is automatically generated regardless of a format in a design document, and a test by a user is performed. The present invention relates to a technique that enables case editing and improves system verification efficiency and prevents quality degradation.

  In order to develop a high-quality system in a short period of time while high-quality system development and short delivery times are required, automatic source generation and automation of test work are being considered. As for the automation of test work, test cases, automatic generation of test data, automatic execution of tests, and automatic verification of test results are also being considered. In particular, with regard to automatic test case generation, a system that automatically generates a test case based on a design document related to a program to be tested is known.

  As such conventional technology, for example, a computer for generating test cases and test data, target screen acquisition means for acquiring a target screen for test case generation from screen transition definition information, and screen configuration information constituting the target screen In-screen column acquisition means for acquiring a test target column, column check information acquisition means for acquiring a constraint for the test target column from data definition information, matching the constraint for the test target column with a test case template, A test case generation program (see Patent Document 1) characterized by functioning as test case data generation means for generating test data has been proposed.

  Further, a plurality of pieces of test data specification information including a plurality of item information constituting the test data, attribute information indicating whether the item information is kanji, numbers, or characters, and a record length of the item information are stored. A specification file part, an item attribute parameter file part for storing a plurality of item attribute parameter information including variables corresponding to the attribute information and record length of the test data, the test data specification information stored in the specification file part, and the A test data creation system comprising a control unit that generates test data of a computer system in an internal table unit with reference to item attribute parameter information stored in an item attribute parameter file unit, wherein the control unit includes the specification file A first step of extracting test data specification information from the test section, and a test extracted by the first step A second step of extracting a plurality of item attribute parameter information corresponding to the attribute information and record length of the data specification information from the item attribute parameter file unit; and a plurality of item information of the test data specification information extracted in the first step. A third step set in the internal table unit according to the record length of the item information, a plurality of item information in the internal table unit set in the third step, a variable of the item attribute parameter information extracted in the second step There has also been proposed a test data creation system (see Patent Document 2) that executes a fourth step of generating test data by assigning data according to the above.

JP 2006-260390 A JP 2009-289083 A

  Automatic generation of test cases is possible using conventional technology. However, the design document used for the automatic generation of test cases is based on the premise that the format is fixed. For example, it cannot be applied to a design document whose format and description items are different from the fixed standard. The problem remains.

  In addition, since the format of test cases output by the conventional technology is fixed, test cases are output even for items that are not required depending on the design document. There also arises a problem of increasing itself. On the other hand, since necessary test cases may not be output, there is a possibility that the quality of the system may deteriorate due to test omission.

  SUMMARY OF THE INVENTION An object of the present invention is to provide a technology for automatically generating a test case regardless of the format in the design document and enabling the user to edit the test case, thereby improving the efficiency of system verification and preventing the deterioration of quality. .

  The test case automatic generation system of the present invention that solves the above problems is a computer that automatically generates a test case of the system based on data of a system design document, and defines items common to various design documents in advance. The storage unit storing the table and the test content definition and output condition including the items included in the description for each test case are designated by the user via the input unit and stored in the storage unit as a test information database. The process and the design document data to be processed are collated with the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched with the item of the table And storing the design information database in the storage unit and reading the design information database data from the storage unit. Pattern matching between the read data and the output condition of each test case in the test information database, the test case where the output condition is satisfied, or the test case where the output condition was not originally set For the specified test case, the data corresponding to each item included in the definition of the corresponding test case in the test information database is specified from the read design information database data, and the specified data is And an arithmetic unit that executes processing for generating a corresponding test case by setting the definition.

  In addition, the test case automatic generation method of the present invention stores a table in which tables defined in advance for items common to various design documents are stored in order to automatically generate the test cases of the system based on the data of the system design documents. A computer having a test information for each test case, the definition of the test content including the item included in the description and the output condition received from the user via the input unit and stored in the storage unit as a test information database; The design document data to be processed is collated with the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched to the table item, A process of storing the design information database in the storage unit, and reading the design information database data from the storage unit, Pattern matching between the test data and the output condition of each test case in the test information database to identify a test case where the output condition is satisfied or a test case where the output condition was not originally set And for the identified test case, data corresponding to each item included in the definition of the corresponding test case in the test information database is identified from the read design information database data, and the identified data is set in the definition And generating a corresponding test case.

  Further, the test case automatic generation program of the present invention stores a table in which tables defined in advance for items common to various design documents are stored in order to automatically generate the test cases of the system based on the data of the system design documents. A process for receiving a specification from a user via an input unit and storing it in a storage unit as a test information database with respect to a test content definition and an output condition for each test case, for each test case. The design document data to be processed is collated with the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched to the table item, The process of storing in the storage unit as a design information database, and reading the data of the design information database from the storage unit, Pattern matching between the read data and the output conditions of each test case in the test information database is performed to identify a test case that satisfies the output condition or a test case that did not originally have an output condition set. For the processing and the specified test case, data corresponding to each item included in the definition of the corresponding test case in the test information database is specified from the read design information database data, and the specified data is set as the definition. And processing for generating a corresponding test case by setting.

  According to the present invention, a test case can be automatically generated regardless of the format in the design document, and the test case can be edited by the user, so that the efficiency of system verification can be improved and the deterioration of quality can be prevented.

It is a figure which shows the structural example of the test case automatic generation system of this embodiment. It is a figure which shows the format example of the design document in this embodiment. It is a figure which shows the example of a relationship between the design items in this embodiment. It is a figure which shows the example of the design document in this embodiment. It is a figure which shows the example of a relationship of the design item data in this embodiment. It is a figure which shows the example of a table structure of a design information database and a test information database. It is a figure which shows the example of the design document table in this embodiment. It is a figure which shows the example of the design item table in this embodiment. It is a figure which shows the example of the design document detailed table in this embodiment. It is a flowchart which shows process sequence example 1 of the test case automatic generation method in this embodiment. It is a figure which shows the example of the design item data table in this embodiment. It is a figure which shows the example of the model file in this embodiment. It is a figure which shows the example of the environment setting file in this embodiment. It is a figure which shows the example of the test case in this embodiment. It is a figure which shows the example of the test case table in this embodiment. It is a figure which shows the example of the test case detailed table in this embodiment. It is a figure which shows the example of the output condition table in this embodiment. It is a flowchart which shows process sequence example 2 of the test case automatic generation method in this embodiment. It is a flowchart which shows process sequence example 3 of the test case automatic generation method in this embodiment.

  Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a diagram illustrating a configuration example of a test case automatic generation system 100 according to the present embodiment. A test system automatic generation system 100 shown in FIG. 1 automatically generates a test case regardless of a format in a design document, and also allows a user to edit a test case, thereby improving the efficiency of system verification and preventing deterioration in quality. It is.

  The hardware configuration of the test case automatic generation system 100 is as follows, for example. The test case automatic generation system 100 includes a storage unit 101 composed of a suitable non-volatile storage device such as a hard disk drive, a memory 103 composed of a volatile storage device such as a RAM, and a program 102 held in the storage unit 101. An operation unit 104 such as a CPU for performing overall control of the apparatus itself by executing it by reading it into the memory 103 and performing various determinations, calculations and control processes, an input unit 105 such as a keyboard and a mouse for accepting key inputs from the user, A display unit 106 such as a display for displaying processing data is provided. The storage unit 101 stores a program 102 for implementing functions necessary for the test case automatic generation system of the present embodiment, various tables, and data.

  Examples of tables and data stored in the storage unit 101 include a table 125 (design document table 601, design item table 602, design document detail table 603, design item data defined in advance for items common to various design documents. Table 604) and a test information database 126 (including a test case table 605, a test case detail table 606, and an output condition table 607) previously designated by the user. In addition, a template file 127, an environment setting file 128, and the like are also stored in the storage unit 101. These databases and files will be described later.

  In such an automatic test case generation system 100, the design document 10 including the screen transition definition information 5 and the data specification information 6 is registered in the design information database 125 according to the items indicated by the tables 601 to 604. The test case automatic generation system 100 automatically generates the test case 20 using the template file 127 based on the design information database 125, the test information database 126, and the environment setting file 128.

  Next, functions provided in the test case automatic generation system 100 of this embodiment will be described. As described above, the functions described below can be said to be functions that are implemented when the arithmetic unit 104 of the test case automatic generation system 100 executes the program 102, for example.

  The test case automatic generation system 100 inputs the test content definition (test case table 605, test case detail table 606) and output conditions (output condition table 607) for each test case in which the items are included in the description. It has a function of receiving designation from the user via the unit 105 and storing it in the storage unit 101 as the test information database 126.

  Further, the test case automatic generation system 100 collates the data of the design document 10 to be processed with the respective tables 601 to 604, and obtains information corresponding to each item defined in the table as the data of the design document 10. And the extracted data is stored in the storage unit 101 as the design information database 125 in accordance with the items of the tables 601 to 604.

  The design document 10 describes design items necessary for developing a program and the like. When a similar system is developed, the format differs for each project, but the design items are almost common among projects. Cheap. Therefore, the test case automatic generation system 100 according to the present embodiment performs a process of extracting the data of the design document 10 in accordance with the data items of the tables 601 to 604 and introducing the extracted data into the design information database 125. The difference in the format between the design documents 10 used for generating the data is absorbed.

  Further, the test case automatic generation system 100 reads the data of the design information database 125 from the storage unit 101, the read data, and the output conditions of each test case in the test information database 126 (the output condition table 607 indicates Information) and performing a pattern matching with the information) to specify a test case where the output condition is satisfied or a test case where the output condition was not originally set.

  In addition, the test case automatic generation system 100 specifies data corresponding to each item included in the definition of the corresponding test case in the test information database for the specified test case from the data in the read design information database 125. The test data is generated by setting the specified data in the definition.

  Note that when the test case automatic generation system 100 performs pattern matching between the data of the design information database 125 read from the storage unit 101 and the output condition of each test case in the test information database 126, the output condition is It is preferable that the combination of information shown is a regular expression, and this is pattern-matched with the data in the design information database 125.

  According to the test case automatic generation system 100 of this embodiment, the user can maintain the tables 605 to 607 in the test information database 126, and the addition of test cases to be output such as check conditions and confirmation contents to be included in the test cases is possible. , Change and delete. In addition, by designating test case output conditions, regular expressions can be introduced to ensure reliable and efficient test case output control by pattern matching.

  Subsequently, a data configuration example and the like will be described in the design document 10 to be processed in the present embodiment. FIG. 2 is a diagram showing a format example of the design document 10 to be processed in the test case automatic generation system 100 of the present embodiment. As an example of the design document 10 handled by the test case automatic generation system 100 (hereinafter referred to as the system 100), it is assumed that data in which a screen configuration definition is described on one sheet existing in one spreadsheet file. (Of course, the design document regarding the screen configuration is merely an example). In general, a sheet in a spreadsheet file is configured by arranging rectangular cells into which values can be input in a matrix arrangement vertically and horizontally, and each cell has a coordinate value indicating an arrangement in the matrix (for example, “A column”). "A3"), the absolute position on the sheet can be specified. Normally, there is no limit on the number of sheets included in one spreadsheet file, and a plurality of sheets describing a plurality of design documents 10 can be included in one spreadsheet file.

  FIG. 2 shows an example of three design document formats: a screen list 11, a screen item definition document 12, and a screen button definition document 13. The screen list 11 is a design document format that lists and expresses information on all screens designed in system development. In the example of FIG. 2, it is described in one sheet (a “screen list” tag exists in the lower left of the sheet) in one spreadsheet file.

  On the other hand, the screen item definition document 12 and the screen button definition document 13 have a design document format in which all screen items and button item information existing on each screen defined in the screen list 11 are listed and expressed. is there. In the example of FIG. 2, each sheet is described in two sheets in one spreadsheet file. Therefore, “screen item definition document” and “screen button definition document” are present at the lower left of the sheet.

  Here, the name of each sheet, that is, the sheet name is “design document” defined in the design document table 601 in order to identify which record in the design document table 601 described later corresponds to the design document 10 to be processed. The name must be the same as “Name”. Therefore, when the design document format shown in the example of FIG. 2 is considered, the design document table 601 includes three records “screen list”, “screen item definition document”, and “screen button definition document” as “design document name”. Will exist.

  Further, it is assumed that a plurality of design items described in the design document 10 exist in one design document. In the case of the example of FIG. 2, the screen list 11 has two design items, “screen ID” and “screen name”. The screen item definition document 12 has six design items of “screen ID”, “screen item ID”, “screen item name”, “control”, “digit”, and “required”. The screen button definition document 13 has three design items of “screen ID”, “screen button ID”, and “screen button name”.

  It can be assumed that the same design item exists in a plurality of design documents, that is, the screen list 11, the screen item definition document 12, the screen button definition document 13 and the like in the example of FIG. Design items existing in a plurality of design documents are design items for linking the design documents, and design documents having the same data value in the same design item are related design documents. In the example of FIG. 2, “screen ID” is described in a plurality of design documents, and the design documents having the same “screen ID” are related to each other.

  An example of the relationship between design items based on the format of such design documents is shown in FIG. It is assumed that there is a 1: N parent-child relationship between design items handled by the system 100. The parent design item is a design item that uniquely determines a child design item. A parent design item can have a plurality of child design items, but a child design item can have only one parent design item. Therefore, when the value corresponding to the parent design item is determined, the value corresponding to the child design item is automatically determined.

  In the example shown in FIG. 3, the parent-child relationship between the design items of the design document formats 11 to 13 shown in FIG. 2 is expressed. In this figure, “screen ID” is a design item that uniquely identifies a screen, and when this screen ID is determined, “screen name” is automatically determined, so between “screen ID” and “screen name”. Can have a relationship in which “screen ID” is a parent and “screen name” is a child.

  Further, since there is one “screen name” for “screen ID”, “screen ID” and “screen name” have a 1: 1 parent-child relationship. “Screen item ID” is an ID for uniquely identifying an item on the screen. Since the items on the screen are automatically determined when the screen is determined, there can be a relationship between “screen ID” and “screen item ID” in which “screen ID” is a parent and “screen item ID” is a child. Further, since there are a plurality of screen items on the screen, a 1: N parent-child relationship can be established between “screen ID” and “screen item ID”.

  “Screen item name”, “control”, and “digit” are items automatically determined when “screen item ID” is determined. “Screen item ID”, “screen item name”, “control”, “digit” "Can be related to" screen item ID "as a parent and" screen item name "," control ", and" digit "as children. Since there is one “screen item name”, “control”, and “digit” for “screen item ID”, each of “screen item ID”, “screen item name”, “control”, and “digit” There is a 1: 1 parent-child relationship.

  For the same reason as “screen item ID”, “screen button ID” has a 1: N parent-child relationship in which “screen ID” is a parent and “screen button ID” is a child. Furthermore, for the same reason as “screen button name”, “screen item name”, “control”, and “digit”, there is a 1: 1 parent-child relationship in which “screen button ID” is the parent and “screen button name” is the child. Become.

  FIG. 4 shows examples of the screen list 14, the screen item definition document 15, and the screen button definition document 16 as the design document 10 created by the user based on such a format. In the example shown in FIG. 4, there are two screens to be developed, and information on the two screens is described in a list format in the screen list 14. The screen item definition document 15 and the screen button definition document 16 are examples created for each screen, and the screen item definition document 15 describes information on two screen items existing on the screen in a list format. In the screen button definition document 16, information of one button existing on the screen is described in a list format.

  FIG. 5 shows the relationship between design items for such a design document as in FIG. In the design example illustrated in FIG. 4, there are two screen items and one button item on the screen. Therefore, in the screen ID: SCREEN01, one screen name: user registration screen, two screen item IDs: userId, userName, and one button item ID: insert exist as child design item data. Furthermore, the screen item ID: userId has four design item data that are children of the screen item name: user ID, control: text, digit: 10, and mandatory: ◯, and the screen item ID: userName. There are four design item data that are children of screen item name: user name, control: text, digit: 5, and mandatory:-. The screen button ID: insert includes one design item data as a child of the screen button name: registration.

  Next, exemplary table configurations of the design information database 125 and the test information database 126 used by the system 100 will be described with reference to FIGS.

  The design information database 125 includes four tables: a design document table 601, a design item table 602, a design document detail table 603, and a design item data table 604.

  The design document table 601 is a table for holding information related to the design document 10 that is an input of the system 100. The design document table 601 includes two items, a design document ID 701 and a design document name 702, as shown in FIG. The design document ID 701 is an item serving as a primary key of the design document table 601 and is an ID for uniquely identifying an input design document. The design document name 702 represents the Japanese name of the input design document. As described with reference to FIG. 2, the design document name 702 needs to be the same as the sheet name of the input design document in order to identify which design document is designated by the user.

  In the example of FIG. 2, the design document includes three design documents, that is, the screen list 14, the screen item definition document 15, and the screen button definition document 16. Therefore, in the example of the design document table 601 shown in FIG. Three pieces of information are registered. It is necessary to set a unique ID for the design document ID 701. For each design document ID for the screen list 14, the screen item definition document 15, and the screen button definition document 16, for example, "ScreenList" , “ScreenItem” and “ScreenButton” are set. Since the design document name 702 needs to match the sheet name of the spreadsheet file as described in FIG. 2, the design document name 702 includes “screen list”, “screen item definition document”, and “screen button”, respectively. Definition document "is set.

  The design item table 602 is a table for holding information on design items described in a design document, which is necessary for system development. As shown in FIG. 8, the design item table 602 includes three items: a design item ID 801, a design item name 802, and a parent design item ID 803. The design item ID 801 is an item serving as a primary key of the design item table 602, and is an ID for uniquely identifying the design item. The design item name 803 represents the Japanese name of the design item described in the input design document. Since the parent design item ID 802 has a 1: N parent-child relationship between the design items as described in FIG. 3, the design item ID of the parent design item is set for the child design item. It is an item.

  In the example of the design item table 602 shown in FIG. 8, two design items “screen ID” and “screen name” for “screen list” as “design items”, “screen ID” for “screen item definition document”, The six design items “screen item ID”, “screen item name”, “control”, “digit”, and “required” are “screen ID”, “screen button ID”, “screen” for “screen button definition document”. There are three design items "button name". “Screen ID” is present in all design documents of “screen list”, “screen item definition document”, and “screen button definition document”. Except for duplication, “screen ID”, “screen name” There are nine design items: “screen item ID”, “screen item name”, “control”, “digit”, “required”, “screen button ID”, and “screen button name”. Accordingly, nine pieces of information are registered in the design item table 602. It is necessary to set a unique ID for the design item ID 801, and “screen ID”, “screen name”, “screen item ID”, “screen item name”, “control”, “digit”, “required”, “ScreenId”, “ScreenName”, “ScreenItemId”, “ScreenItemName”, “ScreenItemSize”, “ScreenItemSize”, “ScreenItem”, “ScreenItemSize”, “ScreenItemSize”, “ScreenItemSize”, “ScreenItemSize”, “ScreenItemSize”, “ScreenItemSize” , “ScreenButtonId” and “ScreenButtonName” are set.

  Since the design item name 803 is the Japanese name of the design item, “screen ID”, “screen name”, “screen item ID”, “screen item name”, “control”, “digit”, “required” ”,“ Screen button ID ”, and“ screen button name ”are set. Furthermore, since the design item ID 802 of the parent item has the parent-child relationship shown in FIG. 3 between the design items, “-” indicating that “screen ID” is not set is set, and “screen name” and “screen item ID” are set. "ScreenId" is set to "ScreenId", "Screen Item Name", "Control", "Digit", "Required" is set to "ScreenItemId", and "Screen Button Name" is set to "ScreenItem Name". “ScreenButtonId” is set.

  The design document detail table 603 is a table for associating the design document 10 with the design item, and is a table for holding information indicating which design item exists at which position of the design document 10. As illustrated in FIG. 9, the design document detail table 603 includes six items: a design document ID 901, a design item ID 902, an absolute position 903, a repeat presence / absence 904, a data reading direction 905, and a registration presence / absence 906.

  The design document ID 901 and the design item ID 902 are items serving as main keys of the design document detail table 603, and indicate which design item is described in which design document. The design document ID 901 needs to be the design document ID 701 present in the design document table 601, and the design item ID 902 needs to be the design item ID 801 present in the design item table 602. The absolute position 903 is information indicating in which position of the design document the design item exists. As an example based on FIG. 2, the data for the design item: screen ID in the design document: screen list starts from the position “A2”, so “A2” is set in the absolute position 903. The repeat presence / absence 904 is information indicating whether the data of the design item is one or more between design documents. “No” is set for one and “Yes” is set for plural. The Referring to the example of FIG. 2, since a plurality of data for the design item: screen ID in the design document: screen list are described, “Yes” is set in the repeat presence / absence 904. On the other hand, since only one piece of data for the design item: screen ID in the design document: screen item definition document is described, “none” is set in the repeat presence / absence 904. The data reading direction 905 is used when there are a plurality of design item data and indicates the data repetition direction. When the corresponding design item is repeated upward, “↑” is repeated downward. “↓” is set in the case of being repeated, “←” is set in the case of being repeated in the left direction, and “→” is set in the case of being repeated in the right direction. If there is only one design item data, “-” is set. As an example based on FIG. 2, since a plurality of data for design items: screen IDs in the design document: screen list are described in the downward direction, “↓” is set in the data reading direction 905. On the other hand, since only one piece of data for the design item: screen ID in the design document: screen item definition document is described, “-” is set in the data reading direction 905. The registration presence / absence 906 is information indicating from which design document the design item data is registered with respect to the design item described in a plurality of design documents. Even if the same design item data is registered from a plurality of design documents, useless information only increases, so that the design item data can be registered only from one design document. Therefore, when the registration presence / absence 906 is “present” in a certain design document for a certain design item, the design item needs to be “not present” with respect to other design documents. In the example based on FIG. 2, the design item: screen ID is described in three design documents. Therefore, the presence / absence of registration 906 can be set to “present” only in one of these design documents. Therefore, when the registration status 906 is set to “present” in the design document: screen list, the registration status 906 can only be set to “none” in the design document: screen item definition document and the design document: screen button definition document.

  In the design detail table illustrated in FIG. 9, two records having a design document ID 901 “ScreenList”, a design item ID 902 “ScreenId”, a design document ID 901 “ScreenList”, and a design item ID 902 “ScreenName” are registered. Yes. In the example of FIG. 2, since a plurality of “screen IDs” are described downward from the position “A2”, the absolute position 903 of the record having the design document ID 901 “ScreenList” and the design item ID 902 “ScreenId” is displayed. “A2” is set to “Yes” in the repeat presence / absence 904 and “↓” in the data reading direction 905. In addition, “screen ID” is described in a plurality of design documents. In this example, since registration is performed from “screen list”, the registration presence / absence 906 is set to “present”. Therefore, in the screen item definition document 15 and the screen button definition document 16 in which “screen ID” is described, the registration presence / absence 906 is set to “none”. Similarly, since a plurality of “screen names” are described downward from the position “B2”, “B2” is displayed at the absolute position 903 of the record having the design document ID 901 “ScreenList” and the design item ID 902 “ScreenName”. “Yes” is set in the repeat presence / absence 904, and “↓” is set in the data reading direction 905. Further, since “screen name” is described only in “screen list”, the registration presence / absence 906 is set to “present”. Other design documents can be set similarly. The system 100 executes the process of extracting and setting the design document data based on the items in the tables 11 to 13 and creating the design information database 125. Since the sheet of the spreadsheet file is composed of the cells whose absolute positions are known as described above, the system 100 uses the specified cells (for example, “ A cell value is read in order from the leftmost cell in the top row such as A1 ", and the cell in which the ID or name of the corresponding design item is set is specified, and the value of the cell connected or adjacent to it, that is, the value of the design item It is sufficient to execute processing such as reading. The same applies to data extraction from the design document 10 based on other tables.

  The design item data table 604 is a table for holding design item data read from the design document 10. The design item data table 604 includes four items: a data number 1101, a design item ID 1102, a value 1103, and a parent item data number 1104. The data number 1101 is information for uniquely identifying the design item data, and is created by the system 100 automatically assigning the design item data to the design item data table 604. The design item ID 1102 indicates which design item the design item data relates to, and needs to be the design item ID 801 existing in the design item table 602. A value 1103 stores design item data read from the design document 10. As described in FIG. 5, the data number 1104 of the parent item sets the data number of the design item data that becomes the parent for the design item data that becomes the child based on the 1: N parent-child relationship between the design items. It is an item. The data number 1104 of the parent item needs to be the data number 1101 existing in the design item data table 604.

  On the other hand, the test information database 126 includes three tables: a test case table 605, a test case detail table 606, and an output condition table 607. The test case table 605 is a table that holds information on one test case to be generated. As shown in FIG. 15, the test case table 605 includes three items: a test case ID 1501, a test case name 1502, and an output condition ID 1503. A test case ID 1501 is an item serving as a primary key of the test case table 605, and is an ID for uniquely identifying a test case. The test case name 1502 represents the Japanese name of the test case. The output condition ID 1503 represents a condition for outputting a test case. Setting a value here enables output control of the test case. The output condition ID 1503 needs to be the output condition ID 1701 existing in the output condition table 607.

  The test case details table 606 is a table that stores a procedure for executing a test case in units of operations. As shown in FIG. 16, the test case details table 606 includes four items: a test case ID 1601, an operation number 1602, an output category 1603, and an operation content 1604. A test case ID 1601 and an operation number 1602 are items serving as main keys of the test case detail table 606, and indicate one operation constituting a procedure for realizing the test case. The test case ID 1601 needs to be a test case ID 1501 existing in the test case table 605. The output category 1603 indicates the category of operation. “Condition” is set for an operation that is a test case check condition, and “Confirm” is set for an operation that is a test case confirmation content. The operation content 1604 indicates a specific operation for testing. There are operations such as “Enter a value for a screen item” and “Press a button” as the check conditions, and operations such as “Check the screen status after pressing the button” as the confirmation contents is there. In addition, the design item ID 801 in the design item table 602 of the design information database 125 can be embedded in the operation content 1604. By setting the design item ID 801 in the format of “{design item ID}”, the corresponding design item ID 801 is displayed. Data can be output. The design item ID set here needs to be the design item ID 801 existing in the design item table 602. Furthermore, by making it possible to describe a function that can be used in the output file, it is also possible to output the calculation result of the function using the design item.

  The output condition table 607 is a table that stores condition information for controlling the output of the test case. The output condition table 607 includes three items: an output condition ID 1701, a design item ID 1702, and an output condition content 1703. The output condition ID 1701 is an item serving as a primary key of the output condition table 607, and is an ID for uniquely identifying the output condition. The design item ID 1702 and the output condition content 1703 represent conditions for outputting a test case, and the test case is output when the design item data for the design item ID 1702 satisfies the pattern specified in the output condition content. The design item ID 1702 needs to be the design item ID 801 existing in the design item table 602.

  Next, a process when registering the data of the design document 10 in the present embodiment in the design information database 125 will be described with reference to FIG. As described above, the system 100 extracts values for each design item of the design document table 601, the design item table 602, and the design document detail table 603 from the data of the design document 10, and corresponds to the corresponding table. Assume that data is held in the storage unit 101 in a format.

  In this case, for example, the system 100 acquires information on the folder name input by the user at the input unit 105 (step 110). For example, the system 100 accesses the corresponding folder stored in the storage unit 101 and acquires all the spreadsheet files storing the design document 10 (step 120).

  Next, the system 100 reads the spreadsheet files acquired in step 120 one by one. If there is a spreadsheet file to be read (step 130: present), the system 100 proceeds to step 140. On the other hand, when there is no spreadsheet file to be read (Step 130: No), the system 100 ends the process. The process in step 130 is repeatedly executed for all the spreadsheet files obtained in step 120 until there are no spreadsheet files to be read.

  Subsequently, the system 100 acquires a sheet describing the data of each design document 10 from the spreadsheet file acquired in step 120 (step 140). The system 100 reads all sheets of the obtained spreadsheet file one by one (step 150). If there is a sheet to be read (step 150: present), the system 100 proceeds to step 160. On the other hand, when there is no sheet to be read (Step 150: No), the system 100 returns the process to Step 130. Such processing is repeatedly executed for all sheets acquired in step 140 until there are no more sheets to be read.

  Subsequently, the system 100 acquires a sheet name from the read sheet (step 160). Further, the system 100 accesses the design document table 601 of the design information database 125, and acquires the design document ID 701 of the record in which the design document name 702 of the design document table 601 matches the acquired sheet name (step 170).

  Next, when the design document ID 701 can be acquired in step 170 (step 180: present), the system 100 advances the processing to step 190. On the other hand, when the design document ID 701 cannot be acquired in step 170 (step 180: none), the system 100 returns the process to step 150.

  Subsequently, the system 100 accesses the design document detail table 603 of the design information database 125, and obtains a record (design document detail record) in which the design document ID 901 of the design detail table matches the design document ID 701 acquired in step 170. (Step 190). The system 100 reads the acquired design document detail records one by one. If there is a design document detail record to be read (step 200: present), the system 100 advances the process to step 210. On the other hand, when there is no design document detail record to be read (step 200: no), the system 100 returns the process to step 150. Such processing is repeatedly executed for all the design document detail records acquired in step 190 until there are no more design document detail records to be read.

  Subsequently, the system 100 acquires values of design item ID 902, absolute position 903, repetition presence / absence 904, data reading direction 905, and registration presence / absence 906 from the read design document detail record (step 210). Then, the system 100 advances the process to step 230 when the registration presence / absence 906 acquired here is “present” (step 220: present). On the other hand, if the registration presence / absence 906 is “none” (step 220: none), the system 100 returns the process to step 200.

  Next, the system 100 accesses the design item table 602 of the design information database 125, and the design item ID 802 of the parent item in the record in which the design item ID 801 of the design item table 602 matches the design item ID 902 acquired in the step 210. Is acquired (step 230).

  When the system 100 has acquired the design item ID 802 of the parent item (step 240: present), the system 100 proceeds to step 250. On the other hand, when the design item ID 802 of the parent item cannot be acquired (step 240: no), the system 100 advances the process to step 260.

  Subsequently, the system 100 selects a data number corresponding to the design item ID 802 of the parent item obtained in step 230 from predetermined data numbers held in the storage unit 101 (numbered in step 280 described later). And obtained as the data number of the parent item (step 250). Of course, since the processing of step 170 to step 240 is sequentially performed from the highest parent along the parent-child relationship between the design items in the design item table 602, a data number is not yet assigned at first. The data number of the parent item cannot be acquired. Therefore, this step passes through until the process related to the design item having a parent in the parent-child relationship is performed.

  Next, the system 100 acquires data from the cell at the absolute position 903 in the corresponding sheet being processed from the step 140 (step 260). When the repeat presence / absence 904 obtained in step 210 is “present”, the system 100 acquires all data based on the data reading direction 905.

  Subsequently, the system 100 reads data one by one from all the data acquired in step 260. If there is data to be read (step 270: present), the system 100 proceeds to step 280. On the other hand, when there is no data to be read (Step 270: No), the system 100 returns the process to Step 200. Such processing is repeated for all data obtained in step 260 until there is no data to be read.

  Next, the system 100 automatically assigns a data number for the corresponding data (design item data) in order to register the data of each design item obtained in step 260 in the design item data table 604 (step 280). For automatic numbering of data numbers, a general method of incrementing numbers one by one in the order of registration may be employed.

  Subsequently, the system 100 stores the data number automatically assigned in the step 280 in the column of the data number 1101 in the design item data table 604 and the design item acquired in the step 210 in the column of the design item ID 1102 similarly. Similarly, set the ID 902, the data acquired in the step 260 in the column of the value 1103, and the data number acquired in the step 250 in the column of the parent item data number, that is, the parent data number 1104, similarly. Data registration is performed (step 290). The system 100 holds the data number automatically assigned in step 280 in the storage unit 101, and returns to step 200 (step 300). Thereafter, as long as there is a design document detail record (step 200: none → step 150), and there are sheets (step 150: none → step 130), the system 100 further continues until there are no spreadsheet files (step 130). : None → END), the above process is repeatedly executed.

  FIG. 11 is a diagram showing an example of the design item data table 604 in which the design document 10 of FIG. 4 is registered through the above flow. Here, as an example, the screen list 14 in the design document 10 will be described. The system 100 extracts and registers “screen ID” and “screen name” from the data of the screen list 14. First, since there are two “screen IDs” “SCREEN01” and “SCREEN02”, the system 100 sets “1” and “2” automatically assigned to the data number 1101 and “screen” to the design item ID 1102. Design item ID “ScreenId” of “ID” is set, and “SCREEN01” and “SCREEN02” are set to “value”, respectively. The parent data number 1104 is not set because there is no parent item design item for “screen ID”. Further, since there are two “screen names”, “user registration screen” and “result screen”, the system 100 assigns “3” and “4” automatically assigned to the data number 1101 to the design item ID 1102. Sets the screen name design item ID: ScreenName, and sets the value 1103 to “user registration screen” and “result screen”. Since the design item of the parent item for “screen name” is “screen ID”, the system 100 sets “1” as the parent data number 1104 of “user registration screen” and the parent data number of “result screen”. “2” is set as 1104. Other items are set similarly.

  Next, test case automatic generation processing will be described. First, a file used by the system 100 for automatic test case generation will be exemplified. FIG. 12 is a diagram showing an example of a template file 127 used by the system 100. The template file 127 used when the system 100 automatically generates a test case can be assumed to be a spreadsheet file as in the design document 10. The system 100 creates a test case to be output based on the design item data held in the design information database 125, the test case definition held in the test information database 126 in advance and the output conditions thereof, and this is used as a template. The test case (file) is automatically generated by applying to the file 127 and outputting. One spreadsheet file is created for each design item data corresponding to the design item ID specified in the environment setting file 128 described in FIG. 13, and one test case is output to one sheet.

  FIG. 13 is a diagram showing an example of the environment setting file 128 used by the system 100. The environment setting file 128 used when the system 100 automatically generates test cases can be assumed to be a text file. In the environment setting file 128, a design item ID serving as an output unit of the test case is designated. In the system 100, a test case is created based on design item data for the design item ID specified in the environment setting file 128 and data of all design items associated with the design item. In the example of FIG. 13, since “screen ID” is designated as the design item ID, in this case, the system 100 generates test cases based on the data of all the design items hanging from the screen ID: SCREEN01 shown in FIG. create.

  Next, an example of the test case 20 automatically generated by the system 100 will be shown. In the example shown in FIG. 14, the test case 20 is composed of three test cases of “required check (no input)”, “number of digits that can be entered (number of digits)”, and “number of digits that can be entered (number of digits + 1)”. ing.

  Among them, the “required check (not input)” is a test case for confirming whether an input error occurs when an input is not made for an item that is specified as required. In addition, “Number of digits that can be entered (number of digits)” and “Number of digits that can be entered (number of digits + 1)” are test cases to confirm that only the number of digits can be entered for the input items on the screen. Two patterns for the number of digits and (number of digits + 1) are prepared as patterns of the number of characters input to the item.

  Further, the “required check (not entered)” test case is a test case that is executed only for items in which “required” is “O” among design items. In the example of FIG. Since “required” is “O” only for “user ID”, the result of outputting one test case for “user ID”, that is, the test case of “required check (not entered)” shown in FIG. It has become. Each test case of “number of digits that can be entered (number of digits)” and “number of digits that can be entered (number of digits + 1)” is a check to be performed on all screen items, and “user ID” and “user name”. Check against both. Moreover, the sheet of the spreadsheet file to be output is a test case unit.

  Next, a table constituting the test information database 126 used when the system 100 automatically generates test cases will be described. FIG. 15 is a diagram illustrating an example of the test case table 605. The test case table 605 exemplified here relates to three test cases of “required check (no input)”, “number of digits that can be entered (number of digits)”, and “number of digits that can be entered (number of digits + 1)” as test cases. A total of 3 records are registered. Such a record is set in advance by the user in charge of the test, and can be updated by the user as necessary (the system 100 displays the table on the output unit 106, and the user inputs an instruction using the input unit 105). Receive). Thereafter, the system 100 also displays information for other tables in the same manner, and accepts instructions such as browsing, updating, and deletion by the user to enable data updating and the like. Accordingly, in the test case table 605 of FIG. 15, the system 100 displays the corresponding information on the output unit 106 for user browsing, such as addition or deletion of a test case, change of the test case name 1502 or output condition ID 1502, and the like. In response, the input unit 105 receives a change instruction and updates the corresponding data.

  In this test case table 605, since the test case ID 1501 is information unique to each test case, “required check (no input)”, “number of digits that can be entered (number of digits)”, “number of digits that can be entered ( “TC001”, “TC002”, and “TC003” are set as non-overlapping values for each of “digit number + 1)”. Since the test case name 1502 represents the Japanese name of the test case, “required check (not entered)”, “number of digits that can be entered (number of digits)”, and “number of digits that can be entered (number of digits + 1)” Is set. The output condition ID 1503 controls the output of the test case, and the test case “required check (not input)” has a condition that it is output only when “required” is “O”. For example, “OP001” indicating the corresponding condition is set in the ID 1503. On the other hand, each test case of “number of inputtable digits (number of digits)” and “number of inputtable digits (number of digits + 1)” is a test case that is output for all screen items. The output condition ID 1503 is not set.

  Further, the test case details table 606 constituting the test information database 126 includes a table in which execution procedures are described for each test case (three test cases in the above example), as illustrated in FIG. Become. Here, the test case: mandatory check (not entered) will be described. Test case: Mandatory check (no input) is composed of a total of eight operations: an operation related to five check conditions and an operation related to three confirmations.

  In the operation content 1604, {design item ID} is embedded, and in the test case automatically generated by the system 100, the description of the design item ID is data of the corresponding design item (extracted from the design document 10). Replaced with and output.

  In FIG. 16, the operation content 1604 whose operation number 1602 is “1” is “{ScreenId}: {ScreenName} is displayed”, and “ScreenId” and “ScreenName” are embedded as design item IDs. Therefore, in the case of FIGS. 4 and 8, as a test case, {ScreenId} is replaced with “SCREEN01” and {ScreenName} is replaced with “User registration screen”, and “SCREEN01: User registration screen is displayed. Is output ". In addition, the operation content 1604 with the operation number 1602 “2” is “uninput the following items”, and the design item ID is not embedded, so the output is output as it is. Also, the operation content 1604 with the operation number 1602 “3” is “ScreenItemId”: {ScreenItemName}, and “ScreenItemId” and “ScreenItemName” are embedded as design item IDs. In this case, there are two screen items, and two lines of “userId: user ID” and “userName: user name” are output. The other operation number records are also output in the same manner.

  FIG. 17 is a diagram illustrating an example of the output condition table 607. In the above examples, there is “required check (no input)” as a test case for which output control is desired. Therefore, in the output condition table 607 of FIG. 17, one record is registered as an output condition for a test case of “essential check (not input)”. In the condition indicated by this record, a test case of “required check (not input)” is output as a test case when “required” for the screen item is “◯”. The output condition ID 1701 is an ID for uniquely identifying the output condition, and “OP001” is set here. In addition, since the output condition regarding the test case of the “required check (not input)” is that “required” for the screen item is “O”, the design item ID 1702 has a design for “required”. Item ID: ScreenItemNessary is set, and “◯” is set in the output condition contents 1703.

  Next, a process in which the system 100 automatically generates the test case 20 based on the design information database 125 and the test information database 126 will be described with reference to FIGS. First, the system 100 acquires a design item ID corresponding to the screen ID from the environment setting file 128 illustrated in FIG. 13 (step 510).

  Next, the system 100 accesses the design item data table 604 of the design information database 125, and the record in which the design item ID 1102 of the design item data table 604 matches the design item ID acquired in step 510, that is, the design item data. A record is acquired (step 520).

  Further, the system 100 reads the design item data records acquired in the step 520 one by one. If there is a design item data record (step 530: present), the system 100 proceeds to step 540. On the other hand, when there is no design item data record (step 530: No), the system 100 ends the process. Such processing is repeatedly executed until the design item data record obtained in step 520 is eliminated.

  Subsequently, the system 100 acquires the data number 1101 from the record acquired in step 520 (step 540). In addition, the system 100 accesses the design item data table 604 of the design information database 125, and in the parent-child relationship that continues with the data number 1101 acquired in the step 540 as a vertex, the data of the design item that is a child until there are no children. All are acquired (step 550). That is, the system 100 creates information corresponding to FIG. 3 and FIG.

  The system 100 accesses the test case table 605 of the test information database 126 and acquires records of all test cases (step 560). The system 100 reads the test case records acquired here one by one. If there is a test case record (step 570: present), the system 100 proceeds to step 580. On the other hand, when there is no test case record (step 570: No), the system 100 ends the process. Such processing is repeatedly executed until there is no test case record obtained in step 560.

  Subsequently, the system 100 acquires the output condition ID 1503 from the record acquired in Step 570 (Step 580). Further, when the output condition ID 1503 can be acquired in step 580 (step 590: present), the system 100 advances the process to step 600. On the other hand, when there is no output condition ID 1503 (step 590: none), the system 100 advances the process to step 650.

  Following the step 590, the system 100 accesses the output condition table 607 of the test information database 126, and outputs an output condition record in which the output condition ID 1701 of the output condition table 607 matches the output condition ID 1503 acquired in the step 580. Obtain (step 600).

  The system 100 acquires the design item ID 1702 and the output condition content 1703 from the output condition record acquired in step 600 (step 610). Further, the system 100 acquires the value 1103 of the design item corresponding to the design item ID 1702 acquired here from the information acquired and created in the step 550 (step 620).

  Next, the system 100 matches the value 1103 of the design item acquired in step 620 with a regular expression for the output condition contents 1703 acquired in step 610 (step 630). A regular expression is a notation method for expressing a pattern of a character string, and is used when searching and replacing a character string. Sometimes called regular expression. In this regular expression, a combination of a normal character and a symbol having a special meaning called a metacharacter is used. By using regular expressions, you can specify “characteristics” (patterns) without specifying a character string directly, so you can search by absorbing fluctuations in the notation or replace multiple different character strings at once. You can do it. For example, “^” means “beginning of line”, “.” Means “any one character”, and “+” means “one or more repetitions of the immediately preceding element”. Accordingly, in order to describe the contents indicated by the output condition contents 1703 using such regular expressions, the system 100 is provided with dictionary data and a predetermined conversion algorithm in advance for defining the regular expressions, and the output condition contents A regular expression is generated by using 1703 as an input, and based on this, a pattern matching with the value 1103 of the design item acquired in step 620 is performed.

  As a result of pattern matching, when the output condition content 1703 matches the value 1103 of the design item acquired in step 620 (step 640: Yes), the system 100 determines that output is possible for the corresponding test case, If no match is found (step 640: NO), it is determined that output is not possible.

  Subsequently, the system 100 advances the processing to step 650 when output is possible (step 640: yes) based on the result of whether output is possible at step 640. On the other hand, when the output is impossible (step 640: NO), the system 100 returns the process to step 570.

  The system 100 acquires a test case ID 1501 and a test case name 1502 from the test case record acquired in step 560 (step 650). In this case, the system 100 copies a sheet whose sheet name is “template” from the template file 127, and creates a new sheet having the acquired test case name 1502 as the sheet name (step 660).

  Next, the system 100 accesses the test case detail table 606 of the test information database 126, and a record in which the test case ID 1601 of the test case detail table 606 matches the test case ID 1501 acquired in step 650, that is, a test case detail record. Is obtained (step 670).

  Further, the system 100 reads the test case detail records acquired in the step 670 one by one. If there is a test case detail record (step 680: present), the system 100 advances the process to step 690. On the other hand, if there is no test case detail record (step 680: No), the system 100 returns the process to step 570. Such processing is repeatedly executed until there is no test case detail record obtained in step 670.

  Subsequently, the system 100 acquires the output category 1603 and the operation content 1604 from the test case detail record acquired in Step 670 (Step 690). The system 100 acquires a design item ID included in the operation content 1604 acquired here (step 700). In this case, the system 100 treats a value between “{” and “}” in the operation content 1604 as a design item ID.

  The system 100 acquires the design item value 1103 corresponding to the design item ID acquired in step 700 from the information acquired and created in step 550 (step 710). Further, the system 100 replaces the design item value 1103 acquired in step 710 with the design item ID included in the operation content 1604 obtained in step 690 (step 720).

  Based on the output category 1603 such as “condition” and “confirmation” acquired in step 690, the system 100 creates the operation content created in step 720 from the sheet (from the template file 127 in step 660). Sheets (see FIG. 12 for the format) are output to the cells of the corresponding output category, thereby performing test case generation / output processing (step 730). By performing such processing, the test case 20 illustrated in FIG. 14 (of which output is possible) is generated. After outputting such a test case, the system 100 returns the process to step 680. Thereafter, until there is no test case detail record (step 680: none → step 570), until there is no test case record (step 570: none → step 530), until there is no design item data record (step 530: none → END). The system 100 repeats the process.

  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, test cases can be automatically generated for various design documents having different formats, and the amount of work can be reduced by omitting the test case generation work. In addition, test cases that are automatically generated can be added, changed, or deleted by the user, and the amount of work increases due to the digestion of unnecessary test cases, and the quality deteriorates due to test omission due to the lack of necessary test cases being output. Can be prevented.

  Therefore, the test case can be automatically generated regardless of the format in the design document, and the test case can be edited by the user, thereby improving the efficiency of system verification and preventing the deterioration of the quality.

  At least the following will be clarified by the description of the present specification. That is, in the test case automatic generation system, the calculation unit performs the pattern matching between the design information database data read from the storage unit and the output condition of each test case in the test information database. It is also possible to use a combination of information indicated by a regular expression and pattern match this with the data in the design information database.

5 Screen transition definition information 6 Data specification information 10 Design document 20 Test case 100 Test case automatic generation system 101 Storage unit 102 Program 103 Memory 104 Operation unit 105 Input unit 106 Output unit 125 Design information database 126 Test information database 127 Model file 128 Environment Setting file 601 Design document table 602 Design item table 603 Design document detail table 604 Design item data table 605 Test case table 606 Test case detail table 607 Output condition table

Claims (4)

A computer that automatically generates a test case of the system based on data of a system design document,
A storage unit storing a table defined in advance for items common to various design documents;
For each test case, with respect to the test content definition and output condition in which the item is included in the description, a process of receiving a designation from the user via the input unit and storing it in the storage unit as a test information database;
The design document data to be processed is checked against the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched to the table item to design Processing stored in the storage unit as an information database;
Read the design information database data from the storage unit, perform pattern matching between the read data and the output condition of each test case in the test information database, and the test case or output that satisfies the output condition Processing to identify test cases for which conditions were not originally set,
For the specified test case, data corresponding to each item included in the definition of the corresponding test case in the test information database is specified from the read design information database data, and the specified data is set in the definition. An arithmetic unit that executes a process of generating the corresponding test case in
Automatic test case generation system with The computing unit is
When performing pattern matching between the design information database data read from the storage unit and the output conditions of each test case in the test information database, a combination of information indicated by the output conditions is used as a regular expression, and this is used as the design information. The test case automatic generation system according to claim 1, wherein pattern matching is performed on data in a database. In order to automatically generate a test case of the system based on the data of the system design document, a computer having a storage unit storing a table defined in advance for items common between various design documents,
For each test case, with respect to the test content definition and output condition in which the item is included in the description, a process of receiving a designation from the user via the input unit and storing it in the storage unit as a test information database;
The design document data to be processed is checked against the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched to the table item to design Processing stored in the storage unit as an information database;
Read the design information database data from the storage unit, perform pattern matching between the read data and the output condition of each test case in the test information database, and the test case or output that satisfies the output condition Processing to identify test cases for which conditions were not originally set,
For the specified test case, data corresponding to each item included in the definition of the corresponding test case in the test information database is specified from the read design information database data, and the specified data is set in the definition. To generate the corresponding test case in
The test case automatic generation method characterized by performing this. In order to automatically generate a test case of the system based on the data of the system design document, a computer having a storage unit storing a table defined in advance for items common to various design documents,
For each test case, with respect to the test content definition and output condition in which the item is included in the description, a process of receiving a designation from the user via the input unit and storing it in the storage unit as a test information database;
The design document data to be processed is checked against the table, information corresponding to each item defined in the table is extracted from the design document data, and the extracted data is matched to the table item to design Processing stored in the storage unit as an information database;
Read the design information database data from the storage unit, perform pattern matching between the read data and the output condition of each test case in the test information database, and the test case or output that satisfies the output condition Processing to identify test cases for which conditions were not originally set,
For the specified test case, data corresponding to each item included in the definition of the corresponding test case in the test information database is specified from the read design information database data, and the specified data is set in the definition. To generate the corresponding test case in
A test case automatic generation program characterized in that

Images