JPS646468B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to a digital data display system capable of displaying both alphanumeric and graphic data.
The present invention is based on the system described in European patent application no. It has applications in systems such as

One problem associated with data processing systems is
It is rigorous testing to ensure that the system operates within its design parameters. The most common testing method is to use test programs that test specific aspects of the system. It takes two to four weeks to write one test program by hand, and the number of test programs that test one system is on the order of 1,000, making it suitable for testing large systems. Creating test programs manually
It turns out that it requires a lot of effort.

British patents 1479122 and 1510240 describe methods of operating a computer to create test programs.

In the test program writing method of GB 1479122, statements are generated on a weighted random basis and predictions are made about variable values that change during the operation of each statement. Programs created by this method are suitable for testing data computations and manipulations of compiler programs. British Patent No. 1510240 describes how to write a test program suitable for testing a compiler's ability to process input/output instructions.

When a compiler is tested, the results of running the test program are obtained as a series of error messages on the I/O terminal or as a printout from the printer. Analysis of such messages can provide an indication of failures in the system.

However, testing data display systems requires different methods. This is because errors in the system do not necessarily appear as error messages, but as erroneous data on the visual display unit.

The test program that is generated contains three different types of statements.

(a) Structural statements. For example, PROC,
END, error subroutine, butting
Grid subroutines, float compare subroutines, etc.

(b) Random Data Display System Statement.

(c) Mixed self-examination statements. Some of these may actually be data display system statements.

The main part of each test program is, of course, the random data display.
Consists of system statements. . For each random statement generated, the program generator must complete the following tasks:

(1) Generating statement text that is valid and executable without error.

(2) Predicting its execution and registering all important information in the generator's internal control blocks.

(3) Correct execution can be ultimately verified.

This third objective is the most difficult in the field of graphic testing. The reason is that most errors are displayed in the form of incorrect output to the display device during test program execution time.

In accordance with the present invention, a data display system is implemented in which a display of alphanumeric data and graphical data is assembled in a data processing device and displayed on a display terminal, and includes a test program generator. Ru. The above test program generator is
It generates programs and stores them, and its feature is that it has means for generating test programs. The program includes main (primary) data to be displayed and secondary (secondary) data, and the secondary data includes marker symbols. The marker signal is arranged to appear at a predetermined location with respect to the primary data on the display terminal, and if the marker symbol is not present at that predetermined location when the primary data is displayed, an error condition is signaled. .

Embodiments of the invention are described with reference to statements and commands used in the Graphical Data Display Manager (GDDM) and Presentation Graphics Facility (PGF) data display systems commercially available from IBM Corporation. For a complete understanding of the above systems and directives and statements, please refer to the
GDDM and PGF Overview (GC33-0100) and
Please refer to the GDDM User Guide (SC33-0101).

Broadly speaking, test programs are automatically generated according to the principles set out in the aforementioned British patent, with the addition of statements that output secondary information. There are two types of this secondary information.
When a test program is generated to test the alphanumeric capabilities of a digital data display system, some portion of the terminal output from the test program is "reverberated" into the test program itself. Therefore, it is automatically inspected. For example, the generated character field contains a special echo-inducing character "?" in a particular position along with a series of the same alphanumeric test characters. When this is displayed on the terminal, the user writes a test character, for example "Q", over the "?". The test program then issues a READ command and all modified contents of the terminal display screen are read back to the main processor. The test program then checks whether the expected number of fields were returned and whether all special characters were overwritten correctly. If not, a signal is generated indicating an error condition.

The second type of secondary information is used when the graphical capabilities of the digital display system are being tested. When the test program generator generates statements that define the occurrence of primitives (lines or arcs), it stores the predicted end points of each primitive. When the complete display is transferred to the terminal, special marker symbols are sent to the predicted primitive end points and displayed on the screen. Thus, it is possible to visually check whether all displayed primitives begin and end with a marker symbol and whether there are any marker symbols that are not attached to a line or arc. Additionally, all generated graphical elements can be visually inspected to see if they fall within a particular viewing window defined by the test program.

FIG. 1 shows the major stages involved in generating a test program. These stages are digital
Executed on the main processing unit of the data display system.
The generation-related process described above is called a test generator.

The generator includes four main processes:
Each of them is divided into many subordinate actions. Process 10 of FIG. 1 is for the user's first step to enter control information for a particular run into the digital display system. This control information includes weighting factors for the various instructions appearing in the test program, an indication of the total number of instructions in the test program, and the number of alphanumeric and graphic display blocks to be generated. The above control information is
Entered into the system from a terminal display, such as an IBM 3279 color display. Once the control information is entered, the next process 12 begins.

The operations of process 12 are to generate test program statements, predict the behavior of the statements and the values of variables, and store the text of the statements in a direct access file for later reordering. Details of the process will be explained later with reference to FIG.

Process 14 generates an output summary. This output summary contains details of the contents of the generated test program as comments in the test program. This includes the number of statements and blocks generated and the frequency of each type of statement or block. This summary can be accumulated and can represent the contents of a set of test programs.

In process 16, the generated test program is output and stored as a program on a disk file connected to the system so that it can be used to test the system.

FIG. 2 is a flowchart detailing the steps of process 12 in FIG. The first step 20 is to generate external procedure statements for the test program. This is standard for the particular programming language used. In PL/I this is next to the program name.
Generate PROCEDURE OPTIONS (MAIN). The next step 22 is to determine whether the next block of statements to be generated is for a graphical or alphanumeric display. This determination is made on a random basis with weighting determined by the input control information entered in process 10 of FIG. If the decision is to generate an alphanumeric block, step 24 is entered. If the decision is one that causes a graphic block, then
Enter stage 26. Step 24 will be described in detail below with reference to FIGS. 3 and 4. Step 26 will be described in detail below with reference to FIGS. 5 and 6.

When step 24 or 26 is completed, step 28 is entered. Step interval 28 is to determine whether enough blocks have been generated for a particular test program. The information for this decision is
Entered as part of process 10 of the figure. If the required number of blocks has not been generated, step 22 is entered again. If there are enough blocks, step 30 is entered.

Step 30 is to generate standard routines to handle the error and provide a frame for the picture to be displayed and a bucking grid for the graphical display. These routines are not necessarily generated for each test program, but the routines themselves are not random.

Step 32 is to generate an external procedure termination statement.

FIG. 3 illustrates the major steps in stage 24 of FIG. The primary purpose of the process of FIG. 3 is to generate statements that display certain characters along with alphanumeric data at the terminal. This character is specified by the user and is overwritten by typing on the keyboard or indicated by a light pen directed at the screen. All changed fields are sent to the test program and examined. If they are not correct, an error condition is signaled.

The first step 40 is to call the page creation subroutine. This routine provides the text of the page creation statement. This statement defines how many rows and columns in the generator should be used in pages or internal control blocks. Pages or internal control blocks are used to ensure that generated statements can be executed and are set to reflect the parameters described above.

The next step 41 is to call a subroutine that adds a random number of field declarations to the test program. This subroutine
It has the name FIELD DECLARE and is called at this point in the process. This is to ensure that there is always at least one valid field declaration when the statement is issued at any later time.

Step 42 is to determine whether the type of page created in step 40 allows character attribute statements. If not, step 43
If you agree, proceed to step 44.

Step 43 is to call a subroutine called SELECT to select one of all alphanumeric statements except those related to character attributes. Similarly, step 44 calls the SELECT subroutine to select one statement from among all alphanumeric statements. Step 45 calls the specific statement generation subroutine to generate the selected statement. The occurrence of different statements involves similar processes. FIG. 4 is an example of generating an alphanumeric PUT statement, which will be explained later.

The types of statements that may be generated in step 45 are shown in FIG. These are FIELD-DECLARE, MULTIPLE FIELD DECLARE, PUT DATA, SET CURSOR, and SET
DEFAULTS), set field attributes, set character attributes, and query statements. The principle for generating these statements is the same as for generating the PUT statement, which will be explained with reference to FIG.

Upon completion of step 45, step 46 is entered to determine whether sufficient statements have been generated. If it has not been generated, step 42 is entered again. If it has occurred, step 47
to go into. Step 47 goes to test program
By adding a READ statement,
Step 48 is to add check code to the test program to check whether all echo fields have arrived correctly.

FIG. 4 is a flowchart of the process of generating an alphanumeric PUT statement. The first step 50 is to enter the already defined alphanumeric field (step 41 in Figure 3).
The method is to randomly select one of the following.

If the field is numeric only, a decision is made at step 51 to enter step 52. Step 52 is to select a numeric test character. This character will eventually appear on the display screen, the user will overwrite it, and when the READ statement (step 47 in Figure 3) is executed, it will "reverberate".
returned by.

If the field has an attribute of "Immediate Light Pen", in step 53
A decision is made to enter 4. Step 54 sets the test character to the "#" symbol.

If the field falls within the type of "delayed light pen", the determination at step 55 causes step 56 to be entered. Step 56 sets the test character to the "!" symbol.

If the field is not of any of the above types, step 57 is entered. Step 57 is to select a random test character and then select the length of the data and the location in the field of the echo-inducing character.

Upon completion of steps 52, 54, 56 or 57,
Go to step 58. Step 58 assembles the text of the PUT statement and tests it.
It is an addition to the program. Step 59 then follows. Step 59 updates the test program generator's internal dictionary to enable efficient monitoring of the echoed data inspection.

FIG. 5 shows the major steps in step 26 of FIG. The first step 60 is to create the various parameters necessary to define the graphical display. These parameters are created by calling a series of subroutines.
The first one generates page creation parameters, which are the same as the page creation routines for alphanumeric processing. Other routines define the graphics field, picture space, viewports and windows to be used, and the segments in which the graphics picture is drawn.

The next step 61 determines whether the graphics area is being assembled. Always "no" for the first statement raised
Then, the process goes to step 62. Step 62 is
Determine which graphic statements should be generated. This is done on a weighted random generator basis. If it is determined in step 61 that the graphics area is assembled, step 63 is entered. There, you can select the available graphics within the graphics area.
Statement is selected.

After step 62 or 63 is completed, step 64 calls a routine that generates the selected statement. The generation of a typical arc (ARC) statement in the generation of primitives will be explained later with reference to FIG.

Other types of statements that can be called are shown in FIG. They are LINE,
These are MOVE, ELLIPSE, AREA, CHARACTER STRING, change attribute statement, and query statement. All of these are randomly selected, given weighting values based on the specific functionality being tested. The generation of each statement follows the ARC statement generation principle explained with reference to FIG.

When the statement is issued, step 65
is entered and it is determined whether the region is still assembled. If yes, step 66 is entered to determine if the region is complete. If completed, step 67 is entered and an end-of-region statement is added to the test program. If the decision at step 65 or 66 is "no", step 68 is entered. Even after step 67 is completed, step 68 is entered.

Step 68 determines whether enough statements have been generated. If it has not been generated, the process returns to step 61 again. If it has been generated, step 69 is entered. Step 69 is a process for closing the segment created in step 60. Then comes step 70. Step 70 adds a statement to the test program to send a marker to the endpoint of the predicted primitive. The next step 71 is to test
Add output statements to your program.

FIG. 6 is a flowchart of the process for generating an ARC statement. In a GDDM system, an "arc" is defined as a graph starting from a single point with a defined center point and sweeping through X degrees.
Therefore, the first step 80 is to select the center of the arc using a random number generator to provide a valid coordinate point. The second step 81 is to use a random number generator to select how many sweeps the arc should contain.

In order to provide a valid ARC statement, it is necessary to check that the defined arc does not go outside the window defined in step 60 of FIG. Steps 82-89 are associated with this check.

Step 82 initially sets X (the angle of sweep) to 10. Step 83 calculates the end points of the arc with a sweep of X degrees. Step 84 is
Calculate whether the end point is inside the window.
If no, step 85 reduces the value of X to a valid value. This is done by subtracting some randomly selected number from the current value of X. If the end point is within the window, step 86 determines whether X is equal to the sweep selected in step 81.

If X is equal to the selected sweep, steps 90 and 91 are entered. If not, step 87 adds 10 degrees to the X value. Step 88
determines whether X is greater than the selected sweep. If no, go to step 8 again.
Enter 3. If yes, step 8
Before reentering step 3, step 89 sets the value of X equal to the number selected in step 81.

Step 90 creates the text of the ARC statement and appends it to the test program. Step 91 adds the predicted endpoints to the endpoint array maintained in the test program generator.

When a primitive (line or arc) is generated, the test program generator adds the coordinates of the primitive's predicted end points to the array. These coordinates are used to generate end point marker symbols. The marker symbol described above is transferred to the display device by the statement immediately preceding the READ statement in the test program. All marker symbols must occur at the end points of the lines on the display. This can be visually inspected. A line without a marker symbol or a marker symbol not attached to a line indicates an error in the system.

FIG. 7 shows a typical graph test output as it appears on the display screen. Area 100 is the fifth
This is the window defined in step 60 of the figure. In this case, it is assumed that the subroutine initially selected in step 62 of FIG. 5 is the AREA subroutine. Subsequent primitives therefore limit the area. 101 is the starting point, and the first primitive drawn is an arc ending at point 102. The marker symbol illustrated with an asterisk is the point 1
Generated for 01 and 102. The second finite is the arc ending at 103. Since location 103 is adjacent to the edge of window 100, the arc definition may have required adjustment of the sweep angle. 2
One solid line connects points 103, 104, and 105, and one dash line connects points 105 and 106. After the dash line is generated, the region termination routine closes the region by joining points 106 and 101. Closed areas are shaded with the appropriate color.

Visually it can be checked whether the marker symbols appear in the correct place and whether any primitives are protruding out of the window. Furthermore, the shading of the area can be checked for excess or deficiency in color.

The mechanism for generating the end-of-line marker and checking whether the echo-inducing symbol has been modified correctly will now be described.

Each time a primitive is generated, the test program generator adds the X,Y coordinates of the end points to the array. When the graphics block is sent to the display terminal, a composite marker symbol is also sent to each of the predicted end points.
Each marker symbol has a "yellow" and "black" portion so that it is visible no matter what the background color is.

The generation of echogenic characters and their examination is rather complex. When an alphanumeric block is being generated, the test program generator maintains a dictionary for that block. Its entry is the starting row, starting column,
Contains field attributes such as width and depth. Since the number of data characters to be sent to the field is selected at random, the dictionary entry contains information indicating said number and which data characters are echo-inducing characters. . Therefore, if a field is of length 12, and seven alpha characters are to be entered into the field, and the fourth character is declared to be the echo-inducing character, then
The entry contains this information. Furthermore, the entry indicates whether the echo-inducing character should be overwritten or modified with a light pen.

When an alpha block is sent to a display device, the test program generator's dictionary has entries for all fields in that block. When the modified fields are returned from the display to the processor, the generated test program checks whether all fields sent with echo-inducing characters were correctly modified and returned to the test program. Tests to check for changes use the data held in the dictionary to determine the location of echogenic characters.

[Brief explanation of drawings]

1 is a flowchart showing the main process of generating a test program; FIG. 2 is a flowchart showing details of process 12 of FIG. 1; FIG. 3 is a flowchart showing details of step 24 of FIG. 2; The diagram shows alphanumeric symbols related to step 45 in Figure 3.
A flow diagram of the process that generates a PUT statement,
FIG. 5 is a flowchart detailing step 26 of FIG.
Figure 6 shows the ARC associated with step 64 in Figure 5.
Flowchart of the Process of Generating Statements, FIG. 7 is a diagram illustrating the display generated by a typical test program.

Claims (1)

[Scope of Claims] 1. In a digital data display system in which alphanumeric data and graphic data are created in a data processing device and displayed on a display terminal, main data representing the data to be displayed; a test generator that generates a test program including slave data for displaying a marker at a predetermined position of the main data when the data is correctly created in the data processing device and displayed on the display terminal; a digital data display system configured to indicate an error condition when the marker is not displayed at the predetermined position of the main data by execution of the test program.