JMeter किन चीज़ों में बेहतरीन है
समवर्ती लोड पैदा करना। थ्रेड ग्रुप, ramp-up, डिस्ट्रिब्यूटेड जेनरेटर। इसे इसी के लिए बनाया गया था और यह आज भी सबसे बेहतरीन मुफ़्त विकल्पों में से एक है।
प्रोटोकॉल की व्यापकता। HTTP से कहीं आगे, जो मैसेजिंग और डेटाबेस लेयर वाले एंटरप्राइज़ सिस्टम के लिए मायने रखता है।
पहले से इंस्टॉल होना। तकनीकी ख़ूबी नहीं, फिर भी टीमों के इसे इस्तेमाल करने की एक असली वजह।
JMeter API टेस्टिंग कहाँ असहज हो जाती है
टेस्ट प्लान XML होते हैं
पुल रिक्वेस्ट में किसी बदलाव की समीक्षा करना लगभग नामुमकिन है।
किसी .jmx फ़ाइल में मर्ज कॉन्फ़्लिक्ट अपने आप में एक अलग ही किस्म की तकलीफ़ हैं।
assertion डिफ़ॉल्ट रूप से सतही होते हैं
रिस्पॉन्स कोड और सबस्ट्रिंग मैचिंग आम मामलों को संभाल लेते हैं, उससे ज़्यादा कुछ नहीं।
कुछ भी संरचनात्मक जाँचना हो तो स्क्रिप्टिंग एलिमेंट लगाना पड़ता है।
स्टेट मैन्युअल है
एक्सट्रैक्टर, वेरिएबल और कंट्रोलर, सब हाथ से जोड़े जाते हैं।
डिपेंडेंसी ग्राफ़ कहीं घोषित नहीं होता, वह प्लान की संरचना में ही रहता है।
वह बँटवारा जो काम करता है
क्षमता के सवाल के लिए JMeter को रखिए: लगातार समवर्तीता में सर्विस कैसा बर्ताव करती है, लेटेंसी कहाँ बिगड़ती है, सबसे पहले क्या टूटता है। वह इसी के लिए है, और यहाँ कहीं भी उसे बदल देने की बात नहीं कही जा रही।
फ़ंक्शनल शुद्धता को कहीं ऐसी जगह ले जाइए जो सेशन, कैप्चर की गई वैल्यू, क्रम और क्लीनअप को आपके जोड़े हुए एलिमेंट नहीं, बल्कि प्रोडक्ट का हिस्सा मानती हो। इन चारों का विवरण यहाँ है: API टेस्टिंग डॉक्युमेंटेशन.
एक काम जो JMeter में वैसे भी करने लायक है
अपने लोड प्लान में body assertion जोड़िए, चाहे कुछ ही रिक्वेस्ट के नमूने पर। जो लोड टेस्ट सिर्फ़ स्टेटस कोड जाँचता है, वह साफ़-सुथरा रन दिखाता रहेगा जबकि सर्विस खाली नतीजे लौटा रही होगी; और तेज़ पर ग़लत सबसे बुरा नतीजा है, क्योंकि उसकी पड़ताल कोई नहीं करता।
फ़ंक्शनल लेयर को जगह पर बिठाना
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोकल इंस्टॉल नहीं चाहते, उनके लिए डैशबोर्ड वही सब कर देता है, और पूरा कमांड सेट यहाँ मिलेगा: CLI रिपॉज़िटरी.
.jmx वाली समस्या, सीधे शब्दों में
JMeter में फ़ंक्शनल कवरेज समय के साथ जो बिगड़ती जाती है, उसकी वजह assertion नहीं, फ़ाइल फ़ॉर्मैट है — और क्यों, इस पर ठोस बात करना ज़रूरी है।
टेस्ट प्लान GUI से बनी XML होती है। एक assertion बदलने वाली पुल रिक्वेस्ट खोलिए तो diff में एलिमेंट का बदला हुआ क्रम और जनरेट किए गए आइडेंटिफ़ायर दिखते हैं, यानी समीक्षा भरोसे का मामला बन जाती है। एक ही हफ़्ते में दो लोग एक ही प्लान में बदलाव करें तो ऐसा मर्ज कॉन्फ़्लिक्ट बनता है जिसे पढ़कर सुलझाने से आसान एक पक्ष को हटा देना होता है। और चूँकि समीक्षा व्यावहारिक नहीं रह जाती, प्लान में ऐसे बदलाव जमा होते जाते हैं जिन्हें किसी ने देखा ही नहीं।
यह एक असली लागत है और जब प्लान का मालिक एक ही व्यक्ति हो तो यह दिखाई नहीं देती — और ज़्यादातर JMeter सूट ठीक इसी हालत में बनते हैं।
अलग-अलग रफ़्तार
लोड, रिलीज़ से पहले और आर्किटेक्चर में बदलाव के बाद। शुद्धता, हर पुल रिक्वेस्ट पर, क्योंकि रिग्रेशन ठीक करना तभी सबसे सस्ता होता है।
GitHub App एक webhook है जिसे आप TestSprite डैशबोर्ड में सेट करते हैं। यह उसी डिप्लॉयमेंट इवेंट को सुनता है जो आपकी पाइपलाइन पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ नहीं बदलता।
GitHub Actions इस स्टेप को आपके अपने वर्कफ़्लो के अंदर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।
TestSprite लोड प्लान पर से क्या बोझ हटाता है
वह फ़ंक्शनल कवरेज जो सिर्फ़ इसलिए JMeter में आ बसी क्योंकि JMeter पहले से वहाँ था। प्लान एक डिस्कवरी पास और आपके स्पेसिफ़िकेशन से जनरेट होते हैं, एलिमेंट जोड़-जोड़कर बनाने के बजाय सादी भाषा में लिखे जाते हैं, और जनरेट की गई XML में दबे रहने के बजाय पुल रिक्वेस्ट में समीक्षा के लायक रहते हैं।
Auto-Authentication पूरे रन के दौरान सेशन ज़िंदा रखता है, Dynamic Variables एक कॉल से दूसरी कॉल तक वैल्यू ले जाते हैं, Dependency Chains हर केस को क्या चाहिए और वह क्या पैदा करता है, उससे एक्ज़ीक्यूशन का क्रम तय करती हैं, और Auto-Cleanup ठीक वही हटाता है जो रन ने बनाया था। ये वही हिस्से हैं जो आप अभी एक्सट्रैक्टर, वेरिएबल, कंट्रोलर और teardown थ्रेड ग्रुप से ख़ुद बनाते हैं।
आपके लोड प्लान जस के तस रहते हैं, वही काम करते हुए जिसमें JMeter सचमुच बेहतरीन है। फ़ायदा यह है कि शुद्धता की जाँच रिलीज़ से पहले नहीं, हर पुल रिक्वेस्ट पर चलती है, और assertion में हुआ बदलाव ऐसा होता है जिसे कोई दूसरा व्यक्ति पढ़ सके।
क्या JMeter फ़ंक्शनल API टेस्टिंग कर सकता है?
हाँ, पर सहूलियत आपके ख़िलाफ़ है। XML प्लान, सतही डिफ़ॉल्ट assertion और मैन्युअल स्टेट हैंडलिंग — यही इसकी क़ीमत है।
क्या हमें JMeter को हटा देना चाहिए?
लोड के लिए नहीं। जो फ़ंक्शनल कवरेज संयोग से वहाँ पहुँच गई, उसे हटाइए, और लोड प्लान बनाए रखिए।
Taurus या JMeter DSL का क्या?
दोनों लिखने का अनुभव काफ़ी बेहतर बना देते हैं। वे यह नहीं बदलते कि टूल किस चीज़ के लिए अनुकूलित है।
क्या हम दोनों को CI में चला सकते हैं?
हाँ। वे अलग-अलग सवालों के जवाब अलग-अलग रफ़्तार पर देते हैं, और किसी को दूसरे के बारे में जानने की ज़रूरत नहीं।
क्या TestSprite लोड पैदा करता है?
नहीं। यह शुद्धता की पुष्टि करता है, बाउंड्री केस समेत। लगातार समवर्तीता JMeter का इलाक़ा है।
लोड प्लान रखिए, शुद्धता कहीं और ले जाइए।
JMeter API टेस्टिंग इसलिए चलती है क्योंकि JMeter पहले से मौजूद है, इसलिए नहीं कि वह इस काम पर फ़िट बैठता है। क्षमता के लिए उसे रखिए, अपने मौजूदा लोड प्लान में body assertion जोड़िए, और फ़ंक्शनल शुद्धता को कहीं ऐसी जगह रखिए जो सेशन, स्टेट, क्रम और क्लीनअप के लिए बनी हो।