Software Testing and Quality Assurance Software Testing and Quality Assurance Lecture

Document Sample
Software Testing and Quality Assurance Software Testing and Quality Assurance Lecture Powered By Docstoc
					Software Testing and Quality
Assurance

     Lecture 11 - The Testing
  Perspective (Chapter 2, A Practical Guide to
         Testing Object-Oriented Software)




                                                 1
Lecture Outline
   Testing perspective -Object-Oriented
    Concepts
       Interface
       Class




                                           2
Interface - Testing Perspective
   An interface is an aggregation of
    behavioral declarations.
   An interface is a building block for
    specifications.
       In java: interface
       In C++: by declaring abstract class with
        only public, pure virtual methods.


                                                   3
Interface - Testing Perspective
   Interface encapsulates operation
    specifications.
       Theses specifications incrementally build the
        specifications of large groupings such as classes.
   Interface has relationships with other
    interfaces and classes.
   Testers perspective:
       Relationship between interfaces.


                                                        4
Interface - Testing
Perspective- Example
   For example, an interface might
    describe a set of behaviors related to
    being a moving object.
   public interface Movable {
       public Point getsPosition ():
       public Velocity getVelocity();
       public void mover();
    }
                                             5
Class - Testing Perspective
   A class is a set of objects that share a
    common conceptual bases (a template
    for creating objects).
       Objects form the basic element for
        executing OO programs
       While classes form the basic elements for
        defining OO programs.


                                                6
Class - Testing Perspective
   Instantiation: the process of creating an
    object.
   Instance (object): the result of instantiation.
   The conceptual basis common to all the
    objects in a class is expressed in terms:
       A class specification: what each object can do
        (C++ header file).
       A class implementation: how each object do what
        they can do.

                                                      7
Class Specifications
   Describes what the class represents and
    what an instance of the class can do.
   An operation is an action that can be applied
    to an object to obtain a certain effect:
       Accessor (or inspector) operation: provide
        information about an object.
            For example, value of some attribute (in C++, const)
       Modifier operations: change the state of an object
        by setting one or more attributes to have new
        values.


                                                                    8
Class Specifications
   Other types of operations:
       A constructor is a class object operation
        used to create a new object including the
        initialization of the new instance when it
        comes into existence.
       A destructor is an instance object
        operation used to perform any processing
        needed just prior to the end of an object’s
        lifetime.

                                                  9
Class Specifications
   Semantics can be specified at several
    different points:
       Preconditions: conditions that must hold before
        the operation is performed.
       Postconditions: conditions that must hold after
        the operation is performed.
       Invariants: conditions that must always hold
        within the life time of the object.
            Implied post-condition for each operation.
   Testers care about
       Preconditions, post-conditions, invariants
       Relation to other classes (interactions)
                                                          10
Class Specifications
   To write specification for an operation, two
    basic approaches can be used to define the
    interface between the receiver and the
    sender:
       Design by contract approach.
       Defensive programming approach.
   Each approach has a set of rules about how
    to define the constraints and the
    responsibilities for the sender and receiver
    when an operation to be performed.

                                               11
Class Specifications -
Contract
   Design by contract:
       A contract between the sender and receiver of a
        message.
       The sender is responsible for ensuring the
        preconditions are met.
       The receiver is responsible for ensuring post-
        conditions are met and maintaining class
        invariants.
       Testers care about how this contract is enforced.
       Language support:
            iContract

                                                       12
      Class Specifications -
      Contract
             Pre and Postcondition - Summary
               Client (i.e. caller)                 Supplier (i.e. method)


Obligation     Must ensure precondition (i.e.       Must ensure post-
               correct input parameter)             condition (i.e. method
                                                    works correctly)


Benefit        Need not ensure post-condition       Need not ensure
               (i.e. special values or exceptions   precondition (i.e. validity
                                                    of input parameters),
                                                    although it needs to
                                                    check it before it runs.

                                                                                  13
Class Specifications - Contract
p binds the client A.
                                               q binds the supplier B.
It is an obligation for
                                               It is an obligation for B
A but a benefit for B.
                                                  but a benefit for A.


      Class A                 contract            Class B

                                                  m(x);
                                                     pre: p
                                                     post: q


                   Class B says to its clients:
            “If you promise to call m with p satisfied,
           then I, in return, promise to deliver a final
                   state in which q is satisfied.”                         14
Class Specifications - Contract
 double sqrt (double x)
   Design by contract example:
        require
               x >= 0
        do
               …
        ensure
               result * result == x
        end

   The same example using iContract
    syntax:
    //** return Square root of x
             @pre x >= 0
             @post return * return == x */
       double sqrt (double x) { … }
                                             15
        Defensive programming
   Interface is defined primarily in terms of the
    receiver.
   An operation returns some indication concerning
    the status of the result of the request (success or
    failure) in terms of return code.
   The receiver can provide the sender an object
    that encapsulates the status of the request.
       Exceptions are used frequently.


                                                     16
Defensive programming
   The goal is to identify “garbage in” and
    hence eliminate “garbage out”.
   A member function checks for the
    improper values coming in and then
    report that status of the request to the
    sender.



                                           17
Defensive programming
   This approach increases the complexity
    of the software.
       Each sender must follow a request for an
        operation with code to check the
        processing status and then;
       for each possible outcome, provide code to
        take an appropriate recovery action.
   Testers care about how the receiver
    ensures pre and post-conditions.
                                               18
Defensive programming
   Defensive programming example using
    assert:
     void test( int *p ) {
          assert( p != 0 );
          if (p == 0)
               return;
          // use p.
     }


                                     19
Class Specifications
   Contract vs. defensive programming:
       The contract approach simplifies class testing, but
        complicates interaction testing because we must
        ensure any sender meets preconditions.
       The defensive programming approach
        complicates both
            class testing (test cases must address all possible
             outcomes); and
            interaction testing (we must ensure all possible outcomes
             are produced and that they are properly handled by a
             sender).


                                                                  20
Class Implementation
   Class implementation describes how an
    object represents its attributes and carries out
    operations.
   It compromises several components:
       A set of data values stored in data members
        (instance variables or variables).
       A set of methods (member functions in C++ or
        methods in Java) constitutes code that will be
        used to implement an algorithm that accomplishes
        one operation declared in the public or private
        class specification.

                                                     21
Class Implementation – Testing
Perspective
   From testing perspective, potential causes of failures
    within class design and implementation:
       A class specification contains operations to construct
        instances. These operations may not properly initialize the
        attributes of the new instances.
       A class relies on collaboration with other classes to define its
        behaviors and attributes. These other classes may be
        implemented incorrectly.
       A class’ implementation “satisfies” its specification, but that
        is no guarantee that the specification is correct.
       The implementation might not support all required operations
        or may incorrectly perform operations.
       A class specifies preconditions to each operation. The class
        may not provide a way for the precondition to be checked by
        a sender before sending a message.
                                                                   22
Class Implementation
   The design approach used gives rise to
    different sets of potential problems:
       In contract approach we only need to test
        situations in which the precordinations are
        satisfied.
       In defensive programming approach we
        must test every possible input to determine
        that the outcome is handled properly.

                                                23
Key points
   Object-oriented concepts:
     interface

     class (specification and

      implementation)




                                 24
Announcements
   Help Session
       Wednesday or Thursday
       What time is suitable for everyone?
   Major 1 on Sat November 8, 2008
       What time is suitable for everyone?




                                              25

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:6/4/2012
language:English
pages:25