Ordem de Execução em JMeter
Tabela de conteúdos
Novato - This article is part of a series.
Ordem de Execução #
Possivelmente uma das principais problemas encontradas em JMeter é falta de conhecimento sobre a ordem de execução. Isso é especialmente comum quando tentar obter resultados específicos por meio de threads ou grupos de threads. Primeiro, precisamos entender que JMeter executa o plano de teste ou script sequencialmente, mas dentro desta sequência existe uma ordem e hierarquia respeitada em forma de árvore.
A ordem de execução pode ser encontrada na referência, seção 3.9 e é como segue:
- Elementos de Configuração
- Pre-processadores
- Temporizadores
- Sampleres
- Post-processadores (se a resposta não for nula)
- Assertores (se a resposta não for nula)
- Recebedores (se a resposta não for nula)
1.- Elementos de Configuração #
Isso significa que primeiro qualquer elemento de configuração será executado em nível plano de teste ou plano de teste, e da mesma forma como a sequência desce pelos níveis inferiores na árvore.
2. - Processadores Pré-Processores #
Segundo, os processadores pré-processores serão executados, embora geralmente estejam ligados a um sampler porque eles ampliam ou modificam sua escala.
3.- Timers #
Terceiramente, temos timers, e dedicarei um parágrafo inteiro a isso porque é muito comum encontrar uma planilha de testes com mais de um timer. Embora seja possível ou possivel ter múltiplos timers, não é recomendado ter eles no mesmo nível. Se você quer que um timer afetar apenas um sampler, o sampler deve estar abaixo dele. Se algum ou todos os timers estiverem no mesmo nível, essas vezes irão somar e poderiam seriamente afetar seus resultados.
4.- Samplers #
Em quarto lugar, encontramos os samplers, e é aqui que começamos a ver resultados nos receptores, pois esses são os pedidos que enviamos aos servidores usando o protocolo selecionado.
5.- Processadores Post-Processores #
No quinto lugar estão os processadores post-processores. A partir deste ponto em diante, o sampler deve fornecer algum dado de saída; se for nulo, a chance de falhar é alta. Todos os extratores utilizados para realizar as correlações estão aqui, pois eles precisam de informações para extraírem os valores que serão usados posteriormente.
6.- Afirmações #
Quando a informação necessária foi extraída, os seis e o último posicionamento são executados: as afirmações. Essas são usadas para validar a resposta recebida procurando valores específicos nele e agir sobre eles.
7.- Recebedores #
No seventh e último lugar estão os recebedores, onde podemos visualizar solicitações e respostas. O receptor mais útil para isso é o exibindo árvore de resultados.
É muito importante se familiarizar com e entender essa sequência de execução, porque será repetida em cada nível da árvore. Alguns componentes herdam seus valores de níveis inferiores, como os timers, que afetam os samplers em todos os níveis subniveis, conforme podemos ver na seguinte imagem:
No exemplo anterior, apenas um cronômetro está configurado na nível do grupo de thread, isso afetará os testes 1, 4, 5, “Debug” e “JSR223”, também impactará os testes HTTP que estão dentro da “Transação Controller”, é fácil verificar isso porque no quadrado vermelho podemos ver o tempo total de execução que é 36 segundos, e o cronômetro foi configurado para 5 segundos, que foi ativado por 7 testes dando um total de 35 segundos de espera + 1 segundo de resposta.
Não importa quantos níveis subnível houver, os cronômetros sempre herdarão seus valores. Outros exemplos de herança seriam o Módulo de Múltiplo Header e o Defaultes HTTP Request. No caso do módulo de múltiplas cabeçalhos, poderíamos colocar um único componente no nível do teste plano que afetaria todos os grupos de thread, assim que eles usariam o mesmo valor de “User-Agent” para todas as requisições HTTP ou HTTPS. Da mesma forma, o request by definition substituirá a protocolo e/ou IP address e/ou server name e/ou portos valores que serão usados em todas as requisições HTTP, desde que eles estejam vazios nos testes HTTP.
No futuro, criarei um post específico para discutir os benefícios da utilização de herança em mais detalhes, especialmente para reutilizar códigos em diferentes ambientes de teste.