تست های خود را با دستگاه های مدیریت شده Gradle مقیاس کنید

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

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

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

یک دستگاه مجازی با مدیریت Gradle ایجاد کنید

می‌توانید یک دستگاه مجازی را که می‌خواهید Gradle برای آزمایش برنامه شما در فایل ساخت ماژول خود استفاده کند، مشخص کنید. نمونه کد زیر یک Pixel 2 با API سطح 30 به عنوان دستگاهی با مدیریت Gradle ایجاد می‌کند.

کاتلین 

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 و فاکتورهای شکل، می‌توانید چندین دستگاه با مدیریت Gradle تعریف کنید و آنها را به یک گروه نام‌گذاری شده اضافه کنید. سپس 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)
      }
    }
  }
}

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

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

در ویندوز:

gradlew device-nameBuildVariantAndroidTest

در لینوکس یا macOS:

./gradlew device-nameBuildVariantAndroidTest

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

در ویندوز:

gradlew group-nameGroupBuildVariantAndroidTest

در لینوکس یا macOS:

./gradlew group-nameGroupBuildVariantAndroidTest

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

اشتراک گذاری آزمایشی را فعال کنید

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

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

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

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

وقتی تست‌های شما کامل شد، Gradle نتایج آزمایش را در یک فایل .proto برای هر قطعه استفاده شده در اجرای آزمایشی خروجی می‌دهد.

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

دستگاه‌های مدیریت‌شده توسط Gradle از نوعی دستگاه شبیه‌ساز به نام دستگاه تست خودکار (ATD) پشتیبانی می‌کنند که برای کاهش منابع CPU و حافظه هنگام اجرای آزمایش‌های ابزاری بهینه‌سازی شده است. ATD ها عملکرد زمان اجرا را به چند روش بهبود می بخشند:

  • برنامه های از پیش نصب شده را که معمولاً برای آزمایش برنامه شما مفید نیستند، حذف کنید
  • برخی از خدمات پس زمینه را که معمولاً برای آزمایش برنامه شما مفید نیستند، غیرفعال کنید
  • رندر سخت افزار را غیرفعال کنید

قبل از شروع، مطمئن شوید که شبیه ساز اندروید را به آخرین نسخه موجود به روز کرده اید. سپس، همانطور که در زیر نشان داده شده است، هنگام تعریف یک دستگاه با مدیریت Gradle در فایل ساخت سطح ماژول، یک تصویر "-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"
        }
      }
    }
  }
}

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

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

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

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

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

برنامه ها و خدمات تنظیمات:
  • CarrierConfig
  • اطلاعات اضطراری
  • OneTimeInitializer
  • PhotoTable (محافظ صفحه نمایش)
  • تامین
  • برنامه تنظیمات
  • StorageManager
  • تنظیمات APN تلفن
  • کاغذ دیواری برش دهنده
  • Wallpaper Picker
 این برنامه‌ها یک رابط کاربری گرافیکی برای کاربران نهایی ارائه می‌کنند تا تنظیمات پلتفرم را تغییر دهند، دستگاه خود را راه‌اندازی کنند یا فضای ذخیره‌سازی دستگاه را مدیریت کنند. این معمولاً خارج از محدوده آزمایش خودکار در سطح برنامه است.


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

SystemUI تست‌های خودکار شما باید روی منطق برنامه‌تان تمرکز کنند، در حالی که فرض می‌کنیم دیگر برنامه‌ها یا پلتفرم به درستی کار می‌کنند.
برنامه ها و خدمات AOSP:
  • مرورگر 2
  • تقویم
  • دوربین 2
  • مخاطبین
  • شماره گیر
  • ساعت رومیزی
  • گالری 2
  • LatinIME
  • Launcher3QuickStep
  • موسیقی
  • جعبه جستجوی سریع
  • تنظیمات هوشمند
 این برنامه‌ها و سرویس‌ها معمولاً خارج از محدوده آزمایش‌های خودکار کد برنامه شما هستند.

از دستگاه های Firebase Test Lab استفاده کنید

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

شروع کنید

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

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

  2. برای نصب Google Cloud CLI، مراحل Install the gcloud CLI را دنبال کنید.

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

    1. پیوند به پروژه Firebase خود در gcloud:

      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 خود را به عنوان پروژه سهمیه اضافه کنید. این مرحله فقط در صورتی لازم است که از سهمیه بدون هزینه برای آزمایشگاه تست فراتر رفته باشید.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. API های مورد نیاز را فعال کنید.

    در صفحه کتابخانه Google Developers Console API ، Cloud Testing API و Cloud Tool Results API را با تایپ این نام‌های 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 را به عنوان یک دستگاه آزمایشگاه آزمایشی مدیریت شده Gradle به نام ftlDevice ایجاد می کند. بلوک firebaseTestLab {} زمانی در دسترس است که افزونه com.google.firebase.testlab را در ماژول خود اعمال کنید.

کاتلین 

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

شیار

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

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

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

اجرای آزمایشی را با اشتراک گذاری هوشمند بهینه کنید

آزمایش بر روی دستگاه‌های آزمایشگاه تست مدیریت شده توسط Gradle از اشتراک گذاری هوشمند پشتیبانی می‌کند. اشتراک‌گذاری هوشمند به‌طور خودکار آزمایش‌های شما را در بین خرده‌ها توزیع می‌کند، به طوری که هر قطعه تقریباً برای یک زمان اجرا می‌شود، و تلاش‌های تخصیص دستی و مدت زمان اجرای آزمایش کلی را کاهش می‌دهد. اشتراک گذاری هوشمند از تاریخچه آزمایش شما یا اطلاعاتی در مورد مدت زمانی که آزمایش های شما قبلاً اجرا شده است استفاده می کند تا آزمایش ها را به روشی بهینه توزیع کند. توجه داشته باشید که برای استفاده از اشتراک گذاری هوشمند به نسخه 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 in Flank/Fladle.
       */
      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
  }
}