El objetivo de las pruebas de estrés es identificar posibles fallos o mal funcionamiento de los sistemas en situaciones de carga y uso concurrente de una aplicación.

Este documento establece el alcance de las pruebas de estrés realizadas para un cliente de SIPSA y presenta un resumen de los principales hallazgos identificados durante las pruebas.

Toda organización debería considerar las pruebas de rendimiento como una parte integral de su proceso de prueba. Si una empresa no prueba continuamente el rendimiento de sus aplicaciones, software o API, corre el riesgo de que esos productos se bloqueen y, por extensión, la empresa puede aplastarse y quemarse, especialmente dado el clima económico actual, con las empresas que necesitan hacer frente a la demanda adicional online.

La frase «pruebas de rendimiento» lo dice todo: realiza un seguimiento de cómo se está comportando su producto y cómo está funcionando. Esto es importante si tiene muchos o pocos clientes.

Si solo tiene unos pocos clientes, ¿puede permitirse dejar de realizar las pruebas de carga? posiblemente, pero esa no es realmente una buena opción o de hecho una positiva, ¿verdad? ¿Qué pasa si uno de esos valiosos clientes, que no puede permitirse perder, aumenta repentinamente su uso?

Este no será el único cliente en fallar, todos sus clientes fallarán. La realidad es que su negocio es demasiado importante para no realizar pruebas de carga. No importa lo que prediga para el tráfico y las tasas de uso, este debe ser un caso de preparación para el peor de los casos mientras espera el mejor resultado.

Las pruebas de carga y las pruebas de rendimiento deben verse como una extensión de su servicio al cliente y el diseño del producto, ya que deben llevarse a cabo desde la etapa embrionaria de su producto; ayudan a determinar la viabilidad, la necesidad y a generar un rendimiento confiable en el diseño y la estructura. del sistema hasta que alcance el final de la vida útil del producto y sea necesario reemplazarlo.

Es de vital importancia que automatice las pruebas durante su ciclo de vida, para asegurar la calidad de su código, que pueda adaptarse y evolucionar, que sus recursos puedan ajustarse para cumplir con las demandas del cliente y del servidor, ya sea que se contraigan o se expandan.

Es ampliamente aceptado que no importa cuán rica en funciones pueda ser una aplicación si los usuarios perciben su desempeño como pobre, los niveles de rechazo serán altos. Podría deberse a que se bloquea o sufre retrasos en la carga. Cualquier aplicación debe ofrecer un rendimiento aceptable incluso cuando resista cargas de uso pico con caídas en el ancho de banda de la red y en condiciones menos que óptimas.

Beneficios que ofrece TAST como Herramienta de prueba de carga.

  1. Aseguramiento de la calidad de los sistemas productivos.
  2. Eficiencia. La única forma de ejecutar pruebas de carga es a través de la Automatización, de lo contrario tendría que coordinar el trabajo de muchos testers y eso es inviable si no se hace automáticamente. Todas las herramientas que hacen pruebas de carga lo hacen automáticamente, pero logramos eficiencia con TAST. TAST es la herramienta para definir pruebas funcionales y de sistema y por extensión es posible utilizar todas estas pruebas en situaciones de carga.
  3. Las pruebas de carga con TAST se realizan de forma distribuida. Esto evita problemas de seguridad al atacar los sistemas desde diferentes IPs.
  4. La prueba de carga automatizada es rápida. Con TAST podemos aplicar slots de prueba de carga periódica y continua, alineados con las modificaciones funcionales, ya que reutilizamos los esquemas de prueba ya creados en fases anteriores (pruebas de integración, funcionales y de aceptación).

Prueba de Carga con TAST: Caso de éxito.

La ejecución de la prueba se lleva a cabo en diferentes intervalos de tiempo en función de dos escenarios diferentes:
* Pruebas concurrentes: Ejecución de la navegación Front-End accediendo al mismo tiempo por varios usuarios.

* Prueba de esfuerzo: prueba de esfuerzo basada en la inyección de carga API ajustando el infra utilizado a la cantidad de carga inyectada.

Esta prueba se realizó en 3 niveles para revisar el comportamiento del sistema en situaciones de carga solo con navegación y carga en situaciones de procesamiento de datos entre sistemas internos. Organizamos los niveles por el tipo de carga generada en todo el sistema, no solo en el front-end.

Nivel 1: Navegación 100%.
Nivel 2: 90% navegación 10% registro y procesamiento de datos.
Nivel 3: 50% navegación 50% registro y procesamiento de datos.

A partir de estas ejecuciones, el capítulo de resultados presenta hallazgos y tiempos de respuesta para mostrar claramente los casos en los que el sistema no se comportó como se esperaba, pero también los tiempos de respuesta del sistema para las diferentes llamadas, en ambos casos: solicitud “buscar / leer” y “guardar / escritura ”solicitud.

Los resultados se clasifican de dos formas:

* Fallos: detección de errores. La gravedad de estos hallazgos es alta.
* Incremento de Tiempos de Respuesta: comparando los tiempos observados en el Stress test con los tiempos de carga estándar. En este caso, la gravedad de estos hallazgos se considera media o baja, debido a que el sistema se comporta como se esperaba.

La ejecución del Stress test se ha realizado utilizando dos herramientas principales:

* TAST (Test Automation System Tool): herramienta que se utiliza para ejecutar automáticamente casos de prueba del sistema de extremo a extremo.
* AI (Application Insights): herramienta utilizada para monitorear el comportamiento de la infraestructura, así como para medir los tiempos de respuesta y depurar el registro de solicitudes de falla entre sistemas.

Durante la sesión de 5 horas cargando y estresando el sistema utilizando los escenarios y niveles de carga anteriores se observaron los siguientes comportamientos:

* Frond End Gateway tuvo un rendimiento no lineal y detectó el límite en la dimensión de infraestructura.
* Core System, el entorno de preproducción no ha alcanzado ninguna falla de infraestructura, pero la observación del aumento del tiempo de respuesta creció más allá del tiempo de espera del sistema externo.
* Interfaz con un sistema de middleware, detección del límite de solicitud realizada a 4 por minuto de media.

Los resultados de la prueba de carga y estrés requirieron las siguientes acciones:

  • Corrección de problemas de alta gravedad:
  1. F1: La petición a la base de datos no funciona correctamente cuando hay acceso concurrente.
  2. F2: Tiempo de espera de la API para cargar la primera página del front-end.
  • Analizar los recursos de infraestructura considerando la carga esperada en el entorno de producción.
  • Análisis y dimensionamiento de carga en el entorno de producción para evitar los hallazgos con severidad media y baja, siguiendo los siguientes consejos:
  1. Escalar la implementación horizontalmente para aumentar la cantidad de POD que admiten tanto el front end gateway como el core system.
  2. Incrementar el umbral del timeout de respuesta del sistema para evitar el rechazo de solicitudes en caso de situaciones de carga en caso de que sea aceptado por los usuarios finales. Se recomienda realizar una segunda prueba de estrés una vez aplicadas las correcciones y recomendaciones al sistema para verificar si los comportamientos mejoran. Los tiempos medios de las pruebas de esfuerzo se han recopilado de IA.

Conclusiones

La herramienta para las pruebas de carga automatizadas: TAST.

TAST ejecuta pruebas de carga reutilizando el diseño de las pruebas del sistema E2E.

Las pruebas de carga en TAST permiten detectar:

  1. Mal dimensionamiento del sistema infra
  2. Incrementos en los tiempos de respuesta del sistema
  3. Errores de gestión de la base de datos
  4. Limitaciones de las interfaces del sistema

La ejecución de pruebas de carga con TAST es posible tanto en entornos Waterfall (generalmente solo se hace 1 vez antes del inicio de la producción) como Agile (donde son necesarios con cambios de nueva infraestructura, funcional o de arquitectura).