Respuesta.

Históricamente, el rendimiento del software se comprobaba después de la parte funcional principal: los desarrolladores ejecutaban scripts manualmente o recopilaban métricas con herramientas como JMeter. Con la transición masiva a DevOps y CI/CD, surgió la necesidad de automatizar estos procesos y obtener métricas en cada etapa de entrega.

El problema se complica porque la automatización de la carga no es simplemente la ejecución de pruebas listas, sino una configuración fina de los escenarios de carga, la reproducibilidad del perfil de usuarios, la emulación de redes reales, la consideración de la latencia y la limitación del hardware de prueba.

La solución moderna es la implementación de herramientas especializadas (por ejemplo, Gatling, Locust, k6), creación de escenarios con parametrización del perfil de usuarios, integración de pruebas de rendimiento en los pipelines de CI, automatización de la acumulación y el análisis de métricas, alertas en caso de deterioro del rendimiento.

Características clave:

Configuración correcta de los escenarios de carga (repetibilidad y más cercana a la realidad).
Análisis de métricas (división de benchmarking, estrés, intervalos largos) y automatización de su recopilación.
Evaluación del impacto de los resultados de las pruebas en la calidad general de la entrega y el cumplimiento de SLA.

Preguntas capciosas.

¿Es cierto que la automatización de "cargadoras" solo es permitida en producción?

No. Las pruebas automáticas de rendimiento y estrés se pueden realizar en una aplicación o stand dedicado de stage, para no violar el SLA. La automatización de estas es, por el contrario, preferible antes de salir a producción.

Si las pruebas automáticas de carga pasan, ¿se puede estar seguro de la experiencia real del usuario?

No: las pruebas automáticas solo dan una imagen promedio. El comportamiento de los usuarios reales puede diferir debido a las condiciones de red, plataformas utilizadas y otros factores que son difíciles de emular uno a uno.

¿Debería enfocarme solo en los promedios del tiempo de respuesta?

No. Es extremadamente importante considerar el percentil (por ejemplo, el 95º, 99º), ya que los promedios pueden estar sesgados por valores atípicos, y precisamente los valores extremos a menudo afectan más la experiencia del usuario.

Errores típicos y anti-patrones

Enfoque solo en escenarios simples "login/logout", sin emular operaciones comerciales.
Ignorar el análisis de los peores escenarios (tail latency).
Análisis insuficiente de dependencias (por ejemplo, servicios externos no desconectados y límites de tasa).

Ejemplo de la vida

Caso negativo

La empresa implementó pruebas automáticas de rendimiento solo en el acceso al sistema: los scripts ejecutaron 1000 inicios de sesión, analizaron el tiempo de respuesta promedio, y consideraron que el problema estaba resuelto. En el primer lanzamiento real, hubo múltiples time-outs: resultó que las operaciones comerciales "pesadas" paralelas no se tuvieron en cuenta, y la API fallaba bajo carga.

Pros:

Confirmación rápida de la funcionalidad de escenarios triviales.

Contras:

Ignorar las cadenas de usuarios más importantes condujo a un incidente.
Falsa sensación de estabilidad.

Caso positivo

En otro equipo, todo el perfil de carga se formuló a partir del monitoreo de producción; scripts separados emulaban la actividad máxima desde diferentes dispositivos y redes. Todos los resultados se compararon automáticamente con un estándar, y las desviaciones superiores al 5% generaban alertas y suspendían el lanzamiento.