Tendencias de automatización de pruebas de Android en 2022 | de Eugene Matsyuk | noviembre 2022

¡Hola a todos! Mi nombre es Eugene y me encantan las pruebas automatizadas. También soy uno de los coautores de Kaspresso, una biblioteca de código abierto para escribir pruebas automatizadas para aplicaciones de Android, autor de varios artículos y conferencias sobre pruebas (Kaspresso: The Autotest Framework You’ve Been Looking Forward to. Part I , Autotests en Android. La imagen completa, Cómo empezar a escribir autotests y no volverse loco). Mi amigo Sergei Iartsev (CTO de HintEd) también se enamoró de las pruebas automatizadas; En su trabajo, se ocupa diariamente de la automatización de pruebas para diferentes plataformas. En mi artículo Autotests en Android. El panorama general, esbocé 5 partes principales:

• escribir pruebas,
• corredor de pruebas,
• donde hacer las pruebas
• infraestructura
• otras cosas, incluidos los informes de prueba, la integración de CI/CD, etc.

Hace unos años (2019-2020) nos cansamos mucho de escribir pruebas automatizadas, así que desarrollamos Kaspresso. Ahora los desarrolladores y evaluadores pueden olvidarse de problemas como la irregularidad, los registros, el rendimiento, etc. y concentrarse en escribir pruebas con un DSL agradable y simple. Sin embargo, los equipos de desarrollo todavía tienen problemas en otras áreas relacionadas con la automatización de pruebas, como la infraestructura, donde hay que adentrarse en el mundo mágico de DevOps, o incluso hacer highload. Recientemente nos interesó cómo se ven las pruebas automatizadas en diferentes equipos. Para averiguarlo, Sergei y yo entrevistamos a más de 30 equipos diferentes. El número 30 puede parecer una gota en el océano, pero aún es más que 1, 2 o 5, por lo que creemos que nuestra investigación es lo suficientemente relevante. Entonces, ¿qué equipos hemos tenido el placer de entrevistar? Muchos de ellos trabajan para empresas con sede en Rusia, mientras que varios equipos provienen de empresas europeas, estadounidenses y australianas: Spotify, Revolut, Badoo, Auto.ru, Sber, HeadHunter y otras. Todos escriben pruebas de interfaz de usuario de una forma u otra, y el número de esas pruebas varía ampliamente:Otro punto al que prestamos especial atención fue el cumplimiento de la pirámide de prueba. Solo un recordatorio rápido de que en una pirámide de prueba saludable, las pruebas unitarias constituyen aproximadamente el 80 % del conjunto de pruebas general, mientras que las pruebas E2E (o pruebas de interfaz de usuario) se mantienen en un modesto 5 %.El 75% de nuestros encuestados siguen este concepto por completo o con pequeñas desviaciones. Algo salió mal para el otro 25%: el número de pruebas E2E es mayor que el de pruebas unitarias. Pero ciertamente no revelaremos ningún nombre; ese es nuestro pequeño secreto. 🙂 Nuestra siguiente pregunta fue sobre la primera fase cuando se inician las pruebas de IU. Tenga en cuenta que es posible que estas no sean todas las pruebas, sino un conjunto específico o una selección basada en un análisis de impacto. Algunas pruebas pueden usar datos simulados. La imagen es la siguiente:Más de la mitad de nuestros encuestados inician sus pruebas de interfaz de usuario en solicitudes de extracción y otra cuarta parte lo hace en compilaciones nocturnas regulares. Es evidente que la práctica de solo probar antes del lanzamiento es cosa del pasado. También es importante tener en cuenta que más de la mitad de nuestros encuestados utilizan datos falsos en sus pruebas. La experiencia muestra que sin usar simulacros es bastante imposible estabilizar las pruebas, especialmente en PR. ¿Cuál es el tiempo promedio de prueba en un PR? Veamos el gráfico a continuación:Continuamos encontrándonos con la declaración de que los desarrolladores no están dispuestos a esperar más de 15 minutos para obtener los resultados de la ejecución de la prueba. De lo contrario, cambian a otra tarea y el PR actual se congela. Desafortunadamente, no tenemos ninguna investigación en nuestras manos para probar este punto. Pero si llevamos esta afirmación más allá, muchos equipos aún tienen margen de mejora. La escalabilidad de la infraestructura es fundamental. Es importante mencionar que el tiempo de otras ejecuciones de prueba (construcción nocturna, posterior a la fusión) no es tan crítico y puede demorar hasta 2 o 3 horas. Ya que estamos en el tema de la escalabilidad, eche un vistazo a otro gráfico que muestra cuántas pruebas lanzan nuestros encuestados en paralelo:Aproximadamente la mitad no usa más de 5 emuladores. Casi todos los encuestados que comienzan las pruebas en 1 subproceso no tienen ejecuciones de prueba para relaciones públicas. La razón es clara: es una cuestión de infraestructura. Luego preguntamos a los equipos sobre las tecnologías que utilizan para la automatización de pruebas (aquí nuestros participantes podían elegir varias opciones):Como muestran los resultados de la encuesta, un conjunto de herramientas estándar para la automatización de pruebas de Android incluye Kaspresso (¡que casi obtuvo el primer lugar!) + Marathon + Allure. Espresso y UI Automator también son muy populares, lo que puede explicarse por la necesidad de personalizar la herramienta según las necesidades y la existencia de algunas soluciones personalizadas basadas en estas herramientas nativas. ¿Qué pasa con la infraestructura? Los resultados aquí son bastante interesantes:Casi la mitad de nuestros encuestados solo usan una computadora local. Local Service también se encuentra entre los proveedores líderes (un conjunto de servidores orquestados por Kubernetes o similar), así como Firebase TestLab. Otros equipos usan AWS, Google Cloud, OpenSTF, agentes de compilación, etc. El siguiente es el proceso de trabajo, es decir, quién es responsable de la «redacción y mantenimiento de pruebas» y la «infraestructura de prueba»:Tenga en cuenta que escribir pruebas ya no es prerrogativa del control de calidad o de un equipo de automatización separado: este enfoque está claramente desactualizado. Los desarrolladores participan activamente en la redacción de pruebas de interfaz de usuario porque las pruebas garantizan la calidad, que también es su responsabilidad. Este proceso colaborativo de redacción de pruebas ayuda a los desarrolladores y evaluadores a lograr mejores resultados al compartir la responsabilidad por la calidad del producto. A su vez, los problemas relacionados con la infraestructura se delegan principalmente a un equipo de DevOps o un equipo de plataforma móvil. Una de nuestras últimas preguntas fue sobre las herramientas que los equipos quieren usar para mejorar sus pruebas automatizadas (rendimiento, habilidades, conveniencia, etc.). A continuación se muestra su lista, ordenada por popularidad:

• Prueba de puerta de validez. Se realiza una nueva prueba 5-10 veces, a veces más, con el objetivo de confirmar su estabilidad. Si no hay descamación, la prueba se incluye en un conjunto de pruebas.
• Análisis de impacto. Este análisis nos ayuda a no ejecutar todas las pruebas en una suite, solo aquellas afectadas por cambios en el código.
• Simulacro de red/proxy. Simulación y representación de solicitudes de red para la aplicación o todo el dispositivo de prueba, incluidos problemas como la grabación correcta de simulacros y su actualización. Aquí debemos mencionar herramientas como MockWebServer, MitmProxy, Charles, etc.
• Diferencia de captura de pantalla La diferencia visual entre una prueba exitosa y una fallida. Inmediatamente muestra la diferencia en la interfaz de usuario.
• Imágenes calientes de Docker. Imágenes de Docker «calentadas» de emuladores. Esto permite un ahorro de tiempo significativo al principio. Por cierto, una aplicación también se puede «calentar» (por ejemplo, se puede autorizar al usuario, etc.).
• Un énfasis en escribir pruebas unitarias que solo verifican una parte de la funcionalidad y no el escenario de prueba completo, evitando pasar constantemente por la autorización, la pantalla de inicio, etc.

En esta parte del artículo, Sergei y yo daremos nuestra opinión sobre cómo ha cambiado la situación en las pruebas de Android en comparación con 2020. Estas son nuestras conclusiones personales basadas en los datos que hemos recopilado. De ninguna manera es un estudio completo, pero sin duda podemos destacar algunos puntos interesantes.El proceso de escribir pruebas automatizadas.El 90% de los equipos que encuestamos usan pruebas nativas. Sin embargo, no podemos negar que existe una tendencia hacia un mayor uso de pruebas nativas en comparación con las soluciones multiplataforma. Los equipos que recién comienzan a escribir pruebas automatizadas están muy entusiasmados con Kaspresso, ya que les ahorra muchas molestias. Esta es una opinión absolutamente honesta y sin prejuicios de nuestra parte :). También hay equipos que ya han invertido muchos recursos en sus soluciones de automatización de pruebas existentes basadas en Espresso y UI Automator. En última instancia, continúan trabajando para mejorar la solución existente o cambian gradualmente a otras opciones como Kaspresso mientras mantienen algunas de sus pruebas existentes de Espresso y UI Automator.Corredores de prueba e informesLas soluciones nativas como AndroidJUnitRunner y Orchestrator siguen siendo populares. Pero si anhelas algo mejor, «un instrumento para gobernarlos a todos», entonces no busques más allá de Marathon. Es un corredor de pruebas de rápido desarrollo, el único inconveniente es que no cubre la parte de la infraestructura de ninguna manera, a diferencia de, por ejemplo, Flank, que puede funcionar con Firebase TestLab (aunque no funciona con otras herramientas similares). ). Cuando se trata de reseñas, la mayoría de nuestros encuestados de habla rusa prefieren Allure. Para ser honesto, no parece haber una mejor solución en el mercado hoy en día.infraestructuraLos equipos que han estado en el negocio durante mucho tiempo han logrado crear sistemas personalizados en sus servidores que organizan y mantienen de forma independiente. Pero por lo demás, la situación con la infraestructura sigue siendo bastante frustrante. Actualmente no existe en el mercado una solución simple, flexible y escalable. Esto explica por qué el 23% de los encuestados realizan sus pruebas en una sola computadora local. Por supuesto, siempre existe Firebase TestLab, pero solo funciona bien para una pequeña cantidad de pruebas relativamente simples. A medida que aumenta la cantidad de pruebas, inevitablemente desea informes confiables, pruebas paralelas listas para usar, ver el historial y el análisis de la ejecución de pruebas, personalizar las imágenes de Docker (por ejemplo, configurar proxies) y más. Todo esto lo tienes que configurar tú mismo de alguna manera. Hemos oído hablar de una herramienta llamada emulator.wtf, pero aún no conocemos ningún caso de su uso exitoso. Otra herramienta nueva es TestWise, cuyo equipo Sergei ahora está asesorando. En el próximo artículo planeamos comparar todos los servicios anteriores.Proceso de automatización de pruebas.La opinión predominante solía ser que las pruebas automatizadas eran responsabilidad exclusiva de un equipo de automatización de pruebas. Este paradigma funcionó durante un tiempo, pero inicialmente condujo a problemas como la falta de sincronización entre la aplicación y sus pruebas, el cambio de responsabilidad, etc. Ahora estamos viendo un cambio fundamental en la mentalidad hacia la idea de que las pruebas automatizadas son una parte integral de una aplicación y una parte necesaria de su calidad. Los desarrolladores participan mucho más activamente en el proceso de automatización de pruebas y las pruebas se llevan a cabo lo más rápido posible, es decir, en PR. Además, para mejorar la estabilidad de las pruebas, es importante simular el backend, lo que definitivamente requiere el apoyo activo de los desarrolladores. Lanzar pruebas en PR hace que sea mucho más fácil ver la razón de su falla, ya que el alcance de los cambios es bastante limitado. Parece que es hora de decir adiós. ¡Gracias por leer este artículo! No dude en escribir sus preguntas y pensamientos en los comentarios a continuación; Esperamos contar con su presencia. ¡Muchas gracias a Christina Rozenkova por su ayuda con la traducción!