25
1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object- Oriented Software)

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

  • View
    221

  • Download
    1

Embed Size (px)

Citation preview

Page 1: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

1

Software Testing and Quality Assurance

Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to

Testing Object-Oriented Software)

Page 2: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

2

Lecture Outline Testing perspective -Object-Oriented

Concepts Interface Class

Page 3: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

3

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.

Page 4: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

4

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.

Page 5: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

5

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();

}

Page 6: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

6

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.

Page 7: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

7

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.

Page 8: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

8

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.

Class Specifications

Page 9: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

9

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.

Page 10: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

10

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)

Page 11: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

11

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.

Page 12: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

12

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

Page 13: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

13

Class Specifications - Contract Pre and Postcondition - Summary

Client (i.e. caller) Supplier (i.e. method)

Obligation Must ensure precondition (i.e. correct input parameter)

Must ensure post-condition (i.e. method works correctly)

Benefit Need not ensure post-condition (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.

Page 14: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

14

Class Specifications - Contract

Class B

m(x);

contractClass A

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

q binds the supplier B. It is an obligation for B

but a benefit for A.

p binds the client A. It is an obligation for A but a benefit for B.

Page 15: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

15

Class Specifications - Contract

Design by contract example:

The same example using iContract syntax:

double sqrt (double x)require

x >= 0do

…ensure

result * result == xend

//** return Square root of x @pre x >= 0 @post return * return == x */ double sqrt (double x) { … }

Page 16: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

16

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.

Defensive programming

Page 17: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

17

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.

Page 18: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

18

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.

Page 19: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

19

Defensive programming

Defensive programming example using assert:

void test( int *p ) { assert( p != 0 ); if (p == 0)

return; // use p.

}

Page 20: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

20

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

Page 21: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

21

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.

Page 22: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

22

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.

Page 23: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

23

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.

Page 24: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

24

Key points Object-oriented concepts:

interface class (specification and

implementation)

Page 25: 1 Software Testing and Quality Assurance Lecture 11 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)

25

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?