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