ciós s tesztek ciós s tesztek Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 11. 27. IntegraciosTeszt / 1 ós tesztek IntegraciosTeszt / 2 ciós s tesztek (folyt.) Feltételezzük, hogy az építıelemek már önmagukban teszteltek. Ha hibát észlelünk, az feltehetıleg a modulok együttmőködésébıl adódik. Integration Level Testing (ILT) Együttmőködı egységek vizsgálata Egy részrendszert állítunk össze Többnyire csak technikai, nem funkcionális részrendszerek ezért probléma lehet a megfelelı teszt esetek elıállítása ós tesztek IntegraciosTeszt / 3 ós tesztek IntegraciosTeszt / 4 Miskolci Egyetem 1
giák "Big-bang" integráció Minden egység rendelkezésre áll, és ezekbıl egybıl a teljes rendszer építjük fel Valójában az ITL kimarad, és egybıl a System Level Testing következik Nagyon nehéz a hibák okát megtalálni Egy hibajelenséget több hiba együttese is okozhat (a hibák következményei "összemosódnak") Ezért legfeljebb nagyon egyszerő rendszerek esetén alkalmazható Egyetlen elıny: nagyon kevés segédkódot kell írni. giák k (+) Inkrementációs integrációs és tesztelési stratégia Néhány elemet (modult vagy részrendszert) kombinálunk Olyan teszteket futtatunk, amelyek csak az összeépített elemeket igénylik Ha minden teszt sikeres, újabb elemeket teszünk hozzá a rendszerhez. További teszteket futatunk, amelyek az új elemek meglétét is igénylik. ós tesztek IntegraciosTeszt / 5 ós tesztek IntegraciosTeszt / 6 giák k (+) A fenti iterációt addig folytatjuk, amíg a teljes rendszert összeépítettük, és azon valamennyi teszt sikeresen lefutott. A Példa: T1 A B T1 T2 T3 A B C T2 T3 T4 B C D T1 T2 T3 T4 T5 giák k (+) Két megközelítés Top-down integráció Bottom-up integráció Többnyire a két megközelítés valamilyen ötvözetét használják a gyakorlatban. Test sequence 1 Test sequence 2 Test sequence 3 ós tesztek IntegraciosTeszt / 7 ós tesztek IntegraciosTeszt / 8 Miskolci Egyetem 2
Top-down integráci ció Top-down integráci stubs Testing Level 1 Level 1 sequence Level 3 stubs... A hierarchia legfelsı szintjén álló elem tesztelésével kezdjük Az egy szinttel lejjebb álló elemek viselkedését és iterface-ét szimuláló ideiglenes elemek (stub) szükségesek. Ha a teszt sikeres, az ideiglenes elemeket a valódiakkal helyettesítjük, az általuk használtakat pedig újabb ideiglenes elemekkel szimuláljuk. ós tesztek IntegraciosTeszt / 9 ós tesztek IntegraciosTeszt / 10 Elınyei: Top-down integráci Jól illeszkedik a top-down programfejlesztési módszerekhez. Egy modul a megírása után rögtön tesztelhetı. Az esetleges tervezési hibák korán kiderülnek, és idejében orvosolhatók. Viszonylag korán rendelkezésre áll egy korlátozott képességő rendszer : validáció Hátrányai: Top-down integráci Bonyolult lehet a szimulációt végzı ideiglenes rutinok megírása. A hieracrhia felsı szintjein álló modulok sokszor nem szolgáltatnak outputot. A teszteléshez külön eredmény-generáló "betétek" szükségesek. ós tesztek IntegraciosTeszt / 11 ós tesztek IntegraciosTeszt / 12 Miskolci Egyetem 3
Test drivers Test drivers Bottom-up integráci ció 1 1 1 Testing sequence Bottom-up integráci Elıször a legalsó szinten levı modulokat teszteljük, majd a hierarchiában felfelé haladunk. Ehhez a felsı szinteket szimuláló tesztelési környezetet (test driver) kell írni. Ha a teszt sikeres, a teszt driver-eket a valódi implementált elemekre cseréljük, és a következı szintet helyettesítjük test driver-ekkel ós tesztek IntegraciosTeszt / 13 ós tesztek IntegraciosTeszt / 14 System Level Testing (SLT) A rendszer összes komponensének teljes körő (funkcionális, nem funkcionális) tesztelése Feladata annak megállapítása, hogy a rendszer kiadható-e a megrendelınek (végsı ellenırzés). Talán ezért láttam már a "release test" kifejezést is. Másik elnevezés: "alpha version". A fejlesztı szervezeten belül végzik. Szükséges az éles használat környezetének minél pontosabb szimulációja. Használható tesztelési módszerek Szolgáltatás tesztelés nyilvánvaló Mennyiségi tesztelés A szoftver mőködését nagy mennyiségő adattal teszteljük a kapacitáskorlátok ellenırzésére. Végrehajtási / válasz idıket is figyelhetünk, mérhetünk. ós tesztek IntegraciosTeszt / 15 ós tesztek IntegraciosTeszt / 16 Miskolci Egyetem 4
Terheléses tesztelés (Stressz-tesztelés) A tesztelt rendszert valamilyen szempontból erıs terhelésnek teszi ki. Fontos tényezı az idı! Adott idıkorláton belül hogyan teljesít nagy mennyiségő adatokon dolgozva. Intenzív feldolgozást kívánó helyzeteket kell teremteni, melyek szélsıségesek, de elıfordulhatnak A robosztusság ellenırzésére érdemes a terhelést olyan szintre is emelni, amely (elvileg) nem fordulhat elı. ós tesztek IntegraciosTeszt / 17 Használhatósági tesztelés A rendszer egy meghatározott felhasználó által, egy meghatározott felhasználási körben használva, meghatározott célok hatékony és produktív elérésére, mennyire kielégítı és mennyire vezet megelégedésre. Biztonsági tesztelés Az adatbiztonsággal és adatvédelemmel kapcsolatos hibák vizsgálata. ós tesztek IntegraciosTeszt / 18 Teljesítménytesztelés A teljesítmény vagy a hatékonyság mérése különbözı terheléseknél és konfigurációkra meghatározott válaszidık és feldolgozási sebességek formájában. Konfigurációtesztelés Különbözı környezetek (hardver, operációs rendszer, egyéb szoftver installációk) lehetségesek. Ha a programnak korábbi rendszerekhez kell kapcsolódniuk, vagy a program egy korábbi változatát váltják le: ellenırizni kell a kompatibilitást vagy a konverziós eljárásokat. ós tesztek IntegraciosTeszt / 19 Megbízhatósági tesztelés Ha program céljai között megbízhatósággal kapcsolatos speciális kitételek szerepelnek. A megbízhatósági teszteknek adott esetben ki kell terjedniük a rendszer programozási, hardver- vagy adathibák bekövetkezte utáni felállására, mőködésbe visszaállására. ós tesztek IntegraciosTeszt / 20 Miskolci Egyetem 5
Dokumentációtesztelés Felhasználói és fejlesztési dokumentumokra A felhasználói dokumentációban szereplı összes illusztratív példát le kell képezni tesztesetekké és végre is kell hajtani velük a tesztelést. Összefoglalva: Ez a szint is elsısorban verifikációs szemlélető, a sikeres teszt tehát az, amelyik hibát okoz! Természetesen validációs célja is van, de itt is a hibák kimutatása a cél. ós tesztek IntegraciosTeszt / 21 ós tesztek IntegraciosTeszt / 22 User Acceptance Testing (UAT) Feladata annak megállapítása, hogy a rendszer éles üzembe állítható-e. Célja felhasználó és minden haszonélvezı (stakeholder) elégedettségének vizsgálata. Általában a megrendelı telephelyén, annak közremőködésével, és a végleges üzemeltetési körülmények között kell végrehajtani. ós tesztek IntegraciosTeszt / 23 User Acceptance Testing (UAT) (+) A használható tesztelési módszerek hasonlóak, mint a SLT esetén, de azok közül csak a felhasználó számára releváns eseteket kell bemutatni. Ez a szint elsısorban verifikációs szemlélető, tehát az a jó teszt, amely sikeres mőködést produkál. Lehet verifikációs célja is (olyan hibák kimutatására, amelyek csak a végleges mőködtetı környezetben vizsgálhatók.) ós tesztek IntegraciosTeszt / 24 Miskolci Egyetem 6
User Acceptance Testing (UAT) (+) Egy speciális UAT módszer: béta verzió kibocsátása Személyes megjegyzéseim: Nem hosszú távra szóló üzleti modell az UAT-t a SLT sikertelen teszt eseteibıl összeállítani Meg az sem, amikor a felhasználó fizet azért, hogy tesztelhesse a rendszert (túl korai release) Irodalomjegyzék 1. Ian Sommerville: Szoftverrendszerek fejlesztése Panem, Budapest, 2002 ós tesztek IntegraciosTeszt / 25 ós tesztek IntegraciosTeszt / 26 Miskolci Egyetem 7