A SZOFTVERTECHNOLÓGIA ALAPJAI

1. ASZOFTVERTECHNOLÓGIAALAPJAI SzoftvertesztelésA szoftver becslése 12. előadás PPKE-ITK

2. Tartalom 1. A hiányosságok tesztelése 1.1 A fekete doboz tesztelés 1.2 Ekvivalencia-osztályozás 1.3 Struktúrateszt 1.4 Útvonal tesztelés 2. Integrációs tesztelés 2.1 Az integrációs tesztelés stratégiái 2.2 Interfésztesztelés 2.3 Terhelési (stressz) tesztek 3. Objektumorientált tesztelés PPKE-ITK Szoftvertechnológia-2011

3. 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. PPKE-ITK Szoftvertechnológia-2011

4. 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. PPKE-ITK Szoftvertechnológia-2011

5. 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. PPKE-ITK Szoftvertechnológia-2011

6. 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. PPKE-ITK Szoftvertechnológia-2011

7. Teszt-esetek Teszt-adatok Teszt-eredmények Teszt-jelentések Teszt-esetektervezése Teszt-adatokkészítése Programfuttatásatesztadatokkal Eredményekösszevetése atesztesetekkel A hiányosságok tesztelésének folyamata PPKE-ITK Szoftvertechnológia-2011

8. 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. PPKE-ITK Szoftvertechnológia-2011

9. A fekete doboz tesztelés Input tesztadatok Rendellenesviselkedést okozóinput adatok Ie Rendszer Outputteszt-eredmények A hiányosságokatfelfedő outputok Oe PPKE-ITK Szoftvertechnológia-2011

10. 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 PPKE-ITK Szoftvertechnológia-2011

11. 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). PPKE-ITK Szoftvertechnológia-2011

12. 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. PPKE-ITK Szoftvertechnológia-2011

13. 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. PPKE-ITK Szoftvertechnológia-2011

14. 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. PPKE-ITK Szoftvertechnológia-2011

15. A T1 T1 A T2 T1 B T2 A T3 T2 B T3 B C T4 T3 T4 C T5 D Tesztsorozat1. Tesztsorozat2. Tesztsorozat3. Inkrementális integrációs tesztelés PPKE-ITK Szoftvertechnológia-2011

16. 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. PPKE-ITK Szoftvertechnológia-2011

17. 2. szint 2. szint 2. szint 1. szint Tesztelés fentről lefelé A tesztelés sorrendje 1. szint 2. szintű csonkok 3. szintű csonkok PPKE-ITK Szoftvertechnológia-2011

18. Tesztelés lentről felfelé Tesztmeghajtók N. szint N. szint N. szint N. szint N. szint A teszteléssorrendje Tesztmeghajtók N-1 szint N-1 szint N-1 szint PPKE-ITK Szoftvertechnológia-2011

19. 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. PPKE-ITK Szoftvertechnológia-2011

20. 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. PPKE-ITK Szoftvertechnológia-2011

21. 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. PPKE-ITK Szoftvertechnológia-2011

22. 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. PPKE-ITK Szoftvertechnológia-2011

23. 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). PPKE-ITK Szoftvertechnológia-2011

24. 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. PPKE-ITK Szoftvertechnológia-2011

25. 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. PPKE-ITK Szoftvertechnológia-2011

26. 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. PPKE-ITK Szoftvertechnológia-2011

27. 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. PPKE-ITK Szoftvertechnológia-2011

28. 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. PPKE-ITK Szoftvertechnológia-2011

29. 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. PPKE-ITK Szoftvertechnológia-2011

30. 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.! PPKE-ITK Szoftvertechnológia-2011

31. 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. PPKE-ITK Szoftvertechnológia-2011

32. Tesztelő eszközrendszer Tesztadat-generátor Specifi-káció Tesztmenedzser Előrejelző Tesztadat Forráskód Teszteltprogram Dinamikuselemző Teszt-eredmények Teszt-előrejelzések Szimulátor Állományössze-hasonlító Futtatásijelentés Jelentés-generátor Teszteredményjelentések PPKE-ITK Szoftvertechnológia-2011

33. Ö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. PPKE-ITK Szoftvertechnológia-2011

34. A szoftver költségei

35. 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ó, ...) PPKE-ITK Szoftvertechnológia-2011

36. 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. PPKE-ITK Szoftvertechnológia-2011

37. 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? PPKE-ITK Szoftvertechnológia-2011

38. 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. PPKE-ITK Szoftvertechnológia-2011

39. 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. PPKE-ITK Szoftvertechnológia-2011

40. 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) PPKE-ITK Szoftvertechnológia-2011

41. 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. PPKE-ITK Szoftvertechnológia-2011

42. 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. PPKE-ITK Szoftvertechnológia-2011

43. 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) PPKE-ITK Szoftvertechnológia-2011

44. 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 PPKE-ITK Szoftvertechnológia-2011

45. 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égei PREX – személyek gyakorlata, FCIL – támogató eszközök, SCED – ütemezés ASLOC = automatikusan generált kódsorok, AT = aut. rendszerkód, ATPRO = termelékenység, PPKE-ITK Szoftvertechnológia-2011

46. 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. PPKE-ITK Szoftvertechnológia-2011