Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Black Box Unit Testing
This material was covered during lectures on April 2, 1997.
Equivalence Partitioning is a black box testing method in which one attempts to partition the ``input domain'' for a function into a collection of disjoint sets, such that a test case can be derived for each set, with the hope that (if the function has been implementation in a reasonable way) the function's behaviour will be consistent for all inputs in the same ``set.''
In particular, it's hoped that if the function works (in)correctly on any one input from the set, then it works (in)correctly on all inputs from the set - so that one test can give reasonable evidence about how the function will behave on all inputs in the set at once.
In equivalence partitioning, the type of each input parameter is inspected, and one tries to follow a set of guidelines in order to split up the input set, based on the type of parameter found.
For example, if it's found that an input parameter is an integer and a range of values is considered to be acceptable (that is, ``correct'' values for the parameter), then guidelines for equivalence partitioning dictate that you should include a test such that the parameter's value is smaller than the minimum value allowed, a second test such that the parameter's value is within the allowed range, and a third test such that the parameter's value is greater than the maximum value allowed. Effectively, the set of all inputs has been partitioned into three disjoint sets.
In general, each input parameter can be used to split the set of all inputs into two, or three, sets; taking all combinations of test cases will give a number of tests that is exponential in the number of input parameters - but not too large, if the number of parameters is small (which you should hope to be the case, in any event).
A similar kind of strategy can be used to partition the output domain - that is, can be applied to the values returned by the function as outputs.
A small amount of additional information can be found in recent editions of Pressman's Software Engineering: A Practitioner's Approach.
Boundary Value Analysis is a method that ``complements'' Equivalence Partitioning, by adding tests in which inputs have values at the ``boundaries'' of their allowed ranges of values. For example, if an input parameter is allowed to have values between some minimum value a and some maximum value b, then the guidelines for Boundary Value Analysis will dictate inclusion of tests in which the parameter has values a-1, a, a+1, b-1, b, and b+1. A similar idea can be applied in order to produce tests on data structures, such as arrays, whose sizes can vary: Include tests such that the data structure is slightly too small, just barely large enough, just barely small enough, and slightly too large.
This is motivated by experience suggesting that some mistakes, like ``off-by-one errors,'' affect behaviour of functions (only) when parameters have values or sizes near the maximum or minimum that is allowed. Since these mistakes are easy to make, it's worthwhile to include tests designed specifically to find them.
Again, additional details can be found in recent editions of Pressman's text.
This is not a ``testing method,'' in the sense that it you probably won't find it discussed in references on testing. However, it should be noted that you should include tests that make all the ``errors'' identified in process or module specifications - it isn't sufficient to test the behaviour of functions on ``correct'' inputs alone.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Black Box Unit Testing