White box testing traditionally refers to the use of program source code as a test basis, that is, as the basis for designing tests and test cases.
A looser definition says that "white box testing is based on internal structures of the software", but it is very unclear what kinds of "internal structure" are covered by this.
A looser definition says that "white box testing is based on internal structures of the software", but it is very unclear what kinds of "internal structure" are covered by this.
White-box testing usually involves tracing possible execution paths through the code and working out what input values would force the execution of those paths. Quite simple techniques exist by which the tester (usually the developer who wrote the code) can work out the smallest number of paths necessary to test, or "cover," all the code.
Examples include control flow problems (e.g., closed or infinite loops or unreachable code), and data flow problems (e.g., trying to use a variable which has no defined value).
White box testing is usually associated with component testing (i.e., unit testing), and with the concept that, at minimum, 100% of the component's code statements should be tested before the component is released for use ("100% code coverage").
References:
White box testing is usually associated with component testing (i.e., unit testing), and with the concept that, at minimum, 100% of the component's code statements should be tested before the component is released for use ("100% code coverage").
References:
