בדף הזה מפורטות תשובות לשאלות נפוצות על הרצת בדיקות באמצעות Developer Device Platform, וגם עזרה בפתרון בעיות. לא מצאתם את מה שחיפשתם או שאתם צריכים עזרה נוספת? אפשר לפנות אלינו.
פתרון בעיות
אילו משאבים יש לך להעברה מ-Firebase Test Lab אל Developer Device Platform?
אם אתם עוברים מ-Firebase Test Lab ל-Developer Device Platform, כדאי לעיין במדריך להעברת נתונים, בתרגום של פקודות ודגלים ובמיומנות ההעברה של סוכני AI.
למה הבדיקה נמשכת כל כך הרבה זמן?
כשבוחרים מכשיר עם רמת קיבולת גבוהה בקטלוג של Developer Device Platform, הבדיקות עשויות להתחיל מהר יותר. אם הקיבולת של המכשיר נמוכה, יכול להיות שהבדיקות יימשכו זמן רב יותר. אם מספר הבדיקות שהופעלו גדול בהרבה מהקיבולת של המכשירים שנבחרו, יכול להיות שייקח יותר זמן עד שהבדיקות יסתיימו.
בדיקות שמופעלות בכל רמת קיבולת של מכשיר עשויות להימשך זמן רב יותר בגלל הגורמים הבאים:
- תנועת הגולשים, שמשפיעה על זמינות המכשיר ועל מהירות הבדיקה.
- כשלים במכשיר או בתשתית, שיכולים לקרות בכל שלב. כדי לבדוק אם יש תשתית מדווחת ל-Developer Device Platform, אפשר לעיין בלוח הבקרה Google Cloud Personalized Service Health.
מידע נוסף על קיבולת המכשיר בפלטפורמת המכשירים למפתחים זמין בקטלוג המכשירים.
למה אני מקבל תוצאות בדיקה לא חד-משמעיות?
תוצאות לא חד-משמעיות של בדיקות מתרחשות בדרך כלל בגלל ביטול של הרצת בדיקות או בגלל שגיאות בתשתית. בנוסף ל-PASSED ול-FAILED, יכול להיות ש-Developer Device Platform יחזיר ERROR, TIMED_OUT ו-CANCELLED.
שגיאות בתשתית נגרמות מבעיות פנימיות ב-Developer Device Platform, כמו שגיאות בחיבור לרשת או התנהגויות לא צפויות של המכשיר. פלטפורמת המכשירים למפתחים מנסה שוב באופן פנימי להריץ בדיקות שיוצרות שגיאות בתשתית כמה פעמים לפני שהיא מדווחת על תוצאה לא חד-משמעית.
כדי לזהות את הגורם לשגיאה, פועלים לפי השלבים הבאים:
- בודקים אם יש הפסקות זמניות ידועות בשירות בלוח הבקרה Google Cloud Service Health.
כדי לוודא שהבעיה ניתנת לשחזור, צריך לנסות שוב את הבדיקה ב-Developer Device Platform.
אם אפשר, כדאי לנסות להריץ את הבדיקה במכשיר אחר או בסוג מכשיר אחר. מידע נוסף מופיע בקטלוג המכשירים.
למה הריצה של הבדיקות שלי נמשכה יותר זמן אחרי שחילקתי אותן?
החלוקה יכולה לגרום לבדיקות לפעול זמן רב יותר אם מספר החלקים שציינתם גדול ממספר המכשירים שזמינים לשימוש בפלטפורמת המכשירים למפתחים. כדי להימנע ממצב כזה, כדאי להגביל את מספר המכשירים למספר השברים. מידע נוסף על בחירת מכשיר אחר זמין בקטלוג המכשירים.
למה לוקח הרבה זמן עד שהבדיקה מתחילה?
כששולחים בקשת בדיקה, האפליקציה עוברת קודם אימות, חתימה מחדש וכו' כהכנה להרצת בדיקות במכשיר. בדרך כלל התהליך הזה מסתיים תוך כמה שניות, אבל הוא יכול להימשך יותר זמן אם האפליקציה גדולה.
אחרי שהאפליקציה מוכנה, מתוזמנות הרצות של בדיקות והן נשארות בתור עד שמכשיר יהיה מוכן להריץ אותן.
למה לוקח כל כך הרבה זמן עד שהבדיקה מסתיימת?
אחרי שסיימתם את ביצוע הבדיקה, המערכת מורידה את תוצרי הבדיקה מהמכשיר, מעבדת אותם ומעלה אותם ל-Cloud Storage. משך הזמן של השלב הזה יכול להיות מושפע מהכמות ומהגודל של הארטיפקטים.
פתרון בעיות ספציפיות ל-Android
האפליקציה לא מחזירה נתונים ואי אפשר לאתר צילומי מסך
פריטי מידע של ביצוע בדיקה (כמו צילומי מסך וקבצי יומן) מאוחסנים ב-Cloud Storage ומוצגים ישירות במסוף Google Cloud . מוודאים שהקציתם תפקידים ברמת הפרויקט.
חשוב גם לציין שלפלטפורמה למפתחי מכשירים יש סוכן שירות ייעודי שמשתמש בפרטי הכניסה שלו ולא בפרטי הכניסה שלכם כדי:
- קריאה וכתיבה לקטגוריות ולאובייקטים ב-Cloud Storage
- הורדת קובצי קלט של Cloud Storage למערכת הפנימית
- העלאת קבצים מהמערכת הפנימית לקטגוריית הפלט של Cloud Storage
יכול להיות שיש לכם גישה לקובץ ולקטגוריה של Cloud Storage, אבל הקטגוריה הזו נמצאת בבעלות של Google Cloud פרויקט אחר מזה שבו נעשה שימוש ב-DDP. לכן לחשבון השירות של Developer Device Platform אין גישה אליו.
יכול להיות שיהיו לכם גם אמצעי בקרה נוספים על הגישה לקטגוריות ספציפיות. בקטע הרצה במכשיר מוסבר איך לכלול קבצים בבדיקות, ובקטע שיתוף אחסון מוסבר איך להעניק גישה לדליים חיצוניים ב-Developer Device Platform.
למה אני מקבל תוצאות חלקיות או חסרות של בדיקות אינסטרומנטציה?
כשמריצים בדיקות של מכשור, יכול להיות שמספר מקרי הבדיקה הכולל יהיה נמוך מהצפוי. לרוב הסיבה לכך היא ש-Developer Device Platform לא מצליח לנתח את logcat כדי למצוא סמני התחלה או סיום של תרחיש בדיקה, שבדרך כלל נוצרים על ידי AndroidJUnitRunner.
אלה כמה מהסיבות הנפוצות לבעיה הזו:
| תיאור הבעיה | פתרון אפשרי |
|---|---|
| מקרה הבדיקה לא הופעל בגלל שהזמן הקצוב לתפוגה חלף. אם משך הבדיקות הכולל ארוך יותר מהזמן הקצוב לתפוגה שציינתם או מהזמן המקסימלי לתפוגה, Developer Device Platform מבטלת את שאר מקרי הבדיקה. |
|
| השלמת תרחיש הבדיקה נכשלה כי הוא הסתיים מוקדם מדי או נתקע. יכול להיות שהרצת תרחיש הבדיקה תסתיים לפני הזמן בגלל חריגה שלא נתפסה או בגלל שגיאת טענה. תרחישי בדיקה עלולים להיתקע בלולאה אינסופית או שלא יוכלו להמשיך, למשל אם האפליקציה לא מציגה את התצוגה הנכונה ותרחיש הבדיקה לא יכול לבצע את הפעולה בממשק המשתמש. |
בודקים את הסרטון ואת logcat כדי להבין איפה הבדיקה נעצרה.
|
מפעיל בדיקות בהתאמה אישית (כולל הרחבה של AndroidJUnitRunner) קרס באופן לא צפוי או כתב סמני התחלה או סיום של תרחיש בדיקה לא צפויים ל-logcat.
|
בודקים את הקוד של כלי ההרצה של הבדיקות. |
נכתבו יותר מדי יומנים אל logcat, מה שגרם לעומס יתר על המאגר הזמני או לקריסה של התהליך logcat.
|
הפחתת פעולות הכתיבה ל-logcat.
|
| האפליקציה שנבדקה קרסה. | מבצעים ניפוי באגים באפליקציה. |
שאלות נפוצות
איפה אפשר למצוא מידע על התמחור של Developer Device Platform?
פרטים נוספים זמינים במאמר בנושא שאלות על תמחור וחיוב.
איפה אפשר למצוא פרטים על המכשיר, כמו רזולוציה וכו'?
מידע מפורט על המכשיר זמין דרך ה-API, ואפשר לגשת אליו מ-CLI של Developer Device Platform באמצעות הפקודה device-run devices describe <device-id>:
gcloud beta device-run devices describe DEVICE_ID
איך אפשר לדעת אם התנועה שמגיעה לשרת העורפי שלי מגיעה מ-Developer Device Platform?
מהקצה העורפי שלכם, אתם יכולים לבדוק את כתובת ה-IP של המקור מול טווח כתובות ה-IP שלנו כדי לקבוע אם התנועה מגיעה ממכשירי בדיקה שמארחים בפלטפורמת המכשירים למפתחים.
האם Developer Device Platform פועלת עם VPC-SC?
Developer Device Platform לא פועלת עם VPC-SC, שחוסמת את ההעתקה של אפליקציות ופריטי בדיקה אחרים בין האחסון הפנימי של Developer Device Platform לבין דלי התוצאות של המשתמשים.
איך מצמצמים בדיקות לא יציבות ב-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
האם Developer Device Platform תומכת במכשירים לבישים?
כן! פלטפורמת המכשירים למפתחים תומכת ב-Google Pixel Watch. עכשיו אפשר להריץ בדיקות באפליקציה עצמאית ל-Wear OS בשעוני Google Pixel Watch. מידע נוסף על מכשירים בפלטפורמת Developer Device Platform זמין בקטלוג המכשירים.
האם Developer Device Platform תומכת במכשירי Google העדכניים?
כן! פלטפורמת המכשירים למפתחים תומכת ב-Google Pixel Tablet וב-Google Pixel Fold. אפשר להריץ את הבדיקות במכשירים פיזיים עצמאיים. בקטלוג המכשירים אפשר לקרוא מידע נוסף על המכשירים שזמינים ב-Developer Device Platform.
האם פלטפורמת מכשירי הפיתוח תומכת ב-Appium, Flutter/FlutterDriver, ReactNative/Jest או Cucumber?
חלק מהפריטים האלה נמצאים בתוכנית הפיתוח שלנו, אבל אנחנו לא יכולים להתחייב לתמיכה בפלטפורמות האלה לבדיקות ולפיתוח אפליקציות. עם זאת, אם יצרתם את האפליקציה באמצעות framework שתומך ב-Espresso (לדוגמה, Flutter), אתם יכולים לכתוב בדיקת אינסטרומנטציה באמצעות Espresso ואז להריץ את הבדיקה ב-Developer Device Platform.
האם Developer Device Platform תומכת בבדיקה של אפליקציות שעברו טשטוש, למשל באמצעות ProGuard או R8?
Developer Device Platform לא תומכת באופן מפורש בערפול קוד או בפענוח קוד מעורפל. האפליקציה כנראה תפעל, אבל כל נתוני האפליקציה שעברו טשטוש, כמו עקבות מחסנית, יופיעו ביומנים כנתונים שעברו טשטוש.
האם אפשר להשתמש במכשיר מתקפל במצבים ובתנוחות שונים של קיפול בזמן בדיקה ב-Developer Device Platform?
כן! אתם יכולים לבדוק את המכשיר המתקפל במצבים ותנוחות של מכשיר מתקפל.
מכשירים מתקפלים יכולים להיות במצבים שונים של קיפול, כמו 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, לא צריך להוסיף Developer Device Platform SDK כדי להשתמש ב-Developer Device Platform. אם עדיין אין לכם אפליקציה, אתם יכולים להוריד קובץ APK באינטרנט או ליצור אפליקציה וקובץ APK לבדיקה מאחת הדוגמאות במאגר AndroidX ב-GitHub. שימו לב: בדיקת מכשור דורשת גם אפליקציה וגם קובץ APK של בדיקה שנבנו מקוד מקור. מידע נוסף זמין במאמר בנושא בדיקות עם מכשור.
בסקירה הכללית על מוצר DDP אפשר לקרוא מידע נוסף על התכונות של Developer Device Platform.
באילו מכשירים הכי מומלץ לבצע בדיקות השוואה בין צילומי מסך?
בדיקות השוואה בין צילומי מסך הן בדיקות שבהן טענות הבדיקה מבוססות על השוואה בין תמונות מסך שהתקבלו במהלך הפעלת הבדיקה לבין תמונות מוזהבות שמייצגות התנהגות צפויה. יכול להיות שהבדיקות האלה יהיו פחות יציבות בסוגי מכשירים מסוימים בהשוואה לסוגים אחרים. מומלץ לטרגט מכשירי אמולטור של Arm (*.arm) לסוגים האלה של בדיקות. מכשירי אמולטור של Arm משתמשים בתמונות שדומות מאוד או זהות לאמולטורים כלליים של Android Studio.
מומלץ גם לבדוק ספריות בדיקה שיכולות לעזור להפוך את בדיקות צילומי המסך ליציבות יותר בנוכחות שינויים צפויים.
האם Developer Device Platform מעדכנת מכשירים וירטואליים?
כן! מכשירים וירטואליים מתעדכנים כשמתבצעים השינויים הבאים:
- עדכונים בתמונות קיימות
- הוצאה משימוש של רמות API קודמות
- נוספו רמות 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.