Testing de rendimiento para QA: guía con k6 y JMeter

Tu suite de Playwright pasa en verde. 200 tests automatizados dicen que todo funciona. Y aun así, el día del lanzamiento la web se cae en cuanto se conectan 300 personas a la vez.

Eso pasa porque un test funcional responde a una pregunta ("¿funciona?") y un test de rendimiento responde a otra completamente distinta ("¿aguanta?"). La mayoría de formación en automatización, la nuestra incluida, enseña a fondo la primera y casi nunca toca la segunda.

En este artículo vemos qué es el testing de rendimiento, por qué es el hueco más habitual en la formación de un QA que ya sabe automatizar, y cómo dar tus primeros pasos con las dos herramientas más usadas para esto: k6 y JMeter.

Qué es el testing de rendimiento (y en qué se diferencia del funcional)

Un test funcional simula a una sola persona haciendo una sola cosa: entra, rellena un formulario, comprueba que aparece el mensaje correcto. Si pasa, el flujo funciona. Si falla, hay un bug.

Un test de rendimiento simula a muchas personas haciendo eso mismo a la vez, y mide cómo responde el sistema: cuánto tarda, cuántas peticiones fallan, en qué punto deja de aguantar. No busca un bug funcional, busca un límite.

Dentro del testing de rendimiento hay varias familias, y conviene no mezclarlas:

Por qué casi ningún QA lo aprende en su primer año

El motivo es simple: casi toda la formación en automatización de QA se centra en Playwright, Cypress o Selenium, herramientas pensadas para comprobar que algo funciona, no para medir cuánta carga aguanta. El testing de rendimiento suele entrar más tarde, cuando ya hay un producto en producción y alguien empieza a preguntar "¿esto aguantaría un pico de tráfico?".

Eso deja un hueco real, y lo hemos comprobado con datos propios. k6 es una de las tecnologías que nuestro sistema rastrea automáticamente en las ofertas de QA activas en España.

Esto no significa que las empresas no hagan testing de rendimiento (los equipos grandes lo hacen, casi siempre con un perfil de performance engineer o SRE dedicado). Significa que rara vez se lo piden a un QA junior o mid en el propio anuncio, así que tiene sentido aprenderlo cuando ya dominas lo básico, no antes.

k6 vs JMeter: las diferencias reales

Son las dos herramientas más usadas para esto, y parten de dos filosofías distintas.

Tu primer test de carga con k6

k6 se instala como cualquier herramienta de línea de comandos (en Mac, con Homebrew; en Windows y Linux, la documentación oficial trae el paquete para cada sistema). Una vez instalado, un test es un archivo JavaScript:

brew install k6

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 20,
  duration: '30s',
};

export default function () {
  const res = http.get('https://tu-api.com/status');
  check(res, { 'responde 200': (r) => r.status === 200 });
  sleep(1);
}

vus (virtual users) son los usuarios simulados que k6 lanza en paralelo, y duration es cuánto tiempo mantiene esa carga. Este ejemplo simula 20 personas pidiendo /status a la vez durante 30 segundos.

k6 run script.js

Al terminar, k6 imprime un resumen con las métricas clave: http_req_duration (cuánto tarda cada petición), http_req_failed (qué porcentaje falló) y el número real de iteraciones completadas.

Puedes convertir esas métricas en un criterio de aprobación explícito con thresholds, para que el test falle si el rendimiento no cumple lo que has decidido de antemano:

export const options = {
  vus: 20,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

Esto dice: el 95% de las peticiones debe responder en menos de 500 ms, y menos del 1% puede fallar. Si no se cumple, k6 marca el test como fallido, igual que un assert en Playwright.

Lo mismo en JMeter, sin escribir código

JMeter se construye con clicks sobre tres piezas: un Thread Group (define cuántos usuarios simulados y con qué ritmo de subida), un HTTP Request (el endpoint que se llama) y un Listener (dónde ver los resultados, como "Summary Report" o "View Results Tree").

La interfaz gráfica sirve para montar el test, pero no para ejecutarlo de verdad: generar carga real desde la propia GUI consume recursos y distorsiona los resultados. Un test serio se guarda como archivo .jmx y se lanza en modo headless:

jmeter -n -t plan.jmx -l resultados.jtl -e -o informe/

El flag -n fuerza el modo sin interfaz, -t apunta al plan de pruebas, -l guarda los resultados en bruto, y -e -o genera un informe HTML navegable al terminar. Es el mismo test que has diseñado con clicks, pero corriendo sin el peso de la interfaz gráfica.

Qué mirar en los resultados

Un test funcional tiene un resultado binario: pasa o falla. Un test de rendimiento no, entrega una distribución de datos que hay que interpretar. Estas son las métricas que de verdad importan:

• Percentil 95 (p95) de latencia. El promedio engaña: si 95 de cada 100 usuarios esperan 200 ms pero 5 esperan 8 segundos, el promedio parece bueno y la experiencia real no lo es. El p95 muestra lo que sufre el usuario típico con mala suerte.
• Tasa de error. Qué porcentaje de peticiones devuelve un error o no responde. Un sistema que "aguanta" pero devuelve un 20% de errores 500 no está aguantando nada.
• Throughput (peticiones por segundo). Cuánto tráfico real procesa el sistema, no cuánto intentas enviarle. Si mandas 500 peticiones por segundo y solo procesa 80, ahí está tu límite real.
• Punto de ruptura. La carga exacta en la que el sistema deja de responder de forma aceptable. Es el dato que responde a la pregunta que de verdad importa: cuántos usuarios simultáneos aguantamos antes de romper un lanzamiento.

¿Merece la pena aprenderlo si eres junior en QA?

Con honestidad: no es lo primero que debes aprender. Si todavía no automatizas pruebas funcionales con soltura, empieza ahí (puedes ver cómo en tu primer test automatizado con Playwright o en cómo automatizar tests de API con pytest). Eso es lo que sí piden de forma constante las ofertas de QA en España.

Pero una vez tienes eso resuelto, el testing de rendimiento es una de las pocas habilidades que te diferencia de verdad, precisamente porque el dato de antes es real: casi nadie lo trae de fábrica. No hace falta dominarlo a fondo. Con montar un test de carga básico en k6 o JMeter y saber leer un p95, ya vas por delante de la mayoría.