במדריך הזה מוסבר איך להריץ בדיקת אינסטרומנטציה ל-Android באמצעות gcloud beta device-run CLI ולמצוא את התוצאות במסוף Google Cloud . ההנחה היא שיש לכם חשבון ופרויקט ב- Google Cloud .
כדי להשתמש ב-Google Cloud CLI הזה, תצטרכו לספק את מזהה הפרויקט שלכם ב- Google Cloud .
לפני שמתחילים
השלבים האלה מניחים שכבר יצרתם Google Cloud פרויקט, השלמתם את שלבי ההגדרה במדריך למתחילים של Developer Device Platform ועברתם אימות ב-gcloud במסוף.
בנוסף, תצטרכו להכין בדיקת אינסטרומנטציה של Android להרצה. הנחיות מפורטות מופיעות במאמר בנושא יצירת בדיקות עם מכשור.
בנוסף, צריך לזהות את מזהי המכשירים שרוצים להריץ בהם את עומסי העבודה. הוראות מפורטות מופיעות בקטלוג המכשירים.
הרצת בדיקה
אחרי שאתם יודעים את המזהים של המכשירים שזמינים לבדיקת האפליקציה, אתם יכולים לציין מכשירים באמצעות הפקודה gcloud beta device-run sessions submit
instrumentation והדגל --device כדי להריץ בדיקות מכשור.
כדי להריץ את הבדיקה, מריצים פקודה שדומה לפקודה הבאה, אבל עם מזהי המכשירים ונתיב הבדיקה שלכם:
gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk
תיקיית דוחות התוצאות של העבודה נמצאת בנתיב Cloud Storage, כמו gs://<your_project_id>/automation/sessions/session-id/. בודקים את הפלט של הקישור, שדומה לזה:
https://console.cloud.google.com/storage/browser/your_project_id/automation/sessions/session-id/
הגדרת בדיקה
אחרי שמריצים בדיקה, אפשר לבדוק כמה אפשרויות הגדרה:
- כדי להריץ את אותן בדיקות בכמה מכשירים, צריך לספק את האפשרות
--deviceכמה פעמים, למשל--device shiba-34 --device tokay-36. - אפשר לציין באופן אופציונלי קובץ APK אחד או יותר להתקנה לפני הפעלת הבדיקות באמצעות הדגל
--apps=path1,path2,...,path_n. הסדר שאתם מציינים הוא הסדר שבו האפליקציות האלה יותקנו. - צריך לציין את ה-APK של הבדיקה באמצעות הדגל
--test. - כשמציינים נתיב מקומי באמצעות הדגלים
--appsאו--test, ה-CLI של Google Cloud מעתיק אותו אוטומטית ל-bucket של Cloud Storage בנתיבgs://my-project-id/automation/inputs/date_time_four_chars_suffix/בכל פעם שמריצים את הפקודה. - העלאה של קובצי APK גדולים יכולה לקחת זמן, ולכן אפשר להפנות ישירות לקובצי ה-APK באמצעות נתיבי
gs://Cloud Storage שלהם כדי לחסוך זמן העלאה.
הפקודה sessions submit instrumentation חוסמת את תוצאות הסשן כברירת מחדל, כלומר היא תמתין לסיום של הרצת הבדיקה ותציג תוצאות שדומות לתוצאות הבאות:
Using the default Cloud Storage bucket [gs://<my-project-id>] for input and result files. Will create the bucket if it does not exist.
Uploading [app.apk].
Uploading [test.apk].
Initiated long-running operation [operation-number] to create session.
Creating session [session-id] in location [global].
Result files will be stored at [https://console.cloud.google.com/storage/browser/<my-project-id>/automation/sessions/session-id/].
Waiting for session [session-id] to complete....done.
Session [session-id] finished with result [FAILED].
JOB NAME EXECUTION NAME EXECUTION RESULT
job-000 all FAILED: 2 test cases failed, 5 passed
כדי להריץ את הפקודה באופן אסינכרוני, כוללים את הדגל --async. כך הפקודה יכולה לצאת מיד אחרי העלאת הקבצים ל-Cloud Storage והדפסת מזהה הפעולה ומזהה הסשן. אפשר להשתמש בפקודה wait ובמזהה הפעולה כדי להמתין להרצה. החסימה תהיה בתוקף עד לסיום העבודה:
gcloud beta device-run operations wait your_operation_id
שימוש ב-sharding
כדי לכלול את פלטפורמת מכשירי הפיתוח בתהליך עבודה של אינטגרציה רציפה (CI) ופיתוח רציף (CD), כדאי לשקול לפצל את הבדיקות. חלוקת בדיקות (Test sharding) מחלקת קבוצה של בדיקות לתתי-קבוצות (shards) שפועלות בנפרד ובבידוד. פלטפורמת המכשירים למפתחים מריצה כל שבר במקביל באמצעות כמה מכשירים, ומשלימה את כל סדרת הבדיקות בפחות זמן.
אפשרויות שרדינג
אם יש לכם רק מספר קטן של תרחישי בדיקה בעבודות, או שזמן הביצוע הכולל של כל תרחישי הבדיקה לא ארוך, אין צורך להשתמש בפיצול. אם יש לכם מספר גדול של תרחישי בדיקה, או שמשך הביצוע הכולל של כל תרחישי הבדיקה ארוך, כדאי להשתמש ב-sharding.
פלטפורמת המכשירים למפתחים תומכת בפיצול חכם ובפיצול אחיד. כשמחליטים איך לפצל את הבדיקות, כדאי לשקול את האפשרויות הבאות:
אם כל מקרי הבדיקה יימשכו בערך אותו פרק זמן, אפשר להשתמש בפיצול אחיד (uniform sharding) ולחלק את כל מקרי הבדיקה ל-
nרסיסים.אם יש הבדלים גדולים בין זמני ההרצה של תרחישי בדיקה שונים, כדאי להשתמש בפיצול חכם. פלטפורמת המכשירים למפתחים משתמשת בהיסטוריה של זמן ההפעלה של הבדיקות כדי ליצור רסיסים שונים, ומנסה להשלים את כל הרסיסים בפרק זמן דומה.
חלוקה אחידה של נתונים
כדי להפעיל חלוקה למקטעים של הבדיקות עם חלוקה אחידה למקטעים, צריך לכלול את הדגלים --sharding-option=uniform ו---uniform-sharding-count= בפקודה sessions submit instrumentation באופן הבא:
gcloud beta device-run sessions submit instrumentation \
--test path/to/test.apk \
--device shiba-34 \
--device 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 \
--device shiba-35 \
--device 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-max-shard-count: מציין את המספר המקסימלי של רסיסים שייווצרו. מספר המכשירים שצוין בדגל--deviceחייב להיות קטן מהערך הזה או שווה לו.
--smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION– מציינים את זמן הביצוע המטורגט (למשל, 2 דקות, 10 דקות, שעה) לכל רסיס עבור חלוקה לרסיסים חכמה. הטווח התקין הוא מ-2 דקות עד שעה. חובה אם--sharding-option=smart.
--smart-sharding-record-name=SMART_SHARDING_RECORD_NAME– מציינים את השם של קובץ הרשומה של הפיצול החכם, לא כולל סיומת הקובץ. חובה כאשר --sharding-option=smart. קובץ ה-YAML הזה נמצא ב Google Cloudקטגוריית האחסון שצוינה על ידי--bucket-nameבספרייהsmart-sharding/. אם הקובץ לא קיים, הוא ייווצר אוטומטית. אחרת, התוכן שלו יעודכן בסיום הסשן.
עיון בנתוני הניסוי וניהול שלהם
גם במצב אסינכרוני וגם במצב סינכרוני של הפקודה 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/your_project_id-devicerun/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
כדי לבטל סשן פעיל, מריצים את הפקודה הבאה עם מזהה הסשן:
gcloud beta device-run sessions cancel your_session_id
המאמרים הבאים
השלב הבא הוא איתור וניתוח של יומנים.