विकासकर्ताहरूको लागि CI सेवाको रूपमा लोड परीक्षण

बहु-उत्पादन सफ्टवेयर विक्रेताहरूले प्रायः सामना गर्ने समस्याहरू मध्ये एक भनेको लगभग हरेक टोलीमा इन्जिनियरहरू - विकासकर्ताहरू, परीक्षकहरू, र पूर्वाधार प्रशासकहरूको दक्षताहरूको नक्कल हो। यो महँगो इन्जिनियरहरूमा पनि लागू हुन्छ - लोड परीक्षणको क्षेत्रमा विशेषज्ञहरू।

तिनीहरूको प्रत्यक्ष कर्तव्यहरू गर्नुको सट्टा र लोड परीक्षण प्रक्रिया निर्माण गर्न तिनीहरूको अद्वितीय अनुभव प्रयोग गर्नुको सट्टा, एक विधि, इष्टतम मेट्रिक्स छनौट गर्नुहोस् र लोड प्रोफाइलहरू अनुसार अटोटेस्टहरू लेख्नुहोस्, इन्जिनियरहरूले प्रायः स्क्र्याचबाट परीक्षण पूर्वाधारहरू प्रयोग गर्न, लोड उपकरणहरू कन्फिगर गर्न, र तिनीहरूलाई इम्बेड गर्नुपर्छ। CI प्रणालीहरूमा, अनुगमन र रिपोर्टहरूको प्रकाशन सेट अप गर्नुहोस्।

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

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

सेवाको रूपमा लोड परीक्षणको अवधारणाले लोड उपकरणहरू Apache JMeter, Yandex.Tank र तपाइँको आफ्नै फ्रेमवर्कहरू एक स्वेच्छाचारी निरन्तर एकीकरण प्रणालीमा एकीकृत गर्ने क्षमतालाई बुझाउँछ। डेमो GitLab CI को लागि हुनेछ, तर सिद्धान्तहरू सबै CI प्रणालीहरूमा साझा छन्।

सेवाको रूपमा लोड परीक्षण लोड परीक्षणको लागि एक केन्द्रीकृत सेवा हो। लोड परीक्षणहरू समर्पित एजेन्ट पूलहरूमा चलाइन्छ, परिणामहरू स्वचालित रूपमा GitLab पृष्ठहरू, Influx DB र Grafana वा परीक्षण रिपोर्टिङ प्रणालीहरूमा (TestRail, ReportPortal, आदि) प्रकाशित हुन्छन्। GitLab CI परियोजनामा ​​सामान्य gitlab-ci.yml टेम्प्लेट थपेर र प्यारामिटराइज गरेर - स्वचालन र स्केलिंग सम्भव भएसम्म सरल रूपमा कार्यान्वयन गरिन्छ।

यस दृष्टिकोणको फाइदा यो हो कि सम्पूर्ण CI पूर्वाधार, लोड एजेन्टहरू, लोड स्रोतहरूको डकर छविहरू, परीक्षण पाइपलाइनहरू, र प्रकाशन रिपोर्टहरू केन्द्रीकृत स्वचालन विभाग (DevOps इन्जिनियरहरू) द्वारा राखिन्छन्, जबकि लोड परीक्षण इन्जिनियरहरूले परीक्षण विकासमा आफ्नो प्रयासहरू केन्द्रित गर्न सक्छन्। र तिनीहरूको नतिजाहरूको विश्लेषण, पूर्वाधार समस्याहरूसँग व्यवहार नगरी।

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

लोड परीक्षणमा आधारभूत अवधारणा र परिभाषाहरू

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

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

टेस्ट गोल (लक्ष्य) - सर्भर वा सर्भरमा स्थापित अनुप्रयोग जुन लोडको विषय हुनेछ।

परीक्षण परिदृश्य (परीक्षण केस) - प्यारामिटराइज्ड चरणहरूको सेट: प्रयोगकर्ताका कार्यहरू र यी कार्यहरूमा अपेक्षित प्रतिक्रियाहरू, निश्चित नेटवर्क अनुरोधहरू र प्रतिक्रियाहरू, निर्दिष्ट प्यारामिटरहरूमा निर्भर गर्दै।

प्रोफाइल वा लोड योजना (प्रोफाइल) - मा ISTQB पद्धति (खण्ड 4.2.4, p. 43) लोड प्रोफाइलहरूले मेट्रिक्स परिभाषित गर्दछ जुन विशेष परीक्षणको लागि महत्वपूर्ण हुन्छ र परीक्षणको क्रममा लोड प्यारामिटरहरू परिवर्तन गर्ने विकल्पहरू। तपाईंले चित्रमा प्रोफाइलहरूको उदाहरणहरू देख्न सक्नुहुन्छ।

परीक्षण — पूर्वनिर्धारित प्यारामिटरहरूको सेट भएको लिपि।

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

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

नेटवर्क अनुरोध (अनुरोध) — एजेन्टबाट लक्ष्यमा पठाइएको HTTP अनुरोध।

नेटवर्क प्रतिक्रिया (प्रतिक्रिया) — लक्ष्यबाट एजेन्टलाई पठाइएको HTTP प्रतिक्रिया।
HTTP प्रतिक्रिया कोड (HTTP प्रतिक्रिया स्थिति) - अनुप्रयोग सर्भरबाट मानक प्रतिक्रिया कोड।
लेनदेन एक पूर्ण अनुरोध-प्रतिक्रिया चक्र हो। एक लेनदेन एक अनुरोध (अनुरोध) पठाउन सुरु देखि एक प्रतिक्रिया (प्रतिक्रिया) प्राप्त गर्न को लागी गणना गरिन्छ।

लेनदेन स्थिति - अनुरोध-प्रतिक्रिया चक्र सफलतापूर्वक पूरा गर्न सम्भव छ कि छैन। यदि यस चक्रमा कुनै त्रुटि भयो भने, सम्पूर्ण लेनदेन असफल मानिन्छ।

प्रतिक्रिया समय (विलम्बता) - अनुरोध (अनुरोध) पठाउने अन्त्यदेखि प्रतिक्रिया (प्रतिक्रिया) प्राप्त गर्ने सुरुसम्मको समय।

मेट्रिक्स लोड गर्नुहोस् - लोड गरिएको सेवाको विशेषताहरू र लोड एजेन्ट लोड परीक्षणको प्रक्रियामा निर्धारण गरिन्छ।

लोड प्यारामिटरहरू मापनको लागि आधारभूत मेट्रिक्स

विधिमा सबैभन्दा धेरै प्रयोग र सिफारिस गरिएका केही ISTQB (p. 36, 52) मेट्रिकहरू तलको तालिकामा देखाइएको छ। एजेन्ट र लक्ष्यका लागि समान मेट्रिकहरू एउटै लाइनमा सूचीबद्ध छन्।

लोड एजेन्टको लागि मेट्रिक्स
लक्ष्य प्रणाली वा अनुप्रयोगको मेट्रिक्स लोड अन्तर्गत परीक्षण भइरहेको छ

संख्या  vCPU र मेमोरी राम,
डिस्क - लोड एजेन्ट को "फलाम" विशेषताहरु
CPU, मेमोरी, डिस्क प्रयोग - CPU, मेमोरी र डिस्क लोडिङको गतिशीलता
परीक्षणको प्रक्रियामा। सामान्यतया प्रतिशतको रूपमा मापन गरिन्छ
अधिकतम उपलब्ध मानहरू

नेटवर्क थ्रुपुट (लोड एजेन्टमा) - थ्रुपुट
सर्भरमा नेटवर्क इन्टरफेस,
जहाँ लोड एजेन्ट स्थापित छ।
सामान्यतया बाइट्स प्रति सेकेन्डमा मापन गरिन्छ (bps)
नेटवर्क थ्रुपुट(लक्ष्यमा) - नेटवर्क इन्टरफेस ब्यान्डविथ
लक्षित सर्भरमा। सामान्यतया बाइट्स प्रति सेकेन्डमा मापन गरिन्छ (bps)

भर्चुअल प्रयोगकर्ताहरू- भर्चुअल प्रयोगकर्ताहरूको संख्या,
लोड परिदृश्यहरू कार्यान्वयन गर्दै र
वास्तविक प्रयोगकर्ता कार्यहरूको नक्कल गर्दै
भर्चुअल प्रयोगकर्ता स्थिति, उत्तीर्ण/असफल/कुल — सफल संख्या र
भर्चुअल प्रयोगकर्ताहरूको असफल स्थिति
लोड परिदृश्यहरूको लागि, साथै तिनीहरूको कुल संख्या।

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

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

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

लक्ष्य सेवा को एक महत्वपूर्ण विशेषता: कति
उत्पन्न गर्नुहोस् र प्रश्नहरूको जवाफ पठाउनुहोस्
लोडिङ एजेन्ट

HTTP प्रतिक्रिया स्थिति- विभिन्न प्रतिक्रिया कोडहरूको संख्या
लोड एजेन्ट द्वारा प्राप्त अनुप्रयोग सर्भरबाट।
उदाहरण को लागी, 200 OK को अर्थ सफल कल हो,
र 404 - कि स्रोत फेला परेन

विलम्बता (प्रतिक्रिया समय) - अन्त देखि समय
प्रतिक्रिया (प्रतिक्रिया) प्राप्त गर्न सुरु गर्नु अघि अनुरोध (अनुरोध) पठाउँदै।
सामान्यतया मिलिसेकेन्ड (ms) मा मापन

लेनदेन प्रतिक्रिया समय- एक पूर्ण लेनदेनको समय,
अनुरोध-प्रतिक्रिया चक्रको समापन।
यो अनुरोध (अनुरोध) पठाउन सुरु भएको समय हो।
प्रतिक्रिया (प्रतिक्रिया) प्राप्त नगरेसम्म।

लेनदेन समय सेकेन्ड (वा मिनेट) मा मापन गर्न सकिन्छ।
धेरै तरिकामा: न्यूनतम विचार गर्नुहोस्,
अधिकतम, औसत र, उदाहरणका लागि, 90 औं प्रतिशत।
न्यूनतम र अधिकतम पठनहरू चरम छन्
प्रणाली प्रदर्शन स्थिति।
नब्बे प्रतिशत सबैभन्दा बढी प्रयोग गरिन्छ,
जसरी यसले अधिकांश प्रयोगकर्ताहरूलाई देखाउँछ,
सहज रूपमा प्रणाली प्रदर्शन को थ्रेसहोल्ड मा सञ्चालन

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

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

वास्तविक प्रयोगकर्ताहरूको लागि असफल
लेनदेन वास्तवमा मतलब हुनेछ
लोड अन्तर्गत प्रणालीसँग काम गर्न असक्षमता

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

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

योजनाबद्ध नोटहरू:

• QA.Tester लोड परीक्षण मा एक विशेषज्ञ हो,
• लक्ष्य भनेको लक्षित एप्लिकेसन हो जसको लागि तपाईं लोड अन्तर्गत यसको व्यवहार जान्न चाहनुहुन्छ।

रेखाचित्रमा संस्थाहरू, चरणहरू र चरणहरूको वर्गीकरणकर्ता

चरण र चरणहरू
के भइरहेको छ
प्रवेशद्वारमा के छ
आउटपुट के हो

तयारी गर्नुहोस्: परीक्षणको लागि तयारी चरण

लोड प्यारामिटरहरू
सेटिङ र प्रारम्भिकरण
प्रयोगकर्ता
लोड प्यारामिटरहरू,
मेट्रिक्स को छनोट र
परीक्षण योजना तयारी
(प्रोफाइल लोड गर्नुहोस्)
को लागि अनुकूलन विकल्प
लोड एजेन्ट प्रारम्भिकरण
परीक्षण योजना
परीक्षणको उद्देश्य

VM
क्लाउड डिप्लोइमेन्ट
भर्चुअल मेसिन संग
आवश्यक विशेषताहरु
लोड एजेन्टका लागि VM सेटिङहरू
को लागी स्वचालन लिपिहरु
VM सिर्जना
VM मा कन्फिगर गरियो
बादल

पठाउनुहोस्
ओएस सेटअप र तयारी
लागि वातावरण
लोड एजेन्ट काम
को लागि वातावरण सेटिंग्स
लोड एजेन्ट
को लागी स्वचालन लिपिहरु
वातावरण सेटिङहरू
तयार वातावरण:
OS, सेवाहरू र अनुप्रयोगहरू,
कामको लागि आवश्यक
लोड एजेन्ट

लोडएजेन्टहरू
स्थापना, कन्फिगरेसन र प्यारामिटराइजेशन
लोडिङ एजेन्ट।
वा बाट डकर छवि डाउनलोड गर्दै
पूर्व कन्फिगर गरिएको लोड स्रोत
स्रोत डकर छवि लोड गर्नुहोस्
(YAT, JM वा स्व-लिखित फ्रेमवर्क)
सेटिङहरू
लोड एजेन्ट
सेट अप र तयार
लोड एजेन्ट काम गर्न

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

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

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

लग
"कच्चा" लगहरूको संग्रह
लोड परीक्षण को समयमा:
लोड एजेन्ट गतिविधि रेकर्ड,
परीक्षण लक्ष्यको अवस्था
र एजेन्ट चलाउने VM

कार्यान्वयन लगहरू
लोड परीक्षण
प्रणाली लगहरू

मेट्रिक्स
परीक्षणको क्रममा "कच्चा" मेट्रिक्स सङ्कलन गर्दै

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

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

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

प्रकाशित
प्रतिवेदन प्रकाशन
लोड बारे
बाह्य मा परीक्षण
सेवा
प्रशोधित "कच्चा"
उपयुक्त ढाँचामा लगहरू
बाह्यमा अनलोड गर्नका लागि
भण्डारहरू
बाह्यमा सुरक्षित गरियो
भण्डारण रिपोर्ट मा
लोड, उपयुक्त
मानव विश्लेषणको लागि

CI टेम्प्लेटमा लोड स्रोतहरू जडान गर्दै

व्यवहारिक भागमा जाऔं। म कम्पनीका केही परियोजनाहरूमा कसरी देखाउन चाहन्छु सकारात्मक प्रविधिहरू हामीले लोड परीक्षणको अवधारणालाई सेवाको रूपमा लागू गरेका छौं।

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

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

तसर्थ, हाम्रो अनुभवको आधारमा, हामी लोड एजेन्टहरूका लागि कम्तिमा 4 vCPUs, 4 GB RAM, 60 GB SSD प्रयोग गर्न सिफारिस गर्छौं। नेटवर्क कार्डको थ्रुपुट लोड प्रोफाइलको आवश्यकताहरूको आधारमा निर्धारण गरिन्छ।

हामी मुख्यतया दुई लोड स्रोतहरू प्रयोग गर्छौं - Apache JMeter र Yandex.Tank डकर छविहरू।

Yandex.Tank लोड परीक्षणको लागि Yandex बाट खुला स्रोत उपकरण हो। यसको मोड्युलर आर्किटेक्चर फ्यान्टमको उच्च-प्रदर्शन एसिन्क्रोनस हिट-आधारित HTTP अनुरोध जनरेटरमा आधारित छ। ट्याङ्कीसँग SSH प्रोटोकल मार्फत परीक्षण अन्तर्गत सर्भरको स्रोतहरूको बिल्ट-इन निगरानी छ, स्वचालित रूपमा निर्दिष्ट सर्तहरूमा परीक्षण रोक्न सक्छ, परिणामहरू कन्सोलमा र ग्राफको रूपमा प्रदर्शन गर्न सक्छ, तपाईं आफ्नो मोड्युलहरू जडान गर्न सक्नुहुन्छ। यसलाई कार्यक्षमता विस्तार गर्न। वैसे, हामीले ट्याङ्क प्रयोग गर्यौं जब यो अझै मुख्यधारा थिएन। लेखमा "Yandex.Tank र लोड परीक्षण स्वचालन» हामीले २०१३ मा लोड टेस्टिङ कसरी गर्यौं भन्ने कथा पढ्न सक्नुहुन्छ PT अनुप्रयोग फायरवाल हाम्रो कम्पनीको उत्पादनहरु मध्ये एक हो।

अपाचे JMeter Apache बाट खुला स्रोत लोड परीक्षण उपकरण हो। यो स्थिर र गतिशील वेब अनुप्रयोगहरूको परीक्षणको लागि समान रूपमा प्रयोग गर्न सकिन्छ। JMeter ले धेरै संख्यामा प्रोटोकलहरू र अनुप्रयोगहरूसँग अन्तर्क्रिया गर्ने तरिकाहरू समर्थन गर्दछ: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, आदि), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) र IMAP(S), JDBC मार्फत डाटाबेसहरूले शेल आदेशहरू कार्यान्वयन गर्न र जाभा वस्तुहरूसँग काम गर्न सक्छन्। JMeter सँग परीक्षण योजनाहरू सिर्जना गर्न, डिबग गर्ने र कार्यान्वयन गर्न IDE छ। कुनै पनि Java संगत अपरेटिङ सिस्टम (Linux, Windows, Mac OS X) मा कमाण्ड लाइन अपरेशनको लागि CLI पनि छ। उपकरणले गतिशील रूपमा 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 विचारहरू लागू गर्यौं"।

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

लोड परीक्षण सञ्चालनको लागि टेम्प्लेटको उदाहरण परियोजनामा ​​उपलब्ध छ डेमो लोड। को readme फाइल तपाईं टेम्प्लेट प्रयोग गर्न निर्देशनहरू पढ्न सक्नुहुन्छ। टेम्प्लेटमा नै (फाइल gitlab-ci.yml) प्रत्येक चरण के को लागी जिम्मेवार छ भन्ने बारे टिप्पणीहरू छन्।

टेम्प्लेट धेरै सरल छ र माथिको रेखाचित्रमा वर्णन गरिएको लोड परीक्षणको तीन चरणहरू प्रदर्शन गर्दछ: तयारी, परीक्षण, र प्रकाशन रिपोर्टहरू। यसका लागि जिम्मेवार चरणहरू: तयारी, परीक्षण र रिपोर्ट.

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

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

3. चरणमा रिपोर्ट तपाईंले परीक्षण चरणमा प्राप्त परीक्षण परिणामहरूलाई बाह्य भण्डारणहरूमा कसरी प्रकाशित गर्ने भनेर वर्णन गर्न आवश्यक छ, उदाहरणका लागि, GitLab पृष्ठहरू वा विशेष रिपोर्टिङ प्रणालीहरूमा। GitLab पृष्ठहरूलाई ./public डाइरेक्टरी खाली नभएको र परीक्षणहरू समाप्त भएपछि कम्तिमा एउटा index.html फाइल समावेश गर्न आवश्यक छ। तपाईं GitLab पृष्ठ सेवा को सूक्ष्मता को बारे मा पढ्न सक्नुहुन्छ। लिङ्क.

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

   • JMeter देखि GitLab पृष्ठहरू,
   • Yandex.Tank बाट InfluxDB र Grafana.

   सेटअप निर्देशनहरू पोस्ट गर्दै:

   • HTML स्ट्याटिक्स मा GitLab पृष्ठहरू,
   • InfluxDB मा र त्यसपछि ग्राफाना.

डेमो उदाहरणमा, लोड परीक्षण र दुई लोड स्रोतहरू भएको पाइपलाइन (तपाईंले अनावश्यकलाई असक्षम गर्न सक्नुहुन्छ) यस्तो देखिन्छ:

Apache JMeter ले HTML रिपोर्ट आफैं उत्पन्न गर्न सक्छ, त्यसैले यसलाई मानक उपकरणहरू प्रयोग गरेर GitLab पृष्ठहरूमा बचत गर्न अधिक लाभदायक छ। Apache JMeter रिपोर्ट यस्तो देखिन्छ:

Yandex.Tank को लागि डेमो उदाहरणमा, तपाईंले मात्र देख्नुहुनेछ नक्कली पाठ रिपोर्ट GitLab पृष्ठहरूको लागि सेक्सनमा। परीक्षणको क्रममा, ट्याङ्कले परिणामहरूलाई InfluxDB डाटाबेसमा बचत गर्न सक्छ, र त्यहाँबाट तिनीहरू प्रदर्शन गर्न सकिन्छ, उदाहरणका लागि, Grafana मा (कन्फिगरेसन फाइलमा गरिन्छ। ./tests/example-yandextank-test.yml)। ट्याङ्कको रिपोर्ट ग्राफनामा यस्तो देखिन्छ:

सारांश

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

PS म हाम्रा सहकर्मीहरू, सर्गेई कुर्बानोभ र निकोलाई युसेभलाई हाम्रो कम्पनीमा सेवाको रूपमा लोड परीक्षणको अवधारणाको कार्यान्वयनमा प्राविधिक सहयोगको लागि ठूलो धन्यवाद भन्न चाहन्छु।

लेखक: तैमुर गिलमुलिन - उप सकारात्मक टेक्नोलोजीहरूमा टेक्नोलोजी र विकास प्रक्रियाहरू (DevOps) को प्रमुख

स्रोत: www.habr.com