समानताएं क्लाउड सर्वर स्वचालित परीक्षण

मैं आपको बताना चाहता हूं कि मेरे द्वारा काम किए गए समानताएं इंक उत्पादों में से एक का परीक्षण कैसे किया जा रहा है,
- समानताएं क्लाउड सर्वर। मुझे लगता है कि कुछ habruchikov के लिए यह उत्पाद पहले से ही लेखों से परिचित है Parallels ने क्लाउड सर्वर , FastVPS: कैसे हमने वर्चुअलाइजेशन प्लेटफार्मों को बदल दिया है और इसे स्वयं बनाएं: हमने छोटे होस्टरों के लिए अमेज़ॅन-शैली का भंडारण कैसे किया । यदि नहीं, तो मैं ऊपर दिए गए लेखों को पढ़ने की सलाह देता हूं।

इस उत्पाद का परीक्षण कई कारणों से दिलचस्प हो सकता है, और उनमें से एक यह है कि उत्पाद जटिल, बहु-घटक है और कई स्वतंत्र टीमों द्वारा विकसित किया गया है।

अगर मैं आपकी रुचि रखने में कामयाब रहा, तो बिल्ली में आपका स्वागत है।

Parallels Cloud Server अपने आप में एक नंगे धातु का उत्पाद है, अर्थात यह नंगे धातु पर स्थापित है। यह एकीकृत घटकों के साथ एक आरएचईएल-आधारित लिनक्स वितरण (हम क्लाउड लिनक्स का उपयोग करते हैं): हमारे पैच के साथ एक लिनक्स कर्नेल, एक हाइपरविजर , पैरेलल क्लाउड स्टोरेज घटक, एक नया एनाकोंडा-आधारित इंस्टॉलर, समानताएं वर्चुअल ऑटोमेशन कंटेनर और वर्चुअल मशीन और कई मशीनों के प्रबंधन के लिए एक सुविधाजनक वेब-आधारित पैनल है। क्लाउड सर्वर के प्रबंधन और निगरानी के लिए कंसोल उपयोगिताओं। हमारा परीक्षण इनमें से प्रत्येक घटक को शामिल करता है।

प्रस्तावना

वर्तमान में, समानताएं क्लाउड सर्वर की कार्यक्षमता का 98% ऑटोटेस्ट द्वारा परीक्षण किया जा रहा है। और अगर हम समानताएं सर्वर नंगे धातु 4.0 (पीसीएस 6.0 के पूर्ववर्ती) के परीक्षण के लिए 180 अलग-अलग परीक्षण किए, तो पीसीएस 6.0 में पहले से ही उनमें से 600 थे। मुझे यह आरक्षण देना चाहिए कि उत्पाद की बारीकियों ने परीक्षण पर ही अपनी छाप छोड़ दी: हम केवल भौतिक लोगों पर स्वचालित परीक्षण चलाते हैं। सेलेनियम पर साइटों के लिए सर्वर और हमारे परीक्षण किसी भी परीक्षण से भिन्न होते हैं स्वयं परीक्षणों की जटिलता, उनके कॉन्फ़िगरेशन का परिष्कार और अवधि (परीक्षण 1 घंटे से 1 सप्ताह तक रह सकते हैं)।

ताकि आप हमारे परीक्षण के दायरे की कल्पना कर सकें, मैं कुछ आंकड़े दूंगा: पीसीएस 6.0 आरटीएम में हमने 572 परीक्षणों का उपयोग किया और 2.5 महीनों में 2959 परीक्षण लॉन्च किए, जो लगभग 294 मशीन दिन हैं। और हमने 260 अद्वितीय परीक्षणों के साथ नवीनतम अपडेट में से एक का परीक्षण किया और 4800 लॉन्च किए।



लेकिन हमेशा ऐसा नहीं था। हाल ही में, कुछ साल पहले, हमारे पास उन्हें चलाने के लिए कई ऑटोटेस्टर और सर्वर नहीं थे। हमने प्रत्येक मशीन पर मैन्युअल रूप से उत्पाद स्थापित किए, मैन्युअल रूप से प्रत्येक ऑटो परीक्षण शुरू किया, मैन्युअल रूप से बग ट्रैकर में बग बनाए। लेकिन समय के साथ, कारों की संख्या 20 से बढ़कर 100 हो गई, परीक्षणों की संख्या 180 से 600 हो गई, जिन्हें समय-समय पर चलाने की आवश्यकता नहीं है, लेकिन प्रत्येक निर्माण पर। और समय के साथ, हम ऐसी परीक्षण प्रणाली के लिए आए, जो है।

स्व-परीक्षण की सामान्य योजना

स्वचालित परीक्षण चलाने के लिए बुनियादी ढांचा काफी सरल है और इसमें कई सेवाएं शामिल हैं:

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

विधानसभा के बाद प्रत्येक निर्माण परीक्षण के कई चरणों से गुजरता है:

• बेसिक वैलिडेशन टेस्ट
• प्रदर्शन और तनाव परीक्षणों को मापने के लिए निरंतर, नियमित परीक्षण, बेंचमार्क चलाना

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

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

अन्य सेवाओं से जानकारी प्राप्त करने वाले अनुसूचक कर सकते हैं:

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

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



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



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



ऊपर दिए गए स्क्रीनशॉट से पता चलता है कि परीक्षण पांच नोड्स पर चलाया गया था, परीक्षण क्लाइंट ( pclin-c19 ) से लॉन्च किया गया था, और स्वयं नोड्स पर नहीं, समानांतर नोड क्लाउड सर्वर दो नोड्स पर स्थापित किया गया था, आईपी पते का एक पूल उपयोग के लिए प्रत्येक नोड के लिए आरक्षित था। कंटेनर और आभासी मशीनों के लिए आईपी पते।

परीक्षण के सफल समापन पर, परिनियोजन प्रणाली परिणामों को परीक्षण रिपोर्ट प्रणाली में निर्यात करती है, गतिविधियां नष्ट हो जाती हैं, और सर्वर का उपयोग अन्य परीक्षण चलाने के लिए किया जाता है।

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



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



डायनेमिक्स में देखने के लिए कि नोड्स के पूरे परीक्षण पूल के साथ क्या हो रहा है, हमारे पास एक ग्राफ है।



इसलिए, हम हमेशा जानते हैं कि हमारे सर्वर क्या कर रहे हैं।

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



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

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

स्वचालित परीक्षण के बारे में क्या दिलचस्प है?