Nyereség:
- Képes API-tesztelés mélyreható elvégzésére mesterséges intelligencia támogatással állapotkód, séma/szerződés, üzleti szabály és negatív/engedélyezési rétegekben
- Képes JSON-séma generálására mintaválaszból, és elkerülhető az álbizalom, hogy csak az állapotkódot nézzük típussal és kötelező érvényesítéssel
- Lehetőség a biztonsági forgatókönyvek, például az engedélyezés és az IDOR tesztelésére szintetikus adatokkal és védelmi célokra csak az engedélyezésen belül
A legtöbb modern szoftver a háttérben API-n (Application Programming Interface) keresztül kommunikál egymással. Amikor egy mobilalkalmazás tételeket ad a kosárhoz, valójában kérést küld a szerveren lévő API-nak. Az API tesztelése ellenőrzi, hogy ez a beszélgetés helyes, biztonságos és konzisztens, függetlenül a felülettől; Gyorsabb, stabilabb és mélyebb, mint a felhasználói felület tesztelése. A mesterséges intelligencia (AI) nagyon hatékony az API tesztelésben: API definícióból teszteket generál, kivonja a válaszsémát (az adatok szerkezetét meghatározó szerződést), listázza a szélső eseteket. De ismét érvényes a központi figyelmeztetés: az AI nem ismeri az API valódi üzleti szabályait; hajlamos felületes teszteket produkálni, amelyek csak megerősítik, hogy "200 visszaadott". Az Ön feladata annak biztosítása, hogy a teszt igazolja a tényleges szerződést és az üzleti logikát.
Ebben az egységben megtanulhatja, hogyan állíthat be mesterséges intelligencia által támogatott mély API-teszteket olyan megközelítésekkel, mint a Postman, a REST Assured és a sémaérvényesítés.
Az API-tesztelés rétegei
Fontolja meg az API-tesztelést több mélységben, ahol az AI minden rétegben másként segít:
1. Állapotkód és alapvető válasz. A kérés visszaadja a várt HTTP-állapotkódot (200/201 sikeres, 400/401/404 hiba esetén)? Ez a legfelszínesebb réteg; Az AI könnyen termel, de önmagában hamis bizalmat ad.
2. Séma/szerződés érvényesítése. A válasz szerkezete illeszkedik-e a szerződéshez – megvannak-e a várt mezők, megfelelőek-e a típusuk, hiányoznak a kötelező mezők? Az AI képes JSON-sémát – a JSON-dokumentum szerkezetét meghatározó szabványt – generálni egy mintaválaszból, és a tesztek érvényesíthetik a sémát. Ez sokkal robusztusabb, mint egy mező alapú állítás manuális írása.
3. Üzleti szabály érvényesítése. A valós érték itt van: "1000 TL rendelésnél a kedvezmény mező 100 legyen", "törölt rendelést nem lehet újra lemondani". Az AI csak akkor ellenőrzi ezeket, ha megadod neki a szabályokat; Ha nem adod, ugrik.
4. Negatív és biztonság. 401 érvénytelen token, 403 valaki más adataihoz való hozzáférés, 400 törlés rossz törzs esetén. Az engedélyezési tesztek (amelyek ellenőrzik, hogy a felhasználó csak a saját adataihoz férhet hozzá) az API biztonságának lényegét képezik, és védekezési célokat szolgálnak.
Tipp: Ne kérjen tesztet anélkül, hogy azt ne mondja az AI-nak, hogy „nem csak az állapotkódot, hanem a válaszsémát és az üzleti szabályokat is érvényesítse”. Ellenkező esetben olyan tesztek maradnak, amelyek azt mondják, hogy „200 vissza, sikeres”, de nem veszi észre, hogy az API sérült adatokat ad vissza.
Gyenge felszólítás / Erős felszólítás
Gyenge: "Írjon teszteket ehhez az API-hoz."
Erős: "Írjon REST Assured (Java) teszteket a POST /rendelés végpontjához. Megállapodás: a termékazonosító és a mennyiség kötelező a törzsben; 201 és {orderId, total, discount, status} visszaküldésre kerül, ha sikeres. Üzleti szabályok: 10% kedvezmény 1000 TL felett; 400, ha mennyiség<=0; 400, ha mennyiség <=0; 400, ha mennyiség <=0; 400, ha a mennyiség <=0 (1) állapotkód, (2) válasz JSON-séma ellenőrzése, (3) diszkont üzleti szabály, (4) minden állítást explicit üzleti szabályhoz kell kötni, nem csak a 200/201 ellenőrzést.
A hatékony prompt megadja a szerződést, az üzleti szabályokat, a biztonsági forgatókönyveket és a sémaérvényesítési elvárásokat.
Szerződés tesztelése: a csapatok közötti szakítások megelőzése
A mikroszolgáltatási architektúrákban (az a struktúra, amelyben az alkalmazás egymástól független kis szolgáltatásokra van felosztva, amelyek az API-val beszélnek) egy szolgáltatás válaszformátumának megváltoztatása csendben megzavarja a hozzá kapcsolódó szolgáltatásokat. A szerződésteszt – az a teszt, amely ellenőrzi, hogy a szolgáltatói szolgáltatás és a fogyasztói szolgáltatás közötti API-szerződés nincs-e felbontva mindkét oldalon – korán észleli az ilyen megszakításokat. Az ötlet a következő: a fogyasztó „szerződésként” határozza meg, hogy milyen választ vár a termelőtől; A gyártó minden változtatásnál teszteli, hogy továbbra is megfelel-e ennek a megállapodásnak. Tehát amikor egy mező neve vagy típusa megváltozik, a fogyasztó értesíti a csővezetéket, mielőtt az összeomlik.
A mesterséges intelligencia két feladatot gyorsít fel ebben az összefüggésben: egy olyan szerződés megalkotását, amely tükrözi a fogyasztók elvárásait egy meglévő API-válaszból, és előre megjelöli, hogy a módosítás melyik szerződési kitételt sértheti meg. Maga a szerződés azonban üzleti döntés: a szakértő határozza meg, mely területek igazán kritikusak, mely változtatások rontják a visszafelé kompatibilitást – a régi fogyasztók tovább dolgoznak. Az AI megírja a szerződést; Te vagy az, aki jóváhagyja.
Tipp: Egy mező törlése vagy a mezőtípus módosítása egy API-ban szinte mindig törést jelent. Új mezők hozzáadása általában biztonságos. Ha a mesterséges intelligencia „törő vagy biztonságos” kategóriába sorolja a változtatást, az gyors kiadás előtti biztonsági ellenőrzést tesz lehetővé.
Postás vagy kódalapú?
kritérium
Postás/Newman
REST Assured / kód (Java, C#, JS)
Tanulás
Könnyű, vizuális
Kódismeret szükséges
Verzióvezérlés
JSON gyűjtemény
Közvetlenül a forráskódban
összetett logika
Korlátozott (JS szkriptek)
Teljes programozási teljesítmény
CI/CD integráció
Newmannel
Közvetlenül a felépítéstől függ
Sémaellenőrzés
Teszt szkriptekkel
Erőteljes könyvtárral
Csapat skála
kicsi/közepes
nagy, érett
Az AI mindkettőhöz kódot generál; Legyen egyértelmű, hogy melyiket szeretné.
Négy másolható sablon
1) Szerződés alapú API tesztelés:
Az Ön szerepköre: vezető API-tesztmérnök. Írjon teszteket a következő végponthoz [eszköz/nyelv] segítségével: [módszer + elérési út]. Szerződés: [kötelező mezők, sikerkód, válaszstruktúra]. Üzleti szabályok: [szabályok]. Tesztrétegek: (1) állapotkód (2) válaszséma érvényesítése (3) minden üzleti szabály (4) negatív + felhatalmazás. Kapcsolja össze a vonatkozó szabályokat.
2) Séma generálása mintaválaszból:
Hozzon létre JSON-sémát az alábbi API-válaszból. Adja meg a kötelező mezőket, típusokat, formátumkorlátokat (dátum, e-mail, számtartomány). Ezután adjon meg egy tesztpéldát, amely érvényesíti ezt a sémát. Válaszminta: [JSON beillesztése]
3) Negatív és engedélyezési forgatókönyvek:
Negatív és biztonsági tesztesetek generálása a végpont [végpont] számára. Tartalmazza: hiányzó/kötelező mező, rossz típus, túl nagy érték, érvénytelen/lejárt token, jogosulatlan erőforráshoz való hozzáférés (IDOR – hozzáférés valaki más rekordjához azonosító megváltoztatásával), díjkorlát. Adja meg az egyes forgatókönyvekhez a várható állapotkódot és hibatörzset. Megjegyzés: csak a saját API-mon lesz tesztelve, engedélyezett.
4) Álbizalom-szabályozás:
Tekintse meg ezt az API-tesztet. Ez a teszt elérné, ha a szerver a helyes állapotkódot adja vissza, de FALSEbody/data? Ha nem, adja hozzá a séma és az üzleti szabály érvényesítését. Teszt: [teszt beillesztése]
három mini tok
1. eset – A sémaérvényesítés ereje. Egy csapat csak az állapotkódot ellenőrizte az AI-val készített tesztekben. Az egyik verzióban az API hibásan kezdte visszaadni a teljes mezőt szövegként ("1200"); a tesztek zöldek maradtak, mert még mindig 200-at adott vissza. A mobilalkalmazás összeomlott. Miután hozzáadta a típusellenőrzést a „Sémagenerálás a mintaválaszból” sablonnal, a rendszer azonnal elkapta ugyanazt a hibát.
2. eset – Hatósági hiányosság (IDOR). Egy szakértő lefuttatta az IDOR tesztet a mesterséges intelligencia által generált „negatív és engedélyezési forgatókönyvek” között: B felhasználó rendelési azonosítóját kérte az A felhasználó tokenjével. Az API 200 és B adatot adott vissza – ez komoly engedélyezési sebezhetőség. Ez a védekező teszt lezárta az adatszivárgást, mielőtt éles lett volna.
3. eset – Üzleti szabály megkerülése. Az AI 8 tesztet generált a kedvezményes végponthoz; mindenki 200-at ellenőriz, egyik sem ellenőrizte a kedvezmény összegét. A szakértő hozzáadta az üzleti szabályzatot a prompthoz, és reprodukáltatta azokat. Az új tesztek során kiderült, hogy az 1000 TL-es limitnél rosszul számították ki a kedvezményt (999-re is alkalmazták a kedvezményt). A szerződés ellenőrzése nem elegendő; Az üzleti szabályok ellenőrzése elengedhetetlen.
Gyakori hibák
- Csak nézzük az állapotkódot. Azt mondani, hogy "200 visszatért és elmúlt"; nem látni a romlott testet (hamis bizalom).
- A séma érvényesítésének megkerülése. A mezőtípusok és kötelezettségek ellenőrzése; A típusváltozások csendben zajlanak le.
- Tesztelés kérése üzleti szabályok megadása nélkül. A mesterséges intelligencia nem ismeri a szabályokat; csak műszaki ellenőrzést produkál.
- A negatív és jogosultsági forgatókönyvek elfelejtése. A biztonsági réseket (IDOR, jogosulatlan hozzáférés) csak ezek a tesztek észlelik.
- Valós/termelési tokenek és adatok használata. Használjon dedikált médiát és szintetikus adatokat a teszteléshez; Ne dugjon valódi kulcsot a járműbe.
- Jogosulatlan biztonsági tesztelés. Csak a saját API-ján és engedéllyel futtasson engedélyezési teszteket.
Összefoglalva
Az API-tesztelés gyorsan és mélyen ellenőrzi a szoftverek beszédét, interfésztől függetlenül. AI; A szerződéstesztek nagyon hatékonyak a JSON-séma és a negatív/biztonsági forgatókönyvek létrehozásában a mintaválaszból. De a felületes tesztek, amelyek csak az állapotkódot ellenőrzik, pszeudobizalmat adnak. Mind a négy réteg megkövetelése: állapotkód, sémaérvényesítés, üzleti szabály, negatív és engedélyezés. Tegye fel az üzleti szabályokat és a szerződést a promptba; Végezzen biztonsági teszteket szintetikus adatokkal és csak engedéllyel.
Pályázati feladat
Válasszon API-végpontot a saját projektjéből. Írjon mesterséges intelligencia négyrétegű teszteket a „szerződésalapú API tesztelés” sablonnal. Ezután adja hozzá a típus/végrehajtás érvényesítését a „sémagenerálás mintaválaszból” elemmel, és alkalmazza az „ál-bizalom-ellenőrzést”. Futtasson legalább egy IDOR/engedélyezési forgatókönyvet a saját tesztkörnyezetében. Jelentse a szerződés vagy az üzleti szabályok megsértését, amelyet talál; Ha nem talál ilyet, futtassa le a tesztet egy szándékosan elrontott válasz ellen, hogy bebizonyítsa, hogy elkapta.
ellenőrző lista
- [ ] Lefedtem a tesztelés négy rétegét (eset, séma, üzleti szabály, negatív/engedélyezés).
- [ ] A szerződést és az üzleti szabályokat egyértelműen megadtam az AI-nak.
- [ ] Beállítom a válaszsémát (mező, típus, kötelező érvényű) érvényesítő teszteket.
- [ ] Megpróbáltam legalább egy engedélyezési/IDOR forgatókönyvet védekezésképpen.
- [ ] Valódi token/adatok helyett tesztkörnyezetet és szintetikus adatokat használtam.
- [ ] "ál-bizalom-ellenőrzéssel" bizonyítottam, hogy minden teszt elkapja a sérült választ.