1 / 11

Software Testing

Software Testing. Component testing Testing of individual program components Usually responsibility of developer Tests derived from developer’s experience Integration testing Testing of groups of components integrated to create system or sub-system

zagiri
Télécharger la présentation

Software Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Testing • Component testing • Testing of individual program components • Usually responsibility of developer • Tests derived from developer’s experience • Integration testing • Testing of groups of components integrated to create system or sub-system • Responsibility of independent testing team • Tests based on a system specification Ch.20 - Software Testing II

  2. Integration Testing • Problem: Localizing errors found • Strategy: Incremental approach to integration and testing • Issue: What are the increments? Ch.20 - Software Testing II

  3. Incremental Integration Testing Test 1 Module A Test 2 Module B Test 3 Ch.20 - Software Testing II

  4. Incremental Integration Testing Test 1 Module A Test 2 Module B Test 3 Test 4 Module C Test 5 Ch.20 - Software Testing II

  5. Incremental Integration Testing Module D Test 6 Test 1 Module A Test 2 Module B Test 3 Test 4 Module C Test 5 Test 7 Ch.20 - Software Testing II

  6. Puncturing the Balloon It’s never that simple! • Components/tests rarely so “partitionable” • Multiple components may need to be incrementally added together • Tests may reveal errors in established (tested) components that were not completely exercised before • Bug fixes may effect multiple components Ch.20 - Software Testing II

  7. Top-down Testing • Integrate/test high-level components, with stubs for subcomponents • Integrate/test next highest level, incrementally • Repeat until “bottom” reached stub (n.) – Same public interface, limited functionality (“Potemkin Village”) Ch.20 - Software Testing II

  8. Bottom-up Testing • Integrate/test low-level components, using special testing drivers written at that interface level • Integrate/test next highest level, writing new testing drivers for that level • Repeat until “top” reached Ch.20 - Software Testing II

  9. Top-down vs. Bottom-up • Top-down • more like to discover architectural design problems early • Positive feedback from limited, but working, system (“Bells and whistles”) • Bottom-up • Easier to test (no need to write stubs), but… • Test observation a problem with both Ch.20 - Software Testing II

  10. Top-down vs. Bottom-up • Reality: • Both stubs and testing drivers require extra work • Mixture of both strategies employed Ch.20 - Software Testing II

  11. Stress testing • Exercises system beyond its maximum design load • Stressing system test failure behaviour • Systems should not fail catastrophically • Checks for unacceptable loss of service, data • Particularly relevant for testing • servers • systems distributed across network Ch.20 - Software Testing II

More Related