Criterios de aprobación en pruebas de carga: cómo fijarlos

Los criterios de aprobación en pruebas de carga son los pocos límites que una ejecución debe cumplir para darse por aprobada: un percentil de latencia para las peticiones que esperan los usuarios, una tasa de errores y una tasa mínima de peticiones, todo con una carga determinada. Saca los límites de un objetivo de nivel de servicio (SLO), coloca dentro de ellos límites de regresión tomados de ejecuciones anteriores y deja que el código de salida de la herramienta haga fallar la ejecución solo por esos límites estrictos. Todo lo demás es un aviso que lee una persona.

Los datos sobre las herramientas se comprobaron el 9 de octubre de 2026 en la documentación de cada proyecto, y cada límite que aparece es un ejemplo.

¿Qué hace que una prueba de carga se apruebe o falle?

Una ejecución se aprueba cuando todos los límites estrictos se cumplen con la carga prevista, y falla en cuanto uno no se cumple. No es válida cuando la propia prueba no hizo su trabajo, digan lo que digan los números.

Un generador de carga saturado, una carga que nunca llegó a su objetivo o un script con errores producen números sobre el montaje de la prueba. LoadFocus, por ejemplo, muestra un aviso de saturación del generador de carga cuando algún motor alcanzó o superó el 80 % de CPU en su pico. Los códigos de salida de k6 separan los casos para la CI: 99 indica umbrales incumplidos y 107 una excepción en el script (comprobado el 9 de octubre de 2026).

¿Cómo se convierte un SLO en criterios de prueba de carga?

Reformula cada SLO que la carga puede romper, normalmente latencia y disponibilidad, como un límite sobre lo que mide la prueba, y hazlo más estricto que el SLO para que aprobar deje margen.

El libro de SRE de Google define un SLO como un valor objetivo o un rango de valores para un nivel de servicio medido por un indicador (SLI), con ejemplos como: el 99 % de las llamadas Get terminan en menos de 100 ms. Pide que un SLO diga cómo se mide y en qué condiciones es válido, y recomienda un margen de seguridad: un objetivo interno más estricto que el que se promete a los usuarios.

En una prueba de carga, esas condiciones son la carga y la mezcla de peticiones. «El 95 % de las llamadas de pago en menos de 500 ms» podría convertirse, por ejemplo, en «p95 del pago por debajo de 400 ms con 300 peticiones por segundo durante 15 minutos». Si aún no hay SLO, acuerda uno provisional con el responsable de producto.

¿Qué métricas deben cubrir los criterios?

La latencia de las peticiones que esperan los usuarios, una tasa de errores, la tasa de peticiones alcanzada y, sobre todo como avisos, los recursos de los servidores.

• Latencia por tipo de petición. Un percentil global mezcla un health check rápido con una búsqueda lenta. En k6, las peticiones etiquetadas crean submétricas con sus propios límites; en Gatling, details() apunta a una petición o un grupo. Una prueba que frenó su propia carga da percentiles demasiado favorables (coordinated omission).
• Errores, en sentido amplio. Un 200 rápido con una página de error sigue siendo un fallo, así que comprueba el contenido. Una Response Assertion de JMeter que falla marca su muestra como no exitosa; los checks de k6 solo afectan al código de salida a través de un umbral.
• Un mínimo de tasa de peticiones. En un modelo de carga cerrado, un sistema lento recibe menos peticiones, de modo que una ejecución puede cumplir sus límites de latencia con una fracción de la carga prevista (modelo de carga abierto vs cerrado).
• Recursos de los servidores. CPU, memoria y uso de pools salen de tu monitorización. Trátalos como avisos salvo que un plan de capacidad fije un techo estricto.

¿Cómo se eligen los números?

El techo sale del SLO y el límite de regresión, de ejecuciones anteriores de la misma prueba. El SLO dice lo que toleran los usuarios; las ejecuciones anteriores, lo que este build hace normalmente.

El libro de SRE desaconseja fijar un SLO a partir del comportamiento actual. Un límite de regresión existe para detectar cambios, así que el comportamiento actual es justo su materia prima. Ejecuta varias veces el build sin cambios con el mismo entorno y la misma carga, anota cuánto varía cada métrica y pon el límite por encima de la peor ejecución con algo de margen, siempre por debajo del techo derivado del SLO cuando lo haya.

Si las ejecuciones de un mismo build varían más que la regresión que quieres detectar, la prueba es demasiado ruidosa para bloquear builds: alarga primero la fase estable o aísla el entorno. Registra nuevas ejecuciones de referencia tras cualquier cambio deliberado.

¿Qué criterios deben hacer fallar el build y cuáles solo avisar?

Haz fallar el build con los límites que vienen de un SLO o que comprueban que las respuestas son correctas. Avisa con los percentiles de cola, el uso de recursos y las derivas lentas, que piden criterio; una barrera que falla por ruido acaba desactivada pronto.

El plugin ensure de Artillery tiene un nivel de aviso: una condición con strict: false es opcional, así que incumplirla no cambia el código de salida (comprobado el 9 de octubre de 2026). En k6, un check sin umbral nunca hace fallar la ejecución. En el resto de herramientas, deja los avisos fuera de las aserciones.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

¿Cuándo debe detenerse antes de tiempo una prueba de carga?

Cuando seguir solo puede hacer daño o ya no demuestra nada: errores muy por encima del límite, un sistema ya caído o un generador que no da abasto. Dale a la regla un periodo de gracia para que el ruido del arranque no la dispare.

Haz las reglas de parada más laxas que los límites de aprobación: protegen un entorno compartido. En k6, abortOnFail detiene la prueba en cuanto falla un umbral, tras un delayAbortEval opcional. La documentación de Locust sobre extensiones muestra un greenlet en segundo plano que detiene la ejecución cuando la proporción de fallos supera un umbral. En Gatling, crashLoadGeneratorIf detiene el generador con un código de fallo cuando se cumple una condición en la sesión de un usuario virtual. Un Thread Group de JMeter puede detener la prueba ante un error de sampler, algo adecuado para una comprobación de corrección (todo comprobado el 9 de octubre de 2026).

¿Cómo codifica cada herramienta los criterios?

k6 y Artillery convierten un límite estricto incumplido en un código de salida distinto de cero, Locust lo hace ante cualquier petición fallida o con los límites que programes tú, y las aserciones de Gatling hacen fallar el build. JMeter deja el veredicto a un paso posterior a la ejecución.

k6: los umbrales van en las opciones del script. Este ejemplo falla por el p95 de las peticiones etiquetadas name: checkout o por un 0,5 % de errores, y se detiene pasado un minuto si los errores superan el 5 %:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: las aserciones combinan un ámbito (global, forAll, details), una estadística como un percentil o requestsPerSec, y una condición. Se evalúan al terminar la ejecución, y una sola aserción fallida hace fallar la simulación.

Locust termina con código 1 si alguna petición falló, y --exit-code-on-error cambia ese código. Para una proporción o un percentil, asigna environment.process_exit_code en un listener de quitting; el código fuente de Locust da prioridad a ese valor.

JMeter juzga cada muestra con sus aserciones, y sus opciones de línea de comandos no incluyen ningún límite para la ejecución completa. Decide la CI: con un script corto sobre el archivo de resultados, como en nuestra guía de GitHub Actions, o con el jmeter-maven-plugin, un plugin de terceros cuyo goal results hace fallar el build si falla una sola muestra, salvo que errorRateThresholdInPercent fije una tasa (comprobado el 9 de octubre de 2026).

LoadFocus evalúa las ejecuciones según umbrales de aprobado o fallo guardados en la prueba: tiempos de respuesta p95 y p99 máximos, tasa de errores máxima y tasa mínima de peticiones, cada uno opcional. Cada ejecución recibe una insignia PASS o FAIL con los valores reales y los objetivos, y una API entrega el veredicto a un pipeline. LoadFocus ejecuta los escenarios de k6 con tasa de llegada con un número fijo de usuarios, así que ahí un mínimo de tasa comprueba lo que lograron esos usuarios.

FAQ

¿Debe ser el tiempo de respuesta medio un criterio de aprobación? Rara vez. El libro de SRE prefiere los percentiles: una media oculta la cola larga y puede quedarse plana mientras las peticiones más lentas se vuelven mucho más lentas.

¿Cuántos criterios de aprobación debe tener una prueba de carga? Un puñado de límites estrictos, más avisos. El libro de SRE aconseja tener los menos SLO posibles y dice que, si citar uno nunca permite ganar una discusión sobre prioridades, probablemente no merece la pena tenerlo. Aplica la misma regla a cada límite de una prueba de carga.

¿Puede aprobarse una prueba de carga con algunas peticiones fallidas? Sí, si la tasa de errores se mantiene por debajo de su límite. Revisa el comportamiento por defecto de tu herramienta: Locust hace fallar la ejecución con una sola petición fallida.

Lecturas relacionadas

• Pruebas de carga en GitHub Actions: guía práctica
• Coordinated omission: qué es y cómo evitarla
• Cómo hacer una prueba de carga: guía paso a paso
• Puntuación Apdex: qué es y cómo se calcula
• SLO vs SLA: diferencia, SLI y presupuesto de error

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.