Objectoriented Testing

1
Object-oriented Testing

• Wei-Tek Tsai
• Department of Computer Science and
• Engineering
• Arizona State University
• Tempe, AZ 85287

2
Object-Oriented Concepts

• Object-Oriented programming is centered around
  six basic concepts
• Object
• An operational entity that encapsulates both
  specific data values and the code that manipulate
  those values
• Message
• A request that an operation be performed b some
  object
• Interface
• An aggregation of behavioral declarations
• Class
• A set of objects that share a common conceptual
  basis
• Inheritance
• A relationship between classes that allows the
  definition of a new class based on the definition
  of an existing class
• Polymorphism
• The ability to treat an object as belonging to
  more than one type

3
The Characteristics of OO Programs

• They have lots of message passing
• They determine methods at runtimedynamic binding
• There will be method lookup or method linking
  (C)
• Push down the stack execution stack push down
  the return address, parameters, local variables,
• Reusability is more important than pushing stack
• They are now being in embedded systems
• They are used especially for soft real-time
  systems
• In OO programs, paths in method are relatively
  small (unless you have a terrible design), but
  now you have message passing paths in each
  method.
• If you initialize each variable when it is
  declared, then chance of getting data flow bug is
  SMALL

4
Verification Validation

• Verification Are we building the product right?
• Validation Are we building the right product?
• If successful VV techniques for OO paradigm are
  not developed, there is a great risk of failure
  of OO paradigm as a next-generation software
  development technique

5
Object-oriented testing

• Begins by evaluating the correctness and
  consistency of the OOA and OOD models
• Testing strategy changes
• The concept of the unit broadens due to
  encapsulation
• Integration focuses on classes and their
  execution across a thread or in the context of a
  use case
• Validation uses conventional black box methods
• Test case design draws on conventional methods,
  but also encompasses special features

6
OO testing strategy

• Classes are the smallest testable unit
• Inheritance defines new context for methods
• Behavior of inherited methods can be changed
  because of methods that are called within methods
  have to be tested per class
• Objects have states testing methods have to take
  that into account
• Class testing is the equivalent of unit testing
• Operations within the class are tested
• The state behavior of the class is tested
• OO testing concentrates on the states of the
  objects and their interactions

7
Object at Runtime
8
The Fundamental Units of Program in OO Software
Are Classes and Objects

• An OO application consists of a set of class
  instances interacting with one another by sending
  messages and invoking methods
• An application usually consists of clusters of
  objects such as the objects related to
  user-interface and objects related to databases.
• Within each cluster, objects send messages to
  each other to perform tasks.
• Across all the objects there is little or no
  global data

9
Mtss Mgss

• The sequence in which each object invokes its
  method is important for the proper functioning of
  the object
• The Method Sequence Specification (Mtss) 1 2
  of a class documents the correct causal order in
  which the methods of the class can be invoked
• The Message Sequence Specification (Mgss) 1 2
  of a set of classes documents the causal order in
  which messages can be sent out to different
  instances of classes by a method
• Mtss Mgss represents the causal relationship
  between the instance methods of a set of classes.
  It is not a complete specification of the class

10
Mtss Definition

• Method(C) For a class C we define Method(C) as a
  set of all the instance methods defined in C that
  are publicly available
• Example For a Stock class the method set can be,
  Methods(Stack) push, pop, isempty?, isfull?
  top
• Method Sequence We define a method sequence S as
  a nite sequence over a method set M of C, (m0
  m1mn), where each mi?M. A method sequence need
  not contain all the methods in the method set.
  The entries in a method sequence corresponds to a
  causal order in which the methods get invoked.
• Example In the above Stack class a possible
  method sequence is (push top pop isempty?). In
  this method sequence the method push is invoked
  before the method top is invoked for all
  instances of class Stack.
• SeqSpec(C) A SeqSpec(C) is the specification of
  C that defines a sequence relationship between
  all the methods of C. We use regular definition
  for specifying the SeqSpec(C). We also use REC to
  refer to regular definition.

11
Mtss Example
12
Mtss Example (cont.)

• The interface methods dened in Account class are,
  S create deposit
  open withdraw close delete
  where, create and delete methods are
  constructor and delete methods, open method is
  used for opening an account, deposit method is
  used for depositing positive sums of money into
  the account, withdraw method is used for
  withdrawing money from the account, and close
  method is for closing the account. In the
  following we describe a MtSS for the Account
  class. In the sequence specification, the regular
  definition labels such as AccountMethods are
  present on the left hand side of the arrow.
• The SeqSpec(Account) is,
• SeqSpec ? create AccountMethods delete
• AccountMethods ? open TransactionMethods
  close
• T ransactionMethods ? (deposit
  (depositwithdraw))

13
Mtss Example (cont.)

• In the above sequence specification, create is
  the first method the instance of Account class
  executes before executing any of the other
  methods.
• Once the method open is executed, the instance
  can execute either deposit or withdraw method and
  for any number of times before executing the
  close and delete methods. Thus, the MtSS of
  Account class indicates the causal order in which
  the methods can get executed for the correct
  behavior of instances of the class.

14
Safe Sequence

• SafeSeq(C) A SafeSeq(C) defines a set of all
  sequences Si that can be derived from SeqSpec(C)
  of the class C.
• A sequence in SafeSeq(C) is a valid sequence of
  messages accepted by any instance of the class C.
  SafeSeq(C) is the regular set (or the language)
  defined by SeqSpec(C).

15
Safe Sequence Specifications

• Valid message sequence for a class
• Sequence based on the functionality
• Regular definitions for specification
• Regular definition over the alphabet of methods
  set

16
Safe Sequence Specification (cont.)

• Example A bank Account class
• ?Create,Open,Deposit,Withdraw,Close,Delete
• The specification SeqSpec(account) is,
• Methods ?CreateAccountMethods Delete
• AccountMethods ?Open TransactionMethods Close
• TranscationMethods ?Deposit (Deposit
  WithDraw)
• (CreateOpenDepositWithdrawCloseDelete)

17
Comparison with Algebraic Specification

• Support for abstract data types
• Implicit inter method relationship
• Specification based on type theory and argument
  signature
• Useful and easy to use for well-understood data
  structures
• Difficult to generate all valid sequences

18
Properties of Mtss

• Property 1 For any given three methods m1, m2,
  and m3 of a class, then in the MtSS of the class
  it is true that
• m1 (m2 m3) (m1 m2) m3 m1 m2 m3
• In Property 1, the brackets does not change the
  causal order in which the methods get invoked.
• Property 2 For any given three methods m1, m2,
  and m3 used in a MtSS of a class, the operators '
  ' and ' are distributive.
• i.e. m1 (m2m3) (m1 m2)(m1 m3)

19
Mtss State Transition Diagram
The regular express that can be derived
automatically from the STD is (open deposit
(deposit withdraw) close) This regular
expression is the Mtss for the class Account.
20
Mtss from Object Diagram

• Objects
• Objects are represented using
• object name only
• object class only
• object name and class.
• For example, for an object A of class C, the
  object is represented as A, C, or AC.

21
Mtss from Object Diagram (cont.)

• Object relationships
• In an Object diagram, each message is marked with
  three kinds of information.
• A synchronization symbol denoting the direction
  of the invocation.
• Message invocation or an event dispatch.
• A prex sequence number.
• the MtSS of the class is derived from the Object
  diagram as follows
• If s1 and s2 are the sequence numbers of the
  methods m1 and m2, and s1 s2, then the
  corresponding MtSS containing the methods are,
  (m1m2).
• If s1 and s2 are the sequence numbers of the
  methods m1 and m2, and there exists no method m3
  with sequence number s3 such that s1 lt s3 lt s2,
  then the MtSS containing m1 and m2 are, (m1
  m2).
• If a method m1 has no sequence number, and M is
  the MtSS of the class derived from the rest of
  the methods, then the MtSS of the class
  containing the method m1 is, (m1M).

22
Mtss from Object Diagram (cont.)
23
Mtss from Object Diagram (cont.)

• MtSS ? open deposit (deposit withdraw
  accSumm balance) withdraw close
• The sign after the parenthesis indicates that
  any of the methods can be invoked more than once
  in any order.

24
Mgss Definition

• Mgss is used to describe the causal order among
  the methods supported by different objects.
• The MgSS is specified for each of the method that
  sends out messages.
• The MgSS of a method identifies all the messages
  it sends out to other domain objects. It also
  identifies the causal order in which the messages
  are sent out. For the MgSS specification we use
  the same regular expression formalism used for
  MtSS. In addition to all the operators ' ', 'j',
  '', and '' we introduce a new operator '?' that
  indicates that a message prefixed to operator '?'
  is optional. In the following we describe MgSS of
  a method of a class.

25
Mgss Example
26
Mgss Example (cont.)

• The figure above contains four objects O1, O2,
  O3, and O4. The method m1 of O1 sends messages to
  O2, O3, and O4. The order in which messages m2,
  m3, and m4 are sent out to objects by the message
  m1 forms the MgSS of the method m1.
• If the messages are sent out in the order of m2,
  m3, and m4 then the MgSS of m1 is,
• m1O1 ? (m2O2 m3O3 m4O4)
• If the messages are sent out as either m2 or m3
  as first before m4 then, the MgSS of m1 is,
• m1O1 ? ((m2O2 m3O3) m4O4)

27
Mgss and Scenarios

• If a method sends out messages to objects one
  after the other, then all the messages are
  represented in the order in which they will be
  sent out.
• For example, if m1, m2, and m3 are sent out in a
  sequence then the corresponding MgSS will be m1
  m2 m3.
• If a method sends out a message optionally and
  other messages always, the optional message will
  be represented in MgSS using the operator '?'.
• For example, if m1 is sent out optionally and
  then m2 and m3 are sent out, then the MgSS will
  be m1? m2 m3. When messages are predicated on
  conditions, messages are sent out optionally.

28
Mgss and Scenarios (cont.)

• If a method sends out messages alternatively such
  as, a true condition results in one message and
  false condition results in another message, the
  MgSS will contain both the messages as
  alternative messages.
• For example, if m1 or m2 is sent out, but not
  both, then the MgSS corresponding to the above
  condition is, m1m2.
• If a method sends out messages repeatedly such as
  messages in a loop, then the operator '? or '
  is used. The operator '? is used when messages
  are sent out zero or more times, while the
  operator '' is used when messages are sent out
  one or more times.
• For example, if a message m1 is sent out
  repeatedly one or more times, then followed by a
  message m2 then the corresponding MgSS is, (m1)
  m2.

29
How Can We Use Mtss and Mgss?

• MgSS and MtSS together can identify the causal
  order between any two methods defined in two
  diferent classes.
• Since MgSS for a method that sends out no
  messages to other objects is null, MgSS is useful
  for those objects that behave as client objects
  to other objects

30
Interaction Diagram

• Interaction diagrams are used in many OO analysis
  and design techniques for representing the
  interaction between objects
• Interaction diagrams are used to describe how an
  use case can be realized through communicating
  objects.
• The Interaction diagrams are controlled by the
  events owing between the blocks. The events are
  stimuli, i.e. messages sent from one object to
  the other object.

31
Interaction Diagram Example withdrawing of the
money
32
Deriving Mtss from Withdraw Use Case - Rules

• To determine the MtSS for each of the class, the
  events incident on the block corresponding to the
  class is considered.
• For example, to determine the MtSS of ATM
  Hardware, we consider the block corresponding to
  ATM Hardware. The events incident on ATM Hardware
  are readAmt and dispCash.
• The causal order is determined by the order in
  which the events are generated, whether the
  events are conditional or in a loop and so on.
  Information whether the events are conditional or
  not is provided by the use case description
  attached on the left side of the border line.

33
Deriving Mtss from Withdraw Use Case Example

• MtSSATMHardware ? readAmt dispCash
• MtSSBank ? withdrawReq
• MtSSAccount ? getAccInfo getAccSumm balance
  withdraw

34
Deriving Mtss from Withdraw Use Case

• The MtSS corresponds to the causal order in which
  methods at an object are invoked.
• In the interaction diagram example, only one use
  case is shown and thus the MtSS generated from
  the above is not complete. However, once all the
  use case depictions are available, one can
  generate the MtSS completely.

35
Deriving Mgss from Withdraw Use Case - Rules

• To derive MgSS from Interaction diagram for each
  of the methods (events), the events that are
  going out from a block are considered.
• For example, at the block Bank, various events go
  out such as getAccInfo.
• Once all the out going events are known, then the
  causal order among them is determined.
• For determining whether some of the outgoing
  events are optional or whether they are repeated
  multiple times, the use case descriptions are
  read.

36
Deriving Mgss from Withdraw Use Case Example

• withdrawATM ? readAmtATMHardware
  withdrawReqBank dispCashATMHardware
• withdrawReqBank ? getAccInfoAccount
  getAccSummAccount balanceAccount
  withdrawAccount
• In the MgSS generated for the withdraw(), three
  messages are sent out to different classes and
  the causal order among them is identified.

37
Verification and Validation Techniques

• Need for reliable and robust software
• Need to verify analysis, design, and
  implementation
• Specification consistency and completeness (CC)
• Program CC
• Consistency of program against specification

38
Inheritance and Sequence Specification

• Inheritance is use extensively
• Inconsistency in parent and child class
  specification
• Automatic consistency verification is essential
• Consistency rules based on the type of inheritance

39
Inheritance and Sequence Specification (cont.)

• Various types of inheritance-specification,
  refinement, and reuse
• Specialization Inheritance Example
• Example New methods in Checking_Account class
  are Balance, and MonthlyReport

40
Child Class Specifications

• Specification of the parent class specification
• The consistency rule
• Every sequence in the parent class must be a
  proper subseqence of at least one sequence in the
  child class
• Same rule for both single and multiple
  inheritance

41
Child Class Specification

• ExampleSeqSpec(Checking_Account) is,
• Methods ?CreateAccountMethods Delete
  AccountMethods ?Open TransactionMethods Close
• TranscationMethods ?Deposit (Deposit
  WithDrawBalanceMonthlyReport)
• Implementation using an equivalence algorithm of
  two regular definitions

42
Refinement Inheritance and Sequence Specification

• Example
• New Methods in Savings_Account class
• Balance() and Monthly_Report()
• Modified Methods in Account class
• Deposit() and Withdraw()

43
Refinement Inheritance and Sequence Specification
(cont.)

• Consistency rule
• The rule is the same as in previous case except
  that during consistency checking, the refined
  methods must be deleted from the parent classes
  and treated as new methods in the child class.

44
Reuse Inheritance and Sequence Specification

• Some parent class methods are not inherited
• New methods are added in the child class

45
Reuse Inheritance and Sequence Specification
(cont.)

• Example
• Not Inherited Methods push2(), pop2() of Dqueue
  class
• Methods Available push1(), pop1(), and
  is_empty() in Stack class
• Consistency rule
• The rule is same as described in the previous
  cases except that during consistency checking,
  the methods that are not inherited in the child
  class must be deleted from the parent classes.

46
Multiple Interfaces and Specification

• Well defined clients and need-to-know basis
• Promotes maintenance, porting, and reusability
• Enforces protection, security, and controlled
  access
• Specification for each sub-interface

47
Multiple Interfaces and Specification

• Global specification for server class
• Inconsistencies due to shared methods
• Individual subinterfaces consistency w.r.t.
  global specification

48
External CC of Specification

• Inconsistencies in OO program w.r.t.
  specification
• Inconsistencies in using the class specification
• Use sequences of methods must be a subset of
  specified sequences
• Reverse engineering of use sequences for each
  object

49
External CC of Specification (cont.)
50
High Level Steps for External CC

• Identification of starting methods
• Control-flow analysis of OO program. The unit of
  analysis is all methods and messages
• Identify use sequence of messages for each object
• Verify use sequences with original sequence
  specification
• Identify out-of-sequence messages

51
High Level Steps for External CC

• Issues
• Number of objects and corresponding use sequences
• Presence of pointers, polymorphism, and dynamic
  binding
• Over estimation of out-of-sequence messages
• Adaptation of conventional control-flow analysis

52
Run Time Implementation of Sequence Verification

• Static analysis of OO program is incomplete
• Number of run time sequences are less
• Run time verifier for safety critical systems
• Run time verifier for each object

53
Run Time Implementation of Sequence Verification

• Verification of consistency for each message
  received at an object
• Exceptions in the presence of out-of-sequence
  message
• Enabling and disabling of run time verification
  system

54
Test Case Generation

• The testing activity can be divided into four
  stages. They are,
• Identification of the testing criteria.
• Generation of test cases based on the testing
  criteria.
• Execution of the test cases against the target
  implementation, and
• Evaluation of the test results.
• Test case generation is the second step in
  testing. Test case generation is driven based on
  the testing criteria decided as a first step of
  testing.
• The goal of test case generation is to generate
  less number of test cases that are effective in
  identifying most of the faults in a program.

55
Test Cases Generation

• Test cases are usually generated in three steps.
• Identification of the design or program
  components for test case generation. These
  components can be anything from a single
  statement to the entire system. In OO paradigm,
  some example components are methods, methods in a
  class, and message sequences through class
  instances.
• Specification of test inputs and the state of
  related components that exercise the components
  selected in the previous step.
• Specification of expected output of the selected
  component and the expected state of related
  components.

56
Identification of Components and Interactions

• The fundamental components of an OO design are
  classes.
• Individual methods should be tested.
• To make these classes completely reusable, all
  the methods and its interactions must be tested.

57
Test Case Generation Techniques and Strategies

• Traditional ones that can be applied in OO
  testing
• Coverage Criteria
• Black-box Test Cases
• White-box Test Cases
• Data flow Dynamic Test Cases
• State-based Test case generation
• Inspections and Walkthroughs

58
Test Case Generation Techniques and Strategies
(cont.)

• New ones for inheritance
• To test the classes in a library one possible
  approach is to test every class in the library.
  This implies testing of every method in the class
  hierarchy even though the methods might be
  unchanged in the parent and child classes.
  Further, exhaustive testing of each class does
  not reuse the test cases developed for the parent
  class methods. Thus testing of methods on the
  inheritance hierarchy can be optimized.
• Initially a base class is tested thoroughly by
  testing each method. The test case design and
  test case execution information is saved along
  with the base class. Then, when a subclass is
  defined, the testing history of the parent class
  and the modifications done to the child class are
  used to determine the methods in the child
  classes that need new test cases. Test cases from
  parent classes might be used in child classes.

59
Test Case Generation
60
Test Case Generation From Single Class For
Random Testing

• MtSS ? open setupAccnt deposit (deposit
  withdraw balance acctSummary creditLimit)
  withdraw close
• Test cases
• TestCase1 ?
• open setupAccnt deposit deposit balance
  withdraw close
• TestCase2 ? open setupAccnt deposit
  creditLimit balance withdraw close
• TestCase3 ? open setupAccnt deposit
  withdraw creditLimit withdraw close
• TestCase4 ? open setupAccnt deposit
  acctSummary deposit withdraw close
• TestCase5 ? open setupAccnt deposit
  withdraw balance withdraw close
• Minimal Testcase ? open setupAccnt deposit
  withdraw close
• AllMethods ? open setupAccnt deposit
  creditLimit deposit balance accntSummary
  withdraw close

61
Test Case Generation From Single Class For
Partition Testing

• Rewrite Mtss
• SeqSpec ? open setupAccnt deposit
• Transactions withdraw close
• Transactions ?(deposit withdraw balance
  acctSummary creditLimit)

62
Test Case Generation From Single Class For
Partition Testing

• State based partitioning
• Transaction ?(StateMethods NonStateMethods)
• StateMethods ? (deposit withdraw)
• NonStateMethods ? (balance acctSummary
  creditLimit)
• PartitionTestCase1 ? open setupAccnt deposit
  deposit deposit withdraw close
• PartitionTestCase2 ? open setupAccnt deposit
  creditLimit
• acctSummary withdraw close

63
Test Case Generation From Single Class For
Partition Testing

• Attribute based partitioning
• Transaction ? (Use Modify NoAccess)
• Use ? (deposit withdraw creditLimit)
• Modify ? (deposit withdraw)
• NoAccess ? (balance acctSummary)
• PartitionTestCase3 ? open setupAccnt deposit
  withdraw creditLimit withdraw close

64
Test Case Generation From Single Class For
Partition Testing

• Category based partitioning
• SeqSpec ? Init deposit (Queries
  Operations) withdraw Release
• Init ? open setupAccnt
• Operations ? (deposit withdraw accntSummary)
• Queries ? (balance creditLimit accntT ype)
• Release ? close
• CategoryTestCase ? open setupAccnt deposit
  creditLimit accntType withdraw close

65
Test Case Generation From Single Class For
Partition Testing

• Special Cases
• AllPartMethods ? open setupAccnt deposit
  deposit
• withdraw acctSummary withdraw close
• CrossPartMethods ? open setupAccnt deposit
• creditLimitUse withdrawModify
• balanceNoAccess withdraw close

66
Test Case Generation From Single Class For Data
Flow Testing

• Data flow testing helps to identify the path
  incompleteness, redundancies, and ambiguities in
  an implementation.
• Data flow testing strategies are structural
  strategies that can be used to construct test
  paths.
• Data flow testing strategies use operations on
  data objects as a criteria for selecting subpaths
  for testing. Different strategies can be derived
  based on define, use, kill operations on data
  objects.

67
Test Case Generation From Single Class For Data
Flow Testing

• Comparing with procedural techniques, data flow
  testing in OO programs can be carried out within
  a method as well as across methods.
• Steps
• Identify a define and use an instance variable
• Generate a test method sequence such that it
  contains the method that defines and uses the
  same instance variable.
• The define and use information of variables and
  the Mtss of the class are used in data flow based
  test case generation

68
Test Case Generation From Single Class For Data
Flow Testing

• Regarding following code
• class Account
• public
• ...
• int setupAccnt(int crdlimit, char address,
  ...)
• float creditLimit ( )
• ...
• protected
• float balance
• float cred_limit
• ...

• int AccountsetupAccnt(int crdlimit, char
  Address ...)
• ...
• cred_limit crdlimit
• ...
• float AccountcreditLimit ( )
• ...
• if(balance gt 2000)
• return balance
• else
• return cred_limit
• ...

69
Test Case Generation From Single Class For Data
Flow Testing

• TestCase1 ? opensetupAccnt deposit
• accntSummary creditLimit
• withdraw close
• TestCase2 ? opensetupAccnt deposit withdraw
  creditLimit withdraw close
• There are some special cases of data flow test
  cases
• All-du-sequence
• All-use-sequence
• All-definitions-sequence
• All-predicate-use-sequences
• All-computational-use-sequences

70
Inter Class Test Case Generation

• The test cases generated from multiple classes
  can be considered as integration test cases as
  they test the integration of methods between the
  classes.

71
Inter Class Test Case Generation

• In OO paradigm, objects are the run-time entities
  and methods are the basic units that perform the
  computation. Methods usually use the services of
  other objects by sending messages to them. So,
  testing in OO is to generate test cases that
  checks the correctness of this method-message
  interactions.
• The MgSS describes the causal order among the
  methods supported by different classes. The MgSS
  is specified for each of the method that sends
  out messages to class instances. So we use the
  MgSS of all the methods to test the method
  interactions.
• We can use random techniques to generate test
  sequences from the MgSS. Similarly, we can
  partition the messages that are sent out from the
  method and then generate test sequences.

72
Inter Class Test Case Generation - Example
73
Inter Class Test Case Generation - Example
74
Inter Class Test Case Generation

• Method interactions between neighboring classes
• Let a method m1 of class C1 send out messages m2,
  m3, m4, m5, and m6 to different instances of
  classes. Let the MgSS of the method m1 be,
  
  m1C1 ? m2O2 (m3O3 m4O4 m5O5)
  m6O6
• For example The MgSS of the method withdraw() is
  given below
• withdrawATM ? getCashAmntATM_UI
  verifyPolicyBank withdrawReqBank
  dispenseCashATM_UI
• In the above MgSS, the method withdraw() sends
  out messages to the classes Bank and ATM_UI.
  Since, the MgSS corresponds to one sequence that
  is possible, this forms a test sequence. The
  above test case involves the support of other
  classes during test case evaluation. In this
  technique, it is necessary to generate test cases
  for all the methods that interact with
  neighboring classes.

75
Inter Class Test Case Generation

• Method interactions across all related classes
• We can extend the test case generation techniques
  from between neighboring classes to include all
  the classes
• Test cases generated might include several
  classes through a chain of message-method pairs.
• The key here is to identify the methods and the
  temporal order in which these methods might get
  executed.

76
Inter Class Test Case Generation

• The MgSS of the methods verifyPolicy() and
  withdrawReq() of the class Bank is given below.
• verifyPolicyBank ? balanceAccount
  creditLimitAccount
• withdrawReqBank ? withdrawAccount
• A new message sequence that span the instances of
  Account call can be derived by substituting the
  above message sequences.
• withdrawATM ? getCashAmntATM_UI
  verifyPolicyBank balanceAccount
  creditLimitAccount withdrawReqBank
  withdrawAccount dispenseCashATM_UI
• The above test sequence can be used as
  integration test as they span multiple classes.
  In fact, a test sequence can be expanded all
  together until each of the messages ends up at an
  object that does not send out any more messages.

77
Multiple Class Data Flow Test Cases

• When we discuss about technique that generate
  test cases using data flow information across
  objects, the data we use is not instance
  variables, but the domain data. Domain data is a
  data that represents some information in the
  domain. This data is transferred from one object
  to other object as an argument to messages, or as
  a part of an object which is passed as an
  argument to other object.
• For example, the domain data in ATM is deposit
  money, withdraw amount, balance left in the
  account, and account information.

78
Multiple Class Data Flow Test Cases - steps

• Identification of the domain data that is read,
  defined, used, and computed across class
  instances.
• Identification of the criteria of data access
  such as define-use, read-use, or create-use of
  the domain data.
• Identification of a sequence of methods belonging
  to different classes that links up the method
  that defines the domain data and a method that
  uses the domain data

79
Multiple Class Data Flow Test Cases - examples

• DataDefine ? depositATM getCashAmntATM_UI
  depositReqBank depositAccount
• DataUse ? acctStatusATM acctInfoReqBank
  balanceAccount

80
Multiple Class Random Test Cases

• Random test sequence generation can be used to
  design test cases for integration testing or
  system level testing.
• The multiple class random test cases are
  generated with respect to a class. A class that
  has methods sending out messages to objects is
  identified. A test case is generated randomly to
  test the class under consideration. This test
  case is expanded to include chains of
  message-method pairs so that the test case spans
  several class instances.

81
Multiple Class Random Test Cases - steps

• For each client class that has methods sending
  out messages to other classes, generate a random
  test sequence from its MtSS or use a sequence
  that has been already generated for that class.
• For each of the message in the test sequence,
  determine the corresponding method in the target
  object.
• Determine the MgSS of the method and generate a
  test sequence from the MgSS using the techniques
  that generate test cases from method interaction.
• Substitute the newly generated sequence in the
  original generated test sequence to form a
  complete random test sequence.

82
Multiple Class Random Test Cases - examples

• For integration test case, we need to use the
  intermediate classes that receives messages and
  sends out message to other classes.
• For example, SeqSpecBank ? verifyAcct verifyPin
  ((verifyPolicy withdrawReq) depositReq
  acctInfoReq)
• the Bank class sends out messages to Account
  class.
• A random test sequence generated from the
  sequence specication given above,
• TestCase ? verifyAcct verifyPin depositReq

83
Multiple Class Partition Test Cases

• A new partition criteria and generate test
  sequences from each of the partition. The methods
  can be easily partitioned based on multiple
  interfaces.
• For example, the class Bank, has two types of
  messages incident on it, one from ATM class and
  other from Cashier class. So, the methods
  supported at Bank class can be partitioned into
  two categories. Further, each of the category can
  be partitioned based on those that modify the
  state versus those that does not modify the
  state.
• The test sequence then can be expanded to include
  many chains of method-message pairs until
  messages end at objects that do not send out
  messages.

84
Multiple Class Partition Test Cases - examples

• In the following, we use the state based
  partition criteria to generate a partition test
  sequence.
• partition the transaction methods into state
  affecting and non state affecting. The state
  affecting methods are depositReq() and
  withdrawReq() while the non state affecting
  method is acctInfoReq().
• TestCase ? verifyAcct verifyPin acctInfoReq
• From the above test case, we can generate a
  complete partition test case by expanding each of
  the method all the way into its constituent
  messages.
• PartTestCase ? verifyAcctBankvalidAccAccInfo
  verifyPinBank validPinAccInfo acctInfoReq
  balanceAccount
  creditLimitAccount

85
Scenario Based Test Sequence Generation

• An OO software system usually consists of several
  subsystems. Several classes are used for
  implementing each of the subsystem. The
  subsystems interact with one another and their
  interaction is well defined.
• One can write several scenarios in which these
  subsystems can be used.
• ATM example user interface for the account
  holders is one subsystem that interacts with Bank
  and Account classes.
• For bank operators there can be another subsystem
  that interacts with Bank and Account classes for
  entering and administration of the account
  information.
• Each of the above subsystems must be used in a
  well defined manner and scenario based testing
  helps in ensuring that at the highest level these
  subsystems function properly.
• Scenario based test sequences are also useful to
  test the end-user classes. These test sequences
  can also be used as a system level test cases.
  The scenarios between the system and the user is
  captured for testing the major interactions and
  information exchanges. Scenarios must be
  constructed for normal situations first and then
  for exception situations. In the following we
  describe scenario test cases for normal situation
  only.

86
Scenario Based Test Sequence Generation - examples

• The MtSS for the ATM-UI class is,
• SeqSpec ? insertCard enterPin selectAccount
  ((deposit enterAmt) (withdraw enterAmt)
  acctInfo) terminate
• For account information scenario
• TestCase1 ? insertCard enterPin selectAccount
  acctInfo terminate
• For withdraw scenario
• TestCase2 ? insertCard enterPin selectAccount
  withdraw enterAmt terminate

87
Test Case Generation from State Transition Diagram
88
Test Case Generation from State Transition Diagram

• All state coverage method sequence
• An all state coverage method sequence can be
  derived from the STD by following from start
  state to end state of the STD. A set of method
  sequences that forces the object of Account to go
  through all the states are given below
• TestCase1 ? open setupAccnt deposit
  withdraw close
• TestCase2 ? open setupAccnt deposit deposit
  credit withdraw close
• TestCase3 ? open setupAccnt deposit
  withdraw accntInfo withdraw close

89
Test Case Generation from State Transition Diagram

• All Method Coverage Sequences
• Follow from start state to end state and include
  all the methods in the sequence they are invoked.
  At a state if there are more than one method that
  can be invoked, then the sequence of the methods
  can be selected randomly. For example, in state
  working account there are five methods and each
  of the methods can be invoked in any order. A
  test sequence that satisfies the all method
  coverage criteria is given below
• TestCase1 ? open setupAccnt deposit balance
  withdraw credit accntInfo withdraw
  close

90
Test Case Generation for Robustness

• Negative Test Sequences from MtSS
• Method dropping
• In this technique, a method that is a must in any
  sequence is not selected to generate an illegal
  method sequence. For a given MtSS, if there are n
  methods that appear in every sequence, then one
  can generate n negative test sequences by
  dropping each method at a time. Depending on the
  methods dropped, the class can take different
  corrective actions.
• Example
• MtSS ? open setupAccnt deposit (deposit
  withdraw balance acctSummary creditLimit)
  withdraw close
• TestSeq ? open deposit deposit withdraw
  acctSummary creditLimit withdraw
  close

91
Test Case Generation for Robustness

• Method reversing
• In this technique, a method that must be invoked
  immediately after another method is reversed with
  each other to form a negative test sequence. If
  there are n such pairs of methods, then one can
  generate n negative test sequences by this
  technique. Depending on the methods that are
  reversed, it is useful if the class can identify
  the actual order and report the same.
• Example
• TestSeq ? open deposit setupAccnt deposit
  withdraw acctSummary creditLimit
  withdraw close

92
Test Case Generation for Robustness

• Repeating methods
• In this technique, a method that must be invoked
  only once is used multiple times in the sequence
  to form a negative test case. Thus, if there are
  n methods that must be invoked only once, then
  one can generate at least n negative test
  sequences.
• Example
• TestSeq ? open setupAccnt setupAccnt
  deposit withdraw acctSummary
  creditLimit withdraw close

93
Negative Test Sequences from MgSS

• The MgSS of a class denes a causal order in which
  a method of a class sends out messages. The
• MgSS of a method identies all possible valid
  sequences in which the messages are sent out. A
• message sequence that is not compliant with the
  MgSS of a method is thus a negative test case. As
• discussed before, we use regular expression
  formalism to represent the MgSS. The operators
  used are
• '' to represent an immediate sequence, 'j' to
  represent exclusive-or among sequence, '?'
  corresponds
• to a zero or more number of times repetition, and
  '' corresponds to one or more number of times
• 82
• repetition. Even though, several techniques exist
  for generating various negative test sequences,
  in
• the following, we discuss three techniques for
  generating negative test cases from MgSS.

94
Negative Test Sequences from MgSS

• Message dropping
• In this technique, a message that is a must in
  any message sequence is dropped. For a given
  MgSS, if there are n messages that must appear in
  every message sequence, then one can generate n
  negative test sequences by dropping each message
  one at a time. Depending on the messages dropped,
  the class instances receiving the messages must
  take different corrective actions
• Example
• withdrawATM ? getCashAmntATM_UI
  verifyPolicyBank withdrawReqBank
  dispenseCashATM_UI
• withdrawATM ? verifyPolicyBank withdrawReqBank
  dispenseCashATM_UI

95
Negative Test Sequences from MgSS

• Message reversing
• In this technique, a message that must be sent
  immediately after another message is reversed
  with each other to form a negative test sequence.
  If there are n such pairs of messages, then one
  can generate n negative test sequences by this
  technique. Depending on the messages that are
  reversed, it is useful if the class instances
  receiving the messages can identify the reversed
  order of the messages.
• Example
• withdrawATM ? verifyPolicyBank
  getCashAmntATM_UI withdrawReqBank
  dispenseCashATM_UI

96
Negative Test Sequences from MgSS

• Repeating messages
• In this technique, a message that must be sent
  out only once is used several times in the
  sequence to form a negative test case. Thus, if
  there are n methods that must be sent out only
  once, then one can generate at least n negative
  test sequences.
• Example
• withdrawATM ? getCashAmntATM_UI
  verifyPolicyBank verifyPolicyBank
  withdrawReqBank dispenseCashATM_UI

97
References

• S. H. Kirani and W.T. Tsai Method Sequence
  Specification and Verification of Classes. JOOP
  7 (6) 28-38 (1994).
• R. V. Vishnuvajjala, W.T. Tsai, R. Mojdehbakhsh
  and L. Elliott Specifying timing constraints in
  real-time object-oriented systems. HASE 1996
  32-39.
• W.T. Tsai, Y. Tu, W. Shao and E. Ebner Testing
  Extensible Design Patterns in Object-Oriented
  Frameworks through Scenario Templates. COMPSAC
  1999 166-171
• S. H. Kirani and Wei-Teck Tsai Specification
  and Verification of Object-Oriented Programs.
  Ph.D. Thesis.