Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Luiz Gustavo Schroeder Vieira Muita gente que trabalha com Testes de Software, bem como na área de TI num geral, trata o Teste de Performance como uma “caixa preta”. Parece que atividades como criar scripts com ferramentas para simulação de múltiplos usuários (apesar de simulação não ser o termo mais adequado quando falamos de Testes de Desempenho), monitorar o servidor de aplicação, banco de dados, CPU e memória, encontrar gargalos, ajustar queries no banco (de maneira geral, efetuar o famoso “application tuning”), parecem atividade de outro mundo. Mesmo porque esse tipo de atividade não faz muito parte do dia-dia de uma empresa de tecnologia, geralmente é terceirizada, pontualmente, com uma equipe especializada.O motivo pelo qual decidi escrever esse post é justamente para comentar QUANDO Testes de Performance fazem parte de uma organização naturalmente corporativa. Antes de quaisquer comentários, gostaria de declarar que conheço instituições que possuem uma própria equipe/estrutura especializada em Testes de Performance para as aplicações internas, o que é muito interessante. Todavia, isso é exceção, OK?Pela minha vivência com Testes de Performance, posso dizer que existem três situações as quais uma empresa geralmente procura por esse tipo de serviço:- Quando existe uma real preocupação com o desempenho da aplicação, ou seja, geralmente se a aplicação é crítica e depende de um tempo de resposta adequado. Posso citar o exemplo da Nike, num projeto que participei da primeira etapa enquanto trabalhava na HP-EDS. Eles pretendiam lançar um site durante as Olimpíadas de Pequim, sendo assim, quem acessasse o site durante a abertura participaria de uma promoção deles. Seriam centenas de milhares de acessos do mundo inteiro num momento específico do dia e ano. Comercialmente era muito importante que esse site permanecesse 100% estável. Dessa forma, solicitaram que a aplicação suportasse 300.000 acessos simultâneos e durante a primeira etapa conseguimos atingir apenas, algo em torno de, 8000 usuários virtuais. Infelizmente, não pude acompanhar as etapas posteriores desse projeto…- Ou, quando já aconteceu o problema, e, se acontecer novamente, pode dar resultados extremamente negativos para os responsáveis pela aplicação. Por exemplo, tivemos um cliente na LUGATI que precisava que a nova configuração de servidor dele atendesse, concorrentemente, 3500 usuários simultâneos em horário de pico. Caso contrário, perderia o contrato com uma grande instituição, o que resultaria numa diminuição drástica no faturamento da empresa. Após os Testes, utilizamos quatro controllers com o JMeter no seu limite (inclusive tivemos que expandir o uso da JVM para as versões 64 bits) e o site atingiu 4000 acessos simultâneos com uma taxa de erro baixíssima. Um sucesso.- A última situação, acreditem, é também bastante comum. Normalmente, quando é necessário apresentar ao usuário potencial do sistema que este é confiável, através de um relatório de Testes de Performance. É algo como se respondesse, antecipadamente, que o sistema não é lento “como os seus concorrentes do mercado”, mesmo que ele seja. Já presenciei a seguinte situação, por exemplo: “coloca qualquer informação aí no Relatório porque eu só preciso mostrar ao cliente que o sistema permanece estável após as alterações. Esses dados não precisam ser reais de fato…” Pasmem!

Source: http://www.testavo.com.br/2012/03/teste-de-performance-qual-utilidade.html

Você também pode querer ler

Comments are off for this post.