Object-oriented Testing

1
Object-oriented Testing

• SIM3302

2
Objectives

• To cover the strategies and tools associated with
  object oriented testing
• Analysis and Design Testing
• Class Tests
• Integration Tests
• Validation Tests
• System Tests

3
Object-oriented Testing

• When should testing begin?
• Analysis and Design
• Testing begins by evaluating the OOA and OOD
  models
• How do we test OOA models (requirements and use
  cases)?
• How do we test OOD models (class and sequence
  diagrams)?
• Structured walk-throughs, prototypes
• Formal reviews of correctness, completeness and
  consistency
• Programming
• How does OO make testing different from
  procedural programming?
• Concept of a unit broadens due to class
  encapsulation
• Integration focuses on classes and their context
  of a use case scenarioor their execution across
  a thread
• Validation may still use conventional black box
  methods

4
Testing Analysisand Design

• Syntactic correctness
• Are UML and ADT notation used correctly?
• Semantic correctness
• Does the model reflect the real world problem?
• Is UML used as intended by its designers?
• Is the ADT design complete (capturing all the
  classes and operations in UML diagram) and
  understandable?
• Testing for consistency
• An inconsistent model has representations in one
  part that are not reflected in other portions of
  the model

5
Testing the Class Model

• Revisit the Use Cases, CRC cards and UML class
  model. Check that all collaborations are
  properly represented. Inspect the description of
  each CRC index card to make sure a delegated
  responsibility is part of the collaborators
  definition.
• Example in a point of sale system.
• A read credit card responsibility of a credit
  sale class is accomplished if satisfied by a
  credit card collaborator
• Invert connections to ensure that each
  collaborator asked for a service is receiving
  requests from a reasonable source
• Example a credit card being asked for a purchase
  amount
• Have you tested your analysis and design?
• If not, who will do it?

6
Testing OO Code
Integration tests

• Class tests

Validation tests
System tests
7
Object-oriented Testing Strategies(1)

• Unit Testing
• Smallest testable unit is the encapsulated class
  or object
• Test each operation as part of a class hierarchy
  because its class hierarchy defines its context
  of use
• Driven by class operations and state behavior,
  not algorithmic detail and data flow across
  module interface
• Approach
• Test each method (and constructor) within a class
• Test the state behavior (attributes) of the class
  between methods
• Complete test coverage of a class involves
• Testing all operations
• Setting and interrogating all object attributes
• Exercising the object in all possible state
• Test sequences are designed to ensure that
  relevant operations are exercised
• State of the class is examined to determine if
  errors exist

8
Object-oriented Testing Strategies(2)

• Unit Testing
• How is class testing different from conventional
  testing?
• Conventional testing focuses on
  input-process-output, whereas class testing
  focuses on each method, then designing sequences
  of methods to exercise states of a class
• But white-box testing can still be applied

9
Object-oriented Testing Strategies(3)

• Integration Testing
• OO does not have a hierarchical control structure
  so conventional top-down and bottom-up
  integration tests have little meaning
• Focuses on groups of classes that collaborate in
  some manner
• Integration of operations one at a time into a
  class is often meaningless
• Because of direct and indirect interaction of
  components
• Thread-based testing
• Testing/integrate the set of classes required to
  respond to one input or event
• Use-based testing (integrates classes required by
  one use cas
• Begins by testing independent classes that use
  very few of server classes
• Next layer of classes (dependent classes) that
  use the independent classes are tested next
• Cluster testing
• Groups of collaborating classes are tested for
  interaction errors
• Regression testing is important as each thread,
  cluster or subsystem is added to the system

10
Object-oriented Testing Strategies(4)

• Validation Testing
• Are we building the right product?
• Validation succeeds when software functions in a
  manner that can be reasonably expected by the
  customer.
• Focuses on visible user actions and user
  recognizable outputs
• Validation tests are based on the use-case
  scenarios, the object behavior model, and the
  event flow diagram
• Apply
• Use-case scenarios from the software requirements
  spec
• Black-box testing to create a deficiency list
• Acceptance tests through alpha (at developers
  site) and beta (at customers site) testing with
  actual customers

11
Object-oriented Testing Strategies(5)

• Software may be part of a larger system. This
  often leads to finger pointing by other system
  dev teams
• Finger pointing defence
• Design error-handling paths that test external
  information
• Conduct a series of tests that simulate bad data
• Record the results of tests to use as evidence
• Types of System Testing
• Recovery testing how well and quickly does the
  system recover from faults
• Security testing verify that protection
  mechanisms built into the system will protect
  from unauthorized access (hackers, disgruntled
  employees, fraudsters)
• Stress testing place abnormal load on the system
• Performance testing investigate the run-time
  performance within the context of an integrated
  system

12
Test Case Design(1)

• Each test case should be uniquely identified and
  be explicitly associated with a class to be
  tested
• the purpose of the test should be stated
• A list of testing steps should be developed for
  each test and contains
• A list of specified states for the object that is
  to be tested
• A list of messages and operations that will be
  exercised as a consequence of the test
• A list of exceptions that may occur as the object
  is tested
• A list of external conditions needed to be
  changed for the test
• Supplementary information required to understand
  or implement the test
• OO testing focuses on designing appropriate
  sequences of operations

13
Testing Methods at the Class Level(1)

• Random Testing requires large number of data
  permutation and combination
• Identify operations applicable to a class
• Define constraints on their use e.g. the class
  must always be initialized first
• Identify a minimum test sequence an operation
  sequence that defines the minimum life history of
  the class
• Generate a variety of random test sequences this
  exercises more complex class instance life
  histories

14
Testing Methods at the Class Level(2)

• Example of Random Testing
• 1) consider an account class that has the
  following operations
• open, setup, deposit, withdrawal, balance,
  summarize, credit Limit, close
• 2) The account must be opened first and closed
  on completion

15
Testing Methods at the Class Level(3)

• Example of Random Testing
• 3) a variety of behaviors may occur
• opensetupdepositdeposit withdrawal
  balance summarize credit limitnwithdrawalclo
  se
• 4) different operation sequences can be
  generated randomly
• test case 1 opensetupdepositdeposit
  balance summarize
• withdrawalclose
• test case 2 opensetupdepositwithdrawal
  deposit balance
• credit
  limitwithdrawalclose

16
Testing Methods at the Class Level(4)

• Partition Testing reduces the number of test
  cases required to test a class (remember ECP)
• Input and output are categorized
• Deriving partitioning categories
• State-based partitioning
• Categorizes class operations based on their
  ability to change the state of the class
• Tests designed in way so that operations that
  cause state changes are tested separately from
  those that do not
• Example
• Test case sp1 opensetupdepositdeposit
  withdrawal withdrawalclose
• Test case sp2 opensetupdepositsummarize
  credit limit
• withdrawalclose

17
Testing Methods at the Class Level(5)

• Deriving partitioning categories
• Attribute-based partitioning
• Categorizes class operations based on the
  attributes that they use and modify
• Tests designed in way so that operations that use
  or modify attributes are tested separately from
  those that do not use or modify attributes
• Example
• for the account class, the attributes balance
  and credit limit can be used to define
  operations. Operations are divided into three
  partitions
• 1) operations that use credit limit
• 2) operations that modify credit limit
• 3) operations that do not use of modify credit
  limit

18
Testing Methods at the Class Level(6)

• Deriving partitioning categories
• Category-based partitioning
• Categorizes class operations based on the generic
  function that each performs such as
  initialization, computation, query, termination
• Example
• operations in the account class can be
  categorized as
• 1) initialization (open, setup)
• 2) computation (deposit, withdraw)
• 3) queries (balance, summarize, credit limit)
• 4) termination (close)

19
Interclass Test Case Design(1)

• Test case design becomes more complicated as
  integration of the OO system begins testing of
  collaboration between classes
• Refer to diagram

20
Interclass Test Case Design(2)

• Multiple class testing
• For each client class, use the list of class
  operators to generate a series of random test
  sequences that send messages to other server
  classes
• For each message generated, determine the
  collaborator class and the corresponding operator
  in the server object
• For each operator in the server object (invoked
  by a client object message), determine the
  message that it transmits
• For each of the message, determine the next level
  of operators that are invoked and incorporate
  these into the test sequence.

21
Interclass Test Case Design(3)

• Multiple class testing example
• Consider a sequence of operations for the bank
  class relative to an ATM class
• verifyAcctverifyPinverifyPolicywithdrawReq
  depositReq AcctInfoReqn
• A random test case for the bank class might be
• Test case r3 verifyAcctverifyPin depositReq
• The collaborators invoked for the above test case
  are ValidationInfo to execute verifyAcct and
  verifyPin. Collaborate with Account to execute
  depositReq
• Thus a new test case is
• Test case r4 verifyAcctBankvalidAcctValidation
  InfoverifyPinBankValidPinValidationInfodeposi
  tReqdepositAccount

22
Interclass Test Case Design(4)

• Test derived from behavior models
• Use the state transition diagram as a model
• Test cases must cover all states
• Breadth first traversal of the state model can be
  used (test one transition at a time and only make
  use of previously tested transitions when testing
  a new transition

23
Testing MethodsApplicable at Interclass Level(1)

• Cluster Testing
• Concerned with integrating and testing clusters
  of cooperating objects
• Identify clusters using knowledge of the
  operation of objects and the system features that
  are implemented by these clusters
• Approaches to cluster testing
• Use-case or scenario testing
• Testing is based on a user interactions with the
  system
• Has the advantage that it tests systems features
  as experienced by users
• Thread testing tests the systems response to
  events as processing threads through the system
• Object interaction testing test sequences of
  object interactions that stop when an object
  operation does not call on services from another
  object

24
Testing MethodsApplicable at Interclass Level(2)

• Use Case/Scenario-based Testing
• Based on
• Use cases
• Corresponding sequence diagrams
• Identify scenarios from use-case and supplement
  these with interaction diagrams that show the
  objects involved in the scenario
• Concentrates on functional requirements
• Every use case
• Every fully expanded (ltltextendgtgt) combination
• Every fully expanded (ltltusesgtgt) combination
• Tests normal as well as exceptional behavior

25
OO Test Design Issues

• White-box testing methods can be applied to
  testing the code used to implement operations
• Black-box testing methods are appropriate for
  testing OO systems
• OO programming brings additional testing concerns
• Classes may contain operations that are inherited
  from superclass
• Subclasses may contain operations that were
  redefined rather than inherited
• All classes derived from a previously tested base
  class need to be thoroughly tested.

26
Summary

• One strategy is a bottom-up approach class,
  integration, validation and system level testing