বিল্ড-ম্যানেজড ডিভাইসগুলির সাহায্যে আপনার পরীক্ষাগুলি স্কেল করুন

বিল্ড-ম্যানেজড ডিভাইসগুলি আপনার স্বয়ংক্রিয় যন্ত্রযুক্ত পরীক্ষার জন্য ধারাবাহিকতা, কর্মক্ষমতা এবং নির্ভরযোগ্যতা উন্নত করে। API লেভেল 27 এবং তার বেশির জন্য উপলব্ধ এই বৈশিষ্ট্যটি আপনাকে আপনার প্রকল্পের Gradle ফাইলগুলিতে ভার্চুয়াল বা দূরবর্তী শারীরিক পরীক্ষার ডিভাইসগুলি কনফিগার করতে দেয়। Android Gradle প্লাগইন আপনার স্বয়ংক্রিয় পরীক্ষাগুলি সম্পাদন করার সময় সেই ডিভাইসগুলিকে সম্পূর্ণরূপে পরিচালনা করার জন্য - অর্থাৎ, তৈরি, স্থাপন এবং ভেঙে ফেলার জন্য - কনফিগারেশনগুলি ব্যবহার করে।

এই বৈশিষ্ট্যটি অ্যান্ড্রয়েড গ্রেডল প্লাগইনকে কেবল আপনার চলমান পরীক্ষাগুলিতেই নয়, ডিভাইসগুলির জীবনচক্রেও দৃশ্যমানতা প্রদান করে, এইভাবে নিম্নলিখিত উপায়ে আপনার পরীক্ষার অভিজ্ঞতার মান উন্নত করে:

  • আপনার পরীক্ষাগুলি কার্যকর করা নিশ্চিত করার জন্য ডিভাইস-সম্পর্কিত সমস্যাগুলি পরিচালনা করে।
  • ভার্চুয়াল ডিভাইসের জন্য, ডিভাইসের স্টার্টআপ সময় এবং মেমোরি ব্যবহার উন্নত করতে এবং পরীক্ষার মধ্যে ডিভাইসগুলিকে একটি পরিষ্কার অবস্থায় পুনরুদ্ধার করতে এমুলেটর স্ন্যাপশট ব্যবহার করে।
  • পরীক্ষার ফলাফল ক্যাশে করে এবং শুধুমাত্র সেই পরীক্ষাগুলি পুনরায় চালায় যেগুলি ভিন্ন ফলাফল প্রদান করতে পারে
  • স্থানীয় এবং দূরবর্তী পরীক্ষা রানের মধ্যে আপনার পরীক্ষা চালানোর জন্য একটি সামঞ্জস্যপূর্ণ পরিবেশ প্রদান করে।

একটি ভার্চুয়াল বিল্ড-ম্যানেজড ডিভাইস তৈরি করুন

আপনার মডিউল-স্তরের বিল্ড ফাইলে আপনি আপনার অ্যাপটি পরীক্ষা করার জন্য যে ভার্চুয়াল ডিভাইসটি ব্যবহার করতে চান তা নির্দিষ্ট করতে পারেন। নিম্নলিখিত কোড নমুনাটি একটি বিল্ড-পরিচালিত ডিভাইস হিসাবে একটি Pixel 2 চলমান API লেভেল 30 তৈরি করে।

কোটলিন 

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"
        }
      }
    }
  }
}

ডিভাইসের গ্রুপ নির্ধারণ করুন

বিভিন্ন ডিভাইস কনফিগারেশন, যেমন বিভিন্ন API লেভেল এবং ফর্ম ফ্যাক্টর জুড়ে আপনার পরীক্ষাগুলিকে স্কেল করতে সাহায্য করার জন্য, আপনি একাধিক বিল্ড-ম্যানেজড ডিভাইস সংজ্ঞায়িত করতে পারেন এবং সেগুলিকে একটি নামযুক্ত গ্রুপে যুক্ত করতে পারেন। অ্যান্ড্রয়েড গ্রেডল প্লাগইনটি তখন গ্রুপের সমস্ত ডিভাইস জুড়ে আপনার পরীক্ষাগুলি সমান্তরালভাবে সম্পাদন করতে পারে।

নিচের উদাহরণে 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

পরীক্ষার আউটপুটে একটি HTML ফাইলের পথ থাকে যার পরীক্ষার রিপোর্ট থাকে। আপনি IDE-তে Run > Test History-এ ক্লিক করে আরও বিশ্লেষণের জন্য Android Studio-তে পরীক্ষার ফলাফল আমদানি করতে পারেন।

টেস্ট শারডিং সক্ষম করুন

বিল্ড-ম্যানেজড ডিভাইসগুলি টেস্ট শারডিং সমর্থন করে, যা আপনাকে আপনার টেস্ট স্যুটকে একাধিক অভিন্ন ভার্চুয়াল ডিভাইস ইনস্ট্যান্সে বিভক্ত করতে দেয়, যাকে বলা হয় shards , যা সমান্তরালভাবে চলে। টেস্ট শারডিং ব্যবহার অতিরিক্ত কম্পিউটেশনাল রিসোর্সের খরচে সামগ্রিক পরীক্ষার কার্যকর করার সময় কমাতে সাহায্য করতে পারে।

একটি নির্দিষ্ট পরীক্ষামূলক রানে আপনি কতগুলি শার্ড ব্যবহার করতে চান তা সেট করতে, আপনার gradle.properties ফাইলে নিম্নলিখিতগুলি সেট করুন: 

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

এই বিকল্পটি ব্যবহার করে আপনার পরীক্ষা চালানোর সময়, বিল্ড-ম্যানেজড ডিভাইসগুলি পরীক্ষা চালানোর সময় প্রতিটি ডিভাইস প্রোফাইলের জন্য আপনার নির্দিষ্ট করা শার্ডের সংখ্যা সরবরাহ করে। সুতরাং, উদাহরণস্বরূপ, যদি আপনি আপনার পরীক্ষাগুলি তিনটি ডিভাইসের একটি ডিভাইস গ্রুপে স্থাপন করেন এবং numManagedDeviceShards দুটিতে সেট করেন, তাহলে বিল্ড-ম্যানেজড ডিভাইসগুলি আপনার পরীক্ষা চালানোর জন্য মোট ছয়টি ভার্চুয়াল ডিভাইস সরবরাহ করবে।

যখন আপনার পরীক্ষাগুলি সম্পন্ন হয়, তখন গ্র্যাডেল পরীক্ষায় ব্যবহৃত প্রতিটি শার্ডের জন্য একটি .proto ফাইলে পরীক্ষার ফলাফল আউটপুট করে।

স্বয়ংক্রিয় পরীক্ষা ডিভাইস ব্যবহার করুন

বিল্ড-ম্যানেজড ডিভাইসগুলি অটোমেটেড টেস্ট ডিভাইস (ATD) নামক এক ধরণের এমুলেটর ডিভাইস সমর্থন করে, যা আপনার ইন্সট্রুমেন্টেড পরীক্ষা চালানোর সময় CPU এবং মেমরি রিসোর্স কমাতে অপ্টিমাইজ করা হয়। ATDগুলি কয়েকটি উপায়ে রানটাইম কর্মক্ষমতা উন্নত করে:

  • আপনার অ্যাপ পরীক্ষা করার জন্য সাধারণত কার্যকর না হওয়া আগে থেকে ইনস্টল করা অ্যাপগুলি সরিয়ে ফেলুন।
  • আপনার অ্যাপ পরীক্ষা করার জন্য সাধারণত কার্যকর না হওয়া কিছু ব্যাকগ্রাউন্ড পরিষেবা অক্ষম করুন।
  • হার্ডওয়্যার রেন্ডারিং অক্ষম করুন

শুরু করার আগে, নিশ্চিত করুন যে আপনি অ্যান্ড্রয়েড এমুলেটরটি সর্বশেষ উপলব্ধ সংস্করণে আপডেট করেছেন । তারপর, আপনার মডিউল-স্তরের বিল্ড ফাইলে একটি বিল্ড-ম্যানেজড ডিভাইস সংজ্ঞায়িত করার সময় একটি "-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"
        }
      }
    }
  }
}

আপনি অন্যান্য বিল্ড-ম্যানেজড ডিভাইসের সাথে ডিভাইস গ্রুপ তৈরি করতে পারেন। পারফরম্যান্সের উন্নতি আরও কার্যকর করার জন্য, আপনি আপনার টেস্ট স্যুটের মোট টেস্ট এক্সিকিউশন সময় কমাতে টেস্ট শার্ডিং সহ ATD ব্যবহার করতে পারেন।

ATD ছবি থেকে কী সরানো হয়েছে?

হেডলেস মোডে কাজ করার পাশাপাশি, ATD গুলি আপনার অ্যাপের কোড পরীক্ষা করার জন্য সাধারণত প্রয়োজন হয় না এমন অ্যাপ এবং পরিষেবাগুলি সরিয়ে বা নিষ্ক্রিয় করে কর্মক্ষমতা অপ্টিমাইজ করে। নীচের টেবিলটি ATD চিত্রগুলিতে আমরা যে উপাদানগুলি সরিয়ে বা নিষ্ক্রিয় করেছি তার একটি সারসংক্ষেপ এবং কেন সেগুলি কার্যকর নাও হতে পারে তার বর্ণনা প্রদান করে।

ATD ছবিতে কী সরানো হয়েছে স্বয়ংক্রিয় পরীক্ষা চালানোর সময় কেন আপনার এটির প্রয়োজন নাও হতে পারে
গুগল প্রোডাক্ট অ্যাপস:
  • মেইল
  • মানচিত্র
  • ক্রোম
  • বার্তা
  • প্লে স্টোর, এবং অন্যান্য
 আপনার স্বয়ংক্রিয় পরীক্ষাগুলি আপনার নিজস্ব অ্যাপের যুক্তির উপর ফোকাস করা উচিত এবং ধরে নেওয়া উচিত যে অন্যান্য অ্যাপ বা প্ল্যাটফর্ম সঠিকভাবে কাজ করবে।

Espresso-Intents এর সাহায্যে, আপনি আপনার বহির্গামী অভিপ্রায়গুলিকে মেলাতে এবং যাচাই করতে পারেন অথবা প্রকৃত অভিপ্রায় প্রতিক্রিয়ার পরিবর্তে স্টাব প্রতিক্রিয়াও প্রদান করতে পারেন।

সেটিংস অ্যাপ এবং পরিষেবা:
  • ক্যারিয়ার কনফিগ
  • জরুরি তথ্য
  • ওয়ানটাইম ইনিশিয়ালাইজার
  • ফটোটেবিল (স্ক্রিনসেভার)
  • বিধান
  • সেটিংস অ্যাপ
  • স্টোরেজ ম্যানেজার
  • টেলিফোনি APN কনফিগারেশন
  • ওয়ালপেপারক্রপার
  • ওয়ালপেপার পিকার
 এই অ্যাপগুলি ব্যবহারকারীদের প্ল্যাটফর্ম সেটিংস পরিবর্তন করতে, তাদের ডিভাইস সেট আপ করতে বা ডিভাইস স্টোরেজ পরিচালনা করতে একটি GUI প্রদান করে। এটি সাধারণত অ্যাপ-স্তরের স্বয়ংক্রিয় পরীক্ষার আওতার বাইরে।


দ্রষ্টব্য: সেটিংস প্রদানকারী এখনও ATD ছবিতে উপলব্ধ।

সিস্টেমইউআই আপনার স্বয়ংক্রিয় পরীক্ষাগুলি আপনার নিজস্ব অ্যাপের যুক্তির উপর ফোকাস করা উচিত এবং ধরে নেওয়া উচিত যে অন্যান্য অ্যাপ বা প্ল্যাটফর্ম সঠিকভাবে কাজ করবে।
AOSP অ্যাপ এবং পরিষেবা:
  • ব্রাউজার২
  • ক্যালেন্ডার
  • ক্যামেরা২
  • পরিচিতি
  • ডায়ালার
  • ডেস্কক্লক
  • গ্যালারি২
  • ল্যাটিনআইএমই
  • লঞ্চার৩কুইকস্টেপ
  • সঙ্গীত
  • দ্রুত অনুসন্ধান বাক্স
  • সেটিংসবুদ্ধিমত্তা
 এই অ্যাপ এবং পরিষেবাগুলি সাধারণত আপনার অ্যাপের কোডের জন্য স্বয়ংক্রিয় পরীক্ষার আওতার বাইরে থাকে।

Firebase টেস্ট ল্যাব ডিভাইস ব্যবহার করুন

বিল্ড-ম্যানেজড ডিভাইস ব্যবহার করার সময় আপনি Firebase Test Lab ডিভাইসগুলিতে স্কেলে আপনার স্বয়ংক্রিয় যন্ত্রযুক্ত পরীক্ষা চালাতে পারেন। Test Lab আপনাকে ভৌত এবং ভার্চুয়াল উভয় ধরণের Android ডিভাইসে একসাথে আপনার পরীক্ষা চালাতে দেয়। এই পরীক্ষাগুলি দূরবর্তী Google ডেটা সেন্টারে চালানো হয়। বিল্ড-ম্যানেজড ডিভাইসগুলির সহায়তায়, বিল্ড সিস্টেম আপনার কনফিগারেশনের উপর ভিত্তি করে এই টেস্ট ল্যাব ডিভাইসগুলির বিরুদ্ধে চলমান পরীক্ষাগুলি সম্পূর্ণরূপে পরিচালনা করতে পারে।

শুরু করুন

নিম্নলিখিত ধাপগুলি বিল্ড-ম্যানেজড ডিভাইসগুলির সাথে ফায়ারবেস টেস্ট ল্যাব ডিভাইসগুলি কীভাবে ব্যবহার শুরু করবেন তা বর্ণনা করে। এই ধাপগুলি ব্যবহারকারীর শংসাপত্র প্রদানের জন্য gcloud CLI ব্যবহার করে, যা সমস্ত ডেভেলপমেন্ট পরিবেশে প্রযোজ্য নাও হতে পারে। আপনার প্রয়োজনের জন্য কোন প্রমাণীকরণ প্রক্রিয়া ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য, অ্যাপ্লিকেশন ডিফল্ট শংসাপত্রগুলি কীভাবে কাজ করে তা দেখুন।

  1. একটি Firebase প্রকল্প তৈরি করতে, Firebase কনসোলে যান। প্রকল্প যোগ করুন ক্লিক করুন এবং একটি প্রকল্প তৈরি করতে অন-স্ক্রিন প্রম্পটগুলি অনুসরণ করুন। আপনার প্রকল্প আইডি মনে রাখবেন।

  2. গুগল ক্লাউড সিএলআই ইনস্টল করতে, জিক্লাউড সিএলআই ইনস্টল করুন -এ ধাপগুলি অনুসরণ করুন।

  3. আপনার স্থানীয় পরিবেশ কনফিগার করুন।

    1. gcloud-এ আপনার Firebase প্রকল্পের লিঙ্ক: 

      gcloud config set project FIREBASE_PROJECT_ID

    2. API অ্যাক্সেসের জন্য আপনার ব্যবহারকারীর শংসাপত্র ব্যবহারের অনুমোদন দিন। আমরা মডিউল-স্তরের বিল্ড স্ক্রিপ্টে DSL ব্যবহার করে Gradle-এ একটি পরিষেবা অ্যাকাউন্ট JSON ফাইল পাস করে অনুমোদন করার পরামর্শ দিচ্ছি:

      কোটলিন 

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

      খাঁজকাটা 

      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. প্রয়োজনীয় API গুলি সক্ষম করুন।

    গুগল ডেভেলপারস কনসোল এপিআই লাইব্রেরি পৃষ্ঠায় , কনসোলের শীর্ষে অনুসন্ধান বাক্সে এই এপিআই নামগুলি টাইপ করে এবং তারপরে প্রতিটি এপিআইয়ের জন্য ওভারভিউ পৃষ্ঠায় এপিআই সক্ষম করুন ক্লিক করে ক্লাউড টেস্টিং এপিআই এবং ক্লাউড টুল ফলাফল এপিআই সক্ষম করুন।

  5. আপনার অ্যান্ড্রয়েড প্রকল্পটি কনফিগার করুন।

    1. শীর্ষ-স্তরের বিল্ড স্ক্রিপ্টে Firebase Test Lab প্লাগইন যোগ করুন:

      কোটলিন 

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

      খাঁজকাটা 

      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 প্লাগইন যোগ করুন:

      কোটলিন 

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

      খাঁজকাটা 

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

একটি টেস্ট ল্যাব ডিভাইস নির্দিষ্ট করুন

মডিউল-লেভেল বিল্ড স্ক্রিপ্টে আপনার অ্যাপ পরীক্ষা করার জন্য Gradle-এর জন্য আপনি একটি Firebase Test Lab ডিভাইস নির্দিষ্ট করতে পারেন। নিম্নলিখিত কোড নমুনাটি ftlDevice নামক একটি বিল্ড-পরিচালিত টেস্ট ল্যাব ডিভাইস হিসাবে একটি Pixel 3 চলমান API লেভেল 30 তৈরি করে। আপনার মডিউলে com.google.firebase.testlab প্লাগইন প্রয়োগ করলে firebaseTestLab {} ব্লকটি উপলব্ধ থাকে।

কোটলিন 

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

খাঁজকাটা 

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

ফায়ারবেস টেস্ট ল্যাব ডিভাইস সহ বিল্ড-ম্যানেজড ডিভাইসের একটি গ্রুপ সংজ্ঞায়িত করতে, ডিভাইসের গ্রুপ সংজ্ঞায়িত করুন দেখুন।

আপনার পরীক্ষা চালানোর জন্য, অন্যান্য বিল্ড-ম্যানেজড ডিভাইস চালানোর জন্য ব্যবহৃত একই কমান্ড ব্যবহার করুন। মনে রাখবেন যে Gradle সমান্তরালভাবে পরীক্ষা চালায় না বা টেস্ট ল্যাব ডিভাইসের জন্য অন্যান্য Google ক্লাউড CLI কনফিগারেশন সমর্থন করে না।

স্মার্ট শারডিং ব্যবহার করে টেস্ট রান অপ্টিমাইজ করুন

বিল্ড-ম্যানেজড টেস্ট ল্যাব ডিভাইসে পরীক্ষা করা স্মার্ট শার্ডিং সমর্থন করে। স্মার্ট শার্ডিং স্বয়ংক্রিয়ভাবে আপনার পরীক্ষাগুলিকে বিভিন্ন শার্ডে বিতরণ করে যাতে প্রতিটি শার্ড প্রায় একই সময় ধরে চলে, ম্যানুয়াল বরাদ্দ প্রচেষ্টা এবং সামগ্রিক পরীক্ষা চালানোর সময়কাল হ্রাস করে। স্মার্ট শার্ডিং আপনার পরীক্ষার ইতিহাস ব্যবহার করে, অথবা আপনার পরীক্ষাগুলি আগে কত সময় ধরে চালানো হয়েছে সে সম্পর্কে তথ্য ব্যবহার করে, সর্বোত্তম উপায়ে পরীক্ষাগুলি বিতরণ করে। মনে রাখবেন যে স্মার্ট শার্ডিং ব্যবহার করার জন্য আপনার ফায়ারবেস টেস্ট ল্যাবের জন্য গ্র্যাডেল প্লাগইনের 0.0.1-alpha05 সংস্করণ প্রয়োজন।

স্মার্ট শার্ডিং সক্ষম করতে, প্রতিটি শার্ডের মধ্যে পরীক্ষা করতে কত সময় লাগবে তা নির্দিষ্ট করুন। পরীক্ষা শেষ হওয়ার আগেই শার্ডগুলি বাতিল হয়ে যাওয়ার পরিস্থিতি এড়াতে আপনার লক্ষ্য শার্ডের সময়কাল timeoutMinutes চেয়ে কমপক্ষে পাঁচ মিনিট কম সেট করা উচিত। 

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

আরও জানতে, Firebase Test Lab ডিভাইস DSL বিকল্পগুলি সম্পর্কে পড়ুন।

টেস্ট ল্যাব ডিভাইসের জন্য আপডেট করা DSL

আপনার টেস্ট রান কাস্টমাইজ করতে অথবা আপনি ইতিমধ্যেই ব্যবহার করছেন এমন অন্যান্য সমাধান থেকে মাইগ্রেট করতে সাহায্য করার জন্য আপনি আরও DSL বিকল্প কনফিগার করতে পারেন। নিম্নলিখিত কোড স্নিপেটে বর্ণিত এই বিকল্পগুলির মধ্যে কিছু দেখুন। 

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
  }
}