×

Courses

Chapters

>
<

Software Engineering

Software Engineering White Box Testing | CrackEase

White Box Testing

White Box Testing

  • Also known as Clear‑Box, Glass‑Box, Code‑Based or Structural testing.
  • Tests internal structure, logic and implementation of the code — testers need knowledge of the source code.
  • Usually performed by developers or testers with programming expertise; applied at unit, integration and sometimes system levels.
  • Test cases are designed to exercise control paths, conditions, loops and data flows to reveal implementation defects.

Types of Errors Found

White box techniques diagram
  • Control‑flow testing
  • Data‑flow testing
  • Branch coverage
  • Statement coverage
  • Path and prime‑path testing
  • Loop testing

Techniques of White Box Testing

Cyclomatic complexity graph

1. Statement coverage

Ensure every statement in the code is executed at least once by tests.

2. Branch coverage

Design tests so each branch (true/false outcome) is executed at least once.

3. Path coverage

Attempt to execute all possible execution paths from entry to exit — often impractical for large programs.

4. Loop testing

Test simple, nested and concatenated loops, focusing on boundary values (0, 1, max‑1, max).

Basis Path Testing & Cyclomatic Complexity

Basis path testing uses the control‑flow graph to identify independent paths and derive a minimal set of test cases.

Steps:

  1. Build the control flow graph from the code.
  2. Calculate cyclomatic complexity V(G).
  3. Identify independent paths.
  4. Design test cases for each independent path.

Common formulas for V(G):

  • V(G) = P + 1, where P = number of predicate nodes
  • V(G) = E − N + 2, where E = edges, N = nodes
  • V(G) = number of independent regions in the graph

Example: if V(G) = 3 then there are 3 independent paths (P1, P2, P3) that should be exercised.

Advantages vs Disadvantages

Advantages

  • Covers internal code paths and helps optimize implementation.
  • Helps find hidden errors (dead code, logic flaws, security holes).
  • Can be automated and started early during development.
  • Enables precise fault localization at code level.

Disadvantages

  • Can be time‑consuming and expensive to achieve high coverage.
  • May miss missing or incorrect requirements — it tests implementation, not specification.
  • Requires skilled testers with programming knowledge.
  • Not feasible to exhaustively test all paths for large programs.
Footer Content | CrackEase
→
←