API-kérések tesztelése és válaszidő optimalizálása az alkalmazásban

API tesztelés magánügyfeleknek

Az API tesztelés akkor kell, amikor egy weboldal, alkalmazás, űrlap, fizetési folyamat vagy külső kapcsolat nem látható módon hibázik, de a végeredmény mégis rossz. Ilyenkor nem elég azt nézni, hogy a felület szép-e. Meg kell vizsgálni, hogy a háttérben futó kérések pontos adatot küldenek-e, jó választ kapnak-e, és mennyi idő alatt történik meg a válasz. A Qjob.hu felületén magánügyfélként olyan szabadúszót lehet keresni, aki távolról átnézi a kéréseket, a válaszidőt, a hibakódokat és a tipikus adatkezelési gondokat.

Én azt látom, hogy sok ügyfél csak akkor kér segítséget, amikor a hiba már a felhasználóknál is látszik. Például nem érkezik meg a rendelés, rossz adat kerül a fiókba, nem működik a belépés, vagy a fizetés után nem frissül az állapot. Pedig az ilyen gondok egy része előre kiszűrhető. Egy tapasztalt tesztelő nem csak kattintgat. Megnézi a kérés tartalmát, a válasz szerkezetét, az állapotkódokat, az időzítést és azt is, hogy a rendszer mit csinál hibás vagy hiányos adatokkal.

API tesztelés célja és helye

Az alkalmazásprogramozási felület ellenőrzése azért fontos, mert sok online szolgáltatás több külön rendszerből áll. A felhasználó csak egy gombot lát, de mögötte lehet adatbázis, fizetési szolgáltató, hírlevélrendszer, ügyfélfiók, készletkezelés vagy saját fejlesztésű háttérrendszer. Ha ezek közül bármelyik pont hibásan válaszol, a teljes folyamat bizonytalanná válik.

Az ilyen munka távolról is jól végezhető, ha az ügyfél megadja a tesztkörnyezethez szükséges hozzáférést, a dokumentációt, a mintakéréseket és a várt eredményt. Nem kell személyes találkozó. Inkább pontos leírás kell. Melyik végpontot kell nézni. Milyen adatot kell küldeni. Mi számít jó válasznak. Mi számít hibának. Szerintem ez a munka akkor sikeres, ha a megbízó nem csak annyit kap vissza, hogy működik vagy nem működik, hanem érthető listát kap a hibákról, a kockázatokról és a javítási sorrendről.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy a webáruház kosara hibás. A felület néha elveszítette a kiválasztott terméket. A vizsgálat után kiderült, hogy az egyik háttérkérés túl lassan válaszolt, és a rendszer emiatt korábbi állapotot írt vissza. A probléma nem a kosár kinézetében volt, hanem a háttérkapcsolatban. Egy sima felületi ellenőrzés ezt könnyen kihagyta volna.

API teszt árak és munkamennyiség

Az ár főleg attól függ, hány végpontot kell ellenőrizni, van-e leírás, kell-e teljesítménymérés, és szükséges-e részletes hibajegy minden talált problémához. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő csak néhány egyszerű kérést futtat le, de nem nézi meg a szélső eseteket. Ez rövid távon olcsóbbnak tűnik, később viszont drágább lehet, ha a hibát már éles használat közben kell javítani.

Tapasztalatom szerint a kisebb magánmegbízásoknál a leggyakoribb igény nem a teljes automatizálás, hanem egy célzott állapotfelmérés. Az ügyfél szeretné tudni, hogy miért lassú egy kérés, miért kap rossz választ a felület, vagy miért csak néha jelenik meg egy adat. Ilyenkor a szabadúszó tesztelő néhány órától néhány napig dolgozik a problémán. Nagyobb rendszernél viszont már külön feladat a dokumentáció, a tesztadatok előkészítése és a javítás utáni újraellenőrzés.

API tesztelő kiválasztása

Az API tesztelő kiválasztásánál nem az a legfontosabb, hogy hány eszköz nevét sorolja fel. Fontosabb, hogy érthetően kérdezzen. Milyen végpontok vannak. Van-e hozzáférés tesztkörnyezethez. Milyen válasz számít helyesnek. Kell-e jogosultságot vizsgálni. Van-e határidő. Ezek a kérdések azt mutatják, hogy a szakember nem találgatni akar, hanem mérhető munkát végezni.

Érdemes olyan magánszakembert választani, aki tud röviden és világosan jelenteni. Egy technikai hiba nem sokat ér, ha az ügyfél nem érti, mit kell továbbadnia a fejlesztőnek. A jó leírás tartalmazza a lépéseket, a küldött adatot, a kapott választ, az elvárt eredményt és a hiba súlyát. Nem kell feleslegesen bonyolítani. De a lényeg nem maradhat ki.

Sokan ott hibáznak, hogy csak az óradíjat nézik. Egy alacsony árú ajánlat lehet megfelelő egy egyszerű ellenőrzésre, de nem biztos, hogy elég egy fizetési folyamat vagy belépési rendszer vizsgálatához. Szerintem a portfólió mellett azt is meg kell nézni, hogyan ír a tesztelő. Ha a válaszai zavarosak, a hibajelentése is könnyen zavaros lesz.

API ellenőrzés menete távolról

A távoli munka első lépése a feladat pontosítása. Az ügyfél elküldi, melyik folyamatot kell nézni, milyen hozzáférés használható, és mi a panasz. Ez lehet lassú válaszidő, hibás adat, rossz jogosultság, nem mentett állapot vagy időnként megszakadó kapcsolat. Minél pontosabb a kiindulás, annál kevesebb idő megy el felesleges keresésre.

A második lépés a tesztkörnyezet és a mintakérések ellenőrzése. A szakember megnézi, hogy a megadott címek működnek-e, milyen adatok szükségesek, és van-e olyan korlátozás, amely befolyásolja a munkát. Ezután jönnek a kézi próbák. Helyes adat. Hiányzó adat. Rossz formátum. Túl hosszú érték. Ismételt kérés. Lejárt jogosultság. Lassú válasz. Ezekből sokszor gyorsan látszik, hol gyenge a rendszer.

A harmadik lépés az eredmény átadása. Ez lehet rövid összefoglaló, táblázatos hibalista vagy részletes technikai jelentés. Kisebb feladatnál elég lehet egy tömör leírás. Nagyobb munkánál jobb, ha minden hiba külön bejegyzést kap. A javítás után gyakran szükség van visszatesztre is. Ez azt jelenti, hogy a tesztelő újra lefuttatja a korábban hibás eseteket, és megnézi, valóban javult-e a rendszer.

Válaszidő és hibakódok vizsgálata

A válaszidő nem csak kényelmi kérdés. Ha egy kérés túl lassú, a felhasználó azt hiheti, hogy a gomb nem működik, újra elküldi az adatot, vagy elhagyja az oldalt. Egy lassú háttérválasz adatütközést is okozhat. Különösen akkor, ha több kérés egymás után fut, és az egyik később érkezik vissza, mint kellene.

Az állapotkódok ellenőrzése szintén alapfeladat. Más jelentése van a sikeres válasznak, a jogosultsági hibának, a nem talált adatnak és a szerverhibának. Ha a rendszer minden helyzetben ugyanazt a választ adja, a felület és a felhasználó sem tud megfelelően reagálni. Egy jó online tesztelés ezért nem csak azt nézi, hogy van-e válasz, hanem azt is, hogy a válasz megfelelő-e az adott helyzethez.

Az API tesztelés során a szakember figyelheti a válasz törzsét is. Benne van-e minden szükséges mező. Jó-e az adattípus. Nem hiányzik-e az azonosító. Nem kerül-e vissza olyan adat, amelyet nem kellene megmutatni. Ezek apró részleteknek tűnnek, de sok hibát okoznak. Főleg akkor, ha a felület több szerepkörrel dolgozik, például ügyfél, adminisztrátor és külső szolgáltató más-más adatot lát.

Gyakori hibák API teszt során

Az egyik leggyakoribb hiba, hogy az ügyfél csak a boldog útvonalat kéri ellenőrizni. Vagyis azt, amikor minden adat helyes, a kapcsolat gyors, a felhasználó jogosult, és nincs váratlan helyzet. Ez fontos, de kevés. A valós használatban előfordul üres mező, hibás formátum, duplikált kérés, megszakadt kapcsolat és lejárt munkamenet is.

Másik gyakori gond a homályos elvárás. Ha nincs leírva, mi számít helyes válasznak, a tesztelő csak következtetni tud. Ez lassítja a munkát, és félreértést okozhat. Én azt látom, hogy a jó megbízás rövid, de konkrét. Például a regisztrációs kérésnek sikeres esetben azonosítót kell visszaadnia, hibás e-mailnél pedig egyértelmű hibajelzést. Ez már elég jó alap a vizsgálathoz.

Probléma az is, amikor az ügyfél nem ad tesztadatot. Éles adatokkal dolgozni kockázatos, főleg fizetés, ügyfélfiók vagy személyes adat esetén. Jobb külön próbaadatot használni. Így a szabadúszó szakember biztonságosabban tud hibát keresni, és nem keveredik valódi ügyfélfolyamatba.

API teszt eredmény és átadás

A munka végén az ügyfélnek olyan anyagot kell kapnia, amelyből dönteni tud. Nem feltétlenül hosszú dokumentum kell. De legyen benne, mi lett ellenőrizve, milyen hibák voltak, mi sürgős, és mi csak későbbi javítás. Egy rövid, pontos jelentés többet ér, mint egy hosszú, homályos leírás.

Az API tesztelés értéke sokszor abban van, hogy láthatóvá teszi a rejtett hibákat. A felhasználó csak annyit érez, hogy valami nem működik. A vizsgálat viszont megmutatja, melyik kérés hibázik, milyen adatnál történik a gond, és mennyi idő alatt válaszol a rendszer. Ez segít a fejlesztőnek is, mert nem nulláról kell keresnie a problémát.

Szerintem magánügyfélként akkor érdemes ilyen szolgáltatást kérni, ha már van működő weboldal, alkalmazás vagy külső kapcsolat, de bizonytalan a működés. Lehet ez egyszeri ellenőrzés, javítás utáni visszateszt vagy rendszeres kisebb vizsgálat. A lényeg az, hogy a feladat legyen pontos, a kommunikáció online követhető legyen, és az eredmény átadása ne csak szóban történjen.