Sie sind auf Seite 1von 24

Captulo

1
Automao de Testes de Desempenho e Estresse com o JMeter
Ismayle de Sousa Santos, Pedro de Alcntara dos Santos Neto

Resumo A atividade de teste uma das atividades relacionadas garantia da qualidade de software. Existem vrios tipos de testes, mas no cenrio atual, em que a maioria dos sistemas est voltada para a Web, os testes de desempenho e estresse tm um destaque especial. atravs deles que podemos vericar, dentre outras coisas, a performance e a capacidade de recuperao de falhas do sistema. O custo dos testes, entretanto, geralmente alto, no sendo raro que esse custo chegue a 40% do esforo total de um projeto. Por isso a importncia do uso de ferramentas de automao de testes. O objetivo deste curso apresentar os conceitos relacionados aos testes de desempenho e estresse, bem como a utilizao do JMeter, uma ferramenta de automao apropriada para esse tipo de teste.

1.1. Introduo
O desenvolvimento de sistemas de software envolve uma srie de atividades em que a possibilidade de injeo de erros so enormes. Por conta disso, o teste de software um elemento crtico na garantia da qualidade de um produto, atuando como uma reviso nal da especicao, desenho e gerao de cdigo. 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 conabilidade de um sistema [7]. Apesar de sua importncia, os testes muitas vezes no so executados visto que a realizao dessa atividade geralmente bastante onerosa em um desenvolvimento. Dependendo do tipo de sistema a ser desenvolvido, ela pode ser responsvel por mais de 50% dos custos [7]. Para se ter uma idia dos custos envolvidos, de acordo com um relatrio 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 relatrio 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 vericao dinmica do funcionamento de um programa utilizando um conjunto nito de casos de teste, adequadamente escolhido dentro de um domnio de execuo innito, contra seu comportamento esperado [3]. Nesse conceito existem alguns elementos chaves: dinmica: o teste exige a execuo do produto, embora algumas de suas atividades possam ser realizadas antes do produto estar operacional; conjunto nito: o teste exaustivo geralmente impossvel, mesmo para produtos simples; escolhido: necessrio selecionar testes com alta probabilidade de encontrar defeitos, preferencialmente com o mnimo de esforo; comportamento esperado: para que um teste possa ser executado necessrio saber o comportamento esperado, para que ele possa ser comparado com o obtido. Com base no que foi exposto anteriormente possvel notar a importncia da utilizao de ferramentas que automatizem a criao e execuo dos testes. Neste trabalho apresentamos uma viso 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 prxima seo apresentamos os conceitos de testes de desempenho e estresse; em seguida, o JMeter e seus principais componentes so descritos; por m, descrevemos um exemplo da utilizao do JMeter em um sistema, alm de concluirmos o trabalho com algumas observaes 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 so[2]: Latncia, que o tempo entre uma requisio e a completude e resposta da operao requisitada; Vazo (throughput), o nmero de operaes que o sistema capaz de completar em um dado perodo de tempo; Escalabilidade, a quantidade de usurios simultneos que o sistema pode lidar; Uso de recursos de mquina, como memria e processamento. Para a correta execuo desse tipo de teste necessrio que haja um conjunto bem denido de objetivos para esses requisitos, do contrrio, esses testes sero medies cegas [8]. Apesar de um teste de desempenho completo e ideal depender da existncia de um sistema totalmente integrado e funcional, no contexto sobre o qual o mesmo ir funcionar, testes de desempenho so freqentemente aplicados em todos os passos do processo de teste [7]. Isso est fundamentado na mxima que diz que quanto mais cedo uma falha detectada, mais eciente e barata a sua soluo, principalmente levando em

considerao o fato de que a maioria dos problemas crticos de desempenho advm de decises feitas em estgios iniciais do ciclo de desenvolvimento do software [2]. Testes de estresse normalmente so feitos juntamente com testes de desempenho, no raro havendo confuso entre os mesmos. Enquanto o teste de desempenho tem como objetivo testar se determinado sistema capaz de lidar com a carga denida nos requisitos, o teste de estresse consiste em submeter o sistema a situaes anormais de uso [5], como grandes quantidades de carga, comportamento anormal de portas em um servidor, reduo dos recursos computacionais disponveis, entradas no realistas de dados. Assim, possvel observar o comportamento do sistema durante essas situaes crticas, identicando falhas potencialmente difceis de serem encontradas em situaes normais, mas no tolerveis, como o vazamento de informaes condenciais de um banco de dados em mensagens de erro, por exemplo [1]. Testes de desempenho e estresse geralmente so onerosos. Eles demandam instrumentao de software e hardware, alm de testadores hbeis e com bom conhecimento nas ferramentas escolhidas. So testes caros, porm importantes, pois em softwares de mdio a grande porte, os principais problemas relatados aps a entrega do software esto relacionados degradao de desempenho ou a incapacidade do sistema de lidar com a vazo exigida. Isso acontece porque comum o software ser largamente testado quanto funcionalidade, mas no ter seu desempenho apropriadamente testado [8]. Alm disso, com a consolidao dos sistemas Web, questes relativas ao desempenho e comportamento sob estresse ganharam ainda mais visibilidade. Isso porque no contexto de alta competitividade como o atual, a performance desses sistemas reete diretamente na satisfao ou no do seu pblico.

1.3. JMeter
O Apache JMeter, cuja tela principal apresentada na Figura 1.1, uma aplicao desktop projetada para a realizao de testes de desempenho e estresse em aplicaes cliente/servidor, tais como aplicaes Web. Ele pode ser usado para simular cargas de trabalho em um servidor, rede, aplicaes ou mesmo em um objeto, testando sua robustez. O seu desenvolvedor original foi Stefanno Mazzochi, membro da Apache Software Foundation, mas hoje a ferramenta, que Open Source, resultado do trabalho de milhares de pessoas [4]. Por ser uma ferramenta inteiramente escrita em Java, o JMeter compatvel com qualquer ambiente capaz de suportar a mquina virtual Java verso 1.4 ou superior. O JMeter tambm permite a criao de testes para diversos protocolos, como HTTP, JDBC, FTP, SOAP, dentre outros, podendo inclusive ser utilizada para testar objetos implementados em Java. Alm de poder ser usado para criao e execuo de testes de desempenho e estresse, o JMeter tambm permite a realizao de testes funcionais. Isso possvel graas aos vrios tipos de asseres que ele possui e que podem ser usadas para vericar os resultados das requisies enviadas ao objeto de teste. Essas asseres aceitam inclusive expresses regulares, o que lhes agrega mais poder e exibilidade. No JMeter, a organizao dos elementos que compe o teste feita atravs de uma rvore hierrquica, cuja raiz o Plano de Teste (TestPlan). Na Figura 1.1 possvel

Figura 1.1. Tela principal do Apache JMeter.

observar a rvore mencionada. Alguns elementos da rvore de teste so hierrquicos, como os Listeners (relatrios) e as Assertions (asseres), pertencendo e referenciando a outros elementos da ordem hierrquica superior. Outros elementos, como os Samplers (requisies), so primariamente ordenados e, portanto, a ordem na qual aparecem verticalmente na rvore determina sua ordem de execuo. Essa organizao tambm reetida no arquivo XML gerado pela ferramenta para a persistncia dos elementos. Nesse arquivo, ilustrado na Figura 1.2, cada elemento do script de teste corresponde a um elemento na estrutura XML. Quanto a execuo dos testes com o JMeter, ela pode ser feita de duas formas: em uma mquina s ou de forma distribuda, na qual o esforo do teste distribudo dentre diversas mquinas. A partilha do esforo do teste uma caracterstica muito importante e muitas vezes necessria para a correta execuo dos testes de desempenho e estresse. atravs dela que os testadores podem conseguir uma maior delidade na recriao de cenrios de teste, pois com a distribuio da execuo do teste entre vrias mquinas evita-se gargalos tanto de processamento quanto de caminhos na rede do sistema sob teste.

1.4. Componentes do JMeter


Um Plano de Testes para o JMeter um conjunto de elementos que descrevem uma srie de passos que sero executados. Assim, um teste bem denido geralmente incorpora vrios componentes do JMeter. Para adicionar, deletar, copiar ou mover um elemento

Figura 1.2. Trecho do arquivo XML gerado pelo JMeter.

(componente) de um script de teste, basta clicar com o boto direito do mouse sobre o elemento e escolher a opo desejada. Um componente tambm pode "conter"outro componente. Nesse caso, diz-se que um o "lho", o que est a uma hierarquia inferior, e o outro o "pai", que est em uma hierarquia superior a do lho e com o qual o lho est ligado. Na Figura 1.1, por exemplo, o primeiro "Duration Assertion" lho da requisio nomeada de "Login", todos os elementos da mesma hierarquia ou inferior ao dessa requisio so lhos do Thread Group, que por sua vez lho do Test Plan. O JMeter possui vrios componentes que podem ser usados na criao dos testes. Essa sesso, entretanto, abordar apenas aqueles mais usados e diretamente ligados criao e execuo de testes automatizados para sistemas Web. 1.4.1. Elementos Bsicos Os elementos denominados aqui como "Bsicos", so os componenetes do JMeter que devem estar presentes em todos os testes criados/executados com ele. Os elementos referidos so. Test Plan: componente que representa o plano de teste;

WorkBench: uma espcie de "rea de trabalho". Assim, todos os elementos que forem seu lho no sero executados: eles so utilizados apenas como rea de armazenamento temporrio, para a composio do teste; Thread Group: contm a congurao do grupo de usurios virtuais, onde cada usurio corresponde a uma thread que lanada e controlada pelo JMeter e que simula a navegao do usurio na aplicao sob teste. Os dois primeiros elementos citados anteiormente esto presentes no script de teste desde o momento em que o JMeter iniciado. J o Thread Group deve ser adicionado manualmente. A primeira ao a ser feita aps a adio do Thread Group congurar o Test Plan, ilustrado na Figura 1.3.

Figura 1.3. Test Plan - plano de teste

Nele possvel denir um nome identicador para o Plano do Teste, adicionar comentrios, criar variveis globais, que so visveis por todas as requisies do plano de teste em questo, alm de permitir a denio de parmetros ou comportamentos comuns a todos os testes. Alm disso, o Test Plan contm duas caixas de seleo (checkbox): "Functional Testing", que se selecionada faz com que o JMeter grave os dados retornados do servidor para cada requisio feita. Essa opo interfere signicamente no desempenho da ferramenta e, portanto, no deve estar marcada no caso de um teste de desempenho ou estresse.

"Run each Thread Group separately", com o qual pode-se denir se os grupos de usurios virtuais sero executados simultaneamente ou sequencialmente. Como supracitado, o Thread Group, ilustrado na Figura 1.4, representa um grupo de usurios virtuais. Podemos ter vrios Threads Groups ligados ao Test Plan, e todos os outros elementos, com exceo do WorkBench, devem ser adicionados como lho de algum Thread Group.

Figura 1.4. Thread Group - grupo de usurios virtuais

Na criao de testes com o JMeter, aps congurar o Test Plan, o testador deve congurar o Thread Group, ou seja, deve denir suas propriedades. "Number of threads": o nmero de threads que executaro os testes, ou seja, o nmero de usurios virtuais. Cada thread ir executar o plano de teste de forma independentemente das outras threads que esto executando, por isso threads mltiplas so usadas para simular conexes concorrentes na aplicao sob teste; "Ramp-Up Period": dene a frequncia de lanamento das threads. Se forem denidas 10 threads e um ramp-up de 100s, ento o JMeter levar 100s para iniciar todas as threads, ou seja, uma thread ser iniciada a cada 10s. "Loop Count": dene quantas vezes o plano de teste ser executado. Logo, caso seja marcado o checkBox "Forever", o teste entrar em execuo innta e o valor denido no Loop Count ser desconsiderado.

"Scheduler": atravs do qual pode-se denir um horrio para o incio e trmino da execuo dos testes. Ao contrrio das citadas anteriormente, a congurao dessa propriedade opcional. 1.4.2. Sampler Samplers so componentes que representam cada requisio que o JMeter far ao servidor quando o plano de teste for executado. No caso de um sistema Web, cada operao ou mudana de pgina corresponde a uma requisio. O JMeter contm vrios tipos de Samplers, como por exemplo, FTP Request, HTTP Request, JDBC Request, dentre outros. Cada Sampler contm vrias propriedades que podem ser conguradas. Como o objetivo deste artigo apresentar a automao de testes de desempenho e estresse para aplicaes web, apresentamos a seguir apenas o HTTP Request (Requisio HTTP). 1.4.2.1. HTTP Request O HTTP Request permite o envio de requisies HTTP/HTTPS ou arquivos para um servidor Web. Na Figura1.5 apresentamos um exemplo de um HTTP Request adicionado a um Plano de Teste.

Figura 1.5. HTTPRequest - Requisio HTTP

Dentre as propriedades desse elemento podemos destacar:

"Name": o nome da requisio; "Server": URL ou endereo ip do servidor Web; "Port": a porta a ser usada. Por default ela j est congurada como 80. "Protocol": dene se a requisio HTTP, HTTPS or FILE (para enviar arquivo ao servidor); "Method": dene o mtodo de submisso dos dados. Os principais mtodos so o GET, no qual os dados so enviados na prpria URL, e POST, onde os dados so enviados "ocultamente"na requisio, ou seja, no so visveis na URL; "Path": o path da pgina testada; "Send Parameters With the Request": no qual adicionamos todos os parmetros e os seus respectivos valores para serem enviados junto com a requisio; 1.4.3. Logic Controllers Os Logic Controllers so usados para alterar a execuo do plano do teste. Com eles possvel, por exemplo, selecionar qual requisio ser enviada dentre um conjunto de requisies, repetir a execuo de requisies e executar requisies somente sob certas condies. Sero apresentados aqui os principais controladores lgicos: "Simple Controller", "Loop Controller", "Once only Controller", "Interleave Controller" e "If Controller". 1.4.3.1. Simple Controller Os Simple Controllers so elementos que no causam nenhuma alterao na execuo dos testes, sendo utilizado somente para organizar a rvore do plano de teste. Com ele o usurio pode agrupar Samplers e outros elementos de forma a deixar o teste mais organizado e inteligvel. Uma ilustrao dessa situao pode ser visualizada na Figura 1.6, onde trs Simpler Controller so usados para agrupar as requisies de forma a permitir a fcil identicao de quais delas so executadas em cada um dos dois casos de uso, Login ou Usuario, do sistem sob teste. 1.4.3.2. Loop Controller O Loop Controller (Figura 1.7) o componente no qual possivel determinar quantas vezes um certo grupo de requisies deve ser executado. Esse elemento atua independentemente da propriedade "Loop Count"do Thread Group. Assim, se o plano de teste foi congurado para ser executado trs vezes e existe uma "requisio A"que est como lho de um Loop Controller congurado para ser executado 2 vezes, ento a requisio em questo ser executada 3 2 = 6 vezes.

Figura 1.6. SimpleController - Controlador Simples

Figura 1.7. LoopController - Controlador de Loop

1.4.3.3. Once Only Controller O Once Only Controller, ilustrado na Figura 1.8, permite que as requisies controladas por ele, assim como seus lhos, sejam executados uma nica vez por cada thread. Dessa forma, a requisio que est sobre o efeito desse elemento s ser executada na primeira iterao do teste. Testes que requerem um nico login para estabelecer a sesso podem ser criados utilizando uma requisio que faa o login como lho de um Once Only Controller. Assim, o login s executado apenas uma vez por cada thread.

Figura 1.8. OnceOnlyController - Controlador de execuo nica

1.4.3.4. Interleave Controller O Interleave Controller usado para alternar entre seus lhos a cada iterao, com base na ordem em que eles esto dispostos. No exemplo ilustrado na Figura 1.9, apresentamos um teste que foi congurado para iterar duas vezes, tendo a seguinte sequncia de execuo: Requisio A, Requisio B, Requisio A, Requisio C.

Figura 1.9. InterleaveController - Controlador de Alternncia

O JMeter tambm possui o Random Controller, que similar ao Interleave Controller. A nica diferena entre eles o fato desse no alternar entre as requisies com base na ordem em que foram colocadas. O Random Controller simplesmente escolhe aleatoriamente um dos seus lhos a cada iterao.

1.4.3.5. If Controller Com o If Controller possvel colocar uma condio que ser avaliada para denir se o seu lho vai ser executado ou no. No exemplo ilustrado na Figura 1.10, a "requisio A"s ser executada se a varivel "var"tiver valor menor que 10. importante observar tambm como feita a referncia a variveis no JMeter: devemos utilizar o nome da varivel (var) entre chaves e precedida de cifro ($).

Figura 1.10. ifController - Controlador IF

1.4.4. Listeners Para visualizar os resultados dos testes necessrio adicionar um Listener ao plano de teste. Os Listeners capturam os dados das informaes durante a execuo dos testes e criam relatrios e grcos com os resultados obtidos. Alm de exibir os resultados, os listeners tambm possibilitam a gerao de um arquivo, que pode ser inclusive uma planilha eletrnica, contendo tais resultados. Existem vrios tipos de Listeners, mas apenas trs sero abordados a seguir : "View Results Tree", "Assertion Results" e "Graph Results". 1.4.4.1. View Results Tree O View Results Tree um listener que mostra uma rvore com as respostas de todos os samplers, permitindo assim que o testador veja o resultado de cada sampler que foi executado. Atravs dele, o usurio tambm toma conhecimento do tempo gasto para obteno da resposta, alm de outras informaes associadas requisio, como por exemplo, a URL acessada e os parmetros enviados. Esse elemento tambm permite visualizar o resultado de vrias formas diferentes, como por exemplo, no formato texto, HTML ou XML. A Figura 1.11 ilustra a utilizao desse listener. A partir da gura podemos observar que esse Listener ideal para visualizar o que exatamente o usurio nal deveria de acordo com cada requisio. 1.4.4.2. Assertion Results O Assertion Results permite uma visualizao do resultado das asseres que falharam. Alm de indicar qual requisio teve falha na assero, ele indica qual assero falhou (Response ou Duration), e o porqu da falha. No exemplo ilustrado na Figura 1.12, por exemplo, ele mostra que o Response Assertion da "requisio A"falhou, pois ele procurou pela palavra "teste"e no a encontrou na pgina resultante da execuo dessa requisio. 1.4.4.3. Graph Results O Graph Results, ilustrado na Figura 1.13, gera um grco que plota os tempos de todas as requisies, o desvio padro, a mdia e a taxa de requisies realizadas por segundo. O

Figura 1.11. View Results Tree - Visualizador dos Resultados em rvores

Figura 1.12. Assertion Results - Visualizador dos Resultados das Asseres

testador tem a possibilidade de optar por quais desses dados ele quer visualizar no grco e esse Listener, assim como os outros, permite a indicao de um arquivo para exportar a visualizao gerada. 1.4.5. Congurations Elements Os Congurations Elements so elementos que podem adicionar ou modicar dados das requisies. Os principais Congurations Elements utilizados em testes para aplicaes Web so o "HTTP Cookie Manager", usado para manter a sesso, e o "HTTP Request

Figura 1.13. Graph Results - Visualizador dos Resultados em um Grco

Defaults", para denir o servidor que ser usado por todas as HTTP Requests da sua hierarquia ou inferior.

1.4.5.1. HTTP Cookie Manager Esse elemento, ilustrado na Figura 1.14 , pode ser usado de duas formas: sem preencher nenhum valor ou congurando o Cookie manualmente. No primeiro caso, esse componente guarda e envia os cookies como um browser e atua como se houvesse um Cookie Manager para cada thread. Isso quer dizer que aps o JMeter receber a resposta de uma requisio, se ela contiver um cookie, esse ser armazenado e enviado para as prximas requisies para o mesmo site. J no segundo, quando o testador adiciona manualmente um cookie, o Cookie Manager servir para compartilhar o mesmo cookie entre todas as threads.

Figura 1.14. HTTP Cookie Manager - Gerenciador do Cookie de requisies HTTP

1.4.5.2. HTTP Request Defaults Esse elemento permite a denio de propriedades para serem utilizados por todos os HTTP Request da sua mesma hierarquia ou e, uma hierarquia inferior. Se um teste contiver, por exemplo, 30 requisies para um mesmo site, ento elas provavelmente acessaro o mesmo servidor. Assim, ao invs de denirmos em cada HTTP Request o servidor, colocamos o endereo do servidor apenas no HTTP Request Defaults, ilustrado na Figura 1.15, restanto s HTTP Requests denir apenas os path e os parmetros das pginas testadas.

Figura 1.15. HTTP Request Defaults - Padro das Requisies HTTP

1.4.6. Assertions Os Assertions permitem a validao das respostas recebidas do servidor que est sendo testado. Com as assertions, o testador obtm a certeza de que a aplicao est retornando o resultado esperado. Isso porque ela faz com que o JMeter procure determinado texto dentro do contedo retornado de uma requisio. Se o texto no for encontrado a assero falhar. Em testes para servidores Web, duas assertions so muito utilizadas: "Response Assertion"e "Duration Assertion". 1.4.6.1. Response Assertion O Response Assertion faz com que o JMeter procure por um determinado texto, denido pelo testador, na requisio obtida como resposta. A procura por esse texto feito utilizando-se o sistema de expresso regular presente na ferramenta. Caso o texto no seja encontrado, a assero falhar e aparecer no Assertion Results em vermelho, aparecendo destacado no View Results Tree, caso esses elementes estejam adicionados a um plano de teste. Na Figura 1.16 , por exemplo, temos uma Response Assertion que possui um nico objetivo, que encontrar a palavra "teste"na reposta da requisio a qual ele est associado.

Figura 1.16. Response Assertion - Assero na Resposta

1.4.6.2. Duration Assertion O Duration Assertion, ilustrado na Figura 1.17, usado para denir o tempo mximo que o sistema tem para responder a uma requisio. Caso a obteno da resposta demore mais que o tempo denido, a assero falhar. Essa assertion muito utilizada, pois a partir dela podemos vericar o atendimento a um dos principais requisitos de desempenho: o tempo de resposta das requisies.

Figura 1.17. Duration Assertion - Assero do Tempo de Resposta

1.4.7. Timers Por default, o JMeter envia as requisies das threads sem pausar um tempo entre elas. Isso signica que as requisies sero disparadas rapidamente, uma seguida da outra. Como os usurios sempre analisam os resultados obtidos antes de executar a prxima ao, Timers devem ser usados para simular paradas entre as requisies, tornando-as mais realistas. Existem vrios tipos de timers, mas para simplicar, apresentamos aqui apenas o mais simples deles, o "Constant Timer", ilustrado na Figura 1.18. Esse timer dene o tempo em milisegundos que cada thread deve aguardar entre as requisies.

Figura 1.18. Constante Timer - Tempo constante entre as requisies

1.4.8. Pre-Processors Um Pre-Processor um elemento que executa certas aes antes da requisio ser enviada. Eles so utilizados para modicar caractersticas ou atualizar valores de variveis das requisies antes que estas sejam executadas. Dentre os Pre-Processors disponveis temos o Counter, ilustrado na Figura 1.19, que representa um contador que pode ser referenciado em qualquer lugar do Plano de Testes. Ele pode ser usado, por exemplo, para colocar um valor nico em um certo campo em cada iterao. Para isso, basta colocar como valor desse campo uma string qualquer seguido da referncia varivel que contm o valor do contador, o "Reference Name"do contador. Suponhamos, por exemplo, que temos como parmetro de uma requisio, um campo com nome "login", cujo valor deve ser nico toda vez que essa requisio for executada. Uma possvel soluo seria acrescentar um contador, denir suas propriedades (valor inicial, vamor mximo, incremento, nome da

varivel) e colocar "login${cont}", onde "cont" o nome da varivel do contador, como valor do campo "login".

Figura 1.19. Counter - Contador

1.4.9. Post-Processors Um Post-Processor um elemento que executa uma ao depois que uma requisio executada. Geralmente eles so utilizados para processar os dados recebidos da requisio e os seus resultados so utilizados para modicar as requisies seguintes. Dentre os Post-Processors, destacamos o Regular Expression Extractor, ilustrado na Figura 1.20, que permite ao testador extrair valores da resposta proveniente do servidor a partir de expresses regulares.

Figura 1.20. Regular Expression Extractor - Extrator de Expresses Regulares

1.5. Criando testes de desempenho e estresse automatizados


Esta sesso tem por objetivo apresentar um pequeno exemplo de utilizao da ferramenta para a automao de testes de desempenho e estresse de um sistema Web. O objeto de teste referido uma parte de um gerador (sistema) de pginas Web para usurios leigos. A funo desse gerador tornar simples a criao de pginas, seguindo um formato prestabelecido. Os usurios do sistema podem criar menus laterais, notcias, destaques,

usurios para administrar as pginas e links para outras pginas e arquivos. Esse sistema possui no total 8 casos de uso, mas iremos abordar aqui apenas o caso de uso Usurios, que corresponde as operaes de incluso, alterao, busca e remoo de um usurio desse sistema. Para iniciar a criao desse teste, primeira coisa a ser feita a insero do Thread Group e congurao do nosso Test Plan. Com base nos requisitos denidos para esse sistema, conguramos o teste para 100 usurios simultneos a serem disparados em 50 segundos. Tambm colocamos o teste para repetir por trs vezes, para assim conrmarmos os padres de comportamento do sistema, como por exemplo, a identicao de que certa operao sempre demora mais que o esperado. Para mantermos o teste organizado adicionamos quatro Simpler Controllers, cada um nomeado com a operao cujas requisies lhos iro realizar. O resultado pode ser visualizado na Figura 1.21.

Figura 1.21. Plano de Teste do caso de uso Usurio

Em seguida, adicionamos os listeners, o View Resulsts in Tree e o Graph Results. E como os testes seriam todos para um mesmo servidor, acrescentamos tambm o HTTP Request Defaults, congurando-o com o endereo do servidor que ser testado e o HTTP Cookie Manager, pois para acessar o sistema preciso logar e necessrio manter a sesso do usurio logado para permanecer no sistema. O estado do Test Plan com essas coguraes ilustrado na Figura 1.22 . Por m, basta colocar as requisies que realizam as operaes, bem como as asseres para vericar o atendimento aos requisitos de desempenho. Primeiro criamos a requisio "Login", cuja funo fazer o usurio virtual logar na pgina. Como j tinhamos congurado o HTTP Request Default, s precisamos agora denir o path e os parmetros da pgina testada, que no caso da requisio "Login"so os campos login e senha. Existem caratersticas importantes que devem ser observadas nesse ponto. Em primeiro lugar, o path supracitado no qualquer path do sistema. O path em questo o path que tratar os dados provenientes da requisio. Logo, para a congurao correta, muitas vezes necessrio olhar o cdigo-fonte da pgina ou algum documento que tenha

Figura 1.22. Plano de Teste do caso de uso Usurios com as conguraes gerais

toda a congurao dela, a m de descobrir qual pgina receber aqueles dados. Na pgina de login do usurio, por exemplo, vericamos que a pgina que trata os dados a prpria pgina que os recebe. Assim, o path dessa requisio o mesmo path onde o usurio insere os dados. Isso pode ser facilmente visualizado atravs do cdigo-fonte da pgina onde o usurio insere o login e a senha, ilustrado na Figura 1.23. Nele observamos que a ao do formulrio que recebe o login e a senha est em branco, oncluindo ento que ela prpria recebe e trata o login e a senha. Outro detalhe que merece ser mencionado est relacionado aos re-direcionamentos de alguns sistemas Web. No sistema utilizado neste trabalho, por exemplo, quando o usurio efetua a operao de login, o sistema redireciona para a mesma pgina, se o login falhar, ou para a pgina principal caso o login seja bem sucedido. O problema que se a opo Follow Redirects no estiver marcada, o JMeter no "seguir"esse redirecionamento e, portanto, continuar na mesma pgina para o qual os dados foram enviados. Assim, devemos desmarcar a opo Redirect Automatically, que no segue os re-direcionamentos que vem como resposta de uma requisio, e marcar a opo Follow Redirects. Alm disso, devemos colocar como mtodo de submisso aquele utilizado pela pgina (GET,POST,...) e adicionar os parametros necessrios. No nosso exemplo, a partir do cdigo-fonte, ilustrado na Figura 1.23, identicamos que o mtodo utilizado o POST e observamos que os campos necessrios no eram somente "login"e "senha". Para o correto funcionamento da requisio necessrio colocar tambm o campo "enviado". Isso porque os campos hidden so usados pela pgina para identicar a submisso de

Figura 1.23. Cdigo-fonte da pgina de login do usurio do sistema

dados, logo so campos necessrios para a execuo da operao requisitada. Nesse caso devemos preencher os valores respectivos dos campos login e senha, colocando tambm o valor do campo "enviado"como sendo o valor denido na sua propriedade value, ou seja, o valor "ok". Como resultado de todas essas conguraes, o login foi bem sucedido, como visto na Figura 1.24.

Figura 1.24. Execuo da requisio "Login"do estudo de caso

Como basta um login para cada usurio virtual, colocamos a requisio de login como lho do controlador Once Only Controller. Continuando a automao do teste, in-

serirmos uma Response Assertion, para nos certicarmos que a pgina alvo foi alcanada e um Duration Assertion, para medirmos o tempo gasto para responder a essa requisio. Por ltimo, devemos criar as outras requisies seguindo os mesmos passos: descobrindo o path, colocando os campos, o mtodo, adicionando um duration e um response assertion. Feitas todas as requisies, notamos que algumas asseres da requisio de Insero de Usurio falhavam. Observamos ento que isso acontecia porque na insero de Usurio o campo "login", que nesse caso era o nome de login do usurio, deveria ser nico para cada usurio. Adicionamos ento um Count, e modicamos o valor do campo login para usuario${cont}, em que "cont" o nome da varivel que contm o valor do contador. Isso signica que durante a execuo desses testes estamos inserindo usurios com os logins usuario1, usuario2, usuario3, etc, ou seja, criaremos um login nico para cada usurio. Feito isso, temos agora um teste automatizado de desempenho e estresse para o caso de uso Usurio, teste esse visualizado na Figura 1.25.

Figura 1.25. Teste automatizado de desempenho e estresse para o caso de uso Usurio do sistema testado

Alm da construo dos testes, a anlise dos seus resultados importante para se identicar as reas crticas do sistema. Os resultados da execuo do nosso exemplo, em forma de grco, podem ser visualizados na Figura 1.26. Com esses dados, aliados aos resultados exibidos no View Results Tree, adicionado ao plano de teste, podem ser utilizados pelo testador para avaliar sobre o atendimento da aplicao aos requisitos de desempenho existentes.

Figura 1.26. Grco resultante da execuo dos testes

1.6. Concluso
A atividade de Teste fundamental para a garantia da qualidade dos produtos desenvolvidos. Dentre os diversos testes, destacamos os testes de desempenho e estresse, que esto crescendo em importncia, uma vez que os sistemas para Web cada vez ganham mais espao em relao aos sistemas desktop. Esses testes ainda so pouco utilizados no cenrio atual e como os custos associados a sua execuo so altos, a utilizao de ferramentas que automatizem a criao e execuo dos mesmos essencial. Alm disso, fazer medies de tempo de resposta e simular muitos usurios acessando ao mesmo tempo uma aplicao invivel e muitas vezes at impossvel de se fazer sem uma ferramenta que automatize o processo. Neste trabalho apresentamos a automao de testes de desempenho e estresse para sistemas Web atravs de uma ferramenta de automao desses testes. Para isso, descrevemos os principais componentes do JMeter, uma ferramenta de automao desses testes, e apresentamos um estudo de caso de forma a esclarecer os procedimentos necessrios para se automatizar os testes de desempenho e estresse com a ferramenta em questo. E com o que foi apresentado aqui, podemos concluir que no mercado competitivo como o atual, investir em testes de software e em ferramentas que automatizem a sua realizao pode

ser a chave de sucesso para muitas empresas.

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