यह पृष्ठ फायरबेस टेस्ट लैब के साथ परीक्षण चलाने के बारे में समस्या निवारण सहायता और अक्सर पूछे जाने वाले प्रश्नों के उत्तर प्रदान करता है। ज्ञात मुद्दे भी प्रलेखित हैं। यदि आप जो खोज रहे हैं वह आपको नहीं मिल रहा है या आपको अतिरिक्त सहायता की आवश्यकता है, तो फायरबेस स्लैक पर #टेस्ट-लैब चैनल से जुड़ें या फायरबेस समर्थन से संपर्क करें।
समस्या निवारण
जब आप टेस्ट लैब कैटलॉग में उच्च क्षमता स्तर वाले डिवाइस का चयन करते हैं, तो परीक्षण तेजी से शुरू हो सकते हैं। जब किसी उपकरण की क्षमता कम होती है, तो परीक्षण चलने में अधिक समय लग सकता है। यदि किए गए परीक्षणों की संख्या चयनित उपकरणों की क्षमता से बहुत अधिक है, तो परीक्षणों को समाप्त होने में अधिक समय लग सकता है।
किसी भी स्तर की डिवाइस क्षमता स्तर पर चलने वाले परीक्षणों में निम्नलिखित कारकों के कारण अधिक समय लग सकता है:
- ट्रैफ़िक, जो डिवाइस की उपलब्धता और परीक्षण गति को प्रभावित करता है।
- डिवाइस या बुनियादी ढांचे की विफलता, जो किसी भी समय हो सकती है। यह जांचने के लिए कि क्या टेस्ट लैब के लिए रिपोर्ट किया गया बुनियादी ढांचा है, फायरबेस स्थिति डैशबोर्ड देखें।
टेस्ट लैब में डिवाइस क्षमता के बारे में अधिक जानने के लिए, Android और iOS के लिए डिवाइस क्षमता जानकारी देखें।
अनिर्णीत परीक्षण परिणाम आमतौर पर या तो रद्द किए गए परीक्षण रन या बुनियादी ढांचे की त्रुटियों के कारण होते हैं।
इन्फ्रास्ट्रक्चर त्रुटियाँ आंतरिक परीक्षण लैब समस्याओं, जैसे नेटवर्क त्रुटियों या अप्रत्याशित डिवाइस व्यवहार के कारण होती हैं। टेस्ट लैब अनिर्णायक परिणाम की रिपोर्ट करने से पहले कई बार बुनियादी ढांचे संबंधी त्रुटियों को उत्पन्न करने वाले टेस्ट रन को आंतरिक रूप से रिटायर कर देता है; हालाँकि, आप असफलफ़ास्ट का उपयोग करके इन पुनर्प्रयासों को अक्षम कर सकते हैं।
त्रुटि का कारण निर्धारित करने के लिए, इन चरणों का पालन करें:
- फायरबेस स्थिति डैशबोर्ड में ज्ञात आउटेज की जाँच करें।
यह सत्यापित करने के लिए कि यह प्रतिलिपि प्रस्तुत करने योग्य है, टेस्ट लैब में परीक्षण का पुनः प्रयास करें।
यदि लागू हो तो किसी भिन्न डिवाइस या डिवाइस प्रकार पर परीक्षण चलाने का प्रयास करें।
यदि समस्या बनी रहती है, तो फायरबेस स्लैक पर #test-lab चैनल में टेस्ट लैब टीम से संपर्क करें।
जब आपके द्वारा निर्दिष्ट शार्ड की संख्या टेस्ट लैब में उपयोग के लिए उपलब्ध उपकरणों की संख्या से अधिक हो जाती है, तो शेयरिंग के कारण आपके परीक्षण लंबे समय तक चल सकते हैं। इस स्थिति से बचने के लिए, किसी भिन्न डिवाइस पर स्विच करने का प्रयास करें। किसी भिन्न डिवाइस को चुनने के बारे में अधिक जानकारी के लिए,डिवाइस क्षमता देखें।
जब आप एक परीक्षण अनुरोध सबमिट करते हैं, तो किसी डिवाइस पर परीक्षण चलाने की तैयारी के लिए आपके ऐप को पहले सत्यापित किया जाता है, पुनः हस्ताक्षरित किया जाता है, आदि। आम तौर पर, यह प्रक्रिया कुछ सेकंड से भी कम समय में पूरी हो जाती है, लेकिन यह आपके ऐप के आकार जैसे कारकों से प्रभावित हो सकती है।
आपका ऐप तैयार होने के बाद, परीक्षण निष्पादन निर्धारित किया जाता है और तब तक कतार में रहता है जब तक कोई डिवाइस इसे चलाने के लिए तैयार नहीं हो जाता। जब तक सभी परीक्षण निष्पादन चलना समाप्त नहीं हो जाते, मैट्रिक्स स्थिति "लंबित" रहेगी (भले ही परीक्षण निष्पादन कतार में हों या सक्रिय रूप से चल रहे हों)।
परीक्षण निष्पादन समाप्त होने के बाद, परीक्षण कलाकृतियों को डिवाइस से डाउनलोड किया जाता है, संसाधित किया जाता है और क्लाउड स्टोरेज पर अपलोड किया जाता है। इस चरण की अवधि कलाकृतियों की मात्रा और आकार से प्रभावित हो सकती है।
परीक्षण निष्पादन कलाकृतियाँ (जैसे स्क्रीनशॉट और लॉग फ़ाइलें) Google क्लाउड स्टोरेज में संग्रहीत की जाती हैं और सीधे फायरबेस कंसोल में प्रस्तुत की जाती हैं। यदि आपका परीक्षण निष्पादन पिछले 90 दिनों के भीतर किया गया था, तो जांचें कि आपने प्रोजेक्ट स्तर की भूमिकाएँ (प्रोजेक्ट स्वामी, प्रोजेक्ट संपादक, या प्रोजेक्ट व्यूअर) सौंपी हैं। कृपया यह भी सुनिश्चित करें कि आपके प्रोजेक्ट या आपके संगठन के लिए क्लाउड ऑडिट लॉगिंग सक्षम नहीं है।
यदि निष्पादन 90 दिन से अधिक पहले किया गया था, तो सबसे अधिक संभावना है कि परीक्षण कलाकृतियाँ स्वचालित रूप से हटा दी गई हैं। आप टेस्ट लैब डैशबोर्ड में टेस्ट परिणाम टैब पर क्लिक करके परिणाम बकेट कॉन्फ़िगरेशन की जांच कर सकते हैं। डिफ़ॉल्ट परिणाम बकेट को ऑब्जेक्ट को 90 दिनों तक बनाए रखने के लिए कॉन्फ़िगर किया गया है।
अपने परीक्षण कलाकृतियों को लंबे समय तक बनाए रखने के लिए, कमांड gcloud firebase test android run
--results-bucket
ध्वज के साथ चलाएँ और परिणाम बकेट के नाम से पास करें। अधिक जानकारी के लिए, gcloud firebase test android run
reference document पर जाएँ।
जब आप इंस्ट्रुमेंटेशन परीक्षण चलाते हैं, तो आपको आंशिक परिणाम दर्शाने वाली परीक्षण त्रुटियाँ दिखाई दे सकती हैं जिनमें Test run failed to complete. Expected x tests, received y
(जहाँ y
x
से कम है)। इस त्रुटि का अर्थ है कि टेस्ट लैब टेस्ट केस प्रारंभ या अंत मार्करों के लिए लॉगकैट को पार्स नहीं कर सका जो आमतौर पर AndroidJUnitRunner द्वारा उत्पन्न होते हैं।
इस समस्या के सामान्य कारण निम्नलिखित हैं:
मुद्दे का विवरण | संभावित समाधान |
---|---|
टाइमआउट के कारण टेस्ट केस नहीं चला। यदि परीक्षणों की कुल अवधि आपके द्वारा निर्दिष्ट टाइमआउट से अधिक या अधिकतम टाइमआउट से अधिक है, तो टेस्ट लैब शेष परीक्षण मामलों को रद्द कर देता है। |
|
परीक्षण मामला पूरा नहीं हो सका क्योंकि यह समय से पहले बंद हो गया या अटक गया। किसी अज्ञात अपवाद या दावा त्रुटि के कारण परीक्षण मामला समय से पहले बंद हो सकता है। परीक्षण मामले अनंत लूप में फंस सकते हैं या आगे बढ़ने में असमर्थ हो सकते हैं, उदाहरण के लिए, यदि ऐप सही दृश्य नहीं दिखाता है और परीक्षण मामला यूआई पर कार्रवाई नहीं कर सकता है। | परीक्षण कहां रुका इसकी जांच के लिए वीडियो और logcat देखें। |
एक कस्टम परीक्षण धावक (विस्तारित AndroidJUnitRunner सहित) अप्रत्याशित रूप से दुर्घटनाग्रस्त हो गया या logcat पर अप्रत्याशित परीक्षण केस प्रारंभ या समाप्ति मार्कर लिख दिया। | अपना टेस्ट रनर कोड जांचें. |
logcat पर अत्यधिक लॉग लिखे गए, जिससे बफ़र दब गया या logcat प्रक्रिया क्रैश हो गई। | logcat में लिखना कम करें। |
परीक्षण के तहत ऐप क्रैश हो गया. | अपने ऐप को डीबग करें. |
अक्सर पूछे जाने वाले प्रश्नों
फायरबेस टेस्ट लैब उपकरणों पर परीक्षण और क्लाउड एपीआई का उपयोग करने के लिए निःशुल्क कोटा प्रदान करता है। ध्यान दें कि परीक्षण कोटा मानक फायरबेस मूल्य निर्धारण योजना का उपयोग करता है, जबकि क्लाउड एपीआई कोटा नहीं करता है।
परीक्षण कोटा
परीक्षण कोटा परीक्षण चलाने के लिए उपयोग किए जाने वाले उपकरणों की संख्या से निर्धारित होता है। फायरबेस स्पार्क योजना में उपयोगकर्ताओं के लिए बिना किसी शुल्क के एक निश्चित परीक्षण कोटा है। ब्लेज़ योजना के लिए, यदि समय के साथ Google क्लाउड का उपयोग बढ़ता है तो आपका कोटा बढ़ सकता है। यदि आप अपने परीक्षण कोटा तक पहुँच गए हैं, तो अगले दिन तक प्रतीक्षा करें या यदि आप वर्तमान में स्पार्क योजना पर हैं तो ब्लेज़ योजना में अपग्रेड करें। यदि आप पहले से ही ब्लेज़ योजना पर हैं, तो आप कोटा बढ़ाने का अनुरोध कर सकते हैं। अधिक जानकारी के लिए, परीक्षण कोटा देखें।
आप Google क्लाउड कंसोल में अपने परीक्षण कोटा उपयोग की निगरानी कर सकते हैं।
क्लाउड परीक्षण एपीआई कोटा
क्लाउड टेस्टिंग एपीआई दो कोटा सीमाओं के साथ आती है: प्रति प्रोजेक्ट प्रति दिन अनुरोध, और प्रति प्रोजेक्ट हर 100 सेकंड के लिए अनुरोध। आप Google क्लाउड कंसोल में अपने उपयोग की निगरानी कर सकते हैं।
क्लाउड टूल परिणाम एपीआई कोटा
क्लाउड टूल परिणाम एपीआई दो कोटा सीमाओं के साथ आता है: प्रति प्रोजेक्ट प्रति दिन प्रश्न, और प्रति प्रोजेक्ट प्रत्येक 100 सेकंड पर प्रश्न। आप Google क्लाउड कंसोल में अपने उपयोग की निगरानी कर सकते हैं।
एपीआई सीमाओं पर अधिक जानकारी के लिए टेस्ट लैब के लिए क्लाउड एपीआई कोटा देखें। यदि आप एपीआई कोटा तक पहुंच गए हैं:
अपने कोटा को सीधे Google क्लाउड कंसोल में संपादित करके उच्च कोटा के लिए अनुरोध सबमिट करें (ध्यान दें कि अधिकांश सीमाएँ डिफ़ॉल्ट रूप से अधिकतम पर सेट हैं), या
Google क्लाउड कंसोल में अनुरोध फ़ॉर्म भरकर या फ़ायरबेस समर्थन से संपर्क करके उच्च एपीआई कोटा का अनुरोध करें।
अपने बैकएंड से, आप हमारी आईपी श्रेणियों के विरुद्ध स्रोत आईपी पते की जांच करके यह निर्धारित कर सकते हैं कि फायरबेस-होस्ट किए गए परीक्षण उपकरणों से ट्रैफ़िक आ रहा है या नहीं।
टेस्ट लैब वीपीसी-एससी के साथ काम नहीं करता है, जो टेस्ट लैब के आंतरिक भंडारण और उपयोगकर्ताओं के परिणाम बकेट के बीच ऐप्स और अन्य परीक्षण कलाकृतियों की प्रतिलिपि को रोकता है।
आपके परीक्षणों में परतदार व्यवहार का पता लगाने के लिए, हम--num-flaky-test-attemptsविकल्प का उपयोग करने की सलाह देते हैं। डिफ्लेक रीरन को सामान्य परीक्षण निष्पादन के समान ही आपके दैनिक कोटा में बिल किया जाता है या गिना जाता है।
निम्नलिखित को ध्यान में रखें:
- विफलता का पता चलने पर संपूर्ण परीक्षण निष्पादन फिर से चलता है। केवल विफल परीक्षण मामलों को पुनः प्रयास करने के लिए कोई समर्थन नहीं है।
- डिफ्लेक रिट्री रन एक ही समय में चलने के लिए निर्धारित हैं, लेकिन समानांतर में चलने की गारंटी नहीं है, उदाहरण के लिए, जब ट्रैफ़िक उपलब्ध उपकरणों की संख्या से अधिक हो जाता है।
हाँ! टेस्ट लैब Google Pixel Watch को सपोर्ट करता है। अब आप Google Pixel Watches पर अपने स्टैंडअलोन वेयर ऐप पर परीक्षण चला सकते हैं। टेस्ट लैब उपकरणों के बारे में अधिक जानने के लिए, उपलब्ध उपकरणों पर परीक्षण देखें।
हाँ! टेस्ट लैब Google Pixel टैबलेट और Google Pixel फोल्ड को सपोर्ट करता है। आप अपने परीक्षण अपने स्टैंडअलोन भौतिक उपकरणों पर चला सकते हैं। टेस्ट लैब उपकरणों के बारे में अधिक जानने के लिए, उपलब्ध उपकरणों पर परीक्षण देखें।
यदि आप फायरबेस में अपने ऐप का परीक्षण कर रहे हैं या प्ले कंसोल में प्री-लॉन्च रिपोर्ट के लिए परीक्षण चला रहे हैं, तो आप सिस्टम प्रॉपर्टी firebase.test.lab
की जांच करके यह पता लगा सकते हैं कि फायरबेस-होस्टेड डिवाइस पर परीक्षण चलाया जा रहा है या नहीं। आपकी MainActivity
फ़ाइल. फिर आप testLabSetting
के लिए बूलियन मान के आधार पर अतिरिक्त कथन निष्पादित कर सकते हैं। अधिक जानकारी के लिए, संशोधित परीक्षण व्यवहार देखें।
हालाँकि इनमें से कुछ आइटम हमारे रोडमैप पर हैं, हम वर्तमान में इन परीक्षण और ऐप विकास प्लेटफार्मों का समर्थन करने के लिए प्रतिबद्धता प्रदान करने में असमर्थ हैं। हालाँकि, यदि आपने अपना ऐप एक ऐसे फ्रेमवर्क के साथ बनाया है जो एस्प्रेसो (उदाहरण के लिए, फ़्लटर) का समर्थन करता है, तो आप एस्प्रेसो का उपयोग करके एक इंस्ट्रूमेंटेशन टेस्ट लिख सकते हैं और फिर टेस्ट लैब में परीक्षण चला सकते हैं।
टेस्ट लैब स्पष्ट रूप से अस्पष्टता या अस्पष्टता को दूर करने का समर्थन नहीं करता है। जबकि ऐप चलने की संभावना है, कोई भी अस्पष्ट ऐप डेटा, जैसे स्टैक ट्रेस, लॉग में अस्पष्ट के रूप में दिखाई देगा।
हाँ! आप अपने फोल्डेबल डिवाइस का फोल्डेबल अवस्थाओं और मुद्राओं में परीक्षण कर सकते हैं।
फोल्डेबल डिवाइस विभिन्न मुड़ी हुई अवस्थाओं में हो सकते हैं, जैसे FLAT
(पूरी तरह से खुला) या HALF_OPENED
(पूरी तरह से खुले और पूरी तरह से बंद के बीच)।
दूसरी ओर, आसन में विशिष्ट डिवाइस ओरिएंटेशन और फोल्डेबल स्थिति शामिल होती है। उदाहरण के लिए, टेबलटॉप आसन, जो क्षैतिज अभिविन्यास में HALF_OPENED
स्थिति है, या पुस्तक आसन, जो लंबवत अभिविन्यास में HALF_OPENED
स्थिति है।
यदि आप इंस्ट्रूमेंटेशन परीक्षण चला रहे हैं, तो आप जेटपैक विंडोमैनेजर लाइब्रेरी का उपयोग कर सकते हैं और विभिन्न स्थितियों और मुद्राओं पर परीक्षण करने के लिए फोल्डेबल दस्तावेज़ों पर अपने ऐप का परीक्षण कर सकते हैं।
वैकल्पिक रूप से, उपलब्ध स्थितियाँ डिवाइस-विशिष्ट होती हैं और adb shell command cmd device_state
उपयोग करके उनसे इंटरैक्ट किया जा सकता है।
- वर्तमान स्थिति को सूचीबद्ध करने के लिए,
adb shell cmd device_state state
चलाएँ। - वर्तमान स्थिति को सेट या ओवरराइड करने के लिए,
adb shell cmd device_state state <IDENTIFIER>
चलाएँ। - स्थिति को रीसेट करने के लिए,
adb shell cmd device_state state reset
चलाएँ। - उपलब्ध स्थितियों की जांच करने के लिए, फोल्डेबल डिवाइस पर
adb shell cmd device_state print-states
कमांड चलाएं।
Google पिक्सेल फ़ोल्ड (मॉडल आईडी felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
सैमसंग गैलेक्सी Z फोल्ड4 (मॉडल आईडी q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
अन्य फायरबेस उत्पादों के विपरीत, आपको टेस्ट लैब का उपयोग करने के लिए फायरबेस एसडीके जोड़ने की आवश्यकता नहीं है। यदि आपके पास पहले से कोई ऐप नहीं है, तो आप ऑनलाइन एक एपीके डाउनलोड कर सकते हैं या एंड्रॉइडएक्स गिटहब रिपॉजिटरी में से किसी एक नमूने से एक ऐप और एक परीक्षण एपीके बना सकते हैं। ध्यान दें कि रोबो टेस्ट चलाने के लिए आपको केवल अपने ऐप की एपीके फ़ाइल की आवश्यकता होती है, जबकि इंस्ट्रूमेंटेशन टेस्ट के लिए ऐप और टेस्ट एपीके दोनों की आवश्यकता होती है जो स्रोत कोड से निर्मित होते हैं। अधिक जानकारी के लिए, यंत्रीकृत परीक्षणों के बारे में पढ़ें।
टेस्ट लैब सुविधाओं के बारे में अधिक जानने के लिए, फायरबेस टेस्ट लैब के साथ एंड्रॉइड के लिए परीक्षण शुरू करें देखें।
स्क्रीनशॉट-डिफ़ परीक्षण वह जगह है जहां परीक्षण दावे परीक्षण चलाने के दौरान प्राप्त स्क्रीन छवियों की तुलना अपेक्षित व्यवहार का प्रतिनिधित्व करने वाली सुनहरी छवियों से करने पर आधारित होते हैं। ऐसे परीक्षण कुछ डिवाइस प्रकारों पर दूसरों की तुलना में अधिक भंगुर हो सकते हैं। हम इस प्रकार के परीक्षणों के लिए आर्म ( *.arm
) एमुलेटर उपकरणों को लक्षित करने की सलाह देते हैं। आर्म एमुलेटर डिवाइस उन छवियों का उपयोग करते हैं जो एंड्रॉइड स्टूडियो 'जेनेरिक' एमुलेटर के समान या समान हैं।
हम यह भी अनुशंसा करते हैं कि आप परीक्षण पुस्तकालयों की जांच करें जो अपेक्षित परिवर्तनों की उपस्थिति में स्क्रीनशॉट परीक्षणों को और अधिक मजबूत बनाने में मदद कर सकते हैं।
हाँ! निम्नलिखित परिवर्तन किए जाने पर वर्चुअल डिवाइस अपडेट किए जाते हैं:
- मौजूदा छवियों में अद्यतन
- पहले के एपीआई स्तरों का अवमूल्यन
- नए Android API स्तर जोड़े गए हैं
कवरेज रिपोर्ट सक्षम करने के लिए, environmentVariables
फ़ील्ड में coverage=true
जोड़ें। यदि आप एंड्रॉइड टेस्ट ऑर्केस्ट्रेटर का उपयोग कर रहे हैं, तो आपको कवरेज परिणामों को संग्रहीत करने के लिए एक निर्देशिका प्रदान करनी होगी:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
यदि आप ऑर्केस्ट्रेटर का उपयोग नहीं कर रहे हैं, तो आप एक फ़ाइल पथ निर्दिष्ट कर सकते हैं:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
विस्तृत डिवाइस जानकारी एपीआई के माध्यम से उपलब्ध है और इसे डिस्क्रिप्शन कमांड का उपयोग करके जीक्लाउड क्लाइंट से एक्सेस किया जा सकता है:
gcloud firebase test android models describe MODEL
ज्ञात पहलु
रोबो परीक्षण साइन-इन स्क्रीन को बायपास नहीं कर सकता है, जिसमें साइन इन करने के लिए क्रेडेंशियल दर्ज करने के अलावा अतिरिक्त उपयोगकर्ता कार्रवाई की आवश्यकता होती है, उदाहरण के लिए, कैप्चा पूरा करना।
रोबो परीक्षण उन ऐप्स के साथ सबसे अच्छा काम करता है जो एंड्रॉइड यूआई फ्रेमवर्क ( View
, ViewGroup
और WebView
ऑब्जेक्ट्स सहित) से यूआई तत्वों का उपयोग करते हैं। यदि आप उन ऐप्स का उपयोग करने के लिए रोबो टेस्ट का उपयोग करते हैं जो अन्य यूआई फ्रेमवर्क का उपयोग करते हैं, जिसमें यूनिटी गेम इंजन का उपयोग करने वाले ऐप्स भी शामिल हैं, तो परीक्षण पहली स्क्रीन से परे खोज किए बिना बाहर निकल सकता है।