דף זה תורגם על ידי Cloud Translation API.

התאמת הבדיקות באמצעות מכשירים שמנוהלים על ידי Gradle

מכשירים שמנוהלים על ידי Gradle משפרים את העקביות, הביצועים והאמינות של את הבדיקות האוטומטיות האינסטרומנטליות. התכונה הזו זמינה ברמות API 27 מאפשרת לך להגדיר מכשירים לבדיקה פיזית וירטואלית או מרחוק בקובצי Gradle של הפרויקט. מערכת ה-build משתמשת בתצורות כדי לנהל - כלומר, ליצור, לפרוס ולכבות - את המכשירים האלה בזמן ביצוע בדיקות אוטומטיות.

התכונה הזו מאפשרת ל-Gradle הרשאות לראות לא רק את הבדיקות שאתם מריצים, אלא גם את מחזור החיים של המכשירים, ובכך לשפר את איכות להתנסות בדרכים הבאות:

טיפול בבעיות שקשורות למכשירים כדי להבטיח שהבדיקות יבוצעו
במכשירים וירטואליים, תמונות מצב של האמולטור משפרות את זמן ההפעלה של המכשיר ושימוש בזיכרון ולשחזר את המכשירים למצב נקי בין בדיקות
שמירה במטמון של תוצאות הבדיקה והרצה חוזרת רק של בדיקות שצפויים לספק תוצאות
מספקת סביבה עקבית להרצת הבדיקות בין מקומי ל- הרצת בדיקות מרחוק

יצירת מכשיר וירטואלי בניהול Gradle

אפשר לציין מכשיר וירטואלי שישמש את Gradle לבדיקה של בקובץ ה-build ברמת המודול. דוגמת הקוד הבאה יוצרת Pixel 2 להריץ את רמת API 30 כמכשיר שמנוהל על ידי Gradle.

Kotlin

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

Kotlin

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 הוא שם המכשיר שהגדרת בו סקריפט ה-build של Gradle (כמו pixel2api30), ו-BuildVariant הוא של האפליקציה שרוצים לבדוק.

ב-Windows:

gradlew device-nameBuildVariantAndroidTest

ב-Linux או ב-macOS:

./gradlew device-nameBuildVariantAndroidTest

כדי להריץ בדיקות בקבוצה של מכשירים בניהול Gradle, משתמשים את הפקודות הבאות.

ב-Windows:

gradlew group-nameGroupBuildVariantAndroidTest

ב-Linux או ב-macOS:

./gradlew group-nameGroupBuildVariantAndroidTest

פלט הבדיקה כולל נתיב לקובץ HTML שמכיל את דוח הבדיקה. שלך יכול גם לייבא תוצאות בדיקה ל-Android Studio לניתוח נוסף על ידי לחיצה על הפעלה > היסטוריית בדיקות בסביבת הפיתוח המשולבת (IDE).

הפעלת החלוקה לבדיקה

במכשירים שמנוהלים על ידי Gradle יש תמיכה בפיצול (Sharing) בדיקות, שמאפשר לפצל את הבדיקה במספר מופעים וירטואליים זהים של מכשירים, שנקראים פיצולים, שפועלים במקביל. השימוש בפיצול בדיקות יכול לעזור בהפחתת הביצוע הכולל של הבדיקה בזמן הזה בעלות של משאבי חישוב נוספים.

כדי להגדיר את מספר הפיצולים שרוצים להשתמש בהם בהרצת בדיקה נתונה, הגדר הבאים בקובץ gradle.properties:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

כשמריצים בדיקות באמצעות האפשרות הזו, מכשירים שמנוהלים על ידי Gradle מקצים את ההקצאה מספר הפיצולים שציינת לכל פרופיל מכשיר בהרצת הבדיקה. אז בשביל לדוגמה, אם פרסתם את הבדיקות בקבוצת מכשירים של שלושה מכשירים והגדרתם numManagedDeviceShards או שניים, במכשירים שמנוהלים על ידי Gradle, יקצה ערך כולל של שישה מכשירים וירטואליים להרצת הבדיקה.

כשהבדיקות יושלמו, תוצאות הבדיקה ב-Gradle מפיקות את תוצאות הבדיקה בקובץ .proto לכל פיצול שנעשה בו שימוש בהרצת הבדיקה.

שימוש במכשירי בדיקה אוטומטיים

מכשירים בניהול Gradle תומכים בסוג של מכשיר אמולטור שנקרא מכשיר בדיקה (ATD), שעבר אופטימיזציה לצמצום משאבי המעבד והזיכרון כאשר והרצת הבדיקות האינסטרומנטטיביות. ATD משפרת את הביצועים בזמן ריצה בכמה דרכים:

הסרת אפליקציות שהותקנו מראש ולרוב לא שימושיות לבדיקת האפליקציה
להשבית שירותי רקע מסוימים שבדרך כלל לא שימושיים בדיקת האפליקציה
השבתת עיבוד החומרה

לפני שמתחילים, חשוב לוודא מעדכנים את האמולטור של Android לגרסה האחרונה גרסה זמינה. לאחר מכן מציינים ' -atd' כשמוגדרת תמונה בניהול Gradle במכשיר ה-build שלך ברמת המודול, כפי שמוצג בהמשך:

Kotlin

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?

בנוסף להפעלה במצב 'דפדפן ללא GUI', ATD גם מבצעת אופטימיזציה של הביצועים על הסרה או השבתה של אפליקציות ושירותים שבדרך כלל לא נדרשים בדיקה של קוד האפליקציה. בטבלה הבאה יש סקירה כללית של הרכיבים. הסרנו או השבתנו תמונות של ATD ותיאורים של הסיבות האפשריות לכך שימושי.

מה יוסר מתמונות של ATD	סיבות אפשריות לכך שלא תצטרכו את התכונה הזו כשמבצעים בדיקות אוטומטיות
אפליקציות של מוצרי Google: דואר מפות Chrome הודעות חנות Play ועוד	הבדיקות האוטומטיות צריכות להתמקד בלוגיקה של האפליקציה שלכם, בהנחה כדי שאפליקציות אחרות או הפלטפורמה יפעלו בצורה תקינה. באמצעות אובייקטים של אספרסו, ניתן להתאים ולאמת את הכוונות היוצאות שלכם או אפילו לספק נתיבים תגובות במקום תגובות לכוונות אמיתיות.
הגדרות של אפליקציות ושירותים: תצורת Carrier מידע למקרה חירום מאתחל חד-פעמי PhotoTable (שומרי מסך) הקצאה אפליקציית ההגדרות מנהל האחסון הגדרת ה-APN של הטלפוניה חיתוך טפטים בוחר טפטים	באפליקציות האלה מוצג ממשק GUI למשתמשי הקצה כדי להחליף את הפלטפורמה הגדרות, להגדיר את המכשיר או לנהל את האחסון במכשיר. בדרך כלל מחוץ להיקף של בדיקות אוטומטיות ברמת האפליקציה. הערה: ספק ההגדרות עדיין זמין בתמונה של ATD.

ממשק משתמש	הבדיקות האוטומטיות צריכות להתמקד בלוגיקה של האפליקציה שלכם, בהנחה כדי שאפליקציות אחרות או הפלטפורמה יפעלו בצורה תקינה.
אפליקציות ושירותים של AOSP: דפדפן2 יומן Camera2 אנשי קשר Dialer שעון שולחני גלריה 2 LatinIME Launcher3QuickStep מוזיקה תיבת החיפוש המהיר הגדרות בינה מלאכותית	האפליקציות והשירותים האלה בדרך כלל לא נכללים את קוד האפליקציה שלכם.

להשתמש במכשירים של Firebase Test Lab

אפשר להריץ בדיקות אוטומטיות בקנה מידה נרחב באמצעות Firebase Test מכשירי Lab בזמן השימוש מכשירים שמנוהלים על ידי Gradle. Test Lab מאפשרת לכם להריץ את הבדיקות בו-זמנית מגוון רחב של מכשירי Android, גם פיזיים וגם וירטואליים. הבדיקות האלה פועלות ב- במרכזי הנתונים המרוחקים של Google. באמצעות תמיכה ממכשירים שמנוהלים על ידי Gradle, ה-build המערכת יכולה לנהל באופן מלא בדיקות פעילות במכשירים אלה של Test Lab, על סמך את ההגדרות האישיות שלכם.

שנתחיל?

השלבים הבאים מתארים איך להתחיל להשתמש במכשירים של Firebase Test Lab עם מכשירים שמנוהלים על ידי Gradle. שימו לב שהשלבים האלה משתמשים ב-CLI של gcloud כדי לספק למשתמש פרטי כניסה מסוימים, שעשויים לא לחול על כל סביבות הפיתוח. לקבלת מידע נוסף על תהליך האימות שבו תשתמשו בהתאם לצרכים שלכם, ראו Application Default Credentials עובד/ת.

כדי ליצור פרויקט Firebase, נכנסים אל מסוף Firebase. לוחצים על מוסיפים פרויקט ופועלים לפי ההוראות במסך כדי ליצור פרויקט. חשוב לזכור את מזהה הפרויקט.

הערה: ההפעלה של Google Analytics היא אופציונלית ולא נדרשת כדי להשתמש ב-Firebase Test Lab. אלא אם בכוונתך להשתמש באחד מהשירותים הבאים, התלויים ב: ב-Google Analytics, מומלץ לא להפעיל את Google Analytics במקרים הבאים: שנדרשת בתהליך העבודה ליצירת הפרויקט.
כדי להתקין את Google Cloud CLI, פועלים לפי השלבים הבאים: להתקין את ה-CLI של gcloud.
מגדירים את הסביבה המקומית.
1. קישור לפרויקט Firebase ב-gcloud:
```
gcloud config set project FIREBASE_PROJECT_ID
```
2. אישור השימוש בפרטי הכניסה של המשתמש לצורך גישה ל-API. ההמלצות שלנו באמצעות העברה קובץ JSON של חשבון שירות ב-Gradle באמצעות DSL בסקריפט ה-build ברמת המודול:
  Kotlin
  
  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
```
  הערה: כדי לגשת למכסות מעבר לסף ללא עלות, צריך לפרויקט Firebase שלכם חייב להיות ב תוכנית תמחור ותשלומים מפולפלת. אפשר לשדרג לתוכנית התמחור והתשלומים של Blaze במסוף Firebase.
הפעלת ממשקי ה-API הנדרשים.

ב בדף ספריית ה-API של Google Developers Console, מפעילים את Cloud Testing API ו-Cloud Tool Results API על ידי הקלדת שמות ממשקי ה-API בתיבת החיפוש שבחלק העליון של המסוף, ואז לחיצה על הפעלת API בדף הסקירה הכללית של כל ממשק API.
מגדירים את פרויקט Android.
1. מוסיפים את הפלאגין של Firebase Test Lab לסקריפט ה-build ברמה העליונה:
  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 לסקריפט ה-build ברמת המודול:
  Kotlin
  
  plugins { ... id "com.google.firebase.testlab" }
  מגניב
  
  plugins { ... id 'com.google.firebase.testlab' }

הגדרת מכשיר Test Lab

אפשר להגדיר ל-Gradle מכשיר ב-Firebase Test Lab שישמש לבדיקה בסקריפט ה-build ברמת המודול. דוגמת הקוד הבאה יוצרת מכשיר Pixel 3 עם רמת API 30 המנוהל על ידי Gradle, שנקרא מכשיר Test Lab שמנוהל על ידי Gradle ftlDevice החסימה של firebaseTestLab {} זמינה כשמחילים את com.google.firebase.testlab למודול שלך.

Kotlin

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.

אופטימיזציה של הרצת הבדיקות באמצעות חלוקה חכמה

בדיקות במכשירי Test Lab שמנוהלים על ידי Gradle תומכות בפיצול חכם. חכמה חלוקה לפיצולים, תפיץ באופן אוטומטי את הבדיקות בין פיצולים, כך שכל פיצול פועל למשך זמן זהה בערך, וכך מפחית את מאמצי ההקצאה הידנית משך הזמן הכולל של הרצת הבדיקה. פיצול חכם מתבסס על היסטוריית הבדיקות או על המידע שלכם כמה זמן נמשכה הרצת הבדיקות בעבר, כדי להפיץ את הבדיקות בדרך אופטימלית. לתשומת ליבכם: גרסה 0.0.1-alpha05 של הפלאגין Gradle כדי לאפשר שימוש בפיצול חכם ב-Firebase Test Lab.

כדי להפעיל פיצול חכם, יש לציין את משך הזמן לבדיקות בכל פיצול מה צריך לקחת. צריך להגדיר את יעד הזמן המפוצל של היעד לחמישה לפחות דקות פחות מ-timeoutMinutes כדי למנוע את המצב של פיצולים הבדיקות יבוטלו לפני שהבדיקות יסתיימו.

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

למידע נוסף, אפשר לקרוא על אפשרויות DSL של מכשיר 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 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
  }
}