**Software Testing Methodologies - Detailed Notes (10 Marks | 20 Pages)
Topic: Transaction Flow Testing & Dataflow Testing**
Unit: Transaction Flow Testing
1. Introduction to Transaction Flow Testing
Transaction flow testing is a white-box testing technique used to test logical control flows in software
through user-initiated transactions. It is particularly useful in business applications where multiple
transaction paths exist. It ensures the correctness of software logic for each transaction.
2. What is a Transaction?
• A transaction is a user-initiated operation that performs a meaningful task in a system.
• Examples: Login, Booking a Ticket, Processing a Payment.
3. Transaction Flow Graph (TFG)
• A directed graph representing the logical flow of a transaction.
• Nodes: processing steps or decisions
• Edges: control flow between nodes
• Used to visualize all possible paths of a transaction.
4. Steps to Perform Transaction Flow Testing
1. Identify all possible user transactions.
2. Construct Transaction Flow Graphs.
3. Select test paths from TFG.
4. Sensitize paths using test inputs.
5. Instrument the code for monitoring.
6. Design supporting test database.
7. Execute tests and analyze results.
5. Transaction Flow Testing Techniques
5.1. Get to the Transaction Flow
• Understand the application’s functionality.
• Identify all key transaction points.
5.2. Inspection, Reviews, and Walkthroughs
• Peer reviews and walkthroughs to detect logical and control flow issues.
• Helps refine TFG.
1
5.3. Path Selection
• Select important paths that need to be tested.
• Use basis path testing and cyclomatic complexity.
5.4. Path Sensitization
• Provide inputs that force the execution of a specific path.
• Ensures that selected paths are reachable.
5.5. Path Instrumentation
• Insert monitoring statements into the code to trace path execution.
• Helps verify test coverage.
5.6. Design and Maintain Test Database
• Prepare input data sets that reflect real-world scenarios.
• Include both valid and invalid test data.
5.7. Test Execution
• Run the selected test paths.
• Monitor which path was executed.
• Compare actual and expected outputs.
6. Example: Login Transaction
Start -> Enter Username -> Enter Password -> Validate
-> [Valid -> Dashboard]
-> [Invalid -> Error Message -> Retry]
• Paths:
• Valid login
• Invalid login
• Retry scenario
7. Benefits of Transaction Flow Testing
• Detects control flow defects
• Improves logic coverage
• Useful for high-risk transaction paths
8. Summary Table
Technique Purpose
TFG Visualize flow
2
Technique Purpose
Reviews & Walkthroughs Detect logical flaws
Path Selection Choose effective test paths
Path Sensitization Provide inputs to activate path
Instrumentation Monitor path execution
Test DB Provide required inputs
Test Execution Run and validate selected paths
Unit: Dataflow Testing
1. Introduction to Dataflow Testing
Dataflow Testing is a white-box testing technique focused on the lifecycle of variables in the program. It
targets definition, usage, and killing (deactivation) of variables.
2. Basics of Dataflow Testing
• Analyzes the flow of data between variables and operations.
• Checks if variables are properly defined, used, and killed.
• Prevents issues like:
• Use of undefined variables
• Redefinition without use
• Defined but unused variables
3. Key Terms in Dataflow Testing
Term Meaning
Definition Variable assigned a value
Usage Variable used in a computation or condition
Kill Variable goes out of scope or redefined
DU Pair Definition-Use pair
4. Dataflow Testing Criteria
4.1. All-Defs Criterion
• Every variable definition must be used at least once.
3
4.2. All-Uses Criterion
• For each definition, all uses must be tested.
4.3. All DU-Paths Criterion
• All possible definition-use paths must be tested.
4.4. All P-Uses and C-Uses
• P-Use: Predicate Use (in conditions)
• C-Use: Computation Use (in expressions)
5. Strategies in Dataflow Testing
5.1. Identify Variables
• List all variables used in the code.
5.2. Create Control Flow Graph (CFG)
• CFG represents the execution flow with nodes and edges.
5.3. Determine DU Pairs
• Mark where each variable is defined and used.
5.4. Select DU Paths
• Create test cases that cover each DU pair.
5.5. Sensitize Paths
• Choose inputs to activate these paths.
5.6. Execute and Analyze
• Run tests, verify outputs, and check coverage.
6. Example of DU Pair
int x = 5; // Definition (d)
if (x > 0) // Predicate Use (p-use)
y = x + 1; // Computation Use (c-use)
• DU Pairs: (d, p-use), (d, c-use)
4
7. Application of Dataflow Testing
• Critical in safety-sensitive systems (e.g., medical, automotive).
• Ensures no unintended side effects or data leaks.
• Helps in static analysis tools.
8. Comparison: Transaction Flow vs Dataflow Testing
Feature Transaction Flow Testing Dataflow Testing
Focus Control flow of transactions Variable usage and behavior
Tools Used Flow graphs, instrumentation DU pair analysis, CFG
Best For Business systems Logic-heavy or secure systems
Detects Logical path errors Data-related bugs
9. Advantages of Dataflow Testing
• Finds deep data-related defects
• Improves code optimization
• Ensures correctness of variable usage
10. Limitations
• Requires full access to source code
• Complex for large systems
• Needs automated tools for better management
11. Tools for Dataflow Testing
• CodeSonar
• KLEE
• GCC Dataflow Plugin
12. Conclusion
Dataflow and Transaction Flow Testing are powerful white-box testing methods. While transaction flow
focuses on the logical flow of user operations, dataflow testing emphasizes the correct handling of data
inside the code. Both help in building robust and error-free systems.
Unit: Domain Testing
Domain testing is a white-box and black-box testing approach that focuses on selecting test cases from the
domain of input data. It ensures that the software behaves correctly for every valid input and gracefully
handles invalid inputs.
5
1. Domain and Path
• Domain refers to the range of input values a function can accept.
• Path refers to the execution path the program takes based on the inputs.
• Domain testing involves testing inputs that trigger different program paths.
2. Nice and Ugly Domains
• Nice domains: Input values that are typical and expected, where the system behaves correctly.
• Ugly domains: Input values at boundaries or unexpected ranges that may cause errors or expose
hidden bugs.
• Testing both ensures robustness.
3. Domain Testing
• Focuses on selecting representative values from input domains.
• Helps reduce the number of test cases by choosing meaningful inputs (like boundary values).
• Techniques:
• Boundary Value Analysis
• Equivalence Partitioning
4. Domain and Interface Testing
• Tests the interactions between modules or components.
• Checks whether data is properly passed and interpreted between domains.
• Detects mismatches, conversion errors, and integration bugs.
5. Domain and Testability
• Refers to how easy it is to design and execute tests for a domain.
• Well-defined domains lead to better testability.
• Complex or overlapping domains may reduce test effectiveness and clarity.
6. Summary
Domain testing is essential for ensuring correctness in programs that rely heavily on varied input types. By
exploring different parts of the input space, especially edge cases, we can uncover subtle bugs and improve
software reliability.
