Con este artículo, abrimos una serie de publicaciones sobre cómo automatizamos el proceso de prueba manual de un gran sistema de información en uno de los principales proyectos de LANIT y lo que surgió de él.

La primera parte, organizativa y administrativa, debería ser útil principalmente para aquellos que son responsables de probar la automatización y crear tales sistemas en su conjunto. Los gerentes de proyecto, los líderes de grupo y los propietarios de servicios de pruebas funcionales y automáticas, todos los que se preocupan por la pregunta "cómo construir una prueba rentable de extremo a extremo de su sistema de TI", encontrarán aquí un plan y una metodología específicos.

Fuente

Parte 1 - Organizacional y gerencial. ¿Por qué necesitamos automatización? Organización del proceso de desarrollo y gestión. Organización de uso

Inicialmente, al principio había un sistema de información grande y complejo (lo llamaremos el "Sistema") con numerosos escenarios de negocios complejos, largos e interconectados. Todos los scripts se probaron como E2E a través de interfaces web exclusivamente en modo manual (había más de mil quinientos de tales escenarios de la prioridad más crítica solamente). Además, todos estos escenarios tuvieron que completarse al menos una vez durante la regresión de cada nueva versión o revisión antes de la próxima actualización de implementación del producto.

En cierto momento, cuando se volvió completamente insoportable hacer clic con el mouse en modo manual, decidimos automatizarlo todo. Eso es lo que hicieron a través del desarrollo de un servicio separado basado en java + selenium + selenide + selenoid, que también se denomina "marco de prueba" o simplemente - "Autotests" .

Históricamente, el código del marco de prueba fue desarrollado por dos equipos. Primero, el primer equipo creó un prototipo con un par de docenas de escenarios. Luego, el segundo equipo durante un año escaló el prototipo tanto en amplitud (número de pruebas) como en profundidad (se introdujeron los patrones típicos de codificación e implementación).

Soy el equipo y el líder del equipo del segundo equipo, que adoptó el marco prototipo para escalar (en mayo de 2018).

En el momento de escribir este artículo, la tarea establecida hace un año se completó y el equipo del proyecto recibió un servicio de automatización estable. No fue en vano que enfatice el servicio , porque inicialmente la tarea no se estableció como desarrollar una aplicación, sino como proporcionar un servicio-servicio para la automatización de pruebas a un grupo de "pruebas funcionales". Y esta característica posteriormente influyó enormemente en la organización del desarrollo y la arquitectura del marco de prueba.

Resumen

Se automatizaron aproximadamente 1.500 escenarios de prueba: en cada prueba, de 200 a 2000 operaciones de usuario.

La capacidad total del servicio es de hasta 60 navegadores que funcionan simultáneamente, y este no es el límite (el número se puede aumentar en 5 veces debido a las máquinas virtuales).
La duración total de una regresión completa no es más de 3 horas, y la prueba PreQA es menos de una hora.

Se ha implementado una amplia gama de características:

• uso local (ejecución en tiempo real) y remoto (a través de planes Bamboo);
• limitar la composición de las pruebas de funcionamiento por filtro;
• un informe detallado con los resultados de cada paso del escenario de prueba (a través del marco Allure);
• descargar y cargar archivos desde / hacia el navegador, seguido de verificar los resultados de su procesamiento en términos del formato y contenido de los archivos;
• contabilidad y control de la naturaleza asincrónica de la interfaz angular. Incluyendo el control de solicitudes bloqueadas (solicitud pendiente) entre servicios angulares y REST;
• control de registros del navegador;
• grabación de prueba de video;
• eliminación de la instantánea de la página en el punto de "caída" de la prueba;
• transmisión de eventos en ELK;
• mucho más sobre las pequeñas cosas ...

¿Por qué se necesitaba todo esto?

Al principio, el propósito del sistema era bastante simple y claro.

Imagine que tiene un gran sistema de registro para administrar una amplia gama de documentos y su ciclo de vida, que proporcionan un par de cientos de procesos comerciales. Además, hay millones de personas, proveedores, decenas de miles, servicios, miles, documentos complejos, incluidos el marco y la plantilla, y la provisión de procesos comerciales se proporciona de cientos de maneras diferentes ...

Todo esto se convierte en mil escenarios de prueba, y esto es solo la más alta prioridad y solo positivo.

En el proceso de automatización, se revelaron varios matices que requerían el uso de varias soluciones.

Por ejemplo, una secuencia de comandos podría contener hasta cientos de operaciones separadas, incluidas aquellas interesantes como: "Descargue un archivo EXCEL con datos y verifique que el sistema procese cada registro del archivo" (para resolver este problema, tomó varios pasos para preparar los datos y luego verificar el resultado de cargarlo en Sistema). Y ahora agregamos la restricción de reutilización de datos de prueba: los datos de prueba para completar con éxito la mayoría de los escenarios de prueba deben ser "nuevos" y no haber sido utilizados previamente en escenarios similares (durante las pruebas, el estado de los datos en el Sistema cambia, como resultado de lo cual no se pueden reutilizar para los mismos controles)

Fuente

En algún momento, las pruebas manuales del Sistema como parte de la regresión dejaron de parecer rentables y lo suficientemente rápidas, y decidieron automatizarlo a través de la interfaz de usuario web.

En otras palabras, el grupo de prueba funcional abre la "página", selecciona el "grupo de prueba", presiona el botón "ejecutar" (utilizamos Bamboo). Luego, las Autopruebas (en lo sucesivo denominadas Autopruebas. Designe el producto creado para la prueba en general) emula automáticamente las acciones de los usuarios en el Sistema a través del navegador ("presione" los botones necesarios, ingrese los valores en los campos, etc.), al finalizar, muestre un informe detallado de todos pasos y acciones completadas y resultados de la verificación (correspondencia de la reacción esperada del Sistema a su comportamiento real).

Total, el propósito de Autotests es la automatización de las pruebas manuales E2E. Este es un sistema "externo" que no participa en el proceso de desarrollo del sistema bajo prueba y de ninguna manera está conectado con la unidad o las pruebas de integración utilizadas por los desarrolladores.

Objetivos

Era necesario reducir significativamente los costos de mano de obra para realizar las pruebas End-2-End y aumentar la velocidad de las regresiones completas y reducidas en términos de volumen.

Las tareas

La tarea principal del desarrollo se formuló de manera muy simple: automatizar en los próximos 6 meses 1000 escenarios de prueba de la más alta prioridad.

El número previsto de acciones de prueba básicas varió de 100 a 300, lo que nos dio alrededor de 200 mil métodos de prueba con 10-20 líneas de código, sin tener en cuenta las clases generales y auxiliares de ayudantes, proveedores de datos y modelos de datos.

Por lo tanto, resultó que, teniendo en cuenta las limitaciones de tiempo (130 días hábiles), era necesario hacer al menos 10 pruebas por día y al mismo tiempo garantizar la relevancia de las autoevaluaciones implementadas teniendo en cuenta los cambios que ocurren en el Sistema (el Sistema se está desarrollando activamente).

Según las estimaciones de los expertos, el trabajo requerido para desarrollar una prueba automática fue de 4 a 8 horas. Entonces obtuvimos un equipo de al menos 5 personas (en realidad, en el pico del desarrollo de las pruebas automáticas, el equipo tenía más de 10 ingenieros de automatización).

Las tareas que debían resolverse también eran comprensibles.

• Configurar procesos y comando:
• definir el proceso de interacción con el cliente (grupo de prueba funcional), corregir el formato de descripción del caso de prueba como entrada para el equipo de automatización;
• organizar el proceso de desarrollo y mantenimiento;
• formar un equipo
  
• Desarrolle autotests con las siguientes características:
• haga clic automáticamente en los botones del navegador con una comprobación preliminar de la presencia de elementos y la información necesaria en la página;
• proporcionar trabajo con elementos complejos como Yandex.Map;
• para garantizar la carga de archivos generados automáticamente en el Sistema, para garantizar la descarga de archivos del Sistema con la verificación de su formato y contenido.
• Proporcione un registro de las capturas de pantalla del navegador, videos y registros internos.
• Para proporcionar la capacidad de integrarse con sistemas externos como un servidor de correo, sistema de seguimiento de tareas (JIRA) para verificar los procesos de integración entre el sistema probado y los sistemas externos.
• Proporcione un informe documentado sobre todas las acciones tomadas, incluida una visualización de los valores ingresados ​​y verificados, así como todas las inversiones necesarias.
• Realice pruebas en el volumen requerido en modo paralelo.
• Implemente autotests en la infraestructura existente.
• Perfeccione los scripts de prueba ya automatizados del concepto de objetivo de consonante (velocidad de refinamiento: aproximadamente 50 pruebas por semana de sprint).

Como mencioné en la introducción, al principio teníamos un prototipo de MVP en funcionamiento implementado por otro equipo, que tuvo que incrementarse de 20 pruebas a 1000, agregando nuevas características en el camino y asegurando una escalabilidad y flexibilidad aceptables para realizar cambios.

La presencia de un prototipo funcional adicionalmente en la entrada nos dio una pila tecnológica, que incluía: Java SE8, JUnit4, Selenium + Selenide + Selenoid, Bamboo como un "corredor" de pruebas y un "generador" de informes Allure. Dado que el prototipo funcionó bien y proporcionó la funcionalidad básica necesaria, decidimos no cambiar la pila tecnológica, sino centrarnos en desarrollar la escalabilidad de la solución, aumentar la estabilidad y desarrollar las características requeridas faltantes.

Básicamente, todo parecía factible y optimista. Además, hicimos frente por completo a las tareas en un momento dado.

A continuación se describen los aspectos tecnológicos y de proceso individuales del desarrollo de AutoTests.

Descripción de las pruebas automáticas. Historias y características del usuario

Fuente

Las pruebas automáticas implementan el siguiente conjunto de historias de usuarios en el contexto de su uso por el grupo de prueba:

• automatización de prueba manual;
• regresión automática completa;
• control de calidad de ensamblajes en la cadena CI \ CD.

Los detalles de implementación y las decisiones arquitectónicas se discutirán en la Parte 2 - Técnico. Arquitectura y pila técnica. Detalles de implementación y sorpresas técnicas .

Pruebas automáticas y manuales (Historias de usuarios)

Como probador, quiero realizar la prueba E2E objetivo, que se realizará sin mi participación directa (en modo automático) y me proporcionará un informe detallado en el contexto de los pasos tomados, incluidos los datos ingresados ​​y los resultados obtenidos, así como:

• Debería ser posible seleccionar diferentes soportes objetivo antes de comenzar la prueba;
• debería poder gestionar la composición de las pruebas en ejecución de todas las implementadas;
• al final de la prueba, debe obtener un video de la prueba desde la pantalla del navegador;
• cuando la prueba falla, debe obtener una captura de pantalla de la ventana activa del navegador.

Regresión completa automática

Como grupo de prueba, quiero realizar todas las pruebas todas las noches en un banco de pruebas específico en modo automático, incluidas todas las características de "Prueba manual automática".

Control de calidad de ensamblaje en la cadena CI \ CD

Como grupo de prueba, quiero realizar pruebas automáticas de las actualizaciones implementadas del sistema en un soporte preQA dedicado antes de actualizar los soportes de la etapa de prueba funcional objetivo, que luego se utilizaron para las pruebas funcionales.

Funciones básicas implementadas

Fuente

Aquí hay un breve conjunto de las principales funciones implementadas de AutoTests, que resultaron ser vitales o simplemente útiles. Los detalles de la implementación de algunas funciones interesantes se encontrarán en la segunda parte del artículo.

Uso local y remoto

La función ofrecía dos opciones para ejecutar Autotests: local y remota.

En modo local, el probador realizó la prueba automática requerida en su lugar de trabajo y al mismo tiempo pudo observar lo que sucedía en el navegador. El lanzamiento se realizó a través del "triángulo verde" en IntelliJ IIDEA -). La función fue muy útil al inicio del proyecto para la depuración y las demostraciones, pero ahora solo la usan los desarrolladores de pruebas automáticas.

En modo remoto, el probador inicia la prueba automática utilizando la interfaz del plan Bamboo con los parámetros de la composición de las pruebas en ejecución, un soporte y algunos otros parámetros.

La función se implementó utilizando la variable de entorno MODE = REMOTE | LOCAL, según el cual se inicializó un navegador web local o remoto en la nube de Selenoid .

Limitar la composición de las pruebas en ejecución por filtro

La función permite limitar la composición de las pruebas en ejecución en modo de uso remoto para la comodidad de los usuarios y para reducir el tiempo de prueba. Se utiliza filtración en dos etapas. El primer paso bloquea la ejecución de pruebas basadas en la variable FILTER_BLOCK y se utiliza principalmente para excluir la ejecución de grandes grupos de pruebas. El segundo paso "omite" solo las pruebas que coinciden con la variable FILTER.

El valor de los filtros se especifica como un conjunto de expresiones regulares REGEXP1, ..., REGEXPN, aplicadas de acuerdo con el principio de "OR".

Al comenzar en modo manual, se le pidió al probador que estableciera una variable de entorno especial como una lista de expresiones regulares aplicables a la anotación especial @ Filter (valor de cadena), que anotó todos los métodos de prueba en las clases de prueba. Para cada prueba, esta anotación es única y se construye sobre la base de un conjunto de etiquetas separadas por un guión bajo. Utilizamos la siguiente plantilla mínima SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}, donde la etiqueta DEFAULT es para las pruebas incluidas en la regresión nocturna automática.

La función se implementa a través de una extensión personalizada de la clase org.junit.runners.BlockJUnit4ClassRunner (los detalles se darán en la Parte 2-1 de la continuación de este artículo)

Documentar el informe con los resultados de todos los pasos.

Los resultados de la prueba se muestran para todas las acciones de prueba (pasos) con toda la información requerida que está disponible en Allure Framework. Enumerarlos no tiene sentido. Hay suficiente información tanto en el sitio web oficial como en Internet en general. No hubo sorpresas al usar Allure Framework, y en general lo recomiendo para su uso.

Las principales funciones utilizadas son:

• visualización de cada paso de prueba (el nombre del paso corresponde a su nombre en la especificación de prueba - script de prueba);
• mostrar parámetros de paso en una forma legible por humanos (a través de la implementación requerida del método toString de todos los valores transmitidos);
• Adjuntar capturas de pantalla, videos y varios archivos adicionales al informe;
• clasificación de pruebas por tipos y subsistemas, así como la vinculación de la prueba automática con la especificación de prueba en el sistema de gestión de casos de prueba Test Link mediante el uso de anotaciones especializadas.

Descargue y cargue archivos desde / al navegador con su posterior verificación y análisis

Trabajar con archivos es un aspecto extremadamente importante de los scripts de prueba. Era necesario proporcionar tanto cargar varios archivos como descargar.

La descarga de archivos implicaba, en primer lugar, cargar archivos EXCEL generados dinámicamente en el Sistema de acuerdo con el contexto de la ejecución del script de prueba. La descarga se implementó utilizando métodos estándar proporcionados por las herramientas de selenio.

Cargar archivos implicaba descargar archivos presionando el "botón" en el navegador a un directorio local con la posterior "transferencia" de este archivo al servidor donde se ejecutaron los AutoTests (el servidor en el que se instaló el agente de Bamboo remoto). Además, este archivo se analizó y analizó en términos de formato y contenido. Los principales tipos de archivos fueron archivos EXCEL y PDF.

La implementación de esta función resultó ser una tarea no trivial, principalmente debido a la falta de capacidades estándar de manejo de archivos: en este momento, la función se implementa solo para el navegador Chrome a través de la página de servicio "chrome: // downloads /".

Te contaré en detalle sobre los detalles de implementación en la segunda parte.

Contabilidad y control de la naturaleza asincrónica de la interfaz angular. Control de solicitud pendiente entre servicios angulares y REST

Dado que el objeto de nuestras pruebas se basó en Angular, tuvimos que aprender a "luchar" con la naturaleza asincrónica de la interfaz y los tiempos de espera.

En general, además de org.openqa.selenium.support.ui.FluentWait, utilizamos un método de espera especialmente diseñado que verifica a través de Javascript las interacciones "incompletas" con los servicios REST front-end, y en función de este tiempo de espera dinámico, las pruebas obtienen información sobre si seguir entonces espera un poco más.

Desde el punto de vista de la funcionalidad, pudimos reducir significativamente el tiempo necesario para completar las pruebas debido al rechazo de las expectativas estáticas donde no hay forma de determinar de manera diferente la finalización de la operación. Además, esto nos permitió definir servicios REST "colgantes" con problemas de rendimiento. Por ejemplo, capturaron un servicio REST para el que el número de registros que se muestran en la página se estableció en 10,000 elementos.

La información sobre el servicio REST "congelado" con todos los parámetros de su llamada, debido a que la prueba "cae" debido a razones de infraestructura, se agrega a los resultados de la prueba descartada y también se transmite como un evento en ELK. Esto le permite transferir inmediatamente los problemas identificados a los equipos de desarrollo apropiados del Sistema.

Control de registro del navegador

La función de control de registro del navegador se agregó para controlar los errores en las páginas de nivel SEVERO para recibir información adicional para las pruebas descartadas, por ejemplo, para monitorear errores como "... Error al cargar el recurso: el servidor respondió con un estado de 500 (Error interno del servidor)".

La composición de los errores de procesamiento de la página en el navegador se aplica a cada resultado de la prueba y también se descarga como eventos en el ELK.

Grabación de video de la prueba y eliminación de la instantánea de la página en el punto de "caída" de la prueba

Las funciones se implementan para la conveniencia de diagnosticar y analizar pruebas descartadas.

La grabación de video se habilita por separado para el modo de ejecución de prueba remota seleccionado. El video se adjunta como un archivo adjunto a los resultados en el informe de Allure.
Se toma una captura de pantalla automáticamente cuando la prueba falla y los resultados también se aplican al informe de Allure.

Pasando eventos a ELK

La función de enviar eventos a ELK se implementa para permitir el análisis estadístico del comportamiento general de AutoTests y la estabilidad del objeto de prueba. Por el momento, se han enviado eventos para completar las pruebas con resultados y duración, así como errores del navegador de nivel GRAVE y servicios REST "congelados" fijos.

Organización de desarrollo

Fuente

Equipo de desarrollo

Entonces, necesitábamos al menos 5 desarrolladores. Agregue otra persona para compensar las ausencias no planificadas. Tenemos 6. Además de un líder de equipo, que es responsable de la funcionalidad transversal y la revisión del código.

Por lo tanto, fue necesario tomar 6 desarrolladores de Java (en realidad, en la cima del desarrollo de las pruebas automáticas, el equipo superó los 10 ingenieros de automatización).

Dado el estado general del mercado y una pila tecnológica bastante simple, el equipo estaba formado principalmente por pasantes, la mayoría de ellos recién graduados de las universidades o estaban en su último año. De hecho, estábamos buscando personas con un conocimiento básico de Java. Se dio preferencia a especialistas en pruebas manuales que quisieran convertirse en programadores, y a candidatos motivados con alguna (insignificante) experiencia de desarrollo, que en el futuro quisieran convertirse en programadores.

, ( 2 – . . ).

, , . CodeRush . .

. , , «» .

() . code review merge request ( GitLab). code review «» ( ) .

– . / , .

ode review , , () - , . ode review .

code review , .

: , , , , . , , , / .

« », - -. -.

, . sprint retrospective event.

- ( ) , stakeholder .

– . , , . , - . .

- ( , . .), . () , « » / « » ( , , ).

- - ( : - – , - , — , ). , - / : « - ( )».

- , - (-) - («» ). «» - - « X» ( , -).

, . master, -. - - code review.

, – , .

:

(+) ;
(+) ;
(+) «» ;
(-) ();
(-) hotfix .

.

• MASTER.
• .
• FEATURE .
• , « » rebase.
• Gitlab merge request . merge request- :
• — «Jira»;
• — Bamboo.

GateKeeper ( )

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

La segunda parte, la técnica, se centra principalmente en los líderes de los grupos de automatización UI pruebas de extremo a extremo y automatización de pruebas líder. Aquí encontrarán recetas específicas para la organización arquitectónica del código y la implementación, lo que respalda el desarrollo paralelo en masa de grandes grupos de pruebas frente a la variabilidad constante de las especificaciones de prueba. Además, puede encontrar en la segunda parte la lista completa de funciones necesarias para las pruebas de IU con algunos detalles de implementación. Y una lista de sorpresas que también puede encontrar.