CPSC 333: Path Testing Example

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Path Testing Example


This material was covered during lectures on March 26, 1997.


Example Program

Now, path testing will be applied in order to design a set of tests for the sorting program whose pseudocode has already been given.

Flow Graph

A flow graph can be developed for this program, as previously described. This graph is as follows.

Flow Graph for Sorting Program

Cyclomatic Complexity

As a check, we'll compute the cyclomatic complexity of this flow graph, using each of the three definitions for ``cyclomatic complexity'' that have been given.

  1. It should be clear that these nodes and edges delineate three ``regions'' of the screen (Don't forget that the ``region'' that surrounds the entire graph should be included!). Thus, an application of the first definition of cyclomatic complexity suggests that the cyclomatic complexity of this program is 3.

  2. This flow graph has n=10 nodes and e=11 edges. Since e-n+2 = 3, an application of the second definition of cyclomatic complexity also suggests that the cyclomatic complexity of this program is 3.

  3. Finally, there are p=2 two-sided conditions (corresponding to nodes whose fan-out is 2, instead of 1 or 0) in this program. Since p+1 = 3 in this case, the third definition of cyclomatic complexity suggests that the cyclomatic complexity of this flow graph is 3, as well.

Once again, the fact that these definitions all give the same value doesn't ``prove'' that the flow graph is correct; on the other hand, you should certainly go back over your flow graph and look for problems, if the values don't agree!

Design of Tests

Now, we'll try to design tests by choosing inputs (and specifying the expected outputs), such that execution of each new test would ``cover'' an edge in the flow graph that hadn't been covered before.

As previously discussed it's generally a good idea to try to choose tests that cover as few new edges as possible at a time, in order to make it as easy as possible to figure out where to look for problems in the source code when a test ``succeeds'' in detecting a problem.

Test #1

In keeping with this goal, we'll start with a test whose execution doesn't include an execution of the loop body for the outer while loop in the code.

Test #1
Inputs: n = 1; A[1] = 1
Expected Outputs: A[1] = 1

We're not bothering to specify the output value for n, above, because there is no statement in the source code that can cause this value to be changed - so its value will always be the same as the value it had when execution began.

Execution of the program (while ``tracing'' its progress along the corresponding edges in the flow graph) reveals that execution begins at statement s1, then edge e1 is followed to condition c1; the test fails, so that edge e11 is followed to the stop node, after that.

Here is the flow graph, redrawn with the edges ``covered'' by this test shown as dashed lines, instead of solid ones.

Flow Graph, Redrawn

Test #2

Next, we'll add a test that causes the outer loop body to be executed (once) but whose execution doesn't include execution of the body of the inner loop.

Test #2
Inputs: n=2; A[1] = 1, A[2] = 2
Expected Output: A[1] = 1, A[2] = 2

Execution of the program causes the following sequence of edges in the flow graph to be followed:

e1; e2; e3; e9; e10; e11

Again, here is the redrawn flow graph, with all the edges covered by one or both of the first two tests drawn as dashed lines.

Flow Graph, Redrawn Again

Test #3

Finally, here is a third, simple, test, that causes the inner loop body to be executed (once) as well:

Test #3
Inputs: n=2; A[1] = 2, A[2] = 1
Expected Output: A[1] = 1, A[2] = 2

Execution of the program on this test causes the following sequence of edges in the flow graph to be followed:

e1; e2; e3; e4; e5; e6; e7; e8; e9; e10; e11

This time, the flow graph won't be redrawn; it would like the original picture of the flow graph, except that every one of the edges would be shown as a dashed line - telling us that we're finished (with ``path testing'').

Note that the number of tests used happens to be the same as the cyclomatic complexity of the flow graph, in this case.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Path Testing Example


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca