Hagnaður:
- Geta til að framkvæma API próf í dýpt með stuðningi við gervigreind í stöðukóða, skema/samningi, viðskiptareglu og neikvæðum/heimildarlögum
- Geta til að búa til JSON skema úr sýnishornssvari og forðast gerviöryggi þess að horfa aðeins á stöðukóðann með gerð og nauðsynlegri staðfestingu
- Geta til að prófa öryggisatburðarás eins og heimild og IDOR með tilbúnum gögnum og aðeins í varnarskyni innan heimildar
Flestir nútímahugbúnaður talar saman í bakgrunni í gegnum API (Application Programming Interface — viðmótið þar sem tvö hugbúnaðarstykki tala saman samkvæmt tilteknum samningi). Þegar farsímaforrit bætir hlutum í körfuna sendir það í raun beiðni til API á þjóninum. API prófun athugar að þetta samtal sé rétt, öruggt og samkvæmt, óháð viðmótinu; Það er hraðvirkara, stöðugra og dýpra en HÍ prófun. Gervigreind (AI) er mjög dugleg við API próf: hún býr til próf úr API skilgreiningu, dregur út svarskema (samningurinn sem skilgreinir uppbyggingu gagnanna), listar upp jaðartilvik. En aftur gildir aðal fyrirvarinn: gervigreindin þekkir ekki raunverulegar viðskiptareglur API; hefur tilhneigingu til að framleiða yfirborðsleg próf sem staðfesta aðeins "200 skilað". Starf þitt er að ganga úr skugga um að prófið sannreyni raunverulegan samning og viðskiptarökfræði.
Í þessari einingu muntu læra hvernig á að setja upp AI-studd, djúp API próf með aðferðum eins og Postman, REST Assured og skemalöggildingu.
Lög af API prófun
Íhugaðu API próf í nokkrum dýptum, þar sem gervigreind hjálpar á mismunandi hátt í hverju lagi:
1. Stöðukóði og grunnsvörun. Skilar beiðnin væntanlegum HTTP stöðukóða (200/201 fyrir árangur, 400/401/404 fyrir villu)? Þetta er yfirborðslegasta lagið; Gervigreind framleiðir auðveldlega en gefur ein og sér falskt traust.
2. Skema/samningsfullgilding. Passar uppbygging svarsins við samninginn - eru væntanlegir reitir til staðar, eru gerðir þeirra réttar, vantar nauðsynlega reiti? Gervigreind getur búið til JSON Schema - staðalinn sem skilgreinir uppbyggingu JSON skjals - úr sýnishornssvari og próf geta sannreynt gegn því skema. Þetta er miklu öflugra en að skrifa handvirkt fullyrðingu sem byggir á vettvangi.
3. Löggilding viðskiptareglna. Raungildið er hér: "Fyrir 1000 TL pöntun ætti afsláttarreiturinn að vera 100", "ekki er hægt að afturkalla pöntun aftur". AI mun aðeins staðfesta þetta ef þú gefur henni reglurnar; Ef þú gefur það ekki, mun það hoppa.
4. Neikvætt og öryggi. 401 fyrir ógilt tákn, 403 fyrir aðgang að gögnum einhvers annars, hreinsa 400 fyrir slæman líkama. Heimildarpróf (sem sannreyna að notandi hafi aðeins aðgang að eigin gögnum) eru hjarta API öryggis og eru gerðar í varnarskyni.
Ábending: Ekki biðja um próf án þess að segja gervigreindinni að „staðfesta ekki bara stöðukóðann, heldur einnig svarskemað og þessar viðskiptareglur. Annars muntu sitja eftir með próf sem segja "200 skilað, samþykkt" en tekur ekki eftir því að API skilar skemmdum gögnum.
Veik kvaðning / Sterk kvaðning
Veikt: "Skrifaðu próf fyrir þetta API."
Strong: "Skrifaðu REST Assured (Java) próf fyrir POST /pöntun endapunktinn. Samningur: vöruauðkenni og magn eru skyldubundin í meginmálinu; 201 og {orderId, total, discount, status} eru skilað við árangur. Viðskiptareglur: 10% afsláttur yfir 1000 TL; 400 ef gilt magn til 3 þegar 4010; Pöntun notanda: (1) stöðukóði, (2) staðfesting á svari JSON skema, (3) viðskiptareglu um afslátt, (4) binda hverja staðhæfingu við skýra viðskiptareglu.
Öfluga vísbendingin gefur samningnum, viðskiptareglum, öryggisatburðarás og skemastaðfestingu væntingar.
Samningsprófun: koma í veg fyrir sambandsslit milli liða
Í örþjónustuarkitektúrum (uppbyggingin þar sem forritinu er skipt í litlar þjónustur sem eru óháðar hver annarri og tala við API) truflar breyting á svarsniði þjónustu hljóðlaust aðra þjónustu tengda henni. Samningsprófun - prófið sem sannreynir að API samningur milli þjónustuveitunnar og neytendaþjónustunnar sé ekki rofinn á báða bóga - grípur slík brot snemma. Hugmyndin er þessi: neytandinn skilgreinir form viðbragða sem hann væntir frá framleiðanda sem "samning"; Við hverja breytingu prófar framleiðandinn að hann standist enn þennan samning. Þannig að þegar nafn eða tegund reits breytist, lætur neytandinn leiðsluna vita áður en hún hrynur.
Gervigreind flýtir fyrir tveimur verkefnum í þessu samhengi: að semja samning sem endurspeglar væntingar neytenda frá núverandi API-viðbrögðum og að formerkja hvaða samningsákvæði breyting gæti rofið. En samningurinn sjálfur er viðskiptaákvörðun: sérfræðingurinn ákvarðar hvaða svæði eru raunverulega mikilvæg, hvaða breytingar munu brjóta afturábak eindrægni - gamlir neytendur halda áfram að vinna. AI skrifar samninginn; Þú ert sá sem samþykkir það.
Ábending: Að eyða reit eða breyta reitgerðinni í API er næstum alltaf brotabreyting. Að bæta við nýjum reitum er venjulega öruggt. Að láta gervigreindina flokka breytingu sem „brjótandi eða örugg“ veitir skjóta öryggisathugun fyrir útgáfu.
Póstmaður eða kóða-undirstaða?
viðmiðun
Póstmaður/Newman
REST Assured / kóða (Java, C#, JS)
Að læra
Auðvelt, sjónrænt
Kóðaþekking nauðsynleg
Útgáfustýring
Safn JSON
Beint í frumkóða
flókin rökfræði
Takmarkað (JS forskriftir)
Fullur forritunarkraftur
CI/CD samþætting
með Newman
Beint háð byggingu
Skema staðfesting
Með prófunarforskriftum
Öflugur með bókasafni
Team mælikvarði
lítil/meðal
stór, þroskaður
AI býr til kóða fyrir bæði; Vertu með það á hreinu hver þú vilt.
Fjögur afritanleg sniðmát
1) Samningsbundið API próf:
Hlutverk þitt: yfirmaður API prófunarverkfræðings. Skrifaðu próf fyrir eftirfarandi endapunkt með [tól/tungumáli]: [aðferð + slóð]. Samningur: [nauðsynlegir reitir, árangurskóði, uppbygging viðbragða]. Viðskiptareglur: [reglur]. Prófalög: (1) stöðukóði (2) staðfesting á svörunarskema (3) hverja viðskiptareglu (4) tengja hverja viðskiptareglu við viðeigandi staðhæfingu + heimild.
2) Myndun skema frá sýnisvari:
Búðu til JSON Schema úr sýnishorns API svarinu hér að neðan. Tilgreindu nauðsynlega reiti, gerðir, sniðtakmarkanir (dagsetning, tölvupóstur, númerasvið). Gefðu síðan prófdæmi sem staðfestir þetta skema. Dæmi um svar: [líma JSON]
3) Neikvæðar og heimildarsviðsmyndir:
Búðu til neikvæð og öryggisprófunartilvik fyrir endapunkt[endapunkt]. Inniheldur: reit vantar/áskilið, röng gerð, of mikið gildi, ógilt/útrunnið auðkenni, aðgangur að óviðkomandi auðlind (IDOR — aðgangur að skrá einhvers annars með því að skipta um auðkenni), gjaldtakmörk. Tilgreindu væntanlegan stöðukóða og villuhluta fyrir hverja atburðarás. Athugið: Verður aðeins prófað á eigin API, leyfilegt.
4) Gervitraustsstjórnun:
Skoðaðu þetta API próf. Myndi þetta próf grípa ef þjónninn skilaði réttum stöðukóða en FALSEbody/gögn? Ef ekki skaltu bæta við skema og staðfestingu viðskiptareglna. Próf: [líma próf]
þrjú smámál
Tilfelli 1 - Kraftur skemastaðfestingar. Hópur var aðeins að athuga stöðukóðann í prófunum sem það framleiddi með gervigreind. Í einni útgáfu byrjaði API ranglega að skila heildarreitnum sem texta ("1200"); prófin héldust græn því það var enn að skila 200. Farsímaforrit hrundi. Eftir að hafa bætt við tegundarvottun með sniðmátinu „Skemamyndun úr sýnishornssvörun“, fannst sama villa strax.
Mál 2 — heimildabil (IDOR). Sérfræðingur framkvæmdi IDOR prófið á milli „neikvæðra og heimildarsviðsmynda“ sem gervigreindin myndaði: Hann bað um pöntunarauðkenni notanda B með tákni notanda A. API skilaði gögnum upp á 200 og B - alvarlegt heimildarveiki. Þetta varnarpróf lokaði fyrir gagnaleka áður en það fór í loftið.
Mál 3 - Framhjáhald viðskiptareglna. AI bjó til 8 próf fyrir afsláttarendapunktinn; allir voru að athuga 200, enginn var að sannreyna afsláttarupphæðina. Sérfræðingurinn bætti viðskiptareglunum við boðskapinn og lét afrita þær. Nýjar prófanir leiddu í ljós að afslátturinn var rangt reiknaður við 1000 TL mörkin (afslátturinn var einnig settur á 999). Samningseftirlit er ekki nóg; Eftirlit með viðskiptareglum er nauðsynlegt.
Algeng mistök
- Bara að skoða stöðukóðann. Að segja "200 hafa snúið aftur og liðið"; að sjá ekki spillta líkamann (falskt traust).
- Framhjá skemastaðfestingu. Athugaðu ekki svæðisgerðir og skyldu; tegundabreytingar líða hljóðlaust.
- Að biðja um próf án þess að veita viðskiptareglur. AI þekkir ekki reglurnar; það framleiðir aðeins tæknilega stjórn.
- Að gleyma neikvæðum og réttindum. Öryggisveikleikar (IDOR, óviðkomandi aðgangur) eru aðeins gripnir af þessum prófum.
- Notkun raunverulegs/framleiðslutákna og gagna. Notaðu sérstaka miðla og tilbúið gögn til að prófa; Ekki stinga alvöru lyklum inn í ökutækið.
- Óviðkomandi öryggisprófun. Keyrðu aðeins leyfispróf á eigin API og með leyfi.
Í stuttu máli
API prófun sannreynir tal hugbúnaðarhluta hratt og djúpt, óháð viðmóti. gervigreind; samningspróf eru mjög skilvirk við að búa til JSON skema og neikvæðar/öryggissviðsmyndir úr sýnishornssvarinu. En yfirborðsleg próf sem athuga aðeins stöðukóðann gefa gerviöryggi. Krefjast allra fjögurra laga: stöðukóða, skemastaðfestingar, viðskiptareglu, neikvæðrar og heimildar. Settu viðskiptareglur og samning á hvetjandi; Framkvæmdu öryggisprófanir með tilbúnum gögnum og aðeins með leyfi.
Umsóknarverkefni
Veldu API endapunkt úr þínu eigin verkefni. Láttu gervigreind skrifa fjögurra laga próf með „samningsbundnu API prófun“ sniðmátinu. Bættu síðan við tegundar-/framfylgdarstaðfestingu með „skemagerð úr sýnishornssvari“ og notaðu „gervitraustathugun“. Keyrðu að minnsta kosti eina IDOR/heimildaratburðarás í þínu eigin prófunarumhverfi. Tilkynna hvers kyns brot á samningum eða viðskiptareglum sem þú finnur; Ef þú finnur ekki neina skaltu keyra prófið á móti vísvitandi ranglátu svari til að sanna að það hafi náð því.
gátlisti
- [ ] Ég fór yfir fjögur lög prófanna (tilfelli, skema, viðskiptareglu, neikvætt/heimild).
- [ ] Ég gaf gervigreindinni greinilega samninginn og viðskiptareglurnar.
- [ ] Ég setti upp próf sem sannreyna svarskema (reitur, tegund, nauðsynleg).
- [ ] Ég hef reynt að minnsta kosti eina heimild/IDOR atburðarás í vörn.
- [ ] Ég notaði prófunarumhverfi og tilbúið gögn í stað raunverulegra tákna/gagna.
- [ ] Ég sannaði með „gervi-öryggisskoðun“ að hvert próf grípur spillt viðbrögð.