Mi az az interfész tesztelése? Típusok és példa

Mi az az interfész tesztelése?

Interfész tesztelése egy olyan szoftvertesztelési típusként definiálják, amely ellenőrzi, hogy két különböző szoftverrendszer közötti kommunikáció megfelelően működik-e.

Egy olyan kapcsolatot, amely két komponenst integrál, interfésznek nevezünk. Ez az interfész a számítógépes világban bármi lehet, például API-k, webszolgáltatások stb. Ezen csatlakozó szolgáltatások vagy interfészek tesztelését interfész tesztelésnek nevezzük.

Az interfész valójában olyan szoftver, amely parancsokból, üzenetekből és egyéb attribútumokból áll, amelyek lehetővé teszik az eszköz és a felhasználó közötti kommunikációt.

A lényeg az, hogy egy interfésznek van egy hátrányatract: egy elfogadott kérésformátum, egy elfogadott válaszformátum, egy elfogadott hibakód-készlet és egy elfogadott időtúllépés. Interfész tesztelési gyakorlatok, amelyektracmindkét oldalról, így az egyik csapat által végrehajtott változtatás nem szakítja meg csendben a másikat. Mivel ennek a forgalomnak a nagy része soha nem jut el a képernyőre, a talált hibák láthatatlanok a fekete doboz tesztelés kizárólag a felhasználói felületen keresztül végrehajtható.

Hogyan kell elvégezni az interfész tesztelését

Az interfész tesztelése két fő szegmens tesztelését foglalja magában:

1. Webszerver és alkalmazásszerver interfész
2. Alkalmazásszerver és adatbázisszerver interfész.

A fent említett forgatókönyvek esetén az interfész tesztelése a következővel történik

• Ellenőrizze, hogy a szerverek megfelelően futnak-e vagy sem
• A hibákat a rendszer megfelelően kezeli, vagy hibaüzenetet ad vissza az alkalmazás által végzett bármely lekérdezéshez
• Ellenőrizze az eredményeket, amikor a webszerverrel való kapcsolat alaphelyzetbe áll

Az alábbi ábra egyetlen láncként mutatja be ezt a két szegmenst, ahol a böngésző a webszerverrel, a webszerver az alkalmazásszerverrel, az alkalmazásszerver pedig az adatbázis-szerverrel kommunikál.

A gyakorlatban a tesztelő ugrásonként halad végig ezen a láncon. Minden ugrást először egy érvényes kéréssel hajt végre, majd egy hibásan formázott kéréssel, végül pedig a távoli végpont szándékosan elérhetetlenné tételével, így mind a sikeres, mind a sikertelen útvonal ugyanarra a pontra rögzül. próbaper.

Példa az interfész tesztelésére

Tegyük fel, hogy bármely xyz alkalmazás esetén az interfész a következőt veszi fel: XML fájl bemenetként és leadja JSON fájl kimenetként. Az alkalmazás felületének teszteléséhez mindössze az XML fájlformátum és a JSON fájlformátum specifikációjára van szükség.

Ezen specifikációk segítségével létrehozhatunk egy minta bemeneti XML fájlt, és betáplálhatjuk azt az interfészbe. Ezután a bemeneti (XML) és kimeneti (JSON) fájlok validálása a követelményeknek megfelelően az interfész tesztelése.

Figyeljük meg, mire nincs szükség a példához: nincs képernyő, nincs a front-end felépítése és nincs ismeret a felületen belüli kódról. Két formátumspecifikáció elegendő a tesztek megírásához, ezért a felület tesztelése jóval a felhasználói felület létrehozása előtt elkezdődhet.

Miért kell interfész tesztelést végezni?

Az interfész tesztelése megtörtént

• Annak biztosítása érdekében, hogy a végfelhasználók vagy az ügyfelek ne ütközzenek semmilyen problémába egy adott szoftvertermék használata során
• Annak azonosítása, hogy a végfelhasználók általában mely alkalmazási területekhez férnek hozzá, és ellenőrizni tudjuk annak felhasználóbarát jellegét is.
• A biztonsági követelmények ellenőrzése a rendszerek közötti kommunikáció során
• Annak ellenőrzése, hogy egy megoldás képes-e kezelni az alkalmazáskiszolgáló és a webhely közötti hálózati hibákat

Van egy költségérv is. A kérésformátum hibáját olcsón kijavítani, amíg a két rendszer még össze van kötve, és költséges, miután egy downstream rendszer már tárolta a hibásan formázott adatokat.

Az interfész tesztelésének típusai

Az interfész tesztelése során különféle típusú teszteléseket végeznek az interfészen, amelyek magukban foglalhatják

• Munkafolyamat: Biztosítja, hogy az interfészmotor az elvárásoknak megfelelően kezelje a szokásos munkafolyamatokat.
• Peremesetek - váratlan értékek: Ezt figyelembe veszik, amikor a tesztelés során felcserélik a dátumot, hónapot és napot.
• Teljesítmény-, terhelés- és hálózati tesztelés: Egy nagy volumenű interfész több adatot igényelhet. Terhelésvizsgálat mint egy kis volumenű interfész, az interfészmotortól és a csatlakozási infrastruktúrától függően
• Egyedi rendszerek: Ez magában foglalja az egyes rendszerek egyedi tesztelését. Például a kiskereskedelmi üzlet számlázási rendszerének és készletgazdálkodási rendszerének külön kell működnie.

Az első elem elég közel van munkafolyamat-tesztelés forgatókönyveinek újrafelhasználásához, és az utolsó elem átfedésben van a következővel: modul tesztelés, mivel egy rendszer, amelyik magától meghibásodik, újra meghibásodik, ha egyszer újra csatlakoztatják.

Interfész tesztelési stratégia

Az interfész tesztelési stratégia (Interface Testing Strategy) egy módszer, amellyel interfészeket tesztelhetünk általános tesztekkel, függetlenül a megvalósítástól. Használhatjuk az absz.tract teszteseteket, és a teszteset konkrét példányait hozza létre az interfész tesztelési stratégia minden egyes implementációjához. Az alap/abstracA t tesztesetek implementáció-semleges teszteket végeznek, míg a konkrét tesztek az objektumok tesztelésére szolgáló példányosításról és implementáció-specifikus tesztek végrehajtásáról gondoskodnak.

Ennek a struktúrának a kifizetődő hozadéka az újrafelhasználás. Amikor ugyanazon interfész harmadik implementációja jelenik meg, az absz.tracA t csomag változatlanul fut rajta, és csak a példányosítási kódot kell megírni. Ugyanezt az ötletet nagyobb léptékben alkalmazzák a következőben: alkatrész tesztelése, ahol egy megosztotttracA t csomagot minden olyan komponensen lefuttatják, amely állítólag megfelel neki.

Interfész tesztelő eszközök

Mivel egy interfésznek nincs képernyője, az eszközöknek közvetlenül kell kéréseket létrehozniuk, és nyers válaszokra kell érvényesíteniük azokat. A csapatok általában három eszközkategóriát kombinálnak.

• API kliensek és kéréskészítők: Olyan eszközök, mint Postman, SoapUIAz Insomnia és a Hoppscotch REST, SOAP vagy GraphQL hívásokat küld, újrafelhasználható gyűjteményekként tárolja azokat, és állapotkódokra, fejlécekre és választörzsekre állítja be azokat.
• Codeszintű tesztkönyvtárak: A meglévő tesztkészleten belül futó függvénykönyvtárak lehetővé teszik, hogy az interfészellenőrzések az egységtesztek mellett éljenek, és minden builden végrehajtódjanak, ami megakadályozza, hogy elavuljanak.
• Betöltési és protokolleszközök: Egy olyan eszköz, mint pl. JMeter ugyanazt az interfészt hajtja meg hangerőn, ami a funkcionális ellenőrzést Teljesítményfelmérés a kapcsolatról.
• Szolgáltatásvirtualizáció és mockok: Egy, a túlsó véget helyettesítő csonk lehetővé teszi az egyik oldal tesztelését, miközben a másik nem érhető el, befejezetlen, vagy túl drága ahhoz, hogy ismételten hívják.

A kiválasztás kevésbé fontos, mint a lefedettség. Bármelyik klienst is választjuk, a kérések gyűjteményét a kóddal együtt a verziókövetésben kell tárolni, így az interfész és a tesztjeinek módosítása ugyanabban a commitban érkeznek meg. A tágabb kategória részleteit a következő részben tárgyaljuk: API tesztelés.

Interfész tesztelési ellenőrzőlista és bevált gyakorlatok

Egy rövid ellenőrzőlista segítségével a különböző verziókban is nyomon követhető az interfészek lefedettsége. Ezt minden egyes kapcsolatra külön-külön, ne pedig az egész alkalmazásra vonatkozóan kell elvégezni.

• Contracelőször is: Győződjön meg arról, hogy a kérés- és válaszsémák mezőnként, beleértve az adattípusokat és az opcionális mezőket is, megfelelnek a közzétett specifikációnak.
• Határértékek: Üres hasznos adatokat, maximális hosszúságú mezőket, váratlan karakterkészleteket és fordított dátumformátumokat küldhet.
• Hibaútvonalak: Ellenőrizd, hogy minden hiba értelmes kódot és üzenetet ad-e vissza, nem pedig egy veremfájlt. tracvagy egy csendes siker.
• Időtúllépések és újrapróbálkozások: Szakítsa meg a kapcsolatot a kérés közben, és erősítse meg, hogy a hívó biztonságosan újrapróbálkozik a tranzakció megkettőzése nélkül.
• Biztonság: Ellenőrizd a hivatkozás hitelesítését, engedélyezését és titkosítását, és győződj meg arról, hogy a hibaüzenetek nem szivárogtatnak ki belső részleteket.
• Adatkonzisztencia: Olvasd vissza a rekordot a túloldalról, és győződj meg arról, hogy semmi sem csonkolódott, nem kódolódott át vagy nem rendeződött át átvitel közben.
• Volume: Ismételd meg a legnagyobb forgalmú hívást egyidejű terhelés alatt, és figyeld a kapcsolatkészlet kimerülését.

Három gyakorlat teszi ezt az ellenőrzőlistát megismételhetővé. Először is, automatizáld a tesztcsomagot, és futtasd minden builden, mivel a felületek csendesebben változnak, mint a képernyők. Másodszor, naplózd a teljes kérést és választ minden hibára, mivel egy felülethibát szinte lehetetlen reprodukálni egy képernyőképről. Harmadszor, tartsd a tesztcsomagot függetlennek más tesztcsomagok által létrehozott tesztadatoktól, hogy a hiba a felületre mutasson, ne pedig egy hiányzó rekordra.

Ezek az ellenőrzések természetes módon illeszkednek a tágabb tervbe, amelyet a ... pontban ismertetünk. a szoftvertesztelés típusai, és ezek lefutnak, mielőtt ugyanazokat a kapcsolatokat végponttól végig gyakorolnák a folyamat során rendszertesztelés.

Interfész tesztelés vs integrációs tesztelés

A két kifejezés inkább összefügg, mintsem ellentétes: az interfésztesztelés az integrációs munka azon része, amely magára a kapcsolatra koncentrál. Az alábbi táblázat bemutatja mindkét oldal hangsúlyait.

Bárki, aki új a tágabb tudományágban, a környező szinteket a ... részben leírtak szerint fogja megtalálni. integrációs tesztelés és általában véve szoftver tesztelés bevezetés, míg a fent használt terminológia a standardból származik szoftverfejlesztés gyakorlat. Böngészőalapú rendszerek esetén ugyanazokat a kapcsolatokat végül újra gyakorolják a folyamat során webes alkalmazás tesztelés.

GYIK