इस गाइड में बताया गया है कि Firebase Test Lab. इस गाइड का इस्तेमाल करने के लिए, आपके पास ऐसा इंस्ट्रुमेंटेशन टेस्ट होना चाहिए जिसे आपने या आपकी टीम ने लिखा हो. यह टेस्ट, Espresso या UI Automator Android टेस्ट फ़्रेमवर्क का इस्तेमाल करता हो. इंस्ट्रुमेंटेशन टेस्ट 45 तक चल सकते हैं डिजिटल डिवाइसों पर 60 मिनट तक और वर्चुअल डिवाइसों पर 60 मिनट तक.
बाद के चरणों में, आप अपने ऐप्लिकेशन के APK और Firebase के लिए आपके टेस्ट का APK.
(ज़रूरी नहीं) अपने ऐप्लिकेशन में स्क्रीनशॉट लाइब्रेरी जोड़ना
Firebase Test Lab में एक लाइब्रेरी (testlab-instr-lib) शामिल होती है. इसका इस्तेमाल, इंस्ट्रुमेंटेशन टेस्ट चलाते समय, AndroidX के ScreenCapture की मदद से लिए गए किसी भी स्क्रीनशॉट को प्रोसेस करने के लिए किया जा सकता है. जैसे, Espresso टेस्ट फ़्रेमवर्क का इस्तेमाल करके लिखे गए टेस्ट.
इस सेक्शन में, AndroidX लाइब्रेरी की मदद से ScreenCapture
ऑब्जेक्ट बनाने और testlab-instr-lib का इस्तेमाल करके उन्हें प्रोसेस करने का तरीका बताया गया है.
इंस्ट्रूमेंटेशन टेस्ट पूरा होने के बाद, Firebase कंसोल में कैप्चर किए गए स्क्रीनशॉट देखे जा सकते हैं.
ऐप्लिकेशन का नमूना आज़माएं
इस सुविधा को आज़माने के लिए, NotePad का सैंपल ऐप्लिकेशन डाउनलोड करें. स्क्रीनशॉट लेने की सुविधा पहले से ही नोटपैड प्रोजेक्ट में शामिल किया गया है.
पहला चरण. अपने प्रोजेक्ट में स्क्रीनशॉट लाइब्रेरी जोड़ें
आपके टेस्ट प्रोजेक्ट की रूट-लेवल सेटिंग की Gradle फ़ाइल (
settings.gradle.kts
याsettings.gradle
), Google की Maven रिपॉज़िटरी जोड़ें हरrepositories
सेक्शन में:pluginManagement { repositories { // Add the following line: google() // Google's Maven repository mavenCentral() gradlePluginPortal() } } dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { // Add the following line: google() // Google's Maven repository mavenCentral() } } // ...
आपके मॉड्यूल (ऐप्लिकेशन-लेवल) की Gradle फ़ाइल (आम तौर पर) में
<project>/<app-module>/build.gradle.kts
या<project>/<app-module>/build.gradle
), इसके लिए कोई डिपेंडेंसी जोड़ें Test Lab स्क्रीनशॉट लाइब्रेरी.dependencies { // ... // Add Test Lab's instrumentation test screenshot library: androidTestImplementation("com.google.firebase:testlab-instr-lib:0.2") // ...
अपने टेस्ट की
AndroidManifest.xml
फ़ाइल में,FirebaseScreenCaptureProcessor
को<instrumentation>
एलिमेंट के अंदर मेटा-डेटा टैग में रजिस्टर करें. आपके पास प्रोसेसर को तर्क के साथ ब्राउज़ करें (इसे देखें AndroidJUnitRunner रेफ़रंस के लिए दस्तावेज़ देखें.<instrumentation // Check that you have the following line (if not, add it): android:name="androidx.test.runner.AndroidJUnitRunner" // Specifies AndroidJUnitRunner as the test runner android:targetPackage="com.your.package.name"> // Add the following: <meta-data android:name="screenCaptureProcessors" android:value="com.google.firebase.testlab.screenshot.FirebaseScreenCaptureProcessor" /> </instrumentation> ...
अपने ऐप्लिकेशन की
AndroidManifest.xml
फ़ाइल में,<manifest>
एलिमेंट में ये लाइनें जोड़ें:<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
अपनी
AndroidManifest.xml
फ़ाइल में,<manifest>
टैग में ये लाइनें जोड़कर, अपने ऐप्लिकेशन के लिए सिस्टम की अनुमतियां तय करें. अगर आपको टेस्ट करना है Android 10 (एपीआई लेवल 29) या इसके बाद वाले वर्शन पर,WRITE_EXTERNAL_STORAGE
को छोड़ दें अनुमति (आपके ऐप्लिकेशन को इस अनुमति की ज़रूरत नहीं है, डिवाइस पर स्क्रीनशॉट लिख सकते हैं).<manifest ... > <!-- WRITE_EXTERNAL_STORAGE is not needed on Android 10 (API level 29) or higher. --> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.INTERNET"/> ... </manifest>
दूसरा चरण. टेस्ट के दौरान स्क्रीनशॉट लेना
अपने टेस्ट के किसी भी समय स्क्रीनशॉट लेना हो, तो
AndroidX लाइब्रेरी से Screenshot.capture()
तरीका. इससे एक
ScreenCapture
ऑब्जेक्ट बनता है.
ScreenCapture
ऑब्जेक्ट पर process()
को कॉल करने पर, उसे AndroidManifest.xml
में रजिस्टर किए गए ScreenCaptureProcessor का इस्तेमाल करके प्रोसेस किया जाता है. ध्यान दें कि
अगर कोई प्रोसेसर रजिस्टर नहीं है, तो BasicScreenCaptureProcessor
का इस्तेमाल किया जाता है.
आपने FirebaseScreenCaptureProcessor
रजिस्टर किया है, इसलिए आपके स्क्रीनशॉट को FirebaseScreenCaptureProcessor
के ज़रिए प्रोसेस किया जाएगा. साथ ही, Firebase Test Lab के साथ टेस्ट चलाने पर, ये नतीजों के साथ आपके लिए उपलब्ध होंगे.
ScreenCapture
बनाने के लिए, इस्तेमाल के उदाहरण:
एपीआई बिल्ड पर फ़ुल स्क्रीनकैप्चर करें.VERSION_CODES.JELLY_BEAN_MR2 और ऊपर:
Screenshot.capture()
किसी भी एपीआई लेवल पर गतिविधि का
ScreenCapture
लें. ध्यान दें कि यह यह विकल्प Build.VERSION_CODES.JELLY_BEAN_MR2 से कम कीमत वाले डिवाइसों के लिए ही उपलब्ध है.@Rule public ActivityTestRule<MainActivity> activityRule = new ActivityTestRule<>(MainActivity.class); ... Screenshot.capture(activityRule.getActivity()); ...
Screenकैप्चर को प्रोसेस करने के लिए, इस्तेमाल के उदाहरण
FirebaseScreenCaptureProcessor
की मदद सेScreenCapture
को प्रोसेस करने के लिए:Screenshot.capture().process();
किसी तय
ScreenCaptureProcessor
के ज़रिएScreenCapture
को प्रोसेस करें (इससे आपको पेमेंट प्रोसेस करने वाली कंपनी को रजिस्टर करने की ज़रूरत नहीं पड़ती):Set<ScreenCaptureProcessor> processors = new HashSet<>(); processors.add(new FirebaseScreenCaptureProcessor()); Screenshot.capture().process(processors);
ScreenCapture
का नाम और फ़ॉर्मैट सेट करें. इसके बाद, रजिस्टर किया गया प्रोसेसर:Screenshot.capture().setName("myscreenshot").setFormat(CompressFormat.JPEG).process();
चरण 3. टेस्ट बनाएं और चलाएं
अपना ऐप्लिकेशन बनाएं और APK टेस्ट करें (देखें अपने ऐप्लिकेशन की जांच करना देखें).
APK फ़ाइलों को Firebase कंसोल के Test Lab डैशबोर्ड पर अपलोड करें.
आखिर में, अपना टेस्ट चलाएं.
चौथा चरण. टेस्ट के स्क्रीनशॉट देखना
टेस्ट पूरा होने के बाद, Firebase कंसोल में लिए गए किसी भी स्क्रीनशॉट को देखा जा सकता है.
टेस्ट टैब में, पूरा हो चुका टेस्ट चुनें. इसके बाद, नतीजे टैब पर क्लिक करें.
जांच को फिर से चुनें. इसके बाद, दिखने वाले स्क्रीनशॉट टैब पर क्लिक करें.
(ज़रूरी नहीं) टेस्ट की अन्य सुविधाएं चालू करना
टेस्ट को चलाने से पहले, नीचे दी गई सुविधाओं को चालू किया जा सकता है Test Lab:
ऑर्केस्ट्रेटर चालू करें
Android Test Orchestrator एक ऐसा टूल है जो आपके ऐप्लिकेशन के हर इंस्ट्रूमेंटेशन टेस्ट को अलग-अलग चलाता है. Test Lab हमेशा Orchestrator के नए वर्शन का इस्तेमाल करता है.
Test Lab के लिए Orchestrator को चालू करने के लिए, इंस्ट्रुमेंटेशन टेस्ट के सेटअप में, अतिरिक्त विकल्प > Orchestrator के साथ चलाएं पर क्लिक करें.
Orchestrator का इस्तेमाल करने पर, आपको ये फ़ायदे मिलते हैं:
- शेयर की गई कोई स्थिति नहीं है. हर जांच अपने-आप होती है इंस्ट्रुमेंटेशन इंस्टेंस, इसलिए सभी परीक्षणों में एक शेयर स्थिति जमा नहीं होती है.
- अलग-अलग क्रैश. अगर कोई टेस्ट क्रैश हो जाता है, तो सिर्फ़ इंस्ट्रुमेंटेशन बंद कर दिया जाता है. साथ ही, आपके सुइट में अन्य टेस्ट अब भी चल सकते हैं.
ध्यान रखें कि Orchestrator का इस्तेमाल करने पर, हर टेस्ट में अपना इंस्ट्रूमेंटेशन इंस्टेंस चलता है. इसका मतलब है कि हर टेस्ट केस के बाद, ऐप्लिकेशन प्रोसेस को फिर से शुरू किया जाता है. दौड़ने के समय में हुई बढ़ोतरी की वजह से, आपकी कंपनी की परफ़ॉर्मेंस पर असर पड़ सकता है कोटा के इस्तेमाल या बिल किए गए समय पर को रोकने के लिए आपने अपने डिवाइसों की सीमा पार कर ली है टाइम आउट की सीमाएं तय करें. अगर आप अपने ऐप्लिकेशन की तो यह ओवरहेड छोटा हो जाएगा.
Orchestrator के लिए अन्य विकल्प सेट करने के लिए, environmentVariables
फ़ील्ड के ज़रिए उन्हें बताएं. उदाहरण के लिए, clearPackageData
का इस्तेमाल करने के लिए, gcloud में इस विकल्प का इस्तेमाल करें:
--environment-variables clearPackageData=true
sharding की सुविधा चालू करना
परीक्षण शार्डिंग, परीक्षणों के एक सेट को ऐसे उप-समूहों (शर्ड) में विभाजित करती है जो और अलग से लिखा जा सकता है. Test Lab हर शार्ड को अपने आप समानांतर रूप से चलाता है कई तरह के डिवाइसों का इस्तेमाल करके, जांच के पूरे सेट को कम समय में पूरा करता है.
उदाहरण के लिए, अगर आपने N शर्ड बनाए हैं, तो चुने गए हर डिवाइस के लिए, Test Lab एक जैसे N डिवाइसों को स्पिन अप करता है और हर डिवाइस पर टेस्ट का सबसेट चलाता है. इसका मतलब है कि शार्ड टेस्ट केस की वजह से, हर डिवाइस के लिए कई टेस्ट एक्ज़िक्यूशन हो सकते हैं. हालांकि, बिना शार्ड वाले टेस्ट केस की वजह से, हर टेस्ट में एक ही टेस्ट लागू होता है डिवाइस. Test Lab के कॉन्सेप्ट सीखने के लिए, यह देखें मुख्य सिद्धांत.
Firebase कंसोल में टेस्ट शार्डिंग चालू करने के लिए, यह तरीका अपनाएं:
इंस्ट्रुमेंटेशन टेस्ट सेटअप में, अन्य विकल्प पर क्लिक करें.
शर्ड करना सेक्शन में, उन शर्ड की संख्या डालें जिन्हें आपको चलाना है.
टेस्ट शार्ड के लिए बिलिंग
Test Lab, AndroidJUnitRunner के पहले से मौजूद sharding mechanism का इस्तेमाल करके, आपके शर्ड लागू करता है. खाली शार्ड (बिना असाइन किए शार्ड) को स्पिन करने से बचने के लिए टेस्ट केस), आपके पास मौजूद शार्ड की संख्या बनाएं, टेस्ट केस की कुल संख्या से कम होना चाहिए. इसके तरीके के आधार पर टेस्ट केस को चलने में ज़्यादा समय लगता है, इसलिए आम तौर पर 2-10 टेस्ट असाइन करना अच्छा रहता है केस प्रति शार्ड.
बिलिंग के बारे में ज़्यादा जानकारी पाने के लिए, इस्तेमाल, कोटा, और बिलिंग लेख पढ़ें.