Broadening The view of testing

 The construction of object oriented software begins with creation of

analysis and design Model
 These model are relatively informal representation of system
requirement and evolve into detailed model of classes , class
connection and relationships, system design and allocation and
object design
 At each stage the model can be tested in an attempt to uncover
errors prior to their propagation to next Iteration
 The review of OO analysis and design model is especially useful
because the same semantics constructs appear at analysis design
and code level
 Consider an Example in which mistake is done initially in analysis
phase ,and if not detected how extra effort will be done as it
propagates to other phases

Thursday, December 9, 2021 Object oriented Testing 1

 Error in analysis Phase

 Consider a class in which number of attribute are defined during

first phase of analysis
 An Extraneous attribute is appended due to wrong interpretation
and two function are added to manipulate that attribute
 If the model is shown to particular Domain expert errors can be
detected, but suppose errors are not detected what will happens.
1) Special subclasses may have generated to accommodate
the unnecessary attribute or exception to do it
2) A misinterpretation of class Definition may lead to
incorrect or extraneous class description
3) The behavior of system or it classes may be improperly
Characterized to accommodate Extraneous attribute

Thursday, December 9, 2021 Object oriented Testing 2

 Error propagated to Design

 Following error will propagate in design phase

1) Improper allocation of Classes to subsystem and/or
tasks may occur during these phase

2) Unnecessary design work may be expended to create

the procedural design for operation that address
extraneous attribute

3) The messaging Model will be incorrect

 If error remained undetected during design and passes to code

activity more effort will be expended to generate code, in addition
testing will absorb more time

Thursday, December 9, 2021 Object oriented Testing 3

 Testing OOA and OOD Model
 Analysis and design model cannot be tested in conventional
sense ,because they cannot be executed
 The different step for testing are as follows

1) Correctness of OOA and OOD Models

1.1) The notation and syntax used to represent analysis and
design model will be tied to specific analysis and design
method that is chosen for product
1.2) Syntactic correctness is judged on proper use of
symbology each model is reviewed for correct symbolic
notation
1.3) Semantic correctness can be judged based on model
conformance to real world domain. If model accurately
reflect the real world then it is semantically correct
Thursday, December 9, 2021 Object oriented Testing 4
 Consistency of OOA and OOD Models
 An inconsistent model has representation in one part that are not
reflected in other portion of Model
 To access consistency CRC (class-responsibility-collaborator) 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

Thursday, December 9, 2021 Object oriented Testing 5

 Evaluating consistency of Class Model using CRC

 To evaluate the class model following step recommended

1) Revisit the CRC model and object relationship model. Cross check to
ensure that all collaboration implied by the OOA model are properly
Represented
2) Inspect the description of each CRC index card to determine if
delegated responsibility is part of collaboration definition
3) Invert the connection to ensure that each collaborator that is asked
for services is receiving request from a reasonable source
4) Using the inverted connection examined in step 3, determine
whether other classes might be required and whether responsibility
are properly grouped among the classes
5) Determine whether widely requested responsibility might be
combined into single responsibilities
6) Step 1 through 5 are applied iteratively to each model

Thursday, December 9, 2021 Object oriented Testing 6

 Evaluating consistency of Class Model contd…

 Once OOD model is created review of system design and object

design has to be conducted

 In system design the overall product architecture, subsystem that

compose product ,the manner in which subsystem are allocated to
processors, the allocation of classes to subsystem and the design of
user interface has to be tested

 The object model should be tested against the object relationship

network to insure that all design objects contain the necessary
attribute and operation to implement the collaboration defined for
each CRC index card

Thursday, December 9, 2021 Object oriented Testing 7

 Object Oriented Testing Strategies

Unit Testing in Object oriented Context

 When object oriented software is considered the concept of Unit testing
changes Drastically
 The reason for same is Encapsulation which drives the definition of
classes and object (i.e variable and function are represented in same
class)
 Instead of testing an Individual model, the smallest testable unit is
encapsulated class or object
 Because a class contain number of different operation and particular
operation may exist as a part of different classes the meaning has
changed
 Class testing in OO software is Equivalent to unit testing in conventional
software which tend to focus on algorithmic details of module and data
flow across the module. Class testing for OO software is driven by
operation encapsulated by the class and state behavior of class.

Thursday, December 9, 2021 Object oriented Testing 8

 Integration Testing in the OO Context

 Object oriented software does not have a hierarchical control structure,

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

Thursday, December 9, 2021 Object oriented Testing 9

 Validation Testing in an OO Context
 At the validation or system level, details of class connection disappear

 The validation of OO software focuses on user-visible action and user-

recognizable output from the system

 To assist in the derivation of validation tests, the tester should draw

upon the use-case that are part of analysis model

 The use-case provide a scenario that has high likelihood of uncovered

errors in user requirement

 Conventional Black Box Testing Method can be used

Thursday, December 9, 2021 Object oriented Testing 10

 Test Case Design For OO Software
 Test case design for OO Software is still evolving
 The overall approach defined by Berard is as follows
1) Each test case should be uniquely and explicitly associated with class
to be tested
2) The purpose of state should be stated
3) The list of Testing step should be developed for each test case and
should contain
> List of Specified state for object that has to be tested
> List of Message and operation that will be exercised as a
consequence of the state
> List of exception that may occur when object is tested
> List of External condition
> Supplementary information that is needed understanding and
implementing the test

Thursday, December 9, 2021 Object oriented Testing 11

 Test Case design Implication of OO Concepts

 Encapsulation is Major problem while implementing the test case

design which is designed by tester
 Unless built-in-operation are provided to report the value for class
attribute , a snapshot of the state of an object may be difficult to
acquire
 Inheritance may also lead additional challenge for test case designer
 Multiple inheritance complicate testing futher by increasing number
of contexts for which testing is required
 White-box testing can be applied to the operation in class, but
many class operation cause some argue that effort applied to white-
box testing might be redirected to tests at class level
 Black-box testing Method are as appropriate for OO System as they
are for System developed using conventional SE methods

Thursday, December 9, 2021 Object oriented Testing 12

 Fault based Testing
 The object of fault based testing within an OO system is to design
test that have high likelihood of uncovering plausible fault (aspect of
the implementation of the system that may result in defects)
 The product or system must conform to customer requirement, the
preliminary planning required to perform fault based testing begins
with analysis model
 To determine whether these fault exists, test case are designed to
exercise design or code

 Consider simple example. Software engg often make errors at

boundary of problem
 When testing SQRT operation that returns error for negative value,
we know try the boundaries a negative number close to zero or zero
itself check whether the programmer made mistake like
if (x>0) calculate_the_square_root()

Thursday, December 9, 2021 Object oriented Testing 13

 Fault based Testing Continued……
 Instead of correct
if (x>=0) calculate_the_square_root()
 Consider another example of Boolean expression
if (a&&!b||c)
 Multicondition testing and related technique probe for certain plausible
fault in this expression ,such as
&& should be ||
! Was left out where it was needed
there should be parenthesis around !b||c
 For each plausible fault we design test case that will force the incorrect
expression to fail
 Integration testing looks for plausible fault in operation call or message
connection. Three type are encountered
1)Unexpected result
2)wrong operation/message used
3)incorrect Invocation
Thursday, December 9, 2021 Object oriented Testing 14
 Test cases and Class Hierarchy

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

 Base::refined and Derived:: refined if this type of classes are

defined then a tester has to go through all the aspect of base class
then the one defined as derived class and as both are interrelated
the test case design becomes complicated

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

precautious

Thursday, December 9, 2021 Object oriented Testing 15

 Scenario based testing

 Fault based testing misses two main error

1) Incorrect specification
2) Interaction among Subsystem
 In first type of error the product does not do what the customer
want, it might omit important functionality
 Error associated with subsystem interaction occur when the
behavior of one subsystem create circumstance that cause another
subsystem to fail
 Scenario based testing concentrate on what user does, not what
product does. This means capturing the task user has to perform
,then applying them and their variants as test.
 Scenario uncovers the interaction error. But to accomplish this, test
case must be more complex and more realistic than fault based test

Thursday, December 9, 2021 Object oriented Testing 16

 Scenario Based Testing
 Consider following example
Use Case: Print a New Copy

Background :Someone ask the user for a fresh copy of the

document. It must be printed

1) Open the Document

2) Select print in the menu
3) Check if your printing a page range, click print entire
document
4) Click on Print Button
3) Close the Document

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

Thursday, December 9, 2021 Object oriented Testing 17

 Testing Surface Structure
 Surface structure refers to the externally observable structure of an OO
program. The structure that is immediately obvious to an end user

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

given an object to manipulate in some way

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

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

 Whatever the interface style, test case design that exercise the surface
structure should use both objects and operation as clues leading to
overlooked tasks
Thursday, December 9, 2021 Object oriented Testing 18
 Testing Deep structure
 Deep structure refers to internal technical details of OO Program
 Deep structure testing is designed to exercise dependencies
behavior and communication mechanism that have been established
as part of system and object design
 Analysis and design model are used as basis for deep structure
testing
 For example the object-relationship diagram or the subsystem
collaboration diagram depicts collaboration between objects and
subsystem that may not be externally visible
 The test case design then ask “Have we captured some task that
exercise the collaboration noted on the object-relationship diagram
or the subsystem collaboration diagram? If not why not?”

Thursday, December 9, 2021 Object oriented Testing 19

 Testing Method applicable at the class level
1) Random Testing for OO Classes
 Consider a banking application in which an account class has following
operation: open, setup, deposit, withdraw, balance, summarize,
creditlimit and close
 Each of these operation may be applied for account but certain constraint
are implied by the nature of problem (account must be open before doing
any specific operation)
 Even with these constraint, there many permutation of the operation like
open-setup-deposit-withdraw-close
 A variety of different operation sequence can be generated

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

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

Thursday, December 9, 2021 Object oriented Testing 20

 Partitioning testing at class level
 Partition testing reduce number of test case required to exercise the
class in much same manner as equivalence partitioning. There are two
type of this test
1) State based Partitioning
> It categorize class operation based on their ability to change the
state of class. In previous example state operation include deposit
and withdraw. Test case will be as follows
Testcase1:open-setup-deposit- withdraw-withdraw-close
Testcase2:open– setup – deposit – summarize – close
Testcase1 is responsible for changing state while testcase2 does not change
state
2) Attribute based testing
 It categorize class operation based on attribute they use. For account
class attribute balance and creditlimit can be used as partition
 Test sequence are then designed for each partition
Thursday, December 9, 2021 Object oriented Testing 21
 Interclass test case design
 Test case design can become more complicated as integration of OO
System is done
 Like testing of the individual classes, class collaboration testing can
accomplished by applying random and partitioning methods as well as
scenario based testing and behavioral testing
Multiple class Testing
 Following step are suggested to generate multiple class random test
case
1)For each client class, use the list of class operation to generate a series
of random test sequence. The operation will send message to other
server classes
2)For each class that is generated determine the collaborator class and
the corresponding operation in server object
3)For each operation in server object determine the message it transmits

Thursday, December 9, 2021 Object oriented Testing 22

 Continued….

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

Thursday, December 9, 2021 Object oriented Testing 23

 Test derived from behavior model

 Behavior model can be used as test case design

 State based technique can be used to derive test cases
 The state model can be traversed in ‘breadth-first” manner
 In these context breadth first implies that a test case
exercise a single transition and that when a new transition
is to be tested only previously tested transition are used
 Consider credit card object a breadth first approach to this
type of testing would not exercise submitted before it
exercised defined and undefined
 If it did ,it would make use of transition that had been
previously tested and would therefore violate breadth first
crieteria

Thursday, December 9, 2021 Object oriented Testing 24

 End of Syllabus

 This to declare that syllabus for object oriented analysis and

software testing is over today dated 12/09/21 05:45 AM

Thursday, December 9, 2021 Object oriented Testing 25