Tempo de pensamento em teste de carga: como definir

Tempo de pensamento em teste de carga é a pausa que um usuário virtual faz entre duas ações, representando os segundos que uma pessoa real passa lendo uma página ou preenchendo um formulário. Ele decide quanta pressão cada usuário virtual exerce: quanto mais longa a pausa, menos requisições por segundo o mesmo número de usuários envia. Meça o valor com dados de usuários reais, varie-o aleatoriamente em torno desse valor e escreva-o no script com o comando de pausa da sua ferramenta.

É só aritmética, sem nenhum teste por trás: uma requisição por volta, uma resposta em 0,5 segundo, e o número de usuários dividido por (tempo de resposta + tempo de pensamento).

O que é tempo de pensamento em teste de carga?

Tempo de pensamento é a espera proposital que um script de teste insere entre os passos de uma jornada de usuário. Ele reproduz a parte humana de uma sessão: ler, comparar, digitar.

No script de uma loja, ele fica entre “abrir a página do produto” e “adicionar ao carrinho”, fora de qualquer requisição. O guia da LoadFocus sobre atrasos em teste de carga separa esse tempo do atraso de rampa, que adiciona usuários aos poucos, e do atraso de início entre um usuário e o próximo, e observa que muitas ferramentas chamam de “delay”, sem mais nada, o atraso de rampa. Quando uma ferramenta oferecer um campo “delay”, confira a qual dos três ele se refere.

Por que o tempo de pensamento muda a carga com o mesmo número de usuários?

Com um número fixo de usuários virtuais, cada um espera uma resposta, faz uma pausa e só então envia a próxima requisição. A volta dele leva o tempo de resposta mais o tempo de pensamento, então cada segundo de pausa a mais reduz as requisições que cada usuário envia por segundo.

Cem usuários sem pausa enviam 200 requisições por segundo com uma resposta de 0,5 segundo; com uma pausa de 5 segundos enviam cerca de 18, de modo que duas execuções “com 100 usuários” podem ser testes bem diferentes. A documentação do k6 descreve o mesmo efeito para o seu modelo fechado: a próxima iteração só começa quando a anterior termina, então respostas mais lentas também reduzem o ritmo (conferido em 9 de outubro de 2026).

Cortar o tempo de pensamento para tirar mais carga de menos usuários tem um custo: vinte usuários sem pausas podem igualar o ritmo de requisições de várias centenas que fazem pausas, mantendo abertas muito menos sessões e conexões do que a produção.

Qual é a diferença entre tempo de pensamento e pacing?

Tempo de pensamento é uma pausa depois de um passo, então uma volta fica mais longa sempre que as respostas ficam lentas. Pacing fixa o intervalo entre o início de uma volta e o início da seguinte, e encurta a espera quando o trabalho demorou mais.

Com pacing de 30 segundos, um usuário começa uma volta a cada 30 segundos, quer as requisições tenham levado 2 segundos ou 20, o que combina com testes montados a partir de volumes de negócio como “500 pedidos por hora”. A documentação do constant_pacing do Locust explica o caso extremo: se a tarefa durar mais que o intervalo, a espera cai para zero (conferido em 9 de outubro de 2026). Muitos scripts usam os dois, com tempo de pensamento entre os passos e pacing na volta inteira.

O tempo de pensamento deve ser fixo ou aleatório?

Aleatório, em torno de uma média que você mediu. Uma pausa fixa mantém no mesmo passo os usuários que começaram juntos, que chegam à mesma página no mesmo momento, volta após volta.

Essas ondas sincronizadas podem criar picos que a produção nunca vê, e uma pausa aleatória espalha os usuários. Mantenha a média onde seus dados a colocam: uma pausa uniforme entre 2 e 8 segundos dá 5 em média, a mesma carga média de uma pausa fixa de 5 segundos. A distribuição uniforme é a escolha simples por padrão; uma normal (gaussiana) agrupa as pausas em torno de um valor típico, e uma exponencial gera muitas esperas curtas e algumas longas.

Como escolher os valores do tempo de pensamento?

Tire-os do que os usuários reais fazem em cada passo, usando sua ferramenta de analytics, os logs de acesso ou uma ferramenta de monitoramento de usuários reais (RUM). Use um valor diferente por passo, porque ler a página de um produto leva mais tempo do que apertar um botão.

O tempo na página registrado pelo analytics, ou o intervalo entre requisições consecutivas de uma mesma sessão nos logs de acesso, se aproxima do tempo de pensamento daquele passo. Use a mediana como pausa média e a dispersão para definir a faixa aleatória, e descarte os tempos ociosos, como uma aba esquecida aberta durante o almoço.

Uma API chamada por outros programas não tem ninguém humano no circuito, então modele diretamente o ritmo de requisições dela. Sem dados, anote no plano de teste os valores que você supôs, para que uma execução futura os substitua; o guia passo a passo para fazer um teste de carga mostra onde eles entram.

Como adicionar tempo de pensamento no k6, JMeter, Gatling, Locust e Artillery?

Cada ferramenta tem seu próprio comando de pausa, e a maioria também oferece pacing ou controle de ritmo.

Os fatos da tabela acima e das notas abaixo vêm da documentação de cada projeto, conferidos em 9 de outubro de 2026; as cinco ferramentas aparecem na nossa análise de ferramentas de teste de carga open source.

k6. sleep(t) pausa o usuário virtual por t segundos; a documentação monta pausas aleatórias com Math.random() ou com randomIntBetween() do k6-utils:

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // de 2 a 8 segundos
  http.get("https://example.com/cart");
}

JMeter. Entre os timers, o Constant Timer recebe um atraso em milissegundos, os Uniform e Gaussian Random Timers somam uma parte aleatória a um deslocamento fixo, e o Constant Throughput Timer varia suas pausas para manter uma meta de amostras por minuto. Um timer roda antes de cada sampler do seu escopo, então um único timer no nível do Thread Group pausa antes de cada requisição.

Gatling. pause(2, 8) espera um tempo aleatório uniforme, e pace(30) dentro de um laço o executa no máximo uma vez a cada 30 segundos. No nível da simulação, você pode passar todas as pausas para uma distribuição normal ou exponencial, ou desligá-las com disablePauses().

Locust. O wait_time vale depois de cada tarefa, então uma tarefa com duas requisições sob constant_throughput(2) envia quatro requisições por segundo por usuário.

Artillery. Um passo think pausa por um número de segundos, e uma configuração think.jitter em config.http.defaults adiciona variação aleatória a cada passo think. Para ver duas dessas ferramentas lado a lado, leia k6 vs Artillery.

O tempo de pensamento importa num teste por taxa de chegada?

Menos, no que diz respeito ao ritmo de requisições. Quando a ferramenta inicia novas iterações num ritmo fixo, as pausas decidem quanto tempo cada usuário fica e, portanto, quantos estão ativos ao mesmo tempo.

Os executores por taxa de chegada do k6 ditam o ritmo das iterações pela taxa, e a documentação desaconselha um sleep no fim da iteração; as fases de carga do Artillery também criam um número fixo de novos usuários virtuais por segundo (ambos conferidos em 9 de outubro de 2026). O tempo de pensamento entre os passos continua moldando cada sessão.

Como as ferramentas de script da LoadFocus definem o tempo de pensamento?

Elas o escrevem no script do k6 ou do JMeter como valor inicial, para você ajustar depois.

A importação de cURL, HAR, Postman ou OpenAPI transforma uma requisição capturada em um script do k6 que termina cada iteração com sleep(1); trate esse segundo como um valor provisório a substituir pelas suas medições. O gerador de testes com IA da LoadFocus é instruído a dar a cada passo um tempo de pensamento, escreve esse tempo como sleep() para o k6 ou como Constant Timer para o JMeter, e avisa quando um cenário com vários passos não tem nenhum.

FAQ

Dá para rodar um teste de carga sem tempo de pensamento? Sim, para encontrar a vazão máxima de um endpoint ou num teste de estresse, desde que você apresente o resultado em requisições por segundo. Ele diz pouco sobre quantos usuários reais o sistema consegue atender.

O tempo de pensamento entra no tempo de resposta? Não nos tempos de cada requisição. No k6, http_req_duration cobre o envio, a espera e o recebimento, enquanto iteration_duration cobre a volta inteira (referência de métricas, conferido em 9 de outubro de 2026). Um Transaction Controller do JMeter deixa os timers fora do seu tempo, a menos que você marque a opção que os inclui.

Leituras relacionadas

• Modelo de carga aberto vs fechado: qual usar e quando
• Lei de Little em teste de carga: dimensionar e conferir
• Como fazer um teste de carga: guia passo a passo
• Teoria das filas: o que é e por que a latência dispara

As afirmações técnicas deste artigo não foram revisadas de forma independente.