नफा:
- स्टेटस कोड, स्कीमा/करार, व्यवसाय नियम आणि नकारात्मक/अधिकृतीकरण स्तरांवर कृत्रिम बुद्धिमत्ता समर्थनासह सखोल API चाचणी आयोजित करण्याची क्षमता
- नमुना प्रतिसादातून JSON स्कीमा व्युत्पन्न करण्याची क्षमता आणि प्रकार आणि अत्यावश्यक प्रमाणीकरणासह केवळ स्थिती कोड पाहण्याचा छद्म-आत्मविश्वास टाळा
- सिंथेटिक डेटासह अधिकृतता आणि IDOR सारख्या सुरक्षा परिस्थितींची चाचणी घेण्याची क्षमता आणि केवळ अधिकृततेच्या आत संरक्षणात्मक हेतूंसाठी
बहुतेक आधुनिक सॉफ्टवेअर API द्वारे पार्श्वभूमीत एकमेकांशी बोलतात (ॲप्लिकेशन प्रोग्रामिंग इंटरफेस - इंटरफेस जेथे सॉफ्टवेअरचे दोन तुकडे एका विशिष्ट करारानुसार बोलतात). जेव्हा मोबाइल ॲप कार्टमध्ये आयटम जोडते, तेव्हा ते सर्व्हरवरील API ला विनंती पाठवते. API चाचणी तपासते की हे संभाषण योग्य, सुरक्षित आणि सुसंगत आहे, इंटरफेसची पर्वा न करता; हे UI चाचणीपेक्षा जलद, अधिक स्थिर आणि सखोल आहे. एपीआय चाचणीमध्ये कृत्रिम बुद्धिमत्ता (एआय) खूप कार्यक्षम आहे: ते एपीआय परिभाषेतून चाचण्या तयार करते, प्रतिसाद स्कीमा (डेटा ची रचना परिभाषित करणारे करार) काढते, एज केसेसची यादी करते. परंतु पुन्हा केंद्रीय सावधगिरी लागू होते: AI ला तुमच्या API चे वास्तविक व्यवसाय नियम माहित नाहीत; वरवरच्या चाचण्या तयार करतात ज्या केवळ "200 परत आल्या" ची पुष्टी करतात. चाचणी वास्तविक करार आणि व्यवसाय तर्काची पडताळणी करते याची खात्री करणे हे तुमचे काम आहे.
या युनिटमध्ये, तुम्ही पोस्टमन, आरईएसटी ॲश्युअर्ड आणि स्कीमा व्हॅलिडेशन यासारख्या पध्दतींसह एआय-समर्थित, सखोल API चाचण्या कशा सेट करायच्या ते शिकाल.
API चाचणीचे स्तर
प्रत्येक स्तरावर AI वेगवेगळ्या प्रकारे मदत करत असताना, API चाचण्यांचा विचार करा:
1. स्थिती कोड आणि मूलभूत प्रतिसाद. विनंती अपेक्षित HTTP स्थिती कोड (यशासाठी 200/201, त्रुटीसाठी 400/401/404) परत करते का? हा सर्वात वरवरचा थर आहे; एआय सहज तयार करते परंतु एकटेच खोटा-विश्वास देते.
2. स्कीमा/करार प्रमाणीकरण. प्रतिसादाची रचना कराराशी जुळते का — अपेक्षित फील्ड उपस्थित आहेत, त्यांचे प्रकार योग्य आहेत का, आवश्यक फील्ड गहाळ आहेत का? AI JSON स्कीमा व्युत्पन्न करू शकते — जेएसओएन दस्तऐवजाची रचना परिभाषित करणारे मानक — नमुना प्रतिसादातून, आणि चाचण्या त्या स्कीमा विरुद्ध प्रमाणित करू शकतात. फील्ड-आधारित प्रतिपादन व्यक्तिचलितपणे लिहिण्यापेक्षा हे अधिक मजबूत आहे.
3. व्यवसाय नियम प्रमाणीकरण. वास्तविक मूल्य येथे आहे: "1000 TL ऑर्डरसाठी, सूट फील्ड 100 असावी", "रद्द केलेली ऑर्डर पुन्हा रद्द केली जाऊ शकत नाही". जर तुम्ही नियम दिले तरच AI हे सत्यापित करेल; जर तुम्ही ते दिले नाही तर ते उडी मारेल.
4. नकारात्मक आणि सुरक्षितता. अवैध टोकनसाठी 401, दुसऱ्याच्या डेटामध्ये प्रवेश करण्यासाठी 403, खराब शरीरासाठी 400 साफ करा. अधिकृतता चाचण्या (वापरकर्ता फक्त त्यांच्या स्वतःच्या डेटामध्ये प्रवेश करू शकतो याची पडताळणी करणे) हे API सुरक्षेचे केंद्र आहे आणि त्या बचावात्मक हेतूंसाठी केल्या जातात.
टीप: AI ला "फक्त स्टेटस कोडच नाही तर प्रतिसाद स्कीमा आणि ते व्यवसाय नियम देखील प्रमाणित करा" असे न सांगता चाचणीची विनंती करू नका. अन्यथा, तुमच्याकडे "200 परत आले, उत्तीर्ण" असे म्हणणाऱ्या चाचण्या राहतील परंतु API दूषित डेटा परत करत असल्याचे लक्षात येणार नाही.
कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट
कमकुवत: "या API साठी चाचण्या लिहा."
सशक्त: "पोस्ट/ऑर्डर एंडपॉइंटसाठी REST Assured (Java) चाचण्या लिहा. करार: productId आणि प्रमाण शरीरात अनिवार्य आहे; 201 आणि {orderId, total, discount, status} यशस्वी झाल्यावर परत केले जातात. व्यवसाय नियम: 1000 TL पेक्षा 10% सवलत; 400 = 400 असल्यास; टोकन; 403 जेव्हा दुसऱ्या वापरकर्त्याच्या चाचण्या पाहतात: (1) स्थिती कोड, (2) प्रतिसाद JSON स्कीमा प्रमाणीकरण, (4) प्रत्येक दावा स्पष्टपणे 200/201 तपासू नका.
शक्तिशाली प्रॉम्प्ट करार, व्यवसाय नियम, सुरक्षा परिस्थिती आणि स्कीमा प्रमाणीकरण अपेक्षा देते.
करार चाचणी: संघांमधील ब्रेकअप रोखणे
मायक्रोसर्व्हिस आर्किटेक्चर्समध्ये (ज्या रचनामध्ये ऍप्लिकेशन लहान सेवांमध्ये विभागले गेले आहे जे एकमेकांपासून स्वतंत्र आहेत आणि API शी बोलतात), सेवेचे प्रतिसाद स्वरूप बदलणे शांतपणे त्याच्याशी कनेक्ट केलेल्या इतर सेवांमध्ये व्यत्यय आणते. कॉन्ट्रॅक्ट टेस्टिंग - प्रदाता सेवा आणि ग्राहक सेवा यांच्यातील API करार दोन्ही बाजूंनी तुटलेला नाही याची पडताळणी करणारी चाचणी - अशा ब्रेक लवकर पकडते. कल्पना अशी आहे: ग्राहक "करार" म्हणून उत्पादकाकडून अपेक्षित प्रतिसादाचे स्वरूप परिभाषित करतो; प्रत्येक बदलासह, निर्माता चाचणी करतो की तो अजूनही या कराराचे पालन करतो. म्हणून जेव्हा फील्डचे नाव किंवा प्रकार बदलतो, तेव्हा ग्राहक पाइपलाइन क्रॅश होण्यापूर्वी सूचित करतो.
AI या संदर्भात दोन कार्यांना गती देते: एखाद्या कराराचा मसुदा तयार करणे जे विद्यमान API प्रतिसादाकडून ग्राहकांच्या अपेक्षा दर्शवते आणि कोणते करार खंड बदलू शकतात ते पूर्व-चिन्हांकित करणे. परंतु करार हाच एक व्यावसायिक निर्णय आहे: तज्ञ ठरवतात की कोणती क्षेत्रे खरोखर गंभीर आहेत, कोणते बदल मागासलेली अनुकूलता खंडित करतील — जुने ग्राहक काम करणे सुरू ठेवतात. एआय करार लिहितो; ते मंजूर करणारे तुम्हीच आहात.
टीप: फील्ड हटवणे किंवा API मधील फील्ड प्रकार बदलणे हा नेहमीच एक ब्रेकिंग बदल असतो. नवीन फील्ड जोडणे सहसा सुरक्षित असते. AI ने बदलाला “ब्रेकिंग किंवा सुरक्षित” म्हणून वर्गीकृत केल्याने द्रुत-रिलीझपूर्व सुरक्षा तपासणी मिळते.
पोस्टमन की कोड-आधारित?
निकष
पोस्टमन/न्यूमन
REST Assured / code (Java, C#, JS)
शिकत आहे
सोपे, दृश्यमान
कोड ज्ञान आवश्यक
आवृत्ती नियंत्रण
संकलन JSON
थेट स्त्रोत कोडमध्ये
जटिल तर्कशास्त्र
मर्यादित (JS स्क्रिप्ट्स)
संपूर्ण प्रोग्रामिंग शक्ती
CI/CD एकत्रीकरण
न्यूमन सह
थेट बांधणीवर अवलंबून
स्कीमा प्रमाणीकरण
चाचणी स्क्रिप्टसह
लायब्ररीसह शक्तिशाली
संघ स्केल
लहान/मध्यम
मोठे, प्रौढ
एआय दोन्हीसाठी कोड व्युत्पन्न करते; तुम्हाला कोणते हवे आहे ते स्पष्ट करा.
चार कॉपी करण्यायोग्य टेम्पलेट्स
1) करार-आधारित API चाचणी:
तुमची भूमिका: वरिष्ठ API चाचणी अभियंता. [tool/language] सह खालील एंडपॉईंटसाठी चाचण्या लिहा: [पद्धत + पथ]. करार: [आवश्यक फील्ड, यश कोड, प्रतिसाद रचना]. व्यवसाय नियम: [नियम]. चाचणी स्तर: (1) स्थिती कोड (2) प्रतिसाद स्कीमा प्रमाणीकरण (3) प्रत्येक व्यवसाय अधिकृतता नियम (4) प्रत्येक व्यवसाय अधिकृतता नियम + 4) नकारात्मक नियमानुसार खंड
२) नमुना प्रतिसादातून स्कीमा निर्मिती:
खालील नमुना API प्रतिसादातून JSON स्कीमा व्युत्पन्न करा. आवश्यक फील्ड, प्रकार, स्वरूप मर्यादा (तारीख, ईमेल, नंबर श्रेणी) निर्दिष्ट करा. नंतर एक चाचणी उदाहरण द्या जे या स्कीमाच्या विरूद्ध प्रमाणित होते. नमुना प्रतिसाद: [JSON पेस्ट करा]
3) नकारात्मक आणि अधिकृतता परिस्थिती:
एंडपॉइंट [एंडपॉइंट] साठी नकारात्मक आणि सुरक्षितता चाचणी प्रकरणे व्युत्पन्न करा. यात समाविष्ट आहे: गहाळ/आवश्यक फील्ड, चुकीचा प्रकार, खूप मोठे मूल्य, अवैध/कालबाह्य टोकन, अनधिकृत संसाधनात प्रवेश (IDOR — आयडी बदलून एखाद्याच्या रेकॉर्डमध्ये प्रवेश), दर मर्यादा. प्रत्येक परिस्थितीसाठी अपेक्षित स्थिती कोड आणि त्रुटी मुख्य भाग निर्दिष्ट करा. टीप: केवळ माझ्या स्वतःच्या API वर चाचणी केली जाईल, अधिकृत.
4) छद्म-विश्वास नियंत्रण:
ही API चाचणी पहा. सर्व्हरने योग्य स्थिती कोड परंतु FALSEbody/डेटा दिल्यास ही चाचणी पकडेल का? नसल्यास, स्कीमा आणि व्यवसाय नियम प्रमाणीकरण जोडा. चाचणी: [पेस्ट चाचणी]
तीन लहान प्रकरणे
केस 1 - स्कीमा प्रमाणीकरणाची शक्ती. एआय सह तयार केलेल्या चाचण्यांमध्ये एक टीम फक्त स्टेटस कोड तपासत होती. एका आवृत्तीमध्ये, API ने चुकीने एकूण फील्ड मजकूर ("1200") म्हणून परत करण्यास सुरुवात केली; चाचण्या हिरव्या राहिल्या कारण ते अजूनही 200 परत करत होते. मोबाइल ऍप्लिकेशन क्रॅश झाले. "नमुना प्रतिसादातून स्कीमा जनरेशन" टेम्पलेटसह प्रकार प्रमाणीकरण जोडल्यानंतर, तीच त्रुटी त्वरित पकडली गेली.
प्रकरण 2 - प्राधिकरण अंतर (IDOR). एका तज्ञाने AI द्वारे व्युत्पन्न केलेल्या "नकारात्मक आणि अधिकृतता परिस्थिती" दरम्यान IDOR चाचणी केली: त्याने वापरकर्ता A च्या टोकनसह वापरकर्ता B च्या ऑर्डर आयडीची विनंती केली. API ने 200 आणि B चा डेटा परत केला — एक गंभीर अधिकृतता भेद्यता. या बचावात्मक चाचणीने थेट जाण्यापूर्वी डेटा लीक बंद केला.
केस 3 — व्यवसाय नियम बायपास. AI ने डिस्काउंट एंडपॉइंटसाठी 8 चाचण्या तयार केल्या; सर्व 200 तपासत होते, कोणीही सवलतीच्या रकमेची पडताळणी करत नव्हते. तज्ञाने प्रॉम्प्टमध्ये व्यवसाय नियम जोडले आणि त्यांचे पुनरुत्पादन केले. नवीन चाचण्यांमधून असे दिसून आले की सवलत 1000 TL मर्यादेवर चुकीच्या पद्धतीने मोजली गेली होती (सवलत 999 वर देखील लागू करण्यात आली होती). करार नियंत्रण पुरेसे नाही; व्यवसाय नियम नियंत्रण आवश्यक आहे.
सामान्य चुका
- फक्त स्टेटस कोड बघतोय. "200 परत आले आणि पास झाले" असे म्हणणे; दूषित शरीर न पाहणे (खोटा-विश्वास).
- स्कीमा प्रमाणीकरण बायपास करणे. फील्ड प्रकार आणि दायित्व तपासत नाही; प्रकारातील बदल शांतपणे पास होतात.
- व्यवसाय नियम न देता चाचणीची विनंती करणे. AI ला नियम माहित नाहीत; ते फक्त तांत्रिक नियंत्रण तयार करते.
- नकारात्मक आणि हक्क परिस्थिती विसरणे. सुरक्षा भेद्यता (IDOR, अनधिकृत प्रवेश) फक्त या चाचण्यांद्वारे पकडल्या जातात.
- वास्तविक/उत्पादन टोकन आणि डेटा वापरणे. चाचणीसाठी समर्पित मीडिया आणि सिंथेटिक डेटा वापरा; वाहनात खऱ्या चाव्या चिकटवू नका.
- अनधिकृत सुरक्षा चाचणी. फक्त तुमच्या स्वतःच्या API वर आणि परवानगीने अधिकृतता चाचण्या चालवा.
सारांशात
API चाचणी इंटरफेसची पर्वा न करता सॉफ्टवेअरच्या तुकड्यांचे उच्चार जलद आणि सखोलपणे सत्यापित करते. AI; नमुना प्रतिसादातून JSON स्कीमा आणि नकारात्मक/सुरक्षा परिस्थिती निर्माण करण्यासाठी करार चाचण्या खूप कार्यक्षम आहेत. परंतु वरवरच्या चाचण्या ज्या केवळ स्टेटस कोड तपासतात ते छद्म-आत्मविश्वास देतात. सर्व चार स्तर आवश्यक आहेत: स्थिती कोड, स्कीमा प्रमाणीकरण, व्यवसाय नियम, नकारात्मक आणि अधिकृतता. प्रॉम्प्टवर व्यवसाय नियम आणि करार ठेवा; सिंथेटिक डेटासह आणि केवळ अधिकृततेसह सुरक्षा चाचण्या करा.
अर्ज कार्य
तुमच्या स्वतःच्या प्रोजेक्टमधून API एंडपॉइंट निवडा. AI ला “करार-आधारित API चाचणी” टेम्पलेटसह चार-स्तर चाचण्या लिहा. नंतर "नमुना प्रतिसादातून स्कीमा जनरेशन" सह प्रकार/अंमलबजावणी प्रमाणीकरण जोडा आणि "स्यूडो-ट्रस्ट चेकिंग" लागू करा. तुमच्या स्वतःच्या चाचणी वातावरणात किमान एक IDOR/अधिकृतीकरण परिस्थिती चालवा. तुम्हाला आढळलेले कोणतेही करार किंवा व्यवसाय नियमांचे उल्लंघन कळवा; तुम्हाला काहीही सापडत नसल्यास, जाणूनबुजून चुकीच्या प्रतिसादाविरुद्ध चाचणी चालवा आणि हे सिद्ध करा की ते पकडले आहे.
चेकलिस्ट
- [ ] मी चाचणीचे चार स्तर समाविष्ट केले आहेत (केस, स्कीमा, व्यवसाय नियम, नकारात्मक/अधिकृतता).
- [ ] मी स्पष्टपणे AI ला करार आणि व्यवसाय नियम दिले.
- मी प्रतिसाद योजना (फील्ड, प्रकार, अनिवार्य) प्रमाणित करणाऱ्या चाचण्या सेट केल्या आहेत.
- [ ] मी किमान एक अधिकृतता/आयडीओआर परिस्थिती बचावात्मकपणे प्रयत्न केला आहे.
- मी वास्तविक टोकन/डेटा ऐवजी चाचणी वातावरण आणि सिंथेटिक डेटा वापरला.
- प्रत्येक चाचणी दूषित प्रतिसाद पकडते हे मी "स्यूडो-कॉन्फिडन्स चेक" सह सिद्ध केले.