Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Chapter 17 Chapter 17 Software Testing Strategies Software ...


Published on

  • Be the first to comment

Chapter 17 Chapter 17 Software Testing Strategies Software ...

  1. 1. Chapter 17 Software Testing Strategies 1 Objectives 1. Strategic Approach to Software Testing 2. Strategic Issues 3. Unit Testing 4. Integration Testing 5. Validation Testing 6. System Testing 2
  2. 2. A Strategic Approach to Testing Software testing accounts for the largest percentage (up to 25-30%) of technical effort in the software engineering 25- process. The objective of software testing is to uncover errors. To fulfill this objective, a series of 4 types (levels) of tests – 1) unit, 2) integration, 3) validation, and 4) system tests – are planned and executed. 3 Components of Testing Strategy 1. unit test 2. unit integration concentrate on functional test verification of a component concentrate on functional and incorporation verification of a component and incorporation of components into a program structure. structure. 4. system 3. validation test test demonstrates traceability validates software once it has been to software requirements Incorporated into a larger system (actual environment) 4
  3. 3. Characteristics of SW Testing Strategy 1. Testing begins at the component level and works “outward” toward the integration of the entire SW system 2. Different testing techniques are appropriate at different points. 3. Testing is conducted by the developer (alpha-testing) and by (alpha-testing) (beta-testing). independent test group (beta-testing). 5 Verification and Validation Verification corresponds to “Are we building the product right?” (Is process correct?) Validation corresponds to “Are we building the right product?” (Is product correct?) Ex: somebody used software engineering theory, software design procedures, graphic user interface, testing procedures, BUT the final product is useless – in this case: verification – YES, validation – NO. 6
  4. 4. 1. Unit Testing module to be tested results software engineer test cases Unit testing focuses verification effort on the smallest unit. It is white-box oriented testing technology. Parallel testing on multiple modules is possible. 7 Unit Testing (cont.) module to be tested We should test: interfaces local data structures and types of data boundary conditions independent paths error handling paths test cases 8
  5. 5. 2. Unit Integration Testing Strategies Options: • the “big bang” approach (top-down integration) (top- • an incremental construction strategy (bottom-up integration) (bottom- 9 Top Down Integration (cont.) A top module is tested with stubs B F G stubs are replaced one at a time, "depth first" C as new modules are integrated, some subset of tests is re-run re- D E 10
  6. 6. Bottom-Up Integration (cont.) A B F G drivers are replaced one at a time, "depth first" C working modules are grouped into building blocks and integrated D E cluster 11 3, 4, … and other High Order Testing other specialized testing beta testing Validation testing: Focus is on software requirements System testing: Focus is on system integration 4. system test Alpha/Beta testing: Focus is on customer usage Recovery testing: forces the software to fail in a variety of testing: ways and verifies that recovery is properly performed Security testing: verifies that protection mechanisms built into 3. validation test a system will, in fact, protect it from improper penetration Stress testing: executes a system in a manner that demands resources in abnormal quantity, frequency, or volume Performance Testing: test the run-time performance of run- software within the context of an integrated system 12
  7. 7. Testing vs. Debugging Testing: a systematic, planned activity Debugging: an art (luck, intuition, etc.). 13 Consequences (Types) of SW Bugs infectious damage catastrophic extreme serious disturbing annoying mild Bug Type Bug Categories: function-related bugs, function- system-related bugs, data bugs, coding bugs, system- design bugs, documentation bugs, standards violations, etc. 14