White-box testing (also known as clear box testing, glass box testing, and transparent box testing and structural testing) is a method of testing software that tests internal structures or workings of an application.
While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level.
White-box test design techniques include:
• Control flow testing
• Data flow testing
• Branch testing
• Path testing
• Statement coverage
• Decision coverage
Control flow testing:
The “Basic idea” behind Control Flow Testing is to “select paths” as test cases and come up with the inputs (input values) to execute through those paths. It includes the following 4 steps:
Build the Control Flow Diagram (CFD)
Select the paths in the (CFD) to cover for the testing
Pick or develop the input values for testing the chosen paths
Analyze the test results
Data flow testing: Data Flow testing is basically a white box testing approach. In this we test the variables definitions and their uses in the program to find out the anomalies like:
1. Variable defined but not used.
2. Variable used but not defined.
3. Variable has been defined twice before using.
Branch Coverage:
-Achieved when every branch from a node is executed at least once by a test suite.
- Also known as decision coverage or all-edge coverage.
-Improve on statement coverage by requiring that each branch be taken at least once. Hence each outcome of a predicate expression is exercised at least once (i.e., true and false).
- However, it is limited by the fact that it treats a compound predicate as a single statement: branch coverage may be achieved without exercising all of the conditions
Example:
int foo(int x)
{
if (a==b || (x==y && isEmpty()))
{ ++x; }
else { –x; }
return x;
}
- Branch coverage misses several of the possible entry-exit paths. Branch coverage may be
Achieved using:
1.a ==b
2.a !=b and x !=y
Without ever exercising this.isEmpty()
Path: starts with the entry node, follows through a number of links and nodes, and ends up in an exit node; we are interested “logical” paths.
Statement coverage:
-Achieved when all statements in a method have been executed at least once.
-Also known as line coverage, segment coverage, or basic block coverage.
-Segment and basic block coverages count segments instead of individual statements.
-Segment coverage ensures that all code segments defined in the CFG are covered.
Example:
int foo(int x) {
if (a==b) { ++x; }
else { –x;}
return x;
}
Statement coverage is achieved by having test cases involving both:
1.a==b
2.a != b
Test Coverage Overview:
-Test coverage attempts to address questions about when to stop testing, or the amount of testing that is enough for a given program.
-Ideal testing is to explore exhaustively the entire test domain, which in general is impossible.
-Some code may never be executed due to the possibility of missing test cases.
-Effectiveness of test suites can be established only by knowing what code is, or isn’t executed.
Review Questions:
-Example int foo(int x) { if (a==b || (x==y && isEmpty())) { ++x; } else { –x; } return x; }
Mark each of the following as true or false:
(1)Segment coverage implies statement coverage .
(2)Branch coverage implies segment coverage
(3)Branch coverage implies multiple conditional coverage
(4)Multiple conditional coverage implies branch coverage
(5)Path coverage implies branch coverage
(6)All def-use path coverage implies all definition coverage
Result: T T F T T T
-What test cases will give 100% branch coverage? -Does this achieve 100% multiple conditional coverage?
-Which coverage criteria should be used here to maximize coverage?
