0% found this document useful (0 votes)
3 views10 pages

Understanding Domain Testing Explained

Domain testing is a technique used to verify the correctness of input data classifications by examining the boundaries of defined domains. It can be applied to both functional and structural testing based on specifications or implementations, and involves understanding the relationships between domains, paths, and predicates. The document also discusses the characteristics of nice and ugly domains, as well as the importance of compatibility between caller and called routines in interface testing.

Uploaded by

arjunreddy125572
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views10 pages

Understanding Domain Testing Explained

Domain testing is a technique used to verify the correctness of input data classifications by examining the boundaries of defined domains. It can be applied to both functional and structural testing based on specifications or implementations, and involves understanding the relationships between domains, paths, and predicates. The document also discusses the characteristics of nice and ugly domains, as well as the importance of compatibility between caller and called routines in interface testing.

Uploaded by

arjunreddy125572
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd

What is Domain Testing? Explain with an example?

 Programs as input data classifiers: domain testing attempts to determi ne


whether the classification is or is not correct.
 Application of domain testing to interfaces and integration, domain design,
software design for testability, and limitations.
Schematic Representation of Domain Testing

 Domain testing can be based on specifications and/or equivalent implementation


information.
 If domain testing is based on specifications, it is a functional test technique;
 if based on implementations, it is a structural technique.
 Domain testing, as practiced, is usually applied to one input variable or to simple
combinations of two variables, based on specification

Domains, Paths, and Predicates


 A Domain Is a Set
 Domains, Paths, and Predicates
 1. A domain for a loop-free program corresponds to a set of numbers defined
over the input vector.
 2. For every domain there is at least one path through the routine, along which
that domain’s processing is done.
 3. The set of interpreted predicates traversed on that path (i.e., the path’s
predicate expression) defines the domain’s boundaries
Closed/open domains

 a domain boundary is closed with respect to a domain if the points on the


boundary belong to the domain.
 If the boundary points belong to some other domain, the boundary is said to be
open
Domain Dimensionality
 Domain Dimensionality
 Every input variable adds one dimension to the domain.
 One variable defines domains on a number line, two variables define planar
domains, three variables define solid domains
The Bug Assumptions
 The Bug Assumptions :The bug assumption for domain testing is that processing
is okay but the domain definition is wrong.
 Contradictory Domains
 Ambiguous Domains
 Over specified Domains
 Boundary Errors
 Closure Reversal
 Faulty Logic
 Double-Zero Representation
NICE DOMAINS AND UGLY DOMAINS
 Nice Domains

Below represents some nice, typical, two-dimensional domains


The boundaries have several important properties discussed below: they are linear,
complete, systematic, orthogonal, consistently closed, simply connected, and convex.

 Linear and Nonlinear Boundaries


 Complete Boundaries

 Systematic Boundaries
f1(X
1(X) >= k1
f1(X
1(X) >= k2
fi(
fi(X) >= ki

 Orthogonal Boundaries
:The U and V boundary sets in Figure 6.3 are orthogonal; that is, every
inequality in V is perpendicular to every inequality in U.

 Closure Consistency :

 Convex :A geometric figure (in any number of dimensions) is convex if you can
take two arbitrary points on any two different boundaries, join them by a line and all
points on that line lie within the figure. Nice domains are convex; dirty domains aren’t

 Simply Connected : Nice domains are simply connected; that is, they are in
one piece rather than pieces all over the place interspersed with other domains. if a
domain is convex it is simply connected, but not vice versa.

Ugly Domains and How Programmers and Testers Treat Them


 Some domains are born ugly and some are uglified by bad specifications
 . Nonlinear Boundaries
 . Ambiguities and Contradictions

.Rectifying Boundary Closures


 Simplifying the Topology

Forcing Closure Consistency


 interior point (Figure 6.10) is a point in the domain such that all points within an
arbitrarily small distance (called an epsilon neighborhood)
neighborhood) are also in the
domain.

 A boundary point is one such that within an epsilon neighborhood there are
points both in the domain and not in the domain.

 An extreme point is a point that does not lie between any two other arbitrary but
distinct points of a (convex) domain.

 An on point is a point on the boundary. If the domain boundary is closed, an off


point is a point near the boundary but in the adjacent domain. If the boundary is open,
an off point is a point near the boundary but in the domain being tested;
Testing ONE-Dimensional Domains

Testing Two-Dimensional Domains

 Figure 6.15 shows domain boundary bugs for two-dimensional domains.


 A and B are adjacent domains and the boundary is closed with respect to A,
which means that it is open with respect to B. We’ll first discuss cases for closed
boundaries
 Closure Bug—Figure
Bug—Figure 6.15a shows a faulty closure, such as might be caused by
using a wrong operator (for example, x >= k when x > k was intended, or vice versa).
The two on points detect this bug because those values will get B rather than A
processing.
 Shifted Boundary—In
Boundary—In Figure 6.15b the bug is a shift up, which converts part of
domain B into A processing, denoted by A’. This result is caused by an incorrect
constant in a predicate, such as x + y >= 17 when x + y >= 7 was intended. The off point
(closed off outside) catches this bug. Figure 6.15c shows a shift down that is caught by
the two on points.
 Tilted Boundary—A
Boundary—A tilted boundary occurs when coefficients in the boundary
inequality are wrong.
 For example, 3x3x + 7y
7y > 17 when 7x
7x + 3y
3y > 17 was intended.
 Figure 6.15d has a tilted boundary, which creates erroneous domain segments A’
and B’. In this example the bug is caught by the left on point.
 Extra Boundary—An
Boundary—An extra boundary is created by an extra predicate. An extra
boundary will slice through many different domains and will therefore cause many test
failures for the same bug.
 Missing Boundary—A
Boundary—A missing boundary is created by leaving a boundary
predicate out. A missing boundary will merge different domains

Explain about DOMAINS AND INTERFACE TESTING ?


 The set of output values produced by a function is called the range of the
function
 The set of input values over which the function is defined is called he Domain
 the caller’s range must be compatible with the called routine’s domain.

An interface test consists of exploring the correctness of the following mappings:

 caller domain → caller range (caller unit test)


 caller range → called domain (integration test)
 called domain → called range (called unit test)
 Another way to put this is to say that the caller’s range is the caller’s notion of the
called routine’s domain

Range/Domain Closure Compatibility


 Assume that the caller’s range and the called domain spans the same numbers
—say, 0 to 17.
 Figure 6.19 shows the four ways in which the caller’s range closure and the
called’s domain closure can agree. I’ve turned the number line on its side. The thick line
means closed and the thin line means open.
 Figure 6.19 shows the four cases consisting of domains that are closed both on
top (17) and bottom (0), open top and closed bottom, closed top and open bottom, and
open top and bottom.

Span Compatibility

 Equal-Span Range/Domain Compatibility Bugs.

 shows the twelve different ways the caller and the called can disagree about
closure. Not all of them are necessarily bugs.

Harmless Range/Domain Span Incompatibility Bug.


 In all cases, the caller’s range is a subset of the called’s domain.

 Called routine’s domain has a smaller span than the caller expects. All of these
examples are buggy

You might also like