Faida:
- Uwezo wa kufanya majaribio ya API kwa kina na usaidizi wa akili bandia katika msimbo wa hali, schema/mkataba, kanuni za biashara na tabaka hasi/uidhinishaji.
- Uwezo wa kutengeneza schema ya JSON kutoka kwa majibu ya sampuli na epuka kujiamini kwa uwongo ya kuangalia tu nambari ya hali iliyo na aina na uthibitisho wa lazima.
- Uwezo wa kujaribu hali za usalama kama vile uidhinishaji na IDOR na data ya syntetisk na kwa madhumuni ya kujihami tu ndani ya idhini.
Programu nyingi za kisasa huzungumza chinichini kupitia API (Kiolesura cha Kuandaa Programu - kiolesura ambacho vipande viwili vya programu huzungumza kulingana na mkataba mahususi). Programu ya simu ya mkononi inapoongeza vipengee kwenye rukwama, hakika hutuma ombi kwa API kwenye seva. Jaribio la API hukagua kuwa mazungumzo haya ni sahihi, salama, na thabiti, bila kujali kiolesura; Ni ya haraka, thabiti na ya kina zaidi kuliko majaribio ya UI. Akili Bandia (AI) ni bora sana katika majaribio ya API: hutoa majaribio kutoka kwa ufafanuzi wa API, hutoa schema ya majibu (mkataba unaofafanua muundo wa data), huorodhesha kesi za makali. Lakini tena pango kuu linatumika: AI haijui sheria halisi za biashara za API yako; huelekea kutoa vipimo vya juu juu ambavyo vinathibitisha tu "200 walirudi". Kazi yako ni kuhakikisha kuwa jaribio linathibitisha mkataba halisi na mantiki ya biashara.
Katika kitengo hiki, utajifunza jinsi ya kusanidi majaribio ya API yanayoungwa mkono na AI na mbinu kama vile Postman, REST Assured na uthibitishaji wa schema.
Tabaka za majaribio ya API
Fikiria majaribio ya API kwa kina kadhaa, na AI kusaidia tofauti katika kila safu:
1. Msimbo wa hali na majibu ya msingi. Je, ombi linarudisha msimbo wa hali ya HTTP unaotarajiwa (200/201 kwa mafanikio, 400/401/404 kwa makosa)? Hii ni safu ya juu juu zaidi; AI inazalisha kwa urahisi lakini peke yake inatoa uaminifu-uongo.
2. Uthibitishaji wa schema/mkataba. Je, muundo wa majibu unalingana na mkataba - ni sehemu zinazotarajiwa zipo, aina zao ni sahihi, sehemu zinazohitajika hazipo? AI inaweza kuzalisha JSON Schema - kiwango kinachofafanua muundo wa hati ya JSON - kutoka kwa sampuli ya majibu, na majaribio yanaweza kuthibitishwa dhidi ya schema hiyo. Hii ni nguvu zaidi kuliko kuandika mwenyewe madai ya msingi wa shamba.
3. Uthibitishaji wa sheria ya biashara. Thamani halisi iko hapa: "Kwa agizo la 1000 TL, sehemu ya punguzo inapaswa kuwa 100", "agizo lililoghairiwa haliwezi kughairiwa tena". AI itathibitisha haya tu ikiwa utaipa sheria; Usipoitoa itaruka.
4. Hasi na usalama. 401 kwa ishara batili, 403 kwa kupata data ya mtu mwingine, futa 400 kwa mwili mbaya. Majaribio ya uidhinishaji (kuthibitisha kuwa mtumiaji anaweza kufikia data yake pekee) ndio kiini cha usalama wa API na hufanywa kwa madhumuni ya kujihami.
Kidokezo: Usiombe jaribio bila kuwaambia AI "ithibitishe sio msimbo wa hali tu, lakini pia taratibu za majibu na sheria hizo za biashara." Vinginevyo, utasalia na majaribio ambayo yanasema "200 zimerudishwa, zimepitishwa" lakini usione API inarudisha data iliyoharibika.
Mwongozo dhaifu / Mwongozo thabiti
Dhaifu: "Andika majaribio ya API hii."
Imara: "Andika majaribio ya Uhakikisho wa REST (Java) kwa sehemu ya mwisho ya POST / agizo. Makubaliano: ID ya bidhaa na kiasi ni lazima katika mwili; 201 na {orderId, jumla, punguzo, hali} hurejeshwa baada ya kufaulu. Sheria za biashara: punguzo la 10% zaidi ya 1000 TL; 400 ikiwa ni kiasi cha 0; 400 ikiwa ni 0; 40 kama kiasi cha $ 30; 400 kama kiasi cha $ 30; Majaribio ya mtumiaji: (1) msimbo wa hali, (2) jibu la uthibitishaji wa schema ya JSON, (3) kanuni ya punguzo la biashara, (4) funga kila madai kwa sheria iliyo wazi ya biashara;
Kidokezo chenye nguvu kinapeana mkataba, sheria za biashara, hali za usalama na matarajio ya uthibitishaji wa taratibu.
Jaribio la mkataba: kuzuia migawanyiko kati ya timu
Katika usanifu wa huduma ndogo (muundo ambao programu imegawanywa katika huduma ndogo ambazo hazitegemei kila mmoja na kuzungumza na API), kubadilisha muundo wa majibu ya huduma huvuruga kimya huduma zingine zilizounganishwa nayo. Jaribio la mkataba - jaribio linalothibitisha kuwa mkataba wa API kati ya huduma ya mtoa huduma na huduma ya watumiaji haujavunjwa kwa pande zote mbili - hupata mapumziko kama hayo mapema. Wazo ni hili: mlaji anafafanua aina ya majibu anayotarajia kutoka kwa mtayarishaji kama "mkataba"; Kwa kila badiliko, mtengenezaji hupima kwamba bado inatii makubaliano haya. Kwa hivyo jina au aina ya sehemu inapobadilika, mtumiaji huarifu bomba kabla halijaanguka.
AI huharakisha kazi mbili katika muktadha huu: kuandaa mkataba ambao unaonyesha matarajio ya watumiaji kutoka kwa jibu lililopo la API, na kuweka alama mapema ni kifungu gani cha mkataba kinaweza kuvunjika. Lakini mkataba yenyewe ni uamuzi wa biashara: mtaalam huamua ni maeneo gani ambayo ni muhimu sana, ambayo mabadiliko yatavunja utangamano wa nyuma - watumiaji wa zamani wanaendelea kufanya kazi. AI inaandika mkataba; Wewe ndiye unayeidhinisha.
Kidokezo: Kufuta sehemu au kubadilisha aina ya uga katika API karibu kila mara ni badiliko kubwa. Kuongeza sehemu mpya kwa kawaida ni salama. Kufanya AI kuainisha mabadiliko kama "kuvunjika au salama" hutoa ukaguzi wa usalama wa mapema kabla ya kutolewa.
Posta au kulingana na msimbo?
kigezo
Postman/Newman
REST Uhakikisho / msimbo (Java, C#, JS)
Kujifunza
Rahisi, inayoonekana
Ujuzi wa kanuni unahitajika
Udhibiti wa toleo
Mkusanyiko wa JSON
Moja kwa moja katika msimbo wa chanzo
mantiki tata
Mchache (hati za JS)
Nguvu kamili ya programu
Ujumuishaji wa CI/CD
akiwa na Newman
Inategemea moja kwa moja ujenzi
Uthibitishaji wa schema
Na maandishi ya mtihani
Inayo nguvu na maktaba
Kiwango cha timu
ndogo/kati
kubwa, kukomaa
AI inazalisha kanuni kwa wote wawili; Kuwa wazi unayotaka.
Violezo vinne vinavyoweza kunakiliwa
1) Majaribio ya API kulingana na mkataba:
Jukumu lako: mhandisi mkuu wa majaribio ya API. Andika majaribio ya ncha ifuatayo ya mwisho kwa [zana/lugha]: [mbinu + njia].Mkataba: [sehemu zinazohitajika, msimbo wa mafanikio, muundo wa majibu].Kanuni za biashara: [kanuni].Safu za majaribio: (1) msimbo wa hali (2) uthibitishaji wa schema ya majibu(3) kila kanuni ya biashara (4) unganisha sheria husika + wasiliana na idhini ya kila mtu.
2) Uzalishaji wa schema kutoka kwa majibu ya sampuli:
Tengeneza Schema ya JSON kutoka kwa sampuli ya jibu la API hapa chini. Bainisha sehemu zinazohitajika, aina, vikwazo vya umbizo (tarehe, barua pepe, masafa ya nambari). Kisha toa mfano wa jaribio ambao unathibitisha dhidi ya schema hii. Jibu la mfano: [bandika JSON]
3) Matukio mabaya na ya idhini:
Tengeneza kesi za majaribio hasi na usalama kwa mwisho[endpoint]. Inajumuisha: sehemu inayokosekana/inayohitajika, aina isiyo sahihi, thamani kubwa mno, tokeni batili/iliyoisha muda wake, ufikiaji wa rasilimali isiyoidhinishwa (IDOR - ufikiaji wa rekodi ya mtu mwingine kwa kubadilisha kitambulisho), kiwango cha juu cha bei. Bainisha msimbo wa hali unaotarajiwa na mwili wa hitilafu kwa kila hali. Kumbuka: itajaribiwa tu kwenye API yangu mwenyewe, iliyoidhinishwa.
4) Udhibiti wa uaminifu wa uwongo:
Angalia jaribio hili la API. Je, jaribio hili lingepatikana ikiwa seva itarudisha msimbo sahihi wa hali lakini FALSEbody/data? Ikiwa sivyo, ongeza schema na uthibitishaji wa sheria za biashara. Mtihani: [Bandika mtihani]
kesi tatu ndogo
Kesi ya 1 - Nguvu ya uthibitishaji wa schema. Timu ilikuwa ikikagua tu msimbo wa hali katika majaribio iliyotoa na AI. Katika toleo moja, API ilianza kurudisha uga jumla kimakosa kama maandishi ("1200"); majaribio yalikaa kijani kwa sababu yalikuwa bado yanarudi 200. Programu ya rununu ilianguka. Baada ya kuongeza uthibitishaji wa aina kwa kiolezo cha "Schema kizazi kutoka kwa sampuli ya majibu", hitilafu sawa ilipatikana mara moja.
Kesi 2 - Pengo la mamlaka (IDOR). Mtaalamu aliendesha jaribio la IDOR kati ya "matukio hasi na ya uidhinishaji" yaliyotolewa na AI: Aliomba kitambulisho cha agizo la mtumiaji B na ishara ya mtumiaji A. API ilirejesha data ya 200 na B - hatari kubwa ya uidhinishaji. Jaribio hili la ulinzi lilifunga uvujaji wa data kabla haijachapishwa.
Kesi ya 3 - Sheria ya biashara kupita. AI ilizalisha majaribio 8 kwa sehemu ya mwisho ya punguzo; wote walikuwa wakiangalia 200, hakuna waliokuwa wakithibitisha kiasi cha punguzo. Mtaalamu huyo aliongeza sheria za biashara kwenye kidokezo na akaamuru zitolewe tena. Majaribio mapya yalibaini kuwa punguzo lilikokotolewa kimakosa katika kikomo cha TL 1000 (punguzo hilo pia lilitumika kwa 999). Udhibiti wa mkataba hautoshi; Udhibiti wa sheria za biashara ni lazima.
Makosa ya kawaida
- Kuangalia tu msimbo wa hali. Kusema "200 wamerudi na kupita"; kutoona mwili ulioharibika (uaminifu wa uongo).
- Kukwepa uthibitishaji wa schema. Si kuangalia aina za uwanja na wajibu; mabadiliko ya aina hupita kimya kimya.
- Kuomba majaribio bila kutoa sheria za biashara. AI haijui sheria; inazalisha udhibiti wa kiufundi tu.
- Kusahau hali mbaya na haki. Athari za kiusalama (IDOR, ufikiaji usioidhinishwa) hupatikana tu na majaribio haya.
- Kutumia tokeni halisi/za uzalishaji na data. Tumia midia iliyojitolea na data ya sintetiki kwa majaribio; Usibandike funguo halisi kwenye gari.
- Jaribio la usalama lisiloidhinishwa. Fanya majaribio ya uidhinishaji tu kwenye API yako mwenyewe na kwa ruhusa.
Kwa muhtasari
Jaribio la API huthibitisha matamshi ya vipande vya programu haraka na kwa kina, bila kujali kiolesura. AI; majaribio ya mikataba ni bora sana katika kutoa schema ya JSON na hali hasi/usalama kutoka kwa majibu ya sampuli. Lakini majaribio ya juu juu ambayo huangalia msimbo wa hali pekee hutoa kujiamini-pseudo. Inahitaji safu zote nne: msimbo wa hali, uthibitishaji wa schema, sheria ya biashara, hasi, na uidhinishaji. Weka sheria za biashara na mkataba kwa haraka; Fanya majaribio ya usalama kwa data ya sintetiki na kwa idhini pekee.
Jukumu la maombi
Chagua mwisho wa API kutoka kwa mradi wako mwenyewe. Fanya AI iandike majaribio ya safu nne kwa kiolezo cha "API ya majaribio ya kandarasi". Kisha ongeza uthibitishaji wa aina/utekelezaji na "uzalishaji wa schema kutoka kwa majibu ya sampuli" na utumie "ukaguzi wa uaminifu wa uwongo". Tekeleza angalao tukio moja la IDOR/idhini katika mazingira yako ya majaribio. Ripoti ukiukaji wowote wa sheria za biashara au mkataba unaopata; Ikiwa huwezi kupata yoyote, fanya jaribio dhidi ya jibu lililoharibika kimakusudi ili uthibitishe kuwa lililipata.
orodha ya ukaguzi
- [ ] Nilishughulikia safu nne za majaribio (kesi, schema, sheria ya biashara, hasi/idhini).
- [ ] Nilitoa kwa uwazi mkataba na sheria za biashara kwa AI.
- [ ] Nilianzisha majaribio ambayo yanathibitisha schema ya majibu (uga, aina, sharti).
- [ ] Nimejaribu angalau hali moja ya idhini/IDOR kwa kujilinda.
- [ ] Nilitumia mazingira ya majaribio na data ya sintetiki badala ya ishara/data halisi.
- [ ] Nilithibitisha kwa "kukagua kujiamini-pseudo" kwamba kila jaribio hupata jibu lililopotoshwa.