API टेस्टिंग क्या है? REST API कैसे टेस्ट करें

स्टेप 1 — कॉन्ट्रैक्ट पढ़ें। कॉन्ट्रैक्ट नौ नतीजे डॉक्यूमेंट करता है: 201, 400, 401, 403 FORBIDDEN, 403 INSUFFICIENT_SCOPE, 404, 409, 415 और 422, इसलिए किसी भी बाउंड्री से पहले सेट में कम से कम नौ टेस्ट चाहिए। जिन नियमों की सीमाएँ हैं: qty (1 से रिटर्न हो सकने वाली quantity तक: O-5001 में A-100 के लिए 2 और B-200 के लिए 1), comment (500 characters), items (कम से कम एक entry, हर SKU एक बार, सिर्फ़ उसी ऑर्डर के SKU) और 14 दिन की अवधि। टेस्ट डेटा में अवधि की सीमा पर कोई ऑर्डर नहीं है, इसलिए CUS-101 के दो और सिंथेटिक ऑर्डर माँगें, जैसे 17 Sep 2026 को डिलीवर हुआ O-5004 (आज से 14 दिन पहले) और 16 Sep 2026 को डिलीवर हुआ O-5005 (15 दिन), दोनों में A-100 × 1, ताकि डेवलपर की रिक्वेस्ट बिना बदलाव उन पर चले। हर टेस्ट restore किए गए डेटा पर चलाएँ: हर सफल रिटर्न अगले टेस्ट के लिए रिटर्न हो सकने वाली quantity घटा देता है। नीचे का मॉडल सेट टेस्ट को RT-01 से RT-25 तक नंबर देता है; आपकी नंबरिंग और शब्द अलग हो सकते हैं।

स्टेप 2 — हैप्पी पाथ। RT-01 डेवलपर की रिक्वेस्ट (A-100 × 1, DAMAGED): 201; Location में /api/v1/returns/ के बाद बॉडी वाला id है; Content-Type: application/json और Cache-Control: no-store; बॉडी में रिटर्न के सभी फ़ील्ड सही टाइप के साथ हैं — refundAmount नंबर है, string नहीं, comment null है, createdAt ऑफ़सेट के साथ ISO 8601 में है — और वैल्यू सही हैं: orderId O-5001, status requested, items और reason जैसे भेजे गए, refundAmount 49.95; रिस्पॉन्स टाइम 800 ms से कम। इस रिस्पॉन्स को अपनी बेसलाइन के रूप में सेव करें। RT-02 ऑर्डर का सब कुछ: A-100 × 2 और B-200 × 1, reason WRONG_ITEM, एक छोटे comment के साथ: 201, दोनों items सूची में, comment वैसा ही लौटा जैसा भेजा, और refundAmount 219.90 (2 × 49.95 + 120.00) — ऐसी वैल्यू जिसे सिर्फ़ स्टेटस कोड जाँचना कभी नहीं पकड़ता।

स्टेप 3 — इनपुट तोड़ें; हर टेस्ट RT-01 ही है, बस एक बदलाव के साथ। RT-03 {"items": [ के बाद कटी बॉडी → 400 MALFORMED_JSON। RT-04 वही वैध बॉडी Content-Type: text/plain के साथ → 415 UNSUPPORTED_MEDIA_TYPE। RT-05 items हटाया → 422 VALIDATION_ERROR, field items। RT-06 "items": [] → 422, field items। RT-07 A-100 के लिए qty की बाउंड्री, जिसकी रिटर्न हो सकने वाली quantity 2 है (2-value boundary value analysis: हर बाउंड्री वैल्यू और बगल वाले partition में उसकी सबसे नज़दीकी वैल्यू): 0 → 422 और field items[0].qty; 1 → 201 (RT-01); 2 → 201; 3 → 422। RT-08 qty की अवैध वैल्यू और टाइप: -1, 1.5 और "1" (string) → हर एक पर 422। RT-09 SKU C-300, जो दूसरे ऑर्डर का है → 422, field items[0].sku। RT-10 items में A-100 दो बार → 422। RT-11 reason हटाया, और reason OTHER → 422, field reason। RT-12 ठीक 500 characters का comment → 201, पूरा comment लौटता है; 501 characters → 422, field comment।

RT-13 ऑर्डर O-9999 → 404 ORDER_NOT_FOUND। RT-14 O-5002, जो सिर्फ़ शिप हुआ है → 409 ORDER_NOT_RETURNABLE, जो कॉन्ट्रैक्ट डिलीवर न हुए ऑर्डर के लिए देता है (Q4 देखें)। RT-15 अवधि: O-5004 (दिन 14) → 201, अगर दिन 14 गिना जाता है (Q1); O-5005 (दिन 15) और O-5003 (दिन 21) → 409। RT-16 quotes और angle brackets वाला comment, जैसे O'Brien "test" <b>x</b> → 201, और comment ठीक वैसा ही लौटता है जैसा भेजा, बिना 500 के और किसी मैसेज में SQL या स्टैक ट्रेस के बिना। ऐसे इनपुट सिर्फ़ उन्हीं सिस्टम पर भेजें जिन्हें टेस्ट करने की आपको अनुमति है — यहाँ आपकी टीम का staging।

स्टेप 4 — ऑथेंटिकेशन। RT-17 बिना Authorization हेडर → 401 UNAUTHENTICATED और रिटर्न का कोई डेटा नहीं; RFC 9110 यह भी माँगता है कि हर 401 रिस्पॉन्स में WWW-Authenticate हेडर हो। RT-18 TOKEN_A_EXPIRED → 401 UNAUTHENTICATED। RT-19 O-5001 पर कस्टमर CUS-202 का TOKEN_B → 403 FORBIDDEN, बॉडी में O-5001 के बारे में कुछ नहीं; इसके बाद TOKEN_A के साथ GET /api/v1/orders/O-5001/returns कोई नया रिटर्न नहीं दिखाता, और TOKEN_B के साथ वही GET → 403। RFC 9110 सर्वर को ऑर्डर का अस्तित्व छिपाने के लिए इसकी जगह 404 देने की अनुमति देता है; इस कॉन्ट्रैक्ट ने 403 चुना है, इसलिए अपेक्षित परिणाम 403 है। RT-20 TOKEN_A_READ, जिसके पास सिर्फ़ orders:read है → 403 INSUFFICIENT_SCOPE।

स्टेप 5 — स्टेट बदलाव और हेडर। RT-21 RT-01 के बाद GET /api/v1/orders/O-5001/returns → 200, ठीक एक रिटर्न के साथ जिसका id, items, reason और refundAmount 201 वाली बॉडी से मेल खाते हैं। RT-22 रिटर्न हो सकने वाली quantity घटती है: RT-01 के बाद A-100 के लिए qty 2 → 422 (सिर्फ़ 1 बचा है), qty 1 → 201, फिर दोबारा qty 1 → 422। RT-23 RT-01 के साथ "status": "approved", "refundAmount": 999 → 201, status requested और refundAmount 49.95: क्लाइंट अपना रिफ़ंड ख़ुद तय न कर सके (OWASP API Security Top 10 2023 इसे API3, Broken Object Property Level Authorization के अंतर्गत रखता है)। RT-24 रिजेक्ट हुई रिक्वेस्ट कुछ नहीं बदलतीं: qty 3 वाले RT-07, RT-11 और RT-14 के बाद उस ऑर्डर के रिटर्न की सूची वैसी ही रहती है। RT-25 RT-02 वाली रिक्वेस्ट एक ही पल में दो बार भेजी गई → एक 201 और एक 422; दो 201 का मतलब है वही items दो बार रिफ़ंड होना। हर रिस्पॉन्स पर, एरर समेत, असर्ट करें: Content-Type: application/json, Cache-Control: no-store (डेटा प्राइवेट है), कॉन्ट्रैक्ट वाला एरर शेप, और Location सिर्फ़ 201 पर।

तरीके के आख़िरी दो स्टेप भी लागू होते हैं: हर टेस्ट का रिस्पॉन्स टाइम रिकॉर्ड करें और 800 ms से ऊपर वाले हर टाइम को चिह्नित करें, भले ही रिस्पॉन्स सही हो, और बिल्ड के बीच टाइम की तुलना करें: लगातार बढ़ता टाइम रिग्रेशन है, भले ही वह 800 ms से कम रहे। फिर सेट को ऐसे कलेक्शन में बदलें जो टेस्ट डेटा restore करे, हर बिल्ड पर चले और RT-01 की तुलना सेव की गई बेसलाइन से करे। एक एंडपॉइंट के लिए यह 25 टेस्ट हैं। गाइड का FAQ न्यूनतम बताता है — एक हैप्पी पाथ, हर डॉक्यूमेंटेड एरर के लिए एक, एक ऑथेंटिकेशन फ़ेलियर और हर पैरामीटर की बाउंड्री वैल्यू — और RT-21 से RT-25 वही हैं जो सिर्फ़ अलग-अलग रिस्पॉन्स से बना सेट छोड़ देता है।

स्टेप 6 — पहला रन। R1 तीन कारणों से फ़ेल है, और तीनों गाइड में बताए गए हैं: ख़राब इनपुट पर 422 की जगह 500, और कॉन्ट्रैक्ट से अलग एरर शेप (code, message और field वाले error ऑब्जेक्ट की जगह एक string) — ये गाइड की दो आम गलतियाँ हैं; और इंटरनल लीक करने वाला मैसेज (exception का नाम, सोर्स फ़ाइल और लाइन नंबर), जिसे गाइड की "हर रिस्पॉन्स में क्या असर्ट करें" वाली सूची मना करती है। अपेक्षित: field items[0].qty के साथ 422 VALIDATION_ERROR।

R2 फ़ेल है और सबसे गंभीर है: ऑथराइज़ेशन चेक गायब — टोकन वैध है लेकिन ऐसे कस्टमर का है जिसका इस ऑर्डर पर कोई हक़ नहीं। कोई भी signed-in कस्टमर किसी और के ऑर्डर पर रिटर्न, और इसलिए रिफ़ंड, माँग सकता है, और रिस्पॉन्स उस ऑर्डर का डेटा दिखाता है। OWASP API Security Top 10 2023 इसे API1, Broken Object Level Authorization कहता है। अपेक्षित: 403 FORBIDDEN, और कोई रिटर्न नहीं बनता। इसे सबसे पहले रिपोर्ट करें, severity Critical के साथ, TOKEN_B वाली सटीक रिक्वेस्ट, 201 रिस्पॉन्स और इसके बनाए रिटर्न R-9002 सहित; फ़िक्स के बाद RT-19 को confirmation testing के रूप में फिर चलाएँ, TOKEN_B वाले GET समेत। R3 फ़ेल है: बॉडी के अंदर एरर के साथ 200 OK, इसलिए स्टेटस कोड पर भरोसा करने वाला क्लाइंट कस्टमर को बताता है कि रिटर्न स्वीकार हो गया, और बॉडी में एक और अलग एरर शेप है। अपेक्षित: field reason के साथ 422 VALIDATION_ERROR, और कोई रिटर्न नहीं बनता।

Product owner और डेवलपर के लिए सवाल। Q1 क्या "within 14 days of delivery" में दिन 14 शामिल है, और क्या यह स्टोर के टाइम ज़ोन में कैलेंडर दिनों में गिना जाता है या डिलीवरी के समय से 24 घंटे की अवधियों में? Q2 अरबी टेक्स्ट और emoji के लिए comment के 500 characters कैसे गिने जाते हैं, और क्या खाली comment स्वीकार है? Q3 क्या reason case-sensitive है, यानी क्या damaged रिजेक्ट होता है? Q4 जब कोई रिक्वेस्ट दो नियम तोड़े, तो कौन-सा एरर पहले आता है? जैसे दूसरे कस्टमर का ऑर्डर और अवैध बॉडी, या O-5002, जो डिलीवर नहीं हुआ है, इसलिए उसकी कोई quantity अभी रिटर्न नहीं हो सकती (409 या 422?)। आमतौर पर उम्मीद यह है कि ऑथराइज़ेशन चेक पहले हो, ताकि वैलिडेशन मैसेज किसी और के ऑर्डर के बारे में कुछ न बताएँ।

अपना काम जाँचें: हर डॉक्यूमेंटेड स्टेटस कोड आपके सेट में कम से कम एक बार आना चाहिए; हर नेगेटिव टेस्ट RT-01 में ठीक एक चीज़ बदले; और हर अपेक्षित परिणाम स्टेटस कोड और एरर कोड का नाम ले, सिर्फ़ "एक एरर" नहीं। ISTQB की भाषा में कॉन्ट्रैक्ट test basis है, हर डॉक्यूमेंटेड रिस्पॉन्स और हर नियम एक test condition है, और RT-07, RT-12 और RT-15 2-value boundary value analysis लागू करते हैं। अगर आपके सेट में रिस्पॉन्स के बाद की जाँचें, यानी RT-21 से RT-25, नहीं थीं, तो उन्हें जोड़ें: रिस्पॉन्स सही दिख सकता है जबकि उसके पीछे का डेटा गलत हो।