Download - OBJECT ORIENTED TESTING

Transcript
Page 1: OBJECT ORIENTED TESTING

OBJECT ORIENTED TESTING

SYSTEM TESTING

UNIT TESTING

INTEGRATIONTESTING

INHERITANCE

POLYMORPHISM

ENCAPSULATION

By Maj Nicko Petchiny

Page 2: OBJECT ORIENTED TESTING

REFERENCES

• Developing an OO Software Testing and Maintenance Environment (King, Gao, Hsia, et-al)

• Incremental Testing of OO Class Structures (Harrold, McGregor)

• OO Integration Testing (Jorgensen, Ericksen)

• OO Software Testing, A Hierarchical Approach (Siegel)

Page 3: OBJECT ORIENTED TESTING

OUTLINE

• TRADITIONAL VS OO SW DEVELOPMENT AND TESTING

• OO CONCEPTS/EFFECT ON TESTING

• PROPOSED OO INTEGRATION TESTING APPROACH

• EXAMPLE USING TEST APPROACH

• CONCLUSION

Page 4: OBJECT ORIENTED TESTING

TRADITIONAL DEVELOPMENT & TESTING (WATERFALL LIFE CYCLE)

• REQUIREMENTS SPEC SYSTEM TESTING

• PRELIMINARY DESIGN INTEGRATION TESTING

– FUNCTIONAL– DECOMPOSITION

• DETAILED DESIGN UNIT TESTING

Page 5: OBJECT ORIENTED TESTING

TRADITIONAL TESTING

• SYSTEM– VERIFY SW SATISFIES ALL SW REQRS

• INTEGRATION– BASED ON STRUCTURE OF DESIGN– TOP DOWN OR BOTTOM UP APPROACH

• UNIT– ENCAPSULATES FUNCTIONALITY

Page 6: OBJECT ORIENTED TESTING

OO DEVELOPMENT & TESTING

• DEVELOPMENT BASED ON BEHAVIOUR

• COMPOSITION

• TYPICALLY RAPID PROTOTYPING

• INCREMENTAL APPROACH

• 3 TRADITIONAL TESTING LEVELS ARE NOT AS CLEARLY DEFINED

Page 7: OBJECT ORIENTED TESTING

OBJECT ORIENTED TESTING

• SYSTEM– SAME AS TRADITIONAL– STILL BASED ON REQRS SPEC

• UNIT– TWO COMMON STRUCTURES USED

• METHOD*• CLASS

– SAME AS TRADITIONAL(DRIVERS & STUBS)

Page 8: OBJECT ORIENTED TESTING

METHOD 2

METHOD 1

METHOD METHOD METHOD

METHOD

METHOD

OBJECT CLASS A

B C D

E

F

Page 9: OBJECT ORIENTED TESTING

METHOD 2

METHOD 1

METHOD METHOD METHOD

METHOD

METHOD

OBJECT CLASS A

B C D

E

F

Page 10: OBJECT ORIENTED TESTING

OO INTEGRATION TESTING

• MAIN PROGRAM IS MINIMIZED

• MOST COMPLICATED PART OF OO TESTING

• TESTING BASED ON COMPOSITION IN BOTTOM UP APPROACH

• USE OF CLUSTERS

• ORD - CLASS DEPENDENCIES

• BBD OR DIRECTED GRAPHS - SHOWS METHOD DEPENDENCIES

Page 11: OBJECT ORIENTED TESTING

meth1

meth3meth2

Class 1

A

B

OUTPUT PORT EVENT

A

meth1 meth3

meth2

meth2

meth1

B

OUTPUT PORT EVENT

Class 2

Class 3

MM-Path

Message

1

2

3

Page 12: OBJECT ORIENTED TESTING

OO CONCEPTS/EFFECTS ON TESTING

• ENCAPSULATION

• POLYMORPHISM

• INHERITANCE

Page 13: OBJECT ORIENTED TESTING

ENCAPSULATION

• CLASS STRUCTURE

• INTERFACE DEFINED BY PUBLIC METHODS

• BEHAVIOR DEFINED BY METHODS THAT OPERATE ON ITS INSTANCE DATA (IN CONVENTIONAL SEPARATE)

• HELPS ENFORCE INFO HIDING

Page 14: OBJECT ORIENTED TESTING

ENCAPSULATION TESTING ISSUES

• MINIMIZES RIPPLE EFFECT (AT THE UNIT LEVEL) OF MAKING A CHANGE

• HIGHLY DELOCALIZED– CHANGE COULD RESULT IN

SIGNIFICANT REGRESSION TESTING

• ORDER OF TESTING IS IMPORTANT (CAN REDUCE TESTING EFFORT)

Page 15: OBJECT ORIENTED TESTING

METHOD

METHOD

CLASS A

CLASS B

CLASS C

METHOD

USES USES

Page 16: OBJECT ORIENTED TESTING

POLYMORPHISM

• AN ATTRIBUTE MAY HAVE MORE THAN ONE SET OF VALUES

• AN OPERATION MAY BE IMPLEMENTED BY MORE THAN ONE METHOD ( e.g GRAPHICS )

• OVERLOADING (type or number of variables)

• DYNAMIC BINDING

Page 17: OBJECT ORIENTED TESTING

OO TESTING ISSUES

• POLYMORPHISM– DO YOU TEST ONE VARIANT ?– DO YOU TEST ALL VARIATIONS ?– IF ALL, DO YOU TEST ALL VARIANTS AT

ALL LEVELS• UNIT

• “INTEGRATION” OR SYSTEM LEVEL

– REUSE DRIVERS AND STUBS

Page 18: OBJECT ORIENTED TESTING

INHERITANCE STRUCTURES

BASE

SUBCLASS

SINGLE

BASEBASE

SUBCLASS

SUBCLASS

SUBCLASS

BASE

MULTIPLE MULTIPLE LEVELS

Page 19: OBJECT ORIENTED TESTING

INHERITANCE

PARENT CLASS

MODIFIER

+

RESULT CLASS

Page 20: OBJECT ORIENTED TESTING

INHERITANCE

A

B

C

M2

+

A

M1

+

B

CA

M1

B

+

B

M2

+

C

Page 21: OBJECT ORIENTED TESTING

INHERITANCE MODIFIERS

• NONE (ONLY INHERITED ATTRIBUTE)

• ADD NEW ATTRIBUTE(S)

• REDEFINE PARENT’S ATTRIBUTE(S)

• VIRTUAL ATTRIBUTE (THREADS IN JAVA)

Page 22: OBJECT ORIENTED TESTING

OO TESTING ISSUES

• INHERITANCE– DO YOU COMPLETELY TEST ALL BASE

CLASSES AND THEIR SUB-CLASSES ?– DO YOU COMPLETELY TEST ALL BASE

CLASSES AND ONLY TEST THE CHANGES OR MODIFICATIONS IN THEIR SUB-CLASSES ?

– AT WHAT LEVELS DO YOU TEST?– IN WHICH ORDER DO YOU TEST?

Page 23: OBJECT ORIENTED TESTING

INHERITED TESTING

SCENARIO UNIT INTEGRATION

NONE X?

NEW X X?

REDEFINED X X

VIRTUAL (COMPLETEDBY SUBCLASS)

X X?

VIRTUAL ( NOTCOMPLETED)

Page 24: OBJECT ORIENTED TESTING

OO TESTING METHODOLOGY

• JORGENSEN AND ERICKSEN PROPOSE 5 LEVELS

• A METHOD - UNIT TESTING• MESSAGE QUIESCENCE - INTEGRATION• EVENT QUIESCENCE - INTEGRATION• THREAD TESTING -SYSTEM• THREAD INTERACTION -SYSTEM

Page 25: OBJECT ORIENTED TESTING

CONSTRUCT DEFINITIONS

• MM-PATH (METHOD MESSAGE - PATH) [MESSAGE QUIESCENCE]

– SEQUENCE OF EXECUTIONS LINKED BY MESSAGES.

– STARTS WITH METHOD AND ENDS WITH A METHOD THAT DOESN’T PRODUCE A MESSAGE

Page 26: OBJECT ORIENTED TESTING

CONSTRUCT DEFINITIONS

• ASF (ATOMIC SYSTEM FUNCTION) [EVENT QUIESCENCE]

– REPRESENTS AN INPUT EVENT– FOLLOWED BY A SET OF MM-PATHS– TERMINATED BY AN OUPUT EVENT

Page 27: OBJECT ORIENTED TESTING

meth1

meth3meth2

Class 1

INPUT PORT EVENT A

B

ASF INPUT PORT EVENT

OUTPUT PORT EVENT

A

meth1 meth3

meth2

meth2

meth1

B

ASF OUTPUT PORT EVENT

Class 2

Class 3

MM-Path

Message

1

2

3

Page 28: OBJECT ORIENTED TESTING

ATM PIN ENTRY

• CUSTOMER ENTERS CARD(EVENT)• SCREEN REQUESTING PIN ENTRY IS

DISPLAYED• AN INTERLEAVED SEQUENCE OF DIGIT KEY

TOUCHES WITH AUDIBLE AND VISUAL FEEDBACK

• POSSIBILITY OF CANCELLATION BY CUSTOMER

• SYSTEM DISPOSITION(VALID PIN OR CARD RETAINED)

Page 29: OBJECT ORIENTED TESTING

BANKCARDSLOT

SECURITY

SCREEN

Keypad

SpecialKeypad

NumKeypad

Page 30: OBJECT ORIENTED TESTING

getKeyEvents

parseKeyEvent

showMessage

pinForPan

checkPin

Screen

memberCard

ValidateCard

CardSlot

Bank

NumKeypad

Security

Customer inserts cardASF Starts here

Message is displayed

ASF ends here

Key pushers

Page 31: OBJECT ORIENTED TESTING

CONCLUSION

• OO TESTING LEVELS- UNIT &SYSTEM SAME AS TRADITIONAL LEVELS

• OO INTEGRATION TESTING IS DIFFERENT AND MORE COMPLEX

• OPTIMAL TEST ORDER SAVES

• TOOLS REQUIRED TO SCALE UP OO TESTING

• LIMIT DESIGNERS TO STRAIGHT INHERITANCE (NO REDEFINING)