Solución de problemas de Test Lab y preguntas frecuentes
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 que finaliza 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.
La app no muestra los datos y no puede ubicar las capturas de pantalla
Los artefactos de ejecución de prueba (como las capturas de pantalla y los archivos de registro) se almacenan en
Google Cloud Storage y se procesan directamente en Firebase console. Si
tu ejecución de prueba se realizó en los últimos 90 días, comprueba si
asignaste roles a nivel del proyecto (propietario, editor o visualizador del proyecto).
También asegúrate de que Cloud Audit Logging no esté habilitado en tu organización
o proyecto.
Si la ejecución se realizó hace más de 90 días,
es probable que se hayan borrado automáticamente los artefactos de prueba. Para verificar la
configuración del bucket de resultados, haz clic en la pestaña Resultados de la prueba del
panel de Test Lab. Según la configuración del bucket de resultados predeterminado, se conservan los objetos por 90 días.
Para conservar los artefactos de prueba por más tiempo, ejecuta el comando
gcloud firebase test android run con el parámetro --results-bucket y pasa
el nombre del bucket de resultados. Consulta la documentación de referencia de gcloud firebase test android run
si necesitas más información.
¿Por qué recibo resultados parciales o faltantes en los casos de prueba de instrumentación?
Cuando ejecutas pruebas de instrumentación, es posible que veas errores de prueba que indican resultados parciales con mensajes como Test run failed to complete. Expected
x tests, received y (y es menor que x).
Este error indica que Test Lab no pudo analizar el Logcat de los marcadores de inicio
o fin de casos de prueba que suele generar
AndroidJUnitRunner.
Las siguientes son causas comunes de este problema:
Descripción del problema
Solución posible
No se ejecutó el caso de prueba porque se agotó el tiempo de espera. Si la duración total de las
pruebas supera el tiempo de espera especificado o un
tiempo de espera máximo,
Test Lab cancela el resto de los casos de prueba.
Aumenta el tiempo de espera de la matriz para asegurarte de que todas las pruebas se puedan completar.
Fragmenta las pruebas, si aún no lo hiciste, para que cada fragmento ejecute un
subconjunto de las pruebas y se complete en un período más corto.
Si ya habilitaste la fragmentación, aumenta la cantidad de fragmentos.
No se pudo completar el caso de prueba porque se cerró de forma prematura o se detuvo.
Es posible que el caso de prueba se cierre antes de tiempo debido a una excepción no detectada o
un error de aserción. Es posible que los casos de prueba se detengan en un bucle infinito o que
no puedan continuar, por ejemplo, si la app no muestra la vista correcta y
el caso de prueba no puede realizar la acción en la IU.
Revisa el video y el logcat para investigar dónde se detuvo la
prueba.
Un ejecutor de pruebas personalizado (incluida la extensión de AndroidJUnitRunner) falló
de forma inesperada o escribió marcadores de inicio o fin de casos de prueba inesperados en
logcat.
Verifica el código del ejecutor de pruebas.
Los registros excesivos se escribieron en logcat y sobrecargaron el búfer o
hicieron fallar el proceso logcat.
Reduce las operaciones de escritura a logcat.
La app sometida a prueba falló.
Depura tu app.
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.
¿Test Lab funciona 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.
¿Test Lab es compatible con dispositivos wearable?
Sí. Test Lab es compatible con el Google Pixel Watch. Ahora puedes ejecutar pruebas en
tu app para Wear independiente en el Google Pixel Watch. Para obtener más información sobre los
dispositivos de Test Lab, consulta Cómo realizar pruebas en los
dispositivos disponibles.
¿Test Lab es compatible con los dispositivos de Google más recientes?
Sí. Test Lab es compatible con la Google Pixel Tablet y el Google Pixel Fold. Puedes ejecutar las pruebas en tus dispositivos físicos independientes.
Para obtener más información sobre los
dispositivos de Test Lab, consulta Cómo realizar pruebas en los
dispositivos disponibles.
¿Cómo puedo detectar una prueba en ejecución en Test Lab?
Si pruebas la app en Firebase o ejecutas pruebas para un informe previo al lanzamiento en Play Console, puedes verificar la propiedad del sistema firebase.test.lab en tu archivo MainActivity para detectar si una prueba se ejecuta en un dispositivo alojado en Firebase. Luego puedes ejecutar sentencias adicionales basadas en el valor booleano de testLabSetting. Para obtener más detalles, consulta la sección sobre comportamientos de prueba modificados.
¿Test Lab es 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. Sin embargo,
si creaste la app con un framework que admite Espresso (como
Flutter), puedes escribir una prueba de instrumentación con
Espresso
y, luego, ejecutarla en Test Lab.
¿Test Lab
es compatible con pruebas de apps ofuscadas, por ejemplo, con ProGuard o R8?
Test Lab no admite explícitamente la ofuscación o desofuscación. Si bien es probable que
la app se ejecute, cualquier dato ofuscado, como los seguimientos de pila,
aparecerá como ofuscado en los registros.
¿Puedo usar mi dispositivo plegable en diferentes estados y posiciones plegables mientras hago pruebas en Test Lab?
Estos dispositivos pueden estar en varios estados de plegado, como FLAT (completamente abierto) o HALF_OPENED (entre completamente abierto y completamente cerrado).
Por otro lado, las posiciones constan de la orientación específica y el estado plegable del dispositivo. Por ejemplo, la posición de mesa, que es un estado HALF_OPENED en orientación horizontal, o la posición de libro, que es un estado HALF_OPENED en orientación vertical.
Como alternativa, los estados disponibles son específicos del dispositivo y se puede interactuar con ellos mediante adb
shell command cmd device_state.
Para mostrar el estado actual, ejecuta adb shell cmd device_state state.
Para establecer o anular el estado actual, ejecuta adb shell cmd device_state state <IDENTIFIER>.
Para restablecer el estado, ejecuta adb shell cmd device_state state reset.
Para verificar los estados disponibles, ejecuta el comando adb shell cmd device_state print-states en el dispositivo plegable.
A diferencia de otros productos de Firebase, no necesitas agregar un SDK de Firebase para usar Test Lab. Si aún no tienes una app, puedes descargar un APK en línea o compilar una app y un APK de prueba de una de las muestras del repositorio de AndroidX en GitHub.
Ten en cuenta que solo necesitas el archivo APK de tu app para ejecutar una prueba Robo, mientras que una prueba de instrumentación requiere una app y un APK de prueba que se compilan a partir del código fuente. Para obtener más información,
consulta el artículo sobre las pruebas instrumentadas.
¿Qué dispositivos son mejores para
las pruebas de captura de pantalla con diferencias?
En las pruebas de captura de pantalla con diferencias, las aserciones de prueba se basan en comparar
imágenes de pantalla obtenidas durante la ejecución de 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 otras. Recomendamos segmentar
los dispositivos emuladores de ARM (*.arm) para este tipo de pruebas. Los dispositivos emuladores de ARM usan
imágenes muy similares o idénticas a los emuladores “genéricos” de Android Studio.
También te recomendamos que investigues las bibliotecas de prueba, ya que pueden ayudar a que las
pruebas de captura de pantalla sean más sólidas ante la presencia de cambios esperados.
¿Cómo habilito los informes de cobertura?
Para habilitarlos, agrega coverage=true al
campo environmentVariables.
Si usas Android Test Orchestrator, deberás proporcionar un directorio para
almacenar los resultados de la cobertura:
¿Dónde puedo encontrar los detalles del dispositivo, como
la resolución, las ABI compatibles, 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 android models describe MODEL
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.
