Developer Device Platform Device Run

במדריך הזה מוסבר איך להריץ בדיקת אינסטרומנטציה ל-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

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

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