Quiero ejecutar cualquier cantidad de pruebas de IU de Android para cada PR. ¿Tus acciones? Parte I | de Eugene Matsyuk | abril 2023

Estimado lector, si está leyendo este artículo, probablemente ya se haya dado cuenta del valor de incorporar pruebas de interfaz de usuario para cada solicitud de incorporación de cambios en su proceso de desarrollo. En resumen, es la única forma de asegurarse de que su rama principal esté lista para su lanzamiento en todo momento. Lanzar versiones excelentes y estables es crucial en el mundo móvil, donde un usuario gestiona por completo el proceso de actualización de una aplicación, a diferencia del mundo backend. Si es un novato en las pruebas de interfaz de usuario de Android, lea mi artículo anterior o hable con Alex Bykov para obtener todos los detalles y explicaciones. La ejecución de pruebas de interfaz de usuario en cada PR, si bien es beneficiosa, presenta desafíos importantes para la infraestructura subyacente. Como resultado, casi todos los equipos que intentan implementar pruebas de IU para cualquier RP encuentran dificultades, a menudo cometen los mismos errores e invierten mucho tiempo y recursos en el proceso. En esta serie de artículos, abordaré los requisitos de infraestructura específicos necesarios para ejecutar pruebas de interfaz de usuario en PR, discutiré las soluciones disponibles en el mercado, exploraré cómo estas soluciones pueden ayudar a cumplir con los criterios anteriores e intentaré estimar la construcción de nuestras propias soluciones. . Con una comprensión profunda de los desafíos de la infraestructura y las explicaciones disponibles, los equipos de desarrollo pueden controlar mejor la complejidad de implementar pruebas de interfaz de usuario para cualquier RP y, en última instancia, ahorrar tiempo y recursos. Primero, definamos el término infraestructura de prueba de interfaz de usuario. «Infraestructura de prueba de interfaz de usuario» es lo que permite la ejecución de las pruebas de interfaz de usuario. En cada PR. Cualquier número de pruebas. Desde la perspectiva de un usuario (equipos de control de calidad y desarrollo de software), parece que estoy enviando un comando para ejecutar una serie de pruebas y obtener un informe. Es todo. Debe ser fácil para quienes lo usan. Pero es complejo para quienes desarrollan y respaldan la solución. Entonces, nuestro objetivo final es construir de alguna manera esa infraestructura utilizando soluciones y recursos internos o externos. Bien, ahora refresquemos nuestra memoria del panorama general del proceso de prueba de la interfaz de usuario con algunas actualizaciones que aparecieron la última vez.Ves muchos detalles en el rompecabezas. Ahora mire dónde se presenta la infraestructura de prueba de interfaz de usuario.La «infraestructura de prueba de interfaz de usuario» cubre una amplia gama de cosas diferentes. Las partes de escritura y back-end permanecen en el lado del usuario, ya que solo el usuario (desarrollador o SDET) ahora puede crear pruebas. Por lo tanto, la escritura no es objeto de este artículo. Para obtener una excelente comparación de todas las herramientas de escritura, consulte los artículos Dónde escribir pruebas de IU de Android (Parte 1) y Dónde escribir pruebas de IU de Android (Parte 2) (excepto Maestro, que apareció después del lanzamiento). Las cuestiones de back-end relacionadas con las pruebas en redes reales o simuladas se abordarán parcialmente más adelante. Pero debo mencionar que, a gran escala, Mock Network también tiene la responsabilidad de la infraestructura de prueba de UI. Antes de profundizar en las complejidades de construir esta infraestructura, recomiendo comenzar con un conjunto claro de requisitos y expectativas. Estos sirven como una hoja de ruta para guiarlo a través del complicado proceso de construcción de la infraestructura. Además, es importante recordar que los principales usuarios de la infraestructura de pruebas de IU son los desarrolladores, los SDET (ingenieros de desarrollo de software en pruebas) y el control de calidad. Por lo tanto, nuestro enfoque debe estar en optimizar su experiencia laboral y garantizar un entorno cómodo y eficiente para estos profesionales. Echa un vistazo a la siguiente imagen.Ahora veamos punto por punto.Plataformas compatiblesEn el desarrollo de Android, existen dos plataformas principales para crear pruebas de interfaz de usuario:

1. La plataforma nativa donde los desarrolladores solo usan herramientas proporcionadas por Google, como Espresso y UI Automator. Las soluciones como Kaspresso, Barista, etc. se basan en Espresso y UI Automator.
2. Appium, un marco de prueba multiplataforma de código abierto.

interfazA continuación, una expectativa básica es la fácil integración con los sistemas CI/CD existentes a través de complementos y la capacidad de aprovechar la infraestructura a través de la interfaz de línea de comandos (CLI). El complemento y la CLI deben al menos proporcionar la flexibilidad para filtrar las pruebas para su ejecución y seleccionar los dispositivos deseados. Además de esta funcionalidad básica, se deben admitir diferentes modos de verificación, es decir, ejecuciones rápidas frente a la verificación de una corrección por descamación. Más adelante se proporcionarán más detalles sobre estos términos.informesAl final de una ejecución, un usuario espera informes que contengan al menos la siguiente información:

• el resultado final: pasa o falla
• Número de pruebas realizadas, aprobadas, fallidas e ignoradas
• Información sobre pruebas fallidas, como seguimiento de pila, registros de dispositivos y videos
• algunos análisis, como el porcentaje de pruebas fallidas, incluidos los reintentos

estabilidadLa estabilidad es un término amplio que abarca varios aspectos de las pruebas de interfaz de usuario. Una prueba puede ser inestable (o errónea) por varias razones, tales como: B. Pruebas mal escritas, un backend inestable o una red poco confiable cuando la prueba se ejecuta desde un backend real, indicadores de funciones, una configuración incorrecta o un dispositivo inestable (por ejemplo, actualizar los servicios de Google o no apagar la animación), inestabilidad del marco (espresso, Se sabe que UI Automator y Appium tienen sus peculiaridades) o problemas internos con la infraestructura de prueba causados ​​por factores como alta carga o bloqueos en cualquiera de los servicios internos. Eche un vistazo a la siguiente imagen para resumir las posibles razones de la falla:Al elegir una infraestructura, esperamos una estabilidad total o al menos una recuperación rápida que no afecte los resultados generales y el tiempo. La infraestructura de prueba de IU debe cubrir las áreas de «dónde ejecutar», «ejecutar» e «infraestructura de hardware». Con el tiempo, la cantidad de pruebas de interfaz de usuario tiende a aumentar y, con ello, la aparición de pruebas escamosas. Una prueba poco confiable es una prueba que funciona correctamente la mayor parte del tiempo, pero que ocasionalmente falla por alguna razón especial. Desafortunadamente, las pruebas fallidas son una realidad ineludible de las pruebas de interfaz de usuario. Si bien es importante investigar las causas principales, no es bueno bloquear una solicitud de incorporación de cambios basada en una sola prueba de IU que falló ocasionalmente. Por lo tanto, como usuario de una infraestructura de pruebas de interfaz de usuario, espero una sencilla e integrada. mecanismo de reintento estar disponible.tiempo y escalabilidadEl tiempo de ejecución del conjunto de pruebas es un factor crítico para cualquier infraestructura de prueba de IU. Para entender mejor esto, primero examinemos los elementos que afectan el tiempo de ejecución:Estos factores se pueden dividir en dos grupos: los que dependen de las pruebas del usuario y los que están relacionados con la infraestructura. Se pueden emplear varias estrategias para reducir el tiempo de ejecución de la prueba. Un enfoque común es centrarse en una funcionalidad específica dentro de una sola prueba, simulando el backend y evitando acciones repetitivas como iniciar sesión. En términos de infraestructura, el algoritmo de ejecución de la prueba juega un papel crucial en la determinación del tiempo requerido. Por ejemplo, considere una ejecución de prueba con una estrategia de apilamiento subóptima:Como alternativa, examine una ejecución de prueba con una política de reintento no óptima:En mi estudio reciente, que incluyó más de 30 entrevistas con diferentes equipos de desarrollo, descubrí que la mayoría de los equipos están dispuestos a esperar 15 minutos para ejecutar una prueba de IU en una solicitud de incorporación de cambios. Esto sugiere que incluso con numerosas pruebas de interfaz de usuario y de desarrollador, pruebas escritas de forma subóptima, ejecuciones de relaciones públicas simultáneas o pruebas fallidas, todas las relaciones públicas deben completarse dentro de ellas. ventana de 15 minutosSin embargo, es un escenario común que los tiempos de espera de PR pueden variar de 15 minutos a varias horas bajo cargas de infraestructura pesadas, lo que a menudo resulta en cancelaciones debido a tiempos de espera. Esto subraya la importancia de optimizar el sistema para manejar tales situaciones de manera eficiente. Es por eso que incluí «escalabilidad» en el título.SeguridadLa seguridad protege el entorno de prueba, los datos y la aplicación del acceso no autorizado, la manipulación o la actividad maliciosa. Algunos aspectos críticos de la seguridad en una infraestructura de prueba de la interfaz de usuario de Android incluyen:

• Autenticación y autorización: asegúrese de que solo los usuarios autorizados puedan acceder al entorno de prueba, los datos y los recursos.
• Privacidad: proteja la información confidencial, incluidos los datos de prueba y las credenciales de usuario, con cifrado en tránsito y en reposo. Implemente procedimientos apropiados de almacenamiento y eliminación de datos para evitar la fuga de datos.
• Seguridad de red: comunicaciones seguras entre equipos de prueba, servidores y otros componentes de infraestructura.

CostosMe gustaría destacar los dos aspectos principales:

• El modelo de tarificación y el uso de los recursos pagados. En general, existen los siguientes modelos de precios: Paga por un paralelo y paga por un minuto. Sin embargo, la sabia selección y aplicación del modelo de fijación de precios adecuado es un tema importante aparte.
• El segundo aspecto son los algoritmos internos y las soluciones de la infraestructura de pruebas de UI, que permiten gastar menos dinero para ejecutar el mismo conjunto de pruebas. Una de las posibles optimizaciones se describe anteriormente (mejor procesamiento por lotes y manejo de pruebas escamosas).

ApoyoEl último en esta lista, pero ciertamente no menos importante en términos de importancia, es el soporte. Muchos equipos priorizan no solo el servicio en sí, sino también la calidad del soporte brindado. Factores como la rapidez de respuesta, la amabilidad y el ahorro de tiempo para el equipo son muy valorados. Además, la priorización de funciones en función de las necesidades y preferencias del cliente mejora aún más la experiencia general de soporte. Las piezas de infraestructura de código abierto suelen ser muy valoradas por los clientes, ya que promueven la confianza en las soluciones proporcionadas y les permiten comprender mejor los mecanismos subyacentes. En este artículo, profundicé en el concepto de infraestructura de prueba de IU y discutí los criterios esenciales para seleccionar o construir dicha infraestructura. En los próximos artículos, me centraré en explorar el mercado de soluciones notables y trataré de estimar los costos potenciales involucrados en la implementación de un sistema interno.