JP5561135B2 - Data generation method, program, and apparatus - Google Patents

Description

  The present invention relates to a software operation confirmation test, and more particularly to a technique for generating test data used in model checking for checking whether a model expressing a system specification satisfies a property required for the system. .

  Software model checking is to comprehensively execute whether a program corresponding to a model satisfies a property (referred to as a property) that must be satisfied as a specification, and the property is established in the program state at the time of execution. This is an inspection method by checking whether or not.

  Here, the model is a description of the behavior and processing contents of the system to be developed, and there are various models depending on the level of detail of the description. For example, at the level of the outline design, a model describing the static structure and processing sequence of information processed by the system using UML (Unified Modeling Language) is used. In addition, when a development specification is described strictly, a specification description language is used to describe the development specification as a model. Furthermore, when modeling dynamic aspects of a development system, for example, state transitions are described using a model description language such as Promela. Model checking can be executed on a model described in Promela using a tool called SPIN model checker.

  A program written using an executable program language such as Java (registered trademark) is also considered to be a model with the most detailed description. Model checking using a program as a model is particularly called program model checking, but is hereinafter simply referred to as model checking. As a model checking tool for a program written in Java, for example, there is a JPF (Java Path Finder). The model dealt with in this application describes the business logic on the server side of the Web application.

  In general, in model checking for a Web application program, a screen state displayed on a browser or the like and a database state on the server side, that is, a data value stored in the database, are used as a program state to be observed.

  The model checking process consists of first setting the initial state of the screen and database for the program to be checked, and then using the driver to drive the program to be checked by raising events one after another. To do. At this time, the driver comprehensively selects events and input data so that the inspection target program can be in various states. Then, while driving the event, it is checked whether the property violation (bug) has occurred by checking whether the program state satisfies the property.

  Here, an event is a user operation such as inputting data into an item on the screen and pressing a button. The property describes the logic properties that the model (program) should satisfy. Specifically, it has a configuration that includes preconditions and postconditions related to the events to be inspected and the events to be evaluated, and the preconditions and postconditions are described by logical expressions using first-order predicate logic, temporal logic, etc. Can be processed by a computer or the like.

  In the property check in model checking, for the event to be checked, when the precondition is “true” in the program state before event driving, it is confirmed that the postcondition is “true” in the program state after event driving. It is. That is, if the precondition is not evaluated to be true, the postcondition is not evaluated, and any property for which the precondition has never been true will not be checked during program execution. Therefore, it is necessary to adjust the driver and program initial state so that all property preconditions are true at least once.

  In particular, in model checking for a Web application, screen data is set in a driver, and database data (DB data) is set as an initial program state. For this reason, there has conventionally been a technique of generating screen data and DB data that make the constraint described in the preconditions true by using the properties themselves and common constraints on the DB data.

  In recent years, with the dramatic improvement in computer performance, a tool (solver) that solves the satisfiability problem of logical formulas such as SAT (SATisability probabilities) and SMT (Satisfiability Modulo Theories) is used. It is considered to find a satisfactory solution for the property precondition.

  The inventor is examining a technique for generating screen data and DB data using techniques such as SAT and SMT. A constraint condition to be satisfied by data is constructed from property preconditions, and a specific data value that satisfies the data constraint condition is generated using an SMT solver. The SMT solver solves the satisfiability problem of a logical expression, for example, by inputting a logical expression and outputting a condition range that the data should satisfy.

JP 2009-87354 A JP 2010-102650 A

  However, in the prior art, data that can be solved individually as a satisfiability problem using the preconditions of each property as data constraint conditions, and the preconditions are satisfied is generated. In other words, in the prior art, data cannot be generated in consideration of the context of properties such as dependency relationships and causal relationships.

  Therefore, if the properties are set in a context on the execution path of the program to be inspected, even if the data generated using the prior art is input to the program to be inspected and driven, There was a problem that the precondition of the corresponding property was not necessarily true later. If the property precondition does not become true, the program to be inspected does not evaluate whether or not the property is satisfied. Therefore, the data generated by the prior art is insufficient.

  In order to deal with the above-mentioned problems of the prior art, it is difficult to simply consider the context of properties for the following reasons.

  (1) Property context cannot be determined from property descriptions alone.

  (2) From only the description of the property, it is not possible to determine which of the items constituting the property precondition is the data input in the event.

  The present invention has been made in view of the above problems, and its object is to provide a precondition for the property when the property is set in a context on the execution path of the program to be inspected. It is to provide a technique capable of generating data such that is true.

  A data generation method disclosed as one aspect of the present invention is a method for generating test data for confirming the operation of a program, in which a computer shows 1) transition between screens executed by a program to be inspected. Transition information, screen item information indicating an item included in each screen, and a screen information setting processing step for reading a property indicating a specification to be satisfied by the program; and 2) on the screen transition indicated by the screen transition information. A property placement processing step for determining which screen transition specification of which one corresponds to, and associating the property determined to be relevant to the screen transition, and 3) for the property associated with the screen transition, Determine whether it is caused by the input item at the most recent event on the screen transition of the program. An input determination processing step in which the determination is true when the condition is caused by the input item at the most recent event; and 4) screen transition of the program when the property precondition is not the input item at the most recent event. Collecting properties until the input item judgment for the acquired property is true, and collecting the acquired property group as a dependent property; A data constraint generation processing step for generating a constraint condition for data generation using the precondition, the postcondition and the connection condition is executed.

  A data generation program disclosed as another embodiment of the present invention is for causing a computer to execute each process realized by the above processing method.

  In addition, a data generation apparatus disclosed as another aspect of the present invention includes each processing unit that executes processing realized by the above processing method.

  The data generation apparatus disclosed as one aspect of the present invention generates data such that the property precondition is true when the property is set in a context on the execution path of the inspection target program. It is possible to reduce the labor of data generation processing for model checking.

It is a figure showing an example of the whole model checking device in an embodiment of the present invention. It is a figure which shows the block structural example of the data generation apparatus in embodiment of this invention. It is a figure which shows the example of the screen transition in the web application of the test object in embodiment of this invention. It is a figure which shows the example in case a screen transition which changes with the values of a display item (member type) occurs. It is a figure which shows the example of the database information in embodiment of this invention. It is a figure which shows the example of the property in embodiment of this invention. It is a figure which shows the example of the screen transition information in embodiment of this invention. It is a figure which shows the example of the screen item information in embodiment of this invention. It is a figure which shows the example of a processing flow of the data constraint production | generation part in embodiment of this invention. It is a figure which shows the example of a more detailed process flow of a property arrangement | positioning process (step S2). It is a figure which shows the information extracted from a property by the property arrangement | positioning part in embodiment of this invention as a table. It is a figure which shows the example of the result table produced | generated by the property arrangement | positioning part in embodiment of this invention. It is a figure which matches and shows the process result of a property arrangement | positioning part on a screen transition. It is a figure which shows the example of a more detailed process flow of the input determination process (step S3) of a property. It is a figure which shows the example of a process result of the input determination part in embodiment of this invention. It is a figure which shows the process result of an input determination part matched with a screen transition. It is a figure which shows the example of a more detailed process flow of a property retroactive acquisition process (step S4) and a dependence property extraction process (step S5). It is a figure which shows the example of the work table of the dependence property collection part in embodiment of this invention. It is a figure which shows the example of a list by the dependency property which is an output result of the dependency property collection part in embodiment of this invention. It is a figure which shows the process result of a dependence property collection part matched with a screen transition. It is a figure which shows the example of a more detailed process flow of a property arrangement | positioning process (step S7). It is a figure which shows the example of the process result of the dependence property rearrangement part in embodiment of this invention. It is a figure which shows the example of a more detailed process flow of a constraint condition production | generation process (step S8). It is a figure which shows the example of the process result of a data constraint production | generation part. It is a figure which shows the example of the property whose input determination is not true. It is a figure which shows the example of the property whose input determination is not true. It is a figure which shows the example of a more detailed process flow of a property complementation process (step S6). It is a figure which shows the example of the process result of the property complementation part in embodiment of this invention.

  In the following, an embodiment for generating test data to be used when performing model checking for a program that uses a screen and a database (DB) as a check target is also disclosed in the data generating device disclosed as one aspect of the present invention. And explained.

  FIG. 1 is a diagram illustrating an example of an entire model checking apparatus that performs data generation and model checking.

  A model checking device 1 shown in FIG. 1 includes a data generation device 3 and a check execution device 5 and is connected to an input / output device (not shown). The data generation device 3 is a device disclosed as one aspect of the present invention.

  Each of the data generation device 3 and the inspection execution device 5 includes a control unit 10 and a storage unit 20 and is connected to an input / output device.

  In the model checking device 1, the data generation device 3 generates test data 25 for model checking by input and operation from the input / output device, and the test execution device 5 generates test data 25 generated by the data generation device 3. Is used to perform model checking of the program 27 to be checked.

  The model checking device 1 is realized by a computer or dedicated hardware.

  The control unit 10 controls the exchange of information with peripheral devices such as an input / output device and an external recording device that are not shown in FIG. 1 in addition to the data generation device 3 and the test execution device 5. For the realization of the control unit 10, a CPU (Central Processing Unit) or a programmable device (FPGA (Field Programmable Gate Array), PLD (Programmable Logic Device), or the like) can be used. The data generation device 3 and the inspection execution device 5 may be implemented and executed on a computer as software (computer program). The software can be recorded on a computer-readable recording medium.

  The storage unit 20 stores data used by the data generation device 3 and the inspection execution device 5. The storage unit 20 is a memory such as a ROM (Read Only Memory), a RAM (Random Access Memory), and a hard disk. The storage unit 20 stores input data input from the input / output device, a driver, a database stub, a network stub, and the like. The storage unit 20 may record data such as parameter values and variable values, and can also be used as a work area.

  As a storage unit of the data generation device 3, the storage unit 20 stores a property 21, database (DB) information 22, screen transition information 23, and screen item information 24.

  As processing means of the data generation device 3, the control unit 10 includes a data constraint generation unit 31 and a data generation unit 33.

  The data constraint generation unit 31 uses the property 21, the DB information 22, the screen transition information 23, and the screen item information 24 stored in the storage unit 20 to generate a data constraint that serves as a constraint condition for generating the test data 25. .

  The data generation unit 33 generates test data 25 that satisfies the data constraints generated by the data constraint generation unit 31.

  As a storage unit of the inspection execution device 5, the storage unit 20 stores test data 25 and an inspection target program 27.

  As processing means of the inspection execution device 5, the control unit 10 includes a driver 51 and an inspection execution unit 53.

  The driver 51 uses the test data 25 to generate an event for the inspection target program 27 that is a model.

  The inspection execution unit 53 drives the inspection target program 27 by the driver 51 to change the program state, and checks whether the property 21 is established in the changed program state.

  FIG. 1 shows a configuration example in which the model checking apparatus 1 including the data generation apparatus 3 and the inspection execution apparatus 5 is implemented as one physical apparatus, but the data generation apparatus 3 and the inspection execution apparatus 5 are Each may be configured as a separate device.

  FIG. 2 is a diagram illustrating a block configuration example of the data generation device 3.

  The data constraint generating unit 31 of the data generating device 3 includes a screen information setting unit 311, a property arranging unit 312, an input determining unit 313, a dependency property collecting unit 314, a property complementing unit 315, a dependency property organizing unit 316, and a constraint generating unit 317. Is provided.

  The screen information setting unit 311 acquires and sets the screen transition information 23 and the screen item information 24 of the inspection target program 27.

  The property placement unit 312 acquires the property 21, determines which transition specification on the screen transition each property 21 corresponds to, and places the property 21 on the corresponding screen transition.

  The input determination unit 313 sequentially selects the properties 21 arranged on the screen transition and determines whether the precondition of the selected property 21 is caused by the input item at the latest event on the screen transition.

  When it is determined that the precondition of the property 21 is not caused by the input item of the latest event, the dependency property collection unit 314 retrieves the property 21 arranged retroactively on the screen transition based on the screen transition information 23. The property sequence is collected by repeating the screen transition retroactive and property acquisition until the input determination of the acquired property 21 becomes true. A property sequence collected by going back from a certain property to a screen transition is called a dependency property, and a set of dependency properties is called a dependency property list.

  When the dependent property collection unit 314 cannot extract the property 21 for which the input determination is true, the property complementation unit 315 supplements the property that is insufficient to make the input determination true.

  The dependency property organizing unit 316 arranges the dependency property list by excluding duplicate properties and unrelated properties 21 as data transition from the dependency property list.

  The data constraint generation unit 317 generates a constraint condition (data constraint) in the generation process of the test data 25 using the precondition and postcondition of the dependency property list, and the connection condition.

  The data generation unit 33 includes a data constraint condition holding unit 331 and a data constraint solver 332.

  The data constraint condition holding unit 331 holds the data constraint generated by the data constraint generation unit 31.

  The data constraint solver 332 generates test data 25 that satisfies the data constraints held by the data constraint condition holding unit 28 using a known technique such as an SMT solver.

  Hereinafter, the process of the data generation device 3 will be described more specifically by taking as an example the process when the inspection target is a Web application program for online shopping.

  The data generation device 3 is not limited to a specific program language type, application architecture, or framework.

  FIG. 3 is a diagram illustrating an example of screen transition in the Web application to be inspected.

  In the following description, a screen means a page in which a Web page description (screen program) described in HTML or the like is displayed on a Web browser. For example, in a Web application using Java, a Web page as a screen is described in JSP (Java Server Pages), compiled into Servlet at the time of use, executed, and the processing result is transmitted to the Web browser in HTML format. As a result, a screen (Web page) is displayed.

  The example shown in FIG. 3 shows screen transitions of a login screen 41, a product selection screen 42, a product search screen 43, a confirmation screen 44, a payment screen 45, and a completion screen 46 as a part of the online shopping Web application. .

  The login screen 41 includes “ID” 411 and “password” 412 as screen items, and a “login button” 413 as operation buttons. ID 411 is an input item for customer identification information, and password 412 is an input item for a customer password. When the login screen 41 has an input for the ID 411 and the password 412 and the login button 413 is pressed, the screen transitions to the product selection screen 42.

  The product selection screen 42 includes “quantity” 421 as input items, “product search button” 422 and “confirmation button” 423 as operation buttons, and “name” 424 and “member type” 425 as display items. The quantity 421 is an input item for the number of products purchased, and the name 424 and the member type 425 are display items corresponding to the input items on the login screen 41.

  In the product selection screen 42, based on the input (ID, password) on the login screen 41, customer data stored in a customer database 221 to be described later is searched, and the corresponding customer name and member type are the name 424 and the member type. 425, respectively.

  When the product search button 422 is pressed on the product selection screen 42, the screen transitions to the product search screen 43, the quantity 421 is input, and when the confirmation button 423 is pressed, the screen transitions to the confirmation screen 44.

  The product search screen 43 includes a “product addition button” 431 as an operation button. When the product addition button 431 is pressed, the product search operation screen omitted in the screen transition example of FIG. 3 is performed, the product search operation is performed, and the product selection screen 42 to which the list of selected products is added is displayed. .

  The confirmation screen 44 is a redisplay of the display items of the product selection screen 42, has no input items, and includes only a “return button” 441 and a “payment button” 442 as operation buttons.

  When the return button 441 is pressed on the confirmation screen 44, the display transitions to the product selection screen 42. When the payment button 442 is pressed, the display transitions to the payment screen 45.

  The payment screen 45 is a customer information display item 451 including the customer name and member type, and a product information display item 451 including a list of selected products (product name, price, quantity, discount rate, discount amount, amount). In addition, a “return button” 453 and a “purchase confirmation button” 452 are provided as operation buttons.

  When the return button 453 is pressed on the payment screen 45, the screen transitions to the confirmation screen 44. When the purchase confirmation button 452 is pressed, the purchase processing is executed, the screen transitions to the completion screen 46, and the purchase is completed.

  In the Web application to be inspected, as shown in FIG. 3, the screen is changed by an event of a button press between six screens.

  FIG. 4 shows the discount rate value of the display item 451 on the payment screen 45 due to the difference in the member type value (“gold” or “normal”) on the confirmation screen 44 in the transition between the confirmation screen 44 and the payment screen 45. It is a figure which shows that there exists a different transition.

  When the display item of the confirmation screen 44, that is, the value of the member type of the display item of the product selection screen 42 is “Gold”, the event transits to the payment screen 45a. On the payment screen 45a, the value of the member type 471 among the display items of the personal information is “gold”, and the value of the discount rate 472 is “0.1” among the display items of the product information. On the other hand, when the member type is “normal”, the screen transits to the payment screen 45b. In the payment screen 45b, the value of the member type 473 is “normal” and the value of the discount rate 474 is “0”.

  FIG. 5 is a diagram illustrating an example of the database information 22.

  In the online shopping Web application, information of the customer database 221 and the product database 222 is used as the database information 22.

  FIG. 5A is a diagram illustrating a configuration example of the customer database 221. The customer database 221 stores customer data such as ID, PW, name, and type. The ID is customer identification information, the PW is a customer password, the name is the customer name, and the type is information indicating the member type.

  FIG. 5B is a diagram illustrating a configuration example of the product database 222. The product database 222 stores product data such as product names, prices, and inventory numbers. The product name is information for identifying the product, the price is the product unit price, and the number of stocks is information indicating the number of products to be stocked.

  3 and FIG. 4, the customer database 221 and the product database 222 shown in FIG. 5 are used. As an example, on the login screen 41, the customer database 221 is searched based on the input of the ID 411 and the password 412, and if there is corresponding customer data, the login is permitted, and if not, the login is rejected. Further, the product search on the product search screen 43 is performed by searching for product data stored in the product database 222. In this case, it is possible to describe the specifications such as the product data in the product database 222 being appropriately displayed on the screen by the property.

  FIG. 6 is a diagram illustrating an example of a property.

  A property 21 shown in FIG. 6 is a specification example of a property of a Web application having screen transitions shown in FIGS. Each property is associated with a property name for identifying the property in the property description at the external specification level. Here, the property at the external specification level is a specification described with respect to the value of the screen item displayed on the screen and the data stored in the database.

  In the property description example shown in FIG. 6, the part before “⇒ (logical inclusion, derivation)” is called a precondition and the part after is called a postcondition. This property description indicates that when the inspection target program 27 is in a state where the precondition is “true”, the state after the transition requests that the postcondition be “true”.

  “Symbol #” indicates a variable, and is described as “holding source #variable” when the screen or database holds variables or fields.

  Further, it is assumed that “COUNT (DB name, condition)” is a function that acquires the number of records that satisfy a condition in a table stored in a specified database.

  Also, “DB # field name.where (condition)” represents the value of the designated field of the record that satisfies the condition in the designated database.

Description of property P1 shown in FIG. 6 “(COUNT (customer DB, (customer DB # ID = login screen #ID) AND (customer DB # PW = login screen #password)) = 1) @ login button pressed ⇒ (product selection Screen # name = customer DB # name.where (customer DB # ID = login screen #ID)) AND (product selection screen #member type = customer DB # type.where (customer DB # ID = login screen #ID)) ” Is
“When the number of data stored in the customer DB satisfying the condition of ((customer DB # ID = login screen #ID) AND (pw = login screen #PW)) among the data stored in the customer DB when the login button is pressed is 1. For example, the name value of the product selection screen is equal to the value of the name field of the data satisfying (ID = login screen #ID) of the customer DB, and the member type value of the product selection screen is (ID = login) of the customer DB. It is equal to the value of the member type field of the data satisfying the screen #ID).

  FIG. 7 is a diagram illustrating an example of the screen transition information 23. In this embodiment, the screen transition information 23 is held as a screen list table 231 shown in FIG. 7A and a screen transition table 232 shown in FIG.

  The screen list table 231 is a table showing a list of screens displayed by the inspection target program 27, and an identification number and a screen name are associated with each screen.

  The screen transition table 232 is a table indicating screen transition, and stores No, transition source screen, event, transition destination screen, and the like. No is a number for identifying a transition, a transition source screen is information for identifying a screen as a transition source, an event is an operation for causing a transition, and a transition destination screen is information for identifying a screen as a transition destination.

  FIG. 8 is a diagram illustrating an example of the screen item information 24. In this embodiment, the screen item information 24 is held as a screen item table for each screen.

  The screen item table is a table showing items provided in each screen, and stores No, item name, variable name, input / output, necessity and the like. No is the item identification number, item name is the item name, variable name is the variable name of the value input / output to the item, input / output is the item type (input / output), necessity is related to data transition This is information (or “necessary” if there is a relationship).

  8A is a screen item table example of the login screen 41, FIG. 8B is a screen item table example of the product selection screen 42, FIG. 8C is a screen item table example of the confirmation screen 44, and FIG. ) Shows a screen item table example of the payment screen 45.

  Hereinafter, the processing operation of the data constraint generation unit 31 of the data generation device 3 will be described using a Web application having a screen transition shown in FIG. 3 as an example.

  FIG. 9 is a diagram illustrating a processing flow example of the data constraint generation unit 31.

  Information Acquisition Process (Step S1): The screen information setting unit 311 reads the screen transition information 23 and the screen item information 24 of the inspection target program 27 from the storage unit 20.

  Property arrangement process (step S2): The property arrangement unit 312 reads the property 21, and based on the screen transition information 23 and the screen item information 24, determines which transition on the screen transition each property 21 corresponds to. Judgment is made and the property 21 is associated with the corresponding screen transition and placed on the screen transition.

  Property input determination process (step S3): The input determination unit 313 sequentially selects the properties 21 arranged in the screen transition, and the precondition of the selected property 21 is caused by the input item at the most recent event on the screen transition. Judge whether to do. When the precondition is caused by the input item, the input determination of the property 21 is “true”.

  Property retroactive acquisition processing (step S4): If the property 21 precondition is not caused by the input item of the latest event, the dependent property collection unit 314 returns the property 21 arranged in the screen transition retroactively on the screen transition. The property acquisition is repeated until the input item determination of the acquired property 21 is true.

  Dependent Property Extraction Processing (Step S5): Based on the acquired property 21, the dependent property collection unit 314 extracts a set of properties (property string) collected until input determination is true as a dependent property.

  Property complement processing (step S6): When the dependency property collection unit 314 cannot extract the property 21 for which the input determination is true, the property complement unit 315 determines the property that is insufficient to make the input determination true. Complement.

  Dependent Property Organizing Process (Step S7): The dependent property organizing unit 316 excludes the property 21 that is irrelevant as a duplicate or data transition from the extracted dependent properties.

  Constraint Condition Generation Processing (Step S8): The data constraint generation unit 317 generates a data constraint as a constraint condition for generating the test data 25 based on the precondition and postcondition of the continuous property and the connection condition in the dependency property. To do.

  FIG. 10 is a diagram showing a more detailed processing flow example of the property arrangement processing (step S2).

  The property arrangement unit 312 reads the screen transition information 23 and the screen item information 24 held by the screen information setting unit 311 and reads the property 21 from the storage unit 20 (step S10). The property placement unit 312 sequentially selects the read properties 21, and if there is an unprocessed property 21 (Y in step S11), the property placement unit 312 divides the property 21 into a precondition and a postcondition, An event is extracted (step S12). If there is no unprocessed property 21 (N in step S11), the process proceeds to step S17.

  Furthermore, the property arrangement unit 312 extracts all rows including events that match the event extracted in the process of step S12 from the screen transition table 232 (step S13). The property placement unit 312 sequentially selects the rows extracted from the screen transition table 232, and if there is an unprocessed extracted row (Y in step S14), the process proceeds to step S15. If there is no unprocessed extracted row, (N of step S14), it returns to the process of step S11.

  In step S15, the property placement unit 312 matches the variable of the precondition or postcondition in the extracted variable or event with that of the transition source screen or posttransition screen in the row of the extracted screen transition table 232, respectively. It is determined whether to do (step S15).

  When it is determined that the variables of the transition source screen or the post-transition screen match in the extracted variables and events (Y in step S15), the property placement unit 312 associates the matched screen transition table row with the property. The result table is stored (step S16). On the other hand, when it is determined that the extracted variables and events do not match (N in step S15), the property placement unit 312 returns to the process in step S14.

  If there is no unprocessed property in step S11 (N in step S11), the property placement unit 312 holds the result table (step S17) and ends the process.

  FIG. 11 is a diagram showing information (precondition variables, events, postcondition variables) extracted from each property 21 by the property placement unit 312 as a table.

  Referring to FIG. 11, from the property P1, “login screen #ID, login screen #password, customer DB # ID, customer DB # PW” as precondition variables, “login button” as event, and “postcondition variable” It can be seen that the product selection screen #name, product selection screen #member type, login screen #ID, customer DB #ID, customer DB #name, customer DB #type are extracted.

  FIG. 12 is a diagram illustrating an example of a result table generated by the property placement unit 312.

  In the result table of the property placement unit 312, the associated property 21 is set to the content of each transition (transition source screen, event, transition destination screen).

  FIG. 13 is a diagram showing the processing result (result table) of the property arrangement unit 213 in association with the screen transition.

  On the screen transition, as an example, the placement result table No. 1 indicates that the property P1 is associated with the screen transition from the first login screen 41 to the product selection screen 42. Also, properties P5, P7, and P8 are installed for the screen transition from the confirmation screen 44 to the payment screen 45a, and properties P6, P7, and P8 are installed for the screen transition from the confirmation screen 44 to the payment screen 45b. Yes.

  FIG. 14 is a diagram showing a more detailed process flow example of the property input determination process (step S3).

  The input determining unit 313 acquires a set of properties arranged in each screen transition on the screen transition from the result table of the property arranging unit 312 (step S20). The input determination unit 313 sequentially selects the property 21 from the acquired property set (step S21), and if there is an unselected property 21 (Y in step S22), extracts the precondition screen variable (step S23). ), If there is no unselected property 21 (N in step S22), the process proceeds to step S210.

  Further, the input determination unit 313 sequentially selects the extracted screen variables (step S24). If there is a screen variable with an unselected precondition (Y in step S25), the process proceeds to the process of step S27, and an unselected screen is selected. If there is no variable (N in step S25), the input determination of the property 21 is set to "true" (step S26), and the process returns to step S21.

  In step S27, the input determination unit 313 determines whether the selected precondition screen variable is an input item on the screen where the event of the property 21 occurs. If the selected precondition screen variable is an input item on the screen where the event of the property 21 occurs (Y in step S27), the input judgment of the extracted precondition screen variable is set to “true (OK)” ( The process returns to step S28) and step S24. If the screen variable of the precondition is not an input item (N in Step S27), the input determination unit 313 sets the input determination of the property to “false (NG)” (Step S29), and returns to the process of Step S21.

  In step S210, the input determination unit 313 outputs the result and ends the process.

  FIG. 15 is a diagram illustrating an example of a processing result (result table) of the input determination unit 313.

  In the result table output by the input determination unit 313, for each property 21, a result of property input determination and an input determination result (individual input determination) for each precondition variable included in the property are set. When there is at least one “false (NG)” in the individual input determination of the screen variable, the result of the input determination of the property is determined as “false (NG)”.

  If the property does not include a precondition screen variable, “none” is recorded in the precondition screen variable, and “true (OK)” is recorded in the individual input determination.

  FIG. 16 is a diagram illustrating the processing result of the input determination unit 313 in association with the screen transition.

  In the screen transition shown in FIG. 16, the result of input determination corresponding to the contents of the result table shown in FIG. 15 is set in the property 21 arranged in each transition. For example, the input determination of the property P1 arranged at the transition from the login screen 41 to the product selection screen 42 is “true (OK)”.

  FIG. 17 is a diagram showing a more detailed process flow example of the property retroactive acquisition process (step S4) and the dependency property extraction process (step S5).

  The dependency property collection unit 314 acquires a set of properties 21 for which the input determination is “false” (NG) from the result table of the input determination unit 313 (step S30). The dependency property collection unit 314 sequentially selects properties from the acquired property set (step S31), and if there is an unselected property (Y in step S32), the input determination unit 313 determines that the individual input determination is “false (NG ) ”Is acquired and set as an unresolved variable (step S33). If there is no unprocessed property (N in step S32), the process proceeds to step S312.

  The dependency property collection unit 314 uses the result table of the input determination unit 313 to go back to the screen transition starting from the property 21 and acquire the property 21 arranged in the transition (step S34). Is determined (step S35).

  When the property 21 can be acquired by going back to the screen transition (Y in step S35), the dependency property collection unit 314 includes an unresolved variable in the acquired precondition and postcondition of the property 21, and the unresolved variable. It is determined whether the conditional expression including is an equation with an unresolved variable (step S36). If the unresolved variable satisfies the determination condition in step S36 (Y in step S36), the dependency property collection unit 314 proceeds to the process in step S38. When the property cannot be acquired retroactively from the screen transition (N in step S35), or when the unresolved variable does not satisfy the determination condition in step S36 in the property acquired retroactively (N in step S36). , The process proceeds to step S37.

  In step S37, the dependency property collection unit 314 records “Unresolved (×)” as the unresolved property 21 in the work table illustrated in FIG. 18, and returns to the process of step S31. The work table shown in FIG. 18 shows, for each property, the unresolved variable, the dependency property, the transition source variable included in the postcondition of the dependency property, and the state of resolution.

  In step S38, the dependency property collection unit 314 adds the property 21 acquired retrospectively to the screen transition to the dependency property list, and the unrelated variable and the variable related to the unresolved variable with an equal sign in the work table. Is recorded as a “transition source variable”. Further, the dependency property collection unit 314 determines whether the input determination of the property 21 acquired retroactively from the screen transition is “true (OK)” (step S39).

  If the input determination of the property 21 acquired retroactively from the screen transition is true (Y in step S39), the dependency property collection unit 314 sets “Resolve (O)” in the resolution column of the corresponding unresolved variable in the work table. Recording is performed (step S310). If the property input determination is not true (N in step S39), the dependency property collection unit 314 records “unresolved (×)” in the resolution column of the corresponding unresolved variable in the work table, and displays the transition source screen. The screen variable is added to the unresolved variable (step S310), and the process returns to step S31.

  In step S312, the dependency property collection unit 314 outputs a dependency property list as a processing result, and ends the processing.

  FIG. 19 is a diagram illustrating an example of a list of dependency properties that are output results of the dependency property collection unit.

  A list of output dependency property columns is recorded in the dependency property list, and an identification number (No) and a property 21 included in the dependency property column are recorded for each dependency property column. For example, the dependency property string of No = 1 indicates a set of properties having the property P3 and the property P1 as elements.

  FIG. 20 is a diagram illustrating the processing result of the dependency property collection unit 314 in association with the screen transition.

  In the screen transition shown in FIG. 20, the corresponding dependency property column in the dependency property list shown in FIG. 19 is set in the property 21 installed in each transition. For example, the property string {property P3, property P1} is associated with the property P3 of the transition from the product selection screen 42 to the confirmation screen 44.

  FIG. 21 is a diagram showing a more detailed processing flow example of the property organizing process (step S7).

  The dependency property organizing unit 316 acquires a dependency property list (a set of dependency property columns) (step S40). The dependency property organizing unit 316 sequentially selects a dependency property column from the dependency property list (step S41). If there is an unselected dependency property column (Y in step S42), the process proceeds to the process of step S43. If there is no dependency property string (N in step S42), the process proceeds to step S46.

  In step S43, the dependency property organizing unit 316 compares the selected dependency property column with another dependency property column in the dependency property list, and checks whether the selected dependency property column is included in the other dependency property columns. (Step S44).

  Here, the dependency property string L1 being included in the dependency property string L2 means that the following inclusion condition C1 or inclusion condition C2 is satisfied.

  Inclusion condition C1 = All element properties of the dependency property string L1 are elements of the dependency property string L2.

  Inclusion condition C2 = the dependency property column L1 and the dependency property column L2 are the same in the second and subsequent property elements, differ only in the first property element, and the precondition of the first property in the dependency property column L1 is , Included in the precondition of the first property of the dependency property column L2.

  When the selected dependency property column is included in another dependency property column (Y in step S44), the dependency property organizing unit 316 deletes the selected dependency property column from the dependency property list (step S45). When the selected dependency property column is not included in the other dependency property columns (N in step S44), the dependency property organizing unit 316 returns to the process in step S41.

  In step S46, the dependency property organizing unit 316 outputs the processing result and ends the processing.

  FIG. 22 is a diagram illustrating an example of a processing result (result table) of the dependency property organizing unit.

  In the dependency property list shown in FIG. 22, the dependency property column of No = 1 is included in the dependency property columns of No = 2 and 3 by the inclusion condition C1. Further, the dependency property string of No = 4 is included in the dependency property strings of No = 2 and 3 by the inclusion condition C2. Therefore, the dependency property sorting unit 316 deletes the dependency property strings of No = 1 and 4 from the dependency property list.

  FIG. 23 is a diagram showing a more detailed process flow example of the constraint condition generation process (step S8).

  The data constraint generation unit 317 acquires a dependency property list from the result table of the dependency property organizing unit 316 (step S50). The data constraint generation unit 317 sequentially selects the dependency property sequence from the dependency property list (step S51). If there is an unselected dependency property sequence (Y in step S52), the process proceeds to the process of step S53, and the unselected If there is no dependency property string (N in step S52), the process proceeds to step S54.

  In step S53, the data constraint generation unit 317 combines the preconditions and postconditions of the first property, the second property to the last property of the selected dependency property column with AND, and creates a result table as a data constraint. And return to the process of step S51.

  In step S54, the data constraint generation unit 317 outputs a result table.

  FIG. 24 is a diagram illustrating an example of a processing result (result table) of the data constraint generation unit.

  In the result table of the data constraint generating unit 317, for each data constraint, an identification number (No), a property element (dependent property) constituting the dependent property column, and the content of the data constraint are recorded.

For example, as a data constraint of No = 1,
“(Confirmation screen #member type =“ gold ”) AND (product selection screen #member type! =“ ”) AND (product selection screen #quantity> 0) AND (product selection screen # name = confirmation screen #name) AND ( Product selection screen #Member type = confirmation screen #Member type) AND (Product selection screen # Quantity = Confirmation screen #Quantity) AND (Product selection screen #Product name = Confirmation screen #Product name) AND (Product selection screen # Price = Confirmation) Screen #price AND (COUNT (customer DB, (customer DB # ID = login screen #ID) AND (customer DB # PW = login screen #password)) = 1) AND (product selection screen # name = customer DB # name .Where (customer DB # ID = login screen #ID)) AND (product selection screen #member type = customer DB # type.where (customer DB # ID = login screen #ID)) ”
A description of the constraint condition is generated and recorded.

  The property complementing process (step S6) is executed by the dependency property collection unit 314 only when the dependency property collection unit 314 cannot extract a property list for which input determination is true.

  25 and 26 are diagrams illustrating examples of properties for which the input determination is not true.

  In the property list shown in FIG. 25, the condition “(product selection screen #member type = confirmation screen # member type)” is not included in the post condition of the property P3 as compared with the property 21 illustrated in FIG. Such a missing condition is caused by the fact that the member type of the display item is omitted as the same in the property P3 on the product selection screen 42 that is the transition source screen and the confirmation screen 44 that is the transition destination screen. .

  Further, in the property list shown in FIG. 26, there is no property P3 itself shown in FIG. Such missing of the property 21 is caused by the fact that the display items of the product selection screen 42 that is the transition source screen and the confirmation screen 44 that is the transition destination screen are all the same.

  In both the examples of FIG. 25 and FIG. 26, since there is no “(product selection screen #member type = confirmation screen #member type)” of the post condition of the property P3 shown in FIG. 6, the dependent property list collection unit 314 , It is not possible to extract properties for which input judgment is true.

  FIG. 27 is a diagram showing a more detailed processing flow example of the property complementing process (step S6).

  The property complementation unit 315 reads the screen transition information 23, the screen item information 24, the property 21, and the result table of the property arrangement unit 312 from the storage unit 20 (step S60). The property complementation unit 315 acquires a set of screens having a transition relationship from the screen transition information 23 (step S61). If there is an unprocessed screen set (Y in step S62), the property complementing unit 315 proceeds to the process of step S63. If there is no unprocessed screen set (N in step S62), the property complementing unit 315 proceeds to the process of step S69. move on.

  In the process of step S63, the property complementing unit 315 acquires the property arranged in the transition of the screen set, and if the property can be acquired (Y in step S64), the process proceeds to the process of step S65 and the property cannot be acquired. If (N in Step S64), the process proceeds to Step S68.

  In step S65, the property complementing unit 315 checks whether there is a screen item that does not appear in the acquired property post-condition among the screen items of the transition source screen, and if there is a screen item that does not appear (Y in step S65). The screen items are collected (step S66). Furthermore, the property complementation part 315 produces | generates a property regarding the screen item which has not appeared on the transition origin screen (step S67), and returns to the process of step S61. If there is no screen item that does not appear (N in step S65), the property complementing unit 315 returns to the process in step S61.

  For example, the property generation for the screen item that has not appeared in the transition source screen is performed as follows.

・ The precondition is "TRUE".
• The event is an event that causes a transition between the screens.
• The post-condition is that a screen item that has not appeared is the same as the screen item that has the same name as the screen item that has not appeared in the transition destination screen. At this time, even if there is no screen item with the same name as a screen item name that has not yet appeared in the transition destination screen, the above condition is generated assuming that there is a screen item with that name in the transition destination screen.

  If the property cannot be acquired in the process of step S64 (N in step S64), the property complementing unit 315 sets all screen items of the transition source screen as non-existing screen items (step S68) and proceeds to the process of step S67. move on.

  In step S69, the property complementing unit 315 holds the processing result (result table).

  FIG. 28 is a diagram illustrating an example of the processing result of the property complementing unit.

  The result table shown in FIG. 28A is a property description generated as a complement to the property shown in FIG.

  Of the screen items of the product selection screen 42 that is the transition source screen, the property complementing unit 315 identifies “member type” as an item that does not appear in the post condition of the acquired property P3, and the confirmation screen 44 that is the transition destination screen. Based on the items having the same name, “(product selection screen #member type = confirmation screen #member type)” is generated. Furthermore, a property description in which the precondition is “TRUE”, the event is “confirmation button press” that causes this transition, and the postcondition is “(product selection screen #member type = confirmation screen #member type)”. Generated.

  FIG. 28B shows a property description generated as a complement to the property shown in FIG.

  By using all the screen items of the product selection screen 42 that is the transition source screen, the property complementing unit 315 uses “(product selection screen # name = confirmation screen # name) AND (product selection screen #member type = confirmation screen #membership). Type) AND (product selection screen # quantity = confirmation screen # quantity) AND (product selection screen # product name = confirmation screen # product name) AND (product selection screen # price = confirmation screen # price) "is generated. Then, a property description is generated in which the precondition is “TRUE”, the event is “confirmation button press” that causes this transition, and the postcondition is the above generated description.

  As described above, in the data generation device 3, the data constraint generation unit 31 generates a data constraint for generating the test data 25 from the property precondition, and the data generation unit 33 solves the data constraint with the SMT solver. Thus, test data for model checking can be generated.

  According to the data generation device 3, it is possible to determine data constraints for generating data such that the property precondition is true for a program to be inspected whose properties are set in a context on the execution path. As a result, the processing load for generating test data for model checking can be reduced.

  Further, according to the data generation device 3, the data constraint (constraint condition) configured based on the property having the context is specified in the data generation unit 33 using the SMT solver or the SAT solver, thereby the data constraint. Specific data satisfying the above can be generated.

DESCRIPTION OF SYMBOLS 1 Model inspection apparatus 10 Control part 20 Memory | storage part 21 Property 22 Database (DB) information 23 Screen transition information 24 Screen item information 25 Test data 27 Test object program 3 Data generation apparatus 31 Data constraint generation part 311 Screen information setting part 312 Property arrangement Unit 313 input determination unit 314 dependency property collecting unit 315 property complementing unit 316 dependency property organizing unit 317 data constraint generating unit 33 data generating unit 331 data constraint condition holding unit 332 data constraint solver 5 test execution device 51 driver 53 test execution unit

Claims (5)

In a data generation method for generating test data for program operation check,
Computer
Screen information setting process step for reading screen transition information indicating transitions between screens executed by the program to be inspected, screen item information indicating items included in each screen, and properties indicating specifications to be satisfied by the program;
A property placement processing step for determining which screen transition specification on the screen transition indicated in the screen transition information corresponds to the property, and associating the determined property with the screen transition;
For the property associated with the screen transition, it is determined whether the precondition of the property is caused by the input item at the most recent event on the screen transition of the program, and the precondition is set as the input item at the most recent event. An input determination processing step in which the determination is true, if any,
If the property precondition is not an input item at the most recent event, acquire the property by going back to the screen transition of the program, and repeat the property collection until the input item determination for the acquired property is true, A property collection processing step for extracting the acquired property group as a dependent property;
A data generation method characterized by executing a data constraint generation processing step of generating a constraint condition for data generation using the precondition and postcondition of the dependency property, and the connection condition. Said computer further comprising:
Based on the screen transition information, the screen item information, and the property, a property completion processing step for identifying and complementing a property that is insufficient to make the input determination true in the dependency property,
The data generation method according to claim 1, wherein the data generation method is executed. Said computer further comprising:
Property reorganization processing step for excluding duplicate parts included in the dependency property or properties unrelated to data transition,
The data generation method according to claim 1, wherein the data generation method is executed. A data generation process for generating test data for checking the operation of a program,
Computer
Screen information setting processing for reading screen transition information indicating transitions between screens executed by the program to be inspected, screen item information indicating items included in each screen, and properties indicating specifications to be satisfied by the program;
A property placement process for determining which screen transition specification on the screen transition indicated in the screen transition information corresponds to the property, and associating the determined property with the screen transition;
For the property associated with the screen transition, it is determined whether the precondition of the property is caused by the input item at the most recent event on the screen transition of the program, and the precondition is set as the input item at the most recent event. If it is, input judgment processing that makes the judgment true,
If the property precondition is not an input item at the most recent event, acquire the property by going back to the screen transition of the program, and repeat the property collection until the input item determination for the acquired property is true, Property collection processing that extracts the acquired property group as a dependent property;
A data generation program for executing a data constraint generation process for generating a constraint condition for data generation using the precondition and postcondition of the dependency property, and the connection condition. In a data generation device that generates test data for checking the operation of a program,
Screen transition information indicating transitions between screens executed by the program to be inspected, screen item information indicating items included in each screen, and a screen information setting unit for reading properties indicating specifications to be satisfied by the program,
A storage unit for storing the read screen transition information, screen item information, and properties;
Determining which screen transition specification on the screen transition indicated by the screen transition information corresponds to the property, and a property placement unit for associating the determined property with the screen transition;
For the property associated with the screen transition, it is determined whether the precondition of the property is caused by the input item at the most recent event on the screen transition of the program, and the precondition is set as the input item at the most recent event. An input determination unit that makes the determination true if
If the property precondition is not an input item at the most recent event, acquire the property by going back to the screen transition of the program, and repeat the property collection until the input item determination for the acquired property is true, A property collection unit that extracts the acquired property group as a dependent property;
A data generation apparatus comprising: a data constraint generation unit configured to generate a constraint condition for data generation using the precondition and postcondition of the dependency property and the connection condition.

Images