Information processor, information processing method, and program

Abstract

To provide an information processor, an information processing method, and a program that can reduce the number of steps required for creating test specifications.SOLUTION: An information processor according to the embodiment includes a design information reading unit, a test viewpoint data reading unit, a design information trace management unit, and a test specification generation unit. The design information reading unit reads a plurality of design documents to be tested and decomposes design information included in each of the plurality of design documents into models. The test viewpoint data reading unit reads the test viewpoint data. The design information trace management unit defines, on the basis of a result of decomposing the design information included in each of the plurality of design documents into the models, the correspondence between the models. The test specification generation unit generates, on the basis of the test viewpoint data, the result of decomposing the design information included in each of the plurality of design documents into the models, and the result of defining the correspondence between the models, test items for the plurality of design documents and generates test specifications based on the generated test items.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing device, an information processing method, and a program. [Background technology]

[0002] When developing systems and software, it is necessary to create separate documents as outputs of the work. These documents include, for example, design drawings and program specifications, and are created using tools such as CASE (Computer Aided Software Engineering).

[0003] In addition, the development of systems and software requires consideration of the life cycle of analysis, design, development, and testing. The input information for these life cycles is determined based on customer requirements. Throughout the life cycle, these customer requirements are embodied in requirements specifications, functional specifications, design specifications, test scenarios, components, test results, products, etc. Similarly, through the life cycle, they are documented in documents such as requirements specifications, functional specifications, software / system design documents, test specifications, test results reports, detailed design documents, test completion reports, and shipping reports.

[0004] Test specification creation is done manually, which is very costly. For example, the identification of test items depends on the experience of the test designer. Therefore, even for experienced engineers, it is difficult to identify test items without missing anything.

[0005] There is a known technology that defines, registers, updates, etc., system and software specifications, and accurately creates formal documents based on these specifications (see, for example, Patent Document 1). With this technology, deliverables that define the system and software specifications are classified into a metamodel, which is then defined and managed. This technology also defines class names, parent class names, and class constraints. This technology also verifies whether or not the design information satisfies the constraints. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2013-254503 A Summary of the Invention [Problem to be solved by the invention]

[0007] An object of the present invention is to provide an information processing device, an information processing method, and a program that can reduce the number of steps required to create a test specification. [Means for solving the problem]

[0008] An information processing apparatus according to an embodiment includes a design information reading unit, a test viewpoint data reading unit, a design information trace management unit, and a test specification generation unit. The design information reading unit reads a plurality of design documents to be tested, and decomposes the design information included in each of the plurality of design documents into models. The test viewpoint data reading unit reads test viewpoint data. The design information trace management unit defines a correspondence relationship between models based on a result of decomposing the design information included in each of the plurality of design documents into models by the design information reading unit. The test specification generation unit generates test items for the plurality of design documents based on the test viewpoint data read by the test viewpoint data reading unit, a result of decomposing the design information included in each of the plurality of design documents into models by the design information reading unit, and a result of defining the correspondence relationship between models by the design information trace management unit, and generates a test specification based on the generated test items. [Brief description of the drawings]

[0009] [Figure 1] A diagram showing an example of a model data format [Diagram 2] FIG. 1 is a diagram showing an example of an information processing apparatus according to an embodiment of the present invention; [Figure 3A]FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 3B] FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 3C] FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 4] A diagram showing an example of a test viewpoint list [Figure 5A] FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 5B] FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 6] FIG. 1 is a diagram showing an example of a process executed by the information processing apparatus of the present embodiment; [Figure 7] 1 is a flowchart showing an example of an operation of the information processing apparatus according to the present embodiment. [Figure 8] 1 is a flowchart showing an example of an operation of the information processing apparatus according to the present embodiment. [Figure 9] 1 is a flowchart showing an example of an operation of the information processing apparatus according to the present embodiment. [Figure 10] FIG. 13 is a diagram illustrating an example of an information processing device according to a modified example of an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an information processing apparatus, an information processing method, and a program according to the embodiments will be described with reference to the drawings. In the following description, components having the same or similar functions are denoted by the same reference numerals. In addition, duplicate descriptions of those components may be omitted.

[0011] (Embodiment) <Model data format> Figure 1 is a diagram showing an example of a model data format. The model data format is the basic information of the design model, documents, and the relationship information between them, which is used as a basis when an administrator defines design meta-information.

[0012] (Design Meta Information) The data format of the model has, as base classes, "model class," "inter-model relationship class," "document class," and "inter-model document relationship class," which are the data formats of the model, as design meta-information. Note that a class refers to a data type defined in the field of object-oriented technology.

[0013] Figure 1 is a class diagram written in accordance with the object-oriented technical notation UML (Unified Modeling Language), where the rectangles represent classes and the lines between the rectangles represent the relationships between the classes. The inside of a class is expressed in three parts, with the class name described in the top row, attributes in the middle row, and operations described in the bottom row. All operations 1c, 2c, 3c, and 4c are shown in italics.

[0014] Operations 1c to 4c indicate abstract operations, and when the administrator defines a class that inherits this class, the substance of the operation is redefined according to the characteristics of this class.

[0015] Model class 1 is the type of the smallest unit of specifications created throughout the development lifecycle. The data of a model class is of this type. Furthermore, model class 1 is the parent class of all model classes, and the administrator defines model classes for each specific model as child classes of this class.

[0016] The model class 1 has a class name 1a of "model", and attributes 1b of "model name", "model ID", "version", "modifiability flag", "change history", and other attributes such as "identifier". Operations 1c include a "class constraint verification ( )" operation, an "instance constraint verification ( )" operation, and a "specific instance constraint verification ( )" operation. The constraints for these operations will be described later.

[0017] In attribute 1b, "From" contains the source class name, "To" contains the destination class name, "Version" contains version information, "Modifference flag" contains either a flag indicating that modification may be required ("ON") or a flag indicating that modification is not required ("OFF"), and "Change history" contains historical information about changes that have already been made.

[0018] When defining a new class by inheriting model class 1, the "verify class constraints ( )" operation and the "verify instance constraints ( )" operation of operation 1c are defined by the administrator. The "verify specific instance constraints ( )" operation is defined by the user when defining an instance of the newly defined class.

[0019] There may be a parent-child relationship between multiple model classes 1. In this case, the parent-child relationship refers to a whole-part relationship in which the child class corresponds to the parent element.

[0020] Inter-model relationship class 2 is the type of relationship between any two models defined as models. The data of the inter-model relationship class is data of this type. There are various types of specifications created throughout the development lifecycle, and there are also various types of relationships such as input relationships, reference relationships, and relationships between designs and corresponding verification specifications, so these relationships are defined in inter-model relationship class 2.

[0021] The inter-model relationship class 2 is a parent class of all inter-model relationship classes, and the administrator defines an inter-model relationship class for each specific inter-model relationship included in the document as a child class of this class.

[0022] The inter-model relationship class 2 has "inter-model relationship" as its class name 2a, and as its attributes 2b, "From", "To", "Version", "Modifference flag", "Change history" as well as other attributes such as "Description", "Source model list", and "Destination model list", which are the same as those of attribute 1b of model class 1. As operations 2c, it has an operation similar to operation 3c of model class 1, and also an operation for "verifying relationships based on constraints" as necessary.

[0023] Document class 3 is the type of the smallest unit of a document created through the life cycle of development. The data of a document class is of this type. Furthermore, document class 3 is the parent class of all document classes, and the administrator defines a document class for each specific document as a child class of that class. The document class 3 has a class name 3a of "document", and attributes 3b of "document name", "document ID", "version", "modifiability flag", "change history", and other attributes such as "identifier", "description", and "subdocument list", which are the same as the attributes 1b of the model class 1. As operations 3c, the same operations as those of the model class 1 are provided.

[0024] There may be a parent-child relationship between multiple document classes 3. In this case, the parent-child relationship refers to a whole-part relationship in which a child class corresponds to a parent element.

[0025] Model-document relationship class 4 is the type of relationship between any model and document defined as "model" and "document". The data of the model-document relationship class is data of this type. The documents created throughout the development lifecycle are specification information that is also created throughout the development lifecycle, and are created as text based on "model" information. At this time, there are various relationships between "models" and "documents", such as requirements and requirement specifications, design specifications and design specifications, test scenarios and test specifications, etc., and such relationship types are defined in model-document relationship class 4.

[0026] Moreover, the inter-model document relationship class 4 is a parent class of all inter-model document relationship classes, and the administrator defines an inter-model document relationship class for each specific inter-model document relationship included in the document as a child class of this class.

[0027] The model document relationship class 4 has a class name 4a of "model document relationship", and attributes 4b of "From", "To", "Version", "Modifference flag", and "Change history" similar to attributes 1b of model class 1, as well as other attributes such as "Explanatory relationship source model list" and "Related document list". Operation 4c is the same as operation 1c of model class 1, and includes an operation of "Verifying relationship based on constraints" as necessary.

[0028] (Design information) Design information is the actual data created by each of the four classes mentioned above, and includes "model instance," "inter-model relationship instance," "document instance," and "model-document relationship instance." Although not shown, these instances are also expressed in the same way as the classes in Figure 1, with the instance name described in the top row, attributes in the middle row, and operations in the bottom row. The operations indicate abstract operations. The actual operations are defined according to the characteristics of the parent class when the user defines an instance that inherits the parent class mentioned above.

[0029] A model instance is the smallest entity of a specification created throughout the development lifecycle. The data of a model instance is the data of this entity. The attributes of a model instance include the parent model class identifier, the instance identifier and name (description), and the child model instance identifier. Model instance operations include operations for verifying specifications based on constraints, as necessary.

[0030] An inter-model association instance is association information between any two model instances defined as model instances, and is an entity of the association type defined as an inter-model association class. The data of an inter-model association instance is the data of this entity. Attributes of an inter-model association instance include a parent inter-model association identifier, a source model instance identifier, and a destination model instance identifier. Operations of an inter-model association instance include operations to verify the association based on constraints, as necessary.

[0031] A document instance is the smallest entity of a document created throughout the development lifecycle. The data of a document instance is the data of this entity. The attributes of a document instance include the identifier of the parent document class, the identifier and name (description) of the document instance, and the identifier of the child document instance. Operations on document instances include operations for document validation based on constraints, as necessary.

[0032] A model document relationship instance is relationship information between any model instance and document instance defined as a model instance and a document instance, and is an entity of the relationship type defined as a model document relationship class. The data of a model document relationship instance is the data of this entity. Attributes of a model document relationship instance include a parent model document relationship identifier, a source model instance identifier, and a destination document instance identifier. Operations of a model document relationship instance include operations to verify the relationship using constraints, as necessary.

[0033] (constraint conditions) As mentioned above, the design meta information comprises the “class constraint verification ( )” operation, the “instance constraint verification ( )” operation, and the “specific instance constraint verification ( )” operation of operations 1c, 2c, 3c, and 4c in FIG. 1, and the four instances, which are the design information, also comprise their respective operations. Below, we will explain the constraints for defining these classes and instances.

[0034] Constraints are rules that are set as necessary for each of the "models," "relationships between models," "documents," and "relationships between models and documents."Specific constraints include, for example, for a model called "test," rules that "input and output must be defined" for each test model, and for a set of test models, "there must be no test models that are not related to the function model."

[0035] Constraints include constraints on classes, constraints that apply broadly to instances belonging to a class, and constraints that apply only to a specific instance. Class constraints and instance constraints are defined by the administrator as the "Class Constraint Verification ( )" operation and the "Instance Constraint Verification ( )" operation in the model class 1, the inter-model association class 2, the document class 3, and the model-document association class 4, as necessary. Also, specific instance constraints are defined by the user as the "Specific Instance Constraint Verification ( )" operation in the instances of each class, as necessary.

[0036] <Information processing device> 2 is a diagram showing an example of an information processing device of the present embodiment. The information processing device 10 of the present embodiment is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. The information processing device 10 creates a test specification for a design document. The information processing device 10 includes a design information reading unit 11, a test viewpoint data reading unit 12, a design information storage unit 13, a design information trace management unit 14, a trace storage unit 15, and a test specification generation unit 16.

[0037] The design information reading unit 11 reads a design document created based on a design document template. An example of a design document is a design document to be tested. The design information reading unit 11 breaks down the design information included in the read design document into models. The design information reading unit 11 stores the results of breaking down the information included in the design document into models together with the design information in the design information storage unit 13.

[0038] Fig. 3A is a diagram showing an example of processing executed by the information processing device of this embodiment. Fig. 3A shows, as an example, a class diagram obtained by design information reading unit 11 reading a screen list created based on a screen design document template and decomposing the read screen list into models. The inside of a class is expressed in a plurality of parts, and according to Fig. 3A, the specification class, screen ID, screen name, and description are defined as items within the class, and the specification class, screen ID, screen name, and description are described, respectively.

[0039] The specification class is the data type of the specification in the screen list table, for example, "Screen". The screen ID is identification information of the screen, for example, "IMG01", "IMG02", "IMG03", etc. The screen name is the name of the screen, for example, "Screen 01", "Screen 02", "Screen 03", etc. The description is a description of the specification in the screen list table, for example, the contents of the specification.

[0040] By breaking down the screen list into models, the design information reading unit 11 includes in the class diagram "Screen" as the specification class, "IMG01" as the screen ID, "Screen 01" as the screen name, and "..." as the description. Also, by breaking down the screen list into models, the design information reading unit 11 includes in the class diagram "Screen" as the specification class, "IMG02" as the screen ID, "Screen 02" as the screen name, and "..." as the description.

[0041] Furthermore, by breaking down the screen list into models, design information reading unit 11 includes in the class diagram "Screen" as the specification class, "IMG03" as the screen ID, "Screen03" as the screen name, and "..." as the description. Design information reading unit 11 stores in design information storage unit 13 the class diagram obtained by breaking down the screen list into models.

[0042] Fig. 3B is a diagram showing an example of processing executed by the information processing device of this embodiment. Fig. 3B shows, as an example, a class diagram obtained by the design information reading unit 11 reading a screen item specification created based on a design document template of a screen item and decomposing the read screen item specification into models. The inside of a class is expressed by dividing it into a plurality of parts, and according to Fig. 3B, the specification class, screen item ID, screen item name, element type, and label are defined as items within the class, and the specification class, screen item ID, screen item name, element type, and label are described, respectively.

[0043] The specification class is the data type of the specification in the screen item specification, for example, "screen item". The screen item ID is identification information of the screen item, for example, "IMG01.01", "IMG01.02", "IMG01.03", etc. The screen item name is the name of the screen item, for example, "title", "XX label", "XX button", etc. The element type is the type (kind) of the screen item, for example, "title", "label", "button", etc. The label is a description of the specification in the screen item specification, for example, the contents of the specification.

[0044] By breaking down the screen item specifications into models, the design information reading unit 11 includes in the class diagram "screen item" as the specification class, "IMG01.01" as the screen item ID, "title" as the screen item name, "title" as the element type, and "..." as the label. Also, by breaking down the screen list into models, the design information reading unit 11 includes in the class diagram "screen item" as the specification class, "IMG01.02" as the screen item ID, "xx label" as the screen item name, "label" as the element type, and "..." as the label.

[0045] Furthermore, by breaking down the screen list into models, the design information reading unit 11 includes in the class diagram "screen item" as the specification class, "IMG01.03" as the screen item ID, "XX button" as the screen item name, "button" as the element type, and "..." as the label. The design information reading unit 11 stores in the design information storage unit 13 the class diagram obtained by breaking down the screen item specifications into models.

[0046] Fig. 3C is a diagram showing an example of processing executed by the information processing device of this embodiment. Fig. 3C shows, as an example, a class diagram obtained by the design information reading unit 11 reading a screen item processing specification created based on a design document template of the screen item processing and decomposing the read screen item processing specification into models. The inside of a class is expressed as multiple parts, and according to Figure 3C, the items defined within the class are specification class, action ID, action name, event, corresponding item name, action details, and processing description, and the specification class, action ID, action name, event, corresponding item name, action details, and processing description are described respectively.

[0047] The specification class is the type of specification data in the screen item processing specification, for example, "action". The action ID is identification information of the action, for example, "ACT01.01", "ACT01.02", "ACT01.03", etc. are described. The action name is the name of the action, for example, "initial display", "normal end when XX button is clicked", "abnormal end when XX button is clicked", etc. are described. The event is the condition for the screen action to occur, for example, "click XX button", etc. are described. The corresponding item name is the screen item corresponding to the screen action, for example, "XX button", etc. are described. The action details are a description of the action, for example, the contents of the action. The processing description is a description of the processing, for example, the contents of the processing.

[0048] By breaking down the screen item processing specification into models, the design information reading unit 11 includes in the class diagram "action" as the specification class, "ACT01.01" as the action ID, "initial display" as the action name, "···" as the event, "···" as the corresponding item name, "···" as the action details, and "···" as the processing explanation. By breaking down the screen item processing specification into a model, the design information reading unit 11 includes in the class diagram “action” as the specification class, “ACT01.02” as the action ID, “normal end when XX button is clicked” as the action name, “···” as the event, “···” as the corresponding item name, “···” as the action details, and “···” as the processing explanation.

[0049] By breaking down the screen item processing specifications into models, the design information reading unit 11 includes in the class diagram "action" as a specification class, "ACT01.03" as an action ID, "abnormal termination when XX button is clicked" as an action name, "..." as an event, "..." as a corresponding item name, "..." as action details, and "..." as a processing explanation. The design information reading unit 11 stores the class diagram obtained by breaking down the screen item processing specifications into models in the design information storage unit 13. Let's return to Fig. 2 and continue the explanation.

[0050] The test viewpoint data reading unit 12 reads a test viewpoint list created based on a test viewpoint definition template. An example of a test viewpoint list is a list of test viewpoints. The test viewpoint data reading unit 12 stores the read test viewpoint list in the design information storage unit 13.

[0051] Fig. 4 is a diagram showing an example of a test viewpoint list. Fig. 4 shows, as an example, a test viewpoint list read by the test viewpoint data reading unit 12. The test viewpoint list includes a plurality of items, and according to Fig. 4, the following items are defined: test viewpoint ID, test viewpoint_large, test viewpoint_medium, test viewpoint_small, test classification, test process, specification class, attribute name, attribute value, description, operation, and confirmation, and test viewpoint ID, test viewpoint_large, test viewpoint_medium, test viewpoint_small, test classification, test process, specification class, attribute name, attribute value, description, operation, and confirmation are described, respectively.

[0052] The test perspective ID is identification information for the test perspective, and for example, "KANTEN01", "KANTEN02", "KANTEN03", etc. are described. The test perspective_large is a major test item, and for example, "screen system" is described. The test perspective_medium is a medium test item, and for example, "screen specification", "screen item specification", "screen item processing specification", etc. are described. The test perspective_small is a minor test item, and for example, "screen name", "label", "action", etc. are described. The test classification is the classification of the test, and for example, "screen". The test process is the type of test, and for example, "unit test" is described.

[0053] The specification class, attribute name, and attribute value are definitions used to determine the content of the test to be generated. It is assumed that the specification class, attribute name, and attribute value are linked to the specification class to be tested by ID. If only the specification class is defined, a test is made to see if specification data of the specification class that satisfies the prerequisites exists. If the specification class and attribute name are defined, a test is made to see if any data is defined for the attribute name of the specification data of the specification class that satisfies the prerequisites. If the specification class, attribute name, and attribute value are defined, a test is made to see if attribute value data is defined for the attribute name of the specification data of the specification class that satisfies the prerequisites.

[0054] The specification class is the data type of the specification in the test viewpoint list, and for example, screen, screen item, action, etc. are described. The attribute name is the name of the attribute of the test viewpoint, and for example, screen name, label, event, etc. are described. The attribute value is a fixed value defined for the design information to be tested, and for example, in the case of a screen item, the specification class is "screen item", the attribute name is "type", and the attribute value is "pull-down menu", etc. are described.

[0055] The description is an explanation of the test viewpoint, and examples of the description include "check the screen name," "check the screen item label," and "check the screen item action." The operation is a test method, and examples of the description include "display "[spec:screen name]" in the initial state," "display "[spec:screen name]" in the initial state and display the screen item "[spec:screen item name]" on the screen," and "display "[spec:screen name]" in the initial state and perform "[spec:event]" on the screen item "[spec:screen item name]" to perform the following processing. [spec:processing description]." Here, the [spec:XXX] tag is tag information for dynamically embedding a value of design information.

[0056] Confirmation is a method for checking the results of a test. For example, it might describe, "Confirm that "[spec:screen name]" is displayed as the screen name," "Confirm that the label is "[spec:label]," "Confirm that the following action is performed. [spec:action details]," etc.

[0057] Based on the loaded test perspective list, the test perspective data reading unit 12 associates the following in the design information storage unit 13: test perspective ID "KANTEN01", test perspective_large "screen system", test perspective_medium "screen specification", test perspective_small "screen name", test classification "screen", test process "unit test", specification class "screen", attribute name "screen name", attribute value "-", explanation "confirm screen name", operation "display "[spec:screen name]" in the initial state", and confirmation "confirm that "[spec:screen name]" is displayed as the screen name".

[0058] In addition, based on the loaded test perspective list, the test perspective data reading unit 12 associates the following with the test perspective ID "KANTEN02", the test perspective_large "screen system", the test perspective_medium "screen item specification", the test perspective_small "label", the test classification "screen", the test process "unit test", the specification class "screen item", the attribute name "label", the attribute value "-", the explanation "confirm screen item label", the operation "display "[spec:screen name]" in the initial state and display the screen item "[spec:screen item name]" on the screen", and the confirmation "confirm that the label is "[spec:label]"", and stores them in the design information storage unit 13.

[0059] Further, based on the read test viewpoint list, the test viewpoint data reading unit 12 displays "KANTEN03" as the test viewpoint ID, "screen system" as the test viewpoint_large, "screen item processing specification" as the test viewpoint_medium, "action" as the test viewpoint_small, "screen" as the test classification, "unit test" as the test process, "action" as the specification class, "event" as the attribute name, "-" as the attribute value, "screen item action confirmation" as the explanation, and ""[spec:screen name]" as the operation in the initial state, and performs "[spec:event]" on the screen item "[spec:screen item name]", and performs the following processing. [spec:processing explanation], and "Confirm that the following action is performed. [spec:action details]" as the confirmation, and stores them in the design information storage unit 13. Returning to FIG. 2, the explanation will be continued.

[0060] The design information storage unit 13 is realized by a hard disk drive (HDD), a flash memory, a random access memory (RAM), a read only memory (ROM), etc. The design information storage unit 13 stores design information and test viewpoint data. The design information is the actual data of a design document, and includes the results of breaking down the information of the design document into models. The test viewpoint data is the actual data of the test viewpoint data.

[0061] The design information trace management unit 14 defines the relationship between the models based on the correspondence between the models. Specifically, the design information trace management unit 14 acquires a plurality of results of decomposing each of the pieces of information in the plurality of design documents into models from the design information storage unit 13, and defines the relationship based on the correspondence between the plurality of results of decomposing each of the pieces of information in the plurality of design documents acquired into models. The design information trace management unit 14 stores the result of defining the relationship between the models in the trace storage unit 15 as trace information.

[0062] Specifically, the design information trace management unit 14 acquires a class diagram obtained by decomposing the screen list stored in the design information storage unit 13 into models, a class diagram obtained by decomposing the screen item specifications into models, and a class diagram obtained by decomposing the screen item processing specifications into models. The design information trace management unit 14 defines the associations based on the correspondences between the items in the class diagram obtained by decomposing the acquired screen list into models and the class diagram obtained by decomposing the screen item specifications into models.

[0063] 5A is a diagram showing an example of processing executed by the information processing device of this embodiment. The design information trace management unit 14 detects a correspondence between items based on a class diagram obtained by decomposing a screen list into models and a class diagram obtained by decomposing a screen item specification into models. For example, the design information trace management unit 14 determines whether or not an item included in a class diagram obtained by decomposing a screen list into models is included in an item included in a class diagram obtained by decomposing a screen item specification into models. Also, for example, the design information trace management unit 14 determines whether or not an item included in a class diagram obtained by decomposing a screen list into models includes an item included in a class diagram obtained by decomposing a screen item specification into models.

[0064] For example, the design information trace management unit 14 determines that the screen item IDs "IMG01.01", "IMG01.02", and "IMG01.03" included in the class diagram obtained by decomposing the screen item specification into a model are included in the screen ID "IMG01" included in the class diagram obtained by decomposing the screen list into a model. In this case, the design information trace management unit 14 further defines a screen ID in relation to the specification class, screen item ID, screen item name, element type and label as items in the class diagram obtained by decomposing the screen item specification into models, and writes "IMG01" as the defined screen ID.

[0065] For example, the design information trace management unit 14 writes "IMG01" as a screen ID in association with "screen item" as a specification class, "IMG01.01" as a screen item ID, "title" as a screen item name, "title" as an element type, and "..." as a label. For example, the design information trace management unit 14 writes "IMG01" as a screen ID in association with "screen item" as a specification class, "IMG01.02" as a screen item ID, "xx label" as a screen item name, "label" as an element type, and "..." as a label.

[0066] For example, the design information trace management unit 14 writes "IMG01" as a screen ID in association with "screen item" as a specification class, "IMG01.03" as a screen item ID, "XX button" as a screen item name, "button" as an element type, and "..." as a label. The design information trace management unit 14 stores "IMG01" as the screen ID in the trace storage unit 15 as trace information.

[0067] 5B is a diagram showing an example of processing executed by the information processing device of this embodiment. The design information trace management unit 14 detects the correspondence between items based on a class diagram obtained by decomposing the screen item specifications into models and a class diagram obtained by decomposing the screen item process specifications into models. For example, the design information trace management unit 14 determines whether or not an item included in a class diagram obtained by decomposing a screen item processing specification into models includes an item included in a class diagram obtained by decomposing a screen item specification into models. Also, for example, the design information trace management unit 14 determines whether or not an item included in a class diagram obtained by decomposing a screen item specification into models includes an item included in a class diagram obtained by decomposing a screen item processing specification into models.

[0068] For example, the design information trace management unit 14 determines that the action IDs "ACT01.01", "ACT01.02", and "ACT01.03" included in the class diagram obtained by decomposing the screen item processing specification into a model are included in the screen ID "IMG01" included in the class diagram obtained by decomposing the screen item specification into a model. In this case, the design information trace management unit 14 decomposes the screen item processing specification into a model, and in addition to the items such as specification class, action ID, action name, event, corresponding item name, action details and processing description, defines a screen ID and writes "IMG01" as the defined screen ID.

[0069] For example, the design information trace management unit 14 writes "IMG01" as a screen ID in association with "action" as a specification class, "ACT01.01" as an action ID, "initial display" as an action name, "···" as an event, "···" as a corresponding item name, "···" as action details, and "···" as a processing description.

[0070] For example, the design information trace management unit 14 writes "IMG01" as the screen ID in association with "action" as the specification class, "ACT01.02" as the action ID, "normal completion when XX button is clicked" as the action name, "···" as the event, "···" as the corresponding item name, "···" as the action details, and "···" as the processing description.

[0071] For example, the design information trace management unit 14 writes "IMG01" as a screen ID in association with "action" as a specification class, "AT01.03" as an action ID, "abnormal termination when XX button is clicked" as an action name, "..." as an event, "..." as a corresponding item name, "..." as action details, and "..." as a processing explanation. The design information trace management unit 14 stores "IMG01" written as the screen ID as trace information in the trace storage unit 15. Returning to FIG. 2, the explanation will be continued.

[0072] The trace storage unit 15 is realized by a HDD, a flash memory, a RAM, a ROM, etc. The trace storage unit 15 stores trace information.

[0073] The test specification generation unit 16 acquires design information and test viewpoint data from the design information storage unit 13, and acquires trace information from the trace storage unit 15. The test specification generation unit 16 generates a test specification based on the acquired design information, test viewpoint data, and trace information. For example, the test specification generation unit 16 creates a test specification based on a test specification template.

[0074] Fig. 6 is a diagram showing an example of a process executed by the information processing device of this embodiment. Fig. 6 shows, as an example, a process in which the test specification generating unit 16 generates a test specification based on design information, test viewpoint data, and trace information. The test specification includes a plurality of test items, and according to Fig. 6, a test item ID, a test item name, a test process, a test target ID, a test target name, a type, a category, an operation, and a confirmation are defined as the test items, and the test item ID, the test item name, the test process, the test target ID, the test target name, a type, a category, an operation, and a confirmation are described, respectively.

[0075] The test item ID is identification information of the test item, for example, "KANTEN01", "KANTEN02", "KANTEN03", etc. The test item name is the name of the test item, for example, "Confirm screen name", "Confirm screen item label", "Confirm screen item action", etc. The test process is the type of test, for example, "unit test", etc. The test subject ID is identification information of the test subject, for example, "IMG01", etc. The test subject name is the name of the test subject, for example, "screen 01", etc. The type is the type of test, for example, "function", etc. The category is defined as the test category of the test perspective, for example, "normal system", "quasi-normal system", "abnormal system", etc.

[0076] An operation is a method of testing, for example, "Display 'Screen 01' in its initial state," "Display 'Screen 01' in its initial state and display the screen item 'XX label' on the screen," "Display 'Screen 01' in its initial state and perform a 'button click' on the screen item 'XX button' and perform the following process," etc. are described. Here, "Screen 01", "XX label", "XX button" and "Button click" are values ​​that correspond to the [spec:XXX] tag obtained from the design information by the test specification generation unit 16 and are output.

[0077] Confirmation is a method for checking the results of a test, for example, "Confirm that "Screen 01" is displayed as the screen name," "Confirm that the label is "XX Label," "Confirm that the following action is performed. Transition to "Screen 02," etc. Here, "Screen 01", "XX Label" and "Screen 02" are values ​​corresponding to the [spec:XXX] tag that are obtained by the test specification generation unit 16 using trace information from the design information, and the obtained values ​​are output.

[0078] Based on the design information, the test viewpoint data, and the trace information, the test specification generator 16 acquires the operation included in the test viewpoint data, outputs the acquired operation as the operation of the test item, acquires the confirmation included in the test viewpoint data, and outputs the acquired confirmation as the confirmation of the test item. Furthermore, the test specification generator 16 acquires a value corresponding to the [spec:XX] tag from the design information, and outputs the acquired value in place of the [spec:XX] tag. Here, the test specification generator 16 may obtain a value corresponding to the [spec:XX] tag from the design information by using the trace information, and output the obtained value instead of the [spec:XX] tag.

[0079] Specifically, based on the design information, test viewpoint data, and trace information, the test specification generation unit 16 generates a test item ID of "KANTEN01," a test item name of "Confirm screen name," a test process of "unit test," a test target ID of "IMG01," a test target name of "Screen 01," a type of "function," a classification of "normal system," an operation of "display "Screen 01" in the initial state," and a confirmation of "confirm that "Screen 01" is displayed as the screen name."

[0080] Specifically, based on the design information, test viewpoint data, and trace information, the test specification generation unit 16 generates a test item ID of "KANTEN02," a test item name of "Confirm screen item label," a test process of "unit test," a test target ID of "IMG01," a test target name of "Screen 01," a type of "function," a classification of "normal system," an operation of "Display 'Screen 01' in its initial state and display the screen item 'XX label' on the screen," and a confirmation of "Confirm that the label is 'XX label'."

[0081] Specifically, based on the design information, test viewpoint data, and trace information, the test specification generating unit 16 generates a test item ID of "KANTEN03", a test item name of "check screen item action", a test process of "unit test", a test target ID of "IMG01", a test target name of "screen 01", a type of "function", a classification of "normal system", an operation of "display 'screen 01' in the initial state, click the button on the screen item 'xx button', and perform the following process", and a confirmation of "confirm that the following action will be performed. Transition to screen 02". The test specification generating unit 16 outputs the generated test specification.

[0082] (Operation of information processing device) 7 to 9 are flowcharts showing an example of the operation of the information processing device 10 of the present embodiment. The process of generating a test specification by the information processing device 10 will be mainly described with reference to FIGS.

[0083] The test specification generating unit 16 acquires a value (child class) defined in the specification class attribute of the test viewpoint information from the specification class (parent class) to be tested (step S1-1). Steps S2-1 to S31-1 are performed for each child class. The test specification generator 16 checks the relevance between the design information of the specification class (parent class) of the test classification and the design information of the specification class (child class) of the attribute of the specification class of the test viewpoint based on the trace information (step S2-1). At this time, the test specification generator 16 checks the relevance both from the design information of the parent class to the design information of the child class, and from the design information of the child class to the design information of the parent class.

[0084] In step S2-1, the test specification generating unit 16 determines whether there is a relationship between the design information of the test classification specification class (parent class) and the design information of the attribute specification class (child class) of the test viewpoint specification class (step S3-1). If the test specification generator 16 determines that there is no association, the process returns to step S2-1. If the test specification generator 16 determines that there is an association, the test specification generator 16 stores the design information of the child class in a Map in which the specification class is the key and the design information array is the value (step S4-1).

[0085] The test specification generating unit 16 acquires test viewpoint data (step S5-1). For example, the test specification generating unit 16 acquires test viewpoint data whose specification class attribute corresponds to the design information of a child class. Steps S6-1 to S31-1 are performed for each test viewpoint data. The test specification generator 16 determines whether a specification class is defined (step S6-1). If a specification class is not defined (step S6-1: NO), the test specification generator 16 does not generate a test item (step S7-1).

[0086] When the specification class is defined (step S6-1: YES), the test specification generator 16 judges whether the attribute name is defined (step S8-1). When the attribute name is not defined (step S8-1: NO), the test specification generator 16 generates a test item object (step S9-1). If the attribute name is defined (step S8-1: YES), the test specification generating unit 16 determines whether the attribute value is defined (step S10-1). If an attribute value is defined (step S10-1: YES), the test specification generating unit 16 determines whether the value of the attribute name in the design information of the child class matches the attribute name (step S11-1).

[0087] If the value of the attribute name in the design information of the child class matches the attribute name (step S11-1: YES), the test specification generating unit 16 generates a test item object (step S12-1). If the attribute value is not defined (step S10-1: NO), the test specification generating unit 16 determines whether a value is defined for the attribute name in the design information of the child class (step S13-1).

[0088] If a value is not defined for the attribute name of the design information of the child class (step S13-1: NO), the test specification generator 16 does not generate a test item (step S14-1). If a value is defined for the attribute name of the design information of the child class (step S13-1: YES), the test specification generator 16 generates a test item object (step S15-1).

[0089] If the value of the attribute name in the design information of the child class does not match the attribute name (step S11-1: NO), the test specification generator 16 does not generate a test item (step S16-1). After generating the test item object in steps S9-1, S12-1, and S15-1, the test specification generator 16 determines whether an operation is defined (step S13-1).

[0090] If an operation is defined (step S13-1: YES), the test specification generation unit 16 determines whether there is a [spec:XX] tag (step S14-1). If there is no [spec:XX] tag (step S14-1: NO), the test specification generation unit 16 adds the value of the operation to the test item object (step S15-1). Steps S16-1 to S30-1 are performed as many times as there are design information items of child classes to be test items. Steps S16-1 to S22-1 are performed as many times as there are [spec:XX] tags.

[0091] The test specification generating unit 16 judges whether an attribute value is defined in the test viewpoint data (step S16-1). If an attribute value is defined in the test viewpoint data (step S16-1: YES), the test specification generating unit 16 acquires the test viewpoint data (step S17-1). The test specification generating unit 16 judges whether the value of the attribute name of the test viewpoint in the design information of the child class matches the value of the attribute value of the test viewpoint (step S18-1). If the value of the attribute name of the test viewpoint in the design information of the child class does not match the value of the attribute value of the test viewpoint (step S18-1: NO), the test specification generating unit 16 does not generate a test item (step S19-1).

[0092] If the attribute value is not defined in the test viewpoint (step S16-1: NO), the test specification generator 16 determines whether the attribute name of the [SPEC:XX] tag is defined in the design information of the child class (step S20-1). If the attribute name of the [SPEC:XX] tag is defined in the design information of the child class (step S20-1: YES), the test specification generation unit 16 determines whether the attribute name of the test viewpoint is defined in the design information of the child class (step S21-1).

[0093] If the attribute name of the test viewpoint is defined in the design information of the child class, the test specification generator 16 ends the loop of the [SPEC:XX] tag. If the attribute name of the [SPEC:XX] tag is not defined in the design information of the child class (step S20-1: NO) or if the attribute name of the test viewpoint is not defined in the design information of the child class (step S21-1: NO), the test specification generation unit 16 does not generate a test item (step S22-1).

[0094] If the operation is not defined (step S13-1: NO) or after adding the value of the operation to the test item object (step S15-1), the test specification generator 16 judges whether a check is defined (step S23-1). If a check is defined (step S23-1: YES), the test specification generator 16 judges whether a [spec:XX] tag is present (step S24-1).

[0095] If there is no [spec:XX] tag (step S24-1: NO), the test specification generation unit 16 adds the confirmed value to the test item object (step S25-1). If confirmation is not defined (step S23-1: NO) or after adding the confirmed value to the test item object (step S25-1), the test specification generation unit 16 adds it to the test itemization list (step S26-1). Steps S27-1 to S30-1 are performed as many times as there are design information of child classes to be subject to test itemization. Step S27-1 is performed as many times as there are [spec:XX] tags.

[0096] The test specification generator 16 determines whether the attribute name of the [SPEC:XX] tag is defined in the design information of the child class (step S27-1). If the attribute name of the [SPEC:XX] tag is not defined in the design information of the child class (step S27-1: NO), the test specification generator 16 does not generate a test item (step S28-1). The test specification generating unit 16 adds the value of the operation to the test item object (step S29-1). The test specification generating unit 16 adds it to the test item list (step S30-1). The test specification generating unit 16 writes out the test item data (step S31-1).

[0097] In the above embodiment, the screen list, screen item specifications, and screen item processing specifications are described as examples of design documents created based on the design document template, but the present invention is not limited to these examples. For example, the present invention is not limited to the screen list, screen item specifications, and screen item processing specifications, and can be applied to other design documents.

[0098] In the above-described embodiment, the design information trace management unit 14 defines the relationship between the items of the class diagram obtained by decomposing the screen list into models and the items of the class diagram obtained by decomposing the screen item specifications into models, and the relationship between the items of the class diagram obtained by decomposing the screen item specifications into models and the items of the class diagram obtained by decomposing the screen item processing specifications into models, but this is not limited to the example. For example, the design information trace management unit 14 may define the relationships between items in a class diagram obtained by decomposing each of two design documents into models, or may define the relationships between items in a class diagram obtained by decomposing each of four or more design documents into models.

[0099] According to the information processing device 10 of the present embodiment, the information processing device 10 creates a test specification for a design document. The information processing device 10 includes a design information reading unit 11, a test viewpoint data reading unit 12, a design information trace management unit 14, and a test specification generation unit 16. The design information reading unit 11 reads a plurality of design documents to be tested, and breaks down the design information included in each of the plurality of read design documents into models. The test viewpoint data reading unit 12 reads the test viewpoint data. The design information trace management unit 14 defines the correspondence between the models based on the results of decomposing the design information included in each of the multiple design documents into models. The test specification generation unit 16 generates test items for the multiple design documents based on the test viewpoint data read by the test viewpoint data reading unit 12, the result of decomposing the design information included in each of the multiple design documents into models by the design information reading unit 11, and the result of defining the correspondence between the models by the design information trace management unit 14, and generates a test specification based on the generated test items.

[0100] With this configuration, the information processing device 10 can define the correspondence between design information based on the result of decomposing the design information included in each of the multiple design documents into models, so that for any design information, a test specification can be created using other related design information. Specifically, for screen design information, the information processing device 10 can create a test specification using design information of a related function. Therefore, compared to a case where the correspondence between design information is not defined based on the result of decomposing the design information included in each of the multiple design documents into models, the number of types of tests that can be generated can be increased.

[0101] In the information processing device 10, the design information trace management unit 14 defines the correspondence between items included in a class diagram obtained by decomposing the design information included in each of a plurality of design documents into models.

[0102] With this configuration, the information processing device 10 can define the correspondence between items included in a class diagram obtained by decomposing the design information included in each of a plurality of design documents into models, and therefore, for any design information, a test specification can be created using other related design information. Specifically, for screen design information, the information processing device 10 can create a test specification using design information of related functions. This allows the number of types of tests that can be generated to be increased compared to a case in which the correspondence between items included in a class diagram obtained by decomposing the design information included in each of multiple design documents into models is not defined.

[0103] In the information processing device 10, the test specification generating unit 16 obtains the values ​​of the generated test items from the results of decomposing the design information into models.

[0104] By configuring in this manner, the information processing device 10 can obtain the values ​​of the generated test items from the results of decomposing the design information contained in each of the multiple design documents into models, and can create a test specification based on the obtained values ​​of the test items.

[0105] In the information processing device 10, the test specification generating unit 16 obtains the values ​​of the generated test items from the result of decomposing the design information into models, by using the result of defining the correspondence between the models.

[0106] By configuring in this manner, the information processing device 10 can obtain the values ​​of the generated test items from the result of decomposing the design information contained in each of the multiple design documents into models, using the result of defining the correspondence between the models, so that for any design information, the values ​​of the test items can be obtained by using other related design information.

[0107] (Modification of the embodiment) <Information processing device> 10 is a diagram showing an example of an information processing device according to a modification of the embodiment. The information processing device 10a according to the modification of the embodiment is realized by a device such as a personal computer, a server, a smartphone, a tablet computer, or an industrial computer. The information processing device 10a includes a design information reading unit 11, a test viewpoint data reading unit 12, a design information storage unit 13, a design information trace management unit 14, a trace storage unit 15, a test specification generation unit 16a, a design information verification management unit 17a, a design meta information storage unit 18a, and a verification error storage unit 19a.

[0108] The design information verification management unit 17a judges whether or not there is a design omission in the design information stored in the design information storage unit 13, based on a verification rule defined for the meta information of the design information stored in the design meta information storage unit 18a. The design information verification management unit 17a stores design information that is judged to have no design omission in the design information storage unit 13, and stores design information that is judged to have a design omission in the verification error storage unit 19a.

[0109] Specifically, the design information verification management unit 17a judges whether values ​​are written in required items, such as specification class, screen ID, screen name, and description, which are defined when the screen list table is decomposed into models. For example, the required items are set in advance by an administrator. The design information verification management unit 17a judges that there is no design omission when values ​​are written in all required items, and judges that there is a design omission when a value is not written in any required item.

[0110] When it is determined that there is no design omission, the design information verification management unit 17a stores the screen list table for which it is determined that there is no design omission in the design information storage unit 13. When it is determined that there is a design omission, the design information verification management unit 17a stores the screen list table for which it is determined that there is a design omission in the verification error storage unit 19a.

[0111] More specifically, the design information verification management unit 17a determines whether values ​​are written in required items such as the specification class, screen item ID, screen item name, element type, label, etc. that are defined when the screen item specification is decomposed into a model. For example, the required items are set in advance by an administrator. The design information verification management unit 17a determines that there is no design omission when values ​​are written in all of the required items, and determines that there is a design omission when a value is not written in any of the required items.

[0112] When it is determined that there is no design omission, the design information verification management unit 17a stores the screen item specifications for which it is determined that there is no design omission in the design information storage unit 13. When it is determined that there is a design omission, the design information verification management unit 17a stores the screen item specifications for which it is determined that there is a design omission in the verification error storage unit 19a.

[0113] More specifically, the design information verification management unit 17a judges whether values ​​are written in required items such as the specification class, action ID, action name, event, corresponding item name, action details, and processing description that are defined when the screen item processing specification is decomposed into a model. For example, the required items are set in advance by an administrator. The design information verification management unit 17a determines that there is no design omission when values ​​are written in all of the required items, and determines that there is a design omission when a value is not written in any of the required items.

[0114] When it is determined that there is no design omission, the design information verification management unit 17a stores the screen item processing specification for which it is determined that there is no design omission in the design information storage unit 13. When it is determined that there is a design omission, the design information verification management unit 17a stores the screen item processing specification for which it is determined that there is a design omission in the verification error storage unit 19a.

[0115] The design meta information storage unit 18a is realized by a HDD, a flash memory, a RAM, a ROM, etc. The design meta information storage unit 18a stores verification rules defined for meta information of design information. The design meta information storage unit 18a stores required items for items defined when the design information is decomposed into models.

[0116] Specifically, the design meta information storage unit 18a stores required items, such as specification class, screen ID, screen name, and description, which are defined when a screen list table is decomposed into models, and in which values ​​must be written. Specifically, the design meta information storage unit 18a stores required items, such as specification class, screen item ID, screen item name, element type, label, etc., which are defined when the screen item specification is decomposed into a model, and in which values ​​must be written.

[0117] Specifically, the design meta information storage unit 18a stores required items for which values ​​must be written, such as the specification class, action ID, action name, event, corresponding item name, action details, and processing description, which are defined when the screen item processing specification is decomposed into a model.

[0118] The verification error storage unit 19a is realized by a HDD, a flash memory, a RAM, a ROM, etc. The verification error storage unit 19a stores design information that is determined by the design information verification management unit 17a to include a design omission.

[0119] Specifically, the verification error storage unit 19a stores a screen list determined by the design information verification management unit 17a to have a design omission. Also, specifically, the verification error storage unit 19a stores a screen item specification determined by the design information verification management unit 17a to have a design omission. Also, specifically, the verification error storage unit 19a stores a screen item processing specification determined by the design information verification management unit 17a to have a design omission.

[0120] The test specification generating unit 16a acquires design information and test viewpoint data from the design information storing unit 13, and acquires trace information from the trace storing unit 15. For example, the test specification generating unit 16a acquires from the design information storing unit 13 design information that has been determined to have no design omissions. The test specification generator 16a generates a test specification based on the acquired design information, test viewpoint data, and trace information. For example, the test specification generator 16a creates a test specification based on a test specification template. The process of the test specification generator 16a creating a test specification is the same as that of the test specification generator 16, except that the test specification generator 16a uses design information that is determined to have no design omissions.

[0121] An example of the operation of the information processing device 10a according to the modified embodiment can be applied to FIGS. 7 to 9, and therefore a description thereof will be omitted.

[0122] In the modification of the embodiment described above, the case where the design information verification management unit 17a determines whether or not there is a design omission in the design information has been described, but the present invention is not limited to this example. For example, the design information verification management unit 17a may determine whether or not there is an error in the described values ​​for items defined when the design information included in each of the multiple design documents is decomposed into models. The design information verification management unit 17a stores the design information determined to be error-free in the design information storage unit 13, and stores the design information determined to be error-free in the verification error storage unit 19a.

[0123] In this case, the design meta information storage unit 18a stores conditions for values ​​described for items defined when the design information is decomposed into models as verification rules defined for the meta information of the design information. The design information verification management unit 17a determines that there is no error when the values ​​described for items defined when the design information included in each of the multiple design documents is decomposed into models satisfy the conditions stored in the design meta information storage unit 18a, and determines that there is an error when the described values ​​do not satisfy the conditions.

[0124] In a modification of the above-described embodiment, the design information verification management unit 17a may be configured to have verification rules defined for meta-information of design information.

[0125] According to the information processing device 10a of the modified embodiment, the information processing device 10 further includes a design information verification management unit 17a that verifies whether or not there is a design omission in the result of decomposing the design information included in each of the multiple design documents into models based on the verification rules defined for the meta information. The test specification generation unit 16a generates test items for the multiple design documents based on the result of decomposing the design information determined by the design information verification management unit 17a to have no design omission into models, and generates a test specification based on the generated test items.

[0126] With this configuration, the test specification generator 16a can generate test specifications based on the results of decomposing design information that is deemed to have no design omissions into models, thereby ensuring the quality of data input for generating test specifications. Therefore, the test specifications generated by the test specification generator 16a will not omit any test items required for the system and software.

[0127] According to the information processing device 10a of the modified embodiment, the information processing device 10 further includes a design information verification management unit 17a that verifies whether or not there is an error in the result of decomposing the design information included in each of the multiple design documents into a model based on a verification rule defined for the meta information. The test specification generation unit 16a generates test items for the multiple design documents based on the result of decomposing the design information determined to be error-free by the design information verification management unit 17a into a model, and generates a test specification based on the generated test items.

[0128] With this configuration, the test specification generator 16a can generate test specifications based on the results of decomposing design information deemed to be error-free into models, thereby ensuring the quality of data input for generating test specifications. Therefore, the test specifications generated by the test specification generator 16a are free of errors in test items required for the system and software.

[0129] Although the embodiments and modifications of the present invention have been described above, these embodiments and modifications are presented as examples and are not intended to limit the scope of the invention. These embodiments and modifications can be implemented in various other forms, and various omissions, substitutions, changes, and combinations can be made without departing from the gist of the invention. These embodiments and modifications are included in the scope and gist of the invention, and are also included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0130] 10, 10a... information processing device, 11... design information reading unit, 12... test viewpoint data reading unit, 13... design information storage unit, 14... design information trace management unit, 15... trace storage unit, 16, 16a... test specification generation unit, 17a... design information verification management unit, 18a... design meta information storage unit, 19a... verification error storage unit

Claims

1. In an information processing device for creating a test specification for a design document, a design information reading unit that reads a plurality of design documents to be tested and breaks down design information included in each of the plurality of read design documents into models; a test viewpoint data reading unit for reading test viewpoint data; a design information trace management unit that defines a correspondence relationship between models based on a result of decomposing design information included in each of the plurality of design documents into models; a test specification generation unit that generates test items for the plurality of design documents based on the test viewpoint data read by the test viewpoint data reading unit, a result of decomposing design information included in each of the plurality of design documents into models by the design information reading unit, and a result of defining a correspondence relationship between the models by the design information trace management unit, and generates a test specification based on the generated test items; An information processing device comprising:

2. A design information verification management unit that verifies whether or not there is a design omission in the result of decomposing the design information included in each of the plurality of design documents into a model based on a verification rule defined for the meta information. Further equipped with 2. The information processing device according to claim 1, wherein the test specification generation unit generates test items for a plurality of the design documents based on a result of decomposing the design information determined by the design information verification management unit to have no design omissions into models, and generates a test specification based on the generated test items.

3. A design information verification management unit that verifies whether or not there is an error in the result of decomposing the design information included in each of the plurality of design documents into a model based on a verification rule defined for the meta information. Further equipped 2. The information processing device according to claim 1, wherein the test specification generation unit generates test items for a plurality of the design documents based on a result of decomposing the design information determined to be error-free by the design information verification management unit into a model, and generates a test specification based on the generated test items.

4. The information processing apparatus according to claim 1 , wherein the design information trace management unit defines a correspondence relationship between items included in a class diagram obtained by decomposing the design information included in each of the plurality of design documents into models.

5. The information processing apparatus according to claim 1 , wherein the test specification generating unit obtains the generated values ​​of the test items from a result of decomposing the design information into models.

6. The information processing apparatus according to claim 1 , wherein the test specification generating unit obtains the generated values ​​of the test items from a result of decomposing the design information into models, by using a result of defining a correspondence relationship between the models.

7. An information processing method executed by an information processing device for creating a test specification for a design document, comprising: Reading a plurality of design documents to be tested, and decomposing design information contained in each of the plurality of design documents into models; Load the test viewpoint data, defining a relationship between the models based on a result of decomposing the design information included in each of the plurality of design documents into models; An information processing method comprising: generating test items for a plurality of said design documents based on the test viewpoint data, a result of decomposing design information contained in each of the plurality of said design documents into models, and a result of defining the relationships between the models; and generating a test specification based on the generated test items.

8. To your computer A plurality of design documents to be tested are read, and design information included in each of the plurality of design documents that are read is decomposed into a model; Load the test viewpoint data, defining relationships between models based on a result of decomposing design information included in each of the plurality of design documents into models; A program that generates test items for the multiple design documents based on the test viewpoint data, a result of decomposing design information included in each of the multiple design documents into models, and a result of defining the relationship between the models, and generates a test specification based on the generated test items.

Images