हम स्वचालन का अनुकूलन करते हैं: हमने 3-4 बार पुराने घटनाक्रमों को संरक्षित करते हुए ऑटोटेस्ट को कैसे तेज किया

परियोजनाओं पर ऑटो परीक्षणों की आवश्यकता है। लेकिन, जैसा कि वे कहते हैं, स्वाद और रंग पर स्वचालन अलग हो सकता है। हम एक ऐसी परियोजना में आए जहां पहले से ही ऑटोटेस्ट थे, और कवरेज में सुधार करने और मौलिक क्रांति के बिना परीक्षणों के पारित होने में तेजी लाने में सक्षम थे। हमने इसे कैसे किया, इसके बारे में बिल्ली के तहत।

परियोजना के बारे में कुछ शब्द

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

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

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

हम कैसे अराजकता में आए

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

रिफैक्टरिंग

सबसे पहले, हमने आंशिक रूप से पुराने परीक्षणों के कोड को फिर से काम किया, जो अधिक आधुनिक डिजाइन पैटर्न पर निर्भर थे।

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

परमाणु दृष्टिकोण

नए परीक्षणों के निर्माण में तेजी लाने और पुराने लोगों के समर्थन को सरल बनाने के लिए, हम बोझिल एंड-टू-एंड मामलों से चले गए हैं।

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

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

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

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

Mokirovanie

हमारे परीक्षणों के लॉन्च के परिणाम पर एक अस्थिर परीक्षण बेंच के प्रभाव को बाहर करने के लिए, हमने एक नकली सर्वर लॉन्च किया। इसके बाद हमने किन फैसलों पर विचार किया और क्यों ओखेटटॉकॉकवेबसर्वर चुना, मैंने पहले ही हैबे पर लिखा है ।

नतीजतन, परीक्षणों के बाहरी कारणों के कारण एपिसोडिक रूप से गिरने वाले लोगों की हिस्सेदारी में काफी कमी आई।

कोटलिन डी.एस.एल.

समानांतर में, हमने परीक्षणों को अधिक पठनीय बनाया।

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

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

सामान्य तौर पर, यह सब ऑटोटेस्ट्स के कवरेज को तेजी से बढ़ाने के लिए संभव बनाता है। यदि पहले नए टेस्ट सूट को लागू करने में 16-20 घंटे लगते हैं, तो नए दृष्टिकोण के साथ, परीक्षणों की जटिलता के आधार पर, 4 से 12 घंटे लगते हैं (और समर्थन के लिए श्रम लागत 16-24 से 8-12 घंटे तक कम हो गई थी। सप्ताह)।

लेख लेखक: रुस्लान अब्दुलिन

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

PPS हमारे ब्लॉग लेखों को और अधिक रोचक बनाने में हमारी सहायता करें: docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZMioioGXhvr7Y7tw/viewform ।