SOFTWARE TESTING

METHODOLOGIES (STM)
(JNTUH – R22)
[Link] CSE (AI&ML) III-II
By
K SUDHAKAR
Assistant Professor
 UNIT - II
Transaction Flow Testing: transaction flows,
transaction flow testing techniques. Data Flow
testing: Basics of data flow testing, strategies
in data flow testing, application of data flow
testing. Domain Testing: domains and paths,
Nice & ugly domains, domain testing, domains
and interfaces testing, domain and interface
testing, domains and testability.
TRANSACTION FLOW TESTING
Transaction: A transaction is a unit of work initiated by an
external event, consisting of a sequence of operations
performed by a system, users, or devices. It begins with
creation (birth) and concludes when processing is complete,
exiting the system.

Transaction-flow: Transaction-flow represents a system’s

processing. Functional testing methods are applied for
testing T-F.

Transaction-flow Graph: TFG represents a behavioral

(functional) model of the program (system) used for functional
testing by an independent system tester.

Example of a Transaction:
Online Information Retrieval System
 The sequence of steps in a transaction in an online information
retrieval system :
Accept input – The system receives a user query (tentative start).
Validate input – Ensures the input is correct (official start).
Acknowledge request – Confirms receipt to the user.
Process input – Interprets the user’s request.
Search file – Looks for relevant information.
Request more details – Asks the user for clarification if needed.
Accept & validate new input – Receives and checks further
instructions.
Process request – Carries out the user’s search.
Update file – Modifies data if necessary.
Send output – Displays or transmits the search results.
Log transaction & clean up – Records the transaction and
removes temporary data (end).
This sequence ensures smooth and accurate information retrieval.
A real-time example of a transaction in an online banking system:
Accept input (tentative birth) – User enters login credentials.
Validate input (birth) – System verifies username and password.
Transmit acknowledgment to requester – User receives confirmation of
successful login.
Do input processing – User initiates a funds transfer by entering recipient
details and amount.
Search file – System checks the user's account balance and recipient details.
Request directions from user – System asks for confirmation of the
transaction.
Accept input – User confirms the transaction.
Validate input – System verifies if funds are available and checks transaction
limits.
Process request – System deducts the amount from the sender's account.
Update file – Recipient’s account is credited, and the transaction is
recorded.
Transmit output – User receives a confirmation message with transaction
details.
Record transaction in log and clean up (death) – System logs the
transaction and clears temporary session data.
TRANSACTION FLOW GRAPHS
 Transaction flows represent how a system
processes different tasks step by step.
 Similar to control flow graphs, they help in
functional testing to check if the system
works correctly.
 Testers use transaction flow graphs to
understand system behavior, just like
programmers use path testing for code.
 These graphs create a behavioral model,
helping in testing the system’s functionality
effectively.
USAGE:
1. Definition & Importance: Transaction flows are
essential for defining the requirements of complex
systems, particularly in online environments like
banking, airline reservations, or air traffic control.
2. Large-Scale Systems: Big systems can have thousands
of transaction flows, each representing different user
interactions or processes within the system.
3. Flow Representation: These flows are typically
depicted as simple flowgraphs, where most transactions
follow a straight path with minimal branching or looping.
4. Loops & Retries: Unlike control flowgraphs, transaction
flows rarely have loops. The most common loop occurs
when a user is allowed to retry after an input error, such
as entering a PIN incorrectly at an ATM, which may
allow three attempts before blocking the card.
Implementation of Transaction-Flow (in a system)
Transaction Flow and System Control: Transaction flow
indirectly represents how a system controls processes, but it
does not directly link processes to decisions.
How Transactions Move: A transaction follows a specific
path through different processing modules and is stored in a
transaction-control block, where it is processed step by step.
Graphical Representation: Each transaction is shown as a
token, and a transaction flow graph visually represents how
these tokens move through the system.

.
COMPLICATIONS
In simple cases, each transaction has a unique identity
from start to finish, but in complex systems, one
transaction can create new transactions or combine with
others.
Births: A decision symbol (or a node with two or more
outgoing paths) can have three meanings.
1. Decision: The transaction chooses one path or the
other, but never both at the same time.

.
2. Biosis: A new transaction is created from the
original one, and both move forward separately
while the original transaction stays the same.

3. Mitosis: Here the parent transaction is

destroyed and two new transactions are
created.
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
1. Ordinary Junction: A junction is like a
meeting point where a transaction can come
from one path or another, but not both
together.
Absorption : In absorption, one transaction
takes over another. The second transaction
disappears, but the first one stays the same and
continues.

Conjugation : In conjugation, two transactions

join together to create a new transaction. Since
this is similar to a biological process, it is called
conjugation.
 TRANSACTION FLOW TESTING TECHNIQUES:
1. GET THE TRANSACTIONS FLOWS:
 Complex systems handling many different
transactions should clearly show how
transactions move through the system.
 Transaction flows are similar to control flow
graphs and should be explained in increasing
levels of detail.
 A system's design documents must include main
transaction flows, as they are essential for
properly designing functional tests.
INSPECTIONS, REVIEWS AND WALKTHROUGHS:
1. Transaction flows should be reviewed thoroughly by
discussing key transaction types covering 98%-99% of
expected system processes and focusing on functional
aspects rather than technical details.
2. Designers must link each transaction flow to system
requirements, ensuring that every flow aligns with
specifications and expected behaviors.
[Link] flow testing should be the foundation of
system functional testing, similar to how path testing is
crucial for unit testing, with additional test paths
covering loops, extreme values, and boundary conditions.
[Link] cases should be designed to verify all transaction
starts (births) and completions (deaths), and the finalized
test paths should be shared early to maximize their
positive impact on the project.
PATH SELECTION:
Selecting Covering Paths: Choose a set of
paths (C1 + C2) that cover all important
transaction flows, similar to structural path
testing. Focus on functionally meaningful
transactions, just like selecting paths in
control flow graphs.
Exploring Complex Paths: Identify the
longest, most complex, and unusual
transaction flow from start to finish to ensure
the system can handle all possible scenarios.
PATH SENSITIZATION:
 Most normal transaction paths are easy to test, and
achieving 80%-95% coverage is simple. However, the
last few paths can be very difficult to cover.
 Sensitization means defining the transaction. If easy
paths have issues, it likely indicates a bug in
transaction flows or a design flaw in the system.
PATH INSTRUMENTATION:
 Role of Instrumentation: In transaction flow testing,
tracking the path of each transaction is more important
than in unit path testing because it helps monitor how
transactions move through the system.
 Tracking Methods: The path information for each
transaction can be recorded by a central transaction
dispatcher, individual processing modules, or even
system logs maintained by the operating system.
 DATA FLOW TESTING

Data Flow Testing is a structural

testing technique that analyzes how
variables are created, used, and
modified in a program. It follows the
program's execution flow to check if
variables are correctly assigned and
utilized. This method helps detect
issues like unused variables or
incorrect assignments, ensuring
better code quality and reliability.
 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).
Von Neumann Machine :
Most computers today follow the Von
Neumann architecture, where instructions
(commands) and data are stored together
in memory.
The computer works step by step:
• Fetch – Get the next instruction from memory.
• Understand – Figure out what to do.
• Get Data – Collect any needed numbers or
information.
• Execute – Perform the task (like adding or moving
data).
• Save Result – Store the output.
• Increment program counter– Go to the next
instruction.
• GOTO 1 – Keep running the process.
Real Time Example: Calculator (Stored Program Concept 
Von Neumann Basic Structure
 MIMD (Multi-Instruction, Multi-Data)
Architecture:

MIMD computers can process multiple

instructions and data at the same time. They
can perform different tasks on different
pieces of data simultaneously.
• These machines can fetch multiple instructions and
data at once.
• They can perform math and logic operations at the
same time on different data.
• The compiler (a special program) decides the order of
execution.
 This makes MIMD architecture fast and efficient,
useful in supercomputers and modern processors!
Real Time Example: YouTube (Video Processing + Streaming &
Content Delivery + User Recommendations + Ads & Monetization )
MIMD (Multi-Instruction, Multi-Data)
Architecture
Bug Assumption in Data Flow
Testing

In data flow testing, we assume that the

program's flow (order of execution) is
mostly correct, but there might be
problems with how data is used.
• Some data might be missing or used incorrectly.
• If there is a flow issue, it should show signs that data
flow testing can catch.
• Instead of using complex data flow graphs, we use
a simple flowchart with extra notes showing how
data is handled.
This helps us find and fix errors related to
data usage in a program.
DATA FLOW GRAPHS
 A data flow graph is a diagram with
circles (nodes) and arrows (links)
that show how data moves in a program.
• We use a control graph to track how important
data is being used.
• Our goal is to find mistakes by comparing how
data actually flows versus how it should flow.
 This helps us identify errors and make
sure data is used correctly in the
program.
 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
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.
 Anomaly States are:
• Bug State
• Suspicious State
• Normal State

• dd :- Suspicious (Danger) State

• dk :- Bug State
• du :- Normal State
• kd :- Normal State
• kk :- Bug State
• ku :- Bug State
• ud :- Suspicious (Danger) State
• uk :- Normal State
 In addition to the two letter situations,
there are six single letter situations.

A leading dash means nothing happens

before the action, and a trailing dash means
nothing happens after it.

1. -k → Wrong deletion
2. -d → First definition
3. -u → Maybe wrong
4. k- → Okay deletion
5. d- → Unused variable
6. u- → Possible memory issue
 DATA FLOW ANOMALY STATE
GRAPH:
 Data flow anomaly model prescribes that an
object can be in one of four distinct states:
1. K :- undefined, previously killed, does not exist
2. D :- defined but not yet used for anything
3. U :- has been used for computation or in predicate
4. A :- anomalous

Data Flow Anomaly State Graph can be divided into two

types

1. Unforgiving Data - Flow Anomaly Flow Graph

2. Forgiving Data - Flow Anomaly Flow Graph
1. Unforgiving Data - Flow Anomaly Flow
Graph: In an unforgiving model, once a variable has an
error, it stays incorrect and can’t be fixed later.

[Link] Data - Flow Anomaly Flow Graph: A

forgiving model allows mistakes to be fixed, meaning the
system can recover from an error instead of failing.
 Static vs. Dynamic Anomaly
Detection

 Static detection finds possible mistakes before running the

program.
 Dynamic detection finds actual mistakes while the program is
running
DATA FLOW MODEL
1. A data flow model is based on the program's
control flow graph, not its data flow graph.
2. Each link in the control flow graph is labeled with
symbols (like d, k, u) to show how a variable is
used or modified, called link weights.
Components of the model:
 Each program statement has a node with
connections, except for entry (BEGIN) and exit
(END, RETURN) nodes, which complete the
graph.
 Links between nodes have symbols (weights)
showing how a variable is used or changed,
like "cd" for assignment.
 Multiple actions on a link can be combined or
split into smaller links to match the program's
Example:
a=5
b = 10
c=a+b
print(c)
Nodes Representation:
a = 5 → Node 1
b = 10 → Node 2
c = a + b → Node 3
print(c) → Node 4
Links and Weights:
a = 5 → weight d
b = 10 → weight d
c = a + b → weight ud
print(c) → weight p
Graph Structure:
STRATEGIES OF DATA FLOW TESTING:
Data Flow Testing Strategies analyze how data objects
are defined, used, and propagated through a program.
They select test paths based on data flow
characteristics, ensuring thorough coverage beyond
basic control flow.
STRATEGIES:

Data flow testing strategies, based on a program's
control flow graph, vary in effectiveness by including
predicate and/or computational uses of variables in the
test set.
 Various types of data flow testing strategies in
decreasing order of their effectiveness are:
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-du Paths (ADUP) – Covers all definition-use paths for
every variable, ensuring maximum data flow coverage.
Ex: Checking deposit, withdrawal, and insufficient balance scenarios

All Uses Strategy (AU) – Requires testing all definition-

use pairs, covering both predicate and computational
uses.
Ex: Test cases where balance is updated and checked in both if and else if
conditions.

All p-uses/some c-uses (APU+C) – Ensures all predicate

uses are tested while covering at least one
computational use per definition.
Ex: Checking withdrawal condition and ensuring balance update happens
at least once.

All c-uses/some p-uses (ACU+P) – Ensures all

computational uses are tested while covering at least
one predicate use per definition.
Ex: Ensuring both balance = balance + amount and balance = balance -
amount are executed, while also checking at least one if condition.
All Definitions (AD) – Ensures each variable
definition is tested with at least one of its
uses.
Ex: Testing a case where balance is defined (updated) and
then used in a return statement.

All Predicate Uses (APU) – Covers all

predicate (decision-related) uses of each
variable.
Ex: Checking transactions for deposit, withdrawal, and
insufficient balance cases.

All Computational Uses (ACU) – Covers all

computational (calculation-related) uses of
each variable.
Ex: Ensuring both balance + amount and balance - amount
operations are executed.
Applications of Data Flow Testing
 To develop Web Applications – Ensures
error-free data flow in web applications.
 Mobile Platforms – Verifies proper
handling of data in mobile apps.
 Embedded Devices – Detects data flow
issues in embedded system software.
 Automobile Computer Systems –
Ensures reliability in vehicle control
software.
 DFT uses practical applications rather
than Mathematical Applications –
Focuses on real-world system testing rather
than theoretical models.
DOMAINS AND PATHS
DOMAIN:
Domain in mathematics refers to the set of all possible input
values for a function. In software testing, domain testing
checks if a program correctly classifies inputs based on rules. It
can be functional (based on specifications) or structural (based
on implementation). This method often involves testing
extreme values and treating all inputs as numbers for analysis.

Example:
A real-time example of domain testing is validating user age input (18-
60) in an online registration form.
Valid Cases : 18 (Lower), 30 (Typical), 60 (Upper)
Invalid Cases : 17 (Below), 61 (Above), -5 (Negative),
 THE MODEL: THE FOLLOWING FIGURE IS A SCHEMATIC
REPRESENTATION OF DOMAIN TESTING.

1. Before processing, a program first checks and classifies the input.

2. If the input is invalid (e.g., too big), it gets rejected instead of being
processed.
3. Domain testing focuses on how inputs are classified, not on actual
calculations.
4. We only need clear input rules, not internal code details, to ensure each
A DOMAIN IS A SET: An input domain is a set of
possible values. If the programming language
supports set definitions, less testing is needed, but
domain testing is less effective for random data
sets.
DOMAINS, PATHS AND PREDICATES:
1. In domain testing, predicates help define input
classifications based on variables.
2. If testing is based on structure, predicates follow the
program’s control flow; if based on specifications, they
follow data flow.
3. Every domain has at least one path through the
program, and multiple paths exist if the domain has
separate parts.
4. Domains are defined by boundaries, where most errors
occur, and predicates determine which values belong
inside or outside.
5. A domain can have one or multiple boundaries,
regardless of the number of variables defining it.
6. Domains are often defined by multiple boundary
A DOMAIN CLOSURE:
1. A boundary is closed if its edge points belong to
the domain; otherwise, it is open.
2. In a one-dimensional domain (e.g., for variable x),
boundaries can be open or closed.
3. Mistakes in defining boundaries, like using x ≥ 0
instead of x > 0, are common domain bugs.

.
DOMAIN DIMENSIONALITY:
1. Every input variable adds one dimension to the domain.
2. One variable defines domains on a number line.
3. Two variables define planar domains.
4. Three variables define solid domains.
5. Every new predicate slices through previously defined
domains and cuts them in half.
6. Every boundary slices through the input vector space
with a dimensionality which is less than the
dimensionality of the space.
7. Thus, planes are cut by lines and points, volumes by
planes, lines and points and n-spaces by hyper planes.
 BUG ASSUMPTION:
Domain testing assumes the processing is correct,
but boundaries or control flow may be wrong due
to incorrect domain definitions.
Many different bugs can cause domain errors,
including:
1. Double Zero Representation:-
Some languages/computers differentiate between
+0 and -0, leading to errors at boundaries.
2. Floating Point Zero Check –
Floating-point numbers should be compared using
an epsilon value to avoid precision errors.
3. Contradictory Domains – When two supposedly separate
domains overlap due to incorrect specifications.
4. Ambiguous Domains – When parts of a domain are
undefined or incomplete, leading to unexpected gaps.
5. Over specified Domains – Too many constraints make a
domain impossible to achieve.
6. Boundary Errors – Mistakes in handling domain limits,
such as missing or extra boundaries.
7. Closure Reversal – Incorrectly negating a boundary
condition (e.g., x ≥ 0 mistakenly negated as x ≤ 0).
8. Faulty Logic – Errors in complex predicate logic,
leading to domain bugs.
 RESTRICTIONS TO DOMAIN
TESTING:
1. Co-incidental Correctness – Domain testing struggles to catch errors
when the output appears correct for the wrong reasons.
2. Representative Outcome – It assumes that testing one input from a
domain proves all inputs in that domain are correct, which may not
always be true.
3. Simple Domain Boundaries and Compound Predicates – Complex
conditions with multiple boundaries need careful handling as they can
behave differently than expected.
4. Functional Homogeneity of Bugs – Bugs usually affect values
(constants or coefficients) but don’t change the fundamental structure of
boundary conditions.
5. Linear Vector Space – Domain testing assumes that most boundary
conditions are linear, which is often true in practice.
6. Loop-Free Software – Loops complicate domain testing because each
 NICE AND UGLY DOMAINS

NICE DOMAINS:

Where Do Domains Come From?

Domains are developed by testing different approaches
to find what best satisfies users, customers, or voters.
Implemented Domains are fully functional and must be
complete and consistent. Every possible input is
handled correctly, even if that means rejecting certain
inputs.
Specified Domains are the planned or theoretical
versions, which may have gaps or contradictions.
Some inputs might be undefined or lead to conflicting
results.
PROPERTIES/BOUNDARIES OF NICE DOMAINS
Some important properties of nice domains are:
Linear,
Complete,
Systematic,
Orthogonal,
Consistently closed,
Convex and
Simply connected.
LINEAR AND NON LINEAR BOUNDARIES:
Most domain boundaries are linear, requiring n+1 points to define an n-
dimensional hyperplane, and over 99.99% can be linearised for testing.

COMPLETE BOUNDARIES:
Complete boundaries cover the entire number space without
gaps, requiring only one test set. Incomplete boundaries have
gaps due to constraints, unachievable paths, or redundant
conditions. Testing incomplete boundaries is harder, as each
segment must be tested separately.
SYSTEMATIC BOUNDARIES:
Systematic boundaries follow a simple pattern, like evenly
spaced lines. If you test one boundary, you can easily generate
tests for the others. This makes testing faster and more
organized.
ORTHOGONAL BOUNDARIES:
Orthogonal boundaries (perpendicular to each other) can be
tested separately, needing only O(n) tests. Tilting boundaries
creates intersections, requiring testing at each intersection point.
Testing complexity increases from O(n) (linear) to O(n²)
(quadratic) due to these additional intersections.
Consistently closed / Closure
Consistency:
Closure consistency means boundary lines systematically belong to a
specific domain, indicated by shading. Example: If a boundary line is shaded
on the right, it always belongs to the right-side domain. Consistent closure
ensures a clear, predictable pattern, making domain analysis and testing
easier.

Convex:
A convex figure means any two points inside it can be connected by a line
that remains entirely within the figure. Nice (well-defined) domains are
convex, while dirty (poorly defined) domains are not. Suspicious
conditions like "except if," "however," or "but not" in specifications often
Simply Connected Domains:
Simply connected domains are in one continuous piece, not scattered
across different regions.
Convex domains are always simply connected, but a simply connected
domain may not be convex.
Example: If a domain is defined by ABC, the other domain is defined by
NOT(ABC), forming two distinct regions.
UGLY DOMAINS
Ugly domains can be naturally complex or
made worse by unclear specifications.
Programmers simplifying complexity can
be helpful if the complexity is unnecessary but
harmful if it's essential. Testers and
programmers may overlook critical cases if
they don’t recognize necessary complexity. If
essential complexity (like tax rules) is
removed, it creates bugs, while fixing bad
specifications can turn an ugly domain into a
good one.
Ambiguities and Contradictions:
Ambiguities are gaps in input coverage, while contradictions happen when domains
or their boundaries overlap.
Simplifying the Topology:
Simplifying complex domains can lead to mistakes by smoothing concavities,
filling gaps, or connecting separate parts, causing bugs in code and test cases.

Rectifying Boundary closures:

When domain boundaries have inconsistent closure directions (left, right, left, etc.),
the logical fix is to align them in the same direction, ensuring consistency and
reducing errors.
 DOMAIN TESTING STRATEGY
1. Focus on Boundaries: Domains are defined
by boundaries, so testing should target points
on or near them.
2. Identify and Test Boundary Errors: Classify
possible boundary issues, select test cases for
each, and ensure all error types are covered.
3. Optimize Test Cases: Since boundaries
separate multiple domains, reuse test points
for adjacent domains and eliminate redundant
tests.
4. Analyze and Verify: Run tests, analyze results
to detect faulty boundaries, and conduct
DOMAIN BUGS AND HOW TO TEST FOR THEM
Interior Point: Fully inside the domain, with all nearby points also in
the domain.
Boundary Point: Has both inside and outside points within a small
surrounding area.
Extreme Point: Lies at the outermost edge, not between any two other
points.
DOMAIN BUGS AND HOW TO TEST FOR THEM
On Point: Directly on the boundary.
Off Points and Boundary Closure:
Closed Boundary: An off point is outside the domain, in the adjacent domain.
Open Boundary: An off point is inside the domain, near the boundary.
Acronym COOOOI: Closed Off Outside, Open Off Inside for remembering off-
point behavior.
Common Domain Bugs (Figure 4.12):
Closure Bug: Incorrectly handling closed or open boundaries.
DOMAIN BUGS AND HOW TO TEST FOR THEM
Shifted Boundary: Boundary is misplaced from its intended position.
Tilted Boundary: Boundary is at the wrong angle.
Extra Boundary: An unintended extra boundary appears.
Missing Boundary: A necessary boundary is missing.
Importance in Testing:
Testing should focus on these boundary-related issues to catch errors in domain definitions.
Proper classification of on, off, and boundary points helps in designing accurate test cases
 TESTING ONE-DIMENSIONAL DOMAINS
Closure Error (Image b): The boundary mistakenly includes a point that should be
outside, changing ">" to ">=" and causing errors.
Left Shift (Image c): The boundary moves left, wrongly placing a point in A instead
of B, revealing the mistake.
Right Shift (Image d): The boundary moves right, but the usual test point still falls
in B, so another test inside A is needed to catch the shift.
Finding the Bug: Testing a point just inside A helps detect boundary shifts when the
domain is open (Open Off Inside - COOOOI).
TESTING ONE-DIMENSIONAL DOMAINS
Missing Boundary Detection: If a boundary is missing, an 'off' point inside A will
be wrongly processed in B, revealing the bug.
Extra Boundary Detection: An extra boundary incorrectly splits A into two, so
testing two 'off' points near both boundaries helps catch the issue.
Closed Boundary Testing: For a closed boundary, an 'on' test point at the
boundary helps detect closure errors.
Difference from Open Boundaries: Unlike open boundaries, 'off' points just
outside the domain are needed to test closed boundaries properly.