Testes de carga com Apache JMeter

Uma das coisas que mais aprecio no v�o livre (faço v�os de parapente) s�o os preparativos. Gosto de observar todos os apetrechos que levo comigo: GPS, vari�metro, b�ssola, r�dio, apito, canivete su�ço, lanterna, m�quina fotogr�fica e um monte de coisas mais. O divertido � pensar em como tudo aquilo vai ser �til em determinado momento do v�o. Seria poss�vel voar sem nenhum destes equipamentos, sendo necess�rio usar apenas a vela e a selete (a cadeira onde o piloto fica alojado), mas o v�o certamente n�o seria o mesmo. Grande parte dos equipamentos � exigida por segurança; outros s�o capazes de auxiliar na hora de ganhar altura, ou de saber que lugar exatamente se est� sobrevoando.

Mas por que esse papo de v�o livre se a revista � sobre Java? Acontece que tenho a mesma sensaç�o quando ligo meu laptop, abro meu IDE e vejo ali os plug-ins e outros componentes instalados, e que me ajudam na hora de desenvolver, testar, depurar ou otimizar minhas aplicaç�es Java. Eu poderia, � claro, escrever meus sistemas usando apenas o JSDK e um editor de textos, mas o desenvolvimento n�o seria t�o divertido � nem eficaz � do que usando as ferramentas corretas. Uma dessas ferramentas � o Apache JMeter, que apresento neste artigo.

O JMeter

Projeto antigo do Grupo Apache, o JMeter foi inicialmente concebido para a criaç�o e execuç�o de testes de carga em aplicaç�es web. Com ele � poss�vel simular usu�rios simult�neos acessando diversas p�ginas e seguindo fluxos de navegaç�o distintos. Como resultado dos testes, o JMeter fornece relat�rios e gr�ficos que auxiliam a visualizar � e compreender � como a aplicaç�o reagiu. S�o apresentados tempos m�dios, m�ximos e m�nimos de resposta, o n�mero de requisiç�es aceitas e negadas, e uma s�rie de outras informaç�es. O JMeter vem evoluindo e incorporando mais tipos de testes e relat�rios: hoje � poss�vel testar, al�m de aplicaç�es web, servidores FTP, bancos de dados e web services, entre outros.

Voc� pode obter uma c�pia da ferramenta no site de downloads do Jakarta (veja links). Feito o download, descompacte o pacote em um diret�rio � sua escolha. Ser�o criados os seguintes subdiret�rios:

bin: cont�m scripts para inicializaç�o do console gr�fico e do servidor, al�m dos arquivos de propriedades do JMeter;
docs: documentos HTML com informaç�es b�sicas sobre a ferramenta, manual do usu�rio e exemplos de planos de testes;
extras: arquivos relacionados com a task Ant para automaç�o de planos de testes, incluindo bibliotecas e modelos de relat�rios (veja o quadro "JMeter via Ant");
lib: bibliotecas utilizadas pelo JMeter (voc� pode copiar drivers JDBC e outros JARs para esse diret�rio para torn�-los acess�veis durante os testes);
printable_docs: inclui o manual no diret�rio docs, mas sem frames para facilitar a impress�o.

Planos de testes

Um plano de testes (Test Plan) representa a navegaç�o de usu�rios por uma aplicaç�o web. Em uma livraria virtual, por exemplo, essa navegaç�o poderia iniciar-se por uma p�gina de autenticaç�o, indo para a busca de livros, depois para os resultados da busca e seguindo para p�ginas de resumo e confirmaç�o. Criar um plano de testes nesse caso exigiria representar requisiç�es HTTP e cookies, al�m de um temporizador para estabelecer pausas entre requisiç�es (j� que o cliente passa algum tempo escolhendo livros, por exemplo) � isso para citar apenas alguns elementos.

Nesse sentido, o JMeter oferece componentes que representam grupos de threads, requisiç�es, configuraç�es b�sicas, sess�es e cookies, entre muitos outros necess�rios para testes de aplicaç�es web. Os componentes s�o organizados em categorias e podem ser criados e manipulados atrav�s do console gr�fico da ferramenta.

Primeiro Plano

Vamos criar um plano de testes simples para uma aplicaç�o de exemplo do Tomcat que acessa uma p�gina JSP:

http//localhost:8080/examples/jsp/dates/date.jsp

Inicialize o console gr�fico do JMeter chamando jmeter.bat (jmeter, no Linux). Veja a Figura 1. Vamos simular o acesso concorrente de 10 usu�rios e gerar relat�rios com os resultados. O primeiro passo � adicionar um Thread Group, componente respons�vel pela criaç�o de threads. Clique com o bot�o direito em Test Plan, na �rvore de componentes, e escolha Add > Thread Group (veja a Figura 2); mude o nome para "Primeiro Exemplo" e o n�mero de threads para 10. O campo Ramp-up period � utilizado caso se queria aumentar gradualmente o n�mero de threads durante a execuç�o, o que � �til para verificar a escalabilidade de uma aplicaç�o; n�o vamos us�-lo nesse primeiro exemplo.

Desmarque o checkbox Forever e altere o valor de Loop Count para 1 (o teste ser� executado apenas uma vez). A opç�o Scheduler foi adicionada na vers�o 1.9.1 e permite agendar um hor�rio para in�cio e o final dos testes, o que � bastante �til para executar testes durante uma determinada quantidade de tempo, sem fixar o n�mero de repetiç�es.

Vamos adicionar um Sampler do tipo HTTP Request, que faz requisiç�es HTTP contra um servidor web. Clique com o bot�o direito no Thread Group e selecione Add > Samplers> HTTP Request. Defina o Name e altere o endereço do servidor para "localhost" (note que n�o � inclu�do o protocolo). Deve-se adicionar a porta caso ela seja diferente da default (80): usaremos a porta padr�o do Tomcat: 8080. Escolha tamb�m o m�todo HTTP a ser usado, que nesse exemplo simples ser� GET, e defina o path como /examples/jsp/dates/date.jsp. Veja a Figura 3.

Saiba mais: Serviços RESTful: verbos HTTP

Por �ltimo, vamos adicionar dois Listeners para apresentar o resultado dos testes. No menu de contexto do Thread Group, selecione Add > Listener > Aggregate Report. Repita o processo, adicionando o listener View Results in Table.

Voc� j� pode executar os testes, chamando o comando Run > Start. O JMeter criar� 10 threads e todas solicitar�o a p�gina date.jsp. Os resultados ser�o apresentados nos dois listeners. O Aggregate Report (Figura 4) apresenta o n�mero total de requisiç�es e os tempos m�dio, m�nimo e m�ximo de resposta (em milissegundos), al�m do percentual de erros e da taxa de respostas por segundo. O listener View Results in Table mostra o tempo de resposta de cada solicitaç�o e se ela foi atendida com sucesso (veja a Figura 5).

Terminamos o primeiro exemplo. Voc� pode salvar o plano de testes (com Save|Test Plan). O arquivo (XML) ser� gravado com a extens�o .jmx.

Defaults, Controladores e Requisiç�es

Vamos a um exemplo mais completo que utiliza sess�es, componentes de configuraç�o e outras funcionalidades do JMeter. Usaremos outra aplicaç�o de exemplo do Tomcat, chamada "Calendar", acess�vel em http://localhost:8080/examples/jsp/cal/login.html. Um fluxo t�pico para esta aplicaç�o �:

Exibir a p�gina com o formul�rio de login;
Submeter os dados de login;
Selecionar uma data e um hor�rio para um novo compromisso;
Submeter o compromisso.

O objetivo dos testes ser� medir o tempo m�dio de resposta para todas as requisiç�es e identificar a p�gina que mais consome tempo durante a execuç�o. Novamente vamos simular dez usu�rios simult�neos.

Sabendo o fluxo de navegaç�o e o que pretendemos testar, vamos ao plano de testes. Vamos acessar as seguintes URLs, usando o m�todo HTTP GET para as primeiras tr�s e POST para a �ltima:

http://localhost:8080/examples/jsp/cal/login.html
http://localhost:8080/examples/jsp/cal/cal1.jsp?name=Handerson&email=handerson.gomes%40summa-tech.com
http://localhost:8080/examples/jsp/cal/cal2.jsp?time=9am
http://localhost:8080/examples/jsp/cal/cal1.jsp

Observe que as URLs s�o muito semelhantes. Imagine como seria mais simples se fosse poss�vel configurar valores default para evitar a entrada do nome do servidor e do n�mero da porta para todas as requisiç�es. Pensando nesses casos, a equipe do JMeter criou os componentes Config Elements, que permitem definir valores padr�o para requisiç�es.

Crie um plano de testes (chame-o de "JSP Calendar") e adicione a ele um Config Element do tipo HTTP Request Defaults. Defina as configuraç�es conforme a Figura 6 (observe que foi adicionado o endereço e a porta do servidor).

O suporte a cookies � fundamental nesse exemplo. Adicione outro Config Element, um HTTP Cookie Manager, que � capaz de interceptar uma requisiç�o HTTP, verificar se h� cookies em anexo, salv�-los e envi�-los de volta nas requisiç�es posteriores.

O pr�ximo passo � configurar as requisiç�es HTTP. Devemos especificar as URLs e os par�metros enviados para a aplicaç�o web. Crie um Thread Group e a ele adicione dois elementos do grupo Logic Controller � um Once Only Controller (Figura 7), que ir� conter as requisiç�es de Login (que acontecem uma �nica vez); e um Simple Controller, para a requisiç�o de adiç�o de compromisso.

Adicione um HTTP Request ao Once Only Controller (usando Add > Sampler > HTTP Request) e defina as opç�es conforme a Figura 8. Observe que os campos Server Name or IP e Port Number ficam em branco � o JMeter buscar� essas informaç�es no elemento HTTP Request Defaults criado anteriormente.

Crie mais um HTTP Request (com nome "JSP de Login"), esta requisiç�o utiliza os par�metros name e email. Para adicion�-los, clique em Add e faça preencha o nome e o valor como na Figura 9.

Adicione outros dois HTTP Requests, agora ao Simple Controller. Faça as configuraç�es como nas Figuras 10 e 11 (lembre-se de preencher o campo Path com os caminhos das URLs mostradas anteriormente). O console do JMeter tem suporte a "Copiar e Colar" e permite arrastar objetos de um grupo para outro. Esta � uma funcionalidade adicionada nas vers�es mais recentes, e que fez muita falta nos primeiros releases da ferramenta.

Com todos os elementos de requisiç�es adicionados, faltam apenas definir os listeners, para apresentaç�o dos resultados. Crie os seguintes: Aggregate Report, View Results Tree, View Results in Table.

Voc� j� pode executar os testes e verificar os resultados obtidos. No ambiente montado para o artigo, o Aggregate Report informou que a �P�gina de novo Compromisso� teve a m�dia de tempo de resposta mais alta, 64 ms, mas foi prejudicada por um tempo m�ximo de 421 ms. O valor de Rate (que significa quantas requisiç�es puderam ser atendidas por segundo) � semelhante para todas as requisiç�es, na casa de 9.7 (Figura 12). Outra coluna a ser observada � count � note que todas as p�ginas foram executadas 10 vezes, mesmo as que estavam no Once Only Controller, pois o teste foi feito com dez usu�rios simult�neos.

O View Results Tree mostra informaç�es mais detalhadas sobre as respostas, apresentando o cookie utilizado (em Cookie Data), o tempo de resposta (em Load Time) e a p�gina HTML retornada com duas visualizaç�es: o c�digo fonte e um preview do HTML (veja a Figura 13).

Gravaç�o de Requisiç�es

Se o seu plano de testes fizer a navegaç�o por um site com muitas p�ginas, a criaç�o de HTTP Requests para cada uma se tornar� trabalhosa e repetitiva. Para simplificar, o JMeter oferece um servidor de proxy que intercepta as requisiç�es feitas por um navegador web e cria automaticamente< HTTP Requests. Para o proxy � poss�vel tamb�m definir filtros de p�ginas, evitando criar Requests para imagens ou applets, por exemplo.

Vamos criar um plano de testes utilizando o proxy para simular a navegaç�o de um usu�rio pelo site da Java Magazine, percorrendo as p�ginas da mat�ria �A Escolha Certa� (voc� pode usar qualquer outro site para simular os testes, � claro). Crie um novo plano de testes e adicione em WorkBech um elemento HTTP Proxy Server, usando Add > Non-Test Elements > HTTP Proxy Server. Defina a porta do proxy � a default � 8080, mas como esta � utilizada pelo Tomcat, usamos a 1010.

Defina tamb�m um filtro para que n�o sejam criados HTTP Requests para imagens e folhas de estilo (.css). Os tipos de arquivos ignorados s�o definidos usando express�es regulares no campo Patterns to Exclude, no caso: .*\.jpg, .*\.gif e .*\.css.

Adicione um Thread Group e dentro dele um Recording Controller, que � um componente do tipo Logic Controller respons�vel por gerar os HTTP Requests acessados atrav�s do proxy. Inicie o proxy clicando no bot�o Start (veja a Figura 14).

� necess�rio configurar seu navegador para fazer uso do proxy. No Internet Explorer 6.0, por exemplo, chame Tools|Internet Options > Connections > LAN Settings e selecione a opç�o Use a proxy server for your LAN e adicione as entradas espec�ficas (Figura 15). Outros browsers como o Mozilla t�m configuraç�es semelhantes.

Com o plano de testes montado, o proxy em execuç�o e o browser configurado, basta navegar pelo site e abrir as p�ginas desejadas. Ao final ser� criado no Recording Controller v�rios HTTP Requests (Figura 16). Se estes n�o aparecerem, verifique se o browser n�o est� recuperando p�ginas do cache (nesse caso experimente forçar o recarregamento da p�gina, com CTRL+R ou Shift+F5). Finalizados os testes, voc� pode parar o proxy.

Se voc� visitou as quatro p�ginas do artigo "Ecolha Certa", deve ter agora cinco HTTP Request criados. Em cada um deles, haver� um elemento do tipo HTTP Header Manager, que armazena os atributos de cabeçalhos HTTP enviados pelo servidor, por exemplo Cache-control e User-Agent. As propriedades If-Modified-Since e If-None-Match, adicionadas automaticamente, s�o respons�veis pelas informaç�es de cache. Se voc� as mantiver nos HTTP Requests, o servidor HTTP (no caso, o Tomcat) vai assumir que o browser, ou o JMeter, mant�m uma c�pia da p�gina localmente e que esta ser� usada, n�o enviando portanto uma p�gina quando solicitado. Para evitar esse problema, remova do primeiro HTTP Request o elemento Browser-Derived Headers (em HTTP Header Manager).

Adicione tamb�m os seguintes listeners ao Thread Group: View Results Tree, Graph Results e Aggregate Report. Altere tanto o n�mero de threads como o Loop Count para 10.

Execute os testes. Voc� ver� que apenas a primeira p�gina realmente foi retornada pelo servidor HTTP, o que fica claro quando analisamos os resultados em View Results Tree. No Aggregate Report, verificamos que a primeira requisiç�o levou em m�dia 4.6 ms para ser retornada (Figura 17).

Observe que o gr�fico em Graph Results (Figura 18) apresenta linhas com poucas variaç�es, indicando um tempo de resposta constante. Cada ponto destacado no gr�fico representa o tempo de resposta de uma requisiç�o.

Testes em Bancos de Dados

Outros testes que podem ser realizados com o JMeter s�o de consultas SQL, drivers JDBC e da capacidade de processamento de banco de dados. Como exemplo, vamos acessar um banco de dados HSQLDB (no entanto ser� f�cil portar o exemplo para o banco de dados mais acess�vel para voc�). Veja na Listagem 1 o script para criaç�o da tabela com a inserç�o de alguns registros.

Localize o diret�rio onde o JMeter foi instalado (por exemplo, c:\jakarta-jmeter-1.9.1) e copie para seu subdiret�rio lib o driver JDBC do banco. Se o JMeter estiver em execuç�o, reinicie-o para que o driver seja adicionado ao classpath da ferramenta.

Crie um plano de testes e adicione um Config Element do tipo JDBC Database Login Defaults. Este componente armazena as informaç�es de acesso ao banco. Para uma conex�o ao HSQLDB use as seguintes configuraç�es:

JDBC URL: jdbc:hsqldb:hsql://localhost
Driver Class: org.hsqldb.jdbcDriver
Username: sa

Por default, o HSQLDB n�o define uma senha para o usu�rio �sa�, portanto o campo Password pode ficar vazio.

Adicione tamb�m um Config Element do tipo JDBC Database Connection Pool Defaults. Neste componente s�o definidas configuraç�es para o pool de conex�es usado pelo JMeter. Se sua aplicaç�o web faz o acesso ao banco de dados atrav�s de um pool (do servidor de aplicaç�es, por exemplo), uma possibilidade � configur�-lo da mesma forma que foi configurado o pool do servidor, ou seja, com o mesmo n�mero m�ximo de conex�es. Dessa forma � poss�vel fazer os testes das consultas SQL num ambiente semelhante ao de execuç�o.

Adicione um Thread Group e, nele, um Simple Controller. Dentro do Controller insira quatro Samplers do tipo JDBC Request que conter�o as consultas SQL a serem enviadas ao banco:

select * from CLIENTES order by NOME desc
select * from CLIENTES
select * from CLIENTES where ID = 1
select * from CLIENTES where ID+1 = 3

Preencha os campos SQL Query String com a consulta SQL; para o campo Name, costumo usar o pr�prio comando SQL, j� que este � mostrado em alguns relat�rios (como o Aggregate Report). Os outros campos ser�o substitu�dos na execuç�o dos testes, pelos valores definidos nos Config Elements.

Por fim, adicione os listeners Aggregate Report e Graph Results. Execute os testes com um usu�rio (1 thread), 50 vezes (Loop Count = 50). Os resultados sumarizados s�o mostrados na Figura 19.

JMeters Simult�neos

Ao utilizar o JMeter para simular v�rios usu�rios simult�neos, poderemos ter problemas no lado do cliente quanto ao uso de recursos. Dependendo do n�mero de usu�rios simulados e da velocidade de resposta do servidor, a m�quina cliente poder� ser insuficiente para tratar todas as requisiç�es.

Para resolver este problema � poss�vel rodar inst�ncias remotas do JMeter em v�rios computadores da rede, dividindo o trabalho de execuç�o dos testes. As inst�ncias remotas executam os testes em paralelo e reportam o resultado para um �nico cliente que faz a sumarizaç�o, tornando poss�vel alcançar um grande n�mero de requisiç�es sem sobrecarregar os clientes. Veja mais sobre esse recurso.

Listagem 1. Script para criaç�o da tabela de exemplo.


create table CLIENTES (

  ID INTEGER not null, NOME VARCHAR(255) not null,

  EMAIL VARCHAR(255), CIDADE VARCHAR(255) );

 

insert into CLIENTES values (1, 'Handerson Ferreira Gomes',

  'handerson.gomes@summa-tech.com','Sao Paulo');

 

insert into CLIENTES values (2,'Joao da Silva',

  'joao@silva.com', 'Curitiba');

 

insert into CLIENTES values (3,'Maria Aparecida',

  'maria@aparecida.com', 'Rio de Janeiro');

Elementos do JMeter

Thread Groups: S�o o ponto inicial dos planos de teste. Al�m de disparar threads e agrupar componentes, � nos Thread Groups que definimos o n�mero de usu�rios concorrentes, o incremento gradual do n�mero de threads, o n�mero de vezes que o teste deve ser repetido e o tempo total de execuç�o.
Logic Controllers: Nesta categoria entram os elementos respons�veis pela l�gica dos testes. Os controles mais usados s�o o Once Only Controller, que faz com que os componentes aninhados sejam executados apenas uma vez; o Interleave Controller, para a execuç�o alternada de Samplers (um para cada iteraç�o); o Loop Controller, que repete a execuç�o dos componentes o n�mero de vezes especificado; e o Simple Controller, usado apenas para agrupamento.
Samplers: Neste grupo est�o os elementos respons�veis por requisiç�es de serviços, como o HTTP Request, JDBC Request, FTP Request, SOAP-RPC Request e outros.
Listeners: Elementos que geram os diversos relat�rios de testes. Novos relat�rios podem ser desenvolvidos e adicionados ao JMeter (veja links).
Timers: Permitem especificar pausas entre a execuç�o de threads ou de Samplers. Por default, o JMeter executa todos os Samplers (por exemplo, HTTP Requests) em seq��ncia e sem pausas, o que, al�m de n�o ser um comportamento comum para muitas aplicaç�es, pode levar a uma sobrecarga desnecess�ria do servidor.
Assertions: Asserç�es podem ser adicionadas aos Samplers para verificar se a resposta enviada pelo servidor � a esperada. Podem validar o tamanho e o conte�do da resposta e suportam o uso de express�es regulares. Os resultados s�o enviados para o listener Assertions Result.
Configuration Elements: Neste grupo est�o os elementos que armazenam configuraç�es padr�o para alguns Samplers, al�m de elementos de controle como o HTTP Cookie Manager, utilizado no segundo exemplo deste artigo.

Dicas

ique sempre atento ao consumo de CPU e de mem�ria onde o JMeter est� sendo executado. Se a CPU alcançar 100% de uso � melhor diminuir o n�mero de threads, mudar para uma m�quina melhor, ou dividir o processamento em v�rias inst�ncias do JMeter rodando em m�quinas separadas;
Quanto mais r�pido o servidor responder, mais trabalho ter� o JMeter. Isso pode influenciar os resultados dos testes, j� que a ferramenta pode n�o ser capaz de tratar as respostas em tempo h�bil;
Evite executar o JMeter no servidor onde a aplicaç�o est� instalada; se o fizer, ser�o compartilhados recursos de mem�ria e de CPU possivelmente afetando os resultados. Isso vale para servidores de aplicaç�es, servidores web e de banco de dados e outros que sejam usados pela aplicaç�o;
A execuç�o de testes de performance pode levar alguns dias, nos quais os testes s�o executados diversas vezes depois de ajustes na aplicaç�o e no ambiente. Certifique-se de ter um ambiente dedicado durante o per�odo, com o banco de dados, o servidor de aplicaç�es e o servidor web sendo acessados apenas pela equipe de testes. Se isso n�o for garantido ser� dif�cil mensurar com precis�o o resultado dos ajustes feitos durante as v�rias sess�es de testes;
� poss�vel desativar itens de um plano de testes: clique com o bot�o direito sobre o item e selecione Disable/Activate;
Listeners podem ser adicionados a Thread Groups, Logic Controllers ou Samplers. Os dados dos relat�rios relacionados conter�o apenas os elementos do grupo a que pertencem. Esse recurso � �til para extrair dados de um determinado universo do plano de testes;
A ordem dos Samplers no plano de testes define a seq��ncia de sua execuç�o. � poss�vel reorganizar esses elementos arrastando-os para um novo grupo ou alterando sua posiç�o dentro de um grupo.

Planos via Ant

O console gr�fico n�o � a �nica forma de executar um plano de testes do JMeter. Atrav�s de um task do Ant � poss�vel executar um conjunto de planos de testes e gerar relat�rios com os resultados obtidos. A integraç�o JMeter/Ant abre a possibilidade de ter uma equipe fazendo testes cont�nuos de performance, ou testes agendados, sem a necessidade de trabalhar com o console.

Os relat�rios s�o convertidos para HTML usando a task padr�o do Ant XSLT. Dois modelos de relat�rios s�o fornecidos: um resumido semelhante ao Aggregate Report e um detalhado. O arquivo de resultados gerado (com extens�o .jtl) pode ser aberto no console do JMeter, permitindo com isso acesso a outras visualizaç�es como o Graph Results (para carregar um arquivo .jtl, selecione a opç�o Browse no menu de contexto de um listener).

Para poder executar um plano do JMeter com o Ant deve-se copiar o arquivo \extras\ant-jmeter\ant-jmeter.jar para o diret�rio lib do Ant e utilizar a task jmeter no buildfile. Abaixo est� um exemplo de buildfile que faz uso da task, al�m de uma captura do relat�rio gerado:




  

  

  

     

  target>

Conclus�es

Os testes de carga fazem parte de uma etapa fundamental no desenvolvimento de qualquer software multi-usu�rio. Os resultados obtidos podem identificar problemas de performance ou o uso excessivo de recursos do servidor � e usar uma ferramenta como o JMeter � fundamental nesses casos.

Figura 1. Tela inicial do JMeter

Figura 2. Thread Group configurado.

Figura 3. Primeiro HTTP Request.

Figura 4. Aggregate Report: resultados sumarizados.

Figura 5. View Results in Table: resultados em formato tabular.

Figura 6. Config Element HTTP Request Defaults: valores padr�o para requisiç�es HTTP.

Figura 7. Componentes inseridos no Once Only Controller s�o executados apenas uma vez

Figura 8. HTTP Request da p�gina de login.

Figura 9. HTTP Request de Login, que cria a sess�o do usu�rio.

Figura 10. HTTP Request para a listagem dos compromissos agendados

Figura 11. HTTP Request para o cadastro de um compromisso (observe o uso do m�todo POST e da opç�o Encode para todos os par�metros).

Figura 12. Aggregate Report para o exemplo "Calendar".

Figura 13. Resultados hierarquizados com View Results Tree.

Figura 14. Configuraç�o do proxy HTTP do JMeter.

Figura 15. Configuraç�o de proxy no Internet Explorer.

Figura 16. HTTP Request criado pelo Recording Controller.

Figura 17. Aggregate Report para testes de p�ginas do site www.javamagazine.com.br.

Figura 18. Graph Results com resultado de testes no site da Java Magazine.

Figura 19. Resultados dos testes de bancos de dados.

Confira tamb�m

Cursos de Java

Cursos

Cursos de Engenharia de Software