st_unit_2.ppt

Subject Name:
Software Testing
Subject Code:
10CS842
Prepared By:
Tamilarasi.R
Department:
CSE
Date
11/11/2023

Unit –II
Boundary Value Testing,
Equivalence Class Testing, Decision
Table-Based Testing
11/11/2023

11/11/2023
Topics
• Boundary value analysis
• Robustness testing
• Worst-case testing
• Special value testing
• Examples, Random testing, Equivalence classes,
Equivalence test cases for the triangle problem, Next
Date function, and the commission problem,
Guidelines and observations. Decision tables, Test
cases for the triangle problem, Next Date function,
and the commission problem, Guidelines and
observations.

4
Boundary Value Analysis
• Boundary value analysis focuses on the boundary of the
input space to identify test cases.
• The rationale behind boundary value analysis is that errors
tend to occur near the extreme values of an input
variable.
• Programs written in non-strongly typed languages are
more appropriate candidates for boundary value testing.
• In our discussion we will assume a program P accepting
two inputs x1 andx2 such that a ≤ y1 ≤ b and c ≤ y2 ≤ d

5
Valid Input for Program P
• consider the following function:
• boundary inequalities of n input variables define an n-
dimensional input space:
d
y
c
b
y
a
y
y
f 


 2
1
2
1 ,
where
),
,
(
a b
c
d
y2
y1

6
Value Selection in Boundary Value
Analysis
• The basic idea in boundary value analysis is to
select input variable values at their:
– Minimum
– Just above the minimum
– A nominal value
– Just below the maximum
– Maximum

7
Single Fault Assumption
• Boundary value analysis is also augmented by the
single fault assumption principle.
“Failures occur rarely as the result of the
simultaneous occurrence of two (or more) faults”
• In this respect, boundary value analysis test cases can
be obtained by holding the values of all but one
variable at their nominal values, and letting that
variable assume its extreme values.

8
Boundary Value Analysis for Program
P
T = { <y1nom, y2min>, <y1nom, y2min+>, <y1nom, y2nom>, <y1nom, y2max->,
<y1nom, y2max+>, <y1min, y2nom>, < 1nin+, y2nom>, <y1max-, y2nom>,
<y1max, y2nom> }
a b
c
d
y2
y1
.. . ..
.
.
.
.

9
Example Test Cases Using Boundary
Value Analysis
Case # a b c Expected Output
1 100 100 1 Isosceles
3 100 100 100 Equilateral
4 100 100 199 Isosceles
5 100 100 200 Not a Trianle
9 100 199 100 Isosceles
10 100 200 100 Not a Triangle
14 199 100 100 Isosceles
15 200 100 100 Not a Triangle

10
Generalizing Boundary Value Analysis
• The basic boundary value analysis can be
generalized in two ways:
– By the number of variables - (4n +1) test cases
for n variables
– By the kinds of ranges of variables
• Programming language dependent
• Bounded discrete
• Unbounded discrete (no upper or lower bounds
clearly defined)
• Logical variables

11
Limitations of Boundary Value Analysis
• Boundary value analysis works well when the program to be
tested is a function of several independent variables that
represent bounded physical quantities.
• Boundary value analysis selected test data with no
consideration of the function of the program, nor of the
semantic meaning of the variables.
• We can distinguish between physical and logical type of
variables as well (e.g. temperature, pressure speed, or PIN
numbers, telephone numbers etc.)

12
Independence Assumption and
Efficacy of BVT
• Assumes that input variables are independent of one another,
– i.e. the assumption that particular combinations of input variable values have no
special significance
• If basic assumption is not true, then BVT may overlook important test
requirements
• BVT is an instance of more general techniques such as equivalence class
testing or domain testing.
• BVT tends to generate more test cases with poorer test coverage (with the
independence assumption) than domain or equivalence testing.
• But, due to its simplicity, BVT test case generation can be easily automated.

13
Robustness Testing
• Robustness testing is a simple extension of boundary value
analysis.
• In addition to the five boundary value analysis values of
variables, we add values slightly greater that the maximum
(max+) and a value slightly less than the minimum (min-).
• The main value of robustness testing is to force attention on
exception handling.
• In some strongly typed languages values beyond the predefined
range will cause a run-time error.
• It is a choice of using a weak typed language with exception
handling or a strongly typed language with explicit logic to
handle out of range values.

14
Robustness Test Cases for Program P
a b
c
d
y2
y1
... . …
.
.
.
.
.
.

15
Worst Case Testing
• In worst case testing we reject the single fault assumption ans we are
interested what happens when more than one variable has an
extreme value.
• Considering that we have five different values that can be considered
during boundary value analysis testing for one variable, now we take
the Cartesian product of these possible values for 2, 3, … n variables.
• In this respect we can have 5n test cases for n input variables.
• The best application of worst case testing is where physical variables
have numerous interactions and failure of a program is costly.
• Worst case testing can be further augmented by considering robust
worst case testing (i.e. adding slightly out of bounds values to the five
already considered).

16
Worst Case Testing for Program P
a b
c
d
y2
y1
.. . ..
.. . ..
.. . ..
.. . ..
.. . ..

17
Robust Worst Case Testing for Program
P
a b
c
d
y2
y1
... . …
... . …
... . …
... . …
... . …
... . …
... . …

18
Special Value Testing
• Special value testing is probably the most widely practiced
form of functional testing, most intuitive, and least uniform.
• Utilizes domain knowledge and engineering judgment about
program’s “soft spots” to devise test cases.
• Event though special value testing is very subjective on the
generation of test cases, it is often more effective on revealing
program faults.

19
Guidelines for Boundary Value Testing
• With the exception of special value testing, the test methods based
on the boundary values of a program are the most rudimentary.
• Issues in producing satisfactory test cases using boundary value
testing:
– Truly independent variables versus not independent variables
– Normal versus robust values
– Single fault versus multiple fault assumption
• Boundary value analysis can also be applied to the output range of a
program (i.e. error messages), and internal variables (i.e. loop control
variables, indices, and pointers).

20
The Commission Problem
• Rifle salespersons in the Arizona Territory sold rifle locks,
stocks, and barrels made by a gunsmith in Missouri
• Lock = $45.00, stock = $30.00, barrel = $25.00
• Each salesperson had to sell at least one complete rifle per
month ($100)
• The most one salesperson could sell in a month was 70 locks,
80 stocks, and 90 barrels
• Each salesperson sent a telegram to the Missouri company
with the total order for each town (s)he visits
• 1≤towns visited≤10, per month
• Commission: 10% on sales up to $1000, 15% on the next
$800, and 20% on any sales in excess of $1800

21
Example Test Cases Using Output Range Values
80
90
60
60
70
72
40
22.2
33.3
Stocks
Locks
Barrels

22
Output Boundary Value Test Cases
Case # Locks Stocks Barrels Sales Comm. Comments
1 1 1 1 100 10 min
2 10 10 9 975 97.5 border-
3 10 9 10 970 97 border-
4 9 10 10 955 95.5 border-
5 10 10 10 1000 100 border
6 10 10 11 1025 103.75 border+
7 10 11 10 1030 104.5 border+
8 11 10 10 1045 106.75 border+

23
Output Special Value Test Cases
Case # Locks Stocks Barrels Sales Comm. Comment
1 10 11 9 1005 100.75 border+
2 18 17 19 1795 219.25 border+
3 18 19 17 1805 221 border+

11/11/2023
Random testing
• Random testing is a black-box software testing technique
where programs are tested by generating random,
independent inputs. Results of the output are compared
against software specifications to verify that the test output
is pass or fail.
• In case of absence of specifications the exceptions of the
language are used which means if an exception arises during
test execution then it means there is a fault in the program.

Equivalence Classes
• In mathematics, when a set has an equivalence
relation defined on its elements, there is a natural grouping
of elements that are related to one another, forming what
are called equivalence classes.
• An equivalence relation is a binary relation ~ satisfying three properties:
• For every element a in X, a ~ a (reflexivity),
• For every two elements a and b in X, if a ~ b, then b ~ a (symmetry)
• For every three elements a, b, and c in X, if a ~ b and b ~ c, then a ~ c (transitivity).
• The equivalence class of an element a is denoted [a] and is defined as the set
• of elements that are related to a by ~.
11/11/2023

26
Equivalence Class Test Cases for the Triangle
Problem
• Outputs: Not a Triangle, Scalene, Isosceles, Equilateral
• Easier to identify output (range) equivalence classes
– R1 = {<a, b, c> : the triangle with sides a, b, and c is equilateral}
– R2 = {<a, b, c> : the triangle with sides a, b, and c is isosceles}
– R3 = {<a, b, c> : the triangle with sides a, b, and c is scalene}
– R4 = {<a, b, c> : sides a, b, and c do not form a triangle}
T
e
s
tC
a
s
e a b c E
x
p
e
c
te
dO
u
tp
u
t
O
E
1 5 5 5 E
q
u
ila
te
ra
l
O
E
2 2 2 3 Is
o
s
c
e
le
s
O
E
3 3 4 5 S
c
a
le
n
e
O
E
4 4 1 2 N
o
taT
ria
n
g
le

27
Equivalence Class Test Cases for the Triangle
Problem
• Input (domain) equivalence classes
D1 = {<a, b, c> : a = b = c}
D2 = {<a, b, c> : a = b, a ≠ c}
D3 = {<a, b, c> : a = c, a ≠ b}
D4 = {<a, b, c> : b = c, a ≠ b}
D5 = {<a, b, c> : a ≠ b, a ≠ c, b ≠ c}
// D6 = {<a, b, c> : a ≥ b + c}
D6’ = {<a, b, c> : a = b + c}
D6’’ = {<a, b, c> : a > b + c}
// D7 = {<a, b, c> : b ≥ a + c}
D7’ = {<a, b, c> : b = a + c}
D7’’ = {<a, b, c> : b > a + c}
// D8 = {<a, b, c> : c ≥ a + b}
D8’ = {<a, b, c> : c = a + b}
D8’’ = {<a, b, c> : c > a + b}

28 University of Waterloo
Equivalence Class Test Cases for the NextDate
Function
• Input variables
– 1 ≤ month ≤ 12
– 1 ≤ day ≤ 31
– 1812 ≤ year ≤ 2012
• Traditional approach
– Valid equivalence classes
• M1 = { month : 1 ≤ month ≤ 12 }
• D1 = { day : 1 ≤ day ≤ 31 }
• Y1 = { year : 1812 ≤ year ≤ 2012 }
– Invalid equivalence classes
• M2 = { month : month < 1 }
• M3 = { month : month > 12 }
• D2 = { day : day < 1 }
• D3 = { day : day >31 }
• Y2 = { year : year < 1812 }
• Y3 = {year : year > 2012 }
C
a
s
eID M
o
n
th D
a
y Y
e
a
r E
x
p
e
c
te
dO
u
tp
u
t
T
E
1 6 1
5 1
9
1
2 6
/1
6
/1
9
1
2
T
E
2 -
1 1
5 1
9
1
2 in
v
a
lidin
p
u
t
T
E
3 1
3 1
5 1
9
1
2 in
v
a
lidin
p
u
t
T
E
4 6 -
1 1
9
1
2 in
v
a
lidin
p
u
t
T
E
5 6 3
2 1
9
1
2 in
v
a
lidin
p
u
t
T
E
6 6 1
5 1
8
1
1 in
v
a
lidin
p
u
t
T
E
7 6 1
5 2
0
1
3 in
v
a
lidin
p
u
t

29 Universi
Function
• Traditional approach is deficient because it “treats” the
elements of a class at the valid/invalid level
• Different approach: What must be done to an input date?
M1 = { month: month has 30 days }
M2 = { month: month has 31 days }
M3 = { month: month is February }
D1 = { day: 1 ≤ day ≤ 28 }
D2 = { day: day = 29 }
D3 = { day: day = 30 }
D4 = { day: day = 31 }
Y1 = { year: year = 1900 }
Y2 = { year: 1812 ≤ year ≤ 2012 AND (year ≠ 1900)
AND (year mod 4 = 0) }
Y3 = { year: 1812 ≤ year ≤ 2012 AND (year mod 4 ≠ 0) }
Not a perfect set of equivalence classes!!!

30
Function
C
a
s
eID M
o
n
th D
a
y Y
e
a
r E
x
p
e
c
te
dO
u
tp
u
t
W
E
1 6 1
4 1
9
0
0 6
/1
5
/1
9
0
0
W
E
2 7 2
9 1
9
1
2 7
/3
0
/1
9
1
2
W
E
3 2 3
0 1
9
1
3 in
v
a
lidin
p
u
t
W
E
4 6 3
1 1
9
0
0 in
v
a
lidin
p
u
t
Weak equivalence class test cases
Case ID Month Day Year Expected Output
SE1 6 14 1900 6/15/1900
SE2 6 14 1912 6/15/1912
SE3 6 14 1913 6/15/1913
SE4 6 29 1900 6/30/1900
SE5 6 29 1912 6/30/1912
SE6 6 29 1913 6/30/1913
SE7 6 30 1900 07/01/1900
SE8 6 30 1912 07/01/1912
SE9 6 30 1913 07/01/1913
SE10 6 31 1900 ERROR
SE11 6 31 1912 ERROR
SE12 6 31 1913 ERROR
SE13 7 14 1900 7/15/1900
SE14 7 14 1912 7/15/1912
SE15 7 14 1913 7/15/1913
SE16 7 29 1900 7/30/1900
SE17 7 29 1912 7/30/1912
SE18 7 29 1913 7/30/1913
Case ID Month Day Year Expected Output
SE19 7 30 1900 7/31/1900
SE20 7 30 1912 7/31/1912
SE21 7 30 1913 7/31/1913
SE22 7 31 1900 08/01/1900
SE23 7 31 1912 08/01/1912
SE24 7 31 1913 08/01/1913
SE25 2 14 1900 2/15/1900
SE26 2 14 1912 2/15/1912
SE27 2 14 1913 2/15/1913
SE28 2 29 1900 ERROR
SE29 2 29 1912 03/01/1912
SE30 2 29 1913 ERROR
SE31 2 30 1900 ERROR
SE32 2 30 1912 ERROR
SE33 2 30 1913 ERROR
SE34 2 31 1900 ERROR
SE35 2 31 1912 ERROR
SE36 2 31 1913 ERROR
Strong equivalence class test cases

SE 465/ECE 453 31 University of Waterloo
Equivalence Class Test Cases for the Commission
Problem
• Input Domain Equivalence Classes
– Lock
• L1 = { lock: 1 ≤ lock ≤ 70 }
• L2 = { lock: lock < 1 }
• L3 = { lock: lock > 70 }
– Stock
• S1 = { stock: 1 ≤ stock ≤ 80 }
• S2 = { stock: stock < 1 }
• S3 = { stock: stock > 80 }
– Barrel
• B1 = { barrel: 1 ≤ barrel ≤ 90 }
• B2 = { barrel: barrel < 1 }
• B3 = { barrel: barrel > 90 }

32
Problem
Strong Input Domain Equivalence Class Test Cases
Test Case locks stocks barrels sales com m ission
SE1 35 40 45 3900 640
SE2 35 40 0 ERROR ERROR
T
e
s
t
C
a
s
e
l
o
c
k
ss
t
o
c
k
s
b
a
r
r
e
l
ss
a
l
e
sc
o
m
m
i
s
s
i
o
n
W
E
1 3
5 4
0 4
5 3
9
0
0 6
4
0
W
E
2 0 0 0 E
R
R
O
R
E
R
R
O
R
W
E
3 7
1 8
1 9
1 E
R
R
O
R
E
R
R
O
R
Weak Input Domain Equivalence Class Test Cases

33
Problem
• sales = 45 x locks + 30 x stocks + 25 x barrels
• L1 = { <lock, stock, barrel> : sales ≤ 1000 }
• L2 = { <lock, stock, barrel> : 1000 < sales ≤ 1800 }
• L3 = { <lock, stock, barrel> : sales > 1800 }
Output Range Equivalence Class Test Cases
T
e
s
t
C
a
s
e
l
o
c
k
ss
t
o
c
k
s
b
a
r
r
e
l
ss
a
l
e
sc
o
m
m
i
s
s
i
o
n
O
R
1 5 5 5 5
0
0 5
0
O
R
2 1
5 1
5 1
5 1
5
0
0 1
7
5
O
R
3 2
5 2
5 2
5 2
5
0
0 3
6
0

Guidelines and Observations
1. The traditional form of equivalence class testing is generally
not as thorough as weak equivalence class testing, which in
turn, is not as thorough as the strong form of equivalence
class testing
2. The only time it makes sense to use the traditional
approach is when the implementation language is not
strongly typed
3. If error conditions are a high priority, we could extend
strong equivalence class testing to include invalid classes
(e.g. commission problem)
4. Equivalence class testing is appropriate when input data is
defined in terms of ranges and sets of discrete values. This
is certainly the case when system malfunctions can occur
for out-of-limit variable values

1. Equivalence class testing is strengthened by a hybrid
approach with boundary value testing. (We can “reuse” the
effort made in defining the equivalence classes) (e.g.
NextDate function)
2. Equivalence class testing is indicated when the program
function is complex. In such cases, the complexity of the
function can help identify useful equivalence classes, as in
the NextDate function
3. Strong equivalence class testing makes a presumption that
the variables are independent when the Cartesian Product
is taken. If there are any dependencies, these will often
generate “error” test cases, as they did in the NextDate
function

1. Several tries may be needed before “the
right” equivalence relation is discovered, as
we saw in the NextDate example. In other
cases, there is an “obvious” or “natural”
equivalence partition. When in doubt, the
best bet is to try to second guess aspects of
any reasonable implementation

st_unit_2.ppt

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to st_unit_2.ppt

Similar to st_unit_2.ppt (20)

Recently uploaded

Recently uploaded (20)

st_unit_2.ppt