Path Testing & Basis Path Testing in Software with Examples

What is Path Testing in Software Testing?

Path testing is a structural testing method that involves using the source code of a program in order to find every possible executable path. It helps to determine all faults lying within a piece of code. This method is designed to execute all or selected path through a computer program.

Any non-trivial program contains many possible execution paths. Testing every one of them is both difficult and time-consuming, and most of them overlap. Basis path testing reduces that redundancy by identifying the smallest set of paths that still exercises every statement and every branch at least once.

Basis Path Testing in Software Engineering

Basis Path Testing in software engineering is a White Box Testing method in which test cases are defined based on flows or logical paths that can be taken through the program. The objective of basis path testing is to define the number of independent paths, so the number of test cases needed can be defined explicitly to maximize test coverage.

In software engineering, Basis path testing involves execution of all possible blocks in a program and achieves maximum path coverage with the least number of test cases. It is a hybrid method of branch testing and path testing methods.

A simple example makes the idea concrete.

The flow graph above contains conditional statements, so control can reach the exit by more than one route. Three independent paths are needed to cover it:

• Path 1: 1,2,3,5,6, 7
• Path 2: 1,2,4,5,6, 7
• Path 3: 1, 6, 7

How to Draw a Control Flow Graph

Every step of basis path testing depends on the control flow graph, so it is worth being precise about how one is built.

• Node: a sequence of statements that always execute together, drawn as a circle. A run of statements with no branch collapses into a single node.
• Edge: a transfer of control from one node to the next, drawn as an arrow. Edges are the only way control moves.
• Predicate node: a node containing a condition, with two or more edges leaving it. These drive the complexity count.
• Region: an area bounded by edges and nodes. The number of regions plus one also equals the cyclomatic complexity.

Consider a short module with two decisions:

if (a > b) {          // node 1, predicate
    max = a;          // node 2
} else {
    max = b;          // node 3
}
if (max > limit) {    // node 4, predicate
    alert();          // node 5
}
return max;           // node 6

The graph has 6 nodes and 6 edges, giving V(G) = 6 – 6 + 2 = 2 by the edge formula. The predicate count gives the same answer more quickly: 2 decisions plus 1 equals 3 independent paths through the two branches taken together. Use whichever form you can compute reliably, and cross-check with the other.

Two rules that prevent most errors. First, a compound condition such as if (x > 0 && y > 0) counts as two predicate nodes, not one, because the short-circuit creates a second decision. Second, a loop contributes one predicate node regardless of how many times it iterates.

Steps for Basis Path Testing

The basic steps involved in basis path testing include

• Draw a control graph (to determine different program paths)
• Calculate Cyclomatic complexity (metrics to determine the number of independent paths)
• Find a basis set of paths
• Generate test cases to exercise each path

Advantages and Limitations of Basis Path Testing

Advantages of Basis Path Testing

• It helps to reduce the redundant tests
• It focuses attention on program logic
• It replaces arbitrary test case selection with an analytical basis
• Test cases which exercise basis set will execute every statement in a program at least once

Limitations of Basis Path Testing

• It cannot find missing code. A requirement that was never implemented has no path, so no test will be generated for it. Basis path testing must be paired with requirement-based testing.
• Path count grows quickly. Nested loops and compound conditions push complexity up fast, and a module with V(G) above 20 becomes impractical to cover this way.
• Coverage is not correctness. Executing a path proves the code runs, not that it produces the right answer. Each test still needs a meaningful assertion.
• Data-dependent paths. Some paths are only reachable with specific input combinations that can be hard or impossible to construct.

FAQs