JP6626946B1 - Test support system, test support method, and test support program - Google Patents

Abstract

A test support system for efficiently testing a test target system having an input / output unit is provided. A test support system includes an evaluation terminal and a scenario generation terminal connected to a host system. The evaluation terminal is a computer terminal for evaluating the test target system. The control unit 31 of the scenario generation terminal generates a scenario including a plurality of screens specified in order using the screen definition information recorded in the design document storage unit 32. Next, from the screen definition information of the screens constituting the scenario, specify the input items and output items of the screen, output a setting sheet for setting item values to the input items, and use the item values set in the setting sheet. And generate a script to execute the scenario. Then, a test control file including a setting sheet and a script is output so that the test operation of the host system is executed by the evaluation terminal. [Selection diagram] Fig. 1

Description

  The present invention relates to a test support system, a test support method, and a test support program for supporting a test on a test target system.

  The test of the host system or the like is performed by creating a test item and comparing the result obtained by executing the test with an expected value. For example, a test is performed by setting item values used for test items on a screen output to a user terminal connected to the host system. In this case, the work load such as setting an item value for each item on the screen is heavy.

  Therefore, various techniques are being examined for a test using a screen (for example, Patent Documents 1 and 2). In the technique described in Patent Document 1, a test script of a software program is made into components for each screen. Specifically, first, the standard operation commands corresponding to the names and attributes of the objects in the screen and the object types are read from the screen definition information and the standard operation commands corresponding to the object types. Next, the read information is edited and described, and a script corresponding to one screen is generated. This script simulates all input events and state transition actions to the screen using data representing input events and state transition actions as arguments. According to the test scenario, embed arguments and arrange and use parts .

  Further, in the technique described in Patent Literature 2, a process from creation of a test item related to control information input to a screen to execution of a test is performed. Specifically, screen definition information including a definition of control information that can be input to a control information input field included in a screen displayed by the application is acquired. Then, input data including a control information input field is created based on the screen definition information, and control information input to the input field is received. Then, a checklist having test items including the input control information is created. Based on the checklist, checklist execution data having control information included in the test item is generated, and a macro script is generated based on the data.

JP-A-2002-14845 JP 2014-186617 A

Among the processes in the host system, there is a process for inputting to the operation screen. If the input operation to the operation screen was performed for the test of the host system, the efficiency of the test could not be improved.
Further, among the processes in the host system, there is a process of performing a plurality of procedures in cooperation. The information generated in the preceding procedure may be used in the subsequent procedure. When testing such a linked procedure, if the work was interrupted for each procedure in order to transfer the information generated in the preceding screen processing to the subsequent screen processing, efficiency could not be improved. .

  A test support system that solves the above-mentioned problem includes a design document storage unit in which screen definition information is recorded, a control unit that generates a scenario for performing a test using the screen definition information, and a test execution unit that is connected to a host system. And Then, the control unit generates a scenario including a plurality of screens specified in order using the screen definition information recorded in the design document storage unit, from the screen definition information of the screens constituting the scenario, Identify input items and output items of the screen, output a setting sheet for setting item values to the input items, and generate a script for executing the scenario using the item values set in the setting sheet. And outputting a test control file including the setting sheet and the script in order to cause the test execution unit to execute a test operation in the host system.

  According to the present invention, a test can be efficiently performed on a test target system.

FIG. 1 is a system schematic diagram of the embodiment. FIG. 4 is an explanatory diagram of a processing procedure according to the embodiment. It is an explanatory view of the processing procedure of this embodiment, (a) is a handover, (b) is an explanatory view of scenario generation processing. It is explanatory drawing of the screen used by this embodiment, (a) is an explanatory view of the scenario generation screen before input, (b) is an explanatory view of the scenario generation screen after input. It is explanatory drawing of the screen used by this embodiment, (a) is an explanatory view of the takeover setting screen before input, (b) is an explanatory view of the takeover setting screen after input. FIG. 4 is an explanatory diagram of a processing procedure according to the embodiment. Explanatory drawing of the processing procedure of other embodiment.

  Hereinafter, an embodiment of a test support system will be described with reference to FIGS. Here, the operation using the screen output to the client terminal is automated, and the test of the test target system is performed. In the present embodiment, it is assumed that a test of an operation in a host system (including a network) connected to a client terminal is performed.

  The host system 10 is a computer system that provides services to users. In the present embodiment, the host system 10 provides various services based on customer information.

As shown in FIG. 1, in this embodiment, an evaluation terminal 20 and a scenario generation terminal 30 connected to a host system 10 are used.
The evaluation terminal 20 is a computer terminal for evaluating the test target system. The evaluation terminal 20 includes a control unit 21, a test data storage unit 22, and a test log storage unit 23.

  The control unit 21 includes control means (CPU, RAM, ROM, and the like), and performs processes (described below, such as a test execution stage and a verification stage). The control unit 21 functions as a test execution unit 211 and a verification unit 212 by executing an evaluation program for that purpose.

The test execution unit 211 executes a test process of the test target system using the test cases recorded in the test data storage unit 22. Further, the test execution unit 211 holds an authority table for specifying necessary authority of the approver according to the response message.
The verification unit 212 outputs a result obtained by comparing the content obtained by the test execution with the expected value.

  The test data storage unit 22 stores test data of each test case used when executing a test. This test data is recorded when each test case is registered. In the test data, a test control file (script, data table sheet) is recorded for a screen number used in each test case.

  The script is a program for executing a test of each test case. The script includes a description for performing an input operation of each item value recorded on the data table sheet on a screen output by the host system 10.

In the data table sheet, data on item values and expected values in each test case used at the time of testing is recorded.
The test log storage unit 23 records a test log record regarding a history of operations and operations at the time of the test. This test log record is recorded when the test processing is executed. In the test log record, data on the log is recorded for the test case name.

In the test case name data area, data on an identifier for specifying a test case is recorded.
In the log data area, screen data, print data, and data on item values are recorded for the screen number of the image acquired by executing the test case.

  The scenario generation terminal 30 is a computer terminal for generating test data used for a test. The scenario generation terminal 30 includes a control unit 31, a design document storage unit 32, and a test case storage unit 33.

The control unit 31 includes control means (CPU, RAM, ROM, and the like), and performs processes (to be described later, such as a scenario generation stage). By executing the test support program for that purpose, the control unit 21 functions as the scenario generation unit 311.
The scenario generation unit 311 performs a process of generating a test case used in a test scenario based on the design document.

  The design document storage unit 32 records a screen definition material file of an output screen output to the client terminal. This screen definition material file is recorded when screen definition information of a screen to be output on the client terminal is registered.

  In the screen definition material file, information on the screen layout for the screen number is recorded. The screen includes a request screen for inputting a request message to the host system 10 at the client terminal, a response screen for outputting a response message acquired from the host system 10, and the like.

In the screen number data area, data relating to an identifier for specifying each screen is recorded.
In the screen layout, input items to be input on this screen, items included in this screen, and arrangement of operation keys (buttons) are recorded.

  Further, in the screen definition material file, complementary information for the screen number is recorded. This complementary information is information that complements the screen definition in relation to this screen.

  Test management data for evaluating the test target system is recorded in the test case storage unit 33. The test management data is recorded when executing the scenario generation processing. In this test management data, a test case name, a screen number, item information, and expected information are recorded.

In the test case name data area, data on an identifier for specifying each test case is recorded.
In the screen number data area, data relating to an identifier for specifying a screen used in this test case is recorded.

In the item information data area, data relating to item values set for items included in this screen is recorded.
When a screen is output, a bitmap of the screen expected to be output and data on the item value (expected value) of each item included in the screen are recorded in the expected information data area. When a printed matter is output, data on the arrangement of items in the printed matter expected to be output and the item value (expected value) of each item is recorded.
Further, in the test management data, approvable authority information (ID, password) is set in order to correspond to a transaction (management transaction) requiring approval of a predetermined authority.

  Further, the evaluation terminal 20 and the scenario generation terminal 30 are connected to input units 20a and 30a and output units 20b and 30b, respectively. The input units 20a and 30a are used for inputting various information such as a keyboard and a pointing device. The output units 20b and 30b are used to output various information such as a display and a printer.

(Overview)
The outline of the test support method will be described with reference to FIG.
In the present embodiment, the scenario generation unit 311 of the scenario generation terminal 30 creates a scenario data table sheet using the screen definition material file recorded in the design document storage unit 32. In this scenario data table sheet, screen numbers, items, and operation keys of screens used for the test are set.

  Then, in the scenario data table sheet displayed on the output unit 30b, each item value (input value) used for the test is input for each test case using the input unit 30a. Then, the scenario data table sheet in which each input value and each operation key is input is input to the scenario generation unit 311.

  In this case, the scenario generation unit 311 generates a script and a data table sheet for performing a test. Next, the generated script and data table sheet are input to the test execution unit 211 of the evaluation terminal 20 using the input unit 20a.

  In this case, the test execution unit 211 of the evaluation terminal 20 executes a test of the host system 10 using the generated script and the data table sheet. Then, the test execution unit 211 records the information output by the test in the test log storage unit 23.

  Next, the verification unit 212 generates an evaluation result by comparing the test output information recorded in the test log storage unit 23 with the expected value recorded in the test data storage unit 22, and outputs the result to the output unit 20b.

(Test support processing)
Next, test support processing (scenario generation processing, test processing) in the evaluation terminal 20 will be described with reference to FIGS.

(Scenario generation processing)
First, the scenario generation processing will be described with reference to FIGS. Here, a scenario in which the screens used for the test are specified in order is generated. In this case, it is assumed that the item values generated by the processing on the preceding screen are used in the processing on the subsequent screen.

  For example, as shown in FIG. 3A, a customer identifier generated by customer registration is used when registering detailed information. In this case, a scenario is generated in which processing using the detailed registration screen is performed after processing using the customer registration screen. First, the host system 10 generates a customer identifier based on the customer registration screen 400. Then, the evaluation terminal 20 specifies the generated customer identifier in the screen data acquired from the host system 10 and uses the specified customer identifier on the detailed registration screen 410. Here, an example will be described in which the inherited information is specified in the screen data acquired from the host system 10. However, the inherited information may be identified in the print data acquired from the host system 10.

Next, the scenario generation processing will be described with reference to FIG.
First, the control unit 31 of the scenario generation terminal 30 executes a screen designation process according to a scenario (Step S1-1). Specifically, the scenario generation unit 311 of the control unit 31 outputs a scenario generation screen to the output unit 30b.

As shown in FIG. 4A, the scenario generation screen 500 includes a scenario name input field 501, a screen transition list display field 502, and a screen transition input field 503.
The scenario name input field 501 includes an input field for setting an identifier for specifying this scenario.

  The screen transition list display column 502 displays a list of screens specified for use in the scenario. The screen transition list display field includes a screen number, a screen name, a key press, an evidence, an item value takeover field, a change field, and a delete field, which are set in a screen transition input field 503 described later with respect to the serial number. Further, for each screen, a change column (upward button, down button) is displayed in the change column, and a delete button is displayed in the delete column. The advance button is an operation button used to advance the order of the target screen in the scenario, and the advance button is an operation button used to advance the order of the target screen in the scenario. The delete button is an operation button used to delete the target screen from the scenario.

The screen transition input column 503 is provided with a screen number input column, an operation key designation column, an evidence column, a key press column (no screen transition), and a key press column (screen transition exists).
In the screen number input field, the screen number of the screen used in the scenario is input. Here, a screen recorded in the design document storage unit 32 is specified.

The operation key specification field is a field for specifying an operation key for transmitting a message, which is arranged on this screen.
In the evidence field, a field for specifying a test log output method candidate (for example, “do not print”, “output screen copy”, and “output verification data”) is displayed together with a selection field.

In the key press column (no screen transition), key candidates to be selected on the screen when there is no screen transition are displayed together with the selection column.
In the key press column (with screen transition), key candidates to be selected on the screen when there is a screen transition are displayed together with the selection column.

Further, the scenario generation screen 500 is provided with a line addition button, a clear button, and a read button from an existing scenario.
The row addition button is selected when the input in the screen transition input field 503 is completed. In this case, the scenario generation unit 311 adds the information input to the screen transition input field 503 to the screen transition list display field 502.

The clear button is an operation button used to reset the contents of the screen transition list display column 502.
The read button from the existing scenario is an operation button used when a scenario (existing scenario) registered in the test case storage unit 33 is called and used.

  As shown in FIG. 4B, in the scenario, after setting the screens of the serial numbers “1” and “2”, set the operation of the screen number “3010” in the screen transition input column 503 and select the line addition button. In this case, a screen column 511 is added to the screen transition list display column 502.

  Next, as shown in FIG. 3B, the control unit 31 of the scenario generation terminal 30 executes a process of selecting a takeover destination screen (step S1-2). Specifically, when the information included in the preceding screen (preceding information) is to be transferred to the succeeding screen (succeeding information) in the screen number displayed in the screen transition list display field 502, the unset button in the item value transfer field is clicked. select. In this case, the scenario generation unit 311 of the control unit 31 specifies a screen that inherits information by selecting an unset button.

  Next, the control unit 31 of the scenario generation terminal 30 executes a process of selecting a takeover source (step S1-3). Specifically, the scenario generation unit 311 of the control unit 31 outputs a takeover setting screen to the output unit 30b.

  As shown in FIG. 5A, the takeover setting screen 520 includes a takeover input list column 521 and a takeover input column 522. Information (input pattern, item, takeover source) set in a takeover input field 522 described later is displayed in the takeover input list field 521. Further, the takeover input list field 521 includes a delete button for deleting each set takeover input.

The takeover input field 522 includes fields for an input pattern, an input destination screen, an input destination item, a takeover source screen, and a takeover source item.
In the input pattern field, one of “screen item inheritance”, “print item inheritance” and the like can be selected. "Screen item takeover" is used to take over the item values of the items included in the screen. The “print item takeover” is used to take over the value of the position specified in the print data for the item included in the printed matter printed on the takeover source screen.

In the input destination screen column, the screen specified in the screen transition list display column 502 is set as the input destination screen.
In the input destination item field, the items included in the screen data of the input destination screen are obtained from the design document storage unit 32, output as selection candidates, and the items selected from the selection candidates are set as input destination screen items. I do.

  In the takeover source screen field, the preceding screen set in the screen transition list display field 502 is displayed in a pull-down manner with respect to the input destination screen. Using this pull-down display, a desired takeover source screen is designated.

  When "screen item takeover" is selected, the items included in the screen data of the selected takeover source screen are output as selection candidates. Then, the item selected from the selection candidates is set in the takeover source item column.

  When "takeover of print items" is selected, a print data setting column is displayed. In the print data setting field, the character string layout included in the print data of the printed matter is pasted on the selected takeover source screen. Then, the item arrangement (for example, start line, start character column position, number of character columns) of the character string specified in the character string layout pasted in the print data setting column is set in the takeover source item column.

Further, the takeover setting screen 520 is provided with a line addition button and a clear button.
The row addition button is selected when the input in the handover input field 522 is completed. In this case, the scenario generation unit 311 adds the information input to the takeover input column 522 to the takeover input list column 521.

The clear button is selected when resetting the contents of the takeover input list field 521.
In this case, as shown in FIG. 5B, in the handover input field 522, the "customer identifier" of the "customer identifier opening" screen is set as the handover source information, and the "customer registration" screen is set as the input destination information. When the "Add row" button is selected, the takeover setting 531 is added to the takeover input list field 521.

  In this case, the scenario generation unit 311 changes the unset button to the set button in the item value takeover information column for the screen number displayed in the screen transition list display column 502 shown in FIG.

  Next, the control unit 31 of the scenario generation terminal 30 executes a scenario output process (Step S1-4). Specifically, when each setting is completed, a scenario output button in the scenario name input field 501 shown in FIG. 4B is selected. In this case, the scenario generation unit 311 of the control unit 31 outputs a tabular data table sheet to the output unit 30b. In the data table sheet, items included in each screen constituting the scenario are arranged. Further, the data table sheet includes a sheet for setting a user ID and a password used for management transactions. The authority of each user can be specified based on the user ID and the password.

  Then, the person in charge sets values in the data table sheet (step S1-5). Specifically, for the items set in the data table sheet, the item values used for the test are input using the input unit 30a.

  Next, the control unit 31 of the scenario generation terminal 30 executes a reading process of the data table sheet for which the value has been set (step S1-6). Specifically, the scenario generation unit 311 of the control unit 31 reads a data table sheet in which item values are set.

  Next, the control unit 31 of the scenario generation terminal 30 executes a script generation process (Step S1-7). Specifically, the scenario generation unit 311 of the control unit 31 generates a script including a description for performing an input operation of each item value recorded on the data table sheet on the screen configuring the scenario. When the takeover input is selected, the script includes a description for setting the item value of the takeover source item on the takeover source screen in the input destination item on the input destination screen. Further, the scenario generation unit 311 controls the execution of the test case using the item values set in the data table sheet in this script.

(Test processing)
Next, the test processing will be described with reference to FIG. Here, the script and data table sheet generated by the scenario generation terminal 30 are read by the evaluation terminal 20 and recorded in the test data storage unit 22.

  First, the control unit 21 of the evaluation terminal 20 executes a test case calling process (Step S2-1). Specifically, the test execution unit 211 of the control unit 21 sequentially specifies the test cases recorded in the test data storage unit 22.

  Next, the control unit 21 of the evaluation terminal 20 executes a message transmission process (Step S2-2). Specifically, the test execution unit 211 of the control unit 21 creates a request message generated by an operation of setting an item value set in the data table sheet by a setting operation using a screen of a screen number by a script. I do. In this setting operation, the item values set in the data table sheet are set on the screen of the screen number set in the test case. Here, when the takeover input is set in the test data storage unit 22 with this screen as the input destination screen, the test execution unit 211 specifies the takeover source screen in the test log storage unit 23. Then, the test execution unit 211 acquires the item value of the takeover source item on the takeover source screen, and sets the acquired value in the input destination screen and the input destination item. When the takeover source is a printed matter, the test execution unit 211 acquires the item value in the item arrangement specified in the scenario generation process from the print data recorded in the test log storage unit 23, and sets the acquired item value in the request message. Then, the test execution unit 211 transmits the created request message to the host system 10.

  Next, the control unit 21 of the evaluation terminal 20 executes a test result recording process (Step S2-3). Specifically, the test execution unit 211 of the control unit 21 acquires a response message from the host system 10. In this case, the test execution unit 211 generates a test log record in which a test case name and a test result (contents of a response message) are recorded, and records this in the test log storage unit 23.

  Next, the control unit 21 of the evaluation terminal 20 executes a determination process as to whether or not approval is required (Step S2-4). Specifically, the test execution unit 211 of the control unit 21 determines that approval is necessary when the response message includes information on the management transaction.

When it is determined that approval is required (in the case of “YES” in step S2-4), the control unit 21 of the evaluation terminal 20 executes a management transaction corresponding process.
Here, the control unit 21 of the evaluation terminal 20 executes a determination process of the approval authority (Step S2-5). Specifically, the test execution unit 211 of the control unit 21 specifies the necessary authority of the approver according to the response message using the authority table.

  Next, the control unit 21 of the evaluation terminal 20 executes an output log recording process (Step S2-6). Specifically, the test execution unit 211 of the control unit 21 generates a test log record related to the output of the approval screen, and records it in the test log storage unit 23.

  Next, the control unit 21 of the evaluation terminal 20 performs a determination process as to whether or not the user has the approval authority (step S2-7). Specifically, the test execution unit 211 of the control unit 21 specifies the user authority based on the user ID and the password recorded on the data table sheet. Then, the test execution unit 211 compares the authority of the approver specified according to the response message with the user authority. If the user authority is equal to or higher than the authority of the approver, it is determined that the user has the approval authority.

  When it is determined that the user has the approval authority (“YES” in step S2-7), the control unit 21 of the evaluation terminal 20 executes an approved process (step S2-8). Specifically, the test execution unit 211 of the control unit 21 generates a test log record in which “approved” is recorded, and records it in the test log storage unit 23.

  On the other hand, when it is determined that the user does not have the approval authority (“NO” in step S2-7), the control unit 21 of the evaluation terminal 20 executes a warning process (step S2-9). Specifically, the test execution unit 211 of the control unit 21 generates a test log record in which a warning is recorded, and records the generated test log record in the test log storage unit 23.

  Next, the control unit 21 of the evaluation terminal 20 executes a determination process as to whether or not the test has been completed (Step S2-10). Specifically, when there is no unexecuted test case in the test data storage unit 22, the test execution unit 211 of the control unit 21 determines that the test has been completed. When it is determined that the approval is unnecessary (in the case of “NO” in step S2-4), step S2-10 is also executed.

When it is determined that the test has not been completed (NO in step S2-10), the control unit 21 of the evaluation terminal 20 returns to the test case calling process (step S2-1).
On the other hand, if it is determined that the test is to be ended (“YES” in step S2-10), control unit 21 of evaluation terminal 20 ends the test processing.

As described above, according to the present embodiment, the following effects can be obtained.
(1) According to the present embodiment, the control unit 31 of the scenario generation terminal 30 executes a screen designation process according to a scenario (step S1-1). Thereby, a test scenario including a screen used for a test can be created.

  (2) According to the present embodiment, the control unit 31 of the scenario generation terminal 30 executes a process of selecting a takeover destination screen (step S1-2). Thus, when different procedures are performed successively, a test can be performed using the information obtained in the preceding procedure in the subsequent procedure.

  (3) According to the present embodiment, the control unit 31 of the scenario generation terminal 30 executes a scenario output process (Step S1-4). Thus, the item values used in the test scenario can be set efficiently using the table sheet.

  (4) According to the present embodiment, the control unit 31 of the scenario generation terminal 30 executes a script generation process (Step S1-7). Thereby, a program for executing a test in the evaluation terminal 20 can be generated.

  (5) According to the present embodiment, the control unit 21 of the evaluation terminal 20 performs a test case calling process (Step S2-1), a message transmission process (Step S2-2), and a test result recording process (Step S2-). Execute 3). As a result, the test can be efficiently performed by using the script and omitting the input operation during the test.

  (6) According to the present embodiment, the control unit 21 of the evaluation terminal 20 executes a determination process as to whether approval is necessary (Step S2-4). Then, when it is determined that approval is required (in the case of “YES” in step S2-4), the control unit 21 of the evaluation terminal 20 executes a management transaction corresponding process. As a result, a test in a management transaction requiring approval can be performed.

This embodiment can be implemented with the following modifications. The present embodiment and the following modifications can be implemented in combination with each other within a technically consistent range.
In the above embodiment, the control unit 21 of the evaluation terminal 20 executes a test case calling process (Step S2-1) and a test result recording process (Step S2-3). Here, the test process may be executed while determining whether or not the test result is appropriate. In this case, the evaluation terminal 20 holds an error handling table for determining whether or not an error handling is possible. The error correspondence table records a recovery process necessary for dealing with the error in association with the screen number and the error message for the error that can be handled. For example, if the item values are insufficiently set in the attribute items that are not directly related to the transaction on the transaction input screen, it is possible to respond to an error. Insufficient setting of item value "is set. Then, in association with the screen number and the error message, the “item value setting operation” is recorded as the recovery process.

The test process will be described with reference to FIG.
Also in this case, the control unit 21 of the evaluation terminal 20 performs the test case calling process (step S3-1), the message transmission process (step S3-2), and the test result The recording process (step S3-3) is executed.

  Next, the control unit 21 of the evaluation terminal 20 performs a determination process as to whether or not there is an error (step S3-4). Specifically, the test execution unit 211 of the control unit 21 compares the output result of the test case with the expected value and determines whether or not they match. Here, if they do not match, it is determined that an error has occurred.

  When it is determined that there is no error (in the case of “NO” in step S3-4), the control unit 21 of the evaluation terminal 20 executes a determination process as to whether or not approval is required as in step S2-4 (step S2-4). S3-5).

  On the other hand, when it is determined that an error has occurred (in the case of “YES” in step S3-4), the control unit 21 of the evaluation terminal 20 executes a determination process as to whether or not an error response is necessary (step S3-6). Specifically, the test execution unit 211 of the control unit 21 checks whether the screen number and the error message are recorded in the error correspondence table. When the screen number and the error message are recorded in the error handling table, it is determined that the error handling is possible.

  When it is determined that error handling is necessary (in the case of “YES” in step S3-6), the control unit 21 of the evaluation terminal 20 executes a recovery process according to the screen and the error (step S3-7). Specifically, the test execution unit 211 of the control unit 21 acquires a recovery process corresponding to the screen number and the error message from the error correspondence table, and executes the recovery process. For example, if the setting of the item value is insufficient, a recovery process for setting the item value in the attribute item is executed. Then, the test execution unit 211 records a log related to the “recovery process” in the test log storage unit 23.

Then, the control unit 21 of the evaluation terminal 20 repeats the processing from step S3-1 on for the test case on which the recovery processing has been performed.
On the other hand, when it is determined that the error handling is unnecessary (in the case of “NO” in step S3-6), the control unit 21 of the evaluation terminal 20 executes a determination process as to whether the test interruption is necessary (step S3-8). ). Specifically, the test execution unit 211 of the control unit 21 determines that interruption is necessary for a screen number and an error message that are not recorded in the error correspondence table.

  When it is determined that the test needs to be interrupted (in the case of “YES” in step S3-8), the control unit 21 of the evaluation terminal 20 executes an alerting process (step S3-9). Specifically, the test execution unit 211 of the control unit 21 outputs the alert screen to the output unit 20b, and interrupts the test. This alert screen includes a screen number and an error message.

  Next, the control unit 21 of the evaluation terminal 20 performs a determination process as to whether or not to continue the test (Step S3-10). Specifically, the person in charge checks the screen number of the alert screen and the error message, and determines whether to stop or continue the test. Then, the test execution unit 211 of the control unit 21 acquires either the stop or the continuation instruction input on the alert screen.

  When a continuation instruction is input to the alert screen and it is determined that the test is to be continued (in the case of “YES” in step S3-10), the control unit 21 of the evaluation terminal 20 determines whether or not the test has been completed, as in step S2-10. Is determined (step S3-11). If it is determined that the test has not been completed, a continuation instruction is recorded in the test log storage unit 23, and the processing from step S3-1 is repeated. It should be noted that the management transaction corresponding process is executed after it is determined that approval is not required (in the case of “NO” in step S3-5) or when it is determined that approval is required (in the case of “YES” in step S3-5). Thereafter, a determination process as to whether or not the test has been completed is executed (step S3-11).

If it is determined that the test is not to be ended (if “NO” in step S3-11), the control unit 21 of the evaluation terminal 20 returns to the test case calling process (step S3-1).
On the other hand, when a stop instruction is input to the alert screen and it is determined that the test is not to be continued (“NO” in step S3-10), or when it is determined that the test is to be terminated (“YES” in step S3-11). Case), the control unit 21 of the evaluation terminal 20 ends the test processing.
As a result, the test can be continued or interrupted according to the error that occurred during the test.

  In the above embodiment, the control unit 21 of the evaluation terminal 20 executes a message transmission process (Step S2-2) and a test result recording process (Step S2-3). Here, when an error occurs, an error on the server side or an error on the terminal (evaluation terminal 20) side may be identified, and the response may be changed. In this case, the control unit 21 of the evaluation terminal 20 holds an error identification table for identifying a server-side error and a terminal-side error in association with the error message acquired by the evaluation terminal 20. Then, recovery processing is performed according to the location where the error has occurred.

  In the above-described embodiment, when “print item inheritance” is selected as the input pattern on the inheritance setting screen 520, the character string layout included in the print data used for printing the printed matter is pasted in the print data setting column. Here, a character string layout used for printing may be prepared in advance. In this case, the scenario generation terminal 30 is provided with a print pattern information storage unit. In the print pattern information storage unit, a print pattern management record relating to print data of a printed material output in the test is recorded. This print pattern management record is recorded when a print pattern of a printed material output in the test is registered. In the print management record, data on the print layout is recorded in association with the print target.

In the print target data area, data relating to an identifier for specifying the type of printed matter is recorded.
In the print layout data area, data on a character string layout (line, column, etc.) on which an item value is printed is recorded for each item included in the printed matter to be printed.

  Then, in the takeover source selection process (step S1-3), the character string layout of the printed matter printed on the designated input destination screen is displayed in the print data setting column. Thereby, the character string of the takeover source can be efficiently specified.

  In the above embodiment, the evaluation terminal 20 and the scenario generation terminal 30 are used. The hardware configuration is not limited to this. For example, the evaluation terminal 20 and the scenario generation terminal 30 may be configured by one piece of hardware. Further, the verification unit 212 may be provided in the scenario generation terminal 30. In this case, the test log recorded in the test log storage unit 23 of the evaluation terminal 20 is transferred to the scenario generation terminal 30. Then, the scenario generation terminal 30 compares the content obtained by the test execution with the expected value recorded in the test data storage unit 22.

  In the above embodiment, the control unit 31 of the scenario generation terminal 30 executes a scenario generation process. Here, every time the screen definition file is changed, the screen definition file may be registered in the design document storage unit 32 and a test may be executed. In this case, the same screen number, item, and operation key are set in the changed screen definition file, and the script or data table sheet generated before the change is used. With a general mechanism that creates an automatic execution script and automates the test, if the screen definition is changed, the maintenance of the script will be burdensome. In the above embodiment, a script or a data table sheet is generated using the scenario data table sheet in which the screen number, item, and operation key of the screen used for the test are set. Therefore, the test is performed using the same script as it is. be able to.

Reference Signs List 10 host system, 20 evaluation terminal, 21 control unit, 211 test execution unit, 212 verification unit, 22 test data storage unit, 23 test log storage unit, 30 scenario generation terminal, 31 control unit Numeral 311: Scenario generation unit, 32: Design document storage unit, 33: Test case storage unit, 20a, 30a: Input unit, 20b, 30b: Output unit.

Claims (7)

A design document storage unit in which screen definition information is recorded,
A control unit that generates a scenario for performing a test using the screen definition information;
A test support system comprising: a test execution unit connected to the host system;
The control unit includes:
Generate a scenario consisting of a plurality of screens specified in order using the screen definition information recorded in the design document storage unit,
From the screen definition information of the screens constituting the scenario, specify the input items and output items of the screen,
In the scenario, specify a preceding screen and a succeeding screen obtained from the host system,
Specify the takeover destination item in the input items included in the subsequent screen,
In the output items included in the preceding screen, specify the takeover source item,
Output a setting sheet for setting item values to the input items,
Using the item values set in the setting sheet, in order to execute the scenario, generate a script for inputting the item value of the takeover source item to the takeover destination item, and execute the test execution unit in the host system. A test control file including the setting sheet and the script in order to execute a test operation according to (1). Test support system according to claim 1, characterized in that to obtain the item value of the takeover source fields, from the screen data of the preceding screen acquired from the host system. Test support system according to claim 1 or 2, characterized in that to obtain the item value of the takeover source fields, from the print data associated with the prior screen acquired from the host system. The control unit includes:
Using the screen definition information recorded in the design document storage unit, to specify the items included in the screen constituting the scenario,
The test support system according to any one of claims 1 to 3, wherein a script for executing a specified operation for the specified item is generated. The control unit includes:
Holds an error handling table for determining whether error handling is possible for the screen,
If it is determined that the screen is an error , using the error correspondence table , based on the error, determine whether the test can be continued,
If it is determined that the test can be continued, record the error output log and continue the test.
The test support system according to any one of claims 1 to 4 , wherein the test is interrupted when it is determined that the test cannot be continued. A design document storage unit in which screen definition information is recorded,
A control unit that generates a scenario for performing a test using the screen definition information;
A method for supporting a test using a test support system including a test execution unit connected to a host system,
The control unit includes:
Generate a scenario consisting of a plurality of screens specified in order using the screen definition information recorded in the design document storage unit,
From the screen definition information of the screens constituting the scenario, specify the input items and output items of the screen,
In the scenario, specify a preceding screen and a succeeding screen obtained from the host system,
Specify the takeover destination item in the input items included in the subsequent screen,
In the output items included in the preceding screen, specify the takeover source item,
Output a setting sheet for setting item values to the input items,
Using the item values set in the setting sheet, to execute the scenario, generate a script for inputting the item value of the takeover source item to the takeover destination item, and execute the test execution unit in the host system. And outputting a test control file including the setting sheet and the script in order to execute a test operation according to (1). A design document storage unit in which screen definition information is recorded,
A control unit that generates a scenario for performing a test using the screen definition information;
A test support system including a test execution unit connected to a host system, the program supporting a test,
The control unit,
Generate a scenario consisting of a plurality of screens specified in order using the screen definition information recorded in the design document storage unit,
From the screen definition information of the screen constituting the scenario, specify the input items and output items of the screen,
In the scenario, specify a preceding screen and a succeeding screen obtained from the host system,
Specify the takeover destination item in the input items included in the subsequent screen,
In the output items included in the preceding screen, specify the takeover source item,
Output a setting sheet for setting item values to the input items,
Using the item values set in the setting sheet, to execute the scenario, generate a script for inputting the item value of the takeover source item to the takeover destination item, and execute the test execution unit in the host system. A test support program that functions as a unit that outputs a test control file including the setting sheet and the script in order to execute a test operation according to (1).

Images