Uno de los problemas que a menudo encuentran los proveedores de software multiproducto es la duplicación de las competencias de los ingenieros (desarrolladores, probadores y administradores de infraestructura) en casi todos los equipos. Esto también se aplica a los costosos ingenieros, expertos en el campo de las pruebas de carga.En lugar de comprometerse con sus responsabilidades directas y usar su experiencia única para construir el proceso de prueba de carga, eligiendo una metodología, métricas óptimas y escribiendo autoevaluaciones de acuerdo con los perfiles de carga, los ingenieros a menudo tienen que implementar infraestructura de prueba desde cero, configurar herramientas de carga e incorporarlas en sistemas CI, configure el monitoreo y la publicación de informes.Puede encontrar soluciones a algunos problemas de organización en las pruebas que utilizamos en Positive Technologies en otro artículo . Y en esto hablaré sobre la posibilidad de integrar pruebas de carga en una tubería común de CI utilizando el concepto de "prueba de carga como servicio". Aprenderá cómo y qué imágenes acoplables de fuentes de carga se pueden utilizar en la canalización de CI; Cómo conectar fuentes de carga a su proyecto de CI utilizando una plantilla de ensamblaje; cómo se ve una tubería de demostración para ejecutar pruebas de carga y publicar resultados. Este artículo puede ser útil para ingenieros de pruebas de software e ingenieros de automatización de CI que hayan pensado en la arquitectura de su sistema de carga.Esencia del concepto
El concepto de prueba de carga como un servicio implica la capacidad de integrar Apache JMeter, Yandex.Tank herramientas de carga y marcos propios en un sistema arbitrario de integración continua. Una demostración será para GitLab CI, pero los principios son comunes a todos los sistemas CI.La prueba de carga como servicio es un servicio centralizado para realizar pruebas de carga. Las pruebas de carga se ejecutan en grupos de agentes dedicados, los resultados se publican automáticamente en GitLab Pages, Influx DB y Grafana o en sistemas de informes de prueba (TestRail, ReportPortal, etc.). La automatización y el escalado se realizan de la manera más simple posible: agregando y parametrizando la plantilla gitlab-ci.yml habitual en el proyecto GitLab CI.La ventaja del enfoque es que toda la infraestructura de CI, los agentes de carga, las imágenes acopladas de las fuentes de carga, las tuberías de prueba y la publicación de informes son compatibles con el departamento de automatización central (ingenieros de DevOps), y los ingenieros de prueba de carga pueden centrar sus esfuerzos en el desarrollo de pruebas y análisis de sus resultados, sin tratar con problemas de infraestructura.Para simplificar la descripción, asumimos que la aplicación de prueba de destino o el servidor ya está implementado y configurado de antemano (para esto, se pueden usar scripts automatizados en Python, SaltStack, Ansible, etc.). Luego, todo el concepto de prueba de esfuerzo como servicio se ajusta a tres etapas: preparación, prueba, publicación de informes . Más detalles en el diagrama (se puede hacer clic en todas las imágenes):
Al realizar pruebas de estrés, tratamos de cumplir con los estándares y la metodología de ISTQB , utilizamos la terminología adecuada y las métricas recomendadas. Daré una breve lista de conceptos básicos y definiciones en pruebas de carga.Agente de carga (agente de carga) : la máquina virtual en la que se iniciará la aplicación, la fuente de la carga (Apache JMeter, Yandex.Tank o módulo de carga autoescrito).El propósito de la prueba (objetivo) es un servidor o aplicación instalada en el servidor que estará sujeta a carga.Caso de prueba (caso de prueba) : un conjunto de pasos parametrizados: acciones del usuario y reacciones esperadas a estas acciones, con solicitudes y respuestas de red fijas, según los parámetros especificados.Perfil o plan de carga (perfil) : en la metodología ISTQB (Sección 4.2.4, p. 43), los perfiles de carga determinan las métricas críticas para una prueba en particular y las opciones para cambiar los parámetros de carga durante la prueba. Puede ver ejemplos de perfiles en la figura. Test es un script con un conjunto predefinido de parámetros. Plan de prueba: conjunto de pruebas y perfil de carga. Testrun (testrun) : una iteración de ejecutar una prueba con un escenario de carga totalmente ejecutado y un informe recibido. Solicitud de red (solicitud) : una solicitud HTTP enviada desde el agente al destino. Respuesta de red (respuesta) : una respuesta HTTP enviada desde el destino al agente.
El estado de respuesta HTTP es un código de respuesta estándar del servidor de aplicaciones.Transacción (transacción): un ciclo completo de "solicitud - respuesta". Una transacción se cuenta desde el comienzo del envío de una solicitud (solicitud) hasta la finalización de recibir una respuesta (respuesta).Estado de la transacción (estado de las transacciones) : ¿fue posible completar con éxito el ciclo "solicitud-respuesta"? Si hubo algún error en este bucle, la transacción completa se considera infructuosa.Tiempo de respuesta (latencia) : tiempo desde el final del envío de una solicitud (solicitud) hasta el comienzo de recibir una respuesta (respuesta).Métricas de carga (métricas) : las características del servicio cargado y el agente de carga definidos durante el proceso de prueba de carga.Métricas básicas para medir parámetros de carga
Algunas de las métricas más comunes y recomendadas en la metodología ISTQB (p. 36, 52) se muestran en la tabla a continuación. Métricas similares para el agente y el objetivo se muestran en la misma línea.El esquema básico de las pruebas de carga es muy simple y consta de tres etapas principales, que ya mencioné: Preparar - Prueba - Informe , es decir, preparar objetivos de prueba y establecer parámetros para las fuentes de carga, luego realizar pruebas de carga y, finalmente, generar y publicar un informe Sobre las pruebas. Notas al esquema:
- QA.Tester - experto en pruebas de estrés,
- Target es la aplicación de destino para la que necesita conocer su comportamiento bajo carga.
Clasificador de entidades, etapas y pasos en el diagrama.
CI-
Pasemos a la parte práctica. Quiero mostrar cómo en algunos proyectos en Positive Technologies implementamos el concepto de prueba de carga como un servicio.Primero, con la ayuda de nuestros ingenieros de DevOps, creamos un grupo de agentes dedicado en GitLab CI para ejecutar pruebas de carga. Para no confundirlos en plantillas con otros, como grupos de ensamblaje, agregamos etiquetas a estos agentes, etiquetas : carga. Puede usar cualquier otra etiqueta clara. Se establecen durante el registro de GitLab CI Runners.¿Cómo averiguar la potencia requerida por hardware? Las características de los agentes de carga (una cantidad suficiente de vCPU, RAM y disco) se pueden calcular sobre la base de que Docker, Python (para Yandex.Tank), el agente GitLab CI, Java (para Apache JMeter) deben ejecutarse en el agente. Para Java con JMeter, también se recomienda que use un mínimo de 512 MB de RAM y, como límite superior, el 80% de la memoria disponible .Por lo tanto, según nuestra experiencia, recomendamos utilizar al menos 4 vCPU, 4 GB de RAM, 60 GB de SSD para agentes de carga. El ancho de banda de la tarjeta de red se determina en función de los requisitos del perfil de carga.Utilizamos principalmente dos fuentes de carga: imágenes acoplables Apache JMeter y Yandex.Tank.Yandex.Tank- Esta es la herramienta de código abierto de Yandex para pruebas de estrés. Su arquitectura modular se basa en el generador de solicitud HTTP asíncrono asíncrono de alto rendimiento Phantom. El tanque tiene monitoreo incorporado de los recursos del servidor probado utilizando el protocolo SSH, puede detener automáticamente la prueba de acuerdo con las condiciones dadas, puede enviar los resultados tanto a la consola como en forma de gráficos, puede conectar sus módulos a ella para ampliar la funcionalidad. Por cierto, usamos Tank cuando aún no era convencional. En el artículo " Yandex.Tank and Automation of Load Testing ", puede leer la historia de cómo, en 2013, lo usamos para realizar pruebas de carga de PT Appllication Firewall , uno de los productos de nuestra empresa.Apache JMeterEs una herramienta de código abierto para realizar pruebas de estrés de Apache. Se puede usar igualmente bien para probar aplicaciones web estáticas y dinámicas. JMeter admite una gran cantidad de protocolos y formas de interactuar con aplicaciones: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), servicios web SOAP / REST, FTP, TCP, LDAP, SMTP (S), POP3 (S ) e IMAP (S), bases de datos a través de JDBC, pueden ejecutar comandos de shell y trabajar con objetos Java. JMeter tiene un IDE para crear, depurar y ejecutar planes de prueba. También hay una CLI para trabajar en la línea de comandos de cualquier sistema operativo Java compatible (Linux, Windows, Mac OS X). La herramienta puede generar dinámicamente un informe de prueba HTML.Para facilitar el uso dentro de nuestra empresa, para la capacidad de los evaluadores de cambiar y agregar el entorno, creamos imágenes acoplables de fuentes de carga en GitLab CI con publicación en el registro interno de acopladores en Artifactory . De esta forma resulta más rápido y fácil conectarlos en tuberías para pruebas de carga. Cómo hacer que Docker presione el registro a través de GitLab CI: consulte las instrucciones .El archivo base docker para Yandex.Tank tomamos esto:Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]
Y para Apache JMeter este:Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]
Puede leer cómo funciona nuestro sistema de integración continua en el artículo " Automatización de procesos de desarrollo: cómo implementamos ideas de DevOps en tecnologías positivas ".Plantilla y tubería
Una plantilla de ejemplo para realizar pruebas de carga está disponible en el proyecto de carga de demostración . Puede leer las instrucciones para usar la plantilla en el archivo Léame . En la plantilla misma (el archivo .gitlab-ci.yml ) hay notas sobre de qué es responsable este o aquel paso.La plantilla es muy simple y muestra las tres etapas de prueba de carga descritas anteriormente en el diagrama: preparación, prueba y publicación de informes. Responsable del directorio de etapas : la preparación, la prueba y el informe .- Prepare . , - docker registry: Test. .
- Test , . : Yandex.Tank, Apache JMeter, . job-. :
: CI- . , bash-. , — QA-. . ./tests.
- Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .
, :
:
En un ejemplo de demostración, una tubería con pruebas de carga y dos fuentes de carga (puede deshabilitar innecesariamente) se ve así: Apache JMeter puede generar un informe HTML por sí mismo, por lo que es más rentable guardarlo en las páginas de GitLab usando herramientas regulares. Así es como se ve el informe Apache JMeter: en la demostración de Yandex.Tank, verá solo un informe de texto falso en la sección de páginas de GitLab. Durante las pruebas, Tank puede guardar los resultados en la base de datos InfluxDB, y desde allí se pueden mostrar, por ejemplo, en Grafana (la configuración se realiza en el archivo ./tests/example-yandextank-test.yml ). Así es como se ve el informe de Tank en Grafana:
Resumen
En el artículo hablé sobre el concepto de "prueba de carga como servicio" (prueba de carga como servicio). La idea principal es utilizar la infraestructura de grupos preconfigurados de agentes de carga, imágenes acopladas de fuentes de carga, sistemas de informes y una tubería que los une en GitLab CI basado en una plantilla simple .gitlab-ci.yml (ejemplo por referencia ). Todo esto es respaldado por un pequeño equipo de ingenieros de automatización y se replica a pedido de los equipos de productos. Espero que esto le ayude a preparar e implementar un esquema similar en su empresa. ¡Gracias por su atención!PD: Quiero agradecerles a mis colegas, Sergey Kurbanov y Nikolay Yusev, por su asistencia técnica con la implementación del concepto de prueba de carga como un servicio en nuestra empresa.Autor :Timur Gilmullin - diputado. Jefe de Tecnología y Procesos de Desarrollo (DevOps), Tecnologías Positivas