Os custos da realização dos Testes de Desempenho e Estresse

Os custos da realização dos Testes de Desempenho e Estresse Iure de Sousa Fé 1, Ismayle de Sousa Santos 1, Pedro de Alcântara dos Santos Neto 1 1 Departamento de Informática e Estatística Universidade Federal do Piauí (UFPI) Campus Ininga, PI Brasil {ismayle,iure,pasn}@ufpi.edu.br Abstract. The companies are using more and more software testing to ensure systems quality. However, the testing activity is expensive and many times it is not performed entirely. In the case of Web applications, for instance, it is common the execution of functional testing, to verify the behavior, but it is not trivial the verification of non-functional aspects, as performance requirements. This work presents one of the reasons that performance and stress testing are seldom executed, that is the related costs. In order to do this we present the main aspects that increases the performance and stress testing costs. Resumo. Cada vez mais empresas utilizam testes de software para garantir a qualidade dos sistemas desenvolvidos. Contudo, a atividade de testes é onerosa, o que faz com que muitas empresas desenvolvedoras de softwares não a realizem por completo. No caso de aplicações para Web, por exemplo, boa parte das empresas realiza testes funcionais, que verificam o comportamento do sistema, mas não verificam as características não-funcionais, como por exemplo, requisitos de desempenho. Este artigo apresenta uma das razões pelas quais os testes de desempenho e estresse são pouco executados, que é justamente o seu custo de execução. Para isso, serão apresentados os principais fatores que tornam a realização desses testes tão onerosa. 1. Introdução Uma vez que os softwares estão cada vez mais presentes no cotidiano e que o mundo globalizado é altamente competitivo, é essencial para se manter no mercado que os softwares desenvolvidos sejam de alta qualidade. Um dos meios usados para se garantir a qualidade de um software é a realização de testes. O teste de software é a verificação dinâmica do funcionamento de um programa utilizando um conjunto finito de casos de teste, adequadamente escolhido dentro de um domínio de execução, em geral, infinito, contra seu comportamento esperado [IEEE 2004]. Os testes, entretanto, requerem tempo, conhecimento, planejamento, infraestrutura e pessoal especializado, sendo, portanto, uma atividade inerentemente custosa[myers 2004]. Com isso, boa parte das empresas desenvolvedoras de software não realiza testes. Contudo, a falta de testes pode fazer com que o software desenvolvido seja entregue com defeitos, o que pode trazer muitos problemas, como por exemplo, prejuízos financeiros, danos físicos e até perda de vidas humanas, além de prejudicar a imagem da equipe perante a empresa e desta para com o cliente. Existem vários tipos de testes. O teste funcional, por exemplo, tem como objetivo verificar o comportamento do software. Isso normalmente é feito a partir de uma análise

da execução verificando se a utilização de determinadas entradas causa a obtenção da saída esperada. Esse é o mais comumente encontrado e executado nas empresas, pois ele testa se o sistema realiza o que foi acordado entre desenvolvedor e cliente [Myers 2004]. Por outro lado, testes como os de desempenho e estresse, que estão relacionados à requisitos não-funcionais, ainda são pouco executados. É importante notar que no cenário atual, no qual os sistemas estão cada vez mais voltados para Web, a realização de testes de desempenho e estresse se torna essencial, pois para esses sistemas o desempenho é um dos requisitos mais importantes a ser observado [Molinari 2003]. Isso pode ser confirmado com o que aconteceu no Serviço de Emergência de Londres, em 1992 [Finkelstein and Dowell 1996]. Nesse episódio houve perda de vidas devido a um aumento nas solicitações e incapacidade do sistema em tratar um grande número de requisições simultâneas. Testes de desempenho e estresse poderiam ter detectado esse problema, evitando assim a catástrofe. Este artigo apresenta as principais razões que tornam a realização dos testes de desempenho e estresse tão onerosa. Serão apresentados as dificuldades relacionadas à preparação do ambiente, a execução e análise dos resultados. O objetivo dessa explanação é deixar claro aos profissionais ligados ao desenvolvimento de software as questões relacionadas a esses testes, podendo assim direcionar os esforços de pesquisadores e desenvolvedores para buscar meios que minimizem os custos associados, além de deixar claro algumas questões que permanecem desconhecidas até que se tente executar tais testes. O restante deste artigo está organizado da seguinte forma: a Seção 2 detalha a diferença entre os testes de desempenho e os testes de estresse; na Seção 3 são descritos os custos relacionados à preparação do ambiente; a Seção 4 apresenta os custos associados à execução dos testes de desempenho e estresse e a análise dos resultados; e a Seção 5 conclui o artigo apontando direções para possíveis trabalhos futuros. 2. Testes de Desempenho x Testes de Estresse O Teste de desempenho consiste em testar um sistema quanto aos seus requisitos de desempenho, dentro de um determinado contexto. São exemplos desse tipo de requisito [Denaro et al. 2004]: Tempo de resposta (Latência): tempo entre uma requisição e a completude e resposta da operação requisitada; Throughput: número de operações que o sistema é capaz de completar em um dado período de tempo; Escalabilidade: quantidade de usuários simultâneos que o sistema pode lidar; Uso de recursos de máquina, como memória e processamento. Conforme citado anteriormente, é necessário que o teste de desempenho seja feito em um contexto específico. Para isso, deve haver um conjunto bem definido de requisitos, do contrário, esses testes serão medições cegas [Weyuker and Vokolos 2000]. São exemplos desses requisitos: i) o sistema deve suportar 100 usuários simultâneos; ii) todas as requisições devem ser respondidas em menos de 8 segundos. A partir dessa definição, o teste de desempenho deve simular o ambiente desejado e verificar se o sistema se comporta conforme especificado.

Apesar de um teste de desempenho completo e ideal depender da existência de um sistema totalmente integrado e funcional, sendo executado em um ambiente similar ao que abrigará o funcionamento do sistema quando entregue, testes de desempenho podem ser aplicados em todos os passos da construção do software [Pressman 2006]. Isso é uma boa prática, principalmente levando em consideração o fato de que a maioria dos problemas críticos de desempenho advém de decisões feitas em estágios iniciais do ciclo de desenvolvimento do software [Denaro et al. 2004]. Testes de estresse geralmente são realizados de forma conjunta com testes de desempenho, não sendo raro haver confusão entre os mesmos. Enquanto o teste de desempenho tem como objetivo testar se determinado sistema é capaz de lidar com a carga esperada e definida nos requisitos, o teste de estresse consiste em submeter o sistema a situações anormais de uso [Myers 2004], como grandes quantidades de carga, comportamento anormal de portas em um servidor, redução dos recursos computacionais disponíveis e entradas não realistas de dados [Garousi et al. 2006]. A partir do teste de estresse é possível observar o comportamento do sistema durante situações críticas, identificando falhas não toleráveis e potencialmente difíceis de serem encontradas em situações normais de funcionamento. Um exemplo de um comportamento indesejável é o vazamento de informações confidenciais de um banco de dados em mensagens de erro [Sommerville 2003]. Além disso, a capacidade de recuperação de falhas de um sistema pode ser testada durante a execução do teste de estresse e apesar de, conceitualmente, o teste de estresse executar um programa sob condições as quais ele não foi projetado para atuar, é importante frisar que essas situações nem sempre são impossíveis de ocorrer [Pressman 2006]. 3. Preparação do ambiente de teste O primeiro desafio para se executar um teste de desempenho e estresse está na definição da carga de trabalho (workload). No caso de aplicações web, isso corresponde a definir a quantidade de requisições que devem ser processadas pelo sistema testado. O problema é que como os testes de desempenho e estresse devem verificar a performance da aplicação, se o workload é incorretamente planejado, como por exemplo, não levando em conta os períodos de maior acesso, os resultados dos testes não serão válidos [Everett and McLeod 2007]. Supondo, por exemplo, um sistema web que no ambiente real lida com 1000 a 1500 usuários simultâneos. Se os testes de desempenho e estresse para esse sistema fossem feitos com apenas 100 usuários concorrentes, a performance apresentada durante esses testes seria muito diferente da performance real da aplicação. Assim, para a definição do workload, o ambiente real do sistema sob teste deve ser cuidadosamente analisado. A Figura 1 apresenta um possível exemplo do resultado de um bom planejamento da carga de trabalho para um sistema de biblioteca on-line. Nela é possível observar que devem ser discriminados, com relação a cada operação do sistema, os requisitos de tempo, a quantidade de usuários a ser utilizada e os dias e horários de maior acesso. Definida a carga de trabalho, o próximo passo consiste na preparação do ambiente, ou seja, na simulação do ambiente real da aplicação testada e na geração dos dados necessários. A primeira decorre do fato de que os testes de desempenho e estresse estão relacionados a performance da aplicação testada, logo, é necessário que esses testes sejam

Figura 1. Exemplo de planejamento da carga de trabalho realizados em condições idênticas às do funcionamento real, caso contrário os resultados obtidos não serão válidos. Quanto a geração de dados, ela se faz necessária, pois de forma geral, nos testes de desempenho e estresse são criados centenas e até milhares de usuários virtuais que enviam requisições a aplicação sob teste. Assim, dependendo da aplicação testada, se os dados utilizados tiverem que ser únicos para cada usuário virtual, eles deverão ser gerados antes da execução desses testes. A simulação do ambiente real da aplicação pode exigir muito tempo de trabalho. Isso porque, devem ser levados em conta os seguintes fatores [Molyneaux 2009]: Largura de banda: A infra-instrutura deve ser levada em conta, pois é comum que mais de um sistema seja hospedado em uma mesma máquina, o que significa que eles estariam disputando entre si os recursos disponíveis da máquina. Número de servidores: a aplicação pode ser distribuída ou replicada em vários servidores, o que dificultaria a simulação do ambiente real. Número de camadas da aplicação: a utilização de camadas entre o usuário e aplicação pode ter grande influência na performance de uma aplicação. A utilização de um servidor de Proxy, por exemplo, acarretaria em um processamento a mais, aumentando assim, o tempo de resposta do usuário. Banco de dados: o banco de dados utilizado durante os testes deve ter dimensões próximas as que o sistema testado irá possuir, pois fazer buscas em um banco de dados de 1 Giga pode consumir um tempo de resposta bem diferente de fazer as mesmas buscas em um banco com 10 Gigas. Quantidade de usuários virtuais: como os teste de desempenho e estresse devem fornecer uma carga de trabalho para a aplicação testada, deve ser definido quantos usuários virtuais deverão ser criados para enviar as requisições. A simulação do número de servidores e da largura de banda poderia ser feita com o uso de máquinas virtuais. Entretanto, a utilização destas consome mais memória e processamento e, além disso, seria praticamente impossível simular uma rede real na qual os servidores estão conectados a grandes distâncias. Como mencionado anteriormente, em muitas situações existe a necessidade de dados previamente cadastrados para executar certas funcionalidades requisitadas durante a execução dos testes de desempenho e estresse. Considerando um sistema de biblioteca, por exemplo, no qual é possível uma pessoa tomar um livro emprestado se o livro estiver disponível e se a pessoa tiver menos de três livros emprestados na sua conta. Então, devido as restrições da aplicação, para a execução de um teste de desempenho ou estresse, onde fosse feito o empréstimo de centenas ou até milhares de livros, seria necessário a existência de vários cadastros de livros e de pessoas.

Gerar os dados automaticamente é com certeza uma das partes mais trabalhosas da preparação do ambiente para realização dos testes de desempenho e estresse. Isso porque a geração de dados deve levar em conta as dependências existentes entre as entidades da aplicação. Assim, alguns cuidados devem ser tomados, como a fidelidade a multiplicidade dos relacionamentos, pois a criação de dados em multiplicidades erradas pode interferir em possíveis validações ocorridas na operação testada, e a verificação da existência de associações reflexivas ou dependências cíclicas, para evitar ciclos intermináveis de criação de dados. Além disso, devem ser observados os problemas relacionados ao domínio dos dados a serem criados automaticamente, pois se gerados de forma inadequada, eles podem fazer com que o sistema responda as requisições de forma inesperada, o que poderia prejudicar o tempo de resposta da aplicação durante o teste de desempenho, ou até mesmo impossibilitar a realização de requisições que utilizassem tais dados. Dessa forma, a geração de dados também deve levar em conta os valores que não podem ser nulos, os limites inferior e superior, além dos atributos que devem seguir um certo formato ou que devem passar por uma certa validação, como no caso de CPF e CNPJ. 4. Execução dos Testes e Análise dos resultados Quanto à execução dos testes, o principal fator de gastos está relacionado ao uso de ferramentas de testes. Como a execução dos testes de desempenho e estresse exige que múltiplas requisições sejam enviadas ao mesmo tempo ao sistema testado, ferramentas que criam e gerenciam usuários virtuais são essenciais para a execução automática desses testes. Contudo, a equipe de teste deve procurar adquirir aquela que melhor atenda as suas necessidades, pois a escolha de uma ferramenta inadequada pode prejudicar a produtividade da equipe de teste, como por exemplo, exigindo muito tempo para que o testador consiga aprender a utilizá-la. A ferramenta de teste escolhida também deve ser apropriada para testar o alvo definido para o teste de desempenho e estresse. Isso porque além de poder testar a performance da aplicação com relação as requisições feitas pelos usuários, podem ser feitos testes de desempenho e estresse para avaliar, por exemplo, a performance de web services ou de um banco de dados. Em síntese, se a ferramenta escolhida for gratuita, os custos estarão relacionados ao tempo gasto para o aprendizado, criação e execução dos testes, caso contrário, se for uma paga, além desses custos existirá o gasto com a compra da licença da ferramenta. Por fim, como os resultados dos testes de desempenho e estresse normalmente são apresentados através de gráficos e valores estatísticos, os responsáveis por esses testes devem possuir os conhecimentos necessários para interpretá-los. Logo, deve-se também investir recursos em capital humano, seja com treinamentos ou através da contratação de profissionais especializados, pois a falta desse investimento pode resultar em gastos com melhoria de desempenho sem necessidade ou na entrega do produto sem atender aos requisitos [Meier et al. 2007]. 5. Conclusões A atividade de Teste é parte importante do processo usado para garantir a qualidade de um software. Os testes, entretanto, requerem tempo, conhecimento, planejamento,

infra-estrutura e conhecimento especializado, sendo, portanto, uma atividade inerentemente custosa. Embora os testes funcionais estejam relativamente bem difundidos nas organizações, isso não acontece com os testes de desempenho e estresse, que são bem menos difundidos. As principais explicações relacionadas a esse fato são a ausência de profissionais qualificados e o alto custo para realização desses testes. Os testes de desempenho e estresse, principalmente em se tratando de sistemas para Web, são considerados essenciais. Por conta disso, foram detalhados neste trabalho os principais pontos a abordar durante a execução desse tipo de teste. Foram descritos as principais dificuldades relacionadas a preparação do ambiente, execução e análise dos resultados, as quais tornam a realização desses testes muito custosa. Este trabalho faz parte de um trabalho maior que visa automatizar parte dos aspectos aqui apresentados. Inicialmente, foram levantados os problemas relacionados, descritos neste artigo, para em seguinda analisarmos como atuar na resolução de cada um desses problemas. Essa é a principal continuidade do trabalo. Outra linha futura é a comparação entre os custos dos testes de desempenho e estresse e os custos de outros tipos de testes, como por exemplo, os testes funcionais, para que possamos exibir métricas relacionadas a essa atividade. Referências Denaro, G., Polini, A., and Emmerich, W. (2004). Early performance testing of distributed software applications. SIGSOFT Software Engineering Notes, 29(1):94 103. Everett, G. D. and McLeod, R. (2007). Software Testing: Testing Across the Entire Software Development Life Cycle. John Wiley & Sons. Finkelstein, A. and Dowell, J. (1996). A comedy of errors: the london ambulance service case study. In IWSSD 96: Proceedings of the 8th International Workshop on Software Specification and Design, page 2, Washington, DC, USA. IEEE Computer Society. Garousi, V., Briand, L., and Labiche, Y. (2006). Traffic-aware stress testing of distributed systems based on UML models. In Proceedings of the 28th International Conference on Software Engineering (ICSE), pages 391 400, Shanghai, China. IEEE (2004). The guide to the software engineering body of knowledge. IEEE Computer Society. Meier, J. D., Farre, C., Bansode, P., Barber, S., and Rea, D. (2007). Performance Testing Guidance for Web Applications: patterns & practices. Microsoft Corporation. Molinari, L. (2003). Testes de Software: Produzindo Sistemas Melhores e Conviáveis. Editora ÉricaLtda, São Paulo. Molyneaux, I. (2009). The Art of Application Performance Testing: Help for Programmers and Quality Assurance. O Reilly Media. 1a edição. Myers, G. (2004). The Art of Software Testing. John Wiley & Sons. 2a edição. Pressman, R. (2006). Engenharia de Software. McGraw-Hill. 6a edição. Sommerville, I. (2003). Engenharia de Software. Addison Wesley. 6a edição. Weyuker, E. and Vokolos, F. (2000). Experience with performance testing of software systems: Issues, an approach, and case study. IEEE Transactions on Software Engineering, 26(12):1147 1156.