Domino net provisioning tesztelése esettanulmány 1.0 Készítette: Dobó Arnold Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax: +361 469 4029 e-mail: info@rubin.hu; web: www.rubin.hu
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
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 20-80 é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
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 12.04 LTS Hardware kiépítés: 16GB RAM, 2 db Intel(R) Xeon(R) CPU E5430 @ 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
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. 80 70 60 50 40 30 NET provisioning hibák Új hibák 20 10 0 q1 q2 q3 q4 2012 q1 2012 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. 2010 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
2000.04.10 2001.04.10 2002.04.10 2003.04.10 2004.04.10 2005.04.10 2006.04.10 2007.04.10 2008.04.10 2009.04.10 2010.04.10.04.10 2012.04.10 esettanulmány 450 400 350 300 250 200 150 100 50 0 Ú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 2000,00 1500,00 1000,00 500,00 Javítási idő 0,00-500,00 Oldal 6 / 6