تست‌های خود را با دستگاه‌های مدیریت‌شده توسط build، مقیاس‌بندی کنید

دستگاه‌های مدیریت‌شده توسط Build، سازگاری، عملکرد و قابلیت اطمینان را برای تست‌های خودکارِ ابزاربندی‌شده شما بهبود می‌بخشند. این ویژگی که برای سطوح API 27 و بالاتر در دسترس است، به شما امکان می‌دهد دستگاه‌های تست فیزیکی مجازی یا از راه دور را در فایل‌های Gradle پروژه خود پیکربندی کنید. افزونه Android Gradle از این پیکربندی‌ها برای مدیریت کامل - یعنی ایجاد، استقرار و از رده خارج کردن - آن دستگاه‌ها هنگام اجرای تست‌های خودکار شما استفاده می‌کند.

این ویژگی به افزونه‌ی اندروید گریدل (Android Gradle) نه تنها امکان مشاهده‌ی تست‌هایی که اجرا می‌کنید، بلکه امکان مشاهده‌ی چرخه‌ی حیات دستگاه‌ها را نیز می‌دهد و در نتیجه کیفیت تجربه‌ی تست شما را به روش‌های زیر بهبود می‌بخشد:

  • مشکلات مربوط به دستگاه را مدیریت می‌کند تا از اجرای تست‌های شما اطمینان حاصل شود
  • برای دستگاه‌های مجازی، از اسنپ‌شات‌های شبیه‌ساز برای بهبود زمان راه‌اندازی دستگاه و استفاده از حافظه استفاده می‌کند و دستگاه‌ها را بین آزمایش‌ها به حالت اولیه برمی‌گرداند.
  • نتایج تست را ذخیره می‌کند و فقط تست‌هایی را که احتمالاً نتایج متفاوتی ارائه می‌دهند، دوباره اجرا می‌کند
  • یک محیط سازگار برای اجرای تست‌های شما بین تست‌های محلی و از راه دور فراهم می‌کند.

ایجاد یک دستگاه مجازی مدیریت‌شده توسط build

شما می‌توانید یک دستگاه مجازی که می‌خواهید برای آزمایش برنامه خود استفاده کنید را در فایل ساخت سطح ماژول خود مشخص کنید. نمونه کد زیر یک 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 و فاکتورهای فرم مختلف، می‌توانید چندین دستگاه مدیریت‌شده توسط build را تعریف کرده و آنها را به یک گروه نامگذاری‌شده اضافه کنید. افزونه 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)
      }
    }
  }
}

تست‌های خود را اجرا کنید

برای اجرای تست‌های خود با استفاده از دستگاه‌های مدیریت‌شده توسط build که پیکربندی کرده‌اید، از دستور زیر استفاده کنید. device-name نام دستگاهی است که در اسکریپت ساخت Gradle خود پیکربندی کرده‌اید (مانند pixel2api30 ) و BuildVariant نوع ساخت برنامه‌ای است که می‌خواهید آزمایش کنید، مانند Debug .

لینوکس و macOS 

./gradlew device-nameBuildVariantAndroidTest

ویندوز 

gradlew device-nameBuildVariantAndroidTest

برای اجرای تست‌های خود روی گروهی از دستگاه‌های مدیریت‌شده توسط build، از دستور زیر استفاده کنید.

لینوکس و macOS 

./gradlew group-nameGroupBuildVariantAndroidTest

./gradlew group-nameGroupBuildVariantAndroidTest

ویندوز 

gradlew group-nameGroupBuildVariantAndroidTest

خروجی تست شامل مسیری به یک فایل HTML است که گزارش تست در آن قرار دارد. همچنین می‌توانید با کلیک روی Run > Test History در IDE، نتایج تست را برای تجزیه و تحلیل بیشتر به اندروید استودیو وارد کنید.

فعال کردن تست شاردینگ

دستگاه‌های مدیریت‌شده توسط Build از Test sharding پشتیبانی می‌کنند که به شما امکان می‌دهد مجموعه تست خود را بین تعدادی از نمونه‌های دستگاه مجازی یکسان، به نام shards ، که به صورت موازی اجرا می‌شوند، تقسیم کنید. استفاده از Test sharding می‌تواند به کاهش زمان کلی اجرای تست با هزینه منابع محاسباتی اضافی کمک کند.

برای تنظیم تعداد Shardهایی که می‌خواهید در یک اجرای آزمایشی مشخص استفاده کنید، موارد زیر را در فایل gradle.properties خود تنظیم کنید: 

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

هنگام اجرای تست‌های خود با استفاده از این گزینه، دستگاه‌های مدیریت‌شده توسط build، تعداد shardهایی را که برای هر پروفایل دستگاه در اجرای تست مشخص می‌کنید، فراهم می‌کنند. بنابراین، برای مثال، اگر تست‌های خود را روی یک گروه دستگاه متشکل از سه دستگاه مستقر کرده باشید و numManagedDeviceShards را روی دو تنظیم کرده باشید، دستگاه‌های مدیریت‌شده توسط build در مجموع شش دستگاه مجازی را برای اجرای تست شما فراهم می‌کنند.

وقتی تست‌های شما کامل شد، Gradle نتایج تست را در یک فایل .proto برای هر shard مورد استفاده در اجرای تست، نمایش می‌دهد.

از دستگاه‌های تست خودکار استفاده کنید

دستگاه‌های مدیریت‌شده توسط Build از نوعی دستگاه شبیه‌ساز به نام دستگاه تست خودکار (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"
        }
      }
    }
  }
}

شما همچنین می‌توانید گروه‌های دستگاه را مانند سایر دستگاه‌های مدیریت‌شده توسط build ایجاد کنید . برای بهره‌مندی بیشتر از بهبود عملکرد، می‌توانید از ATDها به همراه test sharding نیز استفاده کنید تا زمان اجرای کل تست مجموعه تست خود را کاهش دهید.

چه چیزی از تصاویر ATD حذف شده است؟

علاوه بر عملکرد در حالت بدون سر، ATD ها با حذف یا غیرفعال کردن برنامه‌ها و سرویس‌هایی که معمولاً برای آزمایش کد برنامه شما لازم نیستند، عملکرد را نیز بهینه می‌کنند. جدول زیر مروری بر اجزایی که در تصاویر ATD حذف یا غیرفعال کرده‌ایم و توضیحاتی در مورد اینکه چرا ممکن است مفید نباشند، ارائه می‌دهد.

آنچه در تصاویر ATD حذف شده است چرا ممکن است هنگام اجرای تست‌های خودکار به این مورد نیاز نداشته باشید
برنامه‌های محصول گوگل:
  • ایمیل
  • نقشه‌ها
  • کروم
  • پیام‌ها
  • فروشگاه پلی و موارد دیگر
 تست‌های خودکار شما باید روی منطق برنامه خودتان تمرکز کنند، در حالی که فرض را بر این می‌گذارند که سایر برنامه‌ها یا پلتفرم به درستی کار خواهند کرد.

با Espresso-Intents ، می‌توانید Intentهای خروجی خود را مطابقت داده و اعتبارسنجی کنید یا حتی به جای پاسخ‌های Intent واقعی، پاسخ‌های stub ارائه دهید.

تنظیمات برنامه‌ها و سرویس‌ها:
  • پیکربندی حامل
  • اطلاعات اضطراری
  • مقداردهی اولیه یک‌باره
  • میز عکس (محافظ صفحه نمایش)
  • تأمین
  • برنامه تنظیمات
  • مدیر ذخیره‌سازی
  • پیکربندی APN تلفن
  • کاغذ دیواری کراپر
  • انتخابگر تصویر زمینه
 این برنامه‌ها یک رابط کاربری گرافیکی (GUI) برای کاربران نهایی ارائه می‌دهند تا تنظیمات پلتفرم را تغییر دهند، دستگاه خود را راه‌اندازی کنند یا فضای ذخیره‌سازی دستگاه را مدیریت کنند. این موارد معمولاً خارج از محدوده تست خودکار در سطح برنامه است.


توجه: ارائه دهنده تنظیمات هنوز در تصویر ATD موجود است.

رابط کاربری سیستم تست‌های خودکار شما باید روی منطق برنامه خودتان تمرکز کنند، در حالی که فرض را بر این می‌گذارند که سایر برنامه‌ها یا پلتفرم به درستی کار خواهند کرد.
برنامه‌ها و سرویس‌های AOSP:
  • مرورگر۲
  • تقویم
  • دوربین۲
  • مخاطبین
  • شماره‌گیر
  • ساعت رومیزی
  • گالری۲
  • لاتینIME
  • لانچر۳کوئیک‌استپ
  • موسیقی
  • جعبه جستجوی سریع
  • تنظیماتهوش
 این برنامه‌ها و سرویس‌ها معمولاً خارج از محدوده تست‌های خودکار برای کد برنامه شما هستند.

از دستگاه‌های آزمایشگاه تست فایربیس استفاده کنید

شما می‌توانید تست‌های خودکار و ابزاربندی‌شده خود را در مقیاس بزرگ روی دستگاه‌های Firebase Test Lab هنگام استفاده از دستگاه‌های build-managed اجرا کنید. Test Lab به شما امکان می‌دهد تست‌های خود را همزمان روی طیف وسیعی از دستگاه‌های اندروید، چه فیزیکی و چه مجازی، اجرا کنید. این تست‌ها در مراکز داده گوگل از راه دور اجرا می‌شوند. با پشتیبانی از دستگاه‌های build-managed، سیستم build می‌تواند تست‌های در حال اجرا را بر روی این دستگاه‌های Test Lab بر اساس پیکربندی‌های شما به طور کامل مدیریت کند.

شروع کنید

مراحل زیر نحوه شروع استفاده از دستگاه‌های Firebase Test Lab با دستگاه‌های مدیریت‌شده توسط build را شرح می‌دهد. این مراحل از رابط خط فرمان gcloud برای ارائه اعتبارنامه‌های کاربر استفاده می‌کنند که ممکن است در همه محیط‌های توسعه اعمال نشود. برای اطلاعات بیشتر در مورد اینکه از چه فرآیند احراز هویتی برای نیازهای خود استفاده کنید، به بخش «نحوه عملکرد اعتبارنامه‌های پیش‌فرض برنامه» مراجعه کنید.

  1. برای ایجاد یک پروژه Firebase، به کنسول Firebase بروید. روی Add project کلیک کنید و دستورالعمل‌های روی صفحه را برای ایجاد یک پروژه دنبال کنید. شناسه پروژه خود را به خاطر بسپارید.

  2. برای نصب رابط خط فرمان گوگل کلود (Google Cloud CLI)، مراحل نصب رابط خط فرمان gcloud را دنبال کنید.

  3. محیط محلی خود را پیکربندی کنید.

    1. لینک پروژه فایربیس شما در جی کلود: 

      gcloud config set project FIREBASE_PROJECT_ID

    2. استفاده از اعتبارنامه‌های کاربری خود را برای دسترسی به API مجاز کنید. توصیه می‌کنیم با ارسال یک فایل JSON حساب کاربری سرویس به Gradle با استفاده از DSL در اسکریپت ساخت سطح ماژول، مجوز دهید:

      کاتلین 

      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 های مورد نیاز

    در صفحه کتابخانه API کنسول توسعه‌دهندگان گوگل ، با تایپ نام‌های APIهای Cloud Testing API و Cloud Tool Results API در کادر جستجو در بالای کنسول و سپس کلیک روی Enable API در صفحه مرور کلی برای هر 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'
}

یک دستگاه آزمایشگاه تست مشخص کنید

شما می‌توانید یک دستگاه Firebase Test Lab را برای Gradle مشخص کنید تا برای آزمایش برنامه شما در اسکریپت ساخت سطح ماژول استفاده شود. نمونه کد زیر یک Pixel 3 با API سطح 30 را به عنوان یک دستگاه 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، به بخش تعریف گروه‌های دستگاه‌ها مراجعه کنید.

برای اجرای تست‌های خود، از همان دستوراتی که برای اجرای سایر دستگاه‌های مدیریت‌شده توسط build استفاده می‌شود ، استفاده کنید. توجه داشته باشید که Gradle تست‌ها را به صورت موازی اجرا نمی‌کند یا از سایر پیکربندی‌های Google Cloud CLI برای دستگاه‌های Test Lab پشتیبانی نمی‌کند.

بهینه‌سازی اجرای تست‌ها با استفاده از شاردینگ هوشمند

تست روی دستگاه‌های آزمایشگاه تست مدیریت‌شده توسط build، از sharding هوشمند پشتیبانی می‌کند. sharding هوشمند به‌طور خودکار تست‌های شما را در بین shardها توزیع می‌کند، به‌طوری که هر shard تقریباً در زمان یکسانی اجرا می‌شود و تلاش‌های تخصیص دستی و مدت زمان کلی اجرای تست را کاهش می‌دهد. sharding هوشمند از تاریخچه تست شما یا اطلاعات مربوط به مدت زمان اجرای تست‌های قبلی شما برای توزیع تست‌ها به روشی بهینه استفاده می‌کند. توجه داشته باشید که برای استفاده از sharding هوشمند به نسخه 0.0.1-alpha05 افزونه Gradle برای Firebase Test Lab نیاز دارید.

برای فعال کردن شاردینگ هوشمند، مدت زمان تست‌های درون هر شارد را مشخص کنید. شما باید مدت زمان شارد هدف را حداقل پنج دقیقه کمتر از timeoutMinutes تنظیم کنید تا از وضعیتی که شارد‌ها قبل از اتمام تست‌ها لغو می‌شوند، جلوگیری شود. 

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

برای کسب اطلاعات بیشتر، درباره گزینه‌های DSL دستگاه Firebase Test Lab مطالعه کنید.

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