¿Qué es soak testing?

¿Qué es soak testing?

Soak testing (también llamado endurance testing) corre carga moderada y sostenida contra un sistema durante muchas horas o días, mucho más que un load test típico. El objetivo no es encontrar el techo de capacidad ni stress-romper el sistema. Es sacar problemas de desarrollo lento que solo se manifiestan tras horas de operación: memory leaks, drift de connection pool, llenado de log disk, expiración de certificados, thrashing de conexiones de BD, patrones lentos de cache eviction.

Soak testing vs load testing

Un load test corre al peak esperado durante 15 minutos a unas horas. Lo suficiente para que las cachés calienten y el comportamiento a corto plazo se estabilice. Un soak test corre quizás al 40-60% del peak durante 8-72 horas. Lo suficiente para que los problemas que se acumulan gradualmente se hagan visibles.

Las preguntas que cada uno responde difieren:

• Load test: ¿puede mi sistema cumplir SLOs al peak esperado durante una hora o dos?
• Soak test: si corro mi sistema a carga moderada de forma continua durante dos días, ¿se mantiene estable el rendimiento o se degrada lentamente?

Los soak tests corren intencionalmente por debajo del peak para sacar problemas acumulados. Para encontrar la carga máxima sostenible en sí, ver capacity testing.

Qué encuentran los soak tests

Cosas que los load tests cortos pierden:

• Memory leaks. Un objeto nunca garbage-collected, un buffer nunca liberado, una caché que crece sin límite. El heap crece durante horas hasta que la JVM (o Node, Go, Python) llega a un límite y el proceso muere.
• Drift de connection pool. Pools de conexión de BD o HTTP-client que filtran una conexión por cada N peticiones, finalmente agotando los slots disponibles.
• Llenado de log disk. Logging verbose se come el disco; producción se queda sin espacio tras horas.
• Expiración de certificado o token. Un token OAuth cacheado durante 1 hora; si no se refresca correctamente, todas las peticiones tras la hora fallan.
• Cache eviction lenta. Los cache hits se mantienen altos un tiempo, luego caen al rotar el working set; el rendimiento degrada silenciosamente.
• Agotamiento de recursos que se compone. Tablas temp de BD, backlogs de message queue, file descriptors.

Cuándo ejecutar un soak test

• Pre-major-release. Un servicio persistente nuevo, upgrade de framework o migración de BD introducen comportamiento a largo plazo desconocido.
• Tras cambios de arquitectura. Nueva capa de caché, nueva message queue, nuevo driver de BD, nuevo sidecar de service mesh.
• Trimestralmente, como regression check. La mayoría de equipos ejecutan soak tests con menos frecuencia que load tests; trimestralmente captura drift lento entre releases.
• Post-incident. Si un outage fue causado por un leak lento, un soak test contra el fix confirma que el leak se fue.

Métricas clave de soak test

1. Tendencia de uso de memoria en el tiempo. El heap debería estabilizarse, no escalar linealmente. Memoria escalando = leak.
2. Drift de percentil de response time. p95 en hora 24 debe coincidir con p95 en hora 1.
3. Utilización de pool de recursos. Pool de conexiones BD, pool HTTP client, pool de threads. Debería mantenerse plano, no escalar.
4. Error rate en el tiempo. Debe mantenerse constante. Repunte súbito en hora N = un problema acumulado acaba de cruzar un umbral.

Cómo ejecutar un soak test

Mismos scripts que load testing, mayor duración. En JMeter, fija la duración del Thread Group en muchas horas (24-72). En k6, configura un escenario constant-vus con un ajuste duration largo.

Para soak tests de varios días donde el test-harness mismo no puede correr continuamente en un portátil, ejecuta desde LoadFocus. La infraestructura cloud gestiona la sesión de larga duración sin restricciones de máquina local.

Si tu equipo no tiene tiempo para configurar y monitorear soak runs de varios días, LoadFocus ofrece load testing services donde los ingenieros ejecutan el soak, monitorean las métricas y entregan un informe.