tanulas_automatizalt_manualis_szoftverteszteles
Fehér Krisztián: Automatizált és manuális szoftvertesztelési alapismeretek
Tartalomjegyzék
1 Előszó
1.1 A leírás célja
1.2 A leírás felépítése
2 A szoftvertesztelésről általában
2.1 A tesztelés fogalma
2.2 A divatokról a szoftveriparban
2.3 A tesztelő személye
2.4 Miért van szükség tesztekre?
2.5 Dobozoljunk!
2.6 A tesztkörnyezet
3 A szoftvertesztelés a fejlesztések életciklusában
3.1 Tervezés
3.2 Egység (unit) tesztek
3.3 Integrációs teszt
3.4 Rendszerteszt
3.5 Elfogadási és átadási teszt
3.6 A fejlesztések utóélete
3.7 Alfa és béta tesztek
4 A tesztelés folyamata
4.1 A tesztelésben érintettek köre
4.2 Egy teljes tesztelési ciklus bemutatása
4.3 Tesztek osztályozása
4.3.1 Fejlesztői tesztek
4.3.2 A tesztelők felségterülete
4.4 Tesztek megtervezése, előkészítése
4.5 A tesztek végrehajtása
4.6 Hibák keresése és kezelése
4.7 Hibajavítások újratesztelése
5 Manuális tesztelés
5.1 Teszttípusok
5.1.1 Funkcionális tesztek
5.1.1.1 Villám (smoke) teszt
5.1.1.2 Gyors (sanity) teszt
5.1.1.3 Különböző UI tesztek
5.1.2 Nem-funkcionális tesztek
5.1.2.1 Telepíthetőségi teszt
5.1.2.2 Használhatósági (usability) teszt
5.1.2.3 Dokumentációs teszt
5.1.2.4 Hordozhatósági (portability) test
5.1.2.5 Speciális megbízhatósági (reliability) tesztek
5.1.2.6 Biztonsági (security) teszt
5.2 Segédprogramok
6 Automatizált tesztelés
6.1 Teszt típusok
6.1.1 GUI teszt
6.1.2 Internetes tesztelés
6.1.3 Terheléses- és teljesítménytesztek
6.1.3.1 Baseline teszt
6.1.3.2 Skálázhatósági teszt
6.1.3.3 Performancia teszt
6.1.3.4 Stressz teszt
6.1.3.5 Endurance teszt
6.2 Segédprogramok
6.3 Tesztek konfigurálása
6.4 Tesztkörnyezet, monitorozás
6.5 Teljesítménytesztek kiértékelése (példák)
7 Különleges tesztek
7.1 Videojátékok tesztelése
7.2 Mesterséges intelligencia és tesztelés
1 Előszó
A szoftvertesztelés népszerű dolog nemcsak külföldön, hanem Magyarországon is.
Örömteli látni, hogy manapság már furcsán néznek azokra, akik a szoftvertesztelést csak egy elhanyagolható, úri huncutságnak tekintik. Pedig 10-15 évvel ezelőtt még egészen más volt a helyzet.
Jelen leírás a szoftvertesztelés főbb területeit kívánja bemutatni a téma iránt komolyabban érdeklődő olvasóknak, egyúttal aktuális pillanatképet is készítve a szoftvertesztelés jelen helyzetéről az informatika világában.
A leírásnak nem célja a teljesség, ez az informatikában egy leírás keretein belül általában nem is lehetséges. Sokkal inkább egy iránytűként érdemes rá tekinteni, melynek segítségével magabiztosan el lehet indulni a szoftvertesztelés izgalmas útján, de legalábbis érdemben megismerhető ez a terület.
Komolykodás helyett könnyed, érthető stílusban íródtak a fejezetek, hiszen a cél az ismeretterjesztés és az érdeklődés felkeltése eziránt a szép szakterület iránt.
1.1 A leírás célja
A leírás célközönsége az informatika iránt érdeklődő olvasó, kezdő szoftvertesztelő, vagy informatikai vezető, akinek foglalkoznia kell a szoftvertesztelés menedzselésével.
Segítséget ad teljesen kezdő tesztelőknek, akár kézikönyvként, „kisokosként” is használható a mindennapokban, a kellő rutin megszerzéséig.
Továbbá bízom benne, hogy segítségével jobban sikerül tudatosítani a laikusok számára is, hogy menyire fontos a minőségbiztosítás a szoftverek világában.
1.2 A leírás felépítése
A leírás első, rövidebb blokkja magáról a szoftvertesztelésről ejt néhány keresetlen szót.
A két fő tartalmi blokk a manuális és az automatizált szoftvertesztelés. Ezzel a két fogalommal találkozik leggyakrabban az ember, ha tesztelésről esik szó.
Az automatizált tesztek esetén önkényesen kiemelem a teljesítményteszteket, mivel ezek lefolyását és célját könnyedén el tudja képzelni minden olvasó.
2 A szoftvertesztelésről általában
2.1 A tesztelés fogalma
A szoftvertesztelés lényegét a következőképpen szoktam megfogalmazni:
„A szoftvertesztelés a szoftverfejlesztési folyamatot tervezetten kísérő, azzal szorosan összefüggő, ám annak önálló része, melynek célja a tesztelt szoftver minőségének feltárása.”
A minőség szó hallatán esetleg felkapja a fejét a kedves olvasó és ez nem is véletlen. A szoftvertesztelés a minőségbiztosítás része, ami minden komolyabb cég, vállalat, vállalkozás működésének szerves része (kellene, hogy legyen).
Már rögtön az elején le kell szögezni, hogy a szoftver fogalma itt tágabban értelmezendő, mivel az jelenthet egy egész, komplett szoftverrendszert is, beleértve a fizikai infrastruktúrát (szerverek stb.). Ha itt megállunk egy pillanatra és ezt mégegyszer átgondoljuk, úgy tűnhet, hogy ez a dolog bizony elég összetett valami lehet. Nos, az is.
2.2 A divatokról a szoftveriparban
A szoftvertesztelés a fejlesztési folyamatok szerves része és mint ilyen, ezek modelljébe szokás beilleszteni. Ez rendben is van így.
Régebben a vízesés modell, pár éve a SCRUM, újabban pedig az agilis módszerek folynak a csapból is.
Személy szerint nekem nem tűnik célravezetőnek (nagyon finoman megfogalmazva), ha pár évente elkezdik a szakmai közösségi oldalakon fényezni az aktuálisan követendő trendet, kikiáltva azt a tuti-frankó módszernek, hogy ”Na, majd ez…”
Egyes trendek ugyanis tragikomikus eredményeket is létrehozhatnak, erre három példát említek.
Az egyik az ún. fejlesztő-tesztelő munkakör, ami egy izzadtságszagú kifejezés és megpróbálja bebeszélni az embereknek, hogy egy programozónak tesztelői feladatokat is el kell tudnia látni egyszerre.
Szakmai körökben gyakran közröhej tárgya a full-stack programozó elnevezés, ami valójában a beteges spórolási igyekezet egyik mellékterméke és olyan programozót jelent, aki egyszerre nagyszámú technológiához kapcsolódó feladatot lát el.
Manapság divatos a devops fogalma is, ami a fejlesztői és az üzemeltetői kompetenciák összekutyulását hirdeti és az egyik legostobább dolog, amit egy fejlesztési projekt résztvevőire rá lehet erőltetni.
Trendek jönnek, trendek mennek, de még ennél is fontosabb, hogy minden fejlesztési projekt olyan módszert találjon, ami a leginkább illeszkedik a benne dolgozókhoz és persze magához a projekthez is, szőröstül-bőröstül, nem pedig úgy néz ki, mint tehénen a gatya. Ez sokszor kihívás lehet.
Ettől függetlenül a világ már csak ilyen, mindig minden változik, ezt el kell fogadni, bár nem is kötelező minden után lelkesen rohanni. (Ez mindenesetre egy olyan dilemma, ami más szakterületekre is igaz.)
2.3 A tesztelő személye
”Tesztelő bárkiből lehet!” hangozhatna egy reklámszlogen. De valóban így van?
Legalábbis régebben így volt, elsősorban a kis cégek, vállalkozások esetében. Teljesen bevett dolog volt, hogy a nagyfőnök odament a programozó munkatársához és azt mondta neki:
”- Te, Jocó! Nyomogasd már végig az új funkcionalitást a szoftverünkben, amit a Kareszék tegnap összedobtak! Ne tölts el vele sok időt, csak nézz rá egy kicsit, aztán ha valami nagyon gáz, dobj egy mailt róla!
- Oké főnök, meglesz!”
A fenti beszélgetés a tesztelés vadnyugatias hőskorában egyáltalán nem volt ritkaság. A programozók időről-időre ki lettek nevezve tesztelőnek, aztán valami kisült a dologból. Hogy mi, az nagyban függött persze az illető hozzáállásától és szakértelmétől is, de sokszor nem volt benne köszönet. Nem is csoda.
Nagyon jó, ha egy tesztelő ismeri, hogyan készíthető el egy szoftver, de egy fenékkel bizony csak egy lovat lehet biztosan megülni. Nem is ragozom tovább…
Szoftvertesztelő valóban bárkiből lehet, ha teljesíti az alábbi kritériumokat:
• Készségszinten képes használni informatikai eszközöket.
• Rendelkezik a szoftvertesztelés alapvető ismeretével, azaz tudja és érti is, hogy tesztelőként mit kellene csinálnia.
• Nyitott és kommunikatív személyiség.
Az egyik legfontosabb tanulság, amit le kell vonni az eddigiekből, hogy a tesztelés teljesértékű hivatás, nem pedig valamiféle „beugró” szerep.
A szoftvertesztelők informatikusok, akiknek elsődleges feladatuk, hogy bizonyos minőségi szempontok alapján vizsgáljanak szoftvereket, ill. azok működését.
2.4 Miért van szükség tesztekre?
Laikus szemmel nézve a szoftvertesztelés talán túlzott elővigyázatosságnak is tűnhet, arról nem is beszélve, hogy nem olcsó mulatság, hiszen „embert kell ráállítani”.
Azért egy szoftver nem lehet olyan rossz, ugye? De igen, lehet! Már csak azért is, mert a szoftvereket többnyire még azért emberek írják és az emberek bizony tökéletlenek, így a munkájukban is mindig meg fog mutatkozni ez a tökéletlenség. A szoftverek szempontjából nincs is ezzel semmi baj egészen addig, amíg ezt szem előtt tartják. Sőt, ez elengedhetetlenül szükséges ahhoz, hogy minőségi szoftvertermékek születhessenek.
De nemcsak az igényesség kedvéért van erre szükség. Gondoljunk csak egy atomerőmű, vagy egy utasszállító repülőgép szoftverére, banki szoftverekre és számos olyan területre a hétköznapokban, ahol kis hibák sem engedhetőek meg!
Az anyagi károk mellet az erkölcsi károk veszélye szintén nem elhanyagolható szempont, amikor szoftverek minőségéről beszélünk.
Napjainkban olyan mértékű verseny alakult ki az informatikában, ami a minőségi hibákat komoly piaci hátránnyal bünteti, sokszor azonnal. Minden azonnal kell, mindennek egyből működnie kell. Ami nem jó, azt eldobják és keresnek helyette valami olyat, ami jobb. Különösen igaz ez a mobileszközökre készített alkalmazásokra. Ilyen világban élünk, ez van.
A megfelelően kivitelezett szoftvertesztelés ezért minden költségessége ellenére végeredményben hatalmas felesleges kiadásoktól mentheti meg a cégeket, ezért érdemes rá áldozni. Sőt, valójában ez a legerősebb érv a szoftvertesztelés mellett.
2.5 Dobozoljunk!
A teszteket szokás a szerint is megkülönböztetni, hogy mennyire ismert a tesztelt alkalmazás belső működése, akár egészen a programkódig.
Amennyiben a tesztelőnek teljes rálátása van az alkalmazás felépítményére, akkor ún. fehérdobozos tesztelésről beszélnek (white-box testing).
Ha az alkalmazás belső működése a tesztelő elől rejtve marad (manuális teszteléskor például ez teljesen rendben van), akkor ún. fekete doboz tesztelésről beszélünk (black box testing).
Ezeknek a „dobozolós” fogalmaknak van több változata is, de a lényeg, hogy ismerjük ezek jelentésének a hátterét.
2.6 A tesztkörnyezet
Magától értetődő, hogy a fejlesztők használnak valamilyen tesztkörnyezetet. (Valahogyan csak ki kell próbálniuk nekik is, hogy működik-e a munkájuk…)
Triviális esetben a tesztkörnyezet maga a fejlesztő gépe, kissé komplexebb rendszereknél már egy-egy szerverről beszélünk, míg nagyvállalati környezetben külön infrastruktúrát tartanak fenn, kifejezetten a szoftverek tesztelésére, esetleg teszt típusonként egyet-egyet.
Mindezek ellenére elsősorban a kis cégeknél gyakran lebecsülik a tesztkörnyezet fontosságát és inkább csak egy felesleges pénznyelőként tekintenek rá. Pedig sok esetben egy számítógépről van csupán szó, amit a tesztelésre kell fenntartani, ez pedig nem is olyan nagy költség.
A tesztkörnyezet ideális esetben menedzselve van, még akkor is, ha csak egyetlen gépről van szó. A tesztek kimenetelét ugyanis alapjaiban befolyásolhatja, hogy pontosan milyen hardveres és szoftveres környezet jellemzi.
A legfontosabb jellemzők:
- CPU
- RAM
- háttértár mérete és jellege
- operációs rendszer verziója
- a telepített célalkalmazás verziószáma.
Ezenkívül minden más fontos lehet, ami bármilyen módon befolyásolhatja a teszteredményket. Videojátékok esetén például egyáltalán nem mindegy, milyen videokártya található a tesztgépen.
A tesztkörnyezetet ideális esetben csak a tesztelők (és üzemeltetők, ha vannak) használhatnák. Nos, a gyakorlatban ez többnyire nem így van, menedzselés ide vagy oda: boldog-boldogtalan kínozza a gépe(ke)t, kipróbál ezt-azt. Ez adott esetben veszélyeztetheti egy teszt kijelentőerejét, ami már elsőre sem hangzik túl bíztatóan. De másodjára sem.
Pontosan ezt érdemes felhozni érvként, amikor dedikált, menedzselt tesztkörnyezet mellett igyekszünk kiállni.
3 A szoftvertesztelés a fejlesztések életciklusában
A szoftvertesztelés mint tevékenység csak a fejlesztési folyamatok kontextusában értelmezhető, ezért fontos tudatosítani pár dolgot ezzel kapcsolatban.
A tesztelésnek elviekben az alkalmazások elkészítésének, üzembehelyezésének minden fázisát végig kellene kísérnie, még ha a valóságban ez nincs is teljesen így.
3.1 Tervezés
Egy fejlesztési projektnek van valamiféle előkészítési, tervezési fázisa. Cége válogatja, hogy ez egy kávénál folytatott informális megbeszélés, vagy több tucat résztvevő bevonásával, alaposan dokumentált folyamat-e. Ideális esetben a tesztelőket, de legalábbis a tesztmenedzsert már illik bevonni ebbe a fázisba is. A konkrét programozás csak ezután kezdődik el. A programozási tevékenység általában a leghosszabb és a legszínesebb, a szónak minden értelmében.
3.2 Egység (unit) tesztek
Elsősorban a fejlesztők végzik az egyes programmodulok tesztjét. Ez egy erősen kódközeli tesztelés. Célja, hogy az egyes programegységek önmagukban is az elvárásoknak megfelelően működnek-e.
A fejlesztési munkák előrehaladtával a szoftver elér egy olyan szintre, hogy már lehet vele valamit csinálni. Ez azért is hasznos dolog, mert a döntéshozók ezen a ponton láthatják, hogy a szoftver tényleg azt és úgy csinálja-e, ahogyan elképzelték.
Közben persze jönnek az új ötletek is mindenhonnan és a fejlesztőcsapat tagjainak nem kis munkájába kerül, hogy határidőre minden vad ötletet megvalósítsanak. A határidők betartása sokszor nem sikerül. Persze a menetközben talált hibák javítását is gőzerővel végezni kell. Nem túlzás azt állítani, hogy vannak fejlesztési projektek, melyek leginkább egy olyan autó összeszereléséhez hasonlítanak, amit menet közben kell összerakni.
3.3 Integrációs teszt
Az egyes programmodulok, egységek sikeres együttműködését ellenőrzik az integrációs tesztek.
3.4 Rendszerteszt
Az integrációs teszt egyfajta magasabb szintű tesztjét jelentik a rendszertesztek, melyek a szoftverrendszer egészének a működését vizsgálják. Ebben a fázisban tehát eltávolodnak az egyes modulok, komponensek vizsgálatától.
3.5 Elfogadási és átadási teszt
A szoftver késznek titulált változatát el kell fogadnia minden résztvevőnek. Ez olyan fontos mozzanat, hogy még külön teszt típus is van rá: elfogadási teszt. Ha a szoftver ezen átmegy, akkor már nincs sok szenvedés hátra.
Az elfogadási teszteket követhetik még további tesztek is, melyek célja a rendszer éles üzembehelyezésének sikeres lebonyolítása.
A szoftver átadása is fontos mozzanat, adott esetben egy átadási teszttel egybekötve. Ilyenkor a megrendelő lényegében formálisan is rábólint a munka befejeztére.
3.6 A fejlesztések utóélete
Nagy költségvetésű projektek esetén ez azonban még nem az út vége, hanem egy újabb kezdete. Innentől indul ugyanis a támogatási időszak, aminek az időtartama szerződésben rögzítve van és egészen minimális időtartamoktól kezdve az örökkévalóságig eltarthat, ha van rá elég anyagi erőforrás (csörög a kassza).
A támogatási időszakban folyamatosan felmerülhetnek újabb fejlesztési-, javítási igények, melyek eredményeit természetesen szintén dokumentálni, na és persze tesztelni kell.
Apropó dokumentálás. Ez egy igen vicces terület, mert sok „komoly” fejlesztőcég egyszerűen nem ad ki a kezéből egy valamirevaló dokumentációt, felhasználói kézikönyvet, sőt esetleg egyáltalán semmilyen dokumentációt. Ennek az oka első ránézésre a töketlenség, de sokszor nagyon is átgondolt zsarolási stratégia van mögötte. Ezzel ugyanis a fejlesztők igyekezhetnek hosszú távon is nélkülözhetetlenné tenni magukat. Más kérdés, hogy ez mennyire bölcs stratégia, mivel ez egy idő után a visszájára sülhet el. De van ilyen is.
A támogatási időszak általában több évet jelent. Gondoljunk csak például az operációs rendszerek támogatására!
Amit ebből látnunk kell, hogy a tesztelésnek a szoftverfejlesztés teljes ciklusában megvan a maga helye.
Ehhez kapcsolódik a következő fejezet is, mely már kifejezetten a tesztelési tevékenységekről szól.
3.7 Alfa és béta tesztek
Gyakran hallunk alfa-, béta és még ki tudja milyen görög ábécés tesztekről operációs rendszerek, vagy éppen videojátékok kapcsán.
Ezek a tesztek részben nyitottak a nagyközönség előtt, hétköznapi emberek is lehetőséget kaphatnak egy szoftver kipróbálására.
Ezen tesztek célja nem elsősorban a szakmailag igényes értékelések begyűjtése, hiszen sokszor laikusokról van szó, hanem a számos különféle számítógép konfigurációból fakadó sokszínűségből eredő esetleges instabilitás és egyéb nem kívánatos hibák idő előtti felfedése.
Az alfa teszteket házon belül, a béta teszteket nyilvános keretek között végzik.
4 A tesztelés folyamata
4.1 A tesztelésben érintettek köre
A tesztelők ideális esetben nem magányos harcosokként küzdenek, hanem tesztmenedzser segíti munkájukat, minden információt és erőforrást biztosítva számukra, ami a munkájukhoz szükséges lehet. A tesztmenedzsert segíthetik külön tesztkoordinátorok, akik sokszor maguk is tapasztalt tesztelők.
Az üzleti elemzők feladata az adott fejlesztési projekt minden operatív résztvevője számára úgy megfogalmazni a célokat és az igényeket, hogy azokat konkrétan le lehessen programozni és tesztelni, anélkül, hogy az eredeti célkitűzések sérülnének.
A tesztelők legtöbbször szorosan együtt dolgoznak a programozókkal, fejlesztőkkel, akik a hibák kijavítását is végzik.
Természetesen egy fejlesztési projektnek számos más résztvevője is lehet, mint például az ún. product owner, aki az egész fejlesztési folyamatot igyekszik mozgásban tartani, amolyan producerként, hogy a filmes világ egyik szakkifejezésével éljek.
Komplex rendszerek esetén az üzemeltetők is fontos szerepet játszanak, hiszen ők biztosítják a sokszor igen összetett szoftverrendszerek üzembehelyezését, folyamatos működését, elérhetőségét.
4.2 Egy teljes tesztelési ciklus bemutatása
A teszteket meg kell tervezni, méghozzá minél előbb. Klasszikus menedzsment hiba szokott lenni a tesztelés túl kései bevezetése, akkor, amikor egy szoftver már félkész állapotban van. Ez azért lehet a bukás biztos receptje, mert ezen a ponton felbukkanhatnak olyan, sokszor tervezési eredetű hibák, melyek kijavítása már túlságosan sok erőforrást igényel.
Tehát a tesztelést már azelőtt fel kell venni a repertoárba, mielőtt elkezdődne a fejlesztés. Már a tervezési fázisban is könnyedén kibukhatnak olyan részletek, amelyek csak a tesztelés figyelembevételével kerülnek napvilágra. Ilyen részlet lehet például a dedikált tesztadatok, vagy ad absurdum egy releváns tesztkörnyezet teljes hiánya.
A tervezés során becsléseket lehet megfogalmazni a tesztelés várható időtartamára és költségeire vonatkozóan. Ilyenkor dől el az is, hogy milyen segédprogramokat használjanak a tesztelők.
Amennyiben a tesztelés vezetője is egyetért abban, hogy a tesztelés kivitelezhető, elindulhat a tényleges munka. Gyakran ez egy formális indító megbeszélés (ún. „kick-off”) keretén belül történik.
Az elvárt tesztek típusától függően ekkor már elkezdhető a tesztek bizonyos fokú gyakorlati tervezése, kialakítása. A tervezés (teszt dizájn) során pontosan meg kell határozni a teszt végrehajtásához szükséges összes előfeltételt, az esetlegesen szükséges tesztadatok tulajdonságait és az elvárt eredményeket, a sikeres tesztvégrehajtás kritériumait. A teszttervek elkészítéséhez valamilyen szintű vonatkozó dokumentációra (specifikáció) van szükség.
A tesztek végrehajtása természetesen csak akkor lehetséges, ha a tesztelés tárgya az előzőleg jóváhagyott tervekben megfogalmazottaknak megfelelően már minimális szinten rendelkezésre áll.
A tesztvégrehajtás után a rendelkezésre álló eredmények alapján a tesztelő megfigyeléseket tehet és óvatos következtetéseket vonhat le. Ez a teszt kiértékelése. A tesztről egy jelentést (report) illik írni, amiben a folyamat be- és kimenete is kellő, de nem túlzó részletességgel le van írva. Hibák, anomáliák esetén az oda vezető lépéseket, történéseket is rögzíteni kell, hogy a programozók minél hamarabb megtalálhassák a hiba forrását. A hibák dokumentálására hamarosan részletesen is kitérek.
Ha a teszt nem talált hibát, akkor mindenki örül. Ha mégis, akkor a hibák validálása után azok kijavítására és a teszt megismétlésére van szükség, egészen addig, amíg a teszt sikeres nem lesz.
Nos, a fent leírtak egy ideális világban így zajlanak, de a valóságban sokszor másképpen mennek a dolgok. A fogyó pénz, az egyre közeledő határidők, vállalati belső politizálás, kicsinyes macska-egér játékok sokszor keresztülhúzzák a leglelkesebb tesztelő elvárásait is. A dokumentációk hiánya például klasszikus nehézség szokott lenni, noha az ilyesmit magától értetődőnek gondolná az ember.
Kell lázadni a sokszor égbekiáltó hiányosságok, bakik miatt? Igen is és nem is. Mindenki döntse el maga, hogy az adott helyzetben minek van értelme! Érdemes itt „elmenni a falig”, de azért nem kell, hogy ez a dolog a rögeszménkké váljon.
4.3 Tesztek osztályozása
A szoftvertesztelési tevékenységnek alapvetően két változata létezik: manuális és automatizált tesztelés.
Mindkettő különféle, jól elkülöníthető teszttípusokat foglal magában.
A manuális szoftvertesztelés során egy-egy szempont alapján, folyamatos emberi részvétellel és interakcióval zajlik a munka.
Az automatizált tesztek az emberi interakciók jelentős részét kiküszöbölik a gyorsaság és a skálázhatóság érdekében.
A tesztek típusairól külön fejezetekben lesz szó.
4.3.1 Fejlesztői tesztek
Fontos említést tenni a fejlesztői tesztekről, melyek különböző tesztszinteket is magukban foglalnak. Ezeket maguk a programozók végzik, mert nélkülük maga a fejlesztés sem lenne túl hatékony (nem árt, ha a szoftver egy-egy része valóban működik is).
Az ún. statikus tesztelés során maga a programkód kerül nagyító alá, ami kódelemzést jelent és a fejlesztői munka szerves része (legalábbis nem jellemző manapság, hogy kódsorok bogarászására külön tesztelőt alkalmaznának).
Az ún. komponens tesztek a szoftver egyes, izolált részeinek együttműködését célozzák és többnyire szintén fejlesztők végzik, saját eszközeikkel, ill. módszereikkel, mivel ez egy forráskódhoz kötött munka.
4.3.2 A tesztelők felségterülete
A dinamikus tesztelés a szoftver működés közbeni ellenőrzését jelenti és valóban általában ez az, amire a legtöbben gondolnak, amikor tesztelésről van szó. Ez a leírás is értelemszerűen dinamikus tesztelési technikákról szól.
A következő szinten, az integrációs tesztek során már elsősorban azt ellenőrzik, hogy a szoftver egyes nagyobb részegységei megfelelően működnek-e együtt. Ez a terület célzott felkészülést és előkészületeket igényel. Manuális- és automatizált tesztek szintén végrehajthatóak ezen a tesztszinten.
Az integrációs teszteken túl a rendszertesztek már a szoftver éles működését is modellezik és egy magasszintű megközelítést jelentenek. Értelme akkor van, ha előzőleg már az integrációs tesztek is sikeresek.
4.4 Tesztek megtervezése, előkészítése
Azt hinni, hogy egy szoftver nem tartalmazhat hibákat, csak azért, mert egy teszt sikeres volt, legalább olyan badarság, mint azt hinni, hogy teszteléssel teljes mértékben ki lehet küszöbölni minden potenciális hibát.
A tesztelés során szinte mindig célzottan keresünk olyan hibákat, melyek előfordulását ki szeretnénk zárni. Ez így elég soványnak tűnik, de némileg enyhíthetünk az e felett érzett félelmeinken, ha minél több lehetőséget megvizsgálunk.
De kezdjük az elején! Először is azt ildomos tisztázni, hogy pontosan mit kell tesztelni. Ha ez nem egyértelmű, akkor bizony rá kell kérdezni. Tesztelni bármit lehet, kezdve a tesztadatok helyes feldolgozásától a futtatókörnyezet terheléséig széles a paletta. Nyilvánvaló az is, hogy csak bizonyos eseteket kell vizsgálni, különben a tesztelés soha nem érne véget. Többnyire a leginkább várható hibák kiszűrése a cél, mert ezek bekövetkezte a legvalószínűbb.
Vegyünk egy könnyed példát! Tesztelni kell egy videojátékot, hogy egy konkrét hardverkonfiguráción és előre megadott tesztadatokkal, adott beállításokkal elér-e 60 képkocka/másodperces sebességet a játék renderelő motorja.
Íme a haditerv:
- A teszt célja: a renderelés sebességének validálása, egy konkrét célérték alapján.
- A teszt alanya: a videojáték.
- A teszt tárgya: a renderelő motor sebességértékei.
- A kiértékelés alapja: a mért FPS értékek átlaga.
- A teszt feltétele: a videojáték telepítve van és az összes hardveres feltétel adott.
- A teszt lehetséges kimenetelei:
- siker: legalább 60 FPS-t sikerült elérni
- sikertelenség: a szoftver a 60 FPS-t soha, vagy nem konzisztensen tudja tartani.
A fenti példa remekül alkalmazható a legtöbb tesztelési feladat végrahajtásának előkészítéséhez, függetlenül attól, hogy egy videojátékot, vagy éppen egy komplex üzleti alkalmazást kell-e tesztelni. Arra kell mindig figyelni, hogy minden részlet egyértelmű legyen, még mielőtt a teszt végrehajtására kerülne a sor! Mivel senki sem gondolatolvasó, így kénytelenek vagyunk kérdezni.
A tervezés fontos fázisa a tesztek ütemezése. Biztosan tudnunk kell, hogy mikor áll készen a szoftver a tesztelésre. Egyszerűbb szoftverek esetén ez akár lehet informális rákérdezés a fejlesztőknél, komplex rendszerek esetén az üzemeltetőktől kell kérni egy ún. „időablakot”, egy idősávot, amikor garantáltan csak mi „püfölhetjük” a szoftvert és semmilyen más tevékenység nem zajlik, ami a tesztet befolyásolná (pl. telepítenek valamilyen frissítést stb.).
Nézzünk most egy példát egy teszt dokumentálására! Az egyszerűség kedvéért táblázatos formát használok, de persze számos hasznos segédprogram létezik tesztesetek megtervezésére.
Teszt neve: Bejelentkezési teszt
Lépés | Leírás | Megjegyzés | Elvárt eredmény |
1. | Alkalmazás elindítása. | Ellenőrizni a sikeres telepítést! | Megjelenik a bejelentkező ablak. |
2. | Felhasználói adatok megadása. | Nincs. | A felhasználói név és jelszó megadása lehetséges. |
3. | Kattintás a ’Belépés’ eliratú gombra. | Nincs. | A felhasználó sikeresen bejelentkezett. |
4.5 A tesztek végrehajtása
Az igazság pillanata mindig a tesztek futtatása. Ekkor derül ki, hogy mindent jól előkészítettünk-e, ill. természetesen az is, hogy a tesztelt szoftver hogyan muzsikál. Hosszabb tesztek alatt érdemes nyitva tartani a szemünket, hátha valamilyen egyéb furcsaságot is észlelünk. Nem ez a lényeg, de a nyitott szemmel dolgozó tesztelőket általában szeretik, kivéve, ha teljesen oda nem illő dolgokat reklamálnak.
Például nincs értelme nyomógombokhoz használt színeken rugózni, ha a fő feladat egyébként egy funkcionalitás működőképességének az ellenőrzése.
Ellenben fontos lehet, ha a teszt következtében például egy másik funkcionalitás összeomlik.
A tesztek végrehajtását többnyire ugyanazzal az eszközzel dokumentálják, mint amelyikkel a teszteket megtervezték.
Egy teszt kimenetele igen sokféle lehet, nem korlátozódik csupán a „jó”, „nem jó” esetekre.
Néhány példa lehetséges teszteredményekre:
- Várakozó: valamilyen előfeltétel hiánya miatt a végrehajtás mégsem kezdődhetett el.
- Sikeres: minden klappolt.
- Kiértékelés/validálás alatt: hosszabb időre van szükség az eredmények kiértékelésére.
- Nem érvényes: a teszt kimenetele kiértékelhetetlen, ilyenkor a teszt megismétlése várható/szükséges.
- Sikertelen: valamilyen hiba keletkezett, gáz van.
Ha tesztek végrehajtását rendszeresen dokumentálják, idővel valóságos aranybányává válhat ez a dokumentáció is.
Kiderülhet, mely funkciókkal szokott a legtöbb galiba előfordulni, de az is, hogy általában mennyi ideig tart kijavítani egy hibát, ideértve természetesen az adott teszt ismételt végrehajtását, a hibajavítás ellenőrzése végett.
Alább egy nagyon egyszerű dokumentációs minta tesztek naplózására.
Szoftver | Verzió | Teszt | Végrehajtási idő | Eredmény |
Webshop | 1.0 | Termék törlése | 2 perc | Sikeres |
Webshop | 2.0 | Termék törlése | 2 perc | Várakozás (még nincsen telepítve). |
4.6 Hibák keresése és kezelése
Ha hibát találunk, az valójában jó dolog, hiszen a tesztelés koncepciójának helyességét bizonyítja. Ha minduntalan csak sikeres tesztekkel szembesülünk, az már-már gyanús kell, hogy legyen.
Tegyük most fel, hogy hibát találunk! Mit tegyünk? A hibát minél gyorsabban ki kell javítani és szólni kell a fejlesztőknek, nemde? Persze, de azért csak lassan a testtel!
Minden hibát dokumentálni kell! Ez nem valamiféle öncélú pedantéria, hanem a visszakereshetőség egyik fontos feltétele (lásd az előző alfejezetet). Másrészt előfordulhat, hogy a programozócsapatnak sok hiba „van a rovásán” és éppen más hibák kijavításán dolgozik. Az is elképzelhető, hogy súlyosabb hibák is vannak, előbb azokat kell kijavítani. Ne feledjük: „Verba volant, scripta manent!” („A szó elszáll, az írás megmarad!”)
A dokumentálás előtt meg kell győződnünk arról, hogy a hiba előhozása reprodukálható! Máskülönben a fejlesztők széttárják a kezüket, mondván: ”Sajnos mi nem látunk hibát”. Emiatt pedig a hibajelentésünk érvénytelen (nem valid) lesz. A hiba újból történő előidézéséhez jegyezzünk fel minden, oda vezető lépést!
Most tegyük fel, hogy reprodukálható hibát találtunk! Mit kell lejegyeznünk ezzel kapcsolatban?
• A hiba rövid, de beszédes megnevezését (költői vénával rendelkező tesztelők előnyben).
Negatív példa: „Nem megy az X funkció”
Pozitív példa: ”Programhiba az XY gombra történő kattintáskor”
• A hiba részletesebb leírása, mi történik pontosan.
• Ha lehetséges, képernyőképeket is készítsünk!
• Ha van, a hibaüzenet, a lehető legteljesebben, akár csatolt fájlként is.
• A hiba előhozásának lépései. Ha a hiba adatok használatához van kötve, az adatok leírása/megadása (pl. csatolmányként).
• El-/megkerülhető-e a hiba?
• A tesztelt szoftver verziója.
• Ha számít: a szoftver-/hardverkörnyezet konfigurációjának megadása.
• A hiba súlyossága: mennyire nagy galibát okoz a hiba (pl. a. elhanyagolható, b. szódával elmegy, c. apokalipszis).
• A hiba kijavításának sürgőssége, prioritása (például a. alacsony, b. normál, c. magas).
A tesztelőnek a hibák súlyosságára, ill. sürgősségére javaslatot kell tennie, de többnyire a programozók, vagy más projektrésztvevők ezt akár felül is írhatják. Ha ez nem egyezik a véleményünkkel, ne bánkódjunk, ennek a felelőssége már nem a miénk lesz!
A hibák dokumentálására számos megoldás létezik. A legrosszabb, amit tehetünk, ha nem dokumentálunk semmit, csak szóbeli susmusolással közöljük a tényeket az illetékesekkel.
Az email-ben történő elküldés kézenfekvőnek tűnik, de egy idő után garantáltan átláthatatlan lesz a hibák feldolgozása, a javítások ellenőrzése stb. Ilyesmi akkor jó, ha szeretjük a „ki nevet a végén” típusú, ill. a detektívjátékokat. Egyébként nem ajánlott.
Ennél egy fokkal jobb valamilyen táblázat használata, de az átláthatatlanság idővel itt is garantált.
A fentiek miatt erősen megfontolandó valamilyen célszoftver használata. Régebben ez valamilyen kliens célszoftver volt, manapság azonban egyértelműen az online, webes felülettel rendelkező dokumentációs rendszerek az elterjedtek. Ilyen például a JIRA is. Ezek a rendszerek ugyan többnyire fizetősek és nem is feltétlenül olcsók, ám adatbázis alapúak, ami azt jelenti, hogy remekül rendszerezhetőek, nagyon pontosan visszakövethetővé teszik a hibák javítását, nem mellesleg pedig csinos kimutatásokat lehet belőlük készíteni, amivel minden menedzsert kenyérre lehet kenni.
Ha egy fejlesztőcsapat árérzékeny, megfontolandó lehet utolsó szalmaszálként lottózni, vagy ha az nem szimpatikus, akkor saját célszoftvert fejleszteni. Egy 2-3 fős elszánt programozó különítmény egy alapszintű dokumentációs rendszert akár egy hétvége alatt össze tud dobni, nem nagy dolog.
4.7 Hibajavítások újratesztelése
Azért a programozók is szeretnek egy kicsit tesztelni, nekik is vannak speciális tesztjeik, ill. konkrét hibajavítások alkalmával (elvileg) ellenőrzik is, hogy legalábbis náluk tényleg eltűnt-e a hiba. Ennek ellenére a tesztelőnek kutya kötelessége a hibajavítás után egy teljes ellenőrzést, egy ún. visszamenőleges jellegű, szakszóval regresszív tesztet végrehajtania.
Ha ez a teszt sikeres, csak akkor tekinthető a hibajavítás érvényesnek. Minden más esetben a programozónak ismét meg kell néznie, hol hiányzik még valami.
5 Manuális tesztelés
A manuális szoftvertesztelés az egyik legalapvetőbb minőségellenőrzési forma a szoftverfejlesztés terén. Bár napjainkban az automatizált tesztelési formák árnyékában kevésbé „divatos” dolog, elengedhetetlenül szükséges gyakorlat.
5.1 Teszttípusok
A két fő teszttípus a funkcionális és a nem-funkcionális tesztek csoportja. Ezek további altípusokra bonthatóak.
5.1.1 Funkcionális tesztek
A funkcionális tesztekhez tartozik minden olyan tesztelés, ami egy adott, konkrét programfunkcióhoz köthető, ilyen például egy felhasználói fiók létrehozása, módosítása, vagy törlése.
A tesztelés alapját egy leírás, dokumentáció adja, sok esetben ennek a neve is funkcionális specifikáció, de megteszi egy kellően részletes felhasználói kézikönyv is.
5.1.1.1 Villám (smoke) teszt
A smoke (magyarul: „füst”, mert az gyorsan elillan) teszt egy felületes, gyors kipróbálással egyenértékű teszt, mely durvább hibák felbukkanását igyekszik kiszűrni. Nem célja komplett folyamatok végigtesztelése, bár nem is zárja ki azokat. Többnyire előkészíti a további teszteket.
Smoke teszt lehet például az alkalmazás elindulásának, néhány kulcsfontosságú adat betöltésének az ellenőrzése.
5.1.1.2 Gyors (sanity) teszt
A sanity tesztet talán gyorstesztnek lenne érdemes fordítani. Annyiban több a smoke tesztnél, hogy egy-egy folyamat gyors végigtesztelését és ellenőrzését jelenti, de nem merül el a részletekben és elsősorban az eredmény ellenőrzésére koncentrál.
5.1.1.3 Különböző UI tesztek
A felhasználói felületen (angolul: GUI-n) végzett tesztek a legkézenfekvőbb manuális tesztek. Durván fogalmazva ez az a teszt, amelynek során „végignyomkodják” az alkalmazás felületét.
Szebben megfogalmazva, ezek a tesztek a felhasználói felületen zajlanak, közvetlen tesztelői interakcióval.
5.1.2 Nem-funkcionális tesztek
Nem-funkcionális tesztnek minden olyan teszt, mely ugyan az adott szoftverrel kapcsolatos minőséget jellemzi, de nem egy konkrét programfunkcióhoz kapcsolódóan.
5.1.2.1 Telepíthetőségi teszt
A dokumentációs tesztekhez (lásd lentebb) kapcsolható teszt, melynek célja, hogy kiszűrje: a telepítésnek a dokumentáció szerinti végrehajtása során fellép-e bárminemű hiba, mely az alkalmazás működtetését veszélyeztetheti.
Extrém esetben egy alkalmazás egyáltalán nem is telepíthető a dokumentált módon.
5.1.2.2 Használhatósági (usability) teszt
A használhatóság elég tág fogalom, de nincsen ezzel semmi baj, annál többféle helyzetre alkalmazható.
A használhatóság tesztelése egy adott „feature”, funkció felhasználói szemszögből nézett működését jelenti, például azt, hogy egy funkciót egy élő ember mennyire könnyen képes még leírással is használni. Bár itt funkcióról beszélünk, mégis nem maga a funkció eredménye, hanem „emészthetősége” van fókuszban.
5.1.2.3 Dokumentációs teszt
A felhasználói dokumentációknak régebben sokkal nagyobb szerep jutott, mint napjainkban, legyen szó akár felhasználói/játékprogramról, vagy éppen üzleti alkalmazásról.
Szinte el sem hiszi az ember, hogy annakidején még külön grafikusokat, tervezőket alkalmaztak kifejezetten kézikönyvek megalkotásához. Manapság örülhetünk, ha valamiféle összetákolt PDF dokumentumot „dobnak” az ember után, nemhogy egy nyomdailag is ritkaságszámba menő, művészi igényességű, valódi kézikönyvet.
A művészi hatáson túl azonban a tartalmi szempontok is fontosak természetesen. Annál is inkább, mert dokumentációnak tekinthető egy egyszerű, formázatlan szövegfájl is.
A technikai leírások például egy üzleti alkalmazás esetén életbevágóan fontosak lehetnek, hiszen nélkülük akár az egész alkalmazás üzembehelyezése is kudarcba fulladhat.
Egy valamire való dokumentációnak tartalmaznia kell a következő dolgokat:
• rendszerkövetelmények megnevezése
• telepítés (ha szükséges) leírása
• üzembe helyezés bemutatása
• elindítás leírása
• egyes programfunkciók elérhetősége és használatuk lépésről-lépésre történő leírása
• hibaüzenetek gyűjteménye
• külső segítségnyújtás kérésének módja.
Többnyire nem ezeknek a hiánya, hanem pontatlansága szokott gondokat okozni a gyakorlatban, elsősorban a nagyobb verzióváltásokból eredő új információk dokumentálásának hiánya miatt.
5.1.2.4 Hordozhatósági (portability) test
A hordozhatóság nem elsősorban platformok közötti átjárhatóságot jelent (bár napjaink „mindent-mindennel összekapcsolni” elven működő világában már ez sem elrugaszkodott gondolat), hanem üzemeltetési infrastruktúrák közötti hordozhatóságot.
Ez talán egy kis magyarázatra szorul. Tegyük fel, hogy egy alkalmazást már 5 éve üzemeltetnek egy adott infrastruktúrán! Az alkalmazás remekül „belakta” a vasakat és remekül érzi magát, köszöni szépen. Ez az alkalmazás akkor jól hordozható, ha a legfrissebb verzióját a nulláról kiindulva hibátlanul fel lehet telepíteni egy fizikailag teljesen más infrastruktúrán és az üzembehelyezés után legalább ugyanúgy el tudja látni feladatát, mint a régi infrastruktúrán.
Na, ez a gyakorlatban igen ritkán teljesül. Miért? Azért, mert minél bonyolultabb egy rendszer, annál több a dokumentálatlan, szájhagyomány útján terjedő kis „hegesztés”, apró finomhangolás a rendszeren, ami a simulékony működést eredményezte az idők során.
Ideális esetben minden beállítási lehetőség dokumentálva van és így teljesen hordozhatóvá válik egy alkalmazás, de a gyakorlatban ez szinte soha nincsen így.
5.1.2.5 Speciális megbízhatósági (reliability) tesztek
A megbízhatósági tesztek azt hivatottak ellenőrizni, hogy az alkalmazás szempontjából vészhelyzeti körülmények között megtartható-e, vagy visszaállítható-e az alkalmazás működőképessége és az alkalmazás adatai.
A backup tesztek során az alkalmazáson, ill. annak adatain valamilyen durvább változtatást eszközölnek, mely akár az alkalmazás üzemképtelenségét is eredményezheti (destruktív hajlamú tesztelők előnyben). Ezt követően pedig egy korábbi, ideálisan a teszt előkészületeként elvégzett biztonsági mentés visszaállítására, bejátszására kerül sor, majd pedig egy smoke, esetleg sanity teszt jön.
Az ún. failover tesztek során az alkalmazások „öngyógyító” képessége kerül górcső alá. Itt szintén egy hibát idéznek elő. Lehetőleg persze olyat, amiről tudni lehet, hogy az alkalmazás képes lehet kezelni, hiszen itt is nyilván van egy ésszerű határ. Klasszikus, sok technikai hozzáértést nem is igénylő megoldás az érintett tápvezetékek kihúzkodása a számítógépekből, az alkalmazás futása közben, majd pedig a rendszer és az alkalmazás újraindítása. Valljuk be, ez még meglehetősen egyszerű alkalmazások számára is kemény kihívás lehet…
5.1.2.6 Biztonsági (security) teszt
Biztonsági tesztekről is köteteket lehetne írni, a téma nagyságára itt csak utalok. A legtöbb biztonsági teszt manuális tesztnek tekintendő, dacára a rengeteg szkriptnek, melyekkel sok folyamat automatizálható. Mégis talán ez az a teszttípus, mely leginkább igényli az emberi találékonyságot, ezáltal nem is tudja nélkülözni az emberi beavatkozást.
A biztonsági tesztek szakállas példái az autentikációs tesztek és a túlterheléses tesztek, mely utóbbiak már valóban az automatizált tesztek világára mutatnak.
5.2 Segédprogramok
Manuális tesztek végrehajtásához segédprogramok triviális módon nem jellemzőek. Elsősorban a teszteredmények, a teszt lefutásának a dokumentálására használnak segédprogramokat, alkalmazásokat. Ilyen online, testreszabható alkalmazás a JIRA is, mely igen közkedvelt szerte a világon.
A SOAP UI segítségével webszolgáltatásokat lehet könnyedén tesztelni. A kiszolgáló számítógép megadása intuitív módon történik, az elküldendő üzeneteket pedig kényelmesen szerkeszthetjük elküldés előtt. A válaszüzeneteket automatikusan megjeleníti az alkalmazás.
Webes alkalmazásoknál hasznos lehet a böngészők beépített hibakereső, elemző funkciója is.
6 Automatizált tesztelés
Az automatizált tesztelésre sokan úgy tekintenek, mint a tesztelés szent gráljára, a valóság azonban az, hogy ez nem csodafegyver. A manuális tesztelés kiváltására sem alkalmas teljes mértékben.
Valójában a manuális és automatizált tesztelés ideális esetben kéz a kézben jár és ki kell, hogy egészítse egymást.
Gyakorta hallani olyan véleményeket, melyek a manuális tesztek teljes felváltása mellett törnek lándzsát, az automatizált tesztek javára. Ez a megközelítés egy szélsőséges álláspontot képvisel és pontosan a lényeget nem veszi figyelembe: a manuális és az automatizált tesztelés más-más feladatokra hatékony, nem pedig egymás vetélytársai.
Automatizált tesztekre olyankor van szükség, amikor a teszttevékenység szinte mindig ugyanúgy elvégezhető és sokszor is kell megismételni.
Ez még akkor is jól jöhet, ha magát a tesztet csak egyetlen példányban kell futtatni, például egyetlen személynek. A folyamat automatizált kiváltásával másra is lesz ideje a tesztelőnek, ill. nem unja magát halálra az illető és persze a hibázás esélye is kisebb.
A másik ok, amiért automatizált tesztekre szükség lehet, a tömegesen végrehajtott teszttevékenység iránti igény. Egy webshop esetén például üzleti szempontból kritikus lehet tudni, hogy mekkora vásárlói rohamot tud kibírni, kiszolgálni. Manuális teszteléssel ilyesmit lehetetlen ellenőrizni, nem valószínű ugyanis, hogy egy-egy teszt kedvéért 1-2000 tesztelőt ráállítanának a tesztelésre. Ez egyrészt butaság is lenne, másrészt túlságosan drága is. A megfelelő segédprogramokkal ugyanis elegendő egyetlenegyszer előkészíteni egy tesztet és azt sokszoros példányban lefuttatni, végrehajtani. Az eredmény szinte teljesen ugyanaz lesz.
Az egyik ok, amiért még sincsen minden automatizálva, hogy míg manuális teszteket adott esetben komolyabb technikai háttértudás nélkül is végre lehet hajtani, az automatizált tesztek esetén ez már nem működne. Ide már fejlesztői, algoritmikus gondolkodás kell, egyszerűen azért, mert ezeket a teszteket kevés kivétellel valamilyen kódolási nyelven meg kell fogalmazni. Másrészt itt már a háttérrendszerek ismerete, ill. a szakmai háttérismeret is erőteljesebben érvényesül, mert a tesztelő csak ezek segítségével tudja előkészíteni teljesen az automatizált tesztet.
A másik ok a tesztek karbantartásából eredő többletköltség. Ritka az, hogy egy egyszer megírt automatizált teszt az idők végezetéig módosítások nélkül hibátlanul végrehajtható maradjon. Sőt, a tesztek folyamatos karbantartása, érvényes tesztadatok létrehozása és naprakészen tartása az, ami a legtöbb időt igénybe veszi az automatizált tesztek esetén. Ez már rövidtávon is sok ráfordítást követel, ezért kétszer is meg kell gondolni, hogy mit akarunk automatizálni.
6.1 Teszt típusok
Az automatizált teszteknek számos válfaja létezik, ezeket kombinálni is lehet. Nem is érdemes a teljességre törekedni, amikor róluk beszélünk. Bizonyos teszt típusokat azonban mindenképpen ismerni kell.
Az automatizált tesztek egy része a felhasználói felülethez kötött, ilyenkor nagy hangsúlyt kaphat az alkalmazás renderelési sebessége, azaz, hogy milyen gyorsan képes előállítani, frissíteni a felhasználói felületet. Másik részük pedig ún. API tesztnek minősül, ilyenkor tisztán csak az egyes programfunkciók, szolgáltatások igénybevételén van a hangsúly, a felhasználói felület nincsen fókuszban.
6.1.1 GUI teszt
A felhasználói felületeken végzett tesztek automatizálása adja magát, hiszen a grafikus felhasználói felülettel rendelkező alkalmazások tesztelése így hasonlít leginkább arra, ahogyan az alkalmazást a valódi felhasználók is használják.
A legegyszerűbb GUI tesztek egérkattintást és szövegbevitelt szimulálnak. A bonyolultabb tesztek képesek a GUI tartalmának megfelelően különböző módokon végrehajtani ugyanazt a tesztet. Ennek során a felhasználói felület egyes elemeire azok tartalma, vagy valamilyen egyedi azonosítója alapján szokás hivatkozni.
6.1.2 Internetes tesztelés
Az internetes tesztelés manapság kezd divatossá válni. Lényege, hogy interneten elérhető éles rendszereket vonnak teszt alá úgy, hogy a tesztet az internet irányából hajtják végre.
Erre elsősorban a nagy felhőszolgáltatások (például AWS) adnak lehetőséget.
A teszt létjogosultságát sokan abban látják, hogy ez a teszt adja a legpontosabb eredményeket.
Hátránya viszont a tesztelés azon alapelvének tudatos megsértése, miszerint éles alkalmazást, rendszereket tilos tesztelni, az ezzel járó kockázatok miatt.
6.1.3 Terheléses- és teljesítménytesztek
A teljesítménytesztek, idegen szóval performancia tesztek az automatizált tesztek egyik alapvető ágát jelentik. Ha valamiért érdemes automatizált teszteket létrehozni, akkor ezek a tesztek biztosan azok. Ezen tesztek mindig a leadott teljesítmény és a kezelt maximális terhelés kérdése körül forognak, más-más hangsúllyal.
Ezen tesztek végrehajtásakor a tesztelt alkalmazás teherbíróképességét hibatűrését tesztelik. Ez a rendszer általános stabilitása miatt is fontos, de azért is, hogy „csúcsidőkben” is megbízhatóan működjön.
Az egész diszkrét bája, hogy ezek a tesztek nagyban hasonlítanak az illegális túlterheléses támadások végrehajtására, csak éppen teljesen legálisan hajthatóak végre, na és persze ellenőrzött körülmények között.
Lássuk hát, milyen elterjedt terheléses- és teljesítménytesztek léteznek és melyik mire való!
A teljesítménytesztek során a generálandó terhelést konfigurálni kell, méghozzá az aktív (szimulált) felhasználók számával. Ennek során a terhelés konfigurációja megkülönbözteti a rampup (növekvő terhelés), plató (kitartás változatlan terheléssel) és a rampdown (csökkenő terhelés) fogalmait.
6.1.3.1 Baseline teszt
A baseline teszt csak egy előkészület további tesztekre. Végrehajtásával referenciaértékek megszerzése a cél, melyekhez hozzá lehet igazítani a majdani teljesítményteszteket.
Ilyen teljesítményfelmérő tesztet kis, akár minimális terheléssel is végre lehet hajtani és persze mindig megismételhető, amikor viszonyítási alapra van szükség.
6.1.3.2 Skálázhatósági teszt
Egy alkalmazás üzemeltetése, de akár frissítése szempontjából is nagyon fontos tudni, hogy mi az a terhelés, amit már nem tud hiba nélkül elviselni a rendszer, ill. hol van az a pont, amikor a rendszer teljesen leáll, azaz nem tud további kéréseket kiszolgálni. Ezt röviden úgy mondjuk, hogy milyen mértékben skálázható az alkalmazás.
Ezek a tesztek minimális terheléssel indulnak, majd hosszabb-rövidebb plató fázisok után folyamatosan növelik a terhelést rampup fázisokkal.
A teszt célja a hibahatárok meghatározása, így a konfiguráció végét szándékosan túlzottan magasra állítják be.
6.1.3.3 Performancia teszt
A teljesítménytesztek célja annak felfedése, hogy milyen ingadozás léphet fel terheléskor és mennyi hiba lép fel fokozatosan erősödő terhelés mellett. Ezek a tesztek jellemzően 100%-os terhelést is generálnak, de nem lépik át ezt a határt, tehát a cél nem az alkalmazás térdre kényszerítése.
A teszt legvégén egyetlen, vagy valamennyire fokozatos rampdown fázis konfigurálása szokás.
6.1.3.4 Stressz teszt
A stressz teszt, mint ahogyan a neve is mutatja, az alkalmazást egy időre kiugróan magas terhelésnek veti alá, ami túlmegy a 100%-on. Hogy ez mennyi, az az adott alkalmazástól függ. Lehet 120%, de akár 200-300% is. Csak olyan magas csúcsterhelést érdemes választani, amit az alkalmazás egy nagyon rövid ideig úgy-ahogy képes elviselni.
A teszt segítségével megállapítható, hogy az elvárt ideig valóban állja-e a sarat az alkalmazás, ill. azon túl mennyi ideig képes hiba nélkül, vagy minimális hibaszámmal ellátni feladatát.
6.1.3.5 Endurance teszt
Az endurance teszt magyar megfelelője kissé bizonytalan, talán a „túlélési teszt” is lehetne, mivel a cél annak megállapítása, hogy kiugróan magas terhelés mellett (100%, vagy magasabb) mennyi ideig képes működni az alkalmazás.
Rampdown fázisra itt nincsen szükség, csak egy nagyon hosszú platóra, mert egy idő után úgyis az alkalmazás leállása várható. Itt tehát kifejezetten az alkalmazás összerogyására játszanak rá.
Olyan alkalmazás nem létezik, ami végig hiba nélkül kibírná ezt a tesztet, legfeljebb a terhelés konfigurációja nem volt elég jó.
6.2 Segédprogramok
Az automatizált tesztelést támogató alkalmazások közül nem egy eredetileg napi munkára megírt egyszerű segédprogramként kezdte pályafutását, majd készítőik egyre több funkcionalitással, még nagyobb rugalmassággal ruházták fel őket és hosszú évek alatt professzionális üzleti termék lett belőlük.
A legtöbb ilyen segédprogram már nem is egyetlen program, hanem komplett keretrendszer, ami egyben fejlesztőrendszerként is üzemel, lévén ezeket a teszteket programozni kell. Túlnyomórészt Windows operációs rendszeren futtathatóak, de a tesztelt célrendszerek sora nagyon tágas, egészen a mobileszközökig terjed, beleértve különböző mobil operációs rendszereket is.
A teljesség igénye nélkül, néhány „nagyágyú” erről a területről:
• AutoHotKey
• UFT (Unified Functional Testing)
• Ranorex Studio
• Robot Framework
• Selenium
• Silk Performer
• Tricentis Tosca.
Ezen segédprogramok nagy része fizetős, de akadnak nyílt forráskódú, ingyenesen hozzáférhetőek is.
6.3 Terheléses tesztek konfigurálása
A terheléses tesztek futtatását gondosan meg kell tervezni. Komplex alkalmazások, ill. tesztek esetén, elsősorban teljesítményteszteknél nem mindegy, hogy hány példányban fut le párhuzamosan a teszt. Erre a célra ún. virtuális ágenseket/felhasználókat tud létrehozni az adott keretrendszer. Valahogy úgy, ahogyan több szálon képesek futni egyes alkalmazások.
Az egyes ágensek „adagolását” percre, sőt másodpercre pontosan meg lehet adni bizonyos segédprogramoknál.
Az ütemezés úgynevezett tesztszintekre bontva szükséges. Egy tesztszint időben értelmezett adott mértékű terhelést jelent, amibe beletartozhatnak átmenetek is.
Ilyenkor meg kell adni, hogy az adott tesztszint mennyi ágenssel induljon és mennyivel fejeződjön be, valamint azt is, hogy mennyi ideig kell tartania egy adott tesztszintnek.
Alább egy példa egy ilyen konfigurációra.
Látható, hogy összesen 5 szimulált felhasználó fogja végrehajtani a tesztet. A terhelés felfutása és lefutása 1-1 percig fog tartani. A szinten tartott terhelések 10 és 20 percig fognak tartani. Így a teljes teszt hossza 34 perc lesz.
Érdemben tehát 2 tesztszint van, nem számítva az átmeneteket és az utolsó egy percet, ami egyfajta pufferidőnek is van fenntartva.
A tesztek konfigurálását tovább lehet bonyolítani azzal, hogy nem mindegyik ágens ugyanazt a műveletet hajtja végre, hanem más és más tevékenységeket. Így például olyan teszt is összeállítható, melynek során mondjuk egy webáruházat úgy tesztelünk, hogy 5 felhasználó regisztrációt végez, 20 vásárol, 150 pedig böngészi a webáruház tartalmát.
Ezek alapján már jobban elképzelhető, milyen sok variácó elképzelhető egy-egy teszt esetében.
6.4 Tesztkörnyezet, monitorozás
Akárcsak a manuális tesztelés esetén, az automatizált teszteket többnyire elszigetelt, tehát nem éles infrastruktúrán, tesztkörnyezetben szokták elvégezni (legalábbis, ha nem szeretik a váratlan izgalmakat).
Fontos, hogy a tesztkörnyezet és maga a tesztelendő alkalmazás a lehető legjobban hasonlítson az éles rendszerre. Amennyiben ez nem lehetséges (például, mert túl drága lenne 1:1 arányban felépíteni egy nagyvállalati tesztkörnyezetet), akkor a tesztkörnyezet általában mint az éles rendszer arányosan csökkentett kapacitású változata is elég lehet. Ilyenkor az eredményeket ennek az aránynak a figyelembevételével kell kiértékelni, ill. a tesztet is ennek megfelelően konfigurálni, kivált, ha terheléses tesztről van szó.
A teljesítménytesztek során az alábbi típusú adatokra igyekeznek a tesztelők mérőszámokat gyűjteni, folyamatos monitorozással:
• CPU terhelés
• memória terhelés- és kihasználtság
• hálózati adatforgalom
• üzleti tranzakciók száma
• a tranzakciók feldolgozási ideje
• aktív felhasználók száma
• hibák előfordulásának száma
• adatbázisműveletek időtartama
• hibák száma és típusa(!).
A fenti adatok ismeretében meglepően pontos kép kirajzolható egy alkalmazásról.
6.5 Teljesítménytesztek kiértékelése (példák)
Az alábbiakban néhány preparált grafikon segítségével néhány tipikus mérési eredmény értelmezéséhez szeretnék segítséget, támpontot nyújtani. Kezdjük CPU mérésekkel!
Az alábbi mérés megfelel egy klasszikus teljesítménytesztnek.
Látható, hogy a teszt elején némileg megnő a CPU terhelés, ami általában elfogadható. A teljesítménytesztek elején ugyanis gyakori a cache-elés, az alkalmazás „magára találása”.
Nagy terheléskor pedig (a teszt vége felé) értelemszerűen megnő a terhelés.
Ugyanezt mutatja a következő ábra is, csak most a hibák előfordulásának a kijelzésével. Hibák jellemzően bármikor előfordulhatnak, de elsősorban magas terhelés esetén várhatóak.
Amennyiben az adott alkalmazás nem képes magas terhelést elviselni, akkor a CPU kihasználtság értékei meredeken emelkednek és a vártnál is hamarabb elérik a maximumot, ahonnan nem mozdulnak el érdemben.
Az alábbi ábra pontosan egy ilyen szituációt ábrázol.
Olykor előfordulhatnak megmagyarázhatatlan jelenségek. Például, hogy a CPU terhelés már a teszt elején is többször megugrik, visszaesik stb.
Ilyenkor meg kell próbálni megkeresni a jelenség okát, ami lehet például az is, hogy a teszttel párhuzamosan egy másik, nem kívánatos folyamat is zajlik a számítógépen. Ezt meg kell szüntetni és a tesztet meg kell ismételni.
A memóriakihasználtság tekintetében a legfontosabb elvárás (amellett, hogy a teszt során nem szökik az egekbe), hogy a teszt végén nagyjából visszaálljon a teszt előtti állapotra. Ez bizonyítja ugyanis, hogy az adott szoftver megfelelően gazdálkodik a memóriával oly módon, hogy például a nem használt területeket ismét felszabadítja stb.
Nem törvényszerű, de sokszor a CPU, RAM magas kihasználtsága és a hibák előfordulása kéz a kézben járnak, azaz ha gond van, ezekből egyszerre többet is megfigyelhetünk.
A következő ábrán egy elvárt memóriaterhelés látszik a teszt során.
Az alábbi grafikon azonban problémát jelez: a felhasznált memóriaterületek a teszt után is lefoglalva maradtak. Ez előbb-utóbb a teljes rendszer összeomlásához is vezethet.
7 Különleges tesztek
7.1 Videojátékok tesztelése
A videojátékipar napjainkra már megelőzte a filmipart bevétel tekintetében és az esport-on keresztül folyamatosan megváltoztatja a szabadidős, vagy éppen professzionális videojátékozásról alkotott képet is.
A streaming játékszolgáltatások igen ígéretesen teret hódítanak, ez pedig pontosan egy olyan terület, ahol a teljesítmény (gyors működés) elementárisan befolyásolja ennek az üzletágnak a sikerét.
A videojátékokat ennek ellenére a lokális futtatásra is finomhangolni kell és a tesztelésnek itt is kiemelkedő jelentősége van.
A gamer számítógépek teljesítményét már évek óta nagy divat tesztelni, olyannyira, hogy egyes tesztprogramok online „dícsőség falat” is működtetnek, ahol megtekinthetőek a legnagyobb sebességű számítógépek eredményei, konfigurációja.
Ezt a fajta teljesítménymérést benchmarkingnak nevezik. Egyes játékprogramok beépített benchmarkkal is rendelkeznek. A végrehajtás során többnyire a CPU, GPU, memória kihasználtságát mérik, ill. ezek hőmérsékletét.
Az eredmények ismeretében a játékosok ellenőrizhetik, hogy hardverük valóban ki tudja-e adni magából az áhított teljesítményt, ill. a hardvertuningolás szerelmesei tovább finomíthatják beállításaikat.
A videojátékok tesztelése a fejlesztési fázisban sem egyszerű feladat. Gondoljunk csak bele: régi és vadonatúj hardverek, eltérő szoftverkörnyezetek és még megannyi lehetséges buktató állhat egy videojáték megfelelő sebességen történő futtatásának útjában.
A fentiek tükrében talán jobban érthető, hogy miért határoznak meg minimális, ill. ajánlott rendszerkövetelményeket a játékprogramokhoz: minden hardveren lehetetlen tesztelni a játékokat. Amelyeken mégis megteszik, csak azokat tudják nyugodt szívvel megadni a készítők.
7.2 Mesterséges intelligencia és tesztelés
Az MI megoldások térhódítása egyelőre megállíthatatlannak tűnik.
A szoftvertesztelés szempontjából 2 kapcsolódási pontja van:
• magának az MI-nek a tesztelése
• az MI munkájának az ellenőrzése.
Bár első ránézésre a két dolog ugyanaz, van egy árnyalatnyi különbség. Egy MI helyes működése alatt itt a működési logika helyességét kell érteni. Ha ez rendben van, csak akkor van értelme az MI munkájának az eredményeit tesztelni.
Az, hogy hogyan működik „belülről” egy MI, már napjainkban is igen nehezen átlátható. Ez akkor válik teljesen black-box dologgá, amikor az MI már önmagát is képes lesz fejleszteni. Napjainkban ennek az előrelépésnek a határán mozog a technológiai fejlődés.
A mesterséges intelligencián alapuló munkák eredményei azért is kirobbanóan népszerűek, mert laikusok számára is jól érthető, sőt élvezhető eredményeket produkálnak: a keresőrendszerek varázslatos módon „kitalálják”, hogy milyen termékeket szeretünk, vagy éppen virtuálisan „életre keltenek” festmények alapján réges-régen élt embereket. Ez mind szép és jó.
De egy MI-nek másfajta feladata is van. Ilyen például a gyógyszerfejlesztés. A koronavírus elleni vakcinák fejlesztésébe egyes cégek már MI-t vontak be például, eredményesen.
Bizonyosan el fog jönni az az idő (méghozzá sokkal hamarabb, mint gondolnánk), amikor az MI-alapú technológia már olyan bonyolultan fog működni, hogy azt élő ember már nem lesz képes ellenőrizni. Az így készített termékeket, melyek lehetnek szoftverek is, vagy alaposan, tetemes időráfordítással letesztelik emberek is, vagy egyszerűen vakon elhiszik majd, hogy amit az MI eldöntött, az jó lesz. Ha nincsen idő ellenőrizgetni, akkor ez egy valós dilemma. Ennek legékesebb példája az önvezető autók esete, ahol a másodperc tört része alatt születnek döntések és ami marad, az csak a vak bizalom a gépben.
Az MI tehát rendesen feladja a leckét a szoftvertesztelésnek is. Közeleg egy szép új világ?