ObjectOriented Testing CIS 375 Bruce R Maxim UMDearborn
Object-Oriented Testing CIS 375 Bruce R. Maxim UM-Dearborn 1
OO testing Activities • • Review OOA and OOD models Class testing after code is written Integration testing within subsystems Integration testing as subsystems are added to the system • Validation testing based on OOA usecases 2
Correctness of OOA/OOA Models • syntactic correctness – judged by making sure proper modeling conventions and symbolism were used • semantic correctness – checking the model's conformance to the real world problem domain 3
Consistency of OOA/OOD Models - 1 • assess the class-responsibility-collaborator (CRC) model and object-relationship diagram • review system design – examine the object-behavior model to check mapping of system behavior to subsystems – review concurrency and task allocation – examine the use-case scenarios and exercise the user interface design 4
Consistency of OOA/OOD Models - 2 • test object model against the object relationship network to ensure that all design object contain necessary attributes and operations needed to implement the collaborations defined for each CRC card • review detailed specifications of algorithms used to implement operations using conventional inspection techniques 5
Class Model Assessment - 1 1. Revisit the CRC model and the objectrelationship model 2. Inspect the description of each CRC card to determine if a delegated responsibility is part of the collaborator's definition 3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a responsible source 6
Class Model Assessment - 2 4. Using the inverted connections from step 3, determine whether – other classes might be required – responsibilities are properly grouped among classes 5. Determine whether widely requested responsibilities might be combined into a single responsibility 6. Steps 1 to 5 are applied iteratively to each class and during OOA model evaluation 7
OO Unit Testing • smallest testable unit is the encapsulated class or object • similar to system testing of conventional software • do not test operations in isolation from one another • driven by class operations and state behavior, not algorithmic detail or data flow across module interface 8
OO Integration Testing - 1 • focuses on groups of classes that collaborate or communicate in some manner • integration of operations one at a time into classes is often meaningless • regression testing is important as each thread, cluster, or subsystem is added to the system 9
OO Integration Testing - 2 • thread-based testing – testing all classes required to respond to one system input or event • use-based testing – test independent classes first – test dependent classes making use of them next • cluster testing – groups of collaborating classes are tested for interaction errors 10
OO Validation Testing • focuses on visible user actions and user recognizable outputs from the system • validation tests are based on OOA – use-case scenarios – object-behavior model – event flow diagram • conventional black-box testing methods can be used to drive the validation tests 11
OO Test Case Design • Each test case should be uniquely identified and be explicitly associated with a class to be tested • State the purpose of each test • List the testing details for each test 12
OO Test Case Detail • states to examine for each object involved • messages and operations to exercised as a consequence of the test • exceptions that may occur when the object is tested • external conditions needed to be changed for the test • supplementary information required to understand or implement the test 13
OO Test Design Issues • White-box testing methods can be applied to testing the code used to implement class operations, but not much else • Black-box testing methods are appropriate for testing OO systems 14
OOP Testing Concerns • classes may contain operations that are inherited from super classes • subclasses may contain operations that were redefined rather than inherited • all classes derived from an previously tested base class need to be thoroughly tested 15
Fault-Base Testing • best reserved for operations and the class level • uses the inheritance structure • tester examines the OOA model and hypothesizes a set of plausible defects that may be encountered in operation calls and message connections and builds appropriate test cases • misses incorrect specification and errors in subsystem interactions 16
Scenario-Based Testing • using the user tasks described in the usecases and building the test cases from the tasks and their variants • uncovers errors that occur when any actor interacts with the OO software • concentrates on what the user does, not what the product does • you are better off spending more time on reviewing the use-cases as they are created and less time on use-case testing 17
Testing Surface Structure and Deep Structure • Testing surface structure – exercising the structure observable by end-user – often involves observing and interviewing users as they manipulate system objects • Testing deep structure – exercising internal program structure established as part of the system and object design • dependencies • behaviors • communications mechanisms 18
Random Class Testing • Requires large numbers data permutations and combinations • Can be very inefficient • Using partition testing can reduce the number of test cases required 19
Partitioned Class Testing - 1 • state-based partitioning – tests designed in way so that operations that cause state changes are tested separately from those that do not • attribute-based partitioning – for each class attribute, operations are classified according to those that • use the attribute • modify the attribute • do not use or modify the attribute 20
Partitioned Class Testing - 2 • category-based partitioning – operations are categorized according to the function they perform: • • Initialization Computation Query Termination 21
Interclass Test Case Design Multiple Class Testing • for each client class use the list of class operators to generate random test sequences that send messages to other server classes • for each message generated determine the collaborator class and the corresponding server object operator • for each server class operator (invoked by a client object message) determine the message it transmits • for each message, determine the next level of operators that are invoked and incorporate them into the test sequence 22
Interclass Test Case Design Behavior Model Testing • test cases must cover all states in the state transition diagram • breadth first traversal of the state model can be used (test one transition at a time and only make use of previously tested transitions when testing a new transition) • test cases can also be derived to ensure that all behaviors for the class have been adequately exercised 23
- Slides: 23