1 / 26

Object-oriented Testing

Object-oriented Testing. SIM3302. Objectives. To cover the strategies and tools associated with object oriented testing Analysis and Design Testing Class Tests Integration Tests Validation Tests System Tests. Object-oriented Testing. When should testing begin? Analysis and Design:

georgianne
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 SIM3302

  2. Objectives • To cover the strategies and tools associated with object oriented testing • Analysis and Design Testing • Class Tests • Integration Tests • Validation Tests • System Tests

  3. Object-oriented Testing • When should testing begin? • Analysis and Design: • Testing begins by evaluating the OOA and OOD models • How do we test OOA models (requirements and use cases)? • How do we test OOD models (class and sequence diagrams)? • Structured walk-throughs, prototypes • Formal reviews of correctness, completeness and consistency • Programming: • How does OO make testing different from procedural programming? • Concept of a ‘unit’ broadens due to class encapsulation • Integration focuses on classes and their context of a use case scenarioor their execution across a thread • Validation may still use conventional black box methods

  4. Testing Analysisand Design • Syntactic correctness: • Are UML and ADT notation used correctly? • Semantic correctness: • Does the model reflect the real world problem? • Is UML used as intended by its designers? • Is the ADT design complete (capturing all the classes and operations in UML diagram) and understandable? • Testing for consistency: • An inconsistent model has representations in one part that are not reflected in other portions of the model

  5. Testing the Class Model • Revisit the Use Cases, CRC cards and UML class model. Check that all collaborations are properly represented. Inspect the description of each CRC index card to make sure a delegated responsibility is part of the collaborator’s definition. • Example: in a point of sale system. • A read credit card responsibility of a credit sale class is accomplished if satisfied by a credit card collaborator • Invert connections to ensure that each collaborator asked for a service is receiving requests from a reasonable source • Example: a credit card being asked for a purchase amount • Have you tested your analysis and design? • If not, who will do it?

  6. Testing OO Code Integration tests Class tests Validation tests System tests

  7. Object-oriented Testing Strategies(1) • Unit Testing • Smallest testable unit is the encapsulated class or object • Test each operation as part of a class hierarchy because its class hierarchy defines its context of use • Driven by class operations and state behavior, not algorithmic detail and data flow across module interface • Approach: • Test each method (and constructor) within a class • Test the state behavior (attributes) of the class between methods • Complete test coverage of a class involves • Testing all operations • Setting and interrogating all object attributes • Exercising the object in all possible state • Test sequences are designed to ensure that relevant operations are exercised • State of the class is examined to determine if errors exist

  8. Object-oriented Testing Strategies(2) • Unit Testing … • How is class testing different from conventional testing? • Conventional testing focuses on input-process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class • But white-box testing can still be applied

  9. Object-oriented Testing Strategies(3) • Integration Testing • OO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning • Focuses on groups of classes that collaborate in some manner • Integration of operations one at a time into a class is often meaningless • Because of direct and indirect interaction of components • Thread-based testing • Testing/integrate the set of classes required to respond to one input or event • Use-based testing (integrates classes required by one use cas • Begins by testing independent classes that use very few of server classes • Next layer of classes (dependent classes) that use the independent classes are tested next • Cluster testing • Groups of collaborating classes are tested for interaction errors • Regression testing is important as each thread, cluster or subsystem is added to the system

  10. Object-oriented Testing Strategies(4) • Validation Testing • Are we building the right product? • Validation succeeds when software functions in a manner that can be reasonably expected by the customer. • Focuses on visible user actions and user recognizable outputs • Validation tests are based on the use-case scenarios, the object behavior model, and the event flow diagram • Apply: • Use-case scenarios from the software requirements spec • Black-box testing to create a deficiency list • Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers

  11. Object-oriented Testing Strategies(5) • Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams • Finger pointing defence: • Design error-handling paths that test external information • Conduct a series of tests that simulate bad data • Record the results of tests to use as evidence • Types of System Testing: • Recovery testing: how well and quickly does the system recover from faults • Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters) • Stress testing: place abnormal load on the system • Performance testing: investigate the run-time performance within the context of an integrated system

  12. Test Case Design(1) • Each test case should be uniquely identified and be explicitly associated with a class to be tested • the purpose of the test should be stated • A list of testing steps should be developed for each test and contains: • A list of specified states for the object that is to be tested • A list of messages and operations that will be exercised as a consequence of the test • A list of exceptions that may occur as the object is tested • A list of external conditions needed to be changed for the test • Supplementary information required to understand or implement the test • OO testing focuses on designing appropriate sequences of operations

  13. Testing Methods at the Class Level(1) • Random Testing : requires large number of data permutation and combination • Identify operations applicable to a class • Define constraints on their use– e.g. the class must always be initialized first • Identify a minimum test sequence – an operation sequence that defines the minimum life history of the class • Generate a variety of random test sequences– this exercises more complex class instance life histories

  14. Testing Methods at the Class Level(2) • Example of Random Testing 1) consider an account class that has the following operations: open, setup, deposit, withdrawal, balance, summarize, credit Limit, close 2)The account must be opened first and closed on completion

  15. Testing Methods at the Class Level(3) • Example of Random Testing 3) a variety of behaviors may occur: open•setup•deposit•[deposit | withdrawal | balance| summarize | creditlimit]n•withdrawal•close 4)different operation sequences can be generated randomly: test case #1: open•setup•deposit•deposit•balance•summarize• withdrawal•close test case #2: open•setup•deposit•withdrawal•deposit•balance• credit limit•withdrawal•close

  16. Testing Methods at the Class Level(4) • Partition Testing : reduces the number of test cases required to test a class (remember ECP) • Input and output are categorized • Deriving partitioning categories: • State-based partitioning • Categorizes class operations based on their ability to change the state of the class • Tests designed in way so that operations that cause state changes are tested separately from those that do not • Example: • Test case #sp1: open•setup•deposit•deposit•withdrawal•withdrawal•close • Test case #sp2: open•setup•deposit•summarize •credit limit• withdrawal•close

  17. Testing Methods at the Class Level(5) • Deriving partitioning categories: • Attribute-based partitioning • Categorizes class operations based on the attributes that they use and modify • Tests designed in way so that operations that use or modify attributes are tested separately from those that do not use or modify attributes • Example: for the account class, the attributes balance and credit limit can be used to define operations. Operations are divided into three partitions: 1) operations that usecredit limit 2)operations that modify credit limit 3)operations that do not use of modify credit limit

  18. Testing Methods at the Class Level(6) • Deriving partitioning categories: • Category-based partitioning • Categorizes class operations based on the generic function that each performs such as initialization, computation, query, termination • Example: operations in the account class can be categorized as: 1) initialization (open, setup) 2) computation (deposit, withdraw) 3)queries (balance, summarize, credit limit) 4)termination (close)

  19. Interclass Test Case Design(1) • Test case design becomes more complicated as integration of the OO system begins – testing of collaboration between classes • Refer to diagram

  20. Interclass Test Case Design(2) • Multiple class testing • For each client class, use the list of class operators to generate a series of random test sequences that send messages to other server classes • For each message generated, determine the collaborator class and the corresponding operator in the server object • For each operator in the server object (invoked by a client object message), determine the message that it transmits • For each of the message, determine the next level of operators that are invoked and incorporate these into the test sequence.

  21. Interclass Test Case Design(3) • Multiple class testing : example Consider a sequence of operations for the bank class relative to an ATM class: verifyAcct•verifyPin•[[verifyPolicy•withdrawReq] | depositReq | AcctInfoReq]n A random test case for the bank class might be Test case #r3: verifyAcct•verifyPin•depositReq The collaborators invoked for the above test case are ValidationInfo to execute verifyAcct and verifyPin. Collaborate with Account to execute depositReq Thus a new test case is Test case #r4 : verifyAcctBank[validAcctValidationInfo]•verifyPinBank•[ValidPinValidationInfo•depositReq•[depositAccount]

  22. Interclass Test Case Design(4) • Test derived from behavior models • Use the state transition diagram as a model • Test cases must cover all states • 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

  23. Testing MethodsApplicable at Interclass Level(1) • Cluster Testing • Concerned with integrating and testing clusters of cooperating objects • Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters • Approaches to cluster testing • Use-case or scenario testing • Testing is based on a user interactions with the system • Has the advantage that it tests systems features as experienced by users • Thread testing – tests the systems response to events as processing threads through the system • Object interaction testing – test sequences of object interactions that stop when an object operation does not call on services from another object

  24. Testing MethodsApplicable at Interclass Level(2) • Use Case/Scenario-based Testing • Based on • Use cases • Corresponding sequence diagrams • Identify scenarios from use-case and supplement these with interaction diagrams that show the objects involved in the scenario • Concentrates on functional requirements • Every use case • Every fully expanded (<<extend>>) combination • Every fully expanded (<<uses>>) combination • Tests normal as well as exceptional behavior

  25. OO Test Design Issues • White-box testing methods can be applied to testing the code used to implement operations • Black-box testing methods are appropriate for testing OO systems • OO programming brings additional testing concerns • Classes may contain operations that are inherited from superclass • Subclasses may contain operations that were redefined rather than inherited • All classes derived from a previously tested base class need to be thoroughly tested.

  26. Summary • One strategy is a bottom-up approach – class, integration, validation and system level testing

More Related