1. Black-Box Testing Techniques I
Software Testing and Verification
Lecture 4
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida

2. Definition of Black-Box Testing
Testing based solely on analysis of requirements (specification, user documentation, etc.).
Also know as functional testing.
Black-box testing concerns techniques for designing tests; it is not a “level” of testing.
Black-box techniques apply to all levels of testing (e.g., unit, component, product, and system).

3. Definition of Black-Box Testing
Testing based solely on analysis of requirements (specification, user documentation, etc.).
Also know as functional testing.
Black-box testing concerns techniques for designing tests; it is not a “level” of testing.
Black-box techniques apply to all levels of testing (e.g., unit, component, product, and system).

4. Definition of Black-Box Testing
Testing based solely on analysis of requirements (specification, user documentation, etc.).
Also know as functional testing.
Black-box testing concerns techniques for designing tests; it is not a “level” of testing.
Black-box techniques apply to all levels of testing (e.g., unit, component, product, and system).

5. Definition of Black-Box Testing
Testing based solely on analysis of requirements (specification, user documentation, etc.).
Also know as functional testing.
Black-box testing concerns techniques for designing tests; it is not a “level” of testing.
Black-box techniques apply to all levels of testing (e.g., unit, component, product, and system).

6. Design Techniques Considered
Partition testing
Combinatorial Approaches
Boundary Value Analysis
Intuition & Experience

7. Design Techniques Considered
Partition testing
Combinatorial Approaches
Boundary Value Analysis
Intuition & Experience

8. Design Techniques Considered
Partition testing
Combinatorial Approaches
Boundary Value Analysis
Intuition & Experience

9. Design Techniques Considered
Partition testing
Combinatorial Approaches
Boundary Value Analysis
Intuition & Experience

10. Partition Testing
Also known as input space partitioning and equivalence partitioning.
Can be thought of as exhaustive testing Las Vegas style...
Idea is to partition the program’s input space based on a (small) number of equivalence classes such that, according to the specification, every element of a given partition would be “handled” (i.e., mapped to an output) “in the same manner.”

11. Partition Testing
Also known as input space partitioning and equivalence partitioning.
Can be thought of as exhaustive testing Las Vegas style...
Idea is to partition the program’s input space based on a (small) number of equivalence classes such that, according to the specification, every element of a given partition would be “handled” (i.e., mapped to an output) “in the same manner.”

12. Partition Testing
Also known as input space partitioning and equivalence partitioning.
Can be thought of as exhaustive testing Las Vegas style...
Idea is to partition the program’s input space based on a (small) number of equivalence classes such that, according to the specification, every element of a given partition is “handled” (e.g., mapped to an output) “in the same manner.”

13. Partition Testing (cont’d)
If the program happens to be implemented in such a way that being “handled in the same manner” means that either
every element of a partition is mapped to a correct output, or
every element of a partition is mapped to an incorrect output,
then testing the program with just one element from each partition would be tantamount to exhaustive testing.

14. Partition Testing (cont’d)
Two types of equivalence classes are identified: valid (corresponding to inputs deemed valid from the specification) and invalid (corresponding to inputs deemed erroneous from the specification)
In most multi-input cases, classes for individual inputs must be combined in some manner to partition the input space. (E.g., see City Tax Specification below.)

15. Partition Testing (cont’d)
Two types of equivalence classes are identified: valid (corresponding to inputs deemed valid from the specification) and invalid (corresponding to inputs deemed erroneous from the specification)
In most multi-input cases, classes for individual inputs must be combined in some manner to partition the input space. (E.g., see City Tax Specification below.)

16. Partition Testing (cont’d)
However, it is sometimes possible and convenient to identify multivariate classes which partition an input space directly.
Consider the following specification…

17. Partition Testing (cont’d)
However, it is sometimes possible and convenient to identify multivariate classes which partition an input space directly.
Consider the following specification…

18. Partition Testing Example
Program Specification:
An ordered pair of numbers, (x, y), are input and a message is output stating whether they are in ascending order, descending order, or equal. If the input is other than an ordered pair of numbers, an error message is output.

19. Partition Testing Example (cont’d)
Equivalence Classes:
{ (x, y) | x<y } (V)
{ (x, y) | x>y } (V)
{ (x, y) | x=y } (V)
{ input is other than an ordered
pair of numbers } (I)
Valid classes
Invalid class

20. Valid (x, y) Input Space
x = y
x < y
x > y

21. Partition Testing Example (cont’d)
In this case, being “handled in the same manner” clearly relates directly to the relationship between inputs x and y, so equivalence classes are more naturally defined in terms of (x,y) pairs.

22. Sample Program Design
Conceptually, would the underlying assumption of partition testing hold for these classes if the following program design was employed?
if (input is other than an ordered pair of numbers) then output(“invalid input”)
else
if x<y then output(“ascending order”)
if x>y then output(“ascending order”)
output(“equal”)

23. Identifying and Representing Test Cases
Test case design requirements are often represented (documented) using a “test case COVERAGE MATRIX.”
Columns in the matrix represent templates for test case inputs (and in some cases expected results).
Rows represent the design rationale for each test case.

24. Identifying and Representing Test Cases
Test case design requirements are often represented (documented) using a “test case COVERAGE MATRIX.”
Columns in the matrix represent templates for test case inputs (and in some cases expected results).
Rows represent the design rationale for each test case.

25. Identifying and Representing Test Cases
Test case design requirements are often represented (documented) using a “test case COVERAGE MATRIX.”
Columns in the matrix represent templates for test case inputs (and in some cases expected results).
Rows represent the design rationale for each test case.

26. A Test Case Coverage Matrix
EQUIVALENCE
CLASSES
TEST CASES 1 2 3 4
{ (x, y) | x>y } (V) V
{ (x, y) | x<y } (V)
{ (x, y) | x=y } (V)
{ other } (I) I†
† Rule of thumb: include test cases that cover invalid classes one at a time to
avoid “masking of errors.”

27. Dealing with Complex Multiple-Input Situations
In the example above, (x, y) input pairs were considered as a unit, yielding a set of disjoint classes partitioning the two-dimensional x, y (valid) input space.
For more complex specifications, classes are often identified for INDIVIDUAL input variables, or even INDIVIDUAL ATTRIBUTES of individual input variables, yielding sets of possibly overlapping classes. For example...

28. Dealing with Complex Multiple-Input Situations
In the example above, (x, y) input pairs were considered as a unit, yielding a set of disjoint classes partitioning the two-dimensional x, y (valid) input space.
For more complex specifications, classes are often identified for INDIVIDUAL input variables, or even INDIVIDUAL ATTRIBUTES of individual input variables, yielding sets of possibly overlapping classes. For example...

29. Dealing with Complex Multiple-Input Situations (cont’d)
Part of a More Complex Program Specification:
Three numbers, x, y, and z, are input. If x is a whole number and less than 40, and if y is non-negative, the output is z+(y/x). If x is greater than or equal to 40, or if y is positive, or if z is odd and at least as large as x, then the output is...

30. Dealing with Complex Multiple-Input Situations (cont’d)
(Some) Valid Equivalence Classes:
{ x | x is a whole number } (V)
{ x | x < 40 } (V), { x | x ≥ 40 } (V)
{ y | y = 0 } (V), { y | y > 0 } (V)
{ z | z is odd } (V)
{ (x, z) | z  x } (V)
. . .

31. Dealing with Complex Multiple-Input Situations (cont’d)
In such cases, a strategy for identifying appropriate COMBINATIONS of classes must be employed.
A number of “combinatorial approaches” (including Cause-Effect Analysis) will be considered shortly.
Clearly, the most critical issue in partition testing is the choice of an “equivalence relation” that defines the classes used.

32. Dealing with Complex Multiple-Input Situations (cont’d)
In such cases, a strategy for identifying appropriate COMBINATIONS of classes must be employed.
A number of “combinatorial approaches” (including Cause-Effect Analysis) will be considered shortly.
Clearly, the most critical issue in partition testing is the choice of an “equivalence relation” that defines the classes used.

33. Dealing with Complex Multiple-Input Situations (cont’d)
In such cases, a strategy for identifying appropriate COMBINATIONS of classes must be employed.
A number of “combinatorial approaches” (including Cause-Effect Analysis) will be considered shortly.
Clearly, the most critical issue in partition testing is the choice of an “equivalence relation” that defines the classes used.

34. Some Simple Heuristics for Identifying Equivalence Classes
“Must Be” Situations
“First character must be a letter.”
Identify one valid and one invalid class:
{1st char letter } (V),
{1st char not letter} (I)

35. Some Simple Heuristics for Identifying Equivalence Classes
“Must Be” Situations
“First character must be a letter.”
Identify one valid and one invalid class:
{1st char letter } (V),
{1st char not letter} (I)

36. Some Simple Heuristics for Identifying Equivalence Classes
“Must Be” Situations
“First character must be a letter.”
Identify one valid and one invalid class:
{1st char letter } (V),
{1st char not letter} (I)

37. Some Simple Heuristics for Identifying Equivalence Classes
“Must Be” Situations
“First character must be a letter.”
Identify one valid and one invalid class:
{1st char letter } (V),
{1st char not letter} (I)

38. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Range of Values” Situations
“Input HOURS will range in value from 0 to 40.”
Identify one valid and two invalid classes:
{ HOURS  [0,40] } (V),
{ HOURS < 0 } (I),
{ HOURS > 40 } (I)

39. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Range of Values” Situations
“Input HOURS will range in value from 0 to 40.”
Identify one valid and two invalid classes:
{ HOURS  [0,40] } (V),
{ HOURS < 0 } (I),
{ HOURS > 40 } (I)

40. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Range of Values” Situations
“Input HOURS will range in value from 0 to 40.”
Identify one valid and two invalid classes:
{ HOURS  [0,40] } (V),
{ HOURS < 0 } (I),
{ HOURS > 40 } (I)

41. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Range of Values” Situations
“Input HOURS will range in value from 0 to 40.”
Identify one valid and two invalid classes:
{ HOURS  [0,40] } (V),
{ HOURS < 0 } (I),
{ HOURS > 40 } (I)

42. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Possible Differences” Situations
“For HOURS  20, output ‘Low’; for HOURS > 20, output ‘HIGH’."
If the specification suggests that values in a class may be handled differently, divide the class accordingly. { HOURS  [0,40] } (V) becomes:
{ HOURS  [0,20]} (V),
{ HOURS  (20,40] } (V)

43. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Possible Differences” Situations
“For HOURS  20, output ‘Low’; for HOURS > 20, output ‘HIGH’."
If the specification suggests that values in a class may be handled differently, divide the class accordingly. { HOURS  [0,40] } (V) becomes:
{ HOURS  [0,20]} (V),
{ HOURS  (20,40] } (V)

44. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Possible Differences” Situations
“For HOURS  20, output ‘Low’; for HOURS > 20, output ‘HIGH’."
If the specification suggests that values in a class may be handled differently, divide the class accordingly. { HOURS  [0,40] } (V) becomes:
{ HOURS  [0,20]} (V),
{ HOURS  (20,40] } (V)

45. Some Simple Heuristics for Identifying Equivalence Classes (cont’d)
“Possible Differences” Situations
“For HOURS  20, output ‘Low’; for HOURS > 20, output ‘HIGH’."
If the specification suggests that values in a class may be handled differently, divide the class accordingly. { HOURS  [0,40] } (V) becomes:
{ HOURS  [0,20]} (V),
{ HOURS  (20,40] } (V)

46. Another Partition Testing Example
Identify disjoint sets of classes for each input variable associated with the following program specification fragment.
You may detect some “incompleteness” problems with the specification…

47. Another Partition Testing Example
Identify disjoint sets of classes for each input variable associated with the following program specification fragment.
You may detect some “incompleteness” problems with the specification…

48. City Tax Specification 1:
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the tax is 1%.
- If gross pay is more than $30,000, but no more than
$50,000, the tax is 5%.
- If gross pay is more than $50,000, the tax is 15%.

49. City Tax Specification 1:
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the tax is 1%.
- If gross pay is more than $30,000, but no more than
$50,000, the tax is 5%.
- If gross pay is more than $50,000, the tax is 15%.

50. Equivalence Classes for City Tax Specification 1:
Res?
{ yes } (V)
{ no } (V)
{ other } (I)
Gross_Pay
[0, 30K] (V)
(30K,50K] (V)
(50K, MAX] (V)
< 0 (I)
> MAX (I)
Note that program behaviors associated with invalid inputs are not specified!

51. Two-Dimensional (Valid) Input Space
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
If we partition the space comprised of these classes based solely on the specified outputs, what would the result be?

52. Two-Dimensional (Valid) Input Space
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
If we partition the space comprised of these classes based solely on the specified outputs, what would the result be?

53. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

54. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

55. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

56. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

57. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

58. Partitioning Based on Specified Output
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15%
yes
Res? 1% no
(“Weak Equivalence Class Testing”)
Would you be comfortable with the degree of coverage afforded by choosing ONE test case from each of these 3 partitions? Why or why not?

59. The “Brute-Force” Approach
We could “hedge our bet” by associating a sep-arate partition with every (feasible) combi-nation of classes from the sets:
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
What are the pros and cons of this approach?

60. The “Brute-Force” Approach
We could “hedge our bet” by associating a sep-arate partition with every (feasible) combi-nation of classes from the sets:
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
What are the pros and cons of this approach?

61. The “Brute-Force” Approach
We could “hedge our bet” by associating a sep-arate partition with every (feasible) combi-nation of classes from the sets:
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
(“Strong Equivalence Class Testing”)
What are the pros and cons of this approach?

62. The “Brute-Force” Approach
We could “hedge our bet” by associating a sep-arate partition with every (feasible) combi-nation of classes from the sets:
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
(“Strong Equivalence Class Testing”)
What are the pros and cons of this approach?

63. The “Brute-Force” Approach (cont’d)
The “brute-force” approach of specifying a test case for each (feasible) combination of classes (i.e., for each element in the Cartesian product of the classes associated with each variable) is sometimes referred to as “Strong Equivalence Class Testing.”
In contrast, “Weak Equivalence Class Testing” requires only that all classes are covered. (The minimum number of cases needed will always be the largest number of disjoint classes associated with a single variable.)†
† Note that, as illustrated, covering partitions identified solely on
the basis of specified outputs ≠> weak equivalence class testing.

64. Strong and Weak Equivalence Class Testing
Gross_Pay
Strong:
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
Weak:
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

65. Partitioning Based on the Implied Mapping of Inputs to Outputs
An alternative to both the strong (“brute-force”) and weak equivalence class testing approaches is to consider how the specification implies that inputs are mapped to outputs.
This amounts to choosing an equivalence relation by “second-guessing” how the mapping may actually be implemented based on how the specification is written.
Recall from our specification…

66. Implied Mapping of Inputs to Outputs
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the
tax is 1%.
- If gross pay is more than $30,000, but no
more than $50,000, the tax is 5%.
- If gross pay is more than $50,000, the
tax is 15%.

67. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

68. Implied Mapping of Inputs to Outputs
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the
tax is 1%.
- If gross pay is more than $30,000, but no
more than $50,000, the tax is 5%.
- If gross pay is more than $50,000, the
tax is 15%.

69. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

70. Implied Mapping of Inputs to Outputs
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the
tax is 1%.
- If gross pay is more than $30,000, but no
more than $50,000, the tax is 5%.
- If gross pay is more than $50,000, the
tax is 15%.

71. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

72. Implied Mapping of Inputs to Outputs
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the
tax is 1%.
- If gross pay is more than $30,000, but no
more than $50,000, the tax is 5%.
- If gross pay is more than $50,000, the
tax is 15%.

73. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

74. Implied Mapping of Inputs to Outputs
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale:
- If gross pay is no more than $30,000, the
tax is 1%.
- If gross pay is more than $30,000, but no
more than $50,000, the tax is 5%.
- If gross pay is more than $50,000, the
tax is 15%.

75. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
What are the pros and cons of this approach?

76. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
What are the pros and cons of this approach?

77. Partitioning Based on the Implied Mapping of Inputs to Outputs
What does the logical mapping of inputs to outputs implied by the specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no
What are the pros and cons of this approach?

78. City Tax Specification 2
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
If gross pay is no more than $30,000, the tax is 1%.
If gross pay is more than $30,000, but no more than $50,000 the tax is 1% for non-residents and 5% for residents.
If gross pay is more than $50,000, the tax is 1% for nonresidents and 15% for residents.

79. City Tax Specification 2 (cont’d)
What does the logical mapping of inputs to outputs implied by this specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 1% 5%
15%
yes
Res? no

80. City Tax Specification 2
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
If gross pay is no more than $30,000, the tax is 1%.
If gross pay is more than $30,000, but no more than $50,000 the tax is 1% for non-residents and 5% for residents.
If gross pay is more than $50,000, the tax is 1% for nonresidents and 15% for residents.

81. City Tax Specification 2 (cont’d)
What does the logical mapping of inputs to outputs implied by this specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15% 1%
yes
Res? 1% no

82. City Tax Specification 2
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
If gross pay is no more than $30,000, the tax is 1%.
If gross pay is more than $30,000, but no more than $50,000 the tax is 1% for non-residents and 5% for residents.
If gross pay is more than $50,000, the tax is 1% for nonresidents and 15% for residents.

83. City Tax Specification 2 (cont’d)
What does the logical mapping of inputs to outputs implied by this specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15% 1%
yes
Res? 1% no

84. City Tax Specification 2
The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question.
If gross pay is no more than $30,000, the tax is 1%.
If gross pay is more than $30,000, but no more than $50,000 the tax is 1% for non-residents and 5% for residents.
If gross pay is more than $50,000, the tax is 1% for nonresidents and 15% for residents.

85. City Tax Specification 2 (cont’d)
What does the logical mapping of inputs to outputs implied by this specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15% 1%
yes
Res? 1% no

86. City Tax Specification 2 (cont’d)
What does the logical mapping of inputs to outputs implied by this specification suggest about how the input space should be partitioned?
Gross_Pay
 30K
(30K, 50K]
> 50K 5%
15% 1%
yes
Res? 1% no

87. Some conclusions
In general, the connection between partition testing and exhaustive testing is tenuous, at best.
Partitioning a complex, multi-dimensional input space based solely on differences in specified output behavior can be risky.

88. Some conclusions
In general, the connection between partition testing and exhaustive testing is tenuous, at best.
Partitioning a complex, multi-dimensional input space based solely on differences in specified output behavior can be risky.

89. Some conclusions (cont’d)
The “brute-force” approach of associating a separate partition with every (feasible) combination of classes (“strong equivalence class testing”) provides excellent black-box coverage, but is impractical when the number of inputs and associated sets of classes is large.
“Weak equivalence class testing” ensures that all classes are covered, but not all (feasible) combinations of classes

90. Some conclusions (cont’d)
The “brute-force” approach of associating a separate partition with every (feasible) combination of classes (“strong equivalence class testing”) provides excellent black-box coverage, but is impractical when the number of inputs and associated sets of classes is large.
“Weak equivalence class testing” ensures that all classes are covered, but does not ensure coverage of all (feasible) combinations of classes.

91. Some conclusions (cont’d)
Choosing an equivalence relation by “second-guessing” how the mapping of inputs to outputs may be imple- mented based on how the specification is written seems more in keeping with:
...according to the specification, every element
of a given partition would be “handled” (e.g.,
mapped to an output) “in the same manner.”
But does test case coverage of the resultant partitions guarantee:
Strong equivalence class testing?
Weak equivalence class testing?

92. Some conclusions (cont’d)
Choosing an equivalence relation by “second-guessing” how the mapping of inputs to outputs may be imple- mented based on how the specification is written seems more in keeping with:
...according to the specification, every element
of a given partition would be “handled” (e.g.,
mapped to an output) “in the same manner.”
But does test case coverage of the resultant partitions guarantee:
Strong equivalence class testing? Obviously not.
Weak equivalence class testing?

93. Some conclusions (cont’d)
Choosing an equivalence relation by “second-guessing” how the mapping of inputs to outputs may be imple- mented based on how the specification is written seems more in keeping with:
...according to the specification, every element
of a given partition would be “handled” (e.g.,
mapped to an output) “in the same manner.”
But does test case coverage of the resultant partitions guarantee:
Strong equivalence class testing? Obviously not.
Weak equivalence class testing? No.

94. Some conclusions (cont’d)
Choosing an equivalence relation by “second-guessing” how the mapping of inputs to outputs may be imple- mented based on how the specification is written seems more in keeping with:
...according to the specification, every element
of a given partition would be “handled” (e.g.,
mapped to an output) “in the same manner.”
But does test case coverage of the resultant partitions guarantee:
Strong equivalence class testing? Obviously not.
Weak equivalence class testing? No.†
† Try writing a “City Tax Specification 3” that proves this.

95. Coming Up Next…
The combinatorial approach considered next, Cause-Effect Analysis, allows for the systematic (and with appropriate tool support, automatic) partitioning of a multi-dimensional input space for different levels of coverage.

96. Black-Box Testing Techniques I
Software Testing and Verification
Lecture 4
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida