2. In this presentation…..
Black Box Techniques
Equivalence Partioning
Boundary Value Analysis
White Box Techniques
Basis Path Testing
Control Structure Testing
Program Technique Testing
Mutation Testing
co-sponsered by smackstuff.com
3. Equivalence partitioning
•The input domain is usually too large for exhaustive
testing.
•It is therefore partitioned into a finite number of subdomains for the selection of test inputs.
•Each sub-domain is known as an equivalence class and
serves as a source of at least one test input.
co-sponsered by smackstuff.com
4. Equivalence partitioning
Input domain
Input domain
partitioned into four
sub-domains.
2
1
Functional testing
3
4
Too many
test inputs.
Four test inputs, one
selected from each sub-domain.
co-sponsered by smackstuff.com
5. How to partition?
•
Inputs to a program provide clues to partitioning.
•
Example 1:
– Suppose that program P takes an input X, X being an integer.
– For X<0 the program is required to perform task T1 and for X>=0
task T2.
Functional testing
co-sponsered by smackstuff.com
6. How to partition?-continued
– The input domain is prohibitively large because X can assume a large
number of values.
– However, we expect P to behave the same way for all X<0.
– Similarly, we expect P to perform the same way for all values of
X>=0.
– We therefore partition the input domain of P into two sub-domains .
Functional testing
co-sponsered by smackstuff.com
7. Two sub-domains
One test case:
X=-3
Equivalence class
Equivalence class
X<0 X>=0
Another test case:
X=-15
Functional testing
All test inputs in the X<0 sub-domain are considered equivalent.
The assumption is that if one test input in this sub-domain reveals
an error in the program, so will the others.
This is true of the test inputs in the X>=0 sub-domain also.
co-sponsered by smackstuff.com
8. Non-overlapping partitions
•
In the previous example, the two equivalence classes are non-overlapping.
In other words the two sub-domains are disjoint.
•
When the sub-domains are disjoint, it is sufficient to pick one test input
from each equivalence class to test the program .
•
An equivalence class is considered covered when at least one test has
been selected from it.
Functional testing
•
In partition testing our goal is to cover all equivalence classes.
co-sponsered by smackstuff.com
9. Overlapping partitions
•
Example 2:
– Suppose that program P takes three integers X, Y and Z. It is known
that:
• X<Y
• Z>Y
Functional testing
co-sponsered by smackstuff.com
11. Overlapping partition-test selection
•
In this example, we could select 4 test cases as:
– X=4, Y=7, Z=1
– X=4, Y=2, Z=1
satisfies X>=Y
– X=1, Y=7, Z=9
satisfies Z>Y
– X=1, Y=7, Z=2
•
satisfies X<Y
satisfies Z<=Y
Thus, we have one test case from each equivalence class
Functional testing
co-sponsered by smackstuff.com
.
12. Overlapping partition-test selection
•
However, we may also select only 2 test inputs and satisfy all four
equivalence classes:
– X=4, Y=7, Z=1
– X=4, Y=2, Z=3
•
satisfies X<Y and Z<=Y
satisfies X>=Y and Z>Y
Thus, we have reduced the number of test cases from 4 to 2 while
covering each equivalence class.
Functional testing
co-sponsered by smackstuff.com
13. Partitioning using non-numeric data
•
•
In the previous two examples the inputs were integers. One can derive
equivalence classes for other types of data also.
Example 3:
– Suppose that program P takes one character X and one string Y as
inputs. P performs task T1 for all lower case characters and T2 for
upper case characters. Also, it performs task T3 for the null string
and T4 for all other strings.
Functional testing
co-sponsered by smackstuff.com
14. Partitioning using non-numeric data
X: lc, Y: not null
X: UC, Y: not null
X: lc
X:UC
X: lc, Y: null
Functional testing
Y: null Y: not null
X: UC, Y: null
lc: Lower case character
UC: Upper case character
null: null string.
co-sponsered by smackstuff.com
15. Non-numeric data
•
•
Once again we have overlapping partitions.
We can select only 2 test inputs to cover all four equivalence classes. These
are:
– X: lower case, Y: null string
– X: upper case, Y: not a null string
Functional testing
co-sponsered by smackstuff.com
16. Guidelines for equivalence partitioning
•
Input condition specifies a range : create one for the valid case and two for
the invalid cases.
– e.g. for a<=X<=b the classes are
• a<=X<=b (valid case)
• X<a and X>b (the invalid cases)
Functional testing
co-sponsered by smackstuff.com
17. Guidelines-continued
•
Input condition specifies a value: create one for the valid value and two
for incorrect values (below and above the valid value). This may not be
possible for certain data types, e.g. for Boolean.
•
Input condition specifies a member of a set: create one for the valid
co-sponsered by smackstuff.com
value and one for the invalid (not in the set) value
Design Techniques.
.
18. Sufficiency of partitions
•
•
•
In the previous examples we derived equivalence classes based on the
conditions satisfied by the input data.
Then we selected just enough tests to cover each partition.
Think of the advantages and disadvantages of this approach !
co-sponsered by smackstuff.com
Design Techniques
19. Boundary value analysis (BVA)
•
•
•
co-sponsered by smackstuff.com
Another way to generate test cases is to look for boundary values.
Suppose a program takes an integer X as input.
In the absence of any information, we assume that X=0 is a boundary.
Inputs to the program might lie on the boundary or on either side of the
boundary.
Design Techniques
20. BVA: continued
•
This leads to 3 test inputs:
X=0, X=-20, and X=14.
Note that the values -20 and 14 are on either side of the boundary and are
chosen arbitrarily.
co-sponsered by smackstuff.com
•
Notice that using BVA we get 3 equivalence classes. One of these three
classes contains only one value (X=0), the other two are large
Design Techniques
!
21. BVA: continued
•
Now suppose that a program takes two integers X and Y and that x1<=X<=x2
and y1<=Y<=y2.
co-sponsered by smackstuff.com
y2
11
8
y1
5
1
2
10
9
12
4
x1
December 20, 2013
14
Design Techniques
13
7
x2
6
3
22. BVA-continued
•
In this case the four sides of the rectangle represent the boundary.
•
The heuristic for test selection in this case is:
Select one test at each corner (1, 2, 3, 4).
co-sponsered by smackstuff.com
Select one test just outside of each of the four sides of the boundary
(5, 6, 7, 8)
Design Techniques
23. BVA-continued
• Select one test just inside of each of the four sides of the boundary
(10, 11, 12, 13).
• Select one test case inside of the bounded region (9).
• Select one test case outside of the bounded region (14).
co-sponsered by smackstuff.com
How many equivalence classes do we get?
Design Techniques
24. BVA -continued
In the previous examples we considered only numeric data.
BVA can be done on any type of data.
For example, suppose that a program takes a string S and an integer X as inputs.
The constraints on inputs are:
co-sponsered by smackstuff.com
length(S)<=100 and a<=X<=b
Can you derive the test cases using BVA?
Design Techniques
25. BVA applied to output variables
Just as we applied BVA to input data, we can apply it to output data.
Doing so gives us equivalence classes for the output domain.
We then try to find test inputs that will cover each output equivalence class.
co-sponsered by smackstuff.com
Design Techniques
26. White Box Testing Techniques
It is also called as open box or clear box.
Basis Path Testing
•
co-sponsered by smackstuff.com
•
Control Structure Testing
•
Program Technique Testing
•
Mutation Testing
Design Techniques
27. Basis Path Testing
•
Checking for the program running or not from all the possible flows
•
Generate flow graph
•
Calculate Cyclomatic complexity
co-sponsered by smackstuff.com
Example
Program
Flow Graph
Cyclomatic complexity
1 + 1 + 1+ 1 = 4
Design Techniques
28. Basis Path Testing
Using this technique programmers can estimate the execution of the program without
any interruption.
•
Step1: Prepare a program with respect to program logic
•
Step2: Prepare Flow Graph of that program
•
co-sponsered by smackstuff.com
•
Step3: Calculate cyclomatic complexity
•
Step4: Run that program more than one time to cover all the independent paths
Design Techniques
29. Control Structure Testing
During this testing programmers validate the input and output correctness
Step1: Prepare the program according to the design logic
Step2: Execute the program
co-sponsered by smackstuff.com
Step3: Check the input given to the program in all possible ways
Step4: Check the output of the program
Design Techniques
30. Program Technique Testing
•
Using this technique programmers are testing the performance of the program with
different inputs
•
Step1: Prepare the program with respective design logic
•
Step2: Execute the program with different inputs
•
Step3: Calculate the process time
co-sponsered by smackstuff.com
•
Step4: If program execution time is not acceptable change the structure of the
program without disturbing the functionality
Design Techniques
31. Mutation Testing
•
Programmers are making changes in the program to estimate the completeness and
correctness of the program
co-sponsered by smackstuff.com
Program
Program
Program
Change
Change
Passed
Failed
Design Techniques
