Once each function had been tested, a different kind of test was performed on the whole program in order to verify the proper execution and integration of each module in the system.
Such testing session can be thought of as a “path testing”. It was performed by introducing a set of numeric variables used as “counters”, in order to trace the execution flow. More in detail, the following steps were followed in setting up the testing session:
− Definition of a boolean variable (G_TestMode) used to enable/disable the testing mode (see source code in appendix A.1).
− Definition of a pair of numeric variables used to trace entrance and exit events in the main procedure. See variables G_TestCntArchAndPurge_Entering and G_TestCntArchAndPurge_Exiting, respectively at the beginning and at the end of main procedure ArchiveAndPurge (test IDs: ArchiveAndPurge.1 and ArchiveAndPurge.34).
− Definition of a numeric variable placed as first statement in the loop construct that processes all business units. See variable G_TestCntArchAndPurge_BUs at the beginning of loop CurResponsibility (test ID: ArchiveAndPurge.2).
− Definition of a numeric variable placed as first statement in the loop construct that processes all periods in the time range specified. See variable G_TestCntArchAndPurge_Periods at the beginning of loop CurPeriod (test ID:
ArchiveAndPurge.3).
− Defintion of five numeric variables for tracing each of the main archiving phases. See variables G_TestCntArchAndPurge_Phase_1 to G_TestCntArchAndPurge_Phase_5 (test IDs: ArchiveAndPurge.4, ArchiveAndPurge.10, ArchiveAndPurge.16, ArchiveAndPurge.22 and ArchiveAndPurge.28).
− Definition of twenty five numeric variables, for tracing module selection (one for each financial module and archiving phase). See variables G_TestCntGL_Phase_1 to G_TestCntGL_Phase_5, G_TestCntAR_Phase_1 to G_TestCntAR_Phase_5, etc. (test IDs:
ArchiveAndPurge.5, ArchiveAndPurge.6, ArchiveAndPurge.7, ArchiveAndPurge.8, ArchiveAndPurge.9, ArchiveAndPurge.11, ArchiveAndPurge.12, ArchiveAndPurge.13, ArchiveAndPurge.14, ArchiveAndPurge.15, ArchiveAndPurge.18, ArchiveAndPurge.19, ArchiveAndPurge.20, ArchiveAndPurge.21, ArchiveAndPurge.23, ArchiveAndPurge.24, ArchiveAndPurge.25, ArchiveAndPurge.26, ArchiveAndPurge.27, ArchiveAndPurge.29, ArchiveAndPurge.30, ArchiveAndPurge.31, ArchiveAndPurge.32, ArchiveAndPurge.33).
− Definition of a procedure for inspecting the value of test counters (see procedure PrintTestCounters). This procedure is called at the beginning of the main procedure ArchiveAndPurge, in order to show all initial values, and at the end in order to inspect the final status of the counters (test IDs: ArchiveAndPurge.1 and ArchiveAndPurge.34).
These variables and the printing procedure were used in the program source code as illustrated by the statement in Figure 9.2.
1 TESTING PURPOSES ---2 -- Test ID:ArchiveAndPurge.1
3
4 -- If test mode is enabled then...
5 ifG_TestMode then 6
7 -- Prints out the initial value of all test counters (all zeros are expected) 8 PrintTestCounters;
9 -- Increases the 'entering' counter
10 G_TestCntArchAndPurge_Entering:=G_TestCntArchAndPurge_Entering+1;
11 -- Prints out log text and numeric log information 12 Write('Entering main function ArchiveAndPurge');
13 Write('Counter G_TestCntArchAndPurge_Entering is'||BLANK||G_TestCntArchAndPurge_Entering);
14 15 end if;
16
17
---Figure 9.2 Code details for testing purposes
For a given input, the above set of variables was valued so as to indicate the execution path and all the iterations performed.
The input sets were defined by considering the input parameters available to the key user of the archiving program. Precisely the key user has to provide the following input data:
Time range Which is done by choosing a starting period and an ending period from a list of values. Such list of values is a standard component of the ERP application and contains all valid periods and all relevant consistency checks (e.g. the starting period must be prior or equal to the ending period).
Modules Which is done by selecting all needed financial modules (by means of flags). At the moment of writing, the two main financial modules, GL and AR, have been fully implemented. Integration of shared modules AP and PO is in progress and two other modules, AX and FA, have already been predisposed for next integration activities.
As an example, the user can select, say, the whole year 1995 and all financial modules. This corresponds to the following input parameters:
From: 01-1995
To: 14-1995
GL: Yes
AR: Yes
AP_PO: Yes
AX: Yes
FA: Yes
From such considerations, a number of test cases were devised and tried on the program. The most significant of them are collected in Table B.1 and Table B.2.
9.3.2 Archiving volumes
Another testing session aimed at verifying consistency of the archiving program by considering the number of records archived.
For each business unit and financial module, such testing session was structured as indicated by the following steps:
1. For each standard (source) table involved in the archiving process, its total number of records was calculated.
2. The same calculation was performed on all archive (destination) tables.
3. Then, the archiving program was executed (for a given financial module and time range).
4. After the archiving program completed successfully, steps 1 and 2 were re-executed.
Then, the four sets of figures obtained were compared as follows:
source_table_totals_before_arch – source_table_totals_after_arch
=
destination_table_totals_after_arch – destination_table_totals_before_arch where the above items refers to:
source_table_totals_before_arch → Totals computed in the above step 1.
source_table_totals_after_arch → Totals computed in the above step 2.
destination_table_totals_after_arch → Totals computed in the above step 4.
destination_table_totals_before_arch → Totals computed in the above step 4.
The above equation was expected to be satisfied. In fact, the number of records selected for archiving (first part in the equation) had to equal the number of record archived (second part in the equation). Appendix B (section B.2) describes such test on financial module General Ledger.