Skip to main content
Version: 1,0

Plan de Pruebas de Estrés

Información general

Responsable de las pruebas: Text & Lines
Fecha estimada de ejecución: Por definirse


Objetivo

Evaluar la capacidad del sistema para soportar condiciones extremas, simulando cargas que excedan límites operativos normales, y detectar fallos de rendimiento, estabilidad o integridad de datos.


Alcance

Componentes evaluados

  • Base de Datos
  • API (Servidor web)

Volumen de datos

  • Inserción de hasta 180,000 registros
  • Carga concurrente con miles de solicitudes

Escenario de Prueba

Casos de prueba

  • Forzar la inserción de 180,000 registros en la base de datos en un tiempo reducido, con múltiples hilos o procesos simultáneos.
  • Ejecutar consultas complejas con carga concurrente que exceda los niveles normales de uso.
  • Simular múltiples usuarios accediendo al servidor al mismo tiempo y medir el tiempo promedio de respuesta, tasa de transferencia y posibles cuellos de botella.
  • Evaluar la velocidad y estabilidad de la API bajo diferentes niveles de carga.
  • Generar peticiones concurrentes para medir el tiempo promedio de respuesta y detectar cuellos de botella.
  • Simular fallas controladas (corte de red, reinicio de servicio) para observar cómo responde el sistema.

Datos de prueba

Los datos serán generados sintéticamente mediante scripts, diseñados para simular escenarios de uso real.


Configuración del Entorno

Software y versiones

  • Ubuntu versión 22.04
  • RDS MySql versión 8.0.37
  • Node.js versión 22.14
  • CloudWatch versión 1.300053.0
  • Postman versión 11.38.5

Criterios de éxito y falla

Criterios de Éxito para Base de Datos

  • La base de datos maneja la inserción, consulta, actualización y eliminación de grandes volúmenes de datos dentro de N segundos.
  • La integridad de los datos se mantiene incluso bajo carga masiva (sin corrupción ni pérdida de datos).
  • Los índices y claves funcionan eficientemente con el volumen máximo de datos probado.
  • No hay fallos en conexiones simultáneas de 3,800 clientes.

Criterios de Éxito para APIs

  • La API responde a todas las solicitudes dentro del tiempo máximo permitido (N segundos), incluso con X (peor de los casos) solicitudes simultáneas.
  • Los endpoints soportan respuestas de gran tamaño (como datos paginados con 30,000 registros).
  • La API gestiona correctamente errores como tiempos de espera agotados y entradas inválidas.
  • Mantiene la tasa de éxito de respuestas sin errores (por ejemplo, ≥ 99.9%).

Criterios de Falla para Base de Datos

  • Incrementos drásticos en los tiempos de consulta o inserción, superando los límites aceptables.
  • Pérdida, corrupción o duplicación de datos durante las operaciones.
  • Fallos en transacciones bajo condiciones de alta concurrencia (deadlocks, conflictos de escritura).
  • Consumo excesivo de memoria o disco, causando errores de "out of memory" o falta de espacio.

Criterios de Falla para APIs

  • La latencia promedio de las respuestas supera los límites definidos bajo alta carga.
  • Fallos en las conexiones o caídas de endpoints al manejar múltiples solicitudes simultáneas.
  • Respuestas incompletas, con errores en el formato o inconsistencia en los datos.
  • Problemas con la autenticación o autorización bajo volumen masivo de solicitudes.

Resultados esperados

El sistema debería mantenerse funcional, con una degradación controlada del rendimiento, permitiendo identificar umbrales críticos y puntos de optimización.


Ejecución y análisis

Cómo se ejecutará la prueba

  • Preparación del entorno
  • Generación de datos
  • Automatización de pruebas
  • Ejecución de escenarios definidos
  • Registro de métricas

Cómo se interpretarán los resultados

Se registran logs en CloudWatch (en caso de aplicar) para identificar errores o cuellos de botella. También se analizarán los tiempos de respuesta y latencia promedio.


Conclusiones y Recomendaciones

AspectoObservaciones/ResultadosImpacto en el rendimiento
Tiempo de respuesta
Cuellos de botella
Recomendaciones técnicas

Historial de cambios

Tipo de VersiónDescripciónFechaColaborador
1.0Creacion de el documento4/9/2025Rodrigo Antonio Benítez