Software Testing - Integration Testing

993 views

Published on

  • Be the first to comment

  • Be the first to like this

Software Testing - Integration Testing

  1. 1. Software Testing <ul><li>Component testing </li></ul><ul><ul><li>Testing of individual program components </li></ul></ul><ul><ul><li>Usually responsibility of developer </li></ul></ul><ul><ul><li>Tests derived from developer’s experience </li></ul></ul><ul><li>Integration testing </li></ul><ul><ul><li>Testing of groups of components integrated to create system or sub-system </li></ul></ul><ul><ul><li>Responsibility of independent testing team </li></ul></ul><ul><ul><li>Tests based on a system specification </li></ul></ul>
  2. 2. Integration Testing <ul><li>Problem : Localizing errors found </li></ul><ul><li>Strategy : Incremental approach to integration and testing </li></ul><ul><li>Issue : What are the increments? </li></ul>
  3. 3. Incremental Integration Testing Module A Module B Test 1 Test 2 Test 3
  4. 4. Incremental Integration Testing Module A Module B Module C Test 1 Test 2 Test 3 Test 4 Test 5
  5. 5. Incremental Integration Testing Module A Module B Test 1 Test 2 Test 3 Module C Test 4 Test 5 Module D Test 6 Test 7
  6. 6. Puncturing the Balloon <ul><li>It’s never that simple! </li></ul><ul><ul><li>Components/tests rarely so “partitionable” </li></ul></ul><ul><ul><li>Multiple components may need to be incrementally added together </li></ul></ul><ul><ul><li>Tests may reveal errors in established (tested) components that were not completely exercised before </li></ul></ul><ul><ul><li>Bug fixes may effect multiple components </li></ul></ul>
  7. 7. Top-down Testing <ul><li>Integrate/test high-level components, with stubs for subcomponents </li></ul><ul><li>Integrate/test next highest level, incrementally </li></ul><ul><li>Repeat until “bottom” reached </li></ul><ul><li>stub (n.) – Same public interface, limited functionality (“ Potemkin Village ”) </li></ul>
  8. 8. Bottom-up Testing <ul><li>Integrate/test low-level components, using special testing drivers written at that interface level </li></ul><ul><li>Integrate/test next highest level, writing new testing drivers for that level </li></ul><ul><li>Repeat until “top” reached </li></ul>
  9. 9. Top-down vs. Bottom-up <ul><li>Top-down </li></ul><ul><ul><li>more like to discover architectural design problems early </li></ul></ul><ul><ul><li>Positive feedback from limited, but working, system (“Bells and whistles”) </li></ul></ul><ul><li>Bottom-up </li></ul><ul><ul><li>Easier to test (no need to write stubs), but… </li></ul></ul><ul><li>Test observation a problem with both </li></ul>
  10. 10. Top-down vs. Bottom-up <ul><li>Reality: </li></ul><ul><ul><li>Both stubs and testing drivers require extra work </li></ul></ul><ul><ul><li>Mixture of both strategies employed </li></ul></ul>
  11. 11. Stress testing <ul><li>Exercises system beyond its maximum design load </li></ul><ul><li>Stressing system test failure behaviour </li></ul><ul><ul><li>Systems should not fail catastrophically </li></ul></ul><ul><ul><li>Checks for unacceptable loss of service, data </li></ul></ul><ul><li>Particularly relevant for testing </li></ul><ul><ul><li>servers </li></ul></ul><ul><ul><li>systems distributed across network </li></ul></ul>

×