टिड्डी के साथ लोड परीक्षण। भाग ३

टिड्डे तनाव परीक्षण उपकरण पर अंतिम लेख। आज मैं उन टिप्पणियों को साझा करूंगा जो इस प्रक्रिया में जमा हुए हैं। हमेशा की तरह, वीडियो संलग्न है।

भाग 1 - टिड्डी के साथ परीक्षण
भाग 2 - उन्नत परिदृश्य

प्राधिकरण

टिड्डी के साथ अपना पहला परीक्षण लिखते समय, मुझे एक संसाधन में लॉग इन करने की आवश्यकता के साथ सामना करना पड़ा, एक प्राधिकरण टोकन प्राप्त करना, जिसे मैं बाद में लोड परीक्षण के लिए उपयोग करूंगा। फिर सवाल तुरंत उठा - यह कैसे करना है, क्योंकि उपकरण को एक संसाधन में सभी अनुरोध भेजने के लिए तेज किया जाता है, जिसे हम परीक्षण शुरू करते समय कंसोल में इंगित करते हैं। समस्या के कई समाधान हैं:

• परीक्षण किए गए संसाधन पर प्राधिकरण को अक्षम करना - यदि संभव हो तो
• अग्रिम में एक टोकन उत्पन्न करें और लॉन्च करने से पहले परीक्षण कोड में डाल दें - सबसे कमजोर विकल्प, प्रत्येक लॉन्च पर मैन्युअल श्रम की आवश्यकता होती है, लेकिन कुछ दुर्लभ मामलों में मौजूद होने का अधिकार
• अनुरोध लायब्रेरी का उपयोग करके एक अनुरोध भेजें और प्रतिक्रिया से एक टोकन प्राप्त करें - अच्छा, वाक्यविन्यास समान है

मैंने तीसरा विकल्प चुना। नीचे मैं पहले लेख से एक टोकन प्राप्त करने की विभिन्न संभावनाओं के साथ एक लाल उदाहरण प्रस्तुत करता हूं। Google.com एक प्राधिकरण सर्वर के रूप में कार्य करेगा
जैसा कि कोई टोकन नहीं है, मुझे सबसे सरल मान मिलेगा

from locust import HttpLocust, TaskSet, task import requests class UserBehavior(TaskSet): def on_start(self): response = requests.post("http://mysite.sample.com/login", {"username": "ellen_key", "password": "education"}) # get "token" from response header self.client.headers.update({'Authorization': response.headers.get('Date')}) # get "token" from response cookies self.client.cookies.set('Authorization', response.cookies.get('NID')) # get "token" from response body self.client.headers.update({'Authorization': str(response.content.decode().find('google'))}) 

जैसा कि आप उदाहरण से देख सकते हैं, काम शुरू करने से पहले, उपयोगकर्ता एक तृतीय-पक्ष सर्वर को एक अनुरोध भेजता है और प्रतिक्रिया को संसाधित करता है, डेटा को हेडर या कुकीज़ में रखता है।

हेडर

अनुरोध हेडर के साथ काम करते समय, विचार करने के लिए कई महत्वपूर्ण बारीकियां हैं।
प्रत्येक अनुरोध के लिए अलग-अलग, आप अपने स्वयं के सेट को इस प्रकार निर्दिष्ट कर सकते हैं

 self.client.post(url='/posts', data='hello world', headers={'hello': 'world'}) 

जब उपरोक्त उदाहरण निष्पादित किया जाता है, तो हैलो हेडर क्लाइंट सत्र के मौजूदा हेडर में जोड़ा जाएगा, लेकिन केवल इस अनुरोध में निम्नलिखित सभी में नहीं होगा। शीर्षक को स्थिर रखने के लिए, आप इसे सत्र में जोड़ सकते हैं:

 self.client.headers.update({'aaa': 'bbb'}) 

एक और दिलचस्प अवलोकन - यदि अनुरोध में हम उस हेडर को निर्दिष्ट करते हैं जो पहले से ही सत्र में है - इसे ओवरराइट किया जाएगा, लेकिन केवल इस अनुरोध पर। इसलिए आप गलती से किसी महत्वपूर्ण चीज को पोंछने से डर नहीं सकते।

लेकिन अपवाद हैं। यदि हमें मल्टीपार्ट फॉर्म भेजने की आवश्यकता है, तो अनुरोध स्वचालित रूप से एक कंटेंट-टाइप हेडर उत्पन्न करेगा, जो फॉर्म डेटा विभाजक को इंगित करेगा। यदि हम हेडर तर्क का उपयोग करके हेडर को फिर से लिखने के लिए मजबूर करते हैं, तो अनुरोध विफल हो जाएगा क्योंकि फॉर्म को सही तरीके से संसाधित नहीं किया जा सकता है।

यह भी ध्यान देने योग्य है कि सभी हेडर जरूरी तार हैं। यदि आप संख्या निर्दिष्ट करने का प्रयास करते हैं, उदाहरण के लिए { try आआ ’: 123} , तो अनुरोध नहीं भेजा जाएगा और कोड एक अमान्य हैडर अपवाद फेंक देगा

वितरित परीक्षण

वितरित परीक्षण के लिए, टिड्डी कई सीएलआई तर्क प्रदान करती है: --मास्टर और - स्लेव , स्पष्ट रूप से भूमिकाओं को परिभाषित करने के लिए। इस मामले में, मास्टर वाली मशीन लोड का अनुकरण नहीं करेगी, बल्कि केवल आंकड़े एकत्र करेगी और काम का समन्वय करेगी। आइए, विभिन्न कंसोलों में निम्नलिखित कमांड चलाकर हमारे परीक्षण सर्वर और वितरित मोड में कई सत्रों को चलाने की कोशिश करें:

 json-server --watch sample_server/db.json locust -f locust_files\locust_file.py --master --host=http://localhost:3000 locust -f locust_files\locust_file.py --slave --master-host=localhost locust -f locust_files\locust_file.py --slave --master-host=localhost 

ब्राउज़र में टिड्डी खोलने से ( लोकलहोस्ट: 8089 ), आप देख सकते हैं कि ऊपरी दाएं कोने में हमारे पास मशीनों की संख्या है जो भार ले जाएगी

UI के बिना परीक्षण

जब सभी परीक्षण लिखे और डीबग किए जाते हैं, तो उन्हें प्रतिगमन स्वचालित परीक्षण में शामिल करना और समय-समय पर परिणामों की जांच करना अच्छा होगा। निम्न आदेश का उपयोग करके, आप UI के बिना टिड्डी परीक्षण चला सकते हैं:

 locust -f locust_files\locust_file.py --host=http://localhost:3000 --no-web -c 10 -r 2 --run-time 1m --csv=test_result 

जहाँ

• - कोई वेब - एक तर्क जो आपको यूआई के बिना परीक्षण चलाने की अनुमति देता है
• -सी 10 - उपयोगकर्ताओं की अधिकतम संख्या
• -r 2 - उपयोगकर्ता की वृद्धि प्रति सेकंड
• - समय-समय 1 मी - परीक्षण निष्पादन समय (1 मिनट)
• --csv = test_result - परीक्षण पूरा होने के बाद, परिणाम के साथ 2 सीएसवी फाइलें वर्तमान फ़ोल्डर में बनाई जाएंगी, उनके नाम test_result से शुरू होते हैं

अंतिम तथ्य, अवलोकन और निष्कर्ष

वितरित परीक्षण को प्रतिगमन परीक्षण के साथ जोड़ा जा सकता है - यह सुनिश्चित करने के लिए कि लोड के लिए सभी नोड्स शुरू हो गए हैं, आप मास्टर पर तर्क - डेक्सटेक्ट-स्लेव्स = 2 जोड़ सकते हैं, जिस स्थिति में परीक्षण केवल तभी शुरू होगा जब कम से कम 2 नोड्स शुरू हो गए हों।

मुझे एक-दो बार एक स्थिति में आया - परीक्षण किया गया संसाधन केवल HTTPS पर काम करता है, जबकि प्रमाणपत्र ग्राहक द्वारा तैयार किया जाता है और ऑपरेटिंग सिस्टम इसे संदिग्ध के रूप में चिह्नित करता है। परीक्षणों के सफलतापूर्वक काम करने के लिए, आप उन सभी प्रश्नों के लिए एक तर्क जोड़ सकते हैं जो उदाहरण के लिए सुरक्षा जांच को नजरअंदाज करते हैं:

 self.client.get("/posts", verify=False) 

चूंकि मैं हमेशा सुनिश्चित नहीं कर सकता हूं कि परीक्षण किस वातावरण में चलाए जाएंगे, मैं हमेशा इस तर्क का संकेत देता हूं।

वह सब मैं साझा करना चाहता था। अपने लिए, मैंने अनुरोधों को बनाने और सर्वर प्रतिक्रियाओं को संसाधित करने में महान परीक्षण क्षमताओं और परिवर्तनशीलता के साथ एक सरल और सुविधाजनक उपकरण की खोज की। अंत तक पढ़ने के लिए धन्यवाद।