SOFTWARE TESTVERIFI CEN 6070
Popular in Course
Popular in Computer Engineering
This 37 page Class Notes was uploaded by Paxton Okuneva on Saturday September 19, 2015. The Class Notes belongs to CEN 6070 at University of Florida taught by Stephen Thebaut in Fall. Since its upload, it has received 14 views. For similar materials see /class/207040/cen-6070-university-of-florida in Computer Engineering at University of Florida.
Reviews for SOFTWARE TESTVERIFI
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/19/15
Testing ObjectOriented Software A Brief Overview Software Testing and Verification Lecture 12 Prepared by Stephen M ThebouT PhD University of Florida Reference Software Test and Analysis ProcessL Princines and Technigues by Michal Young and Mauro Pezze Projected publication Spring 2007 by John Wiley amp Sons Other sources are readily identifiable via your favorite Internet search engine l The same basic pattern of testing procedural software using functional black box tests supplemented by structural white box tests working from the unit level toward the system level with one or more integration steps also applies to object oriented software testing 39 Sorne features of object oriented lan uages however require special egies andor other considerations Similarities and Differences conl d Such features include the inherently state dependent behavior of methods encapsulation of methods and state inheritance and polymorphism and run time binding of methods The impact of these features lessens as testing level increases however We begin by brie y summarizing the issues and testing related considerations associated with each of these features quot Next we present simple models for unit object class and the initial instance of integration inter object class testing Higher level testing of object oriented systems is basically similar to that of other systems and is not considered further The behavior of methods depend on both their parameters or inputs and the underlying of the object quot For example consider a linear list object class with inspection method ty The result of this operation either true or false clearly depends on the state of the underlying object Thus when testing object oriented soltware techniques which assume stateless method behavior should be avoided quot How would one extend the input partition and combinatorial test case design approaches considered previously to deal with state dependent program behavior Stole Dependent Behavior of Methods coni d Ad hoc adaptations of these approaches are straightforward when combined with standard state machine models of program behavior We discuss the use of such models when considering object class testing Objects are comprised of both public and private attributes and methods quot This can be problematic when the results of operations being tested are private and therefore hidden from the tester The result of a method append on our list object class for example may only be visible through a limited set of public attributes ad Encapsulation of Methods and State conl d Special instrumentation may be required to interpret the results of methods that result in hidden state changes or to access methods that are themselves private Inheritance Inheritance is an abstraction mechanism that allows object classes to specialized or extended from one or more other object classes The resultant child object class inherits attributes and methods from these ancestor classes changing some and adding others Testing issues which arise in the presence of inheritance involve d ermining which methods be re 39 quot New methods obviously must be tested as must changed methods unless it can be shown that their behavior is the same Unchanged methods which interact with changed or new methods may also need to be tested in this context Inheritance coni d In general testers must determine when new tests must be designed when old tests can be re run and when re testing can be avoided all together Polymorphism and Dynamic Binding Many object oriented languages allow variables types and method bindings to change dynamically For example when the generic elements of object class list are dynamically bound to particular types list operations such as appendvaue will be bound to particular methods Polymorphism and Dynamic Binding coni d Testers must be aware of the bindings that may occur with different objects and utilize techniques for determining which combinations of bindings to test Object Class Testing Unit testing of object oriented software normally focuses on object classes as opposed to individual methods Methods often interact in altering object state and their individual behavior can be obscured due to encapsulation when considered in isolation Therefore treating individual methods as units is usually not practical State machine models provide a useful means for describing object states and transitions quot States can be inferred from descriptions of methods that act differently or return different results depending on the state of the object Input partition and combinatorial test case design approaches may be applied on a state by state basis A A Simple Example Consider the operations for a generic Stack object New Bring a stack into existence Push Add an element to the top of a stack Top Evaluate the top element of a stack without removing it A Simple Example conl d Retract Remove the top element from a stack and return the modified stack IsEmpty True if and only if there are no elements on a stack A Simple Example conl d With method signatures New gt Stack Push Stack Elem gt Stack Top Stack gt Elem Retract Stack gt Stack IsiEmpty Stack gt Boolean LJl Suppose the stack speci cation requires a storage capacity of N elements H many different states would be required to represent every possible count of the elements stored quot How might one partition the states into equivalence classes wrt the methods defined if the goal is to produce a model of how one method affects another A Simple Example conl d The Boolean inspection method IsiEmpty suggests two important abstract states for interpreting the behavior of methods empty and non empty Top for example is not defined in state empty Similarly Retract acts differently depending on the state of the stack A Simple Example cont d State Machine Model Push Retract Retra Ct Retract A Simple Example conl d Test cases sequences of method calls should be designed which cover all transitions in the state machine model State machine models are sometimes included in object oriented program specifications In the UML family of notations the take the form of state diagrams Object Class Testing conl d Functional test cases based on the state machine model should be augmented with structural tests derived from class source code Special attention should be given to exception handling Design additional tests for intra class polymorphic calls InterObject Class Testing Inter class testing is the first level of integration testing for object oriented software Focus is interactions among objects of different classes As with imperative software integration should proceed incrementally Just as a calling hierarchy allows design of an integration strategy for imperative soltware useinclude relations serve this purpose for object oriented soltware quot Object classes A and B are related by a useinclude relation if objects of class A make method calls on objects of class B or if class A includes class B Useinclude relations may be derived from a conventional UML class diagram sad 1 Since there is generally no single root wg usually proceeds cluster by clUSLe n a bottom up fashion starting with leaf classes that depend on no others 0 The brute force approach of testing all combinations of calls and states while climbing useinclude relations is imprac tical for non trivial systems InterObject Class Testing conl d Coverage strategies based on the combinatorial approaches considered previously are therefore appropriate Nominal interaction combinations may also be identi ed from UML sequence or collaboration diagrams Such diagrams can be thought of as test scenarios created during system design InterObject Class Testing conl d Unexpected or illegal interaction sequences should also be exercised to check error handling Oracles for Object Classes Unit intra class and integration inter class testing require drivers and stubs to exercise classes under test and oracles to inspect test results Constructing drivers and stubs is similar to that for procedural software Encapsulation of object state however can make the construction of oracles more difficult Oracles for Object Classes conl d The result of executing a sequence of methods is both the outputs produced and the change in state of the object For example if TopPushstackTopstack does not add a copy of the top most element to the stack the result is erroneous regardless of the output produced Oracles for Object Classes cont d Expected result of TopPushstackTopstack Output X State change Oracles need to check both the validity of output and state but quotLe of objects may not be directly accessible One solution build oracles to subvert the encapsulation by modifying source code to allow inspection of private variables Should such modifications be removed alter testing or lelt in the delivered code o If modifications are removed we risk differences in behavior between what is tested and what is used masked or introduced faults performances differences Modi cations left in the code or design rules requiring programmers to provide observabiity interfaces avoid such discrepancies but incur some overhead Oracles for Object Classes conl d Ideally the interface for observing object state should be separated from the main class as allowed by C friend classes An interface that produces a readable representation of object values is useful in debugging as well as testing Testing ObjectOriented Software A Brief Overview Software Testing and Verification Lecture 12 Prepared by Stephen M ThebouT PhD University of Florida
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'