Path testing of computer programs with loops using a tool for simple loop patterns

Abstract

The purpose of this paper is to present a method for testing computer programs with iteration loops. Given such programs, we have shown that for classes of program paths, identified as sequences of simple loop paths, there is a characterizing function called a simple loop pattern. The key idea of simple loop patterns is that these special functions form a base set which can represent any path computation in the given program. A software tool called SILOP has been developed to automatically generate these simple loop patterns, and each corresponding sequence of simple loop paths can be considered as a test case. The tester uses each test case, and with knowledge of the application program, can generate corresponding test data. This paper also presents a method for selecting the specific paths and test data to determine the simple loop pattern reliably. The tester can use this selection method to predict the number of tests required. In order to apply this selection method, the given program must be a linear computer program.The SILOP tool and this test selection method have been applied to commercial software; in this paper, this computational experience is reported and several examples are given to demonstrate the approach. Path computationsVariables in any program are classified in Reference 5 either as input variables or program variables. Input variables form a set X = {xj(i = 1, . . . , k} ; their values are imported from the program environment and do not change within the program. Program variables form a set Z = { z j ( j = 1, ..., m } and are assigned values in the program. The set of all k-vectors x defines the program input space Xk; similarly, the set of all m-vectors z defines the program variable space 2". A special subset of program variables, Y = {y$ = 1, ..., t } , is distinguished. These output variables are program variables whose values are exported to the. program environment, so t I m . A program variable function f computed by a program is of the form f: V+V,where V = Xk X 2". Note that this notation f o r f i s more general than is required for each mapping, since it has been assumed that input variables cannot be assigned. This generalization is essential for further development based on the composition of functions from V onto V ; however, it should be kept in mind that every f: V+V being considered leaves the x part of its arguments unchanged.The control flow graph of a program is defined' as a quadruple:where Q is a finite set of nodes, A is a set of arcs, and s, e are distinguished entry and exit nodes, respectively. Each arc ( a , b ) E A , where a , b E Q , is labelled by a symbol representing the program variable function gU,& V+V. For the purpose of this definition, assume a single program exit node. Later in the paper, without loss of generality, programs may have multiple program exit nodes.A path from node a to node b is a sequence of nodes qoql ... qj, a = qo, b = qj, such that for i = 0, .. ., j-1, each ( q j , q i + l ) E A . If a = s and b = e then the path is a program pa...

Using symbolic execution to guide test generation

“…However, at any point in time, users can obviously choose values of L that provide an appropriate tradeoff between required reliability and testing effort. Alternatively, a technique for deciding how many loop iterations are required [18,26] could be used.…”

“…When the output variables are linear functions of the inputs, White and Wiszniewski [17,18] have shown that one can infer an upper bound for the number of test cases that are required to test the loop contents, irrespective of the number of iterations. However, in a more general case, a decision must be 49 made as to which paths to follow: for instance, the loop can be traversed zero times, once and twice as suggested by Girgis [19].…”

Program analysis too loopy? Set the loops aside

“…The baseline path count is 114. One way of computing this path count is to divide the control flow graphs into sections: the control flow graph before node 6 (contains nodes 1-5), the control flow graph representing the loop at node 6 (contains nodes [6][7][8][9][10][11][12][13][14][15][16][17][18][19][20], and the control flow graph representing the loop after node 6 (contains nodes [21][22][23][24][25]. There are two paths from node 1 to 6.…”

“…In the worst case, the number of paths decreased by one or two orders of magnitude. This occurred in eight functions (13,15,16,18,19,21,22,28). In five of these functions (15,16,19,21,22), there is a significant number of paths outside the loops and relatively few paths within the loops.…”

Software unit test coverage and adequacy

“…It should be noted, first, that although we can often obtain finite applicability by using the feasible version, this may cause the undecidability problem; that is, we may not be able to decide whether a test set satisfies a given adequacy criterion. For example, whether a statement in a program is feasible is undecidable [Weyuker 1979a;Weyuker 1979b;White 1991]. Therefore, when a test set does not cover all the statements in a program, we may not be able to decide whether a statement not covered by the test data is dead code.…”