integration testing(revisited)

• 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