integration testing(revisited)

Download Integration testing(revisited)

Post on 25-May-2015

1.494 views

Category:

Documents

0 download

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