Szoftverarchitektúra - implementáció tervezése -
Architektúra • Architektúra: – strukturálisan fontos elemek és ezek kapcsolata.
1
Architektúra központú • A rendszer architektúrája – (egy adott pillanatban) a rendszer alapvető komponenseinek szerveződése, melyek egymással meghatározott felületeken keresztül kommunikálnak, és hierarchikus szervezésű, egyre finomabb, egymással szintén megfelelő, alacsonyabb szintű felületeken keresztül kommunikáló komponensekből épülnek fel.
Architektúra - nézet • Egy architektúrát több nézet szerint lehet leírni. • A különböző módszertanok különböző nézeteket javasolnak: – Statikus nézet: rendszert alkotó elemek, kapcsolatok. – Dinamikus nézet: a rendszer időbelisége. – Funkcionális nézet: a rendszer funkcionalitása, a rendszer milyen adatokat milyen algoritmusok alapján generál.
2
Architektúra az alkalmazás jellege alapján • Az objektumok csoportosítása az MVC koordináta rendszer alapján – Model-View-Control – Smalltalk vezette be – Sztereotípus – Minden jól tervezett objektum valamelyik koordináta fele húz.
MVC koordináta rendszer • Koordináták: – Határ, – Entitás, – Control objektumok.
• Ez a gondolatmenet általánosítható alkalmazásokra, egy-egy alkalmazás olyan mint egy nagy objektum.
3
MVC koordináta rendszer • Határ: – Felület dominenciájú alkalmazások: • Jellegzetes desktop alkalmazások, szövegszerkesztők, vizuális felhasználói környezetek stb.
• Entitás: – Klasszikus információrendszerek – Fő feladatuk az adatkezelés
• Control – Algoritmus dominenciájú alkalmazások – Tudományos, műszaki számításokat végző alkalmazások – Az architektúrát az algoritmusok befolyásolják – Ritka a gyakorlatban.
Mi a szoftverarchitektúra? • A rendszert felépítő alrendszerek (szoftver komponensek) kerete – alrendszerek meghatározása – alrendszerek tulajdonságai – Vezérlési, valamint kommunikációs kapcsolataik
4
Mi még a szoftverarchitektúra? • Magasszintű terv • A rendszer átfogó struktúrája – több nézet -> több struktúra
• Komponensek és összekötők összesége
Architektúra központú • Architektúrális komponensek: – A rendszer alapvető működését meghatározó szoftver részek, rendszerszervezési megoldások.
• A fejlesztés fázisaiban központi szerepet kap a robosztus architektúra: – Robosztus = rugalmas, jól tűri a változásokat
• Az architektúra megalapozása az elsődleges feladat, hiszen ha itt hibázunk, az nagyon sokba kerül.
5
A SW architektúra szerepe • Az érdekelt szereplők kommunikációjának lehetővé tétele. • A korai fejlesztási fázisok döntéseinek támogatása a követelmények tükrében. • Nagyléptékű újrafelhasználhatóság elősegítése.
A SW architektúra célja • Az architektúra célja: – átláthatóvá teszi a fejlesztést, – könnyebben felismerhetők az újrafelhasználható elemek, – átlátható projekt menedzsment, – kockázatok csökkentése, – lehetővé válik a párhuzamos fejlesztés.
6
A SW architektúrák forrása • Üzleti és technológiai döntések eredménye • Meghatározó a környezet szerepe • A fejlesztők céljai és stratégiája által befolyásolt követelmények vezetnek különféle szoftver architektúrákhoz
Az architektúra ciklus • Az architektúra meghatározó a fejlesztő szervezet szerkezetére • Az architektúra befolyásolja a fejlesztő szervezet céljait • Az architektúra hatással van a követelményekre • A fejlesztés során a fejlesztők tapasztalatokat szereznek architektúráról • Bizonyos rendszerek hatással vannak a fejlesztési kultúrára
7
Az architektúra ciklus
Fejlesztõ szervezet
Követelmények Architektúra Technológiai követelmények Tervezõ/fejlesztõ A rendszer szereplõi
Rendszer A tervezõ tapasztalata
Mitől jó egy architektúra? • Kis számú vezető tervező • Jól definiált funkcionális követelmények és minőségi jellemzők • Jól dokumentált az architektúra • Az architektúra értékelésében az összes érintett szereplő részt vesz • Kvantitatív minőségi mértékek • Inkrementális architektúra implementáció • Kevés erőforrás versenyhelyzet a fejlesztés során
8
Architektúra elemek • Architektúrális minta – típus elemek és kapcsolatok, kényszerek – pl. kliens-szerver minta
• Referencia modell – standard funkcionális felosztás és adatfolyam megoldások – pl. adatbázis kezelő rendszer
• Referencia architektúra – referencia modell leképezése szoftver elemekre – pl. ISO OSI architektúra
Az architektúra rétegei • A rendszer különböző szinten elhelyezkedő elemei rétegekbe sorolhatók.
9
Rétegzett architektúra • Általánosan használt modell • Mit jelent a rétegzettség: – Fizikai rétegek (tier): az egyes rétegek különböző futtatható állományokban vannak, ezek a futtatható állományok különböző gépeken helyezkednek el, az egyes futtatható elemek hálózati protokollon keresztül beszélgetnek – Logikai rétegek (layer): a forráskód belső tagozódása.
• Egyirányú a logikai függés: a fizikai rétegzettség feltételezi a logikait, de fordítva nem!
Javasolt rétegek • Rendszerszoftver réteg. • Közép réteg (elosztott komponensek: EJB, CORBA, DCOM). • Általános alkalmazási réteg. • Felhasználó specifikus alkalmazási réteg (user interfészek). • RUP által javasolt.
10
Szokásos logikai rétegek • • • •
Kezelői felület Alkalmazás logika Adatbázis logika Frameworks, middleware, rendszer szoftver – Minden, ami kiszolgál.
Szokásos logikai rétegek • Kezelői felület – Csak a megjelenés.
• Alkalmazás logika – Az alkalmazásra jellemző elemek.
11
Szokásos logikai rétegek • Adatbázis logika – Egész szervezetre, egész adatbázisra jellemző, nem alkalmazás függő. Általában egy adatbázison több, különböző célú alkalmazás is dolgozhat (Számlázó-, Megrendelés kezelő-, Raktárkészlet kezelő alkalmazás), amik részben vagy egészében ugyan azokat az adatokat használják és az adatok között vannak olyan összefüggések, amik függetlenek a feldolgozás céljától.
• Frameworks, middleware, rendszer szoftver – Minden, ami kiszolgál.
Együttműködés • Kliens-szerver architektúra.
12
Néhány elterjedt architektúrális modell • Osztott adatokra épített architektúra – CASE eszközök
• Kliens-szerver architektúra – hálózati, kommunikációs szoftverek
• Réteg szerkezet architektúra – protokoll referencia modellek
• Funkcionális csőrendszerek • Eseményvezérelt rendszerek
Osztott adatok • Az alrendszerek adatokat cserélnek – központi adatbázis – saját adatbázisok, explicit adatcsere
• Közös adatigényű alkalmazások
13
Osztott adatok • Előnyök – nagy mennyiség" adat hatékonymegosztása – központi adat kezelés lehetősége
• Hátrányok – minden részrendszerben azonos adatszervezés – elosztottság nehézkes
Osztott adatok • Integrált CASE eszköz
14
Réteg szerkezet modell • Speciális alrendszer elrendezés • Rétegekbe szervezett modulok, szolgáltatások • Jól definiált interfészek • Inkrementálisan, egymástól elkülönülten fejleszthető rétegek • Mesterségesen kialakított rétegek
Az OSI modell 7 rétege • • • • • • •
fizikai réteg adatkapcsolati réteg hálózati réteg szállítási réteg viszony réteg megjelenítési réteg alkalmazási rétegek
15
A hoszt Alkalmazási Megjelenítési
Viszony Szállítási Hálózati Adatkapcsolati
Fizikai
B hoszt Alkalmazási protokoll
Megjelenítési protokoll
Viszony protokoll
Szállítási protokoll
Hálózati protokoll
Adatkapcsolati protokoll
Alkalmazási Megjelenítési
Viszony Szállítási Hálózati Adatkapcsolati
Fizikai protokoll
Fizikai
Eseményvezérelt rendszerek • A rendszer vezérlésén kívülről érkező események határozzák meg a viselkedést – Pl. Ha a vállalat eseményvezérelten működik, a felhasználói rendelések közvetlenül meghatározzák a legyártandó termékek számát (a rendelés beérkezése "kiváltja" a gyártás indítását).
• Eseményvezérelt modell – broadcast modell
16
Broadcast modell • Elosztott alrendszerek integrálása • Az alrendszerek “előfizetnek” az őket érdeklő eseményekre az eseménykezelőnél • Események időbeli bekövetkezte ismeretlen
A programtervezés jelentősége
a végzendő feladatok mennyisége
karbantartás tesztelés programtervezés kódolás
karbantartás tesztelés kódolás tervezés
Megvalósítás tervezés nélkül
Megvalósítás tervezéssel
17
A programtervezési módszerek sajátosságai • cél az információs domének tervezési reprezentációvá alakítása • megoldás szimbólumkészlettel, amely a komponensek, azok viszonyának és az algoritmusnak a leírására szolgál • ajánlás az eljárások finomításának és komponensre bontásának végrehajtására • szempontokat ad a szoftverminőség biztosításához
A Warnier-féle strukturált programtervezési lépések • • • •
adatszerkezetek tervezése a programszerkezet kialakítása funkcionális leírás tevékenységek programstruktúrákhoz rendelése
18
A Lorensen-féle OO programtervezés lépései • az alrendszerek adatigényét kielégítő osztályabsztrakciók meghatározása • az absztrakciós osztályok jellemzőinek specifikálása • az osztályok műveleteinek meghatározása • objektumok közötti kommunikáció módjának (üzenetek) specifikációja • felhasználói igények leírása scenárióval • öröklődés vizsgálata
A programtervezés feladatai A programtervezés a korábbi fázisokban kialakított modellek (adat- illetve objektum-modell, funkcionális modell és a rendszer viselkedését leíró dinamikus modell) alapján történik. A programspecifikációt lépései: – adat-tervezés: az adatstruktúrák és ábrázolási módok specifikálása – architektúra tervezés: a programrendszer egyes komponenseinek, azok egymáshoz való viszonyának meghatározása – folyamatok (procedures) tervezése a szerkezeti komponensek működési folyamatokhoz illesztésének specifikációja
19
Az implementációs fázis szakaszai
Dinamikus Adat/objektummodell modell adatok tervezése Funkcionális modell
Programtervezés procedurális
Egyéb elvárások, körülmények
tervezés Kódolás Programmodulok architektúra-terv Tesztelés
tesztelt szoftver-rendszer (integrációs és validitási ellenõrzés)
Tervezési alapelvek • absztrakció • lépésenkénti finomítás • modularitás, komponens szemlélet • szoftver-architektúra • vezérlési hierarchia • adatstruktúra és adatfolyam • szoftverfolyamatok • komponens architektúra • információelrejtés
20
Modularitás • modul, komponens értelmezése beépülési, aktivitási jellemző, vezérlési mód típusok: compile time~, corutin~, conrutin~ definíció: a modul, a komponens a programrendszer legkisebb, önállóan is működőképes, cserélhető, újrafelhasználható egysége, amely interfészeken keresztül csatlakozik a környezetéhez
• funkcionális függetlenség kohézió (binding), csatolás (link, coupling)
Architektúra adatfolyamdiagram Cél: 0.szint
A
az architektúra-komponensek közötti adat- és vezérlési információk áramlásának, az üzenettovábbítási folyamatoknak a szemléltetése
B 1.szint
21
Objektumorientált fejlesztőkörnyezet komponensdiagram Alkalmazások, kliens oldal
Fejlesztõrendszer
user interface (felhasználói felület komponens)
TCP/IPv6 protokoll
CASEeszközök, alkalmazásgenerátorok
Rendszer szerver
Projectmanagement
repositorydomain (fejlesztési adatbázis)
object database (objektum adatbázis) rendszerszolgáltatások
A programtervezés feladatai • adat- és objektumtervezés • architektúra tervezés bemeneti, kimeneti információk, működési, vezérlési funkciók, tesztelési feladatok
• • • •
folyamat-terv készítése működési algoritmus fejlesztőkörnyezet kiválasztása kódolás
22
A program-architektúra tervezés feladatai • a rendszer bemeneti információinak meghatározása • felhasználói interfészek tervezése • a rendszer működését vezérlő funkciók terve: menüszerkezet • architektúra kontextus diagram: információ forrása,típusa, kommunikációs útvonal • szolgáltatások, outputok specifikációja • karbantartási, diagnosztikai és tesztelési tervek
A működési algoritmus tervezése • folyamatábra • Warnier-Orr diagram • Jackson ábra avagy struktúra diagram • Nassi-Shneidermann avagy Chapin-Chart ábra • komponensdiagram • vezérlési struktúradiagram lásd szemléletesen:
23
Folyamatábraszimbólumok
Folyamatábraáltalános adat szimbólum készítés kapcsolódási pont start/stop
START
manuális mûvelet
forrás-dokumentumvagy nyomtatott output on-lineinput
funkció, mûvelet szalagállomány
elõkészítõfunkció
Input a,b Folyamatábraminta
c= 2a+ 5b d= 7ab-4b/a c= d?
igen
x= 5b-3d
nem
lemezállomány rutinmûvelet , könyvtárprogram
x= 4a+ 7c
x= d+ a?
igen
kiír a,b,x
nem
logikai döntés, elágaztatás on-lineoutput
END
mûveletek sorrendje adatkommunikáció
Műveleti struktúrák folyamatábrával Mûveletek szekvenciája
utasítás
utasítás
Aszelekció logikai struktúrája
IF... fe ltéte l nem ELSEág
igen THENág
Iteratívmûveletek ciklikus szerkezetei hátultesztelõ elõltesztelõ
ciklusutasítások DOUNTIL felltétel nem
ciklusutasítások DOWHILE felltétel igen
igen
nem
DOUNTIL
DOWHILE
24
JACKPR
a= 1?
o
*
end: k= 50
a«0?
o
o a= 9999?
o a= 1000?
o különben
k= 25
k= k*2
k= k+ 1
vege
Jackson-féle struktúradiagram
a= a*k+ 1
Chapin-Chart szerkezetek
Szekvencia
IFTHEN... ELSE... szelekció
1. feladat
feltétel hamis igaz
2. feladat 3. feladat
ELSE THEN ág ág
Iterációszemléltetése ciklus feltétel DOWHILE ciklusmag
REPEAT UNTIL ciklusmag ciklus feltétel
CASEszelekció CASEfeltételek érték érték ...... utas. utas. ......
25
Vezérlési struktúradiagram case
döntés (if ... then... else...) S;
S; caseDis whenC1= > S; S;
if Cthen sorrendiség else
S; S; S;
S; S; S; S; S; endif
whenC2 = > S; S; endcase
S;
whileciklus S; whileC; S; S; S; end C; S;
S;
Komponens architektúra "A" modul
"A1" modul
"A2" modul
"A31" modul
"A3" modul
"A32" modul
26
Kódolás „A számítógépes program készítése a végrehajtandó utasítások meghatározott sorrendben írását jelenti a rendelkezésre álló nyelven. Az a mód azonban, ahogyan a programozó a nyelvi lehetőségeket használja a program intelligenciájának mértéke…” Kernighan, 1978.
Tesztelés
27
A tesztelés szükségessége, jelentősége Bevezetés,üzemeltetés, karbantartás, minőségbiztosítás Tesztelés Célkitűzés, kiértékelése problémadefiniálás Elfogadási, rendszer- és terhelési teszt
Elemzés, követelményspecifikáció
M odul-és integrációsteszt
Inkrementális tervezés
M egvalósítás
Tesztelés célja • Helytelen szemlélet: – a szoftver hibamentességének bizonyítása, ill. a specifikált tulajdonságok megvalósításának bizonyítása.
• Helyes felfogás: – a szoftvertesztelés a fejlesztett szoftver végrehajtása azzal a céllal, hogy a benne levő hibákat, ill. a specifikációtól eltérő viselkedését felderítsük.
28
Szoftverrendszerek tesztelése • A szoftver fejlesztés célja: – a specifikációban leírt követelményeket kielégítő szoftver készítése. – Fejlesztés során különböző ellenőrző, elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet: • Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk. • Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk.
V & V: verifikáció és validáció • A verifikáció: – azt vizsgáljuk, hogy a fejlesztés során egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak. – A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék).
29
V & V: verifikáció és validáció • A validáció: – általánosabb folyamat, – Azt vizsgáljuk, hogy az elkészített termék megfelel-e a megrendelő elvárásainak. – A validáció tehát magában foglalja a specifikáció ellenőrzését is.
V & V: verifikáció és validáció • A verifikáció, és a validáció végrehajtására használható technikák: – Szoftver átvizsgálás. – Szoftvertesztelés.
30
V & V: verifikáció és validáció • Szoftver átvizsgálás: – A fejlesztés során előállított termékek (modellek, kód, stb.) statikus elemzése, ami lehet manuális vagy automatizált. – Manuális vizsgálatra példa a kód-review különböző formái, automatizált vizsgálatra példa a UNIX rendszerekben használt lint (splint) eszköz, mely C programokat elemez és felhívja a fejlesztő figyelmét a potenciálisan hibás, vagy hibát eredményező kódrészletekre.
V & V: verifikáció és validáció • Szoftvertesztelés: – Az implementált szoftver futtatása tesztadatokkal, annak kimeneteinek, viselkedésének, ill. teljesítményének megfigyelése, összevetése a követelményekkel, azzal a céllal, hogy a benne levő hibákat felderítsük. – Ezt nevezzük dinamikus elemzésnek, ill. dinamikus verifikációnak.
31
Statikus és dinamikus verifikáció alkalmazása szoftverfejlesztés során Követelmények 1. Analízis & Tervezés
Rendszer terv (pl. UML diagrammok)
2. Terv verifikációja statikus verifikáció (review) Verifikált rendszer terv (pl. UML diagrammok) 3. Implementáció
Implementált rendszer (pl. C++ code)
4. Tesztelés dinamikus verifikáció (szoftvertesztelés) Tesztelt rendszer
Szoftvertesztelés alapsémája • A tesztelés lényege összehasonlítás: – A tesztelt szoftver (software under test, SUT) kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával. – Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést. • Származhat az információ a specifikációból nyert adatokból, • prototípus szoftver leírásából/megfigyeléséből, vagy • a fejlesztés során előállított, rendszer viselkedését leíró modellből.
32
Szoftvertesztelés alapsémája
Referencia (követelmény specifikáció, prototípus, rendszermodell stb.)
bemeneti sorozat
viselkedés, állapot megfigyelése
Tesztelt szoftver software under test, SUT
referencia kimenet
Értékelés (viselkedés, kimenetek összehasonlítása)
eredmény
SUT kimenet
Szoftvertesztelés típusai • Két típus az alapján, hogy mi a tesztelés célja: – Hiányosság és hiba tesztelés: A tesztelés célja a fejlesztés során bekerült specifikációtól eltérő, vagy nem megvalósított működés kiszűrése. – Statisztikai tesztelés: A program teljesítményének, megbízhatóságának vizsgálata általában valós bemenetek felhasználásával.
33
Tesztelés folyamata • A szoftver tesztelése különböző lépésekre bontható. • A szoftverfejlesztés korai szakasza, teszt tervezése: – definiáljuk, milyen módszerekkel és milyen lépésekben végezzük a szoftver tesztelését.
• A tesztelés következő lépése a tesztesetek definiálása. – Tesztesetnek nevezzük egy adott hiba felderítésére szolgáló tesztet. – A teszteset definíciója tartalmazza: • a tesztelés során használandó bemeneteket, • a tesztelt szoftver teszteset végrehajtásához szükséges állapotának leírását (esetlegesen az állapot beállítás módját), • a helyes működés során keletkező referencia kimeneteket, ill. • a teszteset hibamentes végrehajtása során történő viselkedésének (pl. bejárt állapotok) leírását.
Tesztelés folyamata – Ha egy teszteset alkalmas arra, hogy annak végrehajtásával egy adott hiba meglétét, ill. hiányát felderítsük, akkor azt mondjuk, hogy az adott teszteset (ill. az adott teszt) a kérdéses hibát lefedi. Ennek megfelelően beszélünk tesztesetek (tesztek), ill. teszteset halmazok (teszthalmazok) hibafedéséről. – Tesztgenerálásnak azt a folyamatot nevezzük, mely során a teszteseteket előállítjuk, definiáljuk. A tesztgenerálás célja a minél nagyobb hibafedésű teszthalmaz előállítása.
34
Tesztelés folyamata • A tesztesetek definiálása és szoftver implementálása után történik: – a tesztesetek végrehajtása, – az eredmények értékelése, elemzése, mely a tesztelés utolsó fázisa.
• A szoftverben feltételezhetően előfordulható hibák leírását nevezzük hibamodellnek.
SW hibamodell • Hibák: – specifikációs hibák, – tervezési hibák, – kódolási hibák...
• Általános probléma: – Nem lehet olyan leírását adni a hibáknak, ami általánosan használható. – Nehéz a tesztelés hatékonyságát mérni.
35
Tesztelési megközelítések • A tesztelés során a tesztelt rendszert különböző módon lehet kezelni, mely alapvetően más, és más módszereket fog eredményezni a tesztesetek előállítására. Két alapvető megközelítés létezik: – Funkcionális tesztelés – Strukturális tesztelés
Funkcionális tesztelés • A tesztelő nem veszi figyelembe a tesztelt szoftver belső felépítését. Kizárólag a rendszer specifikációja alapján végzi a tesztelést. • Az ilyen szemléletben történő tesztelést szokták még specifikáció alapján történő tesztelésnek is hívni. • Mivel a tesztek tervezése, ill. végrehajtása során a tesztelés alatt álló szoftver belsejébe nem látunk bele, szokásos az ilyen technikákat fekete doboz (black box) tesztelésnek is nevezni.
36
Strukturális tesztelés • A funkcionális tesztelés ellentéte. • A tesztelés a szoftver a specifikációban megadott funkciót megvalósító program szerkezete alapján történik. • Mivel a tesztelő „belelát” a szoftver belső működésébe szokásos az ilyen technikákat fehér doboz (white box) tesztelésnek is nevezni. • Strukturális tesztelés esetén a program vezérélési szerkezetét modellezzük és a tesztelő a vezérlési szerkezet minden ágát, a program különböző bemenetek esetén végrehajtódó részét végrehajtva vizsgálja annak működését.
Funkcionális tesztelési módszerek • Az ekvivalencia partícionálás – egy természetes tesztelési megközelítés formalizálása. – Abból indul ki, hogy minden hibához lehetőleg csak egy tesztesetet definiáljunk. Ennek érdekében a szoftver bemeneti adatainak minden kombinációját tartalmazó képzeletbeli halmazt olyan részekre (partíciókra) bontja, melyek mindegyike más és más hiba felderítésére alkalmas. – A bemenetek partícionálása után, a tesztesetek definiálásakor a tesztelő az egyes partíciókból egyet-egyet választ.
37
Funkcionális tesztelési módszerek • A határérték analízis: – az ekvivalencia partícionálás finomítása. – Míg az ekvivalencia partícionálás során minden ekvivalencia osztályból csak egy, az osztályt reprezentáló bemenetet választottunk, addig a határérték analízis definiálja, hogy melyik bemenetet (vagy bemeneteket) válasszuk az ekvivalencia osztályból. – Azt mondja, hogy ha két partíció határos, vagyis a bemenetek természetes sorrendjében „egymás után következő” bemeneteket tartalmaz, akkor ezeket a partíció határán levő értékeket célszerű a tesztesetekben használt bemenetnek választani. – Egy partícióból, ha több más partícióval határos, akár több bemenetet is használhatunk.
Strukturális tesztelés • A tesztelő nem állít fel explicit hibamodellt a felderítendő hibákról, kizárólag a hibamentes program működését, vezérlési szerkezetét modellezi a folyamat vezérlési gráf (Control Flow Graph - CFG) segítségével. • A strukturális tesztelés alapfeltételezése szerint a programban létrejövő hibák valamilyen módon befolyásolják a program vezérlési szerkezetét, mely a működést leíró folyamat vezérlési gráf gráfpontjainak, ill. éleinek hibás (nem megengedett) bejárását jelenti. • A használt hibamodell tehát egy folyamat vezérlési gráf alapján felállított implicit hibamodell.
38
Tesztelés menete ST esetén • Tesztgenerálás: – Teszt bemenetek generálása valamilyen mértékszám alapján.
• Teszt végrehajtás: – Program egy vezérlési ágának végrehajtása. – Eredmények összehasonlítása a specifikációban rögzítettel.
Strukturális tesztelés előnyei • Hibák keresése anélkül, hogy tudnám, milyen hibákat is keresek konkrétan. • Matematikai modell: tesztelés hatékonyságának számszerű mérése. ST felhasználási területei: – Vezérlés intenzív alkalmazások. – Tervezési hibák felderítése. – Elérhetetlen (dead) kódrészek felderítése.
39
Strukturális tesztelés módszerei • Vezérlési szerkezet modellezése • Programok vezérlési bonyolultsága • Egyszerű strukturális tesztgenerálás
Vezérlési szerkezet modellezése • Folyamat vezérlési gráf (FVG) Control Flow Graph (CFG) • Gráf pontok: utasítások + végpont. • Egymás után végrehajtott utasításokat gráf él köti össze. • Utasítások típusa: – Szekvenciális utasítás. – Elágazás utasítás (predicate statement).
40
CFG • A CFG egy gráf modell. • A gráf pontok az utasításoknak feleltethetők meg. Az utasításokat reprezentáló gráf pontokon kívül a program kezdetét, belépési pontját és végét, kilépési pontját is egy-egy gráf pont reprezentálja. • A gráf származtatása igen egyszerű, az egymás után végrehajtható utasításokat egy-egy irányított gráf él köti össze.
CFG • A gráf-pontok két típusa: – Egyszerű (szekvenciális) gráf pont, amelyből egyetlen gráf él indul ki, és egy szekvenciális utasítást reprezentál. – Elágazás gráf pont, amelyből egynél több gráf él indul ki, és egy elágazás utasítás (predicate statement) feleltethető meg neki.
• A CFG esetén az egyszerűbb kezelhetőség miatt általában a kimenő élek számát kettőben szokták limitálni. • Az elágazás utasításban mindig szerepel egy feltétel, mely meghatározza, hogy az utasítás végrehajtásakor melyik következő utasítás hajtódik végre.
41
CFG START
1
2 3 4 5 6 7 END
Programok vezérlési bonyolultsága • A programok vezérlési szerkezetének bonyolultsága igen eltérő lehet. • A programok vezérlési szerkezetének bonyolultságát jellemző mérőszám, az ún. ciklomatikus komplexitás (CK, Cyclometric complexity).
42
Programok vezérlési bonyolultsága • Ciklonometrikus komplexitás (CK) (Cyclonometric complexity) • Független út: Olyan gráf út, amelyben létezik olyan pont v. él, amely más útnak nem eleme. • Ciklonometrikus komplexitás definíciója: A FVG-ben található független gráf utak maximális száma.
CK számítása • Jelölés: G: gráf; V(G): CK ; E: élek száma; N: pontok száma; P: elágazás utasítások száma. • V(G)= E-N+2 • V(G)=P+1 (bináris elágazások esetén)
43
CK számítási példa begin
E=11 N=9 V(G)=E-N+2=11-9+2=4
1
2 3
P=3 V(G)=P+1=3+1=4
4 5 6 7 end
Egyszerű strukturális tesztgenerálási algoritmus • • •
•
CFG generálása a kód alapján. CK számítása az CFG alapján. Független utak maximális (CK darab utat tartalmazó) halmazának generálása. Bemenetek generálása a független utak bejárásához.
44
Problémák tesztgenerálás során • AZ CFG: – ciklikus, vagyis kört tartalmaz, így elvben a végtelen sok út generálható az adott CFG-hoz.
• Nem generálható olyan bemeneti kombináció, amely egy adott út bejárását eredményezné az CFGben.
Teszt hatékonyságának mérése • A strukturális tesztelés alaposságának jellemzésére mértékszámokat lehet használni. • A mértékszám egy arányszám: – megmutatja, hogy a kiválasztott szempont szerint a tesztelhető elemek (egységek, tételek) mekkora részét teszteltük le, – a korábban bevezetett terminológiát használva a feltételezett hibák mekkora részét fedtük le.
45
Mértékszámok • Utasítás lefedettség: Az utasítások mekkora hányadát hajtottuk végre teszteléskor. • Ág lefedettség (döntés lefedettség): A CFG ágainak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. • Út lefedettség: A CFG-ban található utaknak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor.
SW tesztelés végrehajtása • SW tesztelését több fázisban hajtják végre. – Első fázis a modul tesztelés (unit testing). – Integrációs tesztelés. – Rendszerteszt.
• Míg az első két fázis tipikusan verifikáció, addig a rendszertesztet általában validálására használják.
46
Modul tesztelés • Unit testing. • A fázisban csak az egyes modulok specifikációját veszik alapul. • Különösen munkaigényes és emiatt költséges fejlesztési fázis.
Modul tesztelés • A szoftvermodulok: – önálló specifikációval rendelkező, – más moduloktól függetlenül fordítható szoftver egységek. – Strukturált program esetén ezek lehetnek eljárások, függvények, ill. azok csoportja, – objektumorientált környezetben objektumok, ill. azok halmaza (clustere).
47
Modul tesztelés • A modulok a kész rendszerben használják egymás szolgáltatásait, – pl. az egyik modul meghívja a másik modul adott függvényét. Ekkor azt mondjuk, hogy az egyik modul függ a másik modultól. – Modulok függősége grafikusan is ábrázolható.
Modulok függősége • A modul például függ a B a C és D moduloktól. A
B
H
C
D
E
F
I
J
G
48
Modulok függősége • A tesztelő elkészíti azon modulok biztosan hibamentesen (a specifikációban leírt módon) viselkedő egyszerűsített változatát, melyektől a tesztelt modul (SUT) függ. • A szoftver modulok ilyen egyszerűsített megvalósítását nevezik stub-nak (csonknak).
Teszt driver • A modulok tesztelése csak úgy történhet, ha azokat működtetjük, azok szolgáltatásait meghívjuk. – Ehhez létre kell hozni a megfelelő szoftver környezetet.
• Teszt driver-nek nevezzük azt a szoftver elemet, mely a tesztelés során a tesztelt szoftvert működteti.
49
Teszt driver • Feladata: – a tesztelt szoftver működtetése, annak bemeneti adatok biztosítása. – A szoftver driver általában megvalósítja a kimenetek eltárolását, ill. más, szoftver viselkedését jellemző információ összegyűjtését.
Teszt driver • A stub-ok, ill. teszt drive-ek készítése: – legmunkaigényesebb, így legköltségesebb része a tesztelésnek. – Ha egy szoftver minden modulját önállóan szeretném tesztelni, akkor minden elemnek el kell készítenem a stub változatát, ill. minden elemhez készítenem kell egy teszt driver-t.
• Az ilyen típusú tesztelés az izolációs tesztelés.
50
Izolációs tesztelés
teszt driver
B
H
C
D tesztelt modul
E stub
F stub
I
J
G stub
Tesztelési költségek csökkentése • A teszt driver-ek, ill. stub-ok készítése költséges. – Ezek készítését részben elkerülhetjük: • ha az amúgy is megvalósítandó szoftver moduljaimat használom driver-ként, ill. stub-ként. • Feltétlenül be kell tartanom a tesztelés azon szabályát, hogy tesztelés során a szoftvernek csak olyan komponensét használhatom (driver-ként vagy stub-ként), melynek helyes működése biztos, vagyis már átesett a tesztelésen.
• Két alap technika létezik, a többi lényegében ezek finomítása: – top down tesztelés és – bottom up tesztelés.
51
Top-down tesztelés • A teszt driver-ek készítése kerülhető el. • Teszt driver-ként mindig azokat a modulokat használom, melyek az adott tesztelés alatt álló modulomtól függenek. • Először mindig a hierarchia legmagasabb szintjén álló modulomat kell tesztelni, majd sorban az alatta levő modulokat.
Top-down tesztelés A driver (tesztelve)
B (tesztelve)
C (tesztelve)
E stub
H
I
D tesztelt modul
F stub
G stub
J
52
Bottom-up tesztelés • A teszt stub-ok készítése kerülhető el. • Stub-ként mindig azokat a modulokat használom, melyektől az adott tesztelés alatt álló modulom függ. • A tesztelést a függőségi hierarchia legalsó szintjén kell elkezdeni azokkal a modulokkal, melyek nem függenek más moduloktól. Ezeket letesztelve léphetünk tovább a hierarchia következő szintjére.
Bottom-up tesztelés teszt driver
B
H (tesztelve)
C
D tesztelt modul
E (tesztelve)
F (tesztelve)
I (tesztelve)
J (tesztelve)
G (tesztelve)
53
Tesztesetek definiálása • Teszteset azonosító: – a fejlesztési folyamat teljes menete során ezzel hivatkozhatunk a tesztesetre. – Fontos, hogy tényleg ne változzon. – Hibajelentések készítésekor, ill. teszt riportok összeállításakor látjuk hasznát. Regressziós tesztelésnél különösen hasznos.
• A tesztelt szoftver elem azonosítása, ill. a tesztelt funkció, viselkedés azonosítása, leírása. • A tesztelt szoftver (SUT) teszteset végrehajtása előtt beállítandó állapotának leírása, szükség szerint a beállítás módja.
Tesztesetek definiálása • Teszteset végrehajtásához szükséges bemeneti adatok. • Elvárt eredmény: hibamentes esetben várt kimenet, állapot, esetleg teljesítmény. • Teszteset végrehajtásának előfeltételei: – mely tesztesetet kell hibamentesen végrehajtani, ill. – mely teszteset által tesztelt funkcióra épül az aktuális teszteset.
• A tesztelésnél alkalmazott szabványok előírhatnak további jellemzők megadását, pl. a teszteset definiálásakor alkalmazott tesztelési módszert.
54
Integrációs tesztelés • A rendszer moduljait együtt tesztelik – nagy hangsúlyt fektetve a modulok együttműködésére, – interfészek vizsgálatára.
Rendszerteszt • A teljes rendszert valós adatokkal valós környezetben tesztelik.
55
Tesztadatok összeállításának szempontjai • adatok körének meghatározása: – napi adatok – szélsőséges adatok – tesztelési szintekhez eltérő adatok
• tesztállományok összeállítása • elvárt eredmények meghatározása
Tesztelés alapjai (terminológia) • teszt driver: – tesztelő rutin
• teszt csonk (stub): – Tesztelt egység által használt más egység működését szimuláló rutin.
• teszt eset: egy adott hiba felderítésére szolgáló teszt
56
A programspecifikáció tartalma 1. 1. a programrendszer célja
– rendszercélok – HW, SW környezet specifikációuser interface tervek – menü- és struktúra tervek – adatbázis (külsőleg definiált) – tervezési feltételek
2. Hivatkozott dokumentumok – szoftver dokumentáció – rendszerleírás – HW/SW szállítói információk – technikai referenciák
A programspecifikáció tartalma 2. 3. Tervezési specifikáció
– adatleírás (típus, struktúra) – származtatott programstruktúra – struktúrán belüli interfészek
4. Modulonkénti részletes specifikáció – feldolgozási eljárások – működési algoritmus leírása – interfészspecifikáció (input, output) – tervezési technológia – felhasználandó modulok, hívás módja – adatok köre és szervezési módja
57
A programspecifikáció tartalma 3.
5. File-szerkezetek, globális modell specifikáció
– külső file-szerkezet: file-ok, rekordok, szervezési és elérési mód – globális adatok jegyzéke – file/adat kapcsolatok
6. Folyamatok-modulok kapcsolatrendszere 7. Tesztelési előírások, dokumentáció – tesztadatok, tesztelési utasítás – tesztelési stratégia, integrációs teszt – különleges előírások
8. Programegységek létrehozása (package) – speciális átlapolás – átalakítási feltételek
Átállás • • • •
Kísérleti futtatás Fokozatos átállás Párhuzamos feldolgozás Azonnali átállás
58
Átadás • Az átadás programja, forgatókönyv – Átadási információk – Az átadás programja – Különleges rendelkezések
Átadási információk • • • • •
Az átadás tárgya Az átadás időpontja Az átadás helye Résztvevők Az átadási anyagok – HW, SW dokumentáció, kézikönyvek
• Elfogadási feltételek, átvételi kritériumok
59
Az átadás programja • Bevezető tájékoztató • A rendszer bemutatása, elfogadási teszt (projektvezető és a megbízó) • Az elfogadási teszt kiértékelése (megbízó) • Döntés az elfogadásról • Jegyzőkönyv készítése
60
