White-Box Testing
White-box testing is testing that takes into
account the internal mechanism of a
system or component (IEEE, 1990).
Motivation behind White-box Testing
• Unit testing, which is testing of individual hardware or software
units or groups of related units (IEEE, 1990).
• Integration testing, which is testing in which software components,
hardware components, or both are combined and tested to evaluate
the interaction between them (IEEE, 1990).
• Regression testing, which is selective retesting of a system or
component to verify that modifications have not caused unintended
effects and that the system or component still complies with its
specified requirements (IEEE, 1990).
Testing by Stubs & Drivers
A driver is a software module used to invoke a module
under test and, often, provide test inputs, control and
monitor execution, and report test results (IEEE, 1990)
A stub is a computer program statement substituting for
the body of a software module that is or will be defined
elsewhere (IEEE, 1990) or a dummy component or
object used to simulate the behavior of a real component
(Beizer, 1990) until that component has been developed.
Deriving Test Cases
2.1 Basis Path Testing
Basis path testing (McCabe, 1976) is a means
for ensuring that all independent paths through a
code module have been tested.
Basis Path Testing
• Requirement (Monopoly Game)
If a player wants to purchase a house, her or she must land on an
un-owned property cell and have enough money to buy the property.
If so, the player’s money is decremented by the purchase price,
obtain the house.
a) 1-2-7-8 (property owned, pay rent)
b) 1-2-7-9 (property owned, no money
for rent)
c) 1-2-3-4-5-6 (buy house)
d) 1-2-3 (don’t want to buy)
e) 1-2-3-4 (want to buy, don’t have
enough money)
Deriving Test Cases
2.2 Equivalence Partitioning
A technique that partitions the space of possible
program inputs/outputs into a finite set of
equivalence classes.
Guidelines for Partitioning
Ranges: if a requirement specifies a range then
three equivalence classes are required, one valid and
two invalid.
Numbers: if a requirement specifies a number then
three equivalence classes are required, one valid and
two invalid.
Sets: if a requirement specifies a set then two
equivalence classes are required, one valid and one
invalid.
Deriving Test Cases
2.3 Boundary Value Analysis
Boundary value analysis extends equivalence
partitioning by focusing attention on equivalence
class boundaries.
Equivalence Partitioning/Boundary Value
Analysis
Example:
A person might want to buy a house, but may or may not have
enough money. Considering EP/BVA, we would want to ensure our
test cases include the following:
1. house costs $100, have $200 (equivalence class “have enough
money”)
2. house costs $100, have $50 (equivalence class, “don’t have
enough money”)
3. house costs $100, have $100 (boundary value)
4. house costs $100, have $99 (boundary value)
5. house costs $100, have $101 (boundary value)
3 Control-flow/Coverage Testing
Coverage is a measure of the
completeness of the set of test cases.
3.1 Method Coverage
3.2 Statement Coverage
3.3 Decision/Branch Coverage
3.4 Condition Coverage
Sample Code for Coverage Analysis
3.1 Method Coverage
Method coverage is a measure of the
percentage of methods that have been
called by your test cases.
Test Case 1:
The method call
foo(0, 0, 0, 0, 0.)
3.2 Statement Coverage
Statement coverage is a measure of the
percentage of program statements that are
run when your tests are executed.
3.2 Statement Coverage
Test Case 2:
The method call
foo(1, 1, 1, 1, 1.)
Expected return value of 1.
100% statement
coverage achieved
3.3 Decision/Branch Coverage
Decision or branch coverage is a measure
of how many of the Boolean expressions
(Decision points) of the program have
been evaluated as both true and false in
the testing.
3.3 Decision/Branch Coverage
Line # Predicate True False
3 (a == 0) Test Case 1
foo(0, 0, 0, 0, 0)
return 0
Test Case 2
foo(1, 1, 1, 1, 1)
return 1
7 ((a==b) OR ((c == d) AND bug(a) )) Test Case 2
foo(1, 1, 1, 1, 1)
return 1
Two decision points – one on line 3 and the other on line 7.
Line 3: if (a == 0) {
Line 7: if ((a==b) OR ((c == d) AND bug(a) )) {
75% Branch Coverage
3.3 Decision/Branch Coverage
Test Case 3:
To bring us to 100% branch coverage:
foo(1, 2, 1, 2, 1).
Line # Predicate True False
3 (a == 0) Test Case 1
foo(0, 0, 0, 0, 0)
return 0
Test Case 2
foo(1, 1, 1, 1, 1)
return 1
7 ((a==b) OR ((c == d) AND bug(a) )) Test Case 2
foo(1, 1, 1, 1, 1)
return 1
Test Case 3
foo(1, 2, 1, 2, 1)
100% Branch Coverage
3.4 Condition Coverage
Condition coverage reports the true or
false outcome of each Boolean subexpression of a compound predicate.
Sample Code for Coverage Analysis
3.4 Condition Coverage
Predicate True False
(a==b) Test Case 2
foo(1, 1, x, x, 1)
Return value 0
Test Case 3
foo(1, 2, 1, 2, 1)
Division by zero!
(c==d) Test Case 3
foo(1, 2, 1, 2, 1)
Division by zero!
Bug(a)
50% Conditional Coverage
Test Case 4:
To address test (c==d) as true:
foo(1, 2, 1, 1, 1)
Test Case 5:
foo(3, 2, 1, 1, 1),
3.4 Condition Coverage
Predicate True False
(a==b) Test Case 2
foo(1, 1, x, x, 1)
Return value 0
Test Case 3
foo(1, 2, 1, 2, 1)
Division by zero!
(c==d) Test Case 4
foo(1, 2, 1, 1, 1)
return value 1
Test Case 3
foo(1, 2, 1, 2, 1)
Division by zero!
Bug(a) Test Case 4
foo(1, 2, 1, 1, 1)
return value 1
Test Case 5
foo(3, 2, 1, 1, 1)
Division by zero!
100% Conditional Coverage
Code Coverage Tool – Java Screenshots
Cost of defect throughout the Life Cycle
Software Testing Tools and Techniques 