😥 💈 👏🏽 EDMS के लिए एक मोबाइल एप्लिकेशन के उदाहरण पर ऑटोटेस्ट्स का संगठन 💞 👈🏻 💚

+ बेहतर, लेकिन कम मज़ेदार कवर संस्करण

जल्दी या बाद में, हर कोई एटी पर आता है। जब यह देर से होता है तो स्थिति समझ में आती है, और यह जल्दी कब होता है? और कैसे समझें कि क्या पहले से ही संभव है?

लेख एक टीम के अनुभव पर आधारित है: मैं आपको हमारे पूर्वापेक्षाओं और ऑटोटस्टिंग की शुरुआत के कारणों के बारे में बताता हूं, हमने एटी तत्परता के लिए कौन से मापदंड चुने हैं और अंत में हम कौन से टूल का उपयोग करते हैं। Spoiler: अंत में, कुछ सफल और Xamarin.UITest के साथ बहुत मामलों में नहीं।

उत्पाद के बारे में परिचय

. , , , , , . offline.

-.

सिद्धांत क्या कहता है

उदाहरण के रूप में परीक्षण पिरामिड का उपयोग करके स्वचालन दृष्टिकोण पर विचार करें। पिरामिड के स्तरों के रूप में, मैं उन परीक्षणों का प्रकार ले लूंगा जिनका हम उपयोग करते हैं। अर्थात्, इकाई परीक्षण, एकीकरण परीक्षण और एंड-टू-एंड (E2E) परीक्षण।

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

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

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

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

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

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

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

हमारे साथ ऑटो परीक्षण कैसे आयोजित किए जाते हैं?

प्रत्येक उत्पाद में व्यक्तिगत रूप से इकाई परीक्षण होते हैं, प्रत्येक पीआर पर चलते हैं। वे डेवलपर्स की जिम्मेदारी हैं।

एकीकरण परीक्षण EDMS के साथ वेब सेवा की सहभागिता को सत्यापित करते हैं।

वे एक ग्राहक अनुप्रयोग के संचालन का अनुकरण करते हैं। वे ईडीएस डेटा प्राप्त करने और संशोधित करने के लिए वेब सेवा विधियों की ओर मुड़ते हैं।

सर्वर पक्ष के एक नए संस्करण के प्रत्येक निर्माण के बाद चलाएँ।

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

एकीकरण और अंत-टू-एंड परीक्षण अब परीक्षकों द्वारा किया जा रहा है।

हमें मोबाइल एप्लिकेशन पर एंड-टू-एंड की आवश्यकता क्यों है?

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

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

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

इसलिए, हमारे लिए मोबाइल अनुप्रयोगों के यूआई परीक्षण शुरू करने के प्रारंभिक लक्ष्य थे:

मुख्य आवेदन मामलों की एटी कवरेज;
रिलीज से पहले प्रतिगमन में कीड़े की संख्या को कम करना।

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

कुछ समय बाद, एक और लक्ष्य जोड़ा गया - मैन्युअल प्रतिगमन परीक्षणों की संख्या को कम करना।

और परीक्षण में स्वचालन शुरू करने का समय कब है?

परीक्षण स्वचालन पर शुरू करने से पहले, आपको स्वचालन के लिए अपने आवेदन की तत्परता का मूल्यांकन करना चाहिए। और इस प्रक्रिया के लिए आपकी तत्परता भी।

स्थिर कार्यक्षमता

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

विकास की योजनाएँ

स्वचालन को तभी लागू किया जाना चाहिए जब आपके आवेदन में भविष्य, आने वाले वर्षों के लिए विकास योजनाएं हों। एक एप्लिकेशन के लिए ऑटोटेस्ट क्यों नहीं बदलता है?

साधन

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

कैसे तय करें?

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

पहले तैयार किए गए लक्ष्य बचाव में आए, और मुख्य एक कार्यात्मक परीक्षण था। इसलिए, हमने छोटी शुरुआत की।

परिणामस्वरूप, हमारे परीक्षण:

दिन में एक बार दौड़ें (यह समस्या का स्रोत खोजने के लिए पर्याप्त है अगर कुछ होता है);
हमारे सर्वर पर स्थानीय रूप से चलाएं;
दो उपकरणों (iOS और Android) पर;
एंड्रॉइड के लिए अब लगभग 50 परीक्षण हैं, रन लगभग एक घंटे (विधानसभा के साथ) लेता है;
iOS के लिए - लगभग 40 परीक्षण, रन में लगभग 30 मिनट लगते हैं;
परीक्षण Xamarin.UITest का उपयोग करके लिखे गए हैं;
वे TFS में स्वचालित रूप से निर्मित होते हैं, TFS में उसी स्थान पर हम रनों के परिणामों की निगरानी करते हैं।

Xamarin.UITest के बारे में थोड़ा

यह Xamarin.iOS और Xamarin.Android (ऑब्जेक्टिव-सी / स्विफ्ट के लिए समर्थन और जावा की भी घोषणा की गई है) पर परियोजनाओं के लिए स्वचालित यूआई परीक्षण के लिए एक रूपरेखा है। टेस्ट C # NUnit का उपयोग करते हुए लिखे गए हैं। सामग्री परियोजनाओं को आसानी से एकीकृत किया जा सकता है।

फ्रेमवर्क के संचालन का सिद्धांत दो घटकों पर आधारित है: एक तत्व (क्वेरी) की खोज करना और इसके साथ किसी भी क्रिया को करना (क्रिया), उदाहरण के लिए, एक स्वाइप को दबाने या निष्पादित करना।

उदाहरण के लिए, एक ऐसा परीक्षण है जो अमान्य लॉगिन दर्ज करते समय त्रुटि प्रदर्शित करता है:

public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
  {
    var wrongLogin = TestsSettings.UserLogin + "1";
    app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
    app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
    Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
  }


private string ErrorMessage => 
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;

इसमें प्रयुक्त क्रेडेंशियल इनपुट विधि:

public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
    {
      app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
      app.EnterText(Resources.Identifiers.LoginEdit, login);
      app.EnterText(Resources.Identifiers.PasswordEdit, password);
      app.Tap(Resources.Identifiers.LoginButton);
    }

इस उदाहरण में, मानक फ्रेमवर्क विधियों का उपयोग किया जाता है - एक तत्व की प्रतीक्षा करना, पाठ में प्रवेश करना, एक तत्व पर क्लिक करना।

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

हमारे लिए अप्रत्याशित होना

इंटरफ़ेस तत्वों को संबोधित करने से कभी-कभी हमें वह उम्मीद नहीं होती, जिसकी हमें उम्मीद थी।

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

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

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

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

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

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

कुछ कप्तान परिणाम

स्वचालन को लागू करें यदि यह समझ में आता है।

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

ठीक है, पिरामिड के सिद्धांत के बारे में मत भूलना।

EDMS के लिए एक मोबाइल एप्लिकेशन के उदाहरण पर ऑटोटेस्ट्स का संगठन