Black-box testing checks whether a function or program behaves correctly without examining its implementation. Vary inputs, observe outputs, and compare them with the expected behavior. section 6.2
A practical black-box test focuses on:
- The function specification: what inputs are allowed and what result is expected. section 6.2
- Common use cases and edge cases, including empty inputs, single items, negative values, ties, and invalid data. section 6.7
- Observed behavior rather than the code structure; implementation-specific tests belong to open-box testing. section 6.2 section 6.2.3
Testing a traffic-analysis function
For a function that returns the busiest weekday from traffic records, test ordinary lists, repeated weekdays, empty data, ties, and unusual visitor counts. These tests can reveal incorrect behavior without requiring knowledge of how the function loops through the records. Reading the implementation afterward can suggest further cases, such as first-element, last-element, or empty-list handling. section 6.7 section 6.2.3
Table 6.1 Brief overview of closed-box and open-box testing
|
Closed-box testing
|
Open-box testing
|
|---|---|
|
Requires understanding the function specification to test
|
Requires both the function specification and the code that implements the function to test
|
|
Tests don’t require an understanding of what the code does.
|
Tests should be tailored based on how the code was written.
|
|
Testers need not have technical expertise about the code they’re testing.
|
Testers need to be able to understand the code sufficiently well to determine which tests may be more important.
|
|
Tests the function by varying inputs and checking against expected results
|
Can test the function in the same way as closed-box testing but can also have more granular tests within a function
|
Compare black-box and open-box testing by required knowledge, tester expertise, and the granularity of possible tests. section 6.2
