Erros comuns em testes de carga e como evitá-los com WEBLOAD

O WebLOAD é uma ferramenta específica para Testes de Carga e Performance. Desconhecida de muitos e utilizada por poucos, a ferramenta é open-source e é patrocinada pela Radview Software. Nela é possível realizar testes de carga e performance, podendo ser facilmente usada por qualquer analista de testes.

por Fábio Martinho Campos

Dando continuidade a série “Conhecendo Ferramentas de Automação para Teste de Software”, vamos apresentar dessa vez uma ferramenta específica para Testes de Carga e Performance. Ela se chama WebLOAD. Desconhecida de muitos e utilizada por poucos, a ferramenta é open-source e é patrocinada pela Radview Software. Nela é possível realizar testes de carga e performance, podendo ser facilmente usada por qualquer analista de testes.

Veremos como podemos evitar os erros comuns nos testes de carga.

O teste de carga é um dos últimos elementos da pré-produção na cadeia de desenvolvimento. Isso aumenta a tentação de fazer economias e acelerar resultados nos testes para lançar o produto o mais rápido possível.

No entanto, não há dúvidas de que o teste de carga é um processo de alta complexidade. Planejar incorretamente, criar cenários que não simulam o ambiente de produção real fielmente ou sobrecarregar seus geradores de carga, na melhor das hipóteses, vai custar tempo, dinheiro e recursos envolvidos em novas execuções do mesmo teste. O pior é que lançar um produto mais rápido, sem executar um teste de carga realista, pode ser um verdadeiro desastre.

Aqui está um resumo de alguns dos erros mais comuns cometidos em testes de carga que você precisa evitar. Mais detalhes podem ser encontrados no eBook gratuito disponibilizado pela empresa Radview (vide seção Links).

Não definir objetivos claros

Sem objetivos de teste quantificáveis e bem definidos, seu teste de carga pode se tornar um jogo de adivinhação, isso sendo otimista!

Objetivos de teste de carga precisam ser claramente definidos, com base em requisitos comerciais antes da execução e análise do seu cenário de testes. Alguns objetivos comuns em testes de carga podem ser: número de usuários que o sistema deveria suportar por cenário, tempo de resposta por atividade ou a taxa de transferência (volume de dados) que você espera que seu sistema suporte.

Não criar ambientes de teste realistas

Um ambiente real de produção possui componentes quase infinitos, como servidores, bases de dados, hardwares, ferramentas de terceiros, integrações, processos em segundo plano periódicos e muito mais. Por isso, um dos desafios mais relevantes em um teste de carga é a criação de um ambiente de testes que simule o ambiente de produção real. Sem investimento em tempo e reflexão para a criação de um ambiente realista, você pode desperdiçar uma enorme quantidade de esforços testando algo fora da realidade.

Corte de custos

Reduzir pode ser uma tentação na hora de criar cenários de teste de carga. Mesmo quando houver restrições de orçamento, recursos ou tempo, você não pode comprometer a qualidade dos resultados do seu teste de carga. Dois riscos comuns que devem ser evitados residem no número de usuários e a randomização de dados. Se você precisa testar o sistema com 100.000 usuários, você não pode usar 10.000 usuários. Do mesmo modo, se você criar apenas 100 perfis de usuários para simular 10.000 usuários, o sistema nunca estará sob o mesmo stress por causa do caching de dados.

Começar com carga demais

O objetivo do teste de carga é simular uma grande quantidade de usuários em um ambiente realista. No entanto, especialistas experientes em testes de carga concordam que começar com a carga máxima estabelecida como objetivo vai inevitavelmente falhar. Se você projetou seu teste com o cenário final do seu objetivo para 10.000 usuários de cinco lugares diferentes, mais de três tipos de dispositivos e 10 cenários de uso diferentes, por exemplo, você infelizmente não terá sucesso. Será quase impossível isolar erros quando eles aparecerem.

Em vez disso, comece com um usuário, um local e um dispositivo. Crie um cenário de testes que aumente gradualmente e monitore detalhadamente para encontrar erros em cada estágio.

Sobrecarregar geradores de carga

Máquinas geradoras de carga também podem distorcer resultados durante a execução dos seus objetivos de teste. Uma máquina geradora de carga sobrecarregada pode criar situações nas quais nenhuma carga seja gerada ou a carga seja gerada com resultados distorcidos. Para identificar se geradores de carga estão sobrecarregados, verifique os recursos da máquina, como uso da CPU, uso de memória, mudanças de contextos e transações por segundo.

Ignorar erros do sistema

A medição do desempenho e do tempo de resposta são pontos-chave em um teste de cargas por razões compreensíveis. No entanto, alguns problemas do sistema se manifesta, através de erros de sistema que não são tão evidentes como a falha ou queda no tempo de resposta. Para identificar todas as vulnerabilidades do sistema, dê atenção a erros como HTTP 500, dados incorretos e comportamentos suspeitos, mesmo quando o tempo de resposta parecer perfeito.

Não documentar as execuções de testes

Reexecutar cenários e comparar resultados entre execuções são etapas que fazem parte do processo de teste de carga, mas quando realizado várias vezes, com ajustes e melhorias em diferentes parâmetros, versões do aplicativo e configurações de teste, pode se tornar um pesadelo para rastrear as mudanças feitas em cada execução do teste. Certifique-se de documentar problemas como: objetivos do cenário, configurações exatas do sistema em teste, configurações do ambiente de teste, resultados e conclusões sobre cada execução de cenário.

De uma forma geral, o WebLOAD é uma ferramenta poderosíssima e flexível! Scripts podem ser criados no WebLOAD IDE e importados no WebLOAD Console para avaliação e monitoramento da carga e performance. Além disso é possível configurar o Performance Measurement Manager (PMM) para monitoramento dos recursos no lado do servidor (server-side) e obter estatísticas de CPU, Memória, Banco de Dados, Servidores Web, etc.

Links

eBook gratuito disponibilizado pela empresa Radview
http://lp.radview.com/common-load-testing-mistakes/

Sobre o autor:David Buch é Diretor de Inovação na RadView. David tem 25 anos de experiência na indústria de softwares com mais de 15 anos no ramo do desempenho, gerenciando equipes de desenvolvimento e pesquisa e de controle de qualidade, e ajudando os clientes a realizar seus objetivos. Ele gentilmente entrou em contato com o Linha de Código para atualizar o conteúdo publicado neste artigo.