DATA FLOW TESTING

Data Flow Testing

Data Flow Testing is a type of structural testing . A method is used to find the test paths of a program
according to the locations of definitions and uses of variables in the program. It has nothing to do with data
flow diagrams. Furthermore, it is concerned with:
 Statements where variables receive values,
 Statements where these values are used or referenced.
Data Flow Testing uses the control flow graph to find the situations that can interrupt the flow of the
program. Reference or defined anomalies in the flow of the data are detected at the time of associations
between values and variables. These anomalies are:
 A variable is defined but not used or referenced,
 A variable is used but never defined,
 A variable is defined twice before it is used
STRATEGIES OF DATA FLOW TESTING:
INTRODUCTION:
o Data Flow Testing Strategies are structural strategies.
o In contrast to the path-testing strategies, data-flow strategies take into account what happens to data objects
on the links in addition to the raw connectivity of the graph.
o In other words, data flow strategies require data-flow link weights (d,k,u,c,p).
o Data Flow Testing Strategies are based on selecting test path segments (also called sub paths) that satisfy
some characteristic of data flows for all data objects.
o For example, all sub paths that contain a d (or u, k, du, dk).
o A strategy X is stronger than another strategy Y if all test cases produced under Y are included in those
produced under X - conversely for weaker.
TERMINOLOGY:
1. Definition-Clear Path Segment, with respect to variable X, is a connected sequence of links such that X is
(possibly) defined on the first link and not redefined or killed on any subsequent link of that path segment. II
paths in Figure 3.9 are definition clear because variables X and Y are defined only on the first link (1,3) and
not thereafter. In Figure 3.10, we have a more complicated situation. The following path segments are
definition-clear: (1,3,4), (1,3,5), (5,6,7,4), (7,8,9,6,7), (7,8,9,10), (7,8,10), (7,8,10,11). Subpath (1,3,4,5) is not
definition-clear because the variable is defined on (1,3) and again on (4,5). For practice, try finding all the
definition-clear subpaths for this routine (i.e., for all variables).
2. Loop-Free Path Segment is a path segment for which every node in it is visited at most once. For Example,
path (4,5,6,7,8,10) in Figure 3.10 is loop free, but path (10,11,4,5,6,7,8,10,11,12) is not because nodes 10 and
11 are each visited twice.
3. Simple path segment is a path segment in which at most one node is visited twice. For example, in Figure
3.10, (7,4,5,6,7) is a simple path segment. A simple path segment is either loop-free or if there is a loop, only
one node is involved.
4. A du path from node i to k is a path segment such that if the last link has a computational use of X, then the
path is simple and definition-clear; if the penultimate (last but one) node is j - that is, the path is
(i,p,q,...,r,s,t,j,k) and link (j,k) has a predicate use - then the path from i to j is both loop-free and definition-
clear.
STRATEGIES:
The structural test strategies discussed below are based on the program's control flow graph. They
differ in the extent to which predicate uses and/or computational uses of variables are included in the test set.
Various types of data flow testing strategies in decreasing order of their effectiveness are:
1. All - du Paths (ADUP): The all-du-paths (ADUP) strategy is the strongest data-flow testing strategy
discussed here. It requires that every du path from every definition of every variable to every some test.
For variable X and Y: In Figure 3.9, because variables X and Y are used only on link (1,3), any test
that starts at the entry satisfies this criterion (for variables X and Y, but not for all variables as required by the
strategy).
For variable Z: The situation for variable Z (Figure 3.10) is more complicated because the variable is
redefined in many places. For the definition on link (1,3) we must exercise paths that include subpaths (1,3,4)
and (1,3,5). The definition on link (4,5) is covered by any path that includes (5,6), such as sub path
(1,3,4,5,6, ...). The (5,6) definition requires paths that include sub paths (5,6,7,4) and (5,6,7,8).
For variable V: Variable V (Figure 3.11) is defined only once on link (1,3). Because V has a predicate
use at node 12 and the subsequent path to the end must be forced for both directions at node 12, the all-du-
paths strategy for this variable requires that we exercise 17 all loop-free entry/exit paths and at least one path
that includes the loop caused by (11,4).
Note that we must test paths that include both sub paths (3,4,5) and (3,5) even though neither of these
has V definitions. They must be included because they provide alternate du paths to the V use on link (5,6).
Although (7,4) is not used in the test set for variable V, it will be included in the test set that covers the
predicate uses of array variable V() and U.
The all-du-paths strategy is a strong criterion, but it does not take as many tests as it might seem at first
because any one test simultaneously satisfies the criterion for several definitions and uses of several different
variables.
2. All Uses Strategy (AU):
The all uses strategy is that at least one definition clear path from every definition of every variable to
every use of that definition be exercised under some test.
Just as we reduced our ambitions by stepping down from all paths (P) to branch coverage (C2), say, we
can reduce the number of test cases by asking that the test set should include at least one path segment from
every definition to every use that can be reached by that definition.
For variable V: In Figure 3.11, ADUP requires that we include sub paths (3,4,5) and (3,5) in some
test because subsequent uses of V, such as on link (5,6), can be reached by either alternative. In AU either
(3,4,5) or (3,5) can be used to start paths, but we don't have to use both. Similarly, we can skip the (8,10) link if
we've included the (8,9,10) sub path.
Note the hole. We must include (8,9,10) in some test cases because that's the only way to reach the c
use at link (9,10) - but suppose our bug for variable V is on link (8,10) after all? Find a covering set of paths
under AU for Figure 3.11.
3. All p-uses/some c-uses strategy (APU+C) :
For every variable and every definition of that variable, include at least one definition free path from
the definition to every predicate use; if there are definitions of the variables that are not covered by the above
prescription, then add computational use test cases as required to cover every definition.
For variable Z: In Figure 3.10, for APU+C we can select paths that all take the upper link (12,13) and
therefore we do not cover the c-use of Z: but that's okay according to the strategy's definition because every
definition is covered. Links (1,3), (4,5), (5,6), and (7,8) must be included because they contain definitions for
variable Z. Links (3,4), (3,5), (8,9), (8,10), (9,6), and (9,10) must be included because they contain predicate
uses of Z. Find a covering set of test cases under APU+C for all variables in this example - it only takes two
tests.
For variable V:In Figure 3.11, APU+C is achieved for V by
(1,3,5,6,7,8,10,11,4,5,6,7,8,10,11,12[upper], 13,2) and (1,3,5,6,7,8,10,11,12[lower], 13,2). Note that the c-use
at (9,10) need not be included under the APU+C criterion.
4. All c-uses/some p-uses strategy (ACU+P) :
The all c-uses/some p-uses strategy (ACU+P) is to first ensure coverage by computational use cases
and if any definition is not covered by the previously selected paths, add such predicate use cases as are needed
to assure that every definition is included in some test.
For variable Z: In Figure 3.10, ACU+P coverage is achieved for Z by path (1,3,4,5,6,7,8,10,
11,12,13[lower], 2), but the predicate uses of several definitions are not covered. Specifically, the (1,3)
definition is not covered for the (3,5) p-use, the (7,8) definition is not covered for the (8,9), (9,6) and (9, 10) p-
uses.
The above examples imply that APU+C is stronger than branch coverage but ACU+P may be weaker
than, or incomparable to, branch coverage.
5. All Definitions Strategy (AD):
The all definitions strategy asks only every definition of every variable be covered by at least one use
of that variable, be that use a computational use or a predicate use.
For variable Z: Path (1,3,4,5,6,7,8, . . .) satisfies this criterion for variable Z, whereas any entry/exit
path satisfies it for variable V. From the definition of this strategy we would expect it to be weaker than both
ACU+P and APU+C.
6. All Predicate Uses (APU), All Computational Uses (ACU) Strategies :
The all predicate uses strategy is derived from APU+C strategy by dropping the requirement that we
include a c- use for the variable if there are no p-uses for the variable. The all computational uses strategy is
derived from ACU+P strategy by dropping the requirement that we include a p-use for the variable if there are
no c-uses for the variable. It is intuitively obvious that ACU should be weaker than ACU+P and that APU
should be weaker than APU+C.
ORDERING THE STRATEGIES:
Figure 3.12compares path-flow and data-flow testing strategies. The arrows denote that the strategy at
the arrow's tail is stronger than the strategy at the arrow's head.
 o The right-hand side of this graph, along the path from "all paths" to "all statements" is the more
interesting hierarchy for practical applications.
o Note that although ACU+P is stronger than ACU, both are incomparable to the predicate-biased
strategies. Note also that "all definitions" is not comparable to ACU or APU.
SLICING AND DICING:
o A (static) program slice is a part of a program (e.g., a selected set of statements) defined with respect to a
given variable X (where X is a simple variable or a data vector) and a statement i: it is the set of all statements
that could (potentially, under static analysis) affect the value of X at statement i - where the influence of a
faulty statement could result from an improper computational use or predicate use of some other variables at
prior statements. o If X is incorrect at statement i, it follows that the bug must be in the program slice for X
with respect to i
o A program dice is a part of a slice in which all statements which are known to be correct have been
removed. o In other words, a dice is obtained from a slice by incorporating information obtained through
testing or experiment (e.g., debugging).
o The debugger first limits her scope to those prior statements that could have caused the faulty value at
statement i (the slice) and then eliminates from further consideration those statements that testing has shown to
be correct.
o Debugging can be modeled as an iterative procedure in which slices are further refined by dicing,
where the dicing information is obtained from ad hoc tests aimed primarily at eliminating possibilities.
Debugging ends when the dice has been reduced to the one faulty statement.
o Dynamic slicing is a refinement of static slicing in which only statements on achievable paths to the
statement in question are included.
Advantages of Data Flow Testing:
 Data Flow Testing is used to find the following issues-
 To find a variable that is used but never defined,
 To find a variable that is defined but never used,
 To find a variable that is defined multiple times before it is use,
 Deallocating a variable before it is used.
Disadvantages of Data Flow Testing
 Time consuming and costly process
 Requires knowledge of programming languages
Example:
1. read x, y;
2. if(x>y)
3. a = x+1
 else
4. a = y-1
5. print a;
Control flow graph of above example:

Domain Testing :
It is a software testing technique where minimum numbers of inputs are used to access appropriate output of a
system, to ensure the system does not accept invalid input values. The system is expected to give required
outputs blocking the invalid inputs. If you’re looking to enhance your skills in domain testing and other
essential testing techniques, consider enrolling in this comprehensive software testing course. This course
offers in-depth knowledge and practical tools to improve your ability to identify and address software defects
efficiently.
Importance of Domain Testing
 Protection of Input Space: A software application’s complete input area should be sufficiently covered,
and domain testing helps to verify this. It seeks to identify possible problems with data handling and
processing by testing particular domains or ranges of input values.
 Error detection: It works well for identifying mistakes or irregularities that could happen in particular
input domains. Through the focus of testing efforts on pertinent subsets, domain testing can identify
issues that may be missed in more general, random testing situations.
 Preventing Bugs: Software can be designed with fewer vulnerabilities and critical situations if
developers have a better understanding of the properties and limits of input domains. By taking a
proactive approach to input domain consideration, issues may be avoided before
  they even arise.
 Enhanced Efficiency of Tests: Domain testing aids in organizing testing efforts according to the
software’s most important and pertinent sections. Because more resources are allocated to testing
scenarios that are more likely to uncover significant faults, test effectiveness is raised as a result.
Structure of Domain Testing

 The process is quite similar everywhere when it comes to building the strategy, where the following
step-by-structure is used that suits most of the scenarios:
 Determine the Domain: To comprehend the needs and requirements of the system, the testing team first
works with stakeholders. They establish the precise domain or set of circumstances that the software is
supposed to function in by doing this.
 Split the Domain: After the domain has been located, it is split up into more manageable sections. The
different sets of inputs, states or situations that the software will experience while operating are
represented by these divisions. This stage guarantees thorough coverage and aids in organizing the
testing effort.
 Choose Test Cases: The testing team chooses representative test cases based on the divided domains.
With the goal of covering a range of scenarios within each partition, these test cases offer a
comprehensive analysis of the behavior of the software under diverse circumstances.
 Design Test Data: Within each partition, test data is created to mimic real-world situations. This entails
selecting values, such as boundary values and potentially error-prone inputs, that are likely to be
encountered during actual usage.
 Run Test Cases: The provided test data is used to run the chosen test cases. The testing team watches
how the software behaves during this phase and contrasts it with the outcomes that are anticipated
based on the requirements and specifications.
 Boundary Value Analysis: Testing at the input domain’s boundaries receives particular attention.
Given that errors frequently arise in these extreme circumstances, this also requires checking values at
each partition’s lower and higher borders.
 Error Handling: Within the specified domain, the testing team confirms how the programmed handles
erroneous or unexpected input. It involves making that the programme handles exceptions gracefully
and doesn’t crash, as well as looking for the proper error messages.
 Automation: Depending on the situation, the domain’s complicated or repetitive scenarios may benefit
from automation. In particular, automated testing methods can be used in situations when manual
testing might not be feasible to improve efficiency, repeatability, and coverage.
Domain Knowledge
Domain knowledge is a good understanding of a particular sphere i.e., a person is acquainted
with a particular term or discipline. It helps to minimize the delivery cycle, improve customer
service reduce development time.
Is Domain knowledge required for Domain testing?
It is difficult for someone to perform effectively in a field where the person is not familiar. So a domain tester
should have basic domain knowledge. It is important because:
Online banking- A tester must have to be an expert in online banking activities like login, bill payment, and
transfers.
Retail domains- To successfully run a domain test, the tester has to recognize how things work flow at
different levels. Some examples of retail domains are warehouse management, in-store solutions, etc.
Healthcare- A tester with a proper understanding of domain knowledge should handle a healthcare system. It
is a huge risk to someone’s life when someone with zero knowledge handles the system.
A real-life example of Domain testing
Let there be a group of students on a study tour. For entertainment purposes, they have been given a
ticket to perform a specific activity based on gender and age inputs. Here the entertainment facility acts as the
test, age groups will be boundary values with numerous possible scenarios. Students perform activities in the
following manner:
 Children less than 5 years old are to tell a poem
 Boys 5>=10 are to draw
 Girls 5>=10 are to sing a song
 Boys >10 are to compete in a sport
 Girls >10 are to participate in the quiz
 The remaining children >15 are to participate in an essay competition
Based on the given algorithm, the specialist groups the values into classes i.e., age groups, and then
boundary values are picked i.e., highest and lowest age values in a group. Then different scenarios are built
with expected results for each.

Advantages of Domain Testing

 Effective Utilization of Testing Materials: Domain testing ensures that testing resources are used
efficiently by enabling focused testing on particular ranges or domains. With this focused approach,
important software domains are prioritized.
  Boosts Test Coverage: Domain testing improves test coverage by testing a broad range of variables
inside a domain. This is crucial to guaranteeing thorough testing of the software,particularly in regions
where problems are more likely to occur.
 Enhances the Quality of Software: Better software quality is a result of finding and resolving edge case
problems. Domain testing contributes to the development of more durable and dependable software by
addressing weaknesses in important scenarios.
 Cost-Effective Testing Technique: As domain testing concentrates on particular input ranges and
utilizes fewer resources than comprehensive testing, it is thought to be more cost effective. This makes
it a useful method for identifying important problems within certain fields.
Disadvantages of Domain Testing
 False Sense of Security: Supposing domain testing alone is sufficient could give an illusion of security.
Although it works well in certain areas, it might miss problems outside thoselimits, which could result
in mistakes.
 Difficult to Determine Domain Boundaries: Establishing precise domain boundaries can be difficult. A
complete understanding of the system is necessary to determine the boundaries of input domains, and
inaccurate boundary definitions could result in insufficient testing.
 Might Miss Complex Problems: Domain testing might not be appropriate for detecting intricate
problems involving the interplay of various variables or system components. In such cases, advanced
testing methods might be needed.
 Not Fit for Every System: Domain testing alone might not be sufficient to test certain systems,
especially those with complicated input and output parameters or those requiring more advanced testing
methods.
 UNIT –III
DOMAIN TESTING
(1) Domains and paths:
(i) The Model:
 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 is applied to one input variable or to simple combinations of two variables,
based on specifications.
 The schematic representation of Domain testing is given below.

INPUT CLASSIFY DO CASE 1 OUTPUT

DO CASE 2

DO CASE 3

DO CASE n

 First the different input variables are provided to a program.

 The classifier receives all input variables and divides them into different cases.
 Every case there should be at least one path to process that specified case.
 Finally output is received from this do cases..
(ii) A domain is a set:
 An input domain is a set. If the source language supports set definitions less testing is
needed because the compiler (compile-time and run-time) do much of it for us.
(iii) 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 (implementation), then predicate interpretation must
be based on control flowgraph.
 If domain testing is applied to specifications, then predicate interpretation is based on data
flowgraph.
 For every domain there is at least one path through the routine.
 There may be more than one path if the domain consists of disconnected parts.
 Unless stated otherwise, we’ll assume that domains consist of a single, connected part.
 We’ll also assume that the routine has no loops.
 Domains are defined by their boundaries. For every boundary there is at least one
predicate.
 For example in the statement, IF X > 0 THEN ALPHA ELSE BETA we know that number
greater than zero, belong to ALPHA, number smaller to zero, belong to BETA.
Page 1

1
Review:
1. A domain is a loop free program.
2. For every domain there is at least one path through the routine.
3. The set of interpreted predicates defines the domain boundaries.
(iv) Domain Closure:
 To understand the domain closure, consider the following figure.

MIN MAX
D1 D2 D3

(a) Both side closed

MIN MAX
D1 D2 D3

(b) One side open

MIN MAX
D1 D2 D3

(c) Both side open

 If the domain boundary point belongs to the same domain then the boundary is said to
close. If the domain boundary point belongs to some other domain then the boundary is
said to open.
 In the above figure there are three domains D1, D2, D3.
 In figure a D2’s boundaries are closed both at the minimum and maximum values. If D2 is
closed, then the adjacent domains D1 and D3 must be open.
 In figure b D2 is closed on the minimum side and open on the maximum side, meaning
that D1 is open and D3 is closed. In figure c D2 is open on both sides, which mean that the
adjacent domains D1 and D3 must be closed.
(v) Domain Dimensionality:
 Depending on the input variables, the domains can be classified as number line domains,
planer domains or solid domains.
 That is for one input variable the value of the domain is on the number line, for two
variables the resultant is planer and for three variables the domain is solid.
 One important thing here is to note that we need not worry about the domains
dimensionality with the number of predicates. Because there might be one or more
boundary predicates.
(vi) The Bug Assumptions:
 The bug assumption for domain testing is that processing is okay but the domain definition
is wrong.
 An incorrectly implemented domain means that boundaries are wrong, which mean that
control-flow predicates are wrong.
 The following are some of the bugs that give to domain errors.
(a) Double-Zero Representation:
 Boundary errors for negative zero occur frequently in computers or programming
languages where positive and negative zeros are treated differently.
Page 2

2
 (b) Floating-Point Zero Check:
 A floating-point number can equal to zero only if the previous definition of that number is
set it to zero or if it is subtracted from itself, multiplied by zero.
 Floating-point zero checks should always be done about a small interval.
(c) Contradictory Domains:
 Here at least two assumed distinct domains overlap.
(d) Ambiguous Domains:
 These are missing domain, incomplete domain.
(e) Over specified Domains:
 The domain can be overloaded with so many conditions.
(f) Boundary Errors:
 This error occurs when the boundary is shifted or when the boundary is tilted or missed.
(g) Closure Reversal
 This bug occurs when we have selected the wrong predicate such as x>=0 is written as
x<=0.
(h) Faulty Logic:
 This bug occurs when there are incorrect manipulations, calculations or simplifications
in a domain.
(vii) Restrictions:
(a) General
 Domain testing has restrictions. i.e. we cannot use domain testing if they are violated.
 In testing there is no invalid test, only unproductive test.
(b) Coincidental Correctness
 Coincidental correctness is assumed not to occur.
 Domain testing is not good for which outcome is correct for the wrong reason.
 One important point to be noted here is that, domain testing does not support Boolean
outcomes (TRUE/FALSE).
 If suppose the outputs are some discrete values, then there are some chances of
coincidental correctness.
(c) Representative Outcome
 Domain testing is an example of partition testing.
 Partition testing divide the program’s input space into domains.
 If the selected input is shown to be correct by a test, then processing is correct, and
inputs within that domain are expected to be correct.
 Most test techniques, functional or structural fall under partition testing and therefore
make this representative outcome assumption.
(d) Simple Domain Boundaries and Compound Predicates
 Each boundary is defined by a simple predicate rather than by a compound predicate.
 Compound predicates in which each part of the predicate specifies a different boundary
are not a problem: for example, x >= 0 .AND. x < 17, just specifies two domain
boundaries by one compound predicate.
(e) Functional Homogeneity of Bugs
 Whatever the bug is, it will not change the functional form of the boundary predicate.
(f) Linear Vector Space
 A linear predicate is defined by a linear inequality using only the simple relational
operators >, >=, =, <=, <>, and <.
 Example x2 + y2 > a2.
(g) Loop-free Software
 Loops (indefinite loops) are problematic for domain testing.
Page 3

3
  If a loop is an overall control loop on transactions, say, there’s no problem.
 If the loop is definite, then domain testing may be useful for the processing within the
loop, and loop testing can be applied to the looping values.
(2) Nice Domains:
(i) Where Do Domains Come From?
 Domains are often created by salesmen or politicians.
 The first step in applying domain testing is to get consistent and complete domain
specifications.
(ii) Specified versus Implemented Domains:
 Implemented domains can’t be incomplete or inconsistent but specified domains can be
incomplete or inconsistent.
 Incomplete means that there are input vectors for which no path is specified and
inconsistent means that there are at least two contradictory specifications.
(iii) Nice Domains:
(1) General
 The representation of Nice two-dimensional domains is as follows. .
U1 U2 U3 U4 U5

V1 D11 D12 D13 D14 D15

V2 D21 D22 D23 D24 D25

V3 D31 D33 D34 D35

D32

 The U and V represent boundary sets and D represents domains.

 The boundaries have several important properties. They are linear, complete,
systematic, orthogonal, consistently closed, simply connected and convex.
 If domains have these properties, domain testing is very easy otherwise domain testing
is tough.
(2) Linear and Nonlinear Boundaries
 Nice domain boundaries are defined by linear inequalities or equations.
 The effect on testing comes from only two points then it represents a straight line.
 If it considers three points then it represents a plane and in general it considers n + 1
points then it represents an n-dimensional hyperplane.
 Linear boundaries are more frequently used than the non-linear boundaries.
 We can linearize the non-linear boundaries by using simple transformations.
(3) Complete Boundaries
 Complete boundaries are those boundaries which do not have any gap between them.
 Nice domain boundaries are complete boundaries because they cover from plus infinity
to minus infinity in all dimensions.
 Incomplete boundaries are those boundaries which consist of some gaps between them
and are not covered in all dimensions.
 The following figure represents some incomplete boundaries.
Page 4

4
 E A

A
B B
C
C
D
E
 The Boundaries A and E have gaps so they are incomplete & the boundaries B, C, D
are complete.
 The main advantage of a complete boundary is that it requires only one set of tests to
verify the boundary
(4) Systematic Boundaries
 Systematic boundaries refer to boundary inequalities with simple mathematical
functions such as a constant.
 Consider the following relations,
f1(X) >= k1 or f1(X) >= g(1,c)
f2(X) >= k2 f2(X) >= g(2,c)
................ ................
fi(X) >= ki fi(X) >= g(i,c)
 Where fi is an arbitrary linear function, X is the input vector, ki and c are constants,
and g(i,c) is a decent function that yields a constant, such as k + ic.
(5) Orthogonal Boundaries
 The U and V boundary sets in Nice two-dimensional domains figure are orthogonal; that
is, the every boundary V is perpendicular to every other boundary U.
 If two boundary sets are orthogonal, then they can be tested independently.
 If we want to tilt the above orthogonal boundary we can do it by testing its intersection
points but this can change the linear growth, O(n) into the quadratic growth O(n 2).
 If we tilt the boundaries to get the following figure then we must test the intersections.

(6) Closure Consistency

 Consistent closures are the most simple and fundamental closure.
 It gives consistent and systematic results.
 The following figure shows the boundary closures are consistent.
Page 5

5
 y = k1 + bx

y = k2 + bx

y = k3 + bx

x = A1 x = A2 x = A3 x = A4 x = A5
 In the above figure, the shading lines show one boundary and thick lines show other
boundary.
 It shows Non orthogonal domain boundaries, which mean that every inequality in
domain x is not perpendicular to every inequality in domain y.
(7) Convex
 A figure is said to be convex when for any two boundaries, with two points placed on
them are combined by using a single line then all the points on that line are within the
range of the same figure.
 Nice domains support convex property, where as dirty domains don’t.
(8) Simply Connected
 Nice domains are usually simply connected because they are available at one place as
a whole but not dispersed in other domains..
 Simple connectivity is a weaker requirement than convexity; if a domain is convex it is
simply connected, but not vice versa.
(iv) Ugly Domains:
(a) General
 Some domains are born ugly. Some domains are bad specifications.
 So every simplification of ugly domains by programmers can be either good or bad.
 If the ugliness results from bad specifications and the programmer’s simplification is
harmless, then the programmer has made ugly good.
 But if the domain’s complexity is essential such simplifications gives bugs.
(b) Nonlinear Boundaries
 Non linear boundaries are rare in ordinary programming, because there is no
information on how programmers correct such boundaries.
 So if a domain boundary is non linear, then programmers make it linear.
(c) Ambiguities and Contradictions:.

(a) Ambiguities

(c) Overlapped Domains

Hole B

(d) Contradiction:
Dual Closure (b) Ambiguity:
Missing Boundary
Page 6

6
  Domain ambiguity is missing or incomplete domain boundary.
 In the above figure Domain ambiguities are holes in the A domain and missing
boundary in the B domain.
 An ambiguity for one variable can be see easy.
 An ambiguity for two variables can be difficult to spot.
 An ambiguity for three or more variables impossible to spot. Hence tools are required.
 Overlapping domains and overlapping domain closure is called contradiction.
 There are two types of contradictions are possible here.
(1) Overlapped domain specifications
(2) Overlapped closure specifications.
 In the above figure there is overlapped domain and there is dual closure contradiction.
This is actually a special kind of overlap.
(d) Simplifying the Topology
 Connecting disconnected boundary segments and extending boundaries is called
simplifying the topology
 There are three generic cases of simplifying the topology.

(a) Making it convex

(b) Filling in the Holes

(c) Joining the Pieces

 Programmers introduce bugs and testers misdesign test cases by, smoothing out
concavities, filling in holes, joining disconnected pieces.
(e) Rectifying Boundary Closures
 Different boundaries in different directions can obtain in consistent direction is called
rectifying boundary closures.
 That is domain boundaries which are different directions can obtain in one direction.

(a) Consistent Direction

Page 7

7
 (b) Inclusion/Exclusion Consistency
 In the above figure the hyper plane boundary is outside that can obtain inside. This is
called inclusion / exclusion consistency.
(3) Domain Testing:
(i) Overview:
 Domains are defined by their boundaries. So domain testing concentrates test points on
boundaries or near boundaries.
 Find what wrong with boundaries, and then define a test strategy.
 Because every boundary uses at least two different domains, test points used to check one
domain can also be used to check adjacent domains.
 Run the tests, and determine if any boundaries are faulty.
 Run enough tests to verify every boundary of every domain.
(ii) Domain Bugs and How to Test for Them:
(a) General:
EXTREME POINT

BOUNDARY POINT

INTERIOR POINT

EPSILON NEIGHBORHOOD
 An interior point is a point in a domain. It can be defined as a point which specifies
certain distance covered by some other points in the same domain.
 This distance is known as epsilon neighborhood.
 A boundary point is on the boundary that is a point with in a specific epsilon
neighborhood.
 An extreme point is a point that does not lie between any other two points.
ON POINTS

OFF POINTS

 An on point is a point on the boundary. An off point is outside the boundary.

 If the domain boundary is closed, an off point is a point near the boundary but in the
adjacent domain.
Page 8

8
 If the domain boundary is open, an off point is a point near the boundary but in the
same domain.
 Here we have to remember CLOSED OFF OUTSIDE, OPEN OFF INSIDE
 i.e. COOOOI
 The following figure shows a generic domain ways.

EXTRA BOUNDARY
SHIFTED BOUNDARIES

TILTED BOUNDARIES MISSING BOUNDARY

CORRECT
INCORRECT
OPEN / CLOSE ERROR

(b) Testing One-Dimensional Domains:

 The following figure shows one dimensional domain bugs for open boundaries.
B A

a) An Open Domain (A)

X
B A

b) Closure bug

X
B A

c) Boundary shifted left

X
B A

c) Boundary shifted right

X
B

e) Missing Boundary

X X
B A C

f) Extra Boundary

Page 9

9
 In the above figure a) we assume that the boundary was to open for A.
 In figure b) one test point (marked X) on the boundary detects the bug.
 In figure c) a boundary shifts to left.
 In figure d) a boundary shifts to right.
 In figure e) there is a missing boundary. In figure f) there is an extra boundary.
 The following figure shows one dimensional domain bugs for closed boundaries.
B A

a) A closed Domain (A)

X
B A

b) Closure bug

X
B A

c) Boundary shifted left

X
B A

c) Boundary shifted right

X
B

e) Missing Boundary

X X
B A C

f) Extra Boundary

 In the above figure a) we assume that the boundary was to close for A.
 In figure b) one test point (marked X) on the boundary detects the bug.
 In figure c) a boundary shifts to left. In figure d) a boundary shifts to right.
 In figure e) there is a missing boundary. In figure f) there is an extra boundary.
 Only one difference from this diagram to previous diagram is here we have closed
boundaries.
(c) Testing Two-Dimensional Domains:
 The following figure shows domain boundary bugs for two dimensional domains.
 A and B are adjacent domains, and the boundary is closed with respect to A and the
boundary is opened with respect to B.
(i) Closure Bug:
 The figure (a) shows a wrong closure, that is caused by using a wrong operator for
example, x>=k was used when x > k was intended.
 The two on points detect this bug.
(ii) Shifted Boundary:
 In figure (b) the bug is shifted up, which converts part of domain B into A’.
 This is caused by incorrect constant in a predicate for example x + y >= 17 was used
when x + y > = 7 was intended. Similarly figure (c) shows a shift down.
Page 10

10
 B

X A X
(a) Closure Bug

X
A'

X A X
(b) Shifted Up

X
X B X

B'

A
(c) Shifted Down

A'
X

X A X
B'

(d) Tilted Boundary

A'
X

X A X
B'
(e) Extra Boundary

B
X

X A X

(f) Missing Boundary

Page 11

11
 (iii) Tilted boundary:
 A tilted boundary occurs, when coefficients in the boundary inequality are wrong.
 For example we used 3x + 7y > 17 when 7x + 3y > 17 is needed.
 Figure (d) shows a tilted boundary which creates domain segments A’ and B’.
(iv) Extra Boundary:
 An extra boundary is created by an extra predicate.
 Figure (e) shows an extra boundary. The extra boundary is caught by two on points.
(v) Missing Boundary:
 A missing boundary is created by leaving out the predicate.
 A missing boundary shown in figure (f) is caught by two on points.
 The following figure summarizes domain testing for two dimensional domains.

 There are two on points (closed circles) for each segment and one off point (open circle)
 Note that the selected test points are shared with adjacent domains.
 The on points for two adjacent boundary segments can also be shared.
 The shared on points is given below.

(d) Equality and Inequality Predicates:

 Equality predicates are defined by equality equation such as x + y =12.
 Equality predicates supports only few domain boundaries

A a

c c'
C
d

B
b

 Inequality predicates are defined by inequality equation such as x + y > 12 or x + y <12

 Inequality predicates supports most of the domain boundaries.
 In domain testing, equality predicate of one dimension is a line.
 Similarly equality of two dimensions is a two dimensional domain and equality of three
dimensions is a planer domain.
Page 12

12
  Inequality predicates test points are obtained by taking adjacent domains into
consideration.
 In the above figure the three domains A, B, C are planer. The domain C is a line.
 Here domain testing is done by two on points & two off points.
 That is test point b for B, and test point a for A and test points c and c’ for C.
(e) Random Testing:
 Random testing is a form of functional testing that is useful when the time needed to
write and run directed tests are too long.
 One of the big issues of random testing is to know when a test fails.
 When doing random testing we must ensure that they cover the specification.
 The random testing is less efficient than direct testing. But we need random test
generators.
(f) Testing n-Dimensional Domains:
 If domains defined over n-dimensional input space with p-boundary segments then the
domain testing gives testing n-dimensional domains.
(iii) Procedure:
 Generally domain testing can be done by hand for two dimensions.
 Without tools the strategy is practically impossible for more than two variables.
1. Identify the input variables.
2. Identify variables which appear in domain predicates.
3. Interpret all domain predicates in terms of input variables.
4. For p binary predicates there are 2 p domains.
5. Solve the inequalities to find all the extreme points of each domain.
6. Use the extreme points to solve for near by on points.
(iv) Variations, Tools, Effectiveness:
 Variations can vary the number of on and off points or the extreme points.
 The basic domain testing strategy discussed here is called the N X 1 strategy, because it
uses N on points and one off point.
 In cost effectiveness of domain testing they use partition analysis, which includes domain
testing, computation verification and both structural and functional information.
 Some specification tools are used in domain testing.
(4) Domains and Interface Testing:
(i) General:
 The domain testing plays a very important role in integration testing. In integration testing
we can find the interfaces of different components.
 We can determine whether the components are accurate or not.
(ii) Domains and Range:
 Domains are the input values used. Range is just opposite of domains.
 i.e. Range is output obtained.
 In most testing techniques, more forces on the input values.
 This is because with the help of input values it will be easy to identify the output.
 But interface testing gives more forces on the output values.
 An interface test consists of exploring the correctness of the following mappings.

Caller domain Caller range

Caller range Called domain
Called domain Called range
Page 13

13
(iii) Closure Compatibility:
 Assume that the caller’s range and the called domain spans the same numbers say 0 to 17
 The closure compatibility shows the four cases in which the caller’s range closure and the
called’s domain closure can agree.
 The four cases consists of domains that are closed on top (17) & bottom (0), open top &
closed bottom, closed top & open bottom and open top & bottom.
 Here the thick line represents closed and thin line represents open.
caller called open tops open bottoms both bottom
17

0
both closed
 The following figure shows the twelve different ways the caller and the called can disagree
about closure. Not all of them are necessarily bugs.
17

 Here the four cases in which a caller boundary is open and the called is closed are not
buggy.
(iv) Span Compatibility:
 The following figure shows three possibly harmless of span incompatibilities.
 In this figure Caller span is smaller than Called.
9 9 9 9
7 7

3 3
1 1 1 1
 The range of a caller is a sub set of the called domain. That is not necessarily a bug.
 The following figure shows Called is Smaller than Caller.
Page 14

14
 9 9 9 9
7 7

3 3
1 1 1 1
(v) Interface Range/ Domain Compatibility Testing:
 The application of domain testing is also very important for interface testing because it tests
the range and domain compatibilities among caller and called routines.
 It is the responsibility of the caller to provide the valid inputs to the called routine.
 After getting the valid input, the test will be done on every input variable.
(vi) Finding the values:
 Start with the called routine’s domains and generate test points.
 A good component test should have included all the interesting domain-testing cases.
 Those test cases are the values for which we must find the input values of the caller.
(5) Domains and Testability:
(i) General:
 Domain testing gives orthogonal domain boundaries, consistent closure, independent
boundaries, linear boundaries, and other characteristics. We know that which makes
domain testing difficult. That is it consists of applying algebra to the problem.
(ii) Linearizing Transformations:
 This is used to transfer non linear boundaries to equivalent linear boundaries.
 The different methods used here are
(i)Polynomials:
 A boundary is specified by a polynomial or multinomial in several variables.
 For a polynomial each term can be replaced by a new variable.
 i.e. x, x2, x3, …can be replaced by y1 = x, y2 = x2, y3 = x3 , …
 For multinomials you add more new variables for terms such as xy, x 2y, xy2, …
 So polynomial plays an important role in linear transformations.
(ii)Logarithmic Transforms:
 Products such as xyz can be linearized by substituting u = log (x), v = log (y), log (z).
 The original predicate xyz > 17 now becomes u + v + w > 2.83.
(iii)More general forms:
 Apart from logarithmic transform & polynomials there are general linearizable forms
such as x / (a + b) and axb. We can also linearize by using Taylor series.
(iii) Coordinate Transformations:
 The main purpose of coordinate transformation technique is to convert Parallel boundary
inequalities into non parallel boundary inequalities and Non-parallel boundary inequalities
into orthogonal boundary inequalities.
(iv) A Canonical Program Form:
 Testing is clearly divided into testing the predicate and coordinate transformations.
 i.e. testing the individual case selections, testing the control flow and then testing the case
processing..
(v) Great Insights:
 Sometimes programmers have great insights into programming problems that result in
much simpler programs than one might have expected.

Page 15

15