Esta página proporciona ayuda para la resolución de problemas y respuestas a preguntas frecuentes sobre la ejecución de pruebas con Firebase Test Lab. Los problemas conocidos también están documentados. Si no encuentra lo que busca o necesita ayuda adicional, únase al canal #test-lab en Firebase Slack o comuníquese con el soporte de Firebase .
Solución de problemas
Cuando selecciona 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 poca capacidad, 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 finalizar.
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 la prueba.
- Fallos del dispositivo o de la infraestructura, que pueden ocurrir en cualquier momento. Para verificar si hay una infraestructura reportada para Test Lab, consulte el panel de estado de Firebase .
Para obtener más información sobre la capacidad del dispositivo en Test Lab, consulte información sobre la capacidad del dispositivo para Android e iOS .
Los resultados de las pruebas no concluyentes suelen producirse debido a ejecuciones de pruebas canceladas o errores de infraestructura.
Los errores de infraestructura son causados por problemas internos del laboratorio de pruebas, como errores de red o comportamientos inesperados del dispositivo. Test Lab retira internamente las ejecuciones de pruebas que producen errores de infraestructura varias veces antes de informar un resultado no concluyente; sin embargo, puedes desactivar estos reintentos usando failFast .
Para determinar la causa del error, siga estos pasos:
- Verifique interrupciones conocidas en el panel de estado de Firebase .
Vuelva a intentar la prueba en Test Lab para verificar que sea reproducible.
Intente ejecutar la prueba en un dispositivo o tipo de dispositivo diferente, si corresponde.
Si el problema persiste, comuníquese con el equipo de Test Lab en el canal #test-lab en Firebase Slack.
La fragmentación puede hacer que sus pruebas se ejecuten por más tiempo cuando la cantidad de fragmentos que especificó excede la cantidad de dispositivos disponibles para su uso en Test Lab. Para evitar esta situación, intente cambiar a un dispositivo diferente. Para obtener más información sobre cómo elegir un dispositivo diferente, consulteCapacidad del dispositivo .
Cuando envía una solicitud de prueba, su aplicación primero se valida, se vuelve a firmar, etc., en preparación para ejecutar pruebas en un dispositivo. Normalmente, este proceso se completa en menos de unos segundos, pero puede verse afectado por factores como el tamaño de su aplicación.
Una vez preparada la aplicación, se programan ejecuciones de prueba y permanecen en 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" (independientemente de si las ejecuciones de prueba están en la cola o ejecutándose activamente).
Una vez finalizada la ejecución de la prueba, los artefactos de prueba se descargan del dispositivo, se procesan y se cargan en Cloud Storage. La duración de este paso puede verse afectada por la cantidad y el tamaño de los artefactos.
Los artefactos de ejecución de pruebas (como capturas de pantalla y archivos de registro) se almacenan en Google Cloud Storage y se representan directamente en Firebase console. Si la ejecución de su prueba se realizó dentro de los últimos 90 días, verifique que haya asignado roles a nivel de proyecto (propietario del proyecto, editor del proyecto o visor del proyecto). Asegúrese también de que Cloud Audit Logging no esté habilitado para su proyecto o su organización.
Si la ejecución se realizó hace más de 90 días, lo más probable es que los artefactos de prueba se hayan eliminado automáticamente. Puede verificar la configuración del depósito de resultados haciendo clic en la pestaña Resultados de la prueba en el panel del laboratorio de pruebas. El depósito de resultados predeterminado está configurado para retener objetos durante 90 días.
Para conservar los artefactos de prueba por más tiempo, ejecute el comando gcloud firebase test android run con la marca --results-bucket y pase el nombre del depósito de resultados. Para obtener más información, visita la documentación de referencia gcloud firebase test android run .
Cuando ejecuta pruebas de instrumentación, es posible que vea errores de prueba que indican resultados parciales que contienen mensajes como Test run failed to complete. Expected x tests, received y (donde y es menor que x ). Este error significa que Test Lab no pudo analizar el logcat para los marcadores de inicio o finalización del caso de prueba que generalmente genera AndroidJUnitRunner .
Las siguientes son causas comunes de este problema:
| Descripcion del problema | Posible resolución |
|---|---|
| El caso de prueba no se ejecutó debido a un tiempo de espera. Si la duración total de las pruebas es mayor que el tiempo de espera que especificó o que un tiempo de espera máximo , Test Lab cancela el resto de los casos de prueba. |
|
| El caso de prueba no se pudo completar porque salió prematuramente o se atascó. El caso de prueba puede cerrarse prematuramente debido a una excepción no detectada o un error de aserción. Los casos de prueba pueden quedarse atascados en un bucle infinito o es posible que no puedan continuar, por ejemplo, si la aplicación no muestra la vista correcta y el caso de prueba no puede realizar la acción en la interfaz de usuario. | Consulte el vídeo y el logcat para investigar dónde se detuvo la prueba. |
Un ejecutor de pruebas personalizado (incluida la extensión de AndroidJUnitRunner) falló inesperadamente o escribió marcadores de inicio o finalización de casos de prueba inesperados en logcat . | Verifique su código de corredor de prueba. |
Se escribieron registros excesivos en logcat , lo que saturó el búfer o bloqueó el proceso logcat . | Reducir las escrituras en logcat . |
| La aplicación bajo prueba falló. | Depura tu aplicación. |
Preguntas frecuentes
Firebase Test Lab ofrece cuotas sin costo para realizar pruebas en dispositivos y usar API en la nube. Tenga en cuenta que la cuota de prueba utiliza el plan de precios estándar de Firebase, mientras que las cuotas de Cloud API no.
Cuota de prueba
Las cuotas de prueba están determinadas por la cantidad de dispositivos utilizados para ejecutar pruebas. El plan Firebase Spark tiene una cuota de prueba fija sin costo para los usuarios. Para el plan Blaze, sus cuotas pueden aumentar si su uso de Google Cloud aumenta con el tiempo. Si alcanza su cuota de prueba, espere hasta el día siguiente o actualice al plan Blaze si actualmente tiene el plan Spark. Si ya estás en el plan Blaze, puedes solicitar un aumento de cuota. Para obtener más información, consulte Cuota de prueba .
Puedes monitorear el uso de tu cuota de prueba en la consola de Google Cloud .
Cuota de API de pruebas en la nube
La API de Cloud Testing viene con dos límites de cuota: solicitudes por día por proyecto y solicitudes por cada 100 segundos por proyecto. Puedes monitorear tu uso en la consola de Google Cloud .
Cuota de API de resultados de herramientas en la nube
La API de resultados de la herramienta en la nube viene con dos límites de cuota: consultas por día por proyecto y consultas cada 100 segundos por proyecto. Puedes monitorear tu uso en la consola de Google Cloud .
Consulte Cuotas de API de Cloud para Test Lab para obtener más información sobre los límites de API. Si has alcanzado una cuota de API:
Envíe una solicitud de cuotas más altas editando sus cuotas directamente en la consola de Google Cloud (tenga en cuenta que la mayoría de los límites están configurados al máximo de forma predeterminada), o
Solicite cuotas de API más altas completando un formulario de solicitud en la consola de Google Cloud o comunicándose con el soporte de Firebase .
Desde su backend, puede determinar si el tráfico proviene de dispositivos de prueba alojados en Firebase al comparar la dirección IP de origen con nuestros rangos de IP .
Test Lab no funciona con VPC-SC, que bloquea la copia de aplicaciones y otros artefactos de prueba entre el almacenamiento interno de Test Lab y los depósitos de resultados de los usuarios.
Para detectar comportamientos inestables en sus pruebas, recomendamos utilizar la opción--num-flaky-test-attempts. Las repeticiones de Deflake se facturan o cuentan para su cuota diaria de la misma manera que las ejecuciones de pruebas normales.
Tenga en cuenta lo siguiente:
- Toda la ejecución de la prueba se ejecuta nuevamente cuando se detecta una falla. No se admite el reintento únicamente de casos de prueba fallidos.
- Las ejecuciones de reintento de Deflake están programadas para ejecutarse al mismo tiempo, pero no se garantiza que se ejecuten en paralelo, por ejemplo, cuando el tráfico excede la cantidad de dispositivos disponibles.
¡Sí! Test Lab es compatible con Google Pixel Watch. Ahora puedes ejecutar pruebas en tu aplicación Wear independiente en Google Pixel Watches. Para obtener más información sobre los dispositivos Test Lab, consulte Prueba en dispositivos disponibles .
¡Sí! Test Lab es compatible con Google Pixel Tablet y Google Pixel Fold. Puede ejecutar sus pruebas en sus dispositivos físicos independientes. Para obtener más información sobre los dispositivos Test Lab, consulte Prueba en dispositivos disponibles .
Si estás probando tu aplicación en Firebase o ejecutando pruebas para un informe previo al lanzamiento en Play Console, puedes detectar si se está ejecutando una prueba en un dispositivo alojado en Firebase verificando la propiedad del sistema firebase.test.lab en su archivo MainActivity . Luego puede ejecutar declaraciones adicionales basadas en el valor booleano de testLabSetting . Para obtener más información, consulte Comportamientos de prueba modificados .
Si bien algunos de estos elementos están en nuestra hoja de ruta, actualmente no podemos comprometernos a respaldar estas plataformas de prueba y desarrollo de aplicaciones. Sin embargo, si creó su aplicación con un marco que admite Espresso (por ejemplo, Flutter), puede escribir una prueba de instrumentación usando Espresso y luego ejecutar la prueba en Test Lab.
Test Lab no admite explícitamente la ofuscación o desofuscación. Si bien es probable que la aplicación se ejecute, cualquier dato de la aplicación ofuscado, como los seguimientos de la pila, aparecerá ofuscado en los registros.
¡Sí! Puede probar su dispositivo plegable en estados y posturas plegables .
Los dispositivos plegables pueden estar en varios estados plegados, como FLAT (completamente abierto) o HALF_OPENED (entre completamente abierto y completamente cerrado).
Las posturas, por otro lado, consisten en la orientación específica del dispositivo y su estado plegable. Por ejemplo, la postura de la mesa, que es un estado HALF_OPENED en orientación horizontal, o la postura del libro, que es un estado HALF_OPENED en orientación vertical.
Si está ejecutando pruebas de instrumentación, puede usar la biblioteca Jetpack WindowManager y seguir probando su aplicación en documentación plegable para probar en diferentes estados y posturas.
Alternativamente, los estados disponibles son específicos del dispositivo y se puede interactuar con ellos mediante el adb shell command cmd device_state .
- Para enumerar el estado actual, ejecute
adb shell cmd device_state state. - Para establecer o anular el estado actual, ejecute
adb shell cmd device_state state <IDENTIFIER>. - Para restablecer el estado, ejecute
adb shell cmd device_state state reset. - Para verificar los estados disponibles, ejecute el comando
adb shell cmd device_state print-statesen el dispositivo plegable.
Google Pixel Fold (ID de modelo 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 (ID de modelo 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},
]
A diferencia de otros productos de Firebase, no es necesario agregar un SDK de Firebase para utilizar Test Lab. Si aún no tiene una aplicación, puede descargar un APK en línea o crear una aplicación y un APK de prueba a partir de uno de los ejemplos en el repositorio GitHub de AndroidX . Tenga en cuenta que solo necesita el archivo APK de su aplicación para ejecutar una prueba Robo, mientras que una prueba de instrumentación requiere tanto una aplicación como un APK de prueba creados a partir del código fuente. Para obtener más información, lea sobre Pruebas instrumentadas .
Para obtener más información sobre las funciones de Test Lab, consulte Cómo comenzar a probar Android con Firebase Test Lab .
La prueba de diferenciación de capturas de pantalla es donde las afirmaciones de la prueba se basan en la comparación de imágenes de pantalla obtenidas mientras se ejecuta una prueba con imágenes doradas que representan el comportamiento esperado. Estas pruebas pueden ser más frágiles en algunos tipos de dispositivos que en otros. Recomendamos apuntar a dispositivos emuladores Arm ( *.arm ) para este tipo de pruebas. Los dispositivos emuladores Arm utilizan imágenes que son muy similares o idénticas a los emuladores 'genéricos' de Android Studio.
También le recomendamos que investigue bibliotecas de prueba que puedan ayudar a que las pruebas de captura de pantalla sean más sólidas en presencia de cambios esperados.
¡Sí! Los dispositivos virtuales se actualizan cuando se realizan los siguientes cambios:
- Actualizaciones de imágenes existentes
- Desuso de niveles de API anteriores
- Se agregan nuevos niveles de API de Android
Para habilitar los informes de cobertura, agregue coverage=true al campo environmentVariables . Si utiliza Android Test Orchestrator, deberá proporcionar un directorio para almacenar los resultados de la cobertura:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Si no utiliza Orchestrator, puede especificar una ruta de archivo:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
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 mediante el comando describe :
gcloud firebase test android models describe MODEL
Problemas conocidos
Robo test no puede eludir las pantallas de inicio de sesión que requieren una acción adicional del usuario más allá de ingresar las credenciales para iniciar sesión, por ejemplo, completar un CAPTCHA.
La prueba Robo funciona mejor con aplicaciones que utilizan elementos de la interfaz de usuario del marco de la interfaz de usuario de Android (incluidos los objetos View , ViewGroup y WebView ). Si utiliza la prueba Robo para probar aplicaciones que utilizan otros marcos de interfaz de usuario, incluidas aplicaciones que utilizan el motor de juego Unity, es posible que la prueba finalice sin explorar más allá de la primera pantalla.