PRUEBAS DE RENDIMIENTO

Un software puede funcionar de forma impecable en lo funcional y aun así decepcionar a quienes lo usan. El login tarda de pronto varios segundos, una función de búsqueda responde con retraso cuando la carga aumenta o la aplicación entera se vuelve inestable en cuanto varios miles de usuarios acceden al mismo tiempo. Las pruebas funcionales no sacan a la luz este tipo de problemas. Para quienes desarrollan, las pruebas de rendimiento aportan por eso indicios concretos sobre dónde se forman los cuellos de botella técnicos y cómo repercuten los cambios del sistema en su capacidad de respuesta.

Este artículo ofrece una guía práctica para asegurar el rendimiento del sistema de forma planificable. Estos son los temas centrales:

• Tipos de prueba comparados: el uso preciso de load testing, stress testing, soak testing y spike testing
• Métricas relevantes: desde el uso de recursos en el backend hasta las Core Web Vitals en el frontend
• Infraestructura de prueba: buenas prácticas para construir entornos y escenarios de carga realistas
• Enfoque shift-left: la integración temprana de las pruebas de rendimiento en pipelines CI/CD y procesos DevOps

QualityOne ofrece las pruebas de rendimiento tanto como servicio independiente como dentro del modelo TaaS (Testing as a Service). De este modo, las empresas pueden aprovechar conocimiento especializado en pruebas y la infraestructura técnica necesaria sin mantener de forma permanente un equipo propio de performance testing para cada ensayo de carga.

Los problemas de rendimiento empiezan mucho antes de la caída

Una caída total del sistema es solo la forma más llamativa de un mal rendimiento. Mucho antes pueden aumentar los tiempos de respuesta, ralentizarse las consultas a la base de datos o consumir cada vez más recursos determinados servicios.

Sin mediciones dirigidas, esa evolución pasa fácilmente desapercibida. Un performance check crea una referencia comparable y reproducible: ¿cómo se comporta el mismo software con 100, 1.000 o 10.000 accesos simultáneos? ¿A partir de qué carga baja la capacidad de respuesta? ¿Y qué componente provoca el retraso?

Por qué un mal rendimiento afecta de forma directa a quienes desarrollan

Si un cuello de botella se descubre poco antes del go-live o incluso a través de los clientes, el esfuerzo de diagnóstico se dispara. El equipo de desarrollo tiene que averiguar entonces, y bajo presión de tiempo, si la causa está en el código, en la base de datos, en la infraestructura o en un servicio conectado.

Unas pruebas de rendimiento previstas desde el principio aportan, en cambio, valores medidos que pueden asignarse a versiones y cambios concretos. Las optimizaciones dejan así de ser una suposición y pueden verificarse repitiendo la prueba.

De los tiempos de carga largos a la caída del sistema

No todo problema de rendimiento provoca de inmediato un crash. A menudo lo primero que empeora es la experiencia de uso: las páginas se construyen más despacio, una app responde con retraso o un proceso tarda bastante más de lo habitual.

Para el usuario final, la causa técnica apenas cuenta. Solo percibe que un sitio web o una aplicación responde mal. Si esto se repite, la satisfacción del cliente y, en última instancia, la percepción de la marca pueden resentirse.

¿Qué son las pruebas de rendimiento?

El performance testing pertenece a las pruebas no funcionales. La cuestión central no es si una función devuelve el resultado correcto, sino cómo se comporta el sistema bajo condiciones definidas. En QualityOne ponemos el foco sobre todo en la capacidad de respuesta y la estabilidad bajo carga.

Para ello se genera carga artificial y se mide después cómo reacciona el software. Según el objetivo, se aplican distintos escenarios de carga y procedimientos de prueba.

Performance check: ¿cuánto rinde realmente la aplicación?

Un performance check puede servir primero para registrar el estado actual. Para ello se fijan requisitos medibles y se ejecutan los procesos típicos bajo una carga definida.

Un ejemplo: una consulta de búsqueda debe responderse en menos de dos segundos en al menos el 95 por ciento de los casos con 500 usuarios en paralelo. Solo con una exigencia así pueden hacerse después valoraciones sólidas.

Las pruebas de rendimiento miden más que la velocidad

El tiempo de respuesta medio es solo un valor entre muchos. También cuentan los picos, las tasas de error, el throughput y el uso de recursos.

Un sistema puede, por ejemplo, responder con rapidez mientras hay pocos usuarios activos y consumir en cambio una cantidad desproporcionada de memoria a medida que la carga crece. Las pruebas de rendimiento hacen visibles esas relaciones.

¿Qué valores permiten evaluar el rendimiento con fundamento?

Una medición útil combina valores de distintos niveles. Solo así puede distinguirse si el cuello de botella se produce en la propia aplicación, en la infraestructura o en el trayecto hasta el usuario.

Tiempos de respuesta y de carga desde la óptica del usuario

Los tiempos de respuesta miden, por ejemplo, la duración de una petición a una API o de una transacción. En las aplicaciones de navegador se añaden otros valores y otras posibles fuentes de error, porque el rendering, el JavaScript y los contenidos cargados después influyen en la velocidad percibida. También hay que tener en cuenta los timeouts y los errores de carga que solo aparecen durante el rendering en el navegador. Aquí desempeñan un papel central las métricas estandarizadas de frontend como las Core Web Vitals (por ejemplo, Largest Contentful Paint, Interaction to Next Paint o Cumulative Layout Shift). Sobre todo en las aplicaciones web conviene por ello distinguir entre el rendimiento del backend y el comportamiento real en el navegador. Herramientas modernas como k6 admiten además mediciones basadas en navegador junto al testing basado en protocolo.

Interpretar correctamente throughput, transacciones y carga

El throughput muestra qué volumen de peticiones o transacciones procesa un sistema dentro de un periodo. Este valor resulta interesante sobre todo en relación con una carga creciente.

Si el throughput se mantiene casi invariable pese a sumar usuarios mientras los tiempos de respuesta suben, eso apunta, por ejemplo, a que un recurso ha alcanzado su límite de capacidad.

Uso de recursos en los servidores y en la aplicación

La carga de CPU, la memoria, las conexiones a la base de datos, el tráfico de red o los thread pools ofrecen pistas sobre por qué decae el rendimiento. Por eso las herramientas de monitoring complementan los valores del propio generador de carga.

Así el equipo de desarrollo no solo ve que una petición tarda de repente cinco segundos. Al mismo tiempo puede comprobar qué ocurrió dentro del sistema durante ese periodo.

Los acuerdos de nivel de servicio como exigencia medible

Los acuerdos de nivel de servicio pueden recoger requisitos concretos de disponibilidad y rendimiento. También sirven de base los objetivos internos o los criterios técnicos de aceptación. Para una valoración inequívoca, una prueba de rendimiento necesita esos umbrales. Sin ellos genera datos, pero no una afirmación clara de pass o fail sobre si el rendimiento cumple los requisitos previstos. Para crear una base de evaluación vinculante para todas las partes vale esta regla: las especificaciones de rendimiento deben documentarse en un plan de pruebas.

Los tipos de prueba más importantes en el performance testing

No todo ensayo de carga persigue el mismo objetivo. Los distintos tipos se diferencian sobre todo en la intensidad y la duración con que se exige al sistema.

Load testing: qué revelan las pruebas de carga sobre el uso normal

En el load testing se somete la aplicación a una carga previsible o que aumenta de forma escalonada. El equipo de desarrollo averigua así si el sistema se mantiene dentro de los valores de rendimiento fijados también con muchos usuarios en paralelo.

En QualityOne usamos las pruebas de carga, entre otras cosas, para hacer visibles a tiempo los límites de carga y los puntos débiles de la aplicación, la base de datos, el hardware y la infraestructura de red.

Stress testing: comprobar el comportamiento bajo una carga excepcionalmente alta

El stress testing expone el sistema a una carga por encima de la operación normal y examina su estabilidad y su comportamiento en esa situación extrema. Una prueba así provoca a veces de forma deliberada el apagado de un servidor, por ejemplo como mecanismo de protección para no abrir brechas de seguridad en caso de sobrecarga. Después se comprueba si el sistema vuelve a arrancar de manera segura y robusta y regresa por sí mismo a un estado estable. Si lo que se busca es determinar el límite máximo de carga o breaking point, puede añadirse una prueba de breakpoint.

Spike testing: ¿qué ocurre ante un salto de carga repentino?

Las pruebas de spike no generan una carga que sube despacio, sino saltos bruscos. Un caso de uso típico sería una campaña de venta tras cuyo arranque muchísimos usuarios entran a la vez en un sitio web en cuestión de minutos.

La prueba muestra, entre otras cosas, con qué rapidez reaccionan el autoescalado, las colas u otros mecanismos de protección ante ese pico repentino.

Endurance testing y pruebas de soak para cargas prolongadas

Algunos problemas de rendimiento solo aparecen tras un tiempo largo de ejecución. Por eso, en el endurance testing o en las pruebas de soak la aplicación se somete durante un periodo prolongado a una carga constante o con oscilaciones realistas. Así puede comprobarse si el sistema permanece estable también en funcionamiento continuo.

De este modo salen a la luz problemas que avanzan poco a poco y que las pruebas cortas no detectan, como fugas de memoria, colas que crecen sin freno o conexiones que no se liberan correctamente.

Scalability testing y prueba de capacidad: ¿hasta dónde puede crecer el sistema?

El scalability testing se ocupa de saber en qué medida los recursos adicionales se traducen realmente en más rendimiento. Si se duplica, por ejemplo, la capacidad de servidor, debería poder seguirse qué efecto tiene eso sobre el throughput y los tiempos de respuesta.

Una prueba de capacidad se fija más en la capacidad disponible en sí: ¿cuántos usuarios, transacciones o volúmenes de datos puede asumir el sistema actual antes de superar los umbrales fijados?

¿Qué aportan las pruebas de rendimiento a quienes desarrollan?

Los resultados medibles acortan la búsqueda de problemas de rendimiento. En lugar de optimizar componentes sueltos por intuición, el equipo de desarrollo puede actuar allí donde las pruebas y el monitoring muestran anomalías.

Detectar cuellos de botella antes de que salgan caros en producción

Una consulta lenta a la base de datos apenas llama la atención con diez usuarios de prueba. Bajo carga alta, en cambio, puede bloquear cientos de procesos en paralelo.

Las pruebas de carga crean esas condiciones de forma controlada. Después puede analizarse qué consultas, servicios o recursos llegan antes a su límite.

Comprobar el rendimiento de los microservicios por separado y en conjunto

En una arquitectura de microservicios, una transacción se reparte a menudo entre varios componentes. Una respuesta lenta no tiene por qué proceder, por tanto, del servicio con el que interactúa directamente el usuario. El performance testing puede comprobar APIs aisladas y, a continuación, cadenas de proceso completas. Así puede verse si el problema surge en un microservicio concreto o en la interacción entre varios sistemas. Identificar los endpoints lentos mejora la experiencia de uso, porque esos cuellos de botella pueden optimizarse de forma dirigida antes de que frenen todo el proceso de la transacción.

Descubrir fugas de memoria y consumo creciente de recursos

Las fugas de memoria no suelen notarse de inmediato. El consumo crece paso a paso hasta que, en algún momento, la aplicación se vuelve más lenta o inestable.

Las pruebas de larga duración crean condiciones en las que esa evolución resulta más visible. Lo mismo vale para los pools de conexiones, los threads y otros recursos limitados.

Evaluar el rendimiento desde la óptica del usuario final

Los valores del backend por sí solos no reflejan toda la experiencia de uso. Por eso las pruebas basadas en navegador pueden analizar además cómo se comporta una aplicación desde la perspectiva del usuario final.

Esta forma de testing une el rendimiento técnico con la experiencia de uso: ¿cuánto tiene que esperar una persona, en las condiciones simuladas, hasta que los contenidos que necesita están disponibles y son manejables?

Shift-left: integrar el performance testing en CI/CD y DevOps

El rendimiento no tiene por qué comprobarse únicamente en grandes pruebas de carga poco antes de un release. Al contrario, la recomendación es clara: las pruebas de rendimiento deberían realizarse varias veces a lo largo de todo el proceso de desarrollo y ser obligatorias antes de cada nuevo deployment. Para ello pueden emplearse ya en fases tempranas pruebas más pequeñas y de ejecución rápida. Este planteamiento, conocido en el sector como shift-left performance testing, desplaza el control de calidad hacia el principio del ciclo de desarrollo.

CI/CD: no dejar la prueba de rendimiento para el final

En una pipeline CI/CD pueden ejecutarse automáticamente pruebas de rendimiento seleccionadas después de cada build o cambio. Eso permite una comprobación continua de los endpoints y los procesos importantes.

Herramientas como k6 ofrecen integraciones explícitas con CI/CD; JMeter también puede incorporarse a procesos de integración continua mediante las herramientas de build e integración correspondientes.

Las baselines de rendimiento hacen visibles los cambios

Un valor aislado dice poco mientras le falte una referencia con la que compararse. Las baselines crean esa referencia.

Si una API necesitaba en la versión 1.8 una media de 180 milisegundos y tras un cambio pasa de pronto a 310 milisegundos, la regresión queda a la vista, aunque ambos valores sigan por debajo de un umbral formal.

Comprobación del rendimiento antes del go-live

Antes de grandes releases, migraciones o lanzamientos de producto con mucha promoción pueden tener sentido pruebas de carga más amplias. Aquí importa menos cada commit concreto que la pregunta de si el sistema en su conjunto está preparado para las condiciones previstas.

Una prueba así debería trabajar con perfiles de carga realistas y con una infraestructura lo más parecida posible a la de producción.

Construir un entorno de performance testing realista

El valor informativo de una prueba depende en buena medida de su entorno. Un sistema de prueba pequeño puede comportarse de forma completamente distinta a una arquitectura de producción distribuida. Para obtener resultados consistentes y reproducibles suele ser conveniente un entorno de prueba controlado y, a ser posible, separado.

Escenarios de carga tomados de la práctica en lugar de cifras de usuarios arbitrarias

«10.000 usuarios» no es todavía un modelo de carga utilizable. En la práctica, las personas usan funciones distintas y provocan con ello cargas de intensidad muy distinta. Un planteamiento realista refleja por eso los casos de uso típicos: una parte de los usuarios inicia sesión, otros buscan productos, descargan datos o ejecutan transacciones. De ahí surge un perfil de carga bastante más cercano al uso real.

Un error clásico es aquí el caching. Si en una prueba de carga se emplean una y otra vez peticiones y datos de prueba idénticos, los mecanismos de caché de los distintos niveles pueden atender una proporción irrealmente alta de las peticiones. Con una parametrización adecuada y datos de prueba suficientemente variados se evita que la prueba mida sobre todo el rendimiento de la caché en lugar del comportamiento real del sistema.

¿Cuánto debe parecerse el entorno de prueba al de producción?

Un entorno de performance testing no tiene por qué ser una copia completa del entorno de producción. Las diferencias relevantes, eso sí, deben conocerse.

Menos CPU, bases de datos más pequeñas u otras capacidades de red cambian el resultado. Esas desviaciones hay que tenerlas en cuenta al interpretar los datos, en lugar de trasladar sin más los valores de prueba a la producción.

Las herramientas de monitoring muestran dónde se forma el cuello de botella

El generador de carga describe el efecto; el monitoring ayuda a buscar la causa. Ambas perspectivas deberían juntarse.

Quien observa a la vez los tiempos de respuesta crecientes, los valores de CPU, las métricas de base de datos y el uso de memoria puede asignar las anomalías con mayor rapidez a un componente concreto del sistema.

Herramientas de performance testing: ¿cuáles encajan en el proyecto?

La oferta de herramientas de performance testing va desde proyectos de código abierto consolidados hasta soluciones comerciales muy completas. Qué herramienta conviene depende de la arquitectura, los protocolos, el alcance de las pruebas, el grado de automatización y los conocimientos disponibles en el equipo.

Elegir las herramientas según la aplicación y los requisitos

Lo primero es aclarar qué se va a someter a carga: APIs HTTP, microservicios, un sitio web clásico, bases de datos o procesos completos de navegador.

A eso se suman las preguntas sobre la carga necesaria, la integración con CI/CD, el reporting y la colaboración entre desarrollo y equipo de rendimiento. Un procedimiento de record and replay también puede ayudar a construir determinados flujos.

Herramientas de código abierto: JMeter y k6 para pruebas de rendimiento

Apache JMeter es una herramienta de código abierto para generar carga y medir el rendimiento. Además de HTTP/HTTPS, y con ello por ejemplo servicios web REST y SOAP, JMeter admite entre otros JDBC, JMS, FTP y otros protocolos e interfaces. Los flujos web pueden grabarse y desarrollarse después hasta convertirlos en planes de prueba repetibles; las pruebas de carga amplias se ejecutan normalmente en modo CLI.

k6 también es de código abierto y está muy orientado a los flujos de trabajo de desarrollo. Las pruebas se crean mediante scripts; además de las pruebas de carga clásicas, k6 admite entre otros escenarios de stress, spike y soak, así como mediciones de rendimiento basadas en navegador e integración con CI/CD.

Performance engineering en lugar de reparación de rendimiento

Quien busca problemas de rendimiento solo después de una caída se dedica sobre todo a corregir errores. El performance engineering empieza antes. Incorporar pronto al equipo de performance testing puede reducir los costos de corrección, porque las debilidades de arquitectura y diseño suelen ser más fáciles de subsanar en las fases tempranas del desarrollo.

Mirar el rendimiento a lo largo de todo el ciclo de vida del desarrollo (SDLC)

En el sector se habla aquí del Software Development Life Cycle (SDLC). Los requisitos de rendimiento pueden tenerse en cuenta en ese ciclo ya en la arquitectura y el diseño. Durante el desarrollo siguen mediciones más pequeñas, después pruebas de carga más amplias y, en operación, el monitoring. Así surge una visión continua del rendimiento del sistema. Los equipos DevOps pueden seguir los cambios a lo largo de varias versiones y detectar antes las desviaciones.

Los casos de uso determinan qué rendimiento se necesita realmente

No todo software necesita los mismos valores de rendimiento. Un sistema interno de gestión con 50 usuarios plantea exigencias distintas a las de un portal público de clientes con varios miles de accesos simultáneos.

La forma y la frecuencia de uso también cuentan. El objetivo no es, por tanto, el «máximo rendimiento», sino un rendimiento acorde con los requisitos y los escenarios de carga reales.

Realizar pruebas de rendimiento con el TaaS de QualityOne

El performance testing exige conocimiento específico, herramientas adecuadas y recursos suficientes para generar carga realista y evaluar los resultados con criterio técnico. El planteamiento de recurrir para ello simplemente a la automatización de pruebas clásica falla en la práctica. El enfoque técnico del performance testing es completamente distinto, ya que en la automatización clásica el foco principal está en la interfaz de usuario (UI/GUI). Justo aquí encaja nuestro modelo TaaS (Testing as a Service) de QualityOne, en el que el performance testing es uno de los componentes centrales.

Por qué el TaaS encaja especialmente bien en el performance testing

Muchas empresas no necesitan pruebas de carga amplias a diario. Mantener de forma permanente un equipo propio de performance testing con conocimiento especializado de herramientas y la infraestructura de prueba correspondiente puede resultar por eso desproporcionado. Al mismo tiempo, con cargas altas hay que tener en cuenta también la infraestructura de generación de carga: según la herramienta, el script de prueba y el hardware, la CPU, la memoria o el throughput de red del propio generador pueden convertirse en el cuello de botella y falsear los resultados.

Si una sola instancia no basta para el escenario de carga previsto, la carga puede repartirse entre varios generadores. El distributed testing, en local, en remoto o sobre infraestructuras cloud, permite reproducir de forma controlada y escalable también escenarios de carga muy amplios.

A través del TaaS, esas capacidades especializadas se incorporan en función del proyecto. El equipo interno puede concentrarse en el desarrollo y la optimización técnica, mientras QualityOne planifica, ejecuta y evalúa las actividades de prueba acordadas. Qué herramientas, perfiles de carga e infraestructuras se emplean depende de los requisitos de cada proyecto.

Del requisito a la evaluación: performance testing con QualityOne

Al principio está la pregunta de qué carga debe soportar una aplicación en la práctica. De ahí se derivan objetivos concretos, tipos de prueba y perfiles de carga.

En el paso siguiente se define el entorno de prueba adecuado, se implementa el escenario y se aumenta la carga de forma controlada. Después evaluamos en detalle los tiempos de respuesta, el uso de recursos, las tasas de error y otros valores para juzgar con fundamento la capacidad de respuesta, la estabilidad y los límites de carga del sistema.

Desarrollo y equipo de rendimiento trabajan con los mismos resultados

El modelo TaaS no exime al equipo de desarrollo de su responsabilidad sobre el código y la arquitectura. Su utilidad está más bien en aportar hallazgos sólidos y reproducibles.

Nuestro equipo de performance testing puede documentar con precisión, por ejemplo, que a partir de un determinado número de transacciones en paralelo el tiempo de respuesta de un servicio sube con fuerza o que la base de datos se convierte en el cuello de botella. El equipo de desarrollo puede optimizar después de forma dirigida. Una nueva prueba muestra si el cambio ha supuesto realmente una mejora.

Así la prueba de rendimiento deja de ser un veredicto externo y se convierte en un proceso ágil y técnico de retroalimentación entre pruebas y desarrollo.

Conclusión: las pruebas de rendimiento aportan datos sólidos en lugar de suposiciones

Un buen rendimiento no se deduce solo de un código limpio. Únicamente en condiciones realistas se ve cómo maneja un software una carga creciente, muchos usuarios en paralelo y grandes volúmenes de datos. Load testing, stress testing, spike testing, soak testing y otros tipos de prueba hacen visibles distintos límites de carga y aportan puntos de partida concretos para optimizar.

Quien además integra las comprobaciones de rendimiento en los procesos CI/CD y DevOps siguiendo un enfoque shift-left puede detectar el deterioro ya durante el desarrollo. Las pruebas de carga más amplias antes del go-live complementan ese control continuo y verifican si el sistema en su conjunto está preparado para la operación prevista.

Con su modelo TaaS, QualityOne permite a las empresas incorporar el performance testing a sus procesos de desarrollo según lo que necesiten. Los equipos de desarrollo aprovechan competencia adicional en pruebas, infraestructura de carga en la nube y valoraciones trazables, sin tener que construir de forma permanente todos esos recursos por su cuenta. QualityOne asume las actividades de prueba que correspondan a cada proyecto; el equipo de desarrollo recibe los valores precisos con los que analizar los cuellos de botella de forma dirigida y verificar las mejoras.

Preguntas frecuentes sobre las pruebas de rendimiento

¿Pueden incluirse APIs externas y sistemas de terceros en las pruebas de rendimiento?

Técnicamente es posible, aunque no debería generarse carga sobre sistemas ajenos sin comprobarlo antes. Los proveedores externos pueden tener límites de peticiones o restringir las pruebas de carga por contrato. En esos casos, los servicios externos pueden simularse o sustituirse por sistemas de prueba (mocking). Para la planificación conviene aclarar de antemano qué sistemas pueden someterse a carga.

¿Qué influencia tienen la ubicación y la conexión de red en las pruebas de rendimiento?

La latencia, el ancho de banda y la distancia geográfica pueden influir notablemente en el rendimiento percibido. Para aplicaciones de uso internacional es por ello imprescindible generar carga desde distintas regiones (distributed testing) o reproducir diferentes condiciones de red. Así puede valorarse mejor qué tiempos de respuesta experimentan realmente los usuarios en cada lugar.

¿Cuántos datos de prueba hacen falta para unas pruebas de rendimiento realistas?

Depende mucho de la aplicación. Una base de datos con unos pocos cientos de registros puede dar tiempos de respuesta distintos a los de un sistema con varios millones. Además del volumen, cuentan su estructura y una variedad alta para evitar los efectos del caching. Si los grandes volúmenes de datos son lo habitual en producción, hay que tenerlo en cuenta al planificar las pruebas.

¿Puede lanzarse sin más una prueba de carga contra un sistema productivo accesible desde internet?

Está totalmente desaconsejado hacerlo sin acuerdo previo. Una prueba de carga puede afectar a usuarios reales, activar sistemas automáticos de protección (por ejemplo, la protección antiDDoS) o, en el peor de los casos, provocar ella misma caídas. A eso se suman los posibles efectos sobre servicios conectados y los costos de infraestructura según uso. Las pruebas en el entorno de producción deben prepararse por ello técnica y organizativamente y delimitarse con claridad (por ejemplo, en franjas de poco tráfico).