Search PPTs

Thursday, July 25, 2013

PPT On OBJECT ORIENTED TESTING

Presentation On OBJECT ORIENTED TESTING
Download

OBJECT ORIENTED TESTING Presentation Transcript:
1.OBJECT ORIENTED TESTING

2.BASIC UNIT FOR TESTING INHERITANCE AND TESTING
The class is the smallest unit for testing. This is due to the following reasons.

A) methods are meaningless apart form their class.
B) we can design, method tests, only if we take a class into consideration.
C) class behavior should be verified before a class is reused or promoted to a library.

3.OBJECT ORIENTED TESTING
The goal is to provide some design paradigms that help us to perform object oriented testing (OOT).
Object oriented software centers on a class and the inheritance and encapsulation that affect a class.

4.The class clusters are the practical unit for testing.

A) it is typically impossible to test a class in total isolation.

B) it is not cost effective to develop a complete set of drivers and stubs for every class.

C) a smaller testing budget usually means larger clusters.

5.BASIC CONCEPTS OF STATE MACHINES
A state machine can model the behavior of such classes. They are also called as sequential machines.

The state determined message response patterns are called the behaviour of an objects.

State machines are an engineering application of mathematical models known as finite automata.

6.State-Based Behaviour
A state machine accepts only certain sequences of input and rejects all other. State based behaviour means that the same input is not necessarily always accepted and when accepted, does not necessarily produce the same output.

A state machine is a model that describes behaviour of the system under test in terms of events, states and actions.

7.Mealy/Moore Machines
There are two main variants of state models
Moore Machines
Transitions do no have output
An output action is associated with each state.
Mealy Machine
Transitions have output
No output action is associated with state
In software engineering models, the output action often represents activation of a process, program method or module

8.Design guidelines- Basic requirements
One state must be designated as the initial state.
At least, one state must be designated as the final state. If not, assumptions about termination should be made explicit.
There are no equivalent states. (equivalent state produce exactly the same response for all events visible to the machine in question)
Every defined event and every defined action must appear in at least one transition.
There should be an explicit definition of the mechanism to handle events which are implicity rejected.

9.Limitations of the Basic State Models.
State diagrams can be easily drawn or read up to 20 states. Tabular representation helps but is not suitable for large states.
Concurrency cannot be modeled. Only a single state may be active, so the basic model cannot accommodate two or more simultaneous transition processes. Only one state may client/server system.
With even a moderately large number of states, a state diagram becomes a spaghetti ball.
Basic models do not offer any mechanisms for partitioning or hierarchic abstraction  .

10.Concatenation  
Concatenation involves the formation of a subclass that has no locally defined features other than the minimum requirement of a class definition.
Class hierarchies that do not meet these condition are very likely to be buggy.
 

No comments:

Related Posts Plugin for WordPress, Blogger...

Blog Archive