Távközlési szoftverek Bevezetés

Az előadások a következő témára: "Távközlési szoftverek Bevezetés"— Előadás másolata:

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

2 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

3 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

4 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

5 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!

6 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

7 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

8 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.

9 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

10 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)

11 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

12 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

13 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

14 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)

15 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

16 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

17 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

18 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

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

20 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

21 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

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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 Agile Scrum

34 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

35 Test driven development

36 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