Utilice capturas de pantalla para una apariencia de pantalla completa, OCR para texto visible y coincidencia de imágenes para un objetivo visual conocido. Las pruebas visuales más sólidas de Android combinan una afirmación enfocada con tiempos estables y evidencia de fallas.
La respuesta corta: prueba lo que debe seguir siendo cierto.
Utilice pruebas de captura de pantalla cuando toda la pantalla, el componente, el espaciado, el color o la tipografía deban permanecer visualmente consistentes. Utilice OCR cuando el requisito sea sobre palabras que una persona puede ver, especialmente texto localizado o renderizado dinámicamente. Utilice la coincidencia de imágenes cuando deba aparecer un ícono, botón, insignia o ilustración conocida incluso cuando no tenga un identificador de interfaz de usuario confiable.
Comience con un selector de interfaz de usuario o un estado de accesibilidad cuando el requisito sea semántico: existe un control, está habilitado, está seleccionado o expone una etiqueta estable. Agregue detección de objetos solo cuando el objetivo pertenezca a una clase visual y pueda cambiar demasiado de tamaño o posición para una plantilla. Estos métodos son capas, no marcos de prueba competitivos.
- Pregunte qué evidencia convencería a un revisor de que se aprobó el requisito.
- Elija la señal confiable más estrecha en lugar de comparar cada píxel de forma predeterminada.
- Estabilice la pantalla antes de observarla, luego guarde un artefacto cuando falle la afirmación.
Comparación de métodos de prueba visual de Android
| Método | Lo mejor para | Principal debilidad | Evidencia útil |
|---|---|---|---|
| UI o estado de accesibilidad | Controles, etiquetas, estado habilitado, selección, estructura de navegación. | Los elementos renderizados personalizados o inaccesibles pueden ser invisibles para el árbol de la interfaz de usuario | Jerarquía de UI, propiedades seleccionadas, captura de pantalla |
| Captura de pantalla o imagen dorada | Diseño, espaciado, colores, tipografía, apariencia de los componentes. | Los datos dinámicos, las animaciones, las diferencias de dispositivos y los cambios de representación pueden crear diferencias ruidosas | Imagen actual, línea base aprobada, diferencia visual |
| OCR | Texto visible, localización, recibos, mensajes de estado, valores representados como píxeles | La calidad del reconocimiento depende del recorte, la escala, el contraste, los datos del idioma, la rotación y la segmentación. | Recorte de origen, texto reconocido, confianza o lista de resultados |
| Coincidencia de plantillas | Un icono, botón, insignia, miniatura o pequeña región estable conocida | El tema, la escala, la compresión y el rediseño pueden invalidar la plantilla | Plantilla, región de búsqueda, mejor coincidencia, puntuación, captura de pantalla |
| Detección de objetos | Un objeto visual cuya clase sigue siendo significativa mientras la posición o el tamaño varían. | Requiere un modelo compatible, clases etiquetadas, umbrales y validación del modelo. | Versión del modelo, clase, caja, puntuación, captura de pantalla. |
La guía oficial de prueba de capturas de pantalla de Android describe la comparación de la representación actual con una imagen de referencia aprobada. El complemento de imágenes de Appium expone la coincidencia de características, la coincidencia de plantillas y la comparación de similitudes. OpenCV documenta la mecánica de deslizar una plantilla sobre una imagen, mientras que Tesseract documenta por qué son importantes el preprocesamiento de OCR y la segmentación de páginas. Las herramientas difieren, pero la cuestión del diseño de la prueba sigue siendo la misma: ¿qué observación prueba este requisito?
Elija la afirmación correcta con cuatro preguntas
1. ¿El requisito es semántico o visual?
Si la prueba dice "el botón Enviar está habilitado", primero inspeccione el estado de la interfaz de usuario. Si dice "el botón Enviar no aparece recortado después del cambio de fuente", utilice una captura de pantalla o una comprobación visual enfocada. Una consulta semántica suele ser más fácil de mantener, pero no puede probar la apariencia.
2. ¿Importa el texto exacto?
Utilice OCR cuando el requisito sea la cadena orientada al usuario y el texto no esté expuesto de manera confiable a través del árbol de la interfaz de usuario. Restrinja el reconocimiento a la región significativa más pequeña, seleccione el idioma correcto y compare un resultado normalizado. Mantenga una captura de pantalla porque una cadena de OCR correcta por sí sola no puede mostrar truncamiento, superposición o contraste deficiente.
3. ¿Existe un objetivo visual estable?
Utilice la coincidencia de plantillas para un icono conocido o un control pequeño. Recorte la plantilla con precisión, busque dentro de una región de interés y establezca el umbral a partir de muestras positivas y negativas reales. Un umbral universal rara vez es defendible entre temas, resoluciones y transmisiones remotas comprimidas.
4. ¿Debe permanecer coherente toda la composición?
Utilice la comparación de capturas de pantalla cuando la relación entre muchos elementos sea importante. Controle las fuentes, la configuración regional, la configuración del dispositivo, las barras del sistema, la hora, los datos de la red, las animaciones y el contenido inicial. Si esas entradas no se pueden controlar, enmascare o recorte las regiones dinámicas en lugar de aceptar una prueba permanentemente ruidosa.
Cree una prueba visual que falle de manera útil
- Lleve la aplicación a un estado inicial designado en un dispositivo o emulador autorizado.
- Espere una condición estable, no solo un retraso fijo. UI Automator proporciona estabilidad en espera y una señal de preparación específica de la aplicación es aún mejor.
- Capture la región de origen más pequeña que contenga la evidencia requerida.
- Ejecute una afirmación principal: estado de la interfaz de usuario, OCR, plantilla, detección o comparación de capturas de pantalla.
- Guarde la imagen de origen y el resultado estructurado antes de realizar la siguiente acción.
- En caso de error, deténgase o siga una ruta de recuperación revisada. No toque a un imitador cercano simplemente para mantener la prueba en movimiento.
Un control visual se vuelve más seguro cuando autoriza una transición. Observe el estado actual, haga la afirmación, realice la acción permitida solo después del éxito y verifique la poscondición. Este es el mismo principio de diseño descrito en la guía de clic automático de reconocimiento de imágenes: el reconocimiento no es una prueba de que el flujo de trabajo haya finalizado.
Para trabajos en dispositivos reales,Duplicación de pantalla de Android para pruebas de aplicaciones móvilesle brinda al revisor una vista en vivo mientras se diseña la prueba. La guía de pruebas de humo de control de calidad de automatización de Androidexplica cómo mantener las comprobaciones repetidas limitadas y reproducibles.
Tres escenarios prácticos de prueba visual de Android
Control de calidad de localización en una pantalla de pago
Utilice el estado de la interfaz de usuario para navegar a la pantalla de pago, OCR para confirmar el total localizado y la etiqueta de acción, y una captura de pantalla enfocada para mostrar que las cadenas no están recortadas ni superpuestas. Ejecute cada configuración regional con datos de prueba controlados. Una comparación de píxeles de pantalla completa por sí sola será demasiado sensible a la longitud de la cadena traducida, mientras que el OCR por sí solo no detectará daños en el diseño.
Comprobando un icono de barra de herramientas rediseñado
Utilice una plantilla para el icono aceptado en una pequeña región de la barra de herramientas. Mantenga plantillas separadas cuando se admitan temas claros y oscuros. Cuando la coincidencia falla, adjunte el recorte de la barra de herramientas y la puntuación del mejor candidato. Si el ícono se rediseña intencionalmente, revise y reemplace la plantilla en lugar de bajar el umbral hasta que pase cualquier forma.
Una prueba de humo con un teléfono real después del despliegue
Comience desde una cuenta y un estado de aplicación conocidos, espere la pantalla de inicio, afirme su identidad, realice una acción permitida y verifique el siguiente estado nombrado. Tome una captura de pantalla de cada falla. La densidad del dispositivo, los cuadros de diálogo de permisos, los teclados, las notificaciones y las actualizaciones del sistema son parte del entorno del teléfono real, por lo que la prueba debería informarlos en lugar de ocultarlos.
Fallos falsos comunes y cómo prevenirlos
| Síntoma | causa probable | Mejor respuesta |
|---|---|---|
| La diferencia de captura de pantalla cambia en cada ejecución | Reloj, animación, anuncios, datos inicializados, teclado, barra del sistema o contenido de red | Congelar entradas, esperar estabilidad, recortar o enmascarar solo la región dinámica |
| OCR devuelve texto plausible pero incorrecto | Lenguaje incorrecto, bajo contraste, recorte pequeño, rotación, ruido o segmentación inadecuada | Guarde el recorte, mejore la escala y el contraste, elija el idioma y la segmentación deliberadamente |
| La coincidencia de plantillas funciona solo en un teléfono | Diferente densidad, tema, escala, relación de aspecto o compresión | Utilice una región de interés y plantillas validadas para variantes visuales compatibles |
| Se encuentra la imagen correcta pero falla el grifo. | Las coordenadas de coincidencia no se transformaron en la pantalla actual o una superposición bloquea la entrada | Separe el reconocimiento de la acción y verifique el siguiente estado |
| La prueba continúa en la pantalla equivocada | Sin poscondición o borde de falla | Nombre los estados esperados y deténgase cuando la pantalla actual esté fuera de la ruta revisada |
| El detector de objetos encuentra la clase incorrecta | El modelo o las etiquetas no se ajustan al dominio de la aplicación; el umbral no está validado | Utilice un modelo compatible, registre la versión y la puntuación, pruebe muestras negativas |
Las discusiones comunitarias sobre las pruebas de regresión de Android a menudo regresan a los mismos costos de mantenimiento: matrices de dispositivos, tiempos irregulares, revisión de referencia y pantallas cuyo contenido cambia. Esas no son razones para abandonar las pruebas visuales. Son razones para hacer explícitos el entorno de prueba, la variación aceptada y los artefactos de falla.
Cómo encaja LaiCai Flow en las pruebas visuales
LaiCai Flowes una función de automatización dentro de LaiCai Screen Mirroring. Un flujo puede combinar captura de pantalla, comprobaciones de la interfaz de usuario, OCR, coincidencia de plantillas, detección de objetos, condiciones, acciones y transiciones explícitas de éxito o fracaso. Esto permite al evaluador modelar la pantalla como un estado en lugar de tratar el reconocimiento como un truco aislado.
ConLaiCai Flow Inside, se puede ejecutar un perfil compatible a través de LaiCai Android Agent en el teléfono después de la implementación. La compatibilidad aún depende de cada nodo y activo utilizado por ese perfil. El OCR local utiliza Tesseract; la coincidencia de plantillas utiliza un recurso de imagen seleccionado y una puntuación configurable; La detección local compatible utiliza un modelo compatible. Un nodo de red o modelo remoto aún necesita su propia dependencia de red.
Esto no hace que todas las pruebas visuales sean automáticamente confiables. Los equipos aún necesitan líneas de base, plantillas, regiones de OCR, modelos, umbrales, casos negativos y condiciones posteriores representativas. El valor es que esas decisiones y transiciones se pueden revisar en un solo flujo de trabajo. La guía de automatización de AndroidAIproporciona una visión más amplia de la creación y ejecución en dispositivos reales.
El paquete de evidencia mínimo para una prueba visual fallida
- Nombre de la prueba, compilación de la aplicación, modelo de dispositivo, versión de Android, configuración regional, tema y orientación.
- La captura de pantalla de origen o la región recortada utilizada por la afirmación.
- La propiedad de línea base, plantilla, texto, clase o interfaz de usuario esperada.
- La diferencia observada, el resultado de OCR, el cuadro delimitador, la puntuación de coincidencia o el valor de la interfaz de usuario.
- El estado nombrado anterior, la acción intentada, el siguiente estado esperado y el motivo de la detención.
- Versión de activo, modelo o línea base para que un revisor pueda reproducir la decisión.
Una etiqueta de aprobado/reprobado sin este contexto obliga a la siguiente persona a reproducir toda la ejecución. Un paquete de evidencia compacto convierte la falla en una decisión revisable: arreglar el producto, estabilizar la prueba, actualizar un recurso visual aprobado o rechazar una configuración de dispositivo no compatible.
Preguntas frecuentes sobre pruebas visuales de Android
¿Cada prueba de la interfaz de usuario de Android debería incluir una captura de pantalla?
No. Utilice capturas de pantalla cuando la apariencia sea importante o cuando un artefacto fallido ayude al revisor. Las aserciones semánticas suelen ser mejores para el comportamiento que el árbol de la interfaz de usuario expone de manera confiable.
¿Es el OCR mejor que la coincidencia de imágenes?
OCR responde preguntas sobre texto visible. La comparación de imágenes responde preguntas sobre un patrón visual conocido. Si el requisito incluye tanto la etiqueta como su apariencia, utilice OCR más una captura de pantalla enfocada o una verificación de plantilla.
¿Se pueden ejecutar pruebas de captura de pantalla en teléfonos Android reales?
Sí, pero los dispositivos reales introducen más variaciones que un renderizador o emulador controlado del lado del host. Registre la configuración del dispositivo, estabilice la interfaz de usuario y los datos del sistema y establezca expectativas para la matriz de dispositivos que realmente admite.
¿Cuándo debo utilizar la detección de objetos?
Úselo cuando una clase de objeto significativa se mueva o escale más allá de la tolerancia de una plantilla estable, y solo cuando se haya validado un modelo compatible en las imágenes reales de la aplicación. No agregue un detector sólo porque parezca más avanzado.
Elija evidencia antes de elegir tecnología
Las pruebas visuales confiables de Android comienzan con una frase: ¿qué debe poder demostrar un revisor? Elija el estado de la interfaz de usuario para la semántica, capturas de pantalla para la composición, OCR para el texto, coincidencia de plantillas para un objetivo visual conocido y detección de objetos para una clase validada con geometría variable.
Luego, haga que la observación forme parte de una transición de estado: estabilice, capture, afirme, actúe sólo después del éxito, verifique la poscondición y preserve la evidencia del fracaso. Ese diseño es más fácil de entender que una colección de llamadas visuales desconectadas y mucho más fácil de mantener cuando cambia la aplicación o el dispositivo.
- Desarrolladores de Android: prueba de captura de pantalla
- Desarrolladores de Android: prueba de captura de pantalla de vista previa de redacción
- Desarrolladores de Android: Automator de interfaz de usuario
- Appium: complemento de imágenes y modos de comparación
- OpenCV: coincidencia de plantillas
- Tesseract: mejorando la calidad del OCR
- Discusión de desarrolladores de Android: prueba de captura de pantalla