Bevezetés: Mi az API, illetve a hasonló megoldások?
Az API (Application programing interface), a SOAP (Simple Object Access Protocol), és az MQ (Message Queue/Message broker) három különböző megoldás ugyanarra a kérdésre. Úgy akarok, üzenetet küldeni egy rajtam kívül álló félnek, hogy nem akarom tudni, miként működik, csak azt, hogy miként kell, hogy megszólítsam. pl ahhoz, hogy leadjak egy rendelést egy étteremben nem kell tudnom, hogy hogyan néz ki a konyha, hány szakács van, milyen felszerelést tartalmaz a konyha, csak azt kell tudnom, hogy milyen nyelven beszél a pincér(protokoll), és hogy mik vannak az étlapon (Üzenet sablon). Ezeken keresztül tudom átadni azt az információt, ami ahhoz vezet, hogy megkapom az ebédem.
Informatikai oldalon az API (és a többi fent említett protokoll) ugyanezt csinálja. Meghatározott formátumban, előre definiált sablon alapján üzeneteket küldünk, annak függvényében mit akarunk elérni. Kik küldik? Felület(Frontend) a szervernek(Backend) oda vissza, mobiltelefon a szervernek oda vissza, vagy akár egyes applikációk egymás közötti kommunikációra.
API Dokumentáció fajtái
Fejlesztés során a tesztelő sok minden alapján tervezhet teszteket. Ezeket hívjuk tesztbázisnak, és ISTQB szerint minden is benne van. Gyakorlatban viszont zömmel a legtöbb projekten lévő állandó időhiány miatt, a legkézenfekvőbb tesztbázis a már elkészült funkciók, és a dokumentáció. Ha azt szeretnénk, hogy a fejlesztők jól megértsék a fejlesztendő feladatot, és a tesztelők is már a fejlesztés közben meg tudják tervezni részletesen a teszteket, alapos specifikációra van szükség. Ez viszont mást jelent egy fejlesztőnek, és egy tesztelőnek. Egy fejlesztő sok dologról dönthet a fejlesztés folyamán, amik nem feltétlenül vannak benne a specifikációban.
Fejlesztés során véglegesedő leírók. Előny, vagy hátrány?
Az egyik ilyen pont, az API-k részletes architektúrája. Ebben az esetben a specifikáció az egész funkció működését részletesen tartalmazza, de az ehhez használt „üzenet” sablonra csak vonatkozó, irányadó információkat tartalmaz, vagy semmit. Mi ennek az előnye? Ebben az esetben nincs szükség egy technikailag képzett specifikálóra, tehát olyan esetben, amikor üzleti elvárás alapján fejlesztünk, kihagyhatunk egy plusz lépést a specifikációban, és így egyszerűsíthetünk, gyorsíthatunk a folyamaton. Mi a hátránya? Tesztelés szempontjából ilyenkor ebből a specifikációból csak korlátozottan tudunk tervezni, nincs üzenet sablonunk, amivel megkezdhetjük a teszt tervezést, nem tudunk elvárt eredmény definiálni, csak akkor, amikor már elkészült a fejlesztés. Tehát rosszabb minőségű teszttervezésre leszünk képesek, több idő alatt.Tesztelés szempontjából az a legjobb, ha minél részletesebb, és kidolgozottabb egy specifikáció. Ez tervezés oldalon (specifikáció) többlet időt eredményez, de a valóságban mind a fejlesztés, mind a tesztelés ideje csökkenhet, illetve csökkentjük a hibák valószínűségét.
Mit várunk el?
A következő pontokban leírom mik kellenek ahhoz, hogy egy leírásból rögtön tudjunk teszteket tervezni:
- A hívás típusa legyen feltüntetve (GET,POST,PUT,DELETE,stb)
- A válasz üzenet legyen kifejtve (200_OK, vagy adatokkal érkező válasz)
- Végpont neve pontosan legyen feltűntetve (Pl: „POST /users.json” vagy „http://gyakorlas-redmine.passed.hu:3000/users.xml” ).
- Végpont összes attribútuma fel legyen sorolva.
- Legyen jelölve, vagy leírásban kifejtve, melyik attribútumra van validáció.
- Legyen jelölve, hogy melyik attribútum kötelező.
- Attribútumok típusa/ értékkészlete jelölve legyen (Pl Boolean, string, int)
Ami még fontos/hasznos:
- Vannak olyan attribútumok, amik kötelezők, de értékük lehet null, vagy üres
- Tesztadat tervezési szempontból fontos, hogy vannak-e olyan attribútumok, amikre van validáció
- Ebben az esetben tudjuk azonosítani, hogy egy hívásnak van-e előfeltétele (hívás)
- Vagy külső adatforrásból származó tesztadatokkal kell megegyeznie az értéknek.
- Többválasztásos értékkészlet esetén az értékkészlet legyen kifejtve (Abban az esetben, ha ez dinamikusan szedett értékkészlet, vagy más okokból tartalmaz kezelhetetlen mennyiségű értéket, akkor a forrást kérjük el)
Nézzünk pár API leíró példát. Először a rosszakat.
Mi hiányzik innen?
- A végpont neve (elérési útvonala). Ez azért is fontos, mert bizonyos esetekben az elérési útvonal is tartalmaz változó értékeket
- A hívás típusa (GET,POST,PUT,DELETE, stb)
- Attribútumok kötelezősége
- Attribútumok típusa
Nézzünk jó példákat
Hogyan nézne ki helyesen a fenti példánk?
POST / index.hu/{partnerszam}/feladas
Mutatok még helyes példát:
Miért van erre szükség, miért jó ez neked, ha te vagy a megrendelő?
Nagyban gyorsítja a tesztelő munkáját. Mélyebb tesztelést tesz lehetővé, hiszen nem csak a felületi oldalról tudjuk megtervezni, végrehajtani a tesztelést, hanem a felület kiiktatásával, kizárólag a backend logikát tudjuk tesztelni. Ezen kívül amikor Alkalmazás-Alkalmazás közötti tesztelésről beszélünk, ahol nincs felület, ott kizárólag API vagy más adatküldési protokoll teszteléssel tudunk szeparáltan funkciót tesztelni.
Emellett későbbi automatizálás is gyorsabb, ha nem csak felületi eseteket, hanem API eseteket is automatizálunk (lásd cikkünk: Felületet automatizálok, tehát jó helyre teszem a pénzem… biztos? )
Vannak automatizált megoldások is (Swagger, Scramble).
Tesztelőként kifejezetten szeretem, ha valamilyen automatikus API leíró szolgáltatásban kapom meg az információkat. Miért? Mert ebben az esetben az adott kitelepített verziójú programverzió, és az API leíró verziója nem tér el(alapesetben). Ezeknél minden fontos információ rendezetten elérhető, és sok esetben próbára is van lehetőség. Ilyenek például a Swagger, és az Scrambler. Sajnos ezekben a dokumentumokban ugyanúgy lehetnek hibák, bár mivel automatikusan generálódnak, más típusúak, és ritkábban fordulnak elő. Alapvetően, ha elérhető egy ilyen megoldás, az teljes mértékben ki tudná váltani a többi dokumentációt, de teszt tervezésre korlátozottan alkalmas, hiszen alap esetben csak deploykor kerül ki legújabb verzió, amikorra a tesztelőnek már el kellett volna készülnie a tesztjeivel. Mindenképpen pártoljuk, ha van ilyen megoldás, de sajnos önmagában ez sem mindentudó.
Konklúzió
A Projekt életciklusában minél előbb el kell dönteni van e szükség API tesztelésre. Tesztelési oldalról, amennyiben a kommunikáció az egyes társrendszerek között, illetve a Frontend-Backend között ilyen módszerrel van megoldva, akkor mindenképpen ajánlott.
Ha eldöntöttük, hogy legyen API tesztelés, akkor már a specifikációt is ennek tudatában kell megírni. Ezzel növelni fogjuk a specifikációs időt, de hosszú távon növeljük a termékünk minőségét (Egységesebb végpont nevezéktan, és használat, illetve mélyebb tesztelésből fakadóan). Ha pedig erre az útra léptek egy projekten, akkor remélem ez a cikk segítséget nyújt, hogyan kell a tesztelő számára hasznosan prezentálni az API ra vonatkozó információkat.
Köszönöm, hogy elolvastad, remélem hasznos lesz.
