Testing Object-Oriented Systems



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


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


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.

code a little. ‡ Test process strategy ± Design a little. then continue with classes that use the first group and so on. and test a little cycle S D .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.

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

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.

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 .

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

‡ Reuse test cases with different 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. S D . ‡ Write test cases for abstract classes separately but run them as part of testing their concrete subclasses.

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

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. ‡ Redefined methods: defined in a superclass of but redefined in the class under test : complete Retest reusing tests from the superclass.

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

(OMT dynamic model) ‡ The state of an object is the combination of all the attribute values and objects that the object contains. S D . ‡ An object may transition from a state to state as a result of an event. 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.

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 .

Cluster (Integration) Testing ‡ A cluster is a collection of classes (possibly from different systems) cooperating with each other via messaging. ‡ 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: 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 .

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 . i.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.Types of Errors Found During Integration Testing (cont. ± The timing of events received from the user results in incorrect functioning of the component S D .

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 .

‡ An MM-Path starts with a method and ends when it reaches a method that does not issue a message of its own.. i.e. ‡ A Method/Message path (MM-Path) is a sequence of method executions linked by messages. S D . reaches a message Quiescence.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 .

and terminated by an output event is called Atomic System Function (ASF). 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. the system becomes quiescent and waits for another port event ‡ An input port event followed by a set of MMPaths.

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 .

S D . ‡ Use cases provide a more precise mechanism for writing test cases.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 .Examples of Analysis and Design Models to be Tested ‡ CRC cards ± English text descriptions of a single class. number and type of parameters. and it collaborators with other classes ‡ Class specifications ± Complete specification of a class including its data structure. its responsibilities. return values.and post-conditions. pre. method names.

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

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 .

Conclusion ‡ The OO is not always the best approach to system development. 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.

Sign up to vote on this title
UsefulNot useful