Uno de los problemas que a menudo enfrentan los proveedores de software de múltiples productos es la duplicación de las competencias de los ingenieros (desarrolladores, evaluadores y administradores de infraestructura) en casi todos los equipos. Esto también se aplica a los ingenieros costosos, especialistas en el campo de las pruebas de carga.
En lugar de realizar sus tareas directas y utilizar su experiencia única para crear un proceso de prueba de carga, elegir una metodología, métricas óptimas y escribir pruebas automáticas de acuerdo con los perfiles de carga, los ingenieros a menudo tienen que implementar una infraestructura de prueba desde cero, configurar herramientas de carga e integrarlas. mismos en los sistemas de CI, configurar el seguimiento y la publicación de informes.
Puede encontrar soluciones a algunos problemas organizativos en las pruebas que utilizamos en Positive Technologies en . Y en este, 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" (load testing as a service). Aprenderá cómo y qué imágenes acoplables de fuentes de carga se pueden usar en la canalización de CI; cómo conectar fuentes de carga a su proyecto de CI usando una plantilla de compilación; cómo se ve la canalización de demostración para ejecutar pruebas de carga y publicar los resultados. El artículo puede ser útil para ingenieros de pruebas de software e ingenieros de automatización en CI que estén pensando en la arquitectura de su sistema de carga.
La esencia del concepto
El concepto de prueba de carga como servicio implica la capacidad de integrar las herramientas de carga Apache JMeter, Yandex.Tank y sus propios marcos en un sistema arbitrario de integración continua. La demostración será para GitLab CI, pero los principios son comunes a todos los sistemas de CI.
La prueba de carga como servicio es un servicio centralizado para la prueba 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 implementan de la forma más sencilla posible, agregando y parametrizando la plantilla habitual gitlab-ci.yml en el proyecto GitLab CI.
La ventaja de este enfoque es que toda la infraestructura de CI, los agentes de carga, las imágenes acoplables de las fuentes de carga, las canalizaciones de prueba y los informes de publicación son mantenidos por un departamento de automatización centralizado (ingenieros de DevOps), mientras que los ingenieros de pruebas de carga pueden centrar sus esfuerzos en el desarrollo de pruebas. y análisis de sus resultados, sin tratar temas de infraestructura.
Para simplificar la descripción, supondremos que la aplicación de destino o el servidor bajo prueba ya se ha implementado y configurado de antemano (para esto se pueden usar scripts automatizados en Python, SaltStack, Ansible, etc.). Entonces, todo el concepto de prueba de carga como servicio se ajusta a tres etapas: preparación, ensayo, publicación de informes. Más detalles en el diagrama (se puede hacer clic en todas las imágenes):
Conceptos básicos y definiciones en pruebas de carga
Cuando llevamos a cabo pruebas de carga, tratamos de adherirnos a , use la terminología adecuada y las métricas recomendadas. Daré una breve lista de los principales conceptos y definiciones en las pruebas de carga.
agente de carga - una máquina virtual en la que se iniciará la aplicación - la fuente de carga (Apache JMeter, Yandex.Tank o un módulo de carga autoescrito).
Objetivo de prueba (objetivo) - servidor o aplicación instalada en el servidor que será objeto de carga.
Escenario 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 (Sección 4.2.4, p. 43) Los perfiles de carga definen métricas que son críticas para una prueba en particular y opciones para cambiar los parámetros de carga durante la prueba. Puede ver ejemplos de perfiles en la figura.
Prueba — un escenario con un conjunto predeterminado de parámetros.
Plan de prueba (plan de prueba) - un conjunto de pruebas y un perfil de carga.
Testran (ejecución de prueba) - una iteración de ejecutar una prueba con un escenario de carga totalmente ejecutado y el informe recibido.
Solicitud de red (solicitud) — Una solicitud HTTP enviada desde un agente a un destino.
Respuesta de red (respuesta) — Una respuesta HTTP enviada desde el objetivo al agente.
Código de respuesta HTTP (estado de respuestas HTTP): código de respuesta estándar del servidor de aplicaciones.
Una transacción es un ciclo completo de solicitud-respuesta. Una transacción se cuenta desde el inicio del envío de una solicitud (solicitud) hasta la finalización de la recepción de una respuesta (respuesta).
Estado de la transacción - si fue posible completar con éxito el ciclo de solicitud-respuesta. Si hubo algún error en este ciclo, toda la transacción se considera fallida.
Tiempo de respuesta (latencia) - el tiempo desde el final del envío de una solicitud (solicitud) hasta el comienzo de la recepción de una respuesta (respuesta).
Cargar métricas — las características del servicio cargado y el agente de carga determinado en el proceso de prueba de carga.
Métricas básicas para medir parámetros de carga
Algunas de las más utilizadas y recomendadas en la metodología (p. 36, 52) las métricas se muestran en la siguiente tabla. Las métricas similares para el agente y el objetivo se enumeran en la misma línea.
Métricas para el agente de carga
Métricas del sistema de destino o aplicación que se está probando bajo carga
número CPU virtual y memoria RAM,
Disco - características de "hierro" del agente de carga
CPU, Memoria, uso de disco - dinámica de carga de CPU, memoria y disco
en proceso de prueba. Normalmente se mide como un porcentaje de
valores máximos disponibles
rendimiento de la red (agente en carga) - rendimiento
interfaz de red en el servidor,
donde está instalado el agente de carga.
Normalmente se mide en bytes por segundo (bps)
rendimiento de la red(en el objetivo) - ancho de banda de la interfaz de red
en el servidor de destino. Normalmente se mide en bytes por segundo (bps)
Usuarios virtuales- el número de usuarios virtuales,
implementar escenarios de carga y
imitando las acciones reales del usuario
Estado de los usuarios virtuales, Aprobado/Fallado/Total — número de aciertos y
estados fallidos de usuarios virtuales
para escenarios de carga, así como su número total.
En general, se espera que todos los usuarios hayan podido completar
todas sus tareas especificadas en el perfil de carga.
Cualquier error significará que un usuario real no podrá
resolver su problema al trabajar con el sistema
Solicitudes por segundo (minuto)- el número de solicitudes de red por segundo (o minuto).
Una característica importante de un agente de carga es cuántas solicitudes puede generar.
De hecho, se trata de una imitación del acceso a la aplicación por parte de usuarios virtuales.
Respuestas por segundo (minuto)
- el número de respuestas de la red por segundo (o minuto).
Una característica importante del servicio de destino: cuánto
generar y enviar respuestas a consultas con
agente de carga
Estado de respuesta HTTP— número de códigos de respuesta diferentes
del servidor de aplicaciones recibido por el agente de carga.
Por ejemplo, 200 OK significa una llamada exitosa,
y 404 - que no se encontró el recurso
Estado latente (tiempo de respuesta) - tiempo desde el final
enviar una solicitud (solicitud) antes de comenzar a recibir una respuesta (respuesta).
Normalmente se mide en milisegundos (ms)
Tiempo de respuesta de la transacción— tiempo de una transacción completa,
completar el ciclo de solicitud-respuesta.
Este es el tiempo desde el inicio del envío de la solicitud (solicitud)
hasta completar la recepción de una respuesta (response).
El tiempo de transacción se puede medir en segundos (o minutos)
de varias maneras: considerar el mínimo,
máxima, media y, por ejemplo, el percentil 90.
Las lecturas mínima y máxima son extremas.
estado de rendimiento del sistema.
El percentil noventa es el más utilizado,
como muestra la mayoría de los usuarios,
operar cómodamente en el umbral del rendimiento del sistema
Transacciones por segundo (minuto) - el número de completo
transacciones por segundo (minuto),
es decir, cuánto la aplicación fue capaz de aceptar y
procesar solicitudes y emitir respuestas.
De hecho, este es el rendimiento del sistema.
Estado de la transacción , Pasado / Fallido / Total - número
exitosas, fallidas y el número total de transacciones.
Para usuarios reales sin éxito
la transacción realmente significará
incapacidad para trabajar con el sistema bajo carga
Diagrama esquemático de prueba de carga
El concepto de prueba de carga es muy simple y consta de tres etapas principales, que ya he mencionado: Preparar informe de prueba, es decir, preparar objetivos de prueba y establecer parámetros para fuentes de carga, luego ejecutar pruebas de carga y, al final, generar y publicar un informe de prueba.
Notas esquemáticas:
- QA.Tester es experto en pruebas de carga,
- Target es la aplicación de destino para la que desea conocer su comportamiento bajo carga.
Clasificador de entidades, etapas y pasos en el diagrama
Etapas y pasos
Que pasa
que hay en la entrada
cual es la salida
Preparar: etapa de preparación para la prueba
Parámetros de carga
Configuración e inicialización
usuario
cargar parámetros,
selección de métricas y
preparación del plan de prueba
(cargar perfil)
Opciones personalizadas para
inicialización del agente de carga
Plan de prueba
Propósito de la prueba
VM
Implementación en la nube
máquina virtual con
caracteristicas requeridas
Configuración de máquina virtual para el agente de carga
Scripts de automatización para
creación de máquinas virtuales
VM configurada en
la nube
Env
Configuración y preparación del sistema operativo
medio ambiente para
trabajo del agente de carga
Configuración del entorno para
agente de carga
Scripts de automatización para
configuración del entorno
Ambiente preparado:
SO, servicios y aplicaciones,
necesario para el trabajo
agente de carga
Agentes de carga
Instalación, configuración y parametrización
agente de carga.
O descargando una imagen acoplable desde
fuente de carga preconfigurada
Imagen de ventana acoplable de origen de carga
(YAT, JM o framework autoescrito)
Ajustes
agente de carga
Configurado y listo
al agente de carga de trabajo
Prueba: etapa de ejecución de pruebas de carga. Las fuentes son agentes de carga implementados en grupos de agentes dedicados para GitLab CI
Carga
Inicio del agente de carga
con plan de prueba seleccionado
y cargar parámetros
opciones de usuario
para inicialización
agente de carga
Plan de prueba
Propósito de la prueba
Registros de ejecución
pruebas de carga
Registros del sistema
Dinámica de cambios en métricas de objetivos y agente de carga
Ejecutar agentes
Ejecución del agente
un montón de guiones de prueba
de acuerdo con
cargar perfil
Interacción del agente de carga
con el propósito de probar
Plan de prueba
Propósito de la prueba
Troncos
Recopilación de registros "en bruto"
durante la prueba de carga:
registros de actividad del agente de carga,
estado del objetivo de prueba
y la máquina virtual que ejecuta el agente
Registros de ejecución
pruebas de carga
Registros del sistema
Métrica
Recopilación de métricas "sin procesar" durante las pruebas
Dinámica de cambios en las métricas de objetivos
y agente de carga
Informe: etapa de preparación del informe de prueba
Generador
Procesamiento recogido
sistema de carga y
sistema de monitoreo "en bruto"
métricas y registros
Formación de un informe en
forma legible por humanos
posible con elementos
analistas
Registros de ejecución
pruebas de carga
Registros del sistema
Dinámica de cambios en las métricas
destino y agente de carga
Registros "en bruto" procesados
en un formato adecuado para
cargas al almacenamiento externo
informe de carga estática,
legible por humanos
Publicar
Publicación del informe
sobre la carga
prueba en externo
servicio
Procesado "en bruto"
registros en un formato adecuado
para descarga a exterior
repositorios
Guardado en externo
informes de almacenamiento en
cargar, ajustar
para el análisis humano
Conexión de orígenes de carga en una plantilla de CI
Pasemos a la parte práctica. Quiero mostrar cómo en algunos proyectos en la empresa. hemos implementado el concepto de pruebas de carga como un servicio.
Primero, con la ayuda de nuestros ingenieros de DevOps, creamos un grupo dedicado de agentes en GitLab CI para ejecutar pruebas de carga. Para no confundirlos en plantillas con otros, como pools de ensamblaje, agregamos etiquetas a estos agentes, : carga. Puede utilizar cualquier otra etiqueta comprensible. Ellos preguntan Corredores de GitLab CI.
¿Cómo saber la potencia requerida por hardware? Las características de los agentes de carga (una cantidad suficiente de vCPU, RAM y disco) se pueden calcular en función del hecho de que Docker, Python (para Yandex.Tank), el agente GitLab CI, Java (para Apache JMeter) deben estar ejecutándose en el agente. . Para Java bajo JMeter, también se recomienda utilizar un mínimo de 512 MB de RAM y, como límite superior, .
Por lo tanto, según nuestra experiencia, recomendamos usar al menos 4 vCPU, 4 GB de RAM, 60 GB de SSD para agentes de carga. El rendimiento 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.
es una herramienta de código abierto de Yandex para pruebas de carga. Su arquitectura modular se basa en el generador de solicitudes HTTP asíncrono de alto rendimiento basado en visitas de Phantom. El tanque tiene un monitoreo incorporado de los recursos del servidor bajo prueba a través del protocolo SSH, puede detener automáticamente la prueba bajo condiciones específicas, puede mostrar los resultados tanto en la consola como en forma de gráficos, puede conectar sus módulos para ampliar la funcionalidad. Por cierto, usamos el Tank cuando aún no era convencional. En el artículo "» puede leer la historia de cómo realizamos pruebas de carga con él en 2013 es uno de los productos de nuestra empresa.
es una herramienta de prueba de carga de código abierto de Apache. Se puede usar igualmente bien para probar aplicaciones web tanto estáticas como dinámicas. JMeter admite una gran cantidad de protocolos y formas de interactuar con las 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 la operación de línea de comandos en cualquier sistema operativo compatible con Java (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 interna. . Esto hace que sea más rápido y fácil conectarlos en canalizaciones para pruebas de carga. Cómo hacer docker push al registro a través de GitLab CI - ver .
Tomamos este archivo docker básico para Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Y para Apache JMeter este:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Puedes leer cómo funciona nuestro sistema de integración continua en el artículo "".
Plantilla y canalización
Un ejemplo de una plantilla para realizar pruebas de carga está disponible en el proyecto . En Puede leer las instrucciones para usar la plantilla. En la propia plantilla (archivo ) hay notas sobre de qué es responsable cada paso.
La plantilla es muy simple y demuestra las tres etapas de las pruebas de carga descritas en el diagrama anterior: preparación, prueba y publicación de informes. responsable de esto : Preparar, probar e informar.
- Etapa debe utilizarse para preconfigurar objetivos de prueba o comprobar su disponibilidad. No es necesario configurar el entorno para las fuentes de carga, están preconstruidas como imágenes de la ventana acoplable y se publican en el registro de la ventana acoplable: solo especifique la versión deseada en la etapa de prueba. Pero puedes reconstruirlos y hacer tus propias imágenes modificadas.
- Etapa se utiliza para especificar el origen de carga, ejecutar pruebas y almacenar artefactos de prueba. Puede elegir cualquier fuente de carga: Yandex.Tank, Apache JMeter, la suya propia o todas juntas. Para deshabilitar fuentes innecesarias, simplemente comente o elimine el trabajo. Puntos de entrada para fuentes de carga:
- Los parámetros de lanzamiento de Yandex.Tank se especifican en el archivo .,
- Los parámetros de inicio de Apache JMeter se especifican en el archivo .
Nota: La plantilla de configuración de ensamblaje se usa para configurar la interacción con el sistema CI y no implica la colocación de lógica de prueba en él. Para las pruebas, se especifica el punto de entrada, donde se encuentra el script bash de control. Los ingenieros de control de calidad deben implementar el método de ejecución de pruebas, la generación de informes y los propios scripts de prueba. En la demostración, para ambas fuentes de carga, la solicitud de la página principal de Yandex se usa como la prueba más simple. Los scripts y los parámetros de prueba están en el directorio. .
- En el escenario debe describir cómo publicar los resultados de la prueba obtenidos en la etapa de prueba en almacenamientos externos, por ejemplo, en páginas de GitLab o sistemas de informes especiales. GitLab Pages requiere que el directorio ./public no esté vacío y contenga al menos un archivo index.html después de que hayan finalizado las pruebas. Puede leer sobre los matices del servicio Páginas de GitLab. .
Ejemplos de cómo exportar datos:
- de JMeter a ,
- de Yandex. Tanque a .
Instrucciones de configuración de publicación:
- HTML estático en ,
- a InfluxDB y luego a .
En el ejemplo de demostración, la tubería con pruebas de carga y dos fuentes de carga (puede deshabilitar la innecesaria) se ve así:
Apache JMeter puede generar un informe HTML por sí mismo, por lo que es más rentable guardarlo en GitLab Pages utilizando herramientas estándar. Así es como se ve el informe de Apache JMeter:
En el ejemplo de demostración de Yandex.Tank, solo verá en la sección de Páginas de GitLab. Durante la prueba, el tanque 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 ). Así se ve el reporte de Tank en Grafana:
Resumen
En el artículo, hablé sobre el concepto de "prueba de carga como servicio" (load testing as a service). La idea principal es usar la infraestructura de grupos preconfigurados de agentes de carga, imágenes acoplables de fuentes de carga, sistemas de informes y una tubería que los combina en GitLab CI basado en una plantilla .gitlab-ci.yml simple (ejemplo ). Todo esto está respaldado por un pequeño equipo de ingenieros de automatización y replicado a pedido de los equipos de producto. Espero que esto le ayude a preparar e implementar un esquema similar en su empresa. ¡Gracias por su atención!
PD: Quiero dar las gracias a mis colegas, Sergey Kurbanov y Nikolai Yusev, por la asistencia técnica con la implementación del concepto de prueba de carga como servicio en nuestra empresa.
autor: - Diputado Jefe de Tecnología y Procesos de Desarrollo (DevOps) en Positive Technologies
Fuente: habr.com