View
216
Download
2
Category
Preview:
Citation preview
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
Recommended