Software Testing Methodologies Dichotomies

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: x² and 2^x 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 x² versus 2^x
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.