Designing Tests

Two types of information should be available when designing tests for module testing: a specification for the module and its source code. The specification usually defines the input and output parameters of the module and its functions.

The module tests are written based on the white box test design strategy. This is due primarily to the fact that the white box testing is less feasible when you test larger units, for example, whole programs (this will be the case for the future testing procedures). In addition, the subsequent testing stages are focused on detecting different types of errors, namely, errors that are not necessarily related to the logic of the program, but that occur, for example, when the program fails to satisfy the user’s requirements. Therefore, the test-design process for module testing is as follows: the logic of an individual module is analyzed using one or more white-box methods, and then this set of tests is enhanced by using the black box methods in respect of the module’s specification.

Whatever logic-coverage testing technique is used, the first step should involve making a list of all decisions within the program. All the IF and DO operators are candidates in the program. Examining the source code of the program, you can verify that the DO statements represent simple iterations in which the limit of each iteration will be equal or greater than the initial value (this means that each loop is executed at least once), and the only way to exit the loop is through the DO operator. Consequently, DO operators do not require special attention, since any test that causes the execution of the DO statement will cause its branching in both directions (i.e., when entering and exiting the loop body). For this reason it is necessary to analyze the following statements:

2 IF (EIZE <= 0) l (DSIZE <= 0)

6 IF (SALES (I)> = MAXS ALES)

9 IF (SALES (J) = MAXSALES)

13 IF (EMPTAB.DEPT (K) = DEPTTAB.DEPT (J))

16 IF (SALARY (K)> = LSALARY) | (CODE (K) = MGR)

21 IF(-FOUND)

There is a small number of decisions, so most likely you should choose the multi condition coverage, but you need to test all the logic coverage criteria (excluding statement coverage, which use is limited in many cases) to see which effects they will produce.

In order to satisfy the decision coverage criterion, it is necessary to design a sufficient number of test cases which could invoke execution of each of the statements in both directions. Test cycles can be organized in specially equipped software testing lab which is capable handling almost all operating environments.