פתרון בעיות ב-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 channel הוא Firebase Slack.

למה הפיצול גרם לבדיקות ארוך יותר?

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

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

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

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

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

למה לוקח הרבה זמן עד לסיום הבדיקה?

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

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

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

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

כדי לשמור את פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) לבדיקה למשך זמן רב יותר, מריצים את הפקודה 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 מבטלת את שאר מקרי הבדיקה.	מאריכים את הזמן הקצוב לתפוגה של המטריצה כדי לוודא שכל הבדיקות יכולות להסתיים. אם עדיין לא עשיתם זאת, תצטרכו לפצל את הבדיקות כדי שכל פיצול יריץ קבוצת משנה של בדיקות ומסתיימת בפרק זמן קצר יותר. אם כבר הפעלתם פיצול, צריך להגדיל את מספר המפוצלים.
בקשת הבדיקה לא הושלמה כי היא יצאה לפני הזמן או שנתקעה. מקרה הבדיקה עשוי לצאת מוקדם מדי בגלל חריג לא ידוע או שגיאה בטענת נכוֹנוּת (assertion). מקרי הבדיקה עלולים להיתקע בלולאה אינסופית, או לא יכול להמשיך. לדוגמה, אם האפליקציה לא מציגה את התצוגה הנכונה מקרה הבדיקה לא יכול לבצע את הפעולה בממשק המשתמש.	כדאי לצפות בסרטון ובlogcat כדי לראות איפה הבדיקה הופסק.
תוכנת הרצה בהתאמה אישית לבדיקה (כולל הרחבה של AndroidJUnitRunner) קרסה באופן בלתי צפוי או כתוב סמני התחלה או סיום לא צפויים של מקרי הבדיקה logcat	יש לבדוק את הקוד של הרצת הבדיקה.
יומנים מוגזמים נכתבו אל logcat, והעמסה את מאגר הנתונים הזמני או קריסת את התהליך logcat.	צמצום הכתיבה לlogcat.
האפליקציה שנבדקת קרסה.	ניפוי באגים באפליקציה

שאלות נפוצות

מהן המכסות ללא עלות? של Test Lab? מה אפשר לעשות אם ייגמר לי המקום?

ב-Firebase Test Lab יש מכסות ללא עלות לבדיקה במכשירים ולשימוש ממשקי 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.

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

  • צריך להגיש בקשה להגדלה של המכסות עד עריכת המכסות ישירות במסוף Google Cloud (שימו לב שרוב המגבלות מוגדרות מקסימום כברירת מחדל), או

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

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

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

האם Test Lab עובד עם VPC-SC?

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

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

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

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

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

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

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

כן! Test Lab תומך ב-Google Pixel Watch. עכשיו אפשר להריץ בדיקות את אפליקציית Wear הנפרדת שלכם ב-Google Pixel Watches. מידע נוסף על 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 או מלפפון?

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

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

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

האם אפשר להשתמש במכשיר המתקפל מצבי מתקפלים שונים ותנוחות שונות במהלך הבדיקה במכשיר 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 לבדיקה דרך אחת דוגמאות במאגר AndroidX GitHub. לתשומת ליבכם: צריך רק את את קובץ ה-APK של האפליקציה כדי להריץ בדיקת Robo, ואילו בדיקת אינסטרומנטציה מחייבת אפליקציה ו-APK לבדיקה שנוצרו מקוד מקור. לקבלת מידע נוסף, ניתן לקרוא על בדיקות אינסטרומנטליות.

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

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

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

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

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

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

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

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

כדי להפעיל דוחות כיסוי, צריך להוסיף את coverage=true אל שדה environmentVariables. אם משתמשים ב'תזמור בדיקות של Android', צריך לספק ספרייה מאחסנים את תוצאות הכיסוי:

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

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

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

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

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

gcloud firebase test android models describe MODEL

בעיות מוכרות

captcha לכניסה

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

תמיכה ב-framework של ממשק משתמש

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