👨🏿‍🌾 🚰 🤰 पहली बार हम ऐप सेंटर की कोशिश करते हैं और अपने अनुभव के बारे में बताते हैं 🧦 😣 🦗

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

यह लेख WaveAccess के लोगों द्वारा लिखा गया था ।

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

सैकड़ों Android डिवाइस, OS के विभिन्न संस्करणों के साथ iPhones, और उपकरणों का एक अलग विकर्ण QA इंजीनियरों को असली मोबाइल उपकरणों और ऑपरेटिंग सिस्टम के विभिन्न संस्करणों पर "पकड़ने" दोषों का काम देता है। लेकिन कुछ लोग 10, 20, 50 उपकरणों पर एक ही मैनुअल स्क्रिप्ट चला सकते हैं। इस तरह के कार्यों के लिए धन्यवाद, हमने स्वचालित परीक्षण के हमारे कौशल को पंप किया, खासकर मोबाइल उपकरणों पर। लेकिन चलो ईमानदार रहें: ऑटोटेस्ट चलाने के लिए 20 वास्तविक उपकरणों के साथ भी बुनियादी ढांचे का निर्माण और रखरखाव एक सिरदर्द है।

इस लेख में हम यह बताना चाहते हैं कि हमने वास्तविक उपकरणों के चिड़ियाघर में जो एप्लिकेशन विकसित कर रहे हैं उसकी गुणवत्ता की जांच के लिए हमने नई Microsoft ऐप सेंटर सेवा की कोशिश की।

सेवा का उपयोग करने पर सवाल क्यों उठा

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

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

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

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

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

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

IOS ऐप कैसे सेट करें

इसलिए, परीक्षण अवधि का उपयोग करते हुए, जो कार्यक्षमता पर प्रतिबंध नहीं लगाता है, हम Microsoft ऐप केंद्र में अपना iOS एप्लिकेशन बनाते हैं:

एक मंच चुनें:

प्रोजेक्ट में App Center SDK जोड़ें:

pod 'AppCenter'

चूल्हा स्थापित करने के बाद, AppDelegate.swift फ़ाइल खोलें और अपने स्वयं के आयात कमांड के तहत निम्न पंक्तियाँ जोड़ें:

 import AppCenter import AppCenterAnalytics import AppCenterCrashes

उसी फ़ाइल में, निम्नलिखित पंक्तियाँ जोड़ दीं हैंफ़निश्लांचिंग विधि विधि:

 MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ])

इसी तरह की प्रक्रिया उद्देश्य सी के लिए है, अनुदेश का पूर्ण संस्करण यहां है ।

बनाएं!

बिल्ड टैब पर जाएं, हमारी svc सेवा चुनें।

बिल्ड को कॉन्फ़िगर करें। साइन इन करना न भूलें, क्योंकि यह हमारे लिए एक ऐप प्रारूप एप्लिकेशन फ़ाइल बनाता है जिसे वास्तविक उपकरणों पर चलाया जा सकता है:

हो गया! बिल्ड नाउ बटन पर क्लिक करें और बिल्ड की प्रतीक्षा करें।

एंड्रॉइड अनुप्रयोगों के लिए एक समान कहानी, निर्देश यहां है ।

हम आईओएस के लिए पहला परीक्षण शुरू करते हैं

यूनिट- और प्रत्येक प्लेटफॉर्म के लिए देशी परीक्षण असेंबली (एक चेकमार्क है) में शामिल किए जा सकते हैं। हम नीचे विभिन्न उपकरणों पर एटी की कार्यक्षमता के बारे में बताते हैं।

IOS, Android उपकरणों का एक सेट सेट करें, एक सेट में परीक्षण भेजें

टेस्ट, डिवाइस सेट टैब पर जाएं। हम उपकरणों का एक सेट बनाते हैं, जिस पर हम अपने परीक्षण चलाएंगे। चुनने के लिए 250 से अधिक एंड्रॉइड डिवाइस हैं और 200 से अधिक विभिन्न आईओएस डिवाइस (जेनरेशन वर्जन + आईओएस वर्जन) हैं। उपकरणों की एक विस्तृत सूची यहाँ है ।

यहां यह थोड़ा निराशाजनक था कि सवाल का आधिकारिक जवाब, रिलीज के तुरंत बाद नए एप्पल डिवाइस कैसे दिखाई देंगे, "बिक्री के 1-2 महीने बाद" की तरह लगता है।

हम ऐप सेंटर (XCUITest के लिए एक उदाहरण) में लॉन्च के लिए परीक्षण तैयार करते हैं और उन्हें लॉन्च के लिए भेजते हैं। ऐप सेंटर में केवल एप्लिकेशन बनाने की क्षमता है, इसलिए आपको अभी भी स्थानीय स्तर पर अपने मशीन या अपने CI में टेस्ट प्रोजेक्ट का निर्माण करना होगा।

 Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos

Appium- परीक्षण

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

मावेन उपयोगकर्ताओं के लिए प्रोजेक्ट बिल्ड

चरण 1. एक भंडार और निर्भरता जोड़ें

आपको pom.xml फ़ाइल में JCenter रिपॉजिटरी को जोड़ना होगा।

 XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories>

फिर Appium परीक्षणों के विस्तार के लिए एक निर्भरता जोड़ें

 XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency>

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

चरण 2. एक बूट प्रोफ़ाइल जोड़ें

स्निपेट को <p> में अपने pom.xml में कॉपी करें। अगर पोम फाइल में <प्रोफाइल> सेक्शन गायब है, तो आपको इसे बनाने की आवश्यकता है। सक्रियण के बाद, प्रोफाइल हमारे परीक्षण कक्षाओं और लक्ष्य / अपलोड फ़ोल्डर में सभी निर्भरता को पैक करता है, TestCloud पर अपलोड करने के लिए तैयार है।

ग्रेडल उपयोगकर्ताओं के लिए बनाएँ

चरण 1. रिपोजिटरी और निर्भरता

हम सुनिश्चित करते हैं कि प्रोजेक्ट रूट फ़ोल्डर में build.gradle में JCenter रिपॉजिटरी सक्रिय है:

 gradle allprojects { repositories { jcenter() } }

अनुप्रयोग फ़ोल्डर में build.gradle के लिए निम्न स्निपेट जोड़ें:

 gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0')

ग्रैडल 3.0 के साथ शुरू, androidTestCompile को पदावनत किया जाता है । इसके बजाय, आपको AndroidTestIm कार्यान्वयन की आवश्यकता है।

चरण 2. पीएम फ़ाइल की पीढ़ी को स्वचालित करें

अपलोडर को काम करने के लिए, pom.xml फ़ाइल की आवश्यकता है। बिल्ड फ़ोल्डर में निम्न स्निपेट जोड़ें। एप्लिकेशन फ़ोल्डर में ताकि pom-file स्वचालित रूप से एकत्र हो जाए:

 gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml")

टेस्ट में बदलाव

चरण 1. आयात जोड़ें

अपनी परीक्षा कक्षाओं में पैकेज आयात करें:

 Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule;

चरण 2. TestWatcher का एक उदाहरण बनाएँ

प्रत्येक JUnit नियम परीक्षण वर्ग (या आधार परीक्षण वर्ग) में जोड़ें:

 Java @Rule public TestWatcher watcher = Factory.createWatcher();

चरण 3. ड्राइवर का प्रकार बदलें

घोषित होने पर ड्राइवर का प्रकार बदलें, या तो AndroidDriver <MobileElement> से एन्हांसमेंटएंड्रॉयडड्राइवर <MobileElement>, या IOSDriver <MobileElement> से एन्हांस्डIOSDriver / MobileElement>

 Java private static EnhancedAndroidDriver<MobileElement> driver;

चरण 4. ड्राइवर को अद्यतन करना

हम ड्राइवर इंस्टेंस को बदलते हैं ताकि फॉर्म की रेखाएं:

 Java driver = new AndroidDriver<MobileElement>(url, capabilities);

... दिखने में बदल गया:

 Java driver = Factory.createAndroidDriver(url, capabilities);

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

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

 Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); }

ऐप केंद्र परीक्षण के लिए डाउनलोड करें

लोडिंग प्रक्रिया इस प्रकार है:

ऐप सेंटर टेस्ट अपलोड कमांड जेनरेट करें। दस्तावेज़ीकरण (EN) - एक परीक्षण रन शुरू करना ।
हम लक्ष्य / अपलोड फ़ोल्डर में परीक्षण कक्षाएं और सभी निर्भरताएँ पैक करते हैं

खोल:

mvn -DskipTests -P तैयार-अपलोड पैकेज
डाउनलोड करना और परीक्षण शुरू करना

पूरा होने पर, हम सूची से प्रत्येक डिवाइस पर परिणाम देख सकते हैं:

परिणाम, लॉग, रिपोर्ट के साथ स्क्रीन

प्रत्येक iOS या Android उपकरणों पर, आप एक विस्तृत लॉग और परीक्षण क्रैश के निदान के लिए स्क्रीनशॉट देख सकते हैं:

समय अंतराल के साथ-साथ सभी लॉन्च के आंकड़े:

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

निष्कर्ष

हैरानी की बात है कि एप्लिकेशन के निरंतर एकीकरण से लेकर सतत वितरण तक की पूरी रिलीज़ प्रक्रिया एक ही स्थान पर दी गई है: Microsoft App Center CI बिल्ड, टेस्ट, स्टोर पर तैनाती, एनालिटिक्स, क्रैशलीटिक्स प्रदान करता है।

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

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

Microsoft App Center ने हमें प्रारंभिक मापदंडों के अनुसार व्यवस्थित किया: यह एकीकरण के संदर्भ में बहुत मांग नहीं है, लेकिन यह सभी समर्थित कार्यों को प्रदान करता है, कठिन समर्थन को समाप्त करता है। हम परियोजना पर सेवा का उपयोग करने की योजना बनाते हैं, क्योंकि यह गुणवत्ता सुनिश्चित करते हुए उपकरणों के कार्यों को हल करता है।

पहली बार हम ऐप सेंटर की कोशिश करते हैं और अपने अनुभव के बारे में बताते हैं