ooad testing iii

Sunday, April 9, 2023Sunday, April 9, 2023 Object oriented TestingObject oriented Testing 11

Broadening The view of testingBroadening The view of testing

The construction of object oriented software begins with The construction of object oriented software begins with creation of analysis and design Modelcreation of analysis and design Model

These model are relatively informal representation of These model are relatively informal representation of system requirement and evolve into detailed model of system requirement and evolve into detailed model of classes , class connection and relationships, system design classes , class connection and relationships, system design and allocation and object designand allocation and object design

At each stage the model can be tested in an attempt to At each stage the model can be tested in an attempt to uncover errors prior to their propagation to next Iterationuncover errors prior to their propagation to next Iteration

The review of OO analysis and design model is especially The review of OO analysis and design model is especially useful because the same semantics constructs appear at useful because the same semantics constructs appear at analysis design and code levelanalysis design and code level

Consider an Example in which mistake is done initially in Consider an Example in which mistake is done initially in analysis phase ,and if not detected how extra effort will be analysis phase ,and if not detected how extra effort will be done as it propagates to other phasesdone as it propagates to other phases


Error in analysis PhaseError in analysis Phase

Consider a class in which number of attribute are defined Consider a class in which number of attribute are defined during first phase of analysisduring first phase of analysis

An Extraneous attribute is appended due to wrong An Extraneous attribute is appended due to wrong interpretation and two function are added to manipulate interpretation and two function are added to manipulate that attributethat attribute

If the model is shown to particular Domain expert errors If the model is shown to particular Domain expert errors can be detected, but suppose errors are not detected can be detected, but suppose errors are not detected what will happens.what will happens.

1) Special subclasses may have generated to accommodate 1) Special subclasses may have generated to accommodate

the unnecessary attribute or exception to do itthe unnecessary attribute or exception to do it

2) A misinterpretation of class Definition may lead to 2) A misinterpretation of class Definition may lead to

incorrect or extraneous class descriptionincorrect or extraneous class description

3) The behavior of system or it classes may be improperly 3) The behavior of system or it classes may be improperly

Characterized to accommodate Extraneous attribute Characterized to accommodate Extraneous attribute


Error propagated to DesignError propagated to Design

Following error will propagate in design phaseFollowing error will propagate in design phase

1) Improper allocation of Classes to subsystem and/or 1) Improper allocation of Classes to subsystem and/or

tasks may occur during these phasetasks may occur during these phase

2) Unnecessary design work may be expended to create 2) Unnecessary design work may be expended to create

the procedural design for operation that address the procedural design for operation that address

extraneous attribute extraneous attribute

3) The messaging Model will be incorrect3) The messaging Model will be incorrect

If error remained undetected during design and passes to If error remained undetected during design and passes to code activity more effort will be expended to generate code activity more effort will be expended to generate code, in addition testing will absorb more time code, in addition testing will absorb more time


Testing OOA and OOD ModelTesting OOA and OOD Model

Analysis and design model cannot be tested in conventional Analysis and design model cannot be tested in conventional sense ,because they cannot be executedsense ,because they cannot be executed

The different step for testing are as followsThe different step for testing are as follows

1) Correctness of OOA and OOD Models1) Correctness of OOA and OOD Models

1.1) The notation and syntax used to represent analysis and 1.1) The notation and syntax used to represent analysis and

design model will be tied to specific analysis and design design model will be tied to specific analysis and design

method that is chosen for productmethod that is chosen for product

1.2) Syntactic correctness is judged on proper use of 1.2) Syntactic correctness is judged on proper use of

symbology each model is reviewed for correct symbolic symbology each model is reviewed for correct symbolic

notationnotation

1.3) Semantic correctness can be judged based on model 1.3) Semantic correctness can be judged based on model

conformance to real world domain. If model accurately conformance to real world domain. If model accurately

reflect the real world then it is semantically correctreflect the real world then it is semantically correct


Consistency of OOA and OOD ModelsConsistency of OOA and OOD Models

An inconsistent model has representation in one part that An inconsistent model has representation in one part that are not reflected in other portion of Model are not reflected in other portion of Model

To access consistency CRC (class-responsibility-To access consistency CRC (class-responsibility-collaborator) card is used .It is represented as followscollaborator) card is used .It is represented as follows

The card consist of class name , its responsibility (operations) and its collaborators (other classes to which it sends message and on which it depends for accomplishment for its responsibilities


Evaluating consistency of Class Model using CRCEvaluating consistency of Class Model using CRC

To evaluate the class model following step recommended To evaluate the class model following step recommended

1) Revisit the CRC model and object relationship model. Cross 1) Revisit the CRC model and object relationship model. Cross check to ensure that all collaboration implied by the OOA check to ensure that all collaboration implied by the OOA model are properly Representedmodel are properly Represented

2) Inspect the description of each CRC index card to determine 2) Inspect the description of each CRC index card to determine if delegated responsibility is part of collaboration definitionif delegated responsibility is part of collaboration definition

3) Invert the connection to ensure that each collaborator that is 3) Invert the connection to ensure that each collaborator that is asked for services is receiving request from a reasonable asked for services is receiving request from a reasonable source source

4) Using the inverted connection examined in step 3, determine 4) Using the inverted connection examined in step 3, determine whether other classes might be required and whether whether other classes might be required and whether responsibility are properly grouped among the classesresponsibility are properly grouped among the classes

5) Determine whether widely requested responsibility might be 5) Determine whether widely requested responsibility might be combined into single responsibilitiescombined into single responsibilities

6) Step 1 through 5 are applied iteratively to each model6) Step 1 through 5 are applied iteratively to each model


Evaluating consistency of Class Model contd…Evaluating consistency of Class Model contd…

Once OOD model is created review of system design and Once OOD model is created review of system design and object design has to be conductedobject design has to be conducted

In system design the overall product architecture, In system design the overall product architecture, subsystem that compose product ,the manner in which subsystem that compose product ,the manner in which subsystem are allocated to processors, the allocation of subsystem are allocated to processors, the allocation of classes to subsystem and the design of user interface has classes to subsystem and the design of user interface has to be testedto be tested

The object model should be tested against the object The object model should be tested against the object relationship network to insure that all design objects relationship network to insure that all design objects contain the necessary attribute and operation to implement contain the necessary attribute and operation to implement the collaboration defined for each CRC index card the collaboration defined for each CRC index card


Object Oriented Testing StrategiesObject Oriented Testing Strategies

Unit Testing in Object oriented Context Unit Testing in Object oriented Context When object oriented software is considered the concept of Unit When object oriented software is considered the concept of Unit

testing changes Drasticallytesting changes Drastically The reason for same is Encapsulation which drives the definition The reason for same is Encapsulation which drives the definition

of classes and object (i.e variable and function are represented of classes and object (i.e variable and function are represented in same class)in same class)

Instead of testing an Individual model, the smallest testable unit Instead of testing an Individual model, the smallest testable unit is encapsulated class or objectis encapsulated class or object

Because a class contain number of different operation and Because a class contain number of different operation and particular operation may exist as a part of different classes the particular operation may exist as a part of different classes the meaning has changedmeaning has changed

Class testing in OO software is Equivalent to unit testing in Class testing in OO software is Equivalent to unit testing in conventional software which tend to focus on algorithmic conventional software which tend to focus on algorithmic details of module and data flow across the module. Class testing details of module and data flow across the module. Class testing for OO software is driven by operation encapsulated by the class for OO software is driven by operation encapsulated by the class and state behavior of class. and state behavior of class.


Integration Testing in the OO ContextIntegration Testing in the OO Context

Object oriented software does not have a hierarchical control structure, Object oriented software does not have a hierarchical control structure, conventional top-down and bottom-up integration strategies can not be conventional top-down and bottom-up integration strategies can not be implementedimplemented

There are two different strategies for integration testing of OO systemThere are two different strategies for integration testing of OO system 1)Thread Based testing 1)Thread Based testing > > It integrate the set of Classes required to respond to one particular It integrate the set of Classes required to respond to one particular event or input for the system event or input for the system >> Each Thread is Integrated and tested individually. Regression testing Each Thread is Integrated and tested individually. Regression testing is applied to ensure that no side effect occurs is applied to ensure that no side effect occurs 2) Used based testing2) Used based testing > > It begins construction of the system by testing those independent It begins construction of the system by testing those independent classes that use very few of Server classes classes that use very few of Server classes > > After Independent classes are tested, the next layer of dependent After Independent classes are tested, the next layer of dependent classes that use this class is tested classes that use this class is tested > > This process continues until entire system is constructed This process continues until entire system is constructed


Validation Testing in an OO ContextValidation Testing in an OO Context

At the validation or system level, details of class connection At the validation or system level, details of class connection disappeardisappear

The validation of OO software focuses on user-visible action The validation of OO software focuses on user-visible action and user-recognizable output from the systemand user-recognizable output from the system

To assist in the derivation of validation tests, the tester should To assist in the derivation of validation tests, the tester should draw upon the use-case that are part of analysis model draw upon the use-case that are part of analysis model

The use-case provide a scenario that has high likelihood of The use-case provide a scenario that has high likelihood of uncovered errors in user requirement uncovered errors in user requirement

Conventional Black Box Testing Method can be used Conventional Black Box Testing Method can be used


Test Case Design For OO SoftwareTest Case Design For OO Software

Test case design for OO Software is still evolvingTest case design for OO Software is still evolving The overall approach defined by Berard is as followsThe overall approach defined by Berard is as follows

1) Each test case should be uniquely and explicitly associated 1) Each test case should be uniquely and explicitly associated with class to be testedwith class to be tested

2) The purpose of state should be stated2) The purpose of state should be stated

3) The list of Testing step should be developed for each test 3) The list of Testing step should be developed for each test case and should containcase and should contain

> List of Specified state for object that has to be tested > List of Specified state for object that has to be tested

> List of Message and operation that will be exercised as a > List of Message and operation that will be exercised as a

consequence of the stateconsequence of the state

> List of exception that may occur when object is tested> List of exception that may occur when object is tested

> List of External condition> List of External condition

> Supplementary information that is needed understanding > Supplementary information that is needed understanding and and

implementing the testimplementing the test


Test Case design Implication of OO ConceptsTest Case design Implication of OO Concepts

Encapsulation is Major problem while implementing the test Encapsulation is Major problem while implementing the test case design which is designed by testercase design which is designed by tester

Unless built-in-operation are provided to report the value for Unless built-in-operation are provided to report the value for class attribute , a snapshot of the state of an object may be class attribute , a snapshot of the state of an object may be difficult to acquiredifficult to acquire

Inheritance may also lead additional challenge for test case Inheritance may also lead additional challenge for test case designer designer

Multiple inheritance complicate testing futher by increasing Multiple inheritance complicate testing futher by increasing number of contexts for which testing is required number of contexts for which testing is required

White-box testing can be applied to the operation in class, but White-box testing can be applied to the operation in class, but many class operation cause some argue that effort applied to many class operation cause some argue that effort applied to white-box testing might be redirected to tests at class levelwhite-box testing might be redirected to tests at class level

Black-box testing Method are as appropriate for OO System as Black-box testing Method are as appropriate for OO System as they are for System developed using conventional SE methods they are for System developed using conventional SE methods


Fault based TestingFault based Testing The object of fault based testing within an OO system is to The object of fault based testing within an OO system is to

design test that have high likelihood of uncovering plausible design test that have high likelihood of uncovering plausible fault (aspect of the implementation of the system that may fault (aspect of the implementation of the system that may result in defects)result in defects)

The product or system must conform to customer requirement, The product or system must conform to customer requirement, the preliminary planning required to perform fault based the preliminary planning required to perform fault based testing begins with analysis modeltesting begins with analysis model

To determine whether these fault exists, test case are designed To determine whether these fault exists, test case are designed to exercise design or codeto exercise design or code

Consider simple example. Software engg often make errors at Consider simple example. Software engg often make errors at boundary of problemboundary of problem

When testing SQRT operation that returns error for negative When testing SQRT operation that returns error for negative value, we know try the boundaries a negative number close to value, we know try the boundaries a negative number close to zero or zero itself check whether the programmer made zero or zero itself check whether the programmer made mistake like mistake like

if (x>0) calculate_the_square_root() if (x>0) calculate_the_square_root()


Fault based Testing Continued……Fault based Testing Continued……

Instead of correctInstead of correct if (x>=0) calculate_the_square_root()if (x>=0) calculate_the_square_root() Consider another example of Boolean expressionConsider another example of Boolean expression if (a&&!b||c) if (a&&!b||c) Multicondition testing and related technique probe for certain Multicondition testing and related technique probe for certain

plausible fault in this expression ,such asplausible fault in this expression ,such as && should be ||&& should be || ! Was left out where it was needed ! Was left out where it was needed there should be parenthesis around !b||cthere should be parenthesis around !b||c For each plausible fault we design test case that will force the For each plausible fault we design test case that will force the

incorrect expression to failincorrect expression to fail Integration testing looks for plausible fault in operation call or Integration testing looks for plausible fault in operation call or

message connection. Three type are encountered message connection. Three type are encountered 1)Unexpected result 1)Unexpected result 2)wrong operation/message used2)wrong operation/message used 3)incorrect Invocation3)incorrect Invocation


Test cases and Class HierarchyTest cases and Class Hierarchy

Inheritance does not obviate the need for thorough testing Inheritance does not obviate the need for thorough testing of all derived classes. In fact, it actually complicate the of all derived classes. In fact, it actually complicate the testing processtesting process

Base::refined and Derived:: refined if this type of classes Base::refined and Derived:: refined if this type of classes are defined then a tester has to go through all the aspect of are defined then a tester has to go through all the aspect of base class then the one defined as derived class and as base class then the one defined as derived class and as both are interrelated the test case design becomes both are interrelated the test case design becomes complicatedcomplicated

In such case a long path has to be traversed then tester has In such case a long path has to be traversed then tester has to be precautious to be precautious


Scenario based testing Scenario based testing

Fault based testing misses two main error Fault based testing misses two main error

1) Incorrect specification1) Incorrect specification

2) Interaction among Subsystem2) Interaction among Subsystem In first type of error the product does not do what the In first type of error the product does not do what the

customer want, it might omit important functionalitycustomer want, it might omit important functionality Error associated with subsystem interaction occur when the Error associated with subsystem interaction occur when the

behavior of one subsystem create circumstance that cause behavior of one subsystem create circumstance that cause another subsystem to fail another subsystem to fail

Scenario based testing concentrate on what user does, not Scenario based testing concentrate on what user does, not what product does. This means capturing the task user has what product does. This means capturing the task user has to perform ,then applying them and their variants as test.to perform ,then applying them and their variants as test.

Scenario uncovers the interaction error. But to accomplish Scenario uncovers the interaction error. But to accomplish this, test case must be more complex and more realistic this, test case must be more complex and more realistic than fault based test than fault based test


Scenario Based TestingScenario Based Testing

Consider following example Consider following example Use Case: Print a New CopyUse Case: Print a New Copy

Background :Someone ask the user for a fresh copy of the Background :Someone ask the user for a fresh copy of the document. It must be printed document. It must be printed 1) Open the Document1) Open the Document 2) Select print in the menu2) Select print in the menu 3) Check if your printing a page range, click print entire 3) Check if your printing a page range, click print entire document document 4) Click on Print Button 4) Click on Print Button 3) Close the Document 3) Close the Document

Test case will be designed to check all the above step listed Test case will be designed to check all the above step listed are correctly executedare correctly executed


Testing Surface StructureTesting Surface Structure

Surface structure refers to the externally observable structure of an Surface structure refers to the externally observable structure of an OO program. The structure that is immediately obvious to an end OO program. The structure that is immediately obvious to an end useruser

Rather than performing function, the user of many OO system may Rather than performing function, the user of many OO system may

be given an object to manipulate in some waybe given an object to manipulate in some way

The best test case are derived when designer look at the system in The best test case are derived when designer look at the system in a new or unconventional waya new or unconventional way

Ask a question like “Might the user want to use this operation which Ask a question like “Might the user want to use this operation which applies only to Scanner Object while working with the printer?”applies only to Scanner Object while working with the printer?”

Whatever the interface style, test case design that exercise the Whatever the interface style, test case design that exercise the surface structure should use both objects and operation as clues surface structure should use both objects and operation as clues leading to overlooked tasks leading to overlooked tasks


Testing Deep structureTesting Deep structure

Deep structure refers to internal technical details of OO Deep structure refers to internal technical details of OO Program Program

Deep structure testing is designed to exercise Deep structure testing is designed to exercise dependencies behavior and communication mechanism dependencies behavior and communication mechanism that have been established as part of system and object that have been established as part of system and object design design

Analysis and design model are used as basis for deep Analysis and design model are used as basis for deep structure testing structure testing

For example the object-relationship diagram or the For example the object-relationship diagram or the subsystem collaboration diagram depicts collaboration subsystem collaboration diagram depicts collaboration between objects and subsystem that may not be externally between objects and subsystem that may not be externally visible visible

The test case design then ask “Have we captured some The test case design then ask “Have we captured some task that exercise the collaboration noted on the object-task that exercise the collaboration noted on the object-relationship diagram or the subsystem collaboration relationship diagram or the subsystem collaboration diagram? If not why not?”diagram? If not why not?”


Testing Method applicable at the class levelTesting Method applicable at the class level

1) Random Testing for OO Classes1) Random Testing for OO Classes Consider a banking application in which an account class has Consider a banking application in which an account class has

following operation: open, setup, deposit, withdraw, balance, following operation: open, setup, deposit, withdraw, balance, summarize, creditlimit and closesummarize, creditlimit and close

Each of these operation may be applied for account but certain Each of these operation may be applied for account but certain constraint are implied by the nature of problem (account must be constraint are implied by the nature of problem (account must be open before doing any specific operation)open before doing any specific operation)

Even with these constraint, there many permutation of the operation Even with these constraint, there many permutation of the operation likelike

open-setup-deposit-withdraw-close open-setup-deposit-withdraw-close A variety of different operation sequence can be generatedA variety of different operation sequence can be generated

Test case1: open-- setup – deposit – deposit –balance – summarize -- Test case1: open-- setup – deposit – deposit –balance – summarize -- close close

Test case2:open – setup – deposit – withdraw – balance – closeTest case2:open – setup – deposit – withdraw – balance – close


Partitioning testing at class levelPartitioning testing at class level

Partition testing reduce number of test case required to exercise the Partition testing reduce number of test case required to exercise the class in much same manner as equivalence partitioning. There are class in much same manner as equivalence partitioning. There are two type of this test two type of this test

1) State based Partitioning 1) State based Partitioning

> It categorize class operation based on their ability to change the > It categorize class operation based on their ability to change the

state of class. In previous example state operation include deposit state of class. In previous example state operation include deposit

and withdraw. Test case will be as followsand withdraw. Test case will be as follows

Testcase1:open-setup-deposit- withdraw-withdraw-closeTestcase1:open-setup-deposit- withdraw-withdraw-close

Testcase2:open– setup – deposit – summarize – closeTestcase2:open– setup – deposit – summarize – close

Testcase1 is responsible for changing state while testcase2 does not Testcase1 is responsible for changing state while testcase2 does not change statechange state

2) Attribute based testing2) Attribute based testing It categorize class operation based on attribute they use. For It categorize class operation based on attribute they use. For

account class attribute balance and creditlimit can be used as account class attribute balance and creditlimit can be used as partition partition

Test sequence are then designed for each partition Test sequence are then designed for each partition


Interclass test case designInterclass test case design

Test case design can become more complicated as Test case design can become more complicated as integration of OO System is doneintegration of OO System is done

Like testing of the individual classes, class collaboration Like testing of the individual classes, class collaboration testing can accomplished by applying random and testing can accomplished by applying random and partitioning methods as well as scenario based testing and partitioning methods as well as scenario based testing and behavioral testingbehavioral testing

Multiple class TestingMultiple class Testing Following step are suggested to generate multiple class Following step are suggested to generate multiple class

random test caserandom test case

1)For each client class, use the list of class operation to 1)For each client class, use the list of class operation to generate a series of random test sequence. The operation generate a series of random test sequence. The operation will send message to other server classes will send message to other server classes

2)For each class that is generated determine the collaborator 2)For each class that is generated determine the collaborator class and the corresponding operation in server objectclass and the corresponding operation in server object

3)For each operation in server object determine the message it 3)For each operation in server object determine the message it transmitstransmits


Continued….Continued….

4) For each Message determine next level of operation that are 4) For each Message determine next level of operation that are invoked and incorporate these in to test sequenceinvoked and incorporate these in to test sequence


Test derived from behavior modelTest derived from behavior model

Behavior model can be used as test case design Behavior model can be used as test case design State based technique can be used to derive test casesState based technique can be used to derive test cases The state model can be traversed in ‘breadth-first” The state model can be traversed in ‘breadth-first”

mannermanner In these context breadth first implies that a test case In these context breadth first implies that a test case

exercise a single transition and that when a new exercise a single transition and that when a new transition is to be tested only previously tested transition transition is to be tested only previously tested transition are usedare used

Consider credit card object a breadth first approach to Consider credit card object a breadth first approach to this type of testing would not exercise submitted before this type of testing would not exercise submitted before it exercised defined and undefined it exercised defined and undefined

If it did ,it would make use of transition that had been If it did ,it would make use of transition that had been previously tested and would therefore violate breadth previously tested and would therefore violate breadth first crieteriafirst crieteria


End of SyllabusEnd of Syllabus

This to declare that syllabus for object oriented analysis This to declare that syllabus for object oriented analysis and software testing is over today dated and software testing is over today dated 04/09/2304/09/23 03:35 PM03:35 PM

ooad testing iii

Documents