Escolar Documentos
Profissional Documentos
Cultura Documentos
Automação de Testes de Desempenho e Estresse Com Jmiter
Automação de Testes de Desempenho e Estresse Com Jmiter
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 verificar, 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 final
da especificao, 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 confiabilidade 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.
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 verificar os resultados das requisies enviadas ao objeto de teste. Essas asseres aceitam inclusive
expresses regulares, o que lhes agrega mais poder e flexibilidade.
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
(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 "filho", o que est a uma hierarquia inferior, e
o outro o "pai", que est em uma hierarquia superior a do filho e com o qual o filho
est ligado. Na Figura 1.1, por exemplo, o primeiro "Duration Assertion" filho da requisio nomeada de "Login", todos os elementos da mesma hierarquia ou inferior ao dessa
requisio so filhos do Thread Group, que por sua vez filho 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;
"Run each Thread Group separately", com o qual pode-se definir 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 filho de
algum Thread Group.
Na criao de testes com o JMeter, aps configurar o Test Plan, o testador deve
configurar o Thread Group, ou seja, deve definir 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": define a frequncia de lanamento das threads. Se forem
definidas 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": define quantas vezes o plano de teste ser executado. Logo, caso
seja marcado o checkBox "Forever", o teste entrar em execuo infinta e o valor
definido no Loop Count ser desconsiderado.
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 filhos a cada iterao.
1.4.3.5. If Controller
Com o If Controller possvel colocar uma condio que ser avaliada para definir se o
seu filho 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 ($).
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 grficos 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 figura podemos observar que esse Listener ideal para visualizar o que exatamente o usurio final 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 grfico que plota os tempos de todas
as requisies, o desvio padro, a mdia e a taxa de requisies realizadas por segundo. O
testador tem a possibilidade de optar por quais desses dados ele quer visualizar no grfico
e esse Listener, assim como os outros, permite a indicao de um arquivo para exportar a
visualizao gerada.
1.4.5. Configurations Elements
Os Configurations Elements so elementos que podem adicionar ou modificar dados das
requisies. Os principais Configurations Elements utilizados em testes para aplicaes
Web so o "HTTP Cookie Manager", usado para manter a sesso, e o "HTTP Request
Defaults", para definir o servidor que ser usado por todas as HTTP Requests da sua
hierarquia ou inferior.
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, definido
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.
1.4.7. Timers
Por default, o JMeter envia as requisies das threads sem pausar um tempo entre elas.
Isso significa 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 simplificar, apresentamos aqui
apenas o mais simples deles, o "Constant Timer", ilustrado na Figura 1.18. Esse timer
define o tempo em milisegundos que cada thread deve aguardar 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 modificar 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, definir suas propriedades (valor inicial, vamor mximo, incremento, nome da
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 modificar 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.
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 configurao do nosso Test Plan. Com base nos requisitos definidos para esse
sistema, configuramos o teste para 100 usurios simultneos a serem disparados em 50
segundos. Tambm colocamos o teste para repetir por trs vezes, para assim confirmarmos os padres de comportamento do sistema, como por exemplo, a identificao 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 filhos iro realizar. O resultado pode ser visualizado na Figura 1.21.
Figura 1.22. Plano de Teste do caso de uso Usurios com as configuraes gerais
toda a configurao dela, a fim de descobrir qual pgina receber aqueles dados. Na
pgina de login do usurio, por exemplo, verificamos 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, identificamos 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 identificar a submisso de
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 definido na sua propriedade value, ou seja,
o valor "ok". Como resultado de todas essas configuraes, o login foi bem sucedido,
como visto na Figura 1.24.
Como basta um login para cada usurio virtual, colocamos a requisio de login
como filho do controlador Once Only Controller. Continuando a automao do teste, in-
serirmos uma Response Assertion, para nos certificarmos 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 modificamos o valor do campo
login para usuario${cont}, em que "cont" o nome da varivel que contm o valor do
contador. Isso significa 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.
Alm da construo dos testes, a anlise dos seus resultados importante para
se identificar as reas crticas do sistema. Os resultados da execuo do nosso exemplo,
em forma de grfico, 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.
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
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.