Solución de problemas de Test Lab y preguntas frecuentes
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se proporciona ayuda para solucionar problemas y respuestas a preguntas frecuentes sobre la ejecución de pruebas con Firebase Test Lab. Los problemas conocidos también
se documentan. Si no encuentras lo que
buscas o necesitas más ayuda, únete al canal #test-lab
de
la comunidad de Firebase en Slack o comunícate con el equipo
de asistencia de Firebase.
Soluciona problemas
¿Por qué mi prueba tarda tanto en ejecutarse?
Cuando seleccionas un dispositivo con un nivel de capacidad alto en el catálogo de
Test Lab, las pruebas pueden comenzar más rápido. Cuando un
dispositivo tiene capacidad baja, las pruebas pueden tardar más en ejecutarse. Si la cantidad de
pruebas invocadas es mucho mayor que la capacidad de los dispositivos seleccionados, las pruebas
pueden tardar más en completarse.
Las pruebas que se ejecutan en cualquier nivel de capacidad del dispositivo pueden tardar más debido a los
siguientes factores:
Tráfico, que afecta la disponibilidad del dispositivo y la velocidad de prueba.
Fallas en el dispositivo o la infraestructura, que pueden ocurrir en cualquier momento. A fin de verificar
si hay fallas de infraestructura informadas para Test Lab, consulta el
panel de estado de Firebase.
Si quieres obtener más información sobre la capacidad del dispositivo
en Test Lab, consulta la información sobre capacidad del dispositivo para iOS y Android.
¿Por qué los resultados de la prueba no son concluyentes?
Por lo general, los resultados de la prueba no son concluyentes debido a ejecuciones de pruebas canceladas
o errores de infraestructura.
Los errores de infraestructura se deben a problemas internos de Test Lab, como errores de
red o comportamientos inesperados del dispositivo. Test Lab retira las ejecuciones de pruebas
que producen errores de infraestructura varias veces antes de informar un
resultado no concluyente. Sin embargo, puedes inhabilitar estos reintentos con
failFast.
Para determinar la causa del error, sigue estos pasos:
Vuelve a ejecutar la prueba en Test Lab para verificar que se pueda reproducir.
Intenta ejecutar la prueba en otro dispositivo o tipo de dispositivo, si corresponde.
Si el problema persiste, comunícate con el equipo de Test Lab en el canal#test-lab de
Firebase en Slack.
¿Por qué la fragmentación hizo que mis pruebas se ejecutaran
por más tiempo?
La fragmentación puede provocar que las pruebas se ejecuten durante más tiempo cuando la cantidad de fragmentos que
especificaste supera la cantidad de dispositivos disponibles para usar en Test Lab. Para
evitar esta situación, intenta cambiar a un dispositivo diferente. Si quieres obtener más información
para elegir otro dispositivo, consulta
Capacidad del dispositivo.
¿Por qué mi prueba tarda tanto
en iniciarse?
Cuando envías una solicitud de prueba, tu app se valida, se vuelve a firmar, etc., a modo de
preparación para ejecutar pruebas en un dispositivo. Por lo general, este proceso se completa en
unos pocos segundos, pero puede verse afectado por factores como el tamaño de la
app.
Una vez que tu app esté lista, las ejecuciones de prueba se programan y permanecen en una cola
hasta que un dispositivo esté listo para ejecutarla. Hasta que todas las ejecuciones de prueba terminen de ejecutarse,
el estado de la matriz será “Pendiente” (sin importar si las ejecuciones de prueba están
en cola o se están ejecutando de forma activa).
¿Por qué mi prueba tarda tanto
en terminar?
Una vez finalizada la ejecución de prueba, los artefactos de prueba se descargan del
dispositivo, se procesan y se suben a Cloud Storage. La duración de este paso puede
verse afectada por la cantidad y el tamaño de los artefactos.
Preguntas frecuentes
¿Cuáles son las cuotas sin costo
para Test Lab? ¿Qué debo hacer si se agotan?
Firebase Test Lab ofrece cuotas sin costo para realizar pruebas en dispositivos y usar
las API de Cloud. Ten en cuenta que la cuota para pruebas utiliza el plan de precios estándar de Firebase,
mientras que las cuotas de la API de Cloud no.
Cuota para pruebas
Esta se determina según la cantidad de dispositivos que se usen para realizar las pruebas.
El plan Firebase Spark tiene una cuota de pruebas fija sin costo para los usuarios. En
el plan Blaze, las cuotas pueden aumentar si tu uso de Google Cloud
aumenta con el tiempo. Si alcanzas el límite de la cuota para pruebas, espera hasta el día
siguiente o actualiza al plan Blaze si cuentas con el plan Spark.
Si ya tienes el plan Blaze, puedes solicitar un aumento de cuota.
Para obtener más información,
consulta Cuota para pruebas.
La API de Cloud Testing incluye dos límites de cuota: solicitudes al día por proyecto y solicitudes cada 100 segundos por proyecto. Puedes supervisar tu
uso en la
consola de Google Cloud.
Cuota de la API de Cloud Tool Results
La API de Cloud Tool Results incluye dos límites de cuota: consultas al día por proyecto y consultas cada 100 segundos por proyecto. Puedes supervisar tu
uso en la
consola de Google Cloud.
Consulta las cuotas de la API de Cloud para Test Lab
y obtén más información sobre los límites de la API. Si alcanzaste una cuota de API, tienes las siguientes opciones:
Envía una solicitud de aumento de cuota. Para ello, edita las cuotas directamente en la consola de Google Cloud (ten en cuenta que la mayoría de los límites se establecen como máximos de forma predeterminada).
Completa un formulario de solicitud en la consola de Google Cloud o comunícate con el equipo de asistencia de Firebase para solicitar una cuota de API mayor.
¿Cómo puedo averiguar si el tráfico que llega a mi backend proviene de Test Lab?
Desde tu backend puedes determinar si el tráfico proviene de dispositivos de prueba alojados en Firebase.
Para ello, revisa si la dirección IP de origen pertenece a nuestros
rangos de IP.
¿Funciona Test Lab con
VPC-SC?
Test Lab no funciona con VPC‑SC, que bloquea la copia de apps y otros artefactos de prueba entre el almacenamiento interno de Test Lab y los depósitos de resultados de los usuarios.
¿Cómo puedo detectar pruebas inestables en Test Lab?
Para detectar un comportamiento inestable en tus pruebas, te recomendamos usar las opciones
--num-flaky-test-attempts
. Las ejecuciones de reintento que corrigieron las inestabilidades se facturan o se consideran en tu cuota diaria de la misma manera que
las ejecuciones de prueba normales.
Ten en cuenta lo siguiente:
Cuando se detecta una falla, se vuelve a ejecutar toda la ejecución de prueba. No hay asistencia
para volver a ingresar solo los casos de prueba que fallaron.
Las ejecuciones de reintento que corrigieron inestabilidades están programadas para ejecutarse al mismo tiempo, pero no se
garantiza que se ejecuten en paralelo, por ejemplo, cuando el tráfico supera la cantidad de
dispositivos disponibles.
¿Es Test Lab compatible con
Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Si bien algunas de estas plataformas de pruebas y desarrollo de apps están en nuestra hoja de ruta,
en este momento no podemos garantizar la compatibilidad con ellas.
¿Dónde puedo encontrar los detalles del dispositivo,
como la resolución, etcétera?
La información detallada del dispositivo está disponible a través de la API y se puede acceder a ella
desde el cliente de gcloud con el
comando describe:
gcloud firebase test ios models describe MODEL
¿Puedo usar la fragmentación con pruebas de iOS?
La fragmentación no es compatible de forma nativa con Test Lab para iOS. Sin embargo, puedes
usar el cliente Flank para fragmentar casos de prueba de iOS.
Esto funciona estableciendo los valores y la clave de OnlyTestIdentifiers en el archivo .xctestrun.
Consulta la página man de xcodebuild.xctestrun para obtener más información.
¿Por qué faltan videos en los resultados de mi prueba para iOS?
En iOS 18 o versiones posteriores, no podemos admitir videos en los resultados.
Problemas conocidos
Captchas de acceso
La prueba Robo no puede pasar las pantallas de acceso que solicitan una acción adicional del usuario, aparte de ingresar credenciales de acceso (como completar un CAPTCHA).
Asistencia del framework de IU
La prueba Robo funciona mejor con apps que usan elementos de la IU del framework de la IU de Android (incluidos los objetos View, ViewGroup y WebView). Si usas la prueba Robo con apps que usan otros frameworks de IU, incluidas las apps que usan el motor de juego de Unity, es posible que la prueba se cierre sin explorar más allá de la primera pantalla.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-30 (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"]]
