No início do mês de outubro conduzi, em conjunto com a Cristina Vilas-Bôas , uma Comunidade de Prática (CoP) de Qualidade de Software sobre algumas ferramentas de teste que utilizamos nos projetos em que atuamos na SoftDesign. Na ocasião, apresentei o JMeter, ferramenta para operar testes de carga e estresse em aplicações.
Desenvolvida e mantida pela Apache Foundation, o JMeter é bastante utilizado principalmente por ser uma ferramenta gratuita, de código aberto, além de ser multiplataforma e escrita em Java. Ele permite a avaliação da performance de uma aplicação e grava todas as requisições que um usuário faria em uma situação real. Dessa forma, é possível simular ações dentro da aplicação que ficam gravadas em uma estrutura chamada ‘grupo de teste’, por exemplo.
Após a gravação, o JMeter permite disparar vários lotes simultâneos de requisições, imitando um grupo de usuários. A partir da coleta de dados com base nas respostas, as estatísticas são calculadas e as métricas de performance são geradas, fornecendo cenários de testes mais próximos da realidade.
Script e estrutura de testes
Ao montar um roteiro para os testes, é essencial definir antecipadamente o que irá, de fato, ser testado. Também é importante priorizar as funcionalidades que terão acessos simultâneos e as requisições que podem ser mais lentas. Após essa etapa, é necessário dividi-las e organizá-las por grupos de usuários. Em todos os casos, os testes poderão ser executados de forma simultânea ou separados, pois cada um será configurado de uma forma diferente de acordo com o objetivo da funcionalidade.
O JMeter possui uma estrutura simples de organização, como observamos na figura abaixo. É possível identificar um formato de árvore, onde ficam todos os componentes que serão utilizados por ele. O componente principal, por exemplo, é o plano geral de teste e o responsável por controlar a execução de todos os grupos. É também nessa estrutura que definimos as configurações de execução dos testes.
Definição de grupo de usuários e requisições na ferramenta
Após a primeira etapa de criação dos scripts, é necessário configurar alguns parâmetros. O tempo de inicialização, de execução dos testes nos grupos de usuários e quais deles serão executados são só alguns exemplos do que precisa ser ajustado, como vemos na figura abaixo:
Para efetivar os testes, é indispensável enviar requisições aos servidores. Para que isso aconteça, deve-se utilizar os componentes do sampler – que são controladores pré-definidos para solicitações especificas. Nele temos disponíveis várias opções, tais como FTP, SOAP/XML-RCP, Java, HTTP, entre outros.
Para definir quais serão realizadas existem diversos métodos, os mais utilizados são o Get e Post. O primeiro permite enviar uma requisição ao servidor somente de leitura ou consulta. Já o segundo também envia uma requisição ao servidor, porém ela permite o envio de dados para inclusão ou edição de requisitos.
Árvore de resultado e outros relatórios
Na ocasião, comentei com os participantes da CoP sobre as árvores de resultado. Esse é momento em que as informações de cada requisição feita por cada usuário durante o teste são capturadas, tais como os parâmetros foram enviados na requisição e qual o tempo de resposta dos servidores. Um fato interessante deste formato de relatório é que, quando há algum erro, ele aponta exatamente o que está ocorrendo.
Outro tipo de relatório é o de sumário, onde é uma planilha é gerada com as principais informações da execução do teste. Além desses, existem outros tipos de relatórios disponíveis – qual será utilizado irá depender do tipo de informação que será avaliada, alguns geram gráficos e outros fornecem apenas as informações.
Acho importante ressaltar – para finalizar – que a execução dos testes deve ser realizada enquanto o sistema não tem nenhum acesso, para que não haja interferência nos resultados. Os testes de performance devem ser feitos após a aplicação estar estável, pois não é indicado criar scripts de testes para funcionalidades que serão eventualmente alteradas.
