a webalkalmazások tesztelése

a szoftveriparban mindenki valamilyen módon teszteli alkalmazásait. Sok fejlesztői csapat kidolgozott tesztelési sémákkal rendelkezik, amelyek jól integrálódnak a folyamatos integrációs folyamatokba, de még azoknak is, akiknek nincs automatikus tesztjük, még mindig ki kell találniuk a módját annak ellenőrzésére, hogy kódjuk a rendeltetésszerűen teljesít-e.

egy weboldal létrehozása és a böngészővel történő kézi átkattintás sokféle tesztelést jelent. Bár ez nem a legkifinomultabb, mégis számít. Ugyanez igaz a curl indítására a konzolon, és egy szintetikus kérés küldésére az éppen létrehozott API végpontra.

ez a bejegyzés megvitatja, hogyan lehet automatizálni a már elvégzett kézi tesztelést, mielőtt különböző teszttípusokba és módszertanokba merülnénk.

tesztek automatizálása

a kézi tesztek elegendőek a kis alkalmazásokhoz, de amikor ezek az alkalmazások növekednek, tesztelhető felületük növekszik velük, ami két problémát okoz.

egy, amikor az embereknek minden alkalommal teszteket kell végezniük, amikor egy alkalmazás új verziója befejeződik, következetlenségek merülhetnek fel. Ez különösen igaz, ha sok teszt van. Kettő, a teszteket végző személy nem végezhet más feladatokat. Nagy alkalmazások esetén a tesztelés több napot is igénybe vehet.

a két probléma megoldásának leglogikusabb módja a kézi feladatok automatizálása. A webes alkalmazások tesztjeinek két fő típusa létezik: UI tesztek és API tesztek. Két eszköz automatizálhatja őket.

UI tesztek

az UI teszteket egy bábos nevű eszközzel lehet elvégezni. Puppeteer lehetővé teszi, hogy automatizálják a kézi UI teszt JavaScript használatával. Az NPM-en keresztül telepítve van a következő paranccsal:

 $ npm i puppeteer

ezután írhat egy szkriptet, amely a Chrome fej nélküli verzióját vezérli a tesztek futtatásához. Ez a szkript a következőképpen nézhet ki:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

ebben a szkriptben elindítjuk a Chrome fej nélküli példányát, navigálva example.com, és keres egy h1 elemet. Ha nem létezik, hibaüzenet kerül naplózásra.

API tesztek

API tesztek automatizálhatók Postman segítségével. Postman jön egy grafikus felület épület HTTP kéréseket lehet menteni. Ezek a kérések lehet végrehajtani később csak egy kattintással.

az induláshoz töltse le és telepítse a Postman felhasználói felületet. A kérelem létrehozásához és mentéséhez a következő lépésekre van szükség:

1. kattintson a gyűjtemény létrehozása elemre a bal oldalon
2. írja be a gyűjteményemet a gyűjtemény neveként
3. kattintson a Létrehozás
4. kattintson a gyűjteményem ellipszisére (…) a bal oldalon
5. válassza a Hozzáadás kérés
6. írja be a kérésemet a kérelem neveként
7. kattintson a Mentés a Gyűjteményembe

a kérés a bal oldali sávban jelenik meg az újonnan létrehozott gyűjtemény alatt.

ha kiválasztja, meg kell adnia example.com mint egy URL-t, és adjunk hozzá egy teszt. Teszt hozzáadásához kattintson a tesztek elemre az URL beviteli mező alatti fülsávon.

megjelenik egy szövegterület, amelybe a tesztet JavaScriptben írhatja. A következő példa egy tesztre:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

ha a képernyő jobb felső sarkában a Mentés gombra kattint, majd közvetlenül utána küldi el, a kérését elküldjük. Ezután a teszt szkript végrehajtja annak megállapítását, hogy a válasz állapota 200 volt-e vagy sem.

a vizsgálatok típusai

három különböző típusú vizsgálat létezik. Ezek megértése lehetővé teszi, hogy kiválassza a megfelelő típusú tesztelést a szoftvercsomag különböző részeihez.

Egységtesztek

az Egységtesztek a legegyszerűbb teszttípusok. Ellenőrzik a kód kis részeinek helyességét. Az egységteszt általában egy függvényhívásra vagy egy osztály használatának egyik módjára terjed ki.

az egységteszt általában a kód első “felhasználója”. Egyes tesztmódszerek még a teszt megírását is megkövetelik a tényleges alkalmazáskód végrehajtása előtt.

az Egységtesztek mind a backend, mind a frontend fejlesztésben használhatók. Egyes fejlesztőcsapatok egységtesztekkel ellenőrzik a kód kis részeinek, például űrlapoknak vagy menüknek a renderelt DOM kimenetét. A háttérprogramban az egységteszteket gyakran használják a HTTP-kiszolgáló és az adatbázis vagy más API-k közötti kód tesztelésére.

három széles körben használt tesztfutók unit tesztek:

‐ Jest—Jest többnyire frontend fejlesztés, mert jön az egyedi funkciók, mint a pillanatfelvétel tesztelés, amelyek segítenek a problémák, mint UI regresszió. A tréfa tutorial megtalálható itt.

‐ AVA—AVA kedvelt backend fejlesztés, mert specializálódott erősen párhuzamos végrehajtása vizsgálatok. Az AVA bemutató itt található.

‐ PHPUnit—a PHPUnit egy népszerű keretrendszer az egységtesztekhez a PHP-ben. A PHPUnit bemutató itt található.

ha egy unit teszt külső erőforrásokat igényel, például hálózati kapcsolatokat vagy adatbázisokat, akkor valószínűleg integrációs tesztet ír. Ez a fajta teszt a következő.

integrációs tesztek

a megvalósítás szempontjából az integrációs tesztek egységteszteknek tűnnek. A különbség az, hogy az integrációs tesztek a verem több részét együtt tesztelik. Például tesztelhetik, hogy az ügyfél és a kiszolgáló ugyanazt a protokollt beszéli-e, vagy egy mikroszolgáltatási architektúrában, hogy a szolgáltatások megfelelően működnek-e együtt.

azokat az ellenőrzéseket, amelyek általában több Független egységtesztben végződnek, egyetlen integrációs tesztbe lehet összesíteni, amely meghatározza, hogy minden jól működik-e együtt.

integrációs teszteket használnak mind a frontend, mind a backend fejlesztésben. Néha arra használják őket, hogy megnézzék, a két rész helyesen működik-e egymással, de felhasználhatók annak meghatározására is, hogy az egyik rész különböző moduljai rendeltetésszerűen működnek-e együtt.

ugyanazokat a tesztfutókat használhatja az integrációs tesztekhez, mint amelyeket az egységtesztekhez használt. A Postman, a kézi API-tesztek automatizálásához fent használt felhasználói felület eszköz azonban egy Newman nevű CLI eszközzel is rendelkezik, amely integrálható a CI/CD csővezetékbe.

a Newman képes exportált Postman gyűjtemények futtatására, így kéréseket és teszteket hozhat létre a Postman felhasználói felületével, majd később futtathatja őket a CLI-n keresztül. A Newman bemutató itt található.

ha egy integrációs teszt interakciót igényel a felhasználói felülettel, akkor azt UI tesztnek hívják—címzett következő.

UI tesztek

az UI tesztek a legkifinomultabb tesztek. Megpróbálják automatizált módon utánozni a felhasználói viselkedést, hogy a tesztelőknek ne kelljen manuálisan átkattintaniuk alkalmazásuk minden részét.

az UI tesztek gyakran segítenek rögzíteni egy adott interakciót, amely hibához vezetett a felhasználó számára. Miután elfogták, akkor lehet reprodukálni egy kattintással annak érdekében, hogy rögzítse a hibát, és megakadályozza, hogy jön vissza egy új verziót.

a korábban említett Jest és AVA tesztfutók itt használhatók, de általában szükség van egy extra könyvtárra, hogy megkönnyítse a felhasználói felület interakcióját egy böngészőn keresztül. A folyamatban jelenleg használt két fő könyvtár a következő:

‐ Puppeteer—a Puppeteer egy JavaScript könyvtár, amely a Chrome fej nélküli megvalósításával rendelkezik, amely lehetővé teszi a felhasználói felület tesztjeinek programozott futtatását a háttérben. A bábos bemutató itt található.

‐ szelén—a szelén egy olyan keretrendszer, amely lehetővé teszi a böngésző távvezérlését a WebDriver nevű könyvtáron keresztül. A szelén bemutató itt található.

több típusú teszt létezik, mint az itt felsoroltak. Másoknak különböző céljaik lehetnek; például a terhelési tesztek megpróbálják megtalálni a teljesítmény szűk keresztmetszeteit. Ne feledje, hogy az itt leírt tesztek néha különböző neveket kapnak. A fent bemutatott három típus elengedhetetlen az induláshoz. Az egyik használata jobb, mint egyáltalán nem automatizált tesztelés.

vizsgálati módszerek

a vizsgálati módszerek a tesztelés gondolkodásának módjai. Az alábbiakban leírt három a leggyakrabban használt.

Tesztvezérelt fejlesztés (TDD)

a TDD a legszélesebb körben alkalmazott módszertan és a legtechnikaibb. Azt javasolja, hogy írja meg a teszteket, mielőtt megírná a tesztelni kívánt tényleges kódot. Mivel a kódnak csak a végrehajtott részéhez kell tesztet írnia, az írandó teszt típusa egységteszt.

az Egységtesztek meglehetősen szemcsések, így idővel ennek a módszertannak a használata sok teszt felhalmozódását eredményezi. Ez a valóság, párosulva azzal a ténnyel, hogy a kezdő TDD-szakemberek hajlamosak triviális teszteket írni, egy halom haszontalan teszt létrehozásához vezethet. Ennek elkerülése érdekében elengedhetetlen a tesztek frissítése és tisztítása, amikor a csapat jobban megismerte a TDD-t és általában a tesztelést.

fontos, hogy a teszteket gyakran futtassa, nem csak CI/CD csővezetékben, hanem helyben is a fejlesztőgépén. Írj egy tesztet, futtasd le, lásd, hogy nem sikerül, hajts végre eleget ahhoz, hogy a teszt sikeres legyen, és ismételd meg a folyamatot.

további olvasmányokért nézd meg az Agile Alliance TDD leírását.

átvételi Tesztvezérelt fejlesztés (ATDD)

az ATDD a TDD olyan módosítása, amely inkább az üzleti esetekre, kevésbé a műszaki megvalósításra összpontosít. Az ebben a módszertanban használt teszttípusok többnyire integrációs tesztek, mivel gyakran a rendszer több részét együtt kell használni egy üzleti igény megoldásához.

mivel a tesztek kevésbé technikai jellegűek, tanácsos a nem technikailag orientált embereket is bevonni a tesztelési folyamatba. A terméktulajdonosok és az ügyfelek segíthetnek meghatározni az üzleti eseteket, hogy a fejlesztő tesztet írhasson nekik. Ha a tesztet nem lehet sikeresen futtatni, egyértelmű, hogy több funkciót kell végrehajtani.

az ATDD más absztrakciós szinten működik, mint a TDD, így a két módszertan együtt használható.

további olvasmányokért nézd meg az Agile Alliance TDD leírását.

Behavior Driven Development (BDD)

a BDD a TDD és az ATDD keveréke, és célja, hogy mindkét világ legjobbjait használja a teljes rendszer stabilabbá tételéhez. A BDD megpróbálja meghatározni a rendszert olyan tesztekkel, amelyek szemléltetik annak használatát.

az ATDD-hez hasonlóan a BDD megpróbálja megragadni az üzleti eseteket. Ugyanakkor azt is megköveteli, hogy megkérdőjelezze ezeket a használati eseteket az “5 miért” – vel, mert a “miért” hiányzik az ATDD-ben. Persze, jobb, ha megkérdezzük az ügyfeleket, mit akarnak, ahelyett, hogy kizárólag a fejlesztői bemenetre támaszkodnánk. De az is fontos, hogy megkérdőjelezzük mindkét csoport feltételezéseit.

a BDD a TDD és az ATDD keveréke az absztrakciós szintek értelmében. A TDD csak az alkalmazás kis részeit teszteli, az ATDD pedig csak azt, hogy ezek az alkatrészek hogyan működnek együtt. A BDD megköveteli, hogy ezt a módszertant alkalmazza az alkalmazás nagy egészére és annak kis részeire, így a BDD holisztikusabb megközelítést alkalmaz a teszteléshez.

további olvasmányokért nézd meg az Agile Alliance BDD leírását.

következtetés

bár a tesztelés nem szörnyű, a kézi tesztelés jobb, az automatizált tesztelés pedig a legjobb.

az alkalmazás méretétől függően a kézi teszt napokig vagy akár hetekig megakadályozhatja a fejlesztőcsapat tagjait abban, hogy más projekteken dolgozzanak, ami az üzleti időbe és pénzbe kerül. Ezenkívül az azonos interakciók újra és újra elvégzésének monoton feladata olyan csúszásokhoz vezethet, amelyek gyakran nem fogott hibákban nyilvánulnak meg.

a számítógépek nagyon jól tudják ugyanazt a feladatot újra és újra megismételni, ezért érdemes a tesztelést egy szkriptre bízni, és felszabadítani a fejlesztők idejét. Ha ezek a tesztek be vannak építve a CI / CD folyamatba, akkor a már megírt tesztek csak implicit módon futtathatók, amikor egy új commit landol a tárolókban.

jó ötlet a tesztelési módszertan korai alkalmazása, mert gyakran a nagy problémák az induláskor a” mit “és a” mikor ” a teszteléshez. Ezek a módszerek segíthetnek tisztázni egy olyan folyamatot, amely következetesebbé teszi a tesztek írását a csapat minden tagja számára.