JP5471971B2 - Data generation method, data generation apparatus, and data generation program in model checking - Google Patents

Description

  The present invention relates to a technique for generating test data used for model checking.

  In conventional model checking, first, test data created in advance in a pseudo system is input using a driver. Here, the pseudo system is a program in which the behavior of the system to be inspected is created using a dedicated language or the like based on the design document or specification document of the system. The inspection target program that is a pseudo system is connected to a driver that runs the inspection target program and a stub for abstracting an external environment such as a database or a network. The driver continuously calls the inspection target program a plurality of times in various execution orders, and passes the test data imitating the user's operation as an argument to the inspection target program.

  Next, in model checking, the test target program is executed using the test data, and the execution result of the test target program using the test data corresponds to the test data recorded in the property. Processing for determining whether or not the condition is satisfied is performed.

  When the above-described processing is completed, the test data for the current inspection target program state is input again to the inspection target program using the driver, the inspection target program is executed, and the execution result is the inspection condition. It is determined whether or not

  In this way, in model checking, test data is input to all combinations that can be taken by each state transition that can be taken by the program to be checked, based on a design document, specifications, etc., and is repeatedly executed.

  However, in order to exhaustively perform model checking for all combinations, a driver that can create test data assuming all operations of the program to be checked and input the created test data is required. In other words, it is necessary to be able to reproduce the possible combinations in terms of specifications for the user operation event of the program to be inspected and the test data serving as an argument of the user operation event.

  For example, in model checking typified by Java PathFinder, the test data to be input to the inspection target program is determined depending on the operation result of the inspection target program, so a specific value is determined before operating the inspection target program. Can not. For example, let us consider a case in which there is a specification that a product cannot be purchased when the quantity that can be ordered exceeds the quantity in stock in a product ordering system that can place an order for a product multiple times. In the generation of test data by a conventional driver, a specific value is set for the inventory quantity, and a purchase quantity satisfying the inventory quantity <purchase quantity is obtained for each case. If the stock quantity is 100, the purchase quantity may be 101.

  However, when the inventory quantity changes by purchase, the quantity that can be purchased for the first time and the quantity that can be purchased for the second time are different. Therefore, in order to obtain the quantity that can be purchased for the second time, it is necessary to calculate the inventory quantity as a result of the first purchase, and it is also necessary to describe the inventory quantity in such a way that all specifications relating to the calculation can be judged. For example, if the purchase quantity is 90 at the first time, the inventory quantity is inventory quantity (100 pieces) −purchase quantity (90 pieces) = 10 pieces, so the boundary value at the next purchase is 10 pieces. However, in order to obtain the inventory quantity of 10 pieces, the specification “inventory quantity—the quantity becomes the next inventory quantity” must be described, but usually the driver does not support such a specification.

  Further, if the data created based on the boundary value is used in the second and subsequent purchases, the following problem occurs. When a product is purchased with a purchase quantity of 100 when the stock quantity is 100 for the first time, the boundary value of the inventory quantity becomes 0. However, if the same data as the first time is used, the inspection must be executed in the case of inventory quantity <purchase quantity, inventory quantity = purchase quantity, inventory quantity> purchase quantity even though there is no inventory. For example, the inspection is also performed on three patterns of 101, 100, and 90 purchased quantities. In addition, when a product is purchased with a purchase quantity of 90 pieces when the stock quantity is 100 pieces, the boundary value of the stock quantity is 10 pieces, but if the same data as the first time is used, the stock quantity is the same with 10 pieces. The three patterns must be executed. Further, when the stock quantity is 10 or less, the inspection is not performed. However, since a driver that covers all such specifications is not practical, the second and subsequent tests are performed using the first boundary value.

  As a technique for generating test data, a technique is known in which a route that has not passed during test execution is detected, a source program is analyzed, and an input parameter value that passes through the route is generated. In this technology, code coverage is measured during the test execution of the program, and after the test execution, the coverage result is analyzed to identify the unexecuted route, and the condition for executing the unexecuted route is extracted from the immediately preceding branch condition. To do. The input data passing through the unexecuted route is identified from the variable transition information measured during the test execution related to the condition.

JP 2000-347900 A

  The present invention has been made in view of the above circumstances, and an object thereof is to provide a data generation method, a model checking apparatus, and a data generation program for dynamically generating test data used in model checking.

  A data generation method (driver) that dynamically generates test data in model checking, which is one of the embodiments, is an input data item for each data item used by the computer that executes model checking in the program to be tested for model checking. Refers to the definition table that defines whether it is an output data item. Then, the input data item and the output data item are extracted from the description of the inspection condition used when the inspection target program is executed, and the extracted input data item is specified as the generation target item.

  Next, data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition is acquired and used as data of the output data item corresponding to the acquired data. Convert to format and generate output data.

Next, the inspection condition and the output data are converted into a data format to be input to the SMT solver program to generate a generation condition.
Next, the generation condition is input to execute the SMT solver program, data that satisfies the generation condition is obtained, data corresponding to the generation target item is extracted from the data, and the extracted data is extracted from the generation target item. Input to the execution environment of the program to be inspected.

  According to the embodiment, it is possible to improve inspection accuracy and execution efficiency by dynamically generating test data used in model checking.

1 is a block diagram illustrating an example of a model checking system according to Embodiment 1. FIG. It is a flowchart which shows an Example of operation | movement of the model check system of Embodiment 1. It is a state transition diagram which shows one Example of each state of the state transition which a test object program can take. It is a block diagram which shows one Example of a driver. The figure which shows one Example of the display screen, the screen item definition table, DB item definition table, and product table of the program which receives an order if the product ID and the order quantity are input from the screen of the input / output device and the stock quantity is sufficient. is there. It is a flowchart which shows one Example of operation | movement of a test condition specific | specification part. It is a figure which shows one Example of an inspection condition table. It is a figure which shows one Example of the operation | movement which extracts a data item from test | inspection conditions. It is a figure which shows one Example of a 1st production | generation condition table. It is a flowchart which shows one Example of operation | movement of an output data acquisition part. It is a figure which shows one Example of DB / screen output data table. It is a flowchart which shows one Example of operation | movement of a test condition conversion part. It is a figure which shows one Example of a conversion rule table and a 2nd production | generation condition table. It is a figure which shows one Example of a 2nd production | generation condition table. It is a flowchart which shows one Example of operation | movement of a SMT solver execution part. It is a figure which shows one Example of the execution result of a SMT solver execution part. It is a flowchart which shows one Example of operation | movement of a production | generation data notification part. It is a figure which shows one Example of the outline | summary of operation | movement of a production | generation data notification part. FIG. 6 is a diagram illustrating an example of a hardware configuration of a computer according to a second embodiment.

Details of the first embodiment will be described below with reference to the drawings.
FIG. 1 is a block diagram showing an embodiment of a model checking system. The model checking system in FIG. 1 includes a model checking unit 1, a driver 2, a check target program execution environment 3, a property 4, and the like. As a method for realizing the functions of the model checking unit 1, the driver 2, and the test target program execution environment 3, it is conceivable to use a Central Processing Unit (CPU). It is also conceivable to use a programmable device (Field Programmable Gate Array (FPGA), Programmable Logic Device (PLD), etc.). Note that the function of the model checking unit 1 and the functions of the driver 2 and the test target program execution environment 3 may be realized separately. Also, the program and data of the model checking unit 1, the driver 2, the test target program execution environment 3, and the property 4 are stored in a recording unit such as a memory such as a read only memory (ROM) or a random access memory (RAM) or a hard disk. It is possible to record. Further, data such as parameter values and variable values may be recorded in the recording unit, or may be used as a work area at the time of execution. Note that the program and data of the model checking unit 1, the driver 2, the test target program execution environment 3, and the property 4 need not be recorded in the same memory or hard disk.

  The model checking unit 1 executes model checking using the program execution environment 3 to be checked 3, the driver 2, and the property 4, and the condition described in the functional specification described later in which the execution result is recorded in the property 4 is satisfied. Judge whether it is.

The driver 2 generates dynamic test data used for model checking.
The inspection target program execution environment 3 includes an inspection target program 5, a database stub 6, and a net stub 7 to be described later, in which the behavior of the inspection target system is created in a dedicated language based on the design document and specifications of the inspection target system. have. The inspection target program 5 is a program in which the behavior of the system to be inspected is created based on a design document, a specification document, etc., in order to abstract the external environment such as the driver 2 that runs the inspection target program and the database 6 and the network 7. It is connected to the stub. The database stub 6 is a stub that imitates the recorded contents and operation of the database, and the net stub 7 is a stub that imitates the exchange between devices connected to the network.

In the property 4, the functional specifications described in the specification document, the design document, etc. are shown and recorded in the format of “B (consecutive part) if A (condition part)” (A-> B). The functional specification described in the specification or design document is, for example, “Purchasable if the purchase quantity entered at the time of purchase is within the inventory quantity”. Also, “Inventory quantity-Output warning if purchase quantity is less than 10”, “Error if purchase quantity is less than 0”, “Price over if purchase quantity × unit price exceeds 10,000 yen”, etc. . If the content corresponds to “Purchasable if the purchase quantity entered at the time of purchase is within the inventory quantity”, “Inventory quantity—Purchase quantity and Purchase quantity> 0” is recorded in the condition part, and “Message =“ “null” and stock quantity (after) = stock quantity−purchase quantity ”are recorded. Here, and is a symbol indicating a case where a plurality of conditions are simultaneously satisfied. The “message =...” Of the consequent part is a function for displaying a message, a calculation result, etc. on the screen of the output part described later. For example, when the message = “display content 1” and “display content 2” is described, “display content 1” and “display content 2” are displayed on the output unit. If the content corresponds to “stock quantity—output warning if purchase quantity is less than 10”, “0 ≦ stock quantity−purchase quantity <10 and purchase quantity> 0” is recorded in the condition part. In addition, “message =“ warning ”and inventory quantity (after) = inventory quantity−purchased quantity” are recorded in the consequent part. If the content corresponds to “an error if the purchase quantity is less than 0”, “purchase quantity ≦ 0” is recorded in the condition part, and “message =“ purchase quantity error ”” is recorded in the consequent part. . In addition, if the content corresponds to “Purchase quantity × Unit price exceeds 10,000 yen,” “Unit price × Purchase quantity ≧ 10000” is recorded in the condition part, and “Message =“ Amount over price ”is recorded in the result part. "" Is recorded.
The description format of the property 4 is not limited to the above format.

The operation of the model checking system will be described.
FIG. 2 is a flowchart showing an embodiment of the operation of the model checking system. In step S1, the model checking unit 1 lists options of inspection conditions that can be inspected in the current state. For example, a case will be described in which the state transition states that can be taken by the inspection target program 5 created based on a design document, specifications, and the like are combinations as shown in FIG. Moreover, the state 1 (round 1)-the state 10 (round 10) ... of FIG. 3 has shown each state of a state transition. State 1 in FIG. 3 represents an initial state, and state transition from state 1 to state 2, 3, or the like. State transitions from state 2 to states 4, 6, and 7. State transition from state 3 to state 10. State transition from state 4 to state 5 occurs. State transitions from state 7 to states 8 and 9. Here, if the current state is state 1, inspection conditions such as states 2 and 3 are listed. Similarly, if the current state is state 2, the inspection conditions of states 4, 6, and 7 are listed. The inspection condition is a condition part of a functional specification corresponding to each state recorded in the property 4. Further, the transition of each state shown in FIG. 3 is created in advance and recorded in the recording unit.

  In step S2, the model checking unit 1 identifies one from the checking conditions. For example, if the current state is state 2 in FIG. 3, the inspection conditions of states 4, 6, and 7 are listed, so the inspection conditions of states 4, 6, and 7 are selected. As a selection method, a method of sequentially selecting inspection conditions recorded in the property 4 can be considered. However, the selection method is not limited to the above.

  In step S <b> 3, the inspection condition specified by the model inspection unit 1 is input to the driver 2. Then, the driver 2 generates dynamic test data, which will be described later, and inputs the test data to the inspection target program execution environment 3. Next, it is executed by the inspection target program execution environment 3, and the execution result is output to the model checking unit 1.

  In step S4, the model checking unit 1 checks the execution result. For example, the description of the result part of the functional specification corresponding to each of the execution result and the state of the property 4 is compared. If the execution result satisfies the description content of the result part, it is determined that the result is acceptable in step S5, and step S7 (Yes ). When the execution result does not satisfy the description content of the consequent part, it is determined to be unacceptable in step S5, and the process proceeds to step S6 (No). If it is not acceptable in step S6, the model check may be stopped, or the model check may be continued by changing to another state.

  In step S7, the current state after the model checking unit 1 has passed is extracted by referring to the execution result of the inspection target program execution environment 3. For example, if the inspection has passed in the state 4 of FIG. 3, the state of the state 5 is extracted by the model checking unit 1.

  In step S8, it is determined whether or not the model checking unit 1 has already been inspected. If inspected, the process proceeds to step S10 (Yes), and the inspection has not yet been performed. If there is, the process proceeds to step S9 (No). For example, in step S7, in the state 7 of FIG. 3, when the inspection passes and the state 8 is extracted, if the state 8 has already been inspected, the state 7 is the previous state. To return the state, the process proceeds to step S10. If the state 8 is not yet inspected, the process proceeds to step S9 to determine whether there is a state to be inspected prior to state 8.

  In step S9, it is determined whether or not there is a state in which the model checking unit 1 performs the inspection prior to the current state. If there is no state in which the inspection is performed prior to the current state, it is determined as the end state and step S10. (Yes) If there is a state to be inspected before the current state, it is determined that the state is not an end state, and the process proceeds to step S1 (No). For example, if the state 8 in FIG. 3 has already been inspected, the state is returned to the previous state 7, and if the state 8 has not yet been inspected, the state 8 is returned. In order to execute the model check in the state, the process proceeds to step S1.

  In step S10, the model checking unit 1 returns the current state to the previous state. For example, if the state 8 in FIG. 3 is already inspected, the state is returned to the previous state 7.

  In step S11, it is determined whether the model checking unit 1 has executed each of the inspection conditions listed in step S1. If all the inspection conditions listed are executed, the process proceeds to step S12 (Yes). Transition. If there are inspection conditions that have not yet been executed, the process proceeds to step S2 (No).

  In step S12, the model checking unit 1 determines whether or not the current condition is the initial state. If the current state is the initial state, the model checking ends. If not, the process proceeds to step S10 (No). . For example, if the model check is completed for all states in the initial state of state 1 in FIG. 3, the model check is ended. In the case of the state 2, the process proceeds to step S10, and the state is returned to the previous state 1 (initial state).

The driver 2 will be described.
FIG. 4 is a block diagram showing an embodiment of the driver 2. The driver 2 in FIG. 4 includes an inspection condition specifying unit 201, an output data acquisition unit 202, an inspection condition conversion unit 203, a Satisability Modulo Theories (SMT) solver execution unit 204, and a generated data notification unit 205. The driver 2 has an inspection condition table 206, a screen item definition table 207, a DB item definition table 208, and a conversion rule table 211, which will be described later. In addition, a first generation condition table 209, a DB / screen output data table 210, a second generation condition table 212, and a generation data table 214 are provided. However, each table may be recorded in a place other than the driver 2. The driver 2 also has an SMT solver program executed by the SMT solver execution unit 204.

  The inspection condition specifying unit 201 extracts the input data item and the output data item from the description of the inspection condition used when executing the inspection target program with reference to the definition table, and specifies the input data item as the generation target item. . The definition table is a table in which whether each data item used in the inspection target program of model checking is an input data item or an output data item is defined. The definition table is, for example, a screen item definition table 207, a DB item definition table 208, or the like. The inspection condition specifying unit 201 will be described with reference to FIGS. 5 and 6.

  FIG. 5 is a diagram showing a display screen, a screen item definition table, a DB item definition table, and a product table for a program that accepts an order if the product ID and the order quantity are input from the screen of the input / output device and the stock quantity is sufficient. is there. When the above program is executed, a screen 51 as shown in FIG. 5 is displayed. The person in charge ID for identifying the person in charge, the input range 52 for inputting the ID for identifying the product on the screen 51, and the number of orders for the product. An input range 53 for inputting is displayed. In addition, on the screen 51 shown in FIG. 5, an order button 54 for notifying that the user has decided the order is displayed. In the example of FIG. 5, 1000 is recorded as the person-in-charge ID.

  Definitions of data input / output from the screen 51 are recorded in the screen item definition table 55. The screen item definition table 55 has “screen item name”, “input / output classification”, and “type”. In the “screen item name”, an identifier for identifying input / output data is recorded. In the example of FIG. 5, “person in charge ID”, “product ID”, and “number of orders” are recorded. In “Input / output category”, “input” and “output” that classify whether it is input data input from the screen or output data displayed on the screen are recorded in association with each “screen item name”. Has been. In the “type”, the type of data input / output associated with each “screen item name” is recorded. The type may be a type that defines the type of data used in C language, for example. In the example of FIG. 5, “int” indicating that all types are integers is recorded.

  The DB item definition table 56 in FIG. 5 records data used in the database stub 6 and has “table name”, “DB item name”, and “type”. In “Table name”, “Table name” for identifying a table used in the database stub 6 is recorded. In the example of FIG. 5, a “product table” is recorded. In “DB item name”, an identifier for identifying data used in each table is recorded. In the example of FIG. 5, “person in charge ID”, “product ID”, and “stock quantity” are recorded. In the “type”, the type of data input / output associated with each “DB item name” is recorded. The type may be a type used in C language, for example. In the example of FIG. 5, “int” indicating that all types are integers is recorded. The product table 57 is recorded in the database stub 6 of the inspection target program execution environment 3, and has “person in charge ID”, “product ID”, and “stock quantity”. "1000", "1000", "1010", and "1020" are recorded. In “Product ID”, identifiers “1”, “2”, “3”, and “4” for identifying products are recorded. In “stock quantity”, “10”, “200”, “1000”, and “50” indicating the stock quantity of the current product are recorded.

The inspection condition specifying unit 201 will be described.
FIG. 6 is a flowchart showing an example of the operation of the inspection condition specifying unit 201.
In step S61, the inspection condition specifying unit 201 specifies one data item from the inspection conditions in the inspection condition table 206. For example, the model checking unit 1 executes model checking using the checking conditions associated with each item number of the checking condition table 206 shown in FIG. Here, the inspection condition table 206 has “item number” and “inspection condition”. The “item number” is an identifier for identifying the inspection condition. In this example, “P1”, “P2”, “P3”,... Are recorded. In the “inspection condition”, a description corresponding to the condition part of the functional specification already recorded in the property 4 is recorded in association with the “item number”. In this example, “screen.order quantity <= 0” is recorded in association with “P1”. The case where the number of orders input by the user in the input range 53 of the screen 51 is 0 or less is shown. Further, in association with “P2”, “screen.order number> 0 and (numOf (filter (rec in product table, rec.person in charge ID == screen.person in charge ID and rec.product ID == screen.product ID and rec.stock quantity> = screen.order quantity)) == 1) "is recorded. Here, rec represents a certain record in the table. In the inspection condition, the number of orders entered by the user in the input range 53 of the screen 51 is greater than zero. In addition, the person-in-charge ID in the product table and the person-in-charge ID on the screen 51 are the same, and the product ID in the product table and the product ID input by the user in the input range 52 of the screen 51 are the same. Furthermore, the case where the number of stocks in the product table is equal to or greater than the number of orders entered by the user in the input range 53 of the screen 51 is shown. That is, the case where the order is successful is shown. Further, in association with “P3”, “screen.order number> 0 and (numOf (filter (rec in product table, rec.person in charge ID == screen.person in charge ID and rec.product ID == screen.product ID and rec.stock quantity <screen.order quantity)) == 1) "is recorded. Here, rec represents a certain record in the table. In the inspection condition, the number of orders entered by the user in the input range 53 of the screen 51 is greater than zero. In addition, the person-in-charge ID in the product table and the person-in-charge ID on the screen 51 are the same, and the product ID in the product table and the product ID input by the user in the input range 52 of the screen 51 are the same. Furthermore, the case where the number of stocks in the product table is smaller than the number of orders entered by the user in the input range 53 of the screen 51 is shown. That is, the case where the inventory quantity is insufficient is shown.

  If the model checking unit 1 acquires the inspection condition associated with “P2” of the “item number” in the inspection condition table 206 shown in FIG. 7, first, the data item is extracted from the inspection condition corresponding to P2. To do. Next, the inspection condition corresponding to P2 is recorded as the inspection condition in the first generation condition table 209.

  Next, the extraction of data items is described in, for example, “screen item name” in the screen item definition table 55 and “table name” and “DB item name” in the DB item definition table 56 from the description content of the inspection condition corresponding to P2. Extract data items that match the recorded data. In this example, as shown by 81 in FIG. 8, the data items “screen.number of orders” “product table.person ID” “screen.person ID” “product table.product ID” “screen.product ID” “product”. "Table. Inventory quantity" is extracted. Then, one data item is specified from the extracted data items.

  The first generation condition table 209 separately records input data items and output data items extracted from the description of the inspection conditions. For example, as shown in the first generation condition table 91 in FIG. 9, it has “inspection conditions”, “screen output items”, “DB items”, and “generation target items”. In the example of FIG. 9, the contents of the inspection condition associated with P <b> 2 are recorded in the “inspection condition” of the first generation condition table 91. Output data items are recorded in “screen output items” and “DB items”, and input data items are recorded in “generation target items”.

  In step S62, it is determined with reference to the DB item definition table 208 whether or not the data item specified by the inspection condition specifying unit 201 is a DB item. If the data item is a DB item in step S63, step S64 is performed. (Yes) If it is not a DB item, the process proceeds to step S65 (No). For example, since the data item of the product table 57 is a DB item, “product table. Person in charge ID”, “product table. Product ID”, “product table. Inventory quantity” is allocated to the DB item. If the data item has a description such as “screen”, it is determined to be a screen item. For example, “screen.order number”, “screen.person in charge ID”, and “screen.order number” are screen items.

  In step S64, the inspection condition specifying unit 201 records a data item that is a DB item in the output data item of the first generation condition table 209, and proceeds to step S69. For example, in the first generation condition table 91, the data item is recorded in “DB item” in which the data item that is the DB item is recorded. In this example, “product table.person in charge ID”, “product table.product ID”, “product table.stock quantity” is recorded in “DB item” of the first generation condition table 91.

  In step S65, the inspection condition specifying unit 201 determines whether the data item distributed with reference to the screen item definition table 207 is a screen output item. In step S66, when the inspection condition specifying unit 201 is a screen output item, the process proceeds to step S67 (Yes), and when it is not a screen output item, the process proceeds to step S68 (No). For example, referring to “input / output classification” in the screen item definition table 55 in FIG. 5, when the data item is “output”, the process proceeds to step S67 (Yes). If the data item is “input”, the process proceeds to step S68 (No).

  In step S67, the inspection condition specifying unit 201 records the data item in the screen output item (output data item) of the first generation condition table 209, and proceeds to step S69. In this example, “screen.person ID” is recorded in “screen output item” of the first generation condition table 91 of FIG.

  In step S68, the inspection condition specifying unit 201 records the data item in the generation target item (input data item) in the first generation condition table 209. In this example, “screen.number of orders” “screen.number of orders” is recorded in “generation target item” of the first generation condition table 91 of FIG.

  In step S69, it is determined whether the inspection condition specifying unit 201 has processed all the data items. If all the data items have been distributed, the process proceeds to the processing of the output data acquisition unit 202, and the data that has not been distributed yet. If there is an item, the process proceeds to step S61.

The output data acquisition unit 202 will be described.
The output data acquisition unit 202 acquires data corresponding to the output data item extracted from the description of the inspection condition recorded in the execution environment of the inspection target program, and indicates that the acquired data is used in the output data item. Output data is generated by converting to a format. For example, data corresponding to data items recorded in output data items such as screen output items and DB items in the first generation condition table 209 is obtained by accessing the program execution environment 3 to be inspected, and the DB / screen Record in the output data table 210.

FIG. 10 is a flowchart showing an embodiment of the operation of the output data acquisition unit 202.
For example, a case will be described in which there is a program that accepts an order if the inventory number is sufficient by inputting the product ID and the number of orders from the screen of the input / output device described above into the inspection target program execution environment 3. Assume that the current state is the state of the first generation condition table 91 shown in FIG. Further, as shown in FIG. 11, it is assumed that the screen state of the current program execution environment 3 to be inspected is the state shown in the screen 51 and the state of the table recorded in the database stub 6 is the state shown in the product table 57. .

  In step S <b> 101, the output data acquisition unit 202 refers to the “DB item” in the first generation condition table 91 and identifies the data item. Next, in step S <b> 102, the output data acquisition unit 202 acquires data related to the data item “DB item” from the inspection target program execution environment 3. In this example, the output data acquisition unit 202 associates all the data items recorded in the “DB item” of the first generation condition table 91 with the product table 57. get.

  In step S103, the data acquired by the output data acquisition unit 202 is converted into a format indicating that the output data item is used, and recorded in the DB / screen output data table 210. For example, if the data acquired by the output data acquisition unit 202 is the product table 57, the data shown in “DB data” in FIG. 11 is recorded. In this example, “DB data” corresponds to “Product table [0]. Person in charge ID = 1000, Product table [0]. Product ID = 1, Product table [0]. Number = 10 ”is recorded. In addition, in “DB data”, “product table [1]. Person in charge ID = 1000, product table [1]. Product ID = 2, product table [1]. = 200 "is recorded. In addition, in “DB data”, “product table [2]. Person in charge ID = 1010, product table [2]. Product ID = 3, product table [2]. = 1000 "is recorded. In addition, in “DB data”, “product table [3]. Person in charge ID = 1020, product table [3]. Product ID = 4, product table [3]. = 50 "is recorded.

  In step S104, the output data acquisition unit 202 records the number of rows in the number of records representing the number of rows in the DB / screen output data table 111. In this example, since the number of rows in the product table 57 is 4, “4” is recorded in “DB record number” in the DB / screen output data table 111. However, the “number of DB records” may not be present.

  In step S <b> 105, the output data acquisition unit 202 refers to the “screen output item” in the first generation condition table 91 and identifies the data item. Next, in step S <b> 106, the output data acquisition unit 202 acquires data related to the data item of the screen output item from the inspection target program execution environment 3. For example, the output data acquisition unit 202 displays the data item recorded in the “screen output item” of the first generation condition table 91 as a screen. The screen of the program execution environment 3 to be inspected because it is associated with the person in charge ID. Data related to the person-in-charge ID is acquired.

  In step S107, the data acquired by the output data acquisition unit 202 is converted into a format indicating that the output data item is used and recorded in the DB / screen output data table 210. In this example, screen. Data associated with the person-in-charge ID “screen. Person-in-charge ID = 1000” is recorded in “screen output data” in FIG.

The inspection condition conversion unit 203 will be described.
The inspection condition conversion unit 203 converts the inspection condition and output data into a data format to be input to the SMT solver program, and generates a generation condition. For example, the inspection condition conversion unit 203 converts the inspection conditions using the conversion rule table 211 and the DB / screen output data table 210.

FIG. 12 is a flowchart showing an example of the operation of the inspection condition conversion unit 203.
In step S121, the inspection condition conversion unit 203 acquires the number of records in each table from the DB / screen output data table 210. For example, in the case of the DB / screen output data table 111 in FIG. 11, “4” is acquired from “number of DB records”. Further, when there is no “DB record number”, the number of rows may be obtained using “DB data”. In this example, there is only the product table 57, but when there are a plurality of tables used in the database stub 6 or the like, the number of records in each table is acquired.

  In step S122, the inspection condition conversion unit 203 compares the inspection condition recorded in the first generation condition table 209 with each of the pre-conversion patterns in the conversion rule table 211, and identifies the pre-conversion pattern whose format matches. . And the variable contained in inspection conditions is extracted using the specified pattern before conversion. For example, the format of the description content of “inspection condition” in FIG. 9 is compared with the format of each pre-conversion pattern recorded in the conversion rule table 131 in FIG. In the example of FIG. 13, since it matches the format of “numOf (filter (rec in% DB table%,% conditional expression%)) == 1” of “pre-conversion pattern” in the conversion rule table 131, it is specified. Variables included in the inspection conditions are extracted using the pre-conversion pattern. Variable “product table” “rec. Person in charge ID == screen. Person in charge ID and corresponding to the character string“% DB table% ”“% conditional expression% ”enclosed in% of“ pattern before conversion ” “rec.Product ID == Screen.Product ID and rec.Stock quantity> = Screen.Order quantity” is extracted.

  In step S123, the inspection condition conversion unit 203 converts the inspection conditions by substituting the extracted variables and the number of records into the post-conversion pattern of the conversion rule table 211, and records it in the second generation condition table 212. For example, the post-conversion pattern “For i = 0 to% DB table%. Number of DB records {% conditional expression%} or connection” associated with the pre-conversion pattern specified in step S122 of the conversion rule table 131 of FIG. To generate a generation condition. The post-conversion pattern is a function for converting the inspection condition into the input data of the SMT solver, and the generation condition is data used for the input data of the SMT solver. In this example, the data is converted into the format shown in the generation condition 132 of FIG. “For i = 0 to% DB table%. Number of DB records” indicates [0] to [3] indicating each record of the “product table” indicated by “% DB table%”. “% Conditional expression%” is “product table [0]. Person in charge ID == screen. Person in charge ID and product table [0]. Product ID == screen. ID and product table [0]. Quantity in stock> = screen. When the record of the product table is [1], “Product table [1]. Person in charge ID == screen. Person in charge ID and product table [1]. Product ID == Screen. Product ID and product table [1] .. Stock quantity> = screen. When the record of the product table is [2], “Product table [2]. Person in charge ID == Screen. Person in charge ID and product table [2]. Product ID == Screen. Product ID and product table [2] .. Stock quantity> = screen. When the record of the product table is [3], “Product table [3]. Person in charge ID == screen. Person in charge ID and product table [3]. Product ID == Screen. Product ID and product table [3] .. Stock quantity> = screen. “Or connection” indicates that the descriptions corresponding to the four “% conditional expression%” are combined with the logical sum “or”. However, the function of the post-conversion pattern of this example is not limited to the post-conversion pattern as long as it is a function that can be converted into the input data format of the SMT solver that is actually used.

  In step S124, the inspection condition conversion unit 203 determines whether all the conversion processing has been performed on the inspection conditions. If all the conversion processing has been performed, the process proceeds to step S125 (Yes), and all conversion processing is performed. If not, the process proceeds to step S122 (No). For example, when the inspection condition has a plurality of pre-conversion pattern formats, it is determined whether or not conversion processing has been performed on all the pre-conversion patterns.

  In step S <b> 125, the inspection condition conversion unit 203 acquires the screen output data of the DB / screen output data table 210, converts it into a conditional expression, and records it in the second generation condition table 212. For example, “screen.person in charge = 1000” recorded in “screen output data” is acquired from the DB / screen output data table 111 in FIG. 11, and “and screen.person in charge = 1000” is obtained as shown in FIG. "And add to the post-conversion generation conditions and record. However, the conversion of this example may be a function that can be converted into the input data format of the SMT solver that is actually used, and is not limited to the above conversion.

  In step S126, the inspection condition conversion unit 203 acquires the DB data of the DB / screen output data table 210, converts it into a conditional expression, and records it in the second generation condition table 212. For example, the data recorded in the “DB data” is acquired from the DB / screen output data table 111 of FIG. 11, and “and product table [0]. Person in charge ID = 1000 and product table as shown in FIG. [0] .Product ID = 1 and product table [0] .Stock quantity = 10 and... ”And added to the post-conversion generation condition and recorded. However, the conversion of this example may be a function that can be converted into the input data format of the SMT solver that is actually used, and is not limited to the above conversion.

The SMT solver execution unit 204 will be described.
The SMT solver execution unit 204 executes the SMT solver program 213 with the generation conditions recorded in the second generation condition table 212 generated by the inspection condition conversion unit 203 as input, and obtains data that satisfies the generation conditions. Next, the SMT solver execution unit 204 extracts screen input data from the generation target items in the first generation condition table 209 and records the screen input data in the generation data table 214. The SMT solver determines the satisfaction of constraints input using the DPLL (T) algorithm (see Decision Procedures: An Algorithmic Point of View, Daniel Kroening et al., ISBN: 978-3540741046, Chapter 11) To do. Here, DPLL (T) is an extension of the DPLL algorithm, which is a satisfiability determination algorithm for propositional logic, to predicate logic. DPLL stands for Davis-Putnam-Logemann-Loveland, T stands for Theory, which refers to a subset of predicate logic. For example, a class of logical expressions composed only of natural number equivalence relations (=) such as “x = y and y = 1 and x! = 2” is one of theories. In the SMT solver, first, a propositional logical expression corresponding to the atomic logical expression that is the logical minimum unit of the input constraint is newly given. Subsequently, the SMT solver gives a true / false value to each propositional logical expression so that the logical expression obtained by converting each atomic logical expression of the constraint with the corresponding propositional logical expression can be satisfied. Then, an attempt is made to obtain a specific sufficiency value of an instance (variable) appearing in the atomic logical formula so that the true / false value of the atomic logical formula matches the true / false value of each corresponding propositional logical formula. When a specific sufficient value for each instance can be actually obtained, the SMT solver determines that the input constraint can be satisfied, and outputs the obtained sufficient value as a sufficient solution. If the satisfaction value cannot be obtained, the SMT solver determines that the input constraint is not satisfactory. With this processing, the SMT solver receives the post-conversion constraint as an input and outputs a post-conversion constraint satisfaction solution.

FIG. 15 is a flowchart illustrating an example of the operation of the SMT solver execution unit 204.
In step S151, the SMT solver execution unit 204 acquires and executes the generation conditions of the second generation condition table 212. Then, the SMT solver execution unit 204 acquires the execution result. For example, the SMT solver execution unit 204 inputs the generation condition 141, executes the SMT solver program 213, and acquires the execution result. An execution result 161 of FIG. 16 shows an example of the execution result of the SMT solver program.

  In step S152, the SMT solver execution unit 204 acquires the data item of the generation target item recorded in the first generation condition table 209. For example, the data item “screen.order number” “screen.product ID” of the first generation condition table 91 is acquired. FIG. 16 shows the generation target item 162.

  In step S153, the SMT solver execution unit 204 extracts the generation data used for the generation target item from the execution result, and records it in the generation data table 214. For example, “screen.order quantity = 10” and “screen.product ID = 1” of the execution result 161 are extracted and recorded in the generation data table 163 in FIG.

The generated data notification unit 205 will be described.
The generated data notification unit 205 inputs the generated data of the generated data table 214 to the inspection target program execution environment 3 in order to execute the inspection target program using the generated data of the generated data table 214.

FIG. 17 is a flowchart illustrating an example of the operation of the generated data notification unit 205.
In step S <b> 171, the generation data notification unit 205 acquires generation data from the generation data table 214. Next, in step S172, the generated data notification unit 205 inputs the generated data as test data to the inspection target program. In the case of FIG. 18, the screen, which is the generation data of the generation data table 163, the order quantity = 10 and the screen, the product ID = 1, is input to the inspection target program as test data. Thereafter, the model checking unit 1 executes the current program to be checked, determines whether or not the model check is completed when the execution is completed, and specifies the next check condition when continuing the model check.

  According to the driver of the first embodiment, when it is necessary to determine test data based on values used in a plurality of data items included in a generation target item, generation data that satisfies a post-conversion generation condition is generated and inspected as test data Enter the target program execution environment. In other words, since test data can be dynamically input to the program execution environment to be inspected, it is possible to suppress inputting unnecessary test data to the program execution environment to be inspected and executing it as in the past. Execution efficiency can be improved. In addition, since test data is dynamically generated, inspection conditions that could not be inspected conventionally can be inspected, so that the accuracy of model inspection can be improved. Further, since the test data input to the inspection target program is determined depending on the operation result of the inspection target program, a specific value can be determined before the inspection target program is operated. Further, when an inspection condition that could not be inspected is detected, it is not necessary to generate a driver for the inspection condition and recompile as in the prior art, so that the preparation work for performing model inspection can be reduced.

Embodiment 2 will be described.
Embodiment 2 demonstrates the case where Embodiment 1 is implement | achieved using a computer.
FIG. 19 is a diagram illustrating an example of the hardware configuration of the computer according to the second embodiment. A computer hardware 1900 includes a CPU 1901, a recording unit 1902, a recording medium reading device 1903, an input / output interface 1904 (input / output I / F), a communication interface 1905 (communication I / F), and the like. Further, each of the above components is connected by a bus 1906.

The CPU 1901 executes the above-described processes recorded in the recording unit 1902.
The recording unit 1902 records programs executed by the CPU 1901 and data. It is also used as a work area. For example, ROM, RAM, hard disk drive, etc.

  The recording medium reading device 1903 controls reading / writing of data with respect to the recording medium 1907 according to the control of the CPU 1901. Then, the data written under the control of the recording medium reading device 1903 is recorded on the recording medium 1907, or the data stored in the recording medium 1907 is read. The detachable recording medium 1907 includes a non-transitory recording medium that can be read by a computer, such as a magnetic recording device, an optical disk, a magneto-optical recording medium, and a semiconductor memory. The magnetic recording device includes a hard disk device (HDD). Optical discs include Digital Versatile Disc (DVD), DVD-RAM, Compact Disc Read Only Memory (CD-ROM), and CD-R (Recordable) / RW (ReWritable). Magneto-optical recording media include magneto-optical disks (MO). Note that the recording unit 1902 is also included in a non-transitory recording medium.

  An input / output device 1908 is connected to the input / output interface 1904, receives information input by the user, and transmits the information to the CPU 1901 via the bus 1906. Further, operation information or the like is displayed on the display screen in accordance with a command from the CPU 1901. The input / output device 1908 may be a touch panel, for example.

  The communication interface 1905 is an interface for performing Local Area Network (LAN) connection, Internet connection, and wireless connection with other computers as necessary. It is also connected to other devices and controls data input / output from external devices.

  By using a computer having such a hardware configuration, the various processing functions described above are realized. In that case, a program describing the processing contents of the functions that the system should have is provided. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded in a computer-readable recording medium 1907. The various processing functions are the flowcharts described in the first embodiment.

  When distributing the program, for example, a recording medium 1907 such as a DVD or a CD-ROM in which the program is recorded is sold. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.

  The computer that executes the program stores, for example, the program recorded in the recording medium 1907 or the program transferred from the server computer in its recording unit 1902. Then, the computer reads the program from its own recording unit 1902 and executes processing according to the program. Note that the computer can also read the program directly from the recording medium 1907 and execute processing according to the program. Further, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.

  The present invention is not limited to the above-described embodiment, and various improvements and modifications can be made without departing from the gist of the present invention. Each embodiment may be combined with each other as long as there is no contradiction in processing.

DESCRIPTION OF SYMBOLS 1 Model inspection part 2 Driver 3 Inspection object program execution environment 4 Property 5 Inspection object program 6 Database stub 7 Net stub 201 Inspection condition specific | specification part 202 Output data acquisition part 203 Inspection condition conversion part 204 SMT solver execution part 205 Generating data notification part 206 Inspection condition table 207, 55 Screen item definition table 208, 56 DB item definition table 209, 91 First generation condition table 210, 111 DB / screen output data table 211, 131 Conversion rule table 212, 132, 141 Second generation Condition table 213 SMT solver program 214, 163 Generation data table 51 Screen 52, 53 Input range 54 Order button 57 Product table 161 Execution result 162 Generation target item 1900 Hardware A 1901 CPU
1902 Recording unit 1903 Recording medium reader 1904 Input / output interface (input / output I / F)
1905 Communication interface (communication I / F)
1906 Bus 1907 Recording medium 1908 Input / output device

Claims (3)

A computer that performs model checking
For each data item used in the inspection target program of the model inspection, with reference to a definition table that defines whether the data item is an input data item or an output data item, an inspection condition used when executing the inspection target program Extract the input data item and output data item from the description, identify the extracted input data item as the generation target item,
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data To generate output data,
The inspection conditions and the output data are converted into a data format to be input to the SMT solver program to generate generation conditions,
Input the generation condition, execute an SMT solver program, obtain data satisfying the generation condition, extract data corresponding to the generation target item from the data,
The extracted data is input to the execution environment of the inspection target program as the input of the generation target item.
A data generation method that performs that. Description of inspection conditions used when executing the inspection target program with reference to a definition table that defines whether each data item used in the inspection target program of model checking is an input data item or an output data item An input data item and an output data item extracted from the test condition specifying unit for specifying the extracted input data item as a generation target item;
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data An output data acquisition unit for generating output data,
An inspection condition conversion unit that generates the generation condition by converting the inspection condition and the output data into a format of data input to the SMT solver program;
An SMT solver execution unit that inputs the generation condition, executes an SMT solver program, obtains data that satisfies the generation condition, and extracts data corresponding to the generation target item from the data;
A generation data notification unit for inputting the extracted data to the execution environment of the inspection target program as input of the generation target item;
A data generation device comprising: A computer that performs model checking,
For each data item used in the inspection target program of the model inspection, with reference to a definition table that defines whether the data item is an input data item or an output data item, an inspection condition used when executing the inspection target program Extracting input data items and output data items from the description and identifying the extracted input data items as generation target items;
Acquires data recorded in the execution environment of the inspection target program corresponding to the output data item extracted from the description of the inspection condition, and converts it to a format used as data of the output data item corresponding to the acquired data Process to generate output data,
A process for generating the generation condition by converting the inspection condition and the output data into a data format to be input to the SMT solver program;
A process of inputting the generation condition, executing an SMT solver program, obtaining data satisfying the generation condition, and extracting data corresponding to the generation target item from the data;
A process of inputting the extracted data into the execution environment of the inspection target program as the input of the generation target item;
A data generation program characterized in that

Images