👨🏾‍🔬 👩🏼‍🍳 👩🏽‍🚀 टिड्डी के साथ लोड परीक्षण। भाग २ 🚄 🚴🏻 🤥

मेरे पिछले लेख को पसंद करने वालों के लिए, मैं टिड्डे तनाव परीक्षण उपकरण के अपने छापों को साझा करना जारी रखता हूं।

मैं कोड के साथ लोड टेस्ट अजगर लिखने के लाभों को स्पष्ट रूप से प्रदर्शित करने का प्रयास करूंगा जिसमें आप परीक्षण के लिए कोई भी डेटा आसानी से तैयार कर सकते हैं और परिणामों को संसाधित कर सकते हैं।

सर्वर प्रतिक्रिया प्रसंस्करण

कभी-कभी लोड परीक्षण में, HTTP सर्वर से केवल 200 OK प्राप्त करना पर्याप्त नहीं है। होता है, यह सुनिश्चित करने के लिए प्रतिक्रिया की सामग्री की जांच करना आवश्यक है कि लोड के तहत सर्वर सही डेटा जारी करता है या सटीक गणना करता है। बस ऐसे मामलों के लिए, टिडस्ट ने सर्वर प्रतिक्रिया सफलता मापदंडों को ओवरराइड करने की क्षमता जोड़ी। निम्नलिखित उदाहरण पर विचार करें:

from locust import HttpLocust, TaskSet, task import random as rnd class UserBehavior(TaskSet): @task(1) def check_albums(self): photo_id = rnd.randint(1, 5000) with self.client.get(f'/photos/{photo_id}', catch_response=True, name='/photos/[id]') as response: if response.status_code == 200: album_id = response.json().get('albumId') if album_id % 10 != 0: response.success() else: response.failure(f'album id cannot be {album_id}') else: response.failure(f'status code is {response.status_code}') class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 1000 max_wait = 2000

इसमें केवल एक अनुरोध है, जो निम्नलिखित परिदृश्य में एक भार पैदा करेगा:

सर्वर से, हम 1 से 5000 तक की रेंज में रैंडम आईडी के साथ फोटो ऑब्जेक्ट का अनुरोध करते हैं और इस ऑब्जेक्ट में एल्बम आईडी की जांच करते हैं, यह मानते हुए कि यह 10 से अधिक नहीं हो सकता है

यहाँ आप तुरंत कुछ स्पष्टीकरण दे सकते हैं:

प्रतिक्रिया के रूप में अनुरोध () के साथ भयानक निर्माण : आप इसे सफलतापूर्वक प्रतिक्रिया = अनुरोध () के साथ बदल सकते हैं और प्रतिक्रिया ऑब्जेक्ट के साथ चुपचाप काम कर सकते हैं
URL को python 3.6 में जोड़े गए स्ट्रिंग प्रारूप सिंटैक्स का उपयोग करके बनाया गया है, अगर मैं गलत नहीं हूं - f '/ फोटो / {photo_id}' । पिछले संस्करणों में, यह डिज़ाइन काम नहीं करेगा!
एक नया तर्क जो हमने पहले इस्तेमाल नहीं किया था, catch_response = True , Locust को बताता है कि हम स्वयं सर्वर प्रतिक्रिया की सफलता का निर्धारण करेंगे। यदि आप इसे निर्दिष्ट नहीं करते हैं, तो हम उसी तरह प्रतिक्रिया ऑब्जेक्ट प्राप्त करेंगे और इसके डेटा को संसाधित करने में सक्षम होंगे, लेकिन परिणाम को फिर से परिभाषित नहीं करेंगे। नीचे एक विस्तृत उदाहरण है।
एक और तर्क नाम = '/ तस्वीरें / [आईडी]' । आंकड़ों में अनुरोधों को समूहीकृत करना आवश्यक है। नाम कोई भी पाठ हो सकता है, यूआरएल को दोहराना आवश्यक नहीं है। इसके बिना, एक अद्वितीय पते या मापदंडों के साथ प्रत्येक अनुरोध को अलग से दर्ज किया जाएगा। यहां बताया गया है कि यह कैसे काम करता है:

एक ही तर्क का उपयोग करते हुए, आप एक और चाल कर सकते हैं - कभी-कभी ऐसा होता है कि विभिन्न मापदंडों के साथ एक सेवा (उदाहरण के लिए, POST अनुरोधों की विभिन्न सामग्री) अलग-अलग तर्क करती है। ताकि परीक्षा परिणाम मिश्रित न हों, आप कई अलग-अलग कार्य लिख सकते हैं, प्रत्येक अपने स्वयं के तर्क नाम के लिए निर्दिष्ट कर सकते हैं।

आगे हम चेक करते हैं। मेरे पास उनमें से 2 हैं। सबसे पहले, हम सत्यापित करते हैं कि सर्वर ने एक उत्तर दिया है यदि प्रतिक्रिया।स्टैटस_कोड == 200 )

यदि हाँ, तो जांचें कि क्या एल्बम का आईडी 10 का गुणक है। यदि एक से अधिक नहीं है, तो इस उत्तर को एक सफल प्रतिक्रिया के रूप में चिह्नित करें। ()

अन्य मामलों में, हम इंगित करते हैं कि प्रतिक्रिया क्यों विफल रही। असफलता ('त्रुटि पाठ') । यह पाठ परीक्षण के दौरान विफलता पृष्ठ पर प्रदर्शित किया जाएगा।

इसके अलावा, चौकस पाठक अपवाद की अनुपस्थिति को नोटिस कर सकते हैं जो कोड की विशेषता है जो नेटवर्क इंटरफेस के साथ काम करता है। दरअसल, टाइमआउट, कनेक्शन त्रुटि और अन्य अप्रत्याशित घटनाओं के मामले में, टिड्डे त्रुटियों को संभाल लेंगे और अभी भी एक प्रतिक्रिया लौटाएंगे, यह दर्शाता है कि, हालांकि, प्रतिक्रिया कोड की स्थिति 0 है।

यदि कोड अभी भी एक अपवाद फेंकता है, तो यह रनटाइम पर अपवाद टैब पर लिखा जाएगा ताकि हम इसे संभाल सकें। सबसे विशिष्ट स्थिति यह है कि उत्तर के json'e ने उस मान को वापस नहीं किया है जिसकी हम तलाश कर रहे थे, लेकिन हम पहले से ही इस पर निम्नलिखित संचालन कर रहे हैं।

विषय को बंद करने से पहले - उदाहरण में मैं स्पष्टता के लिए json सर्वर का उपयोग करता हूं, क्योंकि प्रतिक्रियाओं को संसाधित करना आसान है। लेकिन आप HTML, XML, FormData, फ़ाइल अटैचमेंट और HTTP-आधारित प्रोटोकॉल द्वारा उपयोग किए जाने वाले अन्य डेटा के साथ एक ही सफलता के साथ काम कर सकते हैं।

जटिल परिदृश्यों के साथ काम करें

लगभग हर बार कार्य किसी वेब एप्लिकेशन के लोड परीक्षण का संचालन करने के लिए होता है, यह जल्दी से स्पष्ट हो जाता है कि अकेले जीईटी सेवाओं के साथ सभ्य कवरेज प्रदान करना असंभव है - जो केवल डेटा वापस करते हैं।

क्लासिक उदाहरण: एक ऑनलाइन स्टोर का परीक्षण करने के लिए, यह वांछनीय है कि उपयोगकर्ता

मुख्य स्टोर खोला
मुझे माल की तलाश थी
आइटम विवरण खोला गया
कार्ट में जोड़ा गया आइटम
वेतन

उदाहरण से, हम मान सकते हैं कि यादृच्छिक क्रम में कॉलिंग सेवाएं केवल क्रमिक रूप से काम नहीं करेंगी। इसके अलावा, माल, बास्केट और भुगतान के प्रकार प्रत्येक उपयोगकर्ता के लिए विशिष्ट पहचानकर्ता हो सकते हैं।

पिछले उदाहरण का उपयोग करके, मामूली संशोधनों के साथ, आप आसानी से ऐसे परिदृश्य के परीक्षण को लागू कर सकते हैं। हम अपने परीक्षण सर्वर के लिए उदाहरण को अनुकूलित करते हैं:

उपयोगकर्ता एक नई पोस्ट लिख रहा है।
उपयोगकर्ता एक नई पोस्ट पर एक टिप्पणी लिखता है
उपयोगकर्ता टिप्पणी पढ़ता है

 from locust import HttpLocust, TaskSet, task class FlowException(Exception): pass class UserBehavior(TaskSet): @task(1) def check_flow(self): # step 1 new_post = {'userId': 1, 'title': 'my shiny new post', 'body': 'hello everybody'} post_response = self.client.post('/posts', json=new_post) if post_response.status_code != 201: raise FlowException('post not created') post_id = post_response.json().get('id') # step 2 new_comment = { "postId": post_id, "name": "my comment", "email": "test@user.habr", "body": "Author is cool. Some text. Hello world!" } comment_response = self.client.post('/comments', json=new_comment) if comment_response.status_code != 201: raise FlowException('comment not created') comment_id = comment_response.json().get('id') # step 3 self.client.get(f'/comments/{comment_id}', name='/comments/[id]') if comment_response.status_code != 200: raise FlowException('comment not read') class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 1000 max_wait = 2000

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

लोड को यथार्थवादी बना रहा है

अब मुझे फटकारा जा सकता है - स्टोर के मामले में सब कुछ वास्तव में रैखिक है, लेकिन पोस्ट और टिप्पणियों के साथ उदाहरण बहुत दूर है - वे पोस्ट को 10 गुना अधिक बार पढ़ते हैं जो वे बनाते हैं। उचित रूप से, आइए उदाहरण को अधिक व्यवहार्य बनाते हैं। और कम से कम 2 दृष्टिकोण हैं:

यदि उपयोगकर्ता ऐसी संभावना है और बैकएंड की कार्यक्षमता विशिष्ट पदों पर निर्भर नहीं करता है, तो आप उन पोस्ट की सूची को "हार्डकोड" कर सकते हैं, जो उपयोगकर्ता को पढ़ते हैं और परीक्षण कोड को सरल बनाते हैं।
बनाई गई पोस्ट को सहेजें और उन्हें पढ़ें यदि पोस्ट की सूची को पूर्व-निर्धारित करना संभव नहीं है या यथार्थवादी लोड इस बात पर निर्भर करता है कि कौन सी पोस्ट पढ़ी जाती हैं (मैंने इसके कोड को छोटा और अधिक दृश्य बनाने के लिए उदाहरणों से टिप्पणियों के निर्माण को हटा दिया)

 from locust import HttpLocust, TaskSet, task import random as r class UserBehavior(TaskSet): created_posts = [] @task(1) def create_post(self): new_post = {'userId': 1, 'title': 'my shiny new post', 'body': 'hello everybody'} post_response = self.client.post('/posts', json=new_post) if post_response.status_code != 201: return post_id = post_response.json().get('id') self.created_posts.append(post_id) @task(10) def read_post(self): if len(self.created_posts) == 0: return post_id = r.choice(self.created_posts) self.client.get(f'/posts/{post_id}', name='read post') class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 1000 max_wait = 2000

UserBehavior वर्ग में , मैंने एक create_posts सूची बनाई। विशेष ध्यान दें - यह एक वस्तु है और इसे __init __ () वर्ग के निर्माता में नहीं बनाया गया था , इसलिए, क्लाइंट सत्र के विपरीत, यह सूची सभी उपयोगकर्ताओं के लिए सामान्य है। पहला कार्य एक पोस्ट बनाता है और सूची में अपना आईडी लिखता है। दूसरा - 10 गुना अधिक बार, सूची से एक यादृच्छिक रूप से चयनित पोस्ट पढ़ता है। दूसरे कार्य की एक अतिरिक्त स्थिति यह जांचना है कि क्या कोई पोस्ट बनाई गई है।

यदि हम चाहते हैं कि प्रत्येक उपयोगकर्ता केवल अपने डेटा के साथ काम करे, तो हम उन्हें निम्नानुसार कंस्ट्रक्टर में घोषित कर सकते हैं:

 class UserBehavior(TaskSet): def __init__(self, parent): super(UserBehavior, self).__init__(parent) self.created_posts = list()

कुछ और सुविधाएँ

कार्यों की क्रमिक लॉन्चिंग के लिए, आधिकारिक प्रलेखन बताता है कि हम @seq_task (1) कार्य एनोटेशन का भी उपयोग करते हैं, जो तर्क में कार्य क्रम संख्या निर्दिष्ट करता है।

 class MyTaskSequence(TaskSequence): @seq_task(1) def first_task(self): pass @seq_task(2) def second_task(self): pass @seq_task(3) @task(10) def third_task(self): pass

इस उदाहरण में, प्रत्येक उपयोगकर्ता पहले first_task , फिर second_task , फिर 10 बार third_task निष्पादित करेगा।

सच कहूँ तो, इस तरह के अवसर की उपलब्धता प्रसन्न करती है, लेकिन, पिछले उदाहरणों के विपरीत, यह स्पष्ट नहीं है कि यदि आवश्यक हो तो पहले कार्य के परिणामों को दूसरे में कैसे स्थानांतरित किया जाए।

इसके अलावा, विशेष रूप से जटिल परिदृश्यों के लिए, नेस्टेड टास्क सेट बनाना संभव है, वास्तव में, कई टास्कसेट कक्षाएं बनाना और एक दूसरे से कनेक्ट करना।

 from locust import HttpLocust, TaskSet, task class Todo(TaskSet): @task(3) def index(self): self.client.get("/todos") @task(1) def stop(self): self.interrupt() class UserBehavior(TaskSet): tasks = {Todo: 1} @task(3) def index(self): self.client.get("/") @task(2) def posts(self): self.client.get("/posts") class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 1000 max_wait = 2000

ऊपर के उदाहरण में, 1 से 6 की संभावना के साथ, टोडो स्क्रिप्ट लॉन्च की जाएगी, और तब तक निष्पादित की जाएगी, जब तक कि 1 से 4 की संभावना के साथ, यह UserBehavior स्क्रिप्ट पर वापस आ जाएगा। यह बहुत महत्वपूर्ण है कि आपके पास self.interrupt () के लिए एक कॉल है - इसके बिना, परीक्षण उपमा पर केंद्रित होगा।

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

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

सर्वर प्रतिक्रिया प्रसंस्करण

जटिल परिदृश्यों के साथ काम करें

लोड को यथार्थवादी बना रहा है

कुछ और सुविधाएँ

More articles: