लाभ:
- स्थिति कोड, स्कीमा/अनुबंध, व्यवसाय नियम और नकारात्मक/प्राधिकरण परतों पर कृत्रिम बुद्धिमत्ता समर्थन के साथ गहराई से एपीआई परीक्षण करने की क्षमता
- नमूना प्रतिक्रिया से JSON स्कीमा उत्पन्न करने की क्षमता और केवल प्रकार और अनिवार्य सत्यापन के साथ स्थिति कोड को देखने के छद्म आत्मविश्वास से बचें
- सिंथेटिक डेटा के साथ प्राधिकरण और आईडीओआर जैसे सुरक्षा परिदृश्यों का परीक्षण करने की क्षमता और केवल प्राधिकरण के भीतर रक्षात्मक उद्देश्यों के लिए
अधिकांश आधुनिक सॉफ़्टवेयर एपीआई (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस - इंटरफ़ेस जहां सॉफ़्टवेयर के दो टुकड़े एक विशिष्ट अनुबंध के अनुसार बात करते हैं) के माध्यम से पृष्ठभूमि में एक दूसरे से बात करते हैं। जब कोई मोबाइल ऐप कार्ट में आइटम जोड़ता है, तो यह वास्तव में सर्वर पर एक एपीआई को एक अनुरोध भेजता है। एपीआई परीक्षण जाँचता है कि इंटरफ़ेस की परवाह किए बिना यह बातचीत सही, सुरक्षित और सुसंगत है; यह यूआई परीक्षण की तुलना में तेज़, अधिक स्थिर और गहरा है। आर्टिफिशियल इंटेलिजेंस (एआई) एपीआई परीक्षण में बहुत कुशल है: यह एपीआई परिभाषा से परीक्षण उत्पन्न करता है, प्रतिक्रिया स्कीमा (अनुबंध जो डेटा की संरचना को परिभाषित करता है) निकालता है, किनारे के मामलों को सूचीबद्ध करता है। लेकिन फिर से केंद्रीय चेतावनी लागू होती है: एआई आपके एपीआई के वास्तविक व्यावसायिक नियमों को नहीं जानता है; सतही परीक्षण करने की प्रवृत्ति होती है जो केवल "200 लौटे" की पुष्टि करते हैं। आपका काम यह सुनिश्चित करना है कि परीक्षण वास्तविक अनुबंध और व्यावसायिक तर्क की पुष्टि करता है।
इस इकाई में, आप सीखेंगे कि पोस्टमैन, रेस्ट एश्योर्ड और स्कीमा सत्यापन जैसे दृष्टिकोणों के साथ एआई-समर्थित, गहन एपीआई परीक्षण कैसे स्थापित करें।
एपीआई परीक्षण की परतें
कई गहराईयों में एपीआई परीक्षण पर विचार करें, एआई प्रत्येक परत पर अलग-अलग मदद करेगा:
1. स्थिति कोड और मूल प्रतिक्रिया। क्या अनुरोध अपेक्षित HTTP स्थिति कोड (सफलता के लिए 200/201, त्रुटि के लिए 400/401/404) लौटाता है? यह सबसे सतही परत है; एआई आसानी से उत्पादन करता है लेकिन अकेला झूठा-भरोसा देता है।
2. स्कीमा/अनुबंध सत्यापन। क्या प्रतिक्रिया की संरचना अनुबंध के अनुरूप है - क्या अपेक्षित फ़ील्ड मौजूद हैं, क्या उनके प्रकार सही हैं, क्या आवश्यक फ़ील्ड गायब हैं? AI JSON स्कीमा उत्पन्न कर सकता है - वह मानक जो JSON दस्तावेज़ की संरचना को परिभाषित करता है - एक नमूना प्रतिक्रिया से, और परीक्षण उस स्कीमा के विरुद्ध मान्य हो सकते हैं। फ़ील्ड-आधारित दावे को मैन्युअल रूप से लिखने की तुलना में यह कहीं अधिक मजबूत है।
3. व्यवसाय नियम सत्यापन. वास्तविक मूल्य यहां है: "1000 टीएल ऑर्डर के लिए, छूट फ़ील्ड 100 होनी चाहिए", "रद्द किया गया ऑर्डर दोबारा रद्द नहीं किया जा सकता"। एआई इन्हें केवल तभी सत्यापित करेगा जब आप उसे नियम बताएंगे; नहीं दोगे तो कूद जायेगा.
4. नकारात्मकता और सुरक्षा. अमान्य टोकन के लिए 401, किसी और के डेटा तक पहुँचने के लिए 403, खराब बॉडी के लिए स्पष्ट 400। प्राधिकरण परीक्षण (यह सत्यापित करना कि उपयोगकर्ता केवल अपने डेटा तक ही पहुंच सकता है) एपीआई सुरक्षा का केंद्र हैं और रक्षात्मक उद्देश्यों के लिए किए जाते हैं।
युक्ति: एआई को बताए बिना परीक्षण का अनुरोध न करें कि "न केवल स्थिति कोड, बल्कि प्रतिक्रिया स्कीमा और उन व्यावसायिक नियमों को भी मान्य करें।" अन्यथा, आपके पास ऐसे परीक्षण रह जाएंगे जो कहते हैं कि "200 वापस आ गए, उत्तीर्ण हो गए" लेकिन एपीआई द्वारा दूषित डेटा लौटाने पर ध्यान नहीं दिया जाएगा।
कमजोर संकेत/मजबूत संकेत
कमजोर: "इस एपीआई के लिए परीक्षण लिखें।"
मजबूत: "पोस्ट/ऑर्डर एंडपॉइंट के लिए रेस्ट एश्योर्ड (जावा) परीक्षण लिखें। समझौता: मुख्य भाग में उत्पाद आईडी और मात्रा अनिवार्य है; सफलता पर 201 और {ऑर्डर आईडी, कुल, छूट, स्थिति} लौटा दी जाती है। व्यावसायिक नियम: 1000 टीएल से अधिक 10% छूट; 400 यदि मात्रा <= 0; 401 यदि अमान्य टोकन; 403 यदि किसी अन्य उपयोगकर्ता का ऑर्डर देखते हैं। परीक्षण: (1) स्थिति कोड, (2) प्रतिक्रिया JSON स्कीमा सत्यापन, (3) डिस्काउंट बिजनेस नियम, (4) प्रत्येक दावे को स्पष्ट बिजनेस नियम से बांधें, केवल 200/201 की जांच न करें;
शक्तिशाली संकेत अनुबंध, व्यावसायिक नियम, सुरक्षा परिदृश्य और स्कीमा सत्यापन अपेक्षा देता है।
अनुबंध परीक्षण: टीमों के बीच टूटने को रोकना
माइक्रोसर्विस आर्किटेक्चर में (वह संरचना जिसमें एप्लिकेशन को छोटी सेवाओं में विभाजित किया जाता है जो एक-दूसरे से स्वतंत्र होती हैं और एपीआई से बात करती हैं), किसी सेवा के प्रतिक्रिया प्रारूप को बदलने से उससे जुड़ी अन्य सेवाएं चुपचाप बाधित हो जाती हैं। अनुबंध परीक्षण - वह परीक्षण जो सत्यापित करता है कि प्रदाता सेवा और उपभोक्ता सेवा के बीच एपीआई अनुबंध दोनों तरफ से टूटा नहीं है - ऐसे ब्रेक को जल्दी पकड़ लेता है। विचार यह है: उपभोक्ता प्रतिक्रिया के उस रूप को परिभाषित करता है जिसकी वह निर्माता से "अनुबंध" के रूप में अपेक्षा करता है; प्रत्येक परिवर्तन के साथ, निर्माता परीक्षण करता है कि वह अभी भी इस अनुबंध का अनुपालन करता है। इसलिए जब किसी फ़ील्ड का नाम या प्रकार बदलता है, तो उपभोक्ता पाइपलाइन के क्रैश होने से पहले उसे सूचित करता है।
एआई इस संदर्भ में दो कार्यों को गति देता है: एक अनुबंध का मसौदा तैयार करना जो मौजूदा एपीआई प्रतिक्रिया से उपभोक्ता की अपेक्षा को दर्शाता है, और पूर्व-चिह्नित करना कि कौन सा अनुबंध खंड परिवर्तन से टूट सकता है। लेकिन अनुबंध स्वयं एक व्यावसायिक निर्णय है: विशेषज्ञ यह निर्धारित करता है कि कौन से क्षेत्र वास्तव में महत्वपूर्ण हैं, कौन से परिवर्तन पिछड़ी संगतता को तोड़ देंगे - पुराने उपभोक्ता काम करना जारी रखते हैं। एआई अनुबंध लिखता है; आप ही हैं जो इसका अनुमोदन करते हैं।
युक्ति: किसी फ़ील्ड को हटाना या एपीआई में फ़ील्ड प्रकार को बदलना लगभग हमेशा एक ब्रेकिंग परिवर्तन होता है। नए फ़ील्ड जोड़ना आमतौर पर सुरक्षित होता है. एआई द्वारा किसी बदलाव को "ब्रेकिंग या सेफ" के रूप में वर्गीकृत करने से त्वरित प्री-रिलीज़ सुरक्षा जांच मिलती है।
डाकिया या कोड-आधारित?
कसौटी
डाकिया/न्यूमैन
रेस्ट एश्योर्ड / कोड (जावा, सी#, जेएस)
सीखना
आसान, दृश्यात्मक
कोड ज्ञान आवश्यक है
संस्करण नियंत्रण
संग्रह JSON
सीधे स्रोत कोड में
जटिल तर्क
सीमित (जेएस स्क्रिप्ट)
पूर्ण प्रोग्रामिंग शक्ति
सीआई/सीडी एकीकरण
न्यूमैन के साथ
निर्माण पर सीधे निर्भर
स्कीमा सत्यापन
परीक्षण स्क्रिप्ट के साथ
पुस्तकालय के साथ शक्तिशाली
टीम स्केल
छोटा/मध्यम
बड़ा, परिपक्व
एआई दोनों के लिए कोड उत्पन्न करता है; स्पष्ट रहें कि आप कौन सा चाहते हैं।
चार प्रतिलिपि योग्य टेम्पलेट
1) अनुबंध-आधारित एपीआई परीक्षण:
आपकी भूमिका: वरिष्ठ एपीआई परीक्षण इंजीनियर। [उपकरण/भाषा] के साथ निम्नलिखित समापन बिंदु के लिए परीक्षण लिखें: [विधि + पथ]। अनुबंध: [आवश्यक फ़ील्ड, सफलता कोड, प्रतिक्रिया संरचना]। व्यवसाय नियम: [नियम]। परीक्षण परतें: (1) स्थिति कोड (2) प्रतिक्रिया स्कीमा सत्यापन (3) प्रत्येक व्यवसाय नियम (4) नकारात्मक + प्राधिकरण। प्रत्येक दावे को प्रासंगिक नियम/अनुबंध खंड से लिंक करें।
2) नमूना प्रतिक्रिया से स्कीमा निर्माण:
नीचे दिए गए नमूना API प्रतिक्रिया से JSON स्कीमा जेनरेट करें। आवश्यक फ़ील्ड, प्रकार, प्रारूप बाधाएं (तिथि, ईमेल, संख्या सीमा) निर्दिष्ट करें। फिर एक परीक्षण उदाहरण दें जो इस स्कीमा के विरुद्ध मान्य हो। नमूना प्रतिक्रिया: [JSON चिपकाएँ]
3) नकारात्मक और प्राधिकरण परिदृश्य:
एंडपॉइंट[एंडपॉइंट] के लिए नकारात्मक और सुरक्षा परीक्षण मामले उत्पन्न करें। इसमें शामिल हैं: गुम/आवश्यक फ़ील्ड, गलत प्रकार, बहुत बड़ा मान, अमान्य/समाप्त टोकन, अनधिकृत संसाधन तक पहुंच (आईडीओआर - आईडी बदलकर किसी और के रिकॉर्ड तक पहुंच), दर सीमा। प्रत्येक परिदृश्य के लिए अपेक्षित स्थिति कोड और त्रुटि निकाय निर्दिष्ट करें। ध्यान दें: केवल मेरे स्वयं के एपीआई पर परीक्षण किया जाएगा, अधिकृत।
4) छद्म विश्वास नियंत्रण:
इस एपीआई परीक्षण को देखें. यदि सर्वर सही स्थिति कोड लेकिन FALSEbody/डेटा लौटाता है तो क्या यह परीक्षण पकड़ में आएगा? यदि नहीं, तो स्कीमा और व्यावसायिक नियम सत्यापन जोड़ें। परीक्षण: [परीक्षण चिपकाएँ]
तीन मिनी मामले
केस 1 - स्कीमा सत्यापन की शक्ति। एक टीम एआई के साथ उत्पादित परीक्षणों में केवल स्थिति कोड की जांच कर रही थी। एक संस्करण में, एपीआई ने गलती से कुल फ़ील्ड को टेक्स्ट ("1200") के रूप में लौटाना शुरू कर दिया; परीक्षण हरा रहा क्योंकि यह अभी भी 200 लौटा रहा था। मोबाइल एप्लिकेशन क्रैश हो गया। "नमूना प्रतिक्रिया से स्कीमा पीढ़ी" टेम्पलेट के साथ प्रकार सत्यापन जोड़ने के बाद, वही त्रुटि तुरंत पकड़ी गई।
केस 2 - अथॉरिटी गैप (आईडीओआर)। एक विशेषज्ञ ने एआई द्वारा उत्पन्न "नकारात्मक और प्राधिकरण परिदृश्यों" के बीच आईडीओआर परीक्षण चलाया: उन्होंने उपयोगकर्ता ए के टोकन के साथ उपयोगकर्ता बी की ऑर्डर आईडी का अनुरोध किया। एपीआई ने 200 और बी का डेटा लौटाया - एक गंभीर प्राधिकरण भेद्यता। इस रक्षात्मक परीक्षण ने लाइव होने से पहले ही डेटा लीक को बंद कर दिया।
केस 3 - बिजनेस रूल बायपास। एआई ने डिस्काउंट एंडपॉइंट के लिए 8 परीक्षण तैयार किए; सभी 200 की जाँच कर रहे थे, कोई भी छूट की राशि की पुष्टि नहीं कर रहा था। विशेषज्ञ ने व्यावसायिक नियमों को प्रॉम्प्ट में जोड़ा और उन्हें पुन: प्रस्तुत किया। नए परीक्षणों से पता चला कि छूट की गणना 1000 टीएल सीमा पर गलत तरीके से की गई थी (छूट 999 पर भी लागू की गई थी)। अनुबंध नियंत्रण पर्याप्त नहीं है; व्यवसाय नियम नियंत्रण आवश्यक है.
सामान्य गलतियाँ
- बस स्टेटस कोड देख रहा हूं। यह कहने के लिए कि "200 लौट आए और गुजर गए"; भ्रष्ट शरीर को न देखना (झूठा विश्वास)।
- स्कीमा सत्यापन को दरकिनार करना। फ़ील्ड प्रकार और दायित्व की जाँच नहीं करना; प्रकार परिवर्तन चुपचाप गुजरते हैं।
- व्यावसायिक नियम प्रदान किए बिना परीक्षण का अनुरोध करना। एआई को नियम नहीं पता; यह केवल तकनीकी नियंत्रण उत्पन्न करता है।
- नकारात्मक और पात्रता परिदृश्यों को भूल जाना। सुरक्षा कमजोरियां (आईडीओआर, अनधिकृत पहुंच) केवल इन परीक्षणों से पकड़ी जाती हैं।
- वास्तविक/उत्पादन टोकन और डेटा का उपयोग करना। परीक्षण के लिए समर्पित मीडिया और सिंथेटिक डेटा का उपयोग करें; वाहन में असली चाबियाँ न चिपकाएँ।
- अनधिकृत सुरक्षा परीक्षण. प्राधिकरण परीक्षण केवल अपने स्वयं के एपीआई पर और अनुमति के साथ चलाएं।
सारांश
एपीआई परीक्षण इंटरफ़ेस की परवाह किए बिना सॉफ़्टवेयर के टुकड़ों के भाषण को जल्दी और गहराई से सत्यापित करता है। ऐ; नमूना प्रतिक्रिया से JSON स्कीमा और नकारात्मक/सुरक्षा परिदृश्य उत्पन्न करने में अनुबंध परीक्षण बहुत कुशल हैं। लेकिन सतही परीक्षण जो केवल स्थिति कोड की जांच करते हैं, छद्म विश्वास देते हैं। सभी चार परतों की आवश्यकता है: स्थिति कोड, स्कीमा सत्यापन, व्यवसाय नियम, नकारात्मक और प्राधिकरण। व्यावसायिक नियमों और अनुबंध को प्रॉम्प्ट पर रखें; सिंथेटिक डेटा के साथ और केवल प्राधिकरण के साथ सुरक्षा परीक्षण करें।
आवेदन कार्य
अपने स्वयं के प्रोजेक्ट से एक एपीआई एंडपॉइंट चुनें। एआई को "अनुबंध-आधारित एपीआई परीक्षण" टेम्पलेट के साथ चार-परत परीक्षण लिखने को कहें। फिर "नमूना प्रतिक्रिया से स्कीमा निर्माण" के साथ प्रकार/प्रवर्तन सत्यापन जोड़ें और "छद्म-विश्वास जाँच" लागू करें। अपने परीक्षण परिवेश में कम से कम एक IDOR/प्राधिकरण परिदृश्य चलाएँ। किसी भी अनुबंध या व्यावसायिक नियम का उल्लंघन पाए जाने पर उसकी रिपोर्ट करें; यदि आपको कोई नहीं मिल रहा है, तो जानबूझकर विकृत प्रतिक्रिया के खिलाफ परीक्षण चलाएं ताकि यह साबित हो सके कि उसने इसे पकड़ लिया है।
चेकलिस्ट
- [ ] मैंने परीक्षण की चार परतों (केस, स्कीमा, बिजनेस नियम, नकारात्मक/प्राधिकरण) को कवर किया।
- [ ] मैंने एआई को स्पष्ट रूप से अनुबंध और व्यावसायिक नियम दिए।
- [ ] मैंने ऐसे परीक्षण स्थापित किए हैं जो प्रतिक्रिया स्कीमा (फ़ील्ड, प्रकार, अनिवार्यता) को मान्य करते हैं।
- [ ] मैंने रक्षात्मक रूप से कम से कम एक प्राधिकरण/आईडीओआर परिदृश्य का प्रयास किया है।
- [ ] मैंने वास्तविक टोकन/डेटा के बजाय परीक्षण वातावरण और सिंथेटिक डेटा का उपयोग किया।
- [ ] मैंने "छद्म-आत्मविश्वास जांच" से साबित कर दिया कि प्रत्येक परीक्षण दूषित प्रतिक्रिया पकड़ता है।