Stress Test en el desarrollo móvil: qué es, objetivos y cómo se realiza

¿Qué es Stress Test?

Stress Test (pruebas de estrés) es un proceso de evaluación de la capacidad del sistema para operar en condiciones que superan las especificaciones de diseño. Para una aplicación móvil, esto puede significar 10,000 notificaciones push simultáneas con una norma de 1,000; para un backend, 50,000 RPS frente a los 5,000 esperados. La principal diferencia entre Stress Test y Load Test es que el objetivo no es confirmar el rendimiento, sino estudiar el comportamiento del sistema más allá de su capacidad diseñada. Netflix Engineering (2024) define Stress Test como “una verificación de hipótesis de que el sistema fallará de manera predecible.”

Las pruebas de estrés incluyen dos etapas obligatorias: carga hasta el fallo y observación de la recuperación. Recuperación es la capacidad del sistema para volver a la operación normal tras eliminar la sobrecarga. Un sistema que no se recupera sin un reinicio se considera frágil, incluso si soporta sobrecargas a corto plazo. Según AWS Well-Architected Framework (2024), el tiempo de recuperación tras un Stress Test no debe superar los 5 minutos.

Para los clientes móviles, Stress Test incluye la verificación del comportamiento bajo terminación forzada de procesos, desconexión de red y agotamiento de RAM. Android Low Memory Killer puede terminar un proceso en segundo plano cuando la RAM es insuficiente — la prueba de estrés debe verificar que la aplicación restaura correctamente el estado tras dicha terminación. Apple UIKit (2024) recomienda probar escenarios de advertencia de memoria en cada pantalla de la aplicación.

Objetivos del Stress Testing

Determinación del Punto de Fallo

El primer objetivo del Stress Test es determinar el punto de fallo. Es el momento en que uno de los indicadores clave de rendimiento cruza un umbral crítico: el tiempo de respuesta p95 supera los 10 segundos, la tasa de error HTTP 5XX supera el 5% o el rendimiento cae por debajo del 50% del baseline. Registrar el punto de fallo permite al equipo conocer de antemano el límite de escalabilidad del sistema. Capacity planning se basa específicamente en los datos de Stress Test, no de Load Test, porque Load Test no verifica condiciones límite.

Verificación de Mecanismos de Recuperación

El segundo objetivo es verificar los mecanismos de recuperación. Tras reducir la carga a niveles normales, el sistema debe volver a los indicadores base. Si el pool de conexiones a la base de datos no se libera o la caché no se invalida, Stress Test revelará este problema. El circuit breaker (Hystrix, Resilience4j) debe dispararse bajo sobrecarga y restaurar automáticamente la conexión tras la estabilización. Los endpoints de Health check ayudan a monitorear el estado de cada servicio durante la prueba.

Validación del Auto-Scaling

El tercer objetivo es validar el auto-scaling. Si la infraestructura utiliza Kubernetes o AWS Auto Scaling, Stress Test verifica que los nuevos pods o instancias se creen con la suficiente rapidez. Según Google Kubernetes Engine (2024), el tiempo de despliegue de un nuevo pod no debe superar los 30 segundos desde que se activa la métrica de HPA (Horizontal Pod Autoscaler). HPA debe escalar basándose en CPU, memoria y métricas personalizadas. Cluster Autoscaler añade nuevos nodos si los actuales no pueden albergar pods.

Metodología de Stress Test

Aumento gradual de la carga (Ramp-up Stress Test) es el escenario más común. La carga inicial se establece al 50% de lo esperado, luego se incrementa un 10% cada 2 minutos hasta que el sistema falla. Este escenario permite encontrar el límite exacto de estabilidad. Grafana Cloud k6 (2025) recomienda un paso de incremento no superior al 10% para obtener un gráfico suave del tiempo de respuesta.

Pico repentino de carga (Spike Stress Test) — la carga aumenta del 10% al 500% en 10–30 segundos. Este escenario simula situaciones como la propagación viral de contenido o ataques DDoS. Spike Stress Test evalúa no tanto el rendimiento como la supervivencia del sistema: la capacidad de no caer por completo y volver a funcionar tras la estabilización. API Gateway debe configurar rate limiting para proteger el backend de picos repentinos.

Retención prolongada de sobrecarga (Sustained Stress Test) — el sistema se mantiene en estado de sobrecarga durante 30–60 minutos. Este escenario revela fugas de recursos que no se manifiestan en pruebas cortas. Fugas de memoria en aplicaciones Java/Kotlin se acumulan durante 20–40 minutos de trabajo intensivo, y solo Sustained Stress Test las detecta.

Análisis del Punto de Fallo y Recuperación

El punto de fallo se determina por tres criterios: tiempo de respuesta, porcentaje de errores y rendimiento. El umbral de tiempo de respuesta suele superarse primero — las solicitudes comienzan a tardar más del límite establecido. Luego aumenta el porcentaje de errores: el servidor no puede procesar las solicitudes y devuelve 503. Finalmente, el Throughput cae — el sistema ya no puede manejar ni la carga mínima. La métrica del punto de fallo se registra en el perfil de carga para la planificación de capacidad.

El análisis de recuperación incluye tres fases: reacción inmediata (primeros 30 segundos tras eliminar la carga), estabilización (1–5 minutos) y recuperación completa (5–30 minutos). En la fase de reacción inmediata, el tiempo de respuesta debe caer por debajo del baseline — el sistema está liberando colas. Si esto no ocurre, el problema no es la carga sino el estado acumulado. Graceful degradation — la capacidad del sistema para mantener funcionalidad parcial bajo sobrecarga — es un indicador clave de madurez arquitectónica.

Chaos Engineering complementa Stress Test introduciendo fallos deliberadamente: apagar el servidor de base de datos, latencia de red, detener un microservicio. Chaos Monkey de Netflix (2024) termina procesos aleatoriamente en producción, probando la resiliencia del sistema. Para aplicaciones móviles, Chaos Engineering significa probar escenarios: sin red, API no disponible, respuesta vacía del servidor.

Herramientas para Stress Test

k6 con ramping-arrival-rate

k6 soporta Stress Test a través del módulo `execution` con configuración ramping-arrival-rate. Este modo aumenta el número de solicitudes por segundo independientemente del tiempo de ejecución de cada solicitud. En comparación con Load Test, Stress Test en k6 requiere configurar thresholds más agresivos y deshabilitar gracefull-stop para simular un fallo repentino. Grafana Cloud detecta automáticamente el punto de fallo por la inflexión en el gráfico de tiempo de respuesta. k6-operator para Kubernetes permite ejecutar Stress Tests distribuidos desde el clúster.

JMeter con Ultimate Thread Group

JMeter permite configurar Stress Test a través de Ultimate Thread Group — un plugin que define el perfil de carga como una tabla: número de hilos, tiempo de calentamiento, tiempo de retención, tiempo de descenso. Ultimate Thread Group es conveniente para escenarios complejos multifásicos. JMeter Backend Listener envía métricas a InfluxDB para graficar el punto de fallo. Para Stress Test, JMeter recomienda deshabilitar los timeouts de conexión para medir con mayor precisión el comportamiento bajo sobrecarga.

Gremlin para Chaos Engineering

Gremlin es una plataforma de Chaos Engineering para Stress Test de infraestructura. Gremlin permite apagar la red, cargar la CPU, llenar el disco y terminar procesos a nivel de pods individuales de Kubernetes. Los equipos SRE utilizan Gremlin junto con k6 para Stress Test integral: k6 genera carga, Gremlin introduce fallos. Game Day — sesiones regulares de Stress Test con Gremlin, documentadas en un “informe de caos” para analizar la resiliencia del sistema.

Ejemplo de Stress Test en k6

El siguiente script de k6 demuestra Stress Test con aumento gradual de la carga hasta el fallo. Ramping-arrival-rate aumenta el número de solicitudes por segundo independientemente del tiempo de ejecución. Los thresholds están configurados para detección agresiva de degradación: p95 no más de 2000 ms, tasa de error no más del 5%. Cuando se superan los thresholds, k6 finaliza con un código de error, lo que permite integrar Stress Test en el pipeline CI/CD.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Mejores Prácticas de Stress Testing

Comience Stress Test en staging — las pruebas de estrés en producción requieren monitoreo avanzado y un plan de reversión. Google SRE (2024) recomienda realizar Stress Test en un entorno 100% aislado que reproduzca la producción en arquitectura y capacidad. Tras una prueba exitosa en staging, se puede pasar a producción bajo supervisión de SRE. Feature flag para deshabilitar funcionalidad bajo sobrecarga es obligatorio.

Automatice Stress Test en CI/CD para análisis de regresión del punto de fallo. Si una nueva versión de la aplicación tiene un punto de fallo un 20% inferior al anterior, es una regresión que debe corregirse antes del lanzamiento. Baseline breaking point se almacena en métricas y se compara automáticamente con cada resultado de Stress Test. Se activa una alerta cuando el punto de fallo cae un 10%.

Documente cada Stress Test: perfil de carga, punto de fallo, comportamiento de recuperación y lista de problemas encontrados. Netflix Engineering (2024) realiza “Game Day” — sesiones regulares de Stress Test cuyos resultados se documentan en un “informe de caos.” El informe de pruebas de estrés debe contener un gráfico “RPS — tiempo de respuesta” con el punto de fallo marcado.