Software Testing and Quality Assurance

1
Software Testing and Quality Assurance

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

2
Lecture Outline

• Testing perspective -Object-Oriented Concepts
• Class Implementation
• Inheritance
• Polymorphism

3
Class Specifications - Recap

• 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).

4
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.

5
Class Implementation

• 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.

6
Class Implementation

• 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.

7
Class Implementation

• The design approach used, contract or defensive,
  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.

8
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)
  relationship.
• Pre-existing 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).

9
Inheritance

• 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

10
Inheritance Testers 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.

11
Inheritance Testers Perspective

• Provides a mechanism by which we can reuse test
  cases
• Reuse test cases for the super class in testing
  the subclass.

12
Polymorphism

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

13
Polymorphism

• 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

14
Polymorphism

• 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.

15
Polymorphism Testing Perspective

• Inclusion polymorphism from testing perspective
• Inclusion polymorphism allows systems to be
  extended incrementally by adding classes rather
  than modifying existing ones.

16
Polymorphism Testing Perspective

• 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.

17
Polymorphism

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

18
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

19
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

20
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
  classes.
• Package diagram presents conceptual groupings of
  classes with dependencies between groups.
• Sequence diagrams records the sequence of
  messages that represent an algorithm.

21
UML diagrams

• State diagram presents different configurations
  of data-attribute values and the messages that
  transform the data from one configuration to
  another.
• Activity diagram aggregates all possible paths
  through the logic of a method.

22
Development products design models

• From a testing perspective,
• we can reuse and extend use cases developed for
  analysis models.
• 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.

23
Development products source code

• When testing is done
• testing can be done at any time during
  development.
• How testing is done
• function-based and specification-based.
• How much testing is done
• exhaustive testing of each software component and
  of a whole system is seldom practical or
  possible.

24
Key points

• Object-oriented concepts
• Class implementation, inheritance, polymorphism
• Overview of UML models.
• Analysis models (use cases, class, state,
  sequence, activity)
• Design models (class, state, sequence, source
  code).