TTCN-3 alapú tesztrendszerek minőségi aspektusainak vizsgálata

Átírás

1 EÖTVÖS LORÁND TUDOMÁNYEGYETEM DOKTORI ÉRTEKEZÉS TÉZISEI TTCN-3 alapú tesztrendszerek minőségi aspektusainak vizsgálata Szerző: SZABADOS Kristóf Témavezető: Dr. Habil. KOVÁCS Attila Eötvös Loránd Tudományegyetem Informatika Doktori Iskola Vezetője: Prof. Dr. Erzsébet Csuhaj-Varjú Információs Rendszerek Program Vezetője: Prof. Dr. András Benczúr október 16.

2 1 1. fejezet Bevezetés Az első számítógépes program megírása óta a szoftver rendszerek mérete és komplexitása a velük szemben támasztott minőségi elvárásokkal együtt folyamatosan nőtt. Manapság közel 11 millió fejlesztő [1] készít szoftvert az élet minden területéhez. Szoftver segít eljutni az úticélunkhoz, kommunikálni emberekkel, vezérli az energia termelést, annak elosztását és fogyasztását. Szoftver segít a cégek irányításában, kereskedik a piacokon, vigyáz az egészségünkre. Ezeknek a rendszereknek különböző szintű minőségi elvárásokat kell teljesíteniük. A telekommunikáció területén öt kilences" (99,999%) rendelkezésreállás mindössze 5 perc 15 másodperc leállást enged évente beleértve a tervezett fejlesztéseket és javításokat is. A szoftvermérnökök a szükséges minőség biztosítása érdekében komoly erőfeszítéseket tesznek, például teszteket automatizálnak, miközben kezelik a teszteknek a tesztelt rendszerrel együtt növekedő méretét és komplexitását. A minőség iránti igény a telekommunikáció területén az ETSI 1 -t a TTCN-3 2 nyelv kifejlesztésére ösztönözte. Ez egy leíró (szkript) nyelv amit kommunikáló rendszerek szabványos megfelelőségének tesztelésére és az absztrakt teszteket a konkrét környezettel összekapcsoló felület specifikálására használnak Motiváció Bár a tesztek a leírásukra használt szabványos nyelvvel együtt nagyra és komplexre nőttek, a teszt szkriptek belső minőségét, komplexitását, szerkezetét és fejlődését korábban nem vizsgálták. Márpedig a nem megfelelő tesztelési infrastruktúra (csak az USA -ban) évente nagyjából 22, 2 és 59, 5 milliárd USD extra költséget eredményez [2]. A piacra kerülés előtti utolsó tesztelési időszak lerövidítésének egyik leghatékonyabb módja, amikor a tesztek és a termékek együtt fejlődnek. Így elvben, amikor az első teljes termék verzió elkészül, már csak tesztelni kell. A telekommunikációs rendszereknél ez azt jelenti, hogy a tesztelők például a végpontok közötti teszteket néha hónapokkal, vagy évekkel a tesztelendő rendszer teljes elérhetősége előtt elkezdik készíteni. Az ilyen tesztek helyességének ellenőrzése a teljes termék elérhetősége előtt nem lehetséges, utána pedig hatalmas üzleti nyomás alatt történik. Miközben a feltárt minőségi problémáik késleltethetik a termék piacra kerülését. 1 European Telecommunications Standards Institute 2 Testing and Test Control Notation - 3

3 fejezet 1. Bevezetés 2 A TTCN-3 alapú teszt rendszerek tervezői évekig korlátozott eszköztámogatással dolgoztak, gyakran anélkül, hogy megnézhették volna a rendszerük valós arhitektúráját. Álltalános gráf elrendező algoritmusok szabadon elérhető arhitektúra megjelenítők és elemzők nem illeszkedtek jól a napi ipari folyamatokhoz. Az eddig elérhető eszközök nem adtak támogatást az arhitekturális problémák feltárásához vagy annak a megállapításához, hogy mi a következő teendő velük. Az iparban skálázódási problémák miatt sok algoritmust lehetetlen interaktívan használni [3]. Az sem mindig egyértelmű, hogy a CASE termékek kit céloznak meg: a rendszertervezőknek alig van idejük a részleteket vizsgálni, a tesztelőknél hiányozhat a teljes rendszer átlátása. Mivel a nagy méretű teszt rendszerek (még) nem gyakoriak, keveset tudunk az irányításukról. Nem igazán ismert, hogy a különböző menedzsment módszerek és szervezeti változások hogyan hatnak rájuk, hogyan fejlődnek és hogyan lehet jól kezelni a komplexitásuk. Csak anekdoták vannak arról, hogy fejlesztői és tesztelői pozíciókra hogyan kell a legalkalmasabb jelöltet kiválasztani, és nem biztos, hogy a kiválasztottak alkalmazhatóak lesznek teszt automatizálási munkáknál (ahol az alkalmazottaknak tesztelőként kell gondolkodniuk miközben komplex automatikus teszteket fejlesztenek). Mindehhez társul, hogy még maga a TTCN-3 nyelv is fejlődik Alkalmazott módszerek A dolgozat célja olyan eszközök, módszerek, és tudásbázis létrehozása volt ami segíti a magas minőségű tesztrendszerek tervezését és készítését. Megvizsgáltuk az ipari partnerünkél található hibajegyeket, az elérhető eszközöket, áttekintettük a megfelelő szakirodalmat, hogy olyan szabályokat találjunk amikkel automatikusan lehet TTCN-3 tesztek minőségét ellenőrizni, segítve ezzel a tesztelők munkáját. A Delphi [12] módszer segítségével feltártuk a talált problémák valós javítasi költségét. Hálózatok vizsgálatainál megismert módszerek alapján nagy tesztrendszerek architektúráját elemeztük, és két olyan új megjelenítő elrendezést terveztünk, amelyek jobban illeszkednek a rendszer tervezők napi munkájához. Hosszabb időskálán egy nagy tesztrendszer fejlődését követtük nyomon abból a célból, hogy megértsük az ipari teszt rendszerek minőségi változásait. Kérdőíves kutatást végeztünk a Magyarországon jelenlévő cégeknél dolgozó IT szakemberek körében, amelyben felmérjük, az IT szakemberek felkészültségét szerepeik szerint (menedzser, tesztelő, fejlesztő, szakíró), hogy honnan tanulnak, hogyan gondolnak a cégeiknél használt folyamatokra és a szoftver fejlesztési negatív mintákra. A munkánk során a nyilt forráskódú Titan [4] 3 eszközt egészítettük ki, hogy minél szélesebb ipari és szabványosítási közönséget érjünk el. Minden általunk fejlesztett funkcionalitás Titanium néven a Titan eszköz részeként szabadon elérhető. 3 A Titan az Ericsson nyílt forráskódú TTCN-3 eszközkészlete, több mint 4000 belső felhasználóval

4 3 2. fejezet Eredmények A dolgozatban úgy tekintettünk a tesztekre, mint szoftver termékekre, a TTCN- 3-ra mint programozási nyelvre. A TTCN-3-ban írt szoftvertermékeket oly módon elemeztük, hogy összehasonlíthassuk őket normál szoftvertermékekkel A tesztek minősége Három forrás alapján terveztünk eszközt a TTCN-3 code smell-ek méréséhez 1. Elemeztük az ipari partnerünknél vezetett, a termékek statikus átvizsgálása során (review) talált problémák és hibajegyek adatbázisait. Ezek olyan kód minőséget érintő problémákat is tartalmaztak, amelyek más TTCN- 3 projektnél is előfordulhatnak. Átnéztük a PMD [5], FxCop [6], Checkstyle [7], FindBugs [8], xunit Patterns [9], TRex [11] eszközök szabályait és Martin Fowler refaktorálásról szóló könyvét [10]. Csak néhány olyan szabályt sikerült találni ami TTCN- 3 -ra is alkalmazható. Megvizsgáltuk a Titan szemantikus ellenőrző és kódgeneráló algoritmusait olyan helyzeteket keresve, amelyek alacsony minőségű vagy nem hatékony kód generálását eredményezik. Ezek alapján összeállítottuk azon code smell szabályok listáját, amelyek a TTCN-3 nyelvhez illeszkednek. Az ipari partnerünk professzionális TTCN-3 szakértőivel minden szabályt megvitattunk és az ISO/IEC 9126, valamint az ISO/IEC minőségi modellek szerint kategorizáltunk. Tézis 1: TTCN-3 tesztrendszerek minőségének méréséhez code smell-eket definiáltam, majd nemzetközi szoftverminőség szabványoknak megfelelően kategorizáltam őket. Módszert adtam TTCN-3 alapú tesztrendszerek minőségi jellemzéséhez. A definiált a code smell-ek egy implementált részhalmazával elemeztük a 2014 januárjában a -on elérhető összes, továbbá az ipari partnerünknél elérhető néhány tesztrendszert. (A weboldal két szabványosítási testület, az ETSI és 3GPP 2 által készített tesztsorozatokat listázza). 1 A forráskód olyan állapota ami nem feltétlenül hibás, de mélyebb tervezési hibára vagy felreértésre utalhat. 2 3rd Generation Partnership Project

5 fejezet 2. Eredmények 4 Vizsgálataink során számos minőségi problémát találtunk. Mindez az automatikus kódminőség ellenőrzők létjogosultságát támasztja alá. Tézis 2: Számos minőségi problémát találtam ipari és szabványos TTCN-3 tesztsorozatokban. A Delphi módszert követve az ipari partnerünk szakértőinek segítségével becslést adtunk egy-egy code smell előfordulás javítási idejére. A szakértői csapatban volt tesztrendszer-tervező, voltak tesztrendszer fejlesztők valamint karbantartást és támogatást végző szakemberek is. A becsléseket használva azt kaptuk, hogy a szabványos tesztsorozatok jelentős technikai tartozást halmoztak fel. Átlagos nehézségű eseteket feltételezve (amikor minden előfordulás átlagosan nehezen javítható) a projektek technikai tartozása 3 több emberévnyi munka. Tézis 3: Elemeztem és megbecsültem a code smell-ek által jelzett minőségi problémák javításának költségét. A tézisekhez kapcsolódó publikációk: [19, 16, 17, 18, 26] 2.2. A tesztek arhitektúrája Tizenegy TTCN-3 tesztprojekt struktúráját elemeztük ipari és szabványos rendszerek esetében. Minden TTCN-3 modulra 4 megmértük, hogy hány másikat importál 5 és őt hány másik importálja. A méréseink szerint nagy projektekben a bemeneti fokszámeloszlás logaritmus trendet, a kimeneti fokszám hatványeloszlást mutat. TTCN-3 esetén a module import gráf átmérője logaritmus függvénye a projektben található modulok számának. Ez egybeesik mások szoftvergráfok kis-világ és skálafüggetlen tulajdonságokkal kapcsolatos megfigyeléseivel (lásd például [13]). Tézis 4: Azt találtam, hogy nagy méretben a TTCN-3 tesztsorozatok kisvilág tulajdonságokat mutatnak és skálafüggetlenség irányába fejlődnek. A TTCN-3 architektúrák megjelenítéséhez két gráfelrendező algoritmust implementáltunk. Elemeztük a 2016-ban a oldalon elérhető összes (40) TTCN-3 projektet. Számos problémát találtunk ezen tesztsorozatok architektúrájában. Sok esetben találtunk a rendszer többi részétől független modulokat. Számos tesztsorozatban volt olyan legfelső szintű 6 modul, amire valószínűleg nincs szükség. Találtunk egy olyan tesztsorozatot, ahol import körök voltak a modulok között. 3 Olyan fejlesztés közben elmaradt munka, amit később meg kell csinálni 4 TTCN-3 fordítási egysége 5 Közvetlen hivatkozás egy másik modulra TTCN-3 -ban 6 Olyan module ami importál másokat, de őt más nem importálja

6 fejezet 2. Eredmények 5 Könyvtár szinten számos tesztsorozatban találtunk import kört. Kérdőíves felmérésünk szerint a tesztrendszer tervezők hasznosnak találták az eszközünket. Eszközünkkel két rendszertervező a talált import körök 57%-át javítva 3%-ot gyorsított egy tesztrendszer fordítási idején. Tézis 5: Az általunk fejlesztett eszköz alkalmazásával feltártam, hogy a TTCN-3 tesztrendszerek arhitektúrális problémákat tartalmaznak, és a vizualizációm más módszereknél könnyebben detektálhatóvá teszi ezeket. A tézisekhez kapcsolódó publikációk: [15, 20] 2.3. A teszt rendszerek fejlődése Ipari partnerünknél két tesztrendszer fejlesztésének/fejlődésének 5 évét követtük nyomon. A megfigyelt időszak napi bontásában kinyertük a rendszer aktuális állapotát mutató forráskódot és megmértük a code smell-ek számát. Meghatároztuk a különböző code smell-ek fejlődési trendjei közti korrelációkat, és a trendeket összevetettük a projekt történetének fontosabb eseményeivel. A megfigyeléseink az alábbiakban összegezhetőek: A vizsgált tesztrendszerek fejlesztésének integrálása (merge) hatással volt a mért code smell-ek számának változására. A mért code smell-ek számát nem befolyásolta jelentősen a continuous integration bevezetése, sem a fejlesztési módszertan megváltozása, sem pedig a technikai és nem technikai vezetők változása. A megfigyelt tesztrendszerben a code smell-ek jól becsülhető trendeket követtek a rendszer fejlődése folyamán. Tézis 6: Két nagy méretű TTCN-3 tesztrendszer egyesítésének megfigyelése során azt találtam, hogy a belső minőség változása a rendszer fejlődése során más programozási nyelveknél és termékeknél megfigyeltekhez hasonlóan jól becsülhető mintát követ. A tézishez kapcsolódó publikáció: [22] 2.4. A minőség emberi oldala A szoftverfejlesztési projektekben dolgozók között kérdőíves felmérést készítettünk, hogy megértsük, a különféle szerepeket (menedzser, fejlesztő, tesztelő, szakíró) betöltő IT alkalmazottak mit tudnak, honnan tanulnak, hogyan gondolkoznak a folyamataikról és a szoftverfejlesztésben előforduló negatív mintákról. A 456 beérkezett válasz alapján azt láttuk, hogy a szoftverfejlesztő vállalatok általában nagyok, a mérnökök az aktuális szerepükben kevés tapasztalattal (kevesebb mint 2 év) rendelkeznek. A kérdőívünk szerint legtöbben az Internethez, kollégákhoz vagy könyvekhez fordulnak az új ismereteket

7 fejezet 2. Eredmények 6 megszerzéséhez. A megkérdezettek mind a fejlesztői, mind a tesztelői gondolkodásmódot nagyon fontosnak találták a szoftverfejlesztési projektekben. Megfigyeléseink szerint a különböző szerepekben dolgozó emberek gondolkozása nagyon hasonló. A leghasonlóbbak a tesztelők és fejlesztők válaszai voltak. Tézis 7: Egy nagy mintán történő kérdőíves vizsgálatom azt mutatta, hogy a fejlesztők és a tesztelők gondolkodásmódja hasonló. Kicsit precízebben azt mutattam meg, hogy a tesztrendszerek belső minőségének emberi tényezői nagyon hasonlítanak a szoftverfejlesztési projektekben mérhető emberi tényezőkhöz. A tézishez kapcsolódó publikációk: [21, 25] 2.5. Összefoglalás A nagy méretű és komplexitású ipari szoftver termékek minőségének biztosítása nagy méretű és komplexitású tesztrendszereket igényel. Azonban a szoftvertermékekkel szemben, a tesztrendszerek minőségével eddig még nagyon kevés kutatás foglalkozott. A dolgozatban a tesztekre, mint szoftver termékekre, a TTCN-3 nyelvre mint programozási nyelvre tekintettünk. Igy a TTCN-3 -ban írt tesztek minőségét, mint normál szoftver termék minőséget elemeztük. Ismereteink szerint az elsők között hívtuk fel a figyelmet az ipari és szabványos tesztekben található szoftverminőségi (Code Smell és arhitekturális) problémákra. Ismereteink szerint elsőként mutattunk rá, hogy a teszt rendszerek és szoftver rendszerek nagyon hasonlóan fejlődnek és nagyon hasonló tulajdonságú arhitektúrákat vesznek fel, illetve közelítenek. A kérdőíves vizsgálatunk azt mutatta, hogy a fejlesztők és tesztelők gondolkodásmódja nagyon hasonló. Ismereteink szerint mi vizsgáltuk először az IT emberi tényezőit ebből a szempontból.

8 7 Irodalomjegyzék [1] A. Avram: IDC Study: How Many Software Developers Are Out There?, 2014, IDC-software-developers, utolsó ellenőrzés: 2017 Január. [2] G. Tassey: The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002, Final report, Prepared by RTI for the National Institute of Standards and Technology (NIST), documents/director/planning/report02-3.pdf, utolsó ellenőrzés: 2017 Január. [3] S. Hachul, M. Junger: Large-Graph Layout Algorithms at Work: An Experimental Study, Journal of Graph Algorithms and Applications, Vol. 11, No. 2, 2007, pp DOI: /jgaa [4] TITAN, utolsó ellenőrzés: 2017 Január. [5] PMD, utolsó ellenőrzés: 2017 Január. [6] FxCop, utolsó ellenőrzés: 2017 Január. [7] Checkstyle, utolsó ellenőrzés: 2017 Január. [8] FindBugs, utolsó ellenőrzés: 2017 Január. [9] G. Meszaros: xunit Test Patterns: Refactoring Test Code, Addison-Wesley, ISBN-10: , ISBN-13: [10] M. Fowler: Refactoring: Improving the Design of Existing Code, 1999, Addison- Wesley Longman Publishing Co. Inc., Boston, USA. ISBN-10: , ISBN-13: [11] TRex, utolsó ellenőrzés: 2017 Január. [12] L. Helmer: Analysis of the future: The Delphi method, RAND Corporation, 1967, utolsó ellenőrzés: 2017 Január. [13] R. Cohen and D. Hevlin: Scale-Free Networks are Ultrasmall, Physical Review Letters, Vol. 90/5, , PhysRevLett , utolsó ellenőrzés: 2017 Január. [14] Java Universal Network/Graph Framework, utolsó ellenőrzés: 2017 Január.

9 IRODALOMJEGYZÉK 8 Saját cikkek, konferencia előadások, poszterek [15] K. Szabados: Structural Analysis of Large TTCN-3 Projects, In Proceeding Of Testing of Software and Communication Systems, 21st IFIP WG 6.1 International Conference, TESTCOM 2009 and 9th International Workshop, FATES 2009, Eindhoven, The Netherlands, November 2-4, Lecture Notes in Computer Science: Testing of Software and Communication Systems, Springer, 2009, pp ISBN: , DOI: / _19 [16] K. Szabados and A. Kovács: Test software quality issues and connections to international standards, Acta Universitatis Sapientiae, Informatica, 5/1, 2013, pp DOI: /ausi [17] K. Szabados and A. Kovács: Advanced TTCN-3 Test Suite validation with Titan, In Proceedings of the 9th International Conference on Applied Informatics (ICAI), Vol. 2, 2014, pp DOI: /ICAI [18] K. Szabados and A. Kovács, Technical debt of standardized test software, In Proceedings of IEEE 7th International Workshop on Managing Technical Debt (MTD), Bremen, 2015, pp DOI: /MTD [19] K. Szabados and A. Kovács, Up-to-date list of code smells, inf.elte.hu/~attila/testingatscale.htm, last visited: January, [20] K. Szabados, A. Kovács, G. Jenei and D. Góbor: Titanium: Visualization of TTCN-3 system architecture, in Proceedings of IEEE International Conference on Automation, Quality and Testing, Robotics (AQTR), Cluj-Napoca, Romania, 2016, pp DOI: /AQTR [21] K. Szabados and A. Kovács: Knowledge and mindset in software development how developers, testers, technical writers and managers differ a survey, 11th Joint Conference on Mathematics and Computer Science (MACS), Eger, Hungary, Állapota: publikálásra elfogadva. [22] K. Szabados and A. Kovács: Internal quality evolution of a large test system an industrial study, Acta Universitatis Sapientiae, Informatica, 8/2, 2016, [23] K. Szabados: Creating an efficient and incremental IDE for TTCN-3, 10th Joint Conference on Mathematics and Computer Science, Cluj-Napoca, In Studia Universitatis Babes-Bolyai, Informatica, Volume LX, Number 1, 2015, pp [24] K. Szabados and A. Kovács: Developing and Testing at Large Scale, 5th Annual International Conference of the Hungarian Software Testing Forum (HUS- TEF), Budapest, Hungary, (Talk) [25] K. Szabados: Thinking/mindset of testers is the closest to that of developers, 6th International Conference of the Hungarian Software Testing Forum (HUSTEF), Budapest, Hungary, (Poster)

10 IRODALOMJEGYZÉK 9 [26] K. Szabados, Gy. Réthy: Test Software Quality Through Software Metrics, 1st User Conference on Advanced Automated Testing (UCAAT 2013), Paris, (Poster) [27] K. Szabados, A. Kovács: Test systems, software systems. Is there a difference?, 3rd User Conference on Advanced Automated Testing (UCAAT 2015), ETSI, Sophia Antipolis, (Talk)