Your SlideShare is downloading. ×
0
Software Testing Strategies based on Chapter 13 -  Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, ...
Software Testing Testing is the process of exercising a program with the  specific intent of finding errors prior to deliv...
Who Tests the Software? developer independent tester Understands the system  but, will test "gently" and, is dri...
Levels of Testing <ul><li>Unit testing </li></ul><ul><li>Integration testing </li></ul><ul><li>Validation testing </li></u...
Unit Testing module to be tested test cases results software engineer interface  local data structures boundary conditions...
Integration Testing Strategies <ul><li>Options: </li></ul><ul><ul><li>• the “big bang” approach </li></ul></ul><ul><ul><li...
OOT Strategy <ul><li>class testing is the equivalent of unit testing </li></ul><ul><ul><li>operations  within the class ar...
test cases results Debugging suspected causes identified causes corrections regression tests new test cases Debugging: A D...
Software Testing Techniques   based on Chapter 14 -  Software Engineering: A Practitioner’s Approach, 6/e   copyright © 19...
What is a “Good” Test? <ul><li>a high probability of finding an error </li></ul><ul><li>not redundant. </li></ul><ul><li>n...
Exhaustive Testing loop < 20 X There are approx. 10  possible paths! If we execute one test per millisecond, it would take...
RE in V Model system requirements system integration software requirements preliminary design detailed design code & debug...
Software Testing White-Box Testing ... our goal is to ensure that  all   statements and conditions  have  been executed at...
Basis  Path Testing First, we compute the cyclomatic  complexity: number of simple decisions + 1  or number of enclosed ar...
Basis  Path Testing Next, we derive the  independent paths: Since V(G) = 4, there are four paths Path 3:  1,2,3,6,7,8 Path...
Loop Testing Nested  Loops Concatenated Loops  Unstructured  Loops Simple  loop White-Box Testing Why is loop testing impo...
Equivalence Partitioning & Boundary Value Analysis <ul><li>If x  = 5 then … </li></ul>What would be the equivalence classe...
Comparison Testing <ul><li>Used only in situations in which the reliability of software is absolutely critical (e.g., huma...
OOT—Test Case Design Berard [BER93] proposes the following approach: <ul><li>1. Each test case should be uniquely identifi...
OOT Methods: Behavior Testing The tests to be designed should achieve  all state coverage  [KIR94]. That is, the operation...
Omitted Slides
Testability <ul><li>Operability —it operates cleanly </li></ul><ul><li>Observability —the results of each test case are re...
Strategic Issues <ul><li>Understand the  users  of the software and develop a  profile for each user category . </li></ul>...
<ul><li>Counting Bugs </li></ul><ul><li>Sometimes reliability requirements take the form: </li></ul><ul><li>&quot;The soft...
Cyclomatic Complexity A number of industry studies have indicated  that the higher V(G), the higher the probability  or er...
Upcoming SlideShare
Loading in...5
×

Transparency Masters for Software Engineering: A Practitioner's ...

393

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
393
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Transparency Masters for Software Engineering: A Practitioner's ..."

  1. 1. Software Testing Strategies based on Chapter 13 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
  2. 2. Software Testing Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. errors requirements conformance performance an indication of quality
  3. 3. Who Tests the Software? developer independent tester Understands the system but, will test &quot;gently&quot; and, is driven by &quot; delivery &quot; Must learn about the system, but, will attempt to break it and, is driven by quality
  4. 4. Levels of Testing <ul><li>Unit testing </li></ul><ul><li>Integration testing </li></ul><ul><li>Validation testing </li></ul><ul><ul><li>Focus is on software requirements </li></ul></ul><ul><li>System testing </li></ul><ul><ul><li>Focus is on system integration </li></ul></ul><ul><li>Alpha/Beta testing </li></ul><ul><ul><li>Focus is on customer usage </li></ul></ul><ul><li>Recovery testing </li></ul><ul><ul><li>forces the software to fail in a variety of ways and verifies that recovery is properly performed </li></ul></ul><ul><li>Security testing </li></ul><ul><ul><li>verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration </li></ul></ul><ul><li>Stress testing </li></ul><ul><ul><li>executes a system in a manner that demands resources in abnormal quantity, frequency, or volume </li></ul></ul><ul><li>Performance Testing </li></ul><ul><ul><li>test the run-time performance of software within the context of an integrated system </li></ul></ul>
  5. 5. Unit Testing module to be tested test cases results software engineer interface local data structures boundary conditions independent paths error handling paths
  6. 6. Integration Testing Strategies <ul><li>Options: </li></ul><ul><ul><li>• the “big bang” approach </li></ul></ul><ul><ul><li>• an incremental construction strategy </li></ul></ul><ul><li>Top Down, bottom-up, sandwich Integration </li></ul>
  7. 7. OOT Strategy <ul><li>class testing is the equivalent of unit testing </li></ul><ul><ul><li>operations within the class are tested </li></ul></ul><ul><ul><li>the state behavior of the class is examined </li></ul></ul><ul><li>integration applied three different strategies/levels of abstraction </li></ul><ul><ul><li>thread-based testing—integrates the set of classes required to respond to one input or event </li></ul></ul><ul><ul><li>use-based testing—integrates the set of classes required to respond to one use case </li></ul></ul><ul><ul><li>cluster testing—integrates the set of classes required to demonstrate one collaboration </li></ul></ul>… if there is no nesting of classes … this is pushing…
  8. 8. test cases results Debugging suspected causes identified causes corrections regression tests new test cases Debugging: A Diagnostic Process
  9. 9. Software Testing Techniques based on Chapter 14 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
  10. 10. What is a “Good” Test? <ul><li>a high probability of finding an error </li></ul><ul><li>not redundant. </li></ul><ul><li>neither too simple nor too complex </li></ul>&quot;Bugs lurk in corners and congregate at boundaries ...&quot; Boris Beizer OBJECTIVE: CRITERIA: CONSTRAINT: to uncover errors in a complete manner with a minimum of effort and time
  11. 11. Exhaustive Testing loop < 20 X There are approx. 10 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! 14 Where does 10 14 come from? White-Box or Black-Box?
  12. 12. RE in V Model system requirements system integration software requirements preliminary design detailed design code & debug acceptance test software integration component test unit test Time Level of abstraction analyze and design test and integrate [Chung]
  13. 13. Software Testing White-Box Testing ... our goal is to ensure that all statements and conditions have been executed at least once ... Black-Box Testing requirements events input output
  14. 14. Basis Path Testing First, we compute the cyclomatic complexity: number of simple decisions + 1 or number of enclosed areas + 1 In this case, V(G) = 4 White-Box Testing
  15. 15. Basis Path Testing Next, we derive the independent paths: Since V(G) = 4, there are four paths Path 3: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 1: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 Finally, we derive test cases to exercise these paths. White-Box Testing A number of industry studies have indicated that the higher V(G), the higher the probability or errors. 1 2 3 4 5 6 7 8
  16. 16. Loop Testing Nested Loops Concatenated Loops Unstructured Loops Simple loop White-Box Testing Why is loop testing important?
  17. 17. Equivalence Partitioning & Boundary Value Analysis <ul><li>If x = 5 then … </li></ul>What would be the equivalence classes? <ul><li>If x > -5 and x < 5 then … </li></ul>White-Box Testing Black-Box Testing
  18. 18. Comparison Testing <ul><li>Used only in situations in which the reliability of software is absolutely critical (e.g., human-rated systems) </li></ul><ul><ul><li>Separate software engineering teams develop independent versions of an application using the same specification </li></ul></ul><ul><ul><li>Each version can be tested with the same test data to ensure that all provide identical output </li></ul></ul><ul><ul><li>Then all versions are executed in parallel with real-time comparison of results to ensure consistency </li></ul></ul>Black-Box Testing
  19. 19. OOT—Test Case Design Berard [BER93] proposes the following approach: <ul><li>1. Each test case should be uniquely identified and should be explicitly associated with the class to be tested, </li></ul><ul><li>2. A list of testing steps should be developed for each test and should contain [BER94]: </li></ul><ul><ul><li>a. a list of specified states for the object that is to be tested </li></ul></ul><ul><li>b. a list of messages and operations that will be exercised as a consequence of the test how can this be done? </li></ul><ul><li>c. a list of exceptions that may occur as the object is tested </li></ul><ul><li>d. a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test) </li></ul>{people, machine, time of operation, etc.}
  20. 20. OOT Methods: Behavior Testing The tests to be designed should achieve all state coverage [KIR94]. That is, the operation sequences should cause the Account class to make transition through all allowable states Is the set of initial input data enough?
  21. 21. Omitted Slides
  22. 22. Testability <ul><li>Operability —it operates cleanly </li></ul><ul><li>Observability —the results of each test case are readily observed </li></ul><ul><li>Controllability —the degree to which testing can be automated and optimized </li></ul><ul><li>Decomposability —testing can be targeted </li></ul><ul><li>Simplicity —reduce complex architecture and logic to simplify tests </li></ul><ul><li>Stability —few changes are requested during testing </li></ul><ul><li>Understandability —of the design </li></ul>
  23. 23. Strategic Issues <ul><li>Understand the users of the software and develop a profile for each user category . </li></ul><ul><li>Develop a testing plan that emphasizes “rapid cycle testing.” </li></ul><ul><li>Use effective formal technical reviews as a filter prior to testing </li></ul><ul><li>Conduct formal technical reviews to assess the test strategy and test cases themselves. </li></ul>
  24. 24. <ul><li>Counting Bugs </li></ul><ul><li>Sometimes reliability requirements take the form: </li></ul><ul><li>&quot;The software shall have no more than X bugs/1K LOC&quot; </li></ul><ul><li>But how do we measure bugs at delivery time? </li></ul><ul><li>Bebugging Process - based on a Monte Carlo technique for statistical analysis of random events. </li></ul><ul><li>1. before testing, a known number of bugs (seeded bugs) are secretly inserted. </li></ul><ul><li>2. estimate the number of bugs in the system </li></ul><ul><li>3. remove (both known and new) bugs. </li></ul><ul><li># of detected seeded bugs/ # of seeded bugs = # of detected bugs/ # of bugs in the system </li></ul><ul><li># of bugs in the system = # of seeded bugs x # of detected bugs / # of detected seeded bugs </li></ul><ul><li>Example: secretely seed 10 bugs </li></ul><ul><li>an independent test team detects 120 bugs (6 for the seeded) </li></ul><ul><li># of bugs in the system = 10 x 120/6 = 200 </li></ul><ul><li># of bugs in the system after removal = 200 - 120 - 4 = 76 </li></ul><ul><li>But, deadly bugs vs. insignifant ones; not all bugs are equally detectable; ( Suggestion [Musa87]: </li></ul><ul><li>&quot;No more than X bugs/1K LOC may be detected during testing&quot; </li></ul><ul><li>&quot;No more than X bugs/1K LOC may be remain after delivery, </li></ul><ul><li>as calculated by the Monte Carlo seeding technique&quot; </li></ul>NFRs: Reliability   [Chung, RE Lecture Notes]]
  25. 25. Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. V(G) modules modules in this range are more error prone White-Box Testing
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×