22-04-2025

Software Testing
Dr. Madhusmita Sahu
Assistant Professor
Department of Computer Science and Information Technology

Topics To Be Discussed

1 2 3 4 5 6 7
Testing Verificati Testing Levels Test Approac McCabe’s
and its on and activitie of Case hes to Cyclomati
importan Validatio s Testing Design c
ce n Test Complexi
Cases ty
2

1
 22-04-2025

Testing

▪ The aim of testing is to identify all

defects in a program.
▪ However, in practice, even after
satisfactory completion of the testing
phase, it is not possible to guarantee
that a program is error free.
3

Testing

▪ This is because the input data domain

of most programs is very large, and it
is not practical to test the program
exhaustively with respect to each
value that the input can assume.

2
 22-04-2025

Importance of Testing

▪ Software Testing is Important because

if there are any bugs or errors in the
software, it can be identified early and
can be solved before delivery of the
software product.

Importance of Testing

▪ Properly tested software product

ensures reliability, security and high
performance which further results in
time saving, cost effectiveness and
customer satisfaction.

3
 22-04-2025

Importance of Testing

▪ Testing is important because software

bugs could be expensive or even
dangerous.
▪ Software bugs can potentially cause
monetary and human loss.

How to test a program

▪ Testing a program involves executing the

program with a set of test inputs and
observing if the program behaves as
expected.
▪ If the program fails to behave as expected,
then the input data and the conditions under
which it fails are noted for later debugging
8
and error correction.

4
 22-04-2025

How to test a program

▪ A highly simplified view of program

testing is schematically shown as

Verification

▪ Verification is the process of confirming if

the software is meeting the business
requirements, and is developed adhering to
the proper specifications and methodologies.
▪ Verification ensures the product being
developed is according to design
specifications.
10

5
 22-04-2025

Verification

▪ Verification answers the question–

"Are we developing this product by
firmly following all design
specifications ?“ i.e. Are we building
the product right?
▪ Verifications concentrates on the
11
design and system specifications.

Validation

▪ Validation is process of examining

whether or not the software satisfies
the user requirements.
▪ It is carried out at the end of the SDLC.
▪ If the software matches requirements
for which it was made, it is validated.
12

6
 22-04-2025

Validation

▪ Validation ensures the product under

development is as per the user
requirements.
▪ Validation answers the question – “Are we
developing the product which attempts all
that user needs from this software ?“ i.e. Are
we building the right product?.
13
▪ Validation emphasizes on user requirements.

Verification Versus
Validation

Verification Validation
Process of determining whether Process of determining whether
the output of one phase of fully developed software
software development conforms conforms to its requirements
to that of its previous phase. specification.

The objective of verification is to Validation is applied to the fully

check if the artifacts produced developed and integrated
after a phase conforms to that of software to check if it satisfies
the previous phase. the customer’s requirements.
14

7
 22-04-2025

Verification Versus
Validation

Verification Validation
Primary techniques include review, Validation techniques are primarily
simulation and formal verification. based on product testing.
Verification is carried out during the Validation is carried out towards the
development process to check if the end of the development process to
development activities are being check if the right product as required
carried out correctly. by the customer has been
developed.
Verification is concerned with phase The aim of validation is to make the
containment of errors. final product error free.
15

Verification Versus
Validation

Verification Validation
Verification does not require validation requires execution of
execution of the software the software
Verification is carried out during validation is carried out to check
the development process to if the right as required by the
check if the development customer has been developed.
activities are proceeding alright.
Verification techniques can be The aim of validation is to check
viewed as an attempt to achieve whether the deliverable software
16 phase containment of errors. is error free.

8
 22-04-2025

Testing Activities

Test suite design

Running test cases and checking the results to

detect failures

Locate error

Error correction
17

Testing Process

18

9
 22-04-2025

Test suite design

▪ The set of test cases using which a program

is to be tested is designed possibly using
several test case design techniques.

19

Running test cases and

checking the results to
detect failures

▪ Each test case is run and the results are

compared with the expected results.
▪ A mismatch between the actual result and
expected results indicates a failure.
▪ The test cases for which the system fails are
noted down for later debugging.

20

10
 22-04-2025

Locate error

▪ In this activity, the failure symptoms are

analysed to locate the errors.
▪ For each failure observed during the
previous activity, the statements that are in
error are identified.

21

Error correction

▪ After the error is located during debugging,

the code is appropriately changed to correct
the error.

22

11
 22-04-2025

Why Design Test Cases

▪ Testing a software using a large

collection of randomly selected test
cases does not guarantee that all (or
even most) of the errors in the system
will be uncovered.

23

Why Design Test Cases

▪ Consider the following example code

segment which determines the
greater of two integer values x and y.

if (x>y) max = x;
else max = x; /* should be max = y */
24

12
 22-04-2025

Why Design Test Cases

▪ For the given code segment, the test

suite {(x=3,y=2);(x=2,y=3)} can detect
the error, whereas a larger test suite
{(x=3,y=2);(x=4,y=3);(x=5,y=1)} does not
detect the error.

25

Why Design Test Cases

▪ All the test cases in the larger test suite

essentially test the same statement, while
the other statement remains undetected.
▪ So, it would be incorrect to say that a larger
test suite would always detect more errors
than a smaller one, unless of course the
larger test suite has also been carefully
26
designed.

13
 22-04-2025

Why Design Test Cases

▪ This implies that for effective testing,

the test suite should be carefully
designed rather than picked
randomly.

27

Why Design Test Cases

▪ Exhaustive testing of almost any non-

trivial system is impractical due to the
fact that the domain of input data
values to most practical software
systems is extremely large.

28

14
 22-04-2025

Why Design Test Cases

▪ Therefore, to satisfactorily test a

software with minimum cost, we must
design a minimal test suite that is of
reasonable size and can uncover as
many existing errors in the system as
possible.
29

Minimal test suite

▪ A minimal test suite is a carefully

designed set of test cases such that
each test case helps detect different
errors.
▪ Thus, the wastage of effort due to
running multiple tests to detect the
30
same error is avoided.

15
 22-04-2025

Test Case

▪ A test case is a triplet [I, S, R], where

▫ I is the data input to the program
under test,
▫ S is the state of the program at
which the data is to be input, and
▫ R is the result expected to be
31
produced by the program.

Test Case

▫ The state of a program is also called its

execution mode.
▪ An example of a test case is—
▫ [input: “abc”, state: edit, result: abc is
displayed],
■ Which essentially means that the input
abc needs to be applied in the edit
mode, and the expected result is that
32 the string abc would be displayed.

16
 22-04-2025

Test Suite

▪ A test suite is the set of all test cases

that have been designed by a tester to
test a given program.

33

Types of Test Case

• Positive Test
1
Case
• Negative Test
2
Case
34

17
 22-04-2025

Positive Test Case

▪ A test case is said to be a positive test

case
▫ if it is designed to test whether the
software correctly performs a
required functionality.

35

Negative Test Case

▪ A test case is said to be negative

test case,
▫ if it is designed to test whether the
software carries out something that
is not required of the system.

36

18
 22-04-2025

Types of Test Case

Example

▪ Consider a function to manage user

logins.
▪ A positive test case can be designed to
check if the function correctly
validates a legitimate user entering
correct user name and password.
37

Types of Test Case

Example

▪ A negative test case in this case can

be a test case that checks whether the
login functionality validates and
admits a user with wrong or bogus
user name or password.

38

19
 22-04-2025

Approaches to Design Test

Cases

Black-box
• test cases are designed using only the functional
specification of the software.
• black-box testing is also known as functional testing.
White-box (or glass-box)
• designing white-box test cases requires a thorough
knowledge of the code structure of a program,
39
• white-box testing is also called structural testing.

Approaches to Design Test

Cases

▪ Black-box test cases are designed

solely based on the input-output
behaviour of a program.
▪ In contrast, white-box test cases are
based on an analysis of the code.
▪ These two approaches to test case
40 design are complementary.

20
 22-04-2025

Approaches to Design Test

Cases

▪ That is, a program has to be tested

using the test cases designed by both
the approaches, and one testing using
one approach does not substitute
testing using the other.

41

Black Box (BB) Testing

▪ In 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.

42

21
 22-04-2025

Approaches to design black

box test cases

Equivalence class Boundary value

partitioning analysis

43

Equivalence Class
Partitioning

▪ In the equivalence class partitioning

approach, the domain of input values to the
unit under test is partitioned into a set of
equivalence classes.
▪ The partitioning is done such that for
every input data belonging to the same
equivalence class, the program behaves
44
similarly.

22
 22-04-2025

Equivalence Class
Partitioning

▪ The main idea behind defining equivalence

classes of input data is that
▫ testing the code with any one value
belonging to an equivalence class is as
good as testing the code with any other
value belonging to the same equivalence
class.
45

Equivalence Class
Partitioning

▪ Equivalence classes for a unit under

test can be designed by examining the
input data and output data.
▪ The following are two general
guidelines for designing the
equivalence classes .
46

23
 22-04-2025

Equivalence Class
Partitioning

▫ If the input data values to a system can be

specified by a range of values, then one
valid and two invalid equivalence classes
can be defined.
■ For example, if the equivalence class is
the set of integers in the range 1 to 10
(i.e., [1,10]), then the two invalid
equivalence classes are [-∞,0], [11,+∞],
47
and the valid equivalence class is [1,10].

Equivalence Class
Partitioning

▫ If the input data assumes values from a set of

discrete members of some domain, then one
equivalence class for the valid input values and
another equivalence class for the invalid input
values should be defined.
■ For example, if the valid equivalence classes
are {A,B,C}, then the invalid equivalence class
is ∪-{A,B,C}, where ∪ is the universe of all
possible input values.
48

24
 22-04-2025

Equivalence Class
Partitioning Example 1

▪ Consider a program unit that takes an

input integer that can assume values
in the range of 0 and 5000 and
computes its square root.
▪ Determine the equivalence classes
and the black box test suite for the
49
program unit.

Equivalence Class
Partitioning Example 1

▪ There are three equivalence classes

▫ The set of negative integers,
▫ the set of integers in the range of 0 and 5000, and
▫ the set of integers larger than 5000.
▪ Therefore, the test cases must include
representatives for each of the three equivalence
classes.
▪ A possible test suite can be: {–5,500,6000}.

50

25
 22-04-2025

Equivalence Class
Partitioning Example 2

▪ Design the equivalence class test cases for a

function that reads two integer pairs (m1, c1)
and (m2, c2) defining two straight lines of the
form y=mx+c.
▪ The function computes the intersection point
of the two straight lines and displays the
point of intersection.
51

Equivalence Class
Partitioning Example 2

▪ First, there are two equivalence classes: valid and

invalid.
▪ The valid class can be divided into the following
equivalence classes:
▫ No point of intersection:
■ Parallel lines (m1 = m2, c1 c2)
▫ One point of intersection:
■ Intersecting lines (m1 m2)
▫ Infinite points of intersection:
52 ■ Coincident lines (m1 = m2, c1 = c2)

26
 22-04-2025

Equivalence Class
Partitioning Example 2

▪ Now, selecting one representative

value from each equivalence class, we
get the required equivalence class test
suite {{(a,a)(a,a)}{(2,2)(2,5)},{(5,5)(7,7)},
{(10,10)(10,10)}}.
▪ The pair {(a,a) (a,a)} represents the
53
invalid class.

Equivalence Class
Partitioning Example 3

▪ Design equivalence class partitioning

test suite for a function that reads
a character string of size less than
five characters and displays whether
it is a palindrome.

54

27
 22-04-2025

Equivalence Class
Partitioning Example 3

▪ The domain of all input values can be

partitioned into two broad equivalence
classes: valid values and invalid values.
▪ The valid values can be partitioned into
palindromes and non-palindromes.

55

Equivalence Class
Partitioning Example 3

▪ The equivalence classes are the leaf level classes.

56

28
 22-04-2025

Equivalence Class
Partitioning Example 3

▪ The equivalence classes are

▫ palindromes,
▫ non-palindromes, and
▫ invalid inputs.
▪ Now, selecting one representative value
from each equivalence class,
▫ we have the required test suite: {abc, aba,
57
abcdef}.

Boundary Value Analysis

▪ Programmers often fail to properly address

the special processing required by the input
values that lie at the boundary of the
different equivalence classes.
▪ For example, a programmer may improperly
use < instead of <=, or conversely <= for <,
etc.
58

29
 22-04-2025

Boundary Value Analysis

▪ Boundary value analysis-based test

suite design involves designing test
cases using the values at the
boundaries of different equivalence
classes.

59

Boundary Value Analysis

▪ To design boundary value test cases, it is

required to examine the equivalence classes
to check if any of the equivalence classes
contains a range of values.
▪ For those equivalence classes that are not a
range of values (i.e., consist of a discrete
collection of values) no boundary value test
60
cases can be defined.

30
 22-04-2025

Boundary Value Analysis

▪ For an equivalence class that is a range of

values, the boundary values need to be
included in the test suite.
▪ For example, if an equivalence class contains
the integers in the range 1 to 10, then the
boundary value test suite is {0,1,10,11}.

61

Boundary Value Analysis

Example 1

▪ For a function that computes the

square root of the integer values in
the range of 0 and 5000, determine
the boundary value test suite.

62

31
 22-04-2025

Boundary Value Analysis

Example 1

▪ There are three equivalence classes—

▫ The set of negative integers,
▫ the set of integers in the range of 0
and 5000, and
▫ the set of integers larger than 5000.
▪ The boundary value-based test suite
63
is: {0, -1, 5000, 5001}.

Boundary Value Analysis

Example 2

▪ Design equivalence class partitioning

test suite for a function that reads
a character string of size less than
five characters and displays whether
it is a palindrome.

64

32
 22-04-2025

Boundary Value Analysis

Example 2

▪ The equivalence classes are

65

Boundary Value Analysis

Example 2

▪ There is a boundary between the valid

and invalid equivalence classes.
▪ Thus, the boundary value test suite is
{abcdefg, abcdef}.

66

33
 22-04-2025

Summary of the Black-box

Test Suite Design Approach

1 •Examine the input and output values of the program.

2 •Identify the equivalence classes.

3 •Design equivalence class test cases by picking one representative value from each
equivalence class.

4
•Design the boundary value test cases as follows.
•Examine if any equivalence class is a range of values.
•Include the values at the boundaries of such equivalence classes in the test suite.
67

White Box (WB) Testing

▪ White-box testing is an important

type of unit testing.
▪ A white-box testing strategy can
either be coverage-based or fault-
based.

68

34
 22-04-2025

Coverage-based testing

▪ A coverage-based testing strategy attempts to

execute (or cover) certain elements of a program.
▪ Popular examples of coverage-based testing
strategies are
▫ statement coverage,
▫ branch coverage,
▫ multiple condition coverage, and
▫ path coverage-based testing.
69

Testing criterion

▪ The set of specific program

elements that a testing strategy
targets to execute is called the
testing criterion of the strategy.

70

35
 22-04-2025

Testing criterion for

coverage-based testing

▪ A coverage-based testing strategy typically targets to

execute (i.e., cover) certain program elements for
discovering failures.
▪ For example, if a testing strategy requires all the
statements of a program to be executed at least once,
then we say that the testing criterion of the strategy
is statement coverage.
▪ We say that a test suite is adequate with respect to a
criterion, if it covers all program elements of the
71
domain defined by that criterion.

Fault-based testing

▪ A fault-based testing strategy targets

to detect certain types of faults.
▪ An example of a fault-based strategy
is mutation testing.

72

36
 22-04-2025

Control Flow Graph (CFG)

▪ A control flow graph describes how the

control flows through the program.
▪ A control flow graph describes the sequence
in which the different instructions of a
program get executed.

73

Control Flow Graph (CFG)

▪ Formally, a CFG is a directed graph

consisting of a set of nodes and edges (N, E),
such that each node n ∈ N corresponds to a
unique program statement and an edge
exists between two nodes if control can
transfer from one node to the other.

74

37
 22-04-2025

Control Flow Graph (CFG)

▪ Every program
is constructed
by using three
types of
constructs only.
▫ Sequence
▫ Selection
▫ Iteration
75

Control Flow Graph (CFG)

76

38
 22-04-2025

Approaches to design
white box test cases

Condition and
Statement Condition
Branch Coverage Decision
Coverage Coverage
Coverage

Multiple
Multiple Condition Condition/Decision Data flow based
Path Coverage
Coverage Coverage Testing
(MC/DC)

Mutation Testing

77

Statement Coverage

▪ Statement coverage is a metric to measure

the percentage of statements that are
executed by a test suite in a program at least
once.
▪ The principal idea governing the statement
coverage strategy is that unless a statement
is executed, there is no way to determine
78
whether an error exists in that statement.

39
 22-04-2025

Statement Coverage
Example

▪ Design a statement coverage-based test suite for the

following Euclid’s GCD computation function:
int computeGCD(int x,int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5}
6 return x;
79
}

Statement Coverage
Example

▪ To design the test cases for achieving statement

coverage, the conditional expression of the while
statement needs to be made true and the conditional
expression of the if statement needs to be made both
true and false.
▪ By choosing the test set {(x = 3, y = 3), (x = 4, y = 3), (x =
3, y = 4)}, all statements of the program would be
executed at least once.

80

40
 22-04-2025

Branch Coverage

▪ Branch coverage is also called decision coverage (DC).

▪ It is also sometimes referred to as all edge coverage.
▪ A test suite achieves branch coverage,
▫ if it makes the decision expression in each branch
in the program to assume both true and false
values.
▪ Branch testing is also known as all edge testing,
▫ since in this testing scheme,
■ each edge of a program’s control flow graph is
81 required to be traversed at least once.

Branch Coverage Example

▪ Design a branch coverage-based test suite for the

following Euclid’s GCD computation function:
int computeGCD(int x,int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5}
6 return x;
82
}

41
 22-04-2025

Branch Coverage Example

▪ The test suite {(x = 3, y = 3), (x = 3, y =

2), (x = 4, y = 3), (x = 3, y = 4)} achieves
branch coverage.

83

Condition Coverage

▪ Condition coverage testing is also known as

basic condition coverage (BCC) testing.
▪ A test suite is said to achieve basic condition
coverage (BCC),
▫ if each basic condition in every
conditional expression assumes both true
and false values during testing.
84

42
 22-04-2025

Condition Coverage
Example

▪ For the following decision statement:

▫ if(A||B && C) …;
■ the basic conditions A, B, and C
assume both true and false values.
▫ However, for the given expression, just two test
cases can achieve condition coverage.
■ For example, one test case, may assign A =
True, B = True, and C = True and
■ another test case may assign A = False, B =
85
False, and C = False

Condition and Decision

Coverage

▪ A test suite is said to achieve

condition and decision coverage,
▫ if it achieves condition coverage as
well as decision (that is, branch)
coverage.

86

43
 22-04-2025

Multiple Condition
Coverage

▪ Multiple condition coverage (MCC) is

achieved, if the test cases make the
component conditions of a composite
conditional expression to assume all
possible combinations of true and
false values.
87

Multiple Condition
Coverage

▪ For example, consider the composite

conditional expression [(c1 and c2) or c3].
▪ A test suite would achieve MCC, if all the
component conditions c1, c2, and c3 are each
made to assume all combinations of true and
false values.
▪ Therefore, at least eight test cases would be
88
required in this case to achieve MCC.

44
 22-04-2025

Multiple Condition
Coverage

▪ For a composite conditional expression of n

components, 2n test cases are required for multiple
condition coverage.
▪ Thus, for multiple condition coverage, the number of
test cases increases exponentially with the number of
component conditions.
▪ Therefore, multiple condition coverage-based testing
technique is practical only if n (the number of atomic
conditions in the decision expression) is small.
89

Multiple Condition
Coverage Example

▪ Give an example of a fault that is detected by

multiple condition coverage, but not by
branch coverage.
▪ Consider the following C program segment:
if(temperature>150 || temperature>50)
setWarningLightOn();

90

45
 22-04-2025

Multiple Condition
Coverage Example

▪ The program segment has a bug in the

second component condition, it should have
been temperature<50.
▪ The test suite {temperature=160,
temperature=40} achieves branch coverage.
▪ But, it is not able to check that
setWarningLightOn(); should not be called for
91
temperature values within 150 and 50.

Multiple
Condition/Decision
Coverage (MC/DC)

▪ MCC is impractical for many programs as

the number of test cases required to achieve
MCC increases exponentially with the
number of basic conditions in a decision
expression.
▪ Therefore, when a program has decision
expressions made up of dozens of atomic
92
conditions, MCC becomes impractical.

46
 22-04-2025

Multiple
Condition/Decision
Coverage (MC/DC)

▪ Many embedded control applications incorporate

decision statements with several dozens of basic
conditions.
▪ For example, let us assume that a single conditional
expression involves 20 basic conditions.
▪ In this case, the number of test cases required to
achieve MCC would be 220,
▫ which is almost a million test cases.
93

Multiple
Condition/Decision
Coverage (MC/DC)

▪ Modified Condition/Decision Coverage

(MC/DC) testing was proposed to
ensure achievement of almost as
much thorough testing as is achieved
by MCC, but to keep the number of
test cases linear in the number of
94
basic conditions.

47
 22-04-2025

Path Coverage

▪ A test suite achieves path coverage

▫ if it executes each linearly
independent paths (or basis paths)
at least once.
▪ A linearly independent path can be
defined in terms of the control flow
95
graph (CFG) of a program.

Path

▪ A path through a program is any node and

edge sequence from the start node to a
terminal node of the control flow graph of a
program.
▪ A program can have more than one terminal
nodes when it contains multiple exit or
return type of statements.
96

48
 22-04-2025

Path

▪ Writing test cases to cover all paths of a typical

program is impractical since there can be an infinite
number of paths through a program in presence of
loops.
▪ If coverage of all paths is attempted, then the number
of test cases required would become infinitely large.

97

Path

▪ Therefore, we can say that all path

testing is impractical.
▪ For this reason, path coverage testing
does not try to cover all paths, but
only a subset of paths called linearly
independent paths (or basis paths).
98

49
 22-04-2025

Linearly independent set of

paths (or basis path set)

▪ A set of paths for a given program is

called linearly independent set of
paths (or the set of basis paths or
simply the basis set), if each path in
the set introduces at least one new
edge that is not included in any other
99
path in the set.

Linearly independent set of

paths (or basis path set)

▪ Even if we find that a path has one new node

compared to all other linearly independent
paths, then this path should also be included
in the set of linearly independent paths.
▪ This is because, any path having a new node
would automatically have a new edge.

100

50
 22-04-2025

Path Coverage

▪ Even though it is straight forward to

identify the linearly independent
paths for simple programs,
▫ for more complex programs it is not
easy to determine the number of
independent paths.
101

Path Coverage

▪ In this context, McCabe’s cyclomatic

complexity metric is an important result that
lets us compute the number of linearly
independent paths for any arbitrary
program.
▪ McCabe’s cyclomatic complexity defines an
upper bound for the number of linearly
102
independent paths through a program.

51
 22-04-2025

McCabe’s Cyclomatic
Complexity

▪ McCabe’s cyclomatic complexity defines an

upper bound on the number of independent
paths in a program.
▪ Cyclomatic complexity of a program is a
measure of the psychological complexity
or the level of difficulty in understanding the
program.
103

McCabe’s Cyclomatic
Complexity

▪ There are three different ways to compute

the cyclomatic complexity.

104

52
 22-04-2025

Method 1

▪ Given a control flow graph G of a program,

the cyclomatic complexity V(G) can be
computed as:
▫ V(G) = E – N + 2
■ where, N is the number of nodes of the
control flow graph and
■ E is the number of edges in the control
flow graph.
105

Method 2

▪ An alternate way of computing the

cyclomatic complexity of a program is based
on a visual inspection of the control flow
graph
▪ the cyclomatic complexity V (G) for a graph G
is given by the following expression:
▫ V(G) = Total number of non-overlapping
106
bounded areas + 1

53
 22-04-2025

Method 3

▪ The cyclomatic complexity of a program can

also be easily computed by computing the
number of decision and loop statements of
the program.
▪ If N is the number of decision and loop
statements of a program, then the McCabe’s
metric is equal to N + 1.
107

Steps to carry out path

coverage-based testing

1. Draw control flow graph for the program.

2. Determine the McCabe’s metric V (G).
3. Determine the cyclomatic complexity.
1. This gives the minimum number of test cases required
to achieve path coverage.
4. repeat
1. Test using a randomly designed set of test cases.
2. Perform dynamic analysis to check the path coverage
achieved.
108
until at least 90 percent path coverage is achieved.

54
 22-04-2025

Example

109

Example

▪ Calculating Cyclomatic Complexity

▫ Method 1
■ E = 7 and N = 6
■ V(G)=E-N+2=7-6+2=3
▫ Method 2
■ The number of bounded areas is 2.
■ V(G)=2+1=3
▫ Method 3
■ N=2
110 ■ V(G)=N+1=2+1=3

55
 22-04-2025

Example

▪ Total Number of linearly independent Paths

is 3 as the cyclomatic complexity is 3.
▪ The paths are
▫ 1-6
▫ 1-2-3-5-1-6
▫ 1-2-4-5-1-6

111

Example

▪ Test cases are

Test case Path executed

x=3, y=3 1-6

x=4, y=3 1-2-3-5-1-6

x=3, y=4 1-2-4-5-1-6

112

56
 22-04-2025

Data flow based Testing

▪ Data flow based testing method

selects test paths of a program
according to the definitions
and uses of different variables in a
program.

113

Data flow based Testing

▪ Consider a program P .
▪ For a statement numbered S of P, let
▫ DEF(S) = {X | statement S contains a definition of X}
and
▫ USES(S)= {X | statement S contains a use of X}
▪ For the statement S: a=b+c;
▫ DEF(S)={a},
▫ USES(S)={b, c}.
114

57
 22-04-2025

Data flow based Testing

▪ The definition of variable X at

statement S is said to be live at
statement S1, if there exists a path
from statement S to statement S1
which does not contain any definition
of X.
115

Test Coverage criteria in

Data flow based Testing

▪ All definitions criterion is a test

coverage criterion that requires that
test suite should cover at least one
use of all definition occurrences.
▪ All use criterion requires that all uses
of a definition should be covered.
116

58
 22-04-2025

Test Coverage criteria in

Data flow based Testing

▪ All definition-use-paths criterion, which

requires the coverage of all possible
definition-use paths that either are cycle-
free or have only simple cycles.
▪ A simple cycle is a path in which only the end
node and the start node are the same.

117

Test Coverage criteria in

Data flow based Testing

▪ A definition-use pair (or DU pair) of a

variable X is of the form [X,S,S1], where S and
S1 are statement numbers, such that
XϵDEF(S) and XϵUSES(S1), and the definition
of X in the statement S is live at statement
S1.

118

59
 22-04-2025

Test Coverage criteria in

Data flow based Testing

▪ A DU chain is a sequence of DU pairs.

▪ One simple data flow testing strategy
is to require that every DU chain be
covered at least once.

119

Test Coverage criteria in

Data flow based Testing

▪ All-uses criterion is stronger than all-

definitions criterion.
▪ An even stronger criterion is all
definition-use-paths criterion.
▪ A stronger coverage is the DU chain
coverage.
120

60
 22-04-2025

Mutation Testing

▪ Mutation testing is a fault-based testing technique in

the sense that mutation test cases are designed to
help detect specific types of faults in a program.
▪ In mutation testing, a program is first tested by using
an initial test suite designed by using various white
box testing strategies.
▪ After the initial testing is complete, mutation testing
can be taken up.

121

Mutation Testing

▪ The idea behind mutation testing is to make

a few arbitrary changes to a program at a
time.
▪ These changes correspond to simple
programming errors such as using an
inappropriate operator in an arithmetic
expression.
122

61
 22-04-2025

Mutation Testing

▪ Each time the program is changed, it is called

a mutated program and the specific change
effected is called a mutant.
▪ An underlying assumption behind mutation
testing is that all programming errors can be
expressed as a combination of several simple
errors.
123

Levels of Testing

▪ A software product is normally tested in three levels or

stages:
Unit testing
• During unit testing, the individual functions (or units) of a program are
tested.
Integration testing
• After testing all the units individually, the units are slowly integrated and
tested after each step of integration
System testing
124 • Finally, the fully integrated system is tested

62
 22-04-2025

Levels of Testing

▪ Why test each module (unit) in isolation first,

then integrate these modules and test, and
again test the integrated set of modules—
▫ why not just test the integrated set of
modules once thoroughly?
▪ There are two main reasons to it.

125

Levels of Testing

▪ While testing a module, other modules with which this

module needs to interface may not be ready.
▪ It is always a good idea to first test the module in isolation
before integration because it makes debugging easier.
▫ If a failure is detected when an integrated set of
modules is being tested,
■ it would be difficult to determine which module
exactly has the error, and
■ the code of a large number of modules may have to
be examined to localize the error.
126

63
 22-04-2025

Unit Testing

▪ Unit testing is undertaken after coding of a module is

complete, all syntax errors have been removed, and
the code has been reviewed.
▪ This activity is typically undertaken by the
coder of the module himself in the coding phase.
▪ Before carrying out unit testing,
▫ the unit test cases have to be designed and
▫ the test environment for the unit under test has
to be developed.
127

Integration Testing

▪ Integration testing is carried out after all (or

at least some of) the modules have been unit
tested.
▪ Successful completion of unit testing, to a
large extent, ensures that the unit (or
module) as a whole works satisfactorily.

128

64
 22-04-2025

Integration Testing

▪ In this context, the objective of integration

testing is to detect the errors at the module
interfaces (call parameters).
▪ For example, it is checked that no
parameter mismatch occurs when one
module invokes the functionality of another
module.
129

Integration Testing

▪ Thus, the primary objective of integration

testing is to test the module interfaces,
▫ i.e., there are no errors in parameter
passing, when one module invokes the
functionality of another module.
▪ The objective of integration testing is to
check whether the different modules of a
130
program interface with each other properly.

65
 22-04-2025

Approaches to Integration
Testing

1 • Big-bang approach
2 • Top-down approach
3 • Bottom-up approach
• Mixed (also called
4
sandwiched) approach
131

System Testing

▪ After all the units of a program have been

integrated together and tested, system
testing is taken up.
▪ System tests are designed to validate a fully
developed system to assure that it meets
its requirements.
▪ The test cases are therefore designed solely
132
based on the SRS document.

66
 22-04-2025

Kinds of System Testing

Alpha Testing
• Alpha testing refers to the system testing carried out by the test team
within the developing organisation.
Beta Testing
• Beta testing is the system testing performed by a select group of
friendly customers
Acceptance Testing
• Acceptance testing is the system testing performed by the customer
to determine whether to accept the delivery of the system
133

Performance Testing

▪ Performance testing is carried out to

check whether the system meets its
non-functional requirements
identified in the SRS document.

134

67
 22-04-2025

Performance Testing

▪ There are several types of performance testing

corresponding to various types of non-functional
requirements.
▪ For a specific system, the types of performance
testing to be carried out on a system depends on the
different non-functional requirements of the system
documented in its SRS document.
▪ All performance tests can be considered as black-box
tests.
135

Performance Testing

01 Performance 06
Testing
02 07

03 08

04 09

05 10
136

68
 22-04-2025

References

▪ Fundamentals of Software Engineering, Rajib

Mall, Fifth Edition

137

69