Durante o processo de desenvolvimento de software, é comum que os times de desenvolvimento e qualidade (QA) concentrem seus esforços principalmente em testes funcionais, que visam garantir que as diversas funcionalidades da aplicação estejam operando corretamente.
No entanto, além dos testes funcionais, há uma categoria igualmente importante: os testes não funcionais, que têm como objetivo avaliar aspectos como performance, escalabilidade, segurança e usabilidade da aplicação.
É bastante comum que as pessoas desenvolvedoras tenham uma percepção positiva da performance da aplicação, uma vez que todas as funcionalidades são executadas sem problemas aparentes de lentidão ou gargalos.
No entanto, é importante lembrar que esses testes são geralmente realizados em ambientes de desenvolvimento, ou seja, nos próprios computadores das pessoas desenvolvedoras.
Os ambientes de produção, onde as aplicações serão implantadas, geralmente possuem configurações de hardware distintas, além de volumes de dados muito maiores do que os encontrados nos ambientes de desenvolvimento.
Por exemplo, enquanto o banco de dados em ambiente de desenvolvimento pode conter apenas algumas dezenas ou centenas de registros em suas tabelas, no ambiente de produção esse número pode ser exponencialmente maior, chegando a bilhões ou mesmo trilhões de registros.
A negligência na performance de uma aplicação pode acarretar diversos impactos para uma empresa.
Por exemplo, pode causar tempos de carregamento longos, levando os usuários a abandonar a plataforma em busca de alternativas mais rápidas.
Isso prejudica a experiência do cliente, podendo também afetar a reputação da empresa e resultar em perdas financeiras.
Portanto, os testes de performance realizados em ambientes de desenvolvimento podem não refletir de forma precisa o comportamento da aplicação em produção.
É fundamental simular condições realistas de uso, como um alto número de usuários simultâneos e uma alta carga de uso.
Isso pode ser feito via testes de carga e performance utilizando algumas ferramentas, como o Apache JMeter, que são capazes de simular cenários complexos de uso e fornecer feedbacks sobre o desempenho da aplicação em ambientes simulados de produção.
O que é Apache JMeter
O Apache JMeter é uma ferramenta de testes de performance utilizada por times de desenvolvimento e QA.
Desenvolvida e mantida pela , o JMeter é uma aplicação open source escrita em , o que a torna bastante portátil e compatível com muitas tecnologias. O JMeter permite a execução de testes em diversas aplicações e protocolos, incluindo aplicações Web, , servidores de aplicações, entre outros. É possível simular diferentes cenários de carga, permitindo avaliar como uma aplicação responde sob diferentes níveis de tráfego e utilização.
Como fazer download do Apache JMeter
O JMeter pode ser baixado e como se trata de uma aplicação Java ele não é instalado no computador, devendo apenas ser executado. O requisito para sua execução é ter o Java na versão 8 ou superior instalado no computador.
Após realizar o download do arquivo .zip, basta descompactá-lo em algum diretório do seu computador.
Execução
Para executar o JMeter, basta abrir o terminal ou prompt de comandos, navegar até o diretório onde ele foi descompactado e executar o seguinte comando:
java -jar bin/ApacheJMeter.jar
Será aberta a tela principal do JMeter:
O JMeter vem configurado com o idioma Inglês, mas é possível alterar para o Português acessando a opção Choose Language, que está localizada no menu superior Options.
Plano de teste
Ao iniciar o JMeter, perceba que existe um elemento chamado Test Plan (plano de teste) já criado por padrão.
O Test Plan é o ponto de partida para criar e executar os testes no JMeter. Ele funciona como uma espécie de esqueleto para toda a estrutura do teste, definindo os cenários a serem simulados, os protocolos a serem utilizados e as métricas a serem avaliadas.
Nele, você define todos os elementos necessários para configurar e executar seus testes, incluindo a configuração de servidores, threads (usuários virtuais), grupos de amostras, controladores, listeners (ouvintes), entre outros elementos. Cada um desses elementos desempenha um papel específico no teste.
Projeto de exemplo
Para facilitar o entendimento do funcionamento do JMeter, em relação ao test plan e seus elementos, vamos a um exemplo prático.
Suponha que você desenvolveu uma API Rest de um e-commerce e nela exista um endpoint que você deseja testar com o JMeter:
GET /produtos -> Endpoint público para listar os produtos cadastrados Vamos configurar o teste para um cenário que consiste em simular 500 usuários disparando requisições, de maneira simultânea, para o endpoint de listagem de produtos.
Primeiramente, vamos renomear o test plan, selecionando o test plan criado por padrão no JMeter no lado esquerdo da tela e digitando Listagem de produtos no campo Name, no lado direito da tela:
Após isso, vamos salvar o test plan em nosso computador pela opção Save, localizada no menu superior File, ou utilizando o atalho CTRL + S:
Escolha um diretório de sua preferência em seu computador e salve o test plan. Repare que o JMeter criará um arquivo com a extensão .jmx no diretório escolhido.
Thread Group
O próximo passo será configurar o teste para que realize uma simulação de 500 usuários simultâneos disparando requisições para a API.
Essa configuração deve ser feita via adição do elemento Thread Group ao test plan.
O Thread Group representa um grupo de usuários virtuais que vai interagir com a aplicação durante o teste.
Cada Thread Group define o número de usuários virtuais (ou threads) que serão simulados, bem como a forma como esses usuários vão se comportar ao longo do teste, incluindo aspectos como o tempo de inicialização dos usuários, o tempo de espera entre as requisições e a duração total do teste.
Além disso, também é possível configurar o comportamento dos usuários em relação aos erros, definindo se uma thread deve continuar executando mesmo após encontrar um erro ou se deve interromper imediatamente.
Para adicionar um Thread Group ao Test Plan, basta clicar com o botão direito no Test Plan e escolher escolher a opção: Add -> Threads (Users) -> Thread Group:
Será exibida a tela de configuração do Thread Group, conforme demonstrada na imagem abaixo:
Nesta tela, existem diversos campos para realizar a configuração do Thread Group. A seguir, uma explicação do que significa cada um desses campos:
Name: Este campo permite atribuir um nome ao Thread Group para identificação e organização dentro do Test Plan; Comments: Este campo permite adicionar comentários ou notas relevantes ao Thread Group; Action to be taken after a Sampler error: Este campo define o comportamento a ser adotado pelo Thread Group caso um erro ocorra durante a execução dos testes; Number of Threads (users): Este campo define o número total de usuários virtuais (threads) que serão simulados pelo Thread Group durante o teste; Ramp-up period (seconds): Este campo especifica o tempo, em segundos, que o Thread Group levará para adicionar gradualmente os usuários virtuais até atingir o número definido em "Number of Threads (users)"; Loop Count: Este campo define o número de vezes que o Thread Group executará o conjunto de requisições. Se a opção Infinite for marcada, o teste será executado infinitamente, devendo ser finalizado manualmente; Same user on each iteration: Esta opção determina se o mesmo usuário virtual será usado em cada iteração do loop. Quando marcada, o mesmo usuário será mantido em todas as iterações; Delay Thread creation until needed: Esta opção indica se a criação das threads será adiada até que sejam necessárias. Quando marcada, as threads serão criadas apenas quando a execução começar; Specify Thread lifetime: Esta opção permite especificar a duração de vida das threads, ou seja, quanto tempo cada thread será mantida ativa durante o teste; Duration (seconds): Este campo permite definir a duração total do teste, em segundos; Startup delay (seconds): Este campo especifica um atraso inicial, em segundos, antes do início da execução do teste. Sampler
Uma vez configurado o Thread Group, devemos indicar ao JMeter o que esse Thread Group em específico deve fazer, ou seja, devemos configurar as ações que serão realizadas durante a execução do teste. Isso deve ser feito com a adição de um Sampler ao Thread Group.
O Sampler é responsável por simular uma ação específica que um usuário real poderia realizar ao interagir com a aplicação.
Isso pode incluir o envio de uma requisição , a execução de uma consulta em um banco de dados, entre outros. Cada Sampler representa um tipo de ação que pode ser executada pelos usuários virtuais durante o teste.
Para adicionar um Sampler ao Thread Group, basta clicar com o botão direito no Thread Group e escolher escolher a opção: Add -> Sampler:
Repare que nessa opção existem diversos tipos distintos de Samplers que podem ser adicionados ao Thread Group, sendo que cada um deles serve para realizar um tipo específico de ação.
No nosso caso, vamos escolher o Sampler do tipo HTTP Request, pois nosso teste consiste em disparar requisições HTTP para a API.
Ao selecionar essa opção, será exibida a tela de configuração do Sampler, conforme demonstrado na imagem a seguir:
Nesta tela, existem diversos campos para realizar a configuração do Sampler HTTP Request. A seguir, uma explicação do que significa cada um desses campos:
Name: Este campo permite atribuir um nome ao Sampler HTTP Request para identificação e organização dentro do Thread Group; Comments: Este campo permite adicionar comentários ou notas relevantes ao Sampler HTTP Request; Protocol [http]: Este campo define o protocolo a ser utilizado para a requisição; Server Name or IP: Este campo especifica o nome do servidor ou o endereço IP para o qual a requisição HTTP será enviada; Port Number: Este campo define o número da porta a ser utilizada para a conexão com o servidor; HTTP Request: Nesta seção, são configuradas as opções específicas da requisição HTTP; Method: Esta opção define o método HTTP a ser utilizado na requisição, como GET, POST, entre outros; Path: Este campo especifica o caminho (path) da URL para a qual a requisição será enviada; Content encoding: Este campo permite especificar a codificação do conteúdo da requisição, se necessário; Redirect Automatically, Use multipart/form-data e Browser-compatible headers: Estas opções definem o comportamento da requisição em relação a redirecionamentos, uso de formulários multipartes (usados com upload de arquivos) e cabeçalhos compatíveis com o navegador; Follow Redirects e Use KeepAlive: Estas opções configuram se o JMeter deve seguir automaticamente os redirecionamentos e se deve manter a conexão ativa (KeepAlive) após a requisição. Você deve configurar os valores nesta tela de acordo com a aplicação que você deseja testar.
É possível executar os testes do JMeter localmente, em ambiente de desenvolvimento, bastando executar a aplicação em seu computador e digitar localhost no campo Server Name or IP.
Mas lembre-se de que o ideal é sempre testar no ambiente de produção, quando isso for possível, ou então em um ambiente de testes/homologação que seja o mais próximo possível do ambiente de produção.
A partir deste ponto já podemos executar os testes no JMeter. Porém, para conseguir visualizar o resultado dos testes é necessário adicionar mais um elemento ao nosso Test Plan.
LIstener
Os Listeners são componentes responsáveis por coletar e exibir os resultados dos testes de performance realizados.
Eles auxiliam na análise dos dados gerados durante os testes, permitindo avaliar o desempenho da aplicação e identificar possíveis gargalos.
Os Listeners funcionam como "ouvintes" que capturam e exibem os dados gerados durante a execução dos testes.
Eles podem exibir uma variedade de informações, como tempos de resposta, taxas de erro, entre outras.
Cada tipo de Listener oferece uma visualização específica dos dados, permitindo analisar diferentes aspectos do desempenho da aplicação.
Para adicionar um Listener ao Thread Group, basta clicar com o botão direito no Thread Group e escolher escolher a opção: Add -> Listener: