👩🏼‍✈️ 👨🏿‍🚀 🏳️‍🌈 डेवलपर्स के लिए CI सेवा के रूप में लोड परीक्षण ♿️ 🏂🏼 🌎

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लोडिंग मेट्रिक्स (मेट्रिक्स) - लोड परीक्षण की प्रक्रिया के दौरान लोड की गई सेवा और लोडिंग एजेंट की विशेषताएं।

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

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

एजेंट मैट्रिक्स लोड करें	लक्ष्य प्रणाली या लोड के तहत परीक्षण किए गए आवेदन के मेट्रिक्स
वीसीपीयू और रैम मेमोरी की संख्या , डिस्क - लोड एजेंट की "लोहा" विशेषताएं	सीपीयू , मेमोरी, डिस्क का उपयोग - परीक्षण के दौरान प्रोसेसर, मेमोरी और डिस्क को लोड करने की गतिशीलता । आमतौर पर अधिकतम उपलब्ध मूल्यों के प्रतिशत के रूप में मापा जाता है ।
Network throughput (on load agent) — , . (bps)	Network throughput(on target) — . (bps)
Virtual users— ,	Virtual users status, Passed/Failed/Total — , . , , . ,
Requests per second (minute)— ( ). : .	Responses per second (minute) — ( ). :
	HTTP responses status— , . , 200 OK , 404 —
	Latency ( ) — (request) (response). (ms)
	Transaction response time— , « — ». (request) (response). ( ) : , , , , 90- . — . , ,
	Transactions per second (minute) — (), .
	Transactions status , Passed / Failed / Total — , .

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

QA.Tester - तनाव परीक्षण विशेषज्ञ,
टारगेट टारगेट एप्लीकेशन है जिसके लिए आपको लोड के तहत इसके व्यवहार को जानना होगा।

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

चरणों और चरणों	क्या हो रहा है	प्रवेश द्वार पर क्या है	आउटपुट क्या है
तैयारी: परीक्षण तैयारी चरण
Loadparameters	उपयोगकर्ता लोड मापदंडों को सेट करना और आरंभ करना , मैट्रिक्स का चयन करना और परीक्षण योजना तैयार करना (लोड प्रोफ़ाइल)	-
VM
Env			: , ,
LoadAgents	, . -	- (, JM )
Test: . , GitLab CI
Load	-	-
RunAgents		-
Logs	«» : , ,
Metrics	«»
Report:
Generator	«» ,		«» , ,
Publish		«» ,	,

CI-

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

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

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

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

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

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

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

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

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

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

और अपाचे JMeter के लिए यह एक:

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

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

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

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

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

Prepare . , - docker registry: Test. .
Test , . : Yandex.Tank, Apache JMeter, . job-. :
- Yandex.Tank ./tests/yandextank.sh,
- Apache JMeter ./tests/jmeter.sh.
: CI- . , bash-. , — QA-. . ./tests.
Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .

, :
- JMeter GitLab Pages,
- Yandex.Tank InfluxDB Grafana.
:
- HTML- GitLab Pages,
- InfluxDB Grafana.

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

सारांश

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

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

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

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

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

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

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

CI-

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

सारांश

More articles: