TRANSACTION FLOW TESTING Transaction flows are introduced as a representation of system\u2019s processing.
\ue000
Transaction Flow testing are to the independent system what control flow were to the programmer
\ue000
\ue000
Control Flow graph- Structural model
Transactional Flow graph - Model of the structure of the system\u2019s behavior .
\ue000
SOME BASICS OF TRANSACTION FLOW \ue000
Transaction
\ue000
Usage
\ue000
Implementation
\ue000
Perspective
TRANSACTION \ue000
UNIT OF WORK SEEN FROM SYSTEM USER\u2019S VIEW
Sequence of operations, some of which are performed by system, persons, or devices that are outside of the system.
\ue000
Begin with BIRT H i.e. they are created as a result of so external act.
\ue000
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 cent computer to minimize comm. line usage. Form is translated by the terminal control PC to be displaye 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 CANCEL P 1
RE-ORDER
USER START
D1 TYPE 1
REQUEST ORDER FROM THE CPU
A
P5 B
TRANSMIT
PAGE TO TERMINAL
P9 D
WAIT FOR CPU TO CONFIRM
WAIT
P6 C
P10 ACCEPT CPU CONFIRM
P 3
P 2
D2
P7 ACCEPT FIELD INPUT
WAIT
P 4
ACCEPT ORDER FROM THE CPU
PROCESS FORM
YES
ANY MORE FIELDS
B
P8 NO
TRANSMIT ANSWERS TO CPU
D3 YES
VALID ?
NO
MORE PAGES ?
NO
NO
USER WANTS REVIEW ?
EXIT
P12 TRANSMIT DIAGNOSTIC TO TERMINAL
EXIT
YES
SET UP REVIEW
D
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. Th 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 proc
Transaction then moves to C , then either D or E , and fin output processing.
IMPLEMENTATION- TRANSACTION FLOW D
INPUT
S
A
S
B
S
C
S
S
TRANSACTION FLOW
INPUT QUEUE
FRONT END
PROCESS QUEUES
A PROCESSOR
E
OUTPUT QUEUE
EXECUTIVE/HANDLER/DISPATCHER/ OPERATING SYSTEM
B PROCESSOR
C PROCESSOR
D PROCESSOR
E PROCESSOR
OUTPUT MODULE
DISPATCHER QUEUES
Application Processes
SYSTEM CONTROL STRUCTURE
1
DO ALL B'S
DISC READS
DO C'S
TAPE WRITES
3
DO D'S
DISC READS
DO A'S
TAPE READS
EXECUTIVE/ DISAPTCHER FLOWCHART
DO NEW B'S
DISC WRITES
3
DO E'S
DISC WRITES
1
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 afte 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 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. 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 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 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 graph can be complicated processes in their own rights. Third difference is the effect of interrupts in our transaction 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 (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
Absorption : A predator transaction absorbs a prey and pred is retained, however, prey is gone. Therefore this process is called Absorption (figure)
Conjugation : In this , the parent transactions merge to form new daughter. This is called Conjugation (figure)
PARENT
ALTERNATE 1
DAUGHTER
Parent Parent
DAUGHTER
DAUGHTER
ALTERNATE 2
MITOSIS DECISION
BIOSIS
Assumptions
Assume that the transaction flow model is imperfect but tha 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 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 flo 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 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 involve loops, decisions and so on. Parts of the flows may incorporate the behavior of other systems 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 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.
WALKTHROUGHS
Discuss enough transaction types i.e. paths through transacti 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 show how the transaction, directly or indirectly, follows from the requirement.
WALKTHROUGHS
Select additional flow paths beyond C1 + C2 for loops, extr values, and domain boundaries.
Select additional paths for weird cases and very long, poten troublesome transactions with high risks and potential consequential damage.
Design more test cases to validate all births and deaths an search for lost daughters, illegitimate births, and wrongful deaths.
Publish and distribute the selected set of test paths through 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 function 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 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 segment 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 externa 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 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 wher 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 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 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 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.
