New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here


by: Paxton Okuneva


Paxton Okuneva
GPA 3.57

Stephen Thebaut

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Stephen Thebaut
Class Notes
25 ?




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.

Popular in Computer Engineering




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


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


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'

Why people love StudySoup

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Allison Fischer University of Alabama

"I signed up to be an Elite Notetaker with 2 of my sorority sisters this semester. We just posted our notes weekly and were each making over $600 per month. I LOVE StudySoup!"

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.