במדריך הזה מוסבר איך להריץ בדיקת אינסטרומנטציה ל-Android באמצעות gcloud beta device-run CLI ולמצוא את התוצאות במסוף Google Cloud . ההנחה היא שיש לכם חשבון ופרויקט ב- Google Cloud .
כדי להשתמש ב-Google Cloud CLI הזה, תצטרכו לספק את מזהה הפרויקט שלכם ב- Google Cloud . במאמר gcloud beta device-run מופיע סיכום של הפקודות.
לפני שמתחילים
בשלבים האלה אנחנו מניחים שכבר:
- נוצר פרויקט Google Cloud .
- מגדירים את הפלטפורמה למכשירים למפתחים לפי המדריך למתחילים.
- האימות בוצע באמצעות
gcloudבטרמינל. - עיינתי בסקירה הכללית של Device Run כדי לקבל מידע כללי.
- יצירת בדיקה עם מכשור ל-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. הגדרת בדיקה
אחרי שמריצים בדיקה, אפשר לבדוק כמה אפשרויות הגדרה:
- כמה מכשירים: כדי להריץ את אותם הבדיקות בכמה מכשירים, צריך לספק את הדגל
--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(ברירת המחדל היא ניסיון אחד).
הפעלת Orchestrator
פלטפורמת המכשיר למפתחים תומכת ב-Android Test Orchestrator, שמאפשר להריץ כל אחת מהבדיקות של האפליקציה בתוך קריאה משלה ל-Instrumentation.
כשמשתמשים ב-Orchestrator, אתם:
מומלץ להימנע ממצב משותף. כל בדיקה פועלת במופע
Instrumentationמשלה. לכן, אם הבדיקות שלכם משתפות את מצב האפליקציה, רוב המצב המשותף הזה מוסר מהמעבד או מהזיכרון של המכשיר אחרי כל בדיקה. כדי להסיר את כל המצב המשותף מהמעבד ומהזיכרון של המכשיר אחרי כל בדיקה, צריך לכלול את ההגדרהclearPackageDataבאופן הבא:--additional-test-options clearPackageData=trueבידוד קריסות. אם בדיקה אחת קורסת, היא משביתה רק את המופע שלה ב-
Instrumentation. המשמעות היא שהבדיקות האחרות שלכם עדיין יפעלו ויספקו תוצאות בדיקה מלאות.
ב-Developer Device Platform, תזמור בדיקות ל-Android מושבת כברירת מחדל. כדי להפעיל את Orchestrator ולציין את הגרסה שבה רוצים להשתמש במהלך הפעלת הבדיקה, מעבירים את הגרסה שבחרתם לדגל --orchestrator-version=ORCHESTRATOR_VERSION בפקודה sessions submit
instrumentation, כך:
gcloud beta device-run sessions submit instrumentation \
--device shiba-35 \
--test ./ANDROID_TESTS.apk \
--orchestrator-version=1.4.1
מגדירים את הדגל לערך auto כדי להשתמש בגרסת Orchestrator שמוגדרת כברירת מחדל במערכת.
שלב 4. שימוש ב-sharding
כדי לכלול את Developer Device Platform בתהליך עבודה של CI/CD, כדאי לפצל את הבדיקות. חלוקת בדיקות (Test sharding) מחלקת קבוצה של בדיקות לתתי-קבוצות (shards) שפועלות בנפרד ובבידוד. פלטפורמת המכשירים למפתחים מריצה כל שבר במקביל באמצעות כמה מכשירים, ומסיימת את כל סדרת הבדיקות בפחות זמן.
שלב 4.1. בחירת אפשרות שרדינג
אם יש לכם רק מספר קטן של תרחישי בדיקה בעבודות, או שזמן הביצוע הכולל של כל תרחישי הבדיקה לא ארוך, אין צורך להשתמש בפיצול. אם יש לכם מספר גדול של תרחישי בדיקה, או שזמן הביצוע הכולל של כל תרחישי הבדיקה ארוך, כדאי להשתמש בפיצול.
Developer Device Platform תומכת בפיצול חכם ובפיצול אחיד. כשמחליטים איך לפצל את הבדיקות, כדאי לשקול את האפשרויות הבאות:
אם כל מקרי הבדיקה יימשכו בערך אותו פרק זמן, אפשר להשתמש בפיצול אחיד (uniform sharding) ולחלק את כל מקרי הבדיקה ל-
nרסיסים.אם יש הבדלים גדולים בין זמני ההרצה של תרחישי בדיקה שונים, כדאי להשתמש בפיצול חכם. Developer Device Platform משתמשת בהיסטוריה של זמן ההפעלה של הבדיקות כדי ליצור רסיסים שונים, ומנסה להשלים את כל הרסיסים בפרק זמן דומה.
חלוקה אחידה של נתונים
כדי להשתמש בפיצול אחיד של הבדיקות, צריך לכלול את הדגלים --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
הפקודה מוחזרת באופן מיידי, כי הסשן רק מסומן לביטול. הביטול מתבצע באופן אסינכרוני בקצה העורפי.
אם הסשן כבר הסתיים, רק הסטטוס הנוכחי יודפס. בקשה לביטול סשן שהסתיים היא לא שגיאה.
המאמרים הבאים
השלב הבא הוא איתור וניתוח של יומנים.