Módulo 3: Carga de verdade com stages e thresholds

Carga real não começa no talo: ela sobe, segura e desce. stages troca o vus/duration fixos por uma curva:

🧩 trecho de exemplo: JavaScript pra estudar ou colar num arquivo .js, não é comando de terminal

export const options = {
  stages: [
    { duration: "20s", target: 20 },  // sobe de 0 a 20 VUs em 20s
    { duration: "40s", target: 20 },  // segura 20 VUs por 40s (o patamar)
    { duration: "10s", target: 0 },   // desce de 20 a 0
  ],
};

Cada objeto é um trecho: target é o nº de VUs que se quer ao fim do trecho, e o k6 interpola linearmente até lá. O patamar (o trecho do meio, com target igual ao anterior) é onde as métricas contam de verdade.

É a única coisa no k6 que reprova o teste. Cada regra é uma condição sobre uma métrica; se ela não for cumprida, o k6 run termina com código de saída 99, e o CI marca o build como vermelho.

🧩 trecho de exemplo: JavaScript pra estudar ou colar num arquivo .js, não é comando de terminal

thresholds: {
  http_req_failed: ["rate<0.01"],       // menos de 1% de erro
  http_req_duration: ["p(95)<300"],     // 95% das respostas abaixo de 300ms
  "http_req_duration{tipo:leitura}": ["p(95)<600"],  // so nas leituras
  checks: ["rate>0.99"],                 // 99%+ dos checks passando
},

• rate<0.01 numa métrica de taxa (http_req_failed, checks): proporção.
• p(95)<300, p(99)<500, avg<200, max<1000 numa métrica de tempo.
• vários limites na mesma métrica: ["p(95)<300", "p(99)<800"].

No resumo, a linha portão (thresholds) mostra ok ou REPROVADO -> http_req_duration: p(95)<300.

Mesmo script, curvas de stages diferentes:

Tipo	Curva	Responde
smoke	1–2 VUs, poucos segundos	o script e o alvo estão de pé?
load	sobe até a carga esperada, segura, desce	aguenta o dia normal dentro da meta?
stress	sobe além do esperado, em degraus	a que ponto quebra? e como quebra?
spike	salto brusco pra carga altíssima e volta	sobrevive a um pico repentino (promoção, notícia)?
soak	carga média por muito tempo (horas)	degrada com o tempo? (vazamento de memória, disco enchendo)

Quando o portão reprova, olhe o que reprovou:

• p95 estourou, erro baixo: o sistema respondeu tudo, só devagar. Gargalo de performance (banco, CPU, fila).
• erro subiu: passou a recusar requisições (5xx, timeout, connection reset). Achou um teto de capacidade.
• os dois pioram juntos a partir de um nº de VUs: esse número é a capacidade aproximada do sistema como está.

Reprovar não é bug no seu script, é o resultado. O teste de carga existe pra achar esse limite antes do usuário achar.

scripts/03_carga.js tem a rampa até 20 VUs e um threshold de p(95)<300 apertado de propósito. O alvo de treino fica mais lento quanto mais carga recebe, então sob 20 VUs o p95 passa de 300ms e o portão reprova. Com o mock ligado:

k6 run scripts/03_carga.js

O k6 termina com código 99 (portão reprovado): é o esperado, não é falha sua.

Agora vá ao Terminal 1 e aperte Ctrl+C pra encerrar o mock. Sem isso o corretor não consegue checar o lado do servidor. Só depois disso, de volta no Terminal 2:

python verificar.py 3

O corretor confere o que você montou (a rampa chegou a 20 VUs? os dois thresholds existem? o servidor sentiu a carga simultânea?) e mostra uma nota dizendo que o portão reprovou, que é o certo aqui.

A) Rode 03_carga.js como está e confirme python verificar.py 3 com tudo [ok] + a nota de portão reprovado.

B) Afrouxe a meta pra http_req_duration: ["p(95)<1500"] e rode de novo. Agora o k6 run sai com código 0 e a nota vira "o portão passou". A pergunta que sobra, 1500ms é aceitável pro seu produto?, é decisão de time, não da ferramenta.

C, opcional) Suba o mock com a contenção desligada ($env:MOCK_LATENCIA_POR_CARGA_MS=0; python mock/servidor.py) e rode o 03_carga.js original: o p95 nem sobe. Gabarito em trilha-5/GABARITO.md.

Olhar de QA

Quando o portão fecha, reprovar não é falha do teste, é o teste funcionando. O seu trabalho não é decidir se adia a entrega; é entregar a informação com precisão suficiente para outra pessoa decidir. "O p95 do checkout passa de 800ms a partir de 140 usuários; abaixo disso fica em 310ms" é acionável. "Está lento" não é, e é o que faz um relatório de performance ser ignorado.