API टेस्टिंग के तरीक़ों की तुलना

पहले पैटर्न। आज API को एक ही तरीक़ा मिलता है — एक्सप्लोरेटरी अनुरोध — और वह भी असली exploration नहीं: हर रिलीज़ से पहले वही collection हाथ से दोहराया जाता है। ज़्यादा से ज़्यादा यह I3, I7 और, काफ़ी बड़ी test दुकान हो तो, I5 पकड़ सकता था। बाक़ी हर समस्या के लिए ऐसा तरीक़ा चाहिए था जो टीम इस्तेमाल नहीं करती। नीचे का मॉडल जवाब हर समस्या के लिए वह तरीक़ा बताता है जो रिलीज़ से पहले उसे सबसे ज़्यादा संभावना से पकड़ता, और यह कि हाथ से चला पास उसे क्यों चूका; फिर यह कि हर तरीक़ा क्या छोड़ता है, मिश्रण, और टीम लीड को जवाब।

I1 — कॉन्ट्रैक्ट टेस्टिंग, प्रोवाइडर-साइड। अगर GET /api/v2/cart का हर रिस्पॉन्स CI में OpenAPI दस्तावेज़ के विरुद्ध वैलिडेट हो, तो deliveryFee के ग़ायब होते ही बिल्ड फ़ेल हो जाता है — बशर्ते स्कीमा deliveryFee को required बताता हो; यह जाँच लें, क्योंकि जिस स्कीमा के सभी फ़ील्ड optional हैं वह rename के बाद का रिस्पॉन्स स्वीकार कर लेता है। हाथ से चला पास इसे इसलिए चूका कि "delivery_fee": 9.00 किसी व्यक्ति को बिल्कुल ठीक लगता है, और उसी रिलीज़ में बदले web front end में कोई समस्या नहीं दिखी। इंस्टॉल हुए ऐप ही वजह हैं कि इस टीम को कंज़्यूमर-ड्रिवन कॉन्ट्रैक्ट भी चाहिए: इस्तेमाल में मौजूद हर ऐप वर्ज़न वे फ़ील्ड दर्ज करता है जिन्हें वह पढ़ता है, और प्रोवाइडर का जो बदलाव उनमें से किसी को तोड़े, वह शिप होने से पहले फ़ेल होता है। जिस फ़ील्ड का नाम बदलना ज़रूरी हो, उसे तब तक दोनों नामों से, या API के नए वर्ज़न में, भेजा जाता है जब तक पुराने ऐप इस्तेमाल से बाहर न हो जाएँ।

I2 — मॉकिंग। गेटवे का sandbox हर भुगतान तुरंत approve करता है, इसलिए न हाथ से भेजा अनुरोध और न स्टेजिंग पर चला टेस्ट ऐसा गेटवे पैदा कर सकता है जो 40 सेकंड बाद जवाब दे। गेटवे का मॉक यह कर सकता है, और साथ में बाक़ी त्रुटि-पथ भी: कोई जवाब ही नहीं, Retry-After हेडर के साथ 503, 429, और ऐसी बॉडी जो वैध JSON है पर ग़लत आकार की। भुगतान का नतीजा अज्ञात होने पर API क्या करे, यह टीम के साथ तय होना चाहिए — जैसे भुगतान को pending बताए और विफलता बताने के बजाय गेटवे से उसकी स्थिति पूछे — और टेस्ट वही एसर्ट करता है जो ग्राहक के लिए मायने रखता है: एक order, एक बार पैसा कटना। फिर टेस्ट हर बिल्ड पर CI में मॉक के विरुद्ध चलता है। हर रिलीज़ से पहले, स्टेजिंग से असली sandbox के विरुद्ध एक रन पुष्टि करता है कि मॉक अब भी गेटवे जैसा व्यवहार करता है।

I3 — एक्सप्लोरेटरी टेस्टिंग, फिर स्क्रिप्टेड टेस्ट। कॉन्ट्रैक्ट टेस्ट दूसरी छूट को पास कर देता है, क्योंकि रिस्पॉन्स का आकार बिल्कुल सही है: यह नए एंडपॉइंट में ग़लत बिज़नेस लॉजिक है। जो टेस्टर "हर ग्राहक के लिए एक बार वाला नियम तोड़ो" जैसे charter के साथ POST /api/v2/cart/promo को explore करता है, वह code को दूसरे order पर, पहला order रद्द करने के बाद, एक ही पल में दो devices से, और छोटे अक्षरों (welcome50) में आज़माता है। हाथ से चला पास एक तय collection दोहराता है, और नया नियम ठीक वही है जो उसमें नहीं होता: हाथ से अनुरोध भेजना explore करना नहीं है। मिला हर केस स्क्रिप्टेड टेस्ट बनता है, ताकि नियम ठीक बना रहे।

I4 — यथार्थ डेटासेट के साथ लोड टेस्टिंग। हाथ से भेजे अनुरोध इसे नहीं दिखा सकते: एक व्यक्ति एक बार में एक अनुरोध भेजता है, लगभग 30 orders वाले test ग्राहकों के लिए, जबकि इस failure के लिए एक ही समय पर ऐसे बहुत-से ग्राहक चाहिए जिनके 2,000 तक orders हों। Production जैसी order संख्या वाला test data बनाएँ, टेस्ट से पहले product owner के साथ लक्ष्य तय करें (अपेक्षित peak पर एक response time और एक error rate), और टेस्ट इतनी जल्दी चलाएँ कि जो मिले उसे ठीक करके 12 नवंबर से पहले दोबारा चलाया जा सके — और order history में किसी भी बदलाव के बाद फिर, क्योंकि वह हॉट पाथ है। लोड टेस्ट यह नहीं बताता कि सूची में दिखे orders सही हैं या नहीं।

I5 — स्क्रिप्टेड टेस्ट जो GraphQL बॉडी पर एसर्ट करें। GraphQL सर्वर किसी फ़ील्ड के फ़ेल होने पर भी आमतौर पर 200 देता है और failure को errors ऐरे में रखता है, इसलिए स्टेटस कोड का चेक — डैशबोर्ड का health check हो या कोई टेस्ट — हरा ही रहता है। टेस्ट एसर्ट करता है कि errors मौजूद नहीं है और data.storeOrders अपेक्षित orders वाली सूची है, और वह उस बिंदु के दोनों ओर की test दुकानों के साथ चलता है जहाँ यह टूटा: 100 और 101 open orders (2-value boundary value analysis)। सिर्फ़ GraphQL स्कीमा के विरुद्ध कॉन्ट्रैक्ट चेक यह रिस्पॉन्स पास कर देगा: storeOrders error के साथ null लौटा, और GraphQL ऐसा सिर्फ़ उसी फ़ील्ड के लिए करता है जिसे स्कीमा nullable घोषित करता है। Health check को भी इसी तरह ठीक करें, और सबसे बड़े यथार्थ आकार की एक दुकान लोड टेस्ट में जोड़ें, क्योंकि GraphQL का एक अनुरोध बहुत महँगा हो सकता है।

I6 — वेबहुक टेस्ट जिसमें टेस्ट गेटवे की भूमिका निभाता है। "कम से कम एक बार deliver" का मतलब है कि डुप्लिकेट सामान्य हैं, गेटवे की ख़राबी नहीं, इसलिए रिसीवर को उन्हें संभालना होगा। टेस्ट वही साइन किया हुआ payment.succeeded event, उसी event id के साथ, दो बार भेजता है और एसर्ट करता है कि order एक बार paid हुआ और एक ही invoice बना; दूसरा टेस्ट events को अलग क्रम में भेजता है, जैसे उसी भुगतान के लिए payment.succeeded के बाद payment.failed, और टीम द्वारा तय नतीजा जाँचता है (लिखा न हो तो पूछें)। Sandbox से ठीक उसी पल retry नहीं करवाया जा सकता जब टेस्ट को चाहिए, इसलिए यह मॉकिंग है — गेटवे का व्यवहार माँग पर पैदा करना — जो CI में स्क्रिप्टेड टेस्ट के रूप में चलती है।

I7 — वेबहुक रिसीवर के स्क्रिप्टेड नेगेटिव टेस्ट, और एक सुरक्षा defect। तीन अनुरोध उस error status के साथ reject होने चाहिए जो टीम दस्तावेज़ में लिखे (जैसे 401), और order में कोई बदलाव न हो: बिना X-Signature हेडर, ग़लत सीक्रेट से बना सिग्नेचर, और सही तरह साइन की गई बॉडी जो साइन करने के बाद बदली गई। आख़िरी वाला वही है जो HMAC जनरेटर वाला अभ्यास दिखाता है: एक अक्षर बदलने से सिग्नेचर बदल जाता है। Collection में सिर्फ़ गेटवे की वैध कॉल थीं, इसलिए हाथ से चले पास ने ऐसा अनुरोध कभी भेजा ही नहीं; जिस code review ने इसे पकड़ा वह static testing है, और स्क्रिप्टेड टेस्ट इसे ठीक बनाए रखता है। क्योंकि यह API पैसे का लेन-देन करता है और ग्राहकों का निजी डेटा रखता है, मिश्रण में OWASP API Security Top 10 2023 से टेस्ट जोड़ें, सबसे पहले ऑब्जेक्ट-लेवल ऑथराइज़ेशन: एक ग्राहक दूसरे ग्राहक का cart या orders न पढ़ सके, न बदल सके। सिर्फ़ उन्हीं सिस्टम को टेस्ट करें जिनकी आपको अनुमति है — यहाँ आपकी टीम का स्टेजिंग।

I8 — CI में स्क्रिप्टेड फ़ंक्शनल टेस्ट। यह रिग्रेशन है: 2.12 में काम करने वाला filter 2.13 में टूट गया, ऐसी रिलीज़ में जिसके हाथ से चले पास में संयोग से filters नहीं थे। एक टेस्ट कि inStock=true शून्य stock वाला कोई product नहीं लौटाता, हर बिल्ड पर चलने वाले सूट में, उसी बदलाव पर फ़ेल हो जाता जिसने इसे तोड़ा। कॉन्ट्रैक्ट टेस्ट इसे पास कर देता है, क्योंकि सूची में sold-out product का आकार सही है।

इस उत्पाद में हर तरीक़ा फिर भी क्या छोड़ता है, और कमी कौन पूरी करता है। कॉन्ट्रैक्ट टेस्टिंग सही आकार के भीतर ग़लत मान छोड़ती है — I3, I8 और I5 का null — इसलिए स्क्रिप्टेड टेस्ट बिज़नेस नियमों पर एसर्ट करते हैं। स्क्रिप्टेड टेस्ट सिर्फ़ वही पकड़ते हैं जिसके लिए लिखे गए, और I3 जैसा नया नियम उनमें नहीं होता, इसलिए हर नए या बदले एंडपॉइंट पर एक्सप्लोरेटरी सेशन होता है। एक्सप्लोरेटरी सेशन ख़त्म होने के बाद कुछ साबित नहीं करता, इसलिए हर finding स्क्रिप्टेड टेस्ट बनती है। गेटवे का मॉक आपकी टीम से सहमत होता है, ज़रूरी नहीं कि गेटवे से, इसलिए वह गेटवे के अपने API documentation से बनाया जाता है और हर रिलीज़ से पहले स्टेजिंग से असली sandbox के विरुद्ध जाँचा जाता है। लोड टेस्ट फ़ंक्शनल सही-ग़लत के बारे में कुछ नहीं बताता — order history तेज़ और ग़लत दोनों हो सकती है — यह CI सूट कवर करता है।

मिश्रण। CI में हर बिल्ड पर: स्क्रिप्टेड API सूट, जिसके पहले रिग्रेशन टेस्ट में I1 से I8 हों; हर रिस्पॉन्स, एरर रिस्पॉन्स समेत, OpenAPI दस्तावेज़ के विरुद्ध वैलिडेट; बॉडी पर एसर्ट करने वाले GraphQL टेस्ट; I6 और I7 के वेबहुक टेस्ट; और त्रुटि-पथों के लिए गेटवे का मॉक। हर नए या बदले एंडपॉइंट के लिए: एक छोटा एक्सप्लोरेटरी सेशन, जिसकी findings स्क्रिप्टेड टेस्ट बनती हैं। हर रिलीज़ से पहले: स्टेजिंग से असली गेटवे sandbox के विरुद्ध एक रन। कैंपेन से पहले, और order history जैसे किसी हॉट पाथ के बदलाव के बाद: production जैसे डेटा के साथ लोड टेस्ट। यह गाइड का डिफ़ॉल्ट मिश्रण है, दो बदलावों के साथ। इंस्टॉल हुए ऐप API के साथ-साथ update नहीं किए जा सकते — पिछले छह महीनों के वर्ज़न अब भी इस्तेमाल में हैं — इसलिए उनके लिए API सार्वजनिक उत्पाद जैसा व्यवहार करता है और उसे कंज़्यूमर-ड्रिवन कॉन्ट्रैक्ट और अब भी supported हर ऐप वर्ज़न के टेस्ट चाहिए। और वह पैसा और निजी डेटा संभालता है, इसलिए उसे OWASP API Security Top 10 के टेस्ट चाहिए।

आज सबसे पहले: कॉन्ट्रैक्ट। पाँच महीने पुराने OpenAPI दस्तावेज़ को API के अनुसार update करें और वैलिडेट करें — पुराना या अमान्य दस्तावेज़ कॉन्ट्रैक्ट टेस्ट के हर नतीजे को अर्थहीन बना देता है — फिर उससे पहले स्क्रिप्टेड केस जनरेट करें (गाइड का OpenAPI → टेस्ट केस टूल मदद करता है) और वे बिज़नेस-नियम केस जोड़ें जो जनरेटर नहीं जान सकता, जैसे I3। 12 नवंबर तक लगभग पाँच हफ़्ते हैं, तो एक व्यावहारिक क्रम है: कॉन्ट्रैक्ट और CI में कॉन्ट्रैक्ट चेक; फिर I1 से I8, गेटवे मॉक और वेबहुक टेस्ट वाला स्क्रिप्टेड सूट; फिर लोड टेस्ट, इतनी जल्दी कि जो मिले उसे ठीक करके कैंपेन से पहले दोबारा चलाया जा सके।

टीम लीड को जवाब: "नहीं, क्योंकि हाथ से अनुरोध भेजने वाले और लोग पाँच में से सिर्फ़ एक सवाल का जवाब देते हैं। पिछली तिमाही की आठ समस्याओं में से हाथ से भेजे अनुरोध ज़्यादा से ज़्यादा I3, I7 और शायद I5 पकड़ सकते थे; वे I1 नहीं दिखा सकते थे, क्योंकि rename हुआ फ़ील्ड व्यक्ति को ठीक लगता है, न I2 और I6, क्योंकि sandbox धीमा जवाब या retry पैदा नहीं कर सकता, न I4, क्योंकि एक व्यक्ति कैंपेन की peak पैदा नहीं कर सकता — और वे जो पकड़ते हैं, उसकी बाद में दोबारा जाँच नहीं होती; I8 इसी तरह हुआ। Postman सेव किए collections को एसर्शन के साथ CI में चला सकता है, जो स्क्रिप्टेड टेस्ट कवर करता है, लेकिन कॉन्ट्रैक्ट वैलिडेशन, गेटवे के मॉक और लोड टेस्ट के लिए साथ में स्पेसिफ़िकेशन, मॉक लेयर और लोड टूल चाहिए। दूसरे टेस्टर का सबसे अच्छा इस्तेमाल नए एंडपॉइंट पर एक्सप्लोरेटरी सेशन और उनकी findings को स्क्रिप्टेड टेस्ट में बदलना है।"

अपना काम जाँचें। हर समस्या का एक तरीक़ा हो और यह कारण भी कि मौजूदा तरीक़ा उसे क्यों चूका। कारण लिखा हो तो दूसरी mapping भी ठीक हैं — जैसे I7 को एक्सप्लोरेटरी टेस्टिंग में रखना, बशर्ते आप जोड़ें कि सिर्फ़ स्क्रिप्टेड टेस्ट उसे ठीक बनाए रखता है, या I6 को स्क्रिप्टेड टेस्ट में, बशर्ते आप लिखें कि डुप्लिकेट delivery माँग पर पैदा करनी होगी। आपके मिश्रण में लिखा हो कि हर तरीक़ा कब चलता है (हर बिल्ड, हर नया एंडपॉइंट, हर रिलीज़, कैंपेन से पहले) और हर एक क्या छोड़ता है। ISTQB CTFL v4.0 की भाषा में: OpenAPI दस्तावेज़ test basis है और कॉन्ट्रैक्ट टेस्ट के लिए test oracle; एक्सप्लोरेटरी टेस्टिंग एक experience-based test technique है; CI सूट regression testing है, और I1 से I8 में से हर fix को पहले confirmation testing चाहिए; लोड टेस्ट performance efficiency (ISO/IEC 25010) की non-functional testing है; और स्टेजिंग से असली गेटवे के विरुद्ध रन system integration testing है।