White box testing (structural testing)

White box testing is conducted to check the internal

structure of a program. To perform white box testing the
tester should have a through knowledge of the program code
and the purpose for which it is developed.

The basic strength of this testing is that the entire software

implementation is included while testing is performed.

The objective of white box testing is to ensure that the test

cases exercise each path through a program .The test cases
ensure that all internal structures in the program are
developed according to design specifications.
• The test cases also ensure that
• All independent paths within the program have been
executed at least once.
• All internal data structures are exercised to ensure validity.
• All loops are executed at their boundaries and within
operational bounds.
• All the segments present between the control structures are
executed at least once.
• Each branch is exercised at least once.
• All the branches of the conditions and the combinations of
these conditions are exercised at least once.
• The different types of white box testing are
• Basis path testing
• Control structure testing
• Mutation testing
• Basis path testing
• Basis path testing enables the software tester to generate test
cases in order to develop a logical complexity of a component
based design
• This measure is used to specify the basis set of execution
paths.
• Here logical complexity refers to the set of paths required to
execute all statements present in the program .
• Cyclomatic complexity (or conditional complexity) is a
software metric (measurement). It was developed by Thomas
J. McCabe in 1976 and is used to measure the complexity of a
program. It directly measures the number of linearly
independent paths through a program's source code.
• Creating flow graph
• A flow graph is used to show the logical control flow within a
program.
 Flow graph notations

sequence
if

while
 …

case
until
• A flow graph uses different symbols .Circles represent nodes
which are used to depict the procedural statements present in
the program .A series of process boxes and a decision
diamond in a flow chart can be easily mapped into a single
node. Arrows represent edges. Which are used to depict the
flow of control within a program. In a flow graph the area
bounded by edges and nodes is known as region.
• While counting regions the area outside the flow graph is also
counted as a region
 1
R4
R3
1 9 2

9 3 7
2 R1

3 4 R2 5

7
4 5
6

6 8
8
• Independent paths
• P1:1-9
• P2:1-2-7-8-1-9
• P3:1-2-3-4-6-8-1-9
• P4:1-2-3-5-6-8-1-9
• Cyclomatic complexity
• 1.total number of regions
• 2. cc= E- N+2
• 3.CC = P+1( number of predicate nodes +1)
• Predicate node is a node that contains condition.
• In the above example the cyclomatic complexity is calculated
as CC= 11- 9+2 = 4
• Number of regions =4
• C=using the formula cc = p+1 cyclomatic complexity is
calculated as cc= 3+1 =4
• Example:
• Draw the flow graph of the program
• Procedure greater
• Integer :a, b, c=0;
• Enter the value of a;
• Enter the value of b;
• If a>b then
• C=a;
• Else
• C=b;
end greater
• Flow graph
Cc= 2 regions
1
Or
Cc= 6 edges -6nodes +2 = 2
R2 Or
2
Cc = 1 predicate node +1 = 2

R1
4 5

6
 Control structure testing

• Control structure testing is used to enhance the coverage area

by testing various control structures present in the program.
The various types of testing performed under control
structure testing are
• 1.conditon testing
• 2.data flow testing
• 3.loop testing
• Condition testing
• Condition testing ensures that the logical conditions and
decision statements are free from errors. The common types
of logical conditions that are tested using condition testing
are:
 A relational expression such as E1 op E2
Where E1 and E2 are arithmetic expressions and op is an
operator
 A simple condition such as any relational expression preceded
by a not operator.
 A compound condition which is composed of one or more
simple conditions.
 A Boolean expression consisting of operands and Boolean
operator.
• Data flow testing
• It is a testing technique in which test cases are designed to
execute definition and uses of variables in the program.
• To perform data flow testing a definition-use graph is
constructed by associating the variables with nodes and edges
in the control flow graph .once these variables are attached
with nodes and edges of the control flow graph test cases can
easily determine which variable is used in which part of the
program.
Definition use graph
 Definition/Use

• A definition is a location where a value for a variable is

stored into memory.
• Assignment, input, parameter passing, etc.
• A use is a location where a variable’s value is accessed.

• p-use: a use that occurs in a predicate expression, i.e., an

• expression used as a condition in a branch statement
• c-use: a use that occurs in an expression that is used to
• perform certain computation
• Data Flow Anomalies
• Data flow anomalies represent the rules which
help to detect improper use of data. The
notation used to define these anomalies
•
• d – defined, created, initialized
• k – undefined, killed
• u – used
• c – Computation use
• Loop testing
• Loop testing is used to check the validity of loops present in
the program modules
• There exist four types of loops
• Simple loop: refers to a loop that has no other loops in it.
• Nested loops: loops within loops are known as nested loops
• Concatenated loops: Refers to the loops which contain several
loops that may or may not depend on each other.
• Unstructured loops: This type of loop should be redesigned so
that the use of structured programming constructs can be
reflected.
 Nested loops
Concatenated Loops
Simple Loop

Unstructured loop
• Mutation testing
• Mutation testing is white box method where errors are
purposely inserted into a program to verify whether the
existing test case is able to detect the error or not .In this
testing , mutants of the program are created by making some
changes in the original program.
• Steps in mutation testing
• 1.create mutants of a program
• 2.Check both program and its mutants using test cases
• find the mutants that are different from the main program
• ,that is mutants that produce outputs that are different from
the outputs produced by the program.

• Find mutants that are equivalent to the program ,that is

mutants that produce same outputs as produced by the
program.
• Calculate the mutation score using the formula
• M= D/(N-E)
• M= mutation score
• N total number of mutants of the program
• D number of mutants different from the main program
• E total number of mutants that are equivalent to the main
program
• Repeat steps 1 to 5 till mutation score is 1
• Black Box Testing (Functional testing)
• Black box testing checks functional requirements and
examines the input and output data of these requirements
The black box testing is used to find the errors listed below:
 interface errors such as functions which are unable to send
or receive data to/from other software
 Incorrect functions that lead to undesired output when
executed.
 Missing functions and erroneous data structures
 Erroneous databases
• Incorrect conditions due to which the functions produce
incorrect outputs when they are executed.
• Termination errors
• Such as certain conditions due to which a function enters a
loop that forces it to execute indefinitely.
• Various methods in black box testing
• 1.Equivalence class partitioning
• This method tests the validity of outputs by dividing the input
domain into different classes of data using which test cases
can be easily generated.
• WHAT IS EQUIVALENCE PARTITIONING?
• Concepts: Equivalence partitioning is a method for
deriving test cases.
• In this method, classes of input conditions called
equivalence classes are identified such that each
member of the class causes the same kind of
processing and output to occur.
• In this method, the tester identifies various
equivalence classes for partitioning.
• A class is a set of input conditions that are is likely to
be handled the same way by the system.
• If the system were to handle one case in the class
erroneously, it would handle all cases erroneously
• DESIGNING TEST CASES USING EQUIVALENCE PARTITIONING To
use equivalence partitioning, you will need to perform two steps
• Identify the equivalence classes
• Design test cases STEP 1: IDENTIFY EQUIVALENCE CLASSES :Take
each input condition described in the specification and derive at
least two equivalence classes for it. One class represents the set
of cases which satisfy the condition (the valid class) and one
represents cases which do not (the invalid class ) Following are
some general guidelines for identifying equivalence classes:
• a) If the requirements state that a numeric value is input to the
system and must be within a range of values, identify one valid
class inputs which are within the valid range and two invalid
equivalence classes inputs which are too low and inputs which
are too high.
• For example, if an item in inventory can have a
quantity of - 9999 to + 9999, identify the following
classes:
• 1. one valid class: (QTY is greater than or equal to -
9999 and is less than or equal to 9999). This is
written as (- 9999 < = QTY < = 9999)
• 2. the invalid class (QTY is less than -9999), also
written as (QTY < -9999)
• 3. the invalid class (QTY is greater than 9999) , also
written as (QTY >9999)
• B)If the requirements state that the number of items input by
the system at some point must lie within a certain range,
specify one valid class where the number of inputs is within
the valid range, one invalid class where there are too few
inputs and one invalid class where there are, too many inputs.
• For example, specifications state that a maximum of 4
purchase orders can be registered against anyone product.
The equivalence classes are : the valid equivalence class:
(number of purchase orders is greater than or equal to 1 and
less than or equal to 4 , also written as (1 < = no. of purchase
orders < = 4) the invalid class (no. of purchase orders> 4) the
invalid class (no. of purchase orders < 1)
• C)If the requirements state that a particular input item match
one of a set of values and each case will be dealt with the
same way, identify a valid class for values in the set and one
invalid class representing values outside of the set.
• For example, if the requirements state that a valid province
code is ON, QU, and NB, then identify : the valid class code is
one of ON, QU, NB the invalid class code is not one of ON, QU,
NB
• Example
• 1.suppose that a program p takes an integer X
as input
• 2.Now for this input we have X<0 and X>=0
• 3.If x<0 then the program is required to
perform task T1 and if X>=0 then task T2 is
performed.
• 4.The input domain is as large as X and it can assume a large
number of values. Therefore input domain P can be
partitioned into two equivalence classes and all tests inputs in
the x<0 and x>= 0 equivalence classes are considered to be
equivalent
• 5.Now independent test cases arte developed for X<0 and
X>=0
• Boundary value analysis
• Boundary value analysis is a software testing design technique
used to determine test cases covering off-by-one errors.
• It is a black box test design technique where test cases are
designed based on boundary values .Boundary value can be
defined as an input value or output value which is at the edge
of an equivalence partition.
 Boundary value analysis
• It’s widely recognized that input values at the extreme ends of
input domain cause more errors in system.
• More application errors occur at the boundaries of input
domain.
• ‘Boundary value analysis’ testing technique is used to identify
errors at boundaries rather than finding those exist in center
of input domain.
• Boundary value analysis is a next part of Equivalence
partitioning for designing test cases where test cases are
selected at the edges of the equivalence classes.
• Test cases for input box accepting numbers
between 1 and 1000 using Boundary value analysis:
1) Test cases with test data exactly as the input
boundaries of input domain i.e. values 1 and 1000 in
our case.
• 2) Test data with values just below the extreme
edges of input domains i.e. values 0 and 999.
• 3) Test data with values just above the extreme
edges of input domain i.e. values 2 and 1001.
 Definition of Orthogonal Array Testing Strategy

• Orthogonal Array Testing Strategy (OATS) is a systematical, statistical way

of testing pairwise interactions by deriving a suitable small set of test
cases from a large number of scenarios.

(VTB, 2008)
Orthogonal array testing
Orthogonal array testing can be defined as a mathematical
technique that determines the variations of parameters that
need to be tested. This testing is performed when limited data
is to be given as input. it is helpful in finding errors in the
software where incorrect logic is applied.
• Runs: the number of rows in the array. This directly translates
to the number of test cases that will be generated by the
OATS technique.
• Factors: the number of columns in an array. This directly
translates to the maximum number of variables that can be
handled by this array.
• Levels: the maximum number of values that can be taken on
by any single factor. An orthogonal array will contain values
from 0 to Levels-1.
 Orthogonal array testing-common terms
• Runs; number of rows which translates to test
cases
– Since the rows represent an experiment (test) to
be run, it is a goal to minimize the number of row
as much as possible
• Factors; number of columns which is the
number of variables
• Levels; max number of values for a factor
( 0 – levels-1 )
 Technique
• First, determine how many independent
variables you need to test for interaction
(factors)
• Second, determine how many values (levels)
each of these variables will have
• Next, find an orthogonal array that maps to
this requirement
– At least as many factors from step 1
– At least as many levels from step 2
 Technique
• Next, map the factors and levels on to the
array
• Choose values for the “left over” levels
• Create test cases for each run
 The OAT Theory

• OAT can be used to reduce the number of combinations and

provide maximum coverage with a minimum number of test
cases.

• OAT is an array of values in which each column represents a

variable - factor that can take a certain set of values called
levels. Each row represents a test case.

• In OAT, the factors are combined pairwise rather than

representing all possible combinations of factors and levels.

• Orthogonal arrays are two dimensional arrays of numbers

which possess the interesting quality that by choosing any
two columns in the array you receive an even distribution of
all the pairwise combinations of values in the array.
 Simple OAT Example

• Consider three parameters – A, B, and C.

• Parameters A, B, and C each have positive

values – 1, 2, and 3.

• Testing all combinations of the three

parameters would involve executing a total of
27 test cases.
 Simple OAT Example (cont’d)

• With the way programming works, a fault will most

likely depend on the values of two parameters, not
three.
• The fault might occur for each of these three test
cases: A=1, B=1, C=1, A=1, B=1, C=2, and A=1, B=1,
C=3.
• Not necessary to run all 27 scenarios, 9 test cases is
suffice.
• The 9 scenarios outlined in Table 1 (on the next
screen) address all possible pairs within the three
parameters.
 Pair-wise Combination of Parameters

• All possible pairwise combinations between parameters A and B, B and C,

and C and A are displayed in Table 1.
(
• The given L9 Orthogonal Array assess result of test cases as
follows
Single Mode Faults - Single mode faults occur only due to one
parameter. For example, in above Orthogonal array if test
cases 7, 8 and 9 show error, we can expect that value 3 of
parameter 1 is causing the error. Likewise we can detect as
well as isolate the error.
Double Mode Fault - Double mode fault is caused by the two
specific parameters values interacting together. Such an
interaction is a harmful interaction between interacting
parameters.
Multimode Faults - More than two interacting components if
produce the consistent erroneous output, then it is a
multimode fault. Orthogonal array detects the multimode
faults.
 Steps in orthogonal array testing
• Find all the independent variables that need to be
tested for interaction
• Decide The maximum number of values that each
independent variable follows.
• Find an orthogonal array that has a minimum
number of runs
• Map factors and values on to the array
• Choose values for left over levels that is the levels
for which there is no value mapped in the array
• Convert runs into test cases
• To understand orthogonal array testing properly
let us consider the example of a web page .
• Web page consists of three sections
• Top
• Middle
• Bottom
• Factors =3 since there are three sections
• Levels =2 as variables can have either hidden or
visible state
• Draw orthogonal array = 23 as there are two
levels and three factors.
• Four test cases that can be generated are:
• Home page is displayed and all other sections
are hidden
• Home page and all other sections rather than
top section are displayed
• Home page and all other sections rather than
the middle section are displayed
• Home page and all other sections rather than
bottom section are displayed
 Orthogonal array before mapping factors

Factor1 Factor 2 Factor3

Run1 0 0 0

Run2 0 1 1

Run3 1 0 1

Run4 1 1 0
 Orthogonal array after mapping factors

Test1 Hidden Hidden Hidden

Test2 Hidden Visible Visible

Test3 Visible Hidden Visible

Test4 Visible Visible Hidden

 Model-based testing
It is application of Model based design for designing and
optionally also executing artifacts to perform software
testing.
Models can be used to represent the desired behavior of a
System Under Test (SUT), or to represent testing strategies
and a test environment. The picture on the right depicts the
former approach.
A model describing an SUT is usually an abstract, partial
presentation of the SUT's desired behavior.
Test cases derived from such a model are functional tests
on the same level of abstraction as the model. These test
cases are collectively known as an abstract test suite.
• An abstract test suite cannot be directly
executed against an SUT because the suite is
on the wrong level of abstraction. An
executable test suite needs to be derived from
a corresponding abstract test suite. The
executable test suite can communicate
directly with the system under test.