Software Testing Methodologies Dichotomies

Domains and Paths Includes:

The Model:
The schematic representation of domain testing is as shown in the image
A routine must classify the input before doing whatever it does and set it moving on the right path
"reject" is a special processing case if the input is an invalid input (Example: Value too big)
The input then passes to hypothetical subroutine rather than on calculations
Rather than on the calculations, the classification aspect of the routine is focused in domain testing
Structural knowledge is not needed for this model. Only a consistent, complete specification of input values for each case
It is assumed that there must be at least one path for each case to process

A Domain is a Set:
An input domain is a set
If the source language is like PASCAL set types and C enumerated types then it supports set definitions
So, less testing is required as the compiler does much of it
Domain testing does not work well with arbitrary discrete sets of data objects, if the domain contains random and separate values
Domain for a loop-free program corresponds to a set of numbers defined over the input vector
Example: Domain for the variable 'age' corresponds to a set f values from 0 go 100

Domains, Paths and Predicates:

In domain testing, it is assumed that the interpretation of predicates in terms of input vector variables is done

If domain testing is applied to structure, basis for the interpretation of the predicate must be 'actual paths through the routine' i.e. the interpretation is based on the implementation control flow graph

Conversely, if domain testing is applied to specifications, the basis of interpretation for the routine is 'specified data flow graph'. Generally, by the nature of specification, interpretation is not needed as the domains are specified directly

For every domain, there is at least one path through the routine

Multiple paths might exist if

the domain consists of disconnected parts

union of multiple domains is used to define the domain

Domains are defined by their boundaries. Domain boundaries are also where most domain bugs occur

Each and every boundary has at least one predicate specifying the numbers which either belong or don't belong to the domain

Example: In the statement "IF x > 0 THEN ALPHA ELSE BETA", we know that the numbers grater than zero belong to ALPHA processing domain (s) while zero and smaller numbers belong to BETA domain (s)

Irrespective of the number of variables defining the domain, a domain may have one or more boundaries

Example: If the predicate is x² + y² < 16, the domain is the inside of a circle of radius 4 about the origin. Similarly, we could define a spherical domain with one boundary but in three variables

Generally, domains are defined by many boundary segments and thereby many predicates. It implies that the domains boundaries are defined by the set of interpreted predicates traversed on that path. (i.e., the paths predicate expression)

A domain Closure
If the points on the boundary belong to the same domain, a domain boundary with regard to the domain is closed
If the points on the boundary belong to some other domain, then it is said that the boundary is open
The given image shows three situations for a one-dimensional domain, i.e, a domain defined over one input variable 'x'
The importance of domain closure is, 'incorrect closure bugs are frequent domain bugs'
Example: x >= 0 when x > 0 was intended