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

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

समस्या का हल

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

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

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

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

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

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

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

  1. Firebase के स्टेटस डैशबोर्ड में जाकर, देखें कि क्या कोई समस्या है.
  2. Test Lab में जांच फिर से करें, ताकि यह पुष्टि की जा सके कि समस्या दोबारा आ सकती है या नहीं.

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

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

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

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

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

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

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

अगर एक्सीक्यूशन 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 तक कम करें.
टेस्ट किया जा रहा ऐप्लिकेशन क्रैश हो गया. अपने ऐप्लिकेशन को डीबग करें.

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

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

  • टेस्टिंग कोटा

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

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

  • 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 की सहायता टीम से संपर्क करके, एपीआई के लिए ज़्यादा कोटा का अनुरोध करें.

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

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

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

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

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

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

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

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

इनमें से कुछ आइटम हमारे रोडमैप में शामिल हैं. हालांकि, फ़िलहाल हम इन टेस्टिंग और ऐप्लिकेशन डेवलपमेंट प्लैटफ़ॉर्म के साथ काम करने की कोई गारंटी नहीं दे सकते. हालांकि, अगर आपने ऐप्लिकेशन को किसी ऐसे फ़्रेमवर्क के साथ बनाया है जो Espresso के साथ काम करता है (उदाहरण के लिए, Flutter), तो Espresso का इस्तेमाल करके इंस्ट्रूमेंटेशन टेस्ट लिखा जा सकता है. इसके बाद, 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 कमांड चलाएं.
$ 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},
]
$ 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 के अन्य प्रॉडक्ट की तरह Firebase SDK टूल जोड़ने की ज़रूरत नहीं है. अगर आपके पास पहले से कोई ऐप्लिकेशन नहीं है, तो आपके पास ऑनलाइन APK डाउनलोड करने का विकल्प है. इसके अलावा, AndroidX GitHub रिपॉज़िटरी में मौजूद किसी सैंपल से ऐप्लिकेशन और टेस्ट APK भी बनाया जा सकता है. ध्यान दें कि रोबो टेस्ट चलाने के लिए, आपको सिर्फ़ अपने ऐप्लिकेशन की APK फ़ाइल की ज़रूरत होती है. वहीं, इंस्ट्रूमेंटेशन टेस्ट के लिए, सोर्स कोड से बनाए गए ऐप्लिकेशन और टेस्ट APK, दोनों की ज़रूरत होती है. ज़्यादा जानकारी के लिए, इंस्ट्रूमेंट किए गए टेस्ट के बारे में पढ़ें.

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

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

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

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

  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 command का इस्तेमाल करें:

gcloud firebase test android models describe MODEL

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

रोबो टेस्ट, साइन इन स्क्रीन को बायपास नहीं कर सकता. इन स्क्रीन पर, साइन इन करने के लिए क्रेडेंशियल डालने के अलावा, उपयोगकर्ता को कुछ और कार्रवाइयां भी करनी पड़ती हैं. उदाहरण के लिए, कैप्चा भरना.

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