Post

1 Star2 Stars3 Stars4 Stars5 Stars

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.