Pruebas de resistencia (soak testing)

Las pruebas de resistencia (soak testing, también llamadas endurance testing) mantienen un sistema bajo una carga normal y sostenida durante un periodo largo, normalmente varias horas y a veces un día o más. La carga en sí no tiene nada de especial; lo que importa es la duración. Muchos defectos son invisibles en una prueba de carga de 10 minutos porque crecen despacio: unos pocos megabytes perdidos por cada mil solicitudes, una conexión que nunca se devuelve al pool, un archivo de log que llena el disco.

Qué encuentra

• Fugas de memoria. Un uso del heap que sube de forma constante y nunca vuelve a bajar tras la recolección de basura, y que acaba en un fallo por falta de memoria (out of memory).
• Agotamiento de recursos. Conexiones a la base de datos, descriptores de archivo, hilos o sockets que se abren y no se liberan.
• Deriva gradual de la latencia. El p95 en la sexta hora es notablemente peor que en la primera, a menudo por cachés que crecen, tablas infladas o fragmentación.
• Interferencia de tareas programadas. Procesos batch nocturnos, copias de seguridad, renovaciones de certificados o rotación de logs que chocan con el tráfico real.
• Crecimiento del almacenamiento. Discos que se llenan de logs, archivos temporales o colas acumuladas.

Ejemplo (k6)

export const options = {
  stages: [
    { duration: '10m', target: 80 },
    { duration: '8h', target: 80 },
    { duration: '10m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<600'],
    http_req_failed: ['rate<0.005'],
  },
};

La función por defecto es el mismo recorrido de usuario realista que usarías en una prueba de carga. La diferencia es la larga etapa estable.

Cómo leer los resultados

Una prueba de resistencia se juzga por las tendencias, no solo por los umbrales de aprobado/fallido. Grafica la memoria, el número de conexiones, los percentiles de latencia y la tasa de errores a lo largo de toda la ejecución. Una línea plana es un aprobado. Una pendiente ascendente constante es un defecto, aunque la ejecución terminara antes de que algo fallara, porque producción funciona mucho más de ocho horas seguidas.

Errores comunes

• Ejecutar la prueba de resistencia con carga de nivel de estrés, lo que mezcla dos preguntas y hace que la causa de un fallo no quede clara.
• Vigilar solo las métricas del lado del cliente. Las fugas aparecen primero en las gráficas de memoria del servidor y de los pools.
• Usar un entorno que reinicia los servicios o los escala automáticamente durante la ejecución, lo que oculta justo la acumulación que buscas.
• Saltársela porque es lenta. Prográmala por la noche o el fin de semana en lugar de descartarla.