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 (C1 + C2) 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 (C1 + C2) 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 (C1 + C2) needs execution automation without which you cannot get it right
0 comments:
Post a Comment