PAN African e-Network Project

PGDIT
Software Engineering
Semester - 1
Session - 6

Abhishek
Singhal

Topics to be Covered

Coding
Testing Process
Some Terminology
Functional Testing
Structural Testing,

Coding
Goal is to implement the design in best possible
manner
Coding affects testing and maintenance
As testing and maintenance costs are high, aim
of coding activity should be to write code that
reduces them
Hence, goal should not be to reduce coding
cost, but testing and maintenance cost, i.e.
make the job of tester and maintainer easier

Coding
Code is read a lot more
Coders themselves read the code many times for
debugging, extending etc
Maintainers spend a lot of effort reading and
understanding code
Other developers read code when they add to existing
code

Hence, code should be written so it is easy to

understand and read, not easy to write!

Coding
Having clear goal for coding will help achieve
them
Weinberg experiment showed that coders
achieve the goal they set
Diff coders were given the same problem
But different objectives were given to diff
programmers minimize effort, min size, min
memory, maximize clarity, max output clarity
Final programs for diff programmers generally
satisfied the criteria given to them

Weinberg Experiment..

Minimize Effort (o1)

Minimize prog size (o2)
Minimize memory (o3)
Maximize code clarity (o4)
Maximize output clarity (o5)

Resulting Rank (1=best)

O1
o2
o3
o4

o5

1
2-3
5
4
2-3

3
5
4
2
1

4
1
2
3
5

4
2
1
3
5

5
3
4
2
1

Programming Principles
The main goal of the programmer is write simple
and easy to read programs with few bugs in it
Of course, the programmer has to develop it
quickly to keep productivity high
There are various programming principles that
can help write code that is easier to understand
(and test)

Structured Programming
Structured programming started in the
70s, primarily against indiscriminate use of
control constructs like gotos
Goal was to simplify program structure so
it is easier to argue about programs
Is now well established and followed

Structured Programming
A program has a static structure which is the
ordering of statements in the code and this is a
linear ordering
A program also has dynamic structure order in
which statements are executed
Both dynamic and static structures are ordering
of statements
Correctness of a program must talk about the
dynamic structure

Structured Programming
To show a program as correct, we must show that its
dynamic behavior is as expected
But we must argue about this from the code of the
program, i.e. the static structure
I.e program behavior arguments are made on the static
code
This will become easier if the dynamic and static
structures are similar
Closer correspondence will make it easier to understand
dynamic behavior from static structure
This is the idea behind structured programming

Structured Programming
Goal of structured programming is to write
programs whose dynamic structure is
same as static
I.e. statements are executed in the same
order in which they are present in code
As statements organized linearly, the
objective is to develop programs whose
control flow is linear

Structured Programming
Meaningful programs cannot be written as
sequence of simple statements
To achieve the objectives, structured constructs
are to be used
These are single-entry-single-exit constructs
With these, execution of the statements can be
in the order they appear in code
The dynamic and static order becomes same

Structured Programming
Main goal was to ease formal verification of
programs
For verification, the basic theorem to be shown
for
a
program
S
is
of
the
form
P {S} Q
P precondition that holds before S executes
Q post condition that holds after S has
executed and terminated

Structured Programming-Composing
Proofs
If a program is a sequence of the type S1; S2
then it is easier to prove from proofs of S1 and
S2
Suppose we have shown P1 {S1} Q1 and R2
{S2} Q2
Then, if we can show Q1 => R2, then we can
conclude P1 {S1; S2} Q2
So Structured Prog allows composing proofs of
larger programs from proofs of its parts

Structured Programming
Each structured construct should also have a
clear behavior
Then we can compose behavior of statements to
understand behavior of programs
Hence,
arbitrary
single-entry-single-exit
constructs will not help
It can be shown that a few constructs like while,
if, and sequencing suffice for writing any type of
program

Structured Programming
SP was promulgated to help formal verification
of programs
Without linear flow, composition is hard and
verification difficult
But, SP also helps simplify the control flow of
programs, making them easier to understand
and argue about
SP is an accepted and standard practice today
modern languages support it well

Information Hiding
Software solutions always contain data
structures that hold information
Programs work on these DS to perform the
functions they want
In general only some operations are performed
on the information, i.e. the data is manipulated in
a few ways only
E.g. on a banks ledger, only debit, credit, check
cur balance etc are done

Information Hiding
Information hiding the information should be
hidden; only operations on it should be exposed
I.e. data structures are hidden behind the access
functions, which can be used by programs
Info hiding reduces coupling
This practice is a key foundation of OO and
components, and is also widely used today

Some Programming Practices

Control constructs: Use only a few
structured constructs (rather than using a
large no of constructs)
Goto: Use them sparingly, and only when
the alternatives are worse
Info hiding: Use info hiding
Use-defined types: use these to make the
programs easier to read

Some Programming Practices

Nesting: Avoid heavy nesting of if-thenelse; if disjoint nesting can be avoided
Module size: Should not be too large
generally means low cohesion
Module interface: make it simple
Robustness: Handle exceptional situations
Side effects: Avoid them, document

Some Programming Practices

Empty catch block: always have some default
action rather than empty
Empty if, while: bad practice
Read return: should be checked for robustness
Return from finally: should not return from finally
Correlated parameters: Should check for
compatibility

Coding Standards
Programmers spend more time reading code than writing
code
They read their own code as well as other programmers
code
Readability is enhanced if some coding conventions are
followed by all
Coding standards provide these guidelines for
programmers
Generally are regarding naming, file organization,
statements/declarations,
Some Java conventions discussed here

Coding Standards
Naming conventions
Package name should be in lower case (mypackage,
edu.iitk.maths)
Type names should be nouns and start with
uppercase (Day, DateOfBirth,)
Var names should be nouns in lowercase; vars with
large scope should have long names; loop iterators
should be i, j, k
Const names should be all caps
Method names should be verbs starting with lower
case (eg getValue())
Prefix is should be used for boolean methods

Coding Standards
Files
Source files should have .java extension
Each file should contain one outer class and
the name should be same as file
Line length should be less than 80; if longer
continue on another line

Coding Standards
Statements
Vars should be initialized where declared in the
smallest possible scope
Declare related vars together; unrelated vars should
be declared separately
Class vars should never be declared public
Loop vars should be initialized just before the loop
Avoid using break and continue in loops
Avoid executable statements in conditionals
Avoid using the do while construct

Coding Standards
Commenting and layout
Single line comments for a block should be
aligned with the code block
There should be comments for all major vars
explaining what they represent
A comment block should start with a line with
just /* and end with a line with */
Trailing comments after statements should be
short and on the same line

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.

Software Testing
A more appropriate definition is:

Testing is the process of executing a program with

the intent of finding errors.

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.

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 organizations have made a distinction between development
and testing phase by making different people responsible for each
phase.

Testing Objectives
Testing is a process of executing a
program with the intent of finding an
error.
A good test case is one that has a
high probability of finding an as yet
undiscovered error.
A successful test is one that
uncovers an as-yet undiscovered error

Testing Principles
All tests should be traceable to customer requirements.
(from customers point of view)
Tests should be planned long before testing begins.
(Begins as soon as the requirements model is complete)

The pareto principle applies to software testing.

( implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components)

Contd..

Testing should begin in the small and progress

toward testing in the large.

(from individual components and ultimately in

the entire system)
Exhaustive testing in not possible.

(It is not possible to exhaustively test

every program path because the number of paths is
simple too large)
To be most effective , testing should be conducted

by an independent third party.

(Most effective means highest

probability of finding errors)

Software Testability
Characteristics
Operability
The better it works, the more efficiently it can be tested

Observability
What you see is what you test

Controllability
The better we can control the software, the more the testing can be
automated and optimized

Decomposability
By controlling the scope of testing, we can more quickly isolate problems
and perform smarter retesting
Cont

 Simplicity ( Functional, Structural & Code simplicity)

The less there is to test, the more quickly we can test it

Stability
The fewer the changes , the fewer the disruptions to testing

Understabiltiy
The more information we have, the smarter we will test

Attributes of a Good Test

A good test has a high probability of finding an error.
A good test is not redundant.
A good test should be best of breed [KAN93].
A good test should be neither too simple nor too complex.

Testing Fundamentals
Verification
Verification refers to the set of activities that ensure that software
correctly implements a specific functions. Acc. To Boehm [Boe81]
Are we building the product right
Validation
Validation refers to a different set of activities that ensures that the
software that has been built is traceable to customer requirements.
Acc. To Boehm [Boe81]
Are we building the right product
Cont..

Software Testing
Some Terminologies
Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a syntax
error or misunderstanding of specifications. Sometimes, there are logical
errors.
When developers make mistakes while coding, we call these mistakes
bugs.
A fault is the representation of an error, where representation is the mode
of expression, such as narrative text, data flow diagrams, ER diagrams,
source code etc. Defect is a good synonym for fault.
A failure occurs when a fault executes. A particular fault may cause
different failures, depending on how it has been exercised.

Software 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
(Before Execution)
Purpose :
Pre condition: (If any)
Inputs:

Section-II
(After Execution)
Execution History:
Result:
If fails, any possible reason (Optional);

Expected Outputs:
Post conditions:
Written by:
Date:

Any other observation:

Any suggestion:
Run by:
Date:

Fig.: Test case template

The set of test cases is called a test suite. Hence any combination of test
cases may generate a test suite.

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

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

Software Testing
Functional Testing
Input
domain
Input test
data

Output
domain
System
under
test

Figure: Black box testing

Output
test data

Software Testing
Boundary Value Analysis
Consider a program with two input variables x and y. These input variables
have specified boundaries as:
axb
cyd

Input domain

d
y
c
a

Figure: Input domain for program having two input variables

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 Figure. Each dot represent
a test case and inner rectangle is the domain of legitimate inputs. Thus, for a
program of n variables, boundary value analysis yield 4n + 1 test cases.

Input domain

400
300
y 200
100
0

100

200
x

300

400

Figure: Input domain of two variables x and y with

boundaries [100,300] each

Example

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.

Example taken from [1]

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

The Boundary Value Test Cases are :

Test Case

Expected output

50

50

Not Quadratic

50

50

Real Roots

50

50

50

Imaginary Roots

99

50

50

Imaginary Roots

100

50

50

Imaginary Roots

50

50

Imaginary Roots

50

50

Imaginary Roots

50

99

50

Imaginary Roots

50

100

50

Equal Roots

10

50

50

Real Roots

11

50

50

Real Roots

12

50

50

99

Imaginary Roots

13

50

50

100

Imaginary Roots

Example

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

Example taken from [1]

Solution

The Previous date program takes a date as input and checks it for validity.
If valid, it returns the previous date as its output.
With single fault assumption theory, 4n+1 test cases can be designed and
which are equal to 13.

The boundary value test cases are:

Test Case

Month

Day

Year

Expected output

15

1900

14 June, 1900

15

1901

14 June, 1901

15

1962

14 June, 1962

15

2024

14 June, 2024

15

2025

14 June, 2025

1962

31 May, 1962

1962

1 June, 1962

30

1962

29 June, 1962

31

1962

Invalid date

10

15

1962

14 January, 1962

11

15

1962

14 February, 1962

12

11

15

1962

14 November, 1962

13

12

15

1962

14 December, 1962

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 Figure in the next slide.
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)

Robustness testing
400
300
y 200
100
0

100

200
x

300

400

Figure: Robustness test cases for two variables x

and y with range [100,300] each

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.

Table 1: Worst cases test inputs for two

variables example
Test case
number

Inputs
x

100

100

100

Test case
number

Inputs
x

14

200

299

101

15

200

300

100

200

16

299

100

100

299

17

299

101

100

300

18

299

200

6
7

101
101

100
101

19
20

299
299

299
300

101

200

21

300

100

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

--

Example

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

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

Example taken from [1]

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:

Solution
Test case

Expected Output

-1

50

50

Invalid input`

50

50

Not quadratic equation

50

50

Real roots

50

50

50

Imaginary roots

99

50

50

Imaginary roots

100

50

50

Imaginary roots

101

50

50

Invalid input

50

-1

50

Invalid input

50

50

Imaginary roots

10

50

50

Imaginary roots

11

50

99

50

Imaginary roots

12

50

100

50

Equal roots

13

50

101

50

14

50

50

-1

Invalid input
Invalid input

15

50

50

Real roots

16

50

50

Real roots

17

50

50

99

Imaginary roots

18

50

50

100

Imaginary roots

19

50

50

101

Invalid input

Solution (Contd..)
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

Expected output

Not Quadratic

Not Quadratic

50

Not Quadratic

99

Not Quadratic

100

Not Quadratic

Not Quadratic

Not Quadratic

50

Not Quadratic

99

Not Quadratic

10

100

Not Quadratic

11

50

Not Quadratic

12

50

Not Quadratic

13

50

50

Not Quadratic

14

50

99

Not Quadratic

Solution (Contd..)
Test Case

Expected output

15

50

100

Not Quadratic

16

99

Not Quadratic

17

99

Not Quadratic

18

99

50

Not Quadratic

19

99

99

Not Quadratic

20

99

100

Not Quadratic

21

100

Not Quadratic

22

100

Not Quadratic

23

100

50

Not Quadratic

24

100

99

Not Quadratic

25
26

0
1

100
0

100
0

Not Quadratic
Equal Roots

27

Imaginary

28

50

Imaginary

29

99

Imaginary

30

100

Imaginary

31

Real Roots

Solution (Contd..)
Test Case

Expected output

32

Imaginary

33

50

Imaginary

34

99

Imaginary

35

100

Imaginary

36

50

Real Roots

37

50

Real Roots

38

50

50

Real Roots

39

50

99

Real Roots

40

50

100

Real Roots

41

99

Real Roots

42

99

Real Roots

43

99

50

Real Roots

44`

99

99

Real Roots

45

99

100

Real Roots

46

100

Real Roots

47

100

Real Roots

48

100

50

Real Roots

Solution (Contd..)
Test Case

Expected output

49

100

99

Real Roots

50

100

100

Real Roots

51

50

Equal Roots

52

50

Imaginary

53

50

50

Imaginary

54

50

99

Imaginary

55

50

100

Imaginary

56

50

Real Roots

57

50

Imaginary

58

50

50

Imaginary

59

50

99

Imaginary

60

50

100

Imaginary

61

50

50

Real Roots

62

50

50

Real Roots

63

50

50

50

Imaginary

64

50

50

99

Imaginary

65

50

50

100

Imaginary

Solution (Contd..)
Test Case

Expected output

66

50

99

Real Roots

67

50

99

Real Roots

68

50

99

50

Imaginary

69

50

99

99

Imaginary

70

50

99

100

Imaginary

71

50

100

Real Roots

72

50

100

Real Roots

73

50

100

50

Equal Roots

74

50

100

99

Imaginary

75

50

100

100

Imaginary

76

99

Equal Roots

77

99

Imaginary

78

99

50

Imaginary

79

99

99

Imaginary

80

99

100

Imaginary

81

99

Real Roots

82

99

Imaginary

Solution (Contd..)
Test Case

Expected output

83

99

50

Imaginary

84

99

99

Imaginary

85

99

100

Imaginary

86

99

50

Real Roots

87

99

50

Real Roots

88

99

50

50

Imaginary

89

99

50

99

Imaginary

90

99

50

100

Imaginary

91

99

99

Real Roots

92

99

99

Real Roots

93

99

99

50

Imaginary Roots

94

99

99

99

Imaginary

95

99

99

100

Imaginary

96

99

100

Real Roots

97

99

100

Real Roots

98

99

100

50

Imaginary

99

99

100

99

Imaginary

100

99

100

100

Imaginary

Solution (Contd..)
Test Case

Expected output

101

100

Equal Roots

102

100

Imaginary

103

100

50

Imaginary

104

100

99

Imaginary

105

100

100

Imaginary

106

100

Real Roots

107
108

100
100

1
1

1
50

Imaginary
Imaginary

109

100

99

Imaginary

110

100

100

Imaginary

111

100

50

Real Roots

112

100

50

Real Roots

113

100

50

50

Imaginary

114

100

50

99

Imaginary

115

100

50

100

Imaginary

116

100

99

Real Roots

117

100

99

Real Roots

118

100

99

50

Imaginary

Solution (Contd..)
Test Case

Expected output

119

100

99

99

Imaginary

120

100

99

100

Imaginary

121

100

100

Real Roots

122

100

100

Real Roots

123

100

100

50

Imaginary

124

100

100

99

Imaginary

125

100

100

100

Imaginary

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.

Equivalence Class Testing

Invalid input
System
under test

Valid
inputs

Input domain

Outputs

Output domain

Figure: 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.

Example

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

equation as explained in the first example. Identify the equivalence class
test cases for output and input domains.

Example taken from [1]

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

Expected output

50

50

Not a quadratic equation

50

50

Real roots

50

50

50

Imaginary roots

50

100

50

Equal roots

Solution (Contd..)
We may have another set of test cases based on input domain.
I1= {a: a = 0}
I2= {a: a < 0}
I3= {a: 1 a 100}
I4= {a: a > 100}
I5= {b: 0 b 100}
I6= {b: b < 0}
I7= {b: b > 100}
I8= {c: 0 c 100}
I9= {c: c < 0}
I10={c: c > 100}

Solution (Contd..)

Test Case

Expected output

50

50

Not a quadratic equation

-1

50

50

Invalid input

50

50

50

Imaginary Roots

101

50

50

invalid input

50

50

50

Imaginary Roots

50

-1

50

invalid input

50

101

50

invalid input

50

50

50

Imaginary Roots

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.

Example

Consider the program for determining the previous date in a calendar as

explained in previous examples. Identify the equivalence class test cases for
output & input domains.

Example taken from [1]

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

Expected output

15

1962

14 June, 1962

31

1962

Invalid date

Solution (Contd..)
We may have another set of test cases which are based on input domain.
I1={month: 1 m 12}
I2={month: m < 1}
I3={month: m > 12}
I4={day: 1 D 31}
I5={day: D < 1}
I6={day: D > 31}
I7={year: 1900 Y 2025}
I8={year: Y < 1900}
I9={year: Y > 2025}

Solution (Contd..)
Inputs domain test cases are :
Test Case

Expected output

15

1962

14 June, 1962

-1

15

1962

Invalid input

13

15

1962

invalid input

15

1962

14 June, 1962

-1

1962

invalid input

32

1962

invalid input

15

1962

14 June, 1962

15

1899

invalid input (Value out of range)

15

2026

invalid input (Value out of range)

Decision Table Based Testing

Condition
Stub

Entry
True
C1

False

True

False

True

False

True

False

True
True

False
False

---

C2
C3

Action

a1

Stub

X
a2
a3
a4

X
X

X
X

Table: Decision table terminology

Test Case Design

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

C2:x = y?

--

C3:x = z?

--

C4:y = z?

--

a1: Not a triangle

Y
N

Y
Y
Y

N
N

Y
N

N
N

a2: Scalene

a5: Impossible

a3: Isosceles
a4: Equilateral

X
X

Table: Decision table for triangle problem

Software Testing
Conditions
C1 : x < y + z ?

C2 : y < x + z ?

--

C3 : z < x + y ?

--

--

C4 : x = y ?

--

--

--

C5 : x = z ?

--

--

--

C6 : y = z ?

--

--

--

a1 : Not a triangle

a2 : Scalene

a3 : Isosceles
a4 : Equilateral
a5 : Impossible

X
X

Table: Modified decision table

Example

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.

Example taken from [1]

Solution
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: month is February}
I7= {D1: day = 1}
I8= {D2: 2 day 28}
I9= {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}

Solution (Contd..)
The decision table is given below:
Sr.No.

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

X
X

a1: Impossible
a2: Decrement day
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
a8: Reset month to December
a9: Decrement year

Solution (Contd..)
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
a3: Reset day to 31
a4: Reset day to 30
a5: Reset day to 29

a6: Reset day to 28

a7: decrement month
a8: Reset month to December
a9: Decrement year

X
X

Solution (Contd..)
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
a3: Reset day to 31

a8: Reset month to December

a9: Decrement year

a4: Reset day to 30

a5: Reset day to 29
a6: Reset day to 28
a7: decrement month

Solution (Contd..)
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
a2: Decrement day
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
a8: Reset month to December
a9: Decrement year

Solution (Contd..)
Test case

Month

Day

Year

Expected output

June

1964

31 May, 1964

June

1962

31 May, 1962

June

15

1964

14 June, 1964

June

15

1962

14 June, 1962

June

29

1964

28 June, 1964

June

29

1962

28 June, 1962

June

30

1964

29 June, 1964

June

30

1962

29 June, 1962

June

31

1964

Impossible

10

June

31

1962

Impossible

11

May

1964

30 April, 1964

12

May

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

Solution (Contd..)
Test case

Month

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

1964

29 February, 1964

22

March

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

Solution (Contd..)
Test case

Month

Day

Year

Expected output

31

August

1964

31 July, 1962

32

August

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

1964

31 December, 1964

42

January

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

Solution (Contd..)
Test case

Month

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

1964

31 January, 1964

52

February

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

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.

Basic cause effect graph symbols

The basic notation for the graph is shown in figure

Cause Effect Graphing Technique

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

Sample Cause effect graph

Cause Effect Graphing Technique

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),

Constraint Symbols

Symbol for Masks Constraint

Sample Cause Graph with Constraint

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

Figure: The basic construct of the flow graph

Example
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 figure in next slides. 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.

Example taken from [1]

Example

Cont.

Example

Fig. 19: Code of quadratic equation problem

Example

Figure : Program flow graph

Example

Figure : DD Path graph

Solution
The mapping table for DD path graph is:
Flow graph
nodes

DD Path graph
corresponding
node

Remarks

1 to 10

Sequential nodes

11

Decision node

12

Intermediate node

13

Decision node

14,15

Sequential node

16

Two edges are combined here

17

Two edges are combined and decision node

18

Intermediate node

19

Decision node

20,21

Sequential node

22

Decision node

23,24,25

Sequential node

Cont.

Solution
Flow graph
nodes

DD Path graph
corresponding
node

26,27,28,29

Sequential nodes

30

Three edges are combined

31

Decision node

32,33

Sequential node

34,35,36

Sequential node

37

Three edges are combined here

38,39

Sequential nodes with exit node

Independent paths are:

(i) ABGOQRS
(iii) ABCDFGOQRS
(v) ABGHIJNRS
(vi) ABGHIKMNRS

Remarks

(ii) ABGOPRS
(iv) ABCDEFGOPRS
(vi) ABGHIKLNRS

Example

Consider a program given in Figure in next slide 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.

Example taken from [1]

Example

Example

Figure : Code of triangle classification problem

Solution
Flow graph of
triangle problem is:

Figure: Program flow graph

Solution
The mapping table for DD path graph is:
Flow graph
nodes

DD Path graph
corresponding
node

Remarks

1 TO 9

Sequential nodes

10

Decision node

11

Decision node

12, 13

Sequential nodes

14

Two edges are joined here

15, 16, 17

Sequential nodes

18

Decision nodes plus joining of two edges

19

Decision node

20, 21

Sequential nodes

22

Decision node

23, 24

Sequential nodes

25, 26, 27

Sequential nodes

Cont.

Solution
Flow graph
nodes

DD Path graph
corresponding
node

28

M
N
O

Three edges are combined here

P
Q
R

Sequential nodes

29
30, 31
32, 33, 34
35
36, 37

Remarks

Decision node
Sequential nodes
Three edges are combined here
Sequential nodes with exit node

Figure: DD Path graph

Solution
DD Path graph is given in Figure

Independent paths are:

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

Figure: DD Path graph

Text Books

K. K. Aggarwal and Yogesh Singh,

Software
Engineering,
New
Age
International Publishers.
R. S. Pressman, Software Engineering: A
Practitioners Approach, McGraw Hill.
Pankaj Jalote, Software Engineering, A
Precise Approach, Wiley India

References

K. K. Aggarwal and Yogesh Singh,

Software
Engineering,
New
Age
International Publishers.
R. S. Pressman, Software Engineering: A
Practitioners Approach, McGraw Hill.
Pankaj Jalote, Software Engineering, A
Precise Approach, Wiley India .

Thank You
Please forward your query
To: asinghal1@amity.edu
CC:
manoj.amity@panafnet.com