White-Box Testing: Control Flow, Data Flow, and Coverage
White-Box Testing: Control Flow, Data Flow, and Coverage
This domain tests structural test design from code or detailed design: flow graphs, coverage criteria, complexity, and data-flow coverage. You must know which criterion is stronger and when each is practical.
Core rules
- Control flow graph: nodes are statements or blocks, edges are transfers. Cyclomatic complexity V(G) = E − N + 2 for a connected graph, or decisions + 1. It gives the number of independent paths in basis path testing.
- Coverage criteria from weakest to strongest: statement, decision, condition, decision/condition, multiple condition, MC/DC (for safety-critical), path. Path coverage is usually impractical with loops.
- Decision coverage requires each decision true and false; condition coverage requires each atomic condition true and false. Neither guarantees the other.
- MC/DC requires each condition to independently affect the decision outcome; it is required in avionics (DO-178C) and gives strong but feasible coverage.
- Data-flow testing: a definition (write) and use (read) form def-use pairs. Criteria include all-defs, all-uses, and all-du-paths; anomalies include undefined use, dead definition, and inconsistent definition.
Worked example
For if (a > 0 && b > 0) { x++; }, decision coverage needs one test with the decision true (a=1,b=1) and one false (a=0,b=1). That is not MC/DC: for MC/DC, add (a=1,b=0) so each condition independently changes the outcome. Three tests are needed. Reasoning: short-circuit && means condition b is not evaluated when a is false, so MC/DC pairs must be chosen carefully.
Traps
- Claiming 100% statement coverage implies 100% decision coverage.
- Forgetting short-circuit evaluation when designing condition tests.
- Using cyclomatic complexity as a quality score rather than a test-count guide.
- Ignoring data-flow pairs across function calls.
- Assuming path coverage is achievable for loops.