TRANSACTION FLOW TESTING

Transaction flows are introduced as a representation of a system’s processing.

Transaction Flow testing are to the independent system tester what control flow were to the programmer

Control Flow graph- Structural model Transactional Flow graph - Model of the structure of the

system’s behavior .

SOME BASICS OF TRANSACTION FLOW

Transaction Usage Implementation Perspective

TRANSACTION

UNIT OF WORK SEEN FROM SYSTEM USER’S VIEW POINT Sequence of operations, some of which are performed by a

system, persons, or devices that are outside of the system. Begin with BIRTH i.e. they are created as a result of some

external act.

AN EXAMPLE- Online Information Retrieval System

Access Input ( Tentative Birth) Validate Input (Birth) Transmit acknowledgement to requester Do Input processing Search File Request directions from the user Accept Input Validate Input Process request Update file Transmit output Record transaction in log and cleanup ( Death) User viewpoint- Single Transaction; System viewpoint – 12

steps and ten subsidiary tasks

OVERVIEW: Online Information Retrieval System

PC - Terminal controller for several dumb terminals Terminals- used to process forms User specifies the desired action, and terminal controller requests

the appropriate form from a remote central computer. Forms- Several pages long, contains multiple fields. Compressed version of form is then transmitted by the central

computer to minimize comm. line usage. Form is translated by the terminal control PC to be displayed by

dumb terminal. Terminal control only transmits the answers (contents of the

blanks) back to the central computer As each page of the Form is filled out, terminal controller transmits

the answers to the central computer, which either accepts or rejects them. If the answers are invalid, a diagnostic code is transmitted by the central computer to the terminal controller, which in turn translates the code and informs the user at the terminal. Finally, the system allows the user to review the filled out form.

Online Information Retrieval System

USERSTART

1D 1TYPE A

REQUEST ORDER FROM THE CPU

WWWWACCEPT

ORDER FROM THE CPU

PROCESSFORM

B

BTRANSMIT

PAGE TOTERMINAL

W WAIT ACCEPT FIELD

INPUT ANY MORE

FIELDSTRANSMIT

ANSWERS TO CPUW

W WAIT FOR CPU TO

CONFIRM

ACCEPT CPUCONFIRM

W? MORE PAGES ?

USERWANTS

REVIEW ?WWWW

TRANSMITDIAGNOSTIC

TO TERMINALEXIT SET UP REVIEW

CANCEL

-RE ORDER 1P 2P 3P 4P

5P 6P2D YES

NO

7P 8P

NONO

9P 103D

YES

NO12

YES

ANALYSIS: Online Information Retrieval System

Process P1: Several subsidiary processes accomplished by the transmission of the request for an order from the central computer.

Process P2, P6: Wait states for input. P3, P4: Real processing steps. D2, D4 : Decisions dependent on program structure. Which

branch is taken at D3 is determined by user’s behavior.

USAGE- Transaction Flow Testing

Indispensable for specifying requirements of complicated systems, especially online systems

Big system has thousands of transaction flows. The flows are represented relatively smaller flow graphs.

Loops are infrequent as compared to Control flow graphs. The most common loop is RETRY after user provide incorrect inputs repeatedly.

IMPLEMENTATION

Transaction Flow: Representation of a path taken by a transaction through a succession of processing modules( token) such as a transaction control block that is passed from routine to routine as it progresses through its flow.

IMPLEMENTATION- An Example

This transaction goes through input processing which determines its type and then goes through processes A and B.

Result of B may force the transaction to pass back to process A. Transaction then moves to C , then either D or E , and finally to

output processing.

IMPLEMENTATION- TRANSACTION FLOW

INPUT S A S B S C S

D

E

S

FRONT ENDEXECUTIVE/HANDLER/DISPATCHER/

OPERATING SYSTEMOUTPUTMODULE

OUTPUT QUEUE INPUT QUEUE

APROCESSOR

BPROCESSOR

CPROCESSOR

DPROCESSOR

EPROCESSOR

PROCESS QUEUES

DISPATCHER QUEUES

TRANSACTION FLOW

Application Processes

SYSTEM CONTROL STRUCTURE

DO ALLB'S

DOD'S

DISCREADS

DISCREADS

DO C'S

DOA'S

TAPEWRITES

TAPEREADS

DO NEWB'S

DOE'S

1

3

DISCWRITES

DISCWRITES

3

1

EXECUTIVE/ DISAPTCHER FLOWCHART

ANALYSIS- Implementation

Executive/ Scheduler/ Dispatcher: Controls the system. Processes ( Boxes), Processing Queues( Links). Transaction enters an input processing module in response to

the inputs received, e.g., at a terminal. Transaction is created by the act of filling out input queues

(Figure B) for process A, but process A will not necessarily be activated immediately. When a process has finished working on the transaction, it places the transaction control block on a scheduler queue. The scheduler then examines the transaction control block and routes it to the next process based on the information stored in the block. Scheduler contains tables/ code that routes the transaction to the next process.

ANALYSIS- Implementation

In systems, that handles many hundreds of transaction types, this information is contained in tables rather in code.

Figure C shows possible implementations of this transaction processing system.

There could be different transaction flows in the system, all using processes, A,B,C,D,E, and disc and tape reads and writes, in different combinations. Processing might be in order, B,C,A,E,D, or an other combination. Different combinations may have different Wait priorities depending on the requirement.

SCHEDULER CALLS

Assuming that there’s return of control to the scheduler after each process box.

The whole program is organized as a single loop. First the scheduler invokes processing module B, which cleans up all transactions waiting for B processing at that moment. Then the disc reads are initiated and the scheduler turns control over to module C, which clears up all its tasks.

After the tape writes are initiated, module B is invoked again to take care of any additional work that may have accumulated for it . The process continues and finally the entire loop starts over again.

PERSPECTIVE

In Transaction flow testing we don’t restrict ourselves to no. of computers, it could be SIMD, MIMD, communication could be via data structures, over communication lines, processing queues.

We assume nothing about the system’s executive structure or operating system: interrupt driven, cyclic, multi processing etc.

Transaction flow testing is the ultimate black box technique because all we ask is that there be something identifiable as a transaction and that the system will do predictable things to transaction.

CONTROL FLOW GRAPH vs TRANSACTION FLOW GRAPH

Defining Links (Block) :In control flow graphs we define link as a set of instructions such that if any of them is executed, all (barring bugs) would be executed. For Transaction flow graphs this definition changes to identify all processes of interest (Example 1).

Another difference is that the Decision nodes of transaction flow graph can be complicated processes in their own rights.

Third difference is the effect of interrupts in our transaction flow model. Interrupts can do the equivalent of converting every process box into a many splendored thing with more exit links.

BASICS OF TRANSACTION FLOW GRAPHS

Births Mergers

BIRTHS

Decision Nodes: It depicts that transaction will take either alternative, but not both, This is a decision point of transaction flow.

Biosis : The incoming (Parent) transaction gives birth to a new (Daughter) transaction whence both transactions continue on their separate paths, the parent retaining its identity as a transaction, this process is referred as Biosis.

Mitosis: This is similar to Biosis except that the Parent transaction is destroyed and two new transactions (Daughters) are created. This is referred to as Mitosis.

MERGERS

Transaction flow junction nodes are as complicated as transaction flow splits. Following are some types of Mergers.

Junction : This is similar to junction in control flow graph (figure) Absorption : A predator transaction absorbs a prey and predator

is retained, however, prey is gone. Therefore this process is called Absorption (figure)

Conjugation : In this , the parent transactions merge to form a new daughter. This is called Conjugation (figure)

1ALTERNATE

2ALTERNATE

WWWWWW

WWWWWWWW

DAUGHTER

DECISION BIOSIS

Parent

Parent

DAUGHTER

MITOSIS

Assumptions

Assume that the transaction flow model is imperfect but that the correct model is untried. As with all models, we ignore the complications that can invalidate the model and use what we can apply with ease. After all, models for testing are intended to give us insights into effective test case design- so it doesn’t matter that they are imperfect as long as the testing results are good.

COMPLICATED CASES

Biosis: Follow the parent flow from beginning to end. Treat each daughter as a new flow, either to the end or to the point where the daughter is absorbed.

Mitosis : This situation involves three or more transaction flows: from the beginning of the parent’s flow to the mitosis point and one additional flow for each daughter, from the mitosis point to respective end.

Absorption : Follow the predator as the primary flow. The prey is modeled from its beginning to the point at which it’s eaten.

Conjugation : Three or more separate flows- the opposite of mitosis. From the birth of each parent, proceed to the conjugation point and follow the resulting daughter from the conjugation point to her end.

TRANSACTION FLOWS- ILL STRUCTURES

It’s a model of a process, not just code. Humans may be involved in loops, decisions and so on.

Parts of the flows may incorporate the behavior of other systems over which we might have no control.

The number of transactions and complexities of the individual transaction flows grow over time as features are added and enhanced.

Systems are built out of modules and the transaction flows result from the interaction of those modules. Good system design dictates that we avoid changing modules in order to implement new transactions or to modify existing transactions. The result is that we build new paths between modules, new queues, add modules, and so on, and tie the whole together with ad hoc flags and switches to make it work. We may have to fool existing modules into doing the new job for us- that’s usually preferable to changing many different modules. It’s not unusual to deliberately block some paths in order to use a common part for several different kinds of transaction.

Discuss enough transaction types i.e. paths through transaction flows to account for 98% to 99% of the transactions the system is expected to process. Adjust the time spent and the intensity of the review in proportion to the perceived risk of failing to process each transaction properly. The designers should name the transaction, provide its flowgraph, identify all processes, branches, loops, splits, mergers and so on.

Discuss the paths functionally rather than technically. Ask the designers to relate every flow to the specification and to

show how the transaction, directly or indirectly, follows from the requirement.

WALKTHROUGHS

WALKTHROUGHS

Select additional flow paths beyond C1 + C2 for loops, extreme values, and domain boundaries.

Select additional paths for weird cases and very long, potentially troublesome transactions with high risks and potential consequential damage.

Design more test cases to validate all births and deaths and to search for lost daughters, illegitimate births, and wrongful deaths.

Publish and distribute the selected set of test paths through the transaction flows as early as possible so that they will exert the maximum beneficial effect on the project.

Make the transaction flow testing the cornerstone of functional testing as path testing is the cornerstone of the unit testing. For this one needs to achieve C1 and C2 coverage of the complete set of transaction flowgraphs.

PATH SELECTION

Select a covering set of paths based on functionally sensible transactions.

Try to find the most tortuous, longest, strangest paths from the entry to exit of the transaction flow.

Create a catalog of those weird paths. The act of discussing those weird paths will expose missing interlocks, duplicated interlocks, interface problems, programs working at cross processes, duplicated processing- a lot of stuff that would otherwise have shown up only during the final acceptance tests.

SENSITIZATION

Most normal paths are easy to sensitize- 80% to 95% transaction flow coverage (C1 + C2) are easy to achieve, while simple paths are easy to sensitize there are many of them, so there’s lot of boredom in test design.

How about the off paths, exception conditions, path segments on which we expect to find most of the bugs? The reason these paths are often difficult to sensitize is that they correspond to error conditions, synchronization problems, overload responses, and other anomalous situations.

The biggest challenge is testing a protocol across an external interface. In order to test abnormal paths we may have to ask the other system to simulate bad transactions or failures.Its tough to sensitize such path segments if we are going to be fair about it . It’s not as bad if we are ready to play DIRTY

SENSITIZATION- TAKING THE WRONG SIDE

Use Patches- Put a patch into our system or a patch into the system of external interface. In either case, someone has to put an unrealistic patch.

Mistune - Test a system sized with grossly inadequate resources(5% to 10%). This helps t o force most of the resource related exception conditions.

Break the Rules - Transactions always require correctly specified data structures to support them. Often a system database generator is used to create such objects and to assure that all required objects have been correctly specified. Bypass the database generator and use patches to break all rules that are required to go down the desired path.

Use Breakpoints - put breakpoints at the branch points where hard-to-sensitize path segment begins and then patch the sensitization control block to force that path.

INSTRUMENTATION

Instrumentation plays a bigger role in transaction flow testing as compared to unit path testing.

Recorders, Loggers, OS: information of path taken for a transaction must be kept with that transaction. For this we can use recorders( central dispatcher), loggers and in some communication system such traces can be provided by using operating systems.

Instrumentation can be made part of the system design. Elaborate the design as needed to provide complete transaction flow tracing for all transactions.

EXECUTION

For transaction flow testing of a system of any size, make sure we execute the tests using automation tools from the beginning.

If more than a hundred test cases are required to achieve C1+ C2 transaction flow coverage, you will be running and repeating these transactions not once, but hundreds of times over the project’s life.

Transaction flow testing with the intention of achieving C1 + C2 usually leads to a big ( four or five fold) increase in the number of test cases. Without automated execution it wont be possible to expect correct results.