REST API tesztelési oktatóanyag: Minta manuális tesztesetek

Mi az a REST API tesztelés?

REST API tesztelés egy nyílt forráskódú webes automatizálási tesztelési technika, amelyet webes alkalmazások RESTful API-jainak tesztelésére használnak. A REST API tesztelés célja a REST API válaszának rögzítése különféle HTTP/S kérések küldésével annak ellenőrzésére, hogy a REST API megfelelően működik-e vagy sem. A REST API tesztelést GET, POST, PUT és DELETE metódusokkal végzik.

REST a reprezentatív államtranszfer rövidítése. Ez egy építészeti stílus és egy kommunikációs megközelítés, amelyet a fejlesztés során használnak Web ServicesA REST logikus választássá vált az API-k fejlesztéséhez, mivel lehetővé teszi a felhasználók számára a felhőszolgáltatásokkal való hatékony kapcsolatot és interakciót.

Az API, vagy Application Programming Interface, egy webes szoftveralkalmazások elérésére szolgáló programozási utasítások halmaza. Más szóval, egy parancshalmaz, amelyet egy program használ a másikkal való közvetlen kommunikációhoz, és egymás függvényeinek használatához információk megszerzéséhez.

Például egy Google Egy weboldal rendelkezhet API-val a kereséshez, fordításokhoz és naptárakhoz. Általánosságban elmondható, hogy az API-k az alábbi példához hasonlóan néznek ki, egy szervernévvel, elérési úttal és paraméterekkel.

http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv

De miért kellene egyáltalán tesztelési erőfeszítéseket tenni ebbe a rétegbe?

Miért fontos a REST API tesztelés?

A REST API a felhasználói felület és az adatbázis között helyezkedik el, így ez az a réteg, ahol a legtöbb üzleti logika valójában található. Egy árképzési szabály vagy egy jogosultságellenőrzés hibája jóval azelőtt megjelenik az API válaszában, hogy bárki hibás számot észlelne a képernyőn, így az itt végzett tesztelés korábban és közelebb hozza a problémákat az okukhoz.

A második ok a sebesség. Egy kérés milliszekundumok alatt teljesíthető, és nincs szükség böngészőre, renderelőmotorra vagy törékeny elemek azonosítóira. Egy tesztelő több tucat végpontot is tesztelhet egy oldal betöltéséhez szükséges idő alatt, és ugyanaz a kérés ugyanúgy viselkedik, függetlenül attól, hogy a front-end egy weboldal, egy mobilalkalmazás vagy egy partnerintegráció.

A stabilitás a harmadik ok. Az elrendezések folyamatosan változnak, de egy publikált REST kontracvárhatóan állandó marad. Az ellene írt tesztektracnem élik túl az újratervezést, így védik a termék azon részeit, amelyekre más csapatok ténylegesen építenek.

API-módszerek típusai

Főleg 4 típusa van API tesztelés metódusok: GET, POST, DELETE és PUT.

• GET– A GET metódust használják a következőkre:tract információt kér le az adott szerverről egy adott URI használatával. GET kérés használatakor csak akkor szabadtract adatok, és nem lehet más hatással az adatokra.
• POST– A POST kérés új entitás létrehozására szolgál. Használható továbbá adatok küldésére a szerverre, például ügyfélinformációk, fájlfeltöltés stb. HTML űrlapok segítségével.
• PUT– Hozzon létre egy új entitást vagy frissítsen egy meglévőt.
• DELETE– Eltávolítja a cél erőforrás URI által adott összes jelenlegi reprezentációját.

A REST API tesztelése

A REST API teszteléshez az alkalmazásnak egy minta API-val kell interakcióba lépnie tesztelés céljából. Egy API teszteléséhez két dologra van szükség:

• Tesztelőeszköz/keretrendszer az API működtetéséhez
• Írja le saját kódját a minta REST API teszteléséhez

A REST API tesztesetek olyan eszközökkel tesztelhetők, mint:

• Advanced Rest Client
• Postman-Rest Client
• Curl Linux alatt

Itt az Advanced Rest Client programot fogjuk használni. Az alábbiakban a Advanced Rest Client beszerzésének lépései láthatók.

Hogyan szerezhetek Advanced Rest klienst?

• Tovább Google Chromewebáruháza
• Keressen rá az „Advanced Rest Client” kifejezésre, vagy menjen közvetlenül itt és telepítse a bővítményt
• Válassza ki az „Advanced Rest Client” ikont a chrome alkalmazásrésze alatt – chrome://apps/

A webáruház listája az alábbiak szerint jelenik meg.

A telepítés befejezése után kövesse az alábbi tesztet a teszteléshez RESTful API.

A REST API tesztelésének lépései

Itt a REST kliensbővítményt használjuk a Chrome böngészőben. A jobb megértés érdekében egy próba API-t használunk tesztelésre:

http://ip.jsontest.com/

1. lépés: Nyissa meg az Advanced REST klienst

Indítsa el az Advanced REST Client (ARC) alkalmazást, miután sikeresen telepítette.

2. lépés) Írja be a URL az API tesztelése

Adja meg a minta REST API-t URL tesztelésre a URL szövegdoboz.

3. lépés) Válassza ki a HTTP-módszert

Válassza ki a HTTP metódusok típusának metódusát az API-tesztelésben, hogy elérje, pl. POST

4. lépés) Adja meg a fejléckészletet

Adja meg a Fejlécek készletét a Fejlécek szövegmezőben. Kattintson a Fejléckészlet beszúrása gombra.

5. lépés) Erősítse meg a fejlécek beállítását

Következő Kattintson a KÉSZLET HASZNÁLATA lehetőségre.

6. lépés: Adja meg a szükséges testtartalmat

1. Most váltson át a Test fülre.
2. Állítsa be a szükséges törzstartalom típust és a szerkesztő nézetet, pl.: Body content type : application/json
3. Szerkesztő nézet: Nyers bevitel.
4. A Payload alatt add át a teszteléshez szükséges demó API kérés törzsét kulcs-érték párok formájában, például {“key1″:”value1″,”key2″:”value2”}. Ha POST API-ról van szó, akkor törzset vagy paramétereket kell átadnunk. Ezt a megadott payload alatt fogjuk átadni.

{"property" : ["Sites"], "report_type" : ["ALL"]}

⚠️ Figyelmeztetés: Egy application/json Content-Type típusú fájl, amelynek hasznos adata érvénytelen JSON 400-as hibás kérést ad vissza.

7. lépés) A teszt elindításához küldje el a részleteket

1. Nyomja meg a küldés gombot.
2. A RÉSZLETEK gombra kattintva megtekintheti a válaszfejléceket.

Íme a válasz részletei:

A választ továbbra is a várható eredményhez kell viszonyítani.

Az eredmények érvényesítése

Főként a Web API teszteléshez a válaszkódot, a válaszüzenetet és a válasz törzsét kell ellenőriznünk.

A válaszkódok öt családba sorolhatók:

Az alábbiakban láthatók a lehetséges válaszkódok.

Egyetlen kérés bizonyítja, hogy a végpont működik. Egy csomag bizonyítja, hogy folyamatosan működik.

REST API tesztesetek, amiket le kell fedned

Egy hasznos REST API csomag több kategóriára terjed ki ahelyett, hogy ugyanazt a boldog útvonalhívást ismételgetné különböző adatokkal:

• Boldog út: Küldjön érvényes kérést minden végpontnak, és erősítse meg az állapotkódot, a sémát és az összes mező értékét.
• Negatív esetek: Küldjön hibásan formázott JSON-t, egy nem támogatott metódust és egy hiányzó erőforrás-azonosítót, majd várjon 400-as, 405-ös és 404-es kódot az 500-as helyett.
• Határértékek: Ha egy mező 1 és 200 karakter közötti hosszúságú karaktereket fogad el, tesztelje a 0, 1, 200 és 201 értékeket. Az érvényességi szabályok a széleken megszakadnak.
• Speciális karakterek: Ékezetes betűket, emojikat, idézőjeleket és több bájtos szöveget helyezhet át minden mezőn a kódolási hibák felfedése érdekében.
• Contract ellenőrzések: Hasonlítsa össze a választ a közzétett OpenAPI vagy Swagger specifikációval, hogy a nem dokumentált változások korán észrevehetők legyenek.
• Szekvenálás: A végpontokat reális sorrendben hívjuk meg, például POST, GET, majd DELETE, mivel az állapot a hívások között változik.
• Teljesítmény-észlelés: Rögzítse a válaszidőket minden futtatáskor, és jelölje meg azokat a végpontokat, amelyek átlépik a csapattal egyeztetett küszöbértéket.

REST API teszteszköz

A különböző eszközök a tesztelés különböző szakaszaihoz igazodnak.

Lásd az összefoglalót API tesztelő eszközök.

A legtöbb valós végpont megtagadja a válaszadást, amíg a kérés be nem bizonyosodik, hogy ki küldte.

REST API hitelesítés és biztonsági ellenőrzések

A nyilvános demó végpontok bárkire választ adnak, de egy éles REST API egy hitelesítési séma mögött található, és egy engedélyezési hiba sokkal károsabb, mint egy helytelen mezőérték. Először is azonosítsa a mechanizmust: statikus API-kulcs, HTTP Basic hitelesítő adatok, OAuth 2.0 tulajdonos token vagy aláírt JSON webes token.

Miután egy hitelesített kérés sikeres, haladj végig a sikertelen útvonalakon:

1. Nincsenek hitelesítő adatok: Távolítsa el az Authorization fejlécet. Várhatóan 401 Unauthorized hiba és rekordadatok hiánya lesz a törzsben.
2. Hibás hitelesítő adatok: A token egy karaktere megsérült. Várhatóan ismét 401-es hibaüzenet jelenik meg, egy olyan üzenettel, amely nem magyarázza meg az okát.
3. Lejárt hitelesítő adatok: token újrafelhasználása a lejárati ideje után. Győződjön meg arról, hogy elutasításra kerül, ahelyett, hogy elfogadná, ami egy gyakori órajel-elcsúszási hiba.
4. Hibás jogosultsági szint: Alacsony jogosultságú felhasználóként hitelesítsd magad, és hívj meg egy csak rendszergazdai hozzáférésű végpontot. Várj 403-as „Tiltott” hibát, ne 200-ast.
5. Egy másik felhasználó rekordja: Változtasd meg az azonosítót, hogy A felhasználó lekérje B felhasználó adatait. A siker itt komoly hozzáférés-vezérlési hibát jelez.

Végül győződjön meg arról, hogy minden hívás HTTPS-en keresztül halad, hogy a sikertelen válaszok nem szivárogtatnak veremből. traces vagy verzióbannereket, és hogy a gyors ismétlődések 429 túl sok kérést váltanak ki.

A REST API tesztelés olyan nehézségeket is okoz, amelyekkel az interfész tesztelés nem.

Az API tesztelésének kihívásai

A tesztelők számára a REST API tesztelés során felmerülő érdekes problémák a következők:

1. Annak biztosítása, hogy a tesztkábelezés úgy változtassa az API-hívások paramétereit, hogy az ellenőrizze a funkcionalitást, valamint feltárja a hibákat. Ez magában foglalja a peremfeltételek feltárását és a közös paraméterek hozzárendelését.
2. Érdekes paraméterérték-kombinációk létrehozása két vagy több paraméterrel rendelkező hívásokhoz
3. Az API-hívások tartalmának azonosítása. Ez magában foglalhatja a külső környezeti feltételek (perifériák, fájlok stb.), valamint az API-t befolyásoló belsőleg tárolt adatok beállítását.
4. Az API-hívások szekvenálása a függvény végrehajtási sorrendje szerint
5. Hogy az API hasznos eredményeket produkáljon az egymást követő hívásokból.

GYIK