Las tres preguntas dentro de las pruebas de rendimiento de API
| Capacidad | Cuánto tráfico concurrente admite antes de que la latencia se degrade. Necesita un generador de carga. Ejecútala antes de los lanzamientos y después de cambios de arquitectura. |
| Regresión | Si este pull request hizo una llamada más lenta de lo que era. Necesita una línea base y una comparación, no alta concurrencia. |
| Corrección | Si la respuesta es correcta, incluso con entradas incómodas. Necesita aserciones sobre los cuerpos de respuesta. La más barata de las tres y la que más se suele omitir. |
Por qué la regresión es la que conviene automatizar primero
Las pruebas de capacidad son caras de ejecutar y rara vez cambian entre lanzamientos. La regresión de rendimiento es lo contrario: ocurre poco a poco, un pull request a la vez, y cuando una prueba de capacidad la detecta, tienes delante seis meses de cambios acumulados y ninguna pista de cuál fue.
Una simple comparación de tiempos por llamada contra una línea base, ejecutada en cada cambio, detecta la consulta diez veces más lenta el mismo día en que entra. Eso vale más que un informe de capacidad trimestral.
La corrección como base
Ninguna cifra de tiempos significa nada si las respuestas son incorrectas. Un endpoint que devuelve un array vacío es extremadamente rápido. Suena obvio, y es exactamente así como un servicio llega a producción con un filtro roto y unas gráficas de latencia excelentes.
Así que el orden es corrección, luego regresión y luego capacidad. La mayoría de los equipos lo hace al revés porque las pruebas de capacidad son las que parecen trabajo de rendimiento.
Qué aporta la cobertura generada
Los planes de pruebas de API incluyen casos límite y casos de tipo estrés, que sacan a la luz las combinaciones de entrada que vuelven lento un endpoint por una razón estructural y no por carga. Una consulta que se degrada con un tamaño de página grande aparecerá aquí mucho antes de que la encuentre una prueba de capacidad.
Eso no son pruebas de carga ni las sustituyen. Es la capa barata que va debajo.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.
La sesión, el estado, el orden y la limpieza se explican en la documentación de pruebas de API.
Dónde suele estar la regresión
Cuando un endpoint se vuelve más lento entre lanzamientos, la causa casi siempre es una de tres cosas, y conocerlas acorta bastante la búsqueda.
Una consulta que perdió su índice, o que ganó una condición que el índice no cubre. Esta es por mucho la más común y produce un cambio invisible en el diff, porque el SQL se ve bien.
Una llamada que antes era un solo viaje de ida y vuelta y ahora son varios, normalmente porque una función auxiliar empezó a traer los registros relacionados uno por uno dentro de un bucle. El código se lee mejor que antes, y por eso pasa la revisión.
Algo que creció. Una respuesta que incluye una colección que antes tenía cinco elementos y ahora tiene quinientos, porque el producto tuvo éxito. Nada se rompió, y el endpoint ahora es lento para todo el mundo.
Cadencia
Dos caminos, y la decisión depende en realidad de quién es dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu build ya emite. Añadir un paso de GitHub Actions pone la comprobación en el repositorio, donde se revisa como el resto del build.
Cuál de las tres cubre TestSprite
La tercera, la corrección, y los casos límite que sacan a la luz la lentitud estructural. Una consulta que se degrada con un tamaño de página grande aparece como un caso límite fallido o lento mucho antes de que una prueba de capacidad llegue a ella, y por una fracción del costo.
La cobertura sale de API Discovery más tu especificación, con planes que abarcan las categorías funcional, de esquema, de autorización, de manejo de errores y de límites. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables lleva valores de una llamada a otra, Dependency Chains deriva el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que creó la ejecución.
Lo que obtienes es la capa que le falta a la mayoría de los programas de rendimiento: algo que se ejecuta en cada pull request y que notaría un endpoint devolviendo resultados vacíos, que es justo el fallo que una gráfica de throughput reporta como excelente.
¿TestSprite mide la latencia?
Verifica la corrección, no la capacidad. Los tiempos y el throughput bajo concurrencia sostenida requieren una herramienta de rendimiento dedicada.
¿Qué es una línea base razonable?
Tus propias cifras anteriores en el mismo entorno. Los objetivos absolutos tomados de otros productos dicen muy poco.
¿Las pruebas de rendimiento deberían bloquear un merge?
Una regresión grande en una ruta crítica, sí. Una variación pequeña, no, o pasarás el tiempo ajustando umbrales en vez de entregando.
¿Por qué varían tanto nuestras cifras?
Normalmente por un entorno compartido, una caché fría o un volumen de datos distinto. Controla eso antes de confiar en cualquier comparación.
¿Puede una sola herramienta cubrir las tres?
Algunas lo prometen. En la práctica, la pregunta de capacidad necesita un generador de carga y la de corrección necesita aserciones sobre los cuerpos de respuesta, y hacer bien ambas cosas en una misma ejecución es más raro de lo que sugiere el marketing.
Corrección, luego regresión y luego capacidad.
Las pruebas de rendimiento de API son tres preguntas con tres respuestas. La regresión es la que conviene automatizar en cada cambio, la corrección es la base que sostiene todo lo demás, y la capacidad es la cara, la que la mayoría de los equipos aborda primero.