Sínteses em JMeter como LoadRunner

Para aqueles que não sabem da minha história, eu sou originalmente de LoadRunner. Isso foi onde meus carreiras como testador de carga começaram e foram largamente desenvolvidas com o uso deste ferramenta.

Quando comecei a trabalhar com o JMeter, caí em amores pelas suas características. Mas tentar criar mais complexos cenários sem muita dificuldade como fazia o LoadRunner era uma luta para mim. E pior ainda, o LoadRunner trata a parte de criação do cenário como se fosse um completamente separado daquela usada para a criação da script.

Infelizmente, o JMeter não separa isso porque ele trata tudo na mesma interface: criando scripts (ou múltiplos scripts), configurando os cenários e executando todos eles dentro do mesmo programa.

Esta diferença me causou problemas quando tive que realizar testes com mais de cinco casos simultâneos. Ela já parecia desorganizada com 5 scripts, e gerenciar até 10 ou mesmo 15 seria uma enorme tarefa usando o mesmo ferramenta. Não mencionar a manutenção tornaria complexo e difícil distribuir com um time de scripters.

Como Fazer? #

Meu primeiro impulso foi usar-o como é. Sem fazer nada além do que já vem com ele. E como mencionado acima, o uso tornou-se rapidamente uma lama de criar, manter e trabalhar com ele.

Depois de tentar desse jeito com esse problema, eu dei por mim e decidi tentar algo. Orientado pela minha experiência no mundo do LoadRunner, eu tentei imitar um pouco a maneira de criar cenários simples copiando scripts e editando cada uma separadamente.

Após algumas ajustes, consegui alcançar isso fazendo isso desta maneira. Agora vou compartilhar com você como fazer isso em passos simples com explicações que podem tornar o dia-a-dia de uma equipe de testagem de carga mais fácil quando diferentes pessoas trabalham em cenários automatizados diferentes para o mesmo cenário e não têm um ambiente na nuvem.

Passo 1 #

A primeira coisa é ter um arquivo JMX para cada processo de nossa carga teste que executaremos. Não copiar ou colar outros scripts de automação e junte múltiplos processos em um único arquivo. Basta uma caso de teste em cada um.

Mas diferente dos passos tradicionais, aqui colocaremos todos os passos da nossa automação dentro de um FRAGMENT DE TESTES. Nada de controle de threads ou nada. Vamos tentar limpar os passos e voltarmos a focar no que estamos fazendo.

Somente adicione os componentes HTTP relacionados a cada um. Se necessário, adicione e configurem REQUISIÇÕES DE DEFAULT HTTP e GERENCIADOR DE COOKIES HTTP.

Passo 2 #

Outro importante passo para que isso funcione é declarar “tempo de pensamento” de forma global, permitindo que seja aplicado igualmente em todas as etapas relevantes nas respectivas scripts. Mas antes disso, precisamos criar um PARAMETRO USUÁRIO com o qual trabalharemos.

Vamos chamar de variável tempo de pensamento ou variável tempo de pensamento. Podemos atribuir um número fixo (expresso em milissegundos) ou um número aproximado ao seu valor, próximo a esse número fixo. É recomendado usar o número aleatório para não ter igualdades nas esperanças e correr riscos de perder realismo na testagem.

Passo 3 #

Agora, para cada passo onde precisamos adicionar o Tempo de Pensamento (não todos os passos devem incluí-lo), adicionamos um TIMER CONSTANTE no final, mas dentro de cada REQUISIÇÃO HTTP.

Depois de adicionar o TIMER CONSTANTE, basta atribuir o nome da PARAMETRO USUARIO criado no passo 2. Isso significa inserir “${ThinkTime}” na Duração do Thread - ou o nome que foi atribuído à variável.

No final, repetimos isso em cada Request de HTTP que deveria incluir um tempo pensante. Isso modo, simplesmente atualizamos a PARAMETRO USUÁRIO e tudo o mais será atualizado também.

Após essas etapas serem completadas para cada passo em nossos processos de negócios, agora podemos começar a construir o cenário. Podemos fechar os scripts.

Passo 4 #

Para criar o cenário, começaremos com um projeto JMeter vazio. Primeiro, adicione os componentes que precisamos para Listeners e Reporters. Recomendo ter ao menos View Results Tree e Backend Listener (ou JSR233) para enviar os resultados para um plataforma como InfluxDB.

Agora, para cada script que queremos ter em nossa escena, adicionaremos um GROUP DE THREADS e por razões de bom senso, nos nombraremos como nossas processos empresariais.

Cada grupo de tópicos ( THREAD GROUP) será atribuído os ajustes necessários para cada processo empresarial, como ramp-up ou duração e o número de threads para cada um.

Passo 5 #

Aqui, adicionaremos 3 elementos:

• PARÂMETROS USUÁRIOS
• CONTROLE INCLUDE
• AÇÃO CONTROLE FLOW Cada um desses irá cumprir funções diferentes.

Usaremos o elemento USER PARAMETER para definir algumas RTS (Configurações de Tempo de Execução) no estilo LoadRunner. Nele declararemos o tempo mínimo de espera entre cada iteração. Como é aconselhável não ter valores fixos, novamente atribuímos máximos e mínimos para nosso aleatório.

Recomenda não ir muito além e respeitar uma variação de 5 ou 10%. Isso significa que se precisar de um ritmo de 5 segundos, podemos definir máximos e mínimos de 4.5 e 5.5 segundos. Lembre-se de colocar tudo em milésimos.

Como você pode ver na imagem, alterei o nome do parâmetro para RTS. Isso é simplesmente feito para tornar mais fácil identificar quando trabalhar com eles. Independentemente de alguém externo precisar modificar a situação, o nome faz com que seja mais indicativo.

Passo 6 #

Agora no Controller de Inclusão, basta ligá-lo à localização do nosso script.

Recomenda adicionar localizações de pastas compartilhadas ou públicas. Independentemente dos scripts estarem no computador local, é melhor ter tudo em uma pasta compartilhada para evitar problemas de alcançabilidade ou limitar nosso escopo a rodar apenas em um único computador. Podemos então mover o arquivo do cenário e executá-lo onde quisermos (como longe como for, desde que a pasta compartilhada seja acessível).

Quando você executa este cenário, o JMeter carrega os passos e os executa de forma mais limpa e simples para organizar.

Passo 7 #

Agora seguimos com o Ação de Controle de Fluxo que adicionamos no final de cada uma. Isso é a que vai executar o tempo de espera em iterações. Por isso, eu coloquei lá para o tempo de espera acontecer após as etapas do script completarem um ciclo.

I recomendo chamar-o de “Pace” para tornar claro o que isso faz. Selecionaremos a opção “Pause”, marcando “Pause”, para indicar que cada elemento deve parar nesse ponto. Em seguida, na seção de duração (Duração), adicionaremos o seguinte código que automaticamente randomizará a duração do pausa:

                  ${__Random(${RndPaceMin},${RndPaceMin})}

Isso pegará os valores que definimos anteriormente na RTS. Isso é tudo que você precisa configurar nosso Pace. Você não precisa selecionar nada em aquele elemento.

Passo 8 #

Quando a primeira LINHA for concluída, você pode escolher duplicá-la para criar cada linha e então configurar apenas o que está indicado em cada elemento. Lembre-se: isso pode levar a esquecer de colocar as configurações corretas.

Se alguém é muito dedicado, os passos podem ser repetidos para cada script. É importante garantir que cada LINHA tenha as elementos descritos.

Concluído #

Com essas etapas, eles podem executar cenários complexos e felizes os testadores e desenvolvedores! Amigos dos scripts felizes! Beijos :)