Rubin SPIRIT TEST. Domino net provisioning tesztelése esettanulmány 1.0. Készítette: Dobó Arnold Jóváhagyta: Varga József. Rubin Informatikai Zrt.

Méret: px

Mutatás kezdődik a ... oldaltól:

Download "Rubin SPIRIT TEST. Domino net provisioning tesztelése esettanulmány 1.0. Készítette: Dobó Arnold Jóváhagyta: Varga József. Rubin Informatikai Zrt."

Emília Bartané
8 évvel ezelőtt
Látták:

1 Domino net provisioning tesztelése esettanulmány 1.0 Készítette: Dobó Arnold Jóváhagyta: Varga József Rubin Informatikai Zrt Budapest, Egressy út telefon: ; fax: web:

Informatikai Zrt. 1149 Budapest, Egressy út 17-21.

2 esettanulmány 1 Bevezetés - tesztelés A szoftvertesztelés a minőségbiztosítás kiemelt fontosságú területe. A tesztelés segít a termékek és szolgáltatások minőségének javításában. Egy jól megtervezett, szigorú tesztelési eljárásokon átesett szoftver megfelelő működésében joggal bízhatunk. Hibák kiszűrésével és azok, helyes korrigálása esetén a programok minősége számottevően javul. 1.1 Korai tesztelés jelentősége Egyik tesztelési alapelv, a korai tesztelés, mely szerint a tesztelést a fejlesztési életciklus legkorábbi stádiumában kell elkezdeni és az előre meghatározott célokra kell összpontosítani. Ezek a célok lehetnek: a hibák felfedezése információszerezés a szoftver minőségéről programhibák megelőzése az elvárt igények és a teljesítmény összehasonlítása A hagyományos tesztelési felfogás szerint a szoftvertesztelés a fejlesztés után kezdődik, azonban a felgyorsult piaci igények mellett erre kevés idő jut. Napjainkban a korai tesztelés jelentősége és a tesztelői munka eltolódik a döntéshozói és fejlesztői munka támogatásának irányába. Célja, hogy bármely fejlesztési szakaszban lévő rendszerben a hibákat felismerje, emellett kockázatelemzésekkel kiegészítse, és hatékonyan támogassa a fejlesztői munkát. 1.2 Tesztelés agilis fejlesztési modell esetén A hagyományos fejlesztési módszerekkel szemben az agilis fejlesztési módszerek egyre népszerűbbek, amely tesztelési folyamatok változását is maga után vonja. Agilis fejlesztési módszer esetén az egyik leggyakrabban alkalmazott módszer a tesztvezérelt fejlesztési módszer (test driven development). Ez egy olyan szoftverfejlesztési technika, amely a fejlesztőket célozza meg, előre megírt tesztekkel befolyásolja a kód alakulását. Az agilis modellben fejlesztés előtti, közbeni tesztek, kiegészülve a regressziós tesztelésekkel jelentősen növeli a tesztelés mennyiségét a hagyományos fejlesztéshez képest, emiatt automatizált tesztelés szükséges. Az átvételi tesztelés nem kizárólag a tesztelés végén történik, hanem az egész fejlesztési folyamat során jelen vannak ezek a tesztek, ennek következtében a hibák hamarabb a felszínre kerülnek. 2 A Domino Net Provisioning tesztelés bemutatása 2.1 Domino rendszer fejlesztése A Magyar Telekom számára készített összetett alkalmazásunk valós időben szolgálja ki a mobil ügyfelek állapotára és egyenlegére vonatkozó kéréseket. Oldal 2 / 6

Hibák kiszűrésével és azok, helyes korrigálása esetén a programok minősége számottevően javul. 1.

3 esettanulmány A Domino rendszer fejlesztése során rövid határidővel, sok kisebb fejlesztést adtunk át a megrendelőink számára. Az átadott fejlesztések darabszáma jellemzően évente. Ezt 11 shipmentben adjuk át. Az 1997-es induláskor még csak az előre fizető (Prepaid) ügyfelek teljes körű adminisztrációját látta el a rendszer, napjainkra a Domino az összes Mobil ügyfél számára nyújt szolgáltatást. Többek közt a Mobil Internetes egyenlegeket is kezeljük. Minden egyes ügyfél esetén az aktuális internet-szolgáltatás állapotok és egyenlegek alapján dönti el a rendszer, hogy milyen sávszélességgel veheti igénybe az ügyfél a szolgáltatásokat. Több szolgáltatás együttes állapota, és több egyenleg állapota befolyásolja, azt hogy milyen sávszélességet kell engedélyezni a hálózati eszközökben az ügyfeleknek. Mivel az érintett szolgáltatások és az egyenlegek köre az idők folyamán bővült, ezért elérkezett egy pont ahol szükség volt arra, hogy a meglévő logikát újraírva kijavítsuk a többszöri kiegészítés hatására a rendszerbe került bizonytalanságokat. 2.2 Tervezési fázis Ahhoz, hogy az átalakítást úgy tudjuk elvégezni, hogy a rendszer működése biztosan ne változzon meg, szükség volt a rendszer teljes körű felmérésére, egy tesztkészlet elkészítésére az aktuálisan működő logika alapján, valamint a felmérés során tapasztalt hiányosságok alapján a logika újratervezésére. A felderítő tesztelés módszerét választottuk arra, hogy megállapítsuk, hogy minden kombináció esetén megfelelően működik-e a Domino. Mivel abban a szerencsés helyzetben voltunk, hogy az aktuális logikát tartalmazó forrás is a mi kezünkben volt, így annak white box típusú elemezésével tudtuk a teszteseteket bővíteni. (Ez külső megrendelő esetén nem mindig lehetséges.)- Ezek a tesztek az érintett szolgáltatások állapotát menetét és a hozzájuk kapcsolódó egyenlegek változásait tartalmazzák. Ezzel kiderítettük, hogy ténylegesen milyen esetek léteznek, és hogy ezek működése megfelel-e az elvárt működésnek. A tesztesetek elkészülése után, már tudtunk készíteni egy összefoglaló táblázatot, mely alapján elkezdődött a Magyar Telekommal az egyeztetési folyamat. Az egyeztetések két hetet vettek igénybe, melyek során tovább pontosítottuk azaz bővült az érintett szolgáltatások és egyenlegek köre. A tesztelés- egyeztetés- tervezés eredményeként 88 összetett tesztesetet tartalmazó teszthalmaz készült, mely már tartalmazta az összes érintett szolgáltatást és egyenleget. A táblázat mely az egyeztetések alapjául szolgált és a Prepaid ügyfelekre vonatkozóan tartalmazta az egyes tesztesetek bemeneti adatait a végső állapotában 27 sorral és 118 oszloppal rendelkezett, ez a főbb eseteket foglalta magában. Oldal 3 / 6

Az 1997-es induláskor még csak az előre fizető (Prepaid) ügyfelek teljes körű adminisztrációját látta el a rendszer, napjainkra a Domino az összes Mobil ügyfél számára nyújt szolgáltatást.

4 esettanulmány A főbb állapotátmenteket tartalmazó táblázat egy nézete. A rendelkezésre álló táblázat és tesztesetek alapján a program kód tervezését már nagy biztonsággal tudtuk elvégezni, hiszen teljes körűen láttuk, hogy mely részei érintettek a Domino-nak. Így a tervezést már hatékonyan tudtuk megtenni. 2.3 Tesztek fejlesztése A tesztesetek elkészítése során a Domino projektben már 7 éve sikeresen alkalmazott Python Unittest alapú automatizált tesztrendszert használtuk. Mivel a Rubinnak nem áll rendelkezésére az összes kapcsolódó hálózati rendszerből tesztrendszer, ezért a teszt környezetünk ezeket emulálva tartalmazza. Ehhez a teszt halmazhoz a HLR, IPMS, GPROV eszközök emulálására volt szükség. Tesztkörnyezet leírása: Domino adatbázis: Magyar Telekomtól kapott, anonimizált ügyféladatokat tartalmazó oracle adatbázis-szett. Ubuntu server LTS Hardware kiépítés: 16GB RAM, 2 db Intel(R) Xeon(R) CPU 2.66GHz, 2 x 500 Gb sw mirror a rendszernek, 4x200G stripe (stripe only!!!) az adatbázisoknak, 1 Tb single diszk a dumpoknak Tesztscriptek száma: 88 db Összes teszt futási ideje: kb. 17 perc 3 Tesztelés a fejlesztések során A kód implementálását a tesztelés - egyeztetés - tervezés során megszerzett tapasztalatokra támaszkodva végeztük el. Oldal 4 / 6

Így a tervezést már hatékonyan tudtuk megtenni. 2.

5 esettanulmány Az előzetes tesztelés során elkészültek a tesztek, így a fejlesztés már test driven development módszerrel végeztük. Mivel a tervezés során elkészültek a szükséges tesztek, ezért a megvalósítás fázisában támaszkodhattunk rájuk, és ez biztosította, hogy az elvárt funkciók kerüljenek megvalósításra. 3.1 Tesztelés a fejlesztések után A lenti grafikonon látható, hogy a NET provisioning-al kapcsolatosan beérkező újabb hibák száma folyamán folyamatosan növekedett, hiába javítottuk folyamatosan őket. A fejlesztés 2012 első negyedévben lett átadva tesztelésre az MT szakemberei számára. Ezután a rendszerben, a Magyar Telekom tesztelői által észlelt hibák száma jelentősen lecsökkent NET provisioning hibák Új hibák q1 q2 q3 q q q2 4 Tesztek további felhasználása A fejlesztés kapcsán elkészült tesztekkel bővítettük a Domino rendszer fejlesztése során használt regressziós tesztkészletet. A Domino rendszer regressziós tesztelésére szolgáló tesztkészletet 2005-ben kezdtük összeállítani. A tesztek száma folyamatosan növekedett, minden fejlesztés során bővítettük és aktualizáltuk. A teljes tesztkészletünk így jelenleg 6511 db teszt és kb. 5 óra futási ideje van. A következő grafikonon látható, hogy a tesztrendszer bevezetése után és a tesztkészlet bővítése során hogyan alakult az új hibák száma. Bár újabb nagyobb fejlesztések, mint pl elején a postpaid NET átadása, amelynek során a rendszerben levő ügyfelek és a terhelés nagyságrendekkel megnőtt, a hibák száma mindig megugrik, de sokkal alacsonyabb a számuk, mint előtte. A köztes időszakokban pedig kevesebb, mint a fele. Oldal 5 / 6

1 Tesztelés a fejlesztések után A lenti grafikonon látható, hogy a NET provisioning-al kapcsolatosan beérkező újabb hibák száma folyamán folyamatosan növekedett, hiába javítottuk folyamatosan őket.

6 esettanulmány Új hibák száma negyedévenként Tesztek száma *10 Ennek a rendszernek a használata nagymértékben növeli a hatékonyságot, ahogy ez a hibajavítások idején is látható, mivel annak tesztelése, hogy a hiba javítása nem okozott a rendszer egyéb területein változást a működésben gyorssá és megbízhatóvá vált. 3000,00 Javítási idő 2500, , , ,00 500,00 Javítási idő 0,00-500,00 Oldal 6 / 6

Hasonló dokumentumok

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax: