IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987 The Path Prefix Software Testing Strategy RONALD E. PRATHER AND J. PAUL MYERS, JR. Abstract-A new software testing strategy is described. The strategy is "adaptive" in that previous test paths (inputs) are used as a guide in the selection of subsequent paths (inputs). Preliminary implemen- tations have successfully exploited the method's inherent user-inter- active capability. The method ensures branch coverage, requires only "order n" tests (n being the number of decision nodes in the program flowgraph), and offers considerable advantages over existing strategies in its computational requirements. Index Terms-Branch coverage, path selection, program flowgraph analysis, software testing. I. INTRODUCTION THE general goal of software testing is to affirm the 1 quality of a program through systematic exercising of the code in a carefully controlled environment. We find that the theory of program testing [1]-[3] diverges into two separate streams-relating either to functional testing [4]-[6] or to structural testing [7]-[9], respectively. The testing strategy introduced in this paper falls, for the most part, into this latter category-or more precisely, into a variation of the structural testing methodology that might be called adaptive in its approach. The execution of any program test scheme should val- idate an expected prespecified behavior, ideally serving to demonstrate the absence of program errors. Both the program and its specification can be viewed as functions, f and g, from the domain S of input values to the range T of output values that might be anticipated. Both S and T are domains of "vectors"-e.g., x = (Y1, Y2, ' * * , Yn) is an input vector where the yi are the input variables to f. In this context, a test X is a finite subset of S, used to exercise the code in a series of "runs" (hopefully exhib- iting the proper behavior). II. FUNCTIONAL VERSUS STRUCTURAL TESTING In functional testing, one tries to make use of the pro- gram specification in order to design an "adequate" test. Through a careful reading of the specification, one at- tempts to arrive at a problem partition S {P, P2, ,Pm} representing disjoint input subdomains that somehow characterize the original conception of the problem, in a "case-by-case" fashion. It may be that the program is designed to analyze employee records, for example, and Manuscript received December 28, 1984; revised December 30, 1985. The authors are with the Department of Computer Science, Trinity Uni- versity, San Antonio, TX 78284. IEEE Log Number 8714552. we would then want to give special attention to the var- ious dichotomies-male versus female, part-time versus full-time, salaried versus hourly, etc. And these should be reflected in our problem partition (as well as any error or termination conditions, etc.). In general, one then chooses a series of input tests xi e Pi, one from each block of the partition, and it is assumed that such a choice for X = { xi } will be adequate for the task. With the structural testing methodology, one attempts to make use of the program flowgraph in designing an "adequate" test. The methodology can be divided into three rather separate phases 1) program graph construction; 2) test path selection; 3) test case generation; as shown in Fig. 1. The first phase (program graph construction) is the most straightforward. One has only to "annotate" the source code listing f to derive the underlying flowgraph F = ( V, E) as a collection of vertices (V) and edges (E), in the graph-theoretic sense. Given the program flowgraph F = (V, E ), one then enters the second phase (test path selection) in which a finite set {pj } of program paths are chosen, with a view toward satisfying one or more "coverage" criteria. The most often cited criteria are among the following: a) statement coverage: Execute all statements in the graph; b) node coverage: Encounter all decision node entry points in the graph; c) branch coverage: Encounter all exit branches, of each decision node in the graph; d) multiple condition coverage: Achieve all possible combinations of simple Boolean conditions at each deci- sion node in the graph; e) path coverage: Traverse all paths of the graph. It is clear theat "statement coverage" and "node cov- erage" are in themselves rather weak criteria, represent- ing necessary but by no means sufficient conditions for obtaining a reasonable test. The "branch coverage" cri- terion, however, implies the other two and has come to be regarded as a minimal standard of achievement in structural testing. The stronger criteria of "multiple con- dition coverage" and' "path coverage" (suitably defined to include only a finite number of paths) are difficult to achieve in a program of more than moderate complexity. Recognizing this, we note that the "branch coverage" criterion has been widely recognized as the basic measure of testing thoroughness. 0098-5589/87/0700-0761$O1 .00 © 1987 IEEE 761