Café com Tecnologia

Posts Tagged ‘Testes’

Você já deve ter ouvido a palavra “Beta” em alguns momentos de sua vida, se você tem um algum conhecimento do vocabulário grego, se lembra das aulas de economia / mercado financeiro ou simplesmente se você é uma pessoa que tem ou teve aquário em casa.

Mas no mundo do software essa palavra quer dizer aos usuários “olha, este software que você vai usar pode dar alguns problemas, ok?”.  Bom, sendo um pouco mais politicamente correto, uma definição seria:

A versão beta é a versão de um produto de software que ainda se encontra em fase de desenvolvimento e testes. Wikipedia.

Mas o que isso realmente quer dizer? O que significa?

Bom, geralmente as empresas usam deste artifício para apresentar um software com correções, novo design, nova proposta, ou qualquer outra intenção para capturar o feedback de seus usuários comprometendo o mínimo possível sua marca.

Vocês devem ser lembrar do Gmail, produto do Google que ficou anos apresentando essa palavrinha em sua página inicial. Ou do Orkut, que AINDA está em Beta. Várias empresas liberam versões “Beta” de seus novos lançamentos para download.

E já podemos, hoje, encontrar esta mesma prática em sites brasileiros: eu lhes apresento o “Radio UOL Beta“.

Aliás, este post está em versão “Beta”, ok?

Alias, este blog está em versão “Beta”, ok?

Recentemente escrevi sobre como fazer uma configuração no JMeter para fazer teste de carga no IBM WebSphere Portal.

Abaixo, vou demonstrar resultados práticos de 2 planos de testes.

Plano de Teste Simples

Neste Plano de Teste foi configurado uma Thread Group com apenas 20 usuários.

Test Plan 01 - Thread Group

Veja o Summary Report deste Plano de Teste.

Summary Report

Plano de Teste mais “puxado”

Os resultados que serão apresentados abaixo são referentes a uma configuração de um Thread Group com 500 usuários e tempo de ZERO segundos, ou seja, simulado 500 requisições simultâneas.

Nessa configuração, o Summary Report apresentou os resultados abaixo.

Summary Report com 500 usuários

Este Plano de Teste executou 90.000 “samples” num tempo de aproximadamente 2 minutos.

Simultaneamente, verifiquei as informações apresentadas pelo “server-status” disponível no servidor IBM HTTP Server.

IBM HTTP Server - Status

É bom SEMPRE fazer um bom teste de carga antes de liberar seu site para produção. Antes, porém, faça as devidas configurações de “tunnig” em seu produto.

Hoje, para que possam ter uma idéia, verifico um máximo de 120 requisições simultâneas, bem menos das 500 configuradas no Plano de Teste.

Esse tipo de teste é uma boa garantia a ser apresentada para seu cliente para configurar os trabalhos realizados pela equipe técnica.

Escolhi o Apache JMeter para teste de carga no IBM WebSphere Portal. Como mencionado no post anterior, há outros softwares que poderiam ser utilizados.

Plano de Teste

A primeira coisa que precisamos preparar no JMeter é o Test Plan (Plano de Teste). Renomearemos este para “Plano de Teste”.

Apache JMeter

Em um plano de teste podemos adicionar 1 ou mais Thread Group. Em nosso plano de teste, adicionaremos apenas um Thread Group.

Adicionar Thread Group

Neste Thread Group é onde definiremos a quantidade de threads (usuários), o tempo de execução de cada um e a quantidade de repetições.

Thread Group - Configurações

O atributo “Number os Threads (users)” indica a quantidade de usuários/requisições que nosso plano de teste comportará. Neste caso  defini 100 threads a serem executadas.

O atributo “Ramp-Up Period (in seconds)” indica os segundos em que cada Thread será executada. Quando este valor estiver em ZERO, indica que TODAS as Threads serão automaticamente iniciadas.

O atributo “Loop Count” indica as repetições. Neste caso defini 100 repetições.

Essas configurações indicam que teremos 100 repetições de 100 Threads executadas simultaneamente. É um valor considerável. Recomendo que você inicie com 1 Thread e vá aumentando: 5, 10, 20, 50, 100… É uma boa maneira de você medir seu produto e servidor sem maiores danos. Não esqueça de verificar as configurações de seu servidor HTTP também.

Configurar Elementos HTTP

Bom, até agora não mencionamos nada do IBM WebSphere Portal Server. Mas agora começa a parte legal disso tudo. Precisaremos adicionar 4 elementos de configuração:

- HTTP Request Defaults
- HTTP Cookie Manager
- HTTP Header Manager
- HTTP Authorization Manager

HTTP Request Defaults

Neste elemento de configuração, defina as informação referentes a “Web Server”. Para a informação “Server Name or IP”, informe o nome completo do seu servidor. Na informação “Port Number” digite “80″ (ou outro valor que esteja definido).

HTTP Request Defaults

HTTP Cookie Manager

Neste elemento de configuração, marque a opção “Clear cookies each iteration?”

HTTP Cookie Manager

HTTP Header Manager

Neste elemento de configuração, adicione “User-Agent” com valor “Apache_JMeter_2.2″.

HTTP Header Manager

HTTP Authorization Manager

Neste elemento de configuração está o “pulo do gato”: a adição da URL base para autenticação do Portal.

Para a informação “Base URL” digite “/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy”. Nas informações “Username” e “Password” digite valores válidos para autenticação em seu Portal.

HTTP Authorization Manager

Pronto. A partir deste ponto você definirá as requisições e os relatórios.

Configurar Requisições

As requisições são as URLs que existem em seu Portal e que você quer testar. Pode-se usar quantas modelos HTTP Request necessários, mas lembre-se que quanto mais…

HTTP Request

Uma maneira simples de fazer isso é utilizando as famosas URLs Mapeadas no Portal. É o exemplificado na imagem anterior. Certifique-se de desmarcar a opção “Redirect Automatically” e marcar a opção “Follow Redirects”.

Relatórios

Onde as informações do teste de carga serão exibidos? Resposta: as informações podem ser visualizadas nos relatórios/listeners disponíveis.

Um que gosto muito de usar é o “Summary Report”, pois possui vários números como % de erros, o Throughput, média de KB trafegados, etc. Este relatório regista as Requisições (HTTP Request) em cada linha.

Summary Report

Você pode usar vários relatórios ao mesmo tempo, mas… CUIDADO, pois o exagero pode fazer esta humilde aplicação fechar inesperadamente. Experiência comprovada.

Não esqueça de salvar seus relatórios e seu plano de teste.