09 OO Testing and Test Cases

3,494 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,494
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
265
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

09 OO Testing and Test Cases

  1. 1. OO testing and testing strategies <ul><li>Testing object-oriented software </li></ul><ul><li>Testing strategies </li></ul><ul><li>Higher-order testing </li></ul>
  2. 2. Object - oriented testing <ul><li>begins by evaluating the correctness and consistency of the OOA and OOD models </li></ul><ul><li>testing strategy changes </li></ul><ul><ul><li>the concept of the ‘unit’ broadens due to encapsulation </li></ul></ul><ul><ul><li>integration focuses on classes and their execution across a ‘thread’ or in the context of a usage scenario </li></ul></ul><ul><ul><li>validation uses conventional black box methods </li></ul></ul><ul><li>test case design draws on conventional methods, but also encompasses special features </li></ul>
  3. 3. OOT strategy <ul><li>classes are the smallest testable unit </li></ul><ul><li>inheritance defines new context for methods </li></ul><ul><ul><li>behavior of inherited methods can be changed because of methods that are called within </li></ul></ul><ul><ul><li>methods have to be tested per class </li></ul></ul><ul><li>objects have states: testing methods have to take that into account </li></ul><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>OO testing concentrates on the states of the objects and their interactions </li></ul>
  4. 4. Integration applied three different strategies <ul><li>thread-based testing </li></ul><ul><ul><ul><li>integrates the set of classes required to respond to one input or event </li></ul></ul></ul><ul><li>use-case based testing </li></ul><ul><ul><ul><li>integrates the set of classes required to respond to one use class </li></ul></ul></ul><ul><ul><ul><li>starts with independent (ground) classes </li></ul></ul></ul><ul><li>cluster testing </li></ul><ul><ul><ul><li>integrates the set of classes required to demonstrate one collaboration </li></ul></ul></ul>
  5. 5. OOT - test case design (1) <ul><li>Berard [BER93] proposes the following approach: </li></ul><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. the purpose of the test should be stated, </li></ul><ul><li>3. a list of testing steps should be developed for each test and should contain [BER94]: </li></ul>
  6. 6. OOT - test case design (2) <ul><ul><li>A a list of specified states for the object that is to be tested </li></ul></ul><ul><ul><li>B a list of messages and operations that will be exercised as a consequence of the test </li></ul></ul><ul><ul><li>C a list of exceptions that may occur as the object is tested </li></ul></ul><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></ul><ul><ul><li>E supplementary information that will aid in understanding or implementing the test. </li></ul></ul>
  7. 7. Problems in testing OO software <ul><li>Testing shall report errors internal state of object </li></ul><ul><li>Encapsulation hides internal things </li></ul><ul><li>Inheritance: test cases of the superclass may may have to be adapted </li></ul>
  8. 8. OOT methods: Scenario-based testing <ul><li>Concentrates on what the user does NOT what the system does </li></ul><ul><li>Based on use cases </li></ul><ul><li>Described by </li></ul><ul><ul><li>a test </li></ul></ul><ul><ul><li>specific user needs </li></ul></ul>
  9. 9. OOT methods: random testing <ul><li>random testing </li></ul><ul><ul><li>identify operations applicable to a class </li></ul></ul><ul><ul><li>define constraints on their use </li></ul></ul><ul><ul><li>identify a minimum test sequence </li></ul></ul><ul><ul><ul><li>an operation sequence that defines the minimum life history of the class (object) </li></ul></ul></ul><ul><ul><li>generate a variety of random (but valid) test sequences </li></ul></ul><ul><ul><ul><li>exercise other (more complex) class instance life histories </li></ul></ul></ul>
  10. 10. OOT methods: partition testing (1) <ul><li>Partition testing </li></ul><ul><ul><li>reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software </li></ul></ul><ul><ul><li>state-based partitioning </li></ul></ul><ul><ul><ul><li>categorize and test operations based on their ability to change the state of a class </li></ul></ul></ul>
  11. 11. OOT methods: partition testing (2) <ul><li>Partition testing </li></ul><ul><ul><li>attribute-based partitioning </li></ul></ul><ul><ul><ul><li>categorize and test operations based on the attributes that they use </li></ul></ul></ul><ul><ul><li>category-based partitioning </li></ul></ul><ul><ul><ul><li>categorize and test operations based on the generic function each performs e.g. </li></ul></ul></ul><ul><ul><ul><ul><li>initialization </li></ul></ul></ul></ul><ul><ul><ul><ul><li>state changing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>queries </li></ul></ul></ul></ul><ul><ul><ul><ul><li>termination </li></ul></ul></ul></ul>
  12. 12. State diagram based testing <ul><li>Use state diagram to determine a sequence of events </li></ul><ul><li>Tests should achieve all state coverage </li></ul><ul><li>All transitions should be tested at least once </li></ul><ul><li>Test invalid events </li></ul>
  13. 13. OOT methods: Inter-class testing (1) <ul><li>Inter-class testing </li></ul><ul><ul><li>For each client class, use the list of class operators to generate a series of random test sequences. The operators will send messages to other server classes. </li></ul></ul><ul><ul><li>For each message that is generated, determine the collaborator class and the corresponding operator in the server object. </li></ul></ul>
  14. 14. OOT methods: Inter-class testing (2) <ul><li>Inter-class testing </li></ul><ul><ul><li>For each operator in the server object ( that has been invoked by messages sent from the client object), determine the messages that it transmits. </li></ul></ul><ul><ul><li>For each of the messages, determine the next level of operators that are invoked and incorporate these into the test sequence </li></ul></ul>
  15. 15. OO testing and testing strategies <ul><li>Testing object-oriented software </li></ul><ul><li>Testing strategies </li></ul><ul><li>Higher-order testing </li></ul>
  16. 16. Verification & validation <ul><li>Verification: Are we building the product right </li></ul><ul><li>Validation: Are we building the right product </li></ul>
  17. 17. Testing strategy code design requirements high-order tests integration test unit test
  18. 18. Unit testing Test cases Module interface local data structures boundary conditions independent paths error handling paths
  19. 19. Unit testing environment Test cases interface local data structures boundary conditions independent paths error handling paths driver Module stub stub RESULTS
  20. 20. Why integration testing? <ul><li>If all units work individually, why doubt that they work together? </li></ul><ul><li>Putting units together - interfacing </li></ul>
  21. 21. Integration testing Big Bang! incremental construction strategy incremental “ builds” regression testing
  22. 22. Top down integration A G F B E C D top module is tested with stubs stubs are replaced one at a time, “depth first” as new modules are integrated, some subset of tests is re-run
  23. 23. Bottom-up integration drivers are replaced one at a time, “depth first” worker modules are grouped into builds and integrated cluster A G F B E C D
  24. 24. Sandwich testing A G F B E C D worker modules are grouped into builds and integrated cluster top modules are tested with stubs
  25. 25. OO testing and testing strategies <ul><li>Testing object-oriented software </li></ul><ul><li>Testing strategies </li></ul><ul><li>Higher-order testing </li></ul>
  26. 26. High-order testing <ul><li>validation test </li></ul><ul><li>system test </li></ul><ul><li>alpha and beta test </li></ul><ul><li>other specialized testing </li></ul>
  27. 27. Alpha & Beta test software developer site customer site customer tests Beta test developer reviews software developer site customer site customer tests Alpha test
  28. 28. Test specification (1) <ul><li>1. Scope of testing </li></ul><ul><li>2. Test plan </li></ul><ul><li>3. Test procedure n (description of test for build n ) </li></ul><ul><li>4. Actual test results </li></ul><ul><li>5. References </li></ul><ul><li>6. Appendices </li></ul>
  29. 29. Test specification (2) <ul><li>2. Test plan </li></ul><ul><ul><li>A. test phases and builds </li></ul></ul><ul><ul><li>B. schedule </li></ul></ul><ul><ul><li>C. overhead software </li></ul></ul><ul><ul><li>D. environment and resources </li></ul></ul>
  30. 30. Test specification (3) <ul><li>3. Test procedure n </li></ul><ul><ul><li>A. order of integration </li></ul></ul><ul><ul><ul><li>1. purpose </li></ul></ul></ul><ul><ul><ul><li>2. modules to be tested </li></ul></ul></ul><ul><ul><li>B. unit tests for modules in build </li></ul></ul><ul><ul><ul><li>1. description of tests for module n </li></ul></ul></ul><ul><ul><ul><li>2. overhead software description </li></ul></ul></ul><ul><ul><ul><li>3. expected results </li></ul></ul></ul>
  31. 31. Test specification (4) <ul><li>3. Test procedure n </li></ul><ul><ul><li>C. test environment </li></ul></ul><ul><ul><ul><li>1. special tools or techniques </li></ul></ul></ul><ul><ul><ul><li>2. overhead software description </li></ul></ul></ul><ul><ul><li>D. test case data </li></ul></ul><ul><ul><li>E. expected results for build n </li></ul></ul>
  32. 32. Debugging: Symptoms & causes <ul><li>Symptom and cause may be geographically separated </li></ul><ul><li>symptom may disappear when another problem is fixed </li></ul><ul><li>cause may be due to a combination of non-errors </li></ul><ul><li>cause may be due to a system or compiler error </li></ul><ul><li>cause may be due to assumptions that everyone believes </li></ul><ul><li>symptom may be intermittent </li></ul>cause symptom

×