Tu aplicación funciona de maravilla con diez usuarios. ¿Y con diez mil conectados a la vez durante una campaña? Las pruebas de rendimiento responden a esa pregunta antes de que lo haga el mercado: miden cómo se comporta tu sistema bajo distintas condiciones de uso, para evitar caídas y lentitud justo cuando más importa, que suele ser cuando más gente te está mirando.
Qué son, exactamente
Son pruebas no funcionales que evalúan la velocidad, la estabilidad y la capacidad de un sistema. No comprueban si una función hace lo correcto, eso lo hacen las pruebas funcionales, sino si lo hace con rapidez y de forma fiable cuando hay mucho uso. Una web puede tener todos sus botones perfectos y, aun así, volverse inservible en cuanto se junta tráfico, y ese es el tipo de fallo que solo se descubre probando el rendimiento.
Los tipos de pruebas de rendimiento que conviene distinguir
Las pruebas de carga simulan el uso esperado o previsto para comprobar que el sistema responde dentro de lo aceptable. Las de estrés llevan el sistema más allá de su capacidad para ver dónde y cómo falla, y sobre todo cómo se recupera. Las de picos reproducen aumentos bruscos de tráfico, como una campaña o un lanzamiento, que es justo el escenario que más suele sorprender. Las de resistencia mantienen una carga sostenida durante mucho tiempo para detectar fugas de memoria o degradación progresiva, y las de escalabilidad comprueban cómo mejora el rendimiento al añadir recursos.
Qué se mide
Lo habitual es observar el tiempo de respuesta, cuánto tarda el sistema en contestar; el rendimiento o throughput, cuántas peticiones procesa por segundo; la tasa de errores, qué proporción de peticiones falla bajo carga; y el uso de recursos, es decir, procesador, memoria, red y base de datos. Los números solos no dicen mucho; lo importante es compararlos con los objetivos que hayas fijado antes, como un tiempo máximo de respuesta para los flujos clave con un determinado número de usuarios.
Cuándo hacerlas
Antes de lanzamientos importantes o campañas con picos previstos. Después de cambios de arquitectura o infraestructura. Cuando aparecen quejas de lentitud o caídas esporádicas. De forma periódica en productos críticos, como parte del ciclo de entrega. Y al planificar el crecimiento, para saber cuándo se alcanzará el límite actual y con cuánta antelación hay que actuar.
Cómo empezar
El primer paso es definir objetivos medibles y escenarios críticos: inicio de sesión, búsqueda, pago. Luego prepara un entorno lo más parecido posible a producción, porque los resultados en un entorno distinto pueden engañar. Elige una herramienta que se ajuste a tu equipo, como k6, JMeter o Gatling, que permiten simular usuarios y analizar resultados; las que funcionan con scripts, como k6, piden algo de programación, mientras que otras tienen interfaces más visuales. Ejecuta, analiza, busca cuellos de botella, corrígelos y vuelve a medir. Y cuando tengas algo estable, integra versiones ligeras de estas pruebas en el pipeline para detectar degradaciones tempranas.
Los tropiezos habituales son probar tarde, descubriendo los problemas pocos días antes del lanzamiento; usar entornos poco realistas; no tener objetivos claros, de modo que no sabes si un resultado es bueno o malo; simular usuarios que no se comportan como los de verdad; y medir sin investigar la causa. Hacerlas en producción es posible, pero con muchísimo cuidado; lo normal es hacerlas en entornos de prueba para no afectar a usuarios reales.
Si quieres que tu equipo aprenda a diseñar y ejecutar pruebas de rendimiento, pide información en el formulario de contacto y te contamos nuestras capacitaciones.
¡Hasta la próxima!