JPH09223041A - Development supporting device for software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently perform series of software development from a software program preparation process to a system test process. SOLUTION: This device is provided with a specification information generating means 4 for generating specification information 14 of software based on an inter-object relation description file 13 generated in the intermediate process of the program preparation process and a test scenario generating means 5 for generating a test scenario 15 deciding the procedure of operations in the case of performing a system test based on the specification information 14 generated by this specification information generating means 4. Then, since information required for executing the system test is automatically generated from the information showing the structure or the like of a program, which is generated in the program preparation process, and dispatched to a test process, it is made not necessary for a user to prepare the information required for the system test again, and the labor due to manual operations for software development can be remarkably saved.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software development support device, for example, a GUI (Graphical User Int.
It is suitable for use in a device for consistently supporting from the process of creating a software program with an erface) to the system test process.

[0002]

2. Description of the Related Art In recent years, computer systems have been used in a wide variety of applications throughout the world, and their range of use is expanding more and more. The performance of CPUs used in this computer system has been dramatically improved, and high-precision displays such as bitmap displays have become popular.

Under such a background, software design is performed by using a character-based user interface.
There is a growing focus on things like building user interfaces that are easier to use. Therefore, recently, GUI-based computer systems have become mainstream.

Particularly, as the standard window system represented by the X window system has spread, the importance of GUI in software has become higher and higher. Therefore, the evaluation of the entire software by the user often depends on the evaluation of the GUI.

This GUI-based software has visual parts such as buttons, and the operations for them are mainly performed by an input device such as a mouse. Therefore, it is easy to obtain an intuitive understanding and is very easy for the user to use. Also,
The software has a high degree of freedom that can change the input state according to the relationship between the position and position of the pointer and the position and type of parts that appear on the screen.

By the way, software development is generally performed through a program creation process and a test process. In the program creating step, it is possible to create a desired program by combining various program parts (GUI parts) using the GUI and a plurality of program parts related to application functions. Here, the program component generally refers to a functional unit prepared for the purpose of reusing software.

In programming using such program parts, the program parts are often provided in functional units called objects. In general, the technique of designing a program centered on this object unit is called object-oriented programming. In this object-oriented programming, a program is designed so that message communication is performed between each object and each object performs a process according to the content of the received message.

Further, in the test process, a system test is performed in order to check whether or not a program constructed by combining a plurality of program components that have been subjected to a unit test satisfies design specifications. In a series of software development from the program creation process to the test process, software development automation has been considered, which maximizes the use of a computer and reduces the part that requires human labor to improve the development efficiency.

[0009]

However, at present, complete automation is difficult, and a development support device for consistently supporting software, particularly GUI-based software, from program creation to system testing is not available. It doesn't exist. In other words, conventionally, only a tool for partially automating a series of software development has been proposed.

Therefore, in a series of software development steps, a program creating device for automatically creating a source code of a program and a test device for performing a system test of the created program are separately used. As a result, since there is no information that can be passed directly from the program creation device to the test device, it is inefficient because it is necessary to recreate the necessary information when performing the system test.

Further, in GUI-based software, the more complicated the GUI function, the more enormous the combinations of mouse and keyboard operations and the arrangement and types of windows that dynamically change due to these operations. . Therefore, if a person re-creates the information necessary for the system test, the necessary information may be leaked at that time, and the test content may be omitted.

Further, regarding the information itself necessary for the above system test, in the GUI-based software development so far, there is almost no description other than the functional specifications for the software, and it is possible to test the information such as the structural specifications. The reality was that the tests were not satisfactory.

The present invention has been made in view of such an actual situation, and it is possible to consistently support from the software program creation process to the system test process, and to efficiently perform a series of software development. The first purpose is to be able to perform.

Further, according to the present invention, it is possible to perform a system test in a category that could not be performed in the past, and to obtain a sufficiently satisfactory test result without missing the test content. The second purpose is to do so.

[0015]

A software development support apparatus according to the present invention comprises a program creating means for creating a desired software program by combining a plurality of program parts related to GUI and a plurality of program parts related to application functions. , Specification information generating means for generating the specification information of the software according to a predetermined description format based on the inter-object relation description information generated in the intermediate step of program creation by the program creating means, and the specification information generating means. A test scenario generation means for generating a test scenario that defines an operation procedure for a system test based on the specified specification information, and a test program of the software is operated according to the test scenario generated by the test scenario generation means. You The test scenario executing means and the execution result comparing means for checking whether or not the attribute value in each state of the program under test being executed by the test scenario executing means matches the value described in the specification information. It is provided.

Another feature of the present invention is a GUI.
Program creating means for creating a desired software program by combining a plurality of program parts related to the application function and a plurality of program parts related to application functions, and inter-object relationship description information created in the intermediate process of the program creation by the program creating means. Based on the above, a specification information generating means for generating the specification information of the software in accordance with a predetermined description format, and a specification document generating means for generating a specification document based on the specification information generated by the specification information generating means are provided. It is a thing.

Another feature of the present invention is that the inter-object relationship description information comprises layout information indicating the structure of the program of the target software and operation information indicating a message link connecting the program parts. It is characterized by that.

Another feature of the present invention is that the specification information generating means, as the specification information of the software, is structural specification information indicating a structure related to the GUI section of the software and state transition related to the GUI section of the software. It is characterized by generating three types of state transition specification information indicating the above and individual state specification information indicating attribute values in each individual state regarding the GUI part of the software.

Another feature of the present invention is that the specification information generating means, as the specification information of the software, structural specification information indicating a structure related to the GUI section of the software and state transition related to the GUI section of the software. And two types of state transition specification information representing
The test scenario generation means is characterized by generating the test scenario based on the structural specification information and state transition specification information generated by the specification information generation means.

Another feature of the present invention is that the specification information generating means generates individual state specification information representing an attribute value in each individual state regarding the GUI part of the software, and the execution result collating means, It is checked whether the attribute value in each state of the program under test being executed by the test scenario executing means matches the value described in the individual state specification information generated by the specification information generating means. It is characterized by.

Another feature of the present invention is that a program creating means for creating a desired software program by combining a plurality of program parts, and an object created in an intermediate process of creating the program by the program creating means. Based on the relationship description information,
On the basis of the specification information generating means for generating the specification information of the software according to a predetermined description format, and the specification information generated by the specification information generating means, a test scenario that defines an operation procedure for a system test is generated. In each state of the test scenario generation means, the test scenario execution means for operating the test program of the software according to the test scenario generated by the test scenario generation means, and the respective states of the test program being executed by the test scenario execution means. Execution result collation means for collating whether or not the attribute value matches the value described in the specification information is provided.

Another feature of the present invention is that a program creating means for creating a desired software program by combining a plurality of program parts, and an object created in an intermediate process of creating the program by the program creating means. Based on the relationship description information,
A specification information generating means for generating the specification information of the software according to a predetermined description format, and a specification document generating means for generating a specification document based on the specification information generated by the specification information generating means are provided.

Since the present invention comprises the above technical means, based on the inter-object relationship description information obtained in the intermediate process when creating the program of the target software,
Specification information expressing the GUI part of the software is automatically generated, and based on the specification information, a test scenario that defines an operation procedure for performing the specification verification (system test) of the software is automatically generated. Will be generated. As a result, the information necessary for performing the system test can be automatically passed from the program creation process to the test process in just the right amount, and it becomes unnecessary for a human to recreate the information necessary for the system test.

According to another feature of the present invention, for example, a specification of GUI-based software, which was difficult to describe in the past, is automatically generated based on the specification information generated as described above. Will be created in. Moreover,
Since the specification information is generated based on the inter-object relation description information obtained in the intermediate process of creating the target program, there is no difference in the content between the target program and the specifications. .

Further, according to another feature of the present invention, the test scenario is generated based on the structural specification information and the state transition specification information which are not different in content from the program of the above-mentioned object. The executed test scenario covers all the states and all the state transitions of the GUI part of the software. Further, since the system test is executed according to the test scenario generated based on the structural specification information and the state transition specification information, it is possible to perform a test other than the function test which has been conventionally performed.

[0026]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a configuration example of a software development support device according to the present embodiment. First, the configuration of the software development support apparatus according to the present embodiment will be described with reference to FIG.

In FIG. 1, reference numeral 1 denotes a source code generating means, which generates a source code 11 of a target program by combining a plurality of program parts (GUI parts etc.). Reference numeral 2 denotes an execution program generating means, which compiles and links the source code 11 generated by the source code generating means 1 to generate the execution program 1.
Generate 2.

Reference numeral 3 is an inter-object relationship description file generating means, which generates a file 13 in which the relationship defined between the program parts constituting the above-mentioned target program and the message contents are described. The file in which the relationship between the program parts is described is the layout information file 13a that represents the structure of the program. In addition, the file that describes the message content is a message link that connects the program parts (message flow).
Is a motion information file 13b representing

Reference numeral 4 is a specification information generating means, which uses the inter-object relationship description file 13 generated by the inter-object relationship description file generating means 3 to create a GUI.
Specification information 14 for accurately defining the base software is generated. That is, the information (inter-object relation description file 13) written in the description format depending on the tool used in the program creation process is converted into the description format information suitable for the test process of this embodiment.

The specification information 14 generated here is of three types: a structure specification file 14a, a state transition specification file 14b, and an individual state specification file 14c. The structure specification file 14a defines the structure related to the GUI part of software. The state transition specification file 14b defines the state transition of the GUI part of software. Further, the individual state specification file 14c defines the attribute value of the GUI component in each individual state regarding the GUI part of the software.

These structural specification file 14a, state transition specification file 14b and individual state specification file 14
Both c are in a text file format and are automatically generated by the specification information generating means 4. 2 to 7
2 is a diagram showing an example of each of these files, FIG. 2 shows an example of the structure specification file 14a, FIG. 3 shows an example of the state transition specification file 14b, and FIGS. 4 to 7 are individual state specification files 14c. Shows an example.

As shown in FIG. 2, the structure specification file 14
a is what GU is the software to be tested
It describes the combination of the I parts, and one GUI part corresponds to the part I
D, a part class, and a part name are described.

In the example of FIG. 2, the part ID indicates the parent-child relationship from the highest level part. That is, when the component ID is divided into the right and left by the rightmost period, the left shows the component ID of the parent component of the component, and the right shows the order in the sibling components. For example, a part having a part ID of 1.1.1.1 has a parent part having a part ID of 1.1.1, indicating that the part itself is the first child part.

The part class indicates the class to which each GUI part belongs. Further, the component name is described so that the same GUI components respectively belonging to different aggregate components (component classes indicated by component IDs without periods) can be distinguished from each other.

Further, as shown in FIG. 3, the state transition specification file 14b is such that, when an input event relating to the GUI occurs, how the state relating to the GUI part of the software to be tested changes from before the event occurs to after the event occurs. It shows whether to transition to. In the state transition specification file 14b, the types of input events and the states before and after the event occurrence are described in association with each other.

For example, explaining the state transition described at the top of FIG. 3, (SAMPLE.Meters) is shown in FIG.
Since the toggle button is shown from the structure specification file 14a of FIG. 6, it means that if the toggle button is clicked in the state “0”, the state transits to the state “1”. As described above, the state transition specification file 14b of the present embodiment describes the state transition for each minimum unit in which a person performs a GUI operation using a mouse or a keyboard.

As is apparent from FIG. 3, in the present embodiment, there are four states of "0" to "3", and by receiving eight types of input events, the state of transition between these states is shown. This state transition specification file 14b is shown.

Further, the individual state specification file 14c is composed of the parts constituting the GUI section (the structure specification file 14a in FIG. It describes how the attribute value of each component shown) will be.
FIG. 4 describes the attribute values for the state “0”, FIG. 5 for the state “1”, FIG. 6 for the state “2”, and FIG. 7 for the state “3”.

Individual state specification file 14c of this embodiment
The attribute names handled in (1) are basically based on the window attributes managed by the X window system.
That is, the map attribute (map_state), the x coordinate value (x) based on the parent component, the y coordinate value (y) based on the parent component, the component width (width), and the component height (height).
And border width (border_width).

The above-mentioned three types of specifications are newly devised by the applicant of the present invention in order to define GUI-based software. In particular, it is characterized by incorporating the state transition specification. By using these three types of specifications, it is possible to accurately express the specifications of GUI-based software, which has been difficult to describe in the past, in accordance with a predetermined format.

By unifying the specification description system in this way, it becomes possible to reliably transfer information between the program creation process and the test process. Further, it becomes possible to realize an automatic generation function of a test scenario and an automatic judgment function of a test result, which will be described later.

Returning to FIG. 1, the description will be continued. Reference numeral 5 is a test scenario generating means, which generates a test scenario 15 in accordance with the structure specification file 14a and the state transition specification file 14b generated by the specification information generating means 4. The test scenario defines a GUI operation procedure for verifying the specifications of the GUI part of the software to be tested.

Here, this test scenario generation means 5
Uses the above-mentioned state transition specification file 14b to automatically generate a test scenario 15 necessary to cover all states and all state transitions of the GUI part of the software. That is, the test scenario 15 that always executes all the events (input events) shown in FIG. 3 at least once is automatically generated. The test scenario 15 is in a text file format so that the user can easily edit it.

As described above, the specification information 14 generated by the specification information generating means 4 is used for generating the test scenario 15 in the test scenario generating means 5, but the specification document generating means 8 is used. By specification 1
It is also possible to use it when creating 6. The specification creating unit 8 creates a specification 16 based on the specification information 14 and outputs it to, for example, a printer or a display (not shown).

As described above, in the past, it was very difficult to describe the specifications of GUI-based software, and although the specifications themselves were not created in many cases, according to this embodiment, the specifications 16 Can be generated automatically. Therefore, the manpower required to create the specifications can be significantly reduced. The specification information 14 is
The execution program 1 is generated based on the inter-object relationship description file 13 that expresses the relationship and structure between the program parts that make up the target software.
2 and the specification 16 will not have a difference in content.

Reference numeral 6 is a test scenario executing means, which reads the test scenario 15 and directly outputs an event message (an event message having the same format as that directly generated from an actual input device) based on the read contents of the test scenario 15. To create. Then, by supplying the created direct event message to the X server (not shown), the GUI part of the software to be tested is indirectly operated according to the test scenario 15.

Reference numeral 7 is an execution result collating means, which reads the structural specification file 14a and the individual state specification file 14c, and the component attribute values in each state of the program under test being executed by the test scenario executing means 6 are
Check whether it matches the value described in the individual status specification. Then, the test result report 17 in text file format is created based on the contents of the collation result.

For example, based on the test scenario 15, the test scenario executing means 6 executes the input event (clicking the toggle button in the state "0") at the top of the state transition specification file 14b shown in FIG. If executed, the state should transition to "1". The execution result matching unit 7 determines whether or not the state actually transits to "1" as a result of the execution of the input event, immediately after the execution of the input event, the attribute value of the program being started and the attribute of the individual state specification file 14c. Verify by matching the value.

Next, the operation will be described in detail. First, a software developer creates an inter-object relationship description file generating means 3 with an inter-object relationship description file 13 that indicates what kind of program parts are combined in what way to create the target software. Generated by. The inter-object relationship description file generating means 3 is, for example, an editor.

The inter-object relationship description file 13 generated here is a general-purpose file that does not depend on the type of OS (operating system) or window system to be applied, and can be used in common.
On the other hand, the source code 11 needs to be created in consideration of what kind of OS or window system it runs on.
It is unique to the system to which it applies.

The source code 11 is generated by the source code generating means 1 using the inter-object relation description file 13. In this sense, the inter-object relationship description file 13 is the primary artifact, source code 11
Can be said to be a secondary product generated based on the inter-object relationship description file 13. The source code 11 generated in this way is compiled and linked by the execution program generation means 2 to be an execution program 12.

On the other hand, the inter-object relationship description file 13 generated by the inter-object relationship description file generating means 3 is also supplied to the specification information generating means 4. The specification information generation means 4 uses the supplied inter-object relationship description file 13 to generate the above-mentioned three types of specification files 14a, 14b, 14c.

Here, the structure specification file 14a is generated as it is from the layout information file 13a. As described above, since the layout information file 13a represents the structure of the target program, the structure specification file 14a is the layout information file 13a.
It is possible to generate it only by performing the process of changing the description format of.

The state transition specification file 14b and the individual state specification file 14c are generated based on the layout information file 13a and the operation information file 13b. The generation procedure of the state transition specification file 14b and the individual state specification file 14c will be described below with reference to the operation explanatory diagram of FIG. 8 and the flowcharts of FIGS. 9 to 11.

FIG. 8A is a conceptual diagram showing an example of the relationship between the program parts and the message flow indicated by the layout information file 13a and the operation information file 13b. In this example, a state in which a message link is set up from the part A to the part B is shown.

Although only the parts A and B are shown here for the sake of explanation, there are actually some other parts, and message links are established between them.
Further, although one message link is shown from the part A to the part B, actually, a plurality of types of messages are sent from the part A to the part B.

The part A has four states A _{0 to} A ₃ as conceptually illustrated in FIG. 8B, and the part A has the states shown in FIG. 8 according to the types of messages given from other parts.
It is assumed that the transition is made as shown by the arrow in (b). Also,
The component B has B _{0 to} B ₂ as illustrated in FIG.
8C, and transitions as shown by the arrow in FIG. 8C according to the type of message given from another component.

First, the specification information generating means 4 is operated as shown in FIG.
From the information shown in FIG. 8A, the state transition specification information and the individual state specification information for each part having the graph structure shown in FIGS. 8B and 8C are generated.

For example, when generating the specification information for the part A, the contents of a plurality of messages sent from another part to the part A are checked to see if it is a message that causes a state transition of the part A. to decide. Then, only the message that causes the state transition is extracted, and the state transition specification information and the individual state specification information are generated based on the extracted message. The same applies to the part B.

By the way, the state of the part A and the state of the part B often transit under the condition based on their mutual relations. For example, regarding the state transition of the component B shown in FIG. 8C, it is conceivable that the transition from the state B ₁ to the state B ₂ occurs only when the state of the component A is A ₁ .

Therefore, in the present embodiment, the specification information generating means 4 is not limited to generating the specification information for each part as shown in FIGS. 8 (b) and 8 (c), and FIG. Specification information (state transition specification file 14b and individual state specification file 14c) having a graph structure as shown in (d) is generated. As a result, it is possible to know not only that the state of a certain component has transited, but also in what state it transited.

FIG. 9 shows the overall flow of the specification information generation procedure described above. That is, first, in step P1, a state transition graph for each component attribute is generated for each component based on the information described in the layout information file 13a and the operation information file 13b.

Next, in step P2, the above step P1
Using the state transition graph for each component attribute generated in
A state transition graph of each component having the structure illustrated in (b) and (c) is generated. And step P3
Then, using the state transition graph of each component generated in step P2, the entire state transition graph having the structure illustrated in FIG. 8D is generated.

FIG. 10 shows details of the process in step P2 of FIG. In FIG. 10, first, in step P11, all events (all messages) described in the state transition graph for each component attribute generated in step P1 of FIG. 9 are extracted. Then, the next step P12
Then, an initial state set (for example, state A ₀ or state B ₀ ) is created from the initial value of the component attribute, and the attribute value is registered as the first individual state specification information.

Next, in step P13, the above step P
In the initial state created in 12, the above step P11
Create a state set after the occurrence of each event extracted in. As a result, the state transition specification information when each event occurs in the state A ₀ or B ₀ can be obtained.

Then, in step P14, one of the state sets created in step P13 (for example,
A state A ₁ or a state B ₁ ) is selected, and a state set after the occurrence of each event extracted in step P11 in the selected state is created. As a result, the state transition specification information when each event occurs in the state A ₁ or B ₁ can be obtained.

Then, in step P15, it is determined whether or not the attribute value of the state set selected in step P14 has already been registered as individual state specification information. If it is determined that the state set has not been registered, the attribute value of the state set is registered as the second individual state specification information in step P16, and the process returns to step P14.

On the other hand, if it is determined in step P15 that the attribute value of the state set selected in step P14 has already been registered as the individual state specification information, the process proceeds to step P17 and all the parts have Determine if a state set has been considered. Then, if there is a state set that has not been examined yet, the process returns to step P14.

In this way, steps P14 → P15 → P
By repeating 16 loops or P14 → P15 → P17 loops, the attribute values of all the states of each part are sequentially registered as individual state specification information, and each occurrence of an event causes How the state of the component transits is sequentially registered as the state transition specification information. After that, when it is determined in step P17 that the examination of all the state sets has been completed, the state transition graph generation processing of each component is ended.

FIG. 11 shows details of the process in step P3 of FIG. The processing procedure shown in FIG. 11 is basically the same as the processing procedure shown in FIG.
That is, first, in step P21 of FIG. 11, all events described in the state transition graph of each component generated in the process of step P2 of FIG. 9 are extracted. And step P
At 22, an initial state set as a whole is created from the initial state set of each part, and the attribute value thereof is registered as the first individual state specification information.

Next, in step P23, the above step P
In the initial state created in step 22, the above step P21
Create a state set after the occurrence of each event extracted in. As a result, for example, the initial state (A ₀ + B ₀ )
At this time, the state transition specification information when each event occurs can be obtained.

After that, in step P24, one is selected from each state set created in step P23, and the state set after the occurrence of each event extracted in step P21 in the selected state To create each. Thereby, the state transition specification information when each event occurs in the selected state is obtained.

Then, in step P25, it is determined whether or not the attribute value of the state set selected in step P24 has already been registered as individual state specification information. If it is determined that the state set has not been registered, the attribute value of the state set is registered as the second individual state specification information in step P26, and the process returns to step P24.

On the other hand, if it is determined in step P25 that the attribute values of the state set selected in step P24 have already been registered as individual state specification information, the process proceeds to step P27 and all state sets are examined. Determine if it is done. Then, when it is determined that there is a state set that has not been examined yet, the process returns to step P24.

In this way, steps P24 → P25 → P
By repeating the loop of 26 or the loop of P24 → P25 → P27, attribute values of all assumed states are sequentially registered as individual state specification information, and each part is generated in response to the occurrence of each event. The state transition specification information is sequentially registered as to how the state changes. After that, when it is determined in step P27 that the examination has been completed for all the state sets, the entire state transition graph generation process ends.

As described above, the three types of specification information 14 as illustrated in FIGS. 2 to 7, that is, the structure specification file 14a, the state transition specification file 14b and the individual state specification file 14c are used as the specification information generating means 4. Then, the test scenario 15 is automatically generated by the test scenario generating means 5 based on the specification files. At this time, the test scenario generation means 5 generates a test scenario 15 as illustrated in FIG. 13 according to the flowchart shown in FIG.

That is, first, step P31 in FIG.
Then, the state transition specification file 14b as illustrated in FIG.
Is expanded into a graph that is information of a structure that is easy to operate on a computer. The graph is composed of a plurality of nodes and a plurality of edges connecting the nodes, and each node has a 1: 1 ratio for each of states “0” to “3”.
, And each edge corresponds 1: 1 to each of the various input events.

The expansion to the above graph is performed on the memory,
The state transition specification file 14b illustrated in FIG. 3 is replaced with a node list representing a plurality of nodes and an adjacent edge list representing a plurality of edges connected to each node.

Next, in step P32, the leading node of a certain edge is set as the transition source node, and in step P33
Move the state to the transition source node with. For example, the current state is “0” with the node of state “0” as the head node.
Go to Then, in step P34, it is determined whether or not there is an edge without a completion mark in the adjacent edge list for the current transition source node. The completion mark mentioned here is a mark that is added to an edge corresponding to an event when the event is added to the test scenario 15.

If it is determined in step P34 that there is an edge without a completion mark, the process proceeds to step P35, and the event corresponding to the edge found first is added to the test scenario 15. Then, Step P36
Then, mark the first edge found above as completed. After that, in step P37, the terminal node of the first found edge is set as a new transition source node, and in step P38, there is an edge not marked as complete in the adjacent edge list for the new transition source node. Determine again.

If it is determined that there is no edge without the completion mark, the transition source node is marked with the completion mark in step P39, and the process proceeds to step P40. The completion mark attached to the transition source node indicates that the event corresponding to the relevant edge of the transition source node has been added to the test scenario 15. On the other hand, if it is determined in step P38 that there is an edge without a completion mark, the process jumps to step P40.

If it is determined in step P34 that there is no edge without a completion mark, step P4
Proceed to 1 to determine whether or not there is a node not marked as completed in the node list. If it is determined that there is a node without a completion mark, step P42.
Go to and set the first found node as the transition destination node. On the other hand, when it is determined that there is no node without the completion mark, the test scenario generation process ends.

After the processing of the step P42 is finished, in the next step P43, it is determined whether or not there is an edge path connecting the transition source node and the transition destination node set at that time at the shortest. If it is determined that there is a shortest path, the process proceeds to step P44, the event corresponding to the edge along the first shortest path found is added to the test scenario 15, and if necessary, the shortest path Mark the edges and nodes on the way as complete. Then, it progresses to step P40.

In step P40, the transition destination node is set as a new transition source node. When the process of step P40 ends, the process returns to step P33, and the state is moved to the transition source node set at that time.
Then, the above-described operation is repeated through the processing of the next step P34.

On the other hand, when it is determined in step P43 that there is no shortest path, the process proceeds to step P45, and it is determined whether the transition source node at that time is the head node. When it is determined that the node is the head node, the test scenario generation processing is abnormally terminated, and when it is determined that the node is not the head node, the transition source node is set as the head node of the edge in step P46, and the process of step P43 is performed. Return.

In this way, when the test scenario generation means 5 generates the test scenario 15 as shown in FIG. 13, the test scenario execution means 6 automatically executes the system test based on the contents of the test scenario 15. To be done. Then, the execution result collating means 7 automatically collates whether or not the test execution result matches the specifications of the target software, and the test result report file 17 is output.

That is, the test scenario executing means 6
And the execution result collating means 7 automatically executes the system test by operating the mouse and the keyboard in place of the human hand according to the test scenario 15 generated by the test scenario generating means 5, and the test which is the execution result. The result report file 17 is automatically created. Therefore, the labor for performing the system test can be significantly reduced as compared with the conventional method in which whether or not the test execution result conforms to the specifications is manually performed.

As described in detail above, the software development support apparatus according to this embodiment can consistently and automatically perform all the steps from program creation to system test. As described above, since the process from the program creating process to the test process is consistently targeted, it is possible to pass the information necessary for performing the system test from the program creating process to the test process in just proportion.

As a result, it is not necessary for a human to recreate the information required for the system test, and the manpower required for manual operation can be greatly reduced. Therefore, it becomes possible to perform software development very efficiently as compared with the conventional method in which the program creation and the system test are performed independently.

Further, the information necessary for the system test obtained in this embodiment is the same as the target program in terms of contents as described above. Therefore, it is possible to eliminate omission of information necessary for performing the system test, and it is possible to obtain a sufficiently satisfactory excellent test result.

Further, in this embodiment, in addition to the structural specification information of the software, the specification transition ability such as the state transition specification information is sufficient for describing the GUI-based software. This makes it possible to automatically execute tests of the kind that could not be done with the software development support device.

In the above embodiments, the software accompanied by the GUI has been described, but the present invention is not limited to this, and it is needless to say that the present invention is suitable for the system test of the software without the GUI. .

[0093]

As described above, according to the present invention, the specification information generating means for generating the specification information of the GUI-based software based on the inter-object relation description information generated in the intermediate process of program creation, and the specification information generation. Since the test scenario generation means that generates the test scenario that defines the operating procedure when performing the system test based on the specification information generated by the means is provided, the information necessary for performing the system test is tested from the program creation process. It can be automatically passed to the process so that humans do not have to recreate the information necessary for system testing.

As a result, a series of steps from the program creation step to the system test step can be consistently and automatically performed, so that the manual labor can be greatly reduced and the software Development will be much more efficient.

Moreover, the specification information is generated based on the inter-object relationship description information obtained in the intermediate process when creating the target program, and the test scenario is created according to the generated specification information. Therefore, the information necessary for executing the system test can be passed from the program creation process to the test process in just proportion, and the system test can be performed accurately without omission of events.

Further, according to another feature of the present invention, it is difficult to describe in the related art because the specification creating means is provided for creating the specification based on the specification information generated by the specification information generating means. The specification of the GUI-based software can be automatically created based on the specification information, and the labor for creating the specification can be significantly reduced. Moreover, since the specification information is generated based on the inter-object relation description information obtained in the intermediate process of creating the target program, there is no difference in the content between the target program and the specifications. It is possible to create accurate specifications.

According to another feature of the present invention, the software GUI is used as the software specification information.
Three types of structure specification information representing a structure related to the I part, state transition specification information representing a state transition related to the GUI part of the software, and individual state specification information representing attribute values in each individual state related to the GUI part of the software are generated. ,
Since the test scenario is generated by using the above-mentioned state transition specification information, it is possible to generate a test scenario in which all the states and all the state transitions of the GUI part of the software are covered without any missing events. You will be able to perform tests of the kind that were previously impossible.

[Brief description of drawings]

FIG. 1 is a functional block diagram showing a configuration example of a software development support device according to an embodiment of the present invention.

FIG. 2 is a diagram showing an example of a structural specification file.

FIG. 3 is a diagram showing an example of a state transition specification file.

FIG. 4 is a diagram showing an example of an individual state specification file.

FIG. 5 is a diagram showing a continuation of an individual state specification file.

FIG. 6 is a diagram showing a continuation of an individual state specification file.

FIG. 7 is a diagram showing a continuation of an individual state specification file.

FIG. 8 is a diagram for explaining an operation when a state transition specification file and an individual state specification file are generated from a layout information file and an operation information file.

FIG. 9 is a flowchart showing the operation of the specification information generating means.

10 is a flowchart showing details of the process in step P2 of FIG.

FIG. 11 is a flowchart showing details of the process in step P3 of FIG. 9.

FIG. 12 is a flowchart showing the operation of the test scenario generation means.

FIG. 13 is a diagram showing an example of a generated test scenario.

[Explanation of symbols]

 1 Source Code Generation Means 2 Execution Program Generation Means 3 Object Relationship Description File Generation Means 4 Specification Information Generation Means 5 Test Scenario Generation Means 6 Test Scenario Execution Means 7 Execution Result Matching Means 8 Specification Writing Means 11 Source Codes 12 Execution Programs 13 Inter-object relationship description file 13a Layout information file 13b Operation information file 14 Specification information 14a Structural specification file 14b State transition specification file 14c Individual state specification file 15 Test scenario 16 Specification 17 Test result report file

Claims (8)

[Claims] 1. A program creating means for creating a program of desired software by combining a plurality of program parts related to GUI and a plurality of program parts related to application functions, and an intermediate process of program creation by the program creating means. Specification information generating means for generating the specification information of the software according to a predetermined description format based on the object-to-object relationship description information, and a system test based on the specification information generated by the specification information generating means. Test scenario generation means for generating a test scenario that defines the operation procedure, test scenario execution means for operating the program under test of the software according to the test scenario generated by the test scenario generation means, and the test scenario execution Development of a software characterized by comprising an execution result collating means for collating whether or not the attribute value in each state of the program under test being executed in a row matches the value described in the specification information. Support device. 2. A program creating means for creating a desired software program by combining a plurality of GUI-related program parts and a plurality of application function-related program parts, and an intermediate process of program creation by the program creating means. Specification information generating means for generating the specification information of the software according to a predetermined description format based on the object-to-object relationship description information, and a specification document for creating a specification sheet based on the specification information generated by the specification information generating means. An apparatus for supporting software development, which is provided with a creating means. 3. The inter-object relationship description information comprises layout information representing a structure of a program of the target software and operation information representing a message link connecting the program parts. The software development support device described in 2. 4. The specification information generating means, as the specification information of the software, structural specification information representing a structure related to a GUI part of the software, and state transition specification information representing a state transition related to the GUI part of the software.
4. The software development support apparatus according to claim 1, wherein three types of individual state specification information that represents an attribute value in each individual state regarding the GUI unit of the software are generated. 5. The specification information generation means includes, as the specification information of the software, structural specification information indicating a structure related to a GUI portion of the software and state transition specification information indicating a state transition related to the GUI portion of the software. 2. The type according to claim 1, wherein the test scenario generation means generates the test scenario based on the structural specification information and state transition specification information generated by the specification information generation means. Software development support device. 6. The specification information generating means generates individual state specification information representing an attribute value in each individual state regarding the GUI part of the software, and the execution result collating means is executing in the test scenario executing means. 2. The method according to claim 1, wherein it is checked whether the attribute value in each state of the program under test matches the value described in the individual state specification information generated by the specification information generating means. Software development support device. 7. A program creating means for creating a desired software program by combining a plurality of program parts, and based on inter-object relationship description information created in an intermediate step of program creation by the program creating means, Specification information generating means for generating software specification information according to a predetermined description format, and a test for generating a test scenario that defines an operation procedure for system test based on the specification information generated by the specification information generating means. Scenario generation means, test scenario execution means for operating the test program of the software according to the test scenario generated by the test scenario generation means, and attributes in each state of the test program being executed by the test scenario execution means If the value is above Development tool software is characterized by providing an execution result checking means for checking if it matches the value written in the like information. 8. A program creating means for creating a desired software program by combining a plurality of program parts, and based on inter-object relationship description information created in an intermediate process of creating the program by the program creating means, It is characterized in that a specification information generation means for generating specification information of software according to a predetermined description format and a specification document generation means for generating a specification document based on the specification information generated by the specification information generation means are provided. Software development support device.