---
title: "De lenguaje natural a k6: patrones de prompt que producen scripts mantenibles"
description: "Plantillas de prompt para k6: incluye fragmentos OpenAPI, restricciones de ejecución y estructura de salida para que la IA devuelva scripts modulares—no blobs de un solo uso."
publishDate: "2026-07-07"
draft: false
keyword: "patrones prompt lenguaje natural k6"
intent: "MOFU"
cta: "Usa el flujo de escritorio de Performate: imports, corridas k6 y análisis asistido por IA según tu plan, para publicar más rápido sin saltarte la validación."
tags: ["k6", "pruebas-de-carga", "ia", "performate", "natural", "language"]
translationOf: natural-language-to-k6-prompt-patterns
---

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](/es/blog/tipos-escenarios-k6-explicados) 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](/es/blog/flujos-multipaso-ia-k6-concurrencia).

### 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](/es/blog/ejemplos-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.

```javascript
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

| Situación | Patrón recomendado |
|:---|:---|
| Primer borrador desde colección Postman | A — journey único con checks explícitos |
| Carritos, checkout, sesiones por usuario | B — SharedArray + sleep realista |
| Gate de release con SLO publicado | C — umbrales primero, tags justificados |
| Validar alertas de auth o rate limit | D — escenario de error separado y documentado |
| Spec OpenAPI grande sin colección | Bootstrap OpenAPI + patrón A por journey ([OpenAPI e IA](/es/blog/bootstrap-prueba-rendimiento-openapi-ia)) |

**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](/es/blog/k6-observabilidad-metricas-tags)?

**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](/es/blog/propiedad-scripts-k6-generados-ia) y [generación segura asistida por IA](/es/blog/generacion-scripts-k6-asistida-ia-seguridad).

## 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](https://performate.app) | [Book a demo](/demo) | [k6 scenarios](https://k6.io/docs/using-k6/scenarios/)