1 / 30

Chapter 23 Object-Oriented Testing

Chapter 23 Object-Oriented Testing. Object-Oriented Testing. begins by evaluating the correctness and consistency of the OOA and OOD models testing strategy changes the concept of the ‘unit’ broadens due to encapsulation

bernard-ross
Download Presentation

Chapter 23 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. Chapter 23Object-Oriented Testing

  2. Object-Oriented Testing • begins by evaluating the correctness and consistency of the OOA and OOD models • testing strategy changes • the concept of the ‘unit’ broadens due to encapsulation • integration focuses on classes and their execution across a ‘thread’ or in the context of a usage scenario • validation uses conventional black box methods • test case design draws on conventional methods, but also encompasses special features

  3. Testing OOA and OOD Model • Correctness of OOA and OOD Models The notation and syntax used to represent analysis and design models will be tied to the specific analysis and design method that is chosen for the project. Hence, syntactic correctness is judged on proper use of the symbology; each model is reviewed to ensure that proper modeling conventions have been maintained. • Consistency of OOA and OOD Models The consistency of OOA and OOD models may be judged by considering the relationships among entities in the model. To assess consistency, each class and its connections to other classes should be examined. The class-responsibility-collaboration model and an object-relationship diagram can be used to facilitate this activity.

  4. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a reasonable source.

  5. Broadening the View of “Testing” Review of OO analysis and design models is especially useful because the same semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, design, and code level. Therefore, a problem in the definition of class attributes that is uncovered during analysis will circumvent side effects that might occur if the problem were not discovered until design or code (or even the next iteration of analysis).

  6. OOT Strategy • class testing is the equivalent of unit testing • operations within the class are tested • the state behavior of the class is examined • integration applied three different strategies • thread-based testing—integrates the set of classes required to respond to one input or event • use-based testing—integrates the set of classes required to respond to one use case • cluster testing—integrates the set of classes required to demonstrate one collaboration

  7. UN IT Testing • Integration Testing in the OO Context The first, 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. Regression testing is applied to ensure that no side effects occur. • The second integration approach use-based testing, begins the construction of the system by testing those classes (called independent classes) that use very few (if any) of server classes. • After the independent classes are tested, the next layer of classes, called dependent classes, that use the independent classes are tested. This sequence of testing layers of dependent classes continues until the entire system is constructed

  8. Validation Testing in an OO Context • At the validation or system level, the details of class connections disappear. Like conventional validation, the validation of OO software focuses on user-visible actions and user-recognizable output from the system. To assist in the derivation of validation tests, the tester should draw upon the use-cases that are part of the analysis model. • The use-case provides a scenario that has a high likelihood of uncovered errors in user interaction requirements.

  9. OOT—Test Case Design Berard [BER93] proposes the following approach: • 1. Each test case should be uniquely identified and should be explicitly associated with the class to be tested, • 2. The purpose of the test should be stated, • 3. A list of testing steps should be developed for each test and should contain [BER94]: • a. a list of specified states for the object that is to be tested • b. a list of messages and operations that will be exercised as a consequence of the test • c. a list of exceptions that may occur as the object is tested • 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) • e. supplementary information that will aid in understanding or implementing the test.

  10. Fault Based Testing

  11. Fault-based testing misses two main types of errors: (1) incorrect specifications and (2) interactions among subsystems. • When errors associated with incorrect specification occur, the product doesn't do what the customer wants. It might do the wrong thing or it might omit important functionality. But in either circumstance, quality (conformance to requirements) suffers • Scenario Based Testing - Scenarios uncover interaction errors. But to accomplish this, test cases must be more complex and more realistic. Scenario-based testing tends to exercise multiple subsystems in a single test (users do not limit themselves to the use of one subsystem at a time).

  12. Testing Surface Structure and Deep Structure Surface structure refers to the externally observable structure of an OO program. That is, the structure that is immediately obvious to an end-user. Rather than performing functions, the users of many OO systems may be given objects to manipulate in some way.

  13. Deep structure refers to the internal technical details of an OO program. That is, the structure that is understood by examining the design and/or code. • Deep structure testing is designed to exercise dependencies, behaviors, and communication mechanisms that have been established as part of the system and object design of OO software. • The analysis and design models are used as the basis for deep structure testing.

  14. Testing the CRC Model 1. Revisit the CRC model and the object-relationship model. 2. Inspect the description of each CRC index 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 reasonable source. 4. Using the inverted connections examined in step 3, determine whether other classes might be required or whether responsibilities are properly grouped among the 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 through each evolution of the OOA model.

  15. OOT Methods: Random Testing • Random testing • identify operations applicable to a class • define constraints on their use • identify a miminum test sequence • an operation sequence that defines the minimum life history of the class (object) • generate a variety of random (but valid) test sequences • exercise other (more complex) class instance life histories

  16. consider a banking application in which an account class has the following operations: open, setup, deposit, withdraw, balance, summarize, creditLimit, and close The minimum behavioral life history of an instance of account includes the following operations: open•setup•deposit•withdraw•close

  17. Partition Testing at the Class Level • Input and output are categorized and test cases are designed to exercise each category • Partitioning categories are divided as following ---

  18. INTERCLASS TEST CASE DESIGN • For each client class, use the list of class operations to generate a series of random test sequences. The operations will send messages to other server classes. • For each message that is generated, determine the collaborator class and the corresponding operation in the server object. • For each operation in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits. • For each of the messages, determine the next level of operations that are invoked and incorporate these into the test sequence.

  19. OOT Methods: Partition Testing • Partition Testing • reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software • state-based partitioning • categorize and test operations based on their ability to change the state of a class • attribute-based partitioning • categorize and test operations based on the attributes that they use • category-based partitioning • categorize and test operations based on the generic function each performs

More Related