De lenguaje natural a k6: patrones de prompt que producen scripts mantenibles

Le pediste a la IA que «pruebe la API fuerte» y recibiste un blob JavaScript de cuatrocientas líneas con rutas inventadas, un token hardcodeado y un executor que no coincide con la historia de tráfico que querías contar. El problema no fue el modelo—fue el prompt. Las pruebas k6 en lenguaje natural fallan cuando suenan a deseo vago; las que funcionan parecen tickets de ingeniería: entradas, restricciones y un esqueleto de salida explícito.

Siempre adjunta contexto machine-readable—operaciones OpenAPI, requests de ejemplo o un fragmento de colección. El trabajo del modelo es dar forma a ese contexto en idiomas k6, no descubrir tus rutas privadas ni adivinar auth. En esta guía verás cuatro patrones de prompt reutilizables, cómo revisar output para mantenibilidad y qué anti-patrones convierten borradores útiles en deuda técnica.

Para asistentes opcionales en producto (Google Gemini u otros en planes calificados), la misma estructura reduce respuestas incompletas o incorrectas.

Por qué los prompts vagos producen scripts frágiles

Un prompt sin restricciones empuja al modelo a rellenar huecos con supuestos optimistas:

• Rutas y métodos que no existen en tu spec pero «suenan razonables».
• Auth simplificada—un Bearer estático en lugar de login en setup() con refresh.
• Un solo archivo monolítico con veinte endpoints cuando el journey real tiene cuatro pasos.
• Executors genéricos que no reflejan arrival rate, rampa o soak que necesitas medir.

Piensa en pedirle a un contractor que construya una casa sin planos: obtendrás paredes, pero no la distribución que pediste.

Qué debe incluir todo prompt serio

• Alcance del journey—qué operaciones entran y cuáles quedan fuera de esta iteración.
• Restricciones de entorno—variables (BASE_URL, TOKEN), sin secretos en el output.
• Forma de salida—nombres de funciones, bloques setup, tags por defecto, dónde van los check().
• Artefacto adjunto—fragmento OpenAPI, export Postman o curl que ya funciona en staging.

Cruza el executor elegido con tipos de escenario k6 antes de confiar en el script generado.

Patrones de prompt que escalan en equipos

Patrón A — Journey único

Genera JavaScript k6.
Journey: login → listar pedidos → detalle de pedido.
Restricciones: base URL en variable de entorno BASE_URL, bearer token solo desde login en setup.
Salida: setup, tags por defecto, tres requests envueltos en check, sin secretos hardcodeados.

Cuándo usarlo: smoke funcional, primer borrador desde colección pequeña, gates de CI con un camino crítico.

Patrón B — Barrido parametrizado

Genera un escenario con SharedArray sobre el users.json adjunto (schema descrito).
Cada VU debe usar una fila de usuario distinta módulo longitud.
Incluye sleep uniforme aleatorio entre 1–3 s.

Cuándo usarlo: flujos multipaso donde aislamiento de sesión importa—ver flujos multipaso e IA.

Patrón C — Umbrales primero

Dado SLO: checkout p95 < 600 ms a 50 RPS estables, tasa de error < 0,5 %.
Emite escenario + bloque thresholds; justifica tags usados.

Cuándo usarlo: cuando el objetivo es un gate de release—añade ejemplos de umbrales k6 solo tras smoke limpio.

Patrón D — Inyección de errores

Añade un segundo escenario que fuerce 401/403 en el 5 % de logins para verificar monitoring; mantén el escenario principal limpio.
Documenta por qué existe la rama para que futuros lectores no la borren como «flaky».

Cuándo usarlo: validar alertas y dashboards, no throughput nominal.

Script de ejemplo: salida esperada de un prompt bien formado

Ejemplo (ilustrativo—no es una prueba lista para producción). Muestra la estructura que deberías pedir explícitamente en el prompt.

Qué demuestra este ejemplo:

• setup() centralizado para auth—sin tokens en el cuerpo del script.
• Función de dominio (orderJourney) en lugar de un default function genérico.
• Tags consistentes en escenario y requests para reportes segmentados.
• Constantes con significado de negocio—no números mágicos dispersos.

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

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

export function setup() {
  const res = http.post(
    `${BASE}/auth/login`,
    JSON.stringify({ email: __ENV.TEST_EMAIL, password: __ENV.TEST_PASSWORD }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  check(res, { 'login ok': (r) => r.status === 200 });
  return { token: res.json('accessToken') };
}

export const options = {
  scenarios: {
    orders: {
      executor: 'constant-arrival-rate',
      rate: 10,
      timeUnit: '1s',
      duration: '3m',
      preAllocatedVUs: 5,
      maxVUs: 20,
      exec: 'orderJourney',
      tags: { journey: 'orders' },
    },
  },
};

export function orderJourney(data) {
  const headers = {
    Authorization: `Bearer ${data.token}`,
    'Content-Type': 'application/json',
  };

  const list = http.get(`${BASE}/orders`, { headers, tags: { step: 'list' } });
  check(list, { 'list 2xx': (r) => r.status >= 200 && r.status < 300 });

  sleep(1);

  const id = list.json('items.0.id');
  const detail = http.get(`${BASE}/orders/${id}`, { headers, tags: { step: 'detail' } });
  check(detail, { 'detail 2xx': (r) => r.status >= 200 && r.status < 300 });
}

Marco de decisión: qué patrón elegir

Usa un solo patrón por prompt si quieres difs legibles en review—mezclar A+C+D en un mensaje produce scripts difíciles de mantener.

Versiona el texto del prompt junto al script en git: las pruebas en lenguaje natural evolucionan; los diffs deben mostrar si el comportamiento cambió por código o por instrucciones.

Revisión post-generación: checklist de mantenibilidad

Tras recibir output de la IA, recorre esta lista antes del merge:

• ¿Los nombres de función son de dominio (checkoutFlow) y no genéricos (main)?
• ¿Los números mágicos están en const con comentario de significado de negocio?
• ¿Hay un solo lugar para cambiar base URL y modo de auth?
• ¿El executor coincide con la pregunta de tráfico (RPS vs VUs vs rampa)?
• ¿Los tags permiten segmentar reportes como en observabilidad k6?

Anti-patrones a evitar

• «Resuelve auth tú solo» sin un curl que funcione.
• Pedir todos los endpoints en un archivo—divide por journey para review.
• Confiar en checks status === 200 cuando la API devuelve 202 o cuerpos vacíos.

Si la política lo permite, ejecuta el mismo prompt estructurado en dos proveedores y compara outputs—la divergencia destaca requisitos subespecificados.

Cómo Performate encaja con prompts estructurados

Los prompts bien formados aceleran el loop import → run → refine que Performate optimiza en escritorio.

Ejemplo: de ticket a script revisable en un workspace

1. Importa la colección que adjuntaste al prompt—la fuente de verdad queda visible junto al borrador IA. Problema resuelto: el reviewer compara output contra requests reales, no contra memoria.
2. Pega el patrón A (o B/C) en el asistente con el fragmento OpenAPI o export ya en el proyecto. Problema resuelto: contexto machine-readable sin reescribir rutas a mano.
3. Corre smoke a 1 VU en el runner de escritorio antes de pedir umbrales agresivos. Problema resuelto: separas errores de cableado de errores de SLO.
4. Exporta el script k6 para CI una vez pasada la checklist de mantenibilidad. Problema resuelto: local y pipeline comparten el mismo artefacto revisado.

Alinea la gobernanza del repo con propiedad de scripts generados por IA y generación segura asistida por IA.

Cierre

Las pruebas k6 en lenguaje natural escalan cuando los prompts parecen tickets de spec: contexto, restricciones y forma de salida—y luego k6 impone la realidad bajo carga.

Guarda tu próximo prompt junto al script en el PR y pregúntate si un compañero podría regenerar el mismo comportamiento sin adivinar—si no, el prompt aún es demasiado vago.

Try Performate free | Book a demo | k6 scenarios