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.

Domain Testing: Domains and Paths, Nice & Ugly Domains, Domain testing, Domains and Interfaces Testing, Domain and Interface Testing, Domains and Testability.

TRANSACTION FLOW TESTING

INTRODUCTION:

 A transaction is a unit of work seen from a system user's point of view.

 A transaction consists of a sequence of operations, some of which are performed by a system, persons or devices that are outside of the system.

 Transaction begins with Birth-that is they are created as a result of some external act.

 At the conclusion of the transaction's processing, the transaction is no longer in the system.

 Example of a transaction: A transaction for an online information retrieval system might consist of the following steps or tasks:
o Accept input (tentative birth)
o Validate input (birth)
o Transmit acknowledgement to requester
o Do input processing
o Search file
o Request directions from user
o Accept input
o Validate input
o Process request
o Update file
o Transmit output
o Record transaction in log and clean up (death)

 TRANSACTION FLOW GRAPHS:

o Transaction flows are introduced as a representation of a system's processing.
o The methods that were applied to control flow graphs are then used for functional testing.
o Transaction flows and transaction flow testing are to the independent system tester what control flows are path testing are to the programmer.
o The transaction flow graph is to create a behavioral model of the program that leads to functional testing.

o The transaction flow graph is a model of the structure of the system's behavior (functionality).

1
 o An example of a Transaction Flow is as follows:

Figure 3.1: An Example of a Transaction Flow

 USAGE:
o Transaction flows are indispensable for specifying requirements of complicated systems, especially online systems.
o A big system such as an air traffic control or airline reservation system has not hundreds, but thousands of different transaction flows.
o The flows are represented by relatively simple flowgraphs, many of which have a single straight-through path.

o Loops are infrequent compared to control flowgraphs.

o The most common loop is used to request a retry after user input errors. An ATM system, for example, allows the user to try, say three times, and will
take the card away the fourth time.

2
  COMPLICATIONS:
o In simple cases, the transactions have a unique identity from the time they're created to the time they're completed.
o In many systems the transactions can give birth to others, and transactions can also merge.

I. 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. (See Figure 3.2 (a))

2. Biosis: Here the incoming transaction gives birth to a new transaction, and both transaction continue on their separate paths, and the parent
retains it identity. (See Figure 3.2 (b))
3. Mitosis: Here the parent transaction is destroyed and two new transactions are created.(See Figure 3.2 (c))

Figure 3.2: Nodes with multiple out links

II. 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: 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. (See Figure 3.3 (a))

2 Absorption: In absorption case, the predator transaction absorbs prey transaction. The prey gone but the predator retains its identity. (See Figure 3.3
(b))

3 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.(See Figure 3.3 (c))

Figure 3.3: Transaction Flow Junctions and Mergers

We have no problem with ordinary decisions and junctions. Births, absorptions, and conjugations are as problematic for the software designer as they are for
the software modeler and the test designer; as a consequence, such points have more than their share of bugs. The common problems are: lost daughters,
wrongful deaths, and illegitimate births.

3
TRANSACTION FLOW TESTING TECHNIQUES:

 GET THE TRANSACTIONS FLOWS:

 Complicated systems that process a lot of different, complicated transactions should have explicit representations of the transactions flows,
or the equivalent.
 Transaction flows are like control flow graphs, and consequently we should expect to have them in increasing levels of detail.
 The system's design documentation should contain an overview section that details the main transaction flows.
 Detailed transaction flows are a mandatory pre requisite to the rational design of a system's functional test.

 INSPECTIONS, REVIEWS AND WALKTHROUGHS:

 Transaction flows are natural agenda for system reviews or inspections.

 In conducting the walkthroughs, you should:
o Discuss enough transaction types to account for 98%-99% of the transaction the system is expected to process.

o Discuss paths through flows in functional rather than technical terms.

o 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.
o 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

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 the most tortuous, longest, strangest path from the entry to the exit of the transaction flow.

 PATH SENSITIZATION:

 Most of the normal paths are very easy to sensitize-80% - 95% transaction flow coverage (c1+c2) is usually easy to achieve.

 The remaining small percentage is often very difficult.

 Sensitization is the act of defining the transaction. If there are sensitization problems on the easy paths, then bet on either a bug in transaction
flows or a design bug.

 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.

4
Basics of Data Flow Testing

Introduction to Data Flow Testing

Data Flow Testing is a structural (white-box) testing technique that focuses on the life cycle of data objects in a program.
It selects test paths based on definitions, uses, and killings of variables rather than only control flow.

The main objective is to ensure that:

 Every data object is defined before it is used

 No data object is used after it is killed

 All computed values are actually used

Data Flow Machines

Data flow behavior depends on machine architecture.

a) Von Neumann Machine

 Instructions and data stored in the same memory

 Executes one instruction at a time

Execution cycle:

Fetch → Decode → Fetch Operands → Execute → Store Result → Increment PC

b) MIMD (Multi-Instruction, Multi-Data) Machines

 Executes multiple instructions simultaneously

 Performs operations on different data objects in parallel

 Execution sequence depends on the compiler

 DATA FLOW GRAPHS:

 The data flow graph is a graph consisting of nodes and directed links.
 We will use a control 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.

5
 Figure 3.4: Example of a data flow graph

 Data Object State and Usage:

o Data Objects can be created, killed and used.
o 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)
1. Definition (d)
An object is defined when:
Declared
Appears on LHS of assignment
Memory is allocated
File is opened
Record is written

2. Killed or Undefined (k)

An object is killed when:
Memory is released
File is closed
Stack item is popped
Value is lost or becomes unknown

3. Usage (u)
An object is used in two ways:
6
 c (computational use) – RHS of expression
p (predicate use) – used in conditions (IF, WHILE)
Data Flow Anomalies
A data flow anomaly is a suspicious or erroneous sequence of actions on a data object.
Anomalies are represented by two-letter sequences of d, k, and u.
Common Anomalies Table

Sequence Meaning Interpretation

dd Defined twice Suspicious

dk Defined then killed Bug

du Defined then used Correct

ku Killed then used Bug

uu Used repeatedly Normal

Single-Letter Anomalies
A dash (–) indicates no prior or subsequent action.
Examples:
 –u : Use without definition (possibly anomalous)
 d– : Defined but not used
 u– : Used but not killed (may indicate memory leak)
DATA FLOW ANOMALY STATE GRAPH:
Data flow anomaly model prescribes that an object can be in one of four distinct states:

0. K :- undefined, previously killed, does not exist

1. D :- defined but not yet used for anything

2. U :- has been used for computation or in predicate

3. 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.

Figure 3.5: Unforgiving Data Flow Anomaly State Graph

Forgiving Data - Flow Anomaly Flow Graph: Forgiving model is an alternate model where redemption (recover) from the anomalous state is possible

Figure 3.6: Forgiving Data Flow Anomaly State Graph

7
 Strategies of Data Flow Testing

1. All-du-Paths Strategy (ADUP)

(Strongest Strategy)
Definition
This strategy requires that every du-path from every definition of a variable to every possible use be executed by at least
one test case.
Key Points
Covers all definition–use combinations
Includes both c-uses and p-uses
Ensures maximum data flow coverage
Advantages
Very effective in detecting data anomalies
High confidence in variable usage correctness
Disadvantages
Large number of test cases
Difficult to apply for large programs

2. All Uses Strategy (AU)

Definition
For each definition of a variable, at least one definition-clear path to every reachable use (either c-use or p-use) must be
tested.
Key Points
Less strict than ADUP
Does not require all du-paths
Focuses on meaningful uses only

Advantages
Fewer test cases than ADUP
Practical and widely used
Limitation
Some paths may remain untested
3. All Predicate Uses / Some Computational Uses (APU + C)
Definition
For every definition, test all predicate uses
If a definition has no predicate use, then include at least one computational use
Key Points
Gives importance to decision-making logic
Suitable for control-intensive programs
Advantages
Ensures correctness of conditional statements
Balanced test effort
4. All Computational Uses / Some Predicate Uses (ACU + P)
Definition
For each definition, test all computational uses
If no computational use exists, include one predicate use
Key Points
Focuses on calculations and expressions
Useful for computation-heavy programs
Comparison
Weaker than APU + C in decision logic coverage
5. All Definitions Strategy (AD)
Definition
Each definition of a variable must reach at least one use (either c-use or p-use).
Key Points
Simplest data flow strategy
Ensures no definition is completely unused
Advantages
Easy to apply
Requires minimal test cases
Limitation

8
 Weak coverage
Many bugs may remain undetected
6. All Predicate Uses (APU)
Definition
Tests paths so that all predicate uses of each variable are covered.
Use Case
Logic-driven systems
Decision-based software
7. All Computational Uses (ACU)
Definition
Ensures all computational uses of each variable are executed.
Use Case
Numerical and formula-based applications

All-du Paths (ADUP)

The all-du-paths strategy is the strongest data flow testing strategy
It requires that every du path form every definition of every variable to every use of that definition be exercise 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)

For Variable z
The situation for variable z (image) is more complicated because the variable is redefined in many places

For the definition on link (1, 3) we must exercise paths that include sub paths (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 and 4) and (5, 6, 7 and 8)

9
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

Related:Path Sensitizing in Software Testing

In image, ADUP requires that we include sub paths (3,4,5) and (3,5) in some tests 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 the image shown below

10
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

For variable Z

In image 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 a ll variables in this example - it only takes two test

11
For variable V

In image, APU + C is achieved for V by (135678, 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

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

For variable z
12
In image 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
definition 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

All Definition 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

Related:Testing Blindness in Software Testing

Path(1,3,4,5,6,7,7....) 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

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

13
14
15