Blackbox, Whitebox and Greybox Testing
In “black box” testing the internal behaviour of Device Under Test (DUT) is not concerned. Test data is fed into the DUT and the received output data is compared to the expected data. With this approach the goal is to find circumstances in which the program does not behave according to its specification. In theory an exhaustive input testing that finds all the errors/issues requires to test with all possible inputs in the operational area. This can easily grow the number of test cases in practice to infinity. Therefore, it is essential in “black box” testing to design the test cases in a way that the number of test cases is an acceptable level of expectation and the yield is as large as possible.
In “white box” testing the test data and test cases are structured from the internal structure of the program. The emphasis on “white box” testing is often on overall coverage testing. This approach aims to test that every statement in the program executes at least once or every logical branch gets values true and false at least once during the test run. In theory “white box” testing suffers the same kind of infinity problem as with “black box” testing; exhaustive path testing, in which every branching combination is tested, leads quickly to practically to an infinite number of test cases. Thus, in practice compromises must be performed
There is also a combination of “white box” and “black box” testing that is called “grey box” testing. It is “black box” type method that, in addition to the module specifications, has some information from the actual code of the DUT as a basis for test case design parameters.
“Unit” testing is the lowest level of the software testing process in which individual “units” of software is tested. A “unit” is defined as the smallest testable part of software, which is usually a single function. This level of testing is generally performed by developers in parallel with a development process that is a part of test driven development practice.
Integration testing is a level of software testing process where the units are combined and tested as functional groups. At this level the emphasis is on testing the interface and interaction between the units.
System testing is a higher level of the software testing process where a complete integrated system is tested. On embedded systems this phase is usually carried out on prototypes where the functionality of the embedded software in the destination platform is tested in “black box” method.
Acceptance testing is the final stage of testing where the final product is put under test and the design is accepted for release.