Informatika | Tesztelés, Minőségbiztosítás » Farkas Zsuzsa - Tesztelési módszertan bevezetése egy nagyvállalat heterogén IT környezetébe

Tesztelési módszertan bevezetése egy nagyvállalat heterogén IT környezetébe esettanulmány Farkas Zsuzsa Alerant Zrt. farkas.zsuzsanna@aleranthu Tartalom A feladat ◼ A tesztelés egy IT-t használó szervezet életében ◼ A környezet – a tesztelendő IT rendszerek ◼ A kihívások A TestLab projekt ◼ Célkitűzések ◼ A projekt áttekintése Automatikus tesztelés Tesztmodellezés Összefoglaló: eredmények, problémák és további feladatok 2. A feladat 3. A tesztelés egy IT-t használó szervezet életében IT üzemeltetésért felelős IT rendszerek, adatbázisok, infrastruktúra Fejlesztők 4. Felhasználók IT méret és bonyolultság ◼ Egy nagyvállalati üzletág teljes számítógépes rendszere ◼ A teljes rendszer sok alrendszerből/modulból áll ◼ Több (nem egyazon technológiájú) adatbázis; egy-egy adatbázist több rendszer is használ ◼ Adatbázisok többezer táblával, adatbázisok sok millió adattal ◼ Az

alrendszerek/modulok között bonyolult kapcsolatok léteznek ◼ Nagyszámú felhasználó, vállalaton belül és kívül (több tízezer) ◼ A vállalat különböző szervezeteinek elvárásai eltérnek egymástól ◼ Bonyolult fejlesztői társadalom (belső IT fejlesztői szervezet és szerteágazó alvállalkozói kör) 5. Az IT mint ‘élő’ szervezet ◼ A teljes IT rendszer soha sincs készen, állandóan változik/fejlődik: ◼ új üzleti igények ◼ változások a szervezet életében (két vállalat összeolvadása, stb.) ◼ áttérés új technológiákra ◼ szükségtelenné vált részektől (előbb-utóbb) meg kell szabadulni ◼ . ◼ A változtatások nem veszélyeztethetik az üzletmenetet - menet közben kell kereket cserélni . 6. Példa: egy tipikus változtatás B A C ◼ Két vállalatnál a (majdnem) ugyanazt a feladatot az A és a B rendszer látta el ◼ A két vállalat egyesülése után a B rendszer veszi át a feladatot ◼ Az A

rendszer bizonyos speciális mellékfeladatait a B rendszer nem támogatja, ezek kiváltására egy új C rendszer kifejlesztetése mellett döntött a vállalat ◼ 2006 végéig az A rendszer van használatban, 2007-től a B és a C rendszerek: ◼ a B és a C rendszer az A rendszer év végi adattartalmával induljon 2007 elején 7. A tesztelés szerepe ◼ A rendszerek hibátlan működése fontos mind a vállalat működése, mind marketing szempontból ◼ Az egyes szereplőknek különbözőek az elvárásaik, feladataik: ◼ a felhasználók: a saját speciális feladataik IT támogatása ◼ a fejlesztők: saját feladataikra koncentrálnak ◼ fejlesztői teszt ◼ üzemeltetés: az IT egésze ◼ az üzemeltető akkor tudja a felelősséget vállalni, ha megfelelő „bizonyíték” áll rendelkezésre, hogy az egyes alkalmazások „jók” és a jó rendszerekből konzisztens egész áll össze ◼ A tesztelés az IT rendszer folyamatok jó működése

fenntartásának alapvető eszköze 8. Heterogén fejlesztési technológia A rendszerek felhasznált technológia szerint több csoportra bonthatóak: ◼ a mag: Centura alapon fejlesztett, számos modulból/alrendszerből álló üzletági rendszer ◼ Webes/Java-s technológiával készülnek az új funkciókat megvalósító ún. webes alrendszerek ◼ Egyes alrendszerek Delphi-s felületet használnak ◼ Saját, önálló felülettel rendelkezik a ClarifyCRM A rendszerek közti interfészek technológiája is heterogén: ◼ Adatbázison keresztül, TIBCO, . A technológiák sokrétűsége komoly nehezítő tényező a tesztelésben. 9. Fejlesztések/változtatások – mikor kell tesztelni? ◼ A vállalatnak sok működő, kész rendszere van, amelyekhez azonban gyakorta érkeznek változtatási és javítási igények ◼ A változtatási igények általában több rendszert érintenek ◼ A „klasszikus” Centura-modulok nagy része folyamatosan kiváltásra

kerül Web/Java alapon történő fejlesztéssel ◼ A rendszer új alrendszerekkel/modulokkal terjesztődik ki ◼ Fejlesztői teszt/ Átvételi teszt – egy-egy fejlesztési feladat letesztelése ◼ Üzembehelyezési teszt: nem elég csak az új részeket tesztelni – azt is kell ellenőrizni, hogy nem romlottak el a régi dolgok ◼ Folyamatos üzemeltetői teszt – ellenőrizni a spontán korróziót . 10. Kihívások – üzembehelyezési teszt ◼ Egyre nagyobb és bonyolultabb IT rendszer ◼ Heterogén fejlesztési technológiák ◼ A rendszerek között heterogén módon megvalósított interfészek ◼ A fejlesztés is széttagolva, több részleg/beszállító által történik ◼ Változtatási igények, amelyek több rendszert is érintenek: ◼ shipment: egyszerre kibocsájtott változtatások: új modulok, régi rendszerek új változatai, hibajavítás, . ◼ egyszerre kell bevezetni, ◼ előre meghatározott, az üzemeltetőkkel, felhasználókkal

egyeztetett időben ◼ Adatmigrálás egy másik rendszerből Korlátozott idő a változások bevezetésére 11. A tesztelés szervezése szerepkörök kibocsájtás – üzembehelyezési folyamat Szoftverfejlesztő Üzemeltető Alkalmazás manager Teszt manager Teszt tervező/fejlesztő Tesztelő 12. az üzemeltető akkor tudja a felelősséget vállalni, ha megfelelő „bizonyíték” áll rendelkezésre, hogy az alkalmazás „jó” A hagyományos tesztelési módszer ◼ Az egyes rendszereket függetlenül tesztelték ◼ Kézi tesztelés ◼ Automatikus tesztelés ◼ SQA robottal ◼ ez egy adott fejlesztési technológiához kötődött ◼ a heterogén rendszerből csak egy részhalmazra volt alkalmazható Ezzel a módszerrel már nem lehetett megbírkózni a feladattal. 13. A TestLab projekt ◼ A TestLab projektet a vállalat vezetése 2004-ben indította, a fenti problémák megoldására. ◼ A fő célkitűzés: ◼ minél jobb minőségű

shipmenteket (változtatásokat) kibocsájtani, ◼ az átadás/bevezetés hátráltatása nélkül ◼ a cég munkatársainak belső fejlesztése, az Alerant Zrt. munkatársainak részvételével 14. A TestLab projekt ◼ Célkitűzések: ◼ a tesztelés alapelveinek általánossá tétele ◼ modul- és integrációs tesztek, a hangsúly az integrációs tesztelésen ◼ dedikált tesztkörnyezet ◼ automatikus tesztelés ◼ a tesztesetek modellezése ◼ vállalati szabványok ◼ a tesztelési folyamat illesztése az üzembehelyezési folyamathoz ◼ Korlátozott idő a tesztelésre, a minőség feladása nélkül - csak számítógépes támogatással oldható meg: ◼ automatikus tesztelés (tesztrobot) a tesztek gyors lefuttatásához ◼ modellezésen alapuló módszertan a tesztek gyors megírásához, karbantartásához 15. Általános tesztelési alapelvek ◼ Ad-hoc tesztelés helyett szisztematikus, a rendszerek összes fontos aspektusát lefedő tesztelés

◼ A tesztelési lépések formalizált leírása ◼ A tesztek legyenek megismételhetőek ◼ A tesztelési lépésekhez a teszt-adatokat is rögzíteni kell ◼ A tesztelési lépések újrafelhasználhatósága 16. Számítógépes támogatás – a SW eszközök kiválasztása ◼ Tesztelési folyamatok modellezéséhez: a fejlesztés során alkalmazott modellezőeszköz: ◼ a vállalatnál a Rational eszközeit használják szabványos módon ◼ Automatikus tesztelés: a tesztelendő rendszerek fejlesztési technológiájához illeszkedjen ◼ Rational Robot lenne a természetes választás, de: ez nem tudja kezelni a Centura alapú rendszereket ◼ A Mercury cég Winrunner eszköze 17. Dedikált tesztkörnyezet A tesztelés hitelességének biztosítását szolgálja ◼ nagyon hasonlítson az éles környezetre, de attól különböző ◼ a tesztelés megismételhető ◼ a fejlesztés/hibajavítás élesen különüljön el a teszteléstől – a

tesztkörnyezethez a fejlesztők nem férhetnek hozzá 18. Tesztadatok és teszt-adatbázis ◼ A teszt legyen megismételhető ◼ A tesztesetek formalizálva legyenek ◼ ne számítsunk arra, hogy a rendszert jól ismerő ember végzi a tesztelést ◼ olyan részletesen le kell írni a teszt-eseteket, hogy azt a leírása alapján különösebb előképzettség nélkül végre lehessen hajtani ◼ Milyen módszerek léteznek? ◼ az adatbázist újraépítjük ◼ a tesztelés hatását „takarítsuk ki” a teszt-adatbázisból ◼ a tesztadatok megadása extenzió helyett intenzió alapon: Például: Új ügyfél létrehozása: ◼ a tesztadat extenzióval való megadása: konkrét fizikai szintű definíció: » Név: Kovács János » . ◼ a tesztadat intenzióval való megadása: absztrakt szintű definíció: ezzel a konkrét adattal csak egyszer hozzunk létre egy olyan nevet, amely még nem szerepel az futtathatjuk le a adatbázisban tesztet ne a nevet adjuk

meg, hanem a generálás algoritmusát 19. Automatizált tesztelés 20. Automatizált tesztelés Az automatizált tesztelésről általában ◼ Lényege ◼ Teszt-szkriptek ◼ Előnyei Automatizált tesztelés a WinRunner-rel ◼ A szkript nyelv ◼ A felületkezelés módja ◼ Adatbázis-kapcsolat ◼ Ellenőrzések Vállalati szabványok ◼ A szerkezetre vonatkozó elvek és konvenciók ◼ Előre definiált műveletek 21. Automatizált tesztelés Az automatizált tesztelés a tesztelési feladatok elvégeztetése egy specializált alkalmazással – a felhasználó (tesztelő) tevékenységét egy számítógépes rendszer szimulálja: ◼ a tesztelendő rendszer GUI felületén adja meg a teszt-adatokat és tesztelendő funkciókat ◼ a megadott pontokon ellenőrzi, hogy az alkalmazás az elvárt módon viselkedik-e, az elvárt adatokat adja-e vissza 22. Automatizált tesztelés – teszt szkriptek Teszt szkript – egy teszt-eset formalizált,

automatikusan végrehajtható leírása: A tesztelendő alkalmazás Az alkalmazás teszt-terve Teszt szkriptek automatikusan végrehajtható manuálisan végrehajtható 23. A tesztelési feladat „megtanítása” A tesztelési feladat megtanítása a tesztelést végző rendszernek: ◼ a rendszer megjegyzi az egyszer végrehajtott lépéseket, és képes azokat megismételni (pl. mint az Excel makró rekordálása) ◼ a rendszer speciális szkript-nyelvvel rendelkezik, amelyen meg lehet fogalmazni a végrehajtandó lépéseket A tesztelendő alkalmazás automatikus rögzítés Teszt szkript programozás 24. Előnyök Gyors ◼ a tesztelési feladatok nagyságrendekkel gyorsabban végrehajthatók ◼ napi 24 órában működtethető Megbízható ◼ Precízen végrehajtja a folyamatot ◼ Kitartóan végzi az egyhangú munkát ◼ Az emberi hiba kiküszöbölhető Megismételhető ◼ egyszeri munkát igényel, de sokszor végrehajtható ◼ akárhányszor

iterálható ◼ többféle környezetben (pl. operációs rendszer) lefuttatható ugyanaz a teszt Programozható Nagyfokú lefedettséget tud biztosítani Újrafelhasználható 25. . és hátrányok ◼ Nem kreatív, nem önfejlesztő ◼ Jelentős munkát igényel a kifejlesztése 26. WinRunner A cég által választott eszköz: Mercury WinRunner - sokrétű, egyszerűen kezelhető, széles körben elterjedt. Előnyei: ◼ Könnyen érthető szkriptnyelv ◼ Objektum orientált ◼ Szövegalapú fájlok ◼ Környezeti rugalmasság (pl. Citrix támogatás) ◼ Gyors riportkezelés Nehézségek: ◼ Cégen belül új eszköz ◼ Nem kompatibilis az eddigi eszközzel 27. WinRunner Add-in – többféle technológiát támogat 28. Okos szkriptek A szkript a WinRunner saját nyelvén (TSL = Test Script Language) írt program. Miért okos? ◼ Adatok lekérdezése és generálása ◼ A felület elkülönül a folyamattól ◼ Az általános célú részek ki vannak

emelve ◼ A folyamatok részfolyamatokból felépíthetők Mit érünk el ezzel: ◼ Könnyű karbantartani ◼ Egyszerűen bővíthető ◼ Sokszor futtatható ◼ Modellezhető 29. A szkriptek rögzítési módjai Analóg: a felhasználó által elvégzett műveletek fizikai szinten, a billentyűzet és az egér mozgásának a pontos koordináták rögzítésével történik: pl. egy adott képernyőn az OK gomb megnyomásának leírása: ◼ az egérrel 112,300 koordinátára move locator track(. ◼ az egér bal gombjának megnyomása mtype(. ◼ az egér bal gombjának elengedése Környezetérzékeny – objektum-alapú: a felhasználó által elvégzett műveletek leírása az alkalmazás GUI objektumainak segítségével történik: button press(”OK”) 30. Az objektum alapú felületkezelés előnyei ◼ rugalmas: nem érzékeny a felületet érintő programmódosításra ◼ a szkript többféle környezetben is végrehajtható ◼ az ilymódon leírt

műveletek könnyen érthetőek 31. A tesztelés fázisai ◼ A tesztelendő alkalmazás objektumainak „megtanítása” a WinRunner-nek ◼ A teszt szkriptek létrehozása ◼ A teszt szkriptek tesztelése ◼ Hibakeresés/ellenőrzés a teszt szkriptek végrehajtásával ◼ A teszt eredmények ellenőrzése ◼ A felfedezett hibák jelentése 32. Technológiai alapok – kapcsolat a környezettel A WinRunner a következő pontokon kapcsolódik a rendszerhez: ▪ ▪ ▪ ▪ Felhasználói felület Adatbázis Filerendszer . A szkript egyrészt a felhasználó viselkedését szimulálja, másrészt adatot generál és ellenőrzi az elvárt eredményeket. 33. Adatbázis kapcsolat A WinRunner ◼ ODBC-n keresztül kapcsolódik az adatbázishoz. ◼ Egyszerű SQL végrehajtására alkalmas ◼ A lekérdezések eredménye többféleképpen is feldolgozható Ezek segítségével a szkript képes ◼ ◼ ◼ 34. tesztadatot generálni, végrehajtani a folyamatot, és

az eredményt ellenőrizni mind a felületen, mind az adatbázisban adatintegritás ellenőrzése A WinRunner szkriptnyelve: TSL = Test Script Language GUI akciók: ◼ set window ◼ button press ◼ obj type ◼ obj mouse click ◼ menu select item ◼ . 35. A WinRunner szkriptnyelve: TSL = Test Script Language Ellenőrzések: ◼ GUI ◼ ob j check gui ◼ win check gui ◼ . ◼ adatbázis ellenőrzés ◼ file tartalmának ellenőrzése: file compare( "file1", "file2", "differences file" ); ◼ reguláris kifejezések 36. A WinRunner szkriptnyelve: TSL = Test szkript Language Programozási nyelvi konstrukciók: ◼ Változók, tömbök - értékadás ◼ Vezérlőutasítások ◼ Hibakezelés ◼ Függvénydefiniálás – hívás ◼ Külső (C) függvények hívása ◼ . 37. Példa – egy WinRunner szkript részlete Álljunk rá a „tbl3Country” azonosítójú ablakra A „yes” gomb megnyomása Az „Edit” mező

kitöltése 38. újrafelhasználható rész függvényként definiálva A „GUI Map” A GUI Map a felületobjektumok azonosító információt tartalmazza. A szkript rögzítés során automatikusan elmenti ezeket is, de lehetőség van az utólagos kézi felvételre is. Az adatok megváltoztathatóak, lehetőség van pl. reguláris kifejezések használatára is szöveges tartalom esetén. 39. Ellenőrző pontok A WinRunner lehetőséget ad ellenőrző és szinkronizációs pontok beillesztésére is. Ellenőrzési pont: ◼ a folyamat kiemelt fontosságú pontjainak ellenőrzésére szolgálnak. ◼ léteznek a felület objektumaira és az adatbázisban létrejött változásokra vonatkozó ellenőrzések is Szinkronizációs pont: ◼ várakozást jelent: felfüggeszti a szkript futását, amíg a felületen vagy az adatbázisban bekövetkezik a specifikált változás. ◼ Timeout megadható. 40. Hibakeresés-ellenőrzés a tesztszkriptek segítségével ◼

Célzott ellenőrzés, egy adott szkript lefuttatásával ◼ Batch futtatás ◼ Időzített indítás - tesztrobotok 41. A teszt eredmények tesztriport 42. Szabványok a WinRunner használatához ◼ Kódolási konvenciók – szabványos szerkezetű szkriptek ◼ Konkrét tesztadatok megadása helyett alkalmas adat előkeresése az adatbázisból ◼ Előre definiált ellenőrzési tevékenységek 43. A szkriptek szerkezeti felépítése és az elemek szétválasztása Környezeti vátozók beállítása Alrendszer indítása Teszt adatok betöltése Adott felületen történő események felsorolása Adott felületen lévő eseményekhez a konkrét tesztadatok beállítása Az adott tesztrész végehajtása A teszt eredmény helyes megjelenésének ellenőrzése adatbázisban. 44. Előredefiniált szabványos függvények Adatbázis-műveletek: ◼ DBCheck ◼ DBGet String-műveletek . 45. Tesztfolyamatok modellezése 46. Tesztmodellezés ◼ A

modellezés szerepe általában ◼ A TesztLab célkitűzései a modellezésre vonatkozóan ◼ A TesztLab során kialakított vállalati szabvány áttekintése ◼ Tesztszkriptek generálása ◼ Dokumentumok generálása ◼ A modell ellenőrzése 47. A modellezés szerepe Mi az értelme? ◼ mint ami a szoftverfejlesztés modellezési fázisának az értelme: ◼ olvashatóság a rendszer fejlesztésében nem résztvevő alkalmazottak számára (elsősorban: üzemeltetés) ◼ karbantarthatóság - változtathatóság ◼ magasabb absztrakciós szinten való leírás ◼ formalizált leírás ◼ . Tesztforgatókönyvre szükség van: ◼ szöveges vagy ◼ formalizált? Teszt-modell = ◼ a teszt-forgatókönyvek formalizált leírása, ◼ szöveges leírást ebből generálhatunk ◼ a teszt-szkriptet is (nagyobb részt) generálhatjuk 48. Célkitűzések ◼ Modellezési módszertan/szabvány kidolgozása ◼ A meglévő, különböző módon leírt

teszt-forgatókönyvek formalizálása („Minden” rendszer „minden” folyamatának modellezése) ◼ A hiányzó folyamatok felderítése és modellezése ◼ A modellezés folyamatos bevezetése az új fejlesztésekkel kapcsolatosan 49. Modellezési szabvány kidolgozása 1. Követelmények a modellezéssel kapcsolatosan ◼ A formalizmus: UML ◼ Az eszköz: Rational Rose, Rational Software Modeller (RSM) ◼ A modellezés elemeinek összerakása legyen drag-and-drop alapú ◼ Ne legyen bonyolult (a modell elemei között „könnyen” lehessen navigálni, érthető legyen) ◼ A modellben legyenek összeállítva az alapvető, általánosan használt tesztlépések 50. Modellezési szabvány kidolgozása 2. A felhasznált modellezési elemek: ◼ Packagek (csomagok) ◼ Aktorok ◼ Use-case-ek ◼ Aktivitások, aktivitás diagramok ◼ Szekvencia diagramok 51. A modellezés eszköze: 52. A modell szerkezete Az alkalmazások leírása ◼ Rendszer 1 ◼

Interfészek ◼ Üzleti funkciók ◼ Rendszer 2 . A tesztelés leírása ◼ Tesztműveletek ◼ Integrációs tesztek ◼ Modultesztek ◼ Rendszer 1 ◼ Tesztlépések ◼ Kapcsolatok ◼ Tesztesetek (Tesztforgatókönyvek) ◼ Rendszer 2 ◼ . 53. Rendszerek 54. A rendszerek üzleti funkciói ◼ Ez a csomag tartalmazza az adott alkalmazás / alrendszer / modul üzleti funkcionalitásának leírását. ◼ A csomag további csomagokat tartalmazhat, az alrendszer logikai felépítésének megfelelően. ◼ A csomagok tartalma: ◼ Use Case-ek: amelyek az adott alrendszer / modul üzleti funkcióit reprezentálják ◼ Activity: az adott use case a felhasználó szempontjából leírt folyamata 55. A felhasználói felület modellezése 56. A felhasználói felület modellezése 2 ◼ A képernyők és képernyőelemek szabványos reprezentációja osztályokként, megadott sztereotípiával: ◼ a képernyő: osztály (guielement, window sztereotype) ◼ tab

(fül): beágyazott osztály ◼ list, edit, column, .: property ◼ push button, radio button, check button: operation ◼ . ◼ A fejlesztési technológiától független, egységes modellezési konvenció ◼ pl. button, list ◼ A reprezentáció úgy van megválasztva, hogy ezek a GUI elemek a tesztforgatókönyvben drag-and-drop technikával felhasználhatók legyenek ◼ A modellnek ez a része reverse engineering módon feltöltve 57. A felhasználói felület modellezése példa 58. Általánosan használható(használandó) tesztműveletek ◼ A kiinduló modell tartalmazza a teszteléshez szükséges speciális teszt lépések halmazát: ◼ Speciális teszt lépés lehet például a technikai jellegű teszt lépések (adat beírás mezőbe, adat olvasása képernyőről, adat megjegyzése, összehasonlítása stb.) ◼ A tesztlépések Activity-ként vannak reprezentálva ◼ Ezek az activity-k használandók az ellenőrzési pontokon, stb 59.

Tesztműveletek - példa a WinRunner elemi lépései 60. Kapcsolatok - egy alkalmazás futtatásához szükséges hozzáférési információk 61. Kapcsolatok - példa 62. Tesztlépések ◼ A modultesztekben szükséges lépések: ◼ egy-egy üzleti folyamat tesztelési-ellenőrzési lépésekkel kiegészített változata ◼ a tervező által definiált olyan részfolyamat, amelyet a tesztelés során több helyen is fel akar használni ◼ A tesztlépések reprezentációja: ◼ activity és a hozzá kapcsolódó activity diagram ◼ egy lépés általános feladatot is megfogalmazhat: szerepelhet benne döntési pont is 63. Tesztlépések 64. Egy tesztlépés leírása 65. Példa: tesztlépés döntési ponttal 66. Tesztforgatókönyv modulteszt ◼ Activity - Activity diagram ◼ A diagram összefüggő, egy belépési pontú gráf ◼ A megengedett elemek: ◼ a rendszerhez tartozó képernyők és képernyőelemek – Call Operation Action

◼ tesztlépések – Call Behaviour Action ◼ az általánosan használható tesztműveletek 67. Tesztforgatókönyvek a modellben 68. Tesztforgatókönyvek a modellben - 2 69. Az egyes tesztlépések adatainak megadása InitialNode ActivityFinal Node CallOperation Action CallBehavior Action Decision Node 70. InputPin OutputPin Constraint tilos tilos tilos Opcionális tilos tilos tilos Automatikus, tilos átírni Opcionális tilos tilos Automatikus, tilos átírni Opcionális tilos Automatikus, tilos átírni Opcionális tilos Opcionális Opcionális Opcionális, aktuális paraméter Opcionális, bemenő adatok Opcionális, bemenő adatok tilos Opcionális, <<access>> keyword-del Opcionális, <<access>> keyword-del Opcionális, <<access>> keyword-del tilos Mire használjuk? Folyamat indítása Folyamat vége GUI művelet hívása rendszer funkció Stereotype Name tilos Opcionális Kötelezően:

activity final tilos Opcionális Teszt művelet Document Kijövő adat Kijövő adat és elvárt eredmény tilos Példa: tesztforgatókönyvek adatai Kedvezmény választás • Input pin ◼ Előfizető és számlafizető azonos checkbox nincs kipipálva. ◼ Díjcsomag: default (SZERVUSZ) ◼ Roaming Díjcsomag: default (ROADEF) ◼ Belépési díj akció: Nincs adat választása ◼ Készülék akció: Nincs adat választása ◼ Tartozék akció: Nincs adat választása • Output pin • :: Előfizető adatai - [OLA] nézet megjelenik 71. Tesztadatok megadása a modellben DBGet • Input pin • select imei.IMEINUMBER IMEI SZAM, imeiPRODUCTCODE KESZULEK TIPUS, product.productname, imeiCONTRACTNUMBER, imei.location from imei, fradispoconnectionssernum, product where warehouse id=44 and imei.CONTRACTNUMBER is null and imeiproduct id = productproduct id and imei.imei id = fradispoconnectionssernumimei id and rownum<2 order by mei.PRODUCTCODE,imeiIMEINUMBER • Output

pin • SIM = substr(device.devicenum,7,13) KESZULEK = product.productname IMEI = imei.IMEINUMBER 72. Tesztforgatókönyv – integrációs teszt Az egyes rendszereket külön úszósávon 73. Dokumentumok generálása a modellből Mit generálunk? ◼ Tesztforgatókönyv (dokumentum formátumban) ◼ Helyesség-ellenőrzési listák ◼ WinRunner kód (kódváz) 74. Forgatókönyv-generálás Miért van rá szükség? nem elég a modell? ◼ a Rational Software Modeller nincs mindenkinél installálva, ◼ a rendszer nem mindig áll rendelkezésre, ◼ a végfelhasználók nem feltétlenül szeretik a modellt nézegetni ◼ archiválási szempontból is elvárt a teszt forgatókönyvek dokumentum formájában való előállítása De: nehéz jól olvasható dokumentumstruktúrát definiálni 75. Tesztforgatókönyv dokumentumként Forgatókönyv generálási opciók ◼ Forgatókönyveket csak a ‘kész’ tesztesetekre generálunk (amelyekhez tartozó testcase

sztereotípia state attribútuma ‘Modelled’ ) Lehetőség van egy forgatókönyv generálására • egy adott azonosítóval rendelkező tesztesethez, • egy adott rendszerhez, vagy • az integrációs tesztekhez 76. A tesztforgatókönyv szerkezete A: A tesztelendő folyamat: activity diagram B. A tesztelés előfeltételei C. A tesztelés lépései: az A activity diagram aktivitásai ◼ Leírás ◼ Megjegyzés ◼ Bemenő adatok ◼ Elvárt eredmény ◼ Megszorító feltételek ◼ A tényleges eredmény D. A hivatkozott folyamatok ◼ aktivitás- vagy iterációs diagrammal leírva 77. Aktivitásdiagram szöveges kifejtése 1. GetField 2. Jó jelszót kell megadni? Igen 2.1 SetField 2.2 WindowCheck 3. Jó jelszót kell megadni? Nem 2.1 SetField 2.2 WindowCheck 4. SetField 78. Forgatókönyvlista az intraneten 79. Szemelvény egy tesztforgatókönyvből 80. Helyességellenőrzés A modell-alapú megközelítés egyik előnye: ellenőrizni lehet a

tesztleírásokat. Mit tudunk ellenőrizni? ◼ Szerkezeti megfelelőség ◼ Tartalmi megfelelőség ◼ Kitöltöttség ◼ Lefedettség ◼ Duplikátumok kiszűrése ◼ . 81. Helyességellenőrzés néhány példa Szerkezeti megfelelőség: az aktivitásdiagramok ellenőrzése: ◼ egy belépési pontú, összefüggő, irányított gráf ◼ a megengedett csomópontok: az RSA által megengedett elemek egy részhalmaza: Initial node, Activity final node, Call behavior action, Kitöltöttség: ◼ vannak kötelező attribútumok: tesztlépéshez elvárt eredmény, ◼ a szöveges attribútumok kitöltöttsége: nem elég, hogy nemüres a mező, a szöveg érjen el legalább egy minimális hosszat, legyen benne alfanumerikus karakter, . Lefedettség: ◼ minden funkcióhoz van teszteset? ◼ minden nyomógomb, menűelem szerepel valamilyen tesztesetben? Duplikátumok kiszűrése (??) ◼ (nagyon) hasonló nevek kiszűrése ◼ hasonló aktivitásdiagramok megtalálása 82.

Összefoglaló 83. Sikeres volt-e a TesztLab projekt? IGEN Minőségjavulás: Az automatizált tesztelés általános bevezetésével intenzívebb tesztelés vált lehetővé, kézi teszteléssel megoldhatatlan feladatok is elvégezhetők voltak („last minute” módosítások után teljes teszt). A tesztelő és a fejlesztő közti kommunikáció A modellező technológia bevezetése megkönnyítette a tesztelő és a fejlesztő közötti kommunikációt. A WinRunner bevált. Megfelelő eszköznek bizonyult, mind modultesztek, mind integrációs tesztek végrehajtásához. 84. A bevezetés lépései 1. fázis: Technológia & módszertan kidolgozása A rendelkezésre álló információ összegyűjtése - reverse engineering ◼ Az alkalmazások GUI-jának modellezése ◼ Meglévő (szöveges) teszt-forgatókönyvek ◼ . Régi (SQA) teszt-szkriptek migrációja Pilot teszt projekt Termelésbe állítás 2. fázis: Technológiai továbbfejlesztés –

generálás A tesztelés folyamatának megszervezése, illesztés az üzembehelyezési folyamathoz 85. Alapadatok feltöltése a modellbe Alapadatok feltöltésének forrásai: ◼ Adatbázisok ◼ Forráskódok ◼ Tesztforgatókönyvek (Excel) Alapadatok információ tartalma: ◼ Rendszerek, alrendszerek ◼ Rendszerek műveletei ◼ Rendszerek képernyői, képernyők fülei ◼ Képernyők GUI elemei ◼ Felhasználók Az adatbetöltéshez saját fejlesztésű alkalmazás(oka)t készítettünk 86. A módszertan Módszertan előnyei: ◼ A rendszer tervezés során készített modellek nagy mértékben felhasználhatóak ◼ Úgy lett kialakítva, hogy kód legyen generálható belőle ◼ Az új eszközben (RSA/RSM) nagyfokú ellenőrzési funkció van hozzá ▪ Már modellezési időben jelzi a hibát 87. A módszertan bevezetésének haszna Nagyobb dokumentáltság: ◼ ◼ ◼ a régi forgatókönyvek frissítésre kerülnek, a hiányzó folyamatokra új

forgatókönyvek készülnek az új projektekre kötelezően elkészülnek a tesztelési forgatókönyvek Rövidebb fejlesztési idő ◼ teszt forgatókönyvek gyorsabban előállíthatóak testre szabott tesztelési forgatókönyvek készíthetők 88. Eredmények Korábban jelzett hibák A tesztelők több időt fordíthatnak a specifikus kézi tesztekre ◼ Rövidebb tesztidőszak vagy több tesztelés azonos időn belül ◼ Lehetőség shipment előtt futtatni: ▪ Azonnali hibajavítás a shipment kódzárás előtt ▪ Nem a fejlesztők idejét veszi el 89. Futtatási statisztika egy adott alkalmazáshalmaz teszteléséhez ◼ A teljes lefutás ideje 6-8 óra párhuzamosítva, 1 gépről, Citrixen keresztül vezérelhető. ◼ Kézzel futtatva ugyanez, párhuzamosan: 3-5 nap, 5-8 gép és ember. ◼ Csomagolt üzemmód: Az indítás után nem igényel folyamatos figyelmet. ◼ Robotok munkaidőn kívül is futhatnak: napi két futtatás ◼ Automatikusan generált

riportok: minimális kézi adminisztrációt igényel 90. Összefoglalás ▪ A bemutatott technológia bevezetése jelentős költséggel járt, ezt valószínűleg csak egy nagy vállalat engedhette meg magának ▪ De: ilyen bonyolultságú IT környezet is csak egy nagyvállalatnál fordulhat elő ▪ A költség nagyobbik hányada egyszeri költség, a módszertan utólagos bevezetése miatt ▪ A projekt kézzelfogható eredményeket mutat fel ▪ A cég áttért a technologizálásról a termelési fázisra ▪ A termeléssel párhuzamosan további technológiai fejlesztésekre is sor kerül(het) ▪ Gyakorlott fejlesztőgárda gyűlt össze 91. További feladatok ◼ A modellezési szabvány elterjesztése ◼ Az új alkalmazások már robotra modellezve és robottal tesztelve készüljenek ◼ A technológia továbbfejlesztése: jobb technológiai szintű kapcsolat a modell és a szkriptek között: (kódgenerálás, karbantartás támogatása, .) ◼ A

szofterfejlesztés és a teszt-tervezés összekapcsolása ◼ A módszertan kiterjesztése a fejlesztés során le nem fedett területekre (jelenleg csak implementáció közeli modellezés történik) ◼ A jelenlegi modellezés a folyamatmodellezésre koncentrál, ezt ki akarjuk terjeszteni az adatmodellezés területére is ◼ Kapcsolat más, a TesztLab projektbe nem tartozó tesztelési feladatokkal: ◼ TERHELÉSI TESZT ◼ . ◼ . 92. Köszönöm a figyelmet! Farkas Zsuzsa farkas.zsuzsanna@aleranthu Alerant Zrt. 1117 Budapest, Infopark sétány 1. Tel.: (1) 205-0055 Fax: (1) 205-0056 www.aleranthu Az Alerant Rt. a BEA Systems magyarországi disztribútora, technológiai és oktató központja. 93