Fitimet:
- Aftësia për të kryer testimin e API-t në thellësi me mbështetjen e inteligjencës artificiale në kodin e statusit, skemën/kontratën, rregullin e biznesit dhe shtresat negative/autorizimi
- Aftësia për të gjeneruar skemë JSON nga përgjigja e mostrës dhe për të shmangur pseudobesimin e shikimit vetëm të kodit të statusit me llojin dhe vërtetimin imperativ
- Aftësia për të testuar skenarë sigurie si autorizimi dhe IDOR me të dhëna sintetike dhe për qëllime mbrojtëse vetëm brenda autorizimit
Shumica e softuerëve modernë flasin me njëri-tjetrin në sfond nëpërmjet API (Application Programming Interface - ndërfaqja ku dy pjesë të softuerit flasin sipas një kontrate specifike). Kur një aplikacion celular shton artikuj në karrocë, ai në fakt dërgon një kërkesë në një API në server. Testimi i API-së kontrollon nëse kjo bisedë është e saktë, e sigurt dhe e qëndrueshme, pavarësisht nga ndërfaqja; Është më i shpejtë, më i qëndrueshëm dhe më i thellë se testimi i UI. Inteligjenca artificiale (AI) është shumë efikase në testimin API: gjeneron teste nga një përkufizim API, nxjerr skemën e përgjigjes (kontratën që përcakton strukturën e të dhënave), rendit rastet e skajeve. Por përsëri vlen paralajmërimi qendror: AI nuk i njeh rregullat reale të biznesit të API-së tuaj; tenton të prodhojë teste sipërfaqësore që konfirmojnë vetëm "200 të kthyera". Detyra juaj është të siguroheni që testi të verifikojë kontratën aktuale dhe logjikën e biznesit.
Në këtë njësi, do të mësoni se si të vendosni teste të thella API të mbështetura nga AI me qasje të tilla si Postman, REST Assured dhe vlefshmëria e skemës.
Shtresat e testimit të API
Konsideroni testimin e API në disa thellësi, me AI që ndihmon ndryshe në secilën shtresë:
1. Kodi i statusit dhe përgjigja bazë. A e kthen kërkesa kodin e pritshëm të statusit HTTP (200/201 për sukses, 400/401/404 për gabim)? Kjo është shtresa më sipërfaqësore; AI prodhon lehtësisht, por vetëm jep besim të rremë.
2. Vlefshmëria e skemës/kontratës. A përshtatet struktura e përgjigjes me kontratën — a janë të pranishme fushat e pritura, a janë llojet e tyre të sakta, a mungojnë fushat e kërkuara? AI mund të gjenerojë Skemën JSON - standardi që përcakton strukturën e një dokumenti JSON - nga një përgjigje mostër dhe testet mund të vërtetojnë kundrejt asaj skeme. Kjo është shumë më e fortë se shkrimi manual i një deklarate të bazuar në terren.
3. Vleresimi i rregullave te biznesit. Vlera reale është këtu: "Për një porosi 1000 TL, fusha e zbritjes duhet të jetë 100", "porosia e anuluar nuk mund të anulohet përsëri". AI do t'i verifikojë këto vetëm nëse i jep rregullat; Nëse nuk e jep, do të kërcejë.
4. Negativ dhe siguri. 401 për shenjën e pavlefshme, 403 për hyrjen në të dhënat e dikujt tjetër, 400 për trupin e keq. Testet e autorizimit (duke verifikuar që një përdorues mund të ketë akses vetëm në të dhënat e tij) janë thelbi i sigurisë së API-së dhe bëhen për qëllime mbrojtëse.
Këshillë: Mos kërkoni një test pa i thënë AI që "të verifikojë jo vetëm kodin e statusit, por edhe skemën e përgjigjes dhe ato rregulla biznesi". Përndryshe, do të mbeteni me teste që thonë "200 u kthyen, kaluan", por nuk do të vini re që API kthen të dhëna të dëmtuara.
Prompt i dobët / Prompt i fortë
E dobët: "Shkruani teste për këtë API."
Strong: "Shkruani testet REST Assured (Java) për pikën përfundimtare të POST / porosisë. Marrëveshja: productId dhe sasia janë të detyrueshme në trup; 201 dhe {orderId, total, discount, status} kthehen pas suksesit. Rregullat e biznesit: 10% zbritje mbi 1000 TL; 400 nëse sasia 3 = 1; duke parë porosinë e një përdoruesi tjetër: (1) kodin e statusit, (2) vlerësimin e skemës JSON, (3) rregullin e biznesit të zbritjes, (4) lidhni çdo pohim me rregullin e qartë të biznesit.
Prompti i fuqishëm jep kontratën, rregullat e biznesit, skenarët e sigurisë dhe pritshmërinë e vlefshmërisë së skemës.
Testimi i kontratës: parandalimi i ndarjeve midis ekipeve
Në arkitekturat mikroservice (struktura në të cilën aplikacioni është i ndarë në shërbime të vogla që janë të pavarura nga njëra-tjetra dhe flasin me API), ndryshimi i formatit të përgjigjes së një shërbimi ndërpret në heshtje shërbimet e tjera të lidhura me të. Testimi i kontratës - testi që verifikon që kontrata API midis shërbimit të ofruesit dhe shërbimit të konsumatorit nuk është prishur nga të dyja anët - i kap këto ndërprerje herët. Ideja është kjo: konsumatori e përcakton formën e përgjigjes që pret nga prodhuesi si "kontratë"; Me çdo ndryshim, prodhuesi teston që ai ende është në përputhje me këtë marrëveshje. Pra, kur emri ose lloji i një fushe ndryshon, konsumatori njofton tubacionin përpara se të rrëzohet.
AI përshpejton dy detyra në këtë kontekst: hartimin e një kontrate që pasqyron pritshmërinë e konsumatorit nga një përgjigje ekzistuese e API-së dhe parashënjimin se cilën klauzolë të kontratës mund të prishë një ndryshim. Por vetë kontrata është një vendim biznesi: eksperti përcakton se cilat fusha janë vërtet kritike, cilat ndryshime do të prishin përputhshmërinë e prapambetur - konsumatorët e vjetër vazhdojnë të punojnë. AI shkruan kontratën; Ju jeni ai që e miratoni atë.
Këshillë: Fshirja e një fushe ose ndryshimi i llojit të fushës në një API është pothuajse gjithmonë një ndryshim i thyer. Shtimi i fushave të reja është zakonisht i sigurt. Klasifikimi i AI-së si një ndryshim si "i thyer ose i sigurt" siguron një kontroll të shpejtë sigurie para publikimit.
Postier apo i bazuar në kode?
kriteri
Postier/Newman
REST I sigurt / kodi (Java, C#, JS)
Të mësuarit
Lehtë, vizuale
Kërkohet njohuri për kodin
Kontrolli i versionit
Koleksioni JSON
Direkt në kodin burimor
logjikë komplekse
E kufizuar (skriptet JS)
Fuqia e plotë programuese
Integrimi CI/CD
me Newman
Varet drejtpërdrejt nga ndërtimi
Vlefshmëria e skemës
Me skriptet e testimit
I fuqishëm me bibliotekë
Shkalla e ekipit
i vogël/mesatar
i madh, i pjekur
AI gjeneron kod për të dyja; Jini të qartë se cilin dëshironi.
Katër shabllone të kopjueshëm
1) Testimi i API i bazuar në kontratë:
Roli juaj: inxhinier i lartë i testit API. Shkruani teste për pikën përfundimtare të mëposhtme me [mjet/gjuhën]: [metodë + shtegu]. Kontrata: [fushat e kërkuara, kodi i suksesit, struktura e përgjigjes]. Rregullat e biznesit: [rregullat]. Shtresat e testit: (1) kodi i statusit (2) kodi i statusit (2) skema e përgjigjes, verifikimi i skemës së përgjigjes (3) çdo rregull biznesi për të përdorur autorizimin e lidhjes (4)
2) Gjenerimi i skemës nga përgjigja e mostrës:
Gjeneroni skemën JSON nga shembulli i përgjigjes API më poshtë. Specifikoni fushat e kërkuara, llojet, kufizimet e formatit (data, emaili, diapazoni i numrave). Më pas jepni një shembull provë që vërteton këtë skemë. Shembull i përgjigjes: [ngjit JSON]
3) Skenarët negativë dhe autorizues:
Gjeneroni raste testesh negative dhe të sigurisë për pikën përfundimtare[pika përfundimtare]. Përfshin: fushë që mungon/kërkohet, lloj i gabuar, vlerë shumë e madhe, token i pavlefshëm/skaduar, akses në burim të paautorizuar (IDOR — akses në rekordin e dikujt tjetër duke ndryshuar ID), kufi i tarifës. Specifikoni kodin e statusit të pritur dhe trupin e gabimit për secilin skenar. Shënim: do të testohet vetëm në API-në time, të autorizuar.
4) Kontrolli i pseudo-besimit:
Shikoni këtë test API. A do të kapej ky test nëse serveri kthente kodin e saktë të statusit, por FALSEbody/të dhënat? Nëse jo, shtoni vërtetimin e skemës dhe rregullave të biznesit. Test: [paste test]
tre mini kuti
Rasti 1 - Fuqia e vërtetimit të skemës. Një ekip po kontrollonte vetëm kodin e statusit në testet që prodhonte me AI. Në një version, API filloi të kthente gabimisht fushën totale si tekst ("1200"); testet qëndruan jeshile sepse po ktheheshin ende 200. Aplikacioni celular u rrëzua. Pas shtimit të vërtetimit të tipit me shabllonin "Generimi i skemës nga përgjigja e mostrës", i njëjti gabim u kap menjëherë.
Rasti 2 - Hendeku i autoritetit (IDOR). Një ekspert kreu testin IDOR midis "skenarëve negativë dhe autorizues" të gjeneruar nga AI: Ai kërkoi ID-në e porosisë së përdoruesit B me shenjën e përdoruesit A. API ktheu të dhëna prej 200 dhe B - një cenueshmëri serioze autorizimi. Ky test mbrojtës mbylli rrjedhjen e të dhënave përpara se të dilte drejtpërdrejt.
Rasti 3 - Anashkalimi i rregullave të biznesit. AI gjeneroi 8 teste për pikën përfundimtare të zbritjes; të gjithë po kontrollonin 200, asnjë nuk po verifikonte shumën e zbritjes. Eksperti shtoi rregullat e biznesit në kërkesë dhe i bëri ato të riprodhoheshin. Testet e reja zbuluan se zbritja ishte llogaritur gabim në kufirin 1000 TL (zbritja u aplikua edhe për 999). Kontrolli i kontratës nuk mjafton; Kontrolli i rregullave të biznesit është i domosdoshëm.
Gabimet e zakonshme
- Thjesht shikoni kodin e statusit. Të thuash “200 u kthyen dhe kaluan”; duke mos parë trupin e korruptuar (besimi i rremë).
- Duke anashkaluar vërtetimin e skemës. Mos kontrollimi i llojeve dhe detyrimeve të fushave; ndryshimet e tipit kalojnë në heshtje.
- Kërkimi i testimit pa dhënë rregulla biznesi. AI nuk i njeh rregullat; prodhon vetëm kontroll teknik.
- Harrimi i skenarëve negativë dhe të të drejtave. Dobësitë e sigurisë (IDOR, aksesi i paautorizuar) kapen vetëm nga këto teste.
- Përdorimi i argumenteve dhe të dhënave reale/prodhuese. Përdorni media të dedikuara dhe të dhëna sintetike për testim; Mos ngjitni çelësat e vërtetë në automjet.
- Testim i paautorizuar i sigurisë. Kryeni vetëm testet e autorizimit në API-në tuaj dhe me leje.
Në përmbledhje
Testimi API verifikon fjalimin e pjesëve të softuerit shpejt dhe thellë, pavarësisht nga ndërfaqja. AI; testet e kontratës janë shumë efikase në gjenerimin e skemës JSON dhe skenarëve negativë/sigurisë nga përgjigja e mostrës. Por testet sipërfaqësore që kontrollojnë vetëm kodin e statusit japin pseudobesim. Kërkoni të katër shtresat: kodin e statusit, vërtetimin e skemës, rregullin e biznesit, negativin dhe autorizimin. Vendos rregullat e biznesit dhe kontratën menjëherë; Kryeni teste sigurie me të dhëna sintetike dhe vetëm me autorizim.
Detyra e aplikimit
Zgjidhni një pikë fundore API nga projekti juaj. Kërkojini AI të shkruajë teste me katër shtresa me shabllonin "testimi i API-së i bazuar në kontratë". Më pas shtoni vërtetimin e llojit/zbatimit me "prodhimin e skemës nga përgjigja e mostrës" dhe aplikoni "kontrollin pseudo-besimi". Ekzekutoni të paktën një skenar IDOR/autorizim në mjedisin tuaj të testimit. Raportoni çdo shkelje të kontratës ose rregullave të biznesit që gjeni; Nëse nuk mund të gjeni ndonjë, kryeni testin kundër një përgjigjeje të ngatërruar qëllimisht për të provuar se e kapi atë.
listë kontrolli
- [ ] Kam mbuluar katër shtresat e testimit (rasti, skema, rregulli i biznesit, negativ/autorizimi).
- [ ] I dhashë qartë kontratën dhe rregullat e biznesit tek AI.
- [ ] Kam vendosur teste që vërtetojnë skemën e përgjigjes (fusha, lloji, imperativi).
- [ ] Kam provuar të paktën një skenar autorizimi/IDOR në mbrojtje.
- [ ] Kam përdorur mjedis testimi dhe të dhëna sintetike në vend të tokenit/të dhënave reale.
- [ ] Unë vërtetova me një "kontroll pseudobesimi" se çdo test kap përgjigjen e korruptuar.