detail description jmeter components
जेमीटर घटकों की समीक्षा (भाग- II):
=> यह JMeter प्रशिक्षण श्रृंखला का हिस्सा है। इस श्रृंखला के सभी ट्यूटोरियल की सूची यहां देखें ।
आशा है आप सब जरूर गए होंगे JMeter परिचय और स्थापना अब तक। जैसा कि हम श्रृंखला में अगले एक के साथ जारी रखते हैं, यह अत्यधिक अनुशंसा की जाती है कि आप सभी को जेमीटर स्थापित करना चाहिए और कंधे से कंधा मिलाकर अभ्यास करना चाहिए।
इस ट्यूटोरियल में, पाठक अपने आप से परिचित होंगे JMeter के सभी घटकों और परीक्षण योजना में उनका उपयोग कैसे करें ऑटो (एप्लिकेशन अंडर टेस्ट) का परीक्षण करने के लिए सभी संभावित प्रदर्शन परीक्षण परिदृश्यों को कवर करने के लिए।
Jmeter के तत्वों को पिछले लेख में सूचीबद्ध किया गया था।
आप क्या सीखेंगे:
जेमीटर के घटक
आपके संदर्भ के लिए फिर से नीचे कलमिंग:
- जाँच की योजना
- थ्रेडग्रुप
- सैंपलर
- श्रोताओं
- वर्कबेंच
- इस प्रकार के दावे
- तत्व कॉन्फ़िगर करें
- तर्क नियंत्रक
- घड़ी
जेमीटर के सभी प्रमुख घटक जैसे थ्रेड ग्रुप, सैम्पलर, श्रोताओं और कॉन्फिग एलीमेंट्स को लेख में बाद में विवरण में समझाया गया है।
प्रत्येक घटक और जेमीटर के विशिष्ट मॉड्यूल से उनके संबंध को समझने के लिए कृपया नीचे दिए गए प्रवाह आरेख को देखें।
अब हम Jmeter के प्रत्येक घटक को छूने के लिए उपयोग के मामलों के साथ-साथ यह जानना शुरू करेंगे कि यह कैसे काम करता है और परीक्षक अपने परीक्षण में इन्हें कैसे लागू कर सकते हैं। कृपया ध्यान दें कि हम इस लेख में सभी नमूनों, श्रोताओं को कवर नहीं करेंगे। हम सबसे अधिक उपयोग किए जाने वाले काम करेंगे और अगले लेख में आराम करेंगे जब हम वास्तविक समय परीक्षण योजनाएं बनाएंगे।
जाँच की योजना
जिस तरह सॉफ्टवेयर टेस्टिंग में एक सरल परीक्षण योजना में सभी चरण होते हैं जो स्क्रिप्ट को निष्पादित करते हैं, जेमीटर के टेस्ट प्लान का उद्देश्य एक ही है। एक परीक्षण योजना में शामिल होने वाली हर चीज को एक अनुक्रम में निष्पादित किया जाता है जो परीक्षण योजना में परिभाषित अनुक्रम के नीचे से ऊपर या नीचे है।
टेस्ट प्लान सिर्फ उतना ही सरल हो सकता है, जितना जस्ट थ्रेडग्रुप, सैम्पलर और लिसनर के साथ हो सकता है और जैसे ही आप कॉम्प्लेक्स तत्वों, प्रीप्रोसेसर या कंट्रोलर जैसे अधिक तत्वों को जोड़ना शुरू करते हैं तो यह और अधिक जटिल होने लगता है।
जैसा कि हम सभी जानते हैं कि JMeter वर्चुअल यूज़र्स या थ्रेड्स बनाकर परफॉरमेंस को मापता है जो सर्वर को टेस्ट में हिट करता है जैसे कि वास्तविक उपयोगकर्ता किसी सर्वर को रिक्वेस्ट भेज रहे हैं। इसलिए, प्रत्येक परीक्षण योजना में वर्चुअल उपयोगकर्ता या थ्रेड समूह होना चाहिए क्योंकि हम उन्हें JMeter की शर्तों में कहते हैं।
टेस्ट प्लान के बारे में महत्वपूर्ण बातें:
- दौड़ने से पहले परीक्षण योजना बचाई जानी चाहिए
- Jmeter फ़ाइलों या परीक्षण योजनाओं के रूप में सहेजे जाते हैं। JMX एक्सटेंशन फाइलें
- आप अलग-अलग चयन के रूप में टेस्ट प्लान के कुछ हिस्सों को भी बचा सकते हैं। उदाहरण के लिए, यदि आप श्रोता के साथ HTTP रिक्वेस्ट सैम्पलर को बचाना चाहते हैं, तो आप इसे टेस्ट फ्रैगमेंट के रूप में सहेज सकते हैं ताकि इसे अन्य टेस्ट परिदृश्यों में भी उपयोग किया जा सके
- WorkBench के तत्वों को टेस्ट प्लान के साथ सहेजा नहीं गया है
धागा समूह
थ्रेड ग्रुप उपयोगकर्ताओं का एक समूह है जो सर्वर के परीक्षण के तहत या तो समवर्ती या कुछ पूर्वनिर्धारित अनुक्रम में होगा। टेस्ट प्लान पर राइट क्लिक करके थ्रेड ग्रुप को टेस्ट प्लान में जोड़ा जा सकता है। JMeter सभी 'राइट क्लिक सामान' है, आपको राइट क्लिक पर सभी विकल्प मिलते हैं।
आप अपने खुद के लिए थ्रेड ग्रुप का नाम बदल सकते हैं। बस नाम बदलें और टेस्ट प्लान विंडो के बाहर कहीं भी क्लिक करें, आप देखेंगे कि नाम बदल रहा है।
कृपया थ्रेड समूह जोड़ने के लिए नीचे स्क्रीनशॉट देखें
()ध्यान दें: बढ़े हुए दृश्य के लिए किसी भी छवि पर क्लिक करें)
परीक्षण स्थितियों के अनुसार अपने थ्रेड समूह को कॉन्फ़िगर करना बहुत महत्वपूर्ण है।
उदाहरण के लिए, यदि आप यह जांचना चाहते हैं कि जब वेब उपयोगकर्ता समवर्ती रूप से हिट करता है, तो वेब सर्वर कैसे व्यवहार करता है, आप नीचे थ्रेड समूह सेट कर सकते हैं:
असल में, तीन मुख्य पैरामीटर हैं जिन्हें वास्तविक लोड या वर्चुअल उपयोगकर्ता बनाने के लिए कॉन्फ़िगर किया जाना चाहिए:
- थ्रेड की संख्या (उपयोगकर्ता) - यह आभासी उपयोगकर्ताओं की संख्या को परिभाषित करता है। परीक्षण के उद्देश्य के लिए, हमें केवल सीमित मात्रा में लोड उत्पन्न करना चाहिए क्योंकि एक ही बार में बड़ी मात्रा में उत्पादन करने का मतलब होगा कि बहुत सारे थ्रेड्स का उपभोग करना जिससे अंततः उच्च सीपीयू उपयोग हो सके।
- रैंप अप पीरियड्स - यह क्षेत्र लोड जेनरेशन को नियंत्रित करने के लिए बहुत महत्वपूर्ण है। रैंप अप अवधि ने उस समय की मात्रा को परिभाषित किया जिसमें कुल भार उत्पन्न होगा।
उदाहरण 1:
- इसका मतलब है कि सभी 10 उपयोगकर्ता परीक्षण चलाने के साथ ही सर्वर को समवर्ती रूप से मारेंगे
उदाहरण 2:
- आप सभी ने उपरोक्त स्क्रीनशॉट में 'शेड्यूलर' चेकबॉक्स देखा होगा। यदि आप चाहते हैं कि आपका परीक्षण बाद में एक विशिष्ट समय पर चले तो आप समय निर्धारित कर सकते हैं जैसा कि आप नीचे दिए गए स्क्रीनशॉट में भी देख सकते हैं। इसका मतलब है कि हर 1 सेकंड में एक नया उपयोगकर्ता सर्वर से टकराने लगेगा। भार समवर्ती नहीं होगा बल्कि वेतन वृद्धि में होगा। 10 सेवेंदूसरा, सभी उपयोगकर्ता अनुरोध को हिट करेंगे।
- लूप काउंट - यह निर्धारित करता है कि कितनी बार थ्रेड ग्रुप निष्पादित करेगा। यदि आप हमेशा के लिए चेक बॉक्स की जांच करते हैं तो आपका परीक्षण हमेशा के लिए चलेगा जब तक कि आप इसे मैन्युअल रूप से रोक नहीं देते। इसका उपयोग 'यदि आपका सर्वर कुछ मिनटों के लिए निरंतर लोड पर क्रैश नहीं होता है' जैसी किसी चीज़ का परीक्षण करने के लिए किया जा सकता है।
HTML साक्षात्कार प्रश्न और फ्रेशर्स के उत्तर
सैंपलर
तो, कैसे एक Jmeter जानता है कि किस प्रकार का अनुरोध सर्वर को भेजा गया है ???
- यह सांपला के माध्यम से है। नमूनों को टेस्ट प्लान में जोड़ना होगा क्योंकि यह केवल यह बता सकता है कि जेमीटर को किस सर्वर पर और किसी पूर्वनिर्धारित मापदंडों के साथ जाने की आवश्यकता है या नहीं। अनुरोध HTTP, HTTP (s), FTP, TCP, SMTP, SOAP आदि हो सकते हैं।
नमूनों को केवल थ्रेड समूह में जोड़ा जा सकता है सीधे टेस्ट प्लान के तहत नहीं क्योंकि थ्रेड समूहों को परीक्षण के तहत सर्वर URL के लिए अनुरोध भेजने के लिए एक नमूना का उपयोग करने की आवश्यकता होती है। नमूने को पथ से जोड़ा जा सकता है थ्रेड समूह -> नमूनाकर्ता -> HTTP अनुरोध।
HTTP अनुरोध
ये सर्वरों को भेजे जाने वाले सबसे आम अनुरोध हैं। कहो, उदाहरण के लिए, हम चाहते हैं कि 100 उपयोगकर्ता हिट हों https://www.google.com समवर्ती रूप से, इसे नीचे स्क्रीनशॉट में वर्णित किया जा सकता है:
अनुभव के लिए मावेन साक्षात्कार प्रश्न और उत्तर
- पथ मुख्य वेबसाइट के अंदर नेविगेशन है। उदाहरण के लिए, यदि हम http://www.google.com/gmail को हिट करना चाहते हैं तो हम पथ में '/ Gmail' सेट कर सकते हैं और बाकी समान हैं
- सर्वर नाम में 'www' टाइप न करें
- यदि आप किसी प्रॉक्सी सर्वर का उपयोग कर रहे हैं तो पोर्ट नंबर का उपयोग किया जाता है
- यदि आप अपने सर्वर कनेक्शन समय और प्रतिक्रिया समय पर एक बेंचमार्क रखना चाहते हैं, तो टाइमआउट कनेक्ट और प्रतिक्रिया सेट की जा सकती है। यदि आपका सर्वर कॉन्फ़िगर किए गए से प्रतिक्रिया भेजने में अधिक समय लेता है तो आपका अनुरोध विफल हो जाएगा
- आप अपने अनुरोध के साथ भेजने के लिए मापदंडों को भी कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए: कुछ मामलों में, आपको अपने अनुरोध के साथ प्राधिकरण टोकन भेजने की आवश्यकता हो सकती है, इसलिए आपने उन्हें HTTP अनुरोध में नीचे दिया है:
एफ़टीपी अनुरोध
पथ-> टेस्ट प्लान-> थ्रेड ग्रुप-> सैम्पलर-> एफ़टीपी अनुरोध
एफ़टीपी फ़ाइल स्थानांतरण प्रोटोकॉल के लिए खड़ा है और इसका उपयोग सर्वर से फ़ाइल अपलोड या डाउनलोड करने के लिए किया जाता है। JMeter के थ्रेड्स FTP सर्वरों को वहां से फाइल अपलोड या डाउनलोड करने और प्रदर्शन को मापने के लिए अनुरोध भेजते हैं।
- स्थानीय फ़ाइल वह स्थान है जहाँ आपको डाउनलोड की गई फ़ाइल को सहेजने की आवश्यकता होती है
- यदि आप FTP सर्वर से डाउनलोड कर रहे हैं तो GET विकल्प का उपयोग करें
- यदि आप एफ़टीपी सर्वर पर कोई फ़ाइल अपलोड कर रहे हैं तो उपयोगकर्ता POST विकल्प
हमारे पास बहुत से श्रोता हैं जो तब समाहित होंगे जब हम कुछ वास्तविक परीक्षण योजनाओं से गुजरेंगे, जिसमें समप्लर, श्रोता, विन्यास तत्व आदि शामिल होंगे।
श्रोताओं
इसलिए, अब तक हमने सर्वर पर अनुरोध भेजने वाले कुछ नमूने देखे हैं, लेकिन अभी तक प्रतिक्रिया का विश्लेषण नहीं किया है। प्रदर्शन परीक्षण सभी विभिन्न रूपों में सर्वर प्रतिक्रियाओं का विश्लेषण करने और उसके बाद ग्राहक को प्रस्तुत करने के बारे में है।
श्रोताओं का उपयोग परीक्षण निष्पादन के परिणामों को प्रदर्शित करने के लिए किया जाता है ताकि परीक्षकों को आँकड़ों का पता चल सके। जेमीटर में हमारे लगभग 15 श्रोता हैं लेकिन ज्यादातर इस्तेमाल किए गए टेबल, ट्री और ग्राफ हैं।
तालिका में परिणाम देखें:
यह श्रोताओं का सबसे अधिक इस्तेमाल किया जाने वाला और आसानी से समझा जाने वाला रूप है। यह कुछ महत्वपूर्ण प्रदर्शन मापदंडों के साथ तालिका के रूप में परिणाम प्रदर्शित करता है।
श्रोताओं को सीधे परीक्षण योजना के तहत या एक नमूना के तहत जोड़ा जा सकता है। अंतर यह है, जब आप एक नमूना के तहत श्रोता को जोड़ते हैं, तो यह केवल उस नमूने के परिणाम दिखाएगा। यदि हम सीधे परीक्षण योजना के तहत नमूना जोड़ते हैं, तो यह पदानुक्रम में सभी नमूना के लिए परिणाम प्रदर्शित करता है।
आपके संदर्भ के लिए नीचे स्क्रीनशॉट:
आप नीचे दिखाए गए कुछ परिणाम देख सकते हैं:
- विलंब : वह समय है जब सूचना का पहला टुकड़ा प्राप्त होता है यानी डेटा का पहला बाइट प्राप्त होता है
- कनेक्ट समय : यह सर्वर के साथ संबंध स्थापित करने के लिए लिया गया समय है
- नमूने की अवधि : यह पूर्ण डेटा प्राप्त करने के लिए लिया गया समय है
- नमूना - नमूना संख्या की अनुक्रम
- बाइट्स - प्राप्त आंकड़ों का आकार।
पेड़ में परिणाम देखें:
यह एक और सबसे अधिक इस्तेमाल किया जाने वाला श्रोता है और अनुरोध और प्रतिक्रिया के साथ विस्तृत जानकारी प्रदान करता है। एक Json, XML, पाठ, RegEx देखने के अलावा प्रतिक्रिया में प्रदान किया गया HTML पृष्ठ भी देख सकता है।
यह बहुत उपयोगी है क्योंकि परीक्षण सुनिश्चित करने के लिए प्राप्त की गई प्रतिक्रिया पर परीक्षक जोर डाल सकते हैं। प्रतिक्रिया वांछित नहीं होने पर भी जेमीटर परिणाम 'पास' दिखाते हैं।
उदाहरण के लिए: कहते हैं, हमने किसी भी वेबसाइट पर HTTP अनुरोध मारा है www.xyz.com और इसके जवाब में हम उम्मीद करते हैं कि हम XYZ या सरल शब्दों में कहें, जब हम इस पेज कंपनी के होम पेज को हिट करते हैं तो इसके नाम से खुलता है। यदि हम जोर डालते हैं, तो Jmeter अभी भी परिणाम प्रदर्शित करेगा क्योंकि हिट सर्वर पर चला गया है।
परिणामों का प्रारूप जानने के लिए कृपया नीचे देखें:
प्रतिक्रिया में HTML पृष्ठ देखने के लिए, बाएं फलक में ड्रॉप-डाउन पर क्लिक करें और फिर 'HTML' चुनें, प्रतिक्रिया टैब पर नेविगेट करें और उस पृष्ठ की जांच करें जिसे सर्वर की प्रतिक्रिया के रूप में लौटाया गया है।
काम बेंच
एक कार्यक्षेत्र एक ऐसी जगह है जहां आप उन तत्वों को संग्रहीत कर सकते हैं जो आपके वर्तमान परीक्षण योजना में उपयोग में नहीं हैं लेकिन जो बाद में इसमें चिपकाए जा सकते हैं। जब आप JMeter फ़ाइल सहेजते हैं, तो कार्यक्षेत्र में मौजूद घटक स्वचालित रूप से सहेजे नहीं जाते हैं। आपको उन्हें राइट क्लिक करके अलग से सहेजना होगा और 'सेव एज़' विकल्प चुनें।
आप सभी सोच रहे होंगे कि कार्यक्षेत्र का क्या उपयोग है, वैसे भी किसी भी घटक को सीधे Jmeter के टेस्ट प्लान में जोड़ना आसान है।
कार्यक्षेत्र होने का कारण यह था कि उपयोगकर्ता कुछ प्रयोग कर सकता है और नए परिदृश्यों को आज़मा सकता है। जैसा कि हम पहले से ही जानते हैं कि कार्यक्षेत्र में तत्वों को बचाया नहीं जाता है, इसलिए उपयोगकर्ता सचमुच कुछ भी उपयोग कर सकता है और फिर फेंक सकता है। लेकिन, कुछ 'नॉन-टेस्ट कंपोनेंट्स' हैं जो केवल वर्कबेंच में उपलब्ध हैं।
वे यहाँ सूचीबद्ध हैं:
- HTTP मिरर सर्वर
- HTTP (s) टेस्ट स्क्रिप्ट रिकॉर्डर
- संपत्ति प्रदर्शन
HTTP (s) टेस्ट स्क्रिप्ट रिकॉर्डर JMeter में प्रयुक्त सबसे महत्वपूर्ण गैर-टेस्ट एलिमेंट है। यह स्क्रिप्ट को रिकॉर्ड करने और फिर प्रत्येक लेनदेन के लिए लोड को कॉन्फ़िगर करने में परीक्षकों की मदद करता है।
Jmeter केवल सर्वर को भेजे गए अनुरोध को रिकॉर्ड करता है। QTP / सेलेनियम के 'रिकॉर्ड और प्ले' कार्यक्षमता के साथ भ्रमित न हों। सभी अनुरोध दर्ज किए गए हैं और परीक्षक व्यवहार को देखने के लिए उन पर वांछित भार लागू कर सकते हैं।
यह तत्व उन परिदृश्यों के लिए बहुत महत्वपूर्ण है जहां परीक्षकों को यह पता नहीं है कि उनके आवेदन से सभी अनुरोध क्या हो रहे हैं। परीक्षण के तहत आवेदन को रिकॉर्ड करने के लिए वे एचटीपी (एस) स्क्रिप्ट रिकॉर्डर का उपयोग कर सकते हैं।
मोबाइल एप्लिकेशन के प्रदर्शन का परीक्षण इस तरह से किया जा सकता है कि जेएमटर प्रॉक्सी स्थापित करके और फिर उन अनुरोधों को रिकॉर्ड किया जाए जो हमारे मोबाइल ऐप सर्वर पर भेजते हैं। मोबाइल प्रदर्शन परीक्षण के लिए चरण दर चरण प्रक्रिया अगले लेख में बताई जाएगी।
इस प्रकार के दावे
अब तक, हमने कवर किया है कि कैसे JMeter सर्वर को हिट करता है और श्रोताओं के माध्यम से कैसे प्रतिक्रियाएं प्रदर्शित की जाती हैं। यह सुनिश्चित करने के लिए कि प्राप्त की गई प्रतिक्रिया सही है और अपेक्षा के अनुसार, हमें जोर जोड़ने की आवश्यकता है। दावे केवल सत्यापन हैं जो हमें परिणामों की तुलना करने के लिए प्रतिक्रियाओं पर डालने की आवश्यकता है।
नीचे आमतौर पर उपयोग किए जाने वाले दावे हैं:
- प्रतिक्रिया प्रतिक्रिया
- अवधि का जोर
- आकार का जोर
- XML का जोर
- HTML का जोर
प्रतिक्रिया प्रतिक्रिया
रिस्पांस असेसमेंट में, हम अपने स्वयं के पैटर्न स्ट्रिंग्स को जोड़ सकते हैं और फिर एक सर्वर से प्राप्त प्रतिक्रियाओं के साथ उनकी तुलना कर सकते हैं। उदाहरण के लिए, आप सभी जानते हैं कि प्रतिक्रिया कोड 200 है जब कोई भी अनुरोध कुछ प्रतिक्रिया सफलतापूर्वक देता है। इसलिए, यदि हम पैटर्न स्ट्रिंग 'रिस्पांस कोड = 202' जोड़ते हैं, तो परीक्षण का मामला विफल होना चाहिए।
प्रतिक्रिया कोड अभिकथन जोड़ने के लिए कृपया नीचे स्क्रीनशॉट देखें।
अब, जब परीक्षण चलता है, तो यह लाल रंग के साथ परिणाम दिखाता है जो दर्शाता है कि अभिकथन परिणाम विफल हैं।
अवधि का जोर
अवधि अभिकथन बहुत महत्वपूर्ण है और यह पुष्टि करता है कि सर्वर ने निश्चित समय के भीतर जवाब दिया। इसका उपयोग उन परिदृश्यों में किया जा सकता है जहां हमें 100 अनुरोधों का नमूना लेना होगा और यह सुनिश्चित करना होगा कि हर बार प्रतिक्रिया बेंचमार्क सीमा के भीतर प्राप्त हो।
मामला : 10 उपयोगकर्ता समवर्ती रूप से 'google.com' सर्वर से टकरा रहे हैं और अवधि अभिकथन 1000ms पर सेट है। कृपया स्क्रीनसे नीचे देखें:
यदि XML डेटा में एक्सएमएल डॉक्यूमेंट सही है, तो XML एसेर्शन मान्य होता है और एचटीएमएल अभिकथन सर्वर से प्राप्त रिस्पॉन्स के HTML सिंटैक्स की पुष्टि करता है।
तत्वों को कॉन्फ़िगर करें
सर्वर को भेजे गए अनुरोधों को कुछ कॉन्फिग तत्वों का उपयोग करके आगे पैरामीटरेट किया जा सकता है जिन्हें वास्तविक अनुरोध से पहले निष्पादित किया जाता है। इसका एक सरल उदाहरण एक CSV फ़ाइल से एक चर के मूल्यों को पढ़ना हो सकता है जिसके लिए CSV डेटा सेट कॉन्फ़िगरेशन का उपयोग किया जाता है।
नीचे वेब और मोबाइल एप्लिकेशन के प्रदर्शन परीक्षण में उपयोग किए जाने वाले कुछ महत्वपूर्ण कॉन्फ़िगरेशन तत्व हैं
- CSV डेटा सेट कॉन्फ़िगरेशन।
- उपयोगकर्ता परिभाषित चर
- HTTPS अनुरोध डिफ़ॉल्ट
- HTTPS कैश मैनेजर
- HTTPS कुकी प्रबंधक
CSV डेटा सेट कॉन्फ़िगरेशन
CSV डेटा सेट कॉन्फिगर, Jmeter को प्रत्येक अलग-अलग अनुरोध में अलग-अलग पैरामीटर पास करने के बजाय CSV फ़ाइल से कुछ मापदंडों के मूल्यों को चुनने में मदद करता है। उदाहरण के लिए, अगर हमें उपयोगकर्ताओं और पासवर्ड के एक अलग सेट के साथ लॉगिन कार्यक्षमता का परीक्षण करने की आवश्यकता है, तो हम एक CSV फ़ाइल में दो कॉलम बना सकते हैं और वहां मान दर्ज कर सकते हैं ताकि JMeter सर्वर पर भेजे गए प्रत्येक अनुरोध के लिए एक चुन सके।
नीचे भारत में विभिन्न शहरों के लिए मौसम एपीआई का परीक्षण करने के लिए सीएसवी डेटा सेट का उपयोग करने का प्रवाह है।
- परीक्षण योजना में CSV डेटा सेट कॉन्फिग तत्व जोड़ना
- CSV फ़ाइल बनाना
- अनुरोध पैरामीटर में परिवर्तनशील चर। APPID पैरामीटर को गतिशील रूप से उत्पन्न किया जा सकता है http://openweathermap.org/appid
- परीक्षण चलाना और परिणाम देखना।
उपयोगकर्ता परिभाषित चर
यह जेमीटर को पूर्व-परिभाषित चर से मान लेने में मदद करता है। उदाहरण के लिए, समर्थन जिसमें आपको एक परीक्षण योजना बनाने की आवश्यकता होती है जिसमें आपको एक ही URL पर कई HTTP अनुरोधों को जोड़ने की आवश्यकता होती है और एक परिदृश्य हो सकता है जिसमें ग्राहक इसे बाद में कुछ अलग URL पर माइग्रेट करने की योजना बनाता है। प्रत्येक अनुरोध में URL अपडेट करने से बचने के लिए हम JMeter को यूडीवी (यूजर डिफाइंड वेरिएबल) से URL लेने के लिए कह सकते हैं जिसे बाद में अपडेट किए गए URL के सभी अनुरोधों को संभालने के लिए अपडेट किया जा सकता है।
इसलिए, प्रत्येक अनुरोध में URL अपडेट करने से बचने के लिए, हम JMeter को एक UDV (उपयोगकर्ता निर्धारित चर) से URL लेने के लिए कह सकते हैं, जिसे बाद में अपडेट किए गए URL के सभी अनुरोधों को संभालने के लिए अपडेट किया जा सकता है।
HTTP रिक्वेस्ट डिफॉल्ट्स
यह कॉन्फ़िगर तत्व https अनुरोधों के डिफ़ॉल्ट मूल्यों को निर्दिष्ट करने के लिए बहुत उपयोगी है। आपको अधिक मार्गदर्शन करने के लिए, एक उदाहरण लें जहां हमें Google सर्वर पर 50 अलग-अलग अनुरोधों को हिट करने की आवश्यकता है। इस परिदृश्य में, यदि हम एक HTTP अनुरोध डिफ़ॉल्ट जोड़ते हैं, तो हमें सर्वर नाम, पथ या पोर्ट नंबर, कनेक्शन जैसे किसी भी अन्य गुणों को निर्दिष्ट करने की आवश्यकता नहीं है। समय बाहर गुण। HTTP रिक्वेस्ट डिफॉल्ट कॉन्फिग तत्व में जो कुछ भी निर्दिष्ट किया गया है वह सभी HTTP रिक्वेस्ट से विरासत में मिला है।
इस परिदृश्य में, यदि हम एक HTTP रिक्वेस्ट डिफॉल्ट जोड़ते हैं, तो हमें एक सर्वर नाम, पथ या पोर्ट नंबर जैसे किसी भी अन्य गुणों को निर्दिष्ट करने की आवश्यकता नहीं है, गुणों को हटा दें। HTTP रिक्वेस्ट डिफॉल्ट कॉन्फिग तत्व में जो कुछ भी निर्दिष्ट किया गया है वह सभी HTTP रिक्वेस्ट से विरासत में मिला है।
सर्वश्रेष्ठ मुफ्त साइटें मोबाइल फोनों के लिए देखने के लिए
कृपया नीचे देखें कि HTTP रिक्वेस्ट डिफॉल्ट को कैसे जोड़ें और सर्वर और पथ को निर्दिष्ट करें।
HTTP कैश प्रबंधक तथा HTTP कुकी प्रबंधक JMeter को वास्तविक समय ब्राउज़र के रूप में व्यवहार करने के लिए उपयोग किया जाता है। HTTP कैश प्रबंधक प्रत्येक अनुरोध के बाद कैश को साफ़ कर सकता है जबकि दूसरा कुकीज़ सेटिंग्स को प्रबंधित कर सकता है।
तर्क नियंत्रक और टाइमर
तर्क नियंत्रक और टाइमर लेनदेन के प्रवाह को नियंत्रित करने में मदद करते हैं। टाइमर किसी भी सर्वर का परीक्षण करने की आवश्यकता होने पर प्रत्येक थ्रेड में देरी सुनिश्चित करता है। उदाहरण के लिए, अगर HTTP अनुरोध पूरा होने के बाद हमें 5 सेकंड तक प्रतीक्षा करने के लिए FTP अनुरोध की आवश्यकता है, तो हम वहां टाइमर जोड़ सकते हैं।
तर्क नियंत्रकों का उपयोग अनुरोधों के प्रवाह को परिभाषित करने के लिए किया जाता है जो सर्वर को भेजे जाते हैं। यह आपको प्रत्येक मॉड्यूल के लिए अनुरोधों को अलग से स्टोर करने दे सकता है जैसे लॉगिन और लॉगआउट।
निष्कर्ष
अब तक, आप सभी को JMeter के घटकों से परिचित होना चाहिए और इसका उपयोग करने का प्रयास करना चाहिए और कुछ मुद्दों का सामना करना चाहिए। अगले लेख में, हम गतिशीलता डोमेन को कवर करने वाले कुछ वास्तविक समय के प्रदर्शन परीक्षण परिदृश्यों को कवर करेंगे ताकि आप सभी को JMeter पर अधिक ज्ञान प्राप्त हो सके।
बने रहें! अगला लेख आपको अपने अनुरोधों को प्रबंधित करने के साथ-साथ परिणामों का विश्लेषण करने और प्रदर्शन परीक्षण के मानदंड की तुलना करने में मदद करेगा।
=>भाग- III पढ़ना जारी रखें: JMeter प्रोसेसर और नियंत्रक
=> JMeter ट्यूटोरियल के लिए यहां क्लिक करें: पूरा मुफ्त प्रशिक्षण JMeter पर (20+ वीडियो)
अनुशंसित पाठ
- उदाहरण के साथ JMeter सहसंबंध कैसे प्राप्त करें
- जेमीटर टेस्ट प्लान और वर्कबेंच
- JMeter में एफ़टीपी अनुरोध के साथ कार्य करना
- शीर्ष 5 JMeter प्लगइन्स और उनका उपयोग कैसे करें (उदाहरणों के साथ)
- जेमिटर टाइमर: लगातार, बीनशेल और गासियन रैंडम टाइमर
- JMeter में HTTP रिक्वेस्ट के साथ कार्य करना
- Jmeter नियंत्रकों भाग 1
- Jmeter नियंत्रकों भाग 2