टेस्ट लैब की समस्या का हल & अक्सर पूछे जाने वाले सवाल

iOS Android

इस पेज पर, Firebase Test Lab की मदद से टेस्ट चलाने से जुड़ी समस्याओं को हल करने के बारे में जानकारी दी गई है. साथ ही, अक्सर पूछे जाने वाले सवालों के जवाब दिए गए हैं. ऐसी समस्याएं भी दस्तावेज़ में शामिल की जाती हैं जिनके बारे में पहले से जानकारी है. अगर आपको अपनी ज़रूरत के हिसाब से जानकारी नहीं मिल रही है या आपको ज़्यादा मदद चाहिए, तो Firebase Slack पर #test-lab चैनल में शामिल हों या Firebase की सहायता टीम से संपर्क करें.

समस्या का हल

मेरे टेस्ट को पूरा होने में इतना समय क्यों लग रहा है?

Test Labकैटलॉग में ज़्यादा क्षमता वाला डिवाइस चुनने पर, टेस्ट ज़्यादा तेज़ी से शुरू हो सकते हैं. अगर किसी डिवाइस की क्षमता कम है, तो जांच में ज़्यादा समय लग सकता है. अगर चुने गए डिवाइसों की क्षमता से ज़्यादा टेस्ट शुरू किए जाते हैं, तो टेस्ट पूरे होने में ज़्यादा समय लग सकता है.

डिवाइस की क्षमता के किसी भी लेवल पर चल रहे टेस्ट में ज़्यादा समय लग सकता है. इसकी वजह ये हो सकती हैं:

• ट्रैफ़िक, जिससे डिवाइस की उपलब्धता और टेस्ट की स्पीड पर असर पड़ता है.
• डिवाइस या इन्फ़्रास्ट्रक्चर में गड़बड़ियां, जो कभी भी हो सकती हैं. यह देखने के लिए कि Test Lab के लिए किसी इन्फ़्रास्ट्रक्चर की समस्या की शिकायत की गई है या नहीं, Firebase का स्टेटस डैशबोर्ड देखें.

Test Lab में डिवाइस की क्षमता के बारे में ज़्यादा जानने के लिए, Android और iOS के लिए डिवाइस की क्षमता के बारे में जानकारी देखें.

मुझे टेस्ट के अधूरे नतीजे क्यों मिल रहे हैं?

आम तौर पर, टेस्ट के नतीजे साफ़ तौर पर न मिलने की वजह, टेस्ट रन रद्द होना या बुनियादी ढांचे से जुड़ी गड़बड़ियां होती हैं.

बुनियादी ढांचे से जुड़ी गड़बड़ियां, Test Lab की अंदरूनी समस्याओं की वजह से होती हैं. जैसे, नेटवर्क की गड़बड़ियां या डिवाइस के काम करने के तरीके में अचानक बदलाव. Test Lab कई बार बुनियादी ढांचे से जुड़ी गड़बड़ियां होने पर, टेस्ट रन को अंदरूनी तौर पर बंद कर देता है. ऐसा वह किसी नतीजे के न मिलने की रिपोर्ट करने से पहले करता है. हालांकि, failFast का इस्तेमाल करके, इन रीट्राय को बंद किया जा सकता है.

गड़बड़ी की वजह पता करने के लिए, यह तरीका अपनाएं:

1. Firebase के स्टेटस डैशबोर्ड पर जाकर देखें कि क्या कोई ऐसी समस्या है जिसके बारे में पहले से जानकारी है.

2. Test Lab में टेस्ट को फिर से चलाकर देखें कि समस्या फिर से होती है या नहीं.

   ध्यान दें: Test Lab, बुनियादी ढांचे से जुड़ी गड़बड़ियों के लिए आपसे शुल्क नहीं लेता.

3. अगर हो सके, तो किसी दूसरे डिवाइस या डिवाइस टाइप पर टेस्ट चलाएं.

अगर समस्या बनी रहती है, तो Firebase Slack पर #test-lab चैनल में मौजूद Test Lab टीम से संपर्क करें.

शार्डिंग की वजह से मेरे टेस्ट ज़्यादा समय तक क्यों चले?

शार्डिंग की वजह से, आपकी जांचों को पूरा होने में ज़्यादा समय लग सकता है. ऐसा तब होता है, जब आपने जितने शार्ड तय किए हैं उनकी संख्या, Test Lab में इस्तेमाल किए जा सकने वाले डिवाइसों की संख्या से ज़्यादा हो. इस समस्या से बचने के लिए, किसी दूसरे डिवाइस पर स्विच करके देखें. किसी दूसरे डिवाइस को चुनने के बारे में ज़्यादा जानकारी के लिए, डिवाइस की क्षमता लेख पढ़ें.

मेरी परीक्षा शुरू होने में इतना समय क्यों लग रहा है?

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

ऐप्लिकेशन तैयार होने के बाद, टेस्ट के एक्ज़ीक्यूशन शेड्यूल किए जाते हैं. ये तब तक कतार में रहते हैं, जब तक कोई डिवाइस इसे चलाने के लिए तैयार नहीं हो जाता. जब तक सभी टेस्ट एक्ज़ीक्यूशन पूरे नहीं हो जाते, तब तक मैट्रिक्स का स्टेटस "लंबित" रहेगा. भले ही, टेस्ट एक्ज़ीक्यूशन कतार में हों या चालू हों.

ध्यान दें: टेस्टिंग के लिए उपलब्ध डिवाइस का इंतज़ार करने में लगने वाला समय, बिलिंग के समय में नहीं गिना जाता.

मेरे टेस्ट को पूरा होने में इतना समय क्यों लग रहा है?

टेस्ट पूरा होने के बाद, डिवाइस से टेस्ट आर्टफ़ैक्ट डाउनलोड किए जाते हैं. इसके बाद, उन्हें प्रोसेस किया जाता है और Cloud Storage पर अपलोड किया जाता है. इस चरण में लगने वाला समय, आर्टफ़ैक्ट की संख्या और साइज़ पर निर्भर करता है.

ऐप्लिकेशन से डेटा नहीं मिल रहा है और स्क्रीनशॉट नहीं मिल रहे हैं

टेस्ट एक्ज़ीक्यूशन आर्टफ़ैक्ट (जैसे कि स्क्रीनशॉट और लॉग फ़ाइलें) Google Cloud Storage में सेव किए जाते हैं. साथ ही, इन्हें सीधे Firebase कंसोल में रेंडर किया जाता है. अगर टेस्ट पिछले 90 दिनों में किया गया था, तो पक्का करें कि आपने प्रोजेक्ट लेवल की भूमिकाएं (प्रोजेक्ट के मालिक, प्रोजेक्ट एडिटर या प्रोजेक्ट व्यूअर) असाइन की हों. कृपया यह भी पक्का करें कि आपके प्रोजेक्ट या संगठन के लिए, Cloud Audit Logging की सुविधा चालू न हो.

अगर टेस्ट 90 दिन से ज़्यादा समय पहले किया गया था, तो हो सकता है कि टेस्ट के आर्टफ़ैक्ट अपने-आप मिट गए हों. Test Lab डैशबोर्ड में जांच के नतीजे टैब पर क्लिक करके, नतीजे के बकेट कॉन्फ़िगरेशन की जांच की जा सकती है. डिफ़ॉल्ट नतीजे वाले बकेट को इस तरह कॉन्फ़िगर किया जाता है कि वह ऑब्जेक्ट को 90 दिनों तक सेव रख सके.

अपने टेस्ट आर्टफ़ैक्ट को ज़्यादा समय तक सेव रखने के लिए, --results-bucket फ़्लैग के साथ gcloud firebase test android run कमांड चलाएं. इसके बाद, नतीजे वाले बकेट का नाम डालें. ज़्यादा जानकारी के लिए, gcloud firebase test android run रेफ़रंस दस्तावेज़ पर जाएं.

मुझे इंस्ट्रुमेंटेशन टेस्ट केस के नतीजे अधूरे क्यों मिल रहे हैं या क्यों नहीं मिल रहे हैं?

इंस्ट्रुमेंटेशन टेस्ट चलाने पर, आपको टेस्ट से जुड़ी गड़बड़ियां दिख सकती हैं. इनसे पता चलता है कि टेस्ट के नतीजे अधूरे हैं. इनमें Test run failed to complete. Expected x tests, received y जैसे मैसेज शामिल होते हैं. यहां y, x से कम है. इस गड़बड़ी का मतलब है कि Test Lab, टेस्ट केस के शुरू या खत्म होने के मार्कर के लिए logcat को पार्स नहीं कर सका. ये मार्कर आम तौर पर AndroidJUnitRunner जनरेट करता है.

इस समस्या की आम वजहें यहां दी गई हैं:

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

अक्सर पूछे जाने वाले सवाल

Test Lab के लिए, बिना किसी शुल्क के उपलब्ध कोटा क्या हैं? अगर मेरे पास पैसे खत्म हो जाएं, तो मुझे क्या करना चाहिए?

Firebase Test Lab डिवाइसों पर टेस्टिंग के लिए और Cloud API इस्तेमाल करने के लिए, बिना किसी शुल्क के कोटा उपलब्ध कराता है. ध्यान दें कि टेस्टिंग कोटा, Firebase के स्टैंडर्ड प्राइसिंग प्लान का इस्तेमाल करता है. हालांकि, Cloud API के कोटे ऐसा नहीं करते.

• जांच करने के लिए कोटा

  टेस्टिंग के कोटे, टेस्ट चलाने के लिए इस्तेमाल किए गए डिवाइसों की संख्या के आधार पर तय किए जाते हैं. Firebase स्पार्क प्लान में, उपयोगकर्ताओं के लिए टेस्टिंग का एक तय कोटा होता है. इसके लिए, उनसे कोई शुल्क नहीं लिया जाता. Blaze प्लान के लिए, समय के साथ Google Cloud का इस्तेमाल बढ़ने पर, आपके कोटे बढ़ सकते हैं. अगर आपने टेस्टिंग का कोटा पूरा कर लिया है, तो अगले दिन तक इंतज़ार करें. इसके अलावा, अगर आपने Spark प्लान लिया है, तो Blaze प्लान पर अपग्रेड करें. अगर आपने पहले से ही Blaze प्लान लिया हुआ है, तो कोटा बढ़ाने का अनुरोध किया जा सकता है. ज़्यादा जानकारी के लिए, टेस्टिंग कोटा देखें.

  Google Cloud कंसोल में जाकर, टेस्टिंग के लिए तय किए गए कोटे के इस्तेमाल की जानकारी देखी जा सकती है.

• Cloud Testing API का कोटा

  Cloud Testing API के लिए, कोटा की दो सीमाएं तय की गई हैं: हर प्रोजेक्ट के लिए, हर दिन के अनुरोधों की संख्या और हर प्रोजेक्ट के लिए, हर 100 सेकंड में किए जाने वाले अनुरोधों की संख्या. Google Cloud कंसोल में जाकर, अपने इस्तेमाल को मॉनिटर किया जा सकता है.

• Cloud Tool Results API का कोटा

  Cloud Tool Results API के लिए, दो तरह की कोटा सीमाएं तय की गई हैं: हर प्रोजेक्ट के लिए, हर दिन की क्वेरी की सीमा और हर प्रोजेक्ट के लिए, हर 100 सेकंड में की जाने वाली क्वेरी की सीमा. Google Cloud कंसोल में जाकर, अपने इस्तेमाल को मॉनिटर किया जा सकता है.

  एपीआई की सीमाओं के बारे में ज़्यादा जानने के लिए, Test Lab के लिए Cloud API कोटा देखें. अगर आपने एपीआई के लिए तय की गई सीमा पूरी कर ली है, तो:

  • ज़्यादा कोटे के लिए अनुरोध सबमिट करें. इसके लिए, Google Cloud कंसोल में जाकर सीधे अपने कोटे में बदलाव करें. ध्यान दें कि ज़्यादातर सीमाएं डिफ़ॉल्ट रूप से ज़्यादा से ज़्यादा पर सेट होती हैं. इसके अलावा,

  • Google Cloud कंसोल में अनुरोध फ़ॉर्म भरकर या Firebase की सहायता टीम से संपर्क करके, एपीआई के लिए ज़्यादा कोटा का अनुरोध करें.

मुझे कैसे पता चलेगा कि मेरे बैकएंड तक पहुंचने वाला ट्रैफ़िक Test Lab से आ रहा है?

अपने बैकएंड से, यह पता लगाया जा सकता है कि ट्रैफ़िक, Firebase-hosted टेस्ट डिवाइसों से आ रहा है या नहीं. इसके लिए, सोर्स आईपी पते की तुलना हमारी आईपी रेंज से करें.

क्या Test Lab, VPC-SC के साथ काम करता है?

Test Lab, वीपीसी-एससी के साथ काम नहीं करता. यह Test Lab के इंटरनल स्टोरेज और उपयोगकर्ताओं के नतीजों वाले बकेट के बीच, ऐप्लिकेशन और अन्य टेस्ट आर्टफ़ैक्ट को कॉपी करने की प्रोसेस को ब्लॉक करता है.

मैं Test Lab में फ़्लेकी टेस्ट का पता कैसे लगाऊं?

हमारा सुझाव है कि अपने टेस्ट में फ़्लेकी व्यवहार का पता लगाने के लिए, --num-flaky-test-attempts विकल्प का इस्तेमाल करें. डिफ़्लेक रीरन के लिए, आपसे शुल्क लिया जाता है या उन्हें आपके रोज़ के कोटे में गिना जाता है. यह सामान्य टेस्ट एक्ज़ीक्यूशन की तरह ही होता है.

निम्नलिखित का ध्यान रखें:

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

ध्यान दें: इन्फ़्रास्ट्रक्चर से जुड़ी गड़बड़ियां, डिफ़्लेक की सुविधा से अलग होती हैं. साथ ही, इनकी वजह से डिफ़्लेक की सुविधा फिर से शुरू नहीं होती.

क्या Test Lab को स्मार्टवॉच जैसे पहनने वाले डिवाइसों पर इस्तेमाल किया जा सकता है?

हां! Test Lab, Google Pixel Watch के साथ काम करता है. अब Google Pixel Watch पर, Wear OS के स्टैंडअलोन ऐप्लिकेशन की जांच की जा सकती है. Test Lab डिवाइसों के बारे में ज़्यादा जानने के लिए, उपलब्ध डिवाइसों पर टेस्ट करें लेख पढ़ें.

क्या Test Lab, Google के नए डिवाइसों के साथ काम करता है?

हां! Test Lab Google Pixel Tablet और Google Pixel Fold के साथ काम करता है. आपके पास अपने स्टैंडअलोन फ़िज़िकल डिवाइसों पर टेस्ट चलाने का विकल्प होता है. Test Lab डिवाइसों के बारे में ज़्यादा जानने के लिए, उपलब्ध डिवाइसों पर टेस्ट करें लेख पढ़ें.

मैं Test Lab में चल रहे टेस्ट का पता कैसे लगाऊं?

अगर Firebase में अपने ऐप्लिकेशन की जांच की जा रही है या Play Console में प्री-लॉन्च रिपोर्ट के लिए जांच की जा रही है, तो यह पता लगाया जा सकता है कि Firebase पर होस्ट किए गए डिवाइस पर कोई जांच की जा रही है या नहीं. इसके लिए, अपनी MainActivity फ़ाइल में सिस्टम प्रॉपर्टी firebase.test.lab देखें. इसके बाद, testLabSetting के लिए बूलियन वैल्यू के आधार पर, अन्य स्टेटमेंट लागू किए जा सकते हैं. ज़्यादा जानकारी के लिए, टेस्ट के बदले गए व्यवहार देखें.

क्या Test Lab Appium, Flutter/FlutterDriver, ReactNative/Jest या Cucumber के साथ काम करता है?

इनमें से कुछ आइटम हमारे रोडमैप में शामिल हैं. हालांकि, फ़िलहाल हम इन टेस्टिंग और ऐप्लिकेशन डेवलपमेंट प्लैटफ़ॉर्म के साथ काम करने का वादा नहीं कर सकते. हालांकि, अगर आपने अपने ऐप्लिकेशन को ऐसे फ़्रेमवर्क की मदद से बनाया है जो Espresso के साथ काम करता है (उदाहरण के लिए, Flutter), तो Espresso का इस्तेमाल करके इंस्ट्रुमेंटेशन टेस्ट लिखा जा सकता है. इसके बाद, Test Lab में टेस्ट चलाया जा सकता है.

क्या Test Lab, अस्पष्ट किए गए ऐप्लिकेशन की टेस्टिंग के साथ काम करता है? उदाहरण के लिए, ProGuard या R8?

Test Lab में, कोड को उलझाने या उसे समझने लायक बनाने की सुविधा नहीं होती. ऐप्लिकेशन के चलने की संभावना है. हालांकि, धुंधला किया गया ऐप्लिकेशन डेटा, जैसे कि स्टैक ट्रेस, लॉग में धुंधला किया गया दिखेगा.

क्या Test Lab पर टेस्टिंग करते समय, फ़ोल्ड किए जा सकने वाले डिवाइस को अलग-अलग तरीके से फ़ोल्ड किया जा सकता है और अलग-अलग पोज़िशन में रखा जा सकता है?

हां! अपने फ़ोल्ड किए जा सकने वाले डिवाइस को फ़ोल्ड करने की अलग-अलग स्थितियों और पोस्चर में टेस्ट किया जा सकता है.

फ़ोल्ड किए जा सकने वाले डिवाइस, अलग-अलग तरह से फ़ोल्ड किए जा सकते हैं. जैसे, FLAT (पूरी तरह से खुला) या HALF_OPENED (पूरी तरह से खुला और पूरी तरह से बंद के बीच).

वहीं, डिवाइस की ओरिएंटेशन और फ़ोल्ड करने की स्थिति को पोस्चर कहा जाता है. उदाहरण के लिए, टेबलटॉप पोस्चर, जो हॉरिज़ॉन्टल ओरिएंटेशन में HALF_OPENED स्टेट है या बुक पोस्चर, जो वर्टिकल ओरिएंटेशन में HALF_OPENED स्टेट है.

अगर इंस्ट्रूमेंटेशन टेस्ट किए जा रहे हैं, तो अलग-अलग स्थितियों और पोस्चर में टेस्ट करने के लिए, Jetpack WindowManager लाइब्रेरी का इस्तेमाल किया जा सकता है. साथ ही, फ़ोल्ड किए जा सकने वाले डिवाइसों पर अपने ऐप्लिकेशन की जांच करना दस्तावेज़ में दिए गए निर्देशों का पालन किया जा सकता है.

इसके अलावा, उपलब्ध स्थितियां डिवाइस के हिसाब से होती हैं और इनके साथ इंटरैक्ट करने के लिए, 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 Pixel Fold (मॉडल आईडी 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},
]

Samsung Galaxy Z Fold4 (मॉडल आईडी 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},
]

अगर मेरे पास कोई ऐप्लिकेशन नहीं है, तो क्या मैं Test Lab को आज़मा सकता/सकती हूं?

Firebase के अन्य प्रॉडक्ट के उलट, Test Lab का इस्तेमाल करने के लिए, आपको Firebase SDK टूल जोड़ने की ज़रूरत नहीं है. अगर आपके पास पहले से कोई ऐप्लिकेशन नहीं है, तो ऑनलाइन APK डाउनलोड किया जा सकता है. इसके अलावा, AndroidX GitHub रिपॉज़िटरी में मौजूद किसी सैंपल से ऐप्लिकेशन और टेस्ट APK बनाया जा सकता है. ध्यान दें कि रोबो टेस्ट चलाने के लिए, आपको सिर्फ़ अपने ऐप्लिकेशन की APK फ़ाइल की ज़रूरत होती है. वहीं, इंस्ट्रुमेंटेशन टेस्ट के लिए, आपको ऐप्लिकेशन और टेस्ट APK, दोनों की ज़रूरत होती है. ये दोनों, सोर्स कोड से बनाए जाते हैं. ज़्यादा जानकारी के लिए, इंस्ट्रुमेंटेड टेस्ट के बारे में पढ़ें.

Test Lab सुविधाओं के बारे में ज़्यादा जानने के लिए, Firebase Test Lab की मदद से Android के लिए टेस्टिंग शुरू करना लेख पढ़ें.

स्क्रीनशॉट की तुलना करके टेस्टिंग करने के लिए, कौनसे डिवाइस सबसे सही हैं?

स्क्रीनशॉट की तुलना करके टेस्टिंग में, टेस्ट के दौरान ली गई स्क्रीन इमेज की तुलना, ऐसी गोल्डन इमेज से की जाती है जो उम्मीद के मुताबिक काम करने की जानकारी देती हैं. इसके आधार पर टेस्ट के दावे किए जाते हैं. ऐसा हो सकता है कि कुछ डिवाइस टाइप पर इस तरह के टेस्ट, अन्य डिवाइस टाइप के मुकाबले ज़्यादा आसानी से टूट जाएं. हमारा सुझाव है कि इस तरह के टेस्ट के लिए, Arm (*.arm) एम्युलेटर डिवाइसों को टारगेट करें. आर्म इम्यूलेटर डिवाइस, ऐसी इमेज का इस्तेमाल करते हैं जो Android Studio के ‘जेनेरिक’ इम्यूलेटर से मिलती-जुलती या एक जैसी होती हैं.

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

क्या Test Lab वर्चुअल डिवाइसों को अपडेट करता है?

हां! वर्चुअल डिवाइसों को तब अपडेट किया जाता है, जब ये बदलाव किए जाते हैं:

1. मौजूदा इमेज में किए गए अपडेट
2. एपीआई के पुराने लेवल बंद किए जा रहे हैं
3. Android के नए एपीआई लेवल जोड़े गए

मैं कवरेज रिपोर्ट कैसे चालू करूं?

कवरेज रिपोर्ट चालू करने के लिए, environmentVariables फ़ील्ड में coverage=true जोड़ें. अगर Android Test Orchestrator का इस्तेमाल किया जा रहा है, तो आपको कवरेज के नतीजों को सेव करने के लिए एक डायरेक्ट्री देनी होगी:

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

अगर Orchestrator का इस्तेमाल नहीं किया जा रहा है, तो फ़ाइल का पाथ तय किया जा सकता है:

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

मुझे डिवाइस की जानकारी कहां मिल सकती है. जैसे, रिज़ॉल्यूशन, काम करने वाले एबीआइ वगैरह?

डिवाइस के बारे में पूरी जानकारी, एपीआई के ज़रिए उपलब्ध होती है. इसे gcloud क्लाइंट से ऐक्सेस किया जा सकता है. इसके लिए, describe कमांड का इस्तेमाल करें:

gcloud firebase test android models describe MODEL

ज्ञात समस्याएं

साइन-इन कैप्चा

रोबोट टेस्ट, ऐसी साइन-इन स्क्रीन को बायपास नहीं कर सकता जिनमें साइन इन करने के लिए, क्रेडेंशियल डालने के अलावा उपयोगकर्ता को कोई और कार्रवाई भी करनी होती है. उदाहरण के लिए, कैप्चा पूरा करना.

यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क के साथ काम करता है

रोबो टेस्ट, उन ऐप्लिकेशन के साथ सबसे अच्छा काम करता है जो Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क से यूआई एलिमेंट का इस्तेमाल करते हैं. इनमें View, ViewGroup, और WebView ऑब्जेक्ट शामिल हैं. अगर आपने Robo test का इस्तेमाल, यूज़र इंटरफ़ेस (यूआई) के अन्य फ़्रेमवर्क का इस्तेमाल करने वाले ऐप्लिकेशन के लिए किया है, तो हो सकता है कि टेस्ट पहली स्क्रीन से आगे न बढ़े. इनमें Unity गेम इंजन का इस्तेमाल करने वाले ऐप्लिकेशन भी शामिल हैं.