Get best of the week

¿Por qué nos cambiamos a Selenide escribiendo más de 200 nuevas pruebas automáticas en el camino?

Hola, soy una herramienta de automatización de pruebas para uno de los proyectos de una gran empresa. En este artículo, explicaré por qué decidimos cambiar de Serenity a Selenide. Tenemos una tarea a gran escala, y aunque cambiar la pila tecnológica tomó algo de tiempo, más tarde se compensó al acelerar la escritura de pruebas y realizar regresiones.

imagen

Antes de llegar al punto, un poco sobre la tarea en su conjunto.

Desafortunadamente, no puedo revelar los detalles del proyecto bajo los términos de la NDA. De hecho, estas son algunas herramientas para un centro de llamadas de una gran empresa: enrutamiento de llamadas, separación de operadores según temas de llamadas, etc. en una hermosa interfaz de usuario. La interfaz, por cierto, se proporciona no solo para operadores, sino también para controladores que escuchan y evalúan llamadas seleccionadas. Por encima de todo esto, hay un sistema de diferenciación de derechos y un panel de administración que le permite configurar todas las funciones integradas, desde telefonía hasta clasificaciones disponibles para los controladores.

Todo el volumen de funcionalidad se divide en varios proyectos: telefonía, panel de usuario y panel de administración. Los tres proyectos están en desarrollo activo. Y mi tarea es automatizar las pruebas en estos proyectos en el sentido amplio de la palabra.

Para algunas de las funcionalidades desarrolladas, las pruebas automáticas ya existían, pero el especialista que las desarrolló dejó la empresa, por lo que parecía existir un cierto deber técnico para automatizar las pruebas. En total, se escribieron alrededor de 50 autotests, pero la gran mayoría de ellos están completamente desactualizados, porque La funcionalidad ha avanzado mucho. Por lo tanto, inicialmente la tarea era actualizar todo esto.

Actualización de pila


Las pruebas automáticas existentes se escribieron utilizando la biblioteca Serenity. De hecho, tuvieron que reescribirse nuevamente, por lo que no tenía sentido retener los desarrollos existentes. La biblioteca en sí me era familiar, pero personalmente, no la considero una herramienta óptima. Entonces, entendiendo la cantidad de trabajo, decidí cambiar a Selenide desde el principio.

Selenide es una herramienta bastante popular para la cual hay muchas soluciones preparadas. Algunas de las características de Selenide también están disponibles para análogos: Atlas, Selenium, HTMLElements, etc. Pero cada uno de ellos a su manera no nos convenía.

El selenio es la base de selenio. Pero para nuestros propósitos es un nivel demasiado bajo. No tiene sentido reinventar la rueda cuando hay una solución preparada.

Atlas apareció recientemente. Es lo suficientemente crudo y no tiene soporte Groovy.
HtmlElements es bueno para todos, pero está en desuso y no es compatible. También hay JDI, pero tiene problemas de subprocesos múltiples.

Serenity, utilizada anteriormente en el proyecto, era demasiado engorrosa. Todo está tan interconectado que para agregar un nuevo controlador de eventos o interceptor, se tuvo que reescribir una docena de clases (y esto no condujo al éxito cada vez). Además, Surenity no pudo conectar a Allure, el estándar industrial y corporativo real para generar informes de prueba.

En Selenide, desde el punto de vista de la automatización, todo es mucho más simple. Por ejemplo, no es necesario describir por separado los pasos: adjuntar a métodos, etc. Como tiene soporte Allure listo para usar, todas las acciones relacionadas con el trabajo con elementos web se incluyen automáticamente en el informe de prueba.

Por supuesto, Selenide tiene soporte para PageFactory, Page Object y PageElement. Esto hace que el código sea más legible. Además, existen expectativas internas para el momento en que aparece el elemento: no es necesario indicar explícitamente que debe detener la prueba durante unos segundos antes de continuar (el límite de tiempo de espera se establece en las configuraciones). Las expectativas explícitas existen por separado: puede redefinir explícitamente el tiempo de espera para los elementos necesarios en cada paso de la prueba.

Convenientemente, Selenide tiene un conjunto completo de varios métodos listos para usar.

Dado que al comienzo de la transición de Serenity a Selenide, estaba solo en el equipo, la ventaja adicional era que ya tenía suficiente experiencia con Selenide y Groovy, por lo que pude implementar rápidamente soluciones preparadas y, posteriormente, dedicar menos esfuerzo para apoyarlas.

La transición fue casi indolora. Hemos implementado Selenide junto con Allure. Allure le permite crear informes legibles e incluso algo hermosos, que muestran claramente qué pasos se cayeron y con qué error. Fuera de la caja, puede adjuntar capturas de pantalla de páginas web a los informes. Incluso agregamos un video de la ejecución, el código fuente de la página, los registros del navegador y el controlador web.

La migración de las pruebas existentes requirió un mínimo de esfuerzo. Lo que tiene Serenity, lo que tiene Selenide son PageObjects con anotaciones @FindBy. Serenity y Allure usan las mismas anotaciones de paso. Tuve que actualizar el modelo, el anidamiento de elementos entre sí, el orden de invocar los pasos de prueba. Algunas pruebas se eliminaron por completo, algunas se reescribieron desde cero y bastaba con actualizar los localizadores. De hecho, mudarse se ha convertido en una tarea trivial a la que se enfrentan la mayoría de los automatizadores de UI al diseñar una aplicación web.

Actualización de prueba


Después de actualizar la pila tecnológica, tomaron las pruebas ellos mismos. Por cierto, parte de este trabajo ya se ha completado como parte de la transición a una nueva pila.

Dado el retraso acumulado detrás de la funcionalidad de los proyectos, aún tendrían que reescribirse de todos modos; esto es más rentable en el tiempo que buscar inconsistencias en tal volumen de código.

En total, se han escrito alrededor de 220 autotests en este momento tanto para el front-end como para el back-end. El énfasis en el desarrollo posterior estará en el backend, ya que la mayoría de los elementos funcionales en el front end ya están involucrados en las pruebas automáticas. Al mismo tiempo, está cambiando constantemente, por lo que mientras más pruebas aparezcan en el front-end, más fuerzas se deben gastar en su apoyo.

Teniendo recursos de tiempo infinito, siempre tratamos de dirigir los esfuerzos a lo que nos permitirá reducir los costos laborales para el soporte, cubriendo la funcionalidad tanto como sea posible. Ahora la cobertura de las pruebas automáticas superó ligeramente el 50%.


Las pruebas reescritas en Selenide se han vuelto más compactas y precisas debido a la reutilización repetida del código, todo gracias a las capacidades de la propia biblioteca.

Actualizando las pruebas, tomamos en cuenta que deben ejecutarse simultáneamente (en varios hilos). Las pruebas se ejecutaron previamente en máquinas virtuales separadas. Pero la transición a Selenide nos permitió paralelizar la tarea aún más, ejecutándolas en varios hilos.

En términos generales, la transición a un nuevo marco en sí mismo aumentó el número de subprocesos lanzados simultáneamente de 3 a 8, y la posterior optimización de las pruebas, hasta 50. Como resultado, 100 pruebas de IU se ejecutan en solo 10 minutos.


Multithreading, por cierto, es otra ventaja para la que elegimos Selenide. Esta no es una gran capa de repetitivo, usted escribe un mínimo de código. No hay escritos superfluos que Selenium necesite para preparar el proyecto para su lanzamiento. Todo lo que necesita para ejecutar las pruebas ya está listo para usar.

Paralelamente a la actualización y redacción de nuevas pruebas, realicé capacitación para los chicos del departamento de pruebas, ayudándolos a cambiar de pruebas manuales a pruebas completas, por lo que llegó al regimiento de automatización del proyecto. La pila de tecnología utilizada tiene un umbral de entrada más bajo, e Internet está llena de documentación y videos sobre cómo resolver ciertos problemas. Un mes después, un par de probadores se unieron a mí para realizar tareas relacionadas con la automatización.

Ya todo un equipo, pudimos optimizar las pruebas de regresión. Si antes la regresión tomó 7 días del equipo, ahora se realizan las mismas tareas durante 4 días, es decir, Redujimos el tiempo de las pruebas en casi 2 veces.

Hay muchos escenarios por delante que aún no se han automatizado. Automatizamos las pruebas de humo casi por completo, pero ahora hemos cambiado a los escenarios de prueba más laboriosos. Esto ayudará a reducir aún más los tiempos de recurso.

Naturalmente, desarrollaremos una infraestructura de prueba. Planea introducir un servidor simulado. Ahora estamos probando todo en un soporte real, generando datos de prueba. Se necesita tiempo y recursos. El servidor simulado le permitirá ejecutar pruebas automáticas sin esta preparación preliminar (escribimos sobre el servidor simulado para otro proyecto ).

También planeamos implementar un registro de prueba automática para que pueda escribir un script TestRail basado en una pieza de trabajo obtenida haciendo clic directamente en la interfaz en el navegador. En la salida, obtenemos una especie de prototipo de autotest.

Autor del artículo: Yuri Kudryavtsev, Especialista en pruebas automatizadas de software.

PD: publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas en VK , FB , Instagram o en el canal Telegram para conocer todas nuestras publicaciones y otras noticias de Maxilect.

More articles:


All Articles