CHAPTER - 4 Transaction Flow Testing

UNIT II - TRANSACTION FLOW TESTING
 INTRODUCTION:
o A transaction is a unit of work seen from a system user's point of view.
o 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.
o Transaction begin with Birth-that is they are created as a result of some external act.
o At the conclusion of the transaction's processing, the transaction is no longer in the system.
o Example of a transaction: A transaction for an online information retrieval system might consist
of the following steps or tasks:
 Accept input (tentative birth)
 Validate input (birth)
 Transmit acknowledgement 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)
 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 flowgraph is a model of the structure of the system's behavior (functionality).
o An example : Using ATM card in ATM machines
TRANSACTION FLOW GRAPHS
 In simple cases, the transactions have a unique identity from the time they're created to the time they're
completed.
 In many systems the transactions can give birth to others, and transactions can also merge.
 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 outlinks
 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.
Figure 3.3: Transaction Flow Junctions and Mergers

TRANSACTION FLOW TESTING TECHNIQUES:
 GET THE TRANSACTIONS FLOWS:

o Complicated systems that process a lot of different, complicated transactions should have
explicit representations of the transactions flows, or the equivalent.
o Transaction flows are like control flow graphs, and consequently we should expect to have them
in increasing levels of detail.
o The system's design documentation should contain an overview section that details the main
transaction flows.
o Detailed transaction flows are a mandatory pre requisite to the rational design of a system's
functional test.
 INSPECTIONS, REVIEWS AND WALKTHROUGHS:
o Transaction flows are natural agenda for system reviews or inspections.
o In conducting the walkthroughs, you should:
 Discuss enough transaction types to account for 98%-99% of the transaction the
system is expected to process.
 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.
o Make transaction flow testing the corner stone of system functional testing just as path testing
is the corner stone of unit testing.
o Select additional flow paths for loops, extreme values, and domain boundaries.
o 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:
o Select a set of covering paths (c1+c2) using the analogous criteria you used for structural path
testing.
o Select a covering set of paths based on functionally sensible transactions as you would for
control flow graphs.
o Try to find the most tortuous, longest, strangest path from the entry to the exit of the transaction
flow.
 PATH SENSITIZATION:
o Most of the normal paths are very easy to sensitize-80% - 95% transaction flow coverage
(c1+c2) is usually easy to achieve.
o The remaining small percentage is often very difficult.
o 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:
o Instrumentation plays a bigger role in transaction flow testing than in unit path testing.
o 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.
o In some systems, such traces are provided by the operating systems or a running log.
 TEST DATABASES:
o Test Databases must be centrally administered under a comprehensive design plan.
o It will satisfy all testing needs.
o It requires talented, mature diplomatic, and experiences designers to make a test database.
 EXECUTION:
o Transaction flow testing with an intention of achieving C1+c2 coverage usually leads to 4 times
increase in the number of test cases.
o Execution must be made automated with tolls and test drivers.

CHAPTER - 4 Transaction Flow Testing

Uploaded by

Copyright:

Available Formats

CHAPTER - 4 Transaction Flow Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CHAPTER - 4 Transaction Flow Testing

Uploaded by

Copyright:

Available Formats

UNIT II - TRANSACTION FLOW TESTING

TRANSACTION FLOW GRAPHS

Figure 3.3: Transaction Flow Junctions and Mergers

Figure 3.3: Transaction Flow Junctions and Mergers

 GET THE TRANSACTIONS FLOWS:

You might also like