Structural testing methods derive test cases from the internal implementation of software rather than only from external requirements. In the context of software engineering, they are especially valuable during unit and component testing because they reveal defects tied to control logic, variable usage, and implementation mistakes that black-box techniques may miss.2 The core family covered here includes control-flow testing, statement coverage, branch coverage, path coverage, data flow testing, and mutation testing.3

A useful way to organize the topic is to view structural testing as progressively deeper analysis of a program's internal model:

A control-flow graph models executable blocks as nodes and transfers of control as edges; structural criteria then specify what graph elements or related variable interactions must be exercised.2 Statement coverage is a baseline, branch coverage is stronger, and complete path coverage is usually infeasible when loops create very many or even infinitely many paths.2 Data flow testing refines path analysis by targeting how variables are defined and later used, helping uncover anomalies such as use-before-definition, defined-but-never-used values, and redefinitions before use.2 Mutation testing, by contrast, measures the effectiveness of an existing test suite by checking whether tests can distinguish the original program from deliberately altered versions containing small syntactic faults.2

Within the module Software Testing Fundamentals and Test Design, these methods support the learning goals of designing path-based test cases, interpreting structural coverage, selecting tests for critical definition-use interactions, and evaluating test adequacy beyond raw coverage percentages.3

Footnotes

1. Structural Software Testing - Overview of white-box/structural testing concepts and rationale. ↩ ↩² ↩³

2. Testing: Coverage and Structural Coverage - Academic slides explaining statement, branch, and path coverage with CFG-based interpretation. ↩ ↩² ↩³

3. Data Flow Testing: A Comprehensive Guide - Describes data flow testing, variable lifecycle analysis, and typical anomaly detection. ↩ ↩² ↩³

4. Mutation Testing - Explains mutation testing, mutants, equivalent mutants, and mutation score. ↩ ↩² ↩³

5. Basis Path Testing in Software Testing - Summarizes basis path testing and cyclomatic complexity as a practical path-testing approach. ↩ ↩²

6. Data Flow Testing - Explains definitions, uses, def-use analysis, and common data flow anomalies. ↩

7. Mutation Testing for Structural Coverage - Educational video discussing mutation testing as a stronger adequacy indicator than raw structural coverage. ↩

1. Control-Flow Foundations and Coverage Hierarchy

Structural testing usually begins with a CFG built from a code unit. Each node represents a statement or basic block, and each edge represents possible control transfer.2 Coverage criteria define a set of test requirements over that graph.

A common hierarchy is:

For basic structural metrics, the formulas are:

$$\text{Statement Coverage} = \frac{\text{Executed Statements}}{\text{Total Executable Statements}} \times 100$$ $$\text{Branch Coverage} = \frac{\text{Executed Branch Outcomes}}{\text{Total Branch Outcomes}} \times 100$$ $$\text{Path Coverage} = \frac{\text{Executed Paths}}{\text{Selected Target Paths}} \times 100$$

A critical interpretation rule is that $100\%$ statement coverage does not guarantee $100\%$ branch coverage, because a decision can be executed while only one outcome is taken.2 Conversely, for structured code, $100\%$ branch coverage generally implies $100\%$ statement coverage, but still does not guarantee that all path combinations have been exercised.2 This matters because many faults arise from particular sequences of decisions, not merely from touching each branch once.

Consider:

1if (x > 0)
2    y = 1;
3else
4    y = -1;
5
6if (z > 0)
7    w = y + 1;
8else
9    w = y - 1;

Two tests can achieve full branch coverage, but full path coverage of this code segment requires four decision combinations: $(T,T)$, $(T,F)$, $(F,T)$, and $(F,F)$. As decision points accumulate, path counts grow combinatorially; loops increase them further, making exhaustive path testing impractical for most real programs.

Footnotes

1. Testing: Coverage and Structural Coverage - Academic slides explaining statement, branch, and path coverage with CFG-based interpretation. ↩ ↩² ↩³ ↩⁴

2. Basis Path Testing in Software Testing - Summarizes basis path testing and cyclomatic complexity as a practical path-testing approach. ↩ ↩² ↩³

3. Statement Coverage Testing - Explains statement coverage and its limitations relative to stronger criteria. ↩ ↩²

2. Path Testing and Basis Path Testing

Path testing seeks to exercise paths through the CFG, often focusing on independent paths rather than all possible paths. In practice, the most common workable form is basis path testing, which uses cyclomatic complexity to estimate the minimum number of independent paths needed for a strong structural baseline.

For a single connected CFG:

$$V(G) = E - N + 2$$

and equivalently:

$$V(G) = D + 1$$

where $D$ is the number of decision nodes.

Suppose a routine has three predicate nodes. Then $V(G)=4$, meaning at least four independent paths should be selected to achieve basis path coverage. This does not mean all concrete paths are tested; rather, the chosen set spans the control structure so that every edge and each major decision pattern is represented.

A compact example:

11 read x
22 if x > 0
33    if x % 2 == 0
44       print("positive even")
55    else
66       print("positive odd")
77 else
88    print("non-positive")

Possible basis paths include:

1. $1 \rightarrow 2T \rightarrow 3T \rightarrow 4$
2. $1 \rightarrow 2T \rightarrow 3F \rightarrow 6$
3. $1 \rightarrow 2F \rightarrow 8$

These cover all statements and all branch outcomes, but if loops were present, complete path coverage would rapidly become infeasible.2

Path testing is effective for defects involving unreachable logic, missing branches, incorrect nesting, and certain sequencing errors.2 Its main limitation is path explosion, especially in loop-rich and highly conditional code.

In the graph above, branch coverage needs each decision outcome once, while path coverage distinguishes the full sequences through both decisions.

Footnotes

1. Basis Path Testing in Software Testing - Summarizes basis path testing and cyclomatic complexity as a practical path-testing approach. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. Testing: Coverage and Structural Coverage - Academic slides explaining statement, branch, and path coverage with CFG-based interpretation. ↩ ↩²

3. Structural Software Testing - Overview of white-box/structural testing concepts and rationale. ↩

3. Data Flow Testing

Data flow testing refines control-flow analysis by focusing on the lifecycle of variables: where they are defined, where they are used, and where they are no longer relevant or are overwritten.2 It uses the CFG, but the selection criterion is not merely path structure; it is the traversal of significant definition-use pairs.

Two standard use categories are:

• c-use: use in calculations or assignments
• p-use: use in decisions or predicates2

Let:

$$DEF(s) = \{x \mid \text{statement } s \text{ defines } x\}$$ $$USE(s) = \{x \mid \text{statement } s \text{ uses } x\}$$

A path from a definition of variable $x$ to a use of $x$ is def-clear if no intermediate node redefines $x$.2 Testing criteria then require selected test paths such as:

• all-defs: from every definition, reach at least one use
• all-uses: from every definition, reach every reachable c-use and p-use
• all-du-paths: cover all def-clear paths from definitions to reachable uses2

Data flow testing is especially strong for finding anomalies such as:

• variable defined but never used
• variable used before definition
• variable redefined before earlier value is used
• stale or unintended propagated values2

Example:

11 total = price * qty
22 if discountCodeValid
33    total = total - 10
44 if total > 100
55    shipping = 0
66 else
77    shipping = 15
88 amount = total + shipping

Here, total is defined at line $1$, possibly redefined at line $3$, then used in the predicate at line $4$ and in computation at line $8$. A data flow analysis distinguishes the $1 \rightarrow 4$, $1 \rightarrow 8$, $3 \rightarrow 4$, and $3 \rightarrow 8$ interactions subject to def-clear paths.2 That level of precision can reveal tests that branch coverage alone would overlook.

Footnotes

1. Data Flow Testing: A Comprehensive Guide - Describes data flow testing, variable lifecycle analysis, and typical anomaly detection. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Data Flow Testing - Explains definitions, uses, def-use analysis, and common data flow anomalies. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

4. Mutation Testing

Mutation testing introduces small changes called mutants into the program and runs the test suite against them.2 If a test causes the mutant to produce a different result from the original program, the mutant is said to be killed; otherwise it survives.

Typical simple mutation operators include:

• relational operator replacement, such as > to >=
• arithmetic operator replacement, such as + to -
• logical connector replacement, such as && to ||
• constant replacement, such as 0 to 1
• statement deletion or assignment replacement2

The basic score is:

$$\text{Mutation Score} = \frac{\text{Killed Mutants}}{\text{Non-equivalent Mutants}} \times 100$$

A key nuance is the existence of equivalent mutants.2 These cannot be killed by any test because, despite syntactic difference, they are semantically identical for all inputs. Equivalent mutant detection is one reason mutation testing can be expensive in practice.

Example original code:

1if (a > b)
2    max = a;
3else
4    max = b;

Mutants:

• if (a >= b)
• if (a < b)
• max = a + 1

A strong test suite should include inputs such as $a>b$, $a<b$, and possibly $a=b$ to kill these mutants.2 Notice how mutation testing often reveals inadequacies even when statement and branch coverage are high: the tests may execute the code but fail to assert the exact behavior needed to distinguish correct from incorrect logic.

Mutation testing is therefore often interpreted as a stronger indicator of test adequacy than raw structural coverage alone, though it has significantly higher computational and maintenance cost.2

Footnotes

1. Mutation Testing - Explains mutation testing, mutants, equivalent mutants, and mutation score. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. Mutation Testing for Structural Coverage - Educational video discussing mutation testing as a stronger adequacy indicator than raw structural coverage. ↩ ↩² ↩³ ↩⁴ ↩⁵

5. Strengths, Limitations, and When to Use Each Method

The major structural methods are complementary rather than interchangeable.3 A disciplined software engineering practice usually combines them according to risk, cost, and test objective.

Several limitations should be emphasized:

1. Coverage percentages can create false confidence if assertions are weak.
2. Complete path coverage is usually infeasible beyond small modules.
3. Data flow testing may become difficult with aliasing, pointers, object state, concurrency, or large interprocedural scopes.
4. Mutation testing can be costly and operationally noisy without good tooling and careful mutant selection.2

For the learning goals of this module, a practical progression is:

• start with statement and branch coverage
• derive basis paths using the CFG
• identify critical definition-use pairs for key variables
• use mutation testing to determine whether tests merely execute code or truly detect implementation faults3

That sequence aligns well with increasing analytical depth and educational value.

Footnotes

1. Structural Software Testing - Overview of white-box/structural testing concepts and rationale. ↩ ↩²

2. Data Flow Testing: A Comprehensive Guide - Describes data flow testing, variable lifecycle analysis, and typical anomaly detection. ↩ ↩² ↩³

3. Mutation Testing - Explains mutation testing, mutants, equivalent mutants, and mutation score. ↩ ↩² ↩³ ↩⁴

4. Basis Path Testing in Software Testing - Summarizes basis path testing and cyclomatic complexity as a practical path-testing approach. ↩

5. Mutation Testing for Structural Coverage - Educational video discussing mutation testing as a stronger adequacy indicator than raw structural coverage. ↩