1 / 23

Object-Oriented Testing

Object-Oriented Testing. CIS 375 Bruce R. Maxim UM-Dearborn. 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 use-cases.

auryon
Télécharger la présentation

Object-Oriented Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Testing CIS 375 Bruce R. Maxim UM-Dearborn

  2. 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 use-cases

  3. 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

  4. 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

  5. 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

  6. Class Model Assessment - 1 • Revisit the CRC model and the object-relationship model • Inspect the description of each CRC card to determine if a delegated responsibility is part of the collaborator's definition • Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a responsible source

  7. Class Model Assessment - 2 • Using the inverted connections from step 3, determine whether • other classes might be required • responsibilities are properly grouped among classes • Determine whether widely requested responsibilities might be combined into a single responsibility • Steps 1 to 5 are applied iteratively to each class and during OOA model evaluation

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. Scenario-Based Testing • using the user tasks described in the use-cases 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

  18. 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

  19. 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

  20. 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

  21. Partitioned Class Testing - 2 • category-based partitioning • operations are categorized according to the function they perform: • Initialization • Computation • Query • Termination

  22. Interclass Test Case DesignMultiple 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

  23. Interclass Test Case DesignBehavior 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

More Related