توسيع نطاق اختباراتك باستخدام الأجهزة التي تتم إدارتها من خلال الإصدار

تعمل الأجهزة التي تديرها الإصدارات على تحسين الاتساق والأداء والموثوقية في الاختبارات المبرمَجة التي تتضمّن أدوات. تتيح لك هذه الميزة، المتوفّرة في المستوى 27 من واجهة برمجة التطبيقات والإصدارات الأحدث، إعداد أجهزة اختبار افتراضية أو مادية عن بُعد في ملفات Gradle الخاصة بمشروعك. يستخدم مكوّن إضافي لنظام Gradle المتوافق مع Android عمليات الإعداد لإدارة هذه الأجهزة بشكل كامل، أي لإنشائها وتفعيلها وإيقافها، عند تنفيذ اختباراتك المبرمَجة.

تمنح هذه الميزة المكوّن الإضافي لنظام Gradle المتوافق مع Android إمكانية رؤية الاختبارات التي تجريها، بالإضافة إلى مراحل نشاط الأجهزة، ما يؤدي إلى تحسين جودة تجربة الاختبار بالطرق التالية:

• يتعامل مع المشاكل المتعلّقة بالجهاز لضمان تنفيذ اختباراتك
• بالنسبة إلى الأجهزة الافتراضية، يتم استخدام لقطات المحاكي لتحسين وقت بدء تشغيل الجهاز واستخدام الذاكرة، واستعادة الأجهزة إلى حالة نظيفة بين الاختبارات.
• تخزين نتائج الاختبارات مؤقتًا وإعادة تشغيل الاختبارات التي من المحتمل أن تقدّم نتائج مختلفة فقط
• توفير بيئة متسقة لتنفيذ الاختبارات بين عمليات الاختبار المحلية وعمليات الاختبار عن بُعد

إنشاء جهاز افتراضي مُدار من خلال الإصدار

يمكنك تحديد جهاز افتراضي تريد استخدامه لاختبار تطبيقك في ملف الإصدار على مستوى الوحدة. ينشئ نموذج الرمز البرمجي التالي جهاز Pixel 2 يعمل بمستوى واجهة برمجة التطبيقات 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"
        }
      }
    }
  }
}

تحديد مجموعات الأجهزة

لمساعدتك في توسيع نطاق اختباراتك على مستوى إعدادات أجهزة متعددة، مثل مستويات واجهة برمجة التطبيقات وعوامل الشكل المختلفة، يمكنك تحديد أجهزة متعددة يديرها الإصدار وإضافتها إلى مجموعة مسماة. يمكن بعد ذلك أن ينفّذ مكوّن إضافي لنظام Gradle المتوافق مع Android الاختبارات على جميع الأجهزة في المجموعة بالتوازي.

يعرض المثال أدناه جهازَين تمت إضافتهما إلى مجموعة أجهزة باسم 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 يحتوي على تقرير الاختبار. يمكنك أيضًا استيراد نتائج الاختبار إلى "استوديو Android" لإجراء المزيد من التحليلات من خلال النقر على تشغيل (Run) > سجلّ الاختبار (Test History) في بيئة التطوير المتكاملة.

تفعيل تقسيم الاختبار

تتيح الأجهزة التي يديرها الإصدار تقسيم الاختبار، ما يتيح لك تقسيم مجموعة الاختبارات على عدد من مثيلات الأجهزة الافتراضية المتطابقة، والتي تُعرف باسم التقسيم، ويتم تشغيلها بالتوازي. يمكن أن يساعد استخدام تقسيم الاختبار في تقليل الوقت الإجمالي لتنفيذ الاختبار مقابل تكلفة موارد حسابية إضافية.

لضبط عدد الأجزاء التي تريد استخدامها في عملية اختبار معيّنة، اضبط ما يلي في ملف gradle.properties:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

عند إجراء الاختبارات باستخدام هذا الخيار، توفّر الأجهزة التي تديرها الإصدارات عدد الأجزاء التي تحدّدها لكل ملف شخصي للجهاز في عملية الاختبار. على سبيل المثال، إذا نشرت اختباراتك إلى مجموعة أجهزة تضم ثلاثة أجهزة وضبطت numManagedDeviceShards على اثنين، ستوفّر الأجهزة التي تديرها الإصدارات إجمالي ستة أجهزة افتراضية لتشغيل الاختبار.

عند اكتمال الاختبارات، يعرض Gradle نتائج الاختبار في ملف .proto لكل جزء مستخدَم في عملية الاختبار.

استخدام أجهزة الاختبار المبرمَجة

تتيح الأجهزة التي تديرها الإصدارات استخدام نوع من أجهزة المحاكي يُعرف باسم "جهاز الاختبار الآلي" (ATD)، وهو جهاز محسَّن لتقليل موارد وحدة المعالجة المركزية والذاكرة عند تشغيل الاختبارات المزوّدة بأدوات. تساهم أنواع البيانات المجردة في تحسين أداء وقت التشغيل بعدة طرق:

• إزالة التطبيقات المثبَّتة مسبقًا والتي لا تكون مفيدة عادةً لاختبار تطبيقك
• إيقاف بعض الخدمات التي تعمل في الخلفية والتي لا تكون مفيدة عادةً لاختبار تطبيقك
• إيقاف العرض باستخدام الأجهزة

قبل البدء، تأكَّد من تحديث "محاكي Android" إلى أحدث إصدار متاح. بعد ذلك، حدِّد صورة "-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"
        }
      }
    }
  }
}

يمكنك أيضًا إنشاء مجموعات أجهزة كما هو الحال مع الأجهزة الأخرى التي تديرها الإصدارات. للاستفادة بشكل أكبر من تحسينات الأداء، يمكنك أيضًا استخدام أدوات اختبار Android مع تقسيم الاختبار لتقليل إجمالي وقت تنفيذ مجموعة الاختبارات.

ما هي المعلومات التي تتم إزالتها من صور الإعلانات المستندة إلى الاهتمامات؟

بالإضافة إلى العمل في وضع بلا واجهة مستخدم رسومية، تعمل الأجهزة الاختبارية الآلية أيضًا على تحسين الأداء من خلال إزالة التطبيقات والخدمات التي لا تكون مطلوبة عادةً لاختبار رموز تطبيقك أو إيقافها. يقدّم الجدول أدناه نظرة عامة على المكوّنات التي أزلناها أو أوقفناها في صور "إعلانات التطبيقات" وأوصافًا لسبب عدم فائدتها.

استخدام أجهزة مختبر Firebase الافتراضي

يمكنك إجراء اختباراتك المبرمَجة للأدوات على نطاق واسع على أجهزة Firebase Test Lab عند استخدام الأجهزة التي تديرها الإصدارات. يتيح لك مركز الاختبار الافتراضي إجراء اختباراتك في الوقت نفسه على مجموعة كبيرة من أجهزة Android، سواء كانت فعلية أو افتراضية. تُجرى هذه الاختبارات في مراكز بيانات Google البعيدة. وبفضل إمكانية استخدام الأجهزة التي يديرها نظام الإصدار، يمكن لنظام الإصدار إدارة عمليات تشغيل الاختبارات على أجهزة مركز الاختبار الافتراضي هذه بشكل كامل استنادًا إلى إعداداتك.

البدء

توضِّح الخطوات التالية كيفية بدء استخدام أجهزة مختبر Firebase الافتراضي مع الأجهزة التي تتم إدارتها من خلال الإصدار. تستخدم هذه الخطوات واجهة سطر الأوامر gcloud لتوفير بيانات اعتماد المستخدم، وقد لا تنطبق على جميع بيئات التطوير. لمزيد من المعلومات حول عملية المصادقة التي يجب استخدامها لتلبية احتياجاتك، يُرجى الاطّلاع على مقالة طريقة عمل بيانات الاعتماد التلقائية للتطبيق.

1. لإنشاء مشروع Firebase، انتقِل إلى وحدة تحكّم Firebase. انقر على إضافة مشروع واتّبِع التعليمات الظاهرة على الشاشة لإنشاء مشروع. تذكَّر رقم تعريف مشروعك.

2. لتثبيت Google Cloud CLI، اتّبِع الخطوات الواردة في تثبيت gcloud CLI.

3. اضبط بيئتك المحلية.

   1. اربط مشروع Firebase في gcloud:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. تفويض استخدام بيانات اعتماد المستخدم للوصول إلى واجهة برمجة التطبيقات ننصحك بمنح الإذن من خلال تمرير ملف JSON لحساب الخدمة إلى Gradle باستخدام DSL في نص برمجة الإصدار على مستوى الوحدة:

      Kotlin

      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. فعِّل واجهات برمجة التطبيقات المطلوبة.

   في صفحة مكتبة واجهات برمجة التطبيقات في Google Developers Console، فعِّل Cloud Testing API وCloud Tool Results API من خلال كتابة أسماء واجهات برمجة التطبيقات هذه في مربّع البحث في أعلى وحدة التحكّم، ثم النقر على تفعيل واجهة برمجة التطبيقات في صفحة النظرة العامة لكل واجهة برمجة تطبيقات.

5. إعداد مشروع Android

   1. أضِف المكوّن الإضافي مختبر Firebase الافتراضي في نص برمجة الإصدار على المستوى الأعلى:

      Kotlin

      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 في نص برمجة الإصدار على مستوى الوحدة:

      Kotlin

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

      أنيق

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

تحديد جهاز في "مركز الاختبار الافتراضي"

يمكنك تحديد جهاز في "مختبر Firebase الافتراضي" ليستخدمه Gradle في اختبار تطبيقك في نص برمجي للإنشاء على مستوى الوحدة. ينشئ نموذج الرمز البرمجي التالي جهاز Pixel 3 يعمل بمستوى واجهة برمجة التطبيقات 30 كجهاز مركز الاختبار الافتراضي مُدار من خلال الإصدار يُطلق عليه اسم ftlDevice. يتوفّر الحظر firebaseTestLab {} عند تطبيق المكوّن الإضافي com.google.firebase.testlab على الوحدة.

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

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

لتحديد مجموعة من الأجهزة المُدارة من خلال الإصدار، بما في ذلك أجهزة مختبر Firebase الافتراضي، راجِع تحديد مجموعات من الأجهزة.

لتشغيل الاختبارات، استخدِم الأوامر نفسها المستخدَمة لتشغيل الأجهزة الأخرى التي تتم إدارتها من خلال الإصدار. يُرجى العِلم أنّ Gradle لا ينفّذ الاختبارات بالتوازي ولا يتيح إعدادات أخرى لواجهة سطر الأوامر (CLI) من Google Cloud لأجهزة مركز الاختبار الافتراضي.

تحسين عمليات تشغيل الاختبار باستخدام التقسيم الذكي

يتيح الاختبار على أجهزة مركز الاختبار الافتراضي التي تديرها الإصدارات تقسيم الاختبارات الذكي. تعمل ميزة Smart sharding على توزيع اختباراتك تلقائيًا على الأجزاء بطريقة تضمن تشغيل كل جزء للمدة نفسها تقريبًا، ما يقلّل من جهود التخصيص اليدوي ومدة تشغيل الاختبار الإجمالية. تستخدم ميزة "التقسيم الذكي" سجلّ الاختبارات أو معلومات حول المدة التي استغرقتها الاختبارات في السابق لتوزيع الاختبارات بطريقة مثالية. يُرجى العِلم أنّه يجب استخدام الإصدار 0.0.1-alpha05 من المكوّن الإضافي Gradle لمختبر Firebase الافتراضي من أجل استخدام التقسيم الذكي.

لتفعيل التقسيم الذكي، حدِّد مقدار الوقت الذي يجب أن تستغرقه الاختبارات ضمن كل جزء. يجب ضبط المدة الزمنية المستهدَفة للجزء على أقل من timeoutMinutes بخمس دقائق على الأقل لتجنُّب إلغاء الأجزاء قبل انتهاء الاختبارات.

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

لمزيد من المعلومات، اطّلِع على خيارات لغة وصف الأجهزة في مختبر Firebase الافتراضي.

تعديل لغة 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
  }
}