बिल्ड मैनेज करने वाले डिवाइसों की मदद से, अपने टेस्ट को स्केल करना

बिल्ड-मैनेज किए गए डिवाइसों से, इंस्ट्रुमेंट की गई ऑटोमेटेड जांचों की परफ़ॉर्मेंस बेहतर होती है. साथ ही, ये ज़्यादा भरोसेमंद होते हैं और इनमें एक जैसी सुविधाएं होती हैं. यह सुविधा, एपीआई लेवल 27 और इससे ऊपर के लेवल के लिए उपलब्ध है. इसकी मदद से, अपने प्रोजेक्ट की Gradle फ़ाइलों में वर्चुअल या रिमोट फ़िज़िकल टेस्ट डिवाइसों को कॉन्फ़िगर किया जा सकता है. Android Gradle प्लगिन, कॉन्फ़िगरेशन का इस्तेमाल करके उन डिवाइसों को पूरी तरह से मैनेज करता है. इसका मतलब है कि वह डिवाइसों को बनाता है, डिप्लॉय करता है, और बंद करता है. ऐसा तब होता है, जब आपकी ऑटोमेटेड जांचें की जाती हैं.

इस सुविधा से, Android Gradle प्लगइन को न सिर्फ़ उन टेस्ट के बारे में जानकारी मिलती है जिन्हें चलाया जा रहा है, बल्कि डिवाइसों के लाइफ़साइकल के बारे में भी जानकारी मिलती है. इससे, टेस्टिंग के अनुभव की क्वालिटी को इन तरीकों से बेहतर बनाया जा सकता है:

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

वर्चुअल बिल्ड-मैनेज डिवाइस बनाना

मॉड्यूल-लेवल की बिल्ड फ़ाइल में, उस वर्चुअल डिवाइस के बारे में बताया जा सकता है जिसका इस्तेमाल आपको अपने ऐप्लिकेशन की टेस्टिंग के लिए करना है. नीचे दिए गए कोड के सैंपल में, एपीआई लेवल 30 पर काम करने वाले Pixel 2 को, बिल्ड-मैनेज किए गए डिवाइस के तौर पर बनाया गया है.

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

डिवाइसों के ग्रुप तय करना

अलग-अलग डिवाइस कॉन्फ़िगरेशन, जैसे कि अलग-अलग एपीआई लेवल और डिवाइसों के नाप या आकार के हिसाब से अपने टेस्ट को बड़े पैमाने पर करने के लिए, एक से ज़्यादा बिल्ड-मैनेज किए गए डिवाइसों को तय किया जा सकता है. साथ ही, उन्हें नाम वाले ग्रुप में जोड़ा जा सकता है. इसके बाद, Android Gradle प्लग इन, ग्रुप में शामिल सभी डिवाइसों पर एक साथ आपकी जांच कर सकता है.

नीचे दिए गए उदाहरण में, दो डिवाइसों को phoneAndTablet नाम के डिवाइस ग्रुप में जोड़ा गया है.

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

टेस्ट चलाना

कॉन्फ़िगर किए गए बिल्ड-मैनेज किए गए डिवाइसों का इस्तेमाल करके जांच करने के लिए, यहां दिया गया निर्देश इस्तेमाल करें. device-name उस डिवाइस का नाम है जिसे आपने Gradle बिल्ड स्क्रिप्ट (जैसे कि pixel2api30) में कॉन्फ़िगर किया है. वहीं, BuildVariant आपके ऐप्लिकेशन का वह बिल्ड वैरिएंट है जिसकी आपको जांच करनी है. जैसे, Debug.

./gradlew device-nameBuildVariantAndroidTest

gradlew device-nameBuildVariantAndroidTest

बिल्ड-मैनेज किए गए डिवाइसों के ग्रुप पर टेस्ट चलाने के लिए, इस कमांड का इस्तेमाल करें.

./gradlew group-nameGroupBuildVariantAndroidTest

./gradlew group-nameGroupBuildVariantAndroidTest

gradlew group-nameGroupBuildVariantAndroidTest

टेस्ट के आउटपुट में, एचटीएमएल फ़ाइल का पाथ शामिल होता है. इस फ़ाइल में टेस्ट रिपोर्ट होती है. आईडीई में चलाएं > टेस्ट का इतिहास पर क्लिक करके, टेस्ट के नतीजों को Android Studio में इंपोर्ट किया जा सकता है, ताकि उनका बेहतर तरीके से विश्लेषण किया जा सके.

टेस्ट शार्डिंग की सुविधा चालू करना

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

किसी टेस्ट रन में इस्तेमाल किए जाने वाले शार्ड की संख्या सेट करने के लिए, अपनी gradle.properties फ़ाइल में यह सेट करें:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

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

टेस्ट पूरे होने पर, Gradle, टेस्ट के नतीजों को .proto फ़ाइल में सेव करता है. यह फ़ाइल, टेस्ट रन में इस्तेमाल किए गए हर शार्ड के लिए होती है.

अपने-आप कॉन्फ़िगर होने वाले टेस्ट डिवाइसों का इस्तेमाल करना

बिल्ड-मैनेज किए गए डिवाइस, एक तरह के एम्युलेटर डिवाइस के साथ काम करते हैं. इसे ऑटोमेटेड टेस्ट डिवाइस (एटीडी) कहा जाता है. इसे इंस्ट्रुमेंटेड टेस्ट चलाने के दौरान, सीपीयू और मेमोरी के संसाधनों को कम करने के लिए ऑप्टिमाइज़ किया गया है. एटीडी, रनटाइम परफ़ॉर्मेंस को कई तरह से बेहतर बनाते हैं:

• पहले से इंस्टॉल किए गए उन ऐप्लिकेशन को हटाएं जो आम तौर पर आपके ऐप्लिकेशन की जांच करने के लिए काम के नहीं होते
• बैकग्राउंड में चलने वाली कुछ ऐसी सेवाओं को बंद करें जो आम तौर पर आपके ऐप्लिकेशन की टेस्टिंग के लिए काम की नहीं होती हैं
• हार्डवेयर रेंडरिंग की सुविधा बंद करना

शुरू करने से पहले, पक्का करें कि आपने Android Emulator को अपडेट करके, उपलब्ध सबसे नया वर्शन इंस्टॉल किया हो. इसके बाद, मॉड्यूल-लेवल की बिल्ड फ़ाइल में, बिल्ड मैनेज किए गए डिवाइस को तय करते समय, "-atd" इमेज तय करें. इसे यहां दिखाया गया है:

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

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

एटीडी इमेज से क्या हटाया जाता है?

एटीडी, हेडलेस मोड में काम करने के साथ-साथ परफ़ॉर्मेंस को भी ऑप्टिमाइज़ करते हैं. इसके लिए, वे उन ऐप्लिकेशन और सेवाओं को हटा देते हैं या बंद कर देते हैं जिनकी आम तौर पर आपके ऐप्लिकेशन के कोड की टेस्टिंग के लिए ज़रूरत नहीं होती. यहां दी गई टेबल में, एटीडी इमेज से हटाए गए या बंद किए गए कॉम्पोनेंट के बारे में खास जानकारी दी गई है. साथ ही, यह भी बताया गया है कि ये कॉम्पोनेंट क्यों काम के नहीं हो सकते.

Firebase टेस्ट लैब के डिवाइसों का इस्तेमाल करना

बिल्ड मैनेज करने वाले डिवाइसों का इस्तेमाल करते समय, Firebase Test Lab डिवाइसों पर, अपने-आप इंस्ट्रुमेंट की गई जांचों को बड़े पैमाने पर चलाया जा सकता है. टेस्ट लैब की मदद से, एक साथ कई Android डिवाइसों पर टेस्ट किए जा सकते हैं. ये डिवाइस, फ़िज़िकल और वर्चुअल, दोनों तरह के हो सकते हैं. ये टेस्ट, Google के रिमोट डेटा सेंटर में चलते हैं. बिल्ड-मैनेज किए गए डिवाइसों की मदद से, बिल्ड सिस्टम इन Test Lab डिवाइसों पर टेस्ट चलाने की प्रोसेस को पूरी तरह से मैनेज कर सकता है. यह प्रोसेस, आपके कॉन्फ़िगरेशन पर आधारित होती है.

शुरू करें

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

1. Firebase प्रोजेक्ट बनाने के लिए, Firebase कंसोल पर जाएं. प्रोजेक्ट जोड़ें पर क्लिक करें और प्रोजेक्ट बनाने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें. अपना प्रोजेक्ट आईडी याद रखें.

2. Google Cloud CLI इंस्टॉल करने के लिए, gcloud CLI इंस्टॉल करें पर दिया गया तरीका अपनाएं.

3. अपने लोकल एनवायरमेंट को कॉन्फ़िगर करें.

   1. gcloud में अपने Firebase प्रोजेक्ट से लिंक करें:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. एपीआई ऐक्सेस करने के लिए, अपने उपयोगकर्ता क्रेडेंशियल के इस्तेमाल की अनुमति दें. हमारा सुझाव है कि मॉड्यूल-लेवल की बिल्ड स्क्रिप्ट में DSL का इस्तेमाल करके, Gradle को सेवा खाते की JSON फ़ाइल पास करके अनुमति दें:

      Kotlin

      firebaseTestLab {
        ...
        serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
      }

      Groovy

      firebaseTestLab {
        ...
        serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
      }

      इसके अलावा, इस टर्मिनल कमांड का इस्तेमाल करके मैन्युअल तरीके से अनुमति दी जा सकती है:

      gcloud auth application-default login
      

   3. ज़रूरी नहीं: अपने Firebase प्रोजेक्ट को कोटा प्रोजेक्ट के तौर पर जोड़ें. यह चरण सिर्फ़ तब ज़रूरी है, जब आपने Test Lab के लिए बिना किसी शुल्क के उपलब्ध कोटा का इस्तेमाल कर लिया हो.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      

4. ज़रूरी एपीआई चालू करें.

   Google Developers Console API लाइब्रेरी पेज पर, Cloud Testing API और Cloud Tool Results API को चालू करें. इसके लिए, कंसोल में सबसे ऊपर मौजूद खोज बॉक्स में इन एपीआई के नाम टाइप करें. इसके बाद, हर एपीआई के खास जानकारी वाले पेज पर जाकर, एपीआई चालू करें पर क्लिक करें.

5. अपने Android प्रोजेक्ट को कॉन्फ़िगर करें.

   1. टॉप-लेवल की बिल्ड स्क्रिप्ट में, Firebase Test Lab प्लगिन जोड़ें:

      Kotlin

      plugins {
        ...
        id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
      }

      Groovy

      plugins {
        ...
        id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
      }

   2. gradle.properties फ़ाइल में कस्टम डिवाइस टाइप चालू करें:

      android.experimental.testOptions.managedDevices.customDevice=true

   3. मॉड्यूल-लेवल की बिल्ड स्क्रिप्ट में Firebase Test Lab प्लगिन जोड़ें:

      Kotlin

      plugins {
       ...
       id "com.google.firebase.testlab"
      }

      Groovy

      plugins {
       ...
       id 'com.google.firebase.testlab'
      }

टेस्ट लैब डिवाइस के बारे में जानकारी देना

मॉड्यूल-लेवल की बिल्ड स्क्रिप्ट में, Gradle के लिए Firebase Test Lab डिवाइस तय किया जा सकता है. इससे Gradle, आपके ऐप्लिकेशन की टेस्टिंग के लिए इस डिवाइस का इस्तेमाल कर पाएगा. यहां दिए गए कोड सैंपल में, एपीआई लेवल 30 पर काम करने वाले Pixel 3 को, बिल्ड मैनेज करने वाले Test Lab डिवाइस के तौर पर बनाया गया है. इसे ftlDevice कहा जाता है. firebaseTestLab {} ब्लॉक तब उपलब्ध होता है, जब अपने मॉड्यूल में com.google.firebase.testlab प्लगिन लागू किया जाता है.

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

बिल्ड-मैनेज किए गए डिवाइसों के ग्रुप को तय करने के लिए, डिवाइसों के ग्रुप तय करना लेख पढ़ें. इसमें Firebase Test Lab डिवाइस भी शामिल हैं.

टेस्ट चलाने के लिए, उन ही निर्देशों का इस्तेमाल करें जिनका इस्तेमाल, बिल्ड-मैनेज किए गए अन्य डिवाइसों को चलाने के लिए किया जाता है. ध्यान दें कि Gradle, टेस्ट को पैरलल में नहीं चलाता है. साथ ही, Test Lab डिवाइसों के लिए Google Cloud CLI के अन्य कॉन्फ़िगरेशन का समर्थन नहीं करता है.

स्मार्ट शार्डिंग की मदद से टेस्ट रन को ऑप्टिमाइज़ करना

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

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

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

ज़्यादा जानने के लिए, Firebase Test Lab डिवाइस के डीएसएल के विकल्पों के बारे में पढ़ें.

टेस्ट लैब डिवाइसों के लिए डीएसएल को अपडेट किया गया

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

firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       *
       * Default to 0 for no sharding.
       */
      numUniformShards = 20
    }

    /**
     * For smart sharding, the target length of time each shard should takes in
     * minutes. Maxes out at 50 shards for physical devices and 100 shards for
     * virtual devices.
     *
     * Only one of numUniformShards or targetedShardDurationMinutes can be set.
     *
     * Defaults to 0 for no smart sharding.
     */
     targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
  }
}