COMPARISON OF DATA FLOW TEST SELECTION CRITERIA

5.7 COMPARISON OF DATA FLOW TEST SELECTION CRITERIA

Having seen a relatively large number of test selection criteria based on the concepts of data flow and control flow, it is useful to find relationships among them. Given

a pair of test selection criteria, we should be able to compare the two. If we cannot compare them, we realize that they are incomparable. Rapps and Weyuker [3] defined the concept of an includes relationship to find out if, for a given pair of selection criteria, one includes the other. In the following, by a complete path we mean a path from the entry node of a flow graph to one of its exit nodes.

Definition: Given two test selection criteria c 1 and c 2 ,c 1 includes c 2 if for every def/use graph any set of complete paths of the graph that satisfies c 1 also satisfies c 2 .

Definition: Given two test selection criteria c 1 and c 2 ,c 1 strictly includes c 2 , denoted by c 1 →c 2 , provided c 1 includes c 2 and for some def/use graph there is

a set of complete paths of the graph that satisfies c 2 but not c 1 . It is easy to note that the “→” relationship is a transitive relation.

Moreover, given two criteria c 1 and c 2 , it is possible that neither c 1 →c 2 nor c 2 →c 1 holds, in which case we call the two criteria incomparable. Proving the strictly includes relationship or the incomparable relationship between two selection criteria in a programming language with arbitrary semantics may not be possible. Thus, to show the strictly includes rela- tionship between a pair of selection criteria, Rapps and Weyuker [3] have considered a restricted programming language with the following syntax:

Start statement:

start

Input statement: read x 1 , . . . ,x n , where x i , . . . ,n are variables.

Assignment statement: y ←f (x 1 , . . . ,x n ), where y, x i , . . . ,n are variables, and f is a function.

Output statement: print e 1 , . . . ,e n , where e 1 , . . . ,e n are output

values.

Unconditional transfer statement: goto m , where m is a label. Conditional transfer statement:

if p (x 1 , . . . ,x n ), then goto m, where p is a predicate.

Halt statement:

stop

5.8 FEASIBLE PATHS AND TEST SELECTION CRITERIA

All-c-uses/Some-p-uses All-p-uses/Some-c-uses

All-c-uses

All-p-uses

All-defs All-branches

All-statements

Figure 5.5 Relationship among DF (data flow) testing criteria. (From ref. 4. © 1988 IEEE.)

Frankl and Weyuker [4] have further extended the relationship; what they have proved has been summarized in Figure 5.5. For example, the all-paths selection criterion strictly includes the all-du-paths criterion. Similarly, the all-c-uses/some-p-uses criterion strictly includes the all-defs criterion.

However, we cannot find a strictly includes relationship between the pair

be a set of paths selected by the all-c-uses criterion with respect to a variable x . Now we cannot say with certainty whether or not the path set P c x satisfies the all-p-uses criterion with respect to the same variable x . Similarly, let P p

all-c-uses and all-p-uses. Let P c x

be a set of paths selected by the all-p-uses criterion with respect to the variable x . Now we cannot say with certainty whether or not the path set

P p x satisfies the all-c-uses criterion with respect to the same variable x . Thus, the two criteria all-c-uses and all-p-uses are incomparable. Note the relationship between data flow–based test selection criteria and control flow–based test selection criteria, as shown in Figure 5.5. The two control flow–based test selection criteria in Figure 5.5 are all-branches and all-statements. The all-p-uses criterion strictly includes the all-branches criterion, which implies that one can select more paths from a data flow graph of a program unit than from its control flow graph.