Neste entr'{a}, apresentamos as melhores pr'{\i}ncipios propostas por dois especialistas no mundo de JMeter: Philippe Mouawad e Antonio Gómez Rodríguez. Eles são os autores de um livro que, na minha opini'{o}n, 'e uma das melhores atualmente: Master Apache JMeter From load testing to DevOps. Recomendo o ebook. Adicionei coment'{\i}rios e exemplos para expandir ou clarificar alguns dos conceitos.

Documentação Obsoleta #

JMeter está disponível há muitos anos, portanto, tenha cuidado ao consultar blogs, vídeos e outras documentações. Informações publicadas mais ou menos duas anos atrás, ou referentes a versões anteriores de 4.0, são provavelmente desatualizadas. A melhor pratica é consultar o documentação oficial e o histórico de alterações através do versões diferentes.

Um importante fonte de informações é nosso página em espanhol, JMeter em Espanhol, no Slack (jmeterenespanol.slack.com) e no Facebook ( https://www.facebook.com/groups/jmeterenespanol/?ref=group_header).

Performância #

A melhor prática é não usar BeanShell ou JavaScript porque significativamente degradam o desempenho do ferramenta. A melhor prática é usar JSR223 que usa Groovy como padrão. Groovy é uma linguagem moderna e poderosa que trabalha com as versões mais recentes de Java.

Use the Non-GUI mode #

A melhor pratica é não usar o modo Não-GUI para testes de carga. O modo GUI deve ser usado durante a fase de desenvolvimento da script, mas é recomendado trocar para o modo Não-GUI uma vez que essa fase tenha sido completada.

Relatório HTML #

JMeter oferece várias alternativas para a gravação de resultados no modo GUI. No entanto, o melhor prático é produzir o relatório HTML ao final do teste (em modo não GUI):

jmeter -n -t [jmx file] -l [results file] -e -o [\Path to output folder]

Recomendo visualizar este link.

Se por algum motivo houvesse um gráfico que não estivesse incluído no relatório HTML, sempre tenha a opção de carregar os resultados em modo GUI (após completar o teste).

Nunca diretamente modificar o arquivo XML onde JMeter armazena a sessão (*.jmx) #

O melhor prático é nunca manipular.

Aprender sobre a ordem de execução #

Em resumo, o padrão de execução dos elementos em JMeter segue regras específicas. O nosso colega respeitável Antonio apresenta os detalhes da ordem de execução neste publicação.

Variáveis e Propriedades #

O melhor prático é entender claramente as diferenças entre Variáveis e Propriedades. Uma Variável é um valor dinâmico exclusivo a uma thread ou usuário virtual (VUser). As variáveis são geralmente definidas usando o elemento Variações de Usuário na planificação durante a execução do teste. A thread faz uma cópia local da variável, e pode modificar este valor sem afetar outras threads no teste. Este uso é típicamente limitado a dados de usuário e regras de correlação. As variáveis são acessadas usando ${varName}. Nossa colega experiente Delvis ilustra como usar as variáveis durante o processo de correlação neste publicação.

Ademais, um Propriedade é uma valor dinâmico que é comum a todas as threads e normalmente usado para definir informações relacionadas à ambiente de execução. Você pode acessar Propriedades usando a função __P(). Por exemplo, a Propriedade PropX será lida usando ${__P(PropX)}

Uso de Funções #

JMeter oferece uma lista completa de funções que permite você otimizar a criação de scripts para testes. A melhor pratica é familiarizar-se com e usar essas funções antes de tentar “reinventar o carro”. Neste [publicação]](https://jmeterenespanol.org/pt/jmeter/time-functions/), nosso colega respeitável Antonio apresenta algumas funções para especificar valores de tempo.

Se isso não bastasse, JMeter também tem outro plugin que fornece funções adicionais.

Exemplo comum é usar a função UUID para criar uma lista aleatória de endereços de e-mail do seguinte formato:

{
    "email": "${__substring(${__UUID()}, 0, 8)}.${__substring(${__UUID()}, 25, 35)}@gmail.com", 
}

Modelos Abertos vs Modelos Fechados #

A melhor prática é usar o modelo correto para a aplicação sendo testada. No modelo aberto, os usuários chegam ao aplicativo de forma assíncrona, independentemente do número de transações que estão sendo processadas no SUT (aplicação sub-testando). Nesta exigência, está relacionado o número de TPS (transações por segundo) x tempo unitário.

Exemplos típicos deste tipo de teste estão presentes em aplicações do e-commerce.

No entanto, em um modelo fechado, o número de usuários é fixo, então a quantidade de transações é limitada pela quantidade de usuários no sistema de teste (SUT). Um exemplo típico é uma central telefônica onde o número de chamadas aceitas é limitado pelo número de operadores; se todos os operadores estiverem ocupados, o sistema não aceitará mais nenhum novo pedido. Aqui está a quantidade de usuários simultâneos (VUsers).