UNIT 4

1
 Software Testing
• What is Testing?
Many people understand many definitions of testing :

1. Testing is the process of demonstrating that errors are not present.

2. The purpose of testing is to show that a program performs its intended

functions correctly.

3. Testing is the process of establishing confidence that a program does

what it is supposed to do.

These definitions are incorrect.

2
 Software Testing
A more appropriate definition is:

“Testing is the process of

executing a program with the intent of
finding errors.”

3
 Software Testing
• Why should We Test ?

Although software testing is itself an expensive activity, yet launching of

software without testing may lead to cost potentially much higher than that
of testing, specially in systems where human safety is involved.

In the software life cycle the earlier the errors are discovered and removed,
the lower is the cost of their removal.

4
 Software Testing
• Who should Do the Testing ?
o Testing requires the developers to find errors from their software.
o It is difficult for software developer to point out errors from own
creations.
o Many organisations have made a distinction between development
and testing phase by making different people responsible for each
phase.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International 5
Publishers, 2007
 Software Testing
• What should We Test ?

We should test the program’s responses to every possible input. It means,

we should test for all valid and invalid inputs. Suppose a program requires
two 8 bit integers as inputs. Total possible combinations are 28x28. If only
one second it required to execute one set of inputs, it may take 18 hours to
test all combinations. Practically, inputs are more than two and size is also
more than 8 bits. We have also not considered invalid inputs where so
many combinations are possible. Hence, complete testing is just not
possible, although, we may wish to do so.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International 6
Publishers, 2007
 Software Testing
Some Terminologies
➢ Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a syntax
error or misunderstanding of specifications. Sometimes, there are logical
errors.

When developers make mistakes while coding, we call these mistakes

“bugs”.

A fault is the representation of an error, where representation is the mode

of expression, such as narrative text, data flow diagrams, ER diagrams,
source code etc. Defect is a good synonym for fault.

A failure occurs when a fault executes. A particular fault may cause

different failures, depending on how it has been exercised.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
9
Publishers, 2007
 Software Testing
➢ Test, Test Case and Test Suite
Test and Test case terms are used interchangeably. In practice, both are
same and are treated as synonyms. Test case describes an input
description and an expected output description.
Test Case ID
Section-I Section-II
(Before Execution) (After Execution)
Purpose : Execution History:
Pre condition: (If any) Result:
Inputs: If fails, any possible reason (Optional);
Expected Outputs: Any other observation:
Post conditions: Any suggestion:
Written by: Run by:
Date: Date:
Fig. 2: Test case template
The set of test cases is called a test suite. Hence any combination of test
cases may generate a test suite.
Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
10
Publishers, 2007
 Software Testing

➢ Verification and Validation

Verification is the process of evaluating a system or component to

determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at
the end of development process to determine whether it satisfies the
specified requirements .
Testing= Verification+Validation

11
1
0
1
1
 Software Testing
Boundary Value Analysis
Consider a program with two input variables x and y. These input variables
have specified boundaries as:
a≤x≤b
c≤y≤
d
Input
domain
d
y
c

a x b

14
Fig.4: Input domain for program having two input variables
 2.2 Boundary Value Analysis
• Test cases that have values on the boundaries
of equivalence classes.
• Chose input lie at the edges of
equivalence class.
• So, if the range is 0.0 < x< 1.0, then the test
cases are 0.0, 1.0 (valid inputs), and -0.1,
and
1.1 (for invalid inputs).
1
3
 Software Testing
The boundary value analysis test cases for our program with two inputs
variables (x and y) that may have any value from 100 to 300 are: (200,100),
(200,101), (200,200), (200,299), (200,300), (100,200), (101,200), (299,200) and
(300,200). This input domain is shown in Fig. 8.5. Each dot represent a test case and
inner rectangle is the domain of legitimate inputs. Thus, for a program of n variables,
boundary value analysis yield 4n + 1 test cases.
Input domain
400
300
y
200

100

0
100 200
x 300
400

Fig. 5: Input domain of two variables x and y with

boundaries [100,300] each
Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
15
Publishers, 2007
 Software Testing
Example- 8.I

Consider a program for the determination of the nature of roots of a

quadratic equation. Its input is a triple of positive integers (say a,b,c) and
values may be from interval [0,100]. The program output may have one of
the following words.
[Not a quadratic equation; Real roots; Imaginary roots; Equal roots]
Design the boundary value test cases.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
16
Publishers, 2007
 Software Testing
Solution

Quadratic equation will be of type:

ax2+bx+c=0
Roots are real if (b2-4ac)>0
Roots are imaginary
if (b2-4ac)<0 Roots are
equal if (b2-4ac)=0 Equation is
not quadratic if a=0

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
17
Publishers, 2007
 Software Testing
The boundary value test cases are :
Test Case a b c Expected output

1 0 50 50 Not Quadratic
2 1 50 50 Real Roots
3 50 50 50 Imaginary Roots
4 99 50 50 Imaginary Roots
5 100 50 50 Imaginary Roots
6 50 0 50 Imaginary Roots
7 50 1 50 Imaginary Roots
8 50 99 50 Imaginary Roots
9 50 100 50 Equal Roots
10 50 50 0 Real Roots
11 50 50 1 Real Roots
12 50 50 99 Imaginary Roots
13 50 50 100 Imaginary Roots

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
18
Publishers, 2007
 Software Testing
Example – 8.2

Consider a program for determining the Previous date. Its input is a triple of
day, month and year with the values in the range
1 ≤ month ≤ 12
1 ≤ day ≤ 31
1900 ≤ year ≤ 2025
The possible outputs would be Previous date or invalid input date. Design the
boundary value test cases.

19
 Software Testing
Solution

The Previous date program takes a date as input and checks it for validity.
If valid, it returns the previous date as its output.

With single fault assumption theory, 4n+1 test cases can be designed and
which are equal to 13.

20
 Software Testing
The boundary value test cases are:
Test Case Month Day Year Expected output

1 6 15 1900 14 June, 1900

2 6 15 1901 14 June, 1901
3 6 15 1962 14 June, 1962
4 6 15 2024 14 June, 2024
5 6 15 2025 14 June, 2025
6 6 1 1962 31 May, 1962
7 6 2 1962 1 June, 1962
8 6 30 1962 29 June, 1962
9 6 31 1962 Invalid date

10 1 15 1962 14 January, 1962

11 2 15 1962 14 February, 1962
12 11 15 1962 14 November, 1962
13 12 15 1962 14 December, 1962

21
 Software Testing
Example – 8.3

Consider a simple program to classify a triangle. Its inputs is a triple of

positive integers (say x, y, z) and the date type for input parameters ensures
that these will be integers greater than 0 and less than or equal to 100. The
program output may be one of the following words:
[Scalene; Isosceles; Equilateral; Not a triangle]
Design the boundary value test cases.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
22
Publishers, 2007
 Software
Solution
Testing
The boundary value test cases are shown below:
Test case x y Z Expected Output
1 50 50 1 Isosceles
2 50 50 2 Isosceles
3 50 50 50 Equilateral
4 50 50 99 Isosceles
5 50 50 100 Not a triangle
6 50 1 50 Isosceles
7 50 2 50 Isosceles
8 50 99 50 Isosceles
9 50 100 50 Not a triangle
10 1 50 50 Isosceles
11 2 50 50 Isosceles
12 99 50 50 Isosceles
13 100 50 50 Not a triangle

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
23
Publishers, 2007
 Black-Box Testing
• Test cases are decided solely on the basis of the requirements or
specifications of the program or module, and the internals of the module
or the program are not considered for selection of test cases.

• The tester only knows the inputs that can be give into the system and
what output the system should give.

• Also called functional testing, as it concern with the functionality of the

program

• In the black-box testing, test cases are designed from an examination of

the input/output values only and no knowledge of design, or code is
required.
2
3
 Generating test cases

• Randomly – not much optimal.

• Optimal means detection of maximum errors
with minimum test cases.
• Some other techniques for designing test-
cases are as follows :-

2
4
 2.1 Equivalence Class Partitioning

• divide the input domain into a set of equivalence classes.

• so that if the program works correctly for a value then it

will work correctly for all the other values in that class.

• Difficult to find equivalence class without knowing the

internal structure of program.

• Equivalence class – inputs with same expected behavior.

2
5
• If the input data values to a system can be
specified by a range of values, then one valid
and two invalid equivalence classes should be
defined.
• If the input data assumes values from a set of
discrete members of some domain, then one
equivalence class for valid input values and
another equivalence class for invalid input
values should be defined.

2
6
 Software Testing
Invalid input

Valid System Outputs

inputs under test

Input domain Output domain

Fig. 7: Equivalence partitioning

Most of the time, equivalence class testing defines classes of the input domain.
However, equivalence classes should also be defined for output domain. Hence,
we should design equivalence classes based on input and output domain.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
62
Publishers, 2007
 Software Testing
Example 8.7
Consider the program for the determination of nature of roots of a quadratic
equation as explained in example 8.1. Identify the equivalence class test
cases for output and input domains.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
63
Publishers, 2007
 Software Testing
Solution

Output domain equivalence class test cases can be identified as follows:

O1={<a,b,c>:Not a quadratic equation if a = 0}
O1={<a,b,c>:Real roots if (b2-4ac)>0}
O1={<a,b,c>:Imaginary roots if (b2-4ac)<0}
O1={<a,b,c>:Equal roots if (b2-4ac)=0}`
The number of test cases can be derived form above relations and shown
below:
Test case a b c Expected output
1 0 50 50 Not a quadratic equation
2 1 50 50 Real roots
3 50 50 50 Imaginary roots
4 50 100 50 Equal roots

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
64
Publishers, 2007
 Software Testing
We may have another set of test cases based on input domain.
I1= {a: a = 0}
I2= {a: a <
0}
I3= {a: 1 ≤ a ≤ 100}
I4= {a: a > 100}
I5= {b: 0 ≤ b ≤ 100}
I6= {b: b < 0}
I7= {b: b > 100}
I8= {c: 0 ≤ c ≤ 100}
I9= {c: c < 0}
I10={c: c > 100}

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
65
Publishers, 2007
 Software Testing

Test Case a b c Expected output

1 0 50 50 Not a quadratic equation

2 -1 50 50 Invalid input
3 50 50 50 Imaginary Roots
4 101 50 50 invalid input
5 50 50 50 Imaginary Roots
6 50 -1 50 invalid input
7 50 101 50 invalid input
8 50 50 50 Imaginary Roots
9 50 50 -1 invalid input
10 50 50 101 invalid input

Here test cases 5 and 8 are redundant test cases.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
66
Publishers, 2007
 Software Testing
Example 8.8
Consider the program for determining the previous date in a calendar as
explained in example 8.3. Identify the equivalence class test cases for output
& input domains.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
67
Publishers, 2007
 Software Testing
Solution
Output domain equivalence class are:

O1={<D,M,Y>: Previous date if all are valid inputs}

O1={<D,M,Y>: Invalid date if any input makes the
date invalid}
Test case M D Y Expected output
1 6 15 1962 14 June, 1962
2 6 31 1962 Invalid date

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
68
Publishers, 2007
 Software Testing
We may have another set of test cases which are based on input domain.

I1={month: 1 ≤ m ≤ 12}
I2={month: m < 1}
I3={month: m > 12}
I4={day: 1 ≤ D ≤ 31}

I5={day: D < 1}
I6={day: D > 31}
I7={year: 1900 ≤ Y ≤ 2025}
I8={year: Y < 1900}
I9={year: Y > 2025}

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
69
Publishers, 2007
 Software Testing
Inputs domain test cases are :

Test Case M D Y Expected output

1 6 15 1962 14 June, 1962

2 -1 15 1962 Invalid input
3 13 15 1962 invalid input
4 6 15 1962 14 June, 1962
5 6 -1 1962 invalid input
6 6 32 1962 invalid input
7 6 15 1962 14 June, 1962
8 6 15 1899 invalid input (Value out of range)
9 6 15 2026 invalid input (Value out of range)

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
70
Publishers, 2007
 Software Testing
Example – 8.9

Consider the triangle problem specified in a example 8.3. Identify the

equivalence class test cases for output and input domain.

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
71
Publishers, 2007
 Software Testing
Solution
Output domain equivalence classes are:

O1={<x,y,z>: Equilateral triangle with sides x,y,z}

O1={<x,y,z>: Isosceles triangle with sides x,y,z}
O1={<x,y,z>: Scalene triangle with sides x,y,z}
O1={<x,y,z>: Not a triangle with sides x,y,z}

The test cases are:

Test case x y z Expected Output
1 50 50 50 Equilateral
2 50 50 99 Isosceles
3 100 99 50 Scalene
4 50 100 50 Not a triangle

Software Engineering (3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
72
Publishers, 2007
 Software Testing
Input domain based classes are:

I1={x: x < 1} I2={x: x >

100}
I3={x: 1 ≤ x ≤ 100} I4={y: y <
1}
I5={y: y > 100}
I6={
y: 1 ≤ y ≤
100} I7={z: z <
1
}
I8={
z: z > 100}
I9={z: 1 ≤ z ≤
1 73
00}
 Software Testing
Some inputs domain test cases can be obtained using the relationship amongst x,y
and z.

I10={< x,y,z >: x = y = z}

I11={< x,y,z >: x = y, x ≠ z}
I12={< x,y,z >: x = z, x ≠ y}
I13={< x,y,z >: y = z, x ≠
y}
I14={< x,y,z >: x ≠ y, x ≠ z, y ≠ z}
I15={< x,y,z >: x = y + z}
I16={< x,y,z >: x > y +z}
I17={< x,y,z >: y = x
+z}
Software
I18={< x,y,z >: yEngineering
> x + z}(3 rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International
74
Publishers, 2007

I19={< x,y,z >: z = x + y}

 Software Testing

Test cases derived from input domain are:

Test case x y z Expected Output

1 0 50 50 Invalid input
2 101 50 50 Invalid input
3 50 50 50 Equilateral
4 50 0 50 Invalid input
5 50 101 50 Invalid input
6 50 50 50 Equilateral
7 50 50 0 Invalid input
8 50 50 101 Invalid input
9 50 50 50 Equilateral
10 60 60 60 Equilateral
11 50 50 60 Isosceles
12 50 60 50 Isosceles
13 60 50 50 Isosceles

75
 Software Testing

Test case x y z Expected Output

14 100 99 50 Scalene
15 100 50 50 Not a triangle
16 100 50 25 Not a triangle
17 50 100 50 Not a triangle
18 50 100 25 Not a triangle
19 50 50 100 Not a triangle
20 25 50 100 Not a triangle

76
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
 White Box Testing
• Is concerned with testing the implementation of the program.

• The intent of this testing is not to exercise all the different

input or output conditions but to exercise the different
programming structures and data structures used in the
program.

• also called structural testing

5
6
 Approaches
• control flow-based testing:- control flow graph (or simply flow
graph) of a program P be G.
A node in this graph represents a block of statements that is always
• executed together.
An edge (i, j) represents a possible transfer of control after executing the
• last statement of the block represented by node i to the first statement of
the block represented by node j .
A node corresponding to a block whose first statement is the start
statement of P is called the start node of G, and a node corresponding to
• a block whose last statement is an exit statement is called an exit node.
A complete path is a path whose first node is the start node and the
last node is an exit node.

• 5
7
5
8
5
9
6
0
• each circle, called a flow graph node, represents one or more procedural
statements.

• The arrows on the flow graph, called edges or links, represent flow of
control.

• Areas bounded by edges and nodes are called regions.

• When counting regions, we include the area outside the graph as a

region.

• When compound conditions are encountered in a procedural design, the

generation of a flow graph becomes slightly more complicated. A compound
condition occurs when one or more Boolean operators (logical OR, AND, NAND,
NOR) is present in a conditional statement.

• Each node that contains a condition is called a predicate node and is characterized
by two or more edges emanating from it.
–Each compound condition in a conditional expression containing one or more 6
Boolean operators (e.g., and, or) is represented by a separate predicate node 1
Consider flow-chart

6
2
Corresponding Flow-Graph

6
3
6
4
A Second Flow Graph Example
3
4

6
8 7
10 9 16
11 17

13 12

14
6
5
15 49
 A Sample Function to Diagram and Analyze
1 int functionZ(int y) 3
2 {
3 int x = 0;
4
4 while (x <= (y * y))
5 { 6 7
6 if ((x % 11 == 0) &&
7 (x % y == 0))
9
8
9
{
printf(“%d”, x); x+
12 13
0 +;
1 } // End if 10
2 else if ((x % 7 == 0) 15
3 ||
4 (x % y == 1)) 16
5 {
6 printf(“%d”, y); x 18
7 = x + 2;
8 } // End else
9 printf(“\n”); 20
} // End
while
0 printf("End of list\n"); 21 6
1 return 0; 6
2 } // End functionZ 50
Compound logic

6
7
 Cyclomatic Complexity
• Cyclomatic complexity is a software metric that provides a
quantitative measure of the
logical complexity of a program.
• When used in the context of the basis path testing
method, the value computed for cyclomatic complexity defines
the number of independent paths in the basis set of a program
and provides us with an upper bound for the number of tests
that must be conducted to ensure that all statements have
been
executed at least once.

6
8
 Path
• A path through a program is a node and edge sequence
from the starting node to a terminal node of the control
flow graph of a program. There can be more than one
terminal node in a program.

• Writing test cases to cover all the paths of a

typical program is impractical. For this reason, the path-
coverage testing does not require coverage of all paths but
only coverage of linearly independent paths.

6
9
linearly independent path
• A linearly independent path is any path through the
program that introduces at
least one new edge that is not included in any other
linearly independent paths.
• If a path has one new node compared to all other
linearly independent paths.
• For example, a set of independent paths for the flow
graph illustrated in Figure

7
0
path 1: 1-11
path 2: 1-2-3-4-5-10-1-11
path 3: 1-2-3-6-8-9-10-1-11
path 4: 1-2-3-6-7-9-10-1-11

7
1
 Methods
• There are three different ways to compute the cyclomatic complexity.
• The number of regions of the flow graph correspond to the cyclomatic
complexity.
• Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V(G) = E - N + 2
where E is the number of flow graph edges, N is the number of flow
graph nodes.
• Cyclomatic complexity, V(G), for a flow graph, G, is also defined as
V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph
G.

7
2
 Example
1. The flow graph has four regions.
2. V(G) = 11 edges 9 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.

7
3
 Graph matrices
• A graph matrix is a square matrix whose size
(i.e., number of rows and columns)
is equal to the number of nodes on the flow
graph. Each row and column corresponds
to an identified node, and matrix entries
correspond to connections (an edge) between
nodes.

7
4
7
5
• Each letter has been replaced with a 1, indicating that a connection
exists (zeros have been excluded for clarity). Represented in this form,
the graph matrix is called a connection matrix.
• Each row with two or more entries represents a predicate node.

7
6
 Loop Testing - General
• A white-box testing technique that focuses
exclusively on the validity of loop constructs
• Four different classes of loops exist
– Simple loops
– Nested loops
– Concatenated loops
– Unstructured loops

7
7
61
7
8
 Testing of Simple Loops
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

‘n’ is the maximum number of allowable passes through the loop

7
9
79
 Testing of 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 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

8
0
80
 Testing Concatenated Loop
• 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.

8
1
 Testing Unstructured Loops
• Whenever possible, this class of loops should
be redesigned to reflect the use of the
structured programming constructs.

8
2