Você está na página 1de 24

Capítulo

1
Automação de Testes de Desempenho e Estresse com o JMeter
Ismayle de Sousa Santos, Pedro de Alcântara dos Santos Neto

Resumo A atividade de teste é uma das atividades relacionadas à garantia da qualidade de software. Existem vários tipos de testes, mas no cenário atual, em que a maioria dos sistemas está voltada para a Web, os testes de desempenho e estresse têm um destaque especial. É através deles que podemos verificar, dentre outras coisas, a performance e a capacidade de recuperação de falhas do sistema. O custo dos testes, entretanto, é geralmente alto, não sendo raro que esse custo chegue a 40% do esforço total de um projeto. Por isso a importância do uso de ferramentas de automação de testes. O objetivo deste curso é apresentar os conceitos relacionados aos testes de desempenho e estresse, bem como a utilização do JMeter, uma ferramenta de automação apropriada para esse tipo de teste.

1.1. Introdução
O desenvolvimento de sistemas de software envolve uma série de atividades em que a possibilidade de injeção de erros são enormes. Por conta disso, o teste de software é um elemento crítico na garantia da qualidade de um produto, atuando como uma revisão final da especificação, desenho e geração de código. Ao realizarmos testes durante o desenvolvimento de software adicionamos valor ao produto, uma vez que o teste corretamente executado tende a descobrir falhas, que devem ser corrigidas, aumentando assim a qualidade e confiabilidade de um sistema [7]. Apesar de sua importância, os testes muitas vezes não são executados visto que a realização dessa atividade é geralmente bastante onerosa em um desenvolvimento. Dependendo do tipo de sistema a ser desenvolvido, ela pode ser responsável por mais de 50% dos custos [7]. Para se ter uma idéia dos custos envolvidos, de acordo com um relatório publicado pelo NIST [6], U$59.500.000.000,00 é o valor relativo ao custo de falhas em softwares desenvolvidos nos Estados Unidos, apenas em 2002. Esse mesmo relatório estima que mais de 37% desse custo (U$22.200.000.000,00) poderia ter sido eliminado se a infraestrutura para teste fosse melhorada.

O teste de software é a verificação dinâmica do funcionamento de um programa utilizando um conjunto finito de casos de teste, adequadamente escolhido dentro de um domínio de execução infinito, contra seu comportamento esperado [3]. Nesse conceito existem alguns elementos chaves: • dinâmica: o teste exige a execução do produto, embora algumas de suas atividades possam ser realizadas antes do produto estar operacional; • conjunto finito: o teste exaustivo é geralmente impossível, mesmo para produtos simples; • escolhido: é necessário selecionar testes com alta probabilidade de encontrar defeitos, preferencialmente com o mínimo de esforço; • comportamento esperado: para que um teste possa ser executado é necessário saber o comportamento esperado, para que ele possa ser comparado com o obtido. Com base no que foi exposto anteriormente é possível notar a importância da utilização de ferramentas que automatizem a criação e execução dos testes. Neste trabalho apresentamos uma visão geral sobre os testes de desempenho e estresse, destacando como automatiza-lo a partir do uso da ferramenta JMeter. Utilizamos a seguinte estrutura neste trabalho: na próxima seção apresentamos os conceitos de testes de desempenho e estresse; em seguida, o JMeter e seus principais componentes são descritos; por fim, descrevemos um exemplo da utilização do JMeter em um sistema, além de concluirmos o trabalho com algumas observações relacionadas a tal tipo de teste.

1.2. Testes de Desempenho e Estresse
Testes de desempenho consistem em testar um sistema quanto aos seus requisitos de desempenho. Alguns exemplos desses requisitos são[2]: • Latência, que é o tempo entre uma requisição e a completude e resposta da operação requisitada; • Vazão (throughput), o número de operações que o sistema é capaz de completar em um dado período de tempo; • Escalabilidade, a quantidade de usuários simultâneos que o sistema pode lidar; • Uso de recursos de máquina, como memória e processamento. Para a correta execução desse tipo de teste é necessário que haja um conjunto bem definido de objetivos para esses requisitos, do contrário, esses testes serão medições cegas [8]. Apesar de um teste de desempenho completo e ideal depender da existência de um sistema totalmente integrado e funcional, no contexto sobre o qual o mesmo irá funcionar, testes de desempenho são freqüentemente aplicados em todos os passos do processo de teste [7]. Isso está fundamentado na máxima que diz que quanto mais cedo uma falha é detectada, mais eficiente e barata é a sua solução, principalmente levando em

mas hoje a ferramenta. Na Figura 1. Assim. mas não toleráveis. não raro havendo confusão entre os mesmos. porém importantes. podendo inclusive ser utilizada para testar objetos implementados em Java. Testes de estresse normalmente são feitos juntamente com testes de desempenho. Essas asserções aceitam inclusive expressões regulares. Além de poder ser usado para criação e execução de testes de desempenho e estresse.1.1 é possível . a organização dos elementos que compõe o teste é feita através de uma árvore hierárquica. é possível observar o comportamento do sistema durante essas situações críticas. com a consolidação dos sistemas Web. Além disso. como o vazamento de informações confidenciais de um banco de dados em mensagens de erro. cuja raiz é o Plano de Teste (TestPlan). No JMeter. JDBC. identificando falhas potencialmente difíceis de serem encontradas em situações normais. é resultado do trabalho de milhares de pessoas [4]. redução dos recursos computacionais disponíveis. pois em softwares de médio a grande porte. o JMeter também permite a realização de testes funcionais. a performance desses sistemas reflete diretamente na satisfação ou não do seu público. FTP. Isso acontece porque é comum o software ser largamente testado quanto à funcionalidade. o que lhes agrega mais poder e flexibilidade. dentre outros. como grandes quantidades de carga. o JMeter é compatível com qualquer ambiente capaz de suportar a máquina virtual Java versão 1. Eles demandam instrumentação de software e hardware. O JMeter também permite a criação de testes para diversos protocolos. tais como aplicações Web. Testes de desempenho e estresse geralmente são onerosos. Ele pode ser usado para simular cargas de trabalho em um servidor. é uma aplicação desktop projetada para a realização de testes de desempenho e estresse em aplicações cliente/servidor. entradas não realistas de dados. além de testadores hábeis e com bom conhecimento nas ferramentas escolhidas. como HTTP. SOAP. O seu desenvolvedor original foi Stefanno Mazzochi. 1.consideração o fato de que a maioria dos problemas críticos de desempenho advém de decisões feitas em estágios iniciais do ciclo de desenvolvimento do software [2]. Isso é possível graças aos vários tipos de asserções que ele possui e que podem ser usadas para verificar os resultados das requisições enviadas ao objeto de teste. por exemplo [1]. mas não ter seu desempenho apropriadamente testado [8]. membro da Apache Software Foundation. Enquanto o teste de desempenho tem como objetivo testar se determinado sistema é capaz de lidar com a carga definida nos requisitos. rede.3. questões relativas ao desempenho e comportamento sob estresse ganharam ainda mais visibilidade. São testes caros. os principais problemas relatados após a entrega do software estão relacionados à degradação de desempenho ou a incapacidade do sistema de lidar com a vazão exigida. cuja tela principal é apresentada na Figura 1. testando sua robustez. aplicações ou mesmo em um objeto.4 ou superior. JMeter O Apache JMeter. Isso porque no contexto de alta competitividade como é o atual. Por ser uma ferramenta inteiramente escrita em Java. que é Open Source. o teste de estresse consiste em submeter o sistema a situações anormais de uso [5]. comportamento anormal de portas em um servidor.

Componentes do JMeter Um Plano de Testes é para o JMeter um conjunto de elementos que descrevem uma série de passos que serão executados. como os Listeners (relatórios) e as Assertions (asserções). Quanto a execução dos testes com o JMeter. Outros elementos. deletar. copiar ou mover um elemento . Tela principal do Apache JMeter. Alguns elementos da árvore de teste são hierárquicos. A partilha do esforço do teste é uma característica muito importante e muitas vezes necessária para a correta execução dos testes de desempenho e estresse.2. ilustrado na Figura 1. como os Samplers (requisições). um teste bem definido geralmente incorpora vários componentes do JMeter. 1.1. são primariamente ordenados e. pertencendo e referenciando a outros elementos da ordem hierárquica superior. Assim. a ordem na qual aparecem verticalmente na árvore determina sua ordem de execução. pois com a distribuição da execução do teste entre várias máquinas evita-se gargalos tanto de processamento quanto de caminhos na rede do sistema sob teste. Para adicionar. na qual o esforço do teste é distribuído dentre diversas máquinas. cada elemento do script de teste corresponde a um elemento na estrutura XML. É através dela que os testadores podem conseguir uma maior fidelidade na recriação de cenários de teste.4. observar a árvore mencionada. ela pode ser feita de duas formas: em uma máquina só ou de forma distribuída.Figura 1. Nesse arquivo. Essa organização também é refletida no arquivo XML gerado pela ferramenta para a persistência dos elementos. portanto.

Essa sessão. basta clicar com o botão direito do mouse sobre o elemento e escolher a opção desejada. Um componente também pode "conter"outro componente. o primeiro "Duration Assertion"é filho da requisição nomeada de "Login". são os componenetes do JMeter que devem estar presentes em todos os testes criados/executados com ele.1.2. Nesse caso.4. entretanto. que está em uma hierarquia superior a do filho e com o qual o filho está ligado.1. e o outro é o "pai". diz-se que um é o "filho". Elementos Básicos Os elementos denominados aqui como "Básicos". Os elementos referidos são. • Test Plan: componente que representa o plano de teste.Figura 1. . por exemplo. todos os elementos da mesma hierarquia ou inferior ao dessa requisição são filhos do Thread Group. que é por sua vez filho do Test Plan. 1. Na Figura 1. O JMeter possui vários componentes que podem ser usados na criação dos testes. o que está a uma hierarquia inferior. Trecho do arquivo XML gerado pelo JMeter. abordará apenas aqueles mais usados e diretamente ligados à criação e execução de testes automatizados para sistemas Web. (componente) de um script de teste.

Além disso. Já o Thread Group deve ser adicionado manualmente. . Os dois primeiros elementos citados anteiormente estão presentes no script de teste desde o momento em que o JMeter é iniciado. adicionar comentários. que são visíveis por todas as requisições do plano de teste em questão. Figura 1. todos os elementos que forem seu filho não serão executados: eles são utilizados apenas como área de armazenamento temporário. Essa opção interfere significamente no desempenho da ferramenta e. o Test Plan contém duas caixas de seleção (checkbox): • "Functional Testing". criar variáveis globais. portanto. para a composição do teste. além de permitir a definição de parâmetros ou comportamentos comuns a todos os testes. A primeira ação a ser feita após a adição do Thread Group é configurar o Test Plan. ilustrado na Figura 1. Test Plan .• WorkBench: é uma espécie de "área de trabalho". • Thread Group: contém a configuração do grupo de usuários virtuais. não deve estar marcada no caso de um teste de desempenho ou estresse.3.plano de teste Nele é possível definir um nome identificador para o Plano do Teste. que se selecionada faz com que o JMeter grave os dados retornados do servidor para cada requisição feita.3. Assim. onde cada usuário corresponde a uma thread que é lançada e controlada pelo JMeter e que simula a navegação do usuário na aplicação sob teste.

devem ser adicionados como filho de algum Thread Group. • "Loop Count": define quantas vezes o plano de teste será executado. o número de usuários virtuais. • "Number of threads": o número de threads que executarão os testes. o Thread Group.grupo de usuários virtuais Na criação de testes com o JMeter. ilustrado na Figura 1. ou seja. Se forem definidas 10 threads e um ramp-up de 100s. caso seja marcado o checkBox "Forever". com exceção do WorkBench. Cada thread irá executar o plano de teste de forma independentemente das outras threads que estão executando. uma thread será iniciada a cada 10s. Podemos ter vários Threads Groups ligados ao Test Plan. ou seja. Figura 1.4. .• "Run each Thread Group separately". Como supracitado. por isso threads múltiplas são usadas para simular conexões concorrentes na aplicação sob teste. então o JMeter levará 100s para iniciar todas as threads. Thread Group . ou seja. • "Ramp-Up Period": define a frequência de lançamento das threads. com o qual pode-se definir se os grupos de usuários virtuais serão executados simultaneamente ou sequencialmente. Logo. deve definir suas propriedades.4. representa um grupo de usuários virtuais. o testador deve configurar o Thread Group. após configurar o Test Plan. o teste entrará em execução infinta e o valor definido no Loop Count será desconsiderado. e todos os outros elementos.

1.4.• "Scheduler": através do qual pode-se definir um horário para o início e término da execução dos testes. Figura 1.1. No caso de um sistema Web. JDBC Request. FTP Request. a configuração dessa propriedade é opcional.5 apresentamos um exemplo de um HTTP Request adicionado a um Plano de Teste. como por exemplo. 1.2. Ao contrário das citadas anteriormente. dentre outros. HTTP Request O HTTP Request permite o envio de requisições HTTP/HTTPS ou arquivos para um servidor Web. apresentamos a seguir apenas o HTTP Request (Requisição HTTP). Sampler Samplers são componentes que representam cada requisição que o JMeter fará ao servidor quando o plano de teste for executado. HTTPRequest . Na Figura1. Cada Sampler contém várias propriedades que podem ser configuradas.2.4.Requisição HTTP Dentre as propriedades desse elemento podemos destacar: . cada operação ou mudança de página corresponde a uma requisição.5. Como o objetivo deste artigo é apresentar a automação de testes de desempenho e estresse para aplicações web. HTTP Request. O JMeter contém vários tipos de Samplers.

Esse elemento atua independentemente da propriedade "Loop Count"do Thread Group.4. "Once only Controller". e POST. • "Server": URL ou endereço ip do servidor Web. 1. • "Port": a porta a ser usada. "Interleave Controller" e "If Controller". Logic Controllers Os Logic Controllers são usados para alterar a execução do plano do teste. repetir a execução de requisições e executar requisições somente sob certas condições.6. "Loop Controller". do sistem sob teste. • "Protocol": define se a requisição é HTTP. Assim. • "Path": o path da página testada. Por default ela já está configurada como 80.3. Loop Controller O Loop Controller (Figura 1. . HTTPS or FILE (para enviar arquivo ao servidor). 1. no qual os dados são enviados na própria URL. Com ele o usuário pode agrupar Samplers e outros elementos de forma a deixar o teste mais organizado e inteligível. selecionar qual requisição será enviada dentre um conjunto de requisições.4. Com eles é possível.3. Simple Controller Os Simple Controllers são elementos que não causam nenhuma alteração na execução dos testes. então a requisição em questão será executada 3 ∗ 2 = 6 vezes. onde os dados são enviados "ocultamente"na requisição.2.1. Os principais métodos são o GET. Login ou Usuario.• "Name": o nome da requisição.4. sendo utilizado somente para organizar a árvore do plano de teste. onde três Simpler Controller são usados para agrupar as requisições de forma a permitir a fácil identificação de quais delas são executadas em cada um dos dois casos de uso. se o plano de teste foi configurado para ser executado três vezes e existe uma "requisição A"que está como filho de um Loop Controller configurado para ser executado 2 vezes. Uma ilustração dessa situação pode ser visualizada na Figura 1. • "Method": define o método de submissão dos dados. não são visíveis na URL.3. 1. ou seja.7) é o componente no qual é possivel determinar quantas vezes um certo grupo de requisições deve ser executado. • "Send Parameters With the Request": no qual adicionamos todos os parâmetros e os seus respectivos valores para serem enviados junto com a requisição. Serão apresentados aqui os principais controladores lógicos: "Simple Controller". por exemplo.

sejam executados uma única vez por cada thread. assim como seus filhos.7.Controlador Simples Figura 1. a requisição que está sobre o efeito desse elemento só será executada na primeira iteração do teste.4.Controlador de Loop 1. LoopController .3.Figura 1. Assim. Testes que requerem um único login para estabelecer a sessão podem ser criados utilizando uma requisição que faça o login como filho de um Once Only Controller.6. Dessa forma. o login só é executado apenas uma vez por cada thread. Once Only Controller O Once Only Controller.3. permite que as requisições controladas por ele. SimpleController . ilustrado na Figura 1.8. .

No exemplo ilustrado na Figura 1. tendo a seguinte sequência de execução: Requisição A. If Controller Com o If Controller é possível colocar uma condição que será avaliada para definir se o seu filho vai ser executado ou não. Requisição C.Controlador de Alternância O JMeter também possui o Random Controller.8.5.4. apresentamos um teste que foi configurado para iterar duas vezes. Requisição A. A única diferença entre eles é o fato desse não alternar entre as requisições com base na ordem em que foram colocadas. Figura 1. . Requisição B.9.Figura 1. a "requisição A"só será executada se a variável "var"tiver valor menor que 10. No exemplo ilustrado na Figura 1.10.Controlador de execução única 1.4. que é similar ao Interleave Controller. 1. É importante observar também como é feita a referência a variáveis no JMeter: devemos utilizar o nome da variável (var) entre chaves e precedida de cifrão ($).3. O Random Controller simplesmente escolhe aleatoriamente um dos seus filhos a cada iteração. Interleave Controller O Interleave Controller é usado para alternar entre seus filhos a cada iteração. com base na ordem em que eles estão dispostos. OnceOnlyController .3.4.9. InterleaveController .

Figura 1.4.10.4. Esse elemento também permite visualizar o resultado de várias formas diferentes. HTML ou XML. o usuário também toma conhecimento do tempo gasto para obtenção da resposta.4. por exemplo. a média e a taxa de requisições realizadas por segundo. Assertion Results O Assertion Results permite uma visualização do resultado das asserções que falharam. "Assertion Results" e "Graph Results". gera um gráfico que plota os tempos de todas as requisições.1.4. A partir da figura podemos observar que esse Listener é ideal para visualizar o que exatamente o usuário final deveria de acordo com cada requisição. Através dele. 1. ilustrado na Figura 1. A Figura 1. mas apenas três serão abordados a seguir : "View Results Tree". No exemplo ilustrado na Figura 1.4. ele mostra que o Response Assertion da "requisição A"falhou. e o porquê da falha. o desvio padrão.Controlador IF 1.3. como por exemplo. Além de exibir os resultados.4. O . que pode ser inclusive uma planilha eletrônica. Graph Results O Graph Results. ele indica qual asserção falhou (Response ou Duration). View Results Tree O View Results Tree é um listener que mostra uma árvore com as respostas de todos os samplers.12. Além de indicar qual requisição teve falha na asserção. pois ele procurou pela palavra "teste"e não a encontrou na página resultante da execução dessa requisição. ifController .13.11 ilustra a utilização desse listener. permitindo assim que o testador veja o resultado de cada sampler que foi executado. como por exemplo.4. Existem vários tipos de Listeners. contendo tais resultados. os listeners também possibilitam a geração de um arquivo. Os Listeners capturam os dados das informações durante a execução dos testes e criam relatórios e gráficos com os resultados obtidos. além de outras informações associadas à requisição. no formato texto. a URL acessada e os parâmetros enviados.4. 1. 1. Listeners Para visualizar os resultados dos testes é necessário adicionar um Listener ao plano de teste.2.

Configurations Elements Os Configurations Elements são elementos que podem adicionar ou modificar dados das requisições. Os principais Configurations Elements utilizados em testes para aplicações Web são o "HTTP Cookie Manager". assim como os outros.Figura 1. View Results Tree .4. 1. permite a indicação de um arquivo para exportar a visualização gerada.Visualizador dos Resultados em árvores Figura 1.12. usado para manter a sessão. e o "HTTP Request .11.5. Assertion Results .Visualizador dos Resultados das Asserções testador tem a possibilidade de optar por quais desses dados ele quer visualizar no gráfico e esse Listener.

13. Graph Results . Já no segundo.14 . No primeiro caso. pode ser usado de duas formas: sem preencher nenhum valor ou configurando o Cookie manualmente. para definir o servidor que será usado por todas as HTTP Requests da sua hierarquia ou inferior. se ela contiver um cookie. o Cookie Manager servirá para compartilhar o mesmo cookie entre todas as threads. HTTP Cookie Manager Esse elemento.1. quando o testador adiciona manualmente um cookie. esse será armazenado e enviado para as próximas requisições para o mesmo site.Figura 1. 1.4. Isso quer dizer que após o JMeter receber a resposta de uma requisição. ilustrado na Figura 1. esse componente guarda e envia os cookies como um browser e atua como se houvesse um Cookie Manager para cada thread. .5.Visualizador dos Resultados em um Gráfico Defaults".

ao invés de definirmos em cada HTTP Request o servidor. Assim.14. restanto às HTTP Requests definir apenas os path e os parâmetros das páginas testadas.2. por exemplo.Figura 1. Figura 1.5. Se um teste contiver.Padrão das Requisições HTTP . 30 requisições para um mesmo site. HTTP Request Defaults . uma hierarquia inferior. ilustrado na Figura 1.Gerenciador do Cookie de requisições HTTP 1.15. então elas provavelmente acessarão o mesmo servidor.4. HTTP Request Defaults Esse elemento permite a definição de propriedades para serem utilizados por todos os HTTP Request da sua mesma hierarquia ou e. colocamos o endereço do servidor apenas no HTTP Request Defaults.15. HTTP Cookie Manager .

4. pois a partir dela podemos verificar o atendimento a um dos principais requisitos de desempenho: o tempo de resposta das requisições.4. Com as assertions.6. 1. o testador obtém a certeza de que a aplicação está retornando o resultado esperado. Na Figura 1.6. Se o texto não for encontrado a asserção falhará.Asserção na Resposta 1. é usado para definir o tempo máximo que o sistema tem para responder a uma requisição.6. temos uma Response Assertion que possui um único objetivo.1. ilustrado na Figura 1. a asserção falhará. Response Assertion . na requisição obtida como resposta. Caso o texto não seja encontrado.16 . Response Assertion O Response Assertion faz com que o JMeter procure por um determinado texto. Figura 1.1. duas assertions são muito utilizadas: "Response Assertion"e "Duration Assertion".16. caso esses elementes estejam adicionados a um plano de teste. por exemplo. A procura por esse texto é feito utilizando-se o sistema de expressão regular presente na ferramenta. definido pelo testador. Duration Assertion O Duration Assertion. aparecendo destacado no View Results Tree.4. Assertions Os Assertions permitem a validação das respostas recebidas do servidor que está sendo testado. Em testes para servidores Web. . Essa assertion é muito utilizada. Isso porque ela faz com que o JMeter procure determinado texto dentro do conteúdo retornado de uma requisição. que é encontrar a palavra "teste"na reposta da requisição a qual ele está associado.17. Caso a obtenção da resposta demore mais que o tempo definido. a asserção falhará e aparecerá no Assertion Results em vermelho.2.

Uma possível solução seria acrescentar um contador. Timers Por default. basta colocar como valor desse campo uma string qualquer seguido da referência à variável que contém o valor do contador. por exemplo. nome da . vamor máximo. que representa um contador que pode ser referenciado em qualquer lugar do Plano de Testes. Para isso. ilustrado na Figura 1.Asserção do Tempo de Resposta 1. Eles são utilizados para modificar características ou atualizar valores de variáveis das requisições antes que estas sejam executadas. uma seguida da outra.8. Esse timer define o tempo em milisegundos que cada thread deve aguardar entre as requisições. para colocar um valor único em um certo campo em cada iteração. Ele pode ser usado. Pre-Processors Um Pre-Processor é um elemento que executa certas ações antes da requisição ser enviada. cujo valor deve ser único toda vez que essa requisição for executada.18. o "Reference Name"do contador.Figura 1.19. que temos como parâmetro de uma requisição. por exemplo. tornando-as mais realistas. mas para simplificar. Constante Timer . o "Constant Timer". um campo com nome "login". Suponhamos. Duration Assertion . Timers devem ser usados para simular paradas entre as requisições.4. o JMeter envia as requisições das threads sem pausar um tempo entre elas.Tempo constante entre as requisições 1. ilustrado na Figura 1. apresentamos aqui apenas o mais simples deles.7. definir suas propriedades (valor inicial. Como os usuários sempre analisam os resultados obtidos antes de executar a próxima ação. Dentre os Pre-Processors disponíveis temos o Counter. Figura 1.4. incremento.18.17. Existem vários tipos de timers. Isso significa que as requisições serão disparadas rapidamente.

9. destaques. Counter . que permite ao testador extrair valores da resposta proveniente do servidor a partir de expressões regulares. A função desse gerador é tornar simples a criação de páginas. notícias. como valor do campo "login".Extrator de Expressões Regulares 1.Contador 1. Geralmente eles são utilizados para processar os dados recebidos da requisição e os seus resultados são utilizados para modificar as requisições seguintes. Post-Processors Um Post-Processor é um elemento que executa uma ação depois que uma requisição é executada.19. Figura 1.5.20. seguindo um formato préestabelecido. Figura 1. Regular Expression Extractor . Dentre os Post-Processors.4. ilustrado na Figura 1. onde "cont"é o nome da variável do contador.variável) e colocar "login${cont}". Criando testes de desempenho e estresse automatizados Esta sessão tem por objetivo apresentar um pequeno exemplo de utilização da ferramenta para a automação de testes de desempenho e estresse de um sistema Web. Os usuários do sistema podem criar menus laterais. O objeto de teste referido é uma parte de um gerador (sistema) de páginas Web para usuários leigos. .20. destacamos o Regular Expression Extractor.

pois para acessar o sistema é preciso logar e é necessário manter a sessão do usuário logado para permanecer no sistema. que corresponde as operações de inclusão. acrescentamos também o HTTP Request Defaults. Figura 1.22 . Existem caraterísticas importantes que devem ser observadas nesse ponto. Também colocamos o teste para repetir por três vezes. como por exemplo. busca e remoção de um usuário desse sistema. bem como as asserções para verificar o atendimento aos requisitos de desempenho. o path supracitado não é qualquer path do sistema. cuja função é fazer o usuário virtual logar na página.21. mas iremos abordar aqui apenas o caso de uso Usuários. Logo. para a configuração correta. Plano de Teste do caso de uso Usuário Em seguida. adicionamos os listeners. O estado do Test Plan com essas cofigurações é ilustrado na Figura 1. Como já tinhamos configurado o HTTP Request Default. muitas vezes é necessário olhar o código-fonte da página ou algum documento que tenha .usuários para administrar as páginas e links para outras páginas e arquivos. Para mantermos o teste organizado adicionamos quatro Simpler Controllers. O path em questão é o path que tratará os dados provenientes da requisição. o View Resulsts in Tree e o Graph Results. basta colocar as requisições que realizam as operações. Para iniciar a criação desse teste. que no caso da requisição "Login"são os campos login e senha.21. Com base nos requisitos definidos para esse sistema. cada um nomeado com a operação cujas requisições filhos irão realizar. Primeiro criamos a requisição "Login". para assim confirmarmos os padrões de comportamento do sistema. Em primeiro lugar. Por fim. configurando-o com o endereço do servidor que será testado e o HTTP Cookie Manager. só precisamos agora definir o path e os parâmetros da página testada. a identificação de que certa operação sempre demora mais que o esperado. configuramos o teste para 100 usuários simultâneos a serem disparados em 50 segundos. Esse sistema possui no total 8 casos de uso. O resultado pode ser visualizado na Figura 1. alteração. E como os testes seriam todos para um mesmo servidor. primeira coisa a ser feita é a inserção do Thread Group e configuração do nosso Test Plan.

identificamos que o método utilizado é o POST e observamos que os campos necessários não eram somente "login"e "senha". devemos desmarcar a opção Redirect Automatically. o path dessa requisição é o mesmo path onde o usuário insere os dados. ou para a página principal caso o login seja bem sucedido. quando o usuário efetua a operação de login.22.. Outro detalhe que merece ser mencionado está relacionado aos re-direcionamentos de alguns sistemas Web. a fim de descobrir qual página receberá aqueles dados. o JMeter não "seguirá"esse redirecionamento e. o sistema redireciona para a mesma página. Assim. Isso pode ser facilmente visualizado através do código-fonte da página onde o usuário insere o login e a senha. No nosso exemplo. oncluindo então que ela própria recebe e trata o login e a senha. e marcar a opção Follow Redirects. por exemplo. continuará na mesma página para o qual os dados foram enviados. O problema é que se a opção Follow Redirects não estiver marcada. verificamos que a página que trata os dados é a própria página que os recebe. ilustrado na Figura 1. Assim. se o login falhar. Isso porque os campos hidden são usados pela página para identificar a submissão de . Plano de Teste do caso de uso Usuários com as configurações gerais toda a configuração dela. portanto..) e adicionar os parametros necessários. por exemplo. que não segue os re-direcionamentos que vem como resposta de uma requisição.POST. No sistema utilizado neste trabalho.23. devemos colocar como método de submissão aquele utilizado pela página (GET.. Para o correto funcionamento da requisição é necessário colocar também o campo "enviado". ilustrado na Figura 1.Figura 1.23. Nele observamos que a ação do formulário que recebe o login e a senha está em branco. Na página de login do usuário. Além disso. a partir do código-fonte.

ou seja. o valor "ok". Código-fonte da página de login do usuário do sistema dados.24. Execução da requisição "Login"do estudo de caso Como basta um login para cada usuário virtual. Figura 1. colocamos a requisição de login como filho do controlador Once Only Controller. como é visto na Figura 1.23.Figura 1. o login foi bem sucedido. Nesse caso devemos preencher os valores respectivos dos campos login e senha. Como resultado de todas essas configurações. logo são campos necessários para a execução da operação requisitada.24. Continuando a automação do teste. in- . colocando também o valor do campo "enviado"como sendo o valor definido na sua propriedade value.

Figura 1. para nos certificarmos que a página alvo foi alcançada e um Duration Assertion. podem ser utilizados pelo testador para avaliar sobre o atendimento da aplicação aos requisitos de desempenho existentes. Com esses dados. Os resultados da execução do nosso exemplo. Feitas todas as requisições. devemos criar as outras requisições seguindo os mesmos passos: descobrindo o path. colocando os campos. deveria ser único para cada usuário. o método. a análise dos seus resultados é importante para se identificar as áreas críticas do sistema. temos agora um teste automatizado de desempenho e estresse para o caso de uso Usuário. Teste automatizado de desempenho e estresse para o caso de uso Usuário do sistema testado Além da construção dos testes. para medirmos o tempo gasto para responder a essa requisição. que nesse caso era o nome de login do usuário.serirmos uma Response Assertion. Por último. notamos que algumas asserções da requisição de Inserção de Usuário falhavam. podem ser visualizados na Figura 1. ou seja. em que "cont"é o nome da variável que contém o valor do contador. e modificamos o valor do campo login para usuario${cont}. Isso significa que durante a execução desses testes estamos inserindo usuários com os logins usuario1.25. Observamos então que isso acontecia porque na inserção de Usuário o campo "login". Feito isso. adicionado ao plano de teste. em forma de gráfico. usuario3. . teste esse visualizado na Figura 1.25.26. aliados aos resultados exibidos no View Results Tree. Adicionamos então um Count. usuario2. etc. criaremos um login único para cada usuário. adicionando um duration e um response assertion.

e apresentamos um estudo de caso de forma a esclarecer os procedimentos necessários para se automatizar os testes de desempenho e estresse com a ferramenta em questão. uma vez que os sistemas para Web cada vez ganham mais espaço em relação aos sistemas desktop. Gráfico resultante da execução dos testes 1. a utilização de ferramentas que automatizem a criação e execução dos mesmos é essencial.26. podemos concluir que no mercado competitivo como é o atual. destacamos os testes de desempenho e estresse. descrevemos os principais componentes do JMeter. Dentre os diversos testes. E com o que foi apresentado aqui. Esses testes ainda são pouco utilizados no cenário atual e como os custos associados a sua execução são altos. uma ferramenta de automação desses testes. Conclusão A atividade de Teste é fundamental para a garantia da qualidade dos produtos desenvolvidos. que estão crescendo em importância. fazer medições de tempo de resposta e simular muitos usuários acessando ao mesmo tempo uma aplicação é inviável e muitas vezes até impossível de se fazer sem uma ferramenta que automatize o processo.Figura 1. Neste trabalho apresentamos a automação de testes de desempenho e estresse para sistemas Web através de uma ferramenta de automação desses testes. investir em testes de software e em ferramentas que automatizem a sua realização pode . Além disso. Para isso.6.

A. pages 94–103. In WOSP ’04: Proceedings of the 4th international workshop on Software and performance. . JMETER. Referências [1] R. Aplicação desktop projetada para testes de carga e medidas de performance. Engenharia de Software. USA. Guide to the Software Engineering Body of Knowledge. [8] E. [6] NIST. Myers. 2004. 2000. Testing Object-Oriented Systems: Models. último acesso em 17/11/2008. NY. McGraw-Hill. Polini. 1979. Binder. http://jakarta. Apache Software Foundation. I.apache. J. IEEE Transactions on Software Engineering. Vokolos.gov/director/prog-ofc/report02-3.nist. and case study. Planning Report 02-3. [3] IEEE. The Art of Software Testing. http://www. John Wiley & Sons. 2006. ACM Press. Early performance testing of distributed software applications. 2002. Experience with performance testing of software systems: Issues.org/jmeter/. National Institute of Standards and Technology. and W.pdf. IEEE Computer Society. [4] A. 2004. 26(12):1147–1156. [2] G. and Tools. [5] G. New York. 6th edition. Weyuker and F. Technical report. Denaro. AddisonWesley. Emmerich. [7] R. an approach. 2000. Pressman.ser a chave de sucesso para muitas empresas. Patterns.