Unit 2 – Transaction Flow Testing

Compiled with reference from:

Software Testing Techniques: Boris Beizer
Craft of Software Testing: Brain Marrick
 Transaction-Flow Testing U2

We will see in this part of Unit 2:

• Concepts of Transaction flows

• Transaction-flow testing

ref boris beizer 2

 Transaction-Flow Testing U2

Contents

1. Definitions of Transaction, Transaction flow, Transaction flow graph

2. It’s representation, implementation architecture in an O.S. & implementation in a system
3. A perspective of TFG model. View wrt DFG, CFG

4. Handling cases – decisions, biosis, mitosis, transactional junction, absorption & conjugation
5. TFG is not structured - Reasons

Transaction Flow Testing Techniques

1. Building transaction flows

2. Inspections, Reviews, and walkthroughs
3. Path selection
4. Path sensitization
5. Instrumentation
6. Test data bases

7. Test Execution

8. Transaction-flow implementation & testing related comments

1. Translation based systems
2. Hidden languages
ref boris beizer 3
 Definitions of Transaction,Transaction-flow, TFG U2

Transaction-flow

Transaction-flow represents a system’s processing. Functional testing methods are

applied for testing T-F.

Transaction-flow Graph

TFG represents a behavioral (functional) model of the program (system) used for
functional testing by an independent system tester.

Transaction

• is a unit of work seen from system’s user point of view.

• consists of a sequence of operations performed by a system, persons or external

devices.

• is created (birth) due to an external act & up on its completion (closure), it

remains in the form of historicalref
records.
boris beizer 4
 A Simple Transaction U2-B

Example: the sequence of steps in a transaction in an online information retrieval system

1. accept inputs 7. Accept Inputs

2. Validate inputs (Birth of tr.) 8. Validate inputs

3. Transmit ack. to the user 9. Process the request

4. Process input 10. Update file

5. Search file 11. Transmit output

6. Request direction from user 12. Record transaction in log & cleanup
(Closure)

Users View of a transaction : Single step

Systems view : Sequence of many operations

ref boris beizer 5

 Example of a Transaction flow (diagram) U2

User (terminal) Terminal controller CPU

cancel

User Request order Request Accept

Process B
Begin Type order Order from
Form
from CPU CPU

help

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

CPU- Y N N
More User wants Done
D Accept Valid ?
Pages ? Review?
Confirm

Transmit Set up
Diagnostic C Review
to Terminal
ref boris beizer 6
 Definitions U2

Transaction-flow Graph : a scenario between users & computer

Transaction-flow : an internal sequence of events in processing a transaction

Uses of Transaction-flow

Specifying requirements of big, online and complicated systems.

Airline reservation systems, air-traffic control systems.

Loops are less as compared to CFG. Loops are used for user input error processing

ref boris beizer 7

 Implementation of Transaction-Flow (in a system) U2

• 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
ref boris beizer 8
 Implementation of Transaction-Flow U2

System Control Structure (architecture of the implementation) :

Input Output
Queue EXECUTIVE Queue
Front Output
End SCHEDULER - AND / OR OPERATING SYSTEM Module
DISPATCHER

Process
Queues A Processor B Processor C Processor D Processor E Processor

Application Processes

Executive / Dispatcher Flowchart (a sample sequence)

Disc Tape Disc

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

Disc Tape Disc

2 Do All D’s Do All A’s Do All E’s 1
Reads Reads Writes

ref boris beizer 9

 Implementation of Transaction-Flow U2

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 :

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

2. It may contain routing information only in tables.

3. Scheduler contains no code / data. Processing modules contain code for routing.

ref boris beizer 10

 Implementation of Transaction-Flow U2

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.

ref boris beizer 11

 A perspective of Transaction-Flow U2

Transaction-flow testing is a block box technique. (as we assumed nothing regarding

computer, communications, environment, O.S., transaction identity or structure or state.)

1. TFG is a kind of DFG.

• TFG has tokens, & DFG has data objects with history of operations applied on them.

• Many techniques of CFG apply to TFG & DFG

2. Decision nodes of TFG have exception exits to the central recovery process.

3. So, we ignore the effect of interrupts in a Transaction-flow.

ref boris beizer 12

 Transaction Flows – splitting & merging decisions U2-B

Splits of transactions (Births)

Alternative 2
1. A decision point in TFG

Alternative 1

2. Biosis Parent
Parent

Daughter Tr.

Daughter Tr.
3. Mitosis Parent

Daughter Tr.

13 ref boris beizer

 Transaction Flows – splitting & merging decisions U2

Mergers of transactions
Path 1

1. Junction Continue

Path 2

Daughter Tr.
2. Absorption
Predator

Predator

3. Conjugation
Parent Daughter

Parent

14 ref boris beizer

 TFG – splitting, merging Transactions U2

NOTES:

• Multiple meanings now for decision and junction symbols in a TFG.

• Simple TFG model is not enough to represent multi-processor

systems & associated coordination systems.

• Petrinet model uses operations for all the above. But Petrinets are
applied to H/W, N/W protocol testing – but not Software.

15 ref boris beizer

 Simplified TFG model U2

Simplify TFG model

• Add New Tr-Flows for Biosis, Mitosis, Absorption, Conjugation

• Problems for programmer, designer & test designer.

• Need to design specific tests – possibility of bugs.

16 ref boris beizer

 Transaction-flow Structure U2-B

Reasons for Unstructuredness

1. Processes involve Human Users

2. Part of Flow from External Systems

3. Errors, Failures, Malfunctions & Recovery Actions

4. Transaction Count, Complexity. Customer & Environment

5. New Transactions, & Modifications

6. Approximation to Reality

17 ref boris beizer

 Transaction - Flow Testing - Steps U2-B

First, Build / Obtain Transaction Flows

• Represent Explicitly

• Design details the Main Tr-Flows

• Create From PDL

• HIPO charts & Petrinet Representations

Objective – Trace the transaction

18 ref boris beizer

 Transaction - Flow Testing - Steps U2-B

1. Inspections, Reviews & Walkthroughs

Start From Preliminary Design

1. Conducting Walkthroughs

• Discuss enough Transaction Types (98%

( Transactions)

• User needs & Functional terms (Design independent)

• Traceability to Requirements

19 ref boris beizer

 Transaction - Flow Testing - Steps U2-B

1. Inspections, Reviews & Walkthroughs …

2. Design Tests for C1 + C2 coverage

3. Additional Coverage (> C1+C2)

• Paths with loops, extreme values, domain boundaries

• Weird cases, long & potentially troublesome Tr.

4. Design Test cases for Tr. Splits & mergers

5. Publish Selected Test Paths early

6. Buyer’s Acceptance – functional & acceptance tests

20 ref boris beizer

 Transaction - Flow Testing Techniques U2-B

2. Path Selection

1. Covering Set (C1+C2) of Functionally Sensible Tr.

2. Add Difficult Paths

• Review with designers & implementers

• Exposure of interface problems & duplicated processing

• Very few Implementation bugs may remain

Transaction-flow Path Covering Set belongs in

System Feature Tests

21 ref boris beizer

 Transaction - Flow Testing Techniques U2-B

3. Sensitization

1. Functionally Sensible Paths – Simple

2. Error, Exception, External Protocol Interface Paths - Difficult

Testing Tr.–Flows with External Interfaces

• Use patches & break points, mistune, and break the rules,

22 ref boris beizer

 Transaction - Flow Testing Techniques U2-B

4. Instrumentation

1. Link Counters are not Useful.

2. Need

• Trace

• Queues on which Tokens resided

• Entries to & Exits from Dispatcher

• A Running Log

Make Instrumentation as part of System Design

23 ref boris beizer

 Transaction - Flow Testing Techniques U2-B

5. 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)

Need experienced System & Test Designers

24 ref boris beizer

 Transaction - Flow Testing Techniques U2-B

6. Test Execution

1. Use Test Execution Automation

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

25 ref boris beizer

 Transaction - Flow Testing - Implementation U2-B

1. Transaction based systems

• TCB

1. Centralized, Common Processing Queues

• Just O(n) Queues for Links of O(n2)

2. Transaction Dispatcher
• Uses tables & Finite State Machines

3. Recovery & Other Logs

• Key events in Tr – Flow

4. Self-Test Support
• Privileged modes in Transaction control tables
26 ref boris beizer
 Transaction - Flow Testing - Caution U2-B

Hidden Languages (flow control language)

• Transaction Flows based on control codes in TCB or DB

• Undeclared. Syntax & Semantics are not debugged.

• Possibility of bugs

27 ref boris beizer