Este artigo tem como objetivo principal propor uma estratégia de utilização para o JMeter, sabendo que a ferramenta oferece maneiras com abordagens diferentes para cada situação, contudo existem diversas opiniões sobre o assunto, e aqui explicarei a maneira que acredito ser a mais coerente com o cenário proposto.

Premissa

O objetivo da estratégia é prover cenários de testes mais reais a forma de uso dos sistemas testados. Portanto, os testes de carga devem simular o mais próximo possível da realidade de utilização, cenários realistas ajudam a minimizar os efeitos da subestimação ou superestimação dos tempos de resposta das aplicações.

Definições

Para que isso possa ser viável a ferramenta de teste de carga deve garantir os seguinte comportamentos:

Think Time

Tempo no qual o usuário para (pensa) durante suas interações com o sistema. Faz os usuários virtuais se comportarem como se fossem usuários reais. Por meio do Think Time, são injetados atrasos e paradas variáveis nos testes para simular cargas de utilização mais realistas.

Cache de navegador

Permite que requisições estáticas como imagens, folhas de estilos, scripts entre outros sejam realizadas apenas uma vez por usuário, sabendo que o comportamento padrão dos navegadores de mercado fazem cache de arquivos que não são alterados com frequência.

Concorrência

Significa vários usuários usando a aplicação em diversas funcionalidades no mesmo período.

Requisições derivadas

Requisições feitas a partir de uma requisição HTTP principal, são elas as requisições para imagens, folhas de estilo e arquivos de script Javascript.

Ferramenta JMeter

A versão do JMeter utilizada foi a versão 2.5.1 que pode ser baixada no seguinte link:
http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

Gravação de Script (JMX) – Passo a Passo

Passo 1: Variáveis do Test Plan

Inicialmente é importante ter pelo menos 4 variáveis no plano.

• Endereço/ip do servidor – SERVER;
• Porta do servidor – PORT;
• Número de usuários do script – THREADS;
• Número de iterações por usuário – ITERATIONS.

Abaixo, um exemplo de como deverá ficar o plano teste.

Com este procedimento todas as ocorrências de localhost e 80 durante a gravação do script serão substituídas pelas variáveis ${SERVER} e ${PORT} respectivamente.
Para utilização deste script no Hudson estas variáveis teriam como valores: ${__P(NOME_VARIAVEL,VALOR_PADRAO)}. Esta função pega as propriedades descritas na inicialização do JMeter, e o segundo parâmetro é o valor padrão para execução do script no caso desta propriedade não ser encontrada.
As variáveis THREADS e ITERATIONS serão utilizadas no componente Grupo de Usuários (Thread Group) como mostra a figura abaixo.

Passo 2: Componente de Proxy

O componente proxy para a gravação deverá ser semelhante a figura abaixo.

O recomendado é que não sejam gravadas as imagens, pois será utilizada a funcionalidade de “Recuperar Recursos Embutidos” descrita neste documento.

Padrões de URL a Serem Excluídos

Filtro para a não inclusão de requisições para folhas de estilo (CSS), arquivos de script de javascript (JS) e imagens (JPG, JPEG, GIF, PNG).
.*\.jpg
.*\.js
.*\.png
.*\.gif
.*\.jpeg
.*\.css

Think time

Para que seja adicionado o think time automaticamente no script com base no tempo de espera entre cada ação tomada durante a gravação deve-se adicionar um Temporizador Constante no proxy, como mostra abaixo.

Passo 3: HTTP Request Defaults

Com o objetivo de padronizar as requisições é interessante que seja inserido antes do início das gravações de script o componente Padrões de Requisição HTTP (HTTP Request Defaults) como na figura abaixo.

Deve-se deixar ativas as opções Recuperar todos os recursos embutidos a partir de arquivos HTML e a opção Use concurrent pool. Estas duas configurações fazem com que as chamadas das páginas sejam interpretadas e que os recursos embutidos (imagens, folhas de estilo, scripts) sejam requisitados no script sem serem explicitamente descritos no plano de teste, o parâmetro Size do pool explicita a quantidade de recursos que serão requisitados ao mesmo tempo pelo JMeter, o padrão são 4 recursos embutidos simultaneamente.

Devido a um comportamento do JMeter, quando existem imagens e/ou outros recursos embutidos dentro do CSS, estes não serão recuperados pela funcionalidade de recuperar os recursos embutidos a partir de arquivos HTML, uma solução de contorno é fazer a chamada dos recursos explicitamente no script.

Passo 4: HTTP Cache Manager

O comportamento esperado deste componente é que a primeira vez que o usuário virtual faça uma requisição sejam feitas todas as requisições embutidas, sendo que na segunda vez que a requisição for feita e a primeira estiver sido feita com sucesso estes recursos embutidos não serão mais requisitados.
O script ficará como abaixo.

A gravação dos scripts de teste devem conter apenas as requisições principais, e automaticamente o Gerenciador de Cache HTTP (HTTP Cache Manager) faz com que as requisições derivadas sejam “cacheadas”.

Existirão casos em que a imagem contém dados variáveis, ou até mesmo regras de negócio atreladas, nestes casos é recomentado que seja feita a requisição explicita no JMeter, fazendo com que a recuperação automática de recursos embutidos e o cache HTTP não tenham efeito sobre ela.

Passo 5: Iniciar a Gravação

Após todos os passos anteriores terem sido concluídos pode-se iniciar a gravação do script utilizando o navegador.

Execução do Script

A árvore de resultados da execução de um script para acessar o Google utilizando a estratégia descrita neste documento ficará como na figura abaixo.
Neste script foi utilizada 1 thread (Usuário Virtual) e 4 iterações, 2 iterações utilizando o cache e 2 sem utilizar o cache.

Perceba que nas 2 primeiras requisições da página inicial traz todas as requisições derivadas como mostra a imagem acima, e as 2 seguintes não como mostra a imagem abaixo, este é o comportamento esperado.

Número de Iterações

Recomenda-se que haja mais de uma iteração para cada thread, preferencialmente que o teste seja feito por um período de tempo que permita a todos os usuários estarem utilizando o sistema concorrentemente. A repetição dos testes por várias iterações permite ao sistema de adaptar ao número de usuários concorrentes tornando os tempos de resposta mais próximos de um cenário real.

Temporizador de Sincronização

O temporizador de sincronização deve ser utilizado em casos que se deseje garantir que uma requisição seja executada por todas as threads (usuários virtuais) ao mesmo tempo. Normalmente a requisição a ser sincronizada encontra-se entre outras requisições que podem tirar a sincronização dos usuários virtuais, como por exemplo o login no sistema, sendo que neste normalmente a funcionalidade que deseja-se testar esta após a entrada dos usuários no sistema.

Estratégia Complementar

O ideal é que todas as funcionalidades do sistema sejam testadas ao mesmo tempo, sendo que esta abordagem é denominada cenário composto. A partir de porcentagens de usuários definida em cada funcionalidade, os quantitativos poderiam ser incrementados, tornando o teste mais condizente com a realidade.

Conclusão

O mais importante de todas as ações tomadas em relação a estratégia padrão de criação/utilização dos scripts é tentar executar uma simulação mais fiel possível da utilização dos usuários reais do sistema. Outras estratégias podem ser adotadas conforme necessidades específicas, portanto necessitando uma avaliação caso a caso nos projetos.