Mi a teszt automatizálás? Egyszerű, világos bevezetés

A szoftverek világában kétféle tesztelés létezik – kézi és automatizált. A manuális tesztelés egyes típusai, mint például a felfedező tesztelés és a használhatósági tesztelés, felbecsülhetetlen értékűek. A tesztelés más fajtáit – például a regressziós tesztelést és a funkcionális tesztelést – manuálisan is elvégezhetjük, de meglehetősen pazarló gyakorlat az emberek számára, hogy újra és újra ugyanazt csinálják. Az ilyen típusú, ismétlődő tesztek alkalmasak a tesztek automatizálására.

A tesztek automatizálása a tesztek automatikus futtatásának, a tesztadatok kezelésének és az eredmények felhasználásának gyakorlata a szoftver minőségének javítása érdekében. Elsősorban minőségbiztosítási intézkedés, de tevékenységei a teljes szoftvergyártó csapat elkötelezettségét igénylik. Az üzleti elemzőktől kezdve a fejlesztőkön át a DevOps mérnökökig mindenki bevonására szükség van ahhoz, hogy a legtöbbet hozza ki a teszt automatizálásból.

Ez a bejegyzés magas szintű megértést nyújt arról, hogy miről is szól a teszt automatizálás. Mindenféle teszt létezik, de nem mindet kell automatizálni, ezért kezdjük a teszt automatizálás általános kritériumaival.

Az automatizálás kritériumai

A tesztnek meg kell felelnie néhány kritériumnak ahhoz, hogy automatizálható legyen – máskülönben a végén többe kerülhet, mint amennyit megtakarít. Végül is az automatizálás egyik fő célja az idő-, munka- és pénzmegtakarítás. Íme néhány általános kritérium a tesztek automatizálásához. Ezek kiindulási pontok, ne feledje. Az Ön kritériumai a körülményektől függően eltérhetnek.

Megismételhető

A tesztnek megismételhetőnek kell lennie. Nincs értelme olyan tesztet automatizálni, amelyet csak egyszer lehet lefuttatni. Egy megismételhető teszt a következő három lépésből áll:

  1. A teszt beállítása, beleértve az adatokat és a környezetet.
  2. A függvény végrehajtása és az eredmény mérése.
  3. Az adatok és a környezet tisztítása.

Az első lépésben a környezetet konzisztens állapotba akarjuk hozni. Más szóval, ha van egy tesztünk egy meglévő felhasználó hozzáadásának megkísérlésére, akkor a teszt elvégzése előtt meg kell győződnünk arról, hogy a felhasználó létezik. A teszt elvégzése után a környezetet vissza kell állítani az alapállapotba.

Determináns

Ha egy függvény determináns, az azt jelenti, hogy az eredmény minden alkalommal ugyanaz, amikor ugyanazzal a bemenettel futtatjuk. Ugyanez igaz az automatizálható tesztekre is. Tegyük fel például, hogy egy összeadási függvényt szeretnénk tesztelni. Tudjuk, hogy 1 + 1 = 2 és hogy 394,19 + 5,81 = 400,00. Az összeadás egy determináns függvény.

A szoftverek viszont olyan nagyszámú változó bemenetet használhatnak, hogy nehéz mindig ugyanazt az eredményt kapni. Egyes változók akár véletlenszerűek is lehetnek, ami megnehezítheti a konkrét eredmény meghatározását. A szoftvertervezés ezt úgy kompenzálhatja, hogy tesztbemeneteket tesz lehetővé egy tesztkészleten keresztül.

Az alkalmazás egyéb jellemzői lehetnek additívak; például egy új felhasználó létrehozása növeli a felhasználók számát. Legalább amikor hozzáadunk egy felhasználót, tudjuk, hogy a felhasználók száma csak eggyel nőhet. A tesztek párhuzamos futtatása azonban váratlan eredményeket okozhat. Az elszigeteléssel megelőzhető az ilyen típusú hamis pozitív eredmény.

Egyetértés nélküli

Egyetértési kérdéseket nem lehet automatizálni. Ez az a terület, ahol a használhatósági tesztelés, a béta tesztelés stb. igazán ragyog. A felhasználói visszajelzés fontos, de egyszerűen nem lehet automatizálni … sajnálom!

Az automatizált tesztek típusai

A teszteknek olyan sok típusa van, amelyek közül sok automatizálható, hogy nem igazán tudjuk mindet egy posztba foglalni. De itt van elég ahhoz, hogy jó kiindulópontot adjon.

Kódelemzés

A kódelemző eszközöknek valójában sokféle típusa létezik, beleértve a statikus elemzést és a dinamikus elemzést. Ezek közül egyes tesztek biztonsági hibákat keresnek, mások a stílust és a formát ellenőrzik. Ezek a tesztek akkor futnak le, amikor a fejlesztő ellenőrzi a kódot. A szabályok konfigurálásán és az eszközök naprakészen tartásán kívül nem sok tesztet kell írni ezekkel az automatizált tesztekkel.

Unit tesztek

Egy unit tesztcsomagot is automatizálhat. Az egységtesztek egyetlen funkció vagy műveleti egység elszigetelt tesztelésére szolgálnak. Ezek jellemzően egy build szerveren futnak. Ezek a tesztek nem függenek adatbázisoktól, külső API-któl vagy fájltárolóktól. Gyorsnak kell lenniük, és csak a kódot kell tesztelniük, a külső függőségeket nem.

Integrációs tesztek

Az integrációs tesztek másfajta állatot jelentenek, ha automatizálásról van szó. Mivel az integrációs teszteknek – amelyeket néha végponttól végpontig tartó teszteknek is neveznek – kölcsönhatásba kell lépniük a külső függőségekkel, bonyolultabb a beállításuk. Gyakran a legjobb, ha hamis külső erőforrásokat hozunk létre, különösen akkor, ha olyan erőforrásokkal van dolgunk, amelyekre nincs ráhatásunk.

Ha például van egy logisztikai alkalmazásunk, amely egy szállító webes szolgáltatásától függ, a tesztünk váratlanul meghiúsulhat, ha a szállító szolgáltatása nem működik. Ez azt jelenti, hogy az alkalmazásod elromlott? Lehet, de elegendő kontrollal kell rendelkeznie a teljes tesztkörnyezet felett ahhoz, hogy minden egyes forgatókönyvet explicit módon hozzon létre. Soha ne függjön egy külső tényezőtől a tesztforgatókönyve kimenetelének meghatározása.

Automatizált elfogadási tesztek

Már számos gyakorlat létezik manapság, amely automatizált elfogadási teszteket (AAT) használ, de alapvetően ugyanazt csinálják. A viselkedésvezérelt fejlesztés (BDD) és az automatizált elfogadási tesztek által vezérelt fejlesztés (AATDD) hasonló. Mindkettő ugyanazt a gyakorlatot követi: az elfogadási tesztet a funkció fejlesztése előtt készítik el.

Az automatizált elfogadási teszt végül lefut, hogy megállapítsa, a funkció teljesíti-e azt, amiben megállapodtak. Ezért kritikus fontosságú, hogy a fejlesztők, az üzlet és a minőségbiztosítás együtt írják meg ezeket a teszteket. Ezek a jövőben regressziós tesztekként szolgálnak, és biztosítják, hogy a funkció megfeleljen az elvárásoknak.

Regressziós tesztek

Az AAT-ok hiányában utólag kell regressziós teszteket írni. Bár mindkettő a funkcionális tesztek formája, a megírásuk módja, időpontja és az, hogy ki írja őket, nagyban különbözik egymástól. Az AAT-okhoz hasonlóan ezeket is lehet API-n keresztül kóddal vagy felhasználói felülettel vezérelni. Léteznek olyan eszközök, amelyekkel ezeket a teszteket GUI segítségével írhatjuk meg.

Teljesítménytesztek

Teljesítménytesztek sokféle létezik, de mindegyik az alkalmazás teljesítményének valamilyen aspektusát teszteli. Vajon bírja-e a szélsőséges nyomást? Teszteljük a rendszert a nagy hőségre? Egyszerűen a terhelés alatti válaszidőre vagyunk kíváncsiak? Mi a helyzet a skálázhatósággal?

Néha ezek a tesztek hatalmas számú felhasználó emulálását igénylik. Ebben az esetben fontos, hogy olyan környezet álljon rendelkezésre, amely képes egy ilyen mutatvány elvégzésére. Az ilyen típusú teszteléshez felhőalapú erőforrások állnak rendelkezésre, de helyben is használhatunk erőforrásokat.

Füsttesztek

Mi az a füstteszt? Ez egy alapvető teszt, amelyet általában egy telepítési vagy karbantartási ablak után végeznek el. A füstteszt célja annak biztosítása, hogy minden szolgáltatás és függőség működőképes legyen. A füstteszt nem egy teljes körű funkcionális teszt. Futtatható egy automatizált telepítés részeként vagy egy kézi lépéssel kiváltható.

Általános teszt-automatizálási folyamat

Most, hogy láttuk az automatizálás kritériumait és az automatizált tesztek elég típusát ahhoz, hogy érezzük a dolgokat, íme a teszt-automatizálás általános folyamata. A tesztautomatizálásnak három fő lépése van: előkészítés, cselekvés, eredmények jelentése.

Előkészítés

Először is elő kell készítenünk az állapotot, a tesztadatokat és a környezetet, ahol a tesztek zajlanak. Mint láttuk, a legtöbb teszt megköveteli, hogy a környezet egy bizonyos állapotba kerüljön, mielőtt egy műveletre sor kerülne. Egy tipikus forgatókönyvben ez némi előkészítést igényel. Vagy az adatokat kell manipulálni, vagy az alkalmazást kell egy adott állapotba helyezni, vagy mindkettőt!

Akció végrehajtása

Mihelyt az állapot és/vagy a környezet az előre meghatározott állapotban van, itt az ideje az akciónak! A tesztillesztő lefuttatja a tesztet, akár az alkalmazás API-jának vagy felhasználói felületének meghívásával, akár a kód közvetlen futtatásával. A tesztmeghajtó felelős a tesztek “vezetéséért”, de a tesztmenedzsment rendszer átveszi a felelősséget, hogy mindent koordináljon, beleértve az eredmények jelentését is.

Eredmények jelentése

A tesztautomatizálási rendszer rögzíti és jelenti az eredményeket. Ezek az eredmények számos különböző formátumban érkezhetnek, és akár problémajegyeket vagy hibákat is létrehozhatnak egy munkakövetési rendszerben. Az alapvető eredmény azonban a megfelelt vagy nem felelt meg. Általában minden egyes tesztforgatókönyvhöz tartozik egy zöld vagy piros jelző, amely a sikeres vagy sikertelen tesztet jelzi.

Néha a tesztek nem eredményesek, vagy valamilyen okból nem futnak le. Amikor ez megtörténik, az automatizálási rendszer teljes kimeneti naplóval rendelkezik, amelyet a fejlesztők áttekinthetnek. Ez a napló segít nekik a probléma felderítésében. Ideális esetben képesek lesznek újra lejátszani a forgatókönyvet, ha már bevetették a javítást.

A lényeg

A lényeg a következő: a tesztautomatizálás gyorsasággal segít a minőség javításában. De nem minden tesztelés automatizálható. Mindenképpen befektetéssel jár. A sokféle teszt esetén fontos a megfelelő keverék. A tesztpiramis egy egyszerű hüvelykujjszabály, amely segít ennek helyes megválasztásában. Eszerint a legtöbb tesztnek egységtesztnek kell lennie, ezt követik a szolgáltatástesztek, majd az UI-tesztek.

A teszt-automatizálási rendszer koordinálja a tesztelési szempontokat, beleértve a tesztadatok kezelését, a tesztek futtatását és az eredmények nyomon követését. A tesztautomatizálás a következő lépés azon csapatok számára, amelyek számára túlterhelődik ugyanazoknak a kézi teszteknek az ismétlése, amelyeket automatizálni kellene.

A szerző életrajza: Ezt a bejegyzést Phil Vuollet írta. Phil szoftvereket használ folyamatok automatizálására a hatékonyság és az ismételhetőség javítása érdekében. A technológiát és az üzleti életet érintő témákról ír, időnként előadásokat tart ugyanezekről a témákról, és családos ember, aki szívesen focizik és társasjátékozik a gyerekeivel.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.