Black box testing
Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements.Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include:
- equivalence partitioning
- boundary value analysis
- all-pairs testing
- fuzz testing
- model-based testing
- traceability matrix etc.
White box testing
White box testing, however, is when the tester has access to the internal data structures, code, and algorithms.
Types of white box testing
The following types of white box testing exist:
- code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once.
- mutation testing methods.
- fault injection methods.
- static testing - White box testing includes all static testing.
Code completeness evaluation
White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.
Two common forms of code coverage are:
- function coverage, which reports on functions executed
- statement coverage, which reports on the number of lines executed to complete the test.
They both return a coverage metric, measured as a percentage.
Grey Box Testing
In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level.
Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values.
Non Functional Software Testing
Special methods exist to test non-functional aspects of software.
- Performance testing checks to see if the software can handle large quantities of data or users.
- Usability testing is needed to check if the user interface is easy to use and understand.
- Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers.
- internationalization and localization is needed to test these aspects of software, for which a pseudolocalization method can be used.