Object-oriented Testing SIM3302. Objectives To cover the strategies and tools associated with object...
-
date post
19-Dec-2015 -
Category
Documents
-
view
227 -
download
1
Transcript of Object-oriented Testing SIM3302. Objectives To cover the strategies and tools associated with object...
Object-oriented Testing
SIM3302
Objectives
To cover the strategies and tools associated with object oriented testingAnalysis and Design TestingClass Tests Integration TestsValidation TestsSystem Tests
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 scenario
or their execution across a thread Validation may still use conventional black box methods
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
Testing the Class Model
1. 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 collaborator’s 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
2. 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?
Testing OO Code
Class testsClass tests
SystemSystemteststests
IntegrationIntegrationteststests
ValidationValidationteststests
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
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
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
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 developer’s site) and beta (at
customer’s site) testing with actual customers
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:1. Design error-handling paths that test external information2. Conduct a series of tests that simulate bad data3. 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
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
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
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
Testing Methods at the Class Level(3)
Example of Random Testing
3) a variety of behaviors may occur:
open•setup•deposit•[deposit | withdrawal | balance| summarize | credit limit]n•withdrawal•close
4) different operation sequences can be generated randomly:
test case #1: open•setup•deposit•deposit• balance• summarize• withdrawal•close
test case #2: open•setup•deposit•withdrawal• deposit• balance• credit limit•withdrawal•close
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: open•setup•deposit•deposit• withdrawal•
withdrawal•close Test case #sp2: open•setup•deposit•summarize •credit limit• withdrawal•close
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
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)
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
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.
Interclass Test Case Design(3)
Multiple class testing : exampleConsider a sequence of operations for the bank class relative to an ATM class:verifyAcct•verifyPin•[[verifyPolicy•withdrawReq] | depositReq | AcctInfoReq]n
A random test case for the bank class might beTest case #r3: verifyAcct•verifyPin• 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 isTest case #r4 :
verifyAcctBank[validAcctValidationInfo]•verifyPinBank•[ValidPinValidationInfo•depositReq•[depositAccount]
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
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
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 (<<extend>>) combination Every fully expanded (<<uses>>) combination Tests normal as well as exceptional behavior
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.
Summary
One strategy is a bottom-up approach – class, integration, validation and system level testing