Infra - Segurança

Teste de desempenho: Conceitos, Objetivos e Aplicação - Parte 1

Avaliação do desempenho: Uma parte crucial de um processo de Qualidade e teste de Software em uma aplicação Web.

por Fábio Martinho Campos



Teste de Performance é uma parte crucial de um processo de Qualidade e teste de Software em uma aplicação Web.

Na maioria dos modelos de processo de Engenharia de Software, o teste de software tem um papel importante na garantia da qualidade de um produto de software. Na maioria dos projetos, a maior parte do esforço vai para testes funcionais e alguns gerentes tendem a ignorar Testes de Performance completamente.

Para sites e aplicações Web, especialmente em uma situação de comércio eletrônico, Testes de Performance são fundamentais. Mesmo uma aplicação bug-free estará fadada ao fracasso, apenas por “aguentar” um tráfego médio, mas não é capaz de lidar com um pico significativo na vida real de uma situação. Para garantir que uma aplicação Web satisfaz certos critérios como performance, throughput de dados ou tempo de resposta, testes em um ambiente semelhante ao de produção será necessário.

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.

São estes alguns dos 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.

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íveis;

- Ambiente real de produção não pode ser simulado, uma vez que para isso seria necessário muitos investimentos.

O Teste de Performance é visto de maneiras diferentes com base nos objetivos estabelecidos para os indicadores de performance. Se o requisito está concentrado nas características específicas do sistema tais como tempo de resposta, throughput, capacidade, utilização dos recursos, então a percepção do Teste de Performance também difere.

Teste de Performance possui três percepções gerais:

1. Teste de Tempo de Resposta(Response Time Testing): Representa a percepção do usuário de quão rápido o sistema reage para uma “Request” ou “Query”. A reação pode ser lenta ou rápida com base no tipo de atividade e o tempo necessário para processar a requisição. A aceitação de um determinado tempo de resposta é um fator relacionado à psicologia humana. As expectativas variam de usuário para usuário! Um usuário que trabalhada com 5 segundos de tempo de reposta, iria ficar frustrado com 10 segundos tempo de resposta, por exemplo. Então, o tempo de resposta de uma aplicação para outra difere, assim como de um usuário para outro. Mas a indústria apresenta as seguintes normas:

Para um sistema multimídia interativo, o tempo de resposta deveria ser 0.1 segundo ou menos, 90% do tempo;

Para sistemas online onde tarefas são inter-relacionadas, o tempo de resposta deveria ser menos que 0.5 segundos, 90% do tempo;

Para sistemas online onde usuários fazem múltiplas tarefas simultaneamente, o tempo de resposta deveria ser 1 segundo ou menos, 90% do tempo.

A consistência do tempo de resposta é medida em vários ciclos de teste, se a performance é calculada especificamente em termos de tempo de resposta.

    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 arquitetura de 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.

    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. Teste de Capacidade é realizado com carga normal para determinar a capacidade extrema, onde o Stress é determinado por sobrecarregar o sistema até que ele falhe, o que também é chamado de carga de estresse, para determinar a capacidade máxima de um sistema.

Abaixo, segue uns exemplos de gráficos gerados por uma ferramenta de automação:

À medida 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 otimizaçã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

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;

- 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.

Os gargalos impactam diretamente a aplicação, que por conseqüência impactará o cliente final com baixa performance. Considerando-se um site de E-Commerce, as seguintes reações dos usuários podem ser:

- Interrupção temporária do acesso ao site e uma nova tentativa após algum tempo;

- Abandono do site por alguns dias;

- Abandono do site para sempre;

- Clientes desencorajam outras pessoas para acessar o site.

Com isso, os stakeholders do projeto têm expectativas como:

- Disponibilidade 24X7;

- Resposta rápida quando uma “query” for realizada;

- Uso adequado da memória em ambos cliente e servidor;

- Máximo de transações por segundo;

- Quais outras expectativas você adicionaria como cliente final?

Por que executar os Testes de Performance?

- Avaliar a release que será disponibilizada para a produção;

- Avaliar uma infra-estrutura adequada:

· Avaliar a capacidade atual;

· Determinar a estabilidade;

· Determinar a capacidade da infra-estrutura da aplicação, bem como determinar futuros recursos necessários a fim de atender aceitáveis níveis de performance;

· Comparação entre diferentes configurações de sistemas para determinar qual infra-estrutura irá melhor atender ambos o negócio e a aplicação;

- Melhoria da eficiência do performance tuning;

- 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; (requisito muito genérico e sem objetivo, mas existe!)

- 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.

- 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;

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

Algumas questões devem ser respondidas ao realizar o Teste de Performance, como:

- O problema está relacionado ao tempo de resposta?

- O problema é indisponibilidade?

- É um problema de freqüentes “Time-outs”?

- O problema de lentidão está ocorrendo em todo o site ou para alguma transação especifica?

- O problema está afetando todos os usuários ou apenas um certo grupo de usuários?

- Um grupo de usuários freqüentemente relata o mesmo problema?

Se sim, analise:

- Verifique a velocidade do link;

- O local de uso;

- Tipo de conexão;

- Verifique a interatividade do usuário com o sistema.

Teste de Performance não só previne como ajuda ainda a responder mais questões, como:

- Será que o sistema é capaz de lidar com constantes aumentos de tráfego da Web, sem comprometer o tempo de resposta, segurança, confiabilidade e precisão?

- Até que ponto a performance será degradada e qual componente será responsável pela degradação?

- Qual o impacto a degradação da performance terá na empresa em termos de vendas e custos de suporte técnico

- O que poderia ser o problema? Servidor, rede, banco de dados, ou a aplicação em sí?

- É necessário controlar todos os componentes de hardware como roteador, firewall, servidores, links de rede ou apenas a monitoração padrão suficiente?

Benchmarking: É o processo de comparação da performance do seu sistema com uma baseline que você tenha criado internamente ou uma comparação com um padrão de indústria realizado por outra organização.

- No caso de um sistema Web, pode-se executar testes que estão em conformidade com as especificações de uma indústria de referência a fim de capturar métricas de desempenho, necessárias para o benchmark da sua aplicação. Então é considerada uma carga de trabalho(workload) fictícia a fim de simular o sistema no ambiente real de produção.

Cargas de Trabalho(Workloads): O objetivo das Cargas de Trabalho é derivar um modelo capaz de mostrar, capturar e reproduzir um comportamento da carga de trabalho e suas funcionalidades mais importantes.

Existem basicamente quatro formas de workload:

- Goal Oriented(Orientado a Meta/Objetivo): Um sistema quando desenvolvido metas definidas! Requisitos de performance são direcionados por estas metas. As metas são usadas para fazer o projeto de carga de trabalho do Teste de Performance;

- Transaction Based(Baseado em Transação): O objetivo é analisar o desempenho do sistema para todas as transações de negócios que são relevantes ao dia-a-dia da empresa. Todas as transações identificadas devem ser usadas enquanto se projeta a carga de trabalho. O desempenho das metas para estas operações deve ser o de verificar a eficiência dos recursos para uma resposta aceitável e caudal.

- Architecture Based(Baseado na Arquitetura): A arquitetura de sistema precisa de ser cuidadosamente ponderada na concepção do trabalho. As tendências de negócio e tecnologia que irá afetar a arquitetura precisam ser consideradas. A carga de trabalho deve ser projetada tendo em mente que estes fatores são parte do cenário do mundo real;

- Growth Based(Baseado no Crescimento): À medida que o negócio cresce, o sistema exige mudanças na sua funcionalidade, desempenho e confiabilidade. Se o sistema não é desenvolvido tendo em vista manter o crescimento, modificações tornam-se mais caras e demoradas. Tendo então o conhecimento das perspectivas de crescimento, uma carga de trabalho detalhada será projetada para verificar a performance do sistema.

Quais sistemas estão vulneráveis à performance:

- Aplicações Client-Server: Arquiteturas Client-Server representam um grande desafio, uma vez que problemas de performance, associados com transação/processamento, presença de vários hardwares diferentes, complexidade na rede de dados, etc. fazem com que toda essa combinação torne o teste ainda mais difícil, sendo ainda mais complicado achar a causa raiz do problema em questão;

- Aplicações Web: Aplicações Web-based, têm evoluído a partir de aplicações Client-Server. Os conceitos de Client-Server são mantidos através de um Web-Client e um Web-Server. Estas são aplicações de software que interagem com os usuários ou outros sistemas usando Hyper Text Transfer Protocol(HTTP). O uso de aplicativos na Web pode variar de simples até tarefas mais complexas. Com a explosão do comércio eletrônico, as empresas estão simplificando os processos e acelerando as operações através da Web como um meio mais eficaz.

Fatores que impactam na performance:

 - Peculiaridades do Projeto:

·   Natureza do Projeto;

·   Metodologias;

 - 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;

· Imagens;

· Multimídia;

· Aplicações executáveis;

- Ambiente do Cliente;

· Diferentes Browsers;

· Diferentes Plataformas;

· Etc.

- Ambiente do Servidor:

·   Transferência de arquivos entre servidores;

·   Localização do servidor;

·   Servidor Web conectado a uma LAN;

- Ambiente do Servidor:

·   Servidor Web localizado em uma LAN dentro de um firewall.

- Ambiente do Servidor:

·   Servidor Web localizado em uma LAN fora de um firewall.

- Ambiente de Rede de Dados:

·   Internet Service Providers(ISP):

o Topologia;

o Links externos

o Roteadores e equipamentos redundantes;

o Link de conexão e velocidade;

o Centro de operações da rede.

· Dialup;

· Cable Moden;

· ISDN(Integrated Services Digital Network);

· Leased Lines( T1, T3);

Web Caching:

·   Client Caching;

·   Proxy Caching;

·   Server Caching.

- Servidores Web(Web Server) e Servidores de Aplicação(Application Server ):

·  Microsoft Internet Information Server (IIS);

- 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).

- Scripting Languages for Web-Based Applications and Client Side Scripting:

·   Cascading Style Sheets (CSS);

·   Python;

·   Virtual Reality Modeling Language (VRML);

·   Common Gateway Interface (CGI);

· Hypertext Preprocessor (PHP);

· Microsoft .NET;

· Active Server Pages (ASP);

· Java Server Pages (JSP);

· Visual Basic (VB) Script;

· JavaScript;

· Jscript;

· Server Side Includes (SSI).

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 é:

As áreas mais comuns onde se poderá encontrar gargalos e realizar o performance tuning são:

Alguns riscos relacionados ao Teste de Performance:

Alguns tipos de teste de software, relacionados ao Teste de Performance podem ser:

  - Carga(Load): Identifica os níveis máximos, os quais um sistema/aplicação pode realizar com sucesso  em termos de carga de trabalho(workload) e número de usuários virtuais(Virtual Users);

  - Stress: Testes são projetados para causar a falha no sistema e determinar o “breaking point” do sistema;

  - Volume: Testes são projetados para identificar o máximo de throughput, ou seja, total de transações por minuto de um sistema;

  - Escalabilidade: Testes são projetados para medir a performance do sistema enquanto uma constante carga é adicionada(Usuários Virtuais);

  - Tolerância(Endurance): Testes são projetados para avaliar a performance do sistema sob condições normais  de carga através de um longo período de tempo;

Testes de Performance X Testes Funcionais

Teste de Performance

Teste Funcional

Não testa o front-end da aplicação, ou seja, as funcionalidades.

Teste o front-end da aplicação, bem como usabilidade e funcionalidades.

Teste a escalabilidade da aplicação e monitora o uso dos recursos de hardware.

Não teste a escalabilidade da aplicação e monitora o uso dos recursos de hardware.

Projetado para determinar como uma aplicação / sistema irá realizar ao longo do tempo.

Não pode determinar como uma aplicação / sistema irá realizar ao longo do tempo.

Requer uma aplicação totalmente funcional para que os cenários sejam executados adequadamente.

Não requer uma aplicação totalmente funcional para que os cenários sejam executados adequadamente.

Vários usuários.

Um usuário.

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 é normalmente executado para ajudar a identificar gargalos 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

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/

Atenciosamente,

Fábio Martinho Campos, CBTS CST CQA COBIT CSCM ISTQB/ISEB CBAS CSTE CSQA
IBM Certified Specialist - Software Quality
Certified Scrum Master
CTMNF(Certified TMap Next Foundation)
MBA in Project Management(PMI)
TMMI Foundation Member
http://br.linkedin.com/in/fabiomartinhocampos

Fábio Martinho Campos

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 na empresa alemã Liebherr Guindastes e Máquinas Operatrizes como analista de sistemas e desenvolvedor web, atuando também como analista de processos para o projeto de GED (Gerenciamento Eletrônico de Documentos) da empresa. 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. Possui as certificações CBTS (Certificação Brasileira de Teste de Software), CQA (Certified Quality Assurance), CST (Certified Software Testing), COBIT(ISACA), ISTQB/ISEB(CTFL) e IBM Certified Specialist – Software Quality. É palestrante da disciplina de Teste de Software e Qualidade de Software, contribui para o crescimento do mercado de Teste de Software no Brasil através de palestras e eventos em universidades.