Automatización Android con AI para probar la localización de apps

Construir un flujo de trabajo de detección de aplicaciones Android que combina pseudolocales, cheques de idiomas reales, revisión RTL, OCR, capturas de pantalla y juicio humano sin multiplicar cada prueba por cada local.

La respuesta corta: automatizar la ruta, revisar el idioma

Un flujo de trabajo de detección de aplicaciones Android confiable separa el trabajo de dispositivo repetible del juicio del idioma. Configuración de lenguaje automatizado, lanzamiento de aplicaciones, navegación, esperas, capturas de pantalla, cheques de estado conocidos y colección de pruebas. Mantenga la calidad de la traducción, tono, significado cultural, clipping ambiguo y equilibrio visual bajo revisión humana. El objetivo no es ejecutar cada prueba en cada idioma. Es crear una matriz pequeña y basada en el riesgo que exponga los fallos más probables para llegar a los usuarios.

Esto importa porque los defectos de localización no son sólo palabras erróneas. Incluye cadenas codificadas, recursos perdidos, expansión de texto, diseños rotos de derecha a izquierda, fechas incorrectas o moneda, desajuste del teclado, fuentes no legibles, botones recortados y ajustes de idioma que no persisten. AnAI Android herramienta de automatizaciónpuede ayudar a repetir la ruta visible y recoger evidencia, pero no puede decidir si una frase suena natural a un cliente local.

El flujo de trabajo a continuación combina las funciones oficiales de localización de Android con los controles de dispositivo observables. No reclama queLaiCai Flowreemplaza las pruebas unitarias, las pruebas Compuestas, Espresso, UI Automator, Appium, un sistema de gestión de la traducción o revisión de lengua nativa. Utilice cada capa para la evidencia que produce mejor.

Comience con una matriz de liberación de localización, no una lista de idiomas

Una lista de idiomas compatibles no es un plan de prueba. Una matriz de liberación conecta un local a la pantalla, condición de dispositivo, formato de datos, dirección de escritura y riesgo de negocio que hacen que locale sea significativo. Sin esa conexión, los equipos a menudo abren la pantalla de inicio en varios idiomas, toman una captura de pantalla y pierden fallos en el checkout, la búsqueda, la recuperación de la cuenta, notificaciones o ajustes.

Elija un local de referencia, un local ondulado, un local compacto o complejo, y un local RTL para cada lanzamiento. Agregue locales específicos para el mercado solamente a los flujos que conllevan riesgo de negocio material.Firebase Test Lab Android matrizsimilarmente trata locale como una dimensión junto con el modelo de dispositivo, versión de Android y orientación; es un modelo de planificación útil incluso cuando se ejecutan cheques en sus propios dispositivos.

Utilizar pseudolocales Android antes de que lleguen las traducciones

Pseudolocales son el sistema de alerta temprana más barato en el flujo de trabajo.Orientación pseudolocal de Androiddescribe`en-XA`, que expande y acentúa el texto inglés, y`ar-XB`, que ejerce el comportamiento derecho a izquierda. Pueden exponer cadenas codificadas, concatenación de cadenas rotas, presión de diseño, problemas de texto bidireccional, y elementos que no se reflejan antes de que un traductor ofrezca copia final.

• Ejecute el viaje principal de usuario en`en-XA`y grabar todas las cadenas que permanecen en inglés claro; puede ser codificada o fuera de la ruta de recursos de localización.
• Repita el mismo viaje en`ar-XB`e inspeccionar el orden de navegación, flechas traseras, pestañas, indicadores de progreso, números mixtos y puntuación.
• Capture error, vacío, permiso, actualización y estados de confirmación; son menos visibles durante la revisión ordinaria del compás feliz.
• Tratar un fallo pseudolocal como defecto de localización, no como prueba de que una traducción real particular es errónea.

Los desarrolladores también pueden inspeccionar pantallas seleccionadas antes.Documentación de localización de AndroidyConfigurar herramienta de vista previasoporte locale-specific previsualizaciones, incluyendo ejemplos RTL. Estos cheques de código-adyacente son rápidos y deben capturar problemas de nivel de componentes antes de un flujo de trabajo completo del dispositivo.

Prueba la ruta del idioma que los usuarios realmente toman

Una pantalla traducida no es suficiente si los usuarios no pueden seleccionar, retener o restablecer el idioma.Android guía de idiomas por aplicaciónexplica que Android 13 y más tarde proporcionan un sistema centralizado para el lenguaje preferido de una aplicación, mientras que AndroidX admite el manejo de aplicaciones compatible en versiones anteriores. Las aplicaciones también pueden tener su propio idioma. Cada camino de entrada compatible necesita una pequeña prueba de transición estatal.

1. Comienza desde un estado limpio llamado: instalación fresca, instalación actualizada, cuenta firmada o copia de seguridad restaurada.
2. Elija el local a través del sistema previsto o vía in-app y confirme si la aplicación reinicia, recrea la actividad o actualizaciones en su lugar.
3. Navegue lejos de los ajustes y confirme el destino locale aparece en una pantalla crítica de negocio.
4. Cerrar y reabrir la aplicación, a continuación, verificar que la preferencia persiste.
5. Reiniciar el predeterminado del sistema y confirmar que los recursos traducidos no permanecen.
6. En versiones anteriores de Android, prueba el camino de compatibilidad real en lugar de asumir Android 13 comportamiento.

El lenguaje del dispositivo y el lenguaje del teclado son preocupaciones separadas.Documentación de pruebas de localización de BrowserStacknotas que cambiar el idioma en un dispositivo Android no necesariamente cambia el lenguaje del teclado. Preserve esa distinción en la matriz por lo que un fallo de entrada de texto no se diagnostica mal como un fallo de recursos.

Seleccione pantallas representativas por riesgo

No multiplique cada prueba de extremo a extremo existente por cada local. Seleccione pantallas donde la localización cambia comportamiento, diseño, confianza o dinero. Un conjunto compacto generalmente incluye a bordo, entrada, navegación en casa, búsqueda, una página de detalle, una forma, una superficie de pago o confirmación, ajustes, notificaciones y el estado de error más importante.

Priorizar controles con ancho fijo, iconos adyacentes, múltiples variables, reglas plurales, texto dinámico del servidor, tarjetas compactas, navegación inferior y texto traducido sobre imágenes. Incluye una pantalla con contenido realista máximo en lugar de solo datos demo vacíos. Si su aplicación soporta tabletas, plegables o paisajes, añádelos únicamente cuando el diseño cambie genuinamente.

Dar a cada pantalla seleccionada un propietario y una razón. Por ejemplo, la confirmación de checkout existe para verificar la moneda, envoltura de líneas, etiquetas de botones y copia legal; la pantalla de recuperación de cuenta existe para verificar el método de entrada, mensajes de error y direcciones de correo electrónico bidireccional. Esto hace que los fallos sean factibles en lugar de producir una carpeta de capturas de pantalla no explicadas.

Coincide con el método de evidencia para el defecto de localización

Ningún único localizador o técnica de imagen prueba la calidad de localización. Elija la observación más pequeña que pueda apoyar la decisión. Las existentesGuía de pruebas visuales de Androidexplica las diferencias más amplias entre el estado UI, OCR, la combinación de imágenes, detección de objetos y capturas de pantalla; localización QA aplica esos métodos a riesgos específicos para el lenguaje.

En la actualidadLaiCai Flowcontrato, OCR devuelve una colección de resultados en lugar de una respuesta mágica. Un flujo debe seleccionar el segmento pertinente antes de comparar texto o posición. Asimismo, un partido visual reporta un estado conocido; no debe ser estirado en una afirmación de que cada píxel o frase es correcta.

Construir un flujo de localización observable en dispositivos Android reales

Un flujo de trabajo visual observable es útil cuando el equipo necesita repetir la misma navegación a través de dispositivos Android reales y entregar un revisor evidencia consistente.LaiCai Flowes una característica de automatización dentroLaiCai Screen Mirroring. Puede organizar pasos visibles tales como esperas, cheques UI-state, OCR, compatibilidad de plantilla, capturas de pantalla, condiciones, bucles atados, y paradas explícitas. ElLaiCai Flowguíacubre el flujo de trabajo del producto.

1. Nombre de la construcción, dispositivo, versión Android, locale, tema, escala de fuentes, y estado de cuenta de inicio.
2. Abra el camino de aplicación o configuración y use esperas explícitas antes de las observaciones dependientes de pantalla.
3. Navegue una fase a nivel de usuario a la vez, manteniendo detalles de búsqueda técnica dentro de flujos de niños legibles cuando el viaje se vuelve complejo.
4. Compruebe una condición de pantalla estable antes de cada acción destructiva o de cambio de estado.
5. Captura la captura de pantalla requerida y cualquier resultado OCR seleccionado con el identificador local y de pantalla.
6. Verificar una poscondición después de la navegación en lugar de asumir que un toque tuvo éxito.
7. Pare con evidencia cuando la pantalla es desconocida; no siga haciendo clic a través de un lenguaje o diálogo inesperado.

Esta capa complementa las pruebas basadas en código. Las pruebas de componentes e instrumentación todavía deben poseer una búsqueda de recursos, lógica estatal, semántica de accesibilidad y afirmaciones deterministas cercanas a la aplicación. Un flujo visible es más fuerte cuando los revisores de soporte, localización o liberación necesitan una ruta repetible y un paquete de evidencia legible por humanos. ElAndroid QA flujo de trabajo de prueba de humoproporciona un patrón general relacionado.

Dar RTL y contenido bidireccional su propio pase de prueba

RTL no es un elemento que añadir al final de una lista de captura de pantalla LTR. Ejecute un pase dedicado con árabe u otro local RTL compatible e incluya contenido de dirección mixta como direcciones de correo electrónico, números de teléfono, precios, cadenas de versión, URLs, códigos y nombres de marca latina. Estas combinaciones revelan puntuaciones y fallas de orden que un párrafo totalmente traducido no puede mostrar.

• Confirme que la navegación, los cajones, las pestañas, la dirección de progreso y los iconos direccionales sólo reflejan su significado.
• Compruebe que los números, unidades, nombres de producto y cursores de entrada siguen siendo legibles dentro de las oraciones RTL.
• Inspeccione la alineación en estados vacíos, diálogos, snackbars, explicaciones de permiso y mensajes de validación de formularios.
• Pruebe los giros y la navegación trasera por el comportamiento, no asumiendo que cada gesto invierte con la dirección de texto.
• Utilice un revisor de idiomas nativos para la puntuación, frases, rupturas de líneas y interpretación cultural.

Uso`ar-XB`temprano para exponer fallas estructurales, luego ejecutar al menos un local RTL real antes de la liberación. Un pseudolocal puede revelar defectos espejo, pero no valida la tipografía o significado de la producción copia árabe.

Formatos de prueba, entrada, notificaciones y superficies externas

Algunos de los fallos de localización más caros se encuentran fuera de la pantalla principal de la aplicación. Agregue cheques enfocados para la fecha y hora, separadores decimales, colocación de divisas, orden de dirección, unidades de medición, números de teléfono, formas plurales, entrada de teclado, comportamiento de portapapeles, texto de notificación, enlaces profundos, contenido web, y cualquier diálogo de sistema que el viaje depende.

Grabar qué local conduce cada valor. El lenguaje de aplicación, sistema locale, país de cuenta, preferencia del servidor, zona horaria y teclado puede estar en desacuerdo. Una captura de pantalla que muestra un valor sorprendente es evidencia útil, pero el informe de fallos también debe nombrar esos insumos para que la ingeniería pueda reproducir la fuente del desajuste.

Treat tienda listados y capturas promocionales como una superficie de liberación separada. Su texto puede provenir de un repositorio diferente y sus imágenes pueden ser generadas por un conducto diferente. Reutiliza el mismo inventario de pantalla y esquema de nominación, pero no marca la aplicación localizada simplemente porque la descripción de la tienda se traduce.

Mantenga la revisión humana donde la automatización es débil

La automatización es buena para repetir una ruta y detectar pruebas conocidas. Los humanos siguen siendo mejores en el sentido, tono, contexto, ajuste cultural, jerarquía visual, humor, ambigüedad, y decidir si una ruptura de línea se ve simplemente diferente o realmente daña la comprensión. Construir la entrega deliberadamente en lugar de tratar la revisión manual como una excepción no planificada.

• Automatización: configuración local, lanzamiento, navegación, esperas, cheques de estado estables, presencia de texto seleccionada, capturas de pantalla, nombre de archivo y embalaje de pruebas.
• Revise manualmente: significado de traducción, naturalidad, matiz legal, accesibilidad de scripts complejos, truncación ambigua, imágenes culturales y equilibrio visual.
• Escalar a pruebas de código: mapeo exacto de recursos, lógica plural, funciones de formato determinista y semántica de componentes.
• Escalar a pruebas de dispositivo o marco: permisos del sistema, comportamiento de aplicación cruzada, integración del teclado y transiciones del ciclo de vida.

Una regla de parada útil es simple: cuando el estado visible no es uno de los estados aprobados, recoge evidencia y detiene. No deje que una automatización continúe a través de una pantalla de consentimiento desconocida, paso de pago, acción destructiva, o camino de sistema no traducido. ElComparación de herramientas de pruebas de automatización de Androidpuede ayudar a asignar cada aserción a la capa correcta.

Crear un paquete de pruebas que un equipo de liberación puede actuar en

Un dashboard pase/fail sin contexto crea otra investigación. Cada hallazgo de localización debe identificar la construcción, paquete de aplicaciones y versión, locale y región, Android versión, dispositivo y resolución, escala de fuentes, tema, estado de inicio, nombre de pantalla, resultado esperado, resultado real, y la captura de pantalla o observación seleccionada que soporta la reclamación.

Use nombres de archivos estables como`build-locale-device-screen-state.png`, entonces mantén un manifiesto que mapas archivos a la matriz de prueba. Separar la variación visual esperada de defectos: una ruptura de línea diferente puede ser aceptable, mientras que un precio oculto, botón inalcanzable, marca reversa, o mensaje de error faltante no es. Asignar gravedad por impacto del usuario, no por diferencia de píxel.

Debido a que ningún dispositivo gestionado por LaiCai estaba disponible en el contexto de generación actual, este artículo describe un flujo de trabajo basado en contratos en lugar de reclamar resultados de referencia para una aplicación, dispositivo o local en particular. Ejecute un piloto representativo en su entorno antes de expandir la matriz.

Android localización QA lista de verificación de liberación

1. Definir la lista local apoyada, el lugar de retorno, las rutas de selección de idiomas y los mercados de alto riesgo.
2. Corre`en-XA`y`ar-XB`en pantallas representativas antes de que lleguen las traducciones finales.
3. Verifique el cambio de idioma per-app real, sistema y en-app donde cada camino es compatible.
4. Cubrir un local lleno de expansión, un local de escritura compleja y un local de RTL en una pantalla pequeña.
5. Incluya los estados de error, vacío, carga, confirmación, permiso, actualización y notificación.
6. Compruebe los formatos regionales, los métodos de entrada, la escala de fuentes, el tema de luz / oscuro y la persistencia del lenguaje.
7. Usa el estado de la interfaz, OCR, comparación de plantillas, capturas de pantalla y revisión humana solo para afirmaciones que realmente puedan respaldar.
8. Guardar un paquete de pruebas nombrado y parar en estados no reconocidos.
9. Que un revisor de lengua nativa apruebe significado, tono, puntuación y ajuste cultural.
10. Mantenga la automatización primaria CTA en la página de propietarios locale-aware y utilice guías de apoyo para detalles de implementación.

Sobre el autor: BeePOS LLC desarrollaLaiCai Screen Mirroringy suLaiCai Flowfunción de automatización. Esta guía se basa en la documentación actual de Android, las prácticas de análisis de localización observadas, y el publicadoLaiCai Flowcontrato de nodos. Las preguntas del producto se pueden enviar a través deLaiCai empresa y página de soporte.

Fuentes

• Android Developers: Prueba tu app con pseudolocales
• Android Desarrolladores: Preferencias de lenguaje de aplicación
• Android Developers: Localiza tu app
• Android Developers: Previsualice su interfaz de usuario con previsualizaciones composibles
• Firebase: Comienza a probar para Android con Test Lab
• BrowserStack: Pruebas de localización usando App Live