Desenvolvimento - ASP. NET

Testes de Performance - Ciclo de Vida de Performance e Atividades Relacionadas - Parte 2

Assim como há o Ciclo de Vida de Desenvolvimento de Software(SDLC), existe também um termo novo chamado de Ciclo de Vida de Teste de Performance, o qual é relevante para sistemas baseados na Web. PTLC é parte fundamental e indispensável do SDLC.

por Fábio Martinho Campos



Ciclo de Vida de Teste de Performance(PTLCPerformance Testing Life Cycle): Assim como há o Ciclo de Vida de Desenvolvimento de Software(SDLC), existe também um termo novo chamado de Ciclo de Vida de Teste de Performance, o qual é relevante para sistemas baseados na Web. PTLC é parte fundamental e indispensável do SDLC.

Uma vez que problemas relacionados com performance devem ser realizados em cada nível do SDLC, existe a necessidade de se avaliar cada fase novamente, saber a causa raiz de cada problema encontrado e ainda registrar os defeitos.

Cada fase do SDLC tem um componente de PTLC!

O Teste de Performance dentro do Ciclo de Vida Tradicional de Desenvolvimento de Software(Waterfall):

O Teste de Performance dentro do Ciclo de Vida de Teste de Software:

Outros exemplos ainda para um ciclo de vida para testes de performance pode ser o abaixo:

Muitos outros ciclos de vida poderiam ser citados. Adicionalmente, estes modelos servem de base para as empresas adotarem totalmente ou apenas partes deles, sendo que ainda adaptações podem ser feitas para serem ajustadas à realidade da empresa.

Para fins de detalhamento e explicação das atividades dentro de cada fase de um modelo de ciclo de vida para testes de performance, vamos usar o exemplo genérico abaixo:

    Identificação do Ambiente de Teste

O ambiente onde será executado os testes de performance bem como as ferramentas e hardware necessário consiste o Ambiente de Teste de Performance. Se a objetivo é determinar a performance do sistema em produção, o ambiente de teste deve/deveria ser uma réplica desse mesmo ambiente, mas com a idéia de geração de cargas de trabalho e monitoramento de recursos.

Réplicas de ambientes de produção não são utilizadas na maioria das vezes!!!

A similaridade entre os componentes de hardware, software e configuração da rede têm grandes impactos nos resultados de performance, sendo que deve-se ainda levar em consideração quais testes serão executados e a carga de trabalho que será gerada.

É importante lembrar que ambientes com hardware e software não são somente responsáveis pelo impacto na performance, mas também os objetivos e metas do teste que será executado

É muito importante entender as similaridades e diferenças entre o ambiente de teste e o Ambiente de produção. Alguns fatores devem ser considerados, como:

- Hardware:

· Configurações;

· Hardware(Processador, memória, etc.);

- Rede de Dados:

· Arquitetura da rede localização do usuário final;

· Implicações de load-balancing(Balanceamento de carga);

· Cluster e configurações de DNS;

- Ferramentas:

· Limitações das ferramentas de geração de carga;

· Impacto no uso de ferramentas de monitoração;

 - Software:

· Outros softwares que estejam rodando ou instalados no mesmo ambiente ou em ambientes virtuais;

· Capacidade de armazenamento e volume de dados;

  - Fatores Externos

· Volume e tipo de tráfego na rede de dados;

· Processos batch agendados; atualizações e/ou backup’s;

· Interações com outros sistemas

Considerações:

- É muito importante que os analistas de teste tenham acesso a servidores e software, ou fácil acesso aos administradores que fazem serviços de instalação, configuração, etc.;

- Identificar a quantidade e o tipo de dado que a aplicação irá usar para simular condições reais;

- Analise os fiirewalls, DNS’s, etc. a fim de produzir o ambiente real de produção;

- É recomendável solicitar ajuda aos administradores de sistemas para que eles possam configurar ferramentas de monitoração, diagnósticos e outras utilidades do ambiente de teste.

    Identificação dos Critérios de Aceite de Performance

Identificação dos Critérios de Aceite de Performance: Geralmente faz sentido começar a identificação ou pelo menos estimar as características de performance desejadas o mais cedo possível no SDLC. Isso pode ser conseguido através de sessões de levantamento de requisitos e acordos já estabelecidos que os usuários e stakeholders esperem de uma boa performance.

Três características são  freqüentemente essenciais para a satisfação dos usuários e stakeholders, como:

 - Tempo de Resposta;

 - Throughput;

 - Utilização de Recursos.

Considerações:

- Requisitos de negócio;

- Expectativas dos usuários;

- Obrigações contratuais;

- Padrões de indústria e conformidade com agencias reguladoras;

- SLA’s;

- Metas de utilização de recursos;

- Vários e realísticos modelos de carga de trabalho;

- KPI(Key Performance Indicators);

- Objetivos de otimização;

- Cronograma, treinamento, contratações, orçamentos, recursos humanos e não humanos, etc.

    Planejamento do Design de Teste

O planejamento de design dos testes de performance envolvem a identificação dos cenários mais usados/comuns dos usuários, determinação da variação entre os usuários, identificação e geração de dados de teste(massa de dados) e especificação das métricas que devem ser/serão coletadas.  Estas informações serão a base para a criação de perfis de cargas de trabalho.

Quando o planejamento de design é feito para se simular o ambiente de produção, os objetivos/metam devem ser a criação de cenários do mundo real para assim prover informações confiáveis para possibilitar a organização a tomar decisões nas informações levantadas.

O design de cenários do mundo real aumentará significativamente a relevância e utilidade dos resultados do teste!!!

A fase de design pode levar muito tempo, uma vez que scripts precisam ser gerados. Para o design, levam-se em consideração os cenários chave, como:

- Cenários obrigatórios, especificados via contrato;

- Cenários mandatórios para se atingir os objetivos/metas de performance;

- Cenários mais comuns;

- Cenários de fator crítico para o negócio da organização;

- Cenários com uso intenso do usuário final;

- Cenários que possam envolver preocupações técnicas e dos stakeholders;

- Cenários com alta visibilidade.

Quando identificadas, coletadas e reportadas corretamente, métricas provêem informações da performance do seu sistema comparando-se com as características de performance desejadas.

Para fazermos um planejamento estruturado, organizado e dedicado para testes de performance precisamos de uma Plano. Um exemplo de template para Plano de Performance é fornecido neste artigo.

Considerações:

- Cenários realísticos são baseados no quem se espera encontrar no mundo real e não teorias e projeções;

- Cenários realísticos produzem mais credibilidade nos resultados e melhora o valor do Teste de Performance;

- Teste de performance no nível de componentes também deve ser encarado com cenários realísticos;

- Se os resultados dos testes foram extrapolados/não realísticos, pode-se criar cenários de inconsistências a medida que o escopo do projeto tende a crescer, levando a decisões freqüentemente erradas;

- Envolvimento dos desenvolvedores e administradores de sistema como forma de determinar as métricas onde provavelmente eles tem forte impacto na performance como um todo;

    Configuraçao do Ambiente de Teste

A preparação do ambiente de teste, ferramentas e recursos para a implementação do design do teste e execução deve iniciar o quanto antes, uma vez que suporte poderá ser necessário para várias atividades como configurações, listas de IP’s, etc. Geralmente, ferramenta de geração de carga e monitoração apresenta problemas e aonde quer que tenha sido o problema(Rede de dados, ambiente, hardware, etc.), problemas precisam ser levantados o quanto antes para que o cronograma de execução não seja impactado.

É necessário também periodicamente reconfigurar, atualizar, adicionar ou melhorar sua geração de carga no ambiente e as ferramentas associadas. Isso porque mesmo que a aplicação que esteja sendo testada continuar com a mesma geração de carga ou a aplicação continue a mesma, provavelmente as métricas que você quer coletar vão mudar.

Considerações:

- Determinar o quanto de carga você poderá gerar antes dos geradores de carga atingir um gargalo;

- Sincronizar o relógio da sua máquina com os relógios do servidor, banco de dados, etc.;

- Monitorar a utilização dos recursos(CPU, rede de dados, memória, etc.) entre os servidores;

- Acionar o suporte responsável por cuidar dos servidores, bando de dados, rede de dados, etc. sempre que necessário;

- Validar o balanceamento de carga.

    Implementação do Design de Teste

Os detalhes de criação/implementação da execução dos testes de performance são baseados em ferramentas de automação. Dependendo da ferramenta de automação a implementação envolve tipicamente a criação de scripts para um único cenário e então melhorando e combinando este com outros cenários para assim representar um modelo de carga de trabalho completo.

Considerações:

- Garantir que os dados de teste foram implementados corretamente. Dados de teste(massa de dados) são repositórios na forma de banco de dados, arquivos texto, variáveis na memória ou planilhas que são usados para simular parâmetros de substituição durante um teste de carga.;

- Garantir que a validação das transações estão implementadas corretamente, pois muitas transações estão reportadas corretamente pelo servidor Web, mas falham ao serem completadas;

- Validar a monitoração dos KPI’s e adicionar apenas indicadores pertinentes. 

    Execução dos Testes

A atividade de execução torna-se, então, a tarefa mais “agradável” e de grande interesse de todos do time de teste para ser realizada. Os fluxos, processos e detalhes técnicos dependem muito da ferramenta que se está usando, ambiente e contexto do projeto. Na realidade, a tarefa de Teste de Performance é significativamente muito mais complexa do que se possa imaginar, ao contrário de muitos acharem que é necessário apenas “rodar” alguns scripts de teste, monitorar as máquinas e clicar em alguns botões.

À medida que se começa a preparação para se executar os testes, é de grande valor adicionar um tempo extra para checar/validar alguns itens como:

- Validar se a configuração do ambiente de teste representa a configuração esperada/projetada para os testes;

- Garantir que ambos os testes e o ambiente de teste estão corretamente configurados para a coleta de métricas;

- Executar um “Smoke Test” antes da execução real dos testes;

- Garantir que os scripts de teste representam o modelo de carga de trabalho que se deseja simular;

- Garantir neste momento que a coleta de indicadores de performance estão configurados corretamente.

Considerações:

- Validar as execuções do teste;

- Validar se os scripts de carga estão usando os valores corretos de dados;

- Quando possível, limitar o ciclo de execuções para um ou dois dias. Revise e priorize novamente após cada ciclo execução;

- Observar a execução dos testes e prestar atenção se algum comportamento não previsto anteriormente está acontecendo no momento;

- Não processar dados, programas ou qualquer outra atividade que consuma muitos recursos do computador, pois isso poderá afetar a geração da carga de trabalho, invalidando os resultados do seu Teste de Performance;

- Desativar qualquer tipo de anti-vírus na geração da carga de trabalho durante o teste para minimizar a probabilidade de involuntariamente impactar os resultados do teste;

- A execução dos testes nunca é realmente finalizada, porém eventualmente vai se chegar a um ponto desejado de um teste particular. Quando você parar de obter informações as quais se deseja, avançar para outros testes.

    Análise, Relatórios e Re-teste

Gerentes e Stakeholders precisam/querem muito mais que simples resultados de vários testes. Eles precisam de conclusões, bem como dados consolidados para apoiar suas conclusões. Membros do time(analistas) precisam não só de resultados dos testes, mas também de análises, comparações e detalhes de como os resultados foram conseguidos.

Antes que os resultados possam ser divulgados, os dados precisam ser analisados. Alguns pontos importantes são necessários quando se analisa os dados retornados pelo Teste de Performance, como:

- Analise os dados de forma individual e como parte colaborativa dentro do time de analistas de teste;

- Analise os dados coletados e compare os resultados com métricas aceitáveis ou níveis esperados para determinar quando a performance da aplicação que está sendo testada mostra tendências que vão ou estão fora dos objetivos de performance;

- Se o teste falhar, diagnósticos e atividades de tunning são geralmente aceitas;

- Se você corrigir um gargalo, repita os testes para validar a correção;

- Use os resultados atuais para priorizar os próximos testes;

- Modifique o teste para conseguir novas/melhores/diferentes informações se o resultado não representar os objetivos do teste;

- A coleta de métricas pode produzir grandes volumes de dados! A redução destes dados pode ser feita mediante análise do que se pode descartar, para assim não se perder dados valiosos;

- Freqüentemente, as análises irão revelar que para um total/completo entendimento dos resultados de um teste particular, métricas adicionais serão necessárias;

- Compartilhe os resultados para o resto do time a fim de receber feedbacks.

Adicionalmente, existem duas categorias principais para onde os relatórios/analises devem ser informados:

- Relatórios Técnicos:

· Descrição do teste, incluindo modelo de carga de trabalho e ambiente de teste;

· Descrição do teste, incluindo modelo de carga de trabalho e ambiente de teste;

· Curtas observações, riscos, questionamentos e requisições diversas(tempo, colaboração de outros membros, etc.);

- Relatórios para Stakeholders:

· Representações visuais dos dados mais relevantes;

· Resumos dos gráficos em termos de critérios/objetivos/metas que foram atingidos;

· Representações visuais dos modelos de carga de trabalho e ambiente de teste;

· Anexos de relatórios técnicos, dados e condições de teste;

· Resumo de observações, riscos e recomendações.

Para a grande eficácia dos relatórios, informações pertinentes e de interesse devem ser colocadas, levando-se em consideração o público-alvo, como:

- Reportes visuais;

- Relatórios antecipados e freqüentes;

- Relatórios com estatísticas/dados corretos;

- Dados consolidados corretamente;

- Faça com que os dados estejam disponíveis para os stakeholders;

- Filtre qualquer dado que não agrega qualquer tipo de informação relevante.

Métricas de Performance

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:

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/

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.