Mga nadagdag:
- Kakayahang magsagawa ng pagsubok sa API nang malalim na may suporta sa artificial intelligence sa status code, schema/kontrata, panuntunan sa negosyo at mga layer ng negatibo/awtorisasyon
- Kakayahang bumuo ng JSON schema mula sa sample na tugon at maiwasan ang pseudo-confidence ng pagtingin lamang sa status code na may uri at kinakailangang pagpapatunay
- Kakayahang subukan ang mga sitwasyong panseguridad tulad ng awtorisasyon at IDOR gamit ang sintetikong data at para sa mga layuning pandepensa lamang sa loob ng awtorisasyon
Karamihan sa mga modernong software ay nakikipag-usap sa isa't isa sa background sa pamamagitan ng API (Application Programming Interface — ang interface kung saan nag-uusap ang dalawang piraso ng software ayon sa isang partikular na kontrata). Kapag nagdagdag ang isang mobile app ng mga item sa cart, nagpapadala talaga ito ng kahilingan sa isang API sa server. Sinusuri ng pagsubok sa API na tama, secure, at pare-pareho ang pag-uusap na ito, anuman ang interface; Ito ay mas mabilis, mas matatag at mas malalim kaysa sa pagsubok sa UI. Napakahusay ng artificial intelligence (AI) sa pagsubok ng API: bumubuo ito ng mga pagsubok mula sa isang kahulugan ng API, kinukuha ang schema ng pagtugon (ang kontrata na tumutukoy sa istruktura ng data), naglilista ng mga edge case. Ngunit muli ang gitnang caveat ay nalalapat: ang AI ay hindi alam ang tunay na mga patakaran sa negosyo ng iyong API; may posibilidad na gumawa ng mababaw na mga pagsubok na nagpapatunay lamang ng "200 ang ibinalik". Ang iyong trabaho ay tiyakin na ang pagsubok ay mabe-verify ang aktwal na kontrata at lohika ng negosyo.
Sa unit na ito, matututunan mo kung paano mag-set up ng suportado ng AI, malalim na mga pagsubok sa API na may mga diskarte gaya ng Postman, REST Assured at schema validation.
Mga layer ng pagsubok sa API
Isaalang-alang ang pagsubok ng API sa ilang mga malalim, na may iba't ibang pagtulong ang AI sa bawat layer:
1. Status code at pangunahing tugon. Ibinabalik ba ng kahilingan ang inaasahang HTTP status code (200/201 para sa tagumpay, 400/401/404 para sa error)? Ito ang pinaka-mababaw na layer; Ang AI ay madaling gumagawa ngunit nag-iisa ang nagbibigay ng maling tiwala.
2. Schema/pagpatunay ng kontrata. Ang istraktura ba ng tugon ay umaangkop sa kontrata — naroroon ba ang mga inaasahang field, tama ba ang kanilang mga uri, nawawala ba ang mga kinakailangang field? Ang AI ay maaaring bumuo ng JSON Schema — ang pamantayan na tumutukoy sa istruktura ng isang JSON na dokumento — mula sa isang sample na tugon, at ang mga pagsubok ay maaaring mag-validate laban sa schema na iyon. Ito ay mas matibay kaysa sa manu-manong pagsulat ng field-based assert.
3. Pagpapatunay ng panuntunan sa negosyo. Ang tunay na halaga ay narito: "Para sa isang 1000 TL na order, ang field ng diskwento ay dapat na 100", "isang nakanselang order ay hindi maaaring kanselahin muli". Ibe-verify lang ito ng AI kung ibibigay mo dito ang mga panuntunan; Kung hindi mo ibibigay, tatalon ito.
4. Negatibo at seguridad. 401 para sa invalid na token, 403 para sa pag-access ng data ng ibang tao, clear 400 para sa masamang katawan. Ang mga pagsusuri sa awtorisasyon (nagpapatunay na ang isang user ay maaari lamang mag-access ng kanilang sariling data) ay ang puso ng seguridad ng API at ginagawa para sa mga layunin ng pagtatanggol.
Tip: Huwag humiling ng pagsubok nang hindi sinasabi sa AI na "i-validate hindi lang ang status code, kundi pati na rin ang response schema at ang mga panuntunan sa negosyo." Kung hindi, maiiwan ka sa mga pagsubok na nagsasabing "200 ang ibinalik, naipasa" ngunit hindi mapapansin ang API na nagbabalik ng sirang data.
Mahinang prompt / Malakas na prompt
Mahina: "Magsulat ng mga pagsubok para sa API na ito."
Malakas: "Isulat ang mga pagsubok sa REST Assured (Java) para sa POST /order endpoint. Kasunduan: productId at dami ay mandatory sa katawan; 201 at {orderId, total, discount, status} ay ibinalik sa tagumpay. Mga panuntunan sa negosyo: 10% na diskwento sa higit sa 1000 TL; 400 kung ang dami ay makikita kapag 4000 ang halaga ng user<=0;301 Mga Pagsusuri.
Ang malakas na prompt ay nagbibigay sa kontrata, mga panuntunan sa negosyo, mga sitwasyon sa seguridad, at inaasahan sa pagpapatunay ng schema.
Pagsusuri sa kontrata: pagpigil sa mga breakup sa pagitan ng mga koponan
Sa mga arkitektura ng microservice (ang istraktura kung saan ang application ay nahahati sa maliliit na serbisyo na independyente sa isa't isa at nakikipag-usap sa API), ang pagbabago sa format ng tugon ng isang serbisyo ay tahimik na nakakagambala sa iba pang mga serbisyong konektado dito. Pagsubok sa kontrata — ang pagsubok na nagpapatunay na ang kontrata ng API sa pagitan ng serbisyo ng provider at serbisyo ng consumer ay hindi nasira sa magkabilang panig — ay maagang nakakakuha ng mga naturang break. Ang ideya ay ito: tinukoy ng mamimili ang anyo ng tugon na inaasahan niya mula sa prodyuser bilang isang "kontrata"; Sa bawat pagbabago, sinusuri ng tagagawa na sumusunod pa rin ito sa kasunduang ito. Kaya kapag nagbago ang pangalan o uri ng isang field, aabisuhan ng consumer ang pipeline bago ito mag-crash.
Pinapabilis ng AI ang dalawang gawain sa kontekstong ito: pag-draft ng isang kontrata na nagpapakita ng inaasahan ng consumer mula sa isang kasalukuyang tugon ng API, at paunang pagmamarka kung aling sugnay ng kontrata ang maaaring masira ng isang pagbabago. Ngunit ang kontrata mismo ay isang desisyon sa negosyo: tinutukoy ng eksperto kung aling mga lugar ang tunay na kritikal, kung aling mga pagbabago ang makakasira sa backward compatibility — patuloy na gumagana ang mga lumang consumer. Isinulat ng AI ang kontrata; Ikaw ang pumayag.
Tip: Ang pagtanggal ng field o pagpapalit ng uri ng field sa isang API ay halos palaging isang nagbabagang pagbabago. Karaniwang ligtas ang pagdaragdag ng mga bagong field. Ang pagkakaroon ng AI classify ng isang pagbabago bilang "breaking or safe" ay nagbibigay ng mabilis na pre-release security check.
Postman o code-based?
pamantayan
Postman/Newman
REST Assured / code (Java, C#, JS)
Pag-aaral
Madali, visual
Kinakailangan ang kaalaman sa code
Kontrol ng bersyon
Koleksyon ng JSON
Direkta sa source code
kumplikadong lohika
Limitado (mga JS script)
Buong lakas ng programming
Pagsasama ng CI/CD
kasama si Newman
Direktang umaasa sa build
Pagpapatunay ng schema
Gamit ang mga test script
Makapangyarihan sa library
Skala ng pangkat
maliit / katamtaman
malaki, mature
Ang AI ay bumubuo ng code para sa pareho; Maging malinaw kung alin ang gusto mo.
Apat na maaaring kopyahin na mga template
1) Pagsubok sa API na nakabatay sa kontrata:
Ang iyong tungkulin: senior API test engineer. Sumulat ng mga pagsubok para sa sumusunod na endpoint gamit ang [tool/language]: [paraan + path]. Kontrata: [mga kinakailangang field, success code, response structure]. Mga panuntunan sa negosyo: [rules]. Test layers: (1) status code (2) response schema validation(3) bawat panuntunan sa negosyo (4) negatibo + authorization. I-link ang bawat isa sa mga tuntunin ng clause.
2) Pagbuo ng schema mula sa sample na tugon:
Bumuo ng JSON Schema mula sa sample na tugon ng API sa ibaba. Tukuyin ang mga kinakailangang field, uri, mga hadlang sa format (petsa, email, hanay ng numero). Pagkatapos ay magbigay ng isang pagsubok na halimbawa na nagpapatunay laban sa schema na ito. Halimbawang tugon: [i-paste ang JSON]
3) Mga senaryo ng negatibo at awtorisasyon:
Bumuo ng negatibo at mga kaso ng pagsubok sa seguridad para sa endpoint[endpoint]. May kasamang: nawawala/kinakailangang field, maling uri, masyadong malaking halaga, invalid/expired na token, access sa hindi awtorisadong mapagkukunan (IDOR — access sa talaan ng ibang tao sa pamamagitan ng pagpapalit ng ID), limitasyon sa rate. Tukuyin ang inaasahang status code at error body para sa bawat senaryo. Tandaan: susuriin lang sa sarili kong API, pinahintulutan.
4) Pseudo-trust control:
Tingnan ang API test na ito. Mahuhuli ba ang pagsubok na ito kung ibinalik ng server ang tamang status code ngunit FALSEbody/data? Kung hindi, magdagdag ng schema at pagpapatunay ng panuntunan sa negosyo. Pagsubok: [paste test]
tatlong mini case
Case 1 — Ang kapangyarihan ng pagpapatunay ng schema. Sinusuri lamang ng isang team ang status code sa mga pagsubok na ginawa nito gamit ang AI. Sa isang bersyon, nagsimulang maling ibalik ng API ang kabuuang field bilang text ("1200"); nanatiling berde ang mga pagsubok dahil bumabalik pa rin ito ng 200. Nag-crash ang mobile application. Pagkatapos magdagdag ng pagpapatunay ng uri gamit ang template na "Pagbuo ng Schema mula sa sample na tugon," agad na nahuli ang parehong error.
Case 2 — Authority gap (IDOR). Isang eksperto ang nagpatakbo ng IDOR test sa pagitan ng "negatibo at authorization scenario" na nabuo ng AI: Hiniling niya ang order ID ng user B na may token ng user A. Ibinalik ng API ang data na 200 at B — isang seryosong kahinaan sa awtorisasyon. Isinara ng defensive test na ito ang data leak bago ito naging live.
Kaso 3 — Pag-bypass ng panuntunan sa negosyo. Nakabuo ang AI ng 8 pagsubok para sa endpoint ng diskwento; lahat ay nagsuri ng 200, walang nagbe-verify ng halaga ng diskwento. Idinagdag ng eksperto ang mga panuntunan sa negosyo sa prompt at pina-reproduce ang mga ito. Ang mga bagong pagsubok ay nagsiwalat na ang diskwento ay nakalkula nang hindi tama sa 1000 TL na limitasyon (ang diskwento ay inilapat din sa 999). Ang kontrol sa kontrata ay hindi sapat; Ang kontrol sa panuntunan ng negosyo ay kinakailangan.
Mga karaniwang pagkakamali
- Nakatingin lang sa status code. Upang sabihing "200 ang bumalik at lumipas"; hindi nakikita ang sira na katawan (false-trust).
- Pag-bypass sa pagpapatunay ng schema. Hindi sinusuri ang mga uri ng field at obligasyon; tahimik na lumilipas ang mga pagbabago sa uri.
- Paghiling ng pagsubok nang hindi nagbibigay ng mga panuntunan sa negosyo. Hindi alam ng AI ang mga patakaran; ito ay gumagawa lamang ng teknikal na kontrol.
- Paglimot sa mga negatibo at entitlement na sitwasyon. Ang mga kahinaan sa seguridad (IDOR, hindi awtorisadong pag-access) ay nahuhuli lamang ng mga pagsubok na ito.
- Paggamit ng tunay/production token at data. Gumamit ng dedikadong media at sintetikong data para sa pagsubok; Huwag ilagay ang tunay na mga susi sa sasakyan.
- Hindi awtorisadong pagsubok sa seguridad. Magpatakbo lamang ng mga pagsusuri sa awtorisasyon sa sarili mong API at nang may pahintulot.
Sa buod
Bine-verify ng pagsubok sa API ang pananalita ng mga piraso ng software nang mabilis at malalim, anuman ang interface. AI; Ang mga pagsubok sa kontrata ay napakahusay sa pagbuo ng JSON schema at negatibo/seguridad na mga sitwasyon mula sa sample na tugon. Ngunit ang mga mababaw na pagsusulit na nagsusuri lamang sa code ng katayuan ay nagbibigay ng pseudo-confidence. Kinakailangan ang lahat ng apat na layer: status code, schema validation, business rule, negative, at authorization. Ilagay ang mga tuntunin sa negosyo at kontrata sa prompt; Magsagawa ng mga pagsubok sa seguridad gamit ang sintetikong data at may pahintulot lamang.
Gawain ng aplikasyon
Pumili ng isang API endpoint mula sa iyong sariling proyekto. Ipasulat sa AI ang mga pagsubok na may apat na layer na may template na "pagsusuri sa API na nakabatay sa kontrata." Pagkatapos ay magdagdag ng uri/pagpapatupad na pagpapatunay na may "schema generation mula sa sample na tugon" at ilapat ang "pseudo-trust checking". Magpatakbo ng kahit isang IDOR/authorization scenario sa sarili mong kapaligiran sa pagsubok. Iulat ang anumang mga paglabag sa kontrata o negosyo na makikita mo; Kung wala kang mahanap, patakbuhin ang pagsubok laban sa isang sadyang magulo na tugon upang patunayan na nahuli ito.
checklist
- [ ] Sinakop ko ang apat na layer ng pagsubok (kaso, schema, panuntunan sa negosyo, negatibo/awtorisasyon).
- [ ] Malinaw kong ibinigay ang kontrata at mga panuntunan sa negosyo sa AI.
- [ ] Nag-set up ako ng mga pagsubok na nagpapatunay sa schema ng tugon (field, uri, kailangan).
- [ ] Sinubukan ko ang hindi bababa sa isang pahintulot/ senaryo ng IDOR nang nagtatanggol.
- [ ] Gumamit ako ng test environment at synthetic na data sa halip na totoong token/data.
- [ ] Pinatunayan ko sa isang "pseudo-confidence check" na ang bawat pagsubok ay nakakakuha ng sira na tugon.