White box test
The term white box test (more rarely also glass box test ) describes a method of software testing in which the tests are developed with knowledge of the internal functioning of the system to be tested. In contrast to the black box test, a look at the source code is permitted for this test. Ie it is checked on the code.
An example of a white box test is process-related testing ( control flow-oriented test method ) in which the process graph is in the foreground. The quality criterion of the test is to ensure that test cases meet certain sufficiency criteria with regard to the coverage of the source code . Common are u. a. the following dimensions (or quality criteria):
- Line coverage : Execution of all source code lines
- Statement coverage or node coverage : Execution of all statements
- Branch coverage or edge engagement : Going through all possible edges of branches of the control flow
- Condition coverage or term coverage (several variants): Run through all possible decisive assignments for logical expressions in conditions
- Path coverage (several variants): Consideration of the paths through a module
The number of test cases required for the individual dimensions differs e.g. T. clearly. Edge overlap is generally seen as the minimum test criterion. Depending on the type and structure of the software to be tested, other dimensions can be useful for a system as a whole or for modules.
Even if a software system has been successfully tested against a sufficiency criterion, that does not rule out that it contains errors. This is due to the nature of the white box test and can have one of the following causes:
- The white box test does not derive test cases from the specification of the program, but from the program itself. Only the correctness of a system can be tested, not whether it meets the required semantics.
- Even if all program paths have been tested, this does not mean that a program is working without errors. The case that edges are missing in the graph of the control flow is not recognized.
In summary, it can be said that white box tests alone are not enough as a test method. A useful test suite should combine black box tests and white box tests. After the coverage of the test cases of the black box test has been measured (using a suitable tool), new test cases are set up by looking at the code parts that are not covered in order to increase the coverage.
If you want to test a system in its subsystems, you need knowledge of the internal functioning of the system to be tested. White box tests are particularly suitable for localizing errors that have occurred, i.e. That is, to identify the component causing the error and, as a regression test, to avoid a recurrence of the error already in the component.
Because the developers of the tests must have knowledge of the inner workings of the system under test, white box tests are developed by the same team, and often by the same developers, as the components to be tested. Special test departments are usually not used for white box tests, since the benefit of testers assigned specifically for this task is usually eliminated by the effort involved in familiarizing with the system.
Comparison with black box tests
White box tests are used to reveal and localize errors in the subcomponents, but due to their methodology they are not a suitable tool for uncovering errors in relation to the specification . The latter requires black box tests. It should also be borne in mind that two components which, taken individually, work correctly in accordance with their respective partial specifications, do not necessarily form a correct unit in accordance with the overall specification. This can be more easily determined by black box tests than by white box tests.
Compared to black box tests , white box tests are much easier to carry out because they do not require any special organizational infrastructure.
Advantages of white box testing over black box testing
- Testing of subcomponents and the internal functionality
- Less organizational effort
- Automation through good tool support
Disadvantages of white box tests compared to black box tests
- Compliance with specification not checked
- Possibly testing "around bugs"
It should also be mentioned that the distinction between black box test and white box test partly depends on the perspective. From the point of view of the overall system, testing a subcomponent is a white box test, since from an external perspective there is no knowledge of the system structure and thus the existing subcomponents for the overall system. From the subcomponent's point of view, the same test can, under certain circumstances, be viewed as a black box test if it is developed and carried out without knowledge of the internals of the subcomponent.
literature
- Andreas Spillner, Tilo Linz: Basic knowledge of software testing - Basic knowledge of software testing: Training and further education to become a Certified Tester: Foundation Level according to the ISTQB standard. 3rd, revised and updated edition, dpunkt.verlag GmbH, Heidelberg 2005, ISBN 3-89864-358-1 .
- Lee Copeland: A Practitioner's Guide to Software Test Design. first printing, Artech House Publishers, Norwood MA, USA 2003, ISBN 1-58053-791-X .
- BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Standard for Software Component Testing ( ZIP ; 340 kB), Working Draft 3.4, April 27, 2001.