डेवलपर्स के लिए सीआई सेवा के रूप में लोड परीक्षण

बहु-उत्पाद सॉफ़्टवेयर विक्रेताओं को अक्सर जिन समस्याओं का सामना करना पड़ता है, उनमें से एक है लगभग हर टीम पर इंजीनियरों - डेवलपर्स, परीक्षकों और बुनियादी ढाँचे के प्रशासकों की दक्षताओं का दोहराव। यह महंगे इंजीनियरों - भार परीक्षण के क्षेत्र में विशेषज्ञों पर भी लागू होता है।

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

परीक्षण में आप कुछ संगठनात्मक समस्याओं का समाधान पा सकते हैं जिनका उपयोग हम सकारात्मक तकनीकों में करते हैं एक और लेख. और इसमें, मैं लोड परीक्षणों को एक सामान्य सीआई पाइपलाइन में एकीकृत करने की संभावना के बारे में बात करूंगा, "लोड परीक्षण एक सेवा के रूप में" (एक सेवा के रूप में लोड परीक्षण) की अवधारणा का उपयोग करके। आप सीखेंगे कि सीआई पाइपलाइन में लोड स्रोतों की डॉकटर छवियों का उपयोग कैसे और कैसे किया जा सकता है; बिल्ड टेम्पलेट का उपयोग करके लोड स्रोतों को अपने CI प्रोजेक्ट से कैसे कनेक्ट करें; लोड परीक्षण चलाने और परिणाम प्रकाशित करने के लिए डेमो पाइपलाइन कैसी दिखती है। लेख सीआई में सॉफ्टवेयर टेस्टिंग इंजीनियरों और ऑटोमेशन इंजीनियरों के लिए उपयोगी हो सकता है जो अपने लोड सिस्टम के आर्किटेक्चर के बारे में सोच रहे हैं।

अवधारणा का सार

एक सेवा के रूप में लोड परीक्षण की अवधारणा का अर्थ है लोड टूल्स Apache JMeter, Yandex.Tank और अपने स्वयं के ढांचे को एक मनमाने ढंग से निरंतर एकीकरण प्रणाली में एकीकृत करने की क्षमता। डेमो GitLab CI के लिए होगा, लेकिन सिद्धांत सभी CI सिस्टम के लिए सामान्य हैं।

सेवा के रूप में लोड परीक्षण लोड परीक्षण के लिए एक केंद्रीकृत सेवा है। लोड परीक्षण समर्पित एजेंट पूल में चलाए जाते हैं, परिणाम स्वचालित रूप से गिटलैब पेज, इन्फ्लक्स डीबी और ग्राफाना या टेस्ट रिपोर्टिंग सिस्टम (टेस्टरेल, रिपोर्टपोर्टल, आदि) में प्रकाशित होते हैं। ऑटोमेशन और स्केलिंग को यथासंभव सरल रूप से लागू किया जाता है - GitLab CI प्रोजेक्ट में सामान्य gitlab-ci.yml टेम्प्लेट को जोड़कर और पैरामीटर करके।

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

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

लोड परीक्षण में बुनियादी अवधारणाएं और परिभाषाएं

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

लोड एजेंट - एक वर्चुअल मशीन जिस पर एप्लिकेशन लॉन्च किया जाएगा - लोड स्रोत (Apache JMeter, Yandex.Tank या एक स्व-लिखित लोड मॉड्यूल)।

परीक्षण लक्ष्य (लक्ष्य) - सर्वर पर स्थापित सर्वर या एप्लिकेशन जो लोड के अधीन होगा।

टेस्ट परिदृश्य (टेस्ट केस) - मानकीकृत चरणों का एक सेट: निर्दिष्ट मापदंडों के आधार पर निश्चित नेटवर्क अनुरोधों और प्रतिक्रियाओं के साथ उपयोगकर्ता क्रियाएं और इन कार्यों के लिए अपेक्षित प्रतिक्रियाएं।

प्रोफ़ाइल या लोड योजना (प्रोफ़ाइल) - में आईएसटीक्यूबी पद्धति (धारा 4.2.4, पृ. 43) लोड प्रोफाइल मेट्रिक्स को परिभाषित करता है जो किसी विशेष परीक्षण के लिए महत्वपूर्ण हैं और परीक्षण के दौरान लोड मापदंडों को बदलने के विकल्प हैं। आप आकृति में प्रोफाइल के उदाहरण देख सकते हैं।

परीक्षा - मापदंडों के पूर्व निर्धारित सेट के साथ एक स्क्रिप्ट।

परीक्षण योजना (परीक्षण योजना) - परीक्षणों का एक सेट और एक लोड प्रोफ़ाइल।

टेस्ट्रन (टेस्ट्रन) - पूरी तरह से निष्पादित लोड परिदृश्य और प्राप्त रिपोर्ट के साथ एक परीक्षण चलाने का एक पुनरावृत्ति।

नेटवर्क अनुरोध (अनुरोध) - एक एजेंट से एक लक्ष्य के लिए भेजा गया एक HTTP अनुरोध।

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

लेन-देन की स्थिति - क्या अनुरोध-प्रतिक्रिया चक्र को सफलतापूर्वक पूरा करना संभव था। यदि इस चक्र में कोई त्रुटि होती है, तो संपूर्ण लेन-देन असफल माना जाता है।

प्रतिक्रिया समय (विलंबता) - प्रतिक्रिया (प्रतिक्रिया) प्राप्त करने की शुरुआत के लिए अनुरोध (अनुरोध) भेजने के अंत से समय।

लोड मेट्रिक्स - लोड परीक्षण की प्रक्रिया में निर्धारित लोडेड सेवा और लोड एजेंट की विशेषताएं।

लोड मापदंडों को मापने के लिए बुनियादी मीट्रिक

कार्यप्रणाली में सबसे अधिक इस्तेमाल और अनुशंसित कुछ आईएसटीक्यूबी (पृष्ठ 36, 52) मेट्रिक्स नीचे दी गई तालिका में दिखाए गए हैं। एजेंट और लक्ष्य के लिए समान मेट्रिक्स एक ही पंक्ति में सूचीबद्ध हैं।

लोड एजेंट के लिए मेट्रिक्स
लोड के तहत परीक्षण किए जा रहे लक्षित सिस्टम या एप्लिकेशन के मेट्रिक्स

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

नेटवर्क थ्रूपुट (लोड एजेंट पर) - थ्रूपुट
सर्वर पर नेटवर्क इंटरफ़ेस,
जहां लोड एजेंट स्थापित है।
आमतौर पर बाइट्स प्रति सेकंड (bps) में मापा जाता है
नेटवर्क थ्रूपुट(लक्ष्य पर) - नेटवर्क इंटरफ़ेस बैंडविड्थ
लक्ष्य सर्वर पर। आमतौर पर बाइट्स प्रति सेकंड (bps) में मापा जाता है

आभासी उपयोगकर्ता- आभासी उपयोगकर्ताओं की संख्या,
लोड परिदृश्यों को लागू करना और
वास्तविक उपयोगकर्ता क्रियाओं का अनुकरण करना
आभासी उपयोगकर्ता स्थिति, उत्तीर्ण/अनुत्तीर्ण/कुल - सफल और की संख्या
आभासी उपयोगकर्ताओं की असफल स्थितियाँ
लोड परिदृश्यों के साथ-साथ उनकी कुल संख्या के लिए।

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

अनुरोध प्रति सेकंड (मिनट)- प्रति सेकंड (या मिनट) नेटवर्क अनुरोधों की संख्या।

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

लक्ष्य सेवा की एक महत्वपूर्ण विशेषता: कितना
के साथ प्रश्नों के उत्तर उत्पन्न करें और भेजें
लोडिंग एजेंट

HTTP प्रतिक्रिया स्थिति- विभिन्न प्रतिक्रिया कोडों की संख्या
लोड एजेंट द्वारा प्राप्त एप्लिकेशन सर्वर से।
उदाहरण के लिए, 200 OK का अर्थ है एक सफल कॉल,
और 404 - कि संसाधन नहीं मिला

विलंब (प्रतिक्रिया समय) - अंत से समय
प्रतिक्रिया (प्रतिक्रिया) प्राप्त करना शुरू करने से पहले एक अनुरोध (अनुरोध) भेजना।
आमतौर पर मिलीसेकंड (एमएस) में मापा जाता है

लेन-देन प्रतिक्रिया समय- एक पूर्ण लेनदेन का समय,
अनुरोध-प्रतिक्रिया चक्र पूरा करना।
यह अनुरोध (अनुरोध) भेजने की शुरुआत से समय है
प्रतिक्रिया (प्रतिक्रिया) प्राप्त करने के पूरा होने तक।

लेन-देन का समय सेकंड (या मिनट) में मापा जा सकता है
कई तरह से: न्यूनतम पर विचार करें,
अधिकतम, औसत और, उदाहरण के लिए, 90वां प्रतिशतक।
न्यूनतम और अधिकतम रीडिंग चरम हैं
सिस्टम प्रदर्शन की स्थिति।
नब्बेवाँ प्रतिशतक सबसे अधिक इस्तेमाल किया जाता है,
जैसा कि यह अधिकांश उपयोगकर्ताओं को दिखाता है,
आराम से सिस्टम प्रदर्शन की दहलीज पर काम कर रहा है

लेन-देन प्रति सेकंड (मिनट) - पूर्ण की संख्या
लेनदेन प्रति सेकंड (मिनट),
यानी आवेदन कितना स्वीकार करने में सक्षम था और
प्रक्रिया अनुरोधों और प्रतिक्रियाओं को जारी करें।
वास्तव में, यह सिस्टम का थ्रूपुट है

लेन-देन की स्थिति , उत्तीर्ण / अनुत्तीर्ण / कुल - संख्या
सफल, असफल और लेन-देन की कुल संख्या।

वास्तविक उपयोगकर्ताओं के लिए असफल
लेन-देन का वास्तव में मतलब होगा
लोड के तहत सिस्टम के साथ काम करने में असमर्थता

लोड परीक्षण योजनाबद्ध आरेख

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

योजनाबद्ध नोट:

• QA.Tester लोड टेस्टिंग का विशेषज्ञ है,
• लक्ष्य वह लक्ष्य अनुप्रयोग है जिसके लिए आप लोड के तहत उसके व्यवहार को जानना चाहते हैं।

आरेख में संस्थाओं, चरणों और चरणों का वर्गीकरण

चरण और चरण
क्या होता है
प्रवेश द्वार पर क्या है
आउटपुट क्या है

तैयारी: परीक्षण के लिए तैयारी चरण

लोडपैरामीटर
सेटिंग और आरंभीकरण
उपयोगकर्ता
लोड पैरामीटर,
मेट्रिक्स की पसंद और
परीक्षण योजना तैयार करना
(लोड प्रोफाइल)
के लिए कस्टम विकल्प
लोड एजेंट आरंभीकरण
जाँच की योजना
परीक्षण का उद्देश्य

VM
मेघ परिनियोजन
वर्चुअल मशीन के साथ
आवश्यक विशेषताएं
लोड एजेंट के लिए वीएम सेटिंग्स
के लिए स्वचालन स्क्रिप्ट
वीएम निर्माण
वीएम में कॉन्फ़िगर किया गया
बादल

env
ओएस सेटअप और तैयारी
के लिए वातावरण
लोड एजेंट का काम
पर्यावरण सेटिंग्स के लिए
लोड एजेंट
के लिए स्वचालन स्क्रिप्ट
पर्यावरण सेटिंग्स
तैयार वातावरण:
ओएस, सेवाओं और अनुप्रयोगों,
काम के लिए आवश्यक
लोड एजेंट

लोडएजेंट
स्थापना, कॉन्फ़िगरेशन और पैरामीटरकरण
लोडिंग एजेंट।
या डॉकर छवि को डाउनलोड करना
पूर्व-कॉन्फ़िगर लोड स्रोत
लोड स्रोत डॉकटर छवि
(YAT, JM या स्व-लिखित रूपरेखा)
समायोजन
लोड एजेंट
सेट अप करें और तैयार करें
वर्क लोड एजेंट के लिए

टेस्ट: लोड टेस्ट के निष्पादन का चरण। स्रोत लोड एजेंट हैं जिन्हें GitLab CI के लिए समर्पित एजेंट पूल में तैनात किया गया है

भार
लोड एजेंट शुरू करना
चयनित परीक्षण योजना के साथ
और लोड पैरामीटर
उपयोगकर्ता विकल्प
आरंभीकरण के लिए
लोड एजेंट
जाँच की योजना
परीक्षण का उद्देश्य
निष्पादन लॉग
भार परीक्षण
सिस्टम लॉग
लक्ष्य मेट्रिक्स और लोड एजेंट में परिवर्तन की गतिशीलता

एजेंट चलाएं
एजेंट निष्पादन
परीक्षण स्क्रिप्ट का भार
के अनुसार
लोड प्रोफाइल
लोड एजेंट इंटरेक्शन
परीक्षण के प्रयोजन के लिए
जाँच की योजना
परीक्षण का उद्देश्य

Logs
"कच्चे" लॉग का संग्रह
लोड परीक्षण के दौरान:
लोड एजेंट गतिविधि रिकॉर्ड,
परीक्षण लक्ष्य की स्थिति
और वीएम एजेंट चला रहा है

निष्पादन लॉग
भार परीक्षण
सिस्टम लॉग

मेट्रिक्स
परीक्षण के दौरान "कच्चे" मेट्रिक्स एकत्रित करना

लक्ष्य मेट्रिक्स में परिवर्तन की गतिशीलता
और लोड एजेंट

रिपोर्ट: परीक्षण रिपोर्ट तैयार करने का चरण

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

प्रकाशित करना
रिपोर्ट का प्रकाशन
भार के बारे में
बाहरी में परीक्षण
सेवा
संसाधित "कच्चा"
एक उपयुक्त प्रारूप में लॉग करता है
बाहरी को उतारने के लिए
खजाने
बाहरी में सहेजा गया
भंडारण रिपोर्ट पर
लोड, उपयुक्त
मानव विश्लेषण के लिए

सीआई टेम्पलेट में लोड स्रोतों को जोड़ना

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

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

हार्डवेयर द्वारा आवश्यक शक्ति कैसे पता करें? लोड एजेंटों की विशेषताएं - पर्याप्त संख्या में vCPU, RAM और डिस्क - की गणना इस तथ्य के आधार पर की जा सकती है कि Docker, Python (Yandex.Tank के लिए), GitLab CI एजेंट, Java (Apache JMeter के लिए) को एजेंट पर चलना चाहिए . जेएमटर के तहत जावा के लिए, न्यूनतम 512 एमबी रैम और ऊपरी सीमा के रूप में उपयोग करने की भी सिफारिश की जाती है, 80% उपलब्ध स्मृति.

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

हम मुख्य रूप से दो लोड स्रोतों का उपयोग करते हैं - Apache JMeter और Yandex.Tank docker इमेज।

यैंडेक्स.टैंक लोड परीक्षण के लिए यैंडेक्स का एक ओपन सोर्स टूल है। इसका मॉड्यूलर आर्किटेक्चर फैंटम के उच्च-प्रदर्शन अतुल्यकालिक हिट-आधारित HTTP अनुरोध जनरेटर पर आधारित है। टैंक में एसएसएच प्रोटोकॉल के माध्यम से परीक्षण के तहत सर्वर के संसाधनों की अंतर्निहित निगरानी है, निर्दिष्ट शर्तों के तहत परीक्षण को स्वचालित रूप से रोक सकता है, परिणामों को कंसोल में और ग्राफ़ के रूप में प्रदर्शित कर सकता है, आप अपने मॉड्यूल कनेक्ट कर सकते हैं इसके लिए कार्यक्षमता का विस्तार करने के लिए। वैसे, हमने टैंक का उपयोग उस समय किया था जब यह मुख्यधारा में नहीं था। लेख में "Yandex.Tank और लोड परीक्षण स्वचालन» आप इसकी कहानी पढ़ सकते हैं कि हमने 2013 में इसके साथ लोड परीक्षण कैसे किया पीटी आवेदन फ़ायरवॉल हमारी कंपनी के उत्पादों में से एक है।

अपाचे JMeter Apache का एक ओपन सोर्स लोड टेस्टिंग टूल है। यह स्थैतिक और गतिशील वेब अनुप्रयोगों दोनों के परीक्षण के लिए समान रूप से अच्छी तरह से उपयोग किया जा सकता है। JMeter बड़ी संख्या में प्रोटोकॉल और अनुप्रयोगों के साथ बातचीत करने के तरीकों का समर्थन करता है: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, आदि), SOAP / REST वेबसर्विसेज, FTP, TCP, LDAP, SMTP (S), POP3 ( S) ) और IMAP(S), JDBC के माध्यम से डेटाबेस, शेल कमांड निष्पादित कर सकते हैं और जावा ऑब्जेक्ट्स के साथ काम कर सकते हैं। JMeter के पास परीक्षण योजनाएँ बनाने, डिबगिंग और निष्पादित करने के लिए एक IDE है। किसी भी जावा संगत ऑपरेटिंग सिस्टम (लिनक्स, विंडोज, मैक ओएस एक्स) पर कमांड लाइन ऑपरेशन के लिए एक सीएलआई भी है। उपकरण गतिशील रूप से एक HTML परीक्षण रिपोर्ट उत्पन्न कर सकता है।

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

हमने Yandex.Tank के लिए यह मूल डॉकर फ़ाइल ली:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

और Apache JMeter के लिए यह एक:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

आप लेख में पढ़ सकते हैं कि हमारी निरंतर एकीकरण प्रणाली कैसे काम करती है "विकास प्रक्रियाओं का स्वचालन: हमने सकारात्मक तकनीकों पर DevOps के विचारों को कैसे लागू किया'.

टेम्पलेट और पाइपलाइन

लोड परीक्षण करने के लिए एक टेम्पलेट का एक उदाहरण प्रोजेक्ट में उपलब्ध है डेमो लोड. में रीडमी फ़ाइल आप टेम्पलेट का उपयोग करने के लिए निर्देश पढ़ सकते हैं। टेम्प्लेट में ही (file .gitlab-ci.yml) प्रत्येक चरण के लिए क्या जिम्मेदार है, इसके बारे में नोट्स हैं।

टेम्प्लेट बहुत सरल है और ऊपर दिए गए आरेख में वर्णित लोड परीक्षण के तीन चरणों को प्रदर्शित करता है: रिपोर्ट तैयार करना, परीक्षण करना और प्रकाशित करना। इसके लिए जिम्मेदार चरणों: तैयार करें, परीक्षण करें और रिपोर्ट करें.

1. मंच तैयार करना परीक्षण लक्ष्यों को पूर्व-कॉन्फ़िगर करने या उनकी उपलब्धता की जाँच करने के लिए उपयोग किया जाना चाहिए। लोड स्रोतों के लिए पर्यावरण को कॉन्फ़िगर करने की आवश्यकता नहीं है, वे डॉकर छवियों के रूप में पूर्व-निर्मित होते हैं और डॉकर रजिस्ट्री में पोस्ट किए जाते हैं: केवल परीक्षण चरण में वांछित संस्करण निर्दिष्ट करें। लेकिन आप उनका पुनर्निर्माण कर सकते हैं और अपनी खुद की संशोधित छवियां बना सकते हैं।
2. मंच टेस्ट लोड स्रोत निर्दिष्ट करने, परीक्षण चलाने और परीक्षण कलाकृतियों को संग्रहीत करने के लिए उपयोग किया जाता है। आप कोई भी लोड स्रोत चुन सकते हैं: Yandex.Tank, Apache JMeter, आपका अपना, या सभी एक साथ। अनावश्यक स्रोतों को अक्षम करने के लिए, बस टिप्पणी करें या कार्य को हटा दें। लोड स्रोतों के लिए प्रवेश बिंदु:
   • Yandex.Tank के लिए लॉन्च पैरामीटर निर्दिष्ट किए गए हैं।/परीक्षण/yandextank.sh,
   • Apache JMeter स्टार्टअप पैरामीटर फ़ाइल में निर्दिष्ट हैं ./परीक्षण/jmeter.sh.

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

3. मंच पर रिपोर्ट आपको यह वर्णन करने की आवश्यकता है कि परीक्षण चरण में प्राप्त परीक्षण परिणामों को बाहरी स्टोरेज में कैसे प्रकाशित किया जाए, उदाहरण के लिए, GitLab पेज या विशेष रिपोर्टिंग सिस्टम पर। GitLab पेजों के लिए आवश्यक है कि ./public निर्देशिका खाली न हो और परीक्षण पूर्ण होने के बाद कम से कम एक index.html फ़ाइल हो। आप GitLab पेज सेवा की बारीकियों के बारे में पढ़ सकते हैं। по ссылке.

   डेटा निर्यात करने के तरीके के उदाहरण:

   • जेएमटर से गिटलैब पेज,
   • Yandex.Tank से इन्फ्लक्सडीबी और ग्राफाना.

   सेटअप निर्देश पोस्ट करना:

   • HTML स्टैटिक्स में गिटलैब पेज,
   • InfluxDB और फिर to ग्राफाना.

डेमो उदाहरण में, लोड परीक्षण और दो लोड स्रोतों वाली पाइपलाइन (आप अनावश्यक को अक्षम कर सकते हैं) इस तरह दिखती है:

Apache JMeter स्वयं एक HTML रिपोर्ट उत्पन्न कर सकता है, इसलिए मानक टूल का उपयोग करके इसे GitLab पेजों में सहेजना अधिक लाभदायक है। Apache JMeter रिपोर्ट इस प्रकार दिखती है:

Yandex.Tank के डेमो उदाहरण में, आप केवल देखेंगे नकली पाठ रिपोर्ट GitLab पृष्ठों के अनुभाग में। परीक्षण के दौरान, टैंक परिणामों को इन्फ्लक्सडीबी डेटाबेस में सहेज सकता है, और वहां से उन्हें प्रदर्शित किया जा सकता है, उदाहरण के लिए, ग्राफाना में (कॉन्फ़िगरेशन फ़ाइल में किया जाता है) ./tests/example-yandextank-test.yml). ग्रेफाना में टैंक की रिपोर्ट इस प्रकार है:

सारांश

लेख में, मैंने "एक सेवा के रूप में लोड परीक्षण" (एक सेवा के रूप में लोड परीक्षण) की अवधारणा के बारे में बात की। मुख्य विचार लोड एजेंटों के पूर्व-कॉन्फ़िगर पूल के बुनियादी ढांचे का उपयोग करना है, लोड स्रोतों की डॉकटर छवियां, रिपोर्टिंग सिस्टम और एक पाइपलाइन जो उन्हें एक सरल .gitlab-ci.yml टेम्पलेट के आधार पर GitLab CI में जोड़ती है (उदाहरण) по ссылке). यह सब स्वचालन इंजीनियरों की एक छोटी टीम द्वारा समर्थित है और उत्पाद टीमों के अनुरोध पर दोहराया गया है। मुझे उम्मीद है कि इससे आपको अपनी कंपनी में इसी तरह की योजना तैयार करने और लागू करने में मदद मिलेगी। ध्यान देने के लिए धन्यवाद!

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

लेखक: तैमूर गिलमुलिन - डिप्टी पॉजिटिव टेक्नोलॉजीज में प्रौद्योगिकी और विकास प्रक्रियाओं (DevOps) के प्रमुख

स्रोत: www.habr.com