Pelnas:
- Galimybė atlikti išsamų API testavimą naudojant dirbtinio intelekto palaikymą būsenos kodo, schemos / sutarties, verslo taisyklės ir neigiamo / įgaliojimo lygmenyse
- Galimybė generuoti JSON schemą iš pavyzdžio atsako ir išvengti pseudo pasitikėjimo žiūrint tik į būsenos kodą su tipu ir privalomu patvirtinimu
- Galimybė išbandyti saugos scenarijus, pvz., autorizaciją ir IDOR, naudojant sintetinius duomenis ir gynybos tikslais tik pagal įgaliojimą
Dauguma šiuolaikinių programinės įrangos bendrauja tarpusavyje fone per API (Application Programming Interface – sąsaja, kur dvi programinės įrangos dalys kalba pagal konkrečią sutartį). Kai programa mobiliesiems įdeda prekių į krepšelį, ji iš tikrųjų siunčia užklausą į API serveryje. API testavimas patikrina, ar šis pokalbis yra teisingas, saugus ir nuoseklus, nepaisant sąsajos; Tai greitesnis, stabilesnis ir gilesnis nei vartotojo sąsajos testavimas. Dirbtinis intelektas (AI) yra labai efektyvus atliekant API testavimą: jis generuoja testus iš API apibrėžimo, ištraukia atsako schemą (sutartį, apibrėžiančią duomenų struktūrą), išvardija kraštutinius atvejus. Tačiau vėlgi galioja pagrindinis įspėjimas: AI nežino tikrųjų jūsų API verslo taisyklių; linkęs gaminti paviršutiniškus testus, kurie patvirtina tik „200 grąžintų“. Jūsų darbas yra įsitikinti, kad testas patvirtina tikrąją sutartį ir verslo logiką.
Šiame skyriuje sužinosite, kaip nustatyti AI palaikomus gilius API testus naudojant tokius metodus kaip Postman, REST Assured ir schemos patvirtinimas.
API testavimo sluoksniai
Apsvarstykite galimybę atlikti API testavimą keliais gyliais, kai AI kiekviename sluoksnyje padeda skirtingai:
1. Būsenos kodas ir pagrindinis atsakymas. Ar užklausa grąžina laukiamą HTTP būsenos kodą (200/201 sėkmingam, 400/401/404 klaidai)? Tai paviršutiniškiausias sluoksnis; AI gamina lengvai, bet vienas suteikia klaidingą pasitikėjimą.
2. Schemos/sutarties patvirtinimas. Ar atsakymo struktūra atitinka sutartį – ar yra numatyti laukeliai, ar teisingi jų tipai, ar nėra privalomų laukų? AI gali sugeneruoti JSON schemą – standartą, apibrėžiantį JSON dokumento struktūrą – iš pavyzdžio atsakymo, o testai gali patvirtinti šią schemą. Tai daug patikimiau, nei rankiniu būdu rašyti lauko tvirtinimą.
3. Verslo taisyklių patvirtinimas. Tikroji vertė yra čia: „1000 TL užsakymui nuolaidos laukelis turi būti 100“, „atšauktas užsakymas negali būti vėl atšauktas“. AI patikrins juos tik tuo atveju, jei pateiksite jam taisykles; Jei neduosi, tai pašoks.
4. Neigiamas ir saugumas. 401 už netinkamą prieigos raktą, 403 už prieigą prie kažkieno duomenų, išvalykite 400 už netinkamą turinį. Autorizacijos testai (tikrina, ar vartotojas gali pasiekti tik savo duomenis) yra API saugumo pagrindas ir atliekami gynybos tikslais.
Patarimas: Neprašykite atlikti testo nenurodę AI „patvirtinti ne tik būsenos kodą, bet ir atsakymo schemą bei tas verslo taisykles“. Priešingu atveju jums liks testai, kurie sako „200 grąžinta, išlaikyta“, bet nepastebėsite, kad API grąžina sugadintus duomenis.
Silpnas raginimas / Stiprus raginimas
Silpnas: „Rašykite šios API testus“.
Stiprus: "Parašykite POST / užsakymo galutinio taško REST Assured (Java) testus. Sutartis: produkto ID ir kiekis yra privalomi turinyje; sėkmingai grąžinami 201 ir {orderId, total, discount, status}. Verslo taisyklės: 10% nuolaida virš 1000 TL; 400, jei kiekis <=0; 400, jei kiekis <=0 (1) būsenos kodas, (2) atsako JSON schemos patvirtinimas, (3) nuolaidų verslo taisyklė, (4) susieti kiekvieną tvirtinimą su aiškia verslo taisykle, ne tik patikrinkite 200/201.
Galingas raginimas pateikia sutartį, verslo taisykles, saugos scenarijus ir schemos patvirtinimo lūkesčius.
Sutarčių testavimas: užkertamas kelias išsiskyrimui tarp komandų
Mikropaslaugų architektūrose (struktūra, kurioje programa yra padalinta į mažas paslaugas, kurios yra nepriklausomos viena nuo kitos ir kalba su API), pakeitus paslaugos atsako formatą tyliai sutrinka kitos su ja susijusios paslaugos. Sutarčių testavimas – testas, kuriuo patikrinama, ar API sutartis tarp teikėjo paslaugos ir vartotojo paslaugos nėra pažeista abiejose pusėse – anksti užfiksuoja tokias pertraukas. Idėja tokia: vartotojas atsakymo formą, kurios jis tikisi iš gamintojo, apibrėžia kaip „sutartį“; Su kiekvienu pakeitimu gamintojas patikrina, ar jis vis dar laikosi šios sutarties. Taigi, kai pasikeičia lauko pavadinimas ar tipas, vartotojas praneša dujotiekiui prieš jam sugenda.
AI paspartina dvi užduotis šiame kontekste: sudaryti sutartį, atspindinčią vartotojo lūkesčius iš esamo API atsako, ir iš anksto pažymėti, kurią sutarties sąlygą pakeitimas gali pažeisti. Tačiau pati sutartis yra verslo sprendimas: ekspertas nustato, kurios sritys yra tikrai kritinės, kokie pakeitimai sulaužys atgalinį suderinamumą – seni vartotojai ir toliau dirba. AI rašo sutartį; Jūs esate tas, kuris tai patvirtina.
Patarimas: lauko ištrynimas arba lauko tipo pakeitimas API beveik visada yra esminis pakeitimas. Pridėti naujų laukų paprastai yra saugu. Jei dirbtinis intelektas pakeitimą klasifikuoja kaip „dūžtantį arba saugų“, galima greitai atlikti saugumo patikrinimą prieš išleidimą.
Paštininkas ar pagal kodą?
kriterijus
Paštininkas / Newmanas
REST Assured / kodas (Java, C#, JS)
Mokymasis
Lengvas, vizualus
Reikalingos kodo žinios
Versijų valdymas
JSON kolekcija
Tiesiogiai šaltinio kode
sudėtinga logika
Ribotas (JS scenarijus)
Pilna programavimo galia
CI/CD integracija
su Newmanu
Tiesiogiai priklauso nuo konstrukcijos
Schemos patvirtinimas
Su bandomaisiais scenarijais
Galingas su biblioteka
Komandos mastelis
mažas/vidutinis
didelis, subrendęs
AI generuoja kodą abiem; Būkite aiškus, kurio norite.
Keturi kopijuojami šablonai
1) Sutartimi pagrįstas API testavimas:
Jūsų vaidmuo: vyresnysis API testavimo inžinierius. Rašykite šio galutinio taško testus naudodami [įrankį/kalbą]: [metodas + kelias]. Sutartis: [būtini laukai, sėkmės kodas, atsakymo struktūra]. Verslo taisyklės: [taisyklės]. Testavimo sluoksniai: (1) būsenos kodas (2) atsakymo schemos patvirtinimas (3) kiekviena verslo taisyklė (4) neigiama kaip / sutartis. Susieti kiekvieną taisyklę.
2) Schemos generavimas iš pavyzdžio atsakymo:
Sugeneruokite JSON schemą iš toliau pateikto API atsako pavyzdžio. Nurodykite būtinus laukus, tipus, formato apribojimus (datą, el. paštą, skaičių diapazoną). Tada pateikite bandymo pavyzdį, kuris patvirtina šią schemą. Atsakymo pavyzdys: [įklijuoti JSON]
3) Neigiami ir autorizacijos scenarijai:
Generuokite neigiamus ir saugos bandymo atvejus, skirtus galutiniam taškui [galutinio taško]. Apima: trūkstamas / privalomas laukas, netinkamas tipas, per didelė reikšmė, negaliojantis / pasibaigęs prieigos raktas, prieiga prie neteisėtų išteklių (IDOR – prieiga prie kito asmens įrašo pakeitus ID), normos riba. Kiekvienam scenarijui nurodykite numatomą būsenos kodą ir klaidos turinį. Pastaba: bus išbandyta tik mano API, įgaliota.
4) Pseudo-pasitikėjimo kontrolė:
Patikrinkite šį API testą. Ar šis testas sugautų, jei serveris pateiktų teisingą būsenos kodą, bet FALSEbody/data? Jei ne, pridėkite schemos ir verslo taisyklių patvirtinimą. Testas: [įklijavimo testas]
trys mini dėklai
1 atvejis – schemos patvirtinimo galia. Komanda tik tikrino būsenos kodą atlikdama bandymus su AI. Vienoje versijoje API pradėjo klaidingai grąžinti bendrą lauką kaip tekstą ("1200"); testai liko žali, nes vis dar grįžo 200. Mobilioji programa sudužo. Pridėjus tipo patvirtinimą naudojant šabloną „Schemos generavimas iš mėginio atsakymo“, ta pati klaida buvo iškart užfiksuota.
2 atvejis – valdžios trūkumas (IDOR). Ekspertas atliko IDOR testą tarp „neigiamo ir autorizacijos scenarijaus“, kurį sukūrė AI: jis paprašė vartotojo B užsakymo ID su vartotojo A prieigos raktu. API grąžino 200 ir B duomenis – rimtą autorizavimo pažeidžiamumą. Šis gynybinis bandymas pašalino duomenų nutekėjimą prieš pradedant jį naudoti.
3 atvejis. Verslo taisyklių apėjimas. AI sugeneravo 8 nuolaidos galutinio taško testus; visi tikrino 200, nė vienas nepatikrino nuolaidos sumos. Ekspertas prie raginimo pridėjo verslo taisykles ir pareikalavo jas atkurti. Nauji testai atskleidė, kad nuolaida neteisingai paskaičiuota ties 1000 TL limitu (nuolaida buvo pritaikyta ir 999). Sutarčių kontrolės neužtenka; Verslo taisyklių kontrolė yra būtina.
Dažnos klaidos
- Tiesiog pažiūrėjau į būsenos kodą. Pasakyti „grįžo ir praėjo 200“; nematyti sugadinto kūno (klaidingas pasitikėjimas).
- Apeinamas schemos patvirtinimas. Laukų tipų ir įsipareigojimų netikrinimas; tipo pokyčiai praeina tyliai.
- Prašymas atlikti testavimą nepateikiant verslo taisyklių. AI nežino taisyklių; ji gamina tik techninę kontrolę.
- Pamirškite neigiamus ir teisių suteikimo scenarijus. Saugos spragas (IDOR, neteisėtą prieigą) sugauna tik šie testai.
- Naudojant tikrus / gamybos žetonus ir duomenis. Testavimui naudokite tam skirtas laikmenas ir sintetinius duomenis; Nekiškite tikrų raktelių į automobilį.
- Neteisėtas saugumo patikrinimas. Leidimo testus vykdykite tik savo API ir turėdami leidimą.
Apibendrinant
API testavimas greitai ir giliai patikrina programinės įrangos dalių kalbą, neatsižvelgiant į sąsają. AI; sutarties testai yra labai veiksmingi generuojant JSON schemą ir neigiamus / saugos scenarijus iš imties atsako. Tačiau paviršutiniški testai, kurie tikrina tik būsenos kodą, suteikia pseudo pasitikėjimo. Reikalauti visų keturių sluoksnių: būsenos kodo, schemos patvirtinimo, verslo taisyklės, neigiamo ir prieigos teisės. Greitai pateikite verslo taisykles ir sutartį; Atlikite saugos testus su sintetiniais duomenimis ir tik su leidimu.
Taikymo užduotis
Pasirinkite API galinį tašką iš savo projekto. Leiskite AI parašyti keturių sluoksnių testus naudodami „sutartimi pagrįsto API testavimo“ šabloną. Tada pridėkite tipo / vykdymo patvirtinimą su „schemos generavimas iš pavyzdžio atsakymo“ ir pritaikykite „pseudo-pasitikėjimo patikrą“. Paleiskite bent vieną IDOR / įgaliojimo scenarijų savo bandymo aplinkoje. Pranešti apie bet kokius rastus sutarties ar verslo taisyklių pažeidimus; Jei nerandate, atlikite testą pagal sąmoningai klaidingą atsakymą, kad įrodytumėte, jog jis jį sugavo.
kontrolinis sąrašas
- [ ] Apžvelgiau keturis testavimo sluoksnius (atvejis, schema, verslo taisyklė, neigiamas / įgaliojimas).
- [ ] Aiškiai pateikiau sutartį ir verslo taisykles AI.
- [ ] Nustatau testus, kurie patvirtina atsakymo schemą (laukas, tipas, imperatyvas).
- [ ] Išbandžiau bent vieną prieigos / IDOR scenarijų gynybai.
- [ ] Naudojau bandomąją aplinką ir sintetinius duomenis, o ne tikrus prieigos raktus/duomenis.
- [ ] „pseudo pasitikėjimo patikrinimu“ įrodžiau, kad kiekvienas testas sugauna sugadintą atsakymą.