🧛🏻 💃🏾 🖕🏿 सॉफ्टवेयर टेस्टिंग के लिए क्लाउड बनाएं 😍 😿 ⬛️

जबकि Google और Microsoft जैसी कंपनियां सक्रिय उपयोगकर्ताओं को क्लाउड सेवाओं पर प्रतीक्षा करने वाली खुशी के बारे में सक्रिय रूप से बता रही हैं, मैं बादलों के दूसरे पक्ष को साझा करना चाहता हूं - डेवलपर्स और सॉफ्टवेयर परीक्षकों के लिए खुशी। उन कुछ वर्षों के लिए, जिनके दौरान मैंने पैराल्ल्स प्लेस्क पैनल परीक्षण टीम का नेतृत्व किया, हमारे उद्देश्यों के लिए क्लाउड का उपयोग करने पर जीवन हैक का एक अच्छा संग्रह संकलित किया गया है।

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

प्रस्तावना के साथ, सब कुछ लगता है। मैं बिल्ली के नीचे जिज्ञासु को आमंत्रित करता हूं।

हमें बादल की आवश्यकता क्यों है?

Parallels Plesk पैनल की लागत दुनिया में होस्टिंग के लिए उपयोग किए जाने वाले सभी सर्वरों का लगभग 50% है। ये लाखों हार्डवेयर और VPS हैं, जिन पर लाखों क्लाइंट साइट घूमती हैं। सॉफ्टवेयर में बग्स की कीमत बहुत बड़ी है, इसमें कोई ट्रिफ़ल्स नहीं हैं। इस संबंध में, स्पलैश QA इंजीनियरों के लिए एक बहुत ही जटिल उत्पाद है। हमें इसके लिए प्रति दिन लगभग 2000 p0 और p1 प्रतिगमन ऑटोटेस्ट चलाने की आवश्यकता है (जिनमें से लगभग 700 परीक्षण उपयोगकर्ता इंटरफ़ेस के लिए समर्पित हैं) 60 कॉन्फ़िगरेशन पर। 24 घंटों में, 120,000 से अधिक ऑटोटेस्ट लॉन्च किए जाते हैं। इसके अलावा, सप्ताह में कम से कम एक बार वह अधिक काम करता है - दर्जनों कॉन्फ़िगरेशन पर "स्प्लैश" के सात समर्थित संस्करणों से अपग्रेड / बैकअप / रिस्टोर / माइग्रेशन की जांच करने के लिए परीक्षण आवश्यक रूप से शुरू किए जाते हैं। महीने में एक बार, क्यूए इंजीनियर प्रदर्शन-, घनत्व- और लोड-परीक्षण करते हैं। खैर, यह रिलीज की पूर्व संध्या पर बहुत गर्म है। फिर उपरोक्त सभी ऑपरेशनों में दर्जनों उत्पादों के साथ एकीकरण को सत्यापित करने की आवश्यकता को जोड़ा गया है।

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

यह क्या होगा?

प्लस्का क्यूए टीम की "विशलिस्ट" (और वास्तव में नोवोसिबिर्स्क पैरलेल्स विकास केंद्र, जहां सेवा प्रदाताओं के लिए कई अन्य उत्पाद बनाए जा रहे हैं) 2008 में बने थे और चार संक्षिप्त बिंदुओं में रखे गए थे:

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

एक साल बाद, "क्लाउड", आपको बुनियादी कार्यों (मशीन को तैनात करने, ऑटो परीक्षण चलाने) की अनुमति देने के लिए तैयार था। 2-3 लोगों ने इसके निर्माण पर काम किया। लगभग सभी क्लाउड सॉफ़्टवेयर मालिकाना है, जिसमें बॉक्स उत्पादों से बाहर एक जोड़े के अपवाद हैं। ये हैं मुनिन (संसाधनों की उपलब्धता की निगरानी) और नागियोस (संसाधनों के उपयोग की निगरानी)। लेकिन टेस्टलिंक (परीक्षण मामलों के मौखिक विवरणों का भंडारण, परीक्षण के मामलों के मैनुअल और स्वचालित निष्पादन के परिणामों का गठन) को गंभीरता से फावड़ा करना पड़ा। कोर और रिपोर्टिंग प्रणाली को संशोधित किया गया था। उदाहरण के लिए, बाद वाले को रिपोर्ट की पीढ़ी को परिमाण के दो आदेशों को तेज करके हमें दिया गया था: यह 5 मिनट था, यह 5 सेकंड था।

एक सक्षम पाठक पूछेगा कि हमने अपने लक्ष्यों और उद्देश्यों के लिए अमेज़ॅन क्लाउड का उपयोग क्यों नहीं किया और इसमें उदाहरण नहीं दिए। मैं थीसिस का जवाब दूंगा:

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

सच्चाई का क्षण: कैसे बादल ने परीक्षकों के जीवन को बदल दिया है?

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

कैसा है? क्लाउड ने क्यूए टीम को नियमित कार्यों से बचाया। परीक्षक एक "थोड़ा व्यवस्थापक" होना बंद हो गया है और अब स्वतंत्र रूप से ओएस, उत्पाद का निर्माण और सर्वर के लिए परीक्षण योजना बनाने में संलग्न नहीं है। अब रोबोट इसमें लगा हुआ है, जिसे GUI या API इंटरफेस के जरिए कमांड किया जा सकता है।

यहाँ यह कैसा दिखता है:

हम उत्पाद और संस्करण (1), परीक्षण योजना (2), बिल्ड (3), कॉन्फ़िगरेशन की सूची (4) का चयन करते हैं, 'रन' बटन दबाएं (5) और यह शुरू होता है। दर्जनों और सैकड़ों मशीनों को तैनात करना, उन पर एक उत्पाद स्थापित करना, ऑटो परीक्षण शुरू करना वस्तुतः कुछ ही क्लिक में होता है।

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

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

परीक्षण बादल के हुड के तहत

यह सरल चलती तस्वीर हमारे बादल के काम को दर्शाती है और इसकी वास्तुकला का एक विचार देती है:

आइए देखें कि निरंतर एकीकरण योजना के उदाहरण का उपयोग करके गियर कैसे अंदर घूमते हैं।

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

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

बेशक, इस रूप में बादल तुरंत दिखाई नहीं दिया। यह इसके प्रभावी उपयोग के बारे में उद्देश्यों और हमारे विचारों के अनुसार विकसित हुआ है (और बदलना जारी है)।

Lifehacks और सुधार

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

क्या उत्पाद में 80 क्रैश 80 कीड़े हैं? क्या यह परीक्षणों में 80 समस्याएं हैं? क्या उत्पाद में यह एक बग है जिससे दुर्घटना के 80 परीक्षण हो सकते हैं? उत्पाद किस हालत में है? क्या वास्तव में टूट गया? लॉग देखने के लिए कहाँ? कई सवाल और कुछ जवाब।

अब परिणाम LogTracker सिस्टम - हमारे आंतरिक विकास को सूचित करते हैं।
स्क्रीन इस प्रणाली के एक पृष्ठ को दिखाती है जिसमें एक विशिष्ट बिल्ड पर परीक्षण योजनाओं में से एक के निष्पादन के परिणामों के बारे में जानकारी है।

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

कृपया ध्यान दें: क्यूए इंजीनियर के साथ काम करने वाले डेटा की संपूर्ण सरणी को स्वचालित रूप से एकत्रित और उत्पन्न किया जाएगा ।

निष्कर्ष

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

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

इन सभी कार्यों के बाद, यह आपके लिए स्पष्ट हो जाएगा कि आपका व्यक्तिगत क्लाउड किस दिशा में विकसित होगा।