integration testing(revisited)
Post on 25-May-2015
1.497 views
Embed Size (px)
TRANSCRIPT
- 1. INTEGRATION AND SYSTEM TESTINGCHAPTER 12 & 13 Csci565 Spring 2009 H.Reza
2. OBJECTIVES
- Integration Testing
- Simple ATM (SATM)
- discuss integration testing strategies
- Top-down
- Bottom-up
- Decomposition Based Integration Testing (DBIT)
- Call Graph Based Integration Testing (CGBIT)
- Path-Based Integration Testing (PBIT)
H.Reza 3. A SOFTWARE TESTING STRATEGY: SPIRAL MODEL H.Reza System Testing System eng. validation Testing Requirements Integration Testing Design Unit Testing Code 4. INTEGRATION TESTING:1
- If all units/components work individually, do they work as a whole when we put them together?
- Not necessarily
- The problem is putting them together or interfacing them
H.Reza 5. PROBLEMS WITH INTERFACING
- Integration faults often traceable to incomplete or misunderstood interface specifications
- mismatched assumptions about other components
- Individually acceptable imprecision may be magnified to unacceptable levels
- Global data structures can present problems
- Inconsistent interpretation of parameters or values
- Mixed units (meters/yards) in Martian Lander
- Violations of value domains, capacity, or size limits
H.Reza 6. INTEGRATION TESTING
- Tests complete systems or subsystems composed of integrated components
- Integration testing should beblack-boxtesting when tests derived from the specification
- Main difficulty islocalising errors
- Incremental integration testing reduces this problem
H.Reza 7. APPROACHES TO INTEGRATION TESTING
- Two major approaches
- Incremental approaches
- The decomposition-based techniques or tree
- Stubs/Drivers
- Call Graph-based techniques
- No stubs or drivers
- Non-incremental approaches
H.Reza 8. INCREMENTAL INTEGRATION TESTING H.Reza 9. INCREMENTAL APPROACHES: TOP-DOWN
- Top-down testing
- Start with high-level system
- integrate from the top-down replacing individual components bystubswhere appropriate
- Depth-first
- Breadth-first
- No-best order
- Critical sections
- Early skeletal versionusing I/O modules
H.Reza 10. STUBS
- Stubs
- Specialmodule to simulate some functionality
- Its production is nontrivial task because the code may simulate a verycomplicated tasks
- E.g.
- Writing a stub performing a database table search routine
- Creating multiple version of same stub for various reasons
H.Reza 11. TOP-DOWN TESTING H.Reza 12. TOP-DOWN: COMPLICATIONS
- The most common complication occurswhen processing at low level hierarchy demandsadequate testing of upper level
- To overcome:
- Either, delay many tests until stubs are replaced with actual modules(BAD)
- Or, develop stubs that perform limited functions that simulate the actual module ( GOOD)
- Or, Integrate the software usingbottom up approach
- Confusion about overlapping with design
H.Reza 13. INCREMENTAL TESTING: BOTTOM UP
- Bottom-up testing
- Integrate individual components in levels until the complete system is created
H.Reza 14. BOTTOM-UP APPROACH
- Starts with construction and testing with atomic modules
- No need for stub
- Low level components are combined into cluster (orbuilds ) to perform a specific sub-function
- A driver (a control program for testing) is written
- Contain hardcoded test input, calls the module being tested, and display the results
- Cluster is tested
- Drivers are removed and clusters are combined moving upward in the program structure
H.Reza 15. BOTTOM-UP TESTING H.Reza M 16. H.Reza A C E B D F J G H I K L 17. H.Reza A Stub C Stub E B Stub D Stub F second state in the top-down 18. H.Reza A Stub C Stub E B D F J Stub H I Intermediate state in the top-down 19. TOP-DOWN
- Possible Sequences of modules
- A, B, C, D, E, F, G, H, I, J, K, L
- A, B, E, F, J, C, G, K, D, H, L, I
- A, D, H, I, K, L, C, G, B, F, J, E
- A, B, F, J, D, I, E, C, G,K, H, L
- If parallel testing allowed, then other alternatives are possible
- After A has been tested, one programmer could take A and test the combination A-B,
- Another programmer could test A-C
H.Reza 20. GUIDELINE FOR INTEGRATION TESTING
- Integrate the components that implement the most frequently used functionality
- Performregression testingfor existing features
- Performprogression testingfor new features
H.Reza 21. NON-INCREMENTAL
- Big-bang
- Imposes no order(GOOD)
- Test all the units (Modules) at once
- Very easy, but difficult tolocalizethe source of errors
H.Reza 22. INTEGRATION TEST DOCUMENT
- Overall plan for integration of the system under construction must be documented in a Test Specification
- The test plan should describe the overall strategy for integration
- Example of phases
- User interaction (menu,button, forms, display presentation)
- Data Manipulation and analysis
- Display processing and generation (RT-2D, RT-3D, etc)
- Database Mgt
- Logic??
H.Reza 23. INTEGRATION: CRITERIA
- The following criteria
- Interface integrity
- (internal and external interfaces are tested as each module (or cluster) is incorporated
- Functional validity
- Testes to uncover functional error
- Information validity
- Tests to uncover error related to local/ global data
- Performance (Quality)
- Tests designed to verify performance bounds during software design
H.Reza 24. TOP-DOWN VS. BOTTOM-UP
- Architectural validation
- Top-down integration testing is better at discovering errors in thesystem architecture
- System demonstration
- Top-down integration testing allowsa limited demonstrationat an early stage in the development
- Test implementation
- Often easier withbottom-up integrationtesting
H.Reza 25. THE WATERFALLLIFE CYCLE H.Reza Requirement specifications Preliminary design details design coding Unit testing Integrationtesting System testing 26. INTEGRATION TESTING: SOFTWARE ARCHITECTURE
- Integration testing
- Howsoftware architecture can be used to conduct tests to uncover errors related to the interface?
H.Reza 27. FIG. 12.2: PRIMARY DESIGN (ORINFORMAL SOFTWARE ARCHITECTURE)OF THE ATM USING TREE-BASED DECOMPOSITION H.Reza Requirement specifications Terminal I/O MangeSession ConductTransactions Card Entry PIN Entry Select Transaction 28. MORE ON PRIMARY DESIGN
- How do perform Integration testing fornon-treebased functional decomposition?
- E.g
- integration testing for OO
- Integration testing for Client/server system