Estrutura do Plano de Teste

Considere a seguinte hierarquia de elementos em um plano de teste JMeter:

Plano de Teste
└── Grupo de Threads
    ├── Requisição HTTP 1          ← Sampler 1
    ├── Controlador If
    │   ├── Requisição HTTP 2      ← Sampler 2
    │   └── Timer Fixo 2
    ├── Timer Fixo 1               ← Timer (irmão, após Requisição HTTP 1)
    ├── Requisição HTTP 3          ← Sampler 3
    └── Timer Fixo 3               ← Timer (filho de Requisição HTTP 3)

Regra Fundamental: Escopo dos Timers no JMeter

No JMeter, os timers seguem uma regra clara de escopo baseada na posição e nível hierárquico:

• Um timer afeta apenas os samplers que vêm depois dele na mesma hierarquia.
• Ele também afeta todos os samplers dentro de contêineres filhos (como loops ou controladores) que estiverem abaixo de sua posição.
• Não há efeito retroativo: um timer não podde influenciar samplers já executados anteriormente na sequência.

Análise Passo a Passo da Execução

1. Execução da "Requisição HTTP 1"

Este é o primeiro elemento do grupo de threads. Quando ele executa, o "Timer Fixo 1" ainda não foi alcançado pela thread. Como o timer está posicionado após essa requisição, ele não tem qualquer impacto sobre ela.

2. Entrada no "Controlador If"

Dentro do controlador, temos:

• A "Requisição HTTP 2", que será executada se a condição do controlador for verdadeira.
• O "Timer Fixo 2", que atua apenas sobre os samplers dentro desse controlador — neste caso, aplicando atraso antes da execução da Requisição HTTP 2.

Como o "Timer Fixo 1" está fora deste bloco e posterior ao controlador, ele não interfere com nenhum elemento interno ao "Controlador If".

3. Ativação do "Timer Fixo 1"

Quando a execução alcança este ponto:

• O timer entra em ação.
• Sua influência começa imediatamente para todos os elementos subsequentes no mesmo nível.

Portanto, ele será aplicado à "Requisição HTTP 3", pois esta vem depois dele na ordem de execução.

4. Comportamento do "Timer Fixo 3"

Como este timer é um filho direto da "Requisição HTTP 3", seu escopo é estritamente local. Ele adicionará um atraso específico anntes da execução dessa única requisição, independentemente de outros timers.

Exemplo Prático: Simulação de Fila

Pense na sequência de execução como uma fila de pessoas esperando atendimento:

1. A primeira pessoa (Requisição HTTP 1) é atendida imediatamente.
2. Depois vem o grupo do "Controlador If", que pode ou não prosseguir.
3. Somente então aparece a placa indicando "Aguardar 5 segundos" (Timer Fixo 1).
4. Todos os próximos na fila (a partir da Requisição HTTP 3) devem respeitar esse atraso.

A placa não volta no tempo para atrasar quem já foi atendido.

Soluções para Aplicar Atraso à Primeira Requisição

Opção 1: Posicionar o Timer Antes da Requisição

Grupo de Threads
├── Timer Fixo 1
├── Requisição HTTP 1
├── Controlador If
│   ├── Requisição HTTP 2
│   └── Timer Fixo 2
└── Requisição HTTP 3

Nesta configuração, o timer afetará todas as requisições seguintes, incluindo a primeira.

Opção 2: Aninhar o Timer como Filho da Requisição

Grupo de Threads
├── Requisição HTTP 1
│   └── Timer Fixo 1
├── Controlador If
│   ├── Requisição HTTP 2
│   └── Timer Fixo 2
└── Requisição HTTP 3

Aqui, o atraso é aplicado exclusivamente à "Requisição HTTP 1", sem impactar outras requisições no plano.

Conclusão Importante

O comportamento dos timers no JMeter depende inteiramente da ordem de execução e da estrutura hierárquica. Um timer só pode adicionar atraso a ações futuras — nunca a ações já concluídas. Para garantir o controle preciso do fluxo, posicione os timers estrategicamente antes ou dentro dos elementos que devem ser afetados.