Domains and Range
The set of output values produced by a function is called the range of the function, in contrast with the domain, which is the set of input values over which the function is defined
For many testing strategies employed, the aim is to specify input values and to predict and/or confirm output values with respect to those inputs
In interface testing, it is required that the output values of the calling routine are selected i.e., callers range must be compatible with the called routines domain
An interface test consists of exploring the correctness of the following mappings:
caller domain --> caller range (caller unit test)
caller range --> caller domain (integration test)
called domain -->called range (called unit test)
The set of output values produced by a function is called the range of the function, in contrast with the domain, which is the set of input values over which the function is defined
For many testing strategies employed, the aim is to specify input values and to predict and/or confirm output values with respect to those inputs
In interface testing, it is required that the output values of the calling routine are selected i.e., callers range must be compatible with the called routines domain
An interface test consists of exploring the correctness of the following mappings:
caller domain --> caller range (caller unit test)
caller range --> caller domain (integration test)
called domain -->called range (called unit test)
Closure Compatibility
Assume that the callers range and the called domain spans the same numbers
Example: 0 to 17
Image shows four ways of representing domain/range closure compatibility. All the four images show that the domain closure is compatible
The thick line means closed and the thin line means open. Image shows the four cases consisting of domains that are closed both on top (17) and bottom (0), open top and closed button, closed top and open bottom, and open top and bottom
Assume that the callers range and the called domain spans the same numbers
Example: 0 to 17
Image shows four ways of representing domain/range closure compatibility. All the four images show that the domain closure is compatible
The thick line means closed and the thin line means open. Image shows the four cases consisting of domains that are closed both on top (17) and bottom (0), open top and closed button, closed top and open bottom, and open top and bottom
Here, the twelve cases represent closure incompatibility. Even though the lines match in terms of span, the closures (edges of the lines) are not compatible. Both the lines are not having equal thickness/thinness representing closure incompatibility
Span Compatibility
Three possibly harmless span incompatibilities are shown in image
In image (b) the ranges and domains don't line up, hence good values are rejected, bad values are accepted, and if the called routine isn't robust enough, we have crashes
Image (c) combines these notions to show various ways we can have holes in the domain: these are all probably buggy
In every case, the callers range is a subset of the called domain. This need not be a bug
The routine is used by many callers, some require values inside a range and some don't. This kind of span incompatibility is a bug only if the caller expects the called routine to validate the called number for the caller
Image (a) shows the opposite situation, wherein the span of the called routines domain is smaller than what the caller expect. Such examples are buggy.
Interface Range/Domain Compatibility Testing
For interface testing, bugs are more likely to concern single variables rather than peculiar combinations of two or more variables
Confirm the callers range, the called routines domain span, and closure of every domain defined for a variable, by testing every input variable independently, i.e., independent of other input variables
There are two boundaries to test and its a one dimensional domain, therefore, it requires one on and one off point per boundary or a total of two on points and two off points for the domain pick the off points appropriate to the closure (COOOOI)
Start with the called routines domains and generate test points in accordance to the domain-testing strategy used for that routine in component testing
To do this without tools for more than one variable at a time, you must be very strong in mathematics
Finding the Values
To implement domain testing, start with the called routines domain and generate test points for that routine in component testing
It doesn't matter even if the solution is not unique because any caller input will produce the required output
There may be no solution for specific points
If the callers domain is ugly, the problem can become very difficult
You should find and evaluate an inverse function for the caller
To do this with more than one variable at a time, you won't be able to do it without tools
Span Compatibility
Three possibly harmless span incompatibilities are shown in image
In image (b) the ranges and domains don't line up, hence good values are rejected, bad values are accepted, and if the called routine isn't robust enough, we have crashes
Image (c) combines these notions to show various ways we can have holes in the domain: these are all probably buggy
In every case, the callers range is a subset of the called domain. This need not be a bug
The routine is used by many callers, some require values inside a range and some don't. This kind of span incompatibility is a bug only if the caller expects the called routine to validate the called number for the caller
Image (a) shows the opposite situation, wherein the span of the called routines domain is smaller than what the caller expect. Such examples are buggy.
Interface Range/Domain Compatibility Testing
For interface testing, bugs are more likely to concern single variables rather than peculiar combinations of two or more variables
Confirm the callers range, the called routines domain span, and closure of every domain defined for a variable, by testing every input variable independently, i.e., independent of other input variables
There are two boundaries to test and its a one dimensional domain, therefore, it requires one on and one off point per boundary or a total of two on points and two off points for the domain pick the off points appropriate to the closure (COOOOI)
Start with the called routines domains and generate test points in accordance to the domain-testing strategy used for that routine in component testing
To do this without tools for more than one variable at a time, you must be very strong in mathematics
Finding the Values
To implement domain testing, start with the called routines domain and generate test points for that routine in component testing
It doesn't matter even if the solution is not unique because any caller input will produce the required output
There may be no solution for specific points
If the callers domain is ugly, the problem can become very difficult
You should find and evaluate an inverse function for the caller
To do this with more than one variable at a time, you won't be able to do it without tools
Post a Comment
Post a Comment