|
|
|
|
|
|
|
Figure 5-8 shows the flow of control through the branching structure of the Notices program for each of these data sets. Set 1 is valid and gives an average of 100, which is passing and not marginal. Set 2 is valid and gives an average of 61, which is passing but marginal. Set 3 is valid and gives an average of 50, which is failing. Set 4 has an invalid test grade, which generates an error message. |
|
|
|
|
|
|
|
|
Every branch in the program is executed at least once through this series of test runs; eliminating any of the test data sets would leave at least one branch untested. This series of data sets provides minimum complete coverage of the program's branching structure. Whenever you test a program with branches in it, you should design a series of tests that covers all of the branches. It may help to draw diagrams like those in Figure 5-8 so that you can see which branches are being executed. |
|
|
|
|
|
|
|
|
Because an action in one branch of a program often affects processing in a later branch, it is critical to test as many combinations of branches, or paths, through a program as possible; this way we can be sure that there are no interdependencies that could cause problems. Of course, some combinations of branches may be impossible to follow. For example, if the else is taken in the first branch of program Notices, the else in the second branch cannot be taken. Shouldn't we try all possible paths? Yes, in theory we should. However, the number of paths in even a small program is quite large. For example, there are 16 possible paths in the LumberYard program. |
|
|
|
|
|
|
|
|
Figure 5-8
Flow of Control Through Notices Program for Each of Four Data Sets |
|
|
|
|
|
