A SZOFTVERTECHNOLÓGIA ALAPJAI

ASZOFTVERTECHNOLÓGIA

ALAPJAI

SzoftvertesztelésA szoftver becslése

12. előadásPPKE-ITK

PPKE-ITK Szoftvertechnológia-2011 13/ 2

Tartalom

1. A hiányosságok tesztelése1.1 A fekete doboz tesztelés1.2 Ekvivalencia-osztályozás1.3 Struktúrateszt1.4 Útvonal tesztelés

2. Integrációs tesztelés2.1 Az integrációs tesztelés stratégiái2.2 Interfésztesztelés2.3 Terhelési (stressz) tesztek

3. Objektumorientált tesztelés


A szoftvertesztelés

• A tesztelési folyamat alapelemei:– Komponens tesztelés:

• Az egyedi programkomponensek tesztelése.• Általában a komponens fejlesztőjének feladata (a kritikus

rendszerek kivételével).

– Integrációs tesztelés• Komponensek, majd modulok csoportjának tesztelése,

amelyek egy rendszert vagy alrendszert alkotnak.• Független tesztelő csoport feladata.• A tesztek a rendszer specifikációja alapján készülnek.


Funkció- és objektumorientált rendszerek tesztelése

• A funkcióorientált rendszereknél:– A rendszer alapvető program-egységei (függvények –

modulok) jól elkülöníthetők,– Ezek külön tesztelhetők.

• Az objektumorientált rendszerek esetén:– Az ilyen megkülönböztetés nem lehetséges, az objektumok

lehetnek egyszerű ( pl. lista), vagy komplex entitások (pl. egy alrendszer objektumai),

– Olykor nincs egyértelmű hierarchia az objektumok között, ezért az integrációs tesztek (fentről lefelé, vagy lentről felfelé) nem alkalmazhatók.


1. A hiányosságok tesztelése

• A cél: feltárni a rejtett hibákat a rendszerben.• A sikeres hiányosság teszt a rendszer helytelen

működését eredményezi (ellentétben a validációs teszttel, amely a rendszer helyes működését ellenőrzi).

• A hibák jelenlétét és nem azok hiányát mutatja ki.• Tesztadatok és tesztesetek:

– A tesztesetek a teszthez szükséges inputok és a várt outputok specifikációi,

– A tesztadatok a rendszer tesztelésére kidolgozott input adatok.


A tesztelés súlyponti kérdései

• Csak teljes körű tesztelés bizonyíthatná, hogy a rendszer hibamentes, de a teljes tesztelés lehetetlen.

• A funkcionális teszteknek a rendszer a képességeit kell vizsgálniuk, nem a komponenseket.

• A fejlesztés során a rendszer régi (korábban már letesztelt) képességeinek tesztelése sokszor fontosabb, mint az újonnan hozzáadott képességeké.

• A tipikus helyzetek tesztelése fontosabb, mint a határesetek tesztelése.


A hiányosságok tesztelésének folyamata

Teszt-esetek

Teszt-adatok

Teszt-eredmények

Teszt-jelentések

Teszt-esetek

tervezése

Teszt-adatok

készítése

Programfuttatása

tesztadatokkal

Eredményekösszevetése atesztesetekkel


1.1 A fekete doboz tesztelés

• Funkcionális tesztelésnek is nevezik.• A programot fekete doboznak tekintjük, a tesztesetek

a programspecifikáció alapján készülnek.• Nem foglalkozik a program implementációjával.• A tesztek tervezése a szoftverfolyamat korai

szakaszában megkezdődhet.(Egyes Agilis módszereknél előbb, mint a program tervezése!)

• Az előreláthatóan hibát okozó tesztesetek tervezéséhez szakterületi ismeretekre van szükség.


A fekete doboz tesztelés

Rendszer

Outputteszt-eredmények

Input tesztadatok

Oe

Ie

Rendellenesviselkedést okozóinput adatok

A hiányosságokatfelfedő outputok


1.2 Ekvivalencia-osztályozás

• A rendszer input és output adatait valamilyen közös jellegzetesség szerint csoportosítják, amelyekre a rendszer hasonló módon reagál:– Például: ha az input 5 jegyű valós szám 10.000 és 99.000

között, akkor az ekvivalencia-osztályok:

< 10.000, 10.001 – 99.000, < 99.999

• A fejlesztők legtöbbször az inputok tipikus értékeit veszik figyelembe.

• A teszteseteket a határértékek közelében és az osztályok közepéből célszerű kiválasztani:

00000, 09999, 10000, 99999, 10001


1.3 Struktúrateszt

• Fehér doboz vagy üvegdoboz tesztelésnek is nevezik, mert a tesztek a program struktúrájának, implementációjának ismeretében készülnek.

• A struktúra és a kód ismeretében újabb ekvivalencia-osztályok definiálhatók.

• A tesztelő a tesztesetek készítésekor elemzi a kódot, hogy biztosítsa minden utasítás legalább egyszeri végrehajtását (az összes lehetséges út-kombináció tesztelésére nincs reális lehetőség).


1.4 Útvonal tesztelés

• Az útvonal tesztelés strukturális tesztelési stratégia. Célja, hogy minden független útvonalon végighaladjon a teszt. Ekkor legalább egyszer biztosan sor került minden utasítás végrehajtására, és minden feltételes utasítás igaz és hamis eseteire.

• A kiindulás a program folyamat-gráfja, amely a döntéseket reprezentáló csomópontokból és a vezérlés irányát képviselő élekből áll. Előállítása viszonylag egyszerű, ha programban nincs goto.

• Csak kisebb programok tesztelhetők ilyen módon.


Ciklomatikus komplexitás

• A független utak száma a programban.• Egy program ciklomatikus komplexitása:

CC = Élek száma – Csomópontok száma + 2

• CC megmutatja, hogy hány tesztet kell végrehajtani az összes független út végrehajtásához, vagyis minden vezérlő utasítás legalább egyszeri végrehajtásához.

• Nem lehet a független utak összes kombinációját végrehajtani.

• A dinamikus programelemzők a fordításkor kiegészítő kódot adnak a programhoz, amelyek mérik, hogy az egyes vezérlő utasítások hányszor kerültek végrehajtásra.


2. Integrációs tesztelés

• Teljes rendszerek vagy alrendszerek tesztelése, amelyek előzőleg már tesztelt komponensekből állnak.

• A komponensek együttműködéséből származó hibák feltárására szolgál.

• Az integrációs teszt fekete doboz tesztelés, a tesztek a specifikációból származnak.

• Komplex rendszerben az észlelt hibás eredményből nehéz a hiba helyére következtetni.

• Az inkrementális integrációs tesztelés némileg segít.


Inkrementális integrációs tesztelés

A

B

A

B

C

A

B

C

D

Tesztsorozat1.

Tesztsorozat2. Tesztsorozat

3.

T3

T5

T4

T3

T2

T1

T4

T3

T2

T1

T2

T1


2.1 Az integrációs tesztelés stratégiái

• Fentről lefelé tesztelés:– A rendszer magas szintű komponenseit még a tervezés és az

implementáció alatt integrálják. A még el-nem készült komponenseket azonos interfésszel készült „csonkok” helyettesítik, ahol szükséges. Ezeket fokozatosan kicserélik a kész elemekkel.(Evolúciós fejlesztésnél alkalmazható)

• Lentről felfelé tesztelés:– A hierarchia alsó szintjein lévő modulok integrálásával és

tesztelésével kezdik, ahol a magasabb szinteket tesztgenerátorok helyettesítik.(Inkrementális és újrafelhasználás alapú fejlesztésnél alkalmazható)

• A gyakorlatban a kettő kombinációját alkalmazzák.


Tesztelés fentről lefelé

2. szintű csonkok2. szint2. szint

1. szint

2. szint

1. szint

3. szintű csonkok

A tesztelés sorrendje


Tesztelés lentről felfeléTeszt

meghajtók

N. szint

N-1 szint

N. szint N. szint N. szint N. szint

N-1 szint N-1 szint

Tesztmeghajtók

A teszteléssorrendje


A tesztelési stratégiák összehasonlítása

• Szerkezeti validáció– A fentről lefelé teszteléssel felfedhetők a hibák a

rendszerarchitektúrában és a magas szintű tervekben, még a folyamat korai szakaszában. Ez a lentről felfelé tesztelésnél csak később lehetséges.

• Rendszerdemonstráció– A fentről lefelé integráció korán lehetővé teszi a korlátozott

demonstrációt. Újrafelhasználható komponensek alkalmazásával a lentről felfelé megközelítéssel is lehetséges.

• Tesztimplementáció– A programcsonkokat nehéz implementálni, a lentről felfelé tesztelés

tesztmeghajtóit valamivel egyszerűbb, de mindenképpen jelentős addicionális fejlesztést igényel.

• Tesztmegfigyelés– A tesztek eredményét mindkét módszernél nehéz megfigyelni.

Mesterséges környezetre, extra kódra van szükség. Különösen a fentről lefelé megközelítésnél, ahol a magasabb szintek sokszor nem szolgáltatnak outputokat.


2.2 Interfésztesztelés

• Interfésztesztelésre akkor van szükség, amikor egy nagyobb rendszer összeépítésekor modulokat vagy alrendszereket integrálunk.

• Célja az interfészek specifikációs- (félreértések), vagy implementációs hibáinak felfedése.

• Az interfésztesztelés az objektumorientált fejlesztésnél fontos (különösen objektumok és osztályok újrafelhasználásakor), mert az objektumokat az interfészeikkel definiáljuk.

• Egyedi objektum tesztelésével az interfészhibákat nem lehet felfedni.A hibák az objektumok közti interakciókban jelentkeznek, nem egy egyedi objektum sajátosságaiként.


Interfész típusok

• Paraméter interfészek:– Adatok továbbítása az egyik alrendszertől a másikhoz.

• Osztott memória interfészek:– Az alrendszerek közös memóriablokkon keresztül cserélnek

adatot egymással.

• Procedurális interfészek:– Egy alrendszer más alrendszerek által hívható eljárásokat

tartalmaz.

• Üzenet alapú interfészek:– Egy alrendszer úgy kér szolgáltatást egy másik alrendszertől,

hogy üzenetet juttat el hozzá. A szolgáltatás eredményeit egy válaszüzenetben kapja meg.


Tipikus interfészhibák

• Interfész hibás alkalmazása:– Egy hívó komponens hibája lehet: rossz típusú vagy sorrendű

paraméterek, hibás számú paraméter, stb.

• Interfész félreértése:– A hívó komponens hibásan értelmezi az interfészt, vagy a hívott

komponens válaszait.

• Időzítési hibák:– A hívó és a hívott komponens különböző sebességgel működik

(osztott memória, vagy üzenettovábbító interfész esetén), és a hívott nem aktuális információt kap.


Az interfésztesztelés irányelvei

• A teszteket úgy kell tervezni, hogy a paraméterek értékei a határértékek közelében legyenek.

• A pointer jellegű paramétereket null értékkel is tesztelni kell.

• Olyan tesztesetet is tervezni kell, amely a hívott komponens hibáját okozza. (A specifikációs hibák többsége a hibák értelmezéséből fakad.)

• Üzenettovábbító, vagy interaktív rendszereknél terhelési (stressz) tesztet kell végrehajtani.

• Osztott memóriájú interfészeket a komponensek aktiválódása sorrendjének megváltoztatásával is tesztelni kell (szinkronizációs hibák).


2.3 Terhelési (stressz) tesztek

• A rendszereket a tervezettnél nagyobb terheléssel is tesztelni kell. Fokozatosan növelni kell a terhelést, amíg a rendszer hibázik, vagy teljesítménye elfogadhatatlanná válik.

• Feladatai:– Szélsőséges körülmények között teszteli a rendszer

viselkedését. A túlterhelés nem okozhat adatvesztést, vagy a szolgáltatások teljes eltűnését. Erre tervezni kell a rendszert.

– Olyan hiányosságokat fed fel, amelyek normális esetben nem okoznak rendszerhibát.

• Különösen fontos az osztott rendszereknél, ahol a nagyobb terhelés a koordinációs adatokkal túlterheli a hálózatot. Ez a folyamatokat lassítja, önmagát erősítő folyamatként túltelíti a rendszert.


3. Objetumorientált tesztelés

• A komponens- és integrációs tesztelés az objektumorientált rendszereknél is alkalmazható.

• Fontos különbségek:– A tesztelendő objektumok komponensként gyakran

nagyobbak, mint az egyszerű függvények.(A fehér doboz tesztelés nehezebben alkalmazható.)

– Az objektumok lazán kötődnek, és a rendszernek/alrendszernek nincs egyértelmű teteje.

– Az újrafelhasznált komponensek kódjához nem mindig lehet hozzájutni, elemezni.


Az objektumorientált tesztelés szintjei

• Az objektumokhoz kapcsolódó műveletek tesztelése: Függvények, vagy eljárások, fekete- vagy fehér doboz eljárással tesztelhetők.

• Objektumosztályok tesztelése:A fekete doboz eljárás alkalmazható, de az ekvivalencia-osztályokat a műveletsorozatokra is ki kell terjeszteni.

• Együttműködő objektumcsoportok tesztelése: Forgatókönyv alapján kijelölhető az objektumok csoportja.

• Objektumorientált rendszer tesztelése:A rendszerkövetelmények verifikációja és validációja más rendszerekhez hasonlóan történhet.


3.1 Objektumosztályok tesztelése

• A teljes (minden utasítás és minden független útvonal) teszt lefedettséghez szükség van:– Az objektumhoz kapcsolódó összes művelet tesztelésére,– Az összes attribútum beállítására és tesztelésére,– Az objektum összes lehetséges állapotának végrehajtására.

• Az öröklődés még nehezíti az objektumosztályok tesztelését, mert az összes örökölt műveletet is tesztelni kell.


3.2 Objektumintegráció

• Az objektumorientált rendszerekben az integráció szintjét nehéz meghatározni.

• A modultesztnek nincs megfelelője, de alkalmazható az együttműködő objektumosztályok csoporttesztje.

• A csoportok az objektumok működésének és a rendszer tulajdonságainak ismeretében jelölhetők ki.


Csoporttesztelés

• Használati eset vagy forgatókönyv alapján:– A tesztek a felhasználói interakciókon alapulnak.– Előnye, hogy a felhasználók által leggyakrabban használt

részeket teszteli.

• Száltesztelés:– A rendszernek egy eseményre adott válaszát vizsgálja, amint az

a rendszeren keresztülhalad.

• Objektum együttműködési teszt:– Az objektumok együttműködésének egy sorozatát vizsgálja,

amely akkor ér véget, ha egy objektumművelet nem hív meg más objektumszolgáltatást.


Forgatókönyv alapú tesztelés

• A használati eset diagram alapján meghatározott forgatókönyvet kiegészíti egy olyan szekvencia diagrammal, amely az érintett objektumokat is megmutatja.

• Olyan forgatókönyveket kell választani, amelyek végül biztosítják, hogy minden objektum minden művelete legalább egyszer tesztelve legyen.

• A szekvencia diagram arra is alkalmas, hogy meghatározzuk a teszt input és output adatait.

• A forgatókönyvben ki kell térni a kivételekre (hibaesetekre) is.!


4. Tesztelő eszközök

• A tesztelés drága és időigényes folyamat.• A tesztelő eszközök automatizálják, amit lehet, így

csökkentik a tesztelés idő- és erőforrásigényét, ezáltal a költségeket.

• Nagy rendszerek esetén a tesztelő eszközöket a rendszer funkcióihoz és felelősségéhez szabják.

• A tesztelő eszközöket nem könnyű integrálni a tervező, fejlesztő CASE eszközökkel.


Tesztelő eszközrendszer

Forráskód

Dinamikuselemző

Futtatásijelentés

Tesztadat

Teszteltprogram

Teszt-eredmények

Tesztmenedzser

Előrejelző

Tesztadat-generátor

SzimulátorÁllomány

össze-hasonlító

Teszt-előrejelzések

Teszteredményjelentések

Specifi-káció

Jelentés-generátor


Összefoglalás• Legfontosabb a rendszer gyakran használt részeit tesztelni.• Az ekvivalenciaosztályozás egy lehetőség a tesztadatok előállítására.

Az osztály határára eső értékek fedik fel a hibákat a legnagyobb valószínűséggel.

• A strukturális tesztelés a programon átvezető útvonalak tesztelésén alapul.

• Az integrációs tesztek a komponensek és interfészeik közti interakciót vizsgálják.

• Interfészhibák a specifikáció hibás értelmezéséből és hibás időzítésből származhatnak.

• Az objektumosztályokat úgy kell tesztelni, hogy minden műveletet kipróbálunk, minden attribútumnak értéket adunk, minden állapotot tesztelünk.

• Az OO rendszereket a használati esetek alapján összegyűjtött objektumcsoportokban lehet tesztelni.

A szoftver költségei


A szoftver költségbecslés alapvető kérdései

– Mekkora munkát igényel egy feladat elvégzése?– Mennyi időbe kerül a feladat végrehajtása?– Mennyi a tevékenység összes költsége?

• A költségbecslés és projektütemezés folyamatos projektvezetési tevékenység.

• A szoftverfejlesztési projekt költségelemei:– A hardver és szoftver költségei a karbantartással együtt,– Utazási és képzési költségek,– Munkaköltségek (bér, közteher, helység, kisegítő munkák,

kommunikáció, rekreáció, ...)


A szoftver költsége és ára

• A költség és az ár között nincs egyszerű arányosság. Befolyásolják:– Piaci lehetőségek,– A költségbecslés bizonytalanságai,– A szerződéses feltételek (tulajdonjog),– A követelmények változékonysága,– A fejlesztő gazdasági helyzete.


A szoftverfejlesztés termelékenysége

• Mérni kell a szoftver valamilyen jellemzőjét és osztani a fejlesztési idővel.– Mennyiségi mérések:

(Forráskód sorok száma, utasítások száma, dokumentáció oldalszáma, stb.)

– Funkcionális mérések:(Az időegység alatt előállított hasznos funkciók száma: Funkciópontok, objektumpontok.)

• A termelékenység összehasonlítása:– Alacsonyabb szintű nyelven több kódsort lehet írni, de azonos

funkciót több kóddal kell megvalósítani,– A jó programozó ugyanazt a funkciót kevesebb kóddal készíti el,

mint a „bőbeszédű” programozó,– Hogyan vegyük figyelembe a kommenteket?


Funkciópontok

• A program jellemzőinek kombinációján alapuló, nyelv-független módszer.

• Méri az alábbi jellemzőket:– Külső bemenetek és kimenetek– Felhasználói interakciók– Külső interfészek– A rendszer által használt fájlok

• Mindegyikhez súlyozási tényezőt rendel:– Egyszerű külső bemenet: 3– Bonyolult belső állományok: 15

• A súlyozási tényezőt egy szervezeten belül, hasonló jellegű szoftverek készítése során gyűjtött statisztikák alapján finomítja.


A funkciópontok számítása

• A funkciópontok (FP) alapján a kódsorok számára (LOC – Lines Of Code) lehet következtetni:– LOC = AVC * FP ahol:– AVC nyelvfüggő szorzófaktor

(200-300 az assembly és 2-40 a 4GL nyelvekre)

• A funkciópont számítás nagyon sok szubjektív elemet tartalmaz.

• Automatikus számítása nem lehetséges, mert a specifikáció alapján kell a funkciópontokat megbecsülni.


Objektumpontok

• 4GL vagy más magas szintű nyelvek esetén a funkciópontok alternatívája. Magas szintű specifikáció alapján könnyebben becsülhető.

• Az objektumpont (NTC) nem azonos az objektumok számával, hanem az alábbiakból számítható:– A külön megjelenítendő képernyők száma, az egyszerűtől (1), a

nagyon bonyolultig (3),– A készítendő jelentések száma (2 – 5 – 8)– A 4GL kiegészítése miatt szükséges 3GL modulok száma (10)


A termelékenység becslése

• Valósidejű, beültetett rendszerek:40 – 160 LOC / hó

• Rendszerprogramok:150 – 400 LOC / hó

• Kereskedelmi alkalmazások:• 200 – 800 LOC / hó• Objektumpontban számolva a termelékenység 4 és

50 pont / hónap közötti, az eszköztámogatottságtól és a fejlesztők képességeitől függően.


A termelékenységet befolyásoló tényezők

• Az alkalmazási terület ismerete:– A hatékony szoftverfejlesztéshez szükséges a szakterület ismerete.

• A folyamat minősége:– A fejlesztési folyamat minőségének jelentős hatása van a

termelékenységre.

• A projekt mérete:– A nagyobb projekt több csoportkommunikációs és adminisztrációs

tevékenységet igényel.

• Technológiai támogatás:– Támogató technológiával (pl. CASE) a termelékenység növelhető.

• Munkakörnyezet:– A jó munkakörülmények és légkör javítják a termelékenységet.


Algoritmikus költségmodellezés COCOMO

• Empirikus modell, a projektek gyakorlatából gyűjtött adatokon alapul.

• Jól dokumentált, hosszú tapasztalat áll mögötte (első verzió: 1981)

• A COCOMO 2 (1995) három szintű modellt alkalmaz:– Korai prototípuskészítés szintje

(becslés objektumpontok alapján)– Korai tervezés szintje

(funkciópontok alapján a forráskódok számát becsli)– Poszt-architekturális szint

(az architektúra terv elkészülte után becsli a szoftver méretét)


Korai prototípuskészítés szintje

• Prototípuskészítést és újrafelhasználást is figyelembe vesz.• A fejlesztői produktivitást objektumpontokkal számolja és a

CASE használatot is bekalkulálja.• A formula: PM = (NOP * (1 - %reuse)) / PROD

– Ahol: PM – a munka emberhónapban, NOP – az objektumpontok száma, PROD - produktivitás

A fejlesztő gyakorlata és képessége

Nagyon kevés Kevés Átlagos Sok Nagyon magas

A CASE érettsége és lehetőségei

Nagyon kevés Kevés Átlagos Sok Nagyon magas

PROD(NOP/hónap)

4 7 13 25 50


Korai tervezési szint• A követelmények tisztázása után végezhető a becslés.• Az alábbi képlettel számol:

PM = A * MéretB * M + PMm

aholM=PERS*RCPX*RUSE*PDIF*PREX*FCIL*SCEDPMm= (ASLOC*(AT/100))/ATPROD

A = 2,5 a kezdeti számításbanB = 1,1 – 1,24 a projekt mérete, újdonsága függvényében.M = projekttényezők:

PERS – személyi képességek,RCPX – termék megbízhatóság,RUSE – szükséges újrafelhasználás,PDIF – platform nehézségeiPREX – személyek gyakorlata, FCIL – támogató eszközök,SCED – ütemezésASLOC = automatikusan generált kódsorok, AT = aut. rendszerkód, ATPRO = termelékenység,


Poszt-architekturális szint

• Ugyanazt a formulát alkalmazza, mint a korai tervezési becslés, de két tényezőt figyelembe vesz:– A követelmények változékonysága,– A lehetséges újrafelhasználás mértéke.

• A szükséges új kódsorok számának becslésekor statisztikai és egyéb értékeket is figyelembe vesz, mint:– A korábbi hasonló projektek hiánya,– A fejlesztés rugalmassága,– A csapat összetartása,– A folyamat fejlettsége.

A SZOFTVERTECHNOLÓGIA ALAPJAI

Documents

Transcript of A SZOFTVERTECHNOLÓGIA ALAPJAI