Más Allá de las Pruebas de Carga Estándar
En las lecciones anteriores, aprendiste a usar herramientas como JMeter, k6, Gatling y Locust para crear pruebas de carga. Pero elegir el tipo correcto de prueba de rendimiento es tan importante como elegir la herramienta correcta. Diferentes tipos de pruebas responden diferentes preguntas sobre tu sistema.
Esta lección cubre cuatro tipos especializados de pruebas de rendimiento que van más allá de las pruebas de carga estándar. Cada uno tiene un propósito distinto, perfil de carga y conjunto de defectos que descubre.
Pruebas de Estrés: Encontrando el Punto de Quiebre
Definición: Las pruebas de estrés empujan al sistema más allá de su capacidad diseñada para identificar el punto de quiebre y observar cómo falla.
Pregunta clave: “¿En qué punto se rompe el sistema y cómo falla?”
Perfil de Carga
Las pruebas de estrés aumentan gradualmente la carga hasta que el sistema se degrada o colapsa:
Una prueba de estrés típica sube muy por encima de la carga máxima esperada:
| Fase | Duración | Nivel de Carga |
|---|---|---|
| Calentamiento | 5 min | 50% del máximo esperado |
| Carga normal | 10 min | 100% del máximo esperado |
| Estrés fase 1 | 10 min | 150% del máximo esperado |
| Estrés fase 2 | 10 min | 200% del máximo esperado |
| Estrés extremo | 10 min | 300% del máximo esperado |
| Recuperación | 10 min | Vuelta a 0 o normal |
Qué Buscar
- ¿Con cuántos usuarios o tasa de solicitudes aparecen los errores?
- ¿El sistema se degrada gradualmente (respuestas lentas) o falla catastróficamente (crash completo, corrupción de datos)?
- ¿Se recupera el sistema cuando la carga vuelve a lo normal, o requiere reinicio?
- ¿Son significativos los mensajes de error? Los usuarios deben ver páginas de error amigables, no stack traces.
- ¿Hay fallos en cascada? ¿Un componente fallando derriba a otros?
Defectos Comunes Encontrados
- Endpoints sin respuesta bajo carga extrema
- Errores de falta de memoria (OOM)
- Agotamiento del pool de hilos
- Límites de conexiones a base de datos excedidos
- Mala configuración del load balancer
- Falta de circuit breakers o rate limiting
- Corrupción de datos bajo escrituras concurrentes
Pruebas de Resistencia (Soak): La Carrera Larga
Definición: Las pruebas de resistencia (también llamadas soak testing) aplican una carga moderada y constante durante un período extendido — típicamente horas o incluso días.
Pregunta clave: “¿El sistema permanece estable y con buen rendimiento durante largos períodos de uso normal?”
Perfil de Carga
15 min] --> B[Carga Estable al 70-80% Capacidad
4-24 horas] B --> C[Ramp Down
15 min] end
| Fase | Duración | Nivel de Carga |
|---|---|---|
| Ramp-up | 15-30 min | 0% al 70-80% de capacidad |
| Estado estable | 4-72 horas | 70-80% del máximo esperado |
| Ramp-down | 15-30 min | Vuelta a 0 |
El nivel de carga debe representar el uso típico de producción, no condiciones extremas. El objetivo es ejecutar el tiempo suficiente para que aparezcan defectos dependientes del tiempo.
Qué Buscar
- Uso de memoria en el tiempo: ¿Tiene tendencia ascendente? Una fuga de memoria lenta que agrega 1MB por hora colapsará el sistema después de días.
- Tendencias de tiempo de respuesta: ¿Los tiempos de respuesta aumentan gradualmente aunque la carga permanezca constante?
- Pool de conexiones a BD: ¿Las conexiones se devuelven correctamente o el pool se agota lentamente?
- Espacio en disco: ¿Los logs, archivos temporales o caché crecen sin límite?
- Handles de servicios externos: ¿Los descriptores de archivo, sockets de red o límites de tasa de API se consumen sin liberarse?
Defectos Comunes Encontrados
- Fugas de memoria (objetos no recolectados por el garbage collector)
- Agotamiento del pool de conexiones a base de datos
- Consumo de espacio en disco por archivos de log
- Degradación gradual del rendimiento
- Problemas de gestión de sesiones (sesiones obsoletas acumulándose)
- Caché que crece sin política de desalojo
- Fugas de descriptores de archivo
Pruebas de Pico (Spike): Ráfaga Repentina
Definición: Las pruebas de pico simulan un aumento repentino y masivo de carga seguido de carga alta sostenida o una disminución igualmente repentina.
Pregunta clave: “¿Puede el sistema manejar una ráfaga repentina de usuarios y recuperarse rápidamente?”
Perfil de Carga
5 min] --> B[Pico Instantáneo
10x usuarios] B --> C[Pico Sostenido
5-10 min] C --> D[Caída a Normal
instantánea] D --> E[Recuperación
5 min] end
Escenarios Reales para Pruebas de Pico
- Ventas relámpago: Un sitio de e-commerce anuncia 90% de descuento al mediodía
- Noticias de última hora: Un sitio de noticias es enlazado desde redes sociales
- Lanzamientos de juegos: Se abre el servidor para un nuevo juego online
- Campañas de marketing: Un email masivo envía millones de usuarios a una landing page
Qué Buscar
- ¿Qué tan rápido escala el sistema? La infraestructura cloud con auto-scaling puede necesitar 2-5 minutos para provisionar nuevas instancias.
- ¿El sistema rechaza carga graciosamente? Deben activarse colas, rate limiting o salas de espera.
- Tiempo de recuperación: ¿Cuánto después del pico vuelve el sistema a tiempos de respuesta normales?
- Consistencia de datos: ¿Hubo transacciones perdidas, pedidos duplicados o datos corruptos durante el pico?
Pruebas de Volumen: Grandes Conjuntos de Datos
Definición: Las pruebas de volumen evalúan el comportamiento del sistema cuando la base de datos o almacenamiento contiene cantidades muy grandes de datos, independientemente de los usuarios concurrentes.
Pregunta clave: “¿El sistema funciona bien cuando el volumen de datos está a escala de producción o más allá?”
Qué lo Hace Diferente
Las pruebas de volumen no son sobre usuarios concurrentes — son sobre tamaño de datos. Puedes ejecutar pruebas de volumen con pocos usuarios pero con millones de registros en la base de datos.
| Aspecto | Prueba de Carga | Prueba de Volumen |
|---|---|---|
| Enfoque | Usuarios concurrentes | Tamaño de datos |
| Usuarios | Muchos (cientos/miles) | Pocos (1-10) |
| Datos | Dataset normal | Dataset muy grande |
| Mide | Tiempo de respuesta bajo carga | Tiempo de respuesta con datos grandes |
Qué Probar
- Consultas de BD: ¿Las consultas que funcionan con 1,000 registros siguen funcionando con 10 millones?
- Funcionalidad de búsqueda: ¿La búsqueda de texto completo se degrada con un índice grande?
- Paginación: ¿La página 10,000 carga tan rápido como la página 1?
- Reportes y agregaciones: ¿Puede el sistema generar reportes de millones de registros?
- Import/Export de datos: ¿Cuánto toma importar o exportar datasets grandes?
Defectos Comunes Encontrados
- Índices de BD faltantes causando escaneos completos de tabla
- Problemas de consultas N+1 volviéndose críticos a escala
- Paginación usando OFFSET en lugar de paginación basada en cursor
- Reportes con timeout en datasets grandes
Ejercicio: Diseñar Perfiles de Carga para Cada Tipo
Eres el QA lead de una plataforma de venta de boletos en línea. La plataforma normalmente maneja 500 usuarios concurrentes y almacena 2 millones de registros de reservas. Diseña perfiles de carga para cada uno de los cuatro tipos de prueba.
Contexto
- Pico normal: 500 usuarios concurrentes
- Máximo esperado: 800 usuarios concurrentes
- Base de datos: 2 millones de reservas, 500K cuentas de usuario
- Eventos especiales: Lanzamientos de boletos para conciertos causan picos de 10x
- El sistema opera 24/7
Requisitos
Para cada tipo de prueba (estrés, resistencia, pico, volumen), especifica:
- La pregunta específica que quieres responder
- El perfil de carga (fases, usuarios, duración)
- Tres métricas clave a monitorear
- Dos defectos potenciales que esperas encontrar
Pista: Piensa en Escenarios Reales
- Estrés: ¿Qué pasa cuando un concierto popular sale a la venta y los usuarios siguen aumentando más allá de 800?
- Resistencia: El sistema opera 24/7 — ¿qué pasa después de una semana de operación continua?
- Pico: Un artista famoso anuncia un concierto sorpresa — 5000 usuarios llegan en 30 segundos.
- Volumen: Después de 3 años de operación, la BD tiene 20 millones de reservas. ¿Las búsquedas siguen funcionando?
Solución: Diseños Completos de Perfiles de Carga
1. Prueba de Estrés
Pregunta: “¿En qué punto el sistema de reservas deja de aceptar nuevas reservaciones?”
Perfil de carga:
- Calentamiento: 5 min a 250 usuarios
- Normal: 10 min a 500 usuarios
- Estrés 1: 10 min a 800 usuarios (máximo esperado)
- Estrés 2: 10 min a 1200 usuarios (150% del máximo)
- Estrés 3: 10 min a 2000 usuarios (250% del máximo)
- Extremo: 10 min a 3000 usuarios
- Recuperación: 15 min vuelta a 500 usuarios
Métricas clave: Tasa de error en cada fase, curva de degradación de tiempo de respuesta, tiempo de recuperación del sistema
Defectos esperados: Pool de conexiones a BD agotado a ~1500 usuarios, emails de confirmación encolándose y fallando bajo alta carga
2. Prueba de Resistencia
Pregunta: “¿El sistema mantiene el rendimiento después de 48 horas de operación continua?”
Perfil de carga:
- Ramp-up: 30 min a 400 usuarios (80% del pico normal)
- Estado estable: 48 horas a 400 usuarios
- Ramp-down: 30 min a 0
Métricas clave: Tendencia de consumo de memoria (por hora), tendencia de p95 de tiempo de respuesta (por hora), utilización del pool de conexiones a BD en el tiempo
Defectos esperados: Objetos de sesión no limpiados para reservas abandonadas (fuga de memoria), rotación de logs mal configurada causando llenado de disco después de 24 horas
3. Prueba de Pico
Pregunta: “¿Puede el sistema manejar una avalancha repentina cuando sale a la venta un concierto popular?”
Perfil de carga:
- Línea base: 5 min a 500 usuarios
- Pico: Salto instantáneo a 5000 usuarios (10x)
- Sostenido: 10 min a 5000 usuarios
- Caída: Instantánea a 500 usuarios
- Recuperación: 10 min a 500 usuarios
Métricas clave: Tasa de error durante los primeros 60 segundos del pico, tiempo hasta la primera reserva exitosa durante el pico, tiempo de recuperación al p95 normal
Defectos esperados: Locks de reserva de asientos causando deadlocks bajo concurrencia repentina, errores de timeout del gateway de pago durante el pico
4. Prueba de Volumen
Pregunta: “¿Las búsquedas y reportes funcionarán cuando la BD alcance 20 millones de reservas?”
Configuración de datos: Poblar BD con 20 millones de registros (10x actual), 5 millones de cuentas de usuario, 10 años de datos históricos
Probar con 5-10 usuarios concurrentes
Métricas clave: Tiempo de ejecución de consultas de búsqueda, tiempo de generación de reportes, tiempo de carga de detalle de reserva para registros viejos vs nuevos
Defectos esperados: Búsqueda de reservas sin filtro de fecha causa escaneo completo de tabla (índice compuesto faltante), agregación de reporte mensual excede timeout de 30 segundos con 20M de registros
Tips Profesionales
- Combina Tipos en la Estrategia de Prueba: Una estrategia completa incluye los cuatro tipos. Ejecuta pruebas de carga primero (línea base), luego estrés, después resistencia y finalmente volumen.
- Monitorea Infraestructura, No Solo Aplicación: Durante todas las pruebas de rendimiento, monitorea CPU, memoria, I/O de disco, red, conexiones a BD y profundidad de colas.
- Prueba la Recuperación Explícitamente: Después de pruebas de estrés y pico, siempre incluye una fase de recuperación. Un sistema que se recupera automáticamente en 30 segundos es muy diferente de uno que requiere intervención manual.
- Generación de Datos para Volumen: Usa herramientas como Faker (Python), DataFactory (Java) o scripts custom para generar datos realistas con la misma distribución estadística que producción.
- Establece Criterios de Aceptación Claros: Antes de ejecutar cualquier prueba, define qué significa “aprobado” y “reprobado”.