PROGRAM TESTING

Generally speaking, each cQmputer prQgram written in symbQlic language is a hand-crafted part Qf a cQmputer system. It cannQt be assumed to. be CQrrect Qr reliable until it has been thQroughly tested. Depending UPQn the cQmplexity Qf the prQgram, it is usually desirable to. test each prQgram in IQgical subsectiQns. After the parts Qf a prQgram are fQund to. be individually accurate and wQrkable, they can then be cQmbined fQr a cQmpQsite test. VariQus aspects Qf testing UNIVAC 9200/9300 Disc System prQgrams are described belQw.

Generation of Test Data

The planning and preparatiQn Qt test data fQr each prQgram requires a significant amQunt Qf prQgrammer effQrt. It is desirable, therefQre, to. institute a system fQr the cQllectiQn Qf all test data into. a permanent systems test library. The CQst Qf future tests will thus be reduced and their cQmprehensiveness will be ensured. In a relatively shQrt periQd Qf time, the aggregate test library will prQvide a higher degree Qf accuracy fQr the system than CQuid be Qbtained if testing were limited to. currently prepared test cases.

One methQd Qf develQping test files is the piecemeal creatiQn Qf test cases by cQding and punching full data recQrds. The fields in these recQrds are as signed arbitrary values which meet the variQUS cQnditiQns fQr which the prQgram prQvides. BQth CQrrect and incQrrect data are included in such recQrds.

AnQther methQd is to. develQP a cQmputer prQgram which fabricates test recQrds Qn a logical Qr randQm basis. Such a prQgram, if develQped, shQuld be a generalized Qne. After it has been debugged, then, it can be used to. prQduce test data fQr many prQgrams.

Program Logic Test

It is recQmmended that each prQgrammer develQP a list Qf the cQnditiQns to. be tested during the preparatiQn Qf the flQwchart. This list shQuld be Qriented to. data file CQntent in a way that permits it to. be used by a clerical staff fQr prQducing the cQrresPQnding

The points at which storage dumps are to be taken, and the part of the program to be dumped, should be indicated on the flowchart. The means by which the storage dumps are to be iden-tified for printout and the Significance of each dump must also be considered.

Test Practices

While the compiling program is designed to continue its processing regardless of the errors in input data, problem programs are much more easily stalled. For this reason a program test demands more preparation effort on the part of the programmer. Following are some recommendations for achieving satisfactory test results.

Establish Test Schedules Ahead of Time

The operations staff should establish and maintain a system for scheduling computer usage.

This schedule should be es tabli shed for periods from several days to several weeks. It should be published well in advance of its actual use. A schedule coordinator should be appointed to obtain estimates of the dates test time will be needed and the amount of time to be allocated to each test. A procedure for cancelling or exchanging test periods should be established and responsibilities fixed for taking the initiative in altering the schedule.

Where possible, scheduled backup jobs and tests should be available for processing in the advent of last minute cancellations.

Have All Files Ready Before T€'st Time

The file containing the program, all input test files, and adequate output file media should be compiled prior to the test. The programmer should verify that everything is in readiness in advance of test time. Care should be exercised to avoid last minute changes in test objectives or tardy preparation c f the executable program.

Prepare a Documented Plan of 0 peration

The programmer should prepare a complete plan of operation for conducting the test. This plan should be documented and contain all the significant details of the test. The name of each file and the reel or disc number con taining it should be indica ted. The device on which each file is to be mounted and the disposition of the output files should be recorded. A documented plan covering the alternatives in case of errors should be in the programmer¹s possession. A good approach to documentation of operating procedures is to design a form similar to that illustrated in Figure 4-3. This form can eventually become the basis for the operator's Run Book.

I

FILE NAME: DEVICE:

INPUT'

FILE NAME: DEVICE:

FILE NAME: DEVICE:

OUTPUT

FILE NAME: DEVICE:

LOAD STANDARD OTHER:

PROCEDURE

DISPLAY REASON ACTION

PROGRAM STOPS

FORM NAME:

CARRIAGE LOOP NO.:

PRINTER FORM SET-UP

SPECIAL INSTRUC-TIONS

Have Program Documentation Available For Reference

Generally, the problems encountered during program testing are unpredictable. Because of this, the programmer must be able to reference program documentation to determine the nature of a problem. An adequate work area should be placed in the immediate vicinity of the computer to facilitate this reference. The programmer should be familiar enough with the program documentation to locate rapidly the documentation corresponding to any specific point in the program. J[t is most helpful if the programmer provides himself with a checklist of items necessary for successful testing. The checklist might resemble the one in Figure 4-4.

I. RUNS TO BE TESTED

II. SOFTWARE R EQU IRE D

D RPG

D

o

o

OTHER ___________________ . ___________________ _

III. NEEDED ITEMS

D PROGRAM FLOWCHARTS

D SOURCE CODE FORMS AN D DECK D SO FTWARE OP ERATING I N:)TRU CTIONS

D

D WORK TAPES

D

D PRINTER FORMS AND FORMS CONTROL LOOP D SAMPLES OF VALID OUTPJT

Figure 4-4. Program Test Checklist

Systems Testing

Most of the programs in the system have some input-to-output relationship to other runs in the system as well as among themselves. Each series of programs should be tested by running a reasonable volume of data through two or more complete processing cycles. It is recommended that this technique be used as part of an acceptance test for each program before the full systems test is performed. When input to a program is one of its output files from a previous cycle, the programmer should make sure that such output is fu11y acceptable input. Also, part of the acceptance test for each program should include test processing of its output files by the other programs that are to use these files as input.