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
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
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 x2 + y2 < 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
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
Post a Comment
Post a Comment