1. Subject Name: Software Testing Subject Code: 10CS842 Prepared By:
Tamilarasi.R
Department:
CSE
Date
4/25/2018

2. Unit –II
Boundary Value Testing, Equivalence Class Testing, Decision Table-Based Testing
4/25/2018

3. 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/25/2018

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:

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

9. Example Test Cases Using Boundary Value Analysis
Expected Output 1
100
Isosceles 2 3
Equilateral 4
199 5
200
Not a Trianle 6 7 8 9 10
Not a Triangle 11 12 13 14 15

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

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

17. Robust Worst Case Testing for Program P… … … … … … …

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
Stock = κοντάκι όπλου, Barrel = κάνη όπλου, Lock = όχι σκανδάλη

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

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

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

24. 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.
4/25/2018

25. 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 ~.
4/25/2018

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}

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. 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 }
University of Waterloo

29. Equivalence Class Test Cases for the NextDate 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!!!
Universi

30. Equivalence Class Test Cases for the NextDate Function
Weak equivalence class test cases
Strong equivalence class test cases

31. 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 }
SE 465/ECE 453
University of Waterloo

32. Equivalence Class Test Cases for the Commission Problem
Strong Input Domain Equivalence Class Test Cases
Weak Input Domain Equivalence Class Test Cases

33. Equivalence Class Test Cases for the Commission 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

34. Guidelines and Observations
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
The only time it makes sense to use the traditional approach is when the implementation language is not strongly typed
If error conditions are a high priority, we could extend strong equivalence class testing to include invalid classes (e.g. commission problem)
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
University of Waterloo

35. Guidelines and Observations
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)
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
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
University of Waterloo

36. Guidelines and Observations
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
University of Waterloo