Ieguvumi:
- Spēja veikt padziļinātu API testēšanu ar mākslīgā intelekta atbalstu statusa kodā, shēmā/līgumā, biznesa noteikumos un negatīvajos/autorizācijas slāņos
- Spēja ģenerēt JSON shēmu no atbildes parauga un izvairīties no pseidopārliecības, aplūkojot tikai statusa kodu ar veidu un obligātu validāciju
- Spēja pārbaudīt drošības scenārijus, piemēram, autorizāciju un IDOR ar sintētiskiem datiem un aizsardzības nolūkos tikai autorizācijas ietvaros
Lielākā daļa mūsdienu programmatūras sarunājas viena ar otru fonā, izmantojot API (Application Programming Interface — saskarne, kurā runā divas programmatūras daļas saskaņā ar īpašu līgumu). Kad mobilā lietotne pievieno preces grozam, tā faktiski nosūta pieprasījumu uz API serverī. API testēšana pārbauda, vai šī saruna ir pareiza, droša un konsekventa neatkarīgi no saskarnes; Tas ir ātrāks, stabilāks un dziļāks nekā lietotāja interfeisa testēšana. Mākslīgais intelekts (AI) ir ļoti efektīvs API testēšanā: tas ģenerē testus no API definīcijas, izvelk atbildes shēmu (līgumu, kas nosaka datu struktūru), uzskaita malas gadījumus. Bet atkal ir spēkā galvenais brīdinājums: AI nezina jūsu API reālos uzņēmējdarbības noteikumus; mēdz ražot virspusējus testus, kas apstiprina tikai "200 atgriezti". Jūsu uzdevums ir pārliecināties, vai pārbaude pārbauda faktisko līgumu un biznesa loģiku.
Šajā nodaļā jūs uzzināsit, kā iestatīt mākslīgā intelekta atbalstītus, dziļus API testus ar tādām pieejām kā Postman, REST Assured un shēmas validācija.
API testēšanas slāņi
Apsveriet API testēšanu vairākos dziļumos, jo AI katrā slānī palīdz atšķirīgi:
1. Statusa kods un pamata atbilde. Vai pieprasījums atgriež paredzamo HTTP statusa kodu (200/201 veiksmīgai darbībai, 400/401/404 kļūdai)? Šis ir virspusējais slānis; AI rada viegli, bet viens pats rada nepatiesu uzticēšanos.
2. Shēmas/līguma apstiprināšana. Vai atbildes struktūra atbilst līgumam — vai ir paredzētie lauki, vai to veidi ir pareizi, vai trūkst obligāto lauku? AI var ģenerēt JSON shēmu — standartu, kas nosaka JSON dokumenta struktūru – no atbildes parauga, un testi var pārbaudīt šo shēmu. Tas ir daudz stabilāk nekā manuāli uz lauka balstīta apgalvojuma rakstīšana.
3. Biznesa noteikumu apstiprināšana. Patiesā vērtība ir šeit: "1000 TL pasūtījumam atlaides laukam jābūt 100", "atceltu pasūtījumu nevar atcelt vēlreiz". AI tos pārbaudīs tikai tad, ja jūs tai piešķirsit noteikumus; Ja nedosi, tas lēks.
4. Negatīvs un drošība. 401 par nederīgu marķieri, 403 par piekļuvi kāda cita datiem, notīriet 400 par sliktu pamattekstu. Autorizācijas testi (pārbauda, vai lietotājs var piekļūt tikai saviem datiem) ir API drošības pamatā, un tie tiek veikti aizsardzības nolūkos.
Padoms. Nepieprasiet pārbaudi, nesakot AI “apstiprināt ne tikai statusa kodu, bet arī atbildes shēmu un šos biznesa noteikumus”. Pretējā gadījumā jums tiks atstāti testi, kas saka "200 atgriezti, nokārtoti", bet nepamanīsiet, ka API atgriež bojātus datus.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Rakstiet šīs API pārbaudes."
Spēcīgs: "Rakstiet REST Assured (Java) testus POST/pasūtījuma galapunktam. Līgums: produkta ID un daudzums ir obligāti pamattekstā; 201 un {orderId, total, discount, status} tiek atgriezti veiksmes gadījumā. Biznesa noteikumi: 10% atlaide virs 1000 TL; 400, ja daudzums <=0; 400, ja daudzums <=0; ja tiek pārbaudīts cits lietotājs;03, ja tiek pārbaudīts 401. (1) statusa kods, (2) atbildes JSON shēmas validācija, (3) atlaižu uzņēmējdarbības noteikums, (4) saistiet katru apgalvojumu ar skaidru biznesa noteikumu, ne tikai pārbaudiet 200/201.
Spēcīgā uzvedne sniedz līguma, uzņēmējdarbības noteikumus, drošības scenārijus un shēmas validācijas cerības.
Līguma pārbaude: lai novērstu izjukšanu starp komandām
Mikropakalpojumu arhitektūrā (struktūra, kurā lietojumprogramma ir sadalīta mazos pakalpojumos, kas ir neatkarīgi viens no otra un runā ar API), pakalpojuma atbildes formāta maiņa klusi pārtrauc citus ar to saistītos pakalpojumus. Līguma pārbaude — tests, kas pārbauda, vai API līgums starp pakalpojumu sniedzēja pakalpojumu un patērētāju pakalpojumu nav lauzts abās pusēs — šādus pārtraukumus konstatē agri. Ideja ir šāda: patērētājs definē atbildes formu, ko viņš sagaida no ražotāja kā "līgumu"; Ar katru izmaiņu ražotājs pārbauda, vai tas joprojām atbilst šim līgumam. Tātad, mainoties lauka nosaukumam vai veidam, patērētājs paziņo cauruļvadam pirms tā avārijas.
AI šajā kontekstā paātrina divus uzdevumus: līguma sastādīšanu, kas atspoguļo patērētāju cerības no esošās API atbildes, un iepriekšēju atzīmēšanu, kuru līguma klauzulu izmaiņas varētu pārkāpt. Bet pats līgums ir biznesa lēmums: eksperts nosaka, kuras jomas ir patiesi kritiskas, kuras izmaiņas izjauks atpakaļejošu savietojamību — vecie patērētāji turpina strādāt. AI raksta līgumu; Jūs esat tas, kurš to apstiprina.
Padoms. Lauka dzēšana vai lauka veida maiņa API gandrīz vienmēr ir būtiskas izmaiņas. Jaunu lauku pievienošana parasti ir droša. Ja AI klasificē izmaiņas kā “bojājošas vai drošas”, tiek nodrošināta ātra drošības pārbaude pirms izlaišanas.
Pastnieks vai kods balstīts?
kritērijs
Pastnieks/Ņūmens
REST Assured / kods (Java, C#, JS)
Mācīšanās
Viegli, vizuāli
Nepieciešamas koda zināšanas
Versiju kontrole
Kolekcija JSON
Tieši avota kodā
sarežģīta loģika
Ierobežots (JS skripti)
Pilna programmēšanas jauda
CI/CD integrācija
ar Ņūmenu
Tieši atkarīgs no uzbūves
Shēmas validācija
Ar testa skriptiem
Jaudīgs ar bibliotēku
Komandas mērogs
mazs/vidējs
liels, nobriedis
AI ģenerē kodu abiem; Esiet skaidrs, kuru vēlaties.
Četras kopējamas veidnes
1) Uz līgumu balstīta API testēšana:
Jūsu uzdevums: vecākais API testēšanas inženieris.Rakstiet šāda galapunkta testus, izmantojot [rīks/valoda]: [metode + ceļš].Līgums: [obligātie lauki, veiksmes kods, atbildes struktūra].Uzņēmējdarbības noteikumi: [kārtulas].Testēšanas slāņi: (1) statusa kods (2) atbildes shēmas validācija (3) katra biznesa kārtula (4) negatīva + līgums. Saistīt katru attiecīgo noteikumu.
2) Shēmas ģenerēšana no atbildes parauga:
Ģenerējiet JSON shēmu no tālāk norādītās API atbildes parauga. Norādiet obligātos laukus, veidus, formāta ierobežojumus (datums, e-pasts, numuru diapazons). Pēc tam sniedziet testa piemēru, kas atbilst šai shēmai. Atbildes paraugs: [ielīmēt JSON]
3) Negatīvie un autorizācijas scenāriji:
Ģenerējiet negatīvus un drošības pārbaudes gadījumus galapunktam [galapunkts]. Ietver: trūkstošs/obligāts lauks, nepareizs tips, pārāk liela vērtība, nederīgs/beidzies marķieris, piekļuve neautorizētam resursam (IDOR — piekļuve kāda cita ierakstam, mainot ID), likmes ierobežojums. Katram scenārijam norādiet paredzamo statusa kodu un kļūdas pamattekstu. Piezīme: tiks pārbaudīta tikai manā API, autorizēta.
4) Pseidouzticības kontrole:
Pārbaudiet šo API testu. Vai šis tests uztvertu, ja serveris atgrieztu pareizo statusa kodu, bet FALSEbody/data? Ja nē, pievienojiet shēmu un biznesa noteikumu validāciju. Tests: [ielīmēšanas tests]
trīs mini futrāļi
1. gadījums — shēmas validācijas jauda. Komanda tikai pārbaudīja statusa kodu testos, ko tā izveidoja ar AI. Vienā versijā API sāka kļūdaini atgriezt kopējo lauku kā tekstu ("1200"); testi palika zaļi, jo joprojām atgriezās 200. Mobilā lietojumprogramma avarēja. Pēc tipa validācijas pievienošanas ar veidni "Shēmas ģenerēšana no atbildes parauga" nekavējoties tika konstatēta tā pati kļūda.
2. gadījums — autoritātes trūkums (IDOR). Eksperts veica IDOR testu starp AI ģenerētajiem “negatīvajiem un autorizācijas scenārijiem”: viņš pieprasīja lietotāja B pasūtījuma ID ar lietotāja A pilnvaru. API atgrieza datus par 200 un B — nopietnu autorizācijas ievainojamību. Šis aizsardzības tests novērsa datu noplūdi, pirms tā sāka darboties.
3. gadījums — biznesa noteikumu apiešana. AI ģenerēja 8 testus atlaides galapunktam; visi pārbaudīja 200, neviens nepārbaudīja atlaides summu. Eksperts uzvednei pievienoja uzņēmējdarbības noteikumus un lika tos pavairot. Jaunajos testos atklājās, ka atlaide aprēķināta nepareizi pie 1000 TL limita (atlaide tika piemērota arī 999). Nepietiek ar līguma kontroli; Biznesa noteikumu kontrole ir obligāta.
Biežas kļūdas
- Paskatoties tikai uz statusa kodu. Teikt "200 ir atgriezušies un pagājuši"; bojātā ķermeņa neredzēšana (viltus uzticēšanās).
- Shēmas validācijas apiešana. Nepārbauda lauku veidus un pienākumus; tipa izmaiņas paiet klusi.
- Pārbaudes pieprasīšana, nenorādot uzņēmējdarbības noteikumus. AI nezina noteikumus; tas ražo tikai tehnisko kontroli.
- Aizmirstot negatīvos un tiesību scenārijus. Drošības ievainojamības (IDOR, nesankcionēta piekļuve) tiek fiksētas tikai šajos testos.
- Izmantojot reālus/ražošanas marķierus un datus. Testēšanai izmantojiet īpašus datu nesējus un sintētiskos datus; Nebāziet automašīnā īstas atslēgas.
- Neatļauta drošības pārbaude. Veiciet autorizācijas testus tikai savā API un ar atļauju.
Rezumējot
API testēšana ātri un dziļi pārbauda programmatūras daļu runu neatkarīgi no saskarnes. AI; līgumu testi ir ļoti efektīvi, lai no izlases atbildes ģenerētu JSON shēmu un negatīvus/drošības scenārijus. Bet virspusēji testi, kas pārbauda tikai statusa kodu, dod pseidopārliecību. Nepieciešami visi četri slāņi: statusa kods, shēmas validācija, biznesa kārtula, negatīvs un autorizācija. Uzvednē ievietojiet uzņēmējdarbības noteikumus un līgumu; Veiciet drošības pārbaudes ar sintētiskiem datiem un tikai ar autorizāciju.
Lietojumprogrammas uzdevums
Izvēlieties API galapunktu no sava projekta. Lieciet AI rakstīt četru slāņu testus, izmantojot veidni “uz līgumu balstīta API testēšana”. Pēc tam pievienojiet tipa/izpildes validāciju ar "shēmas ģenerēšanu no atbildes parauga" un izmantojiet "pseidouzticības pārbaudi". Palaidiet vismaz vienu IDOR/autorizācijas scenāriju savā testa vidē. Ziņojiet par visiem atklātajiem līguma vai uzņēmējdarbības noteikumu pārkāpumiem; Ja nevarat atrast, palaidiet testu, salīdzinot ar apzināti izkropļotu atbildi, lai pierādītu, ka tā to uztvēra.
kontrolsaraksts
- [ ] Es aptvēru četrus testēšanas slāņus (gadījums, shēma, biznesa noteikums, negatīvs/autorizācija).
- [ ] Es skaidri nodevu līgumu un uzņēmējdarbības noteikumus AI.
- [ ] Es iestatīju testus, kas apstiprina atbildes shēmu (lauks, veids, imperatīvs).
- [ ] Aizsardzības nolūkā esmu izmēģinājis vismaz vienu autorizācijas/IDOR scenāriju.
- [ ] Es izmantoju testa vidi un sintētiskos datus, nevis reālus marķierus/datus.
- [ ] Es pierādīju ar "pseidouzticības pārbaudi", ka katrs tests uztver bojāto atbildi.