Black and White Box Testing
Black Box Testing
Black box tests are those which the software under test is treated as a black box. You can't "see" into it. The test provides inputs and responds to outputs without considering how the software works. Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, one cannot be sure that all existent paths are tested.
White Box Testing
White box testing is used to test areas that cannot be reached from a black box level. White box testing (a.k.a. clear box testing, glass box testing or structural testing) uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing, every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).
Since the tests are based on the actual implementation, if the implementation changes, the tests probably will need to change, too. For example ICT needs updates if component values change, and needs modified/new fixture if the circuit changes. This adds financial resistance to the change process, thus buggy products may stay buggy. Automated optical inspection (AOI) offers similar component level correctness checking without the cost of ICT fixtures; however changes still require test updates.
While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test. Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are executed.
Typical white box test design techniques include:
- Control flow testing
- Data flow testing
Grid-Tools – Using Black or White Box Testing
Code coverage assumes you have access to the code and can see all the paths through the code. Black box testing reverses this whereby; you only have control over the input and the ability to monitor any output. Code coverage tends to be used in component testing, that is, where you have discrete sections of code with defined input and outputs. In a more typical test scenario, larger groups of components need to be tested as one unit. With the advent of complex SOA environments, complete end-to-end tests need to be designed and harder tasks implemented. In addition, testers need to balance the need for complete coverage with only limited time to test. The key challenge is to be more efficient and more effective.
From a practical point of view, having access to complete code gives you very useful information that can be used in designing tests. However, Grid-Tools believe a balanced approach needs to be used for both black and white box testing. From a tester’s point of view, this is all “just testing” with more or less information. Read our white paper on this topic.
