Open-box testing examines a program’s implementation to find likely failure points and design tests tailored to its structure. Unlike closed-box testing, it uses both the function specification and the code, while still varying inputs and checking expected results. section 6.2 section 6.2.3
Use the code as a source of test ideas:
- Inspect conditions for boundary mistakes, such as using >= when > is required. section 6.2.3
- Trace loops and test their first element, last element, empty input, and other edge cases. section 6.2.3
- Combine structure-specific tests with closed-box tests to strengthen coverage. section 6.2
Finding a hidden longest-word error
Suppose longest_word should return the first word when several words tie for maximum length. Reading its loop reveals the condition len(words[i]) >= len(longest). Testing ['cat', 'dog', 'me'] exposes the error: the function returns 'dog' instead of 'cat'. Changing >= to > preserves the first longest word. The same code inspection also suggests testing an empty list and lists whose relevant word appears first or last. 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 the information, expertise, and test granularity required by closed-box and open-box testing. section 6.2
