Cómo arreglar el selenio en su canalización de CI / CD

¿Cómo optimiza Selenium en su canalización de CI/CD? Aquí, descubrimos cómo puede modificar la canalización de CI/CD para resolver automáticamente los problemas de prueba de Selenium causados ​​por CI/CD.

Ejecutar pruebas automatizadas de forma continua puede parecer una obviedad. Un sistema de CI es clave, ya que proporciona a los equipos de desarrollo ágiles una visibilidad rápida del estado de sus aplicaciones. Si las pruebas automatizadas están pasando, entonces la aplicación está en buen estado. Si las pruebas fallan, entonces la aplicación está rota de alguna manera. ¿O es eso?

La desafortunada realidad es que las pruebas automatizadas no siempre nos brindan tanta confianza, especialmente cuando se ejecutan pruebas de Selenium. Las pruebas de Selenium pueden fallar por muchas razones diferentes, independientemente de si la aplicación está rota de alguna manera o si cambió. Estos problemas están muy bien detallados en una publicación de blog anterior. Aquí, explicaré cómo modificar la canalización de CI / CD para solucionar automáticamente esos problemas, mejorando la confianza en los resultados de las pruebas del sistema de CI.

Dolor de selenio CI

CI / CD amplifica los problemas de prueba de selenio. Veamos cómo sucede esto. Primero, el desarrollo aterriza algunos cambios en el código. El sistema CI detecta el cambio y activa la canalización de compilación. Los módulos se compilan, las pruebas unitarias se ejecutan y pasan (¡yay!), Y luego la aplicación se empaqueta para su implementación. La canalización de implementación se activa a continuación, poniendo en escena un entorno de prueba, implementando la aplicación bajo prueba y luego inicia las pruebas de integración, muchas de las cuales están escritas con Selenium. No todas las pruebas de Selenium pasan, momento en el que el sistema CI notifica a varias personas de las fallas de la prueba por correo electrónico. Esas personas responden, a veces gastando una cantidad significativa de tiempo investigando y solucionando problemas. Los propietarios de productos, gerentes y otras partes interesadas también ven las fallas en sus paneles de control que desvían su atención de otras cosas. Sabiendo que las pruebas de selenio en sí mismas son inestables, ¿cómo puede alguien tener la confianza de que CI / CD reportó una regresión o defecto real? ¿Cuánto tiempo se pierde solucionando problemas de falsos positivos?

La simple mejora de las pruebas de Selenium puede no ser trivial, a veces implica prueba y error, especialmente cuando los problemas son intermitentes o difíciles de reproducir. De una construcción a otra hay fallas que pueden moverse, donde no hay una única prueba a la que culpar. Pueden ser problemas sistémicos o ambientales que van y vienen. El sistema CI puede utilizar ejecutores VM o basados ​​en la nube que tienen características de rendimiento inconsistentes. Las pruebas se ejecutan y pasan a las estaciones de trabajo de los desarrolladores, pero fallan en la automatización de CI. ¿Suena familiar?

Selenio CI resuelto

Parasoft Selénic Se desarrolló para ayudar a combatir estos desafíos. Selenic automatiza el análisis y la corrección de los problemas de las pruebas de Selenium, proporcionando soluciones o información sobre dichos problemas, y publica los hallazgos cuando el sistema de CI notifica a los usuarios. La carga se traslada al sistema de CI, alejándose de los usuarios que reaccionan a las notificaciones. Con solo dos sencillos pasos, puede automatizar el proceso de corrección de las pruebas de Selenium como parte del flujo de trabajo de CI/CD utilizando Edición esencial de Parasoft Selenic.

Inyectar el agente selenico

Para integrar Parasoft Selenic, se realiza un cambio de una sola línea en el script de ejecución de pruebas existente. Supongamos que tengo un paso de ejecución de Maven en la canalización que gestiona mis pruebas de Selenium basadas en Java. Normalmente, se especifican dos objetivos de Maven, "clean" y "test", que se pasan como argumentos de línea de comandos a Maven. En este caso, simplemente se añade un argumento adicional de línea de comandos de Maven:

-DargLine = -javaagent: $ {SELENIC_HOME} /selenic_agent.jar=selfHealing=true,sessionId = $ {BUILD_TAG}

En Jenkins CI, esto podría verse así:

El Agente Selenic ahora se inyecta en el proceso de ejecución de pruebas, siempre que Selenic esté instalado y tenga licencia en la ubicación indicada por la variable "SELENIC_HOME". El Agente Selenic puede realizar varias funciones, pero para estabilizar las pruebas, solo habilito la función de "autocuración", que intenta identificar y solucionar problemas de pruebas de Selenic sobre la marcha.

Un aspecto a considerar cuidadosamente es si todas las pruebas de Selenium residen en un solo módulo o si existen pruebas en varios módulos. Es común que las pruebas se dividan en varios módulos por motivos de organización. Para que Selenium agregue información de varios módulos de prueba, se debe configurar el argumento "sessionId". En el ejemplo anterior, utilizo "BUILD_TAG", una variable predefinida en el sistema de integración continua (CI) de Jenkins que funciona bien para este propósito. Independientemente del sistema de integración continua (CI) que utilice, le recomiendo crear un identificador de sesión único utilizando las variables proporcionadas por su sistema de CI.

Después de realizar este cambio de una línea, Selenic identifica y corrige automáticamente los problemas de estabilidad de la prueba, lo que brinda a todos mucha más confianza en los resultados de las pruebas publicados por el sistema CI. Sin embargo, hay un componente más de Selenic que recomiendo integrar.

Ejecute el analizador selenico

¿Cómo sabemos qué problemas encontró Selenic o qué corrigió? ¿Debo hacer cambios en las pruebas de selenio para evitar los tipos de problemas que encuentra Selenic? Para obtener esta información, debe ejecutar Selenic Analyzer como otro paso de ejecución en la canalización. Este es un segundo cambio de una línea, pero aún es trivial:

java -jar $ SELENIC_HOME / selenic_analyzer.jar -report target / selenic-reports -sessionId $ {BUILD_TAG}

En Jenkins CI, esto podría verse así:

El Analizador Selenic recopila la información registrada previamente por el Agente Selenic, realiza análisis adicionales de los datos y genera informes que el sistema de CI puede archivar. De forma predeterminada, el analizador procesa la información de la sesión más reciente, pero para mayor robustez, recomiendo configurar explícitamente el argumento "-sessionId" con el mismo valor que se usó anteriormente al configurar el Agente Selenic.

Selenic Analyzer escribe los informes en el directorio de trabajo actual por defecto. Sin embargo, para facilitar el archivado de los informes, debe agregar el argumento "-report" para indicar a Selenic que los escriba en la carpeta "selenic-reports" del directorio de salida de la compilación de su proyecto. Después de esto, debe agregar un paso más en la secuencia de comandos para archivar "target/selenic-reports/**":

Los archivos de informes ahora están disponibles para todos a través del sistema de CI. En el caso de Jenkins CI, se puede acceder cómodamente a los informes en URL estables:

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.html

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.json

La primera URL apunta al informe HTML de Selenic que se puede ver directamente en un navegador web. La segunda URL es el informe JSON que los desarrolladores pueden proporcionar al complemento Selenic IDE para importar las recomendaciones de la última ejecución de prueba automatizada.

Otras Consideraciones

Selenic tiene muchas otras opciones que puede considerar habilitar según su entorno de prueba y otras necesidades específicas.

Selenic registra datos de cada sesión de prueba. Estos datos actúan como base de conocimiento, lo que permite a Selenic aprender y tomar mejores decisiones y recomendaciones de autorreparación con el tiempo. De forma predeterminada, estos datos se almacenan en la máquina donde se ejecuta la prueba. Por lo tanto, si tiene un grupo de ejecutores, querrá que estos datos se encuentren en una carpeta compartida accesible para todos ellos. La ubicación de los datos se puede configurar explícitamente pasando el parámetro "data={path}" al Agente de Selenic y el argumento "-data {path}" al Analizador de Selenic, donde "{path}" sería la ruta del sistema de archivos a una carpeta compartida. En Windows, podría ser una ruta UNC como \HostNameSharedFolder. Los datos grabados se acumularán indefinidamente a menos que se restrinjan. Esto puede provocar un alto uso del disco. Se puede configurar un límite en el número de sesiones de prueba grabadas pasando el parámetro "maxSessionDaysToKeep={num_days}" al Agente de Selenic. "{num_days}" representa el número de días en que se registraron los datos, no los días naturales. En otras palabras, Selenic no contabiliza los días en que no se registraron datos de la sesión de prueba. Esto es útil si ejecuta las pruebas con poca frecuencia, a intervalos irregulares o si el servidor se cayó y no pudo ejecutar las pruebas durante algunos días.

Selenic también puede configurarse para capturar información de diagnóstico adicional con distintos niveles de granularidad. Por ejemplo, puede configurarse para capturar capturas de pantalla de cada acción de Selenium o solo de las acciones fallidas. Para habilitar las capturas de pantalla de las fallas de prueba, puede pasar el parámetro "screenshot=failures" al agente de Selenic. Las capturas de pantalla de las fallas están disponibles en el informe HTML generado por el analizador de Selenic.

CI/CD + Selenic = ❤

Parasoft Selenic se creó para acelerar el desarrollo ágil con Selenium como parte de CI/CD. Desarrolladores y testers pueden ser más productivos, dedicando menos tiempo a buscar "fantasmas" de Selenium y más tiempo a trabajar en cosas reales. Aumente la confianza en los resultados de sus pruebas de Selenium con Selenic.