Távközlési szoftverek Bevezetés Dibuz Sarolta

Tematika Tesztelési alapfogalmak Protokoll specifikáció és tesztelés (CTMF) Automata modellek Tesztsorozat generálás Formális leírónyelvek: SDL, LTS ASN.1, TTCN-3 Uj trendek a távközlésben IMS, LTE

Távközlési rendszerek Elosztott rendszer –Szoftver vezérelte autonóm egységek –Kommunikáció: csatornák, üzenetek, protokollok Nagy komplexitás –Együttműködés, visszafelé kompatibilitás Nagy megbízhatóság –Hibatűrés –Jó minőségű szoftver

Mi a protokoll? A kommunikációt irányító szabályrendszer –Szintaktikai szabályok: üzenetek formátuma Táblázatos formátum vagy leíró nyelv, pl. ASN.1 –Szemantikai szabályok: üzenetek jelentése A viselkedési szabályok implicit módon tartalmazzák a szemantikát –Viselkedési szabályok: adott állapotban milyen üzenet érkezhet Leíró nyelvek: SDL, Estelle, Lotos

Protokoll-technológia a gyakorlatban Buktatók: Formális leírás nem teljes vagy hiányzik Természetes (pl. angol) nyelvű leírás többféleképp értelmezhető A komplexitás miatt a megvalósítás hibákat tartalmazhat Az együttműködés nem garantált Tesztelésre van szükség!

Protokoll tesztelés Tesztelés = modell és megvalósítás ekvivalenciájának ellenőrzése Nem garantálja a hibamentességet –A modell hibás vagy hiányos Nincs formális leírás –Vezérelhetőségi, megfigyelhetőségi problémák Beágyazott, elosztott rendszerek, nem-determinizmus Alapfeltevések (korlátozások) –Teszt hipotézis –Hibamodell

Teszt hipotézis Szabályosság (regularity) –A megvalósítás állapotainak száma korlátos Egységesség (uniformity) –Ekvivalencia csoportok: elég egyet kipróbálni Függetlenség (independency) –Egy hibás modul nem befolyásolja a többi működését Igazságosság (fairness) –Nem-determinisztikus működésnél a lehetséges végrehajtási utak mindegyike sorra kerül

Tesztelők “álma” Push-button testing Ehhez szükséges: 1.formalizálni a specifikációt: Formális Leíró Nyelvek (Formal Description Techniques – FDTs) használata, pl.: SDL, LOTOS, ASN.1) 2.Futtatható tesztsorozatot generálni –Algoritmikusan: CATG – nyitott probléma –Manuálisan

Teszt tervezési alapelvek Fekete doboz (black box) tesztelés –Csak a külső viselkedés ismert –Bemenetekkel gerjesztik és a hozzá tartozó helyes választ ellenőrzik –Pl: konformancia tesztelés Fehér doboz (white box) tesztelés –Ismert a kód felépítése, struktúrája –A program belső állapota (pl. változók) elérhető –Pl: modul gyártói tesztje Szürke doboz (grey box) tesztelés

Tesztesetek felépítése Előhang (preamble) –A rendszert a teszt kezdőállapotába viszi Teszt törzs (test body) –A teszt célt jelentő működés ellenőrzése Utóhang (postamble) –Végállapot ellenőrzés, alapállapotba vitel Eredmény: ítélet –Sikeres (pass) –Sikertelen (fail) –Eldönthetetlen (inconclusive)

Tesztkészletek tulajdonságai Alapos (sound): minden helyes működést elfogad –A megvalósítás helyes → az ítélet pass Kimerítő (exhaustive): minden lehetséges hibát detektál –A megvalósítás hibás → az ítélet fail Teljes (complete): egyszerre sound és exhaustive –Csak elméletben létezik Gyakorlati cél: a tesztkészlet sound legyen

Tesztelés típusai Basic, komponens Funkcionális Integrációs, smoke teszt Teljesítmény –Load, karakterisztika, robusztusság Megfelelőség (konformancia) Együttműködés (interoperability) Végpontok közötti (end to end) Regressziós

PUz PUy SW fejlesztés és tesztelés kapcsolata Analysis Requirements & Pre-study Coding-Review Basic testing Basic test Function testing Regression & function tests Modeling & Model verification MDA-based testing Integration & Verification Integration verification, conformance, system & load tests FOA Network integration & End-to-end tests PUx time space

Komponens v basic tesztelés Tipikusan fehér doboz teszt A fejlesztés utáni első lépés, a fejlesztő végzi Legalacsonyabb szintű tesztelés Komponensek, modulok külön-külön tesztelhetők –Minél hamarabb találjuk meg a hibát, annál olcsóbb javítani –Modul szinten nem annyira komplex a rendszer –Jó előkészítése az integrációnak Software Quality Rank (SQR)

Funkcionális tesztelés Annak ellenőrzése, hogy SW megfelel-e a specifikációjának Gerjesztés helyes és rossz adatokkal GUI tesztelés Dokumentáció tesztelés Installáció, upgrade tesztelése Általában regressziós tesztként futtatják egy részét

Integrációs tesztelés Modulok integrálása után végzik Modulok közötti interfészek és együttműködés ellenőrzése Egyszerű tesztek arra, hogy működik-e a rendszer az új modulok betöltése után –indítás –alap kommunikáció –általában ugyanazokat a teszteket futtatják a projekt során - automatizálni

Integration Centric Engineering (ICE) Egyszerre több modult szállítanak tesztelésre –Vízesés modell –Hagyományos sw fejlesztési módszer Mindig legyen működő SW verzió –Kisebb sw szállításokra bontani a fejlesztett SW-t –Könnyebb legyen az integrálás –Jobban működjön a tesztelés

Teljesítmény tesztelés Annak vizsgálata, hogy a rendszer hogy működik a valóságos környezetében Tesztelés forgalommal –Különböző forgalmi viszonyok mellett, forgalom modellek –Sok felhasználó szimulálása –Automatizálni kell –Időkorlátok meghatározása, kimérése, ellenőrzése Off-line, on-line Nagyon drága eszközök

Robusztusság tesztelés Stressz teszt, túlterhelésre tesztelés –Szűk keresztmetszetek beazonosítása –Hogyan tűri a rendszer a túlterhelést Viselkedés váratlan helyzetekben – mennyire robusztus a rendszer –Pl. Kártyák kihúzása

Hálózat Teljesítmény teszt konfiguráció Tesztelő Tesztelt rendszer Forgalom monitor Háttérterhelés generátor

Konformancia tesztelés Annak biztosítására hogy heterogén (több gyártó által gyártott) rendszerek együttműködjenek Szabványos interfészek tesztelése –Protokoll szabványok Szabványosított tesztelési eljárás (CTMF) Szabványosított teszt nyelv (TTCN) és teszt készletek Általában távközlési sw-ekre végzik

Együttműködés tesztelés Két különböző termék együtt tud-e működni a valóságban –Általában konformancia tesztelés után –Sok választható paraméter, biztosan jól vannak-e beállítva Sokszor szabványosítási szakaszban (IETF) vagy új technológiák bevezetésénél

Együttműködés teszt konfiguráció IUT Monitor Tesztelő

Végpontok közötti tesztelés Annak ellenőrzése, bemutatása, hogy a komplex rendszer működik végig a két felhasználó között Általában teljesítmény viszonyokat is vizsgálnak, karakterisztikus követelmények teljesülését ellenőrzik

Regressziós tesztelés Megismételt funkcionális tesztelés ha változtattunk valamit a SW-en –Hibajavítás után –Új funkció hozzáadása után –Nem rontottunk-e el valamit a régi kódban Automatizálni kell különben nagyon idő és munkaigényes

SW fejlesztés folyamata Követelmények összeállítása Rendszertervezés Implementálás Integrálás Funkcionális tesztelés Rendszer tesztelés Első alkalmazások fázisa A termék piacra bocsátása Karbantartás

Tesztelés - tények Távközlési szoftverek fejlesztési költségeinek több mint 50%-át a tesztelés teszi ki A tesztelés a hibákat tárja fel, nem lesz jobb tőle a szoftver Nem lehet 100% hibamentességig tesztelni A tesztelés végigköveti a teljes szoftver életciklust –Megéri automatizálni

Dinamikus tesztelés fázisai Tesztelés tervezése –Teszt célja –Módszere –Erőforrásai, eszközök Teszt definíció –Milyen teszt feladatokat kell elvégezni –A tesztelési folyamat pontos, megismételhető meghatározása Ha automatikus a tesztelés: a tesztek előállítása Teszt végrehajtás –Tesztkörnyezet felállítása, –Testsorozatok konfigurálása, végrehajtása, –Teszt eredmények, log-ok analizálása

Teszt menedzsment Általában bonyolultak a teszteléshez felhasznált eszközök, sorozatok Sok a teszt konfiguráció Fontos a teszt eredmények megjelenítése A log-ok, trace-ek elemzése Több ember végzi a tesztelést A tesztek és a tesztelt kódban megvalósított követelmények összekapcsolása Teszt progressz riportolás

Teszt környezetek Szimulált környezet –funkcionális tesztelésnél, –csak egyes SW modulokat tesztelünk –a tesztelt eszköz környezetét sw szimulálja –olcsóbb, gazdaságosabb Eredeti HW környezet –drágább –rendszer teljesítményének tesztelése

Teszt automatizálás A teszt futtatás mindig automatizálható Kérdés, mikor érdemes, milyen területen Fontos kiegészítője a tesztelés folyamatának Legtöbb hibát az automatikus tesztek írásakor találják

Miért automatizáljuk a tesztelést –Költségtakarékos –Hatékony, átgondolt, alapos tesztek –Pontosan meghatározott tesztek –Gyakran végrehajtható (regressziós tesztelés) –Összehasonlítható, megismételhető eredmények –Hatékonyan végrehajtható –Emberi erőforrást takarít meg, enélkül is futtatható pl. éjjel –Unalmas ismétlődő munkát küszöböl ki –Gyorsabb teszt végrehajtást tesz lehetővé (de meg kell írni a teszteket) –Ha egyszerre több tesztelő eszközt használunk –Terheléses tesztek

Mikor nem érdemes automatizálni a tesztelést Ha nem hajtható végre sokszor a teszt Ha kézi beavatkozás szükséges –Pl. HW módosítása Ha nem jó teszt eseteket automatizálunk Ha nem használható jól a teszt rendszer vagy nem tanuljuk meg használni Ha nincs meghatározva hogyan használjuk a projektben Ha nehéz a tesztek karbantartása, frissítése Ha nem értjük meg a rendszert amit tesztelünk

Teszt automatizálás új hangsúlyok Meg kell érteni jól a teszt eszköz működését –A teszt eszköz jól bővíthető legyen Teszt sorozat írásához programozói ismeretek is kellenek –Jól karbantarthatóra írni a teszteket Teszt előkészítés tovább tart mint a végrehajtás A tesztelt rendszer működését akkor is tudni kell ha a teszt sikeresen fut

Agilis SW fejlesztési módszerek A vevők igényeinek figyelembe vétele –Gyakori szállitás a vevőknek –Visszejelzések figyelembe vétele Lehetőség a gyors változtatásra fejlesztés közben Csak a vevőknek szükséges dolgokat fejleszteni Mindig a legfontosabb tevékenységen dolgozni Team munka, a csapat ért minden tevékenységhez Minőség biztositása –TDD, continuous integration

Agile Scrum product owner teamcustomer

TDD Test Driven Development Automatikus unit teszt Agilis fejlesztési módszertan része Közvetlenül a kód irása előtt irják meg a teszteket az új fejlesztési követelményeknek megfelelően –Kód változtatása előtt sikertelen a teszt –Új kód megirása után legyen sikeres –Automatikusan legyen újra futtatható pl. kód refaktorálás után

Test driven development

TDD előnyei Minden új feature tesztelésre kerül (100% teszt lefedés) Design for testability –A tesztelhetőséget és a tesztelés módját már a kód változtatása előtt át kell gondolni Minél egyszerűbb legyen a változtatás a kódon (Keep it simple, stupid) –csak annyit változtatni a kódon hogy a teszt lefusson Hibákat hamarabb megtalálják A teszt a kód specifikációját is adja Gyorsabb lehet a kód fejlesztés Nagyobb bizalom az új kódban –De későbbi tesztelés fázisba tartozó tesztekből sem kell kevesebb

Continuous integration Folyamatos minőség ellenőrzés A fejlesztett kódot gyakran „merge”-elik Kis teszt erőfeszités gyakran merge előtt –Elsősorban unit és integrációs tesztek –Gyakran TDD-vel együtt használják Build server, automatikus Continuous deployment –A kód mindig a vevőhöz szállitásra kész állapotban van