Software Testing Methodologies

UNIT 2
Transaction, Data Flow and Domain Testing

Presented by:
Dr. B.Rajalingam
Associate Professor & HOD
Department of Artificial Intelligence and Data Science( AI&DS)
St. Martin's Engineering College
 SOFTWARE TESTING METHODOLOGIES

Prerequisites

1. A course on “Software Engineering”

Course Objectives

 To provide knowledge of the concepts in software testing such as testing process, criteria,
strategies, and methodologies.
 To develop skills in software test automation and management using latest tools.

Course Outcomes:

•Design and develop the best test strategies in accordance to the development model.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 2

 Syllabus
UNIT - I

• Introduction: Purpose of testing, Dichotomies, model for testing, consequences of bugs,

taxonomy of bugs: Flow graphs and Path testing: Basics concepts of path testing, predicates,
path predicates and achievable paths, path sensitizing, path instrumentation, application of
path testing.

UNIT - II

• Transaction Flow Testing: transaction flows, transaction flow testing techniques. Dataflow
testing: Basics of dataflow testing, strategies in dataflow testing, application of dataflow
testing. : domains and paths, Nice & ugly domains, domain testing, domains and interfaces
testing, domain and interface testing, domains and testability.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 3

 Syllabus
UNIT - III

• Paths, Path products and Regular expressions: path products & path expression, reduction procedure, applications,
regular expressions & flow anomaly detection.

• Logic Based Testing: overview, decision tables, path expressions, kv charts, specifications.

UNIT - IV

• State, State Graphs and Transition testing: state graphs, good & bad state graphs, state testing,

• Testability tips.

UNIT - V

• Graph Matrices and Application: Motivational overview, matrix of graph, relations, power of a matrix, node
reduction algorithm, building tools. (Student should be given an exposure to a tool like JMeter or Win-runner).

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 4

TEXT BOOKS:

1. Software Testing techniques – Baris Beizer, Dreamtech, second edition.

2. Software Testing Tools – Dr. K. V. K. K. Prasad, Dreamtech.

REFERENCE BOOKS:

1. The craft of software testing – Brian Marick, Pearson Education.

2. Software Testing Techniques – SPD(Oreille)

3. Software Testing in the Real World – Edward Kit, Pearson.

4. Effective methods of Software Testing, Perry, John Wiley.

5. Art of Software Testing – Meyers, John Wiley.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 5

 What is Transaction flow?
• A unit of work seen from a system users point of view is known as transaction.
• It contains the sequence of operations, some of which are performed by a system, persons or
devices that are outside of the system.
• Transactions begin with birth, i.e. they are created as a result of some external act.
• At the conclusion of the transactions processing, the transaction is no longer in the system.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 6

Following are the steps included in a transaction for an online information retrieval system
• Accept input(tentative birth)
• Validate input(birth)
• Transmit acknowledgment to requester
• Do input processing
• Search file
• Request directions from user
• Accept input
• Validate input
• Process request
• Update File
• Transmit output
• Record transaction in log and clean up(death)
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 7
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 8
 Usage
• Online systems are most complicated system.
• In this, the transaction flows are indispensable for specifying requirements.
• Air traffic control or airline reservation systems are the big systems.
• It has thousands of different transaction flows.
• The flows are represented by relatively simple flow graphs, many of which have a single
straight-through path.
• Loops are infrequent compared to control flow graphs,
• The most common loop is used to request a retry after 'user input' errors.
Example: An ATM system allows the user to try, say three times, and will take the card away
the fourth time.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 9

 Implementation
• The implementation of a transaction flow is generally implicit in the systems control structure
and the database it uses.

• A transaction flow is a representation of a path taken by a transaction through a succession of

processing modules.

• Think of each transaction as represented by a token that passes from one routine to routine as it
progresses through flow.

• Transaction flow graph is a diagrammatic representation of what happens to the tokens.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 10

 Perspective
• Transaction flow testing is the ultimate black box testing as all we know is that there is a
transaction and the system will do predictable actions to the transaction.

• Transaction flow graphs are kind of data flow graphs as we look at the various data objects and
the operation performed on them.

• We should note that the decision nodes of transaction flow graph can be complicated in their
own rights.

• Our transaction flow model should be a simplified version of those decisions.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 11

 What is Transaction Flow Testing?
• The transaction flow testing targets to validate every step of the transaction within a system,
specifically in the financial or fintech apps.
• These steps include data entry, processing, output generation, and validation.
• Consistency and Reliability – Transaction flow testing helps eliminating issues arising due to
external factors and dependencies.
• Accuracy and Integrity – Transactional flow testing ensures that data integrated with
transactions always remain intact across the entire flow.
• In this way, validating and handling outputs are always accurate.
• Enhanced Scalability and Performance – Testing transaction flow enables testers to verify that
the system handles transactions consistently without performance hits or lags during heavy
loads and without unexpected errors.
• Exception Management – Testers evaluate and check that the error messages are displayed
appropriately, and transactions are roll backed when necessary to maintain system integrity.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 12

 Transaction Flow Testing Techniques

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 13

 Get the Transaction Flows
 Transaction flows are like control flow graphs, and consequently, we should expect to have
them in increasing levels of details.

 Complicated systems that process a lot of different, complicated transactions, should have
explicit representations of the transactions flows or the equivalent.

 The systems design documentation should contain an overview section, that details the main
transaction flows.

 Detailed transaction flows are a mandatory prerequisite to the rational design of a systems
functional test.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 14

 Inspections, Reviews and Walkthroughs
• Transaction flows are natural agenda for system reviews or inspections.
• Discuss paths through flows in functional rather than technical terms.
• Ask the designers to relate every flow to the specification and to show how that transaction,
directly or indirectly, follows from the requirements.
• Make transaction flow testing the corner stone of system functional testing, just as path testing
is the corner stone of unit testing.
• Select additional flow paths for loops, extreme values, and domain boundaries.
• Design more test cases to validate all births and deaths.
• Publish and distribute the selected test paths through the transaction flows as early as possible,
so that they will exert the maximum beneficial effect on the project

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 15

 Path Selection
• Select a set of covering paths (C1 + C2) using the analogous criteria you
used for structural path testing.

• Select a covering set of paths based on functionally sensible transactions as

you would for control flow graphs.

• Try to find most tortuous, longest, strongest path from the entry to the exit of
the transaction flow.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 16

 Path Sensitization
• Review of Achievable and Unachievable Paths.
• The act of finding a set of solutions to the path predicate expression is called path sensitization.
• If you can find a solution, the path is achievable.
• If you cannot find a solution, then the path is unachievable.
• If you cannot find a solution to any of the sets of inequalities, the path is not achievable.
• Pragmatic Observations
• Heuristic Procedures for Sensitizing Paths
• Identify
• Classify
• Start Path
• The predicates are correlated
• The predicates are incorrectly classified
• If coverage hasn’t been achieved using independent uncorrelated.
• If coverage hasn’t been achieved extend the cases to those that involve defendent Predicates.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 17
 Path Instrumentation

• Instrumentation plays a bigger role in transaction flow testing than in unit path testing.

• Path instrumentation confirms that the outcome was achieved by the intended path.

• The information of the path taken for a given transaction must be kept with that transaction and

can be recorded by a central transaction dispatcher or by the individual processing modules.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 18

 Design and Maintain Test Database
• Design and maintenance of the test databases constitute about 30% to 40% of the effort in
transaction flow test design.

• People are often unaware that a test database needs to designed.

• Test databases must be centrally administrated and configuration controlled with a

comprehensive design plan.

• Creating a comprehensive test databases is itself a big project on its own

• It requires talented, matured, and diplomatic designers who are experienced in both system
design and test design.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 19

 Test Execution

• Commit to automation of test execution if you want to do transaction flow testing for a system

of any size.

• If the numbers of test cases are limited, you need not worry about test execution automation.

• If the number of test cases run into several hundred, performing transaction flow testing to

achieve (C1 + C2) needs execution automation without which you cannot get it right.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 20

 Key Strategies for Implementing Transaction Flow Testing

1. Prioritizing End-to-End Testing

2. Load and Performance Testing
3. Data Validation and Management
4. Creating Detailed Test Case Scenario
5. Overcome Challenges in Transaction Flow Testing
6. Thoroughly Understand the Transactional Flow

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 21

 Transaction Flows – Splitting & Merging decisions
Splits of transactions (Births)
Alternative 2
1. A decision point in TFG

Alternative 1

2. Biosis Parent
Parent

Daughter Tr.

Daughter Tr.
3.Mitosis Parent

Daughter Tr.

April 22, 2025 STM(Unit 2): Dr. B.Rajalingam 22

 Transaction Flows – Splitting & Merging decisions

Births
• There are three different possible interpretations of the decision symbol or nodes with two or
more out links. It can be a Decision, Biosis or a Mitosis.
1. Decision
• Here the transaction will take one alternative or the other alternative but not both.
2. Biosis
• Here the incoming transaction gives birth to a new transaction, and both transactions that
continue on their separate paths and the parent retains its identity.
3. Mitosis
• Here the parent transaction is destroyed and two new transactions are created.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 23

 Transaction Flows – splitting & merging decisions
Mergers of transactions
Path 1

1. Junction Continue

Path 2

Daughter Tr.
2. Absorption
Predator

Predator

3. Conjugation
Parent Daughter

Parent

April 22, 2025 STM(Unit 2): Dr. B.Rajalingam 24

 Transaction Flows – Splitting & Merging Decisions
Mergers
• Transaction flow junction points are potentially as troublesome as transaction flow splits.
There are three types of junctions: (1) Ordinary Junction (2) Absorption (3) Conjugation
Ordinary Junction:
• An ordinary junction which is similar to the junction in a control flow graph. A
transaction can arrive either on one link or the other.
Absorption:
• In absorption case, the predator transaction absorbs prey transaction. The prey was gone
but the predator retains its identity.
Conjugation:
• In conjugation case, the two parent transactions merge to form a new daughter. In
keeping with the biological flavor, this case is called as conjugation.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 25
 Data Flow Testing

• Data flow testing is the name given to a family of test strategies based on selecting

paths through the program's control flow in order to explore sequences of events

related to the status of data objects.

• For example, pick enough paths to assure that every data object has been

initialized prior to use or that all defined objects have been used for something.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 26

 Motivation

• It is our belief that, just as one would not feel confident about a program without

executing every statement in it as part of some test, one should not feel confident

about a program without having seen the effect of using the value produced by

each and every computation.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 27

 Data Flow Machines

• There are two types of data flow machines with different architectures.

(1) Von Neumann Machines

(2) Multi-instruction, Multi-data Machines (MIMD).

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 28

 Von Neumann Machine Architecture:
• Most computers today are Von-Neumann machines.
• This architecture features interchangeable storage of instructions and data in the same
memory units.
• The Von Neumann machine Architecture executes one instruction at a time in the
following, micro instruction sequence:
• Fetch instruction from memory
• Interpret instruction
• Fetch operands
1. Process or Execute
2. Store result
3. Increment program counter
4. GOTO 1
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 29
 Multi-instruction, Multi-data machines (MIMD) Architecture:

• These machines can fetch several instructions and objects in parallel.

• They can also do arithmetic and logical operations simultaneously on different

data objects.

• The decision of how to sequence them depends on the compiler.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 30

 Data Flow Graphs

• The data flow graph is a graph consisting of nodes and directed links.

• We will use a control flow graph to show what happens to data objects of interest

at that moment.

• Our objective is to expose deviations between the data flows we have and the data

flows we want.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 31

 Data Object State and Usage
• Data Objects can be created, killed and used.

• They can be used in two distinct ways: (1) In a Calculation (2) As a part of a
Control Flow Predicate.

The following symbols denote these possibilities:

• Defined: d - defined, created, initialized, etc.

• Killed or undefined: k - killed, undefined, released etc.

• Usage: u - used for something (c - used in Calculations, p - used in a predicate).

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 32
 Defined (d):
• An object is defined explicitly when it appears in a data declaration.

• Or implicitly when it appears on the left hand side of the assignment.

• It is also to be used to mean that a file has been opened.

• A dynamically allocated object has been allocated.

• Something is pushed on to the stack.

• A record written.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 33

 Killed or Undefined (k)

• An object is killed on undefined when it is released or otherwise made

unavailable.
• When its contents are no longer known with certitude (with absolute certainty /
perfectness).
• Release of dynamically allocated objects back to the availability pool.
• Return of records.
• The old top of the stack after it is popped.
• An assignment statement can kill and redefine immediately.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 34

 Usage (u)

• A variable is used for computation (c) when it appears on the right hand side of an

assignment statement.

• A file record is read or written.

• It is used in a Predicate (p) when it appears directly in a predicate.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 35

 Data Flow Anomalies
• An anomaly is denoted by a two-character sequence of actions.

• For example, ku means that the object is killed and then used, where as dd means
that the object is defined twice without an intervening usage.

• What is an anomaly is depend on the application.

• There are nine possible two-letter combinations for d, k and u.

• some are bugs, some are suspicious, and some are okay.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 36

 Data Flow Anomalies
1. dd :- probably harmless but suspicious. Why define the object twice without an
intervening usage?
2. dk :- probably a bug. Why define the object without using it?
3. du :- the normal case. The object is defined and then used.
4. kd :- normal situation. An object is killed and then redefined.
5. kk :- harmless but probably buggy. Did you want to be sure it was really killed?
6. ku :- a bug. the object doesnot exist.
7. ud :- usually not a bug because the language permits reassignment at almost any
time.
8. uk :- normal situation.
9. uu :- normal situation.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 37
• In addition to the two letter situations, there are six single letter situations.
• We will use a leading dash to mean that nothing of interest (d,k,u) occurs prior to the action noted
along the entry-exit path of interest.
• A trailing dash to mean that nothing happens after the point of interest to the exit.
They possible anomalies are:
1. -k :- possibly anomalous because from the entrance to this point on the path, the variable had not
been defined. We are killing a variable that does not exist.
2. -d :- okay. This is just the first definition along this path.
3. -u :- possibly anomalous. Not anomalous if the variable is global and has been previously defined.
4. k- :- not anomalous. The last thing done on this path was to kill the variable.
5. d- :- possibly anomalous. The variable was defined and not used on this path. But this could be a
global definition.
6. u- :- not anomalous. The variable was used but not killed on this path. Although this sequence is
not anomalous, it signals a frequent kind of bug. If d and k mean dynamic storage allocation and
return respectively, this could be an instance in which a dynamically allocated object was not
returned to the pool after use.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 38
 Data Flow Anomaly State Graph:
• Data flow anomaly model prescribes that an object can be in one of four distinct
states:
• K :- undefined, previously killed, does not exist.
• D :- defined but not yet used for anything.
• U :- has been used for computation or in predicate.
• A :- anomalous.
• These capital letters (K, D, U, A) denote the state of the variable and should not be
confused with the program action, denoted by lower case letters.
• Unforgiving Data - Flow Anomaly Flow Graph: Unforgiving model, in which
once a variable becomes anomalous it can never return to a state of grace.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 39

 Data Flow Anomaly State Graph
• Assume that the variable starts in the K state - that is, it has not been defined or
does not exist.
• If an attempt is made to use it or to kill it (e.g., say that we're talking about
opening, closing, and using files and that 'killing' means closing), the object's state
becomes anomalous (state A) and, once it is anomalous, no action can return the
variable to a working state.
• If it is defined (d), it goes into the D, or defined but not yet used, state.
• If it has been defined (D) and redefined (d) or killed without use (k), it becomes
anomalous, while usage (u) brings it to the U state.
• If in U, redefinition (d) brings it to D, u keeps it in U, and k kills it.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 40

 Forgiving Data - Flow Anomaly Flow Graph
• Forgiving model is an alternate model where redemption (recover) from the anomalous
state is possible.
• This graph has three normal and three anomalous states and he considers the kk
sequence not to be anomalous.
• A proper action from any of the three anomalous states returns the variable to a useful
working state.
• The point of showing you this alternative anomaly state graph is to demonstrate that the
specifics of an anomaly depends on such things as language, application, context, or
even your frame of mind.
• In principle, you must create a new definition of data flow anomaly (e.g., a new state
graph) in each situation.
• You must at least verify that the anomaly definition behind the theory or imbedded in a
data flow anomaly test tool is appropriate to your situation.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 41
 Data Flow Model
• The data flow model is based on the program's control flow graph - Don't confuse
that with the program's data flow graph.

• Here we annotate each link with symbols (for example, d, k, u, c, p) or sequences

of symbols (for example, dd, du, ddd) that denote the sequence of data operations
on that link with respect to the variable of interest.

• Such annotations are called link weights.

• The control flow graph structure is same for every variable: it is the weights that
change.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 42
 Data Flow Model

• Data flow testing is a family of test strategies based on selecting paths through the

program's control flow in order to explore sequences of events related to the status

of variables or data objects.

• Dataflow Testing focuses on the points at which variables receive values and the

points at which these values are used.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 43

 Flow Graph in Software Testing
• Flow Graph is defined as a function in a program that can be represented as a control
flow graph and the nodes in the flow graph are defined as program statements while the
directed edges are the flow of control.
• A Flow Graph consists of nodes and edges.
• The two nodes in the Flow Graph can be either unconnected or connected by an edge in
either direction or connected by an edge in all directions.
• While tracing a path from a source to a sink a back edge is an edge that leads back to a
node that has already been visited.
• The Flow Graph contains one source node and one sink.
• A source node is the node that has no incoming edges while a sink node is the node with
no outgoing edges.
• A program's function may contain more than one sink node, but this graph can be
converted into a graph with only one sink.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 44
 Data Flow Anomaly State Graph

• Used as a main tool for test case identification.

• Represents the relationship between program segments, that is the sequence of

statements having the property that if the first member of the sequence is executed

then all other statements in that sequence will also be executed.

• Nodes represent one program segment.

• The area bounded by edges and nodes are called regions.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 45
 Control Flow Testing
• Control flow testing is a testing technique that comes under white box testing.
• The aim of this technique is to determine the execution order of statements or instructions
of the program through a control structure.
• The control structure of a program is used to develop a test case for the program.
• In this technique, a particular part of a large program is selected by the tester to set the
testing path.
• It is mostly used in unit testing.
• Test cases represented by the control graph of the program.
• Control Flow Graph is formed from the node, edge, decision node, junction node to
specify all possible execution path.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 46
 Notations used for Control Flow Graph

• Node

• Edge

• Decision Node

• Junction node

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 47

 Data Flow Anomaly State Graph
Node
• Nodes in the control flow graph are used to create a path of procedures.
• Basically, it represents the sequence of procedures which procedure is next to come so, the tester
can determine the sequence of occurrence of procedures.
Edge
• Edge in control flow graph is used to link the direction of nodes.
Decision node
• Decision node in the control flow graph is used to decide next node of procedure as per the value.
Junction node
• Junction node in control flow graph is the point where at least three links meet.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 48

Diagram
- control
flow
graph

STM(Unit 2):-Dr. B.Rajalingam 22/04/2025 49

 Flow Graph Symbols

Standard notations used in constructing a flow graph are as in the following.

1. To indicate a Sequence:

2. To indicate "IF-THEN-ELSE":

3. To indicate a "WHILE" Loop:

4. To indicate a "Repeat-Until" Loop:

5. To indicate a "CASE" Statement:

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 50
 To indicate a
Sequence:

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 51

 To indicate "IF-
THEN-ELSE":

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 52

 To indicate a
"WHILE" Loop:

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 53

 To indicate a
"Repeat-Until"
Loop:

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 54

 22/04/2025

To indicate a
"Repeat-
Until" Loop:

STM(Unit 2):-Dr. B.Rajalingam 55

 On a Flow Graph

• Arrows called edges indicates flow of control.

• Circles called nodes indicates one or more actions.

• Areas bounded by edges and nodes are called regions.

• A predicate node is a node containing a condition.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 56

 Terminology
1. Clear Path Segment, is 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.

2. Loop-Free Path Segment is a path segment for which every node in it is visited at most once.

3. Simple path segment is a path segment in which at most one node is visited twice. 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 57

 Strategies of Data Flow Testing
• Data Flow Testing Strategies are structural strategies.
• 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.
• 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:
• In other words, data flow strategies require data-flow link weights (d,k,u,c,p).
• 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.
• For example, all subpaths that contain a d (or u, k, du, dk).
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 58
 Strategies

1. All - du Paths (ADUP)

2. All Uses Strategy (AU)

3. All p-uses/some c-uses strategy (APU+C)

4. All c-uses/some p-uses strategy (ACU+P)

5. All Definitions Strategy (AD)

6. All Predicate Uses (APU), All Computational Uses (ACU) Strategies

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 59
 All - du Paths (ADUP):
• The all-du-paths (ADUP) strategy is the strongest data-flow testing strategy.
• It requires that every du path from every definition of every variable to every use of that
definition be exercised under some test.

For variable X.
In image, because variable X are used only on link (1, 3) any test that starts at the entry
satisfies this criterion (for variable X, but not for all variables as required by the
strategy)
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 60
 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 61

 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, and then
add computational use test cases as required to cover every definition.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 62

 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
• 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

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 63

 All Definitions Strategy (AD)
• The 'all definitions strategy' reveals that every definition of every variable be covered by at least
one use of that variable; be it the use a computational use or a predicate use.
For variable Z

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 64

 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 form 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 obvious that ACU should be weaker than ACU+P, and APU should be weaker than APU+C.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 65

 Sub Topic
Sub Topic name
No’s
1 Introduction
2 Domains & Paths

3 Nice Domains

4 Ugly Domains

5 Domain Testing

6 Domains & Interfaces Testing

7 Domains & Testability

April 22, 2025 STM(Unit 2): Dr. B.Rajalingam 66

 What is Domain Testing?
• In mathematics, domain is a set of possible values of an independent variable or the variables of
a function.
• Domain Testing is a Software Testing process in which the application is tested by giving a
minimum number of inputs and evaluating its appropriate outputs.
• The primary goal of Domain testing is to check whether the software application accepts inputs
within the acceptable range and delivers required output.
• It is a Functional Testing technique in which the output of a system is tested with a minimal
number of inputs to ensure that the system does not accept invalid and out of range input values.
• It is one of the most important White Box Testing methods.
• Domain testing can be based on specifications or equivalent implementation information.
• If domain testing is based on specifications, it is a functional test technique.
• If domain testing is based implementation details, it is a structural test technique.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 67

 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.
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:
• Think what can go wrong.
• Find a solution to handle each case.
• Pick several points to test each error.
• Take one test point to examine adjacent domains
• Then start running the test
• Check if the boundaries are faulty
• Inspect boundaries of all domains
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 68
 Skills required for Domain testing :
To be a good domain tester, one must have the following skills:
• Quick learner
• Domain knowledge
• Can work under pressure
• Technical and Programming skills
• Automation skill
• Bug hunting skill
• Communication skill
• Domain testing requires knowledge of providing correct input to get the necessary
output.
• It is also equivalent to boundary analysis testing, where input variables are examined
and taken as boundary values and equivalence class values to get the desired result.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 69

 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 70

 Advantages of Domain Testing

• Identifies edge cases that can cause issues in a software system.

• Efficient use of testing resources.

• Increases test coverage by testing a wide range of values within a domain.

• Improves software quality by identifying and fixing issues in edge cases.

• Cost-effective testing technique that requires fewer resources compared to other testing
techniques.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 71

 Disadvantages of Domain Testing

• Limited scope, only focuses on a specific range or domain.

• A false sense of security, may not identify all issues outside the domain.

• Difficult to determine domain boundaries.

• May not catch complex issues that require testing of multiple variables or interactions between
different parts of the system.

• May not be suitable for all types of systems, particularly those that have complex input and
output parameters or that require more advanced testing techniques.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 72

 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

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 73

 Domain Testing - Domains & Paths

D1
D2
INPUT CLASSIFY DO CASE 1 OUTPUT
D3

(x,y,z,…) Dn { Outcome }
DO CASE 2
(1, 2, 3, 4, 5,…)

DO CASE 3

DO CASE n

April 22, 2025 STM(Unit 2): Dr. B.Rajalingam 74

 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 75

 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 flowgraph.
• Conversely, if domain testing is applied to specifications, interpretation is based on a specified data
flowgraph for the routine; but usually, as is the nature of specifications, no interpretation is needed because
the domains are specified directly.
• 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 or if the domain is defined by
the union of two or more domains.
• 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.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 76
 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 77

 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 hyperplanes.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 78
 Nice Domains in Domain Testing
• Domains are defined by an imperfect iterative process which aims at achieving the satisfaction
of user, buyer, voter etc..
• The domains which are implemented cant be incomplete or inconsistent, and processing of
every input will be done (rejection is a process), possibly forever.
• Conversely, specified domains can be incomplete and/or inconsistent.
• Incomplete implies that there are input vectors which have no specific path.
• Inconsistent implies that the same segment of the input space has at least two contradictory
specification.
• Some important properties of nice domains are: linear, complete, systematic, orthogonal,
consistently closed, convex and simply connected.
• Domain testing gets better and easier if the domains posses the properties which are mentioned
above.
• The nice domains have lesser bug frequency than the ugly domains.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 79

 Ugly Domains in Domain Testing
• Some domains are born and some are made uglier by bad specifications.
• Example: If the age limit for a job's eligibility is not defined clearly in the specifications
document, it results in an ugly domain.
• Each and every simplification of ugly domains by the programmers can be either good or bad.
• When searching for nice solutions, the programmers will 'simplify' the essential complexity out
of existence.
• Testers in search of brilliant insights will be blind to essential complexity and therefore miss
important cases.
• If the ugliness is because of the bad specifications and the simplification made by the
programmer has no harm, then the programmer has made ugly into good.
• But if the domains complexity is essential (Example: The income tax code), such
'simplifications' constitute bugs.
• The non-linear boundaries are so scare in ordinary programming that the information on how
programmers might "correct" such boundaries when they are essential is not at all at hand.
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 80
 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)

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 81

 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
22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 82
 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.

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 83

 Domains and Testability
• The best approach to do domain is testing is to stay away from it by making things simple such
that the testing is not required.
• Orthogonal domain boundaries, consistent closure, independent boundaries, linear boundaries,
etc.., make the domain testing easier.
• Non-linear boundaries can be converted into equivalent linear boundaries.
• This can be done by applying linearizing transformation.
• Nice boundaries come in parallel sets. Non- parallel inequalities can be converted into a set of
orthogonal boundaries inequalities by suitable co-ordinate transformations.
• Testing can be divided into several steps that can be merged and made small that can be
converted into a canonical program form

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 84

 Thank you

22/04/2025 STM(Unit 2):-Dr. B.Rajalingam 85