Objektum orientált szoftverek tesztelése
2
OO sajátosságok ! adat-elrejtés !
egymásra ható független objektumok saját állapotokkal (nincs egy megosztott globális állapot ) ! a rendszer struktúrája helyett a viselkedésén van a hangsúly ! kód újrafelhasználás ! egységbezárás ! öröklés ! többalakúság
3
OO következmények ! Egységbezárás
az osztályok nem funkcionális részprogramok (metódusok) ! nehéz integrációs tesztelés (állapot beállítás) !
! Adat !
elrejtés
állapot vizsgálat az objektum interfészén keresztül
! Örökl!dés !
többszörös tesztelés szükségessége
4
OO következmények (folyt.) ! Tesztelési !
szintek
Mi egy egység?
! Kompozíciós
stratégia ! Integrációs és rendszer tesztelés GUI ! UML-alapú tesztelés !
5
Teszttervezés ! Várható !
OO meggondolások ! ! !
Bizonyos hibák kisebb valószín"séggel Bizonyos hibák nagyobb valószín"séggel Újfajta hibák
! Várható !
hibák alapján
felhasználás alapján
Scenárió alapú tesztelés
6
Újfajta hibák ! Örökl!dés,
többalakúság
milyen kód hajtódik végre metódus híváskor? ! jó-e a paraméterek formája? ! pl.: base::foo() derived::foo() ! teszt nyílvántartás (kontextus) változása !
7
Hibavalószín"ség változása ! OO !
metódusok általában rövidebbek
inkább integrálási problémák
8
A rendszer szétbontása ! objektumok,
osztályok -> modul
tesztelés ! együttm!köd" osztályok -> osztály csoport tesztelés (integrációs teszt)
9
OO egységek ! Legkisebb
lefordítható és végrehajtható komponens ! Mindig egy f! fejleszt! hozza létre !
Eltérések !
Óriás osztályok " "
Metódus csoportok Rész osztályok
! Osztályok !
mint egységek
UML állapotgépek
10
Osztály tesztelés ! Metódusok,
mint egységek
alacsony ciklomatikus komplexitás ! bonyolult interfészek ! sok csonk szükséges !
! Intraclass
és interclass integráció ! Osztályok, mint egységek statikus nézet ! fordítási id! nézet ! végrehajtási id! nézet !
Hagyományos tesztelési módszerek ! Izolációs
11
tesztelés
nehéz, ritkán alkalmazott ! pl.: !
Osztály tesztelés alatt
Osztály A
Osztály B
Osztály C
Osztály D
Hagyományos tesztelési módszerek ! Bottom-up
tesztelés
osztályokból álló rétegek ! probléma a körkörös hivatkozásokkal ! bels" m!ködés és interfészek tesztelése egyszerre történik !
12
13
Tervezés tesztelhet"ségre ! Osztályok
közötti felesleges kapcsolatokat kerülni kell ! Lehet"ség a bels" adat lekérdezésére, beállítására ! Ne használjunk feleslegesen virtuális metódusokat ! Absztrakt alap osztályok használata (interfész osztályok)
14
Interfész-osztályok Interfész A Osztály tesztelés alatt Implementáció A
Interfész B
Interfész C
Implementáció B
Implementáció C
Interfész D
Implementáció D
15
OO tesztek végrehajtása ! Tesztmeghajtó,
f!program ! Tesztel! keretrendszer és tesztosztályok csatlakoztatása
16
JUnit egység-tesztel! keret ! Java
programok egység-tesztelése ! Automatikus tesztelés !
Tesztkészletek végrehajtása !
!
Tesztfutások “értékelése” !
!
Fejlesztéssel egyidej" teszteset tervezés eredmények értékelése
Teszteredmények rögzítése
17
JUnit egység-tesztel! keret ! Végrehajtás
és dokumentálás alapja a command pattern
18
JUnit egység-tesztel! keret ! A Test
osztály m"ködése
runnable -> végrehajtható ! public void run() { setUp(); //felépítés, beállítás runTest(); //teszt futtatás, plugable sel. tearDown(); //lebontás, takarítás } !
19
JUnit egység-tesztel! keret ! Teszt
metódusok
tesztelend! kód hívása ! kijelentések a helyes eredményekre vonatkozóan !
! ! !
!
assert(’2’==ch) assertEquals(’2’,ch) fail()
TestSuite-ok létrehozása ! ! !
ekvivalencia osztályok határérték analízis stb.
20
JUnit egység-tesztel! keret ! Hiba
kezelés
failure (erre számítunk, teszteredmény) ! error (erre nem számítunk) !
!
public void run(TestResult result) { result.startTest(this); setUp(); try { runTest(); } catch (AssertionFailedError e) { //1 result.addFailure(this, e); } catch (Throwable e) { // 2 result.addError(this, e); } finally { tearDown(); } }
21
JUnit egység tesztel! keret ! IDE
integráció (pl. eclipse, netbeans)
Text interface ! Grafikus felület !
Öröklési kontextus metrikák szükségessége Bázis osztály
Lesz. A
Lesz. B
Örökölt metódusok
Örökölt metódusok
Új metódusok
Új metódusok
22
23
1. Példa ! bázis
osztály
inherited(int x) ... if(x<0) x=x/redef(); ... ! redef() : int 1..10 !
! leszármaztatott !
osztály
redef() : int 0..20
24
Állapot kontextus ! Állapotgép
alapú tesztelés
állapot függ! viselkedés ! állapot-kontextus metrikák !
! Belépési
pont lefedés állapotkontextussal
25 4.2.
Using White-Box Coverage Metrics If entry-point coverage does not ensure thorough testing, perhaps we should use a stronger coverage requirement, say, 100% decision coverage. Unfortunately, there are disadvantages to the adoption of such a requirement.
2. Példa
One factor is that there may be decisions in the code which do not correspond to features of the public interface. Typical examples include error handling code and defensive programming idioms. In these cases, 100% decision coverage may be difficult to achieve.
! Korlátos
stack
A more significant problem is the inability of traditional structural coverage metrics to int test_driver() { identify code which is missing altogether. For example, consider what would happen BoundedStack stack(2); if the BoundedStack implementor forgot to check for the stack-empty condition in pop(). Requiring 100% decision coverage would not help find this fault – the stack.push(1); missing condition is not there to be covered!
4.3.
};
We Can Do Better
stack.pop(); // destructor called implicitly at end of block
Actually, we can write a better test set than that required by any traditional structural coverage metric, and without any knowledge of the internal details of the class.
int better_test_driver() {
The UML state transition diagram (see figure 6) shows how the behaviour of the class BoundedStack stack(2); changes, depending on the current state. This type of diagram is commonly used to describe the state-dependent behaviour of classes stack.push(3); // push() when H Throws BoundedStack::underflow
construction
pop()
empty
push()
pop()
destruction
pop() partially full
destruction
H
push() push()
pop()
Throws BoundedStack::overflow
destruction
full push()
Figure 6: State transition diagram for BoundedStack We can use the additional information provided in the state transition design a test set which thoroughly exercises the BoundedStack class.
4.4.
empty stack.push(1); // push() when partially-full try { stack.push(9); } // push() when full catch (BoundedStack::overflow) { } // expected to throw stack.pop(); // pop() when full stack.pop(); // pop() when partially-full try { stack.pop(); } // pop() when empty catch (BoundedStack::underflow) { } // expected to throw BoundedStack stack2(3); stack2.push(6); // stack2 is partially-full BoundedStack stack3(1); stack3.push(6); // stack3 is full // destructors called implicitly at end of block for diagram to // stack (empty), stack2 (partially-full) and stack3 (full) };
Writing State-Driven Test Cases The aim of our test design is to exercise every method in every possible state. In the improved test set which follows, the push() and pop() methods are invoked on an empty, partially full and full stack: 10 ©IPL Information Processing Ltd
26
Integrációs tesztelés ! UML
támogatás az integrációs teszteléshez Együttm"ködési diagram ! Szekvencia diagram !
! MM-utak ! Különböz!
szomszédsági centrumok
27
Integrációs tesztelés (folyt.) ! Metódus-Üzenet !
üzenetekkel összekötött metódus végrehajtási szekvencia
! Stimulus-Válasz !
utak
utak
események kiváltotta rendszerszint" metódus-üzenet út szekvencia
Kombinált osztály állapotgépek ! Objektum
viselkedése -> állapot átmeneti szabályok állapot (példány és osztály változók) ! események (metódus hívások) ! !rfeltételek (predikátumok a változók felett) ! tevékenységek (értékadások, metódushívások) !
28
29
Kombinált osztály állapotgépek (folyt.) ! Komponens !
elemei !
! ! !
!
folyam gráf
adat és vezérlés folyam a tesztelés szempontjából releváns átmenetekre forrás és cél állapot !rfeltétel Sss Gt Tt tranzíció
Sts
kommunikáló objektumokon keresztül !
actor és mutator metódusok "
def és use helyzetek
Kombinált osztály állapotgépek (folyt.)
variable v. This transition as represented in a component flow graph is presented in Figure 2. The transition node is T1 , the guard node is G1 , and Sa and Sb are the source and target state nodes. Transition nodes that define a variable are labeled, such as def v on node T1 . Uses of v are represented by points ui on edges and inside transition nodes. Both Sa and Sb use v (u1 and u3 ) in their predicate definitions. Function f () is invoked from some other transition, which is represented by transition node Tx . The get function for v is represented by transition node Tva if obj1 is in state Sa when it’s called, and by Tvb if obj1 is in state Sb .
! komponens Tx
folyam gráf pl.
call f ()
Obj1
rest Sa
u1
f ()
G1
u2
T1
Sb
u3
30flow graph, uses of a In a general data predicate are represented by use labels the corresponding state node (u1 , u2 , u3 or parameter in a guard predicate are labels on all edges leaving the corresp (u4 , u6 ). These are called predicate uses in the action of a transition are called (u5 , u7 ). Uses of a variable in a passed p parameter uses (u6 , u7 ).
To summarize, Figure 2 represents the d resulting from definition of variable v b f in obj1, the predicate and computatio in obj2, the passing of that value as a pa h(p), and the resulting predicate and com eter use of v in the guard and action of
def v Tva
Tvb get v
get v
Obj2 Sc
Ty
g ()
G2
u4
T2
Sd
u5
call h (p)
call g ()
Obj3 Se
h (p)
G3
u6
T3
u7
Sf
Figure 2: Portion of Component Flow Graph
Consider obj2, and a transition t2 (transition node T2 ). The guard predicate for t2 (G2 ) calls the get function for v in obj1. This get is represented by two edges from obj1, both labeled by get v. G2 uses v (u4 ), and for it to evaluate to
3. COVERAGE CRITERIA
A number of different coverage criteria data flow graphs, including all-defs, all These have been discussed and compare literature [5, 7, 9, 10, 13]. The object-orie ology described here follows the lead of o focuses on defs and uses of class variab This allows a tester to focus on testing traversal of a def-use path in the compon a transition node that defines a variabl that uses the variable, with no re-defini at any node along the path.
The all-uses testing criterion applied to graph requires tests to execute at least definition of a variable at a transition no use at another node or edge. In Figure uses criterion to variable v in class A req force execution of def-use paths from tr each of the uses u1 to u7 . In the portio
31
Kombinált osztály állapotgépek (folyt.) ! Lefedési !
adatfolyam lefedési kritériumok !
all-defs, all-uses, all-paths
! Teszt !
kritériumok
végrehajtás
tesztelés szempontjából két fajta út !
!
def-use (lehet!leg minél több use tartalmazásával) ext-int (küls! tranzíció)
privát metódusok közvetlenül nem hívhatók ! “nyugalmi” állapotok !
32
Kombinált osztály állapotgépek (folyt.) ! Teszt
S2
F2
specifikálás def-use úthoz rest
T5
Sy F5 Ty
g
S3 F1 Sc
def
rest
T1
Sb
Tvb
v ()
T4
g
use
G2
T2
h
Se
h
G3
T3
rest
G1 f
rest
Sa f Tx
F4
Sx
T6
F3
S1
Figure 3: External Function Calls to Traverse a Def-Use Path
in black box testing. The goal of this research is to identify a sequence of functions Fi from F that when executed in the identified order will cover as many paths in CTP as possible. Given a software system consisting of multiple objects, its
External Functions F
System States SS
F1
SS0
ext-int Paths EXT
def-use Paths CTP
r
Sy F5 Ty
g
S3 F1 Sc
def
rest
T1
Sb
Tvb
v ()
T4
g
use
G2
Se
h
G3
T3
33
Kombinált osztály állapotgépek (folyt.) rest
G1 f
rest
Sa f Tx
F4
Sx
T6
F3
S1
Figure 3: External Function Calls to Traverse a Def-Use Path
! Tesztkészletek
The goal of this research is to identify Fi from F that when executed in the ver as many paths in CTP as possible.
m consisting of multiple objects, its n point in time is defined to be the that time. Suppose a program is in te SS0 and suppose an external funch some choice of values for any of its ending on the object states identified g on the values chosen for any input of a subset of paths in EXT will be of the paths in EXT have any rest be traversed to its ending transition uction of such paths, this node may node of a number of def-use paths in ll be initiated and traversed up to its h in CTP has no rest states, then the l be completed and one can conclude vers all such paths. At the completion ons identified by these paths, the softa new system state SS1 . The tester econd external function F2 to initiate int paths from EXT. Some of these n, initiate a set of new def-use paths n, every execution of a transition in nt path, or in the middle of a leg bedef-use path, may call functions that tion in a previously initiated def-use in a rest state. Figure 4 presents the g successive functions from F to initihich in turn initiate new CTP paths existing CTP paths to the next rest s in a def-use path are labeled r, and orce traversal from a rest state to a th are labeled t.
External Functions F
System States SS
F1
SS0
generálása
ext-int Paths EXT
def-use Paths CTP
r
r
F2
r
SS1
t
t
r
Fn
SSn-1
r
t
Figure 4: Generating an External Test Sequence
transition at a time. This analysis will remove from further consideration at this step in test sequence generation paths that produce inconsistencies in the parallel traversal of all initiated paths. At each step in this process, the following actions must be taken:
Tesztek újra hasznosítása • Identify one guard predicate to be satisfied when a choice of guard nodes appear in simultaneous paths • Delete all paths with guard nodes for the same function that differ from the selected guard
! Felüldefiniált és többalakú metódusok • Identify and delete any combined ext-int-def-use paths
may initiate multiple paths in EXT! may initiate or extend multiple paths ese paths will be mutually inconsis-! contradictory guard predicates, some ompatibility rule for paths, and some le that has already been defined by he head of a def-use path. It will be very carefully, all initiated paths one
i
h
T2
that violate the state compatibility rule
eltér! specifikáció és megvalósítás • Delete any paths currently in a rest state whose next action is inconsistent with any triggered transition up megfelel! hasonlóság to this pointtervezéssel in the analysis átfed! tesztesetek
! • Identify and delete any combined ext-int-def-use paths that are currently at a rest state, but for which the triggered actions of the current external function result in re-definition of the def variable
34
35
3. Példa
36
OO tesztelés metrikái ! Belépési
pont lefedettség ! Kölcsönös hívás lefedettség ! Kontextus függ! mértékek (a hagyományos metrikák spec. változatai) Öröklési kontextus lefedettség ! Állapot kontextus lefedettség (állapot alapú tesztelésnél) !
Metrikák gy"jtése, m"szerezés ! Csomagoló !
37
osztályok
(illeszt! tervezési minta)
38
Scenárió alapú tesztelés ! Use
case-k használata
Követelmény meghatározás ! Interakciós hibák felderítése !
! OO
hatás
szoftver struktúra (mély szerkezet) ! interfész (UI) struktúra (felületi szerkezet) !
39
Felületi struktúra ! Direkt
manipuláció ! Független objektumokban elosztott funkcionalitás ! Task alapú megközelítés
40
Mély szerkezet ! Szoftver
szerkezetének megértése m"ködés közben !
Class diagramok ! !
!
örökl!dés kapcsolatok
Objektum diagramok, interakciós diagramok, use case maps !
m"ködés közbeni kapcsolatok
41
Tesztelési tervezési minták ! Név ! Cél ! Kontextus ! Hibamodell
hiba elérése ! hiba kiváltása ! hiba terjesztése !
! Stratégia !
algoritmus, technika, heurisztika
