Android एप्लिकेशन के उदाहरण पर मैन्युअल परीक्षण की प्रक्रिया में स्वचालन को लागू करने का अनुभव

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

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

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

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

चलो चलते हैं!

प्रारंभिक बिंदु

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

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

समस्या # 1: बहुत सारे प्रतिगमन परीक्षण

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

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

समस्या नंबर 2: आपको मोबाइल ओएस के सभी संस्करणों पर परीक्षण करने की आवश्यकता है

एक महत्वपूर्ण आवश्यकता ऑपरेटिंग सिस्टम संस्करणों की एक विस्तृत श्रृंखला पर हमारे मोबाइल एप्लिकेशन की उपलब्धता है। उदाहरण के लिए, लेखन के समय एंड्रॉइड के मामले में, ये 17 से 28 तक एपीआई स्तर हैं।

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

समाधान: मैनुअल परीक्षण प्रक्रिया में स्वचालन को एकीकृत करें

परीक्षण स्वचालन का एक विशिष्ट कार्य प्रतिगमन परीक्षणों को स्वचालित करना है। इसलिए हम आज परीक्षण प्रक्रिया की दक्षता में सुधार करना चाहते हैं और कल विकास के संभावित परिणामों को रोक सकते हैं।

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

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

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

परिणामस्वरूप हम क्या प्राप्त करना चाहते हैं:

1. प्रतिगमन परीक्षण का स्वचालन।
2. परीक्षण प्रबंधन प्रणाली के साथ एकीकरण।
3. क्लाउड डिवाइसों पर ऑटोटेस्ट्स के पैरामीटरयुक्त मैन्युअल शुरुआत की संभावना।
4. भविष्य में समाधान के पुन: उपयोग की संभावना।

अगला, मैं अलग से तकनीकी घटक में थोड़ा विसर्जन के साथ इनमें से प्रत्येक बिंदु के कार्यान्वयन के बारे में बात करूंगा।

सामान्य समाधान कार्यान्वयन योजना

लेकिन पहले, हमें जो मिला उसकी एक सामान्य रूपरेखा:



ऑटो परीक्षण दो तरह से चलते हैं:

1. विलय के बाद CI से या मास्टर से अनुरोध करने के लिए।
2. जेंकिंस जॉब वेब इंटरफेस से मैन्युअल रूप से परीक्षक।

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

परीक्षणों के दौरान, उनके परिणाम TestRail को भेजे जाते हैं। यह उसी तरह से होता है जैसे कि परीक्षक ने मैन्युअल रूप से परीक्षण किया और परिणामों को एक परिचित तरीके से दर्ज किया।

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

• चुने गए प्रत्येक उपकरण पर परीक्षण के मामलों का परिणाम देखता है;
• मैन्युअल रूप से किसी भी परीक्षण मामले की दोबारा जांच कर सकते हैं;
• ऐसे परीक्षण मामले करता है जो अभी तक स्वचालित नहीं हैं, या किसी भी कारण से अनुकूलित नहीं किए जा सकते हैं;
• वर्तमान परीक्षण रन पर अंतिम निर्णय करता है।

अब चलो कार्यान्वयन के वादा किए गए विवरण पर चलते हैं।

1. ऑटो परीक्षण

उपकरण

हमने उपयोगकर्ता इंटरफ़ेस के साथ बातचीत करने के लिए 3 टूल का उपयोग किया:

• एस्प्रेसो।
• बरिस्ता।
• UI ऑटोमेटर।

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

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

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

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

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

कार्यान्वयन

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

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

एक साधारण उदाहरण पर विचार करें। वर्णित टुकड़े में डेटा दर्ज करने और एक कार्रवाई बटन के लिए कई फ़ील्ड शामिल हैं:



स्वयं लॉगिन कार्यक्षमता परीक्षण का कोड:



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

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

उपरोक्त रिपोर्ट में, जेक व्हार्टन कोटलिन में एक कार्यान्वयन देता है, जहां यह परिमित है। हमने पहले से ही इसे दूसरे प्रोजेक्ट पर आजमाया और हमें वास्तव में पसंद आया।

2. परीक्षण प्रबंधन प्रणाली के साथ एकीकरण

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

JUnit RunListener का उपयोग करके टेस्ट रन के दौरान, विभिन्न घटनाओं को पकड़ा जाता है, जैसे कि testRunStarted , testFailure , testFinished , जिसमें हम TestRail को परिणाम भेजते हैं। यदि आप AndroidJUnitRunner का उपयोग करते हैं, तो उसे आधिकारिक दस्तावेज में वर्णित एक निश्चित तरीके से आपके RunListener के बारे में सूचित करना होगा ।

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

एनोटेशन को लागू करने के लिए कोड:



यह केवल विवरण से सही स्थान पर अपना मूल्य पाने के लिए बना हुआ है:

3. क्लाउड उपकरणों पर ऑटोटेस्ट्स की मैन्युअल शुरुआत

जेनकिंस जॉब में स्टार्टअप परिमाणीकरण

ऑटोटेस्ट्स की मैन्युअल शुरुआत को व्यवस्थित करने के लिए, हम फ्री-स्टाइल जेनकिंस जॉब का उपयोग करते हैं। यह विकल्प इसलिए चुना गया क्योंकि कंपनी को पहले से ही अन्य क्षेत्रों में जेनकिंस जॉब के साथ इसी तरह के काम का कुछ अनुभव था, विशेष रूप से DevOps इंजीनियरों के साथ, जिन्हें उन्होंने सहर्ष साझा किया था।

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

पैरामीटर शामिल हैं:

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

आइए डिवाइस चयन इंटरफ़ेस और परीक्षण सूट के उदाहरण का उपयोग करके हमारे जेनकिंस जॉब के वेब पेज के एक भाग को देखें:



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

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



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

फायरबेस टेस्ट लैब में अंतिम टेस्ट मैट्रिक्स

फायरबेस में डिवाइस मैट्रिक्स में उन उपकरणों द्वारा परीक्षणों का वितरण शामिल है जिन पर वे चलाए गए थे:



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

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

आप एक अलग क्लाउड इंफ्रास्ट्रक्चर पसंद कर सकते हैं जो आपकी परीक्षण प्रक्रिया के साथ भी फिट बैठता है।

4. पुन: उपयोग

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

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

निष्कर्ष

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