JPS63257839A - Debug system for test program - Google Patents

Abstract

PURPOSE:To allow the titled system to simplify the simulate means and to cope with versatile peripheral equipment by effectively utilizing an expected value of a test program and allowing a pseudo fault information designation means to set the device status attended with an optional input/output operation. CONSTITUTION:When a console 82 is designated as an input source device of a pseudo fault data, a test program monitor 42 displays a pattern inquiring about an input/output routine desired to be an object onto the console 82. When a prescribed input is finished, a start number designated to a pseudo fault registration table is set to start the execution of a test program 41. Then a macroinstruction processing compares the input/output processing number of the input/output processing routine to be executed from now with all start numbers of the table and when no coincident number exists, it is processed there is no pseudo fault setting in the succeeding series of input/output operations and the expected value of the program 41 is used as an actual value. When the coincident number exists, a pseuso fault item to be set is inquired at each occasion of execution of instruction and when the required information is set, simulation is executed according to the information.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a debugging method for a test program for testing peripheral devices of an information processing system, and particularly to a debugging method using simulating means.

[Conventional technology]

-a. When a new program is developed, or when a new program is created by modifying an already developed program, whether or not the program achieves the intended purpose is checked. Debugging is performed to find out whether this is the case.

Such debugging is normally performed using a device used in the environment in which the program operates, if that device actually exists. However, it may be difficult to debug using an actual device due to reasons such as shortening the device development period or downsizing the debugging information processing system.

In such cases, simulation programs that simulate the target device are often developed and used, and these simulation programs can be broadly classified into the following types.

■ A method of linking a simulation program to a program running on the processing device where the program to be debugged is executed.

■ Operates on another processing device system B connected to processing device system 8 on which the program to be debugged is executed,
A method in which all input/output instructions from system A are executed to system B, and system B simulates the target device.

Regardless of the method used by the above-mentioned simulation program, in the past, in order to perform debugging with some degree of accuracy, the device to be simulated was accurately simulated, and therefore a huge number of steps were required.

[Problem that the invention seeks to solve]

By the way, in information processing systems, test programs are used to test peripheral devices.
Similar to debugging other types of programs, when debugging such test programs does not actually exist, a simulation program that simulates the functionality of the peripheral device to be tested is used. I was debugging it. For this reason, there is a problem in that it takes a lot of time to develop a simulation program, and it is difficult to quickly debug a test program. In addition, the peripheral devices that are tested by the test program have a wide variety of functions, and even if they are the same type of device, the functions vary depending on the model, so there is a problem that the simulation program to be developed will be miscellaneous. Ta. Furthermore, there is a problem in that the simulation program must be significantly modified every time a new peripheral device is developed.

The present invention solves these conventional problems, and its purpose is to provide a debugging method suitable for test programs for testing peripheral devices.

Means for Solving Problem c] In the test program debugging method of the present invention, each input/output processing routine is described by a plurality of macro instructions, and the parameter section of the macro instruction has an expected value of the test result, In a debugging method for a test program that tests a peripheral device by comparing an actual value obtained by testing the peripheral device with the expected value, each input/output processing routine making up the test program is assigned a unique input/output processing number. and a simulated failure information specifying means for specifying the input/output processing number of the input/output processing routine targeted for the simulated failure, information regarding the simulated failure including the simulated data, and a peripheral bag to be tested by the test program. simulating means for simulating U, and the simulating means detects a pseudo failure for each input/output processing routine to be executed when the test program requests a simulation operation. It is determined whether the input/output processing routine is specified or not according to the input/output processing number specified by the pseudo failure information specifying means, and for an input/output processing routine for which a pseudo failure is not specified, the macro instruction constituting the input/output processing routine is determined. The actual value is the expected value specified in the parameter section, and for an input/output processing routine in which a pseudo failure is specified, the pseudo data specified by the pseudo failure information designation means is used as the actual value.

[Principle and operation of the invention]

The test program debugging method of the present invention makes it possible to simplify the simulation means for simulating peripheral devices by effectively utilizing the characteristics of the test program, and also to cope with the simulation of a wide variety of peripheral devices. There is. That is, unlike other programs, the test program has an expected value of the input/output operation result of the peripheral device, and tests the peripheral device by comparing the expected value with the actual value. Therefore, when checking whether the program under test is correctly performing the operation corresponding to the expected actual value returned from the peripheral device, the means for simulating the peripheral device is It is not necessary to accurately simulate the operation of , it is sufficient to perform a simulation that returns the expected value as the actual value. This allows the simulation means to be simplified.

Also, when we assume that a failure has occurred in a peripheral device and check whether the test program will perform the appropriate operation normally, we can use a pseudo failure that is equivalent to a failure in the peripheral device. Rather than incorporating a mechanism for accurate simulation into the simulation means itself, the response content, that is, the pseudo data, from the peripheral device that matches the type of pseudo fault to be caused is used as pseudo fault information from an external floppy disk device, console, etc. If the designation means provides the pseudo data to the simulation means, and the simulation means performs a simulation using this pseudo data as the actual value from the surrounding NW, the simulation means can be simplified and can be used in a wide variety of ways. This means that simulation of peripheral devices can be easily realized. Furthermore, device states that cannot be easily set in a real device can be easily set.

〔Example〕

Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing an example of an information processing system to which the debugging method of the present invention is applied. This information processing system is connected to a central processing unit 2, a main storage device 4, a common bus 6, a peripheral control device 8, and a peripheral control device 8, and is subject to pseudo failures (hereinafter abbreviated as pseudo failures). It is composed of a floppy disk device 81 and a console 82, which implement an operator ink face for inputting and outputting startup numbers for instructing input/output processing routines, simulated failure data, and the like.

A test program 41 to be debugged and a test program monitor 42 are loaded into the main storage device 4 from a floppy disk device 81 .

The test program 41 includes a plurality of input/output processing routines, and each series of operations constituting each input/output processing routine is described by a macroinstruction, and the parameter portion of the macroinstruction has an expected value. Furthermore, each input/output processing routine is given an input/output processing number that can be uniquely identified within the test program 41. The test program monitor 42 includes a common processing unit 421 that controls the execution of the test program 41 and performs common processing corresponding to each macro instruction of the test program, and a mode recognition storage unit 422 that recognizes and stores simulation operation requests. an operator interface processing unit 423 that targets the console 82 or floppy disk device 81, etc. for setting pseudo failure;
It has an fA management unit 424, a process management unit 425, an input/output management unit 426, etc., and when a simulation operation is requested, the presence or absence of pseudo failure settings is checked for each input/output operation, and if there is no pseudo failure setting, The test program simulates the peripheral device operation expected by the test program using the macro instruction parameters of the test program, and for input/output operation requests that are set as false failures, the peripheral device status set by the console 82 or floppy disk device 81 is simulated. work to do. In FIG. 1, the magnetic disk control device 9 and the magnetic disk device 91 indicated by dotted lines are examples of peripheral devices to be tested by the test program 4I.
It is not needed because it is simulated by

In the input/output processing of the system of this embodiment, when the central processing unit 2 executes an input/output command, predetermined information including the partner channel number is output to the common bus 6, and the peripheral control device (peripheral The control device 8, magnetic disk control device 9, etc.) recognizes that the input/output command is for its own device, analyzes and executes the channel program recorded in a predetermined area of the main storage device 4, and determines the resulting completion status. After writing to a predetermined area of main memory 4,
It consists of a series of operations of generating an interrupt to the central processing unit 2, and the input/output processing routine of the test program 41 is naturally structured in accordance with this architecture.

FIG. 2 shows an example of the configuration of one input/output processing routine (test routine of the minimum test unit) in the test program 511, and FIG. 3 shows the parameter configuration of each macro instruction.

One input/output processing routine shown in Figure 2 is \DIRS
Macro instruction, \S[O macro instruction, \WiO macro instruction, \SCK macro instruction, \DCK macro instruction and \D
Consists of 2RE macro instructions. The \DIRS macro instruction initializes various control data for a series of input/output operations and controls the start of input/output operations.
The SIO macro instruction starts input/output operations for the peripheral device, performs error processing if an error occurs, and returns \WI
In the O macro instruction, wait while monitoring the end interrupt reported from the peripheral device by executing the \SIO macro instruction, and if there is no interrupt within the time, perform error processing,
The \SCK macro instruction compares the status information transferred from the peripheral device at the time of an interrupt with the expected value, and if there is an error, perform error processing according to the type of error, such as outputting a message to that effect, and perform input/output using the \DCK macro instruction. The data read out to the main memory 4 by the operation is compared with the expected value, and if they do not match, error handling is performed according to the content of the discrepancy, and the \D2RE macro instruction performs input/output operation termination processing and device repeat control. ,
The above process is repeated for the number of devices to be tested, and the test operation is completed. Furthermore, each input/output processing routine has a unique identification number within the test program (as described above).
input/output processing number).

Next, the configuration and operation of the test program monitor 42 will be explained.

The test program monitor 42 is the core of the test program system and has various functions necessary for the operation of the test program system, including resource management, input/output management, process management, and operator ink face processing. Further, most of the processing common to each test program is performed by the common processing unit 421 of the test program monitor 42, and the test program 41 only writes macro instructions. That is,
Looking at the \SIO macro instruction in the input/output processing routine in FIG. 3, the test program 41 defines the channel program contents and displays the \3
By simply transferring control to the common processing section 10, the common processing section 421 of the test program monitor 42 can now perform all the processing necessary to execute the C0NNECT command, which is an input/output command in the central processing unit 2. There is.

A debugging method according to the embodiment of the present invention using the test program 41 and test program monitor 42 described above will be described below.

First, the test program monitor 42 operates in the following operation mode:
It has a normal mode and a simulation mode.

The normal mode is an operation in an environment where a real device is connected, and the simulation mode is a mode when debugging the 8-type test program 41. Before the test program monitor 42 receives an instruction to load and execute the test program 41, the mode recognition storage unit 422 determines and stores the operating mode using an OCL command. Note that the method for determining the operation mode does not have to be limited to OCL (
This may be done using a switch or the like.

During simulation mode operation, when the operator instructs to load the test program 41 using the OCL, the test program monitor 42 analyzes the OCL, loads the test program 41 from the floppy disk device 81, and then
Before starting execution of the test program 41, the following processing is performed.

First, a menu screen is output to the console 82, and the operator is asked to specify the input source device for the simulated fault data.

When the operator specifies a pseudo fault data file consisting of the floppy disk device 81 as the input source device on the above menu screen, the test program monitor 42 continuously outputs the specified pseudo fault data file from the floppy disk device 81. A pseudo failure registration table shown in Figure 4 is generated.

That is, the simulated failure data file includes a startup number that instructs the input/output processing routine to be set as a simulated failure, a simulated failure item, and an end status.

1 Since the length of the suspected fault data, the relative position of the readout sofa, the read data, etc. are stored in advance, they are transferred to the pseudo fault registration table. Here, the startup number in the simulated fault registration table is the input/output processing routine that is desired to be simulated fault among the multiple input/output processing routines that make up the test program 41, and is specified by the input/output number assigned to it. It is. In addition, the pseudo-failure items include which items in the input/output processing routine (in Figure 3, ¥SIO, ¥WIO, ¥5-CK, ¥DC)
You can specify whether you want to cause a pseudo-failure for K) and specify multiple items at the same time. The exit status is ¥SC
This is pseudo-failure data of the completion status returned as an actual value in K. The simulated fault data length, read buffer relative position, and subsequent data are information that does not return as actual values in ¥DCK and identifies the simulated fault data.The continuous data is the data to replace the expected value, and the pseudo fault data length. represents the length of the successive data, and the relative read buffer position represents the position within the read buffer where the successive data is to be replaced, that is, the position within the expected value. Note that for input/output processing routines that do not set M faults, the activation number that is the same as the input/output processing number is not registered in the pseudo fault data file, and therefore does not exist in the pseudo fault registration table.

When the generation of the simulated failure registration table is completed, the test program monitor 42 displays the contents of the generated simulated failure registration table on the console 82 for confirmation. At this time, the operator deletes the contents of the false failure registration table.

It is possible to change or add new pseudo fault data.

When the operator confirms the contents of the simulated fault registration table displayed on the console 82 and gives a start instruction, the test program monitor 42 starts executing the test program 41. In the test program 41, each macro instruction is executed in sequence as shown in FIG. 3, but the processing corresponding to each macro instruction in the common processing unit 421 of the test program monitor 42 is, for example, shown in FIG. 5 (at, fbl).

As shown in (c). That is, in the \SIO macro command processing (FIG. 5(a)), it is determined that the simulation mode is in accordance with the information stored in the mode recognition storage section 422 in step Sl, and the test program 4 is executed in step S4.
The input/output processing number of the input/output processing routine to be executed from now on in step 1 is compared with all startup numbers in the pseudo fault registration table, and if there is no matching startup number, the following series of input/output operations will be considered as a pseudo fault. Processing is performed assuming that there is no setting (step S6).

At this time, the expected value of the test program 41 is used as the actual value. For example, when simulating the \SCK macro instruction, an expected value is obtained according to the parameter "expected status area name" in FIG. 3, and this is returned as an actual value.

Furthermore, if there is a startup number that fails once, the information from the simulated failure item in the corresponding row in the simulated failure registration table to the subsequent data is stored as current simulated failure data (step S5).

Then, in ¥WIO (Figure 5(b)), step SI
In step 513, the specification of the simulated failure item (time around day suspected failure item) of the current simulated failure data is determined, and if the simulated failure is set, the test program 41 If a false failure is not set, it is assumed that an interrupt occurred within the specified time and the process proceeds to the next step. In addition, in the processing of the \SCK and \DCK macro instructions (Fig. 5 (C)), it is determined in step S20 that the mode is simulation mode, and in step S22, the designation of the pseudo-failure item of the current pseudo-failure data is determined. However, if a pseudo fault is set for the corresponding item in each macro instruction, the pseudo fault data is used as the actual value (step 524); if not set, the expected value of the test program 41 is used as the actual value. (Step 523). Then, in step 321, the expected value and the actual value are compared,
Processing branches depending on the result. Note that when setting the pseudo fault data as the actual value, the expected value is used for the portion other than the actual value portion replaced by the pseudo fault data.

The operation when the floppy disk device 81 is specified as the input source device of pseudo failure data is as described above, but when the console 82 is specified, the following operation is performed.

First, the test program monitor 42 checks whether or not there is a pseudo failure setting.
If a simulated failure is to be set, a screen is displayed on the console 82 inquiring about the input/output processing routine to be targeted. When the operator sequentially inputs the number (starting number) of the input/output processing routine for which he wants to set a fault and instructs manual termination, the specified starting number is set in the pseudo fault registration table shown in FIG. 4, and the test program 41 is executed. Start. Then, in the \STO macro instruction processing (Fig. 5(a)), the test program 4
The input/output processing number of the input/output processing routine to be executed from now on in step 1 is compared with all startup numbers in the simulated fault registration table, and if there is no startup number to be decremented by 4, the following series of input/output operations will be simulated. It is assumed that there is no fault setting, and the expected value of the test program 41 is used as the actual value. In addition, if there is a matching startup number, one simulated failure item, end status, and simulated failure data length that can be set each time the series of macro instructions is executed.

Read buffer relative position, read data to console 8
Contact the operator via 2. If the operator sets the necessary information accordingly, the simulation will be executed according to that information. In this way, when the console 82 is specified as the input source device for the simulated fault data, the console 82
2, the simulation proceeds in an interactive manner with the operator. Note that if the console 82 is specified, the fourth
It is also possible to create the false fault registration table shown in the figure all at once, and in this case, the subsequent operation will be the same as when the floppy disk device 81 is used.

Further, when the normal mode is specified, the test program monitor 42 that realizes the simulation means of this embodiment has a fifth
As shown in the figure, it is necessary to determine that the mode is not simulated in the processing of each macro instruction (Sl, SIO, 520).
, execute input/output commands and handle errors according to each macro command (step 32.S3).

Waiting for interrupts and monitoring interrupts within time (step Sll)
, 512), comparison of expected value and actual value (step 5
21), and no simulation of peripheral devices is performed.

〔Effect of the invention〕

As explained above, the present invention makes effective use of the feature that the test program has an expected value of the input/output operation result for the peripheral device, and also allows the user to monitor any device status for any input/output operation on the console. By making it possible to specify false failure information such as a floppy disk drive or a floppy disk device, it is possible to simplify the means for simulating peripheral devices necessary for debugging test programs. There are effects that can be dealt with. Furthermore, there is an effect that the device status, which cannot be easily set in the actual device, can be easily set from the false failure information specifying means.

[Brief explanation of drawings]

FIG. 1 is a block diagram showing an example of an information processing system to which the debugging method of the present invention is applied, FIG. 2 is a diagram showing a configuration example of one input/output processing routine of the test program 41, and FIG. 3 is a block diagram showing each macro instruction. FIG. 4 is a diagram showing an example of the configuration of the pseudo failure registration table, and FIG. 5 is a flowchart of an example of processing by the common processing unit 421. In the figure, 2... central processing unit, 4... main storage device, 6... common bus, 8... peripheral control device, 9... magnetic disk control device 81... floppy disk device, 82...console, 91...magnetic disk device

Claims (1)

[Claims] Each input/output processing routine is described by a plurality of macro instructions, and has an expected value of a test result in the parameter section of the macro instruction, and the actual value obtained by testing the peripheral device and the expected value In a debugging method for a test program that tests the peripheral device by comparing it with a value, each input/output processing routine that makes up the test program is assigned a unique input/output processing number, and the input/output processing routine that is the target of the simulated failure is A simulated failure information specifying means for specifying information regarding a simulated failure including the input/output processing number of the output processing routine and simulated data, and a simulating means for simulating a peripheral device to be tested by the test program, The means specifies, for each input/output processing routine to be executed, whether or not a pseudo fault is specified for the input/output processing routine from the pseudo fault information specifying means when the test program requests a simulation operation. For input/output processing routines for which a pseudo failure is not specified, the expected value specified in the parameter part of the macro instruction constituting the input/output processing routine is set as the actual value; A method for debugging a test program, wherein for an input/output processing routine in which a pseudo fault is specified, pseudo data specified by the pseudo fault information designating means is used as the actual value.