¿Qué es soak testing?

¿Qué es soak testing?

El soak testing, también llamado prueba de resistencia o endurance testing, mantiene una carga realista y constante sobre un sistema durante horas en lugar de minutos. La pregunta no es cuánta carga aguanta, sino si el sistema sigue sano mientras la soporta mucho tiempo. Encuentra fallos que tardan horas en formarse, como memory leaks, pools de conexiones agotados y discos que se llenan.

Los dos nombres designan la misma práctica. Cuánto debe durar y cómo leer la tendencia se explica en la guía ampliada endurance testing (soak testing) del blog de LoadFocus.

Cómo funciona una prueba soak

• Parte del script de carga media de tu prueba de carga. El soak test lo reutiliza y solo cambia cuánto dura la meseta.
• Sube hasta una carga normal y esperada y mantenla. La documentación de k6 describe la carga como media, con duraciones como 3, 4, 8, 12, 24 o de 48 a 72 horas.
• Registra la tendencia, no solo el resumen: tiempo de respuesta, tasa de errores, rendimiento, memoria, uso del pool de conexiones y disco, idealmente en el servidor además de en la herramienta de pruebas.
• Compara la primera hora con la última. Cualquier pendiente que no se detiene es el hallazgo.

En k6 todo el esquema cabe en pocas líneas:

export const options = {
  stages: [
    { duration: '5m', target: 100 },
    { duration: '8h', target: 100 },
    { duration: '5m', target: 0 },
  ],
};

Imagina un servicio con un pool de conexiones a base de datos. HikariCP, un pool habitual en Java, trae 10 conexiones por defecto, y cuando no queda ninguna libre quien la pide espera hasta 30 segundos y recibe una SQLException. Si una ruta de código olvida devolver una conexión cada unos miles de peticiones, una prueba de carga de 20 minutos no lo nota. Ocho horas de carga constante vacían el pool, las peticiones se encolan y después fallan.

Qué encuentra un soak test

• Memory leaks. Memoria que se reserva y nunca se libera sube hasta que el proceso muere. En la gráfica es una línea que nunca se estabiliza.
• Fugas de conexiones. Conexiones a base de datos o HTTP que se abren y no se devuelven, como en el ejemplo del pool.
• Crecimiento de disco y logs. Logs, archivos temporales o filas de auditoría que llenan un volumen que nadie dimensionó para una prueba larga.
• Degradación de la caché. Una caché que crece sin expulsar entradas, o cuyo porcentaje de aciertos baja al cambiar el conjunto de trabajo.
• Credenciales que caducan. Un token o certificado en caché que no se renueva bien hace fallar todas las peticiones tras caducar.
• Tareas programadas frente al tráfico. Copias de seguridad y limpiezas que corren una vez al día y nunca se observaron bajo carga.

Errores frecuentes

• Usar carga pico. Una prueba larga con carga irreal es otra prueba. Superar el tráfico normal es prueba de estrés o de capacidad, y mezclarlas dificulta explicar el resultado.
• Parar demasiado pronto. La ejecución debe abarcar al menos un ciclo natural del sistema, como un proceso por lotes cada hora o la copia nocturna.
• Leer solo el resumen. Una media de ocho horas esconde una subida lenta. Mira la gráfica a lo largo del tiempo.
• Mirar solo el cliente. La herramienta de pruebas ve respuestas más lentas. La memoria, las conexiones y el disco del servidor explican el motivo.
• Quedarse sin datos de prueba. Si se repiten los mismos pocos usuarios y registros, las cachés se mantienen calientes y el sistema parece más sano de lo que es.
• Llamar fuga a cada escalón. Un salto repentino suele coincidir con un evento. Cruza la hora con despliegues, tareas y rotación de logs antes.

Soak testing frente a pruebas parecidas

• La prueba de carga comprueba el comportamiento en el pico esperado durante un tiempo limitado.
• La prueba de capacidad busca la carga más alta que el sistema sostiene.
• La prueba de picos (spike testing) golpea el sistema con una ráfaga repentina y observa la recuperación.
• El soak testing es la única de ellas que trata del tiempo y no del tamaño.

Soak test con LoadFocus

Escribe el escenario en JMeter o k6 y fija los usuarios virtuales y la duración en el navegador en LoadFocus. La duración máxima depende del plan: hasta 20 minutos en Starter, 1 hora en Basic y 5 horas desde Essential (loadfocus.com/pricing, octubre de 2026). Eso cubre un soak corto. Para una ejecución de 24 o 72 horas, lanza el mismo script en tu propia infraestructura y vigila las gráficas del servidor, porque la tendencia de memoria, conexiones y disco es el resultado. El diagnóstico de memory leaks se explica en cómo identificar y corregir memory leaks en pruebas de carga.

Preguntas frecuentes sobre soak testing

¿Cuánto debe durar un soak test?

Lo suficiente para abarcar al menos un ciclo natural de tu sistema, por ejemplo un proceso por lotes cada hora o una copia nocturna. La documentación de k6 menciona duraciones de 3 a 72 horas. Ocho horas son una primera ejecución habitual porque cubren una jornada laboral.

¿El soak testing es lo mismo que el endurance testing?

Sí. Ambos términos describen mantener una carga realista durante mucho tiempo para encontrar degradación que solo aparece con el tiempo. Usa el que tu equipo ya utilice.

¿Qué carga debe usar un soak test?

Carga normal y esperada, no el pico. El objetivo es ver qué hace el tiempo con el sistema, así que la carga tiene que ser algo que pueda soportar. Más allá es una prueba de estrés.

¿Cómo se ve un memory leak en un soak test?

La memoria sube durante toda la ejecución y nunca se aplana, a menudo con tiempos de respuesta que empeoran poco a poco porque el recolector de basura trabaja más. Un sistema sano llega a una meseta.

¿Puede LoadFocus ejecutar un soak test de 24 horas?

No en una sola ejecución. La duración máxima es de 5 horas, desde Essential. Un soak más largo se ejecuta en tu propia infraestructura con el mismo script de JMeter o k6.