Software Testing and Quality Assurance: The Testing Perspective - PowerPoint PPT Presentation

About This Presentation

Software Testing and Quality Assurance: The Testing Perspective


Reading Assignment: John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001, ISBN: 0-201-325640. – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 44
Provided by: Was142


Transcript and Presenter's Notes

Title: Software Testing and Quality Assurance: The Testing Perspective

Software Testing and Quality Assurance The
Testing Perspective
  • Reading Assignment
  • John McGregor and David A. Sykes, A Practical
    Guide to Testing Object-Oriented Software,
    Addison-Wesley, 2001, ISBN 0-201-325640.
  • Chapter 2
  • http//

  • Testing perspective.
  • Object-Oriented concepts.
  • Overview of UML models.

Introduction Testing perspective
  • Testing perspective a way of looking at any
    development product and questioning its validity.
  • The person examining work products from this
    perspective utilizes a thorough investigation of
    the software and all its representations to
    identify faults.
  • It makes reviews and inspections just as powerful
    a tool as execution-based testing.
  • Requires that a piece of software demonstrate
    that it not only performs according to its
    specification, but also performs only to that

Inspection, review, and test execution
  • Software testing is typically accomplished by
  • Inspection an examination of software based on
    checklist of typical problems, most items on the
    check list are based on programming language
    semantics and coding conventions (e.g. ensuring
    that each variable is initialized before its
    first use).
  • Review an examination of software with the
    purpose of finding errors and faults even before
    the software is executed (uncover errors such as
    missed or misunderstood requirements or faults in
    a programs logic).
  • Test execution testing software in the context
    of a running program (test if the program has the
    required behavior by giving the program some
    input and verifying that the resulting output is

Testing perspective
  • Skeptical
  • Wants proof of quality.
  • Objective
  • Makes no assumptions.
  • Thorough
  • Doesnt miss important areas.
  • Systematic
  • Searches are reproducible.

Object-Oriented concepts
  • Object
  • Message
  • Interface
  • Class
  • Inheritance
  • Polymorphism

Object-Oriented concepts object
  • An object is an operational entity that
    encapsulates both specific data values and code
    that manipulates those values.
  • Objects are the direct target of the testing
    process during software development.
  • The life cycle for an object begins when it is
    created, proceeds through a series of status, and
    ends when the object is destroyed.

Object-Oriented concepts object (cont...)
  • An object encapsulates and hides information.
  • An object has a state that persists for the life
    of the object.
  • An object has a lifetime.
  • Testers care about
  • Whether the object behaves according to its
  • Whether it interacts appropriately with
    collaborating objects in an executing program.

Object-Oriented concepts message
  • A message is a request that an operation be
    performed by some object.
  • A message has a sender (originating a message).
  • A message has a receiver (receiving the message).
  • A message may include actual parameters.
  • Some messages result in some form of reply such
    as return value and exception.
  • Testers care about
  • Senders
  • Receivers
  • Parameters

Object-Oriented concepts interface
  • An interface is an aggregation of behavioral
  • An interface is a building block for
  • In Java interface
  • In C abstract class with public, pure virtual
  • An interface encapsulates operation
  • An interface has relationships with other
    interfaces and classes.
  • Testers care about
  • Relationships with other interfaces

Object-Oriented concepts interface example
  • public interface Movable
  • public Point getPosition()
  • public void move()

Object-Oriented concepts class
  • A class is a set of objects that share a common
    conceptual bases (a template for creating
  • Objects form the basic element for executing OO
    programs while classes form the basic elements
    for defining OO programs.
  • 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 carries
    out what it can do.

Object-Oriented concepts class class
  • 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) operations provide
    information about an object.
  • Modifier (mutator) operations change the state
    of an object by setting one or more attributes to
    have new values.
  • 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 objects lifetime.

Object-Oriented concepts class class
specification (cont...)
  • Semantics can be specified at several different
  • 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.
  • Testers care about
  • Preconditions
  • Postconditions
  • Invariants
  • Relation to other classes (interactions)

Object-Oriented concepts class class
specification (cont...)
  • To write specifications 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.

Object-Oriented concepts class class
specification (cont...)
  • Design by contract
  • A contract is between the sender and the receiver
    of a message.
  • The sender is responsible for ensuring that the
    preconditions are met.
  • The receiver is responsible for ensuring that the
    postconditions are met and maintaining class
  • Testers care about how this contract is enforced.
  • Language support
  • (Eiffel) by Meyer
  • iContract

Object-Oriented concepts class class
specification (cont...)
  • Pre and Postcondition - Summary

Client (i.e. caller) Supplier (i.e. method)
Obligation Must ensure precondition (i.e. correct input parameter) Must ensure postcondition (i.e. method works correctly)
Benefit Need not ensure postcondition (i.e. special values or exceptions) Need not ensure precondition(i.e. validity of input parameters), although it needs to check it before it runs.
Object-Oriented concepts class class
specification (cont...)
p binds the client A. It is an obligation for A
but a benefit for B.
q binds the supplier B. It is an obligation for
B but a benefit for A.
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
Object-Oriented concepts class class
specification (cont...)
  • Design by contract example
  • The same example using iContract syntax

Object-Oriented concepts class class
specification (cont...)
  • Invariant example

class StackG private int count boolean
isEmpty() other things
invariant isEmpty() (count 0) end
Object-Oriented concepts class class
specification (cont...)
  • Defensive programming
  • 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.
  • 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.

Object-Oriented concepts class class
specification (cont...)
  • Defensive programming
  • This approach increases the complexity of the
  • 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
  • Testers care about how the receiver ensures pre
    and postconditions.

Object-Oriented concepts class class
specification (cont...)
  • Defensive programming example

sqrt (x, epsilon REAL) REAL is -- Square root
of x, precision epsilon require x gt
0 epsilon gt 0 do if x lt 0 then Do
something about it (?) else Normal square
root computation end ensure abs (Result 2
x) lt 2 epsilon Result end
Object-Oriented concepts class class
specification (cont...)
  • Defensive programming example using assert

void test( int p ) assert( p ! 0 ) if (p
0) return // use p.
Object-Oriented concepts class class
specification (cont...)
  • 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).

Object-Oriented concepts class class
  • Class implementation describes how an object
    represents its attributes and carries out
  • 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.
  • A set of constructors to initialize a new
  • A destructor that handles any processing
    associated with the destruction on an instance.
  • A set of primitive operations in a private

Object-Oriented concepts class class
implementation (cont...)
  • 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
  • A class relies on collaboration with other
    classes to define its behaviors and attributes.
    These other classes may be implemented
  • 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.

Object-Oriented concepts class class
implementation (cont...)
  • 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
  • In defensive programming approach we must test
    every possible input to determine that the
    outcome is handled properly.

Object-Oriented concepts inheritance
  • Inheritance is a relationship between classes
    that allows the definition of a new class based
    on the definition of an existing class.
  • Inheritance is is-a (or is a kind of)
  • Preexisting class does not have to be modified or
    made aware in any way of the new class.
  • The new class is referred to as a subclass or
    derived class (in C).
  • If a class inherits from another class, the other
    class is referred to as a super class or base
    class (in C).

Object-Oriented concepts inheritance (cont...)
  • The set of classes that inherit either directly
    or indirectly from a given class form an
    inheritance hierarchy.
  • Testers care about
  • Propagation of errors
  • Potential for test reuse

Object-Oriented concepts inheritance (cont...)
  • From testing perspective
  • Provides a mechanism by which bugs can be
    propagated from a class to its descendents.
    Testing a class as it is developed eliminates
    faults early before they are passed on to the
    other classes.
  • Provides a mechanism by which we can reuse test
    cases (reuse test cases for the super class in
    testing the subclass because the subclass
    inherits from the super class).
  • Models an is a kind of relationship. Proper use
    of inheritance in design leads to benefits in
    execution testing of classes.

Object-Oriented concepts inheritance (cont...)
  • Substitution principle
  • If D is a subclass of C, then if an instance of C
    performs acceptably in a context, you can replace
    that instance of C with an instance of D and it
    will perform acceptably in that context.

Object-Oriented concepts polymorphism
  • Polymorphism is the ability to treat an object as
    belonging to more than one type.
  • Testers care about
  • Unanticipated interactions

Object-Oriented concepts polymorphism (cont...)
  • Inclusion polymorphism Inclusion polymorphism is
    the occurrence of different forms in the same
    class (dynamic binding) -substitute an object
    whose specification matches another objects
    specification for the later object in a request
    for an operation
  • In C
  • Inclusion polymorphism arises from the
    inheritance relationship. A derived class
    inherits the public interface of its base class
    and thus instances of the derived class can
    respond to the same message as the base class.
  • In Java
  • Inclusion polymorphism is supported both through
    inheritance between classes and an implementation
    relationship between interfaces and classes.

Object-Oriented concepts polymorphism (cont...)
  • Inclusion polymorphism from testing perspective
  • Inclusion polymorphism allows systems to be
    extended incrementally by adding classes rather
    than modifying existing ones.
  • Inclusion polymorphism allows any operation to
    have one or more parameters of a polymorphic
    reference. This increases the number of possible
    kinds of actual parameters that should be tested.

Object-Oriented concepts polymorphism (cont...)
  • Parametric polymorphism is the capability to
    define a type in terms of one or more parameters
    (e.g. templates in C)
  • From testing perspective
  • Parametric polymorphism supports a different type
    of relationship from inheritance. If the template
    works for one instantiation, there is no
    guarantee it will work for another.

Development products
  • Unified Modelling Language
  • Developed by Grady Booch, James Rumbaugh, and
    Ivar Jacobson
  • Combined Booch's O-O design, Rumbaugh's OMT, and
    Jacobsons OOSE
  • A notation for modelling

Development products analysis models
  • Two levels of analysis domain
  • Domain analysis focuses on an understanding of
    the problem domain-that is, the general area of
    interest in which the problem of immediate
    interest lies.
  • Application analysis focuses on specific problem
    and the requirements for a solution.
  • Analysis models use case, class, state,
    sequence, and activity diagrams

UML diagrams
  • Use case diagram represents the actors and uses
    of the system and relationships between the uses.
  • Class diagram represents the individual class
    definitions and the relationships between
  • Package diagram presents conceptual groupings of
    classes with dependencies between groups.
  • Sequence diagrams records the sequence of
    messages that represent an algorithm.
  • State diagram presents different configurations
    of data-attribute values and the messages that
    transform the data from one configuration to
  • Activity diagram aggregates all possible paths
    through the logic of a method.

Development products design models
  • A design model represents how the software meets
  • From a testing perspective, we can reuse and
    extend use cases developed for analysis models.
  • Design models class, state, and sequence diagrams

Development products source code
  • Source code and source code documentation are the
    final representation of the software.
  • Major issues
  • Who tests testing can be done by developers who
    adopt a testing perspective.
  • What to test each class can be tested separately
    before it is used as part of the system.
  • When testing is done testing can be done at any
    time during development.
  • How testing is done function-based and
  • How much testing is done exhaustive testing of
    each software component and of a whole system is
    seldom practical or possible.

Key points
  • Testing perspective a way of looking at any
    development product and questioning its validity.
  • Software testing is typically accomplished by
    inspection, review, and test execution.
  • Testing perspective is skeptical, objective,
    thorough, and systematic.

Key points (cont...)
  • Object-oriented concepts
  • Object, message, interface, class (specification
    and implementation), inheritance, polymorphism
  • Overview of UML models.
  • Analysis models (use cases, class, state,
    sequence, activity)
  • Design models (class, state, sequence, source
Write a Comment
User Comments (0)