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:
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.
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.