API लोड टेस्टिंग असल में क्या मापती है
क्षमता: प्रति सेकंड कितनी requests के बाद latency बिगड़ने लगती है। इसका जवाब concurrent ट्रैफ़िक जनरेट करके और response times व error rates पर नज़र रखकर मिलता है।
शुद्धता: क्या response में सही चीज़ आ रही है। इसका जवाब response bodies पर अपेक्षा के मुक़ाबले assertions लगाकर मिलता है।
जो लोड टेस्ट सिर्फ़ status codes जाँचता है, वह साफ़-सुथरा रन रिपोर्ट करेगा जबकि हर response में खाली list आ रही होगी। सर्विस तेज़ थी और गलत थी, और तेज़ व गलत होना धीमे व सही होने से बुरा है, क्योंकि उसकी जाँच कोई नहीं करता।
फ़ंक्शनल suite आपको लोड के बारे में क्या बताती है, और क्या नहीं
जनरेट किए गए API टेस्ट प्लान में boundary और stress जैसे cases शामिल होते हैं: ज़रूरत से बड़े payloads, दायरे से बाहर की values, असामान्य parameter combinations। ये failure की एक असली श्रेणी पकड़ते हैं, और ये लोड टेस्टिंग नहीं हैं। ये लगातार बनी रहने वाली concurrency के तहत व्यवहार मापने के बजाय एक-एक करके edge cases आज़माते हैं।
तो ईमानदार बँटवारा यह है। क्षमता के लिए एक dedicated लोड टूल इस्तेमाल करें। शुद्धता के लिए फ़ंक्शनल verification इस्तेमाल करें, उन edge cases समेत जो सिर्फ़ अटपटे input पर सामने आते हैं। इनमें से कोई दूसरे की जगह नहीं ले सकता, और दोनों चलाना उस खाई को production में खोजने से सस्ता पड़ता है।
लोड टेस्ट शुरू करने से पहले जाँचने लायक तीन चीज़ें
क्या यह प्रति सेकंड एक request पर सही है
टूटे हुए endpoint की लोड टेस्टिंग यह मापती है कि आप कितनी तेज़ी से गलत हो सकते हैं।
क्या यह cleanup करता है
जो लोड रन records बनाकर उन्हें छोड़ देता है, वह अगले रन का व्यवहार बदल देगा।
क्या environment असलियत का प्रतिनिधित्व करता है
जिस environment में डेटा का दसवाँ हिस्सा हो, उससे मिले लोड नतीजे कोई भविष्यवाणी नहीं होते, वे बस एक संख्या होते हैं।
वास्तविक हालात में शुद्धता
पाटने लायक खाई लोड और फ़ंक्शनल टेस्टिंग के बीच नहीं है। बात यह है कि ज़्यादातर फ़ंक्शनल suites एक साफ़, निष्क्रिय environment पर चलती हैं, इसलिए वे उन failures को कभी नहीं देखतीं जो डेटा बड़ा होने या state बिखरी होने पर सामने आती हैं। इस्तेमाल हो चुके environment पर फ़ंक्शनल checks चलाना उन्हें ढूँढने का सस्ता तरीका है।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप स्थानीय तौर पर कुछ इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite dashboard में भी मौजूद है। बाकी CLI surface के लिए देखें CLI रिपॉज़िटरी।
किसी API suite के टिकने का फ़ैसला करने वाली चार चीज़ें — sessions, capture की गई values, ordering और cleanup — के लिए देखें API टेस्टिंग डॉक्यूमेंटेशन।
लोड नतीजे को ईमानदारी से पढ़ना
लोड नतीजों का ज़रूरत से ज़्यादा मतलब निकाला जाता है — लगभग किसी भी दूसरे टेस्ट आउटपुट से ज़्यादा — और आम तौर पर दो दिशाओं में।
जो environment production से मेल नहीं खाता, उससे मिली संख्या आपके अगले रन के लिए तुलना का एक बिंदु भर है, इससे ज़्यादा कुछ नहीं। आधा डेटाबेस, डेटा का दसवाँ हिस्सा, कोई दूसरा ट्रैफ़िक नहीं, अलग instance size। उस आँकड़े को क्षमता बताकर पेश करना ही वह तरीका है जिससे टीमें लॉन्च वाले दिन उस संख्या से चौंक जाती हैं जिसे वे माप चुकी मान रही थीं।
दूसरी दिशा है टेस्ट के पास हो जाने को सेहत का सबूत मान लेना। अगर रन ने सिर्फ़ status codes पर assertions लगाई थीं, तो आपने बस इतना मापा है कि सर्विस लोड के तहत जल्दी जवाब लौटाती है — और जब कोई query खाली set लौटा रही हो, तो वह यह काम बहुत ही कुशलता से करेगी। requests के एक sample पर body assertions चालू कर दीजिए, और वही रन आपको कुछ बताने लगता है।
हर बदलाव पर शुद्धता जाँचें
लोड टेस्टिंग की जगह किसी schedule पर या रिलीज़ से पहले है। शुद्धता की जगह हर pull request पर है, क्योंकि regression को ठीक करना तभी सबसे सस्ता पड़ता है।
GitHub App एक webhook है जिसे आप TestSprite dashboard में सेट करते हैं। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी repository में कुछ नहीं बदलता।
GitHub Actions इस step को आपके अपने workflow के भीतर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।
लोड रन के इर्द-गिर्द TestSprite कहाँ फिट होता है
TestSprite उस शुद्धता वाली परत को सँभालता है जिससे क्षमता की संख्या का कोई मतलब बनता है। यह API को उस व्यवहार के मुक़ाबले आज़माता है जिसकी आप उम्मीद करते हैं — boundary और authorization cases समेत — और यह रिपोर्ट करता है कि असल में क्या लौटा, न कि सिर्फ़ कितनी तेज़ी से।
Coverage चल रही सर्विस पर एक discovery pass और आपके पास जो भी specification हो, उससे जनरेट होता है, इसलिए अटपटे inputs भी बिना किसी के लिखे शामिल हो जाते हैं। Auto-Authentication पूरे रन के दौरान sessions ज़िंदा रखता है, Dynamic Variables calls के बीच values ले जाता है, Dependency Chains हर case की ज़रूरत और उसके नतीजे से execution का क्रम तय करता है, और Auto-Cleanup ठीक वही हटाता है जो रन ने बनाया था।
इसका फ़ायदा यह है कि आपके performance काम के नीचे एक ज़मीन बन जाती है: throughput मापने में एक दिन लगाने से पहले आपको पता होता है कि endpoint सही चीज़ लौटाता है। लगातार बनी रहने वाली concurrency आपके load generator के ही ज़िम्मे रहती है, और दोनों अलग-अलग रफ़्तार पर चलते हैं, एक-दूसरे में दख़ल दिए बिना।
क्या TestSprite लोड टेस्टिंग करता है?
नहीं। यह शुद्धता की जाँच करता है, boundary cases समेत। लगातार बनी रहने वाली concurrency के तहत क्षमता के लिए एक dedicated लोड टूल चाहिए।
क्या हम लोड टेस्ट में response bodies पर assertions लगा सकते हैं?
ज़्यादातर लोड टूल इसे सपोर्ट करते हैं और कम ही टीमें इसे चालू करती हैं, क्योंकि इससे generator का throughput घटता है। इसे सारी requests के बजाय उनके एक sample पर करना ठीक रहता है।
पहले क्या आता है?
शुद्धता। जो endpoint गलत चीज़ लौटाता है, उसकी लोड टेस्टिंग एक भरोसे भरी संख्या देती है जो किसी चीज़ के बारे में कुछ नहीं बताती।
हमें कितनी बार लोड टेस्ट करना चाहिए?
रिलीज़ से पहले और architecture में बदलाव के बाद। लगातार लोड टेस्टिंग महँगी पड़ती है और इन मौक़ों के बीच शायद ही कुछ नया बताती है।
और CI में लोड टेस्टिंग का क्या?
smoke जितने आकार की लोड जाँच काम कर सकती है। CI में पूरी क्षमता की टेस्टिंग का मतलब आम तौर पर या तो कोई बेमतलब लोड लेवल होता है या बहुत धीमी pipeline।
तेज़ और गलत, फिर भी गलत ही है।
API लोड टेस्टिंग क्षमता का जवाब देती है। यह इसका जवाब नहीं देती कि responses सही थे या नहीं, और सिर्फ़ status codes जाँचने वाला लोड टेस्ट तब भी पास हो जाएगा जब API कुछ भी काम का न लौटा रही हो। क्षमता के लिए dedicated टूल इस्तेमाल करें, शुद्धता की जाँच अलग से करें, और शुद्धता पहले करें।