JP5292956B2 - Test data generation program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automatically generate test data enough to perform a correct test of a business application. <P>SOLUTION: Schema related information representing relation definition and relation multiplicity between a first table and a second table, section state information about a combination that can be operationally adopted between the section and the state of the first table, and schema item information of the first table and the second table are used to specify a combination that can be operationally adopted between the section and the state from the section state information, a record of the first table corresponding to the combination is generated according to the schema item information of the first table, a variation in a correspondence relation between a record of the first table and a record of the second table is specified from the schema related information and a multiplicity upper limit, a record is generated according the schema item information, and a record of the second table required in accordance with the variation is generated according to the schema item information and the schema related information. <P>COPYRIGHT: (C)2009,JPO&amp;INPIT

Description

  The present technology relates to a technology in the field of automatically generating test data used in a test of a business application program or the like.

  When testing a business application program or the like, it is necessary to create a test execution environment, but some data must be registered in the database as the test execution environment. In that case, there were the following problems.

(A) Registration of business-consistent data Data to be registered in the database must be business-consistent data. If data is not registered in the database in consideration of this point, The correct test may not be performed.

  As an example of creating data using DB schema information, for example, Japanese Patent Laid-Open No. 2000-20529 exists, but not all business rules can be expressed only by schema information.

  For example, as shown on the left side of FIG. 1, the “user” class and the “user history” class have a 1: n relationship. The “user” class is mapped to the “user” table, and the “user history” is mapped to the “user history” table. This is based on information obtained from the schema information, but when test data is generated from this schema information, as shown on the right side of FIG. The records in the “user history” table are associated with 0 to n.

  However, in business, the relationship between the “user” class and the “user history” class may differ depending on the user category. For example, when the user is an individual category, the “user history” class is not mapped to the “user” class, and when the user is a corporate category, the “user history” class is assigned to the “user” class. May be associated with 0 to n. In such a case, the mapping between the user (individual) and the user history on the right side of FIG. 1 is data that is not consistent in business. Accordingly, it is necessary not to generate a “user history” record corresponding to a “user (individual)” record, but such a record generation cannot be performed only from schema information.

(B) Generation of test data having completeness in processing Data registered in the database can take values of various states and types according to business processes. It is important to register test data for all these states and types. Otherwise, for example, whether the result of the search process is a result of a correct search, or whether the search target data does not contain data that should not be hit even though it is not correctly processed. This is because they cannot be distinguished.

Regarding the completeness in the processing of test data, there has conventionally been a method of extracting processing branch conditions from source code and extracting the data type as a threshold value. However, it is expensive to read the source code by humans, and automatic static analysis has been reported to be successful only for very small-scale applications. very difficult.
JP 2000-20529 A

  As described above, in the conventional method, test data having business consistency in a business application program cannot be automatically generated and registered in the database. In addition, with the conventional method, it is impossible to automatically generate test data that guarantees the completeness of processing of the business application program to be tested. Therefore, with the conventional method, it is not possible to generate sufficient test data for performing a correct test on the business application program.

  Therefore, an object of the present technology is to automatically generate sufficient test data for performing a correct test on a business application program.

  The test data generation method according to the first aspect is a combination of schema-related information representing the relationship between the first table and the second table and the relational multiplicity, and the division and state of the first table that can be taken in business. Access to a design information storage unit that stores partition state information regarding the first table and schema item information of the first table and the second table, and a database that stores data of the first table and data of the second table It is executed by a computer that is capable. Then, a combination of divisions and states in the first table that can be taken in the business is identified from the division state information stored in the design information storage unit, and the schema item information of the first table stored in the design information storage unit The first table record and the second table record are generated from the step of generating the record of the first table corresponding to the combination according to the above and registering it in the database and the schema related information stored in the design information storage unit When there is an ungenerated record that is a record of the first table that is necessary for the above-described variation and a variation specifying step that specifies a variation of the correspondence relationship, the first stored in the design information storage unit A new record is generated according to the schema item information of table 1 and stored in the database In accordance with the relationship between the first table and the second table in the first table non-generated record generation step to record, the schema table information of the second table stored in the design information storage unit and the schema related information A second table record generation step of generating a record of the second table required according to the variation and registering it in the database.

  The test data generation method according to the second aspect includes the schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each partition value, and the first table and the second table. It is executed by a computer that can access a design information storage unit that stores schema item information and a database that stores data of the first table and data of the second table. Then, the variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and according to the variation of the partition value according to the schema item information of the first table stored in the design information storage unit From the step of generating the record of the first table and registering it in the database, and the relational multiplicity for each section value of the schema related information stored in the design information storage unit, the record of the first table and the second table If there is a variation specifying step for specifying the variation of the correspondence relationship with the table record, and a record of the first table that is necessary for the above variation and is not generated, it is stored in the design information storage unit. A new record is generated according to the schema item information of the first table, and the database In accordance with the relationship between the first table and the second table in the first table non-generated record generation step to be registered in the schema table information and schema related information of the second table stored in the design information storage unit, A second table record generation step of generating a record of the second table required according to the variation and registering it in the database.

  The test data generation method according to the third aspect includes the first and second tables, the relationship between the relation tables of the first and second tables, and the division between the related data items in the first and second tables It is executed by a computer that can access the schema related information representing the relational multiplicity for each value, the design information storage unit storing the schema item information of each table, and the database storing each table. Then, the variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the first and the second according to the variation of the partition value according to the schema item information stored in the design information storage unit Including the related data item from the step of generating the record of the table of 2 and registering it in the database, and the relational multiplicity for each division value between the related data items of the schema related information stored in the design information storage unit When there is an ungenerated value that is a value of the related data item of the first and second tables required in the variation specifying step for specifying the record variation of the table and the record variation of the relation table, According to the schema item information of the first and second tables stored in the design information storage unit A new record including the value of the related data item in the first and second tables, and registering it in the database, and using the records in the first and second tables registered in the database, Generating a table record and registering it in the database. In the variation specifying step described above, the relational multiplicity is a to n: b to m (n and m are integers of 2 or more. A is an integer of 0 to less than n. B is an integer of 0 to less than m. ) Includes a development step of developing into a plurality of sub-variations including n: m. In addition, when the relation table generation step described above generates a record group of a relation table for an n: m sub-variation, the number of relations between records indicating the influence spread range at the time of data item change in the record group. Includes n values of related data items in the first table and m values of related data items in the second table so that the maximum value is less than or equal to the upper limit value of the number of relations between records specified. Preparing one or a plurality of sets.

  Sufficient test data can be automatically generated to correctly test business application programs.

[Embodiment 1]
FIG. 2 shows a functional block diagram of the test data generation apparatus 100 according to an embodiment of the present technology. The test data generation device 100 includes an input unit 1 that receives input of setting information and design information from a user, a design information storage unit 3 that stores design information including schema related information, category / state information, and schema item information, A design information reading unit 5 for reading out necessary design information from the information storage unit 3, a variation of test data to be generated using the design information read by the design information reading unit 5 and the setting information from the input unit 1, etc. The data generation determination unit 7 that performs the determination process, the variation data storage unit 9 that stores the processing result of the data generation determination unit 7, and the data stored in the variation data storage unit 9 and the design information reading unit 5 And a data generation unit 11 that generates test data using the designed design information and the like. Note that the test data generated by the data generation unit 11 is registered in the database (DB) 13, and the business application program is tested using the DB 13.

  Below, the example which produces | generates the data represented by a class diagram as shown in FIG.3 and FIG.4 as test data is demonstrated as a 1st example. As shown in FIG. 3, a class “user history” is associated with a class “user” in the form of aggregation. A user table corresponds to the “user” class, and a user history table corresponds to the “user history” class. For each record in the “user” table, 0 to n records are associated with the user history table. Such a relationship between the “user” class and the “user history” class is described as a relationship multiplicity of 1: n. Also, as shown in FIG. 4, the “user” class has two sections. That is, it has a “person / organization” category and a “user” category. With these combinations, for example, in the case of an insurance contract, an “individual user” corresponding to an individual contractor, an “organization user” corresponding to a corporate contract person, an “individual user relationship” corresponding to a company where the individual user works, and an association user belong "Group user relations" that correspond to local governments, local groups, and groups with interests, "individual claimers" who are not individual contractors but who claim complaints on the contents, but are not subject to corporate contracts, but claim claims on the contents Represents a “group Kramer” that corresponds to a coming group. As a specific definition of the data, the “individual / organization” category includes “organization” (category value = 1) and “individual” (category value = 2). Furthermore, the “user” category includes “user” (category value = 1), “user relationship” (category value = 2), and “kramer” (category value = 3). As a result, a subclass “individual user” having a classification value of “individual” in the “individual / organization” category and a classification value of “user” in the “user” category, and “individual / organization” category “individual” ”And the“ user ”category, and the“ user relationship ”subclass“ personal user relationship ”, the“ individual / organization ”category“ individual ”and“ user ” ”Having a classification value of“ Creamer ”in the“ Class ”and a subclass of“ Individual Kramer ”, a classification value of“ Group ”in the“ Individual / Group ”classification, and a classification value of“ User ”in the“ User ”classification. “Group user” with a subclass of “Group user” and “Group” in the “Individual / Group” category and “User relationship” in the “User” category And subclasses, and subclass of "individuals or groups" the classification value of "organization" has and "user" in divided by partition having a partition value of "Kramer" "organization Kramer" is defined.

  Although not shown in FIGS. 3 and 4, in the first example, it is assumed that the “user” class has three states of “unregistered”, “registered”, and “registered deleted”. However, some subclasses do not have the above state. Specifically, the “registered” state and the “registration deleted” state do not exist in the “individual user relationship” subclass and the “group claimer” subclass.

  Next, processing contents of the test data generation apparatus 100 will be described with reference to FIGS. First, the input unit 1 performs a display as shown in FIG. 6 for example to the user, prompts the user to input setting information, accepts the input of setting information, and stores it in a storage device such as a main memory. . Further, the input of design information is further prompted, and the input of design information is accepted and stored in the design information storage unit 3 (step S1). In the screen example of FIG. 6, an input field for a table (schema) name to be generated, an input field for the minimum number of generations per type, and a designation input field for the related multiplicity m (also called the upper limit of multiplicity) are provided. It has been. “Minimum number of generations per type” designates the number of records to be generated for each possible combination of subclass and status. The relational multiplicity m is an upper limit value of n when the relational multiplicity between the “user” class and the “user history” class shown in FIG. 3 is 1: n. Here, it is understood that the name of the table to be generated is “user”, the minimum number of generations per type is “1”, and the designation of the relational multiplicity n is “2”.

  The design information includes information shown in FIGS. FIG. 7 shows an example of schema related information. The schema related information includes a related table name “user history” related to the generated “user” table, a related column (foreign key column) name “user number”, and a relational multiplicity “0..n”. It is. “0..n” indicates 0 to n.

  FIG. 8 shows an example of the category / state information. The category / state information indicates a combination of a subclass and a state. In FIG. 8, in the “individual user” subclass (individual / organization category = 2, user category = 1), there are states of “unregistered”, “registered”, and “deregistered”. In the group category = 1, user category = 1), there are states of “unregistered”, “registered”, “deregistered”, and the “personal user relationship” subclass (individual / organization category = 2, user category = 2) Only has an “unregistered” state, and the “group user relationship” subclass (individual / organization category = 1, user category = 2) has a status of “unregistered”, “registered” and “deregistered”. , “Individual Kramer” subclass (individual / group classification = 2, user classification = 3) has states of “unregistered”, “registered”, “deregistered”, and “group Kramer” subclass (individual / group classification = 1, user classification = 3) Only recording "condition exists. In this way, there are theoretically 3 × 6 = 18 types of records, but since there is a state that does not exist in business, 14 types of records are generated.

  FIG. 9 shows an example of schema item information of the user table. In FIG. 9, for each column (user number, individual / organization classification, user classification, name, address, registration date, deletion date) of the user table record, whether or not it is a “primary key”, a value in an “unregistered” state Presence / absence, presence / absence of a value in the “registration” state, presence / absence of a value in the “registration deletion” state, a mandatory category indicating whether it is essential, and data attributes are registered. In the data attribute, a rule (format, etc.) and a possible value to be generated are defined. Specifically, half-width alphanumeric characters [10] are replaced by half-width alphanumeric characters [A,. . . Z, 0,. . . 9] represents a fixed 10-digit character string. In the present embodiment, [] represents a fixed number, and () represents within. Therefore, full-width (100 bytes) indicates that it is within 100 bytes of full-width characters.

  Furthermore, in this example, the primary key is “user number”, the required columns are “user number”, “individual / organization category”, and “user category”, and the registration date is registered only in the “registered” state. The deletion date is registered only in the “registration deletion” state. For the “unregistered” state, neither the registration date nor the deletion date is registered.

  Data as shown in FIGS. 7 to 9 is input to the input unit 1 in a machine readable format, and is stored in the design information storage unit 3 by the input unit 1. The schema item information (FIG. 15) of the “user history” table is also input and stored in the design information storage unit 3.

  Next, the design information reading unit 5 reads design information (schema related information, category / state information, schema item information) from the design information storage unit 3 (step S3). The contents of the data as described above can be grasped.

  Then, the data generation determination unit 7 specifies the variation of the record to be generated in the user table based on the classification / state information and the input setting information, and stores the data about the variation in the variation data storage unit 9 (step S5). From the category / state information shown in FIG. 8, it is found that there are 14 types of combinations of subclasses and states that can be taken in the business, and as shown in FIG. 6, “minimum number of generations per type” is “1”. Therefore, it is specified that 14 records are generated with one record per type. In this way, variation data storage unit 9 stores variation data indicating that 14 types of records specified from the category / state information are generated one by one.

  Thereafter, the data generation unit 11 generates a record required for the variation stored in the variation data storage unit 9 according to the read schema item information, and registers it in the DB 13 (step S7). For example, the data generation unit 11 has a generation method related to a character string such as “half-width alphanumeric characters”, “half-width characters”, “full-width characters”, and “numbers”, and by inputting a length, a predetermined rule (for example, random , “CUSTOM_” + “number (number of digits matches the total number of digits)” according to the column name such as “user number”, rule to make each value unique if it is a primary key) Automatically generates a string that conforms to

  For example, when a “unregistered” state record is generated in the “group user” subclass, the “user number” as the primary key is set according to the data attribute of half-width alphanumeric character [10] according to the schema item information of FIG. Generate. Since it is a primary key, the value must be unique, and as described above, it is generated according to a rule such as “CUSTOM _” + “three-digit number”. The individual / group classification is “1” because it is “group user”, and the user classification is “1” because it is “group user”. Since “name” is full-width (100 bytes) and “address” is full-width (200 bytes), a character string of length is generated by randomly extracting from a set of hiragana, alphanumeric symbols, common kanji, and katakana To do. However, as for the address, a zip code may be randomly generated and the address corresponding to the zip code may be used as the “address”. In this case, a dictionary that associates the zip code with the address is required. In this way, the first record in FIG. 10 is generated.

  The second to fourteenth records in FIG. 10 are similarly generated according to the variations specified above. Note that the registration date and the deletion date required in the schema item information of FIG. 9 are generated according to a predetermined rule according to the format of YYYY / XX / ZZ. For example, processing such as randomly generating a date for one week including the processing date may be performed. In this way, one each of 14 types of records is generated.

  Then, the data generation determination unit 7 determines whether there is an ungenerated related table (step S9). For example, with reference to schema related information included in the design information, it is determined whether an ungenerated related table exists. If it is determined that there is an ungenerated association table, the process proceeds to the process in FIG. In this example, since the “user history” table has not yet been generated, it is assumed that the process proceeds to the process of FIG.

  On the other hand, if it is determined that there is no ungenerated related table, the data generation determination unit 9 outputs a display including a processing result as shown in FIG. 11 to the user (step S11). FIG. 11 shows that 42 records are stored in the “user” table, 42 records are stored in the “user history” table, and the generated data is stored in the \ CreatedData \ 20070618_moura folder.

  Shifting to the description of the processing in FIG. 12, the data generation determination unit 7 is input by the input unit 1 and the classification / state and relational multiplicity of the columns of the related table to be generated included in the schema related information. The variation of the record of the related table to be generated is determined from the relational multiplicity m, and the variation data is stored in the variation data storage unit 9 (step S13).

  In this example, 0. 0 is placed between the record of the “user” table and the record of the “user history” table. . The existence of n aggregated relationships is specified by the schema related information (FIG. 7). In FIG. 7, the “user history” table does not define the category / state. That is, the record of the “user” table and the record of the “user history” table simply have a relationship of 1: m (m is an integer including 0 here). Therefore, in the present embodiment, “user” table record: “user history” table record = 1: 0, “user” table record: “user history” table record = 1: 1, “user” table Records: three patterns of “user history” table record = 1: m are generated. Note that m is determined by the upper limit of multiplicity specified by the user. In the input example in FIG. 6, “user” table record: “user history” table record = 1: 2.

  Note that, with respect to the record of the “user” table, the record of the “user history” table and p (positive integer). . When there are n aggregated relations, “user” table record: “user history” table record = 1: p, “user” table record: “user history” table record = 1: m 2 Generate one pattern.

As mentioned above, in this example,
“User” table record: “User history” table record = 1: 0
“User” table record: “User history” table record = 1: 1
“User” table record: “User history” table record = 1: 2
These three patterns are required. The record “1” in the “user” table means that the set of 14 types of records is “1”, and since only one set is generated in step S7, the 14 types of records in the “user” table 2 sets are required. For the records in the “user history” table, one set (14 types) for each set of 14 types of records in the “user” table and 14 types of records in the “user” table Two sets (14 types × 2) are required for each set. In total, 14 × 3 = 42 records in the “user” table (however, 14 records have been generated in step S7), and 14 × 3 = 42 records in the “user history” table should also be generated. .

  This is illustrated from another angle as shown in FIG. That is, for one type of record in the “user” table (for example, “group user (unregistered)” record), there are “no”, “one”, and two “user history” records. There are 14 patterns of 3 patterns. Such variation data is stored in the variation data storage unit 9.

  Next, the data generation unit 11 specifies the foreign key (for example, “related column” in the schema related information. Or “specifies a column having the same name in the related source table and the related table from the schema item information). It is determined whether there is an unused value (step S15) For example, when a foreign key value has already been specified by a user or the like, there is an unused value among the specified foreign keys. If such a value exists, the data generation unit 11 uses the unused value of the foreign key to record one record of the related table according to the schema item information of the related table. (Step S17) After that, has the data generation unit 11 generated all the necessary variations identified in Step S13? (Step S19) If the data has not been generated for all variations, the process returns to Step S15, where there is no unused value for the foreign key in this example. When the variation is generated, the process returns to step S9 in FIG.

  If it is determined in step S15 that an unused value of the foreign key does not exist, the data generation unit 11 stores the column corresponding to the foreign key (“user number”) in the related source table (“user” table in this example). It is determined whether there is an unused value in the column (step S21). In this example, the record group (FIG. 10) of the “user” table generated in step S7 corresponds to one record in the “user” table among the variations identified in step S13. Since it is used for a variation of no record, it is determined that there is no unused value in the foreign key corresponding column.

  If it is determined in step S21 that an unused value exists in the foreign key corresponding column in the related source table, the data generation unit 11 uses the unused value in the corresponding foreign key corresponding column. According to the schema item information, one record of the related table is generated and registered in the DB 13 (step S23). Then, control goes to a step S19.

  On the other hand, if it is determined that there is no unused value in the corresponding foreign key column in the related source table, the data generation unit 11 changes the variation specified in step S19 according to the schema item information of the related source table. In response, one necessary record is generated and registered in the DB 13 (step S25). In this example, the first record in FIG. 14 is generated.

  Then, the data generation unit 11 generates one record of the related table according to the schema item information of the related table using the value of the corresponding foreign key column in the related source table generated in step S25, and registers it in the DB 13. (Step S27). In this example, the user number “CUSTOM — 014” of the first record in FIG. 14 is used as the value of the corresponding column of the foreign key, and the first record in the left column of FIG. 16 according to the schema item information in the “user history” table shown in FIG. Is generated. The method of using the schema item information is the same as the schema item information of the “user” table. Then, the process returns to step S19.

  In FIG. 15, the data items “user number” and “history moving date” are the primary key and the required category, and “user number” is composed of alphanumeric characters [10], and “history moving date” is The format is YYYY / XX / ZZ.

  In the case of this example, steps S15, S21, S25, and S27 are repeated to generate the second record to the fourteenth record in FIG. 14, and further generate the second record to the fourteenth record in FIG. Thereafter, steps S15, S21, S25, and S27 are executed to generate the first record in FIG. 17, and further generate the fifteenth record in FIG. Then, steps S15, S21, and S23 are executed to generate the sixteenth record in FIG. As described above, when one record of the “user” table is generated, the process of generating two records of the “user history” table in steps S23 and S27 is repeated, and the second to fourteenth records of the “user” table shown in FIG. And the remaining records (17th to 42nd records) of FIG. 16 are generated.

  If so far, all variations have been generated, so the process returns to step S9 via the terminal B to determine whether all the related tables have been processed. In this example, since there is no related table other than the “user history” table, the processing ends and the display of FIG. 11 is performed in step S11.

  By performing the processing as described above, it is possible to register in the DB 13 test data that maintains business consistency and ensures process completeness.

[Second Example in Embodiment 1]
Next, a second example will be described. The second example is represented by a class diagram as shown in FIG. In other words, the “user” class has two categories: an “individual / organization” category and a “user” category. In the “individual / organization” category, the category value = 1 for organizations, and the category value = 2 for individuals. In the “user” category, the category value = 1 for “user”, the category value = 2 for “user relationship”, and the segment value 3 for “kramer”. Then, the classification value = 1 of the “individual / organization” category and the classification value = 1 of the “user” category are subclasses “organization users”. Up to this point, it is the same as the first example. However, in the first example, the “user history” class is associated with the relationship of aggregation for the entire “user” class, but in the second example, the aggregation relationship of 1: n is provided only for the subclass “group user”. Is associated with the “user history” class.

  FIG. 19 shows schema-related information and category / state information in the second example. In FIG. 19, unlike the first example, the schema related information and the classification / state information are integrated. In this example, as in the first example, there are subclasses of “individual user”, “group user”, “individual user relationship”, “group user relationship”, “individual claimer”, and “group claimer”, “unregistered” “ There are states of “registration” and “registration deletion”, and combinations thereof are defined. However, in the subclasses “individual user relationship” and “organization claimer”, there is no state of “registration” and “registration deletion” (there is an “x” mark). In addition, the combination of the “group user” subclass and the “registration” state defines a related table, a related column, and a related multiplicity. The “user history” table, “user number”, and “0. Is specified. Similarly, a relation table, a relation column, and a relation multiplicity are defined for the combination of the “group user relation” subclass and the “registration” state, and the “user history” table, “user number”, “0. The information “n” is designated.

  Assuming that the schema item information of the “user” table is the same as that in the first example, the “user” table has the same portion (FIG. 10) generated in step S7 of FIG. However, the variation specified in step S13 is different from the first example. Specifically, as shown in FIG. 20, there is no record in the “user history” table for the combination of the “group user” subclass and the “registration” state, and the combination of the “group user relationship” subclass and the “registration” state. Variations corresponding to one record and two records are specified, but records in the “user history” table are not associated with other combinations of subclasses and states.

  Therefore, if the record group shown in FIG. 14 is generated in step S7, four records are added according to the schema item information of the “user” table as shown in FIG. Generated. Further, as shown in FIG. 22, a total of six records in the “user history” table are generated according to the schema item information of the “user history” record. It is assumed that setting information as shown in FIG. 6 has been input.

[Third Example in Embodiment 1]
FIG. 23 shows a class diagram of the third example. In the third example, the “sales charge” class is related to the “user” class in a 1: n relationship, and the “salesperson” class is related to the “sales charge” class in a one-to-one relationship. Yes. That is, there is no dependency relationship between classes as in the first and second examples.

  FIG. 24 shows schema related information of the “user” table of the third example. In FIG. 24, the related table name is the “in-charge” table, the related column is “user number”, and the relationship multiplicity is “1” (ie, 1: 1) for the category “main charge”. The category “general charge” is “0..n”. In this way, an example in which the relationship multiplicity differs depending on the category of “in-charge sales” class is handled.

  The “user” table is generated in accordance with the category / state information shown in FIG. 8 and the schema item information shown in FIG. Then, a record as shown in FIG. 10 is generated.

  On the other hand, it is assumed that the schema item information in the “in-charge sales” table is data as shown in FIG. That is, “user number” and “salesperson ID” are designated as essential as the primary key, and these are composed of 10 alphanumeric characters. In addition, the sales division in charge is also designated as essential, and “1” is set for the main charge and “2” is set for the general charge.

  If the process as described above is performed, a variation as shown in FIG. 26 is specified in step S13. That is, for each of the 14 types of records in the “user” table, there is a variation in which one record in the “main charge” category in the “in charge” table corresponds to each record (there is no record in the “general charge” category in the “in charge” table). ) And 14 types of records in the “user” table, one record in the “main charge” category of the “sales charge” table corresponds to one record, and one record in the “general charge” category corresponds to each record. For each variation and 14 types of records in the “user” table, one record in the “main charge” category in the “in charge” table corresponds to one record, and two records in the “general charge” category correspond to each record. Variations are identified.

  Then, for the “user” table, one set of 14 types of records is generated in step S7, and then, as shown in FIGS. 27A and 27B, according to the schema item information of FIG. 25 according to the variations shown in FIG. A record in the “sales charge” table is generated. As in the first and second examples, three sets of 14 types of records in the “user” table are required. For the “in-charge” table, 14 records + 14 records × 2 + 14 records × 3 = 84 records Is generated. In FIGS. 27A and 27B, one record of the “main charge” category is necessarily required for each “user” record, and therefore 42 types of salesperson IDs are required. For the remaining 42 records out of 84 records, 42 types of salesperson IDs are reused.

  Next, a “salesperson” table associated with the “in-charge sales” table is generated as the remaining related tables. FIG. 28 shows schema related information of the “in-charge” table. In FIG. 28, a related table name “salesperson”, a related column “salesperson ID”, and a relational multiplicity “1” are registered. Therefore, in the “salesperson” table, a record is generated so as to have a one-to-one correspondence with the “salesperson ID” of the “sales charge” table. As described above, since there are 42 types of salesperson IDs, there are 42 records in the “salesperson” table. The value of the foreign key (salesperson ID value) can be extracted from the “in-charge” table.

  Here, schema item information as shown in FIG. 29 is used. In FIG. 29, the “salesperson ID” that is the primary key is essential and is composed of 10-digit alphanumeric characters, and the name of the seller in charge is composed of full-width (100 bytes). According to such schema item information, a “salesperson” table as shown in FIG. 30 is generated.

  As described above, in any of the examples, it is possible to register test data in the DB 13 so as to ensure completeness in processing while maintaining business consistency.

[Modification of Embodiment 1]
In the example described above, the example in which the category / state information is prepared is shown. However, when the status is not particularly specified for business, for example, in the schema related information as shown in FIG. In some cases, the severity may be specified. In such a case, in step S5 of FIG. 5, the variation of the record to be generated is specified according to the combination of the division values that can be taken from the schema related information without using the division / state information, and the record is generated in step S7. Anyway. Furthermore, a record variation is specified without using the division / state information in step S13 of FIG.

[Embodiment 2]
In the first embodiment, the multiplicity between the two tables is 1: n. . n: 0. . The case of m was not subject to processing. In the case of 1: n, the relationship between the records is uniquely determined, whereas in the case of n: m, there can be an infinite number of variations in the relationship between the records. When preparing a record, it was difficult to determine what kind of relational variations would be generated and the data to be effective for fault detection. For example, as shown in FIG. 31, between the customer table record and the sales table record, 0. . 2: 0. . When there is a relationship of 2, as shown in FIG. 32 (a), a pattern in which the records a1 and a2 in the customer table and the records b1 and b2 in the sales table are correlated two-to-two, As shown in (2), a pattern or the like in which records a1 to a3 in the customer table and records b1 to b3 in the sales table are associated with each other in a two-to-two manner is possible. Other patterns can be generated, but as described above, it is difficult to determine what pattern should be adopted.

  However, there are many such multiplicity table relationships in business, and it is necessary to cope with the case of multiplicity n: m in generating test data for a wide range of business.

  For example, consider the case of generating test data for a system for the following business. (A) There is a car sharing club, and there are two owners per car. (2) In order to use a certain vehicle, the credentials of the two people who own the vehicle are required. (3) People who own the same car can issue credentials to each other.

  In such a case, it is possible to generate test data as shown in FIG. 33A, or it is possible to generate test data as shown in FIG. That is, in FIG. 33 (a), the cars A and B are associated with the members 1 and 2 at 2: 2, and in FIG. 33 (b), the cars A to C are 2: 2 at the members 1 to 3. It is associated.

  However, in the case of FIG. 33 (a), the two cars are owned by the members 1 and 2, and no members other than the members 1 and 2 are specified, so there is no scene for issuing a credential. On the other hand, in the case of FIG. 33B, the member 3 does not own the car A, but owns the member 1 that owns the car A and the car C. If a credential is issued from the members 1 and 2 who own the car A, the car A can be used.

That is, in the example of FIG.
IF ((not owning car A) & (owning the same car as the two members who own car A)) then (can use car A)
You can test the logic.

  Thus, even test data with the same multiplicity n: m is not necessarily test data sufficient for performing a test, and it is necessary to generate test data sufficient for performing a test.

  In the following, we introduce the number of inter-record relationships, which is the number of records affected by the change in the record group linked directly or indirectly based on the relational multiplicity, let the user specify the condition value, and the condition value By generating a record that conforms to, a pattern that contains enough records for the test shall be generated. For example, in the case of FIG. 33 (a), the data item “member” and the data item “car” are considered as one record. For example, if member 1 is changed, car B must also be changed. The number of relations between records is counted as “2” by the records including the car B. In the case of FIG. 33 (b), when the member 1 is changed, the car C must be changed. When the car C is changed, the member 3 must be changed. Therefore, the number of relations between records is counted as “3” by the record including the member 1, the record including the car C, and the record including the car B.

  Note that the functional block diagram in the present embodiment is the same as the functional block diagram of the test data generation apparatus 100 (FIG. 2).

  Next, processing contents of the test data generation apparatus 100 according to the second embodiment will be described with reference to FIGS.

  First, a specific example for making the processing flow easy to understand will be described with reference to FIGS. FIG. 34 is a class diagram showing the relationship between the table groups for generating test data. As shown in FIG. 34, the table A for the data items a and b, the table X for the data item x, the relationship between the table A and the table X, and the table Z for the data items a and x are included. It is.

  FIG. 35 shows a schema item definition of table A. The table A includes data items a and b, the data item a is a primary key, and the data items a and b are both essential data items. In addition, the data attribute of the data item “a” is full-width (100 bytes), and the data attribute of the data item “b” is one half-width alphanumeric character. Hereinafter, the data item b is also referred to as a category.

  FIG. 36 shows the schema item definition of table X. The table X includes a data item x, the data item x is a primary key, and the data item x is an essential data item. The data attribute of the data item x is full-width (100 bytes).

  Further, FIG. 37 shows a schema item definition of the table Z. The table Z includes data items a and x, the data items a and x are primary keys, and the data items a and x are both essential data items. Further, the data attribute of the data item “a” is full-width (100 bytes), and the data attribute of the data item “x” is one single-byte alphanumeric character.

  FIG. 38 shows schema related information of the table Z. The schema-related information in FIG. 38 indicates that the relationship multiplicity between table A and table X represented by A: X changes for each value (partition value) of data item b in table A. Specifically, if the value (partition value) of the data item b is “1”, A: X is 0. . 3: 0. . 2 and the value of data item b (partition value) is “2”, A: X is 1: 0. . 2 is specified. In FIG. 38, the related column is not explicitly shown, but it can be seen from the fact that the data item b of the table A is used as the partition value and the schema item definition indicates that the data item a and the data item x are related. .

  Next, the processing flow will be described with reference to FIGS. First, the input unit 1 displays the user as shown in FIG. 40, for example, prompts the user to input setting information, accepts the input of setting information, and stores it in a storage device such as a main memory. . Further, the input of design information is further prompted, and the input of design information is accepted (step S51) and stored in the design information storage unit 3 (step S53). In the screen example of FIG. 40, an input field for the table (schema) name to be generated, a designation input field for the relational multiplicity n, a designation input field for the relational multiplicity m, and a designation input for the upper limit P of the relation number between records. Column. The designation input field for the relational multiplicity n is an input field for designating a numerical value corresponding to the multiplicity n when no specific numerical value is designated for the multiplicity in the schema-related information. In the example of FIG. 38, it is clear that “3” in “0. Similarly, the designation input field for the relational multiplicity m is an input field for designating a numerical value corresponding to m when no specific numerical value is designated for the multiplicity in the schema-related information. In the example of FIG. 38, it is clear that “2” in “0. The designation input field for the upper limit P of the number of relations between records is an input field for designating the upper limit value of the number of relations between records described above.

  Note that the design information input in step S51 includes information as shown in FIGS. Such design information is input to the input unit 1 in a machine readable format, and is stored in the design information storage unit 3 by the input unit 1.

  Then, the data generation determination unit 7 specifies a variation of the record to be generated in the generation target table based on the input setting information and the like, and stores data on the variation in the variation data storage unit 9 (step S55). ). In the input screen shown in FIG. 40, since the tables A and X are tables to be generated, it is specified from the schema item definition and schema related information what variations are required for the tables A and X at the beginning. . In addition, when the category / state information is included in the design information, this is used. However, since the category / state information is not included in this example, it is specified from the schema item definition and the schema related information. 35 and 38, it can be seen that the data item b of the table A takes the segment value “1” or “2”. Therefore, the table A has a record in which the data item b is “1” and “2”. It can be seen that variations such as records are necessary. Therefore, such a variation is registered for the table A in the variation data storage unit 9. On the other hand, according to the examples of FIGS. 36 and 38, there is no special restriction on the design information for the table X, and it is sufficient to simply generate one record. Therefore, data on such variations is registered in the variation data storage unit 9. To do.

  Thereafter, the data generation unit 11 generates a record required for the variation stored in the variation data storage unit 9 in accordance with the read schema item information, schema related information, etc., and registers it in the DB 13 (step S57). ). For example, the data generation unit 11 has a generation method related to a character string such as “half-width alphanumeric characters”, “half-width characters”, “full-width characters”, and “numbers”, and by inputting a length, a predetermined rule (for example, random , “CUSTOM_” + “number (number of digits matches the total number of digits)” according to the column name such as “user number”, rule to make each value unique if it is a primary key) Automatically generates a string that conforms to

  For example, as shown in FIG. 41, for the table A, two records having different values of the data item b that is a segment value are generated. For the table X, one record is simply generated as shown in FIG. As shown in FIG. 43, no record is generated for the table Z at this stage.

  Then, the data generation determination unit 7 determines whether there is an ungenerated related table (step S59). For example, with reference to schema related information included in the design information, it is determined whether an ungenerated related table exists. If it is determined that there is an ungenerated association table, the process proceeds to the process in FIG. In the example of FIG. 40, since the table Z has not yet been generated, the process proceeds to the process of FIG.

  Shifting to the description of the processing in FIG. 44, the data generation determination unit 7 inputs the classification / state (if any) of the related table column to be generated and the relational multiplicity included in the schema related information. The variation of the related table record to be generated is determined from the relational multiplicity numbers n and m input by the unit 1, and the variation data is stored in the variation data storage unit 9 (step S61).

  From the example of FIG. 38, it can be seen that the relational multiplicity between the data item a and the data item x in the table Z which is a related table differs depending on the segment value of the data item b related to the data item a. Therefore, it is divided into the case of the division value “1” of the data item “b” and the case of the division value “2” of the data item “b”. . n: 0. . m for variations later, and in the latter case the relational multiplicity 1: 0. . Since it is 2, records about variations of 0: 0, 1: 1, 1: 2 are generated. Therefore, the relational multiplicity 0. 0 in the case of the segment value “1” of the data item b. . n: 0. . The variation data for m and the variation data of the relational multiplicity 0: 0, 1: 1, 1: 2 in the case of the division value “2” of the data item b are stored in the variation data storage unit 9.

  Thereafter, the data generation unit 11 specifies one unprocessed variation in the variation data storage unit 9 (step S63). Then, it is determined whether or not the specified variation is a variation of relational multiplicity n: m (0..n: 0..m. The same may be omitted hereinafter) (step S65). If the relational multiplicity is not n: m, the data generation unit 11 performs a record generation process (step S67). This record generation process will be described with reference to FIG. However, the processing flow of FIG. 45 is substantially the same as steps S15 to S27 (excluding step S19) of FIG.

  First, the data generation unit 11 specifies the foreign key (for example, “related column” in the schema related information) or “identifies the column having the same name in the related source table and the related table from the schema item information”. It is determined whether a use value exists (step S101) For example, when a foreign key value has already been designated by a user or the like, an unused value exists among the designated foreign keys. When such a value exists, the data generation unit 11 generates a record of the related table using the unused value of the foreign key according to the schema item information of the related table ( Step S103) Then, the process returns to the original process.

  If it is determined in step S101 that there is no unused value for the foreign key, the data generation unit 11 determines whether there is an unused value in the corresponding column of the foreign key in the related source table (step S105). ). If it is determined in step S105 that there is an unused value in the foreign key corresponding column in the related source table, the data generation unit 11 uses the unused value in the corresponding foreign key corresponding column. The related table record is generated according to the schema item information (step S107). Then, the process returns to the original process.

  On the other hand, if it is determined that there is no unused value in the corresponding foreign key column in the related source table, the data generation unit 11 changes the variation specified in step S63 according to the schema item information of the related source table. A necessary record is generated accordingly (step S109).

  Then, the data generation unit 11 generates a record of the related table according to the schema item information of the related table using the value of the foreign key corresponding column in the related source table generated in step S109 (step S111). Then, the process returns to the original process.

  For example, in the case of the division value “2” of the data item b, as described above, a record is generated for the variations of the relational multiplicity 0: 0, 1: 1, 1: 2. If schematically written, as shown in FIG. 46, (a) when data item a corresponds to data item x at 0: 0, (b) when data item a corresponds to data item x at 1: 1. (C) It is necessary to generate a record when the data item a and the data item x correspond 1: 2. In this example, the data item a is used as an external key.

  When processing the relational multiplicity 0: 0, starting from the state shown in FIG. 41, the value “a2” of the data item a is an unused value, so as shown in FIG. The value “a2” of the data item a is adopted, and the value of the data item x is generated as “x10” from the schema item information.

  Next, when processing the relational multiplicity of 1: 1, since there is no unused value in the table A, the value “a14” of the data item a is generated as shown in FIG. 46B. The value “x11” of the corresponding data item x is generated.

  Further, when processing the relational multiplicity 1: 2, since there is no unused value in the table A, the value “a15” of the data item a is generated as shown in FIG. The values “x12” and “x13” of the corresponding data item x are generated.

  When the processing is completed as described above, returning to the description of FIG. 44, the data generation unit 11 registers the data generated in step S67 in the DB 13 (step S69). In the example of the generated data described above, since the processing is for the segment value “2” of the data item b, the values “a14” and “a15” of the data item a corresponding to the segment value “2” as shown in FIG. Data is additionally registered in table A. Similarly, since “x10”, “x11”, “x12”, and “x13” are generated for the data item x, data as shown in FIG. Further, since the 0: 0 relational multiplicity shown in FIG. 46 (a) has no correspondence, except for this case, the correspondences in FIGS. 46 (b) and 46 (c) are shown in FIG. The data as shown in FIG. That is, for relational multiplicity 1: 1, a record including a14 and x11 is registered, and for relational multiplicity 1: 2, a record including a15 and x12 and a record including a15 and x13 are registered.

  Then, the data generation unit 11 determines whether data has been generated for all of the necessary variations identified in step S61 (step S81). If data has not been generated for all variations, the process returns to step S63. On the other hand, if all variations have been generated, the process returns to step S59 in FIG.

  On the other hand, if it is determined in step S65 that the relational multiplicity is a scene of developing a variation for n: m, the data generation unit 11 performs n: m record generation processing (step S71). The n: m record generation process will be described with reference to FIG. In addition, 0. . n: 0. . In the case of m, it is necessary to generate 0: 0, 1: 1, 1: m, n: 1 and n: m. In the present embodiment, first, data for n: m is generated.

  First, the data generation unit 11 performs a record generation process for n: m variations (step S121). This process is the same as in FIG. For n and m, schema related information or user setting input values are used. Here, n = 3 and m = 2.

  When there is no unused foreign key value input from the outside and there is no unused value for the segment value “1” in the data item “a” of the table A, the processing of FIG. 45 is shown in FIG. Such data is generated. That is, data values “a8”, “a9”, and “a10” are generated for the data item a, and data values “x6” and “x7” are generated for the data item x. In the example of FIG. 51, the number of relations between records is “3”.

  In order to satisfy n: m with the minimum number of records, n data items a in table A and m data values x in data item x in table X may be generated. Then, if m lines are drawn from each data value of the data item a to the data value of the data item x (if association is performed), a total of n × m relationships are generated, and n × m relationships are generated in the table Z. Will be generated.

  Next, the data generation unit 11 determines whether or not the upper limit P of the number of relations between records designated by the user exceeds the number of relations between records of the generated record group (step S123). When the user designates “6” as the upper limit P of the number of relations between records, the number of relations between records of the record group generated in FIG. 51 is “3”. Is determined not to exceed the upper limit P.

  In the record group generated in FIG. 51, if the column value a8 is changed, the column value x7 must be changed. If the column value x7 is changed, the column value a10 must be changed. The relation number between records is counted as “3” by the record including the value a8, the record including the column value x7, and the record including the column value a10.

  If the number of relations between records in the generated record group does not exceed the upper limit P, the data generation unit 11 again performs record generation processing for n: m variations (step S125). This is the same as step S121. Therefore, in step S125, as shown in FIG. 52, data similar to the record group generated in FIG. 51 is generated.

  And the data generation part 11 implements the correlation process between records (step S127). For example, the process which connects the record group shown in FIG. 51 and the record group shown in FIG. 52 is implemented. That is, the association as shown in FIG. 53 is performed. In FIG. 53, the dotted line association is an association that is cut when the ratio is changed from 3: 2 to 6: 4, and the thick line association is an association that is generated when the ratio is corrected to 6: 4. Such a connection method is well known in graph theory and will not be described further here. However, it is assumed that rules are prepared in advance and connection is performed according to the rules.

  Returning to step S123 after step S127, the data generation unit 11 determines whether the number of relations between records in the generated record group exceeds the upper limit P of the number of relations between records specified by the user. The number of relations between records in the record group shown in FIG. 53 is “6”, and the upper limit P is “6”. Therefore, it is determined that the condition of step S123 is not satisfied. In such a case, steps S125 and S127 are executed again.

  In the record group shown in FIG. 53, when the column value a8 is changed, the column value x7 is changed. When the column value x7 is changed, the column value a10 is changed, and when the column value a10 is changed. When the column value x8 is changed and the column value x8 is changed, the column value a12 is also changed. When the column value a8 is changed, the column value x6 is also changed, so the column value a13 is also changed. Therefore, a record including the column value a8, a record including the column value x7, a record including the column value a10, a record including the column value x8, a record including the column value a12, and a record including the column value a13. The number of relations between records is counted as “6”.

  Specifically, when a record group as shown in FIG. 51 or 52 is added to the record group shown in FIG. 53 and connected, a record group as shown in FIG. 54 is obtained. However, the number of relations between records is “9”.

  Then, since it is determined in step S123 that the upper limit P of the number of relations between records has been exceeded, the data generation unit 11 discards the data generated at the time of the previous execution when additional record generation processing is being performed, and Return to the previous position (step S129). It is also possible to save the state each time the record generation process is additionally performed and to return to the previous state. In the example described above, the state shown in FIG. 53 is adopted. Then, the process returns to the original process.

  Then, the data generation unit 11 registers the generation data in the DB 13 (Step S131). Data additionally registered in the table A based on FIG. 53 is data as shown in FIG. Since the current processing is for the segment value “1” of the data item b, the segment values are all “1”, and the values of the data item a are “a8” to “a13” as can be seen from FIG. It is. Further, the data additionally registered in the table X based on FIG. 53 is data as shown in FIG. That is, as can be seen from FIG. 53, they are “x6” to “x9”. The data registered in the table Z based on FIG. 53 is data as shown in FIG. In FIG. 57, 12 records are added according to the association of FIG.

  Returning to the description of the processing in FIG. 44, when the processing for n: m is completed in step S71, 0. . n: 0. . The unprocessed 0: 0, 1: 1, 1: m and n: 1 will be processed with variations for m. The data generation unit 11 identifies an unprocessed sub-variation among these (step S73), and performs a record generation process for the pattern (step S75). This process is the same as step S67, and the description thereof is omitted. Then, the data generated in step S75 is registered in the DB 13 (step S77). Further, it is determined whether all the patterns shown in step S73 have been processed. If there is an unprocessed sub-variation, the process returns to step S73. On the other hand, if all sub-variations have been processed, the process proceeds to step S81.

  In the repetition of steps S73 to S79, data as shown in FIG. 58 is generated. However, in the case of 0: 0 shown in FIG. 58A, the unused data value “a1” for the data item a is used in the state of FIG. Since the unused data value “x1” of x is used, no data is newly generated. In the case of 1: 1 shown in FIG. 58B, the data value “a3” of the data item a and the data value “x2” of the data item x are newly generated. Further, in the case of 1: m (2 in this case) shown in FIG. 58 (c), the data value “a4” of the data item a and the data values “x3” and “x4” of the data item x are newly generated. It has been done. In the case of n (here, 3): 1 shown in FIG. 58D, the data values “a5”, “a6” and “a7” of the data item a and the data value “x5” of the data item x are It is a newly created one.

  Such data is additionally registered in the DB 13 in step S77, but records as shown in FIG. 59 are registered in the table A based on FIG. 58, and the table X is shown in FIG. 60 based on FIG. 61 is registered, and a record as shown in FIG. 61 is registered in the table Z based on FIG.

  If it is determined in step S81 that all variations have been processed, the process returns to step S59 in FIG.

  Returning to the description of the processing in FIG. 39, the data generation determination unit 7 again determines whether there is an ungenerated related table (step S59). For example, with reference to schema related information included in the design information, it is determined whether an ungenerated related table exists. If it is determined that an ungenerated association table still exists, the process proceeds to the process in FIG.

  On the other hand, if it is determined that there is no ungenerated related table, the data generation determination unit 7 outputs a display including the processing result as shown in FIG. 62 to the user (step S60). In FIG. 62, 15 records for table A, 13 records for table X, and 21 records for table Z are generated, and the generated related data set is stored in the \ CreatedData \ A_X_Z folder. It is shown. The message content can be modified in various ways.

  When the data finally stored in the DB 13 is collected, 15 records are generated for the table A as shown in FIG. 63, 13 records are generated for the table X as shown in FIG. 64, and 65 records for the table Z are shown in FIG. 21 records are generated as shown in FIG.

  By performing the processing as described above, even in the case where the relational multiplicity is n: m, the business consistency is maintained according to the upper limit of the number of relations between records specified by the user. Thus, it becomes possible to generate a record group that guarantees completeness in processing. In the above, 0. . n: 0. . The example of m has been described. . n: 1. . Even if it is m, it suffices not to generate a 0: 0 sub-variation. Similarly, when the lower limit is larger than 1, for example, 2. . n: 2. . Also in the case of m, it may be developed into sub-variations such as 2: 2, 2: m, n: 2, n: m.

  Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, the functional block diagram shown in FIG. 2 is an example, and may not necessarily correspond to the program module configuration.

  Furthermore, as long as the processing result does not change for the processing flow, the order of steps can be changed or executed in parallel.

  The embodiment described above is summarized as follows.

  The test data generation method according to the first aspect is a combination of schema-related information representing the relationship between the first table and the second table and the relational multiplicity, and the division and state of the first table that can be taken in business. Access to a design information storage unit that stores partition state information regarding the first table and schema item information of the first table and the second table, and a database that stores data of the first table and data of the second table It is executed by a computer that is capable. Then, a combination of divisions and states in the first table that can be taken in the business is identified from the division state information stored in the design information storage unit, and the schema item information of the first table stored in the design information storage unit The first table record and the second table record are generated from the step of generating the record of the first table corresponding to the combination according to the above and registering it in the database and the schema related information stored in the design information storage unit When there is an ungenerated record that is a record of the first table that is necessary for the above-described variation and a variation specifying step that specifies a variation of the correspondence relationship, the first stored in the design information storage unit A new record is generated according to the schema item information of table 1 and stored in the database In accordance with the relationship between the first table and the second table in the first table non-generated record generation step to record, the schema table information of the second table stored in the design information storage unit and the schema related information A second table record generation step of generating a record of the second table required according to the variation and registering it in the database.

  By generating records of the first table according to the combinations that can be taken in this way, business consistency and process coverage are ensured, and the records of the first table and the second table By generating the records of the first and second tables according to the variations of the correspondence relationship with the records, the process completeness is ensured. That is, it is possible to automatically generate sufficient test data for performing a correct test on the business application program.

  In the variation specifying step described above, when the relational multiplicity in the schema related information is x (an integer greater than or equal to 0) to n (variable) and the multiplicity upper limit m (an integer greater than x) is designated, A step of generating a variation of x record of the second table corresponding to one record of the first table and a variation of m record of the second table corresponding to one record of the first table. Also good. This is to ensure completeness in processing.

  Further, in the variation specifying step described above, when the relational multiplicity in the schema related information is 0 to n (variable) and the multiplicity upper limit m (an integer of 2 or more) is designated, 1 in the first table A variation of no record in the second table corresponding to the record, a variation of one record in the second table corresponding to one record in the first table, and a variation corresponding to one record in the first table A step of generating a variation of m records of the table of 2 may be included. This is to ensure completeness in processing by typical variations.

  Further, in the variation specifying step described above, the relational multiplicity between the specific record of the first table and the record of the second table in the schema related information is x (an integer greater than or equal to 0) to n (variable). When the multiplicity upper limit m (an integer greater than x) is specified, the x record of the second table corresponding to the specific record of the first table and a record other than the specific record of the first table Corresponding to the variation that there is no record in the second table corresponding to, and corresponding to the record that is m record of the second table corresponding to the specific record of the first table and other than the specific record of the first table Then, a step of generating a variation of no record in the second table may be included. In some cases, the records in the second table are associated with only specific records (sections and states).

  The first table non-generated record generation step described above determines whether there is a usable value based on the above variation among the column values corresponding to the foreign key in the first table. May be included. In this way, it is possible to determine whether or not there is an ungenerated record that is a record in the first table that is necessary in the above variation.

  Further, in the second table record generation step described above, among the column values corresponding to the foreign keys in the first table, values that can be used based on the above variations correspond to the foreign keys in the second table. You may make it include the step employ | adopted as a value of a column.

  In addition, when the second table record generation step described above generates a new record in the first table non-generated record generation step, the column value corresponding to the foreign key in the new record is changed to the first table record generation step. A step of adopting as a column value corresponding to the foreign key in the table of 2 may be included.

  Furthermore, in the test data generation method according to the first aspect, the design information storage unit includes second schema related information representing the relationship between the first table or the second table and the third table and the relation multiplicity. When the schema item information of the third table is further stored, the second table-related information stored in the design information storage unit and the upper limit of the multiplicity specified by the user are used. A step of specifying a variation of a correspondence relationship between a record or a record of the second table and a record of the third table, and a record of the first table or a record of the second table required in the variation, If a generated record exists, the schema item information of the first table or the second table stored in the design information storage unit The first table or the second table in the step of newly generating a record and registering it in the database, the schema item information of the third table stored in the design information storage unit, and the second schema related information And generating a record of the third table required according to the variation in accordance with the relationship with the third table and registering it in the database. It is possible to deal with a case where a plurality of related tables exist.

  The test data generation method according to the second aspect includes the schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each partition value, the first table, and the second table It is executed by a computer that can access a design information storage unit that stores schema item information of a table and a database that stores data of the first table and data of the second table. Then, the variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and according to the variation of the partition value according to the schema item information of the first table stored in the design information storage unit From the step of generating the record of the first table and registering it in the database, and the relational multiplicity for each section value of the schema related information stored in the design information storage unit, the record of the first table and the second table If there is a variation identification step for identifying the variation of the correspondence relationship with the table record and a record of the first table that is necessary for the variation and has not yet been generated, it is stored in the design information storage unit. A new record is generated according to the schema item information of the first table that is stored in the database. According to the relationship between the first table and the second table in the first table non-generated record generation step to be recorded, the schema item information of the second table stored in the design information storage unit, and the schema related information A second table record generation step of generating a record of the second table required according to the above and registering it in the database.

  Thus, even when the division state information is not prepared, it is possible to automatically generate sufficient test data for performing a correct test on the business application program.

  The test data generation method according to the third aspect includes the first and second tables, the relationship between the relation tables of the first and second tables, and the division between the related data items in the first and second tables It is executed by a computer that can access the schema related information representing the relational multiplicity for each value, the design information storage unit storing the schema item information of each table, and the database storing each table. Then, the variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the first and the second according to the variation of the partition value according to the schema item information stored in the design information storage unit Including a related data item from the step of generating the record of the second table and registering it in the database, and the relational multiplicity for each segment value between the related data items of the schema related information stored in the design information storage unit; When there is an ungenerated value that is a value of the related data item of the first and second tables required in the variation specifying step for specifying the variation of the relationship table record and the variation of the relationship table record. Schema item information of the first and second tables stored in the design information storage unit Therefore, a new record including the value of the related data item in the first and second tables is newly created and registered in the database, and the records in the first and second tables registered in the database are used. Generating a table record and registering it in the database.

  In the variation specifying step described above, the relational multiplicity is a to n: b to m (n and m are integers of 2 or more. A is an integer of 0 to less than n. B is an integer of 0 to less than m. ) Includes a development step of developing into a plurality of sub-variations including n: m. In addition, when the relation table generation step described above generates a record group of a relation table for an n: m sub-variation, the number of relations between records indicating the influence spread range at the time of data item change in the record group. Includes n values of related data items in the first table and m values of related data items in the second table so that the maximum value is less than or equal to the upper limit value of the number of relations between records specified. Preparing one or a plurality of sets.

  In this way, even when the relational multiplicity is a to n: b to m, it is possible to generate test data with sufficient completeness for testing. It is also possible to generate test data while ensuring business consistency in the business application program.

  In the case where a = 0 and b = 0, the expansion may be performed in sub-variations of 0: 0, 1: 1, 1: m, and n: 1. This ensures completeness.

  A program for causing a computer to execute this method can be created, and this program is stored in a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, or a hard disk. . Moreover, it may be distributed as a digital signal via a network or the like. The intermediate processing result is temporarily stored in a storage device such as a main memory.

  The test data generation device 100 is, for example, a computer device. In the computer device, as shown in FIG. 66, a memory 2501 (storage unit), a CPU 2503 (processing unit), and a hard disk drive (HDD) 2505 are displayed. A display control unit 2507 connected to the device 2509, a drive device 2513 for the removable disk 2511, an input device 2515, and a communication control unit 2517 for connecting to a network are connected by a bus 2519. Application programs including an operating system (OS) and a Web browser are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. If necessary, the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary. Such a computer realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above with the OS and necessary application programs.

(Appendix 1)
Schema-related information indicating the relationship between the first table and the second table and the relationship multiplicity, the division state information regarding the combinations of the division and state of the first table that can be taken in business, and the first table A computer that can access a design information storage unit that stores schema item information of the second table, and a database that stores data of the first table and data of the second table;
From the partition state information stored in the design information storage unit, a combination that can be taken in the business of the partition and state in the first table is specified, and the combination of the first table stored in the design information storage unit Generating a record of the first table according to the combination according to schema item information and registering it in the database;
From the schema related information stored in the design information storage unit, a variation specifying step for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table;
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation program for causing execution.

(Appendix 2)
The variation specifying step includes:
When the relational multiplicity in the schema related information is x (an integer greater than or equal to 0) to n (variable) and the multiplicity upper limit m (an integer greater than x) is designated by the user, 1 in the first table The method of claim 1, further comprising: generating a variation called x record of the second table corresponding to a record and a variation called m record of the second table corresponding to one record of the first table. Test data generation program .

(Appendix 3)
The variation specifying step includes:
When the relational multiplicity in the schema-related information is 0 to n (variable) and the multiplicity upper limit m (an integer of 2 or more) is designated by the user, the one corresponding to one record of the first table A variation of no record in the second table, a variation of one record in the second table corresponding to one record in the first table, and the second corresponding to one record in the first table The test data generation program according to supplementary note 1, including a step of generating a variation of m records of the table of .

(Appendix 4)
The variation specifying step includes:
In the schema related information, the relational multiplicity of the specific record of the first table and the record of the second table is x (an integer greater than or equal to 0) to n (variable) and the multiplicity upper limit m is set by the user. When (integer greater than x) is specified, it corresponds to a record of the second table corresponding to a specific record of the first table and corresponds to a record other than the specific record of the first table And a variation that there is no record in the second table, and a record other than the specific record in the first table that is the m record in the second table corresponding to the specific record in the first table. The test data generation program according to appendix 1, including a step of generating a variation of no record in the second table corresponding to Grams .

(Appendix 5)
The first table non-generated record generation step includes:
The test data generation program according to appendix 1, including a step of determining whether there is a usable value based on the variation among the column values corresponding to the foreign key in the first table .

(Appendix 6)
The second table record generation step includes:
Supplementary note 1 including a step of adopting a value that can be used based on the variation among column values corresponding to a foreign key in the first table as a column value corresponding to a foreign key in the second table. Test data generation program .

(Appendix 7)
The second table record generation step includes:
When a new record is generated in the first table non-generated record generation step, the column value corresponding to the foreign key in the new record is changed to the column value corresponding to the foreign key in the second table. The test data generation program according to appendix 1, including the step of adopting as:

(Appendix 8)
The design information storage unit further includes second schema related information representing a relationship between the first table or the second table and the third table and a relation multiplicity, and schema item information of the third table. If stored,
The first table record or the second table record and the third table record from the second schema related information stored in the design information storage unit and the user-specified multiplicity upper limit. Identifying a variation of the correspondence with,
The first table stored in the design information storage unit when there is an ungenerated record that is a record of the first table or a record of the second table required in the variation Or generating a new record according to the schema item information of the second table and registering it in the database;
According to the relationship between the first table or the second table and the third table in the schema item information of the third table and the second schema related information stored in the design information storage unit Generating a record of the third table required according to the variation and registering it in the database;
The test data generation program according to appendix 1, for causing the computer to further execute

(Appendix 9)
Schema-related information indicating the relationship between the first table and the second table and the relationship multiplicity, the division state information regarding the combinations of the division and state of the first table that can be taken in business, and the first table And a design information storage unit that stores schema item information of the second table, and a database that can access a database that stores data of the first table and data of the second table. Test data generation method,
From the partition state information stored in the design information storage unit, a combination that can be taken in the business of the partition and state in the first table is specified, and the combination of the first table stored in the design information storage unit Generating a record of the first table according to the combination according to schema item information and registering it in the database;
From the schema related information stored in the design information storage unit, a variation specifying step for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table;
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation method including

(Appendix 10)
Schema-related information indicating the relationship between the first table and the second table and the relationship multiplicity, the division state information regarding the combinations of the division and state of the first table that can be taken in business, and the first table And a design information storage unit that stores schema item information of the second table;
From the partition state information stored in the design information storage unit, a combination that can be taken in the business of the partition and state in the first table is specified, and the combination of the first table stored in the design information storage unit Means for generating a record of the first table according to the combination according to the schema item information and registering it in a database;
Variation specifying means for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table from the schema related information stored in the design information storage unit;
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. First table non-generated record generating means for generating and registering in the database;
According to the relation between the first table and the second table in the schema item information of the second table and the schema-related information stored in the design information storage unit, it is necessary according to the variation A second table record generating means for generating a record of the second table and registering it in the database;
A test data generating apparatus having

(Appendix 11)
Design information storage for storing schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each section value, and schema item information of the first table and the second table A computer that is accessible to a storage unit and a database that stores data of the first table and data of the second table;
A variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the partition value of the partition value is determined according to the schema item information of the first table stored in the design information storage unit. Generating a record of the first table according to variations and registering it in the database;
A variation for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table from the relationship multiplicity for each of the partition values of the schema related information stored in the design information storage unit Specific steps,
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation program for causing execution.

(Appendix 12)
Schema-related information representing the relationship between the first and second tables and the relationship tables of the first and second tables and the relationship multiplicity for each segment value between the related data items in the first and second tables A computer that can access a design information storage unit that stores schema item information of each table, and a database that stores each table,
The variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the variation according to the variation of the partition value according to the schema item information stored in the design information storage unit Generating records of the first and second tables and registering them in the database;
Variation specification for specifying a variation of the record of the relation table including the related data item from the relation multiplicity for each of the division values between the related data items of the schema related information stored in the design information storage unit Steps,
In the case where there is an ungenerated value that is a value of the related data item in the first and second tables required in the variation of the record in the relation table, the design information storage unit stores the value. According to the schema item information of the first and second tables, a record including the value of the related data item of the first and second tables is newly generated, registered in the database, and registered in the database. Using the records of the first and second tables, generating a record of the relation table and registering it in the database;
To the computer,
The variation specifying step includes:
When the relational multiplicity is a to n: b to m (n and m are integers of 2 or more, a is an integer of 0 to less than n, and b is an integer of 0 to less than m), n: m Including a deployment step that deploys to multiple sub-variations including
The relation table generating step includes
When generating a record group of the relation table for the n: m sub-variation, the relation number between records indicating the influence spread range at the time of data item change in the record group is the upper limit of the relation number between records specified One or a plurality of data sets including n values of related data items in the first table and m values of related data items in the second table are prepared so as to be maximum below the value. Test data generation program including steps.

(Appendix 13)
When a = 0 and b = 0 In the development step, the test data generation program according to appendix 12, wherein the test data is developed into sub-variations of 0: 0, 1: 1, 1: m, and n: 1 .

(Appendix 14)
Design information storage for storing schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each section value, and schema item information of the first table and the second table A test data generation method executed by a computer that is accessible to a storage unit and a database storing data of the first table and data of the second table,
A variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the partition value of the partition value is determined according to the schema item information of the first table stored in the design information storage unit. Generating a record of the first table according to variations and registering it in the database;
A variation for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table from the relationship multiplicity for each of the partition values of the schema related information stored in the design information storage unit Specific steps,
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation method including

(Appendix 15)
Schema-related information representing the relationship between the first and second tables and the relationship tables of the first and second tables and the relationship multiplicity for each segment value between the related data items in the first and second tables And a test data generation method executed by a computer that can access a design information storage unit that stores schema item information of each table and a database that stores each table,
The variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the variation according to the variation of the partition value according to the schema item information stored in the design information storage unit Generating records of the first and second tables and registering them in the database;
Variation specification for specifying a variation of the record of the relation table including the related data item from the relation multiplicity for each of the division values between the related data items of the schema related information stored in the design information storage unit Steps,
In the case where there is an ungenerated value that is a value of the related data item in the first and second tables required in the variation of the record in the relation table, the design information storage unit stores the value. According to the schema item information of the first and second tables, a record including the value of the related data item of the first and second tables is newly generated, registered in the database, and registered in the database. Using the records of the first and second tables, generating a record of the relation table and registering it in the database;
To the computer,
The variation specifying step includes:
When the relational multiplicity is a to n: b to m (n and m are integers of 2 or more, a is an integer of 0 to less than n, and b is an integer of 0 to less than m), n: m Including a deployment step that deploys to multiple sub-variations including
The relation table generating step includes
When generating a record group of the relation table for the n: m sub-variation, the relation number between records indicating the influence spread range at the time of data item change in the record group is the upper limit of the relation number between records specified One or a plurality of data sets including n values of related data items in the first table and m values of related data items in the second table are prepared so as to be maximum below the value. A test data generation method including steps.

(Appendix 16)
Design information storage for storing schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each section value, and schema item information of the first table and the second table And
A variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the partition value of the partition value is determined according to the schema item information of the first table stored in the design information storage unit. Means for generating a record of the first table according to variations and registering it in a database;
A variation for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table from the relationship multiplicity for each of the partition values of the schema related information stored in the design information storage unit Specific means,
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. First table non-generated record generating means for generating and registering in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating means for generating a record of the second table and registering the record in the database;
A test data generating apparatus having

(Appendix 17)
Schema-related information representing the relationship between the first and second tables and the relationship tables of the first and second tables and the relationship multiplicity for each segment value between the related data items in the first and second tables A design information storage unit that stores schema item information of each of the tables;
The variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the variation according to the variation of the partition value according to the schema item information stored in the design information storage unit Means for generating records of the first and second tables and registering them in the database;
Variation specification for specifying a variation of the record of the relation table including the related data item from the relation multiplicity for each of the division values between the related data items of the schema related information stored in the design information storage unit Means,
In the case where there is an ungenerated value that is a value of the related data item in the first and second tables required in the variation of the record in the relation table, the design information storage unit stores the value. According to the schema item information of the first and second tables, a record including the value of the related data item of the first and second tables is newly generated, registered in the database, and registered in the database. Using the records in the first and second tables, the relation table generating means for generating a record in the relation table and registering it in a database;
Have
The variation identification means is
When the relational multiplicity is a to n: b to m (n and m are integers of 2 or more, a is an integer of 0 to less than n, and b is an integer of 0 to less than m), n: m Means to expand to multiple sub-variations including
The relationship table generating means is
When generating a record group of the relation table for the n: m sub-variation, the relation number between records indicating the influence spread range at the time of data item change in the record group is the upper limit of the relation number between records specified One or a plurality of data sets including n values of related data items in the first table and m values of related data items in the second table are prepared so as to be maximum below the value. A test data generating device having means.

It is a figure for demonstrating the problem of a prior art. It is a figure which shows the system outline | summary which concerns on 1st Embodiment. It is a figure which shows the class diagram of a 1st example. It is a class diagram from another viewpoint of the first example. It is a figure which shows the processing flow in 1st Embodiment. It is a figure which shows an example of an input screen. It is a figure which shows an example of the schema relevant information of a user history table. It is a figure which shows an example of the classification and status information of a user table. It is a figure which shows an example of the schema item information of a user table. It is a figure which shows the 1st part of a user table. It is a figure which shows an example of an output screen. It is a figure which shows the processing flow in 1st Embodiment. It is a figure which shows the variation of the correspondence of the user table and user history table in a 1st example. It is a figure which shows the 2nd part of a user table. It is a figure which shows an example of the schema item information of a user history table. It is a figure which shows an example of a user history table. It is a figure which shows the 3rd part of a user table. It is a class diagram in the 2nd example. It is a figure which shows the classification and status information of the 2nd example. It is a figure which shows the variation of the correspondence of the user table and user history table in a 2nd example. It is a figure which shows the additional part of the user table in a 2nd example. It is a figure which shows the user history table in a 2nd example. It is a class diagram in the 3rd example. It is a figure which shows an example of the schema relevant information of a charge sales table. It is a figure which shows an example of the schema item information of a charge sales table. It is a figure which shows the variation in the correspondence of the user table and charge sales table in a 3rd example. It is a figure which shows an example of a charge sales table. It is a figure which shows an example of a charge sales table. It is a figure which shows an example of the schema relevant information of a salesperson table. It is a figure which shows an example of the schema item information of a salesperson table. It is a figure which shows an example of a salesperson table. It is a figure for demonstrating the premise of 2nd Embodiment. It is a figure for demonstrating the premise of 2nd Embodiment. It is a figure for demonstrating the premise of 2nd Embodiment. It is a class diagram of the specific example for demonstrating 2nd Embodiment. It is a figure which shows an example of the schema item definition of Table A. It is a figure which shows an example of the schema item definition of Table X. It is a figure which shows an example of the schema item definition of the table Z. It is a figure which shows an example of schema related information. It is a figure which shows the processing flow in 2nd Embodiment. It is a figure which shows an example of a setting information input screen. It is a figure which shows the state of the table A in a 1st step. It is a figure which shows the state of the table X in a 1st step. It is a figure which shows the state of the table Z in a 1st step. It is a figure which shows the processing flow in 2nd Embodiment. It is a figure which shows the processing flow of a record production | generation process. (A) thru | or (c) are figures which show an example of the data prepared initially in a record production | generation process. It is a figure which shows the data added to the table A in a 2nd step. It is a figure which shows the data added to the table X in a 2nd step. It is a figure which shows the data added to the table Z in a 2nd step. It is a figure which shows the processing flow of an n: m record production | generation process. It is a figure which shows an example of the data prepared in a 3rd step. It is a figure which shows an example of the data added in a 3rd step. It is a figure which shows an example of the data connected in the 3rd step. It is a figure which shows an example of the data further connected in the 3rd step. It is a figure which shows an example of the data added to the table A in a 3rd step. It is a figure which shows an example of the data added to the table X in a 3rd step. It is a figure which shows an example of the data added to the table Z in a 3rd step. (A) thru | or (d) are figures which show an example of the data prepared in a 4th step. It is a figure which shows an example of the data added to the table A in a 4th step. It is a figure which shows an example of the data added to the table X in a 4th step. It is a figure which shows an example of the data added to the table Z in a 4th step. It is a figure which shows the example of an output of a process result. It is a figure which shows an example of the data finally stored in the table A. 4 is a diagram illustrating an example of data finally stored in a table X. FIG. 4 is a diagram illustrating an example of data finally stored in a table Z. FIG. It is a functional block diagram of a computer.

DESCRIPTION OF SYMBOLS 1 Input part 3 Design information storage part 5 Design information reading part 7 Data generation determination part 9 Variation data storage part 11 Data generation part 13 DB

Claims (7)

Schema-related information indicating the relationship between the first table and the second table and the relationship multiplicity, the division state information regarding the combinations of the division and state of the first table that can be taken in business, and the first table A computer that can access a design information storage unit that stores schema item information of the second table, and a database that stores data of the first table and data of the second table;
From the partition state information stored in the design information storage unit, a combination that can be taken in the business of the partition and state in the first table is specified, and the combination of the first table stored in the design information storage unit Generating a record of the first table according to the combination according to schema item information and registering it in the database;
From the schema related information stored in the design information storage unit, a variation specifying step for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table;
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation program to execute The variation specifying step includes:
When the relational multiplicity in the schema-related information is 0 to n (variable) and the multiplicity upper limit m (an integer of 2 or more) is designated by the user, the one corresponding to one record of the first table A variation of no record in the second table, a variation of one record in the second table corresponding to one record in the first table, and the second corresponding to one record in the first table The test data generation program according to claim 1, further comprising a step of generating a variation of m records of the table. The variation specifying step includes:
In the schema-related information, from the relationship between a multiplicity of records for a particular record and said second table in the first table is x (0 or more integer) to n (variable) and multiplicity upper limit m (x When a large integer) is specified, the variation that the x record of the second table corresponds to the specific record of the first table, and the variation corresponding to the specific record of the first table 2. The test data according to claim 1, further comprising: generating a variation of m records of the second table and a variation of n records of the second table corresponding to a specific record of the first table. Generation program. The first table non-generated record generation step includes:
The test data generation program according to claim 1, further comprising: determining whether there is a usable value based on the variation among the column values corresponding to the foreign key in the first table. The second table record generation step includes:
2. The step of adopting a value that can be used based on the variation among column values corresponding to foreign keys in the first table as column values corresponding to foreign keys in the second table. The test data generation program described. Design information storage for storing schema-related information indicating the relationship between the first table and the second table and the relational multiplicity for each section value, and schema item information of the first table and the second table A computer that is accessible to a storage unit and a database that stores data of the first table and data of the second table;
A variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the partition value of the partition value is determined according to the schema item information of the first table stored in the design information storage unit. Generating a record of the first table according to variations and registering it in the database;
A variation for specifying a variation of the correspondence relationship between the record of the first table and the record of the second table from the relationship multiplicity for each of the partition values of the schema related information stored in the design information storage unit Specific steps,
If there is a record of the first table that is necessary for the variation and has not yet been generated, a new record is created in accordance with the schema item information of the first table stored in the design information storage unit. Generating a first table non-generated record to be registered in the database;
Necessary according to the variation in accordance with the relationship between the first table and the second table in the schema item information of the second table and the schema related information stored in the design information storage unit A second table record generating step of generating a record of the second table and registering the record in the database;
Test data generation program to execute Schema-related information representing the relationship between the first and second tables and the relationship tables of the first and second tables and the relationship multiplicity for each segment value between the related data items in the first and second tables A computer that can access a design information storage unit that stores schema item information of each table, and a database that stores each table,
The variation of the partition value specified by the schema related information stored in the design information storage unit is specified, and the variation according to the variation of the partition value according to the schema item information stored in the design information storage unit Generating records of the first and second tables and registering them in the database;
Variation specification for specifying a variation of the record of the relation table including the related data item from the relation multiplicity for each of the division values between the related data items of the schema related information stored in the design information storage unit Steps,
In the case where there is an ungenerated value that is a value of the related data item in the first and second tables required in the variation of the record in the relation table, the design information storage unit stores the value. According to the schema item information of the first and second tables, a record including the value of the related data item of the first and second tables is newly generated, registered in the database, and registered in the database. Using the records of the first and second tables, generating a record of the relation table and registering it in the database;
To the computer,
The variation specifying step includes:
When the relational multiplicity is a to n: b to m (n and m are integers of 2 or more, a is an integer of 0 to less than n, and b is an integer of 0 to less than m), n: m Including a deployment step that deploys to multiple sub-variations including
The relation table generating step includes
When generating a record group of the relation table for the n: m sub-variation, the relation number between records indicating the influence spread range at the time of data item change in the record group is the upper limit of the relation number between records specified One or a plurality of data sets including n values of related data items in the first table and m values of related data items in the second table are prepared so as to be maximum below the value. Test data generation program including steps.

Images