פתרון בעיות ב-Test Lab & שאלות נפוצות

iOS Android

בדף הזה מפורטות תשובות לשאלות נפוצות בנושא הפעלת בדיקות באמצעות Firebase Test Lab, וכן עזרה בפתרון בעיות. בנוסף, מתועדות בעיות ידועות. אם לא מצאתם את מה שחיפשתם או שדרושה לכם עזרה נוספת, תוכלו להצטרף לערוץ #test-lab ב-Slack של Firebase או לפנות אל התמיכה של Firebase.

פתרון בעיות

למה הבדיקה נמשכת כל כך הרבה זמן?

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

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

• תנועה, שמשפיעה על זמינות המכשיר ועל מהירות הבדיקה.
• כשלים במכשיר או בתשתית, שיכולים לקרות בכל שלב. כדי לבדוק אם יש דיווח על תשתית עבור Test Lab, אפשר להיכנס ללוח הבקרה של סטטוס Firebase.

למידע נוסף על קיבולת המכשיר ב-Test Lab, אפשר לעיין במידע על קיבולת המכשיר ב-Android וב-iOS.

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

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

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

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

1. בודקים אם יש הפסקות זמניות בשירות ידועות בלוח הבקרה של סטטוס Firebase.

2. מנסים שוב את הבדיקה ב-Test Lab כדי לוודא שאפשר לשחזר אותה.

   הערה: Test Lab לא מחייבת על שגיאות בתשתית.

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

אם הבעיה נמשכת, אפשר לפנות לצוות Test Lab בערוץ#test-lab ב-Slack של Firebase.

למה חלוקת המטא-נתונים לחלקים (sharding) הגדילה את משך הזמן של הרצת הבדיקות?

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

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

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

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

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

למה הבדיקה נמשכת זמן רב?

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

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

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

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

כדי לשמור את ארטיפקטי הבדיקה למשך זמן ארוך יותר, מריצים את הפקודה gcloud firebase test android run עם הדגל --results-bucket ומעבירים את שם הקטגוריה של התוצאות. למידע נוסף, ראו את מאמרי העזרה של gcloud firebase test android run.

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

כשמריצים בדיקות של מכשירי מדידה, יכול להיות שיופיעו שגיאות בדיקה שמציינות תוצאות חלקיות שמכילות הודעות כמו Test run failed to complete. Expected x tests, received y (כאשר y קטן מ-x). השגיאה הזו מציינת ש-Test Lab לא הצליח לנתח את ה-logcat כדי למצוא את הסמנים להתחלה או לסיום של תרחישים הבדיקה, שנוצרים בדרך כלל על ידי AndroidJUnitRunner.

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

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

שאלות נפוצות

מהן המכסות ללא עלות של Test Lab? מה עושים אם נגמרים לכם שטחי האחסון?

Firebase Test Lab מציע מכסות ללא עלות לבדיקה במכשירים ולשימוש בממשקי Cloud API. חשוב לזכור שבמכסה לבדיקה נעשה שימוש בתוכנית התמחור הרגילה של Firebase, ואילו במכסות של Cloud API לא נעשה שימוש בתוכנית כזו.

• בדיקת המכסה

  מכסות הבדיקה נקבעות על סמך מספר המכשירים שבהם נעשה שימוש להרצת בדיקות. בתוכנית Firebase Spark יש מכסה קבועה של בדיקות ללא עלות למשתמשים. בתוכנית Blaze, המכסות עשויות לגדול אם השימוש שלכם ב-Google Cloud יגדל עם הזמן. אם תגיעו למכסת הבדיקות, תוכלו לחכות עד למחר או לשדרג למינוי Blaze אם אתם משתמשים כרגע במינוי Spark. אם כבר רכשתם את המינוי ל-Blaze, תוכלו לבקש הגדלה של המכסה. מידע נוסף זמין במאמר בדיקת המכסה.

  אפשר לעקוב אחרי ניצול המכסה לבדיקה במסוף Google Cloud.

• מכסה ל-Cloud Testing API

  ל-Cloud Testing API יש שתי מכסות: בקשות ליום לכל פרויקט ובקשות לכל 100 שניות לכל פרויקט. אפשר לעקוב אחרי השימוש במסוף Google Cloud.

• מכסה של Cloud Tool Results API

  ל-Cloud Tool Results API יש שתי מכסות: שאילתות ליום לכל פרויקט ושאילתות לכל 100 שניות לכל פרויקט. אפשר לעקוב אחרי השימוש במסוף Google Cloud.

  למידע נוסף על מגבלות ה-API, אפשר לעיין במאמר מכסות Cloud API ל-Test Lab. אם הגעתם למכסה של API:

  • לשלוח בקשה להגדלת המכסות על ידי עריכת המכסות ישירות במסוף Google Cloud (לתשומת ליבכם: רוב המגבלות מוגדרות למקסימום כברירת מחדל).

  • כדי לבקש הגדלה של מכסות ה-API, אפשר למלא טופס בקשה במסוף Google Cloud או לפנות לתמיכה של Firebase.

איך אפשר לדעת אם התנועה שמגיעה לקצה העורפי שלי מגיעה מ-Test Lab?

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

האם Test Lab פועל עם VPC-SC?

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

איך מזהים בדיקות לא יציבות ב-Test Lab?

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

זכור את הנקודות הבאות:

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

הערה: שגיאות בתשתית הן עצמאיות מהתכונה deflake ולא גורמות להפעלה מחדש של deflake.

האם Test Lab תומך במכשירים לבישים?

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

האם Test Lab תומך במכשירי Google העדכניים ביותר?

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

איך מזהים בדיקה שפועלת ב-Test Lab?

אם אתם בודקים את האפליקציה ב-Firebase או מריצים בדיקות לדוח טרום-השקה ב-Play Console, אתם יכולים לבדוק אם הבדיקה פועלת במכשיר שמתארח ב-Firebase על ידי בדיקה של מאפיין המערכת firebase.test.lab בקובץ MainActivity. לאחר מכן תוכלו להריץ הצהרות נוספות על סמך הערך הבוליאני של testLabSetting. למידע נוסף, ראו התנהגויות בדיקה ששונו.

האם Test Lab תומך ב-Appium, ב-Flutter/FlutterDriver, ב-ReactNative/Jest או ב-Cucumber?

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

האם Test Lab תומך בבדיקת אפליקציות מעורפלות, למשל באמצעות ProGuard או R8)?

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

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

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

מכשירים מתקפלים יכולים להיות במצבים שונים של קיפול, למשל 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},
]

האם אפשר לנסות את Test Lab אם אין אפליקציה?

בניגוד למוצרים אחרים של Firebase, אין צורך להוסיף Firebase SDK כדי להשתמש ב-Test Lab. אם עדיין אין לכם אפליקציה, תוכלו להוריד קובץ APK אונליין או ליצור אפליקציה וקובץ APK לבדיקה מאחד מהדוגמאות במאגר GitHub של AndroidX. חשוב לדעת: כדי להריץ בדיקת Robo, נדרש רק קובץ ה-APK של האפליקציה. לעומת זאת, כדי להריץ בדיקת instrumentation נדרשים גם אפליקציה וגם קובץ APK לבדיקה שנוצרו מקוד מקור. מידע נוסף זמין במאמר בדיקות עם כלי למדידת ביצועים.

למידע נוסף על התכונות של Test Lab, אפשר לעיין במאמר תחילת העבודה עם בדיקות ל-Android באמצעות Firebase Test Lab.

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

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

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

האם Test Lab מעדכן מכשירים וירטואליים?

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

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

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

כדי להפעיל דוחות כיסוי, מוסיפים את הערך coverage=true לשדה environmentVariables. אם אתם משתמשים ב-Android Test Orchestrator, תצטרכו לספק ספרייה לאחסון תוצאות הכיסוי:

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

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

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

איפה אפשר למצוא פרטי מכשיר, כמו רזולוציה, ממשקי ABI נתמכים וכו'?

פרטים מפורטים על המכשיר זמינים דרך ה-API, וניתן לגשת אליהם מלקוח gcloud באמצעות הפקודה describe:

gcloud firebase test android models describe MODEL

בעיות מוכרות

captcha לכניסה

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

תמיכה במסגרת של ממשק המשתמש

בדיקת Robo פועלת בצורה הטובה ביותר באפליקציות שמשתמשות ברכיבי ממשק משתמש מסגרת ממשק המשתמש של Android (כולל אובייקטים מסוג View,‏ ViewGroup ו-WebView). אם משתמשים ב-Robo Test כדי לבדוק אפליקציות שמשתמשות במסגרות אחרות של ממשק משתמש, כולל אפליקציות שמשתמשות במנוע המשחקים של Unity, יכול להיות שהבדיקה תסתיים בלי לבדוק מעבר למסך הראשון.