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

تساعد الأجهزة التي تديرها عملية الإنشاء في تحسين الاتساق والأداء والموثوقية لاختباراتك المبرمَجة. تتيح لك هذه الميزة، المتوفّرة لمستويات واجهة برمجة التطبيقات 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"
        }
      }
    }
  }
}

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

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

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

استخدام أجهزة Firebase Test Lab

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

البدء

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

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

2. لتثبيت Google Cloud CLI، اتّبِع الخطوات الواردة في تثبيت Google Cloud 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))
      }

      Groovy

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

تحديد جهاز Test Lab

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

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

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

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

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

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

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

تعديل لغة DSL لأجهزة Test Lab

تتوفّر المزيد من خيارات 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
  }
}