En el presente documento se detalla los lineamientos actuales para realizar pruebas de performance en las mesas ágiles.

CONTROL DE VERSIONES DEL DOCUMENTO

Propósito

Las Pruebas de Performance o Pruebas de Rendimiento son pruebas no funcionales que nos permiten conocer la cantidad de clientes simultáneos que soporta un producto y medir la velocidad de respuesta en la ejecución de las tareas.”

1. Pruebas de Carga

Una prueba de carga es un tipo de prueba de rendimiento que verifica cómo funcionan los sistemas bajo una gran cantidad de usuarios virtuales simultáneos que realizan transacciones durante un cierto período de tiempo. El objetivo de las pruebas de carga es encontrar dónde están los cuellos de botella de rendimiento y garantizar la estabilidad y el buen funcionamiento del canal digital antes del evento.

2. Pruebas de Estrés

Una prueba de estrés es un tipo de prueba de rendimiento que está diseñada para evaluar la estabilidad y el rendimiento de una aplicación o sistema bajo condiciones extremas de uso o carga. El objetivo principal de estas pruebas es identificar los puntos débiles y los límites de rendimiento del sistema, asegurándose de que pueda manejar la carga prevista sin degradación significativa del rendimiento o fallas.

Lineamiento para solicitar pruebas de performance a nivel cloud:

Se tiene que tener en cuenta estos lineamientos para realizar una solicitud de pruebas de performance a nivel cloud.

Pre requisitos: Antes de hacer una solicitud de pruebas de performance se debe tener en cuenta estos pre requisitos:

¡IMPORTANTE!

Las pruebas de performance se realizarán una vez cerradas las pruebas funcionales.

* 1. Solicita pruebas de performance mediante correo: La solicitud de pruebas de performance, debe ser realizada mediante un correo por el LT o PO de la mesa, dirigido a Katherine Gamboa y Aron Carhuarica, teniendo en cuenta dos puntos importantes para la aprobación de la solicitud.

Checklist

*Proporcionar MS(Microservicio) del flujo a validar.

*Asignación de un recurso (QA).

• Una vez recibida la solicitud, se realizará el cumplimiento de los dos puntos mencionados en el checklist, en caso no se tenga la información completa o no se llegue a enviar lo solicitado en el correo, la solicitud será rechazada y tendrá que volver a mandar una nueva, subsanando las observaciones devueltas.

* 2. Generación de Epica de Testing: Cuando la solicitud haya sido aprobada, cumpliendo los inputs del checklist, se solicitará al equipo de Certificación que genere el FEAT para asociarlo a la epica de testing de la mesa que realiza la solicitud.

* 3. Aprobación para pruebas de performance: Una vez generada la épica y que haya sido asociado al FEAT de testing y se tenga todo el checklist aprobado y en orden, se puede dar inicio al flujo de pruebas de performance.

Flujo de pruebas de performance: Se detalla el proceso de las pruebas de performance:

1. El QA inicia el flujo con la creación de los scripts de pruebas automatizados, usando el lenguaje de Scala con Gatling, luego los cambios es subido a Bitbucket.
2. Una vez se suban los cambios, se realiza la ejecución a través del pipeline de Jenkins con el plugin de Gatling y este será ejecutado en el ambiente de pruebas de performance, Ambiente UAT 4.
3. Cuando la ejecución de las pruebas de performance haya finalizado, se tendrá los reportes en un (.zip) , esto aplica tanto para GDC y Tiolim.

IMPORTANTE: Generación del pipeline de Performance con GenCli

Si es la primera vez ejecutando pruebas de performance, la generación del pipeline solo se realiza por UNICA VEZ**, una vez generada ya no será necesario realizar la generación del pipeline en el Gencli.

Puede seguir el siguiente enlace de generación de pipeline: Generación Pipeline

Pasos:

1. Una vez ingrese al link [Generación Pipeline], seleccione la opción 'Build with Parameters'

2. En la siguiente pantalla, completar lo campos marcados de rojo, el primero será la selección del Tipo de proyecto, luego seleccionar la opción de Performance, en el siguiente input de Repositorio, se debe colocar la ruta del repositorio del proyecto git, finalmente se da click a la opción Ejecutar para generar el pipeline según el tipo de proyecto configurado.

   

   3. Cuando la ejecución haya finalizado, el pipeline se habrá generado en los ambientes de cert, dev y prod.

Tomar en cuenta: Se dará preferencia a todos los que pasen por el flujo ágil

• Continuando con el flujo, el LT / PO, solicita el informe del IPR(Informe de Pruebas de Rendimiento), para su HPA en su despliegue a Producción.
• Con el IPR se puede solicitar la configuración para HPA "Keda".

Tomar en cuenta: No imposibilita que haga las pruebas en caso de no tener un GDC

Puede seguir el siguiente enlace para configurar Keda:

autoescalamiento-keda

3. Arquitectura

Las pruebas de performance se detallan la siguiente arquitectura:

La arquitectura de pruebas de performance se ha dividido en dos fases: - Fase 1:

La primera fase implementada para pruebas de performance, consta de los siguientes puntos.

1. El QA inicia el flujo con la creación de los scripts de pruebas automatizados, usando el lenguaje de Scala con Gatling, luego los cambios es subido a Bitbucket.
2. Una vez se suban los cambios, se realiza la ejecución a través del pipeline de Jenkins con el plugin de Gatling y este será ejecutado en el ambiente de pruebas de performance, Ambiente UAT 4.
3. Cuando la ejecución de las pruebas de performance haya finalizado, se tendrá los reportes en un (.zip) , esto aplica tanto para GDC y Tiolim, en la cual se va guardar los reportes en un Blobstorage.
4. Con este reporte obtendremos el reporte de pruebas de performance que nos ofrece la herramienta de Gatling.

- Fase 2: La segunda fase será implementada a partir del SP3 del PI 16, en el cual tendrá los siguientes puntos.

1. Las métricas obtenidas se van a guardar en el ingestador de loki.
2. Con los datos obtenidos en el ingestador, se va generar un dashboard para mostrar las métricas detalladas.

Tomar en cuenta: Actualmente tenemos la arquitectura Onpremise, que ya está realizada y no se tocará, solo nos enfocaremos en AKS, que es la arquitectura que se va a construir.

4. Framework

El framework de pruebas de performance tiene la siguiente estructura:

• CFG: Contiene el archivo devops.properties, donde se pone la configuración de las ejecuciones en jenkins a través del pipeline.

• TEST: carpeta que contiene los test de prueba, los scripts automatizados y configuraciones de las pruebas de performance.

• Engine: funcionamiento interno de Gatling, ya que es responsable de la orquestación y ejecución de las pruebas. Sin embargo, como usuario de Gatling, no es necesario conocer o interactuar directamente con esta clase.

• IDEPathHelper: se utiliza para definir rutas predeterminadas para ciertos recursos importantes, como las carpetas donde se encuentran las simulaciones y los archivos de datos. También puede ayudar a establecer las ubicaciones para los informes de Gatling generados después de la ejecución de las pruebas. Es importante tener en cuenta que la clase IDEPathHelper se utiliza principalmente para fines de desarrollo en un entorno de IDE y no afecta la ejecución real de las pruebas en sí.

• TARGET: Es una carpeta de salida donde se generan los resultados y artefactos después de ejecutar las pruebas de carga y rendimiento. Es una carpeta importante y se crea automáticamente durante la ejecución de las pruebas.

• .gitignore: Es utilizado para especificar qué archivos y carpetas deben ser ignorados por el sistema de control de versiones Git.

• gatling.config: Es el archivo de configuración principal utilizado por Gatling. En este archivo se especifican diferentes opciones de configuración que afectan el comportamiento y la ejecución de las pruebas de carga y rendimiento realizadas con Gatling.

  Algunas de las opciones de configuración que se pueden encontrar en gatling.conf** incluyen:

  - **Configuración de la simulación:** Se pueden establecer valores predeterminados para ciertos parámetros de simulación, como el tiempo de espera, el número de usuarios virtuales, el tiempo de rampa, entre otros.
  
  - **Configuración del motor de ejecución**: Se pueden configurar aspectos relacionados con el motor de ejecución de Gatling, como el número de hebras del actor, el tiempo de espera máximo, etc.
  
  - **Configuración de registros:** Gatling permite configurar diferentes niveles de registro para sus registros internos, lo que facilita la depuración y el análisis.
  
  - **Configuración de informes:** Se pueden configurar opciones relacionadas con la generación y formato de los informes de Gatling, como el directorio de destino para los informes HTML generados.
  
  - **Configuración de proxies:** Si las pruebas de Gatling deben ejecutarse a través de un proxy, se pueden especificar las opciones de configuración para el proxy aquí.