O slideshow foi denunciado.

Teste de Performance - 3º Encontro da ALATS

3.597 visualizações

Publicada em

Apresentação do Fábio Martinho Campos, apresentada no 3º Encontro da ALATS.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Teste de Performance - 3º Encontro da ALATS

  1. 1. 15/07/2009 3º Encontro Mensal ALATS São Paulo Teste de Performance Usando a Ferramenta PERFMON e WebLOAD Fábio Martinho Campos 23 de Junho de 2009 fabio_noticias@yahoo.com.br Palestrante Fábio Martinho Campos é bacharel em Computação pela UNITAU (Universidade de Taubaté), MBA em Gestão de Projetos pelo IPT (Instituto de Pesquisas Tecnológicas-USP). Trabalhou no INPE-MCT (Instituto Nacional de Pesquisas Espaciais) em São José dos Campos como analista de sistemas e desenvolvedor web da Intranet e Internet por dois anos. Trabalhou também na empresa alemã Liebherr Guindastes e Máquinas Operatrizes como analista de sistemas e desenvolvedor web. Na IBM Brasil trabalhou por um ano como analista de teste no GTO (Global Test Organization) e SEA&T (System Engineer Architecture and Test) no projeto internacional Blue Horizon Configurator. Ainda na IBM trabalhou no Projeto CADU e SCFI do Banco Bradesco. Trabalhou também como Especialista de Testes na empresa HOLD TI Consultoria. Possui ainda a certificação TOEIC (Test of English for International Communication), CBTS (Certificação Brasileira de Teste de Software) pela ALATS (Associação Latino-America de Teste de Software), CQA (Certified Quality Assurance), CST (Certified Software Testing), CSCM(Certified Software Configuration Management), CTFL-ISTQB/ISEB(Certifiec Tester Foundation Level- International Software Testing Qualifications Board/Information Systems Examinations Board) e IBM Certified Specialist - Software Quality. Palestrante e instrutor da disciplina de Teste e Qualidade de Software, contribui para o crescimento do mercado de Teste de Software no Brasil através de palestras e eventos em universidades. Atualmente trabalha na empresa CPMBraxis como Analista de Sistemas Sênior em projetos de Teste de Software. 1
  2. 2. 15/07/2009 Agenda 18:30 Credenciamento 19:00 Início da Palestra 20:00 Coffee break 20:30 Continuação da Palestra 21:30 Espaço aberto para perguntas sobre Teste de Software, ALATS e certificação CBTS  Teste de Performance(Performance Testing)  Conceito, Objetivos e Aplicação  Processo para Teste de Performance  Métricas de Performance  Teste de Carga(Load Testing) e Stress(Stress testing)  Conceito e Processo para Teste de Carga  Conceito e Processo para Teste de Stress  Ferramentas para Teste de Performance e Carga  PERFMON  WebLOAD 2
  3. 3. 15/07/2009  Testes de Performance versus Testes Funcionais: Teste de Performance Teste Funcional Não testa o front-end da aplicação, ou seja, as Teste o front-end da aplicação, bem como funcionalidades. usabilidade e funcionalidades. Teste a escalabilidade da aplicação e monitora Não teste a escalabilidade da aplicação e o uso o uso dos recursos de hardware. dos recursos de hardware. Projetado para determinar como uma aplicação Não pode determinar como uma aplicação / / sistema irá reagir ao longo do tempo. sistema irá reagir ao longo do tempo. Requer uma aplicação totalmente funcional Não requer uma aplicação totalmente funcional para que os cenários sejam executados para que os cenários sejam executados adequadamente. adequadamente. Vários usuários. Um usuário. 3
  4. 4. 15/07/2009  O Teste de Performance em sua mais pura definição é o tipo de teste realizado para se verificar o tempo de resposta de uma aplicação, determinando assim a sua escalabilidade e confiança levando-se em consideração uma carga(load).  O Teste de Performance é usado também para se identificar os famosos gargalos(bottlenecks) de um sistema, determinar compliance com os requisitos não-funcionais de performance e coletar outras informações como hardware necessário para a operação da aplicação.  É de fundamental importância saber aonde se quer chegar e as expectativas de performance esperadas para determinada aplicação! Se você não determina a performance que deseja ter, não saberá onde quer chegar.  O Teste de Performance não é somente executado a fim de se obter o tempo de resposta, mas sim um processo controlado onde há medições e análises.  Propósitos do Teste de Performance:  Determinar a probabilidade que o sistema irá atender aos SLA’s(Service Level Agreement) acordados;  Não mitiga o risco diretamente, mas identifica e quantifica o risco;  Determina a configuração mínima que permitirá o sistema atender os SLA’s;  Determinar tempos de resposta em throughputs;  Determinar gargalos(bottlenecks) no sistema;  Comparação de diferentes plataformas de hardware e O.S.; 4
  5. 5. 15/07/2009  Benefícios do Teste de Performance:  Melhoria da qualidade do ponto de vista do usuário;  Redução do custo de mudanças;  Redução dos custos de sistema;  Aumento dos lucros;  Identificação antecipada dos defeitos mais críticos da aplicação como arquitetura do sistema;  Satisfação do usuário final;  Clareza na utilização dos recursos;  Teste de Performance também remove muitos mitos associados aos usuários;  Restrições do Teste de Performance:  Muito complexo;  As atividade de design, execução, análise e relatórios consome muito tempo;  Deve começar assim que os requisitos/SLA’s forem estabelecidos e acordados;  Requer a simulação de centenas/milhares de usuários simultâneos. Isso requer ferramentas de automação, as quais na maioria das vezes são caras;  Um ambiente propício como banda, configuração do sistema, usuários simultâneos é fundamental para que os resultados sejam os mais realísticos possível;  Ambiente real de produção não pode ser simulado, umas vez que para isso seria necessário muitos investimentos. 5
  6. 6. 15/07/2009  Teste de Performance possui três percepções gerais: 1. Teste de Tempo de Resposta(Response Time Testing): A consistência do tempo de resposta é medido em vários ciclos de teste, se a performance é calculada especificamente em termos de tempo de resposta. 2. Teste de Throughput(Throughput Testing): Teste de Throughput mede o throughput de um servidor em um sistema baseado em Web. Ele é uma medida do número de bytes enviados por unidade de tempo. Throughput de vários servidores em a arquitectura ds sistema pode ser medido em kilobits por segundo, consultas em banco de dados por minuto, transações por hora, ou qualquer outra característica vinculada ao tempo. 3. Teste de Capacidade(Capacity Testing): Mede a capacidade global do sistema e determina até que ponto o resposta tempo e throughput torna-se inaceitável.  À medida em que a carga cresce constantemente para se analisar o comportamento do sistema, deve-se observar os gargalos(bottlenecks). Estes gargalos podem estar localizados nos seguintes lugares:  Aplicação: Desenvolvedores podem usar ferramentas a fim de descobrir ineficiências em seus códigos(algoritmos de busca e localização)  Bando de Dados: Desenvolvedores e Dba’s podem usar ferramentas de otimmização para buscas(queries)  Sistema Operacional: Desenvolvedores e analistas de sistemas podem usar ferramentas para monitorar o constante uso do hardware como memórias e HD’s.  Rede de Dados: Engenheiros de rede podem fazer o uso de sniffers e analisadores de protocolos de rede a fim de monitorar o tráfego na rede de dados. Teste de Performance simula as atividades do usuário e analisa o efeito do ambiente no mundo real da aplicação. 6
  7. 7. 15/07/2009  Gargalos(Bottlenecks) em uma aplicação Web: São desenvolvidas em um ambiente multi-operacional. Módulos do servidor podem ser executados em Unix enquanto módulos do cliente podem rodar no Windows. A concepção global de arquitetura inclui servidor Web, servidor de aplicações, ambiente de rede, firewalls, etc. Um exemplo desta realidade pode ser visto na figura abaixo:  Alguns gargalos clássicos podem incluir:  Alto consumo de recursos como CPU, memória, banda.  Alguns gargalos clássicos podem incluir:  Design do banco de dados durante o desenvolvimento da aplicação;  Padrões de design de tabelas não são seguidos;  Baixa indexação de banco de dados;  Baixa qualidade nas lógicas de “queries”;  Stored Procedures inapropriadas. 7
  8. 8. 15/07/2009  Por quê executar os Testes de Performance?  Avaliar a release que será disponibilizada para a produção.  Determinar se a aplicação pode suportar sua carga de trabalho pretendida ;  Simulação de centenas ou até mesmo milhares de usuários virtuais, representando suas operações rotineiras do sistema em questão;  Avaliar o tempo de resposta da aplicação, sabendo assim quanto tempo o usuário fica esperando por uma resposta do sistema;  Garantir ao longo do tempo que a sua aplicação possui estabilidade o suficiente para aguentar o crescimento da carga de trabalho(workload).  O Papel dos requisitos no Teste de Performance é muito importante, uma vez que as expectativas geradas estão documentadas e acordadas. Ou seja, devem ser cumpridas!  O Teste de Performance se enquadra no tipo de teste não-funcional.  Um requisito de performance é um requisito que impõe condições para um requisito funcional, ou seja, requisitos que especificam a velocidade, acurácia ou uso de memória dentro de uma funcionalidade que deverá ser realizada.  Alguns exemplos de requisitos não-funcionais para performance podem ser:  O processo de autenticação deverá ser completado rapidamente;  Depois que o usuário digita o nome de usuário e senha, e clicar no botão “Enviar” na página de “Login”, o tempo de resposta da autenticação não poderá exceder três segundos; 8
  9. 9. 15/07/2009  Alguns exemplos de requisitos não-funcionais para performance podem ser:  Em média, este cenário acontece 20 vezes por minuto. Depois que o usuário abre a página de “Login”, o usuário digita o nome de usuário e senha válidos, e clicar no botão “Enviar,” o tempo de resposta deve ser inferior a 3 segundos 80% do tempo;  O sistema está sendo executado no âmbito da carga de trabalho mais pesada possível. A média de tempo de resposta para exibir a mensagem promocional sobre determinado produto após um cliente entra em uma página onde estão localizados os itens promocionais devem ser inferiores a 1 segundo.  Atualmente, você é capaz de definir os requisitos de performance do seu projeto? Em quase todos os casos, Teste de Performance descobre erros fatais que provavelmente levariam a sua Aplicação/Sistema a ter tempos de resposta muito altos ou o “Crash” por completo da Aplicação/Sistema. 9
  10. 10. 15/07/2009  Cargas de Trabalho(Workloads): Consiste na descrição da carga de trabalho por meio de parâmetros quantitativos e funcionais. O objetivo é derivar um modelo capaz de mostrar, capturar e reproduzir o comportamento da carga de trabalho e suas mais importantes funcionalidades.  Pode ser realizado de quatro formas:  Fatores que impactam na performance:  Peculiaridades do Projeto:  Natureza do Projeto;  Peculiaridades Técnicas:  Ameaças à Segurança(SQL’s injection);  Negligência por parte dos desenvolvedores;  Complexidade na interface com o usuário(usabilidade);  Conteúdo dos Sites:  HTML; 10
  11. 11. 15/07/2009  Fatores que impactam na performance:  Conteúdo dos Sites:  HTML;  Imagens;  Multimídia;  Aplicações executáveis;  Ambiente do Cliente;  Diferentes Browsers;  Diferentes Plataformas;  Etc.  Fatores que impactam na performance:  Ambiente do Servidor:  Transferência de arquivos entre servidores;  Localização do servidor;  Servidor Web conectado a uma LAN; 11
  12. 12. 15/07/2009  Fatores que impactam na performance:  Ambiente do Servidor:  Servidor Web localizado em uma LAN dentro de um firewall.  Fatores que impactam na performance:  Ambiente do Servidor:  Servidor Web localizado em uma LAN fora de um firewall. 12
  13. 13. 15/07/2009  Fatores que impactam na performance:  Ambiente de Rede de Dados:  Internet Service Providers(ISP): • Topologia; • Links externos • Roteadores e equipamentos redundantes; • Link de conexão e velocidade; • Centro de operações da rede.  Dialup;  Cable Moden;  ISDN(Integrated Services Digital Network);  Leased Lines( T1, T3);  Fatores que impactam na performance:  Web Caching:  Client Caching;  Proxy Caching;  Server Caching 13
  14. 14. 15/07/2009  Fatores que impactam na performance:  Servidores Web(Web Server) e Servidores de Aplicação(Application Server ):  Microsoft Internet Information Server (IIS);  Fatores que impactam na performance:  Servidores Web(Web Server) e Servidores de Aplicação(Application Server ):  Apache Web Server;  Web Logic Application Server (BEA);  WebSphere Application Server;  Oracle9i Application Server;  Sun ONE Application Server;  Orion Application Server.  Scripting Languages for Web-Based Applications:  Hyper Text Markup Language (HTML);  Extensible Markup Language (XML);  Extensible Hypertext Markup Language (XHTML). 14
  15. 15. 15/07/2009  Fatores que impactam na performance:  Scripting Languages for Web-Based Applications:  Cascading Style Sheets (CSS);  Python;  Virtual Reality Modeling Language (VRML);  Common Gateway Interface (CGI);  Client Side Scripting: • Hypertext Preprocessor (PHP); • Microsoft .NET; • Active Server Pages (ASP); • Java Server Pages (JSP); • Visual Basic (VB) Script;  Performance Tuning(Otimização da Performance): Quando o Teste de Performance é realizado de forma completa revela características do sistema/aplicação inaceitáveis, fazendo com que os analistas de teste mudem o foco do Teste de Performance para o performance tuning, descobrindo assim o que é necessário para tornar a sistema/aplicação aceitável. Performance tuning também é realizado quando os objetivos/metas foram atingidos, mas o time do projeto deseja reduzir a quantidade de recursos que são utilizados para então diminuir o tempo de resposta e o volume de hardware necessário ajudando na performance do sistema/aplicação como um todo.  Performance Tuning não está relacionado diretamente como uma atividade dos analistas de teste, mas sim uma cooperação/esforço de todos que estão/são responsáveis pela aplicação/sistema que está sendo testado e pode incluir arquitetos, desenvolvedores, administradores de banco de dados, sistemas e rede de dados.  O processo de Performance Tuning geralmente é separado, mas não independente do Teste de Performance. O seguinte processo para performance tuning é: 15
  16. 16. 15/07/2009  As áreas mais comuns onde se poderá encontrar gargalos e realizar o performance tuning são: 16
  17. 17. 15/07/2009 17
  18. 18. 15/07/2009 18
  19. 19. 15/07/2009 19
  20. 20. 15/07/2009 20
  21. 21. 15/07/2009 21
  22. 22. 15/07/2009  Existe um número quase que ilimitado de métricas que podem ser coletadas durante a execução do Teste de Performance. Entretanto, a coleta de muitas métricas pode fazer com que a análise fique muito “pesada”, bem como impactar negativamente a performance atual da aplicação. Por esta razão, é muito importante identificar métricas que são mais relevantes para os objetivos/metas de performance e as que irão antecipadamente revelar gargalos no sistema. Apenas métricas selecionadas e que são analisadas corretamente podem prover algum tipo de informação valiosa;  Alguns exemplos de métricas de performance podem ser:  Métricas relacionadas à rede de dados;  Métricas relacionadas ao sistema;  Métricas relacionadas à plataforma;  Métricas relacionadas à aplicação;  Métricas relacionadas ao serviço;  Alguns exemplos de métricas podem ser: 22
  23. 23. 15/07/2009  Abaixo, segue um exemplo de gráfico gerado por uma ferramenta de automação:  Abaixo, segue um exemplo de gráfico gerado por uma ferramenta de automação: 23
  24. 24. 15/07/2009  Alguns mitos do Teste de Performance:  Problemas de performance do Client-Server pode ser facilmente consertado apenas por se colocar um processador mais poderoso;  Se as funcionalidades estão funcionando corretamente, usuários não se importam com o tempo de resposta;  Planejamento não é necessário para o Teste de Performance! É intuitivamente óbvio como se medir a performance do sistema;  É necessário apenas algumas horas antes da release ser disponibilizada para produção a validação da performance;  Qualquer um pode medir e analisar a performance; Não é necessário nenhum skills para a atividade de Teste de Performance;  Teste de Performance não requer ferramentas caras.  Teste de Performance em apenas uma frase: Teste de Performance é executado para ajudar a identificar gargalos no sistema, estabelecer uma baseline para futuras análises/testes, apoio no esforço de performance tuning, determinar a conformidade com requisitos e metas de performance, e/ou coleta de outros dados relacionados ao desempenho para assim ajudar os Stakeholders a tomar decisões relacionados com a qualidade total da aplicação que está sendo testada. Além disso, os resultados do Teste de Performance e análises podem ajudar você a estimar a configuração do hardware necessária para suportar a aplicação quando você liberar para o uso em produção. 24
  25. 25. 15/07/2009  Existem muitas razões para o Teste de Carga em aplicações Web. O tipo mais básico de teste de carga é usado para determinar o comportamento da aplicação Web através de condições normais e altos picos de carga. À medida em que se começa o teste de carga, é recomendável se começar com um pequeno número de usuários virtuais(Virtual Users) e então incrementar gradualmente a carga do normal até o pico.  Durante esta execução observe como sua aplicação reage durante o aumento da carga de trabalho.  O processo para teste de carga pode ser visualizado a seguir: 25
  26. 26. 15/07/2009 26
  27. 27. 15/07/2009  Balanceamento de Carga(Load-Balancing): É a técnica utilizada para espalhar/distribuir o trabalho entre dois ou mais computadores, link de rede de dados, CPU’s, HD’s e outros recursos de forma que a utilização do recurso seja otimizada, maximizando assim o throughput e minimizando o tempo de resposta. Usando múltimplos componentes com balanceamento de carga, e não apenas um, pode aumentar a confiança através de redundância.  O serviço de balanceamento é normalmente oferecido por um programa dedicado ou dispositivo de hardware;  Algumas funcionalidades podem incluir:  HTTP compression;  HTTP caching;  HTTP security;  Manipulação de tráfego.  Teste de Stress é um tipo de Teste de Performance focado na determinação da robustez, disponibilidade e confiança da aplicação diante de condições extremas, sendo que o objetivo do é identificar problemas na aplicação que tornam-se aparente somente diante dessas condições. Tais condições podem ser cargas de trabalho muito pesadas, alta simultaneidade de usuários ou limitações de recursos computacionais, sendo este último muito comum, uma vez que os sistemas cada vez mais estão complexos, havendo muita perda desses recursos.  Exemplos de condições de stress podem ser:  Volume excessivo de dados e/ou usuários;  Redução de recursos como capacidade de discos;  Seqüenciamento inesperado;  Etc.  O processo para teste de stress pode ser visualizado a seguir: 27
  28. 28. 15/07/2009  Exemplos de sintomas relacionados ao stress podem ser:  Dados estão perdidos e/ou corrompidos;  Utilização dos recursos ainda continua inaceitável mesmo depois que o stress é removido;  Componentes da aplicação falha ao responder. 28
  29. 29. 15/07/2009  A automação do Teste de Performance é uma necessidade do projeto e se torna inevitável para o sucesso em termos de atingir os objetivos/metas acordados com os stakeholders. Com isso, se torna extremamente valioso a correta aquisição da ferramenta em questão, não sendo necessariamente a mais cara, mas sim a que possa trazer mais facilidades e produtividade para a equipe;  Ferramentas de automação não fazem milagres!!! Para tanto, a disponibilização de tais ferramentas requer nao apenas tempo e dinheiro, mas preparação, planejamento e treinamento. Isso porque a automação do Teste de Performance é um processo humano;  O processo para automação de um Teste de Performance pode ser visualizado a seguir: 29
  30. 30. 15/07/2009  O quê, como e aonde automatizar? Leve em consideração a figura abaixo: 30
  31. 31. 15/07/2009  Considere também os principais indicadores de performance:  Ferramentas para Teste de Performance e Carga:  HP Mercury Loadrunner;  WAPT;  IBM Rational Performance Tester;  Neoload;  Borland Silk Performer;  E-Load  Apache Jmeter;  WebLOAD;  OpenSTA;  Gringer;  Microsoft Web Application Stress Tool;  Etc.  Outras ferramentas open-source podem ser baixadas no link: http://www.opensourcetesting.org 31
  32. 32. 15/07/2009  Ferramenta para monitoração de performance - PERFMON: A ferramenta de monitoração de performance PERFMON, é um visualizador de performance do sistema disponível nas versões Windows NT/2000/2003/XP/Vista.  O PERFMON permite o usuário a selecionar “counters”(contadores) de uma lista disponível de categorias de performance counters(contadores de performance) e mostra cada um deles como gráfico. Possibilita também a coleta de dados de computadores remotos.  Para executar a ferramenta, basta digitar “perfmon” no prompt de comando do Windows. A seguinte tele irá abrir: 32
  33. 33. 15/07/2009 Fontes e Materiais de Referência: Artigos:  http://www.stickyminds.com Sites:  http://msdn.microsoft.com/en-us/library/dd327578.aspx *  http://en.wikipedia.org/wiki/Stress_testing  http://en.wikipedia.org/wiki/Performance_testing  http://en.wikipedia.org/wiki/Load_testing  http://en.wikipedia.org/wiki/Load_balancing_(computing)  http://en.wikipedia.org/wiki/Bottleneck_(engineering)  http://www.opensourcetesting.org/performance.php *  http://www.appperfect.com/  http://www.webperformanceinc.com/index.html?wmi=0,0  http://www.load-testing-tools.com/index.html *  http://www.loadea.com/  http://www.alvicom.hu/eng/index.php  http://www.loadtracer.com/  http://www.stresstester.com/index.php  http://www.loadtestingtool.com/index.shtml  http://www.neotys.com *  http://www.loadtestingtool.com/ - http://www.web-site-test.com/ - http://www.serversupervisor.com/ * Próximo Encontro Mensal da ALATS Tema: Automação: Mitos e Verdades Palestrante: Elias Nogueira Data: Em Breve!!! Horário: 18:30 às 22:30 Informações: sp@alats.org.br 33
  34. 34. 15/07/2009 Perguntas??? E-mail: fabio_noticias@yahoo.com.br 34

×