Section II - White Box Testing Techniques


Chapter 10: Control Flow Testing

Chapter 11: Data Flow Testing



White box testing is a strategy in which testing is based on the internal paths, structure, and implementation of the software under test (SUT). Unlike its complement, black box testing, white box testing generally requires detailed programming skills.

The general white box testing process is:

  • The SUT's implementation is analyzed.
  • Paths through the SUT are identified.
  • Inputs are chosen to cause the SUT to execute selected paths. This is called path sensitization. Expected results for those inputs are determined.
  • The tests are run.
  • Actual outputs are compared with the expected outputs.
  • A determination is made as to the proper functioning of the SUT.


White box testing can be applied at all levels of system development—unit, integration, and system. Generally white box testing is equated with unit testing performed by developers. While this is correct, it is a narrow view of white box testing.

White box testing is more than code testing—it is path testing. Generally, the paths that are tested are within a module (unit testing). But we can apply the same techniques to test paths between modules within subsystems, between subsystems within systems, and even between entire systems.

click to expand


White box testing has four distinct disadvantages. First, the number of execution paths may be so large than they cannot all be tested. Attempting to test all execution paths through white box testing is generally as infeasible as testing all input data combinations through black box testing.

Second, the test cases chosen may not detect data sensitivity errors. For example:


may execute correctly except when r=0.

 y=2*x // should read y=x2

will pass for test cases x=0, y=0 and x=2, y=4

Third, white box testing assumes the control flow is correct (or very close to correct). Since the tests are based on the existing paths, nonexistent paths cannot be discovered through white box testing.

Fourth, the tester must have the programming skills to understand and evaluate the software under test. Unfortunately, many testers today do not have this background.


When using white box testing, the tester can be sure that every path through the software under test has been identified and tested.

A Practitioner's Guide to Software Test Design
A Practitioners Guide to Software Test Design
ISBN: 158053791X
EAN: 2147483647
Year: 2003
Pages: 161
Authors: Lee Copeland © 2008-2020.
If you may any questions please contact us: