Functional Testing

Lecture 4

10/17/2024
1
Functional Testing
◼ It is based on the view that any program
can be considered to be a function that
maps from its input domain to values in its
output range.
◼ Also called Black Box testing.
◼ Testing is based on the functionality of the
program.
◼ Internal structure of code is ignored.

2
10/17/2024
Functional Testing

Input Output
Test Black Box
Test
Data Data

First concentrate on test to pass and then test

to fail. 3
10/17/2024
Functional Testing
◼ Black Box testing
 Boundary Value testing
 Equivalence Class testing
 Decision Tables
 Cause Effect Graphing

4
10/17/2024
Boundary/Limits Testing
◼ Test values, sizes or quantities near the
design limits
◼ Errors tend to occur near the extreme
values of inputs
◼ Robustness: How does the software react
when boundaries are exceeded?

5
10/17/2024
Single Fault Assumption

The Single Fault assumption from reliability

states:
“Failures are rarely the result of the
simultaneous occurrence of two (or more)
faults.”

6
10/17/2024
Extensions of Boundary Testing

◼ Boundary value testing

◼ Robustness testing
◼ Worst-case testing
◼ Robust worst-case testing

7
10/17/2024
Boundary Value Testing

◼ The basic idea of boundary value analysis

is to use input variable values at their
minimum, just above the minimum, at a
nominal value, just below the maximum,
and at the maximum

8
10/17/2024
Input Boundary Value Testing

a b
x

X(min) X(min+) X(nom) X(max-) X(max)

Test cases for a variable x, where a ≤ x ≤ b

Experience shows that errors occur more

frequently for extreme values of a variable

9
10/17/2024
Input Boundary Value Testing (2 variables)

x2

a b x1
Test cases for variable x1 and x2
As in reliability theory, two variables rarely assume
their extreme value
10
10/17/2024
Robustness Testing
◼ An extension of Boundary Value testing:
Include values below the minimum value
and above the maximum value
◼ This is a form of what we call “negative
testing” -- how does the program handle
errors in the input?
◼ This type of testing may not be possible
with some strongly-typed languages

11
10/17/2024
Robustness Testing

a b
x

Test cases for a variable x, where a ≤ x ≤ b

•Stress input boundaries

•Leads to exploratory testing
•Can discover hidden functionality

12
10/17/2024
Robustness Testing (2 variables)

x2

a b x1
Test cases for variable x1 and x2

13
10/17/2024
Worst Case Testing

◼ Discard the Single-Fault Assumption

◼ Allow the input values to
simultaneously approach their
boundaries

14
10/17/2024
Worst Case Testing (2 variables)

x2

a b x1
Test cases for variable x1 and x2

Eliminate the single fault assumption

15
10/17/2024
Robust Worst-case Testing

◼ Discard the Single-Fault Assumption

◼ Allow the input values to
simultaneously approach and exceed
their boundaries

16
10/17/2024
Limitations of Boundary Value
Testing
◼ Variables must be independent.
◼ Not possible for Boolean variables.

17
10/17/2024
Number of Test Cases

◼ In Boundary value Analysis:

4n+1
◼ Robustness Testing
6n+1
◼ Worst-case Testing
5n
Where n is the number of variables

18
10/17/2024
Ad Hoc Testing
◼ Testing carried out using no recognized test
case design technique.
◼ Also known as Special value testing.
◼ Mostly intuitive and least uniform.
◼ It occurs when the tester uses domain
knowledge experience and information about
soft spots to derive test cases. This is also called
ad hoc testing.
◼ Dependent on the abilities of the tester.
◼ Other terms: “hacking”, “out-of-box testing”,
“guerilla testing”
19
10/17/2024
Equivalence Class Testing

◼ Implication of Testing
 Completeness
 Avoid redundancy.

20
10/17/2024
Determining equivalencies

◼ Look for ranges of numbers or values

◼ Look for memberships in groups
◼ Some may be based on time
◼ Include invalid inputs
◼ Don’t worry if they overlap — better to be
redundant than to miss something

21
10/17/2024
Example:
◼ Consider a function F with input variables
x1 and x2 that have the following
boundaries and interval within boundaries.
◼ a<= x1<=d with intervals [a b), [b c), [c d]
◼ e<=x2<=g with intervals [e f), [f g]
◼ Where square brackets and parenthesis
denote closed and open interval end
points respectively.
◼ Invalid values are x1< a, x1>d and x2<e,
x2>g
22
10/17/2024
Types of Equivalence class Testing

◼ Weak Normal Equivalence Class Testing:

use one variable from each equivalence
class in a test case.
◼ Strong Normal Equivalence Class Testing:
based on multiple fault assumption.
◼ Weak robust equivalence class testing
◼ Strong robust equivalence class testing

23
10/17/2024
Weak Normal Equivalence Class
Test Cases
◼ We use one variable from each
equivalence class (interval) in a test case.
◼ Based on single fault assumption theory.
◼ We will always have same number of test
cases as classes in the partition with
largest number of subsets.

24
10/17/2024
Weak Normal Equivalence Class
Testing
x2

a b c d x1

25
10/17/2024
Strong Normal Equivalence Class
Testing
◼ Based on Multiple fault assumption.
◼ We need test case from each element of
the Cartesian product of the equivalence
class

26
10/17/2024
Strong Normal Equivalence Class
Testing
x2

a b c d x1

27
10/17/2024
Weak Robust Equivalence Class
Testing
◼ Name is oxymoronic.
◼ Robust part comes from consideration of
invalid values.
◼ Weak part comes from single fault
assumption.

28
10/17/2024
Weak Robust Equivalence Class
Testing
x2

a b c d x1

29
10/17/2024
Strong Robust Equivalence Class
Testing
◼ Robust part comes from consideration of
invalid values.
◼ Strong part comes from multiple fault
assumption.

30
10/17/2024
Strong Robust Equivalence Class
Testing
x2

a b c d x1

31
10/17/2024
Problems with Robust Testing

◼ Specification does not define what the

expected output for an invalid test case
should be.
◼ Strongly typed languages eliminate the
need for the consideration of invalid
inputs.

32
10/17/2024