UNIT-2

Transaction flow
Data Flow
Domain Testing
Unit- 2

Transaction flow testing

Data Flow Testing
 Domain Testing
 Transaction Flow Testing
What is transaction flow testing?

Transaction flow testing is a method used in software testing that aims

to verify each stage of a transaction within a system, particularly in
applications with payment processes.

These stages usually are data entry, processing, output generation,

and validation.

It helps developers identify design flaws, coding errors, and system-
level issues, helping prevent potential issues with the software.
 A Simple Transaction
Example: the sequence of steps in a transaction in an online information
retrieval system
1. Accept input (tentative birth)
2. Validate input (birth)
Users View of a transaction : Single step
3. Transmit acknowledgement to requester Systems view : Sequence of
4. Do input processing many
operations
5. Search file
6. Request directions from user
7. Accept input
8. Validate input
9. Process request
10.Update file
11.Transmit output :

12.Record transaction in log and clean up (death)

 Example of a Transaction flow (diagram)
User Terminal controller CPU
(terminal)
cance
l
User Request orde Request Accept
Process B
Begin Type r order Order from
Form
from CPU CPU

hel
p

Y
Transmi Accept More
B C Transmit D
t Page Input Fields? To CPU
to Field
terminal

CPU- Y N N
More User wants Done
D Acce Valid ?
Pages ? Review?
pt
Confir
m Transmit Set up
Diagnostic C Review
to Terminal
 Implementation of Transaction-Flow (in a
system)

• Implicit in the design of system’s control structure & associated database.

• No direct one-to-one correspondence between the “processes” and “decisions” of
transaction-flow, and the corresponding program component.
• A transaction-flow is a path taken by the transaction through a succession of
processing modules.
• A transaction is represented by a token.
• A transaction-flow graph is a pictorial representation of what happens to the tokens.

Input S A S B S C S S Output

E
S : Scheduler A, B, C, D, E : Processes
Implementation of Transaction-Flow
System Control Structure (architecture of the
implementation) :
Input Outp
ut
EXECUTIVE
Fron
Queu Queu Outpu
SCHEDULER - AND / OR OPERATING SYSTEM t
t e e
DISPATCHER Modul
End
e

Proce
ss A B C D E
Queue Processor Processor Processor Processor Processor
s
Application
Processes

Executive / Dispatcher Flowchart (a sample sequence)

Disc Tape Disc

1 Do All Do All Do All 2
Reads Writes Writes
B’s C’s B’s

Disc Tape Disc

2 Do All Do All Do All 1
Write
D’s A’s E’s
Read Read s
s s
 Implementation of Transaction-Flow
System control structure

System is controlled by a scheduler …

 A Transaction is created by filling in a Transaction Control Block (TCB) by

user inputs and by placing that token on input Q of Scheduler.

 Scheduler examines and places it on appropriate process Q such as A.

 When A finishes with the Token, it places the TCB back on the scheduler Q.

Scheduler routes it to the next process after examining the token :

• It contains tables or code to route a token to the next process.

• It may contain routing information only in tables.

• Scheduler contains no code / data. Processing modules contain code

for routing.
 Implementation of Transaction-Flow

Transaction Processing System (simplified):

 There are many Tr. & Tr-flows in the system.
 Scheduler invokes processes A to E as well as disk & tape read & writes.
 The order of execution depends on priority & other reasons.
 Cyclic structure like in this example is common in process control &
communication systems
 The criteria for implementation mechanism depends on performance
and resource optimization.
 Transaction Flows – Complications
Births
Decision point : the transaction will take one alternative or the other alternative
but not both Alternativ
e2
Alternative
1
Biosis : the incoming transaction gives birth to a new transaction, and both transaction
continue on their separate paths, and the parent retains it identity.
Parent

Parent

Mitosis the parent transaction is destroyed and two Daughter

new transactions are created Daughter

Parent
Daughter
 Transaction Flows – Complications

Mergers of transactions
Junction : An ordinary junction which is similar to the Path 1
Continue
junction in a control flow graph.
Path 2
Absorption: the predator transaction absorbs
Daughter
prey transaction.
The prey gone but the predator retains its identity Predator

Predator

Conjugation : the two parent transactions merge to

Parent
form a new daughter.
Daughter
In keeping with the biological flavor this case is called
Parent
as conjugation
 Transaction Flow Testing
Techniques
1) Get the transaction flow
2) Inspections, Reviews, Walkthroughs
3) Path selection
4) Path sensitization
5) Path instrumentation
 Techniques :-- Get the transaction
flow
 Complex systems should have clear representations of their
transaction flows.

 Transaction flows are similar to control flow graphs.

 The system's design documents should include an overview of the

main transaction flows.

Detailed transaction flows are essential for designing effective

functional tests.
 Techniques :-- Inspections, Reviews,
Walkthroughs

Cover Key Transaction Types Select Additional Flow Paths

 Discuss enough transaction types to account for 98%-  Include test paths for loops, extreme values, and
99% of the system's expected transactions. domain boundaries.

Use Functional Language Test Births and Deaths:

Describe paths through flows in functional rather than
 Design test cases to validate the creation and
technical terms.
termination of transactions.
Trace to Requirements
Early Distribution
Ask designers to link each flow to the specifications
 Share the selected test paths as early as possible
and demonstrate how it follows from the requirements.
to maximize their impact on the project
Make Transaction Flow Testing a Priority
 Treat transaction flow testing as the foundation of

system functional testing, just as path testing is for

unit testing.
 Path Selection

 Select a set of paths (C1 + C2) using the same criteria

as structural path testing.
 Choose paths based on meaningful transactions,
similar to control flow graphs.
 Identify the longest, most complex, and unusual
path from entry to exit in the transaction flow.
 Path Sensitization
 Most normal paths are easy to define, achieving 80%-95%
transaction flow coverage (C1 + C2) is usually simple.

 The last few percent can be very difficult to cover.

 Sensitization means defining the transaction.

 If there are issues with sensitizing easy paths, it may indicate a

bug in transaction flows or a design flaw.
Testing Tr.–Flows with External Interfaces:
Use Patches, Mistune, Break the Rules, Breaking
point
 Path Instrumentation

Instrumentation plays a bigger role in transaction flow testing

than in unit path testing.
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.
In some systems, such traces are provided by the operating
systems or a running log.
 Test Data bases

1. Design & Maintenance of a Test Data base - Effort

2. Mistakes
• Unawareness about design of a centrally administered
test DB
• Test DB design by Testers
• Using one DB for all tests (need 4 to 5)
Test Execution

1. Use Test Execution Automation

2. Have to do a large number of Tests for C1+C2 coverage

 Data flow Testing
What is Data flow Testing?

Data Flow Testing is a software testing technique that focuses

on how data is used and propagated throughout the program.

 It analyzes the lifecycle of variables and detects issues like

uninitialized variables, unused variables, or improperly updated data.

This technique helps ensure correctness by verifying the data flow

between statements in the code.
 Data Flow Machines
There are two types of data flow machines with different architectures.
1. Von Neumann Machine Architecture:
 Most computers today use the Von Neumann architecture.
 This design stores both instructions and data in the same memory.
 The Von Neumann machine Architecture executes one instruction at a time in
the following, micro instruction sequence:
1. Fetch instruction from memory
2. Interpret instruction
3. Fetch operands
4. Process or Execute
5. Store result
6. Increment program counter
7. GOTO 1
 Multi-Instruction, Multidata-
MIMD
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.

 Data Flow Graphs(DFG)

• It is a graph with nodes & directed links

• Test the Von Neumann way - Convert to CFG

Annotate : program actions (weights)

 Data - Flow Testing - Basics -
Motivation

Program Control flow with Von Neumann’s paradigm

Given m, n, p, q, find e.

e = (m+n+p+q) * (m+n-p-q)

a = m+n
a := m + n
b := p + b=p+q
q c := a +
b d := a - c=a+b
b
e := c * d
d=a-b

e=c*d

Multiple representations of control flow graphs possible.

 Data - Flow Testing - Basics -
Motivation
Program Flow using Data Flow Machines paradigm
BEGIN
PAR DO m p q
n
READ m, n, n, p,
q
END PAR
PAR DO a := m+n b := p+q
a := m+n
b :=
p+q END c := a+b d := a-b
PAR PAR DO
c
:= a+b e := c * d
d := a-
b END PAR
PAR DO
e := c *
d END PAR
The interrelations
END among the data items remain same.
 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
 Data flow Anomalies
There are nine possible two-letter combinations for d, k and u. some are
bugs, some are suspicious, and some are okay.

dd :- probably harmless but suspicious.

dk :- probably a bug. Why define the object without using it?

du :- the normal case.

kd :- normal situation. An object is killed and then redefined.

kk :- harmless but probably buggy.

ku :- a bug. the object does not exist.

ud :- normal, redefinition

uk :- normal situation.

uu :- normal situation.
In addition to the two letter situations, there are six single letter
situations.
They possible anomalies are:
-k :- possibly anomalous
-d :- okay.
-u :- possibly anomalous.
k- :- not anomalous.
u- :- normal, possibly an anomaly
d- :- possibly anomalous
 Data - Flow Testing

Data Flow Anomaly State graph

• Data Object State

• K, D, U, A

• Processing Step

• k, d, u
 Data Flow Anomaly State graph
Unforgiving Data flow state graph forgiving dataflow anomaly state graph
 DFT Strategies
• All-du paths(ADUP)
• All-uses(AU) strategy
•All-p-Uses/Some –C-uses strategy
•All-c-uses/Some-p-Uses strategy
•All definition strategy
• all-predicate-uses(APU) strategy
•All-computational uses strategies
•Ordering the strategies
 All-du Paths (ADUP) Strategy

Definition: This strategy requires covering all definition-use (du)

paths in a program. A du-path is a path from a variable definition
(assignment) to a use of that variable without another definition in
between.
Example:
int x = 5; // Definition of x
if (x > 0) { // Use of x (predicate use)
x = x + 2; // Definition of x
}
print(x); // Use of x (computational use)
 All-Uses (AU) Strategy

Definition: Ensures that every definition of a variable is tested

with every use (both computational and predicate uses).

Example:
For the code below, testing should ensure that both the condition
if(x > 0) and the computation x = x + 2 are tested with all possible
values
intofx x.
= 5; // Definition of x
if (x > 0) { // Use of x (predicate
use)
x = x + 2; // Definition of x
}
 All-p-Uses/Some-c-Uses Strategy

Definition: This strategy ensures that all predicate uses (p-uses) are tested, and at
least one computational use (c-use) for each definition is covered.

Example:

Ensuring that the condition if(x > 0) is tested for both true and false

conditions while covering at least one computational use like x = x + 2

 All-c-Uses/Some-p-Uses Strategy

Definition: Ensures that all computational uses (c-uses) are tested, while at

least one predicate use (p-use) for each definition is covered.

Example:

Ensuring that the computational use x = x + 2 is tested for various values of x,

 All-Definition Strategy

Definition: Ensures that every definition of a variable is covered at least

once in a test case.

Example:
For x = 5; x = x + 2;, tests should ensure execution reaches both
assignments.

 All-Predicate-Uses (APU) Strategy

Definition: Ensures that all predicate uses (conditions) of a variable are

tested.

Example:

For if(x > 0), tests must include both cases where x > 0 and x ≤ 0.
All-Computational Uses (All-c-uses) Strategy

Definition: Ensures that all computational uses of

variables are tested.

Example:
For x = x + 2;, tests should include values ensuring
different computational outcomes.
Ordering of strategies
Example
1. read x, y;
2. if(x>y)
3. a = x+1 Variable Defined at Used at
else X 1 2,3
4. a = y-1
Y 1 2,4
5. print a;
A 3 5
 Domain Testing
What is Domain Testing?
Domain testing is a kind of software testing process during which
the software is tested by giving a minimum number of inputs
and evaluating its proper outputs and it is specific to a
particular domain.

 In domain testing, we test the software by giving the

appropriate inputs and checking for the expected outputs
from the domain perspective.
 Restrictions of Domain
Testing

Coincidental Correctness

Representative Outcome

Simple Domain Boundaries And Compound Predicates

Functional Homogeneity Of Bugs

Linear Vector Space

Loop Free Software

 Coincidental Correctness
Domain testing assumes that if an input passes, the system behaves correctly.
However, some incorrect inputs may still produce expected outputs by chance.
Example:

 A grading system takes marks (0–100) and assigns grades:

A (90–100), B (80–89), etc.

 If the logic mistakenly assigns A to all inputs above 50, testing with values
90 and 95 will pass, even though values like 51 or 60 also wrongly get an A.

“ The test incorrectly assumes correctness.”

 Representative Outcome
Domain testing assumes that testing boundary values is enough to catch all
errors. However, some defects occur in the middle of a range and remain
undetected.

Example:

A discount system applies a 10% discount for amounts between 1000 and
5000.

Boundary values (1000, 5000) are tested and work fine.

However, an error occurs at 2500 (mid-range) where the system mistakenly

applies a 15% discount instead of 10%.

Domain testing at boundaries misses this issue.

Simple Domain Boundaries and Compound Predicates
Domain testing is effective for simple conditions but struggles when inputs
depend on multiple conditions (compound predicates).

Example:

A loan eligibility system requires:

Age > 21

Salary > 30,000

Testing age separately and salary separately might pass.

But testing (Age = 22, Salary = 25,000) fails, and domain testing misses this.

This happens because conditions are interdependent, not independent.

Functional Homogeneity of Bugs

Domain testing assumes all errors behave the same way, but in
reality, different types of bugs behave differently and require different
test strategies.

Example:

A banking app has two different calculations:

Interest Calculation (Formula error)

Loan EMI Calculation (Data type error)

A domain test covering valid/invalid values might catch one type but
miss the second since the bugs behave differently.
Linear Vector Space

Domain testing works well with linear numeric inputs but struggles
with nonlinear relationships.

Example:

A fuel efficiency calculator (Miles per Gallon) is not a simple

function:
At high speeds, fuel efficiency drops sharply.

At low speeds, it may increase non-linearly.

Testing only linear points (20 mph, 40 mph, 60 mph) might miss
nonlinear behaviors between these speeds.
Loop-Free Software

Domain testing assumes the code is loop-free, meaning every

test input runs the same way. However, loops can alter execution.

Example:

A password checker limits 3 failed attempts before blocking

access.

If you test valid and invalid passwords once, the test passes.

But if you enter an invalid password three times, the system

blocks the user.

“ Domain testing does not account for this scenario.”