szoftver-min sÉgbiztosÍtÁs széchenyi istván egyetem ...heckenas/okt/swmin5.pdf ·...
TRANSCRIPT
-
1
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
OO rendszerek jellemzői� Problémák forrása lehet teszteléskor:
� Problémák feldarabolása.� Adatrejtés.
� Az OO rendszerek nagyszámú, egymással aktívan kapcsolatban levő, együttműködő komponensekből állnak.
� A OO programozás másik jellemzője, a komponensek jól definiált interfészen történő elérése, és ezzel párhuzamosan a nem publikus adatok és funkciók elrejtése.
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
-
2
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
OO rendszerek jellemzői� A problémák további forrásai
lehetnek nyelvi sajátságok:�C++-ban használatos virtuális
függvények� Az ilyen kódba rejtett, implicit elágazások
kezelése igen nehéz tesztelés során.
� A OO paradigmában széleskörűen használt polimorfizmus�egyazon kód használati környezettől
függő értelmezésése
-
3
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Lefedettségi analízis� OO kód esetén strukturális mértékszámok
közvetlen használata igen megtévesztő lehet.� Környezettől függő lefedettség
� Kidoloztak az OO rendszerek tesztelésének alaposságának jellmzésérealkalmas egyedi mértékszámokat, valamint a strukturális teszteléskor használt mértékszámok OO rendszerekben használható változatát.
-
4
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Tesztelés nem OO rendszerekben
� A nem OO rendszerek tesztelésekor használt tipikus tesztkörnyezetek, módszerek� bemenetek biztosítása a tesztelt szoftver
(SUT) számára, � SUT működtetése, � kimenetek, esetleges belső változók
megfigyelése.� A leggyakrabban használt tesztelési
módszer az – elsősorban modulteszteléskor használt – izolációs tesztelés.
-
5
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Az izolációs tesztelés előnye� A szoftver komponensei egyenként is
tesztelhetőek, adott esetben még a többi rész elkészülte előtt.
� Tesztelhető először a komponensek belső működése, majd ezt követően az interfészek.
� A tesztkörnyezet egy adott szoftver egymást követő verzióiban újrahasználható.
� A tesztelés megfelelő teszt környezet esetén jól automatizálható.
-
6
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Hagyományos tesztelés OO környezetben
� Izolációs tesztelés� Az izolációs tesztelés alkalmazásakor a
legnagyobb gondot a környezet kialakítésajelenti.
� Problémát jelent a teszt környezet (csonkok) újrafelhasználása is.
� Az izolációs technikát ezért általában nem gyakran használják OO rendszerek tesztelésekor. Ezzel szemben a bottom-uptesztelést, mely sok vonatkozásban hasonló az izolációs technikához, annál többször.
-
7
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Hagyományos tesztelés OO környezetben
� Bottom-up tesztelés� A tesztelő részekre osztja a SUT-t� Egyes önállóan tesztelt részeket azonban
rétegeknek nevezzük� A csak már tesztelt osztályra épülő osztályok
tesztelése addig tart, míg az egész szoftvert le nem teszteltük
� A problémát a körkörös hivatkozások jelentik� Ekkor vagy egyszerre teszteljük az összes, körben
szereplő osztályt, vagy az izolációs technikát használjuk, vagyis a hivatkozott osztályok egy részét a teszt környezet segítségével (csonkok formájában) implementáljuk.
-
8
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
OO rendszerek tesztelési technikái
� Tesztelhetőségre tervezés
� Wrapper osztályok használata
� Tesztelés állapot-átmenet diagramm alapján
-
9
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Tesztelhetőségre tervezés� A tesztelhetőség olyan általános
szempontokként fogalmazható meg mint: � Kerülni kell a nem feltétlenül szükséges
kapcsolatokat osztályok között.� Lehetőséget kell adni az adatok (belső
változók) megfigyelésére, beállítására. � Kerülni kell a virtuális függvények felesleges
használatát.
� A fenti kitételek sajnos nagyon általánosak, az OO programozás eszköztárát lényegesen korlátozzák.
-
10
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Absztrakt Bázis Osztályok� Ennek a tesztelhetőre tervezési
technikának a lényege, hogy az osztályok interfészét egy külön osztályban valósítják meg absztrakt (függvénytörzs nélküli virtuális) függvényekként. Ekkor ugyan a rendszerben levő osztályok száma megnő, azonban könnyebben lehet az egyes osztályokat egymástól elhatárolni, és alkalmazni az izolációs technikát.
-
11
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Wrapper osztályok használata� Az OO rendszerekben nehézséget okoz az
objektumokban használt rejtett adatok megfigyelése és beállítása� A nyelvek többsége (pl.: C++, Java)
lehetőséget ad azonban egyes osztályok közötti speciális viszony (friend) deklarálására, ami lényege, hogy a két osztály kódjából elérhetővé válik a másik osztály belső változói és függvényei.
-
12
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Wrapper osztályok használata� A tesztelő környezetben minden osztályhoz
létrehozhatunk egy wrapper osztályt, mely a deklarációk megfelelő megadásával elérheti a tesztelt osztály belső változóit.
� A wrapper osztályt a tesztelt osztállyal azonosinterfésszel hozzuk létre.
� A wrapper osztály adott függvény meghívásakor dokumentálja a meghívás tényét, a hívási paramétereket, majd meghívja a tesztelt osztály eredeti függvényét.
-
13
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Wrapper osztályok használata
private
public
Class A
private
public
Class B
függvény hívás
return
public
Wrapper Class B
Teszt
dokumentáció
-
14
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Tesztelés állapot-átmenet diagramm alapján
� Az objektumok működése jól modellezhető egy állapot automatával.
� A tesztelt szoftver rendszer reprezentációja a hozzá tartozó objektumokat leíró automaták halmaza lesz.
� Az egyes objektumokhoz tartozó automaták kapcsolatát, a teljes rendszer működését egy rendszer szintű állapot automatával írhatjuk le.
� Az egész rendszer így eseményvezérelten működik, a bemenetek hatása végig szalad az egész rendszeren.
-
15
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Tesztelés állapot-átmenet diagramm alapján
receptor emitter
külsô eseményválasz
szál
tesztelt rendszer határa
komponens osztályok állapot modelljei
-
16
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Mértékszámok használata� Elsősorban OO szoftverteszteléshez
definiált mértékszámok:� Belépési pont lefedettség - Entry point
coverage.� Kölcsönös hívás lefedettség - Call-pair
coverage.� Környezetfüggő mértékszámok:
� Öröklésfüggő lefedettség - Inheritance context coverage
� Állapotfüggő lefedettség - State based context coverage
� Szálfüggő lefedettség - Thread based context coverage
-
17
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Belépési pont fedettség � Azt mutatja meg, hogy egy adott
objektum publikus interfészében definiált függvények mekkora hányadát hívtuk meg a tesztelés folyamán.
� A mértékszám előnye, hogy alkalmas az esetlegesen nem megvalósított, így nem meghívható függvények felderítésére.
-
18
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Kölcsönös hívás lefedettség � Arányszám, ami megadja, hogy két
objektum között lehetséges függvényhívások mekkora hányada került ténylegesen meghívásra a teszt végrehajtása során.
� Ugyanazon függvény különböző kódrészletekből történő hívásait megkülönbözteti.
-
19
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Környezet függő mértékszámok
� A polimorfizmus miatt egy adott kódrészlet a program különböző helyeiről, különböző (program) környezetből hívható.
� A meghívott kód működése függhet a meghívási (aktivizálási) környezettől, így az alapos teszteléshez hozzátartozik az adott kódrészlet minden lehetséges környezetből történő meghívása, tesztelése.
-
20
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Öröklésfüggő döntés lefedettség
� A különböző elágazások bejárását objektum környezetenkéntmegkülönböztjük.
�Melyik leszármazottból történt a hívás?
-
21
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Állapotfüggő lefedettség � Olyan környezet függő mértékszám
csoport, ahol a hívási környezet figyelembevételekor nem csak a hívó objektum típusát, hanem annak aktuális állapotát is figyelembe vesszük.
� Ezeket a mértékszámokat az állapot-átmenet diagramm alapján történő tesztelés során használják.
-
22
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Szálfüggő lefedettség � Többszálú alkalmazások tesztelése
esetén lehet hasznos, amikor a mértékszám számításakor a hívó szál azonosítóját is figyelembe vesszük.
�A szálak azonos közös kódot hajtanak végre, tesztelési szempontból fontos, hogy egy adott kódrészlet melyik szál környezetében került végrehajtásra.
-
23
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Konkrét tesztelő rendszerek� Cantata++
� SGI Tester
� Aprobe
-
24
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Cantata++� IPL Ltd. Bath
� C++ szoftverek egység és integrációs tesztjeihez
� A teszt a tesztelendő forráskód, a tesztscript és a "Cantata++ Test Harness" fordításával ill. linkelésével keletkező futtatható program.
� A teszt scriptek C++ nyelven íródnak és tulajdonképpen egy main függvényből állnak, ami végrehajtja a tesztelendő szoftveregységet.
-
25
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Cantata++� "SM Tool„
�A forráskód beműszerezése, mely C++friend deklarációk és wrappingformájában jelentkezik.
�A csonkok (stub) írása a felhasználóra marad, de megadható, hogy teszteléskor az egyes meghívásokkor milyen visszatérési értékei legyenek a szimulált függvénynek.
-
26
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Cantata++� A teszt scriptekben ellenőrizhetők az
adatelemek értékei ill. ellenőrizhetők azok az adatterületek melyek értékeinek nem szabad változniuk a teszt futása alatt.
� A Cantata lehetővé teszi hogy mérjünk különböző végrehajtási időket.
� A beműszerezés ellátja a kódot teszt lefedettségi metrikák meghatározásához szükséges adatgyűjtő részekkel.
-
27
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Cantata++
-
28
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
SGI Tester� Silicon Graphic Inc.
� ProDev debugger-csomag dinamikus teszt lefedettség analízis eszköze
� A végrehajtható kód speciális beműszerezésére szolgál, teszt lefedettségi adatok gyűjtésére és lehetővé teszi ezen adatok grafikus felületen való elemzését.
� C, C++ és Fortran programokhoz használható� A rendszer script nyelve lehetővé teszi olyan
parancssor orientált programok automatizált tesztelését, melyek viselkedését indításukkor megszabhatjuk.
-
29
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
SGI Tester
-
30
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Aprobe (RootCause)� OC Systems Inc.
� Java, C
� Nem intruzív tesztelő, debuggoló és teljesítmény-optimalizáló rendszer.�műszerezési eljárás abban különbözik a
szokásos tesztelő környezetekétől, hogy a tesztelendő programot a forráskód újrafordítása és linkelése nélkül teszi alkalmassá a tesztelésre
� A próbák az eredeti végrehajtható kóddal mintpatchek egy "dynamic action linking" nevű eljárással kerülnek kapcsolatba.
-
31
Széchenyi István EgyetemOBJEKTUM-ORIENTÁLT SZOFTVER-TESZTELÉS
SZOFTVER-MINŐSÉGBIZTOSÍTÁS
Aprobe (RootCause)