P. 1
Issues in OO Testing1

Issues in OO Testing1

|Views: 9|Likes:
Published by Simardeep Sethi

More info:

Published by: Simardeep Sethi on Jan 09, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

11/11/2011

pdf

text

original

Testing Object-Oriented Systems

:

S D

Testing Object-Oriented Applications: Why is it Different?
‡ ‡ ‡ ‡ No sequential procedural executions No functional decomposition No structure charts to design integration testing Iterative O-O development and its impact on testing and integration strategies

S D

Issues Related to Testing Object-Oriented Applications
‡ Implications of inheritance
± ± ± ± New context of usage Multiple Inheritance True specialization -- reuse of test cases Programming convenience -- must test subclasses and superclasses

S D

Issues Related to Testing Object-Oriented Applications
‡ Implications of encapsulation
± Makes reporting on state difficult ± Correctness proof may help but difficult

‡ Implications of Polymorphism
± Each possible binding requires separate test ± Makes integration more difficult

S D

Issues Related to Testing Object-Oriented Applications ‡ White-box testing ± Appropriate only for methods not for classes ± Control graph testing is not applicable to methods ‡ Black-box testing ± Applicable to classes ± The distance between OO specification and implementation is small compared to conventional systems. S D .

‡ Test process strategy ± Design a little. and test a little cycle S D . code a little.Issues Related to Testing Object-Oriented Applications ‡ Integration strategy ± Thread-based: All classes needed to respond to certain external input ± Uses-based: Starts with classes that do not use other classes. then continue with classes that use the first group and so on.

The Structured Testing Pyramid Requirement Definition Systems Testing Preliminary Design Integration Testing Detailed Design Unit Testing Coding S D .

Unit Test ‡ What is a unit? ± A single. a unit is a method within a class. cohesive function? ± A function whose code fits on one page? ± The amount of code that can be written in 4 to 40 hours? ± Code that is assigned to one person? ‡ In object-oriented programs. S D .

Methods for Generating Test Cases For Unit Testing ‡ Statement coverage ‡ Graph based ± Branch coverage ± Condition coverage ± Path coverage ‡ All unit testing methods are also applicable to testing methods within a class. S D .

Integration Testing ‡ Strategies: ± ± ± ± Bottom-up guided by functional decomposition tree Top-down guided by functional decomposition tree Big bang Pairwise ‡ All focus on structure and interface S D .

Systems Testing ‡ Performed exclusively in terms of inputs and outputs of the system ‡ Performed mostly on the target platform ‡ Thread-based: ± The behavior that results from a system level input ± An interleaved sequence of system inputs (stimuli) and outputs (responses) ± A sequence of transitions in a state machine model of the system S D .

The OO Testing Pyramid Use Case Analysis Use Case Testing Class Hierarchy Design Cluster (Integration) Testing Class Testing Method Design Method Testing Method Coding S D .

Method Testing ‡ Tests each individual method ‡ Performed by the programmer ‡ Glass box using method code ± Statement Coverage ± Decision Coverage ± Path Coverage S D .

Class Testing ‡ Tests All private and publics methods in a class ‡ Test accessor methods before creator methods to control complexity ‡ Class testing is a first level of integration testing ‡ Mainly black-box testing based on class behavior ‡ Must use stubs and drivers to substitute for methods S D .

Class Testing Method 1: ««««.. ««««.. S D . ««««. Method 3: ««««.. Method 2: ««««. ««««.

S D . ‡ Write test cases for abstract classes separately but run them as part of testing their concrete subclasses.Abstract Vs Concrete Classes ‡ Abstract classes are those that can not be instantiated ‡ They can¶t be tested directly but as part of testing concrete classes. ‡ Reuse test cases with different concrete subclasses.

Example Patient Register_a_patient In-patient Register_in_patient Out-patient Register_out_patient S D .

What Methods to Test Within Classes ‡ New methods: defined in the class under test and not inherited or overloaded by methods in a superclass: Complete testing ‡ Inherited methods: defined in a superclass of the class under test: Retest only if the methods interacts with new or redefined method. S D . ‡ Redefined methods: defined in a superclass of but redefined in the class under test : complete Retest reusing tests from the superclass.

the following three techniques can be used to perform functional testing for the class: ± State-Transition testing ± Transaction-Flow testing ± Exception testing S D .Class Testing Techniques In addition to testing methods within a class (either glass box or black box).

(OMT dynamic model) ‡ The state of an object is the combination of all the attribute values and objects that the object contains. which may yield an action.State-Transition Testing ‡ A state-transition model describes the different states and transitions of a class in the context of its position in the inheritance hierarchy. ‡ An object may transition from a state to state as a result of an event. S D .

Example Prospect Receive application Establish-membership Member Receive cancellation 5-years anniversary Retired-member Receive cancellation Life-member S D .

State-Transition Testing ‡ Create test cases corresponding to each transition path that represent a full object life cycle ‡ Make sure each transition is exercised at least once. S D .

‡ A cluster specification should include methods from each class that will be accessed ‡ Cluster testing focuses on the interaction among the instances of the classes in the cluster ‡ It assumes that each class has been tested individually ‡ Cluster testing is considered a second level of integration testing S D .Cluster (Integration) Testing ‡ A cluster is a collection of classes (possibly from different systems) cooperating with each other via messaging.

Cluster (Integration) Testing: Why is it Different? ‡ ‡ ‡ ‡ Event-Driven execution No functional decomposition The sequence of execution is not known Integration testing must be driven by how object will behave dynamically ‡ Object composition introduces a new dimension of integration testing S D .

i.e.. no method to send or receive a message ± Incompatible method and message in sender and receiver ± Incorrect event timing between object actions ± Incorrect instantiation or destruction of objects S D .Types of Errors Found During Integration Testing ‡ Messaging errors: ± Failure to meet a requirement.

) ‡ User interface errors: ± A given sequence of user actions does not have the expected effect on the component. ± The timing of events received from the user results in incorrect functioning of the component S D .Types of Errors Found During Integration Testing (cont.

Methods for Forming Clusters ‡ Function-based clustering ± Based on requirements and use cases ± Difficult to perform if requirements were not available during the design phase ‡ Subject-based clustering ± Based on subject areas that need to test separately ‡ Project Schedule-based clustering ‡ Contract-based clustering S D .

Techniques for Object-Oriented Integration Testing ‡ Message Quiescence ‡ Event Quiescence S D .

‡ A Method/Message path (MM-Path) is a sequence of method executions linked by messages. S D . i.e. reaches a message Quiescence. ‡ An MM-Path starts with a method and ends when it reaches a method that does not issue a message of its own..Message Quiescence ‡ A method is a single unit of code that performs a single cohesive function.

An Object Network Object 1 Object 3 Method 2 Method 1 Method 1 Method 2 Method 3 Object 2 Method 1 Method 3 Method 2 S D .

MM-Paths Object 1 Object 3 Method 2 Method 1 Method 1 Method 2 Method 3 Object 2 Method 1 Method 3 Method 2 S D .

Event Quiescence ‡ An MM Path is triggered by a system-level port input event and end with a system-level port output event ‡ When this port output event is reached. S D . the system becomes quiescent and waits for another port event ‡ An input port event followed by a set of MMPaths. and terminated by an output event is called Atomic System Function (ASF).

Atomic System Function Input port event (A) Object 1 Output port event (A) Object 3 Method 2 Method 1 1 Method 1 Method 2 Method 3 Object 2 Method 1 Output port event (B) Method 3 2 Input port event (B) 3 Method 2 S D .

‡ Use cases provide a more precise mechanism for writing test cases. S D .System Testing ‡ All rules and methods of traditional systems testing are also applicable applicable to objectoriented. ‡ A thread can be ³re-defined´ as a sequence of method executions linked by messages in the object network.

What Are Use Cases ‡ A Use Case describes a scenario in which a user interacts with the system to accomplish a particular task. ‡ Each Use Case specifies: ± ± ± ± The task to be performed The user class Different actions and corresponding system responses Estimated frequency of use ‡ Very useful for deriving test cases early in the requirement phase S D .

Example Use Case # 1 of the Telephone Banking System: Task: User Class: Frequency: User Action User dials the number User enters invalid account number Making a balance transfer Current customer one per week per customer System Response System plays greeting and ask for account number System informs user and ask for account number again System asks for PIN# User enter a valid account number S D .

Static Testing and Analysis of Object-Oriented Models S D .

‡ Use cases ± A representation of the systems usage S D . number and type of parameters. its responsibilities.Examples of Analysis and Design Models to be Tested ‡ CRC cards ± English text descriptions of a single class. pre. and it collaborators with other classes ‡ Class specifications ± Complete specification of a class including its data structure.and post-conditions. method names. return values.

clusters.) ‡ State-Transition Models ± State transition diagrams for classes.Examples of Analysis and Design Models to be Tested (Cont. and subsystems ‡ Object network ± Message sequence between methods in classes ‡ Transaction-Flow Models S D .

Testing Models ‡ Criteria ± Correctness ± Completeness ± Consistency ‡ Early informal models are tested informally ‡ The criteria should be interpretive in the context of iterative incremental approach S D .

Model Testing Approaches ‡ Testing by comparison ± compares each model to its predecessor or to previous forms of the model ‡ Testing by inspection ± uses checklists to make sure that the model meets certain criteria ‡ Testing by verification ± follows certain steps to assure completeness and consistency of one part of the model with another S D .

‡ Claimed benefits of the OO approach can only be obtained through: ± Robust development process ± Good development practices by individuals ± Automated tools ‡ The OO approach introduces substantial difficulties to the testing process. S D .Conclusion ‡ The OO is not always the best approach to system development.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->