פתרון בעיות ושאלות נפוצות בנושא פלטפורמת המכשירים למפתחים

תצוגה מקדימה

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

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

פתרון בעיות

למה לוקח כל כך הרבה זמן להריץ את הבדיקה?

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

בדיקות שמופעלות בכל רמת קיבולת של מכשיר עשויות להימשך זמן רב יותר בגלל הגורמים הבאים:

• תנועת הגולשים, שמשפיעה על זמינות המכשיר ועל מהירות הבדיקה.
• כשלים במכשיר או בתשתית, שיכולים לקרות בכל שלב. כדי לבדוק אם יש תשתית מדווחת ל-Developer Device Platform, אפשר להיכנס ללוח הבקרה Google Cloud Personalized Service Health.

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

למה אני מקבל תוצאות לא חד-משמעיות של בדיקות?

תוצאות לא חד-משמעיות של בדיקות מתרחשות בדרך כלל בגלל ביטול של הרצת בדיקות או בגלל שגיאות בתשתית. בנוסף לערכים PASSED ו-FAILED, יכול להיות שהפלטפורמה Developer Device Platform תחזיר את הערכים ERROR, TIMED_OUT ו-CANCELLED.

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

כדי לגלות את הסיבה לשגיאה, מבצעים את השלבים הבאים:

1. בודקים אם יש הפסקות זמניות ידועות בשירות בלוח הבקרה Google Cloud Service Health.

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

   הערה: בפלטפורמת המכשירים למפתחים לא נגבים תשלומים על שגיאות בתשתית.

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

למה הריצה של הבדיקות שלי נמשכה יותר זמן אחרי שחילקתי אותן?

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

למה לוקח הרבה זמן עד שהבדיקה מתחילה?

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

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

הערה: הזמן שבו הבדיקה ממתינה למכשיר זמין לא נכלל בזמן החיוב.

למה לוקח כל כך הרבה זמן עד שהבדיקה מסתיימת?

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

פתרון בעיות ספציפיות ל-Android

האפליקציה לא מחזירה נתונים ואי אפשר לאתר צילומי מסך

פריטי מידע של ביצוע בדיקה (כמו צילומי מסך וקבצי יומן) מאוחסנים ב-Cloud Storage ומוצגים ישירות במסוף Google Cloud . בודקים שהקציתם תפקידים ברמת הפרויקט.

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

• קריאה וכתיבה לקטגוריות ולאובייקטים ב-Cloud Storage
• הורדת קובצי קלט של Cloud Storage למערכת הפנימית
• העלאת קבצים מהמערכת הפנימית לקטגוריית הפלט ב-Cloud Storage

יכול להיות שיש לכם גישה לקטגוריה ולקובץ ב-Cloud Storage, אבל שהקטגוריה הזו נמצאת בבעלות של פרויקט Google Cloud אחר מזה שבו נעשה שימוש ב-DDP. לכן, לחשבון השירות של פלטפורמת מכשירי הפיתוח אין גישה אליו.

יכול להיות שיהיו לכם גם אמצעי בקרה נוספים על הגישה לקטגוריות נתונים ספציפיות. במאמר הפעלת בדיקה במכשיר מוסבר איך לכלול קבצים בבדיקות.

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

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

אלה כמה מהסיבות הנפוצות לבעיה הזו:

תיאור הבעיה	פתרון אפשרי
מקרה הבדיקה לא הופעל בגלל שהזמן הקצוב לתפוגה חלף. אם משך הזמן הכולל של הבדיקות ארוך יותר מהזמן הקצוב לתפוגה שציינתם או מהזמן הקצוב המקסימלי לתפוגה, פלטפורמת מכשיר הפיתוח מבטלת את שאר מקרי הבדיקה.	כדי לוודא שכל הבדיקות יושלמו, צריך להגדיל את הזמן הקצוב לתפוגה של האינסטרומנטציה של הבדיקה באמצעות `--instrumentation-timeout`. אם עדיין לא עשיתם זאת, כדאי לפצל את הבדיקות כך שכל חלק יריץ קבוצת משנה של הבדיקות ויסתיים תוך פרק זמן קצר יותר. אם כבר הפעלתם את הפיצול, הגדילו את מספר הרסיסים.
השלמת תרחיש הבדיקה נכשלה כי הוא הסתיים מוקדם מדי או נתקע. יכול להיות שהבדיקה תסתיים לפני הזמן בגלל חריגה שלא נתפסה או בגלל שגיאת טענה. יכול להיות שמקרים לבדיקה ייתקעו בלולאה אינסופית או שלא יוכלו להמשיך, למשל אם האפליקציה לא מציגה את התצוגה הנכונה והמקרה לבדיקה לא יכול לבצע את הפעולה בממשק המשתמש.	בודקים את הסרטון ואת logcat כדי לברר איפה הבדיקה נעצרה.
מפעיל בדיקות מותאם אישית (כולל הרחבה של AndroidJUnitRunner) קרס באופן לא צפוי או כתב סמני התחלה או סיום של תרחיש בדיקה לא צפויים אל logcat.	בודקים את הקוד של כלי ההרצה של הבדיקות.
נכתבו יותר מדי יומנים אל logcat, מה שגרם לעומס יתר על המאגר הזמני או לקריסה של התהליך logcat.	הפחתת פעולות הכתיבה ל-logcat.
האפליקציה שנבדקה קרסה.	מבצעים ניפוי באגים באפליקציה.

---

שאלות נפוצות

איפה אפשר למצוא מידע על התמחור של Developer Device Platform?

לפרטים נוספים, אפשר לעיין בשאלות בנושא תמחור וחיוב.

איפה אפשר למצוא פרטים על המכשיר, כמו רזולוציה וכו'?

מידע מפורט על המכשיר זמין דרך ה-API, ואפשר לגשת אליו מ-CLI של פלטפורמת המכשירים למפתחים באמצעות הפקודה device-run devices describe <device-id>:

gcloud beta device-run devices describe DEVICE_ID

איך אפשר לדעת אם התנועה שמגיעה לשרת העורפי שלי מגיעה מ-Developer Device Platform?

מהקצה האחורי שלכם, אתם יכולים לבדוק את כתובת ה-IP של המקור מול טווח כתובות ה-IP שלנו כדי לדעת אם התנועה מגיעה ממכשירי בדיקה שמארחים בפלטפורמת המכשירים למפתחים.

האם פלטפורמת המכשירים למפתחים פועלת עם VPC-SC?

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

איך אפשר לצמצם את הבדיקות הלא יציבות ב-Developer Device Platform?

כדי לזהות התנהגות לא יציבה בבדיקות, מומלץ להשתמש באפשרות --flaky-test-attempts. החיוב על הפעלות חוזרות של בדיקות שנכשלו או שהן נספרות במסגרת המכסה היומית, בדיוק כמו הפעלות רגילות של בדיקות.

חשוב לזכור:

• כברירת מחדל, DDP יריץ את הניסיון החוזר ברצף כדי לחסוך בעלויות. המשתמשים צריכים להגדיר את --flaky-test-parallel-retry להפעלה במקביל.
• הדגל --flaky-test-retry-level מגדיר אם לנסות שוב ברמה shard או ברמה test, וערך ברירת המחדל שלו הוא shard. כדאי להגדיר את הערך ל-test כדי להקטין את הגודל והמשך של בדיקת הניסיון החוזר.

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

שאלות נפוצות שספציפיות ל-iOS

האם פלטפורמת המכשירים למפתחים תומכת ב-Appium,‏ Flutter/FlutterDriver,‏ ReactNative/Jest או Cucumber?

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

למה חסרים סרטונים בתוצאות של בדיקה ב-iOS?

אנחנו מתכננים להוסיף תמיכה בסרטונים בתוצאות ב-iOS 18 ואילך.

שאלות נפוצות שספציפיות ל-Android

האם פלטפורמת המכשירים למפתחים תומכת במכשירים לבישים?

כן! פלטפורמת המכשירים למפתחים תומכת ב-Google Pixel Watch. עכשיו אפשר להריץ בדיקות באפליקציה עצמאית ל-Wear OS בשעוני Google Pixel. מידע נוסף על מכשירי פלטפורמת המפתחים זמין בקטלוג המכשירים.

האם Developer Device Platform תומכת במכשירי Google העדכניים?

כן! פלטפורמת המכשירים למפתחים תומכת ב-Google Pixel Tablet וב-Google Pixel Fold. אפשר להריץ את הבדיקות במכשירים פיזיים עצמאיים. מידע נוסף על המכשירים שזמינים בפלטפורמת המכשירים למפתחים זמין בקטלוג המכשירים.

האם פלטפורמת מכשירי הפיתוח תומכת ב-Appium,‏ Flutter/FlutterDriver,‏ ReactNative/Jest או Cucumber?

חלק מהפריטים האלה נמצאים בתוכנית הפיתוח שלנו, אבל אנחנו לא יכולים להתחייב לתמיכה בפלטפורמות האלה לבדיקות ולפיתוח אפליקציות. עם זאת, אם יצרתם את האפליקציה באמצעות framework שתומך ב-Espresso (לדוגמה, Flutter), אתם יכולים לכתוב בדיקת אינסטרומנטציה באמצעות Espresso ואז להריץ את הבדיקה בפלטפורמת מכשירי הפיתוח.

האם פלטפורמת המכשיר למפתחים תומכת בבדיקה של אפליקציות שעברו טשטוש, למשל באמצעות ProGuard או R8?

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

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

כן! אפשר לבדוק את המכשיר המתקפל במצבים ותנוחות של מכשיר מתקפל.

מכשירים מתקפלים יכולים להיות במצבים מקופלים שונים, כמו FLAT (פתוח לגמרי) או HALF_OPENED (בין פתוח לגמרי לסגור לגמרי).

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

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

לחלופין, המצבים הזמינים הם ספציפיים למכשיר, ואפשר להשתמש ב-adb shell command cmd device_state כדי לבצע פעולות.

• כדי להציג את המצב הנוכחי, מריצים את הפקודה adb shell cmd device_state state.
• כדי להגדיר או לעקוף את המצב הנוכחי, מריצים את הפקודה adb shell cmd device_state state <IDENTIFIER>.
• כדי לאפס את המצב, מריצים את הפקודה adb shell cmd device_state state reset.
• כדי לבדוק את המצבים הזמינים, מריצים את הפקודה adb shell cmd device_state print-states במכשיר המתקפל.

‫Google Pixel Fold (מזהה הדגם felix)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSED', app_accessible=true},
      DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
      DeviceState{identifier=2, name='OPENED', app_accessible=true},
      DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]

‫Samsung Galaxy Z Fold4 (מזהה דגם q4q)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSE', app_accessible=true},
      DeviceState{identifier=1, name='TENT', app_accessible=true},
      DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
      DeviceState{identifier=3, name='OPEN', app_accessible=true},
]

האם אפשר להתנסות בפלטפורמת המכשירים למפתחים אם אין לי אפליקציה?

בשונה ממוצרים אחרים של Developer Device Platform, לא צריך להוסיף Developer Device Platform SDK כדי להשתמש ב-Developer Device Platform. אם עדיין אין לכם אפליקציה, אתם יכולים להוריד קובץ APK באינטרנט או ליצור אפליקציה וקובץ APK לבדיקה מאחת הדוגמאות במאגר AndroidX ב-GitHub. שימו לב: בדיקת מכשור דורשת גם אפליקציה וגם קובץ APK של בדיקה שנבנו מקוד מקור. מידע נוסף זמין במאמר בנושא בדיקות עם מכשור.

בסקירה הכללית על מוצר DDP יש מידע נוסף על התכונות של Developer Device Platform.

באילו מכשירים הכי מומלץ לבצע בדיקות השוואה בין צילומי מסך?

בדיקות השוואה בין צילומי מסך הן בדיקות שבהן טענות הבדיקה מבוססות על השוואה בין תמונות מסך שהתקבלו במהלך הפעלת בדיקה לבין תמונות מוזהבות שמייצגות התנהגות צפויה. יכול להיות שבחלק מסוגי המכשירים הבדיקות האלה יהיו פחות יציבות מאשר בסוגים אחרים. מומלץ לטרגט מכשירי אמולטור של Arm (*.arm) לסוגים האלה של בדיקות. מכשירי אמולטור של Arm משתמשים בתמונות שדומות מאוד או זהות לאמולטורים כלליים של Android Studio.

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

האם Developer Device Platform מעדכן מכשירים וירטואליים?

כן! מכשירים וירטואליים מתעדכנים כשמתבצעים השינויים הבאים:

1. עדכונים בתמונות קיימות
2. הוצאה משימוש של רמות API קודמות
3. נוספו רמות API חדשות ב-Android

איך מפעילים דוחות כיסוי?

כדי להפעיל דוחות כיסוי, מוסיפים את coverage=true לשדה additional-test-options. אם אתם משתמשים ב-תזמור בדיקות ל-Android, עליכם לספק נתיב לספרייה כדי לאחסן את תוצאות הכיסוי:

--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/

אם אתם לא משתמשים ב-Orchestrator, אתם יכולים לציין נתיב קובץ:

--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec

איך נכנסים לאפליקציית Wear בלי טלפון?

אם בדרך כלל נדרש טלפון כדי להיכנס לאפליקציה, אפשר ליצור וריאנט build שדילג על הכניסה ומשתמש באסימון שמוטמע בגרסת build לבדיקה, או לקרוא מקבצים בדיסק שבדרך כלל מועברים באמצעות הדגל --other-files-to-push.

---