Common Mechanisms of UML

Transaction Flow Testing Techniques

Get the Transaction Flows:

v  Complicated systems that process a lot of different, complicated transactions, should have explicit representations of the transactions flows or the equivalent

v  Transaction flows are like control flow graphs, and consequently, we should expect to have them in increasing levels of details

v  The systems design documentation should contain an overview section, that details the main transaction flows

v  Detailed transaction flows are a mandatory prerequisite to the rational design of a systems functional test

Inspections, Reviews and Walkthroughs:

v Transaction flows are natural agenda for system reviews or inspections

v In conducting the walkthrough, you should:

v Discuss enough transaction types to account for 98%-99% of the transaction, the system is expected to process

v Discuss paths through flows in functional rather than technical terms

v Ask the designers to relate every flow to the specification and to show how that transaction, directly or indirectly, follows from the requirements

v Make transaction flow testing the corner stone of system functional testing, just as path testing is the corner stone of unit testing

v Select additional flow paths for loops, extreme values, and domain boundaries

v Design more test cases to validate all births and deaths

v 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

v  Select a set of covering paths (C₁ + C₂) using the analogous criteria you used for structural path testing

v  Select a covering set of paths based on functionally sensible transactions as you would for control flow graphs

v  Try to find most tortuous, longest, strongest path from the entry to the exit of the transaction flow

Path Sensitization

v Most of the normal paths are very easy to sensitize. 80% - 95% transaction flow coverage (C₁ + C₂) is usually easy to achieve

v The remaining small percentage is often very difficult

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

Path Instrumentation

v  Instrumentation plays a bigger role in transaction flow testing than in unit path testing

v  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

v  In some systems, such traces are provided by the operating systems or a running log

Design and Maintain Test Database

v  Design and maintenance of the test databases constitute about 30% to 40% of the effort in transaction flow test design

v  People are often unaware that a test database needs to designed

v  Test databases must be centrally administrated and configuration controlled with a comprehensive design plan

v  Creating a comprehensive test databases is itself a big project on its own

v  It requires talented, matured, and diplomatic designers who are experienced in both system design and test design

Test Execution:

v  Commit to automation of test execution if you want to do transaction flow testing for a system of any size

v  If the numbers of test cases are limited, you need not worry about test execution automation

v  If the number of test cases run into several hundred, performing transaction flow testing to achieve (C₁ + C₂)  needs execution automation without which you cannot get it right