Qazanclar:
- Status kodu, sxem/müqavilə, biznes qaydası və mənfi/icazə səviyyələrində süni intellekt dəstəyi ilə API testini dərindən aparmaq bacarığı
- Nümunə cavabından JSON sxemini yaratmaq və yalnız tip və imperativ doğrulama ilə status koduna baxmaq psevdo-etibarından qaçmaq bacarığı
- İcazə və IDOR kimi təhlükəsizlik ssenarilərini sintetik məlumatlarla və yalnız icazə çərçivəsində müdafiə məqsədləri üçün sınaqdan keçirmək imkanı
Müasir proqram təminatının əksəriyyəti API vasitəsilə arxa planda bir-biri ilə danışır (Application Programming Interface — xüsusi müqaviləyə əsasən iki proqram təminatının danışdığı interfeys). Mobil proqramlar səbətə əşyalar əlavə etdikdə, əslində serverdəki API-yə sorğu göndərir. API testi interfeysdən asılı olmayaraq bu söhbətin düzgün, təhlükəsiz və ardıcıl olduğunu yoxlayır; UI testindən daha sürətli, daha sabit və daha dərindir. Süni intellekt (AI) API testində çox səmərəlidir: API tərifindən testlər yaradır, cavab sxemini çıxarır (məlumatların strukturunu müəyyən edən müqavilə), kənar halları siyahıya alır. Ancaq yenə də mərkəzi xəbərdarlıq tətbiq olunur: AI API-nin real iş qaydalarını bilmir; yalnız "200 qaytarıldı"nı təsdiqləyən səthi testlər çıxarmağa meyllidir. Sizin işiniz testin faktiki müqavilə və biznes məntiqini təsdiqlədiyinə əmin olmaqdır.
Bu bölmədə siz Postman, REST Assured və sxemlərin yoxlanılması kimi yanaşmalarla süni intellektlə dəstəklənən, dərin API testlərini necə qurmağı öyrənəcəksiniz.
API testinin təbəqələri
AI hər qatda fərqli şəkildə kömək etməklə bir neçə dərinlikdə API testini nəzərdən keçirin:
1. Status kodu və əsas cavab. Sorğu gözlənilən HTTP status kodunu qaytarırmı (uğur üçün 200/201, xəta üçün 400/401/404)? Bu, ən səthi təbəqədir; Süni intellekt asanlıqla istehsal edir, lakin təkbaşına yalançı inam verir.
2. Sxem/müqavilə təsdiqi. Cavabın strukturu müqaviləyə uyğundurmu — gözlənilən sahələr mövcuddurmu, onların növləri düzgündürmü, tələb olunan sahələr yoxdur? Süni intellekt nümunə cavabından JSON Sxema - JSON sənədinin strukturunu müəyyən edən standart yarada bilər və testlər həmin sxemə qarşı doğrulaya bilər. Bu, sahəyə əsaslanan təsdiqi əl ilə yazmaqdan daha güclüdür.
3. Biznes qaydalarının təsdiqi. Əsl dəyər buradadır: "1000 TL-lik sifariş üçün endirim sahəsi 100 olmalıdır", "ləğv edilmiş sifariş yenidən ləğv edilə bilməz". Süni intellekt yalnız qaydaları verdiyiniz halda bunları yoxlayacaq; Verməsən, atılacaq.
4. Mənfi və təhlükəsizlik. Yanlış nişan üçün 401, başqasının məlumatlarına daxil olmaq üçün 403, pis bədən üçün 400 silin. Avtorizasiya testləri (istifadəçinin yalnız öz məlumatlarına daxil ola biləcəyini yoxlamaq) API təhlükəsizliyinin ürəyidir və müdafiə məqsədləri üçün edilir.
İpucu: Süni intellektə “yalnız status kodunu deyil, həm də cavab sxemini və bu iş qaydalarını doğrula” demədən test tələb etməyin. Əks halda, "200 qaytarıldı, keçdi" deyən, lakin API-nin zədələnmiş məlumatları qaytardığını görməyən testlərlə qalacaqsınız.
Zəif məlumat / Güclü göstəriş
Zəif: "Bu API üçün testlər yazın."
Güclü: "POST/sifarişin son nöqtəsi üçün REST Assured (Java) testlərini yazın. Razılaşma: məhsulun id və kəmiyyəti bədəndə məcburidir; 201 və {orderId, cəmi, endirim, status} müvəffəqiyyətlə qaytarılır. Biznes qaydaları: 1000 TL-dən yuxarı 10% endirim; 400; əgər=0; əgər miqdar 40< başqa istifadəçinin sifarişini görmək: (1) status kodu, (2) cavab JSON sxeminin doğrulanması, (3) endirim biznes qaydası, (4) hər bir təsdiqi yalnız 200/201-ə bağlamaq;
Güclü sorğu müqaviləni, iş qaydalarını, təhlükəsizlik ssenarilərini və sxemin doğrulanması gözləntilərini verir.
Müqavilə testi: komandalar arasında dağılmaların qarşısının alınması
Mikroservis arxitekturalarında (tətbiqin bir-birindən asılı olmayan və API ilə danışan kiçik xidmətlərə bölündüyü struktur) xidmətin cavab formatının dəyişdirilməsi səssizcə ona qoşulmuş digər xidmətləri pozur. Müqavilə testi - provayder xidməti və istehlakçı xidməti arasında API müqaviləsinin hər iki tərəfdən pozulmadığını yoxlayan test - belə fasilələri erkən tutur. İdeya belədir: istehlakçı istehsalçıdan gözlədiyi cavab formasını “müqavilə” kimi müəyyən edir; Hər dəyişikliklə istehsalçı hələ də bu müqaviləyə uyğun olduğunu yoxlayır. Beləliklə, sahənin adı və ya növü dəyişdikdə, istehlakçı qəzaya uğramazdan əvvəl boru kəmərini xəbərdar edir.
Süni intellekt bu kontekstdə iki vəzifəni sürətləndirir: mövcud API cavabından istehlakçı gözləntilərini əks etdirən müqavilənin hazırlanması və dəyişikliyin hansı müqavilə bəndini poza biləcəyini əvvəlcədən qeyd etmək. Ancaq müqavilənin özü bir iş qərarıdır: ekspert hansı sahələrin həqiqətən kritik olduğunu, hansı dəyişikliklərin geriyə uyğunluğu pozacağını müəyyənləşdirir - köhnə istehlakçılar işləməyə davam edirlər. AI müqaviləni yazır; Bunu təsdiq edən sizsiniz.
İpucu: API-də sahənin silinməsi və ya sahə növünün dəyişdirilməsi demək olar ki, həmişə fasiləsiz dəyişiklikdir. Yeni sahələr əlavə etmək adətən təhlükəsizdir. Süni intellektin dəyişikliyi “sındıran və ya təhlükəsiz” kimi təsnif etməsi, buraxılışdan əvvəl sürətli təhlükəsizlik yoxlamasını təmin edir.
Poçtalyon və ya kod əsasında?
meyar
Poçtalyon/Nyuman
REST Assured / kod (Java, C#, JS)
Öyrənmək
Asan, vizual
Kod biliyi tələb olunur
Versiyaya nəzarət
Kolleksiya JSON
Birbaşa mənbə kodunda
mürəkkəb məntiq
Məhdud (JS skriptləri)
Tam proqramlaşdırma gücü
CI/CD inteqrasiyası
Newman ilə
Quruluşdan birbaşa asılıdır
Sxemanın təsdiqi
Test skriptləri ilə
Kitabxana ilə güclü
Komanda miqyası
kiçik/orta
böyük, yetkin
AI hər ikisi üçün kod yaradır; Hansı birini istədiyinizə aydın olun.
Dörd kopyalana bilən şablon
1) Müqavilə əsaslı API sınağı:
Rolunuz: baş API test mühəndisi. Aşağıdakı son nöqtə üçün testləri [alət/dil] ilə yazın: [metod + yol]. Müqavilə: [tələb olunan sahələr, müvəffəqiyyət kodu, cavab strukturu]. Biznes qaydaları: [qaydalar]. Test qatları: (1) status kodu (2) cavab sxeminin yoxlanılması(3) hər bir biznes qaydası (4) mənfi qaydanın təsdiqlənməsi.
2) Nümunə cavabından şemanın yaradılması:
Aşağıdakı nümunə API cavabından JSON sxemini yaradın. Tələb olunan sahələri, növləri, format məhdudiyyətlərini (tarix, e-poçt, nömrə diapazonu) göstərin. Sonra bu sxemə uyğun olaraq təsdiq edən bir sınaq nümunəsi verin. Cavab nümunəsi: [JSON yapışdırın]
3) Mənfi və icazə ssenariləri:
Son nöqtə[son nöqtə] üçün mənfi və təhlükəsizlik testləri yaradın. Daxildir: çatışmayan/tələb olunan sahə, yanlış tip, çox böyük dəyər, etibarsız/müddəti bitmiş nişan, icazəsiz resursa giriş (IDOR — ID-ni dəyişdirərək başqasının qeydinə giriş), tarif limiti. Hər bir ssenari üçün gözlənilən status kodunu və xəta orqanını göstərin. Qeyd: yalnız öz API-də sınaqdan keçiriləcək, səlahiyyətli.
4) Pseudo-etibar nəzarəti:
Bu API testini yoxlayın. Server düzgün status kodunu, lakin FALSEbody/datasını qaytarsaydı, bu sınaq başa düşəcəkmi? Yoxdursa, sxem və biznes qaydalarının təsdiqini əlavə edin. Test: [test yapışdırın]
üç mini qutu
1-ci hal - Sxemanın təsdiqinin gücü. Komanda AI ilə hazırladığı testlərdə yalnız status kodunu yoxlayırdı. Bir versiyada API səhv olaraq ümumi sahəni mətn kimi qaytarmağa başladı ("1200"); testlər yaşıl qaldı, çünki hələ də 200-ü qaytarırdı. Mobil proqram qəzaya uğradı. "Nümunə cavabından şema yaradılması" şablonu ilə növ təsdiqini əlavə etdikdən sonra eyni xəta dərhal tutuldu.
İş 2 – Səlahiyyət boşluğu (IDOR). Mütəxəssis AI tərəfindən yaradılan "mənfi və avtorizasiya ssenariləri" arasında IDOR testini keçirdi: O, A istifadəçisinin işarəsi ilə B istifadəçisinin sifariş identifikatorunu tələb etdi. API 200 və B məlumatlarını qaytardı - ciddi avtorizasiya zəifliyi. Bu müdafiə testi canlı yayımlanmadan əvvəl məlumat sızmasını bağladı.
3-cü hal – Biznes qaydalarından yan keçmə. AI endirimin son nöqtəsi üçün 8 test yaratdı; hamısı 200 yoxlayırdı, heç biri endirim məbləğini yoxlayırdı. Ekspert sorğuya iş qaydalarını əlavə etdi və onları təkrarladı. Yeni testlər endirimin 1000 TL limitində səhv hesablandığını üzə çıxarıb (endirim 999-a da tətbiq edilib). Müqavilə nəzarəti kifayət deyil; Biznes qaydalarına nəzarət mütləqdir.
Ümumi səhvlər
- Sadəcə status koduna baxır. “200 qayıdıb keçdi” demək; pozulmuş bədəni görməmək (yalan-güvən).
- Sxema doğrulamasından yan keçmək. Sahə növləri və öhdəliyi yoxlanılmaması; tip dəyişiklikləri səssiz keçir.
- Biznes qaydalarını təqdim etmədən sınaq tələb edilməsi. AI qaydaları bilmir; yalnız texniki nəzarət istehsal edir.
- Mənfi və hüquq verən ssenariləri unutmaq. Təhlükəsizlik zəiflikləri (IDOR, icazəsiz giriş) yalnız bu testlər vasitəsilə tutulur.
- Real/istehsal nişanlarından və məlumatlardan istifadə. Test üçün xüsusi media və sintetik məlumatlardan istifadə edin; Həqiqi açarları avtomobilə yapışdırmayın.
- İcazəsiz təhlükəsizlik testi. Yalnız öz API-nizdə və icazə ilə avtorizasiya testlərini keçirin.
Xülasə
API testi interfeysdən asılı olmayaraq proqram hissələrinin nitqini tez və dərindən yoxlayır. AI; müqavilə testləri nümunə cavabından JSON sxemi və mənfi/təhlükəsizlik ssenariləri yaratmaqda çox səmərəlidir. Ancaq yalnız status kodunu yoxlayan səthi testlər psevdoetibar verir. Bütün dörd təbəqəni tələb edin: status kodu, sxemin yoxlanılması, biznes qaydası, mənfi və avtorizasiya. İş qaydalarını və müqaviləni tez bir zamanda qoyun; Təhlükəsizlik testlərini sintetik məlumatlarla və yalnız icazə ilə həyata keçirin.
Tətbiq tapşırığı
Öz layihənizdən API son nöqtəsini seçin. Süni intellektə “müqavilə əsaslı API testi” şablonu ilə dörd qatlı testlər yazdırın. Sonra "nümunə cavabından sxem yaratmaq" ilə növ/məcburi yoxlamanı əlavə edin və "psevdo-etimad yoxlanışı" tətbiq edin. Öz test mühitinizdə ən azı bir IDOR/ avtorizasiya ssenarisini işə salın. Tapdığınız hər hansı müqavilə və ya iş qaydalarının pozulması barədə məlumat verin; Heç birini tapa bilmirsinizsə, onu tutduğunu sübut etmək üçün qəsdən pozulmuş cavaba qarşı test edin.
yoxlama siyahısı
- [ ] Mən testin dörd qatını əhatə etdim (iş, sxem, biznes qaydası, mənfi/icazə).
- [ ] Mən müqaviləni və iş qaydalarını AI-ya açıq şəkildə verdim.
- [ ] Cavab sxemini (sahə, tip, imperativ) təsdiq edən testlər qururam.
- [ ] Müdafiə üçün ən azı bir icazə/IDOR ssenarisini sınamışam.
- [ ] Mən real token/data yerinə test mühitindən və sintetik verilənlərdən istifadə etdim.
- [ ] Mən "yalançı güvən yoxlaması" ilə sübut etdim ki, hər test pozulmuş cavabı tutur.