1

Komponentai, kurie turi būti patikrinti, yra objektų klasės, kurios realizuojamos kaip objektai.

Didesniems vienetams negu individuali funkcija “baltos dėžės” testavimas turi būti išplėstas.

Nėra akivaizdžios viršūnės smulkinančiam integravimui ir testavimui.

Objektinis testavimas

2

Testavimo lygiai

Testuoti operacijas susietas su objektais.

Testuoti objektų klases. Testuoti bendradarbiaujančių objektų

grupes. Testuoti užbaigtą objektinę sistemą.

3

Objektų klasių testavimas

Pilnas klasės testavimas apima : testavimas visų operacijų susietų su objektu, nustatymas ir apklausinėjimas visų objektų

atributų, bandymas objektų visose galimose būsenose.

Paveldimumas sukelia daug sunkumų sukurti klasių testus, kadangi informacija, kuri turi būti testuojama, nėra lokalizuota.

4

Meteorologinės stoties objekto sąsaja

Testiniai atvejai reikalingi visoms operacijoms.

Naudoti būvio modelį, kad identifikuoti testavimui būsenų perėjimus.

Testavimo sekų pavyzdžiai: Shutdown Waiting Shutdown

Waiting Calibrating Testing Transmitting Waiting

Waiting Collecting Waiting Summarising Transmitting Waiting

identifier

reportWeather ()calibrate (instruments)test ()startup (instruments)shutdown (instruments)

WeatherStation

5

Objektų integravimas

Integravimo lygiai yra mažiau aiškūs objektiškai--orientuotose sistemose.

Grupės (Cluster) testavimas liečia bendradarbiaujančių objektų integravimą ir testavimą.

Grupių identifikavimui naudojamos žinios apie objektų operacijas ir sistemos savybes, kurios yra įdiegtos šiose grupėse.

6

Objektų grupių testavimo metodai

Naudojamų atvejų arba scenarijaus testavimas: testavimas yra pagrįstas vartotojo ryšiu su sistema, turi pranašumą, kad taip testuojamos sistemos savybės

kaip patyrusių vartotojų. Gijų testavimas:

sistemos atsakymų į įvykius testavimas kaip veiksmų gijų apdorojimas.

Objektų bendravimo testavimas: testų sekos objektų bendravimui, kuris nutrūksta, kai

objekto operacijos neprašo paslaugų iš kitų objektų.

7

Testavimas pagal scenarijų

Atpažįsta scenarijų iš naudojamų atvejų (use-cases) ir jų papildymų su bendravimo diagramomis, kurios parodo objektus, įtrauktus į scenarijų.

Aptarkime meteorologinės stoties scenarijų, kur ataskaita yra sugeneruota.

8

Surinkti meteorologinius duomenis

:CommsController

request (report)

acknowledge ()report ()

summarise ()

reply (report)

acknowledge ()

send (report)

:WeatherStation :WeatherData

9

Meteorologinės stoties testavimas

Vykdomų metodų gijos CommsController:request WeatherStation:report

WeatherData:summarise

Įvedimas ir išvedimas: įvedamas prašymas reikalauja susietų žinių ir galinės

ataskaitos išvedimo, gali būti pratestuota sukurtais “žaliais” duomenimis ir

įsitikinta , kad reziumuota tinkamai, naudojami tie patys “žali” duomenys testuoti

WeatherData objektus.

10

What is Object-Oriented Programming?

Do we really know

what it is?

11

Things you “hear” about OO:a grain ( grūdas) of truth in all but one

It’s a “new way” of looking at things It’s a paradigm shift You have methods instead of functions you pass messages If you’ve used the “procedural approach”

than you can’t transition to OO You use objects, whatever they are! You use polymorphism, whatever that is!

12

Let’s compare OO to the “old ways”

Previous approach stressed algorithms. Usuall referred to as “procedure-

oriented” approach I like A. Riel’s term: “Action-Oriented”

approach

13

Action-Oriented Programming

Stresses “getting the algorithm correct” uses “functional decomposition” Has a “main” calling routine that

choreographs the activity, calling functions to implement the application

14

Object-Oriented Programming

Stresses the data Decompose the data, together with the

functions that operate on that data Put the data and operations into a “class” An instance of the “class” is an object Each “object” maintains its own data and

operations: must initialize and clean up! Decentralize control

15

Let’s consider an example

Let’s compare the worst-case action-oriented with the best-case object-oriented

Then, we’ll consider the case when the action-oriented goes right!

And, the object-oriented goes wrong!

16

A typicalaction-oriented topology

F1()

F4()

F3(

F2()

F5()

17

Consider a change to the data, marked X

F1()

F4()

F3(

F2()

F5() Functions f1() and f2() mustbe modified

18

However, suppose you or another developer added f6() (and forgot you did it!)

F1()

F4()

F3(

F2()

F5()

F6()

19

However, suppose you or another developer added f6() (and forgot you did it!)

F1()

F4()

F3(

F2()

F5()

You compile,link and execand it doesn’twork!

F6()

20

How does the OO approachcontrol this complexity

D1 D2

D1’s data D2’s data

f1()f2()f3()

f4()f5()f6()

call

call

21

Decompose the data

Data is encapsulated in a class (or object) well-defined public interface permits

operations on the data

22

When action-oriented goes right

Many people build systems using files, with each data structure in a separate file

the functions that operate on data are placed in the same file

some languages contain primitives to restrict operations within/across files (e.g. static, extern)

here, AO takes on attributes of OO approach

23

How can OO go wrong

The god class: performs most of the work, leaves minor details to other classes

proliferation ( daugintis) of classes: too many classes for the size of the problem

24

Class design heuristics

All data is hidden in a class implement a minimum public interface that all

classes understand do not put implementation details in the public

interface A class should capture one, and only one, key

abstraction Keep related data and behavior in one place

25

An important aspect of OO design is to determine the relationships between classes

BookItemJournalItem

LibraryItem

CommandProcessor

StudentPerson StaffPerson

Person LibrarySystem

ClerkPerson

Polymorphos-multiformSubstitutability- Įstatomumas

26

Testing Object-Oriented Software

An Overview,

from McGregor/Sykes

27

Advantages of OO Approach

improvement to development process & to code

if implemented correctly, oo software is higher quality than software developed under the procedural paradigm: understandability, maintainability, extensibility, reliability and reusability

28

Adv of OO

represents design results as refinement & extension of analysis

represents implementation results as a refinement & extension of design

testing OO is based primarily in the requirements of the software

29

What’s different about testing OO

Much carry-over from the procedural approach

For example, still do unit testing; however, what constitutes a until may be different in OO

30

What is software?

instruction codes and data necessary to accomplish a task, as well as all representations of those instructions and data

what are representations: the models developed during analysis

31

Adv of models

test cases can be identified earlier in the development process

errors and faults can be detected earlier test cases developed for analysis

models can be refined and extended to test design models, which can be refined and extended to test subsystems and systems

32

The approach

analyze a little design a little code a little test what you can

33

Kinds of testing for OO

Model testing interaction testing; replaces integration

testing system and subsystem testing acceptance testing: testing of the

application by end users, usually before release

34

Testing Perspective

questions the validity of software & utilizes thorough investigation to identify failures

makes execution-based testing more powerful than reviews or inspections;

reviews never find something that’s missing -- only validates what’s there

35

OO Programming centers around:

object message encapsulation inheritance, and polymorphism

36

For testing, an object:

might be destroyed before it should be might persist ( išsilaikyti) longer than it

should might be manipulated by another object

so that its data becomes inconsistent with other data in the system

might have inappropriate data or exhibit incorrect behavior in the system

37

For testing, a message can fail if:

a sender requests an operation not defined by the receiver

a message contains an improper actual parameter

the receiver cannot perform the requested operation at the time of the request

a sender doesn’t handle the reply properly the receiver returns an incorrect reply

38

Two parts to each class

specification: what each object in the class can do query operations (in C++ s/b const) modifier operations

implementation: how each object in the class does it

39

Two special kinds of class operations

constructor destructor These are different from queries and

modifiers: invoked implicitly!

40

3 Kinds of statements to specify the semantics of a class

pre-conditions: conditions that must hold before an operation can be performed

post-conditions: conditions that must hold after the operation is performed

class invariants: conditions that must always hold for an instance of a class; an implied ( numatomas) post-condition for each operation; can be violated during execution

41

methods

Characterized by behavior behavior can be specified by:

state diagrams sequence diagrams

Two approaches to defining the interface between sender and receiver: contract approach, B. Meyers (1994) defensive programming approach

42

Contract Approach

The interface is defined in terms of the obligations of the sender and receiver involved in the action

obligations specified by pre/post conditions pre-condition: describe the obligation of the

sender (to ensure preconditions are met) post-condition: obligations of the receiver (to

ensure post-conditions and class invariants are met)

43

#ifndef PUCKSUPPLY_H#define PUCKSUPPLY_Hclass PuckSupply {public:

PuckSupply();~PuckSupply();Puck * get();int count() const;

private:int _count;Puck* _store[N];

};#endif

#include “PuckSupply.h”PuckSupply::PuckSupply():(N) {

for (int I = 0; I < N; ++I) {_store[I] = new Puck;

};}

PuckSupply::~Puck() {(for int I=0; I < _count; ++I) {

delete _store[I];};

}

Puck* PuckSupply::get() {return _count > 0 ? _store[--_count]:0;

}

int PuckSupply::count() const {return _count;

}

44

Spec for PuckSupply based on contractsA puck supply is a set of pucks not in play that can be retrieved one at a time. The

pucks are created by a puck supply when it is created.

Class invariant: count associated w/ puck supply is always an integer from 0 to 3, incl.

The count() operation can be applied at any time; it returns the no. of pucks left in the receive and has no effect on the receiver

The get() operation can only be applied if the receiver has at least one puck (count > 0)

constructor has no pre-conditions. The result of the constructor is a puck supply of 3 (count = 3)

the destructor has no pre-conditions; the destructor deletes any pucks that remain in the object

45

Spec for PuckSupply based on Defensive ProgrammingA puck supply is a set of pucks not in play that can be retrieved one at a time. The pucks

are created by a puck supply when it is created.

Class invariant: (count between 0 & 3) -- same The count() operation: (returns no. of pucks) -- same The get() operation can be applied at any time; if the

receiver has at least one puck (count>0) then the result of the operation is a return of a pointer to a puck and reduce the number of pucks by one; owise a NULL pointer is returned and count attribute remains 0.

Constructor: (gives you 3 pucks) -- same the destructor: (deletes remaining pucks) -- same

46

Spec for PuckSupply based on Contract ProgrammingUsing OCL Notation

PuckSupplycount >= 0

PuckSupply::PuckSupply():pre: -- nonepost: count = 3 AND pucks->forAll(puck | not puck.inPlay())

void PuckSupply::count() const:pre: -- nonepost: result = count

Puck * PuckSupply::get()pre: count > 0post: result = pucks->asSequence->first AND

count = count@pre-1

47

Defensive vs Contract

Defensive: interface defined in terms of receiver an operation typically uses return code, or exception goal is to identify “garbage in” to eliminate “garbage out” tends to increase software complexity because each sender

must follow each message w/ check of return code (even though receiver already checked)

complicates class testing: must test for all possible outcomes! Complicates interaction testing: all outcomes handled by

sender

48

Defensive vs Contract

Contract: reflects mutual responsibility and trust eliminates need for receiver to check return

codes important question: How are contracts

enforced? Simplifies class testing but complicates

interaction testing: ensure sender meets pre-conditions

49

A class implementation has:

Data members set of member functions set of constructors destructor set of private operations (in private

interface)

50

Class testing

Since a class is an abstraction of commonaltie, the process must ensure that a rep sample of instances of the class are selected for testing

51

Potential causes of failure of class design/implementation

Doesn’t meet specification contains operations and data that affects the

proper construction of instances might rely on collaboration w/ other objects might meet its spec, but spec might be

incorrect, or violate a higher requirement might specify pre-conditions but not provide

mechanism to check if pre-condition is met

52

In contract/defensive approach:

Contract: must test to ascertain that every attempt to apply an operation must first satisfy pre-conditions

defensive: ascertain that every possible outcome is handled properly

53

Inheritance

Define a new class based on definition of an existing class

used only to implement is-a-kind-of relationship

best use of inheritance is with respect to interfaces and not implementations

54

Inheritance, from testing view

Permits bugs to be propagated from a class to its descendents ( palikuonis)

permits test case reuse verify it’s used properly:

use of inheritance solely for code reuse will probably lead to maintenance difficulty,

this is a design issue, but so common that testers can make a significant contribution by making sure inheritance is used properly

55

Polymorphism

A sender in an OO program can use an object based on its interface and not on its exact class

a derived class inherits the public interface of its base class and thus instances of either class can respond to the same messages

in Java, supported through inheritance or interfaces

56

Poly (cont.)

Because polymorphic references hide the actual class of a referent, both C++ & Java provide support for determining at run time the actual class of a referent

Good OO design holds these run-time inspections to a minimum because they create a maintenance point: extension of the class hierarchy introduces more types to be inspected

57

Testing polymorphism

An operation can return a reply that is a polymorphic reference; the actual class of the referent could be incorrect

any operation can have one or more parameters that is a polymorphic reference; the parameter could be incorrect

Number of instances to check could be large: Need statistical analysis to determine which configurations will expose most faults for least cost

58

OO development products

Use cases class diagrams activity diagrams

state diagrams sequence diagrams

class specification (in OCL) state diagrams activity diagrams