קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בדף הזה מפורטות תשובות לשאלות נפוצות בנושא הרצת בדיקות באמצעות Firebase Test Lab, וגם עזרה בפתרון בעיות. יש גם תיעוד של בעיות מוכרות. אם לא מצאתם את מה שחיפשתם או שאתם צריכים עזרה נוספת, אתם יכולים להצטרף לערוץ #test-lab ב-Firebase Slack או לפנות אל התמיכה של Firebase.
פתרון בעיות
למה הבדיקה נמשכת כל כך הרבה זמן?
כשבוחרים מכשיר עם רמת קיבולת גבוהה בקטלוג Test Lab
יכול להיות שהבדיקות יתחילו מהר יותר. אם הקיבולת של המכשיר נמוכה, יכול להיות שהבדיקות יימשכו זמן רב יותר. אם מספר הבדיקות שהופעלו גדול בהרבה מהקיבולת של המכשירים שנבחרו, יכול להיות שיעבור זמן רב יותר עד שהבדיקות יסתיימו.
בדיקות שמופעלות בכל רמת קיבולת של מכשיר עשויות להימשך זמן רב יותר בגלל הגורמים הבאים:
תנועת הגולשים, שמשפיעה על זמינות המכשיר ועל מהירות הבדיקה.
כשלים במכשיר או בתשתית, שיכולים לקרות בכל שלב. כדי לבדוק אם יש תשתית מדווחת ל-Test Lab, אפשר לעיין בלוח הבקרה של הסטטוס של Firebase.
מידע נוסף על קיבולת המכשיר ב-Test Lab זמין במאמרים על קיבולת המכשיר ל-Android ול-iOS.
למה קיבלתי תוצאות לא חד-משמעיות של בדיקה?
תוצאות לא חד-משמעיות של בדיקות מתרחשות בדרך כלל בגלל ביטול של הרצת בדיקות או בגלל שגיאות בתשתית.
שגיאות בתשתית נגרמות מבעיות פנימיות ב-Test Lab, כמו שגיאות ברשת או התנהגויות לא צפויות של המכשיר. Test Lab באופן פנימי, המערכת מפסיקה הפעלות של בדיקות שמפיקות שגיאות בתשתית כמה פעמים לפני שהיא מדווחת על תוצאה לא חד-משמעית. עם זאת, אפשר להשבית את הניסיונות החוזרים האלה באמצעות failFast.
כדי לגלות את הגורם לשגיאה, פועלים לפי השלבים הבאים:
כדי לוודא שהבעיה ניתנת לשחזור, צריך לנסות שוב את הבדיקה ב-Test Lab.
אם אפשר, כדאי לנסות להריץ את הבדיקה במכשיר אחר או בסוג מכשיר אחר.
אם הבעיה נמשכת, אפשר לפנות אל Test Labהצוות בערוץ#test-lab ב-Firebase Slack.
למה הוספת שרדינג גרמה להרצת הבדיקות שלי למשך זמן ארוך יותר?
החלוקה לשברים עלולה לגרום לבדיקות להימשך זמן רב יותר אם מספר השברים שציינתם גדול ממספר המכשירים שזמינים לשימוש ב-Test Lab. כדי להימנע מהמצב הזה, כדאי לנסות לעבור למכשיר אחר. מידע נוסף על בחירת מכשיר אחר זמין במאמר
קיבולת המכשיר.
למה לוקח כל כך הרבה זמן עד שהבדיקה מתחילה?
כששולחים בקשה לבדיקה, האפליקציה עוברת קודם אימות, חתימה מחדש וכו' כהכנה להרצת בדיקות במכשיר. בדרך כלל התהליך הזה מסתיים תוך כמה שניות, אבל הוא יכול להיות מושפע מגורמים כמו גודל האפליקציה.
אחרי שהאפליקציה מוכנה, מתוזמנות הרצות של בדיקות והן נשארות בתור עד שמכשיר יהיה מוכן להריץ אותן. עד שכל ההרצות של הבדיקות יסתיימו, הסטטוס של המטריצה יהיה 'בהמתנה' (ללא קשר לשאלה אם ההרצות של הבדיקות נמצאות בתור או שהן פועלות באופן פעיל).
למה לוקח כל כך הרבה זמן עד שהבדיקה מסתיימת?
אחרי שהבדיקה מסתיימת, המערכת מורידה את תוצרי הבדיקה מהמכשיר, מעבדת אותם ומעלה אותם אל Cloud Storage. משך הזמן של השלב הזה יכול להיות מושפע מהכמות והגודל של הארטיפקטים.
שאלות נפוצות
מהן המכסות ללא עלות של Test Lab? מה צריך לעשות אם נגמרים לי המינויים?
Firebase Test Lab מציע מכסות ללא עלות לבדיקה במכשירים ולשימוש ב-Cloud APIs. שימו לב: המכסה לבדיקות מבוססת על תוכנית התמחור הרגילה של Firebase, אבל המכסות של Cloud API לא מבוססות עליה.
מכסת בדיקות
מכסות הבדיקות נקבעות לפי מספר המכשירים שמשמשים להרצת הבדיקות.
בתוכנית Firebase Spark יש מכסת בדיקות קבועה ללא עלות למשתמשים. בתוכנית Blaze, יכול להיות שהמכסות יגדלו אם השימוש שלכם ב-Google Cloud יגדל עם הזמן. אם הגעתם למכסת הבדיקות, תצטרכו לחכות עד למחרת או לשדרג למינוי Blaze אם יש לכם כרגע מינוי Spark.
אם כבר יש לכם מינוי לתוכנית Blaze, אתם יכולים לבקש להגדיל את המכסה.
מידע נוסף זמין במאמר בנושא מכסת בדיקה.
שולחים בקשה להגדלת המכסות על ידי עריכת המכסות ישירות במסוף Google Cloud (שימו לב שרוב המגבלות מוגדרות כברירת מחדל למקסימום), או
כדי לבקש הגדלה של מכסות ה-API, אפשר למלא טופס בקשה במסוף Google Cloud או לפנות אל התמיכה של Firebase.
איך אפשר לדעת אם התנועה שמגיעה לקצה העורפי שלי מגיעה מ-Test Lab?
מהקצה העורפי, אפשר לבדוק את כתובת ה-IP של המקור מול טווח כתובות ה-IP שלנו כדי לדעת אם התנועה מגיעה ממכשירי בדיקה שמארחים ב-Firebase.
האם Test Lab פועל עם VPC-SC?
Test Lab לא פועל עם VPC-SC, שחוסם את ההעתקה של אפליקציות ופריטי בדיקה אחרים בין האחסון הפנימי של Test Lab לבין דלי התוצאות של המשתמשים.
איך מזהים בדיקות לא יציבות ב-Test Lab?
כדי לזהות התנהגות לא יציבה בבדיקות, מומלץ להשתמש באפשרות
--num-flaky-test-attempts
. החיוב על הפעלות חוזרות של בדיקות שנכשלו או שהן נספרות במסגרת המכסה היומית, בדיוק כמו הפעלות רגילות של בדיקות.
זכור את הנקודות הבאות:
כל הבדיקה מופעלת מחדש כשמזוהה כשל. אין תמיכה בניסיון חוזר רק של תרחישי בדיקה שנכשלו.
הפעלות חוזרות של בדיקות לא יציבות מתוזמנות להפעלה באותו הזמן, אבל לא מובטח שהן יפעלו במקביל, למשל, כשהתנועה חורגת ממספר המכשירים הזמינים.
האם Test Lab תומך ב-Appium, Flutter/FlutterDriver, ReactNative/Jest או Cucumber?
חלק מהפריטים האלה נמצאים בתוכנית הפיתוח שלנו, אבל כרגע אין לנו אפשרות להתחייב לתמיכה בפלטפורמות האלה לבדיקות ולפיתוח אפליקציות.
איפה אפשר למצוא פרטים על המכשיר, כמו רזולוציה וכו'?
מידע מפורט על המכשיר זמין דרך ה-API, ואפשר לגשת אליו מלקוח gcloud באמצעות הפקודה describe:
gcloud firebase test ios models describe MODEL
האם אפשר להשתמש בפיצול (sharding) בבדיקות iOS?
אין תמיכה מובנית ב-Sharding ב-Test Lab ל-iOS. עם זאת, אפשר להשתמש בלקוח Flank כדי לפצל את תרחישי הבדיקה של iOS.
כדי להשתמש בשיטה הזו, צריך להגדיר את המפתח OnlyTestIdentifiers ואת הערכים בקובץ .xctestrun.
פרטים נוספים מופיעים בדף man בנושא xcodebuild.xctestrun.
למה חסרים סרטונים בתוצאות של בדיקה ב-iOS?
ב-iOS 18 ואילך, אנחנו לא יכולים לתמוך בסרטונים בתוצאות.
בעיות מוכרות
Captchas לכניסה
בדיקת Robo לא יכולה לעקוף מסכי כניסה שנדרשת בהם פעולת משתמש נוספת מעבר להזנת פרטי הכניסה, למשל השלמת CAPTCHA.
תמיכה ב-framework של ממשק משתמש
הבדיקה באמצעות Robo פועלת בצורה הטובה ביותר באפליקציות שמשתמשות ברכיבי ממשק משתמש מתוך מסגרת ממשק המשתמש של Android (כולל אובייקטים מסוג View, ViewGroup ו-WebView). אם אתם משתמשים ב-Robo test כדי לבדוק אפליקציות שמשתמשות במסגרות אחרות של ממשק משתמש, כולל אפליקציות שמשתמשות במנוע המשחק Unity, יכול להיות שהבדיקה תסתיים בלי לבדוק מעבר למסך הראשון.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-09-05 (שעון UTC)."],[],[],null,["\u003cbr /\u003e\n\niOS Android \n\nThis page provides troubleshooting help and answers to frequently asked\nquestions about running tests with Firebase Test Lab. Known issues are also\ndocumented. If you can't find what\nyou're looking for or need additional help, join the [#test-lab\nchannel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack or contact [Firebase\nsupport](https://support.google.com/firebase/contact/support).\n\nTroubleshooting\n\n\u003cbr /\u003e\n\nWhy is my test taking so long to run?\n\n\u003cbr /\u003e\n\nWhen you select a device with a high capacity level in the Test Lab\ncatalog, tests may start faster. When a\ndevice has low capacity, tests might take longer to run. If the number of\ntests invoked is much larger than the capacity of the selected devices, tests\ncan take longer to finish.\n\n\nTests running on any level device capacity level may take longer due to the\nfollowing factors:\n\n- Traffic, which affects device availability and test speed.\n- Device or infrastructure failures, which can happen at any time. To check if there is a reported infrastructure for Test Lab, see the [Firebase status dashboard](https://status.firebase.google.com/summary).\n\n\nTo learn more about device capacity in Test Lab, see device capacity\ninformation for [Android](https://firebase.google.com/docs/test-lab/android/available-testing-devices#device-capacity) and [iOS](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device-capacity).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy am I receiving inconclusive test results?\n\n\u003cbr /\u003e\n\nInconclusive test outcomes commonly occur either because of canceled test runs\nor infrastructure errors.\n\nInfrastructure errors are caused by internal Test Lab issues, like network\nerrors or unexpected device behaviors. Test Lab internally retires test runs\nthat produce infrastructure errors multiple times before reporting an\ninconclusive outcome; however, you can disable these retries using\n[failFast](/docs/test-lab/reference/testing/rest/v1/projects.testMatrices#TestMatrix.FIELDS.fail_fast).\n\nTo determine the cause of the error, follow these steps:\n\n1. Check for known outages in the [Firebase status dashboard](https://status.firebase.google.com/summary).\n2. Retry the test in Test Lab to verify that it is reproducible.\n\n | **Note:** Test Lab does not charge you for infrastructure errors.\n3. Try running the test on a different device or device type, if applicable.\n\nIf the issue persists, contact the Test Lab team in the\n[#test-lab channel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy did sharding make my tests run\nlonger?\n\n\u003cbr /\u003e\n\nSharding can cause your tests to run longer when the number of shards you\nspecified exceeds the number of devices available for use in Test Lab. To\navoid this situation, try switching to a different device. For more information\nabout choosing a different device, see\n\n[Device Capacity](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device_capacity).\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to start?\n\n\u003cbr /\u003e\n\nWhen you submit a test request, your app is first validated, re-signed, etc. in\npreparation for running tests on a device. Normally, this process completes in\nless than a few seconds, but it can be affected by factors like the size of your\napp.\n\nAfter your app is prepared, test executions are scheduled and remain in a queue\nuntil a device is ready to run it. Until all test executions finish running,\nthe matrix status will be \"Pending\" (regardless of whether test executions are\nin the queue or actively running).\n| **Note:** The time your test spends waiting for an available device does not count toward your billing time.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to finish?\n\n\u003cbr /\u003e\n\nAfter the test execution is finished, test artifacts are downloaded from the\ndevice, processed, and uploaded to Cloud Storage. The duration of this step can\nbe affected by the amount and size of the artifacts.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFrequently asked questions\n\n\u003cbr /\u003e\n\nWhat are the no-cost quotas\nfor Test Lab? What should I do if I run out?\n\n\u003cbr /\u003e\n\nFirebase Test Lab offers no-cost quotas for testing on devices and for using\nCloud APIs. Note that the testing quota uses the standard Firebase pricing plan,\nwhile the Cloud API quotas do not.\n\n- **Testing quota**\n\n Testing quotas are determined by the number of devices used to run tests.\n The Firebase Spark plan has a fixed testing quota at no cost to users. For\n the Blaze plan, your quotas might increase if your usage of Google Cloud\n increases over time. If you reach your testing quota, wait until the next\n day or upgrade to the Blaze plan if you are currently on the Spark plan.\n If you are already on the Blaze plan, you can request a quota increase.\n For more information, see\n [Testing quota](/docs/test-lab/usage-quotas-pricing#testing-quota).\n\n You can monitor your testing quota usage in the [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Testing API quota**\n\n The Cloud Testing API comes with two quota limits: requests per day per\n project, and requests per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Tool Results API quota**\n\n The Cloud Tool Results API comes with two quota limits: queries per day per\n project, and queries per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/toolresults.googleapis.com/quotas).\n\n Refer to [Cloud API quotas for Test Lab](/docs/test-lab/usage-quotas-pricing#cloud-api-quota)\n for more information on API limits. If you've reached an API quota:\n - Submit a request for higher quotas by\n [editing your quotas](https://cloud.google.com/docs/quota#requesting_higher_quota)\n directly in the Google Cloud console (note that most limits are set to\n maximum by default), or\n\n - Request higher API quotas by filling out a request form in the\n Google Cloud console or by contacting\n [Firebase support](https://support.google.com/firebase/contact/support).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I find out if the\ntraffic reaching my backend is coming from Test Lab?\n\n\u003cbr /\u003e\n\nFrom your backend, you can determine if traffic is coming from Firebase-hosted\ntest devices by checking the source IP address against our\n[IP ranges](https://firebase.google.com/docs/test-lab/android/get-started#ip-blocks).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab work with\nVPC-SC?\n\n\u003cbr /\u003e\n\nTest Lab does not work with VPC-SC, which blocks the\ncopying of apps and other test artifacts between Test Lab's internal\nstorage and users' results buckets.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I detect flaky tests in\nTest Lab?\n\n\u003cbr /\u003e\n\nTo detect flaky behavior in your tests, we recommend using the\n\n[--num-flaky-test-attempts](https://cloud.google.com/sdk/gcloud/reference/firebase/test/ios/run#--num-flaky-test-attempts)\n\noption. Deflake reruns are billed or counted toward your daily quota the same as\nnormal test executions.\n\nKeep the following in mind:\n\n- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.\n- Deflake retry runs are scheduled to run at the same time, but are not guaranteed to run in parallel, for example, when traffic exceeds the number of available devices.\n\n| **Note:** Infrastructure errors are independent from the deflake feature and don't trigger deflake reruns.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab support\nAppium, Flutter/FlutterDriver, ReactNative/Jest, or Cucumber?\n\n\u003cbr /\u003e\n\nWhile some of these items are on our roadmap, we're currently unable to provide\ncommitment to supporting these testing and app development platforms.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhere can I find device details,\nlike resolution, etc.?\n\n\u003cbr /\u003e\n\nDetailed device information is available through the API and can be accessed\nfrom the gcloud client using the\n[describe command](https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/models/describe):\n\n`gcloud firebase test ios models describe `\u003cvar translate=\"no\"\u003eMODEL\u003c/var\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nCan I use sharding with iOS tests?\n\n\u003cbr /\u003e\n\nSharding isn't natively supported within Test Lab for iOS. However, you can\nuse the [Flank](https://flank.github.io/flank/) client to shard iOS test cases.\n| **Note:** Using Flank iOS sharding creates separate test matrices for each shard.\n\nThis works by setting `OnlyTestIdentifiers` key and values in `.xctestrun` file.\nSee `man` page for `xcodebuild.xctestrun` for more details.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is my iOS test missing videos in the\nresults?\n\n\u003cbr /\u003e\n\nFor iOS 18 or later, we are not able to support videos in the results.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown issues\n\n\u003cbr /\u003e\n\nSign-in Captchas\n\n\u003cbr /\u003e\n\nRobo test cannot bypass sign-in screens that require\nadditional user action beyond entering credentials to sign in, for example,\ncompleting a CAPTCHA.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nUI framework support\n\n\u003cbr /\u003e\n\nRobo test works best with apps that use UI elements from the Android UI\nframework (including `View`, `ViewGroup`, and `WebView`\nobjects). If you use Robo test to exercise apps that use other UI\nframeworks, including apps that use the Unity game engine, the test may exit\nwithout exploring beyond the first screen.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e"]]
