0% found this document useful (0 votes)

19 views

Software Testing Lec 1-3

Uploaded by

सेल्वनथीया लि

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

19 views

Software Testing Lec 1-3

Uploaded by

सेल्वनथीया लि

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 183

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
Softwar Testin
e g
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.

5
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.

6
Softwar Testin
e g

Fig. 1: Control flow graph

7
Software
Testing
The number of paths in the example of Fig. 1 are 1014 or 100 trillions. It is
computed from 520 + 519 + 518 + …… + 51; where 5 is the number of paths
through the loop body. If only 5 minutes are required to test one test path, it
may take approximately one billion years to execute every path.

8
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.

9
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.
10
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
Software
Testing
) Alpha, Beta and Acceptance Testing
The term Acceptance Testing is used when the software is developed for
a specific customer. A series of tests are conducted to enable the customer
to validate all requirements. These tests are conducted by the end user /
customer and may range from adhoc tests to well planned systematic
series of tests.
The terms alpha and beta testing are used when the software is developed
as a product for anonymous customers.
Alpha Tests are conducted at the developer’s site by some potential
customers. These tests are conducted in a controlled environment. Alpha
testing may be started when formal testing process is near completion.

Beta Tests are conducted by the customers / end users at their sites.
Unlike alpha testing, developer is not present here. Beta testing is
conducted in a real environment that cannot be controlled by the developer.
12
Softwar Testin
e g
Functional Testing
Input Output
domain domain

System
Input test Output
under
data test data
test

Fig. 3: Black box testing

13
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 b
x
Fig.4: Input domain for program having two input variables
14
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 300 400

x
Fig. 5: Input domain of two variables x and y with
boundaries [100,300] each
15
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.

16
Softwar Testin
e g
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

17
Softwar Testin
e g
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

18
Software
Testing
Robustness testing
It is nothing but the extension of boundary value analysis. Here, we would
like to see, what happens when the extreme values are exceeded with a
value slightly greater than the maximum, and a value slightly less than
minimum. It means, we want to go outside the legitimate boundary of input
domain. This extended form of boundary value analysis is called
robustness testing and shown in Fig. 6

There are four additional test cases which are outside the legitimate input
domain. Hence total test cases in robustness testing are 6n+1, where n is
the number of input variables. So, 13 test cases are:

(200,99), (200,100), (200,101), (200,200), (200,299), (200,300)

(200,301), (99,200), (100,200), (101,200), (299,200), (300,200), (301,200)

24
Softwar Testin
e g
400
300
y 200
100

0 100 200 300 400

Fig. 8.6: Robustness test cases for two variables x

and y with range [100,300] each

25
Software
Testing
Worst-case testing

If we reject “single fault” assumption theory of reliability and may like to see
what happens when more than one variable has an extreme value. In
electronic circuits analysis, this is called “worst case analysis”. It is more
thorough in the sense that boundary value test cases are a proper subset
of worst case test cases. It requires more effort. Worst case testing for a
function of n variables generate 5n test cases as opposed to 4n+1 test
cases for boundary value analysis. Our two variables example will have
52=25 test cases and are given in table 1.

26
Software
Testing
Table 1: Worst cases test inputs for two variables example

Test case Inputs Test case Inputs

number number
x y x y
1 100 100 14 200 299
2 100 101 15 200 300
3 100 200 16 299 100
4 100 299 17 299 101
5 100 300 18 299 200
6 101 100 19 299 299
7 101 101 20 299 300
8 101 200 21 300 100
9 101 299 22 300 101
10 101 300 23 300 200
11 200 100 24 300 299
12 200 101 25 300 300
13 200 200 --

27
Software
Testing
Example - 8.4

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

equation as explained in example 8.1. Design the Robust test case and worst
test cases for this program.

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

Robust test cases are 6n+1. Hence, in 3 variable input cases total number
of test cases are 19 as given on next slide:

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 29
Softwar Testin
Test case a
e g b c Expected Output

1 -1 50 50 Invalid input`

2 0 50 50 Not quadratic equation

3 1 50 50 Real roots
4 50 50 50 Imaginary roots
5 99 50 50 Imaginary roots
6 100 50 50 Imaginary roots
7 101 50 50 Invalid input
8 50 -1 50 Invalid input
9 50 0 50 Imaginary roots
10 50 1 50 Imaginary roots
11 50 99 50 Imaginary roots
12 50 100 50 Equal roots

13 50 101 50 Invalid input

14 50 50 -1 Invalid input

15 50 50 0 Real roots

16 50 50 1 Real roots
17 50 50 99 Imaginary roots
18 50 50 100 Imaginary roots
19 50 50 101 Invalid input
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 30
Software
Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be
generated in worst test cases. The worst test cases are given below:
Test Case a b c Expected output

1 0 0 0 Not Quadratic
2 0 0 1 Not Quadratic
3 0 0 50 Not Quadratic
4 0 0 99 Not Quadratic
5 0 0 100 Not Quadratic
6 0 1 0 Not Quadratic
7 0 1 1 Not Quadratic
8 0 1 50 Not Quadratic
9 0 1 99 Not Quadratic
10 0 1 100 Not Quadratic
11 0 50 0 Not Quadratic
12 0 50 1 Not Quadratic
13 0 50 50 Not Quadratic
14 0 50 99 Not Quadratic

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 31
Softwar Testin
e g
Test Case A b c Expected output

15 0 50 100 Not Quadratic

16 0 99 0 Not Quadratic
17 0 99 1 Not Quadratic
18 0 99 50 Not Quadratic
19 0 99 99 Not Quadratic
20 0 99 100 Not Quadratic
21 0 100 0 Not Quadratic
22 0 100 1 Not Quadratic
23 0 100 50 Not Quadratic
24 0 100 99 Not Quadratic
25 0 100 100 Not Quadratic
26 1 0 0 Equal Roots
27 1 0 1 Imaginary
28 1 0 50 Imaginary
29 1 0 99 Imaginary
30 1 0 100 Imaginary
31 1 1 0 Real Roots
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 32
Softwar Testin
e g
Test Case A b C Expected output

32 1 1 1 Imaginary
33 1 1 50 Imaginary
34 1 1 99 Imaginary
35 1 1 100 Imaginary
36 1 50 0 Real Roots
37 1 50 1 Real Roots
38 1 50 50 Real Roots
39 1 50 99 Real Roots
40 1 50 100 Real Roots
41 1 99 0 Real Roots
42 1 99 1 Real Roots
43 1 99 50 Real Roots
44` 1 99 99 Real Roots
45 1 99 100 Real Roots
46 1 100 0 Real Roots
47 1 100 1 Real Roots
48 1 100 50 Real Roots
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 33
Softwar Testin
e g
Test Case A b C Expected output

49 1 100 99 Real Roots

50 1 100 100 Real Roots
51 50 0 0 Equal Roots
52 50 0 1 Imaginary
53 50 0 50 Imaginary
54 50 0 99 Imaginary
55 50 0 100 Imaginary
56 50 1 0 Real Roots
57 50 1 1 Imaginary
58 50 1 50 Imaginary
59 50 1 99 Imaginary
60 50 1 100 Imaginary
61 50 50 0 Real Roots
62 50 50 1 Real Roots
63 50 50 50 Imaginary
64 50 50 99 Imaginary
65 50 50 100 Imaginary
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 34
Softwar Testin
Test Case A
e g b C Expected output

66 50 99 0 Real Roots
67 50 99 1 Real Roots
68 50 99 50 Imaginary
69 50 99 99 Imaginary
70 50 99 100 Imaginary
71 50 100 0 Real Roots
72 50 100 1 Real Roots
73 50 100 50 Equal Roots
74 50 100 99 Imaginary
75 50 100 100 Imaginary
76 99 0 0 Equal Roots
77 99 0 1 Imaginary
78 99 0 50 Imaginary
79 99 0 99 Imaginary
80 99 0 100 Imaginary
81 99 1 0 Real Roots
82 99 1 1 Imaginary

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
35
Softwar Testin
e g
Test Case A b C Expected output

83 99 1 50 Imaginary
84 99 1 99 Imaginary
85 99 1 100 Imaginary
86 99 50 0 Real Roots
87 99 50 1 Real Roots
88 99 50 50 Imaginary
89 99 50 99 Imaginary
90 99 50 100 Imaginary
91 99 99 0 Real Roots
92 99 99 1 Real Roots
93 99 99 50 Imaginary Roots
94 99 99 99 Imaginary
95 99 99 100 Imaginary
96 99 100 0 Real Roots
97 99 100 1 Real Roots
98 99 100 50 Imaginary
99 99 100 99 Imaginary
100 99 100 100 Imaginary
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 36
Softwar Testin
Test Case A
e g b C Expected output

101 100 0 0 Equal Roots

102 100 0 1 Imaginary
103 100 0 50 Imaginary
104 100 0 99 Imaginary
105 100 0 100 Imaginary
106 100 1 0 Real Roots
107 100 1 1 Imaginary
108 100 1 50 Imaginary
109 100 1 99 Imaginary
110 100 1 100 Imaginary
111 100 50 0 Real Roots
112 100 50 1 Real Roots
113 100 50 50 Imaginary
114 100 50 99 Imaginary
115 100 50 100 Imaginary
116 100 99 0 Real Roots
117 100 99 1 Real Roots
118 100 99 50 Imaginary

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
37
Softwar Testin
e g
Test Case A b C Expected output

119 100 99 99 Imaginary

120 100 99 100 Imaginary
121 100 100 0 Real Roots
122 100 100 1 Real Roots
123 100 100 50 Imaginary
124 100 100 99 Imaginary
125 100 100 100 Imaginary

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

Consider the program for the determination of previous date in a calendar as

explained in example 8.2. Design the robust and worst test cases for this
program.

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

Robust test cases are 6n+1. Hence total 19 robust test cases are designed
and are given on next slide.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 40
Softwar Testin
Test case
1
Month
6
e g Day
15
Year
1899
Expected Output
Invalid date (outside range)

2 6 15 1900 14 June, 1900

3 6 15 1901 14 June, 1901

4 6 15 1962 14 June, 1962

5 6 15 2024 14 June, 2024

6 6 15 2025 14 June, 2025

7 6 15 Invalid date (outside range)
2026
8 6 0 1962 Invalid date
9 6 1 1962 31 May, 1962

10 6 2 1962 1 June, 1962

11 6 30 1962 29 June, 1962

12 6 31 1962 Invalid date

13 6 32 1962 Invalid date
14 0 15 1962 Invalid date

15 1 15 1962 14 January, 1962

16 2 15 1962 14 February, 1962

17 11 15 1962 14 November, 1962

18 12 15 1962 14 December, 1962

19 13 15 1962 Invalid date

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 41
Software
Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be
generated in worst test cases. The worst test cases are given below:
Test Case Month Day Year Expected output

1 1 1 1900 31 December, 1899

2 1 1 1901 31 December, 1900
3 1 1 1962 31 December, 1961
4 1 1 2024 31 December, 2023
5 1 1 2025 31 December, 2024
6 1 2 1900 1 January, 1900
7 1 2 1901 1 January, 1901
8 1 2 1962 1 January, 1962
9 1 2 2024 1 January, 2024
10 1 2 2025 1 January, 2025
11 1 15 1900 14 January, 1900
12 1 15 1901 14 January, 1901
13 1 15 1962 14 January, 1962
14 1 15 2024 14 January, 2024

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 42
Softwar Testin
e g
Test Case A b c Expected output

15 1 15 2025 14 January, 2025

16 1 30 1900 29 January, 1900
17 1 30 1901 29 January, 1901
18 1 30 1962 29 January, 1962
19 1 30 2024 29 January, 2024
20 1 30 2025 29 January, 2025
21 1 31 1900 30 January, 1900
22 1 31 1901 30 January, 1901
23 1 31 1962 30 January, 1962
24 1 31 2024 30 January, 2024
25 1 31 2025 30 January, 2025
26 2 1 1900 31 January, 1900
27 2 1 1901 31 January, 1901
28 2 1 1962 31 January, 1962
29 2 1 2024 31 January, 2024
30 2 1 2025 31 January, 2025
31 2 2 1900 1 February, 1900
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 43
Softwar Testin
e g
Test Case Month Day Year Expected output

32 2 2 1901 1 February, 1901

33 2 2 1962 1 February, 1962
34 2 2 2024 1 February, 2024
35 2 2 2025 1 February, 2025
36 2 15 1900 14 February, 1900
37 2 15 1901 14 February, 1901
38 2 15 1962 14 February, 1962
39 2 15 2024 14 February, 2024
40 2 15 2025 14 February, 2025
41 2 30 1900 Invalid date
42 2 30 1901 Invalid date
43 2 30 1962 Invalid date
44 2 30 2024 Invalid date
45 2 30 2025 Invalid date
46 2 31 1900 Invalid date
47 2 31 1901 Invalid date
48 2 31 1962 Invalid date
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 44
Softwar Testin
e g
Test Case Month Day Year Expected output

49 2 31 2024 Invalid date

50 2 31 2025 Invalid date
51 6 1 1900 31 May, 1900
52 6 1 1901 31 May, 1901
53 6 1 1962 31 May, 1962
54 6 1 2024 31 May, 2024
55 6 1 2025 31 May, 2025
56 6 2 1900 1 June, 1900
57 6 2 1901 1 June, 1901
58 6 2 1962 1 June, 1962
59 6 2 2024 1 June, 2024
60 6 2 2025 1 June, 2025
61 6 15 1900 14 June, 1900
62 6 15 1901 14 June, 1901
63 6 15 1962 14 June, 1962
64 6 15 2024 14 June, 2024
65 6 15 2025 14 June, 2025
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 45
Softwar Testin
e g
Test Case Month Day Year Expected output

66 6 30 1900 29 June, 1900

67 6 30 1901 29 June, 1901
68 6 30 1962 29 June, 1962
69 6 30 2024 29 June, 2024
70 6 30 2025 29 June, 2025
71 6 31 1900 Invalid date
72 6 31 1901 Invalid date
73 6 31 1962 Invalid date
74 6 31 2024 Invalid date
75 6 31 2025 Invalid date
76 11 1 1900 31 October, 1900
77 11 1 1901 31 October, 1901

78 11 1 1962 31 October, 1962

79 11 1 2024 31 October, 2024
80 11 1 2025 31 October, 2025
81 11 2 1900 1 November, 1900
82 11 2 1901 1 November, 1901
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 46
Softwar Testin
Test Case Month
e g Day Year Expected output

83 11 2 1962 1 November, 1962

84 11 2 2024 1 November, 2024
85 11 2 2025 1 November, 2025
86 11 15 1900 14 November, 1900
87 11 15 1901 14 November, 1901
88 11 15 1962 14 November, 1962
89 11 15 2024 14 November, 2024
90 11 15 2025 14 November, 2025
91 11 30 1900 29 November, 1900
92 11 30 1901 29 November, 1901
93 11 30 1962 29 November, 1962
94 11 30 2024 29 November, 2024
95 11 30 2025 29 November, 2025
96 11 31 1900 Invalid date
97 11 31 1901 Invalid date
98 11 31 1962 Invalid date
99 11 31 2024 Invalid date
100 11 31 2025 Invalid date

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 47
Softwar Testin
Test Case Month
e g Day Year Expected output

101 12 1 1900 30 November, 1900

102 12 1 1901 30 November, 1901
103 12 1 1962 30 November, 1962
104 12 1 2024 30 November, 2024
105 12 1 2025 30 November, 2025
106 12 2 1900 1 December, 1900
107 12 2 1901 1 December, 1901
108 12 2 1962 1 December, 1962
109 12 2 2024 1 December, 2024
110 12 2 2025 1 December, 2025
111 12 15 1900 14 December, 1900
112 12 15 1901 14 December, 1901
113 12 15 1962 14 December, 1962
114 12 15 2024 14 December, 2024
115 12 15 2025 14 December, 2025
116 12 30 1900 29 December, 1900
117 12 30 1901 29 December, 1901
118 12 30 1962 29 December, 1962
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 48
Softwar Testin
e g
Test Case Month Day Year Expected output

119 12 30 2024 29 December, 2024

120 12 30 2025 29 December, 2025
121 12 31 1900 30 December, 1900
122 12 31 1901 30 December, 1901
123 12 31 1962 30 December, 1962
124 12 31 2024 30 December, 2024
125 12 31 2025 30 December, 2025

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

Consider the triangle problem as given in example 8.3. Generate robust and
worst test cases for this problem.

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

Robust test cases are given on next slide.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 51
Softwar Testin
` x e g y z Expected Output

1 50 50 0 Invalid input`

2 50 50 1 Isosceles

3 50 50 2 Isosceles

4 50 50 50 Equilateral
5 50 50 99 Isosceles

6 50 50 100 Not a triangle

7 50 50 Invalid input
101
8 50 0 50 Invalid input
9 50 1 50 Isosceles

10 50 2 50 Isosceles
11 50 99 50 Isosceles

12 50 100 50 Not a triangle

13 50 101 50 Invalid input
14 0 50 50 Invalid input

15 1 50 50 Isosceles
16 2 50 50 Isosceles

17 99 50 50 Isosceles
18 100 50 50 Not a triangle

19 100 50 50 Invalid input

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 52
Software
Testing
Worst test cases are 125 and are given below:

Test Case x y z Expected output

1 1 1 1 Equilateral
2 1 1 2 Not a triangle
3 1 1 50 Not a triangle
4 1 1 99 Not a triangle
5 1 1 100 Not a triangle
6 1 2 1 Not a triangle
7 1 2 2 Isosceles
8 1 2 50 Not a triangle
9 1 2 99 Not a triangle
10 1 2 100 Not a triangle
11 1 50 1 Not a triangle
12 1 50 2 Not a triangle
13 1 50 50 Isosceles
14 1 50 99 Not a triangle

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 53
Softwar Testin
e g
Test Case A b c Expected output

15 1 50 100 Not a triangle

16 1 99 1 Not a triangle
17 1 99 2 Not a triangle
18 1 99 50 Not a triangle
19 1 99 99 Isosceles
20 1 99 100 Not a triangle
21 1 100 1 Not a triangle
22 1 100 2 Not a triangle
23 1 100 50 Not a triangle
24 1 100 99 Not a triangle
25 1 100 100 Isosceles
26 2 1 1 Not a triangle
27 2 1 2 Isosceles
28 2 1 50 Not a triangle
29 2 1 99 Not a triangle
30 2 1 100 Not a triangle
31 2 2 1 Isosceles
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 54
Softwar Testin
e g
Test Case A b C Expected output

32 2 2 2 Equilateral
33 2 2 50 Not a triangle
34 2 2 99 Not a triangle
35 2 2 100 Not a triangle
36 2 50 1 Not a triangle
37 2 50 2 Not a triangle
38 2 50 50 Isosceles
39 2 50 99 Not a triangle
40 2 50 100 Not a triangle
41 2 99 1 Not a triangle
42 2 99 2 Not a triangle
43 2 99 50 Not a triangle
44 2 99 99 Isosceles
45 2 99 100 Scalene
46 2 100 1 Not a triangle
47 2 100 2 Not a triangle
48 2 100 50 Not a triangle
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 55
Softwar Testin
e g
Test Case A b C Expected output

49 2 100 50 Scalene
50 2 100 99 Isosceles
51 50 1 100 Not a triangle
52 50 1 1 Not a triangle
53 50 1 2 Isosceles
54 50 1 50 Not a triangle
55 50 1 99 Not a triangle
56 50 2 100 Not a triangle
57 50 2 1 Not a triangle
58 50 2 2 Isosceles
59 50 2 50 Not a triangle
60 50 2 99 Not a triangle
61 50 50 100 Isosceles
62 50 50 1 Isosceles
63 50 50 2 Equilateral
64 50 50 50 Isosceles
65 50 50 99 Not a triangle
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 56
Softwar Testin
e g
Test Case A B C Expected output

66 50 99 1 Not a triangle
67 50 99 2 Not a triangle
68 50 99 50 Isosceles
69 50 99 99 Isosceles
70 50 99 100 Scalene
71 50 100 1 Not a triangle
72 50 100 2 Not a triangle
73 50 100 50 Not a triangle
74 50 100 99 Scalene
75 50 100 100 Isosceles
76 50 1 1 Not a triangle
77 99 1 2 Not a triangle
78 99 1 50 Not a triangle
79 99 1 99 Isosceles
80 99 1 100 Not a triangle
81 99 2 1 Not a triangle
82 99 2 2 Not a triangle
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 57
Softwar Testin
Test Case A
e g b C Expected output

83 99 2 50 Not a triangle
84 99 2 99 Isosceles
85 99 2 100 Scalene
86 99 50 1 Not a triangle
87 99 50 2 Not a triangle
88 99 50 50 Isosceles
89 99 50 99 Isosceles
90 99 50 100 Scalene
91 99 99 1 Isosceles
92 99 99 2 Isosceles
93 99 99 50 Isosceles
94 99 99 99 Equilateral
95 99 99 100 Isosceles
96 99 100 1 Not a triangle
97 99 100 2 Scalene
98 99 100 50 Scalene
99 99 100 99 Isosceles
100 99 100 100 Isosceles

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 58
Softwar Testin
Test Case A
e g b C Expected output

101 100 1 1 Not a triangle

102 100 1 2 Not a triangle
103 100 1 50 Not a triangle
104 100 1 99 Not a triangle
105 100 1 100 Isosceles
106 100 2 1 Not a triangle
107 100 2 2 Not a triangle
108 100 2 50 Not a triangle
109 100 2 99 Scalene
110 100 2 100 Isosceles
111 100 50 1 Not a triangle
112 100 50 2 Not a triangle
113 100 50 50 Not a triangle
114 100 50 99 Scalene
115 100 50 100 Isosceles
116 100 99 1 Not a triangle
117 100 99 2 Scalene
118 100 99 50 Scalene

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 59
Softwar Testin
e g
Test Case A b C Expected output

119 100 99 99 Isosceles

120 100 99 100 Isosceles
121 100 100 1 Isosceles
122 100 100 2 Isosceles
123 100 100 50 Isosceles
124 100 100 99 Isosceles
125 100 100 100 Equilateral

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 60
Software
Testing
Equivalence Class Testing
In this method, input domain of a program is partitioned into a finite number of
equivalence classes such that one can reasonably assume, but not be
absolutely sure, that the test of a representative value of each class is
equivalent to a test of any other value.
Two steps are required to implementing this method:

1. The equivalence classes are identified by taking each input condition and
partitioning it into valid and invalid classes. For example, if an input
condition specifies a range of values from 1 to 999, we identify one valid
equivalence class [1<item<999]; and two invalid equivalence classes
[item<1] and [item>999].

2. Generate the test cases using the equivalence classes identified in the
previous step. This is performed by writing test cases covering all the valid
equivalence classes. Then a test case is written for each invalid equivalence
class so that no test contains more than one invalid class. This is to ensure
that no two invalid classes mask each other.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 61
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 62
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 63
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 64
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 =
I8= {b: b > 100}
I9= {c: 0 ≤ c ≤ 100}
{c: c < 0}
I10={c: c > 100}

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 65
Softwar Testin
e g
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. If we choose any value other
than nominal, we may not have redundant test cases. Hence total test cases are
10+4=14 for this problem.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 66
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 67
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 68
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}
I ={month: m > 12}
3
I4={day: 1 ≤ D ≤ 31}

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

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 69
Softwar Testin
e g
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 70
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 (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 71
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

50 50 Equilateral
1 50
2 50 50 99 Isosceles

3 100 99 50 Scalene
4 50 100 50 Not a triangle

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 72
Softwar Testin
e g
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:
I7={z: 1 ≤ y ≤ 100}
I8={z: z < 1}
I9={z: z > 100}
1 ≤ z ≤ 100}

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 73
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, x ≠ z, y ≠ z}
I15={< x,y,z
I16={< x,y,z >: x = y + z}
I17={< x,y,z >: x > y +z}
I18={< x,y,z >: y = x +z}
I19={<
x,y,z >: y > x + z}
I20={<
x,y,z >: z = x + y}
x,y,z >: z > x +y}

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 74
Software
Testing
Test cases derived from input domain are:

Test case x y z Expected Output

0 50 Invalid input
1 50
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 Invalid input
0
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

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 75
Softwar Testin
e g

Test case x y z Expected Output

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

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 76
Softwar Testin
e g
Decision Table Based Testing

Condition Entry
Stub
True False
C1
True False True False
C2

True False True False True False ---

Action a1 X X X
Stub
a2 X X X

a3
X X
a4
X X X

Table 2: Decision table terminology

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 77
Softwar Testin
e g
Test case design

C1:x,y,z are sides of a triangle? N Y

C2:x = y? -- Y N
C3:x = z? -- Y N Y N
C4:y = z? N N Y
-- Y Y N Y N
a1: Not a triangle X

a2: Scalene X

a3: Isosceles X X X

a4: Equilateral X
a5: Impossible X X X

Table 3: Decision table for triangle problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 78
Softwar Testin
e g
Conditions F T T T T T T T T T T
C1 : x < y + z ?
C2 : y < x + z ? -- F T T T T T T T T T

C3 : z < x + y ? -- -- F T T T T T T T T

C4 : x = y ? -- -- -- T T T T F F F F

C5 : x = z ? -- -- -- T T F F T T F F

C6 : y = z ? -- -- -- T F T F T F T F

a1 : Not a triangle X X X

a2 : Scalene X

a3 : Isosceles X X X

a4 : Equilateral X

a5 : Impossible X X X

Table 4: Modified decision table

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

Consider the triangle program specified in example 8.3. Identify the

test cases using the decision table of Table 4.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 80
Software
Solution
Testing
There are eleven functional test cases, three to fail triangle property, three
impossible cases, one each to get equilateral, scalene triangle cases, and
three to get on isosceles triangle. The test cases are given in Table 5.
Test case x y z Expected Output

4 2 Not a triangle
1 1
2 1 4 2 Not a triangle

3 1 2 4 Not a triangle
4 5 5 5 Equilateral
5 ? ? ? Impossible
6 ? ? ? Impossible
7 2 2 3 Isosceles
8 ? ? ? Impossible
9 2 3 2 Isosceles
10 3 2 2 Isosceles
11 3 4 5 Scalene

Test cases of triangle problem using decision table

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

Consider a program for the determination of 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 are “Previous date” and “Invalid date”. Design the test cases
using decision table based testing.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 82
Software
Solution Testing
The input domain can be divided into following classes:
I1= {M1: month has 30 days}
I2= {M2: month has 31 days except March, August and January}
I3= {M3: month is March}
I4= {M4: month is August}
I5= {M5:
month is January}
I6= {M6:
I7= {D1: month is February}
I8 = day = 1}
I9= {D2: 2 ≤ day ≤ 28}
{D3: day = 29}
I10={D4: day = 30}
I11={D5: day = 31}
I12={Y1: year is a leap year}
I13={Y2: year is a common year}
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 83
Softwar Testin
The decision table is givenebelow: g
Sr.No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

C1: Months in M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M2 M2 M2 M2 M2

C2: days in D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D1 D1 D2 D2 D3

C3: year in Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1

a1: Impossible X X

a2: Decrement day X X X X X X X X X

a3: Reset day to 31 X X

a4: Reset day to 30 X X

a5: Reset day to 29

a6: Reset day to 28

a7: decrement month X X X X

a8: Reset month to December

a9: Decrement year

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 84
Softwar Testin
e g
Sr.No. 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

C1: Months in M2 M2 M2 M2 M2 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3

C2: days in D3 D4 D4 D5 D5 D1 D1 D2 D2 D3 D3 D4 D4 D5 D5

C3: year in Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2

a1: Impossible

a2: Decrement day X X X X X X X X X X X X X

a3: Reset day to 31

a4: Reset day to 30

a5: Reset day to 29 X

a6: Reset day to 28 X

a7: decrement month X X

a8: Reset month to December

a9: Decrement year

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 85
Softwar Testin
e g
Sr.No. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

C1: Months in M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M5 M5 M5 M5 M5

C2: days in D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D1 D1 D2 D2 D3

C3: year in Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1

a1: Impossible

a2: Decrement day X X X X X X X X X X X

a3: Reset day to 31 X X X X

a4: Reset day to 30

a5: Reset day to 29

a6: Reset day to 28

a7: decrement month X X

a8: Reset month to December X X

a9: Decrement year X X

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 86
Softwar Testin
e g
Sr.No. 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

C1: Months in M5 M5 M5 M5 M5 M6 M6 M6 M6 M6 M6 M6 M6 M6 M6

C2: days in D3 D4 D4 D5 D5 D1 D1 D2 D2 D3 D3 D4 D4 D5 D5

C3: year in Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2

a1: Impossible X X X X X

a2: Decrement day X X X X X X X X

a3: Reset day to 31 X X

a4: Reset day to 30

a5: Reset day to 29

a6: Reset day to 28

a7: decrement month X X

a8: Reset month to December

a9: Decrement year

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 87
Softwar Testin
e g
Test case Month Day Year Expected output
1 June 1 1964 31 May, 1964
2 June 1 1962 31 May, 1962
3 June 15 1964 14 June, 1964
4 June 15 1962 14 June, 1962
5 June 29 1964 28 June, 1964
6 June 29 1962 28 June, 1962
7 June 30 1964 29 June, 1964
8 June 30 1962 29 June, 1962
9 June 31 1964 Impossible
10 June 31 1962 Impossible
11 May 1 1964 30 April, 1964
12 May 1 1962 30 April, 1962
13 May 15 1964 14 May, 1964
14 May 15 1962 14 May, 1962
15 May 29 1964 28 May, 1964

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 88
Softwar Testin
Test case Month
e g Day Year Expected output
16 May 29 1962 28 May, 1962
17 May 30 1964 29 May, 1964
18 May 30 1962 29 May, 1962
19 May 31 1964 30 May, 1964
20 May 31 1962 30 May, 1962
21 March 1 1964 29 February, 1964
22 March 1 1962 28 February, 1962
23 March 15 1964 14 March, 1964
24 March 15 1962 14 March, 1962
25 March 29 1964 28 March, 1964
26 March 29 1962 28 March, 1962
27 March 30 1964 29 March, 1964
28 March 30 1962 29 March, 1962
29 March 31 1964 30 March, 1964
30 March 31 1962 30 March, 1962

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 89
Softwar Testin
e g
Test case Month Day Year Expected output
31 August 1 1964 31 July, 1962
32 August 1 1962 31 July, 1964
33 August 15 1964 14 August, 1964
34 August 15 1962 14 August, 1962
35 August 29 1964 28 August, 1964
36 August 29 1962 28 August, 1962
37 August 30 1964 29 August, 1964
38 August 30 1962 29 August, 1962
39 August 31 1964 30 August, 1964
40 August 31 1962 30 August, 1962
41 January 1 1964 31 December, 1964
42 January 1 1962 31 December, 1962
43 January 15 1964 14 January, 1964
44 January 15 1962 14 January, 1962
45 January 29 1964 28 January, 1964

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 90
Softwar Testin
Test case Month
e g Day Year Expected output
46 January 29 1962 28 January, 1962
47 January 30 1964 29 January, 1964
48 January 30 1962 29 January, 1962
49 January 31 1964 30 January, 1964
50 January 31 1962 30 January, 1962
51 February 1 1964 31 January, 1964
52 February 1 1962 31 January, 1962
53 February 15 1964 14 February, 1964
54 February 15 1962 14 February, 1962
55 February 29 1964 28 February, 1964
56 February 29 1962 Impossible
57 February 30 1964 Impossible
58 February 30 1962 Impossible
59 February 31 1964 Impossible
60 February 31 1962 Impossible

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 91
Software
Testing
Cause Effect Graphing Technique
• Consider single input conditions
• do not explore combinations of input circumstances
Steps
1. Causes & effects in the specifications are identified.
A cause is a distinct input condition or an equivalence class of input conditions.

An effect is an output condition or a system transformation.

2. The semantic content of the specification is analysed and transformed into a

boolean graph linking the causes & effects.

3. Constraints are imposed

4. graph – limited entry decision table

Each column in the table represent a test case.

5. The columns in the decision table are converted into test cases.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 92
Software
Testing
The basic notation for the graph is shown in fig. 8

Fig.8. 8 : Basic cause effect graph symbols

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 93
Software
Testing
Myers explained this effectively with following example. “The characters in column 1
must be an A or B. The character in column 2 must be a digit. In this situation, the
file update is made. If the character in column 1 is incorrect, message x is issued. If
the character in column 2 is not a digit, message y is issued”.
The causes are
c1: character in column 1 is A
c2: character in column 1 is B
c3: character in column 2 is a digit

and the effects are

e1: update made
e2: message x is issued
e3: message y is issued

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 94
Softwar Testin
e g

Fig. 9: Sample cause effect graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 95
Software
Testing
The E constraint states that it must always be true that at most
one of c1 or c2 can be 1 (c1 or c2 cannot be 1 simultaneously). The
I constraint states that at least one of c1, c2 and c3 must always be
1 (c1, c2 and c3 cannot be 0 simultaneously). The O constraint
states that one, and only one, of c1 and c2 must be 1. The
constraint R states that, for c1 to be 1, c2 must be 1 (i.e. it is
impossible for c1 to be 1 and c2 to be 0),

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 96
Softwar Testin
e g

Fig. 10: Constraint symbols

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 97
Softwar Testin
e g

Fig. 11: Symbol for masks constraint

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 98
Softwar Testin
e g

Fig. 12 : Sample cause effect graph with exclusive constraint

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 99
Softwar Testin
e g
Example 8.12
Consider the triangle problem specified in the example 8.3. Draw the Cause
effect graph and identify the test cases.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 100
Software
Solution
Testing
The causes are
c1: side x is less than sum of sides y and z
c2: side y is less than sum of sides x and y
c3: side z is less than sum of sides x and y
c4: side x is equal to side y
c5:
side x is equal to side z
c6:
side y is equal to side z

and effects are

e1: Not a triangle
e2: Scalene triangle
e3: Isosceles triangle
e4: Equilateral triangle
e5:
Impossible stage

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 101
Software
Testing
The cause effect graph is shown in fig. 13 and decision table is shown in table 6.
The test cases for this problem are available in Table 5.
Conditions
C1: x < y + z ? 0 1 1 1 1 1 1 1 1 1 1
C2: y < x + z ? X 0 1 1 1 1 1 1 1 1 1
C3: z < x + y ? X X 0 1 1 1 1 1 1 1
1
C4: x = y ? X X X 1 1 1 1 0 0 0 0
C5: x = z ? X X X 1 1 0 0 1 1 0 0
C6: y = z ? X X X 1 0 1 0 1 0 1 0
e1: Not a triangle 1 1 1
e2: Scalene 1
e3: Isosceles 1 1 1
e4: Equilateral 1
e5: Impossible 1 1 1

Table 6: Decision table

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 102
Softwar Testin
e g

Fig. 13: Cause effect graph of triangle problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 103
Software
Testing
Structural Testing
A complementary approach to functional testing is called structural / white box
testing. It permits us to examine the internal structure of the program.

Path Testing
Path testing is the name given to a group of test techniques based on judiciously
selecting a set of test paths through the program. If the set of paths is properly
chosen, then it means that we have achieved some measure of test thoroughness.

This type of testing involves:

1. generating a set of paths that will cover every branch in the program.

2. finding a set of test cases that will execute every path in the set of program
paths.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 104
Software
Testing
Flow Graph
The control flow of a program can be analysed using a graphical representation
known as flow graph. The flow graph is a directed graph in which nodes are either
entire statements or fragments of a statement, and edges represents flow of control.

Fig. 14: The basic construct of the flow graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 105
Softwar Testin
e g

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 106
Softwar Testin
e g

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 107
Softwar Testin
e g

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 108
Softwar Testin
e g

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 109
Softwar Testin
e g

Fig. 15: Program for previous date problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 110
Softwar Testin
e g

Fig. 16: Flow graph of previous date

problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 111
Software
Testing
DD Path Graph
Table 7: Mapping of flow graph nodes and DD path nodes
Flow graph DD Path graph Remarks
nodes corresponding
node
1 to 9 n1 There is a sequential flow from node 1 to 9
10 n2 Decision node, if true go to 13 else go to 44
11 n3 Decision node, if true go to 12 else go to 19
12 n4 Decision node, if true go to 13 else go to 15
13,14 n5 Sequential nodes and are combined to form new node n5
15,16,17 n6 Sequential nodes
18 n7 Edges from node 14 to 17 are terminated here
19 n8 Decision node, if true go to 20 else go to 37
20 n9 Intermediate node with one input edge and one output edge
21 n10 Decision node, if true go to 22 else go to 27
22 n11 Intermediate node
23 n12 Decision node, if true go to 24 else go to 26

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
Cont…11.
2
Softwar Testin
e g
Flow graph DD Path graph Remarks
nodes corresponding
node
24,25 n13 Sequential nodes
26 n14 Two edges from node 25 & 23 are terminated here
27 n15 Two edges from node 26 & 21 are terminated here. Also a decision node
28,29 n16 Sequential nodes
30 n17 Decision node, if true go to 31 else go to 33
31,32 n18 Sequential nodes
33,34,35 n19 Sequential nodes

36 n20 Three edge from node 29,32 and 35 are terminated here
37 n21 Decision node, if true go to 38 else go to 40
38,39 n22 Sequential nodes
40,41,42 n23 Sequential nodes
43 n24 Three edge from node 36,39 and 42 are terminated here

Cont….
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 113
Softwar Testin
e g
Flow graph DD Path graph Remarks
nodes corresponding
node
44 n25 Decision node, if true go to 45 else go to 82. Three edges from 18,43 & 10
are also terminated here.
45 n26 Decision node, if true go to 46 else go to 77
46 n27 Decision node, if true go to 47 else go to 51
47,48,49,50 n28 Sequential nodes
51 n29 Decision node, if true go to 52 else go to 68
52 n30 Intermediate node with one input edge & one output ege
53 n31 Decision node, if true go to 54 else go to 59
54 n32 Intermediate node
55 n33 Decision node, if true go to 56 else go to 58
56,57 n34 Sequential nodes
58 n35 Two edge from node 57 and 55 are terminated here
59 n36 Decision node, if true go to 60 else go to 63. Two edge from nodes 58 and
53 are terminated.

Cont….
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 114
Softwar Testin
e g
Flow graph DD Path graph Remarks
nodes corresponding
node
60,61,62 n37 Sequential nodes
63,64,65,66 n38 Sequential nodes
67 n39 Two edge from node 62 and 66 are terminated here
68 n40 Decision node, if true go to 69 else go to 72
69,70,71 n41 Sequential nodes
72,73,74,75 n42 Sequential nodes
76 n43 Four edges from nodes 50, 67, 71 and 75 are terminated here.
77,78,79 n44 Sequential nodes
80 n45 Two edges from nodes 76 & 79 are terminated here
81 n46 Intermediate node
82,83,84 n47 Sequential nodes
85 n48 Two edges from nodes 81 and 84 are terminated here
86,87 n49 Sequential nodes with exit node

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 115
Softwar Testin
e g

Fig. 17: DD path graph

of previous date
problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 116
Softwar Testin
e g

Fig. 18: Independent paths of previous date problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 117
Software
Testing
Example 8.13
Consider the problem for the determination of the nature of roots of a quadratic
equation. Its input a triple of positive integers (say a,b,c) and value may be from
interval [0,100].
The program is given in fig. 19. The output may have one of the following words:
[Not a quadratic equation; real roots; Imaginary roots; Equal roots]
Draw the flow graph and DD path graph. Also find independent paths from the DD
Path graph.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 118
Softwar Testin
e g

Cont….
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 119
Softwar Testin
e g

Fig. 19: Code of quadratic equation problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 120
Softwar Testin
Solution e g

Fig. 19 (a) : Program flow

graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 121
Softwar Testin
e g

Fig. 19 (b) : DD Path graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 122
Softwar Testin
e g
The mapping table for DD path graph is:
Flow graph DD Path graph Remarks
nodes corresponding
node
1 to 10 A Sequential nodes
11 B Decision node
12 C Intermediate node
13 D Decision node
14,15 E Sequential node
16 F Two edges are combined here
17 G Two edges are combined and decision node
18 H Intermediate node
19 I Decision node
20,21 J Sequential node
22 K Decision node
23,24,25 L Sequential node

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
Cont…. 123
Softwar Testin
e g
Flow graph DD Path graph Remarks
nodes corresponding
node
26,27,28,29 M Sequential nodes
30 N Three edges are combined
31 O Decision node
32,33 P Sequential node
34,35,36 Q Sequential node
37 R Three edges are combined here
38,39 S Sequential nodes with exit node

Independent paths are:

(i) ABGOQRS (ii) ABGOPRS
(iii) ABCDFGOQRS (iv) ABCDEFGOPRS
(v) ABGHIJNRS (vi) ABGHIKLNRS
(vi) ABGHIKMNRS
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 124
Software
Testing
Example 8.14
Consider a program given in Fig.8.20 for the classification of a triangle. Its input is a
triple of positive integers (say a,b,c) from the interval [1,100]. The output may be
[Scalene, Isosceles, Equilateral, Not a triangle].
Draw the flow graph & DD Path graph. Also find the independent paths from the DD
Path graph.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 125
Softwar Testin
e g

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 126
Softwar Testin
e g

Fig. 20 : Code of triangle classification problem

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 127
Softwar Testin
Solution :
e g
Flow graph of
triangle problem is:

Fig.8. 20 (a): Program flow graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 128
Softwar Testin
e
The mapping table for DD path graph is:
g
Flow graph DD Path graph Remarks
nodes corresponding
node

1 TO 9 A Sequential nodes
B Decision node
10
11 C Decision node

12, 13 D Sequential nodes

14 E Two edges are joined here

15, 16, 17 F Sequential nodes

18 G Decision nodes plus joining of two edges
H Decision node
19
Sequential nodes
20, 21 I
22 J Decision node

23, 24 K Sequential nodes

Sequential nodes
25, 26, 27 L

Cont….
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 129
Softwar Testin
e g
Flow graph DD Path graph Remarks
nodes corresponding
node
28 M Three edges are combined here
29 N Decision node
30, 31 O Sequential nodes
32, 33, 34 P Sequential nodes
35 Q Three edges are combined here
36, 37 R Sequential nodes with exit node

Fig. 20 (b): DD Path graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 130
Softwar Testin
e g
DD Path graph is given in Fig. 20 (b)

Independent paths are:

(i) ABFGNPQR
(ii) ABFGNOQR
(iii) ABCEGNPQR
(iv) ABCDEGNOQR
(v) ABFGHIMQR
(vi) ABFGHJKMQR
(vii)ABFGHJMQR

Fig. 20 (b): DD Path graph

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

McCabe’s cyclomatic metric V(G) = e – n + 2P.

For example, a flow graph shown in in Fig. 21 with entry node ‘a’ and exit node ‘f’.

Fig. 21: Flow graph

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 132
Software
Testing
The value of cyclomatic complexity can be calculated as :
V(G) = 9 – 6 + 2 = 5
Here e = 9, n = 6 and P =1

There will be five independent paths for the flow graph illustrated in Fig. 21.
Path 1 : acf
Path 2 : abef
Path 3 : adcf
Path 4 : a b e a c f or a b e a b e f
Path 5 : abebef

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 133
Software
Testing
Several properties of cyclomatic complexity are stated below:

1. V(G) ≥1

2. V (G) is the maximum number of independent paths in graph G.

3. Inserting & deleting functional statements to G does not affect V(G).

4. G has only one path if and only if V(G)=1.

5. Inserting a new row in G increases V(G) by unity.

6. V(G) depends only on the decision structure of G.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 134
Software
Testing
The role of P in the complexity calculation V(G)=e-n+2P is required to be understood
correctly. We define a flow graph with unique entry and exit nodes, all nodes
reachable from the entry, and exit reachable from all nodes. This definition would
result in all flow graphs having only one connected component. One could, however,
imagine a main program M and two called subroutines A and B having a flow graph
shown in Fig. 22.

Fig. 22
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 135
Software
Testing
Let us denote the total graph above with 3 connected components as

V (M ∪ A ∪ B) e − n +
= 2P
= 13-13+2*3
=6

This method with P ≠ 1 can be used to calculate the complexity of a

collection of programs, particularly a hierarchical nest of subroutines.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 136
Software
Testing
Notice that V (M ∪ A ∪ B) = V (M ) + V ( A) + V (B) . In general, the
complexity of=a 6collection C of flow graphs with K connected components is
equal to the summation of their complexities. To see this let Ci,1 ≤ I ≤ K
denote the k distinct connected component, and let ei and ni be the number of edges
and nodes in the ith-connected component. Then

k k
V (C ) = e − n + 2 = ∑ ei −∑ ni +
p i =1 i =1 2K
k k
= ∑ (ei − ni + 2) = ∑ V
i =1
(Ci )
i =1

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 137
Software
Testing
Two alternate methods are available for the complexity calculations.

1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of

predicate (decision) nodes plus one.
V(G)= ∏ +1
Where ∏ is the number of predicate nodes contained in the flow graph
G.

2. Cyclomatic complexity is equal to the number of regions of the flow

graph.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 138
Softwar Testin
Example 8.15 e g
Consider a flow graph given in Fig. 23 and calculate the cyclomatic
complexity by all three methods.

Fig. 23

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 139
Software
Testing
Solution
Cyclomatic complexity can be calculated by any of the three methods.

1. V(G) = e – n + 2P
= 13 – 10 + 2 = 5

2. V(G) = π+ 1
=4+1=5

3. V(G) = number of regions

Therefore, complexity value of a flow graph in Fig. 23 is 5.

Consider the previous date program with DD path graph given in Fig. 17.
Find cyclomatic complexity.

Number of edges (e) = 65

Number of nodes (n) =49
(i) V(G) = e – n + 2P = 65 – 49 + 2 = 18
(ii) V(G) = π + 1 = 17 + 1 = 18
(iii) V(G) = Number of regions = 18

The cyclomatic complexity is 18.

Consider the quadratic equation problem given in example 8.13 with its DD
Path graph. Find the cyclomatic complexity:

Number of nodes (n) = 19

Number of edges (e) = 24
(i) V(G) = e – n + 2P = 24 – 19 + 2 = 7
(ii) V(G) = π + 1 = 6 + 1 = 7
(iii) V(G) = Number of regions = 7

Hence cyclomatic complexity is 7 meaning thereby, seven

independent paths in the DD Path graph.

Consider the classification of triangle problem given in example 8.14. Find

the cyclomatic complexity.

Number of edges (e) = 23

Number of nodes (n) =18
(i) V(G) = e – n + 2P = 23 – 18 + 2 = 7
(ii) V(G) = π + 1 = 6 + 1 = 7
(iii) V(G) = Number of regions = 7

The cyclomatic complexity is 7. Hence, there are seven independent paths

as given in example 8.14.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 146
Software
Testing
Graph Matrices
A graph matrix is a square matrix with one row and one column for every node in the
graph. The size of the matrix (i.e., the number of rows and columns) is equal to the
number of nodes in the flow graph. Some examples of graphs and associated
matrices are shown in fig. 24.

Fig. 24 (a): Flow graph and graph matrices

Fig. 24 (b): Flow graph and graph matrices

Fig. 24 (c): Flow graph and graph matrices

Fig. 25 : Connection matrix of flow graph shown in Fig. 24 (c)

The square matrix represent that there are two path ab and cd from node 1 to
node 2.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 151
Software
Example 8.19 Testing
Consider the flow graph shown in the Fig. 26 and draw the graph & connection
matrices. Find out cyclomatic complexity and two / three link paths from a node to
any other node.

Fig. 26 : Flow graph

To find two link paths, we have to generate a square of graph matrix [A] and for three
link paths, a cube of matrix [A] is required.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 154
Software
Testing
Data Flow Testing
Data flow testing is another from of structural testing. It has nothing to do with data
flow diagrams.

i. Statements where variables receive values.

ii. Statements where these values are used or referenced.

As we know, variables are defined and referenced throughout the program. We

may have few define/ reference anomalies:

i. A variable is defined but not used/ referenced.

ii. A variable is used but never defined.

iii. A variable is defined twice before it is used.

The definitions refer to a program P that has a program graph G(P) and a set of
program variables V. The G(P) has a single entry node and a single exit node. The
set of all paths in P is PATHS(P)

(i) Defining Node: Node n E G(P) is defining node of the variable V E

a V, statement
written as DEF (V, n), if the value of the variable V is defined the
at
fragment corresponding to node n.
(ii) Usage Node: Node n E G(P) is a usage node of the variable V E V, written
USE (V, n), if the value of the variable V is usedas at statement
fragment
corresponding to node n. A usage node USE (V, n) is a predicate use (denote
as p) if statement n is a predicate statement otherwise USE (V, n) is a
computation use (denoted as c).

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 156
Software
Testing
(iii) Definition use: A definition use path with respect to a variable v (denoted
du-path) is a path in PATHS(P) such that, for some V E V, there are define and
usage nodes DEF(v, m) and USE(v, n) such that m and n are initial and final
nodes of the path.

(iv) Definition clear : A definition clear path with respect to a variable v (denoted
dc-path) is a definition use path in PATHS(P) with initial and final nodes DEF
(V, m) and USE (V, n), such that no other node in the path is a defining node of
V.
The du-paths and dc-paths describe the flow of data across source statements from
points at which the values are defined to points at which the values are used. The
du-paths that are not definition clear are potential trouble spots.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 157
Software
Testing
Hence, our objective is to find all du-paths and then identity those du-paths which are
not dc-paths. The steps are given in Fig. 27. We may like to generate specific test
cases for du-paths that are not dc-paths.

Fig. 27 : Steps for data flow testing

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 158
Software
Example 8.20
Testing
Consider the program of 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 for each of
these may be from interval [0,100]. The program is given in Fig. 19. The output may
have one of the option given below:
(i) Not a quadratic program
(ii) real roots
(iii) imaginary roots
(iv) equal roots
(v) invalid inputs
Find all du-paths and identify those du-paths that are definition clear.

Step I: The program flow graph is given in Fig. 19 (a). The variables used in the
program are a,b,c,d, validinput, D.
Step II: DD Path graph is given in Fig. 19(b). The cyclomatic complexity of this graph
is 7 indicating there are seven independent paths.

Step III: Define/use nodes for all variables are given below:

Variable Defined at node Used at node

a 6
11,13,18,20,24,27,28
b 8 11,18,20,24,28

c 10 11,18

d 18 19,22,23,27
D 23, 27 24,28
Validinput 3, 12, 14 17,31

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 160
Software
Testing
Step IV: The du-paths are identified and are named by their beginning and ending
nodes using Fig. 19 (a).
Variable Path (beginning, end) nodes Definition clear ?
6, 11 Yes
a
6, 13 Yes
6, 18 Yes
6, 20 Yes
6, 24 Yes
6, 27 Yes
6, 28 Yes
8, 11 Yes
b 8, 18 Yes
8, 20 Yes
8, 24 Yes
8, 28 Yes

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 161
Softwar Testin
e g
Variable Path (beginning, end) nodes Definition clear ?
10, 11 Yes
c
10, 18 Yes
d 18, 19 Yes
18, 22 Yes
18, 23 Yes
18, 27 Yes
D 23, 24 Yes
23, 28 Path not possible
27, 24 Path not possible
27, 28 Yes
3, 17 no
validinput
3, 31 no
12, 17 no
12, 31 no
14, 17 yes
14, 31 yes
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 162
Software
Testing
Example 8.21

Consider the program given in Fig. 20 for the classification of a triangle. Its
input is a triple of positive integers (say a,b,c) from the interval [1,100]. The
output may be:
[Scalene, Isosceles, Equilateral, Not a triangle, Invalid inputs].
Find all du-paths and identify those du-paths that are definition clear.

Step I: The program flow graph is given in Fig. 20 (a). The variables used in
the program are a,b,c, valid input.

Step II: DD Path graph is given in Fig. 20(b). The cyclomatic complexity of
this graph is 7 and thus, there are 7 independent paths.
Step III: Define/use nodes for all variables are given below:

Variable Defined at node Used at node

a 6 10, 11, 19, 22
b 7 10, 11, 19, 22

c 9 10, 11, 19, 22

valid input 3, 13, 16 18, 29

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 164
Software
Testing
Step IV: The du-paths are identified and are named by their beginning and ending
nodes using Fig. 20 (a).

Variable Path (beginning, end) nodes Definition clear ?

5, 10 Yes
a
5, 11 Yes
5, 19 Yes
5, 22 Yes

7, 10 Yes
b 7, 11 Yes
7, 19 Yes
7, 22 Yes

9, 10 Yes
c
9, 11 Yes
9, 19 Yes
9, 22 Yes

3, 18 no
valid input
3, 29 no
12, 18 no
12, 29 no
16, 18 Yes
16, 29 Yes

Hence total du-paths are 18 out of which four paths are not definition clear

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 166
Software
Testing
Mutation Testing
Mutation testing is a fault based technique that is similar to fault seeding, except that
mutations to program statements are made in order to determine properties about
test cases. it is basically a fault simulation technique.

Multiple copies of a program are made, and each copy is altered; this altered copy is
called a mutant. Mutants are executed with test data to determine whether the test
data are capable of detecting the change between the original program and the
mutated program.

A mutant that is detected by a test case is termed “killed” and the goal of mutation
procedure is to find a set of test cases that are able to kill groups of mutant
programs.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 167
Software
Testing
When we mutate code there needs to be a way of measuring the degree to which the
code has been modified. For example, if the original expression is x+1 and the
mutant for that expression is x+2, that is a lesser change to the original code than a
mutant such as (c*22), where both the operand and the operator are changed. We
may have a ranking scheme, where a first order mutant is a single change to an
expression, a second order mutant is a mutation to a first order mutant, and so on.
High order mutants becomes intractable and thus in practice only low order mutants
are used.

One difficulty associated with whether mutants will be killed is the problem of
reaching the location; if a mutant is not executed, it cannot be killed. Special test
cases are to be designed to reach a mutant. For example, suppose, we have the
code.
Read (a,b,c);
If(a>b) and (b=c) then
x:=a*b*c; (make mutants; m1, m2, m3 …….)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 168
Software
Testing
To execute this, input domain must contain a value such that a is greater than b and
b equals c. If input domain does not contain such a value, then all mutants made at
this location should be considered equivalent to the original program, because the
statement x:=a*b*c is dead code (code that cannot be reached during execution). If
we make the mutant x+y for x+1, then we should take care about the value of y
which should not be equal to 1 for designing a test case.

The manner by which a test suite is evaluated (scored) via mutation testing is as
follows: for a specified test suite and a specific set of mutants, there will be three
types of mutants in the code i.e., killed or dead, live, equivalent. The sum of the
number of live, killed, and equivalent mutants will be the total number of mutants
created. The score associated with a test suite T and mutants M is simply.

# killed
# total −#
×100%
equivalent

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 169
Softwar Testin
Levels of Testing e g
There are 3 levels of testing:
i. Unit Testing
ii. Integration Testing
iii. System Testing

There are number of reasons in support of unit testing than testing the entire product.

1. The size of a single module is small enough that we can locate an error
fairly easily.

2. The module is small enough that we can attempt to test it in some

demonstrably exhaustive fashion.

3. Confusing interactions of multiple errors in widely different parts of the

software are eliminated.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 171
Software
Testing
There are problems associated with testing a module in isolation. How do we run a
module without anything to call it, to be called by it or, possibly, to output
intermediate values obtained during execution? One approach is to construct an
appropriate driver routine to call if and, simple stubs to be called by it, and to insert
output statements in it.

Stubs serve to replace modules that are subordinate to (called by) the module to be
tested. A stub or dummy subprogram uses the subordinate module’s interface, may
do minimal data manipulation, prints verification of entry, and returns.

This overhead code, called scaffolding represents effort that is import to testing, but
does not appear in the delivered product as shown in Fig. 29.

Fig. 29 : Scaffolding required testing a program unit (module)

The purpose of unit testing is to determine that each independent module is

correctly implemented. This gives little chance to determine that the interface
between modules is also correct, and for this reason integration testing must be
performed. One specific target of integration testing is the interface: whether
parameters match on both sides as to type, permissible ranges, meaning and
utilization.

Fig. 30 : Three different integration approaches

Of the three levels of testing, the system level is closet to everyday experiences.
We test many things; a used car before we buy it, an on-line cable network
service before we subscribe, and so on. A common pattern in these familiar
forms is that we evaluate a product in terms of our expectations; not with
respect to a specification or a standard. Consequently, goal is not to find faults,
but to demonstrate performance. Because of this we tend to approach system
testing from a functional standpoint rather than from a structural one. Since it is
so intuitively familiar, system testing in practice tends to be less formal than it
might be, and is compounded by the reduced testing interval that usually
remains before a delivery deadline.

Petschenik gives some guidelines for choosing test cases during system testing.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 176
Software
Testing
During system testing, we should evaluate a number of attributes of the
software that are vital to the user and are listed in Fig. 31. These represent the
operational correctness of the product and may be part of the software
specifications.

Usable Is the product convenient, clear, and predictable?

Secure Is access to sensitive data restricted to those with authorization?

Will the product work correctly in conjunction with existing data,

Compatible
software, and procedures?

Do adequate safeguards against failure and methods for recovery

Dependable
exist in the product?

Documented Are manuals complete, correct, and understandable?

Fig. 31 : Attributes of software to be tested during system testing

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 177
Software
Testing
Validation Testing
o It refers to test the software as a complete product.
o This should be done after unit & integration testing.
o Alpha, beta & acceptance testing are nothing but the various ways of involving
customer during testing.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 178
Software
Testing
Validation Testing
o IEEE has developed a standard (IEEE standard 1059-1993) entitled “ IEEE guide
for software verification and validation “ to provide specific guidance about
planning and documenting the tasks required by the standard so that the
customer may write an effective plan.
o Validation testing improves the quality of software product in terms of functional
capabilities and quality attributes.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 179
Software
Testing
The Art of Debugging
The goal of testing is to identify errors (bugs) in the program. The process of
testing generates symptoms, and a program’s failure is a clear symptom of the
presence of an error. After getting a symptom, we begin to investigate the cause
and place of that error. After identification of place, we examine that portion to
identify the cause of the problem. This process is called debugging.

Debugging Techniques
Pressman explained few characteristics of bugs that provide some clues.

1. “The symptom and the cause may be geographically remote. That is, the
symptom may appear in one part of a program, while the cause may actually be
located in other part. Highly coupled program structures may complicate this
situation.

2. The symptom may disappear (temporarily) when another error is corrected.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 180
Software
Testing
3. The symptom may actually be caused by non errors (e.g. round off inaccuracies).

4. The symptom may be caused by a human error that is not easily traced.

5. The symptom may be a result of timing problems rather than processing

problems.

6. It may be difficult to accurately reproduce input conditions (e.g. a real time

application in which input ordering is indeterminate).

7. The symptom may be intermittent. This is particularly common in embedded

system that couple hardware with software inextricably.

8. The symptom may be due to causes that are distributed across a number of tasks
running on different processors”.

) Locate the pertinent data

) Organize the data

) Devise a hypothesis

) Prove the hypothesis

Fig. 32 : The inductive debugging process

) Enumerate the possible causes or hypotheses

) Use the data to eliminate possible causes

) Refine the remaining hypothesis

) Prove the remaining hypothesis

Fig. 33 : The inductive debugging process

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 185
Software
Testing
Testing Tools
One way to improve the quality & quantity of testing is to make the process as
pleasant as possible for the tester. This means that tools should be as concise,
powerful & natural as possible.

The two broad categories of software testing tools are :

) Static

) Dynamic

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 186
Software
Testing
There are different types of tools available and some are listed below:

1. Static analyzers, which examine programs systematically and automatically.

2. Code inspectors, who inspect programs automatically to make sure they adhere
to minimum quality standards.

3. standards enforcers, which impose simple rules on the developer.

4. Coverage analysers, which measure the extent of coverage.

5. Output comparators, used to determine whether the output in a program is

appropriate or not.

7. Test harnesses, used to simplify test operations.

8. Test archiving systems, used to provide documentation about programs.

ccs352 Multimedia and Animation
100% (2)
ccs352 Multimedia and Animation
4 pages
ST Module 1
No ratings yet
ST Module 1
40 pages
unit 4-testing
No ratings yet
unit 4-testing
82 pages
SWE2-Testing-Aggarwal-2_1_UP=75_d649864ef3342f4dc73899d001b0245c
No ratings yet
SWE2-Testing-Aggarwal-2_1_UP=75_d649864ef3342f4dc73899d001b0245c
75 pages
4sem BCA SA&SE Unit5 notes
No ratings yet
4sem BCA SA&SE Unit5 notes
32 pages
Unit 4.1
No ratings yet
Unit 4.1
57 pages
UNIT-4 Software Testing and Maintenance
No ratings yet
UNIT-4 Software Testing and Maintenance
58 pages
Module 5
No ratings yet
Module 5
32 pages
Testing - Blackbox
No ratings yet
Testing - Blackbox
75 pages
Software Testing
No ratings yet
Software Testing
8 pages
Software Testing and Quality Assurance Notes
No ratings yet
Software Testing and Quality Assurance Notes
23 pages
Unit-4-Software-Testing
No ratings yet
Unit-4-Software-Testing
211 pages
Week 8 - Software Testing
No ratings yet
Week 8 - Software Testing
148 pages
Software Testing
No ratings yet
Software Testing
212 pages
Chapter 8 Software Testing
No ratings yet
Chapter 8 Software Testing
212 pages
K K Aggarwal YogeshSingh Full Notes 808 898
No ratings yet
K K Aggarwal YogeshSingh Full Notes 808 898
91 pages
Bcse301l Se Module-5a Smsatapathy
No ratings yet
Bcse301l Se Module-5a Smsatapathy
217 pages
Unit I Introduction SW Testing
No ratings yet
Unit I Introduction SW Testing
54 pages
Software Testing
No ratings yet
Software Testing
24 pages
Chapter 8 Software Testing
No ratings yet
Chapter 8 Software Testing
183 pages
Chapter 8 Software Testing Revised
No ratings yet
Chapter 8 Software Testing Revised
126 pages
STQM 1
No ratings yet
STQM 1
83 pages
sv_testing lntroduction
No ratings yet
sv_testing lntroduction
79 pages
Software Testing NE
No ratings yet
Software Testing NE
38 pages
Testing 1
100% (1)
Testing 1
100 pages
Unit-1 STQA
No ratings yet
Unit-1 STQA
127 pages
Lect-3B-Software Testing -Detailed
No ratings yet
Lect-3B-Software Testing -Detailed
135 pages
Module 1_ Testing Methodology
No ratings yet
Module 1_ Testing Methodology
77 pages
Chapter 8 Software Testing-1
No ratings yet
Chapter 8 Software Testing-1
212 pages
CS504Testing
No ratings yet
CS504Testing
24 pages
Unit 5
No ratings yet
Unit 5
18 pages
ccs 366 STA Unit 1
No ratings yet
ccs 366 STA Unit 1
31 pages
05_chapter 1 (1)
No ratings yet
05_chapter 1 (1)
39 pages
Software Testing
No ratings yet
Software Testing
2 pages
Module 5 .1
No ratings yet
Module 5 .1
96 pages
Unit-4
No ratings yet
Unit-4
22 pages
UNIT6
No ratings yet
UNIT6
66 pages
Auto Test
No ratings yet
Auto Test
80 pages
1 Introduction
No ratings yet
1 Introduction
55 pages
Black Box Testing
No ratings yet
Black Box Testing
24 pages
Chapter 1 - Software Testing (Lecture 1 & 2)
No ratings yet
Chapter 1 - Software Testing (Lecture 1 & 2)
68 pages
chapter 5 of software engineering
No ratings yet
chapter 5 of software engineering
17 pages
Software Testing U-1 P 1
No ratings yet
Software Testing U-1 P 1
27 pages
4.2 SoftEngg Unit-IV Coding and Software Testing
No ratings yet
4.2 SoftEngg Unit-IV Coding and Software Testing
72 pages
Unit 1_testing (Autosaved)
No ratings yet
Unit 1_testing (Autosaved)
27 pages
Lecture - 3 - Basics of Software Testing
No ratings yet
Lecture - 3 - Basics of Software Testing
31 pages
17 Software Testing - introduction 2024
No ratings yet
17 Software Testing - introduction 2024
94 pages
SE Unit 4
No ratings yet
SE Unit 4
40 pages
Software Testing
No ratings yet
Software Testing
51 pages
17ISE41ST-UNIT1
No ratings yet
17ISE41ST-UNIT1
176 pages
272: Software Engineering Fall 2012: Instructor: Tevfik Bultan
No ratings yet
272: Software Engineering Fall 2012: Instructor: Tevfik Bultan
55 pages
unit 1
No ratings yet
unit 1
23 pages
Testing
No ratings yet
Testing
50 pages
Testing-Types
No ratings yet
Testing-Types
19 pages
Se 8
No ratings yet
Se 8
25 pages
Resource 20240124101021 System Testing Ch1
No ratings yet
Resource 20240124101021 System Testing Ch1
32 pages
13-Software Testing
No ratings yet
13-Software Testing
20 pages
6th Software Testing
No ratings yet
6th Software Testing
81 pages
Systems Engineering Guide Book for ITS
No ratings yet
Systems Engineering Guide Book for ITS
313 pages
Manual Book 2
No ratings yet
Manual Book 2
70 pages
BOUGAA 2017 Archivage
No ratings yet
BOUGAA 2017 Archivage
213 pages
Unit 2
No ratings yet
Unit 2
16 pages
Manual Book
No ratings yet
Manual Book
78 pages
Ms Word Practical Assignment PDF
No ratings yet
Ms Word Practical Assignment PDF
52 pages
10th Maths EM Unit Wise Question Paper English Medium PDF Download
No ratings yet
10th Maths EM Unit Wise Question Paper English Medium PDF Download
20 pages
COG - CEN - Guidelines
No ratings yet
COG - CEN - Guidelines
4 pages
Hor Template
No ratings yet
Hor Template
1,678 pages
HOR Instruction
No ratings yet
HOR Instruction
10 pages
HOR - Sample Output - Hishult - Aii6 - 337783-0
No ratings yet
HOR - Sample Output - Hishult - Aii6 - 337783-0
8 pages
CS3492 Syllabus
No ratings yet
CS3492 Syllabus
2 pages
Systems Development Life Cycle Phases
No ratings yet
Systems Development Life Cycle Phases
13 pages