Software Specification KXA233 Lecture 11 OO Testing : Ch 22

1. Software SpecificationKXA233Lecture 11OO Testing : Ch 22 Paul Crowther School of Computing University of Tasmania

2. Today... • OO Testing

3. Testing • The general aim of testing is to: • find the greatest number of errors • with a manageable amount of effort • over a realistic time span • For OOA and OOD this must broadened

4. New Problems • Improper allocation of a class to a subsystem • Improper allocation of a class to a task • Extraneous attributes • Messaging problems

5. Correctness of OOA and OOD Models • Model based - checklists will reflect the specific design and analysis model used • Does the model conform to the real world problem domain? • Do class connections reflect real world object connections?

6. Consistency of OOA and OOD Models • Based on relationships between entities • Inconsistent model has representations in one part not correctly reflected in another • Asses each class and its connections to other classes • Use CRC and Object-Relationship models

7. Class Model Evaluation • Crosscheck all collaborations implied by the OOA are properly reflected in the CRC and Object-Relationship Model • Check CRC to determine if a delegated responsibility is part of the collaborators definition • Invert the connection to ensure each collaborator is that is asked for service is receiving requests from a reasonable source • Using inverted connections determine whether other classes might be required or whether responsibilities are properly grouped among classes • Determine whether widely requested responsibilities might be combined into a single responsibility

8. OO Testing Strategies • Testing in the small towards testing inthe large • Unit testing • Integration Testing • Validation and System Testing

9. Unit Testing • Class / Instance of Class (object) /Attributes / Operations • Class can contain a number of operations • An operation may exist as part of a number of classes • Hierarchy: operation in a superclass may vary in subclasses - need to test each • Class testing is driven by operations encapsulated by a class and the state behaviour of the class

10. Integration Testing • Thread-Based Testing integrates the set of classes required to respond to one input or event for the system • Each thread is integrated and tested individually • Use-Based Testing: • test independent classes - those classes which require few (if any) sever classes • test dependent classes after independent classes • Cluster Testing for collaborating classes based on the CRC and object-relationship model

11. Validation Testing • Concentrate on user-visible actions, interactions and output • Based on use-case scenarios • Can use conventional black-box techniques • Can use tests derived from the object-behaviour and state diagrams

12. Test Case Design for OO Software • Each test should be uniquely identified and explicitly associated with a class • The purpose of the test should be stated • Check list • specified states of the object • exceptions list • external conditions list • any supplementary information

13. Test Case implications of OO Concepts - Problems • Encapsulation may make it difficult to acquire on an object • May need extra operations to provide a snap-shot of an objects state • Inheritance • Can use superclass tests on subclass • Unless there is multiple inheritance (subclass used in an entirely different context

14. Applicability of Conventional Methods • Conventional white box testing best at class level • Black box methods are appropriate

15. Fault-Based Testing • A successful test is one that uncovers a fault • Begin at the analysis model • look for plausible faults (eg boundary errors) • determine if they exist • design test cases to exercise the design (and code) • Integration testing - message faults • unexpected result • wrong operation/message used • incorrect invocation • Integration testing looks for faults in the client

16. Impact of OO Programming on Testing • Some types of faults become less plausible • particularly at unit level • Some types of faults become more plausible • particularly integration • Some new types of faults appear • due to inheritance and multiple inheritance

17. Test Cases and the Class Hierarchy • If a inherited class uses an operation from the superclass, the code need not be retested • Unless there is code in the subclass which redefines that operation. • Then a second set of tests is required

18. Scenario-Based Testing • Fault based testing misses: • errors due to incorrect specifications • analyst failed to pick up user requirements • errors due to interactions between subsystems • behaviour of one subsystem causes the another subsystem to fail

19. Scenario-Based Testing • Concentrates on what the user does • Tends to exercise multiple subsystems in a single test • Often based on use-case scenarios

20. Testing Surface Structure and Deep Structure • Surface structure • externally observable to end user • use both objects and operations • eg in an object-based interface, the tester might use the list of objects as a testing checklist • Deep Structure • Internal to OO program • exercise dependencies, behaviours and communication

21. Testing Methods at the Class Level • Random testing • Partitioning

22. Random Testing for OO Classes • Some operations are dependent on other operations - others can be random • open - setup - deposit - withdraw - close • opens - setup - deposit - deposit - summarize - withdraw - creditlimit - withdraw - close • Test with a variety of intermediate sequences (all possibilities?)

23. Partition Testing at the Class Level • Derive partitioning categories for input and output • State-based partitioning • based on ability to change an object state(eg modify) • opens - setup - deposit- deposit - summarize - withdraw - creditlimit - withdraw - close

24. Partition Testing at the Class Level • Attribute-based partitioning • categorizes classes on the attributes they use • Operations can be divided into partitions • use • modify • don’t use

25. Partition Testing at the Class Level • Category-based partitioning • based on generic functions • initialization • computational • queries • termination • opens - setup - deposit - deposit - summarize - withdraw - creditlimit - withdraw - close

26. Interclass Test Case Design • Like testing of individual class testing, collaboration testing uses • random testing • partition testing • Plus • scenario based testing • behavioural testing

27. Multiple Class Testing • Use class collaboration diagram • For each client class use the list of class operators to generate a series of random test sequences • For each message generated determine the collaborator (client) class and corresponding operator (service) • For each operator in the server determine the messages it transmits • For each message determine the next level of operators that are invoked and add to test sequence

28. Tests Derived from Behaviour Models • Use State Transition Diagram (STD) • Test dynamic behaviour • Test should be designed to achieve all state coverage • All behaviours exercised • Traverse state model breadth first • single transition • new transitions added after previous ones tested

29. Next Week... • “Mid Semester” Break • Writing Specifications