---
title: "Usuarios virtuales, think time y sugerencias de IA: chequeos de sanidad antes de correr"
description: "Revisa VUs y think time cuando la IA sugiere escenarios k6: llegada abierta vs cerrada, distribuciones de sleep y por qué scripts sin pausa engañan a todos."
publishDate: "2026-09-22"
draft: false
keyword: "escenarios prueba carga ia"
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 saltar validación."
tags: ["k6", "pruebas-de-carga", "ia", "performate"]
translationOf: virtual-users-think-time-ai-sanity-checks
---

A la IA le encanta `sleep(0)` y 500 VUs porque impresiona en el script. Luego los stakeholders creen que probaste «500 usuarios» cuando en realidad disparaste **RPS irreal** en un bucle cerrado sin think time—señales de capacidad falsas, fallos falsos y decisiones de release construidas sobre ficción.

Antes de correr cualquier escenario k6 sugerido por IA, revisa el **modelo de executor**, **conteo de VUs vs tasa de llegada** y **distribución de sleep** contra analytics ([executors k6](https://k6.io/docs/using-k6/scenarios/executors/)). Esta guía explica modelos abierto vs cerrado, reglas de think time, un ejemplo k6 browse→cart realista y un checklist de revisión IA que tu equipo puede pegar en cada ticket de perf.

## Modelos abierto vs cerrado

La elección del executor es un **modelo del mundo**, no una preferencia de sintaxis:

- **Cerrado** (`constant-vus`, `ramping-vus`): usuarios concurrentes fijos; el RPS **emerge** del tiempo de respuesta. Si el sistema se ralentiza, cada usuario espera más pero sigue activo—el RPS puede caer O el encolado por usuario aumenta carga de formas que producto no describió.
- **Abierto** (`constant-arrival-rate`, `ramping-arrival-rate`): RPS de negocio fijo; los VUs **escalan** con la latencia. Encaja con «500 pedidos por minuto» o «API checkout a 40 req/s».

Elige el modelo que coincida con cómo producto y analytics describen la carga ([stress vs carga](/es/blog/stress-vs-carga-vs-spike-testing)). Si el ticket dice «500 compradores concurrentes navegando», cerrado puede encajar. Si dice «500 checkouts por minuto», abierto es obligatorio.

### Señales de alerta en borradores IA

- VUs > 10× RPS objetivo sin think time largo—implica requests ametralladora.
- `sleep(0)` en rutas de escritura—revisar siempre.
- `constant-vus` cuando la cita de producto era estrictamente RPS—desajuste de executor.
- Falta `setup()` para auth que la IA quitó «por simplicidad».

## Reglas de think time

El think time moldea el RPS implícito más que el conteo de VUs en modelos cerrados:

- Usa **mediana de tiempo entre clics** desde logs o analytics—no cero porque k6 se sintió lento.
- Añade **jitter**—`sleep(2 + Math.random())` evita olas sincronizadas que crean picos artificiales.
- **Sleeps distintos en lectura vs escritura**—navegar más que POST confirm.
- Documenta think time asumido en el pie del reporte—stakeholders comparan corridas con justicia.

RPS implícito (modelo cerrado, aproximado): `VUs / (avg_response_time + think_time)`. Corre piloto de un minuto y compara RPS implícito con analytics antes de escalar duración.

## Ejemplo k6 de sanidad

**Ejemplo (ilustrativo).** Browse→cart con ARR y think time con jitter.

**Qué demuestra este ejemplo:**

- `constant-arrival-rate` define carga de negocio—la declaración de RPS de producto mapea directamente.
- `preAllocatedVUs` / `maxVUs` como topes—k6 escala VUs sin goroutines ilimitadas en el cliente.
- Sleep con jitter tras browse—ritmo realista, no martilleo sincronizado.
- Tags separados en browse vs cart para segmentación en reportes.

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

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

export const options = {
  scenarios: {
    realistic: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.TARGET_RPS || 20),
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 10,
      maxVUs: 80,
      tags: { ai: 'reviewed' },
    },
  },
  thresholds: {
    'http_req_duration{route:cart}': ['p(95)<900'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get(`${BASE}/browse`, { tags: { route: 'browse' } });
  sleep(2 + Math.random()); // think time ~2–3s
  const res = http.post(`${BASE}/cart`, '{}', {
    headers: { 'Content-Type': 'application/json' },
    tags: { route: 'cart' },
  });
  check(res, { ok: (r) => r.status < 500 });
  sleep(1);
}
```

**Patrones que funcionan**

- **Piloto de un minuto** al executor objetivo—compara RPS implícito y tasa de error antes de corrida de 10m.
- **Bloquear executor en UI** tras borrador IA—el editor visual de Performate evita cambio accidental de modelo.
- **Tag `ai:reviewed`** solo tras paso de sanidad humana—empareja con [seguimiento ROI](/es/blog/roi-flujos-k6-asistidos-ia).
- **Pregunta a producto:** «¿RPS o usuarios concurrentes?»—documenta respuesta en ticket.

**Antipatrones a evitar**

- Correr salida IA cruda en staging compartido a VUs completos—valida piloto primero.
- Usar VUs cerrados para prueba de SLO ARR—desajuste de modelo invalida la historia del umbral.
- Quitar sleeps para «ahorrar tiempo CI»—señal falsa no ahorra nada.
- Confiar en umbrales propuestos por IA sin cruce con doc de SLO.

**Pro tip (comando de ejemplo):** corrida piloto con summary JSON para chequeo de RPS implícito.

```bash
k6 run sanity-browse-cart.js --duration 1m --env TARGET_RPS=20 --summary-export=pilot.json
```

**Qué demuestra este comando:** piloto de un minuto produce conteo de iteraciones y stats de duración—divide iteraciones completadas entre 60 para RPS logrado aproximado vs ARR objetivo antes de comprometer corrida larga.

## Marco de decisión: lenguaje de producto vs executor

| Producto dice | Usar executor | Chequeo de sanidad |
|:---|:---|:---|
| «X req/s» o «pedidos/minuto» | `constant-arrival-rate` | RPS logrado ≈ objetivo |
| «X usuarios concurrentes» | `constant-vus` (a menudo) | RPS implícito vs analytics |
| Paso de tráfico flash | spike `ramping-arrival-rate` | No think cero en escrituras |
| Smoke CI | `per-vu-iterations` | Separado del modelo de carga |

## Checklist de revisión IA

Antes de escalar cualquier escenario sugerido por IA:

- [ ] ¿Producto habla en RPS o usuarios concurrentes? Executor coincide.
- [ ] ¿VUs > RPS sin think time largo? Marcar y corregir.
- [ ] ¿La IA quitó auth/setup? Restaurar desde import Postman.
- [ ] Comparar RPS implícito con capacidad staging y banda de analytics.
- [ ] Think time documentado en ticket y pie de reporte.
- [ ] Tag `ai:reviewed` solo tras sign-off humano ([gobernanza](/es/blog/cuando-no-usar-ia-pruebas-de-carga) donde aplique).

## Cómo Performate apoya chequeos de sanidad antes de escalar

Abajo hay un **ejemplo de flujo concreto** para revisar flujo browse/cart borrado por IA—adapta a tu colección.

**Ejemplo: import → borrador IA → bloqueo humano → piloto**

1. **Importa** colección Postman real—requests browse y cart ordenados. *Problema resuelto:* la IA no puede inventar rutas cuando import es paso obligatorio primero.
2. **Deja que IA borre** estructura de escenario—**bloquea** executor a ARR manualmente en UI. *Problema resuelto:* evita defaults `constant-vus` impresionantes pero incorrectos.
3. **Configura** campos think time desde nota de analytics—2–3s browse, 1s post-cart. *Problema resuelto:* editor visual más rápido que cazar líneas `sleep()` que la IA dispersó.
4. **Corre** piloto 1m; lee RPS logrado en reporte. *Problema resuelto:* detecta errores de modelo antes de reserva de staging de treinta minutos.
5. **Compara** carga implícita con banda de analytics—ajusta rate o sleep. *Problema resuelto:* stakeholders confían en números ligados al lenguaje de producto.
6. **Aplica** tag `ai:reviewed` y corre 5m completo—archiva export para camino de promoción CI. *Problema resuelto:* trazabilidad de auditoría de borrador a corrida aprobada.

Ese flujo mapea directamente al `cta` de este post: publicar más rápido sin saltar validación en VUs, think time y executors.

## Cierre

No corras números crudos de VU de IA. Traduce lenguaje de producto a executors, añade think time con jitter, pilota un minuto y luego escala duración—tag `ai:reviewed` solo tras que un humano apostaría su nombre por la config.

Abre tu último script borrado por IA, comprueba executor vs cita de producto y corre piloto de un minuto antes de la próxima ventana completa de staging.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [ROI flujos IA](/es/blog/roi-flujos-k6-asistidos-ia)