Chapter 18

 Testing Conventional Applications

1
Introduction
 The primary objective for test-case design is to
derive a set of tests that have the highest
likelihood for uncovering errors in software.

 To accomplish this objective, two different

categories of test-case design techniques are
used: white-box testing and black-box testing.

2
 Software Testing
•Basis path
•Graph-
testing black-box
•Condition
white-box Based
methods methods Testing
testing •Equivalence
•Data flow partitioning
testing •Boundary
•Loop testing value
analysis
•Orthogonal
array testing
•Model-

Methods based
testing

Strategies

3
White-box testing(glass-box
testing)
 White-box tests focus on the program control structure.

 white-box testing methods, derive test cases that

 (1) guarantee that all independent paths within a module have
been exercised at least once,
 (2) exercise all logical decisions on their true and false sides,
 (3) execute all loops at their boundaries and within their
operational bounds, and
 (4) exercise internal data structures to ensure their validity

4
I) BASIS PATH TESTING
1)Flow graph
 The flow graph depicts logical control flow using the notation
illustrated in next slide.

 Flow graph is generated from codes. You will see the example later.
 Flow graph notation
Sequence UNTIL

IF
IF

CASE

WHILE

6
Flow graph

7
Flow graph
 The arrows on the flow
graph, called edges or Region 4
edges
links, represent flow of Region 6
control and are analogous
to flowchart arrows. Region 5
 Area bounded by edges Region 3
and nodes are called
regions.
 When counting regions, we Region 1

include the area outside the

graph as region. Region 2

8
Flow graph, independent paths,
Cyclomatic Complexity and test cases

 Step – 1: Construct the flow graph from the source

code or flow charts.
 Step – 2: Identify independent paths.
 Step – 3: Calculate Cyclomatic Complexity, V(G).
 Step – 4: Design the test cases.

9
Example 1
Step 1: Binary search flow graph
1

3
Predicate
nodes
4

bottom > top while bottom <= top

5
Predicate Predicate
nodes nodes
6 R2
R1

elemArray [mid] != key

7 11
elemArray
elemArray [mid] > key elemArray [mid] < key
[mid] = key

8 12 13
R3
9 R4

14 10
Example 1
Step 2: Identify independent paths

Path 1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
Path 2: 1, 2, 3, 4, 5, 14
Path 3: 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
Path 4: 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
 Test cases should be derived so that all of these
paths are executed
 A dynamic program analyser may be used to check
that paths have been executed
Example 1
Step 3: Calculate cyclomatic complexity,
V(G)
 Cyclomatic complexity can be used to count the number
of independent paths.
 A number of industry studies have indicated that the
higher V(G), the higher the probability or errors.
Example 1
Step 3: Calculate cyclomatic complexity,
V(G)
Calculation of V(G) by three methods:

Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 16 – 14 + 2 = 4

Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = 3 + 1 = 4 (The predicate nodes are labeled)

Method 3
V(G) = Number of regions = 4
Example 2
Step 1: Drawing flow graph from simplePredicate
code nodes

1
void foo (float y, float a *, int n) 1
{
float x = sin (y) ; R1

if (x > 0.01) 2
2 3
z = tan (x) ;
else
3 Predicate 4
R3
z = cos (x) ; nodes

4 i = 0 ; i <5 x ; + +6i) {
for (int 5 R2
a[i] = a[i] * z ;
6
Cout < < a [i]; } 6
} 6
7
7
14
Example 2
Step 2: Identify independent paths
• There are 3 paths in this program which are
independent paths and they form a basis-set.
• These paths are described below
Path 1: 1 – 2 – 4 – 5 - 7
Path 2: 1 – 3 – 4 – 5 - 7
Path 3: 1 – 2 – 4 – 5 – 6 – 5 – 7
Path 4: 1 – 3 – 4 – 5 – 6 – 5 – 7
• We must execute these paths at least once in order to test
the program thoroughly.
• Accordingly we can design the test cases (no of test cases
=> 3)

15
Example 2
Step 3: Calculate cyclomatic complexity,
V(G)
Calculation of V(G) by three methods:

Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 8 – 7 + 2 = 3

Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = 2 + 1 = 3 (The predicate nodes are labeled)

Method 3
V(G) = Number of regions = 3

16
Example 3
Step 1: Flow graph
1

3
8
4 5

6
7

9
Example 3
Step 2: Identify independent paths
1

3
8
4 5

6
7 Path 1: 1-9
Path 2: 1-2-8-7-1-9
Path 3: 1-2-3-4-6-7-1-9
9 Path 4: 1-2-3-5-6-7-1-9
 Example 3
Step 3: Calculate cyclomatic complexity, V(G)

V(G) = E - N + 2
V(G) = 11 - 9 + 2 = 4

E= no. of edges,
2 N= no. of nodes

1
3
4
V(G) = P + 1
V(G) = 3 + 1 = 4

P= no. of predicate
nodes (conditions) # Regions = 4
Example 4
Step 1: Flow chart

3
4
5 6

20
 Example 4
Step 2: Identify independent paths

Predicate
1
nodes Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
2
Path 4: 1,2,4,7,2,4,...7,8
R1
3
4
5 6 R4
R2

R3
Predicate
nodes edges
7

Predicate
nodes
8

21
Example 4
Step 3: Calculate cyclomatic complexity,
V(G)
Calculation of V(G) by three methods:

Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 9 – 7 + 2 = 4

Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = 3 + 1 = 4 (The predicate nodes are labeled)

Method 3
V(G) = Number of regions = 4

22
Deriving Test Cases
 Using the design or code as a foundation, draw
a corresponding flow graph.
 Determine the cyclomatic complexity of the
resultant flow graph.
 Determine a basis set of linearly independent
paths.
 Prepare test cases that will force execution of
each path in the basis set

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23
Graph Matrices
 A data structure useful for developing a software
tool that assists in basis path testing.
 A graph matrix is a square matrix whose size (i.e.,
number of rows and columns) is equal to the
number of nodes on a flow graph
 Each row and column corresponds to an identified
node, and matrix entries correspond to
connections (an edge) between nodes.
 By adding a link weight to each matrix entry, the
graph matrix can become a powerful tool for
evaluating program control structure during testing

24
Graph Matrices
 The link weight provides additional information about
control flow. In its simplest form, the link weight is 1
(a connection exists) or 0 (a connection does not
exist). But link weights can be assigned other, more
interesting properties:
 The probability that a link (edge) will be execute.
 The processing time expended during traversal of a
link
 The memory required during traversal of a link
 The resources required during traversal of a link.

25
Graph Matrices
Connected
1 to node
Node 1 2 3 4 5
a
1 a
3
e 2
b
3 d b
5 4 d
f 4 c f
c
g 5 g e
2

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26
II) Control Structure Testing

1) Condition testing
 Condition testing is a test-case design method that
exercises the logical conditions contained in a
program module.

 In short, it tests relational operator like <, ≤, >, ≥, =,

≠ and Boolean operators like OR (|), AND (&),
NOT(⌐) that exist in your program.

 The condition testing method focuses on testing

each condition in the program to ensure that it does
not contain errors
27
 Data flow testing
 The data flow testing method selects test paths of a program according to the locations
of definitions and uses of variables in the program.
 assume that each statement in a program is assigned a unique statement number and
that each function does not modify its parameters or global variables.
 For a statement with S as its statement number,
 DEF(S) ={X | statement S contains a definition of X} USE(S) ={X | statement S contains
a use of X
 A definition-use (DU) chain of variable X is of the form [X, S, S’], where S and S’ are
statement numbers, X is in DEF(S) and USE(S’), and the definition of X in statement S
is live at statement S’. One simple data flow testing strategy is to require that every DU
chain be covered at least once.

28
Loop testing
 Loop testing is a white-box testing
technique that focuses exclusively on
the validity of loop constructs.

29
 Simple loops.
 The following set of tests can be applied to
simple loops, where n is the maximum number
of allowable passes through the loop.
 1. Skip the loop entirely.
 2. Only one pass through the loop.
 3. Two passes through the loop.
 4. m passes through the loop where m n.
 5. n -1, n, n +1 passes through the loop.

30
 Nested loops.
 1. Start at the innermost loop. Set all other loops to
minimum values.
 2. Conduct simple loop tests for the innermost loop
while holding the outer loops at their minimum iteration
parameter (e.g., loop counter) values. Add other tests
for out-of-range or excluded values.
 3. Work outward, conducting tests for the next loop, but
keeping all other outer loops at minimum values and
other nested loops to “typical” values.
 4. Continue until all loops have been tested

31
 Concatenated loops. Concatenated loops can be
tested using the approach defined for simple loops, if
each of the loops is independent of the other.
However, if two loops are concatenated and the loop
counter for loop 1 is used as the initial value for loop
2, then the loops are not independent. When the
loops are not independent, the approach applied to
nested loops is recommended.

 Unstructured loops. Whenever possible, this class of

loops should be redesigned to reflect the use of the
structured programming constructs
32
Black-box testing
 Black-box tests are designed to validate
functional requirements without regard to the
internal workings of a program.

 black-box testing techniques enable you to derive

sets of input conditions that will fully exercise all
functional requirements for a program.

33
 Black-box testing
 Tests are designed to answer some of the following
questions:
 How is functional validity tested?
 How are system behavior and performance tested?
 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input values?
 How are the boundaries of a data class isolated?
 What data rates and data volume can the system tolerate?
 What effect will specific combinations of data have on system operation?

34
 Graph-based testing
 The first step in black-box testing is to
understand the objects that are modeled in
software and the relationships that connect
these objects
 Begins by creating a graph of important
objects and their relationships and then
devising a series of tests that will cover the
graph so that each object and relationship is
exercised and errors are uncovered.
35
Graph-based testing
object Directed link object
#1 (link weight) #2

Node weight
Undirected link (value
)
Parallel links
object
#
3

(a)

new menu select generates document

file (generation time  1.0 sec) window

allows editing
is represented as of Attributes:
contains
document background color: white
tex text color: default color
t or preferences

(b)

36
 Equivalence partitioning
 Equivalence partitioning divides the input domain into classes
of data that are likely to exercise a specific software function.

 Test-case design for equivalence partitioning is based on an

evaluation of equivalence classes for an input condition.

 An equivalence class represents a set of valid or invalid

states for input conditions.

37
Equivalence partitioning
 How do I define equivalence classes for testing?
 Equivalence classes may be defined according to
the following guidelines:
 If an input condition specifies a range, one valid and two invalid equivalence classes
are defined.
 If an input condition requires a specific value, one valid and two invalid equivalence
classes are defined.
 If an input condition specifies a member of a set, one valid and one invalid
equivalence classes are defined.
 If an input condition is Boolean, one valid and one invalid equivalence classes are
defined.

38
Boundary Value Analysis
 Boundary value analysis leads to a selection of
test cases that exercise bounding values.

 Boundary value analysis is a test-case design

technique that complements equivalence
partitioning. Rather than selecting any element of
an equivalence class

39
 Boundary Value Analysis
 Guidelines for BVA
 If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b
and just above and just below a and b.

 If an input condition specifies a number of values, test cases should be developed that exercise the minimum and
maximum numbers. Values just above and below minimum and maximum are also tested.

 Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature versus pressure table is
required as output from an engineering analysis program. Test cases should be designed to create an output report
that produces the maximum (and minimum) allowable number of table entries.

 If internal program data structures have prescribed boundaries (e.g., a table has a defined limit of 100 entries), be
certain to design a test case to exercise the data structure at its boundary.

40
Boundary Value Analysis
3 11
4 7 10

Less than 4 Betw een 4 and 1 0 More than 1 0

Number of input v alues

9999 100000
10000 50000 99999

Less than 1 0000 Betw een 1 0000 and 99999 More than 99999

Input v alues

41
Example:

Ritcher Scale Number Input Values

(n)
n<5.0 2.0
5.0 <= n < 5.5 5.0, 5.3

5.5 <= n < 6.5 5.5, 5.7

6.5 <= n < 7.5 6.5, 7.0

higher 7.5, 8.0

Orthogonal Array Testing
 Used when the number of input parameters is small and the values that each of the
parameters may take are clearly bounded
 Orthogonal array testing can be applied to problems in which the input domain is
relatively small but too large to accommodate exhaustive testing. The orthogonal array
testing method is particularly useful in finding region faults—an error category
associated with faulty logic within a software component

43
Orthogonal Array Testing

Z Z

Y Y
X X
One input item at a time L9 orthogonal array44
Orthogonal Array Testing

45
Model-Based Testing
 Uses information contained in the
requirements model as the basis for the
generation of test cases.
 In many cases, the model-based testing
technique uses UML state diagrams, an
element of the behavioral model, as the
basis for the design of test cases.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 46