El software que funciona no es lo mismo que el software que funciona bajo carga. Una característica puede pasar todas las pruebas funcionales, enviarse limpia y luego ceder la primera vez que llega el tráfico real. Las pruebas de rendimiento son la disciplina que cierra esa brecha: miden cómo se comporta un sistema cuando está ocupado, no solo si es correcto cuando está inactivo.
Esta guía explica qué son las pruebas de rendimiento, los principales tipos, las métricas que definen un resultado y cómo encajan en un proceso de prueba moderno.
Qué son las pruebas de rendimiento
Las pruebas de rendimiento evalúan la velocidad, estabilidad y escalabilidad de un sistema bajo una carga de trabajo definida. No preguntan “¿funciona esta característica?”. Preguntan “¿qué tan rápido es, cuánto puede soportar y qué sucede cuando ha tenido suficiente?”
Esa distinción es importante. Las pruebas funcionales y las pruebas de rendimiento responden a preguntas diferentes y detectan errores diferentes. Un endpoint de inicio de sesión puede devolver el token correcto cada vez y aun así tardar cuatro segundos en hacerlo bajo carga. Las pruebas funcionales pasan; los usuarios se van. Las pruebas de rendimiento son lo que saca a la luz ese segundo problema.
El resultado de las pruebas de rendimiento no es un simple aprobado o reprobado. Es un perfil: con esta carga, el sistema responde así de rápido, mantiene este rendimiento y falla de esta manera una vez que se supera este punto. Ese perfil es lo que permite a un equipo planificar la capacidad, establecer niveles de servicio realistas y detectar regresiones antes del lanzamiento.
Los principales tipos de pruebas de rendimiento
Las pruebas de rendimiento son una familia de tipos de pruebas, cada una aplicando carga de una forma diferente para responder a una pregunta distinta.
Las pruebas de línea base ejecutan el sistema bajo una carga normal y esperada y registran el resultado. Esta línea base es la referencia contra la que se comparan todas las pruebas posteriores. Sin ella, no se puede saber si un número es bueno, malo o simplemente diferente.
Las pruebas de carga aplican el tráfico pico esperado y confirman que el sistema aguanta: los tiempos de respuesta se mantienen dentro del presupuesto, los errores se mantienen cerca de cero. Validan que el sistema sobrevive a un día normal de mucha actividad.
Las pruebas de estrés exceden deliberadamente la capacidad, aumentando la carga hasta que el sistema se degrada o falla. El objetivo es encontrar el punto de ruptura y observar el modo de fallo. Una degradación gradual, más lenta pero que sigue sirviendo, es aceptable; la pérdida de datos o los errores en cascada no lo son.
Las pruebas de pico aplican un salto repentino y pronunciado en la carga y la reducen de nuevo. Modelan ventas flash, eventos de noticias y otros picos. Un sistema optimizado para un tráfico constante aún puede fallar ante un pico porque no puede escalar lo suficientemente rápido.
Las pruebas de capacidad encuentran la carga máxima que el sistema puede manejar mientras sigue cumpliendo sus objetivos. La respuesta es un número concreto, utilizado directamente para la planificación de la capacidad y los umbrales de autoescalado.
Las pruebas de resistencia, también llamadas pruebas de estabilidad o de aguante, mantienen una carga moderada durante un período prolongado para exponer fallos lentos: fugas de memoria, agotamiento de recursos, ralentización gradual. Estos son invisibles en ejecuciones cortas y solo aparecen después de horas.
La mayoría de los equipos ejecutan pruebas de línea base, carga y resistencia como estándar, y añaden pruebas de estrés y pico para sistemas con tráfico alto o impredecible.
Las métricas que definen un resultado
Una prueba de rendimiento solo es útil según las métricas que se lean de ella.
El tiempo de respuesta es la duración desde la solicitud hasta la respuesta. Siempre léalo como una distribución. El promedio es engañoso; un promedio saludable puede ocultar un percentil 99 que es diez veces peor. La cola lenta es lo que los usuarios reales notan y de lo que se quejan.
El rendimiento (throughput) es el volumen de trabajo completado por unidad de tiempo, a menudo solicitudes por segundo. Se calcula como el total de solicitudes dividido por la duración de la prueba y representa la verdadera capacidad del sistema.
La concurrencia es el número de usuarios o conexiones simultáneas. La capacidad del sistema a menudo se indica como el nivel de concurrencia en el que el tiempo de respuesta supera el umbral aceptable.
La tasa de error es el porcentaje de solicitudes que fallan bajo carga. Un sistema que se mantiene rápido pero comienza a fallar solicitudes con alta concurrencia no ha pasado; la velocidad sin fiabilidad no es rendimiento.
La utilización de CPU y memoria explica por qué los otros números se mueven. Si la latencia aumenta mientras la CPU está al 100%, el sistema está limitado por la computación. Si la latencia aumenta mientras la CPU está inactiva, el cuello de botella está en un nivel inferior, generalmente una base de datos, un bloqueo o una dependencia externa.
Un resultado completo se lee como una oración: con esta concurrencia, el rendimiento alcanzó su punto máximo aquí, el tiempo de respuesta del percentil 95 fue este, la tasa de error fue esa, y el servidor estuvo limitado por este recurso.
Dónde encajan las pruebas de rendimiento en el proceso
Las pruebas de rendimiento solían ser una única puerta cerca del final de un proyecto, ejecutadas una vez antes del lanzamiento por un equipo especializado. Ese modelo falla para sistemas que se envían continuamente, porque el rendimiento se degrada con casi cada cambio. Una nueva consulta, una integración añadida, una columna sin indexar, cada una añade silenciosamente una latencia que ninguna prueba funcional detecta.
El mejor modelo trata el rendimiento como la corrección: verificado continuamente, con un presupuesto. Defina un presupuesto de tiempo de respuesta y tasa de error para las rutas críticas. Ejecute una prueba de carga ligera en CI/CD para que una regresión falle la compilación en la solicitud de extracción. Reserve las pruebas de estrés y resistencia pesadas para las pruebas programadas previas al lanzamiento, donde su mayor tiempo de ejecución es aceptable.
Para la mayoría de los sistemas, el lugar de mayor valor para probar el rendimiento es la capa de API. Las API llevan la lógica central, son rápidas y deterministas de llamar, y no tienen una interfaz de usuario inestable con la que luchar. Probar las API bajo carga proporciona números fiables a bajo costo; las pruebas de rendimiento de API cubren ese enfoque específico en detalle. Mantener las pruebas de rendimiento junto con las pruebas de API funcionales significa que cada cambio se verifica tanto por su corrección como por su velocidad a la vez.
Errores comunes en las pruebas de rendimiento
Las pruebas de rendimiento son fáciles de realizar de una manera que produce respuestas confiadas y erróneas. Algunos errores aparecen una y otra vez.
Probar contra una infraestructura poco realista. Una prueba de carga en un ordenador portátil de desarrollador, o contra un entorno de staging con una fracción de los recursos de producción, produce números que no significan nada. Pruebe en una infraestructura que coincida con la producción tan de cerca como pueda permitírselo.
Ignorar los efectos de calentamiento. Muchos sistemas son lentos durante los primeros segundos de una ejecución mientras las cachés se llenan y los grupos de conexiones se abren. Medir el arranque en frío y el estado estable juntos produce un promedio engañoso. Descarte la ventana de calentamiento o infórmela por separado.
Leer promedios en lugar de percentiles. Este error merece repetirse porque es muy común. Un tiempo de respuesta promedio de 200 ms puede ocultar un percentil 99 de tres segundos. El promedio describe una solicitud que nadie hace realmente; los percentiles describen a usuarios reales.
Usar datos poco realistas. Probar cada solicitud con el mismo ID de usuario o el mismo producto significa que la base de datos sirve todo desde la caché. El tráfico real se distribuye por el conjunto de datos, accediendo a filas frías y fallos de caché. Varíe los datos de prueba para que coincidan.
Probar un endpoint de forma aislada. Los usuarios reales se mueven a través de flujos de trabajo: iniciar sesión, navegar, buscar, pagar. Golpear un único endpoint no detecta la contención que aparece cuando varios endpoints compiten por la misma base de datos y grupo de conexiones. Pruebe escenarios multietapa realistas, no solo llamadas individuales.
Tratar la prueba como algo único y terminado. Una única prueba de rendimiento previa al lanzamiento queda obsoleta en el momento en que se envía la siguiente característica. El rendimiento se degrada continuamente, por lo que la prueba también debe ejecutarse continuamente.
Evitar estos seis errores es la mayor parte de lo que diferencia una prueba de rendimiento que informa una decisión de una que produce una marca de verificación verde reconfortante pero sin sentido.
Ejecutar pruebas de rendimiento con Apidog
Apidog integra las pruebas de carga en el mismo espacio de trabajo utilizado para el diseño de API y las pruebas funcionales, por lo que las comprobaciones de rendimiento no requieren una herramienta separada ni una copia separada de la definición de la API.
Usted toma un endpoint o un escenario de prueba de varios pasos, confirma que pasa funcionalmente y luego lo ejecuta bajo un número configurado de usuarios virtuales durante una duración establecida. Apidog aumenta la carga gradualmente y reporta los percentiles de tiempo de respuesta, el rendimiento y la tasa de error en vivo, para que pueda ver el nivel de concurrencia exacto donde el rendimiento cambia. Para cargas más allá de una sola máquina, el escenario se exporta a JMeter manteniendo la misma definición.
Debido a que el mismo escenario de prueba sirve tanto para ejecuciones funcionales como de rendimiento, usted mantiene un solo artefacto en lugar de dos. Descargue Apidog para perfilar un endpoint que ya tiene.
Preguntas frecuentes
¿Cuál es la diferencia entre pruebas de rendimiento y pruebas funcionales? Las pruebas funcionales verifican si el software produce resultados correctos. Las pruebas de rendimiento verifican qué tan rápido y con qué fiabilidad lo hace bajo carga. Ambas son necesarias; ninguna reemplaza a la otra.
¿Qué tipo de prueba de rendimiento debo ejecutar primero? Línea base, luego carga. La línea base le da una referencia en condiciones normales; la prueba de carga confirma que el sistema sobrevive al pico de tráfico esperado. A partir de ahí, añada pruebas de estrés, pico y resistencia.
¿Por qué usar percentiles en lugar del tiempo de respuesta promedio? El promedio se arrastra hacia el medio y oculta la cola lenta. Los percentiles 95 y 99 revelan lo que experimentan las solicitudes menos afortunadas, y esa cola es lo que sienten los usuarios.
¿Se pueden automatizar las pruebas de rendimiento? Sí. Una prueba de carga ligera se ejecuta bien en CI con cada cambio, con un presupuesto definido que falla la compilación en caso de regresión. Las pruebas de estrés y resistencia más pesadas suelen programarse en lugar de ejecutarse en cada commit.
¿Cuándo debería comenzar la prueba de rendimiento en el ciclo de desarrollo? Antes de lo que la mayoría de los equipos piensan. No se pueden obtener los números de latencia finales sin infraestructura real, pero se pueden establecer presupuestos y escribir los escenarios de prueba durante el diseño. Ejecutar una prueba de carga básica tan pronto como un endpoint es funcional detecta problemas cuando son baratos de arreglar.
¿Quién es responsable de las pruebas de rendimiento? En los equipos modernos es una responsabilidad compartida. Los desarrolladores ejecutan comprobaciones de carga ligeras en sus propios cambios; QA es propietario de los escenarios de prueba y presupuestos más amplios; operaciones o SRE proporcionan la infraestructura similar a producción y las métricas del lado del servidor. Tratarlo como el trabajo de un especialista es cómo los problemas de rendimiento llegan a producción.
¿Cuánto tiempo debe durar una prueba de rendimiento? El tiempo suficiente para pasar la ventana de calentamiento y alcanzar un estado estable, generalmente varios minutos para una prueba de carga. Las pruebas de resistencia duran horas o días por diseño, ya que su propósito es exponer la degradación lenta que las ejecuciones cortas no detectan.