Távközlési szoftverek Bevezetés Dibuz Sarolta Sarolta.Dibuz@ericsson.com

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) Egységesség (uniformity) 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: formalizálni a specifikációt: Formális Leíró Nyelvek (Formal Description Techniques – FDTs) használata, pl.: SDL, LOTOS, ASN.1) Futtatható tesztsorozatot generálni Algoritmikusan: CATG – nyitott probléma Manuálisan A protocol is a set of rules that governs the communication between entities in different systems. Protocols define format (syntax), order of messages sent and received among network entities, as well as actions taken on message transmission or reception (behaviour). Behaviour of the protocols can be defined using natural language (e.g. English) or some formal description technique. Examples for the latter: SDL, Estelle and Lotos. They are compilable specification languages. None of them has outweighed the others. SDL: Specification & Description Language. (ITU-T Z.100-Z.109) Most popular in the industry. Lotos: Language of Temporal Ordering Specifications (ISO8807) is widely used in the academic world. LOTOS is based on communicating processes. Estelle (ISO9074) is based on extended finite automata.

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

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

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

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

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

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ó Tesztelő Monitor Tesztelő IUT IUT

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

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

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 Target 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 Target környezet 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 sikeres 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 tevekenységen dolgozni Team munka, a team ert minden tevekneységhez Minőség biztositása TDD, continuous integration

Agile Scrum

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 kod specifikációját is adja Gyorsabb kód fejlesztés Nagyobb bizalom az új kódban De későbbi tesztelés fázisba tartozó tesztekből sem kell kevesebb