🔯 👊🏼 🕉️ Odnoklassniki पर स्केलिंग Android परीक्षण 🧓🏽 👊 👩🏿‍🤝‍👨🏽

नमस्कार! मेरा नाम रोमन इवानित्सकी है, मैं ओडनोक्लास्निकिकी परीक्षण स्वचालन टीम में काम करता हूं। 70 मिलियन से अधिक उपयोगकर्ताओं के साथ ओके एक बहुत बड़ी सेवा है। अगर हम मोबाइल उपकरणों के बारे में बात करते हैं, तो अधिकांश एंड्रॉइड चलाने वाले स्मार्टफोन पर OK.RU का उपयोग करता है। इस कारण से, हम अपने Android एप्लिकेशन का परीक्षण करने के बारे में बहुत गंभीर हैं। इस लेख में मैं हमारी कंपनी में स्वचालित परीक्षण के विकास की कहानी बताऊंगा।

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

इतिहास का हिस्सा

ओडनोक्लास्निक में पहले ऑटोटेस्ट्स को सेलेनियम में लिखा गया था, उनके लॉन्च के लिए उन्होंने जेनकिंस, सेलेनियम ग्रिड को सेलेनियम हब और सेलेनियम नोड के एक सेट के साथ उठाया।

त्वरित समाधान, त्वरित शुरुआत, त्वरित लाभ - सही।

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

उस समय, स्वचालित परीक्षण बुनियादी ढांचा इस तरह दिखता था:

हालांकि, सेलेनियम नोड की मात्रा 200 से अधिक या उसके बराबर होने के साथ, हब लोड का सामना नहीं कर सका। अब इस समस्या का अध्ययन किया जा चुका है, और इसीलिए ज़लेनियम या हर किसी का पसंदीदा सेलेनॉइड जैसे उपकरण दिखाई दिए। लेकिन 2014 में कोई मानक समाधान नहीं था, इसलिए हमने अपना खुद का बनाने का फैसला किया।

न्यूनतम आवश्यकताओं को परिभाषित किया जो सेवा को पूरा करना चाहिए:

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

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

समन्वयक

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

समन्वयक की एक विशेषता यह है कि यह सभी नोड प्रबंधकों को तथाकथित खेतों में एकीकृत करता है।

यह खेत जैसा दिखता है। आधे से अधिक संसाधनों का उपयोग किया जाता है, और सभी नोड्स ऑनलाइन:

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

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

समन्वयक की एपीआई बहुत सरल है: वर्तमान में उपयोग किए गए संसाधनों की वर्तमान राशि के लिए सेवा का अनुरोध करना, इसकी सीमा प्राप्त करना और कुछ संसाधन शुरू करना या रोकना संभव है।

नोड मैनेजर

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

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

इंटरेक्शन

परीक्षण ऊपर वर्णित बुनियादी ढांचे के साथ बातचीत करता है: यह आवश्यक संसाधनों के अनुरोध के साथ समन्वयक को संबोधित करता है, समन्वयक इस कार्य को निष्पादन की आवश्यकता के रूप में बचाता है।

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

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

दोष सहिष्णुता को विभिन्न डेटा केंद्रों में DNS फ़ायरवॉल के पीछे कई समन्वयक उदाहरणों के प्रक्षेपण द्वारा सुनिश्चित किया जाता है। यह डेटा केंद्र या सर्वर के साथ समस्या के मामले में काम करने की स्थिति तक पहुंच की गारंटी देता है।

नतीजतन, हमें एक समाधान मिला जो शुरू में निर्धारित सभी आवश्यकताओं को पूरा करता था। यह 2015 से लगातार काम कर रहा है और इसकी प्रभावशीलता साबित हुई है।

एंड्रॉयड

जब एंड्रॉइड पर परीक्षण की बात आती है, तो आमतौर पर दो मुख्य दृष्टिकोण होते हैं। सबसे पहले वेबड्राइवर का उपयोग करना है - यह है कि सेलेंड्रोइड और ऐपियम कैसे काम करते हैं। दूसरा - देशी उपकरणों के साथ काम करने में, इस तरह लागू किया गया रोबोटियम, यूआई ऑटोमेकर या एस्प्रेसो।

इन दृष्टिकोणों के बीच मूलभूत समानताएं डिवाइस को प्राप्त करना और ब्राउज़र प्राप्त करना है।

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

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

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

यह है कि डिवाइस मैनेजर के लिए पहला एपीआई कैसे दिखता है - इसकी मदद से आप उपकरणों की एक सूची प्राप्त कर सकते हैं, एपीके इंस्टॉल / अनइंस्टॉल कर सकते हैं, परीक्षण चला सकते हैं और परिणाम प्राप्त कर सकते हैं।

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

खेत तैयार है - आप फोन कनेक्ट कर सकते हैं।

कई लोग इस तस्वीर से परिचित हैं। मैंने सुना है कि यदि आप एंड्रॉइड फार्मों में लगे हुए हैं, तो आप हर दिन नरक में हैं।

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

Android एमुलेटर चलाने के लिए क्या आवश्यक है?

सबसे पहले, आपको उपयोगिताओं के एक सेट के साथ एक एंड्रॉइड एसडीके की आवश्यकता है।

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

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

हालांकि, ऐसी योजना में एक ख़ासियत है - प्रणाली आपको एक विशिष्ट AVD पर केवल एक उदाहरण एमुलेटर चलाने की अनुमति देती है।

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

प्रदर्शन

एवीडी के साथ काम करने के परिणामों के आधार पर, हमने कई आंतरिक सिफारिशें विकसित की हैं:

86 , ARM . dev/kvm Linux HAXM- Mac Windows
GPU- . , . , , , Android-
.
, localhost,

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

उनके बीच का अंतर यह है कि डिफ़ॉल्ट में सेलेनॉइड में अप्पियम , पड़ोसी और "क्लीन" एमुलेटर का उपयोग किया गया है। इसके अलावा, सेलेनॉइड को अधिक सामुदायिक समर्थन है।

2018 के अंत में, CloudNode-Manager बनाया गया था, यह समन्वयक से संपर्क करता है, कार्यों को प्राप्त करता है और क्लाउड में आदेशों का उपयोग करके लॉन्च किया जाता है। लोहे की मशीनों के बजाय, यह सेवा एक-क्लाउड के संसाधनों का उपयोग करती है - ओडनोक्लास्निक के अपने निजी बादल।

हम डिवाइस मैनजर को समन्वयक के साथ काम करने का तरीका सिखाकर स्केलिंग हासिल करने में कामयाब रहे। ऐसा करने के लिए, मुझे डिवाइस प्रकार (आभासी / वास्तविक) का अनुरोध करने की क्षमता जोड़ने के लिए डिवाइस प्रबंधक एपीआई को बदलना होगा।

यदि आप एक मशीन से 250 एमुलेटर पर ADB Install चलाने का प्रयास करते हैं तो यही होता है।

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

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

लेकिन सब कुछ इतना रसपूर्ण नहीं है। आपने देखा होगा कि अब तक परीक्षणों की गुणवत्ता के बारे में कुछ नहीं कहा गया है।

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

हमने इस समस्या से कैसे निपटा? उन्होंने बस रोबोटियम से एस्प्रेसो के लिए सब कुछ कॉपी किया, और यह अच्छा हो गया ... वास्तव में, नहीं।

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

अब परीक्षण इस तरह दिखता है:

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

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

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

QueueRunner में एक परीक्षण प्रवाह है - यह परीक्षण के जीवन चक्र की निगरानी करता है। अब हम जो डिफ़ॉल्ट प्रवाह का उपयोग करते हैं, उसमें पाँच चरण होते हैं:

उपकरण प्राप्त करना। इस बिंदु पर, Devicemanager समन्वयक के माध्यम से एक वास्तविक या आभासी डिवाइस का अनुरोध करता है।
. APK , – , .
,

नतीजतन, पांच सरल कदम हमारी सेवा में पूरे परीक्षण जीवन चक्र हैं।

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

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

QueueRunner और Devicemanager ने हमें संसाधनों की मात्रा के अनुकूल होने की क्षमता प्रदान की है। अब हम पूरे फार्म को स्केल कर सकते हैं, एमुलेटर के उपयोग के लिए धन्यवाद, अर्थात, लगभग असीमित संख्या में आभासी उपकरणों ने हमें बहुत अधिक परीक्षण चलाने का अवसर दिया, लेकिन अगर किसी कारण से संसाधन उपलब्ध नहीं हैं, तो सेवा उनके लौटने का इंतजार करेगी और लॉन्च के नुकसान नहीं होगा। हम केवल हमारे लिए उपलब्ध संसाधनों का उपयोग करते हैं, तदनुसार, कुछ समय बाद परिणाम अभी भी प्राप्त किए जाएंगे और उसी समय सीआई अवरुद्ध नहीं होंगे। और सबसे महत्वपूर्ण बात यह है कि परीक्षण के बुनियादी ढांचे और परीक्षण अब अलग हैं।
अब, Android पर परीक्षण चलाने के लिए, आपको बस हमें एक परीक्षण APK और परीक्षणों की एक सूची देनी होगी।

हम वर्चुअल मशीनों पर सेलेनियम फार्म से क्लाउड में एंड्रॉइड टेस्ट लॉन्च करने के लिए एक लंबा रास्ता तय कर चुके हैं। हालांकि, यह रास्ता अभी तक पूरा नहीं हुआ है।

विकास की प्रक्रिया

आइए देखें कि परीक्षण की अवसंरचना विकास प्रक्रिया से कैसे संबंधित है और परीक्षक और डेवलपर्स इसे कैसे देखते हैं।

हमारी Android टीम मानक GitFlow का उपयोग करती है:

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

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

रिपोर्टिंग

यह इस प्रकार है कि स्टेटस रिपोर्टिंग कैसी दिखती है:

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

यह दो प्रक्षेपणों की तुलना कैसे दिखता है:

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

यदि कम से कम एक इकाई परीक्षण या एंड-टू-एंड परीक्षण की कुछ सीमा से अधिक गिरती है, तो मर्ज अवरुद्ध हो जाएगा।

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

सारांश

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

यह 2016 में एक सप्ताह के लिए परीक्षण चलाने के समय की तरह लग रहा था - पचास मिनट या उससे अधिक समय तक।

अब यह कैसा दिखता है:

यह चार्ट औसत कारोबारी दिन के 2 घंटे से अधिक समय तक चलने वाले रन दिखाता है। चलने का समय अधिकतम 15 मिनट तक कम हो गया था, रनों की संख्या में स्पष्ट रूप से वृद्धि हुई।

Odnoklassniki पर स्केलिंग Android परीक्षण