Test Generation Criteria

10.3.2 Test Generation Criteria

The purpose of dataflow-based test generation criteria is to force the execution of the program through combinations of definitions and uses in such a way as to detect all possible faults in the sequencing of these events. We discuss four such criteria:

• All definition-use paths.

A path in the program is said to be a definition-use path (du-paths, for short) for some program variable x if and only if it starts with some statement that defines variable x and ends with a statement that uses variable x.

○ All definition-clear paths.

A path in the program is said to be a definition-clear path for some program variable x if and only if it is a definition-use path for variable x and the definition statement with which it starts is the only definition statement for that variable in the path.

The criterion of All definition-use paths provides that one must generate test data to exercise all the definition-use paths for all the variables of the program. To apply this criterion, we proceed as follows:

○ First, we list all the variables of the program. ○ For each variable of the program, we list all the definition statements and all

the use statements. ○ For each definition/use pair, we check whether there exists a path from the definition statement to the use statement. ○ For all the paths identified in the previous steps, we identify a pre-path, from the beginning of the execution to the first statement of the path, and a post- path, from the last statement of the path to the end of the execution.

○ For each triplet made up of a pre-path, a definition-use path, and a post-path, we compute the function of the aggregate path.

218 STRUCTURAL CRITERIA

○ For each aggregate path, we compute the path condition as the domain of the path function. ○ For each path that yields a non-False path condition, we generate test data that exercises this path.

The set of test data so obtained constitutes our test data. • All p-uses. A p-use path for a program with respect to variable x is a

definition-clear path from a definition of variable x to a p-use of x. The criterion of All p-uses provides that one must generate test data to exercise all the p-use paths for all the variables of the program. To apply this criterion, we proceed in the same way as we discuss above, but focusing exclusively on p-use paths.

• All c-uses. A c-use path for a program with respect to variable x is a definition- clear path from a definition of variable x to a c-use of x. The criterion of All c-uses provides that one must generate test data to exercise all the c-use paths for all the variables of the program. To apply this criterion, we proceed in the same way as we discuss above, but focusing exclusively on c-use paths.

• All uses . The criterion of All uses provides that one must generate test data to

meet the All p-uses criterion and test data to meet the All c-uses criterion. • All definitions . The criterion of All definitions provides that one must generate test data to ensure that all definitions are visited at least once.

For the sake of illustration, we briefly discuss the generation of test data according to the four criteria presented herein for the gcd program. We apply the criteria in turn, below:

• All du-paths. We consider in turn variable x, then variable y. For variable x, we find the following definition statements: ○ Statements 2 and 6. And the following use statements: ○ Statements 4, 5, 6, 8, and 9.

We choose the definition-use path that starts at the definition in statement 2 and ends at the use at statement 4. We write this path as follows:

read(x); read(y); ((x!=y)? XX);

The pre-path of this path is empty, since read(x) is the first executable statement of the program. There is an infinity of post-paths; for the sake of illus- trations, we do not take the shortest/simplest post-path, but choose instead the following:

((x!=y)? true); ((x>y)? true); (x=x-y); ((x>y)? false);

10.3 DATA FLOW COVERAGE 219

We leave it to the reader to check that the function of this path is the following: P= s, s length is ≥ 2 head is = 2 × head tail is

x = head tail is y = head tail is

os = os head tail is The domain of this function can be written as:

dom P = s,s length is ≥ 2 head is = 2 × head tail is Possible test data:

is = 24,12,…

We leave it to the interested reader to continue reviewing other definition-use paths, including those obtained by the combinations of statements (2,5), (2,6), (2,8), (6,4), (6,5), and (6,8). Note that by the time we combine the selected path with a pre-path and a post-path, we may find an aggregate path that we have ana- lyzed before; in that case, we can rely on the test data we have generated before.

We must do the same analysis for all the definition-use paths that pertain to variable y; to this effect, we list below the definition and use statements for variable y.

○ Definitions: statements 3 and 8. ○ Uses: statements 4, 5, 6, 8.

• All p-uses. This criterion provides for covering all the definition-clear paths that end with a p-use of some variable. The following table shows the list of definitions and p-uses of each variable of the program.

y Definitions

This includes definition-clear paths (2,4), (2,5), (3,4), and (3,5). • All c-uses. This criterion provides for covering all the definition-clear paths that end with a c-use of some variable. The following table shows the list of defini- tions and p-uses of each variable of the program.

y Definitions

c-uses

220 STRUCTURAL CRITERIA

All paths

All du-paths

All uses

All c-uses

All p-uses

All definitions

Branch coverage

Statement coverage

Figure 10.4 Hierarchy of test generation criteria.

• All uses . The test data generated for this criterion is the union of the test data generated by criterion All p-uses and criterion All c-uses. • All definitions . The test data generated for this criterion must ensure that all the definition nodes are visited at least once; these are 2 and 6 for x, and 3 and 8 for y.