Developer Device Platform Device Run for Android

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

במדריך הזה מוסבר איך להריץ בדיקת אינסטרומנטציה ל-Android באמצעות gcloud beta device-run CLI ולמצוא את התוצאות במסוף Google Cloud . ההנחה היא שיש לכם חשבון ופרויקט ב- Google Cloud .

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

לפני שמתחילים

בשלבים האלה אנחנו מניחים שכבר:

1. נוצר פרויקט Google Cloud .
2. מגדירים את הפלטפורמה למכשירים למפתחים לפי המדריך למתחילים.
3. האימות בוצע באמצעות gcloud בטרמינל.
4. עיינתי בסקירה הכללית של Device Run כדי לקבל מידע כללי.
5. יצירת בדיקה עם מכשור ל-Android.

שלב 1. בחירת מכשירים

באמצעות device-run CLI, אפשר להריץ בדיקות של Android במכשירים פיזיים ווירטואליים זמינים. כדי לראות את הרשימה המלאה של המכשירים הזמינים, אפשר לעיין בקטלוג המכשירים האינטראקטיבי או להריץ את הפקודה:

gcloud beta device-run devices list

פלט לדוגמה:

ID        MAKE    NAME     MODEL FORM      OS_VERSION CAPACITY  AVAILABILITY  PRODUCTS
tegu-35   Google  Pixel 9a tegu  PHYSICAL  35         MEDIUM    LOW           Automation, Streaming
tokay-34  Google  Pixel 9  tokay PHYSICAL  34         HIGH      HIGH          Automation, Streaming

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

שלב 2. הרצת בדיקת האינסטרומנטציה

הערה: הדגלים האלה נדרשים לבדיקות ב-Android:

• מכשיר: מציינים מכשיר באמצעות --device: --device shiba-35
• ‫Test: מציינים את קובץ ה-APK של הבדיקה באמצעות --test: --test /path/to/test.apk

כדי להריץ את הבדיקה, מריצים פקודה שדומה לפקודה הבאה, אבל עם מזהי המכשירים ונתיב הבדיקה שלכם:

gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk

תיקיית דוחות התוצאות של העבודה נמצאת בנתיב Cloud Storage, כמו gs://BUCKET_NAME/automation/sessions/SESSION_ID/. בודקים את פלט הבדיקה של הקישור, שדומה לזה: https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/.

שלב 3. הגדרת בדיקה

הערה: כדי לראות את כל האפשרויות הזמינות לפקודה submit instrumentation, מריצים את הפקודה gcloud beta device-run sessions submit instrumentation --help.

אחרי שמריצים בדיקה, אפשר לבדוק כמה אפשרויות הגדרה:

• כמה מכשירים: כדי להריץ את אותם הבדיקות בכמה מכשירים, צריך לספק את הדגל --device עם כמה מזהי מכשירים שמופרדים באמצעות פסיקים, כמו --device shiba-34,tokay-36, או עם כמה דגלים --device, שכל אחד מהם מציין מזהה מכשיר נפרד (למשל --device shiba-34 --device tokay-36).
• אפליקציות נוספות: אפשר לציין קובץ APK אחד או יותר להתקנה לפני הפעלת הבדיקות באמצעות הדגל --apps=path1,path2,...,path_n. הסדר שאתם מציינים הוא הסדר שבו האפליקציות האלה יותקנו.
• זמן קצוב לתפוגה של בדיקה: הגבלת משך הביצוע: --instrumentation-timeout=10m (הטווח התקין הוא 1m עד 1h, וערך ברירת המחדל הוא 5m).
• קטגוריה של Cloud Storage בהתאמה אישית: אם לא מציינים קטגוריה של Cloud Storage באמצעות הדגל --bucket-name=, Google Cloud CLI ישתמש בקטגוריית ברירת מחדל בשם PROJECT_ID-devicerun.
• ניסיונות חוזרים של בדיקות לא יציבות: הגדרת מספר הניסיונות המקסימלי להרצה מחדש של בדיקות לא יציבות: --flaky-test-attempts=3 (ברירת המחדל היא ניסיון אחד).

שלב 4. שימוש ב-sharding

כדי לכלול את פלטפורמת המכשירים למפתחים בתהליך עבודה של אינטגרציה רציפה (CI) ופיתוח רציף (CD), כדאי לפצל את הבדיקות. חלוקת בדיקות (Test sharding) מחלקת קבוצה של בדיקות לתתי-קבוצות (shards) שפועלות בנפרד ובבידוד. פלטפורמת המכשירים למפתחים מריצה כל שבר במקביל באמצעות כמה מכשירים, ומשלימה את כל סדרת הבדיקות בפחות זמן.

שימו לב: בדיקות של חלוקת נתונים עשויות להיות יקרות יותר. למרות שחלוקת הבדיקות (sharding) מקצרת את הזמן שנדרש להפעלת כל הבדיקות, התקורה של הפעלת האפליקציה בכל חלק (shard) עלולה להגדיל את משך הזמן של כל מכשיר בנפרד.

שלב 4.1. בחירת אפשרות שרדינג

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

פלטפורמת המכשירים למפתחים תומכת בפיצול חכם ובפיצול אחיד. כשמחליטים איך לפצל את הבדיקות, כדאי לשקול את האפשרויות הבאות:

• אם כל מקרי הבדיקה יימשכו בערך אותו פרק זמן, אפשר להשתמש בפיצול אחיד (uniform sharding) ולחלק את כל מקרי הבדיקה ל-n רסיסים.

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

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

חלוקה אחידה

כדי לפצל את הבדיקות באמצעות פיצול אחיד, צריך לכלול את הדגלים --sharding-option=uniform ו---uniform-sharding-count= בפקודה sessions submit instrumentation באופן הבא:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
 --device shiba-34,tokay-36 \
    --sharding-option=uniform \
    --uniform-sharding-count=2

אמור להופיע פלט שמציין Job status: 2 running. השירות יוצר שני ג'ובים, אחד לכל מכשיר. מכיוון שהקלט בשני הג'ובים זהה, השירות מבצע אימות מרכזי, כלומר רק פעם אחת.

אחרי השלמת הפקודה, שתי המשימות יופיעו בנפרד בפלט הסופי:

JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED

חלוקה חכמה

כדי לפצל את הבדיקות באמצעות פיצול חכם, צריך לכלול את הדגלים --sharding-option=smart,‏ --smart-sharding-max-shard-count=, ‏ --smart-sharding-target-duration= (בדקות או בשעה אחת) ו---smart-sharding-record-name= בפקודה sessions submit instrumentation, באופן הבא:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34,shiba-35,tokay-36 \
    --sharding-option=smart \
    --smart-sharding-max-shard-count=3 \
    --smart-sharding-target-duration=5m \
    --smart-sharding-record-name=test.yaml

הפלט הסופי אמור להראות ששלוש משימות הופעלו:

Session [session-3cd0564a] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED
job-002   execution-000   PASSED

לפניכם סיכום של הדגלים של הפיצול החכם שבהם נעשה שימוש כאן:

• ‫--smart-sharding-max-shard-count=SMART_SHARDING_MAX_SHARD_COUNT – מציינים את המספר המקסימלי של רסיסים שייווצרו עבור חלוקה חכמה לרסיסים. אם המדיניות לא מוגדרת או מוגדרת כ-0, המערכת משתמשת במגבלות המקסימליות שמוגדרות על ידה. הטווח התקין הוא 0 עד 20 למכשירים פיזיים ו-0 עד 200 למכשירים וירטואליים.

• ‫--smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION – מציינים את זמן הביצוע המטורגט (לדוגמה, 2m, ‏ 10m, ‏ 1h) לכל שבר עבור חלוקה חכמה לשברים. הטווח התקין הוא מ-2 דקות עד שעה. חובה אם --sharding-option=smart.

• ‫--smart-sharding-record-name=SMART_SHARDING_RECORD_NAME – מציינים את השם של קובץ הרשומה של הפיצול החכם, לא כולל סיומת הקובץ. חובה כאשר ‎--sharding-option=smart. קובץ ה-YAML הזה נמצא ב Google Cloudקטגוריית האחסון שצוינה על ידי --bucket-name בספרייה smart-sharding/. אם הקובץ לא קיים, הוא ייווצר אוטומטית. אחרת, התוכן שלו יעודכן בסיום הסשן.

שלב 5. הצגה וניהול של הרצת הבדיקה

גם במצב אסינכרוני וגם במצב סינכרוני של הפקודה sessions submit instrumentation, אפשר להשתמש בפקודה sessions describe כדי לשלוח שאילתה לגבי סטטוס העבודה במהלך ההפעלה, או לקבל את התוצאה אחרי שהיא מסתיימת:

gcloud beta device-run sessions describe SESSION_ID

הפלט מסכם את תוצאות הבדיקה ומקשר לתוצאות ב Google Cloud מסוף. לדוגמה:

Session SESSION_ID finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

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

gcloud beta device-run sessions list

תקבלו פלט שמכיל את רשימת הסשנים בפרויקט, שדומה לזה:

SESSION_ID                                    START_TIME                STATE
session-4825e153                              2026-07-28T16:38:43.155Z  DONE
session-813ca602                              2026-07-28T22:40:32.415Z  DONE
session-67cd0570                              2026-07-16T08:25:55.474Z  DONE
session-17cc299c                              2026-07-14T14:31:33.649Z  DONE
session-911d0763                              2026-07-09T00:39:02.051Z  DONE
session-4e943fea                              2026-07-15T23:08:32.252Z  DONE
session-0132e458                              2026-08-20T18:33:19.751Z  DONE
session-1077f07b                              2026-07-28T22:35:43.848Z  DONE
session-71b054c6                              2026-07-15T01:15:41.643Z  DONE
session-4f8b2e45                              2026-08-06T23:11:56.161Z  DONE

הפקודה sessions list תומכת בכל אפשרויות הדגלים הרגילות של Google Cloud CLI. לדוגמה:

gcloud beta device-run sessions list --limit 5

התוצאה תהיה דומה ל:

SESSION_ID                            START_TIME                STATE
session-4825e153                      2026-07-28T16:38:43.155Z  DONE
session-813ca602                      2026-07-28T22:40:32.415Z  DONE
93ec2df2-d5bf-4c36-b7f7-c2a4fb0dc3ce  2026-07-03T05:10:58.015Z  DONE
session-67cd0570                      2026-07-16T08:25:55.474Z  DONE
session-17cc299c                      2026-07-14T14:31:33.649Z  DONE

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

gcloud beta device-run sessions list --filter RUNNING

אם יש לכם סשנים פעילים, התוצאות ייראו כך:

SESSION_ID        START_TIME  STATE
session-d7ff8b81              RUNNING

אחרת, תקבלו Listed 0 items.

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

gcloud beta device-run sessions cancel SESSION_ID

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

אם הסשן כבר הסתיים, רק הסטטוס הנוכחי מודפס. בקשה לביטול סשן שהסתיים היא לא שגיאה.

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

השלב הבא הוא איתור וניתוח של יומנים.