סקירה כללית של הפעלת מכשיר בפלטפורמה של מכשיר למפתחים

ברוכים הבאים ל-"הרצה במכשיר" ב-Developer Device Platform, שמאפשרת להריץ בדיקות וקובצי הפעלה בענן במכשירי Android פיזיים ווירטואליים ובמכשירי iOS פיזיים. בדף הזה מפורטות היכולות והמאפיינים המשותפים להרצת בדיקות אינסטרומנטציה של Android, קובצי הפעלה של Android ובדיקות iOS XCTest.

אם אתם עוברים מ-Firebase Test Lab ל-Developer Device Platform, כדאי לעיין במדריך להעברת נתונים, במדריך לתרגום פקודות ודגלים ובמיומנות ההעברה לסוכני AI.

כדי להשתמש ב-Google Cloud CLI, תצטרכו לספק את מזהה הפרויקט ב- Google Cloud . לסיכום של הפקודות, ראו: gcloud beta device-run

יכולות עיקריות

‫Developer Device Platform הרצה במכשיר הוא שירות של Google Cloud שמאפשר להריץ חבילות מקרים לבדיקה אוטומטיות במכשירים ניידים פיזיים ווירטואליים. התכונה "הרצה במכשיר" נוצרה במיוחד לתהליכי עבודה מודרניים של אינטגרציה רציפה (CI) ופריסה רציפה (CD). היא מאפשרת שליטה בשורת הפקודה באמצעות Google Cloud CLI‏ (gcloud beta device-run), כך שהצוותים יכולים להריץ, לנהל ולהרחיב חבילות מקרים לבדיקה בסביבות וירטואליות ובחומרה ייעודית.

1. בדיקות אוטומטיות בפלטפורמות שונות

  • תמיכה ב-Android וב-iOS: התכונה "הרצה במכשיר" תומכת בסביבות בדיקה מובנות, כולל בדיקות אינסטרומנטציה ב-Android (.apk), קובצי הפעלה ב-Android (קובצי בינארי שעברו קומפילציה) ובדיקות XCTest ב-iOS (.ipa או .zip).
  • טירגוט גמיש לפי מכשיר: טירגוט מכשירים פיזיים או מכשירים וירטואליים ספציפיים שמופיעים בקטלוג המכשירים באמצעות מזהי מערכת הפעלה ומזהי דגמים (למשל, דגמי Pixel או אייפון) דרך הדגל --device.
  • הרצה במקביל בכמה מכשירים: מריצים חבילות זהות של מקרים לבדיקה בו-זמנית בכמה מכשירים. כדי לעשות את זה, מציינים מזהי מכשירים מופרדים בפסיקים או מספקים כמה דגלים של --device.

2. מצבי הפעלה ואמצעי בקרה גמישים

  • שליחה סינכרונית ואסינכרונית: כברירת מחדל, הרצות הבדיקה פועלות באופן סינכרוני, ומוצג סיכום בסיום. הוספת הדגל --async מחזירה מזהה סשן באופן מיידי להפעלה ללא חסימה, שאפשר לעקוב אחריה מאוחר יותר באמצעות gcloud beta device-run sessions wait.
  • זמני קצובים לתפוגה בהתאמה אישית*: מגדירים מגבלות על משך הביצוע באמצעות --instrumentation-timeout או --xctest-timeout.
  • ניסיונות חוזרים של בדיקות לא יציבות (flaky tests): מגדירים את מספר הניסיונות המקסימלי לביצוע בדיקות לא יציבות באמצעות הדגל --flaky-test-attempts.

3. ניהול גרסאות תוכנה ויחסי תלות

  • סביבות בדיקה ניתנות להגדרה*: אפשר לגלות, לבדוק ולבחור גרסאות ספציפיות של סביבות תוכנה – כמו AndroidX Test Orchestrator ו-Apple Xcode – לפני שמתחילים את הרצת הבדיקות.
  • זיהוי גרסאות: משתמשים בפקודות gcloud beta device-run software-versions list ו-describe כדי לראות חבילות תוכנה פעילות, גרסאות נתמכות של מערכת ההפעלה ומפרטים של סביבות זמן ריצה שמוגדרות כברירת מחדל.

4. ניהול אחסון וארטיפקטים

  • שילוב עם Cloud Storage: קובצי הקלט של הבדיקות (קובצי APK, קובצי IPA, אפליקציות תומכות) ופריטי הפלט (יומנים, דוחות בדיקה) מאוחסנים ב-Cloud Storage.
  • גמישות בקטגוריות: כברירת מחדל, המערכת בוחרת באופן אוטומטי קטגוריית פרויקט בשם PROJECT_ID-devicerun או מנתבת לקטגוריה בהתאמה אישית שצוינה באמצעות הדגל --bucket-name. השליטה בקטגוריה הזו היא לגמרי בידיים שלכם, ואתם צריכים להסיר את התוכן שלה באופן ידני כשכבר לא צריך אותו, או להגדיר ניהול אוטומטי של מחזור החיים בקטגוריה. הוראות מפורטות זמינות במאמר מידע על מחיקת אובייקטים.
  • נתיבים ישירים לענן: הפניה ישירה לנתיבים קיימים ב-gs:// לקבצים גדולים כדי למנוע תקורה בהעלאה.

5. תכונות מתקדמות לבדיקות ב-Android

  • תזמור בדיקות ל-Android: מבודדים את ביצוע הבדיקה על ידי הרצת כל בדיקה במופע Instrumentation משלה, כדי למנוע מצב של אפליקציה משותפת ולבודד קריסות של האפליקציה.
  • פיצול בדיקות:
    • פיצול אחיד: פיצול שווה של מקרי הבדיקה בין מספר מסוים של שברים (--sharding-option=uniform).
    • חלוקה חכמה למקטעים: שימוש בנתונים היסטוריים של ביצוע בדיקות כדי לאזן באופן דינמי את מקרי הבדיקה בין המקטעים, במטרה להגיע למשך ביצוע כולל ספציפי (--sharding-option=smart).

6. ניהול סשנים וניתוח ביצועים

  • שליטה מלאה בסשן: הצגה, תיאור, סינון או ביטול של הרצות בדיקה פעילות או היסטוריות באמצעות sessions list,‏ sessions describe ו-sessions cancel.
  • אימות מוקדם של קלט: מבצע אימות אוטומטי של קובצי בדיקה בינאריים ופריטי הגדרה שנשלחו, ומציג פרטי שגיאה מפורשים ואת שורש הבעיה (כמו אי-התאמות בחבילת היעד) כשמתרחשות שגיאות.

הגדרות ליבה

דגלי חובה

שימו לב שהדגלים הבאים נדרשים:

  • מכשיר: מציינים מכשיר באמצעות --device: --device shiba-35 או --device iphonese3-18-4
  • בדיקה או קובץ הפעלה: מציינים את חבילת הבדיקה באמצעות --test (--test /path/to/test.apk או --test /path/to/MyTests.zip) להרצות של בדיקות, או מציינים את קובץ ההפעלה הבינארי או הסקריפט באמצעות --executable (--executable /path/to/my_executable) להרצות של קובצי הפעלה ב-Android.

אפשרויות ההגדרה הבאות נפוצות בסשנים של "הרצה במכשיר".

נתיבי קלט ופלט ב-Cloud Storage

  • קטגוריה מותאמת אישית של Cloud Storage: אתם יכולים לציין קטגוריה מותאמת אישית של Cloud Storage לקלט ולפלט: --bucket-name=my-custom-bucket אם לא תציינו קטגוריה של Cloud Storage באמצעות הדגל --bucket-name=, ה-Google Cloud CLI ישתמש בקטגוריית ברירת המחדל שנקראת PROJECT_ID-devicerun.
  • קובצי קלט: כשמציינים נתיב מקומי באמצעות הדגלים --test,‏ --executable,‏ --apps,‏ --additional-apps,‏ --other-files-to-push או --xctestrun-file, ה-Google Cloud CLI מעתיק אותו באופן אוטומטי לקטגוריה של Cloud Storage בנתיב gs://BUCKET_NAME/automation/inputs/DATE_TIME_FOUR_CHARS_SUFFIX/ בכל פעם שמריצים את הפקודה, כאשר ערך ברירת המחדל של BUCKET_NAME הוא PROJECT_ID-devicerun.
  • נתיבים ב-Cloud: העלאת קבצים גדולים יכולה לקחת הרבה זמן, אז כדי לחסוך זמן אפשר להפנות אליהם ישירות באמצעות הנתיבים שלהם ב-Cloud Storage gs://.
  • ‫Result files: פריטי המידע שנוצרו מועלים לקטגוריה של Cloud Storage בנתיב gs://BUCKET_NAME/automation/sessions/session-[SESSION_ID]/.

אימות קלט

פלטפורמת Developer Device Platform מנסה לאמת את הקלט, כולל פריטי מידע שנוצרו בתהליך הפיתוח (artifacts), ומחזירה את השגיאה ERROR במקום PASSED או FAILED כשהיא נתקלת בקלט שגוי:

Session [session-94b57778] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   ERROR

עכשיו מוסיפים את --full לפקודה sessions describe כדי לראות פרטים נוספים על הסשן:

gcloud beta device-run sessions describe --full session-94b57778

הפלט שיתקבל ייראה בערך כך:

name: projects/user-test1/locations/global/sessions/session-94b57778
sessionConfig:
  displayName: instrumentation-session
  jobConfigs:
  -   action:
      androidInstrumentationTest:
        testInstallable:
          files:
          -   gcsInputFile:
              path: gs://user-test1-devicerun/automation/inputs/2026-09-16_18:55.17372947_EECF/my-test.apk
    allocationConfig:
      deviceConfigs:
      -   actions:
        -   androidLogcat: {}
        requirement:
          deviceId: mediumphone-arm-34
    displayName: job-000
  outputDirectoryConfig:
    gcsOutputDirectory:
      path: gs://user-test1-devicerun/automation/sessions
sessionReport:
  endTime: '2026-09-16T18:55:49.721Z'
  id: ed681f23-669b-4464-8a93-b28456e58136
  jobReports:
  -   displayName: job-000
    endTime: '2026-09-16T18:55:45.839Z'
    executionReports:
    -   displayName: execution-000
      endTime: '2026-09-16T18:55:46.694Z'
      id: ce370173-af94-4dd7-acc6-0863e4d2e9ec
      result:
        cause:
          summary:
            message: The instrumentation target package does not match any of the
              installable packages.
            reason: INSTRUMENTATION_TARGET_MISMATCH
            type: CUSTOMER
        resultType: ERROR
      startTime: '1970-01-01T00:00:00Z'
      status:
        statusType: PENDING
    id: 953b5106-3c20-40f0-aceb-18af89cd1b83
    result:
      cause:
        summary:
          message: The instrumentation target package does not match any of the installable
            packages.
          reason: INSTRUMENTATION_TARGET_MISMATCH
          type: CUSTOMER
      resultType: ERROR
    startTime: '2026-09-16T18:55:31.651Z'
    status:
      statusType: DONE
  result:
    resultType: ERROR
  startTime: '2026-09-16T18:55:24.442Z'
  status:
    statusType: DONE

המאמרים הבאים

מריצים בדיקת אינסטרומנטציה של Android, קובץ הפעלה של Android או iOS XCTest באמצעות Developer Device Platform.