Domains and Paths Includes:
Domain Dimensionality
Each input variable adds a dimension to the domain
One variable defines domains on a number line
Example: Age, Salary etc
Two variable define planar domains
Example: x and y co-ordinate values of a plane, sales by month data
Three variables define solid domains
Example: Monthly sales by city data where month, city and sales are the variables
Every new predicates slices through previously defined domains and cuts them in half
Every boundary slices through the input vector space with a dimensionality which is less than the dimensionality of the space
Hence, planes are cut by lines and points, volumes are cut by planes, lines and points and n-spaces are cut by hyper planes
Bug Assumptions
For domain testing, the bug assumption is "processing goes okay but the domain definition is wrong"
An incorrectly implemented domain means that boundaries, hence the control flow predicates are wrong
Various bugs can cause domain errors. A few Domain errors are:
Double Zero Representation: In computers or languages with a distinct positive and negative zero, boundary errors for negative zero are common
Floating Point Zero Check: A floating point number can be a zero, only if the previous definition of that number is either set to zero, subtracted from it self, or multiplied by zero. Hence, the check must be done against an epsilon value
Contradictory Domains
A specified domain can be ambiguous or contradictory but not implemented domain
If atleast two supposedly distinct domains overlap then it is a contradictory domain specification
Ambiguous Domains:
Ambiguous domains means that union of the domains is incomplete i.e., there are missing domains or holes in the specified domains
Not specifying what happens to points on the domain boundary is a common ambiguity
Over Specified Domains:
The domain can be overloaded with so many contradictions that the result is a null domain
another way to put it is to say that the domains path is unachievable
Boundary Errors:
Errors caused in and around the boundary of a domain
Example: Boundary closure bug, shifted, titled, missing and extra boundary
Closure Reversal:
A common bug. The predicate is defined in terms of ">="
The programmer chooses to implement the logical complement and incorrectly uses "<=" for the new predicate; i.e., "x >= 0" is incorrectly negated as "x<=0" , thereby shifting boundary values to adjacent domains
Faulty Logic:
Compound predicates (especially) are subject to faulty logic transformations and improper simplification
If the predicates define domain boundaries, all kinds of domain bugs can result from faulty login manipulations
Restrictions to Domain Testing
Co-incidental Correctness:
Domain testing is not good at finding bugs
if a casual correctness is bothered then an incorrect boundary can be misjudged. Note that it shows the weakness for domain testing when dealing with routines that have binary outcomes (i.e., TRUE/FALSE)
Representative Outcome:
Domain testing is an example of partition testing
The partition testing strategies divide the input space of the program into domains so that all the inputs lying within a domain are equivalent
In the sense that, any input represents all inputs in that domain. If the selected input is shown to be correct by test, then processing is presumed correct, and therefore all inputs within that domain are expected (perhaps unjustifibly) to be correct
Most of the test techniques like functional or structural, comes under partition testing and therefore make this representative outcome assumption
Example: x2 and 2x are equal for x = 2, but the functions are different. The functional differences between adjacent domains are usually simple, such as x + 7 versus x + 9, rather than x2 versus 2x
Simple Domain Boundaries and Compound Predicates:
Compound predicates in which each part of the predicate specifies a different boundary are not a problem
Example: "x >= 0 AND x < 17", just specifies two domain boundaries by one compound predicate
As an example of a compound predicate that specifies one boundary, consider: x = 0 and y >= 7 and Y <= 14
This predicates specifies one boundary equation (x = 0) but alternates closure, putting it in one or the other domain depending on whether y < 7 or y > 14
Treat compound predicates with respect because they are more complicated than they seen
Simple Domain Boundaries and Compound Predicates:
Compound predicates in which each part of the predicate specifies a different boundary are not a problem
Example: "x >= 0 AND x < 17", just specifies two domain boundaries by one compound predicate
As an example of a compound predicate that specifies one boundary, consider: x = 0 and y >= 7 and Y <= 14
This predicates specifies one boundary equation (x = 0) but alternates closure, putting it in one or the other domain depending on whether y < 7 or y > 14
Treat compound predicates with respect because they are more complicated than they seen
Functional Homogeneity of Bugs:
Any bug will not change the functional form of the boundary predicate
Example: If the predicate is ax >= b, the bug will be in the value of a or b but it will not change the predicate to ax >= b
Linear Vector Space:
Most papers on domain testing assume linear boundaries. This assumption is not a bad one as most boundary predicates are practically linear.
Loop Free Software:
Loops are problematic for domain testing as every iteration might give different predicate expression (after interpretation), which indicates possible change in the domain boundary.
Post a Comment
Post a Comment