Scribd
Upload
3 views

ST-Unit-3

The document discusses domain testing, which involves evaluating input data classifiers to ensure correct classifications based on defined domains. It covers concepts such as domain boundaries, dimensionality, and common bugs associated with incorrect domain definitions. Additionally, it distinguishes between 'nice' and 'ugly' domains, highlighting the characteristics of well-defined domains aimed at user satisfaction.

Uploaded by

rahulroshan807
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

ST-Unit-3

The document discusses domain testing, which involves evaluating input data classifiers to ensure correct classifications based on defined domains. It covers concepts such as domain boundaries, dimensionality, and common bugs associated with incorrect domain definitions. Additionally, it distinguishes between 'nice' and 'ugly' domains, highlighting the characteristics of well-defined domains aimed at user satisfaction.

Uploaded by

rahulroshan807
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

UNIT – III

DOMAIN TESTING

By

Y.INDIRA PRIYADARSHINI
Assistant Professor
Department of CSE

Ravindra College of Engineering for Women


Kurnool – 518452, Andhra Pradesh, India
Contents:
1.Domains and Paths.
2.Nice & Ugly Domains.
3.Domain testing.
4.Domains and Interfaces Testing.
5.Domains and Testability.
1.DOMAINS AND PATHS:
A. INTRODUCTION:
•Domain: In mathematics, domain is a set of possible values of an independent
variable or the variables of a function.
•Programs as input data classifiers: domain testing attempts to determine whether
the classification is or is not correct.
•Domain testing can be based on specifications or equivalent implementation
information.
•For example, you're doing domain testing when you check extreme values of an
input variable.
B. THE MODEL: The following figure is a schematic representation of domain testing.

Figure : Schematic Representation of Domain Testing.


C. A DOMAIN IS A SET:
•An input domain is a set.
•If the source language supports set definitions (E.g. PASCAL set types and C
enumerated types) less testing is needed because the compiler does much of it for
us.
•Domain testing does not work well with arbitrary discrete sets of data objects.
•Domain for a loop-free program corresponds to a set of numbers defined over the
input vector.
D. DOMAINS, PATHS AND PREDICATES:
•In domain testing, predicates are assumed to be interpreted in terms of input vector
variables.
•If domain testing is applied to structure, then predicate interpretation must be
based on actual paths through the routine - that is, based on the implementation
control flow graph.
•For every domain, there is at least one path through the routine.
•Domains are defined their boundaries. Domain boundaries are also where most
domain bugs occur.
•For every boundary there is at least one predicate that specifies what numbers
belong to the domain and what numbers don't.
E. A DOMAIN CLOSURE:
•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.
•Figure, shows three situations for a one-dimensional domain - i.e., a domain
defined over one input variable; call it x
•The importance of domain closure is that incorrect closure bugs are frequent
domain bugs. For example, x >= 0 when x > 0 was intended.
Figure : Open and Closed Domains
F. 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.
•Every new predicate 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.
•Thus, planes are cut by lines and points, volumes by planes, lines and points and
n-spaces by hyper planes.
G. BUG ASSUMPTION:
•The bug assumption for the domain testing is that processing is okay but the
domain definition is wrong.
•An incorrectly implemented domain means that boundaries are wrong, which may
in turn mean that control flow predicates are wrong.
•Many different bugs can result in domain errors. Some of them are:
1.Double Zero Representation
2.Floating point zero check
3.Contradictory domains
4. Ambiguous domains
5.Over specified Domains
6.Boundary Errors
7.Closure Reversal
8.Faulty Logic
H. RESTRICTIONS TO DOMAIN TESTING: Domain testing has restrictions, as do
other testing techniques. Some of them include:
1. Co-incidental Correctness
2. Representative Outcome
3. Simple Domain Boundaries and Compound Predicates
4. Functional Homogeneity of Bugs
5. Linear Vector Space
6. Loop Free Software
2.NICE & UGLY DOMAINS :
NICE Domains:
1.Domains are and will be defined by an imperfect iterative process aimed at
achieving (user, buyer, voter) satisfaction
2.Implemented domains can't be incomplete or inconsistent. Every input will be
processed, possibly forever. Inconsistent domains will be made consistent.
3. Conversely, specified domains can be incomplete and/or inconsistent.
4. Some important properties of nice domains are: Linear, Complete, Systematic,
And Orthogonal, Consistently closed, Convex and simply connected

You might also like