Guía para principiantes en pruebas de carga de APIs: tu primera prueba en 30 minutos

Las pruebas funcionales preguntan si un request devuelve el JSON correcto. Las pruebas de carga preguntan qué pasa cuando docenas de clientes golpean ese endpoint a la vez: se agotan pools de conexión, las cachés arrancan en frío y la cola de latencia se ensancha mientras los promedios siguen normales.

Si nunca corriste una prueba de carga, el tooling puede intimidar. El objetivo de esta guía es una corrida smoke honesta en unos treinta minutos, no un plan de capacidad de producción el día uno.

No necesitas miles de usuarios virtuales para aprender algo útil. Necesitas una pregunta clara, un script mínimo y la disciplina de leer el resumen de k6 antes de subir concurrencia. Recorreremos elegir un objetivo, armar un journey mínimo, correr carga smoke en staging e interpretar números, más las trampas que hacen creer a principiantes que su API es invencible cuando el entorno de prueba mintió.

Por qué tu primera prueba debe ser pequeña y específica

Objetivos ambiguos producen gráficos ambiguos. «Probar la API» no es un objetivo; «¿Login más una lectura de catálogo se mantiene bajo 800 ms de p95 con cinco VUs durante dos minutos?» sí lo es. Pruebas pequeñas te enseñan:

• Si auth, headers y base URLs funcionan bajo repetición—no solo una vez en Postman.
• Cómo se comporta http_req_failed cuando el servidor devuelve 500s bajo concurrencia leve.
• Si staging se parece a producción o es tan chico que los resultados engañan (errores comunes).

Piensa en tu primera corrida como una clase de manejo en un estacionamiento vacío. Aprendes controles; no entras a una autopista en hora pico.

Carga vs funcional vs stress (vocabulario en treinta segundos)

• Carga smoke: pocos VUs, duración corta—sanity check bajo concurrencia leve.
• Prueba de carga: tráfico sostenido a niveles esperados—«¿aguantamos un martes normal?»
• Stress / spike: más allá de picos esperados—«¿dónde se rompe?» (stress vs carga vs spike)

Empieza con smoke. Sube de nivel cuando puedas explicar cada línea del resumen (cómo leer reportes).

Implementación práctica en k6: script smoke de treinta minutos

Abajo un script mínimo: autenticar por iteración, fetch de catálogo, assert de status. Cópialo, apunta API_BASE a staging y corre.

Script de ejemplo (ilustrativo—no listo para producción). Reemplaza URLs, credenciales y umbrales con tu API.

Qué demuestra este ejemplo:

• Checks explícitos para que errores HTTP fallen la corrida visiblemente (checks).
• Concurrencia modesta (ramping-vus)—suficiente para aprender, no para DDoSear staging (cuántos usuarios virtuales).
• Umbrales iniciales que puedes endurecer después para CI (ejemplos de umbrales k6).
• Duración corta (dos minutos) apropiada para una primera corrida de aprendizaje.

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    first_smoke: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '30s', target: 5 },
        { duration: '1m', target: 5 },
        { duration: '30s', target: 0 },
      ],
      tags: { test: 'beginner-smoke' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<800'],
  },
};

export default function () {
  const loginRes = http.post(
    `${BASE}/auth/login`,
    JSON.stringify({ email: __ENV.TEST_USER, password: __ENV.TEST_PASS }),
    { headers: { 'Content-Type': 'application/json' }, tags: { step: 'login' } }
  );
  check(loginRes, {
    'login status 200': (r) => r.status === 200,
    'login returns token': (r) => r.json('access_token') !== undefined,
  });

  const token = loginRes.json('access_token');
  const catalogRes = http.get(`${BASE}/v1/catalog?page=1`, {
    headers: { Authorization: `Bearer ${token}` },
    tags: { step: 'catalog' },
  });
  check(catalogRes, { 'catalog status 2xx': (r) => r.status >= 200 && r.status < 300 });

  sleep(1);
}

Patrones que funcionan

• Un journey crítico por script hasta entender resultados—login + lectura alcanza para el día uno.
• sleep() entre pasos para no stress-testear accidentalmente con think time cero (think time y concurrencia).
• Variables de entorno para secretos—nunca commitees contraseñas en scripts (gestionar entornos y variables).
• Import desde Postman si ya tienes colecciones (Postman a k6 paso a paso).

Antipatrones a evitar

• Saltar a 500 VUs porque «más es realista»—debuguearás ruido, no lógica.
• Ignorar http_req_failed porque «la latencia se veía bien».
• Correr contra producción sin aprobación (ética de pruebas).

Pro tip (comando de ejemplo):

k6 run first-smoke.js -e API_BASE=https://staging.example.com -e TEST_USER=demo -e TEST_PASS=secret

Qué demuestra este comando: las env vars mantienen credenciales fuera del script y permiten reruns con distintos targets.

Marco de decisión: qué hacer con tus primeros resultados

Sube concurrencia si la lógica es estable, fallos casi cero y owners de staging aprueban más carga.

Para y arregla si la tasa de error supera 1 % o ves timeouts—más VUs no aclararán la causa raíz.

Agrega puertas CI solo después de confiar en el script en staging dos veces con resultados similares.

Observabilidad, documentación y próximos pasos

Tu primera corrida es exitosa cuando puedes explicar el resumen a un compañero:

• Escribe la pregunta que probaste y el conteo exacto de VUs y duración.
• Guarda el resumen de terminal o export JSON para comparar la semana que viene.
• Anota diferencias de entorno vs producción (tamaño DB, rate limits, feature flags).
• Lista una mejora para la corrida dos (segundo endpoint, umbral más estricto o mantener la carga más tiempo).
• Lee plantilla mínima de script k6 cuando agregues paths de escritura.

Cómo Performate simplifica tu primera prueba de carga

La fricción del CLI frena a muchos principiantes antes de la primera corrida con sentido. Abajo un flujo concreto para el mismo smoke login + catálogo—adapta nombres de colección a tu API.

Ejemplo: de colección Postman a primera corrida smoke en una sesión

1. Importa tu colección Postman (requests login + catálogo que ya usas en QA manual). Problema resuelto: sin ansiedad de script.js vacío—partes de requests familiares.
2. Crea un escenario en el editor visual—ramping-vus a 5 en 30 segundos, mantén dos minutos. Problema resuelto: la sintaxis del ejecutor es un campo de formulario, no hace falta bucear en la documentación el día uno.
3. Agrega checks de status en el panel de request para que fallos aparezcan en el reporte. Problema resuelto: misma visibilidad que check() sin tipear boilerplate primero.
4. Configura env vars para API_BASE, usuario y contraseña en el panel de secretos del escritorio. Problema resuelto: credenciales fuera de scripts exportados.
5. Corre y abre el reporte integrado—prioriza http_req_failed y p95. Problema resuelto: gráficos legibles en lugar de parsear solo tablas ASCII.
6. Exporta el script k6 generado cuando estés listo para CI o compartir con el equipo. Problema resuelto: aprendizaje en escritorio y automatización en pipeline usan el mismo artefacto.

Ese flujo coincide con el cta de este post: empieza tu primera prueba más rápido con tooling guiado de escritorio en lugar de pelear flags del CLI en el minuto uno.

Cierre

Tu primera prueba de carga no tiene que simular Black Friday. Tiene que responder una pregunta clara con checks explícitos, concurrencia modesta y un resumen que puedas explicar.

Corre el script smoke de arriba contra staging esta semana, anota qué significan p95 y http_req_failed para tu API, y solo entonces decide cuántos usuarios virtuales vienen después.

Try Performate free | Guides | k6 documentation