2
Agenda
White Box Testing– Introduction
– Techniques
Equivalence Partitioning
Coverage
– Function Coverage
– Statement Coverage
– Branch Coverage
– Decision Coverage
– Path Coverage
Automatic Testing
4
White Box
White-box testing is testing that takes into account
the internal mechanism of a system or component
(IEEE, 1990)
White-box testing is also known as structural testing,
clear box testing, and glass box testing
(Beizer, 1995)
The connotations of “clear box” and “glass box”
appropriately indicate that you have full visibility of
the internal workings of the software product,
specifically, the logic and the structure of the code
6
White Box
White Box is one of two parts of the basic
"box testing" approach of software testing
– It’s counter-part of black box testing which involves
testing from an external or end-user type perspective
– On the other hand, white box testing is based on the
inner workings of an application and revolves around
internal testing
Main goal of White Box testing is to derive and/or
select test cases based on an analysis of the internal
structure of a component or system
7
White Box
White box testing involves the testing of the software
code for the following :
– Internal security holes
– Broken or poorly structured paths in the coding
processes
– The flow of specific inputs through the code
– Expected output
– The functionality of conditional loops
– Testing of each statement, object and function on an
individual basis
8
White Box
Advantages
– Testing is more thorough, with the possibility of covering
most paths
– Optimization of code by revealing hidden errors and being
able to remove these possible defects
– Gives the programmer introspection because developers
carefully describe any new implementation
– Provides traceability of tests from the source, allowing
future changes to the software to be easily captured in
changes to the tests
– White box tests are easy to automate
– White box testing give clear, engineering-based, rules for
when to stop testing
– Testing can be commenced at an earlier stage
9
White Box
Disadvantages
– White-box testing brings complexity to testing because the
tester must have knowledge of the program, including being
a programmer.
– On some occasions, it is not realistic to be able to test every
single existing condition of the application and some
conditions will be untested
– The tests focus on the software as it exists, and missing
functionality may not be discovered
– Test script maintenance can be a burden if the
implementation changes too frequently
– Expensive as one has to spend both time and money to
perform white box testing
12
Equivalence Partitioning and Boundary Value Analysis
Like EV and BVA on Black Box, these strategies also
have a main purpose to reduce the number of
possible test cases
Similar to Black Box, we categorize and check the
possible inputs to several classes based on several
conditions
In white box, we have known the internal
implementation of the program, so we can perform
the analysis more accurate than before
For further information : black box testing slide
14
Coverage
In software testing, test coverage measures the
amount of testing performed by a set of test
– It will include gathering information about which parts of a
program are actually executed when running the test suite
in order to determine which branches of conditional
statements have been taken
In simple terms, it is a technique to ensure that your
tests are actually testing your code or how much of
your code you exercised by running the test
15
Coverage
The basic coverage measure is where the ‘coverage
item’ is whatever we have been able to count and
see whether a test has exercised or used this item
16
Coverage
What Test Coverage does
– Finding area of a requirement not implemented by a
set of test cases
– Helps to create additional test cases to increase
coverage
– Identifying a quantitative measure of test coverage,
which is an indirect method for quality check
– Identifying meaningless test cases that do not
increase coverage
17
Coverage
Types of coverage items
– Function / Method Coverage
– Statement Coverage
– Branch Coverage
– Decision Coverage
– Path Coverage
18
Function / Method Coverage
Method coverage is a measure of the percentage of
methods that have been executed by test cases
– Has each function (or subroutine) in the program been
called?
Undoubtedly, your tests should call 100% of your
methods.
– It seems irresponsible to deliver methods in your product
when your testing never used these methods
As a result, you need to ensure you have 100%
method coverage
You need to made a complete analysis into your
code
19
Statement Coverage
Statement coverage is a measure of the percentage
of statements that have been executed by test cases
– Has each statement in the program been executed?
Your objective should be to achieve 100% statement
coverage through your testing
20
Branch Coverage
Branch coverage is a measure of the percentage of
the decision points (Boolean expressions) of the
program have been evaluated as both true and false
in test cases
– Has each branch (also called DD-path) of each control
structure (such as in if and case statements) been
executed?
– For example, given an if statement, have both the true and
false branches been executed? Another way of saying this
is, has every edge in the program been executed?
We evaluate an entire Boolean expression as one
true-or-false predicate even if it contains multiple
logical-and or logical-or operators
21
Decision Coverage
Condition coverage is a measure of percentage of
Boolean sub-expressions of the program that have
been evaluated as both true or false outcome
[applies to compound predicate] in test cases
– Has each Boolean sub-expression evaluated both to true
and false?
– Condition coverage measures the outcome of each of these
sub-expressions independently of each other
– With condition coverage, you ensure that each of these sub
expressions has independently been tested as both true
and false
22
Coverage Example
Consider this code snippet
int check(int x, int y)
{
int z = 0;
if ((x>0) && (y>0))
{
z = x;
}
return z;
}
Coverage ?
• Function
• Statement
• Branch
• Condition
• Decision
Assume this function is a part of some bigger program and this program
was run with some test suite
23
Coverage Example
If during this execution function ‘check' was called at least
once, then function coverage for this function is satisfied.
Statement coverage for this function will be satisfied if it was
called with some specific input e.g. as check(1,1), as in this
case, every line in the function is executed including z = x;
Tests calling check(1,1) and check(0,1) will satisfy branch
coverage because, in the first case, the 2 if conditions are met
and z = x; is executed, while in the second case, the first
condition (x>0) is not satisfied, which prevents executing z = x;
Condition coverage can be satisfied with tests that call
check(1,0) and check(0,1).
– These are necessary because in the first cases, (x>0) evaluates to
true, while in the second, it evaluates false
– At the same time, the first case makes (y>0) false, while the
second makes it true
24
Coverage Example
Condition coverage does not necessarily imply branch
coverage directly
For example, consider the following fragment of code:
Condition coverage check each of the conditional parts
independently and the other side branch coverage check the
conditional part as one final statement based on the outer
conditional keyword
If (x>1) AND (y<=0) then
Blue part can be satisfied
at least by two tests:
• Value of x is more than
1 (2,3,….)
• Value of x is less than
1 (0,-1,….)
Yellow part can be satisfied
at least by two tests:
• Value of y is more than 0
(1,2,….)
• Value of y is less than 0
(-1,-2,….)
25
Path Coverage
Path coverage tests all the paths of the program
Path coverage is the strongest criterion of coverage
items in white box testing
– This is a comprehensive technique which ensures that all
the paths of the program are traversed at least once
– This technique is useful for testing the complex programs
Path coverage can be measured with basis path
testing approach
– Look into Software Engineering course’s slide
27
Automatic Testing
One of the advantages of white box testing is easy to
automation
Nowadays there are so many software testing tools
which we can use to
test our code