UNIVERSIDADE ANHEMBI MORUMBI EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER São Paulo 2011

2 EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER Orientadora: Profa. Msc. Regiane Aparecida Marucci. Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi. São Paulo 2011

3 EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi. Aprovado em Nome do orientador/titulação/ies Nome do convidado/ titulação/ies Nome do convidado/ies

4 O tamanho não importa. Olhe para mim, julga-me pelo meu tamanho? E não deve mesmo. Minha aliada a Força é, e poderosa aliada ela é. A vida a cria, e a faz crescer. Sua energia nos cerca e nos une. Luminosos seres somos nós, não essa rude matéria. Precisa a Força sentir à sua volta, aqui, entre nós, na árvore, na pedra em tudo, sim. Yoda, Star Wars

5 RESUMO A área de desenvolvimento de software atualmente é uma das áreas que mais atraem grandes investimentos, não apenas de grandes empresas, mas também de pequenas e médias (B2M Magazine, 2011), buscando a agilidade e automação que sistemas desenvolvidos oferecem para a produtividade da empresa. Com este investimento em novos produtos e com intuito de dar facilidade ao usuário, se faz necessário que estes novos produtos tenham a qualidade esperada pelo usuário final, assim a área de qualidade de software assume um papel importante neste contexto. Além de possuir um software sem erros, o mesmo tem que ter a resposta quase que imediata, dando a percepção ao usuário de estabilidade e eficiência do sistema. Neste cenário complexo e atual, os testes de desempenho têm o objetivo de oferecer segurança à equipe envolvida no desenvolvimento de software para que o sistema esteja de acordo com os requisitos não funcionais exigidos no inicio do projeto, por meio de métricas e relatórios assertivos, definidos para que todas as metas desejadas sejam atingidas. Considerando este contexto, neste trabalho são apresentados os diferentes tipos de teste de desempenho sugeridos na literatura mundial e como estes podem ser aplicados utilizando uma ferramenta de apoio, chamada JMeter. Também são apresentadas as características da plataforma Android, destinada ao desenvolvimento de aplicativos móveis, que foi utilizada neste trabalho para gerar o conhecimento necessário para o desenvolvimento de um aplicativo que apresenta gráficos gerenciais oriundos de um tipo de teste de desempenho aplicado em uma arquitetura e-commerce hipotética. PALAVRAS CHAVE: Teste de Software. Teste Não Funcional. JMeter. Desempenho.

6 ABSTRACT The software development today is one of the areas that attract large investments, not just from big companies but also small and medium enterprises (B2M Magazine, 2011), seeking the flexibility and efficiency that automated systems offer to the company's productivity. With this investment of those new products which objective is to give ease to the user, it is necessary that these new investment products have the expected quality by the end user, having a major role to the quality software area. In addition to owning a software without bugs, it must have also an on the fly answer, giving the user the perception of stability and efficiency. In this complex scenario, the performance tests are intended to reassure the team involved in developing software that the system is in agreement with non-functional requirements required in the project began, returning assertive reports and metrics that ensure the desired goals are attained. This paper will shown different techniques of performance test suggested in the global literature and how these can be applied using a tool to support these specific tests, called JMeter. Is also given the focus to characteristics of the Android platform for developing mobile applications, with the initial purpose on this theoretical study was to generate the knowledge necessary to develop an application that presented managerial charts which provided data from a specific performmance test on an e- commerce web portal. KEY WORDS: Software Test. Non Functional Software Test. JMeter. Performance.

7 LISTA DE FIGURAS Figura 1: O Ciclo de vida clássico Figura 2: Visão de testes de caixa preta Figura 3: Visão de testes de caixa branca Figura 4: Complexidade da definição do tempo de resposta Figura 5: Uma metodologia para o teste de desempenho Figura 6: Exemplo de definição de cenário e carga de trabalho Figura 7: Tela inicial da ferramenta JMeter Figura 8: Principais elementos de um teste de desempenho Figura 9: Tela de parametrização do componente Grupo de usuários Figura 10: Diagrama de classes do Grupo de usuários Figura 11: Requisições agrupadas no elemento Testador Figura 12: Componente Testador do tipo Requisição HTTP Figura 13: Exemplo de campo preenchido para pesquisa no site Google Figura 14: Aggregate Graph é um ouvinte disponível para apresentar um gráfico de tempo de resposta de um teste executado Figura 15: Ao acionar o botão configurar, é possível customizar o tipo de informação escrita no relatório de saída do relatório Figura 16: Indicador visual que mostra que está em execução 1 processo de Figura 17: Fim de uma execução de teste Figura 18: Exemplo de execução de teste utilizando o JMeter Figura 10: Campo parametrizado no arquivo jmeter.properties Figura 20: Possibilidade de execução remota de um script Figura 21: Imagem da arquitetura da plataforma Android Figura 22: Ciclo de vida de uma atividade Figura 23: Arquitetura típica de um Web Site de múltiplas camadas Figura 24: Caso de teste para efetuar uma compra com sucesso desenvolvido para o JMeter Figura 25: Pirâmide de usuários simultâneos utilizando o JPetStore Figura 26: Atributos definidos para o caso de teste no JMeter Figura 27: Distribuição de usuários simultâneos utilizando o JPetStore Figura 28: Desenho técnico da solução JPlotMeter...64

8 Figura 29: Diagrama de classe servidor de aplicações Figura 30: Diagrama de caso de uso Figura 31: Diagrama de classes do aplicativo JPlotMeter

9 LISTA DE TABELAS Tabela 1: Tabela de tempo de resposta por transações transacionais Tabela 2: Tabela de tempo de resposta de serviços Web Tabela 3: Tabela comparativa entre as principais ferramentas de teste de desempenho software livre do mercado Tabela 4: Caso de teste da funcionalidade de compra de um animal Tabela 5: Caso de teste da funcionalidade de pesquisa de um animal Tabela 6: Descrição do caso de Uso Consultar desempenho do site... 66

10 LISTA DE GRÁFICOS Gráfico 1: Demonstração dos eixos do JPlotMeter...68 Gráfico 2: Demonstração das legendas no JPlotMeter...68

11 LISTA DE ABREVIATURAS E SIGLAS API APK BSD CPU CSV DEX FTP GUI GPL HTML JEE JSE JVM LAN OHA REST RMI RTT SDK SQL TI V & V WAN Application Programming Interface Android Package File Berkeley Software Distribution Central Processing Unit Comma Separated Values Dalvik Executable File Transfer Protocol Graphical User Interface General Public License HyperText Markup Language Java Enterprise Edition Java Standart Edition Java Virtual Machine Local Area Network Open Handset Alliance Representational State Transfer Remote Method Invocation Round Time Trip Software Development Kit Structured Query Language Tecnologia de Informação Verificação e Validação Wide Area Network

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO TESTE DE SOFTWARE MODELO DE PROCESSO DE SOFTWARE VERIFICAÇÃO E VALIDAÇÃO TESTES FUNCIONAIS Estratégias adotadas em um ciclo de testes funcionais TESTES NÃO FUNCIONAIS Testes Estruturais Testes de Desempenho Ferramentas de Apoio a testes de desempenho JMETER ARQUITETURA DA FERRAMENTA PRINCIPAIS FUNCIONALIDADES SIMULAÇÃO DE USUÁRIOS VIRTUAIS SIMULAÇÃO DE REQUISIÇÕES RELATÓRIOS Métricas geradas MANEIRAS PARA EXECUÇÃO DE UM TESTE Interface gráfica Linha de comando Execução remota PLATAFORMA ANDROID ARQUITETURA DA PLATAFORMA CARACTERÍSTICAS DO SISTEMA OPERACIONAL RECURSOS OPERACIONAIS APLICATIVOS EXECUTADOS NO ANDROID ELABORAÇÃO DE UM TESTE DE ESFORÇO USANDO O JMETER ANALISANDO A ARQUITETURA EM UM TESTE DE DESEMPENHO... 56

13 5.1.1 Camada WEB Camada de Aplicação Camada de Dados ESCOLHA DE UM TESTE DE DESEMPENHO CRIAÇÃO DE UM CASO DE TESTE DE DESEMPENHO JPLOTMETER: UM RELATÓRIO GERENCIAL PARA O ANDROID ARQUITETURA DA SOLUÇÃO MÉTRICAS COLETADAS DO JMETER PARA GERAÇÃO DO GRÁFICO INTEGRAÇÃO COM O SISTEMA OPERACIONAL ANDROID CONCLUSAO TRABALHOS FUTUROS REFERÊNCIAS ANEXO A IDENTIFICADORES DE CRIAÇÃO DE MÉTRICAS UTILIZADAS PELO JMETER ANEXO B API S DE MAIOR UTILIZAÇÃO PARA DESENVOLVIMENTO NO ANDROID ANEXO C RESPONSABILIDADES DOS MÉTODOS PRESENTES NO CICLO DE VIDA DE UMA ATIVIDADE NO ANDROID APÊNDICE A MODELO LÓGICO DA BASE JPETSTORE APÊNDICE B CONFIGURAÇÃO DO HARDWARE DO SERVIDOR DA APLICAÇÃO JPETSTORE APÊNDICE C LOG OPERACIONAL DA FERRAMENTA JMETER APÊNDICE D MODELAGEM BANCO DE DADOS JPLOTMETER... 82

14 14 1 INTRODUÇÃO "Teste de Software é o processo com o intuito de encontrar erros em um programa ou sistema em execução (MYERS, 2004, p. 20). Esta definição citada por Myers (2004, p. 20) reforça o motivo pelo qual cada dia mais empresas se preocupam com a qualidade do seu software, investindo em grandes equipes para encontrar os defeitos inseridos em tempo de programação, seja por má interpretação da especificação funcional ou falta de mão de obra qualificada (GUERRA; COLOMBO, 2009). Por falta de tempo de cronograma de projeto ou por pouca experiência da equipe de desenvolvimento envolvida, as fábricas de software se preocupam em entregar o sistema conforme o esperado, porém não se preocupando em como o produto foi desenvolvido. Por estes motivos, muitos dos sistemas hoje em produção, acabam tendo problemas de desempenho e mesmo de segurança, por não ter tido uma validação destes requisitos ainda no seu ciclo de testes (GUERRA; COLOMBO, 2009). Diante do que foi exposto, este trabalho expõe as melhores práticas propostas por autores brasileiros e internacionais que servem de apoio para testes de desempenho e demonstra a aplicação de um dos tipos de teste de desempenho utilizando uma ferramenta Open Source chamada JMeter. O resultado da execução servirá de dado de entrada para demonstração através de um gráfico gerencial implementado para a plataforma móvel Android, apresentando o tempo médio de resposta por página ao final de cada ciclo de execução. 1.1 OBJETIVOS O objetivo deste trabalho consiste em apresentar os diferentes tipos de testes de desempenho propostos na literatura, tendo em vista aplicar um destes tipos de teste de desempenho, o teste de esforço, em uma arquitetura e-commerce hipotética. Este teste foi escolhido por poder potencializar o comportamento da degradação da performance de um sistema por buscar o seu ponto de ruptura. Para isso, é demonstrada a utilização da ferramenta Open Source de testes de desempenho chamada JMeter. Finalmente, é desenvolvido um aplicativo de relatório

15 15 gerencial para dispositivos móveis na plataforma Android, chamado de JPlotMeter, que demonstra através de um gráfico a média de tempo de resposta por páginas do portal e-commerce escolhido, com base em informações históricas armazenadas com resultados da execução de cenários de teste através do JMeter. 1.2 JUSTIFICATIVA Atualmente, as empresas investidoras em TI estão cada vez mais preocupadas em aplicar testes funcionais em suas aplicações, pelo fato de não ter uma aplicação com problemas em produção. De certa forma, esta preocupação tem contribuído para ciclos de testes mais bem definidos ao longo do desenvolvimento do software, tendo em vista a sua qualidade (GUERRA; COLOMBO, 2009). Em contrapartida, ainda são poucas as empresas que investem em testes não funcionais, principalmente em testes de desempenho, pela necessidade de conhecimento mais técnico sobre ferramentas e a própria arquitetura envolvida, e aquelas que assim o fazem, ainda não tem uma idéia muito clara dos diferentes tipos de teste e dos momentos mais adequados para cada um deles, além das possíveis ferramentas que podem ser utilizadas para a simulação de usuários virtuais (GUERRA; COLOMBO, 2009). 1.3 ABRANGÊNCIA Este trabalho visa definir de forma clara testes de desempenho e também gerar um relatório gerencial de fácil acesso, resultado da execução de cenários de testes utilizando o JMeter em uma aplicação Web. Portanto, é o foco deste trabalho: a) Demonstração prática de um dos tipos diferentes de Testes de Desempenho; b) Criação de uma aplicação para geração de um relatório gerencial para dispositivos móveis na plataforma Android, com base em resultados de execução de testes com o JMeter. Ressalta-se que não é foco deste trabalho: a) Ciclo de Desenvolvimento de software; b) Boas práticas em um ciclo de desenvolvimento de software;

16 16 c) Testes Funcionais; d) Funcionamento da plataforma Android; e) Análise de hardware; f) Arquitetura de servidor. 1.4 ESTRUTURA DO TRABALHO O trabalho proposto foi dividido de maneira que seja possível compreender como um ciclo de testes está presente dentro do ciclo de desenvolvimento de um software. No capítulo 2, é feita uma explanação sobre o modelo de desenvolvimento de software clássico e o modelo V e como os ciclos de testes funcionais e não funcionais estão presentes em cada um deles. Também é feita uma apresentação sobre ferramentas de apoio aos testes de desempenho disponíveis no mercado. No capítulo 3, o funcionamento arquitetural da ferramenta de testes de desempenho JMeter é explicado, bem como seus componentes são utilizados para a realização de testes. O capítulo 4 apresenta as principais características e o funcionamento do sistema operacional voltado para dispositivos móveis, conhecido como Android. Este capítulo tem um maior enfoque sobre como os aplicativos são executados neste sistema operacional. No capítulo 5, são apresentadas as diferentes camadas em um portal de compras Web e aplicado o ciclo de vida de um teste de desempenho, desde a sua concepção, execução e armazenamento do resultado das informações obtidas através destas execuções. O capítulo 6 apresenta o protótipo operacional do relatório gerencial desenvolvido para o Android, cuja informação de entrada para criação do gráfico é oriundo das execuções previamente armazenadas durante os ciclos de teste. As conclusões e os trabalhos futuros para continuidade deste trabalho são apresentados no capítulo 7 e, por fim, este documento é encerrado com as referências bibliográficas que foram utilizadas para o seu desenvolvimento.

17 17 2 TESTE DE SOFTWARE Segundo MYERS (2004) teste de software, é o processo de executar um programa com o intuito de encontrar erro. O ser humano tem a tendência de trabalhar orientado a objetivos. Portanto, caso o objetivo estabelecido de um ciclo de testes seja demonstrar que o software não possui erros, será escolhida uma massa de dados para teste que indique isto e casos de teste que não ofereçam a cobertura necessária para encontrar erros. Agora caso o objetivo seja identificar erros, a massa de dados para o teste e o conjunto de casos de teste terá a grande probabilidade de atingir os objetivos. Este tipo de pensamento agrega muito mais a um ciclo de desenvolvimento de software (MYERS, 2004). 2.1 MODELO DE PROCESSO DE SOFTWARE O ciclo de desenvolvimento de software contém três fases genéricas definição, desenvolvimento e manutenção que são encontradas independentemente da área de aplicação, do tamanho e complexidade do projeto ou do paradigma de engenharia de software escolhido para o desenvolvimento. Em um ciclo de vida clássico conhecido também como cascata, como pode ser visto na figura 1, sugere-se uma abordagem sistemática e sequencial ao desenvolvimento de software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação teste e manutenção (PRESSMAN, 2005). Análise e Engenharia de Sistemas Análise de requisitos de software Projeto Codificação Teste Manutenção Figura 1: O Ciclo de vida clássico. Fonte: PRESSMAN (2005)

18 18 De acordo com a figura 1, o ciclo de vida clássico é composto pelas seguintes fases: a) Análise e engenharia de sistemas: Uma vez que o software sempre faz parte de um sistema mais amplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos os elementos do sistema e prossegue com a atribuição de certo subconjunto desses requisitos ao software. Essa visão do sistema é essencial quando o software deve fazer interface com outros elementos, tais como hardware, pessoas e bancos de dados. A análise e a engenharia de sistemas envolvem a coleta dos requisitos em nível do sistema, tendo uma pequena quantidade de projeto e uma grande parte de análise de alto nível. b) Análise de requisitos de software: O processo de coleta dos requisitos é intensificado e concentrado especificamente no software. Para entender a natureza do programa a ser construído, o engenheiro (analista) de software deve compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, são documentados e revistos com o cliente. c) Projeto: O projeto de software é, de fato, um processo de múltiplos passos que se concentra em quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface. O processo de elaboração do projeto traduz as exigências numa representação do software que pode ser avaliada quanto à qualidade antes que a codificação se inicie. Como os requisitos, o projeto é documentado e torna-se parte da configuração do software. d) Codificação: O projeto deve ser traduzido numa forma legível por máquina. A etapa de codificação executa essa tarefa. Se o projeto for executado detalhadamente, a codificação pode ser executada mecanicamente. e) Testes: Assim que o código for gerado, inicia-se a realização de testes do programa. O processo de realização de testes concentra-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas, e concentram-se também nos aspectos funcionais externos, ou seja,

19 19 realizando testes para descobrir erros e garantir que a entrada definida produza resultados reais que concordem com os resultados exigidos. f) Manutenção: Provavelmente, o software sofrerá mudanças depois que for entregue ao cliente. Isto se dá, principalmente, em função da descoberta de erros, da necessidade de adaptação do software ao ambiente externo ou, também, do acréscimo de requisitos funcionais ou não ao software. A manutenção de software reaplica cada uma das etapas precedentes do ciclo de vida a um programa existente e não a um novo. No modelo clássico, cada estágio deve ser bem definido e aprovado junto ao cliente antes que o processo prossiga para o estágio seguinte. Atividades fundamentais ao processo como especificação, o desenvolvimento, a validação e a evolução do software são representadas como fases separadas no processo, como a especificação de requisitos, o projeto de software, a implementação, os testes e assim por diante (SOMMERVILLE, 2007). 2.2 VERIFICAÇÃO E VALIDAÇÃO Verificação e validação é um processo utilizado para averiguar se um produto, serviço ou sistema está cumprindo com o especificado e se está em acordo com as definições pré-estabelecidas no seu planejamento (SOMMVERILLE, 2007). Este modelo surgiu como um processo de melhoria ao problema de reatividade existente no modelo de desenvolvimento clássico. O processo de Verificação e de Validação (V & V), embora seja facilmente confundidos, não é a mesma coisa. De forma sutil, esses dois conceitos podem ser definidos como a seguir: Validação: estamos construindo o produto certo? Verificação: estamos construindo certo o produto? Por essas definições pode-se observar que o papel da verificação envolve checar se o software cumpre com suas especificações. É preciso verificar se o sistema cumpre com seus requisitos funcionais e não funcionais especificados. Já a validação é um processo mais genérico. É necessário assegurar que o software atenda às expectativas do cliente, e isso vai além de checar a

20 20 conformidade do sistema com suas especificações, a fim de mostrar que o software faz o que o cliente espera que faça, exatamente como foi especificado. Segundo Sommervile (2007), dentro dos processos de V & V, duas técnicas de checagem e análise de sistemas podem ser utilizadas: 1. As inspeções de software, que analisam e verificam as representações do sistema. Como o documento de requisitos, os diagramas de projeto e o código-fonte do programa. As inspeções podem ser aplicadas em todos os estágios do processo. As inspeções de software e as análises automatizadas são técnicas estáticas de V & V, uma vez que não requerem que o sistema seja executado. 2. Testes de software, consite em verificar se o software desenvolvido está sendo executado conforme esperado, com dados de testes pertinentes, examinando as saídas dele e o seu comportamento operacional. Os testes são uma técnica dinâmica de verificação e validação porque trabalham com uma representação executável do sistema. Para apoiar a equipe encarregada de gerenciar e executar um ciclo de teste de software é criado um ou mais artefatos chamados de plano de teste. Além de ser um documento gerencial, os planos de testes se destinam também aos engenheiros de software envolvidos em projetar e realizar os testes de sistema. Este documento é destinado também à equipe técnica para ter uma visão geral dos testes de sistema. Os planos de testes também fornecem informações ao pessoal responsável por assegurar que os recursos apropriados de hardware e software estejam disponíveis para o grupo de teste. 2.3 TESTES FUNCIONAIS Teste funcional, também chamado de teste caixa preta (BARTIÉ, 2002), é o mais utilizado nas empresas desenvolvedoras de software, em seus ciclos de testes. Ele é mais usado, por ser mais fácil, quando comparado ao teste caixa branca que será abordado no item Um dos pontos de ser mais fácil é pelo fato de não ter que demandar tempo para análise de código-fonte e conceitos implementados internamente no software, porém ele não é o menos importante na categoria de

21 21 testes, por ter regras de negócio envolvidas no software. Este tipo de teste está demonstrado na figura 2. Estímulos Produzidos Resultados Gerados Figura 2: Visão de testes de caixa preta. Fonte: BARTIÉ (2002) Como pode ser visto na figura 2, a função do teste funcional é garantir que todos os requisitos funcionais declarados no escopo do projeto/software estão sendo de fato satisfeitos. Ele testa se o algoritmo inserido no software produz os resultados esperados, através de estímulos de massa de dados de entrada (inputs) e a verificação da resposta correta da aplicação (outputs). Encontra-se com mais facilidade mão de obra qualificada para modelar os testes funcionais, pois não exige muito conhecimento da parte interna do software (código fonte, framework utilizado e etc) do funcionário alocado para esta função. O grande problema é saber se todos os cenários de testes estão de fato sendo atingidos. Para isto na seção seguinte apresentam-se as estrat égias de um ciclo de testes funcionais Estratégias adotadas em um ciclo de testes funcionais Depois que o software é construído, começa a fase de testes de alto nível, onde os critérios estabelecidos nos requisitos funcionais devem ser testados. O teste de validação é a garantia final de que o software está atendendo a todas as exigências funcionais. Os erros estão presentes, e se o engenheiro de Software não os encontrar, o cliente o fará (PRESSMAN, 2005). Nesta etapa, é necessário se ter um plano de testes, que define como selecionar as técnicas de testes, delimitar o escopo a ser testado, planejar a alocação dos recursos necessários em termos de ambiente de testes, definir ferramentas de apoio aos testes, treinamento e alocação de pessoal.

22 22 Para o processo de software no modelo de Verificação e Validação já apresentado no item 2.2, Myers (2004) diz que os componentes de um bom plano de teste são os seguintes: 1) Objetivo: Cada fase de teste deve ter um objetivo definido. 2) Critérios de Conclusão: Critérios devem ser concebidos para especificar quando cada fase do teste pode ser dada por completa. 3) Horários: Estipular horários no calendário é necessário para cada fase. Eles devem indicar quando os casos de testes serão concebidos, escritos e executados. 4) Responsabilidades: Devem ser identificadas para cada fase, as pessoas (recursos) que irão conceber, escrever, executar e controlar os casos de teste e também quem irá fazer a reparação dos erros encontrados. Faz-se necessário definir alguém como sendo a pessoa que irá apresentar o relatório de erros. 5) Biblioteca de casos de teste e padrões: Em projetos grandes é necessário métodos de identificação sistemáticos, escrever e guardar os casos de teste. 6) Ferramentas: Devem ser identificadas quais ferramentas serão necessárias para fazer os testes, incluindo quem irá desenvolver ou adquirilas, como serão utilizados e quando. 7) Tempo de Computador: Este é um plano para saber quantos computadores e por quanto tempo eles serão utilizados para cada fase de teste. Isso inclui desktops máquinas necessárias para o teste de instalação, servidores usados para aplicações de compilação e se necessário servidores Web para aplicações baseadas na Web, dispositivos de redes, e assim por diante. 8) Configuração de hardware: Se faz necessário quando tem se que configurar dispositivos ou hardwares especiais. É necessário um plano que descreva os requisitos, como vão ser cumpridos e quando eles serão necessários. 9) Integração: Faz parte do plano de teste uma definição de como o programa será integrado. Sistemas contendo grandes subsistemas ou programas podem ser reunidos de forma incremental, utilizando-se a

23 23 abordagem top-down ou bottom-up. Se este for o caso, um plano de integração é necessário. O plano de integração do sistema define a ordem da integração e a capacidade funcional de cada versão do sistema. 10) Procedimento de controle: Devem ser identificados vários meios para controlar aspectos do progresso dos testes, incluindo a localização das propensões de erros dos módulos e estimativa do progresso com respeito ao cronograma, recursos e critérios de conclusão. 11) Procedimento de depuração: Devem ser definidos mecanismos para a comunicação de erros detectados, acompanhamento do progresso das correções e implementação das correções no sistema. Também deve fazer parte do plano de depuração os horários, responsabilidades, ferramentas e tempo de computador/recursos. 12) Teste de regressão: É realizado depois de se fazer uma melhoria funcional ou um reparo pontual no programa. Seu objetivo é determinar se a alteração regrediu algum aspecto já testado no programa. O teste geralmente é realizado por re-execução de um subconjunto de casos de teste. Teste de regressão é importante, pois o programa fica muito mais propenso a erros com mudanças e alterações de códigos. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto (MYERS, 2004, p. 41). Pode-se definir um caso de teste, como sendo um conjunto específico de entradas (input) de teste, condições de execução e resultados esperados identificados com a finalidade de avaliar um determinado aspecto de um item de teste-alvo. Os casos de teste podem ser motivados por vários fatores, mas normalmente incluirão um subconjunto dos requisitos e dos riscos envolvidos no projeto. 2.4 TESTES NÃO FUNCIONAIS Os testes não funcionais são verificações da qual o desenvolvedor ou o testador, tem que avaliar se os requisitos não funcionais especificados no começo

24 24 do projeto estão de fato sendo atendidos. Existem algumas categorias de testes não funcionais, sendo elas (BARTIÉ, 2002): a) Teste de Usabilidade; b) Teste Estrutural; a. Teste de Performance (Desempenho); b. Teste de Configuração (Ambiente); c. Teste de Confiabilidade e Disponibilidade; d. Teste de Recuperação; e. Teste de Contingência; c) Teste de Compatibilidade (Versionamento); d) Teste de Segurança; e) Teste de Instalação; As próximas seções apresenta-se conceitos gerais dos Testes Estruturais, com mais enfoque enfoque nos testes de desempenho por ser o objetivo deste trabalho Testes Estruturais Também conhecido como teste de caixa branca (BARTIÉ, 2002), consiste em avaliar o comportamento interno dos componentes do software. Diferentemente do teste de caixa preta, que apenas verifica a saída (output) em relação à entrada (input), o teste estrutural consiste em destrinchar o código fonte, fazendo com que a entrada passe por todos os caminhos lógicos implementados no software, como pode ser visto na figura 3. Caminho A Início do Processamento Término do Processamento Caminho B Figura 3: Visão de testes de caixa branca. Fonte: BARTIÉ (2002)

25 25 Pressman (2005), afirma que os defeitos encontrados pelo teste caixa preta não são os mesmos encontrados pelo teste caixa branca. Pelos seguintes motivos: a) Erros lógicos e pressuposições incorretas são inversamente proporcionais à probabilidade de que um caminho em um programa seja executado. O processamento cotidiano tende a ser bem entendido, enquanto o processamento de um caso especial tende a cair por terra. b) Muitas vezes acredita-se que um caminho lógico não tem a probabilidade de ser executado quando, de fato, ele pode ser executado regularmente. Ou seja, podem-se cometer erros de projeto que são descobertos somente quando se inicia a atividade de teste do caminho. c) Erros tipográficos são aleatórios. Quando um programa é traduzido para código-fonte da linguagem de programação, é provável que alguns erros de digitação ocorram. Muitos deles serão descobertos pela verificação de sintaxe do ambiente de desenvolvimento, mas outros passarão sem ser detectados até que os testes se iniciem. É possível que exista um erro tipográfico tanto num caminho lógico obscuro como num caminho da corrente principal Testes de Desempenho Com o desenvolvimento tecnológico atual e soluções propostas para o mundo coorporativo, a infra-estrutura que dá suporte aos serviços na Web compreende muitos recursos de hardware diferentes, desde estações de trabalho dos clientes, servidores com seus processadores e subsistemas de armazenamento, além dos recursos não previstos na especificação funcional como LANs, WANs, balanceadores de carga e roteadores. Ainda existe a complexidade de processamento de software com diferentes servidores de aplicação, camadas middlewares, sistemas de gerenciamento de banco de dados, sistemas operacionais e diferentes ambientes arquiteturais se comunicando entre si (Alta e Baixa plataforma). Todos estes ingredientes somados a uma codificação complexa sem se preocupar com boas práticas de programação, tornam ainda mais complexo definir aonde pode existir um problema de desempenho (MENASCÉ; ALMEIDA, 2003).

26 26 Uma requisição feita na Web gasta uma parte do seu tempo em processamento dentro da arquitetura da aplicação e outra parte esperando nas filas pelos recursos. Para uma aplicação Web, os pedidos feitos podem ser decomposto em duas diferentes áreas (MENASCÉ; ALMEIDA, 2003): 1. Tempos de Serviço: Tempo gasto usando vários recursos, como processadores, discos e redes. 2. Tempos de Espera: Tempo gasto esperando para usar recursos que estão sendo mantidos por outros pedidos paralelamente. Para o usuário final, existe uma única percepção, o tempo de resposta. Este, por sua vez, pode ser dividido em dois componentes: 1. Tempo de Rede: Todo o tempo gasto pelas mensagens trafegadas entre o navegador do usuário e o Web Site. 2. Tempo no Web Site: Todas requisições processadas internamente pela arquitetura do Web Site. Dentro destes dois componentes, ainda existem outros conceitos como podem ser visualizados na figura 4, que demonstram como um tempo de resposta pode ser totalizado (MENASCÉ; ALMEIDA, 2003). Tempo de Resposta Tempo da Rede Tempo do Web Site Latência Tempo de Transmissão Tempo de serviço CPUs Discos LANs Tempo de fila CPUs Discos LANs Figura 4: Complexidade da definição do tempo de resposta. Fonte: MENASCÉ; ALMEIDA (2003) Com um desmembramento do custo do tempo da rede no universo do tempo de resposta, a latência é formada pelo número de ida e volta (RTT) envolvidos na

27 27 troca de mensagens entre o navegador do cliente e o site, além do tempo de transmissão, que é o tempo necessário para a transmissão de todos os bytes. O tempo gasto por este mesmo pedido do usuário, na arquitetura do web site pode ser decomposto em dois componentes principais, conforme indicado na figura 4. O tempo de serviço é o período de tempo durante o pedido que está recebendo serviço de um recurso, como CPU, disco, LAN. Este mesmo pedido pode visitar um destes recursos, várias vezes, antes que seja concluído. Com esta frequente troca de contexto do processo no processador, estes acabam sendo enfileirados gerando assim o outro componente chamado de tempo de fila. Dentro deste cenário de complexidade arquitetural a percepção do desempenho pode se tornar algo subjetivo e que deve estar em acordo com o que é esperado de resposta pelo usuário final da aplicação. A percepção do desempenho não tem um consenso específico que defina o quão rápido um sistema deva ser principalmente para tempos de resposta em serviços Web. As métricas de desempenho para processos transacionais na alta plataforma sugeridos por Miller (1968) suportam a idéia de um tempo que o homem acredita que sua solicitação está sendo processada, caso a mesma retorne em um tempo inferior a 1 segundo, como pode ser visto na tabela 1, enquanto estudos estatísticos voltados para serviços web mais recentes (ZONA, 1999) apontam uma regra de que o tempo aceitável para resposta de uma página e ou serviço web até a desistência de um usuário é de 8 segundos. Tabela 1: Tabela de tempo de resposta por transações transacionais. Tempo de Resposta 0,1 segundo 1 segundo 10 segundos Fonte: MILLER (1968) Comentário É o limite de tempo em que o usuário sente que a aplicação está respondendo imediatamente. É o limite de tempo para que o fluxo de pensamentos do usuário se mantenha contínuo, apesar de que o usuário notará a demora no processamento. É o limite máximo de espera para manter a atenção do usuário na tela. Com a crescente demanda de serviços web e com o aumento da inclusão digital de mais usuários, a regra proposta pelo survey da Zona Research inc (1999) já não pode ser aplicada exigindo um ganho de desempenho em grandes

28 28 corporações com o medo de perda de rentabilidade líquida ou desistência destes usuários implicando em visitas a web sites concorrentes. Um estudo conduzido por Bhatti, Bouch e Kuchinsky (2000), observou como os usuários reagiam quando eles eram direcionados a usar um web site para configurar e comprar um computador. O estudo identificou que existia frustração quando o tempo de resposta era por volta de 10 segundos. Por outro lado, essa tolerância diminuía de 10 para 4 segundos quando o processo de configuração de compra do computador estava próximo do fim. Spool (2001) conduziu outro estudo com diversos usuários que deveriam visitar 10 sites diferentes e utilizar os recursos dos sites conforme o interesse de cada um. Cada usuário deveria pontuar a velocidade de cada site conforme a sua percepção. Ao final dos testes, percebeu-se que o site considerado o mais devagar de todos pelos usuários era, na verdade, o mais rápido de todos, com um tempo de resposta de 8 segundos. Por outro lado, um site corporativo mundial de compras foi considerado o mais rápido de todos, no entanto, o seu tempo de resposta era de 36 segundos. Concluíram que essa percepção contraditória está ligada aos elementos visuais da página. Em média, os usuários gastam cerca de 4 segundos lendo cada elemento. Este site corporativo oferece vários elementos interessantes do ponto de vista do usuário, dessa forma, após a requisição de uma operação, o usuário gasta vários segundos lendo esses elementos, o que torna a percepção de que o tempo de resposta do site é inferior aos 36 segundos mensurados. Um estudo mais recente publicado por Barber (2007) sugere que acima de 5 a 8 segundos de espera para o usuário já é considerado frustrante, como pode ser visto na tabela 2, e que o tempo considerado típico para o usuário é de 2 a 5 segundos. Tabela 2: Tabela de tempo de resposta de serviços Web. Tempo de Resposta Abaixo de 3 segundos De 2 a 5 segundos Tipico De 5 a 8 segundos Lento De 8 a 15 segundos Frustante Acima de 15 segundos Inaceitável Fonte: BARBER (2007) Comentário Resposta imediata Diante de um cenário subjetivo que depende única e exclusivamente da aplicação Web e do que é esperado da mesma em termos de desempenho, o consenso comum para avaliar o desempenho de uma aplicação é através do tempo

29 29 de resposta e a taxa de processamento da aplicação (MENASCÉ; ALMEIDA, 2003) (ALMEIDA; MENASCÉ; DOWDY, 2004). Além destas duas métricas principais para medição de desempenho, ainda é possível utilizar-se de outras para verificar o desempenho dos serviços na web, sendo elas: a) Tempo de Resposta de ponta a ponta: A soma total do tempo da rede ao tempo de processamento. b) Tempo de Resposta do site: O valor do tempo de espera da requisição do usuário ser completamente atendida. c) Erros por segundo: Qualquer falha no processo de interação com o servidor, como, por exemplo, um estouro na fila de conexões de usuários ignorando todas as requisições que possam ser feitas. d) Visitantes por dia: Demonstra a capacidade atual da aplicação sem degradação do tempo, sendo possível ter o cenário esperado por tempo de desempenho dos serviços prestados. e) Hits: Um único pedido de página pode gerar vários hits, dependendo dos tipos de arquivos incluídos na página HTML solicitada. Uma maneira de determinar qual será a experiência do usuário utilizando os serviços web é através dos testes de desempenho. O objetivo principal de um teste de desempenho é entender qual o desempenho do serviço sob condições de carga de trabalho que reflitam a realidade ou uma projeção da mesma. É importante que estes testes sejam planejados com antecedência e com presença imprescindível da equipe de desenvolvimento, produção e planejamento de capacidade. A chave para obtenção de sucesso nestes tipos de teste é a simulação fiel do ambiente de produção e cenários de carga de trabalho, de modo que os resultados dos testes coincidam com o mundo real da melhor maneira possível e caso a aplicação ainda não esteja disponível ao usuário final já possa ser implantada com a verificação e com o conhecimento dos limites computacionais da mesma. Os testes a serem aplicados devem incluir situações que representam uma atividade típica do sistema e situações de pico, de modo a determinar o comportamento do serviço em ambas às situações. Basicamente podem ser

30 30 definidos três tipos de testes de desempenho caracterizados pela intensidade de carga gerada (MENASCÉ; ALMEIDA, 2003): a) Teste de Carga: É criada uma carga simulada imitando o cenário de demanda típica do sistema, para saber como a aplicação se comporta. b) Teste de esforço: Como o sistema se comporta sob condições extremas (situação atípica), utilizando os cenários de pior caso utilizando a carga mais pesada do que o esperado. Este tipo de teste também é conhecido como Teste de Stress (BARTIÉ, 2002) (MEIER et al., 2007). c) Teste de pico: Testado em condições muito específicas, quando a carga é muitas vezes maior do que a média e em um pequeno espaço de tempo. Este tipo de teste também é conhecido como Spike Test (MEIER et al., 2007). Além destas definições básicas de testes de desempenho, é possível citar testes mais específicos a serem feitos dependendo do resultado esperado pelo usuário (MEIER et al., 2007). a) Capacity Test: Este tipo de teste é destinado para obtenção de resposta sobre qual a capacidade da arquitetura no seu formato original e o quanto é necessário ela crescer dependendo da demanda desejada de usuários. Uma técnica estratégica voltada a determinar um crescimento de arquitetura. b) Component Test: Teste de desempenho voltado a uma única camada da aplicação, cujo objetivo é definir o quanto a mesma isoladamente atende a demanda solicitada e qual o seu tempo de resposta. Teste isolado utilizado para identificação de gargalos específicos da arquitetura. c) Endurance Test: O objetivo deste teste é analisar como a arquitetura se comporta sobre condições contínuas de cargas normais de usuários em um período de tempo superior ao real. A partir do estudo teórico realizado, sobre os tipos de testes de desempenho em suas diferentes nomenclaturas citadas por Menascé (2003) e para os testes de desempenho mais especíifico citados por Meier et al. (2007), obtevese assim, os seguintes tipos. Teste de Carga, Teste de esforço, Teste de Pico, Capacity Test, Component Test, Endurance Test. Ressalta-se que para demonstrar os resultados do relatório gerencial proposto neste trabalho optou-se pelo teste de esforço.

31 31 Assim como nos testes funcionais que possuem um ciclo bem definido dentro da sua etapa de teste, os testes de desempenho também têm uma metodologia definida (MENASCÉ; ALMEIDA, 2003) como pode ser visto na figura 5. Definir objetivos do teste Entender o ambiente Especificar o plano de teste Definir a carga de trabalho do teste Configurar o ambiente de teste Executar os testes Analisar os resultados do teste Figura 5: Uma metodologia para o teste de desempenho. Fonte: MENASCÉ; ALMEIDA (2004) Podem existir diversos tipos de objetivos a se alcançar com um teste de desempenho, alguns exemplos possíveis (MENASCÉ; ALMEIDA, 2003): a) Determinar a capacidade do servidor Web. b) Descobrir o número máximo de usuários simultâneos que um serviço na Web aceita dentro dos limites acordados. c) Determinar a quantidade de requisições simultâneas da camada de aplicação. d) Identificar enfileiramentos na infra-estrutura do serviço Web.

32 32 e) Identificar a degradação do tempo de resposta percebido pelo usuário final ao crescimento das baterias de testes. f) Descobrir a capacidade do servidor de banco de dados. g) Identificar as funções Web que mais oneram a aplicação. Após a definição dos objetivos desejados a atingir com o teste, é necessário ter bem definido qual o ambiente que o mesmo será executado. Nesta etapa do trabalho, busca-se descobrir que tipo de infra-estrutura está rodando a aplicação (informações de servidores, se existe algum serviço terceiro) e quais os softwares envolvidos nesta infra-estrutura (sistemas operacionais, middleware, aplicações, banco de dados). Assim como no teste funcional, é necessário ter definido um plano de teste coerente que busque simular os passos dos usuários na aplicação. Este processo é o mais importante para se ter um resultado que busque atingir a expectativa dos objetivos, pois um cenário mal definido pode apresentar uma execução que não estimule de maneira correta o ambiente (MENASCÉ; ALMEIDA, 2003). Diferentemente dos testes de caixa preta, estes testes buscam englobar apenas cenários cujo final resulte em sucesso e os fluxos mais utilizados pelos usuários, procurando uma distribuição da sua carga de trabalho em percentual de uso e freqüência (BARBER, 2004), como pode ser visto na figura 6. Figura 6: Exemplo de definição de cenário e carga de trabalho. Fonte: BARBER (2004) Após a construção e definição dos cenários juntamente com a sua carga, é necessário efetuar a instrumentação com ferramentas de medição para monitorar cada camada do ambiente enquanto os testes são executados (Servidores Web, Servidores de Aplicação, Sistemas de banco de dados, Sistemas operacionais). Estes testes podem ser executados utilizando dois métodos (MENASCÉ; ALMEIDA, 2003):

33 33 1) Teste Manual: Exigindo a quantidade de mão de obra desejada para obter a quantidade total de requisições definida no objetivo do teste e também uma alta sincronia entre os envolvidos para simular a carga necessária no tempo necessário. 2) Teste Automático: Que utiliza a simulação de usuários virtuais responsáveis em fazer o papel dos usuários reais e são comandados por uma controladora única. Por facilidade, é mais comum a utilização do segundo método para execução destes testes de desempenho, pois o mesmo exige uma equipe reduzida tendo como um único pré-requisito que os envolvidos conheçam os cenários de testes e saibam utilizar a ferramenta que fará a simulação destes usuários virtuais. Ao final da execução dos testes, a última etapa da metodologia é iniciada, com o início da coleta dos dados das ferramentas que monitoram os ambientes e com base nestas informações são feitas as sugestões de melhoria e otimização para todas as camadas do ambiente, onde nem sempre estas sugestões resultam em ampliação de capacidade de processamento de hardware, podendo ser sugestões de otimização de comandos de banco de dados e engenharia baseada em modificações de complexidades algorítmicas de códigos da aplicação. O teste de desempenho é um método comum utilizado para determinar como os usuários experimentarão o desempenho de um serviço na Web, utilizando-se das abordagens específicas para cada tipo de cenário de carga desejado a simular Ferramentas de Apoio a testes de desempenho Com a necessidade de simular os usuários virtuais que representarão os usuários reais, existem diversas ferramentas livres ou pagas que podem atender às necessidades definidas para cenários específicos de testes de desempenho. Estas ferramentas têm como característica comum conter os seguintes itens: a) Requisições: Suporte a diversos tipos de requisições Web que sejam passíveis de parametrização e adequação de maneira customizável, atendendo as necessidades do teste de desempenho.

34 34 b) Controladora de agentes: Um componente específico que permita o controle dos usuários virtuais que serão executados em um ciclo de teste de desempenho. c) Agentes virtuais: Componente parametrizável que execute as requisições previamente programadas pelo software cujo papel será simular o usuário real da aplicação. As ferramentas disponíveis no mercado, tanto software livre quanto pagas, possuem pelo menos estes itens. Podem possuir também componentes a mais que agregam ao cenário da realidade da simulação destes agentes virtuais para um teste de desempenho. O objetivo deste trabalho é apresenta e trabalhar com ferramentas de software livre, porém como existem várias disponíveis no mercado na tabela 3 é apresentado um comparativo entre as mais populares ferramentas do mercado, segundo métricas de maior quantidade de número de downloads do site Opensource (OPENSOURCE, 2011). Pelo fato do grupo ter mais experiência com linguagem de programação Java e por ter suporte técnico necessário em fóruns e listas de discussões, a ferramenta escolhida pelo grupo a ser apresentada é o JMeter. Pelo fato também da ferramenta ter uma interface gráfica, isto facilita no processo de criação de um teste de desempenho podendo inclusive ter a possibilidade de depurar o mesmo em busca de possíveis erros antes de uma execução.

35 35 Tabela 3: Tabela comparativa entre as principais ferramentas de teste de desempenho software livre do mercado. Critério de Avalição Protocolos Funções de Execução Programação em script's Extensibilidade Testes distribuídos Descrição JMeter OpenSTA Webload Protocolos de comunicação que são possíveis simular nas ferramentas Execução do script, facilidade de depuração de um script A possibilidade de manipular os protocolos capturados através de linguagem de script's Possibilidade de aumentar a funcionalidade da ferramenta através de módulos próprios desenvolvidos Possibilidade de executar um teste em diversas máquinas distribuidas dentro de uma rede HTTP,HTTPS, FTP, SOAP/XML- RPC, JMS, JDBC Possui uma interface gráfica permitindo a visualização da execução do script Utiliza linguagem Beanshell/Java Pode ser gerado uma nova versão da aplicação com o desenvolvimento Java de novas telas utilizando SDK do motor Suporta múltiplas máquinas a serem controladas por uma única instância para execução HTTP 1.0 / 1.1 / HTTPS (SSL), SOAP/XML Apenas atráves de log's Linguagem própria chamada "SCL", utiliza o motor da linguagem BASIC Apenas através de script's "SCL" é possível incluilos através importação de aos testes já criados Suporta múltiplas máquinas a serem controladas por uma única instância para execução HTTP/S, WAP, AJAX, ActiveX, Java Apenas atráves de log's Utiliza Javascript Apenas através de Javascript é possível inclui-los através de importação aos testes já criados Não oferece suporte Escalabilidade Possibilidade da ferramenta gerar um número específico de usuários virtuais e gerencia-los de maneira satisfatória a concluir um teste sem oferecer risco de travamento Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Suporte Técnico Fonte: Os autores (2011) Possibilidade de buscar informações e auxilio aos desenvolvedores da ferramenta Fórum próprio de desenvolvedores entusiastas e comunidade Suporte apenas com equipe de criação da ferramenta Suporte apenas com equipe de criação da ferramenta, através de um plano de contrato.

36 36 3 JMETER JMeter é um aplicativo desktop Open Source cujo objetivo principal é testar e medir o desempenho e comportamento funcional de aplicações cliente/servidor, aplicações estas que podem tanto ser Web quanto aplicações FTP (JMETER, 2011). O idealizador e primeiro desenvolvedor desta ferramenta foi Stefano Mazzocchi, do grupo Apache Software Foundation. Nos primórdios a ferramenta tinha o objetivo principal de fazer testes de desempenho no Apache JServ (HALILI, 2008), que mais tarde foi substituído pelo Apache Tomcat. Desde então a comunidade de desenvolvedores entusiastas ao JMeter vem em processo contínuo de desenvolvimento e expansão, adicionando novas funcionalidades para testes de desempenho destinados a servidores FTP, servidores de banco de dados, servidores de aplicação e Servlets Java. 3.1 ARQUITETURA DA FERRAMENTA Desenvolvida na linguagem Java e por ser Open Source, é uma ferramenta altamente extensível a criação de componentes adicionais pela comunidade digital através da sua API (JMETER, 2011). Por ser desenvolvido em Java, o JMeter pode ser utilizado em qualquer sistema operacional que tenha pelo menos uma JVM 1.3. A ferramenta possui uma interface gráfica GUI (Java Swing), que atua como se fosse um cliente de uma arquitetura cliente/servidor, onde estes são simulados no componente denominado grupo de usuários, que por sua vez instanciam a quantidade de processos desejados no container da ferramenta simulando assim requisições reais. Com os cenários criados e executados na ferramenta, é possível medir tempo de resposta e diversos outros componentes de servidores envolvidos no teste como uso de CPU, utilização de memória e utilização de recursos específicos. A interface do usuário é dividida em dois painéis principais. No painel mais a esquerda, como pode ser visto na figura 7, é onde fica a árvore de execução do teste, inicialmente mostrando já dois componentes ao usuário, o item Plano de teste que irá conter todos os passos seguidos para execução de um teste, e a área de trabalho, onde ficam os componentes de apoio para criação de um cenário.

37 37 Figura 7: Tela inicial da ferramenta JMeter. Fonte: Os autores (2011) 3.2 PRINCIPAIS FUNCIONALIDADES Um plano de teste de desempenho típico consiste em pelo menos um grupo de usuários, controladores lógicos, testador, ouvintes, temporizadores, asserções e configurações de ambiente, como podem ser visto na figura 8. Figura 8: Principais elementos de um teste de desempenho. Fonte: Os autores (2011) Cada um destes elementos tem como papel (HALILI, 2008): a) Grupo de Usuários: É neste componente que é definida a quantidade de usuários virtuais que o teste irá simular. É necessário que todos os componentes envolvidos no teste estejam aninhados a este componente. b) Ouvinte: Fornece as informações coletadas pelos testes executados no JMeter.

38 38 c) Configuração de ambiente: Atuam diretamente ao componente Testador. Estas configurações são responsáveis pelo funcionamento real das solicitações de usuários, como por exemplo, configurações de cookies de sessão. d) Controlador lógico: Responsável por agrupar o componente de testador. É nele que pode ser inserida a lógica necessária para tomada de decisões no cenário de teste. e) Temporizador: Componentes que permitem inserir pausa ou atrasos esperados entre as requisições, caso seja necessário. f) Testador: É onde ficam definidos os passos do usuário. g) Asserção: Componente que permite fazer verificações que testam os retornos das requisições feitas, assegurando assim que está de acordo com o esperado. 3.3 SIMULAÇÃO DE USUÁRIOS VIRTUAIS Um dos elementos essenciais do JMeter é o Grupo de usuários. É neste elemento que são feitas as configurações necessárias para simular as múltiplas cargas que estimulam o comportamento do servidor sob condições de testes. É possível com este componente agendar execuções de testes, como pode ser visto na figura 9. Figura 9: Tela de parametrização do componente Grupo de usuários. Fonte: Os autores (2011) Este componente é uma implementação abstrata de uma classe chamada ThreadGroup, como pode ser visto na figura 10, pertencente ao pacote core do

39 39 JMeter, que é a responsável por definir as configurações apresentadas no painel da interface gráfica ao usuário. Figura 10: Diagrama de classes do Grupo de usuários. Fonte: Os autores (2011) Dentro desta classe estão definidos os seguintes objetos: a) RAMP_TIME: Uma variável do tipo String que recebe o valor definido no campo tempo de inicialização. Este tempo é definido pelo usuário de quanto em quanto tempo os usuários virtuais devem entrar para fazer uma execução. b) SCHEDULER: Uma variável do tipo String responsável em instanciar ou não o método se será utilizado, o campo de agendamento pelo teste. c) START_TIME: Variável absoluta do tipo String que recebe o valor da hora de início que o teste foi agendado. d) END_TIME: Variável absoluta do tipo String que recebe o valor da hora de fim que o teste foi agendado. e) DURATION: Variável absoluta do tipo String que recebe o tempo total que a execução agendada deve ser executada. f) DELAY: Variável absoluta do tipo String que recebe o atraso definido para a execução agendada. Já dentro da classe AbstractThreadGroup, tem as implementações dos seguintes objetos:

40 40 a) ON_SAMPLE_ERROR: Variável do tipo String que verifica qual ação a tomar, caso alguma requisição do usuário tenha erro, podendo ser elas: a. ON_SAMPLE_ERROR_CONTINUE: Corresponde ao campo Continuar, caso alguma requisição apresente erro. b. ON_SAMPLE_ERROR_STOPTHREAD: Corresponde ao campo Interromper o usuário virtual, caso alguma requisição apresente erro. c. ON_SAMPLE_ERROR_STOPTEST: Corresponde ao campo Interromper teste, caso alguma requisição apresente erro, aquele cenário especifico é interrompido ao final do mesmo. d. ON_SAMPLE_ERROR_STOPTEST_NOW: Corresponde ao campo Interromper Teste Agora, caso alguma requisição apresente erro, aquele cenário é interrompido no momento. b) NUM_THREADS: Variável do tipo String que é a responsável em criar o número de thread s virtuais que representarão os usuários. c) MAIN_CONTROLLER: Variável do tipo String que cria o componente Grupo de Usuários nas propriedades da arquitetura. 3.4 SIMULAÇÃO DE REQUISIÇÕES Com o elemento grupo de usuários definido em um plano de teste, é necessário que este tenha as requisições que façam realmente o papel de um usuário real. Com o JMeter é possível simular diversos tipos de requisições diferentes (JMETER, 2011), dentre elas: 1) Web HTTP, HTTPS 2) SOAP 3) Banco de dados via JDBC 4) LDAP 5) JMS 6) Mail POP3(S) e IMAP(S) Todas estas requisições ficam agrupadas, como pode ser visto na figura 11, dentro do grupo chamado Testador, que fica disponível sendo um elemento filho na hierarquia de um plano de teste, contido dentro do Grupo de Usuários.

41 41 Figura 11: Requisições agrupadas no elemento Testador. Fonte: Os autores (2011) Internamente, cada protocolo possui uma implementação específica pertinente a cada uma das requisições pertencente ao pacote de códigos \src\protocol\. Estas requisições são utilizadas pelo componente grupo de usuário para simular o protocolo desejado a ser utilizado em um cenário de teste de desempenho. Cada uma das requisições tem os campos específicos que montam uma mensagem de acordo com a sua solicitação. O testador mais comumente utilizado em testes de desempenho é a Requisição HTTP (HALILI, 2008). Este testador é responsável em montar a mensagem destinada a um servidor especificado nos seus campos para simulação de ação do usuário, como pode ser visto na figura 12. Figura 12: Componente Testador do tipo Requisição HTTP. Fonte: Os autores (2011) Cada um dos campos preenchidos é acrescentado à mensagem que é enviada para um servidor. Nem todos os campos são de preenchimento obrigatórios (HALILI, 2008), exceto: a) Nome do servidor ou IP: Caminho único para acesso ao servidor testado

42 42 b) Número da porta: Qual a porta disponível pelo servidor a receber requisições, se esta ficar em branco é adotada a porta padrão 80. c) Método: Neste combo box é possível escolher dentro dos possíveis métodos de requisição a ser montado, sendo dois os principais: a. GET: Ao indicar no cabeçalho da mensagem que a requisição destinada ao servidor é deste tipo, o servidor procura internamente o que a mensagem enviada está procurando e entrega a solicitação ao usuário. b. POST: Caso no cabeçalho da mensagem esteja este método, junto com a mensagem deve haver pelo menos um campo preenchido pelo usuário destinado ao servidor como uma ordem, e o servidor deve responder esta requisição conforme o esperado pelo usuário. d) Enviar parâmetros com a requisição: Caso o campo método seja do tipo POST, é necessário que alguns campos esperados pelo servidor estejam presentes neste campo. É necessário um prévio conhecimento da aplicação para preencher este campo, pois é preciso que seja passado como parâmetro campos com nomes válidos e valores esperados pelo servidor, como pode ser visto na figura 13. Figura 13: Exemplo de campo preenchido para pesquisa no site Google. Fonte: Os autores (2011) 3.5 RELATÓRIOS O JMeter possui uma série de relatórios que auxiliam na análise do resultado de um teste de desempenho ou simplesmente no momento de depuração de um script desenvolvido. Os relatórios do JMeter estão agrupados no componente Ouvinte, que por sua vez colhem informações dos Testadores e apresentam-nas seja como uma

43 43 tabela, um gráfico, uma árvore de execução ou simplesmente em saída texto escrita em um arquivo do tipo log (HALILI, 2008). Cada Ouvinte demonstra as informações coletadas de um modo específico, como por exemplo, a coleta do tempo de resposta de uma página especifica, como pode ser visto na figura 14. Figura 14: Aggregate Graph é um ouvinte disponível para apresentar um gráfico de tempo de resposta de um teste executado. Fonte: JMETER (2011) A coleta feita pelo JMeter para conseguir montar este gráfico pode ser escrita em um arquivo de saída do tipo jtl, uma extensão própria utilizada pela ferramenta que salva as informações contidas na tabela de apoio que é utilizada para montagem do gráfico apresentado. Todos os ouvintes disponibilizados nativamente para o JMeter possuem um campo em comum, que é a opção de configuração de arquivo de escrita, como pode ser visto na figura 15.

44 44 Figura 15: Ao acionar o botão configurar, é possível customizar o tipo de informação escrita no relatório de saída do relatório. Fonte: Os autores (2011) Como a principal funcionalidade do JMeter é simular usuários virtuais e não apresentar relatórios gerenciais gráficos, estes relatórios disponibilizados podem consumir muito recurso computacional da estação que estiver executando a ferramenta, pois estes gráficos são gerados em tempo de execução necessitando uma quantidade alocada de memória física disponibilizada pela máquina virtual que instanciou o JMeter (HALILI, 2008) Métricas geradas Como medir qual o ponto em cada um dos servidores envolvidos em um teste tem o desempenho degrado ou algum gargalo aparece? (HALILI, 2008, p. 68). Com um plano de teste bem equilibrado tendo um crescente número de grupo de usuários virtuais distribuídos de maneira que seja possível verificar o momento de ruptura de desempenho de determinadas funcionalidades. As principais métricas contidas para uma análise simples de tempo de resposta por página consistem em coletas de hit s por páginas e o tempo levado para a resposta de uma solicitação ao servidor (MENASCÉ; ALMEIDA, 2003). Basicamente, é em cima destas duas métricas que o JMeter monta o relatório de tempo de resposta por páginas em tempo de execução. Cada processo disparado pelo grupo de usuários tem um identificador interno que permite o controle das métricas de maneira individual, estes identificadores podem ser vistos no anexo A.

45 45 Tendo estas métricas geradas nativamente pelo JMeter, é comum obter diversos outros relatórios gerados por desenvolvedores entusiastas da ferramenta e disponibilizados para todos no próprio portal de adicionais criados pela comunidade open source (JMETER PLUGIN, 2011). Porém, como citado por Halili (2008), ter um plano de teste com muitos gráficos gerados na ferramenta podem causar um problema de desempenho na própria, mascarando assim resultados ou até mesmo tendo insuficiência de recursos físicos para a execução de um teste. 3.6 MANEIRAS PARA EXECUÇÃO DE UM TESTE Com a criação de um cenário de teste concluída e as monitorações feitas nos servidores envolvidos, tudo já está de acordo para a execução de um cenário de teste de desempenho utilizando o JMeter. O JMeter disponibiliza três maneiras para execução de um teste (JMETER, 2011): 1) Interface gráfica 2) Linha de comando 3) Execução remota Interface gráfica Através da interface gráfica é possível acompanhar a quantidade de processos que estão sendo criados e executados enquanto um teste está em andamento, como pode ser visto na figura 16. Figura 16: Indicador visual que mostra que está em execução 1 processo de 100. Fonte: Os autores (2011) Quando uma execução feita pela interface gráfica é finalizada, o indicador da quantidade de processos criados torna a ficar 0 e sua cor fica novamente cinza, como pode ser visto na figura 17.

46 46 Figura 17: Fim de uma execução de teste. Fonte: Os autores (2011) Os gráficos gerados pelo JMeter só podem ser obtidos com a execução no modo gráfico (JMETER, 2011) Linha de comando Por ter uma interface amigável e de fácil utilização, comumente execuções de testes de desempenho no JMeter são feitas através da sua interface gráfica. Porém, dependendo da quantidade de usuários a serem simuladas, as características físicas da máquina escrava não necessitam atender a demanda tendo, como por exemplo, uma quantidade de memória física disponível para a JVM do JMeter suficiente para a quantidade de processos, caso contrário pode ser afetada a velocidade e a frequência que estes processos são encaminhados ao servidor (HALILI, 2008). Como o JMeter é um aplicativo JAVA, para executar um teste sem utilizar a interface, é necessário invocá-lo através de uma janela de comando informando os parâmetros desejados na linha de comando, como pode ser visto na figura 18. jmeter -n -t meu_teste.jmx -l log.jtl Figura 18: Exemplo de execução de teste utilizando o JMeter. Fonte: JMETER (2011) Onde cada uma das opções corresponde a (JMETER, 2011): -n: Comando específico indicando que o JMeter será executado sem a interface gráfica. -t: Nome do plano de teste criado no JMeter utilizando a interface gráfica. -l: Nome do arquivo de saída que será gerado contendo os resultados da execução.

47 Execução remota É possível executar o JMeter de maneira distribuída, tendo uma instância como nó escravo (servidor JMeter) e suas máquinas que poderão controlar sua execução. Para isso, é necessário que todas as máquinas envolvidas estejam executando a mesma versão de JMeter e preferencialmente com a mesma versão do JAVA instalado (JMETER, 2011), além disso, toda a massa de dados utilizada pelos cenários (como arquivos do tipo csv) devem estar localmente em cada uma das máquinas. Para executar o JMeter no modo remoto, é necessário executá-lo através da instância jmeter-server. Ao executar a instância através deste modo, o JMeter registra uma porta RMI (Remote Method Invocation) dinâmica por onde as máquinas que irão controlá-la possam se comunicar. Com o nó servidor em execução, é necessário efetuar uma parametrização nas máquinas distribuídas. No arquivo de propriedades do JMeter (diretório_instalação/bin/jmeter.properties), no campo remote_hosts deve ser adicionado o IP da máquina servidora que está sendo executada a instância jmeterserver, como pode ser visto na figura 19. Figura 10: Campo parametrizado no arquivo jmeter.properties. Fonte: Os autores (2011) Ao definir neste arquivo que o JMeter terá uma máquina servidora para execução, estará disponível na sua interface gráfica no menu Executar a opção Executar remoto, com o IP do endereço servidor para parametrização, como pode ser visto na figura 20.

48 48 Figura 20: Possibilidade de execução remota de um script. Fonte: Os autores (2011) Este tipo de execução é feita quando a máquina disponibilizada para criação dos scripts não atende a configuração necessária para simulação da quantidade de usuários desejados para um teste mais pesado, podendo assim criar os scripts em uma máquina e executar o teste em outra com maior capacidade de processamento físico (HALILI, 2008).

49 49 4 PLATAFORMA ANDROID É uma plataforma para tecnologia móvel completa, envolvendo um pacote com programa para celular, já com um sistema operacional, middleware, aplicativos e interface do usuário (PEREIRA; SILVA, 2009). O Android foi construído com a intenção de permitir aos desenvolvedores criar aplicações móveis que possam tirar total proveito do que um aparelho portátil possa oferecer. Por ser open source, pode ser sempre adaptado a fim de incorporar novas tecnologias. A plataforma está em constante evolução, já que as comunidades de desenvolvedores estarão trabalhando em conjunto para construir aplicações móveis inovadoras. 4.1 ARQUITETURA DA PLATAFORMA Em Novembro de 2007 o Google anunciou que estava à frente da OHA (Open Handset Alliance) disponibilizando o SDK (Software Development Kit) dias depois. Era esperado que o lançamento de um telefone celular fosse feito, porém foi feito o anúncio de algo mais complexo: Uma plataforma completa para dispositivos móveis batizada de Android. A arquitetura da plataforma Android é dividida em cinco partes fundamentais: Kernel Linux, bibliotecas, ambiente de execução, framework e aplicativo (PEREIRA; SILVA, 2009). A figura 21 ilustra tais camadas conforme a posição em que se encontram. Figura 21: Imagem da arquitetura da plataforma Android. Fonte: PEREIRA, SILVA (2009)

50 50 Cada uma destas camadas presente na figura 21 possui uma funcionalidade específica, sendo elas explicadas nos itens abaixo. a) Applications: Esta camada é destinada a todos os aplicativos fundamentais do Android, todos escritos utilizando a sintaxe Java. Portanto, é nesta camada que os programas criados são executados pela máquina virtual Dalvik. b) Application Framework: nesta camanda se encontram todas as API s e recursos utilizados pelos aplicativos desenvolvidos. Pode ser encontrada como, por exemplo, as classes visuais, listas, grades, caixas de texto, botões, view system (componente responsável para construção de aplicativos) e content provider (componente responsável por uma aplicação acessar informações de outra aplicação). Os principais elementos desta camada são (PEREIRA; SILVA, 2009): a. Activity Manager: É responsável pelo gerenciamento de todas as atividades, quando ela é iniciada e quando é terminada. b. Package Manager: Utilizada pelo activity manager para ler as informações dos pacotes de arquivos Android. O package manager se comunica com o resto do sistema e diz quais os pacotes estão sendo utilizados. c. Window Manager: Responsável por gerenciar as apresentações de janelas. d. Content Providers: Compartilha os dados entre os aparelhos, possibilitando a troca de informações entre os aplicativos. e. View System: Disponibiliza todo o tratamento gráfico para as aplicações. c) Libraries: Esta camada disponibiliza um conjunto de bibliotecas compiladas na linguagem C/C++ utilizadas pelo sistema. Além destas, possui também bibliotecas destinadas a área multimídia, visualização de camadas 2D e 3D, funções específicas para navegadores web, funções de aceleração de hardware, renderização 3D, fontes bitmap e funções de acesso ao banco SQLite. Todos os recursos destas bibliotecas estão disponíveis para o desenvolvimento de aplicativos (MURPHY, 2008). Dentre as principais bibliotecas, é possível destacar (PEREIRA; SILVA, 2009):

51 51 a. Freetype: Renderização de fontes e bitmaps. b. System C Library: Uma implementação derivada da biblioteca C padrão sistema (libc) do tipo Berkeley Software Distribution (BSD). Esta implementação resultou na geração de uma biblioteca desenvolvida exclusiva para o Android, chamada C Bionic. c. Webkit: Biblioteca baseada no código aberto do navegador webkit (WEBKIT, 2011). É nesta API que estão disponíveis os web services embarcados ao Android. Dentro desta biblioteca está disponível o Apache Jakarta Commons HttpClient, que por sua vez permite o acesso direto utilizando a arquitetura do tipo REST (Representational State Transfer) proposta por Fielding (2000), que propõe a utilização de transferências de estados entre o cliente-servidor de maneira bem definida, utilizando sinônimos. d. SQLite: Engine de banco de dados relacional, implementado em C, que dá suporte a base de dados acima de 2 terabytes. e. SGL: Responsável pelos gráficos 2D subjacentes. f. Surface Manager: Responsável por prover o acesso aos subsistemas de exibição, como as camadas 2D e 3D. g. Media Libraries: Uma biblioteca baseada no PacketVideo s OpenCORE (PACKET, 2011), que dão suporte a formatos populares de áudio e vídeo. h. LibWebCore: Bibliotecas específicas destinadas ao navegador Android. i. 3D Libraries: Implementação baseada nas API s do OpenGL ES 1.0 (OPENGL, 2011). d) Android Runtime: Nesta camada contida dentro das Libraries do Android, é onde uma instância da máquina virtual Dalvik, criada para cada aplicação executada no Android, é executada (PEREIRA; ALMEIDA, 2009). A Dalvik (DALVIK, 2011) é uma máquina virtual com melhor desempenho, maior integração com a nova geração de hardware e projetada para executar várias máquinas virtuais paralelamente.

52 52 O Core Libraries inclui um grupo específico de bibliotecas que fornece a maioria das funcionalidades disponíveis nas principais bibliotecas nativas da linguagem Java, como estrutura de dados, acesso a arquivos, acesso a redes e gráficos. e) Linux Kernel: Esta camada atua como abstração entre o hardware e o resto da pilha de software. É utilizado como Kernel Linux a versão 2.6 para serviços centrais do sistema, tais como segurança, gestão de memória, gestão de processos, pilha de protocolos de rede e modelo de drivers. Um dos componentes a se destacar desta camada é o Binder, responsável por obter e enviar para a aplicação requerente a interface de serviço da aplicação requerida, possibilitando assim a comunicação inter-processos. É nesta camada também que se encontra o sistema de gerenciamento de energia do Android, onde um aplicativo requisita o gerenciamento de energia e o driver de energia do kernel passa a checar periodicamente todos os dispositivos que não estão sendo utilizados por aplicações e o desliga. 4.2 CARACTERÍSTICAS DO SISTEMA OPERACIONAL Com o kernel embarcado no Android, o Sistema Operacional possui um Application Framewok que permite o reuso e a substituição de componentes e uma máquina virtual (Dalvik), que é a responsável por executar softwares escritos na linguagem Java e compilada num formato especial de bytecodes. Possui ainda um navegador baseado no Webkit Engine, também usado pelo Safari, um ambiente gráfico e gerenciador de pacotes, biblioteca de compilação 2D e 3D, um banco de dados sendo executado na engine SQLite para armazenar os dados estruturados, suporte para mídias: áudio, vídeo, formatos de imagens (MPEG4, H.264, MP3, AAC, AMR,JPG, PNG e GIF), telefonia GSM, bluetooth, EDGE, 3G e WiFi, câmera, GPS, compasso e acelerômetro.

53 RECURSOS OPERACIONAIS Apesar do Android usar como linguagem de programação nativa Java, em seu sistema operacional não existe uma JVM, mas sim a máquina virtual Dalvik que é otimizada para execuções em dispositivos moveis (LECHETA, 2009). Cada aplicação do Android roda seu próprio processo em uma instância da máquina virtual Dalvik (uma instância especial responsável por criar outras instâncias da JVM). Essa máquina virtual foi escrita para ser rodada eficientemente com múltiplas instâncias e executa arquivos de extensão dex, ainda no formato bytecode desenhado para ocupar menos espaço e carregar rapidamente. Estes arquivos dex e outros recursos como imagem são compactados em um único arquivo com a extensão apk que representa a aplicação final, pronta para ser instalada e finalmente executada. 4.4 APLICATIVOS EXECUTADOS NO ANDROID O Android possui APIs que permitem total modificação por meio de programação do seu conteúdo. Porém, não é necessário sempre utilizar de modificações destas APIs para implementação de softwares, pode-se apenas utilizar o que já está desenvolvida nelas para implementações. As APIs disponibilizadas com maior utilização para o desenvolvimento (PEREIRA; SILVA, 2009) podem ser vistas no Anexo B contido neste documento. Existem quatro elementos da aplicação essenciais para que o sistema Android possa instanciar e executar softwares desenvolvidos, sendo eles (PEREIRA; SILVA, 2009): Activities: É representado por uma tela na aplicação. Possui uma interface composta por Views, consistindo de várias telas que respondem a eventos previamente programados. Cada atividade é uma especialização da classe Activity, que possui um ciclo de vida específico (MURPHY, 2008), que pode ser visto na figura 22.

54 54 Activity Executando OnCreate() OnStart() OnResume() OnPause() OnResume() OnResume() OnStart() OnRestart() Parada *Kill OnStop() Interrompida OnDestroy() *Kill Finalizada Figura 22: Ciclo de vida de uma atividade. Fonte: MURPHY (2008) Quando uma atividade é iniciada, ela é colocada no topo da pilha de atividades e seu estado é modificado para execução. As atividades abaixo que está em execução somente passará para o estado de Executando quando a atividade em execução for finalizada. A responsabilidade de cada método presente no ciclo de vida de uma atividade (PEREIRA; SILVA, 2009) pode ser vista no Anexo C presente neste documento. Cada estado representado na figura 22 tem uma função específica neste ciclo de vida de uma atividade, sendo elas: 1) Executando: Atividade ativa no visor do dispositivo. 2) Parada: Atividade que perdeu o foco para outra atividade, mantém suas informações de estado, porém não interage com o usuário. 3) Interrompida: Caso uma atividade não esteja sendo utilizada pelo usuário, ela mantém as suas informações de estado. 4) Finalizada: O sistema remove a atividade da memória, caso esteja interrompida temporariamente ou estiver parada.

55 55 O sistema pode finalizar as atividades que estiverem no estado Parada ou Interrompida, caso necessite de memória, chamando os métodos OnDestroy() e OnStop() representados como kill na figura 22. a) Services: Todo código que não possui uma interface com o usuário, que são executados em segundo plano e não são interrompidos quando existe uma troca de atividade pelo usuário. Ao contrário do Activity, este elemento possui um ciclo de vida próprio e uma vida curta (PEREIRA; SILVA, 2009), estes são mantidos como um serviço ativo até que seja recebido uma outra ordem. Uma vez conectado com o serviço, pode-se comunicar com este através de uma interface apresentada para o usuário. b) Broadcast Receivers: Este elemento é acionado através de eventos externos, como por exemplo, o acionar de uma ligação telefônica ou quando existem redes disponíveis. c) Content Provider: Quando existe a necessidade de compartilhamento dos dados de uma aplicação com outras aplicações, este é o elemento utilizado, que basicamente compartilha os dados entre os aplicativos. Os elementos activities, services e Broadcast Receivers são ativados por mensagens assíncronas, chamadas Intents, diferentemente dos Content Providers, que são ativados por pedidos de um Content Resolver. Um intent é um objeto que detém o conteúdo de uma mensagem (PEREIRA; SILVA, 2009). Por exemplo, para uma activity, poderia transmitir o pedido de mostrar uma foto, e para um Broadcast, poderia anunciar que a bateria está descarregada.

56 56 5 ELABORAÇÃO DE UM TESTE DE ESFORÇO USANDO O JMETER Este capítulo apresenta os passos necessários para a elaboração de um teste de esforço usando o JMeter. Como o JMeter é uma ferramenta cujo objetivo não é analisar o desempenho de aplicações WEB e sim executar testes de desempenho, neste trabalho propôs-se a criação de um aplicativo para apresentar os resultados de uma execução de testes de desempenho para a plataforma Android. Para o desenvolvimento deste aplicativo, foi necessária a criação de uma arquitetura hipotética de uma loja do tipo e-commerce para ser elaborado um teste de esforço utilizando o JMeter. Para que assim fosse possível ter insumos suficientes para o funcionamento do relatório gerencial desenvolvido para o Android, o JPlotMeter. Portanto, nas próximas seções está descrita de forma sucinta a arquitetura lógica deste portal. 5.1 ANALISANDO A ARQUITETURA EM UM TESTE DE DESEMPENHO As aplicações baseadas na Web normalmente são enquadradas em uma arquitetura de três camadas. A primeira camada nesta arquitetura, também chamada de apresentação, incorpora a interface de usuário com os serviços na Web. É nesta camada onde o usuário final preenche as informações que serão inseridas na aplicação. Na camada seguinte, onde estas informações preenchidas são processadas, é chamada de camada do negócio ou camada de aplicação. É nesta que estão encapsuladas uma coleção de regras para implementar a lógica da aplicação. Finalmente, os dados solicitados por este servidor de aplicação são processados por um servidor de banco de dados, onde são consistidas as informações de negócio. Esta distribuição das camadas pode ser vista na figura 23. Figura 23: Arquitetura típica de um Web Site de múltiplas camadas. Fonte: Os Autores (2011)

57 57 Neste trabalho utiliza-se uma aplicação baseada na arquitetura típica de um e-commerce, o JPetStore (JPETSTORE, 2011). O JPetStore é uma loja virtual cujo objetivo é efetuar vendas de animais pela internet, armazenando as informações em um banco de dados. Esta aplicação foi proposta originalmente pela Sun como uma loja virtual que utiliza conceitos do Java EE. Nos próximos itens, é abordado como cada um destes serviços dispostos na arquitetura proposta foram implementados Camada WEB O software do servidor WEB, também conhecido como servidor HTTP, é um programa que controla o fluxo de dados recebido e emitido em um computador conectado a uma intranet ou à internet. (MENASCÉ, ALMEIDA, 2003, p. 117). Esta é a camada responsável em atender os pedidos HTTP que são enviados pelos clientes através da rede. O servidor estabelece a conexão solicitada entre o cliente e ele mesmo, envia as informações solicitadas e retorna ao modo de escuta. Para agilizar este processo de pedidos, os servidores WEB tratam mais de um pedido por vez. Estes servidores WEB fazem mais do que enviar apenas páginas HTML. Um site ganha dinamismo oferecendo interatividade e efeitos especiais, utilizando programas instalados no cliente, como por exemplo Java, ActiveX e Dynamic HTML. Com estes programas instalados do lado do cliente, o tempo de resposta de requisições ao servidor pode diminuir, pois evita o uso de rede e possíveis atrasos no servidor. Os servidores WEB convencionais normalmente rodam no espaço do usuário, tornando as trocas de contexto necessárias para cada operação de I/O de disco pelo servidor. Na arquitetura do JPetStore o servidor WEB adotado para fazer a apresentação das páginas ao usuário é o Apache HTTP Server Camada de Aplicação Um servidor de aplicação é o software que trata de todas as operações da aplicação entre os clientes baseados em um navegador e o banco de dados. Nesta camada, as solicitações são feitas à camada WEB.

58 58 O objetivo do servidor de aplicação é disponibilizar uma aplicação desenvolvida sem que a mesma esteja exposta diretamente a rede. Com isso, assim que é concluida uma aplicação a mesma é instalada dentro deste servidor de aplicação para que seja possível usuários externos acessa-la. O JPetStore foi idealizado para utilizar o padrão de desenvolvimento Java EE, cujo diferencial para o Java SE é que este é tolerante a falhas em sistemas desenvolvidos multi-camadas e utiliza de bibliotecas específicas para este tipo de tráfego de informação. Portanto, para ter o motor de negócio do JPetStore funcionando, a aplicação foi instalada no servidor de aplicação chamado GlassFish Camada de Dados É nesta camada que as solicitações feitas à camada WEB são consistidas, caso seja assim esperado. Um servidor de banco de dados executa e gerencia aplicações de processamento de transação. Ele pode ser um sistema de banco de dados relacional, que dá suporte a procedimentos armazenados, que pode emitir pedidos SQL ao banco de dados. Estes servidores de gerenciamento de dados devem garantir que os dados permaneçam integros por todo o ambiente distribuído, através do uso de recursos como bloqueio de dados, coerência e replicação. Para consistir nas transações efetuadas no JPetStore, o sistema de gerenciamento de banco de dados escolhido foi o MySQL. A modelagem deste banco de dados pode ser vista no Apêndice A. 5.2 ESCOLHA DE UM TESTE DE DESEMPENHO Para que fosse possível potencializar a demonstração do relatório de tempo médio de resposta por página desenvolvido para o Android, foi escolhido o teste de esforço, que é o tipo de teste de desempenho que oferece maiores insumos para visualização da degradação de utilização dos recursos computacionais. Para a criação de um ciclo de teste de esforço, inicialmente é necessário mapear as funcionalidades da aplicação que se deseja aplicar o teste. Assim que as funcionalidades são mapeadas é necessário também que se tenha um histórico de utilização das mesmas para que seja possível mensurar a criação da carga que será

59 59 utilizada em uma bateria de testes, assim como as informações necessárias a serem utilizadas pelos agentes virtuais que simularam os testes. 5.3 CRIAÇÃO DE UM CASO DE TESTE DE DESEMPENHO Com a fundamentação teórica proposta por Meyer levantada neste trabalho, foram definidos dois casos de teste de desempenho, utilizando duas funcionalidades da aplicação. A primeira refere-se ao fluxo de compra de um animal e a segunda, à pesquisa de um animal. Estes fluxos funcionais estão representados na forma de um caso de teste nas tabelas 4 e 5. Tabela 4: Caso de teste da funcionalidade de compra de um animal. Título: Compra com sucesso de um animal Objetivo: Efetuar a compra de um animal qualquer no site JPetStore recebendo a mensagem do sistema de procedimento efetuado com sucesso. Pré-Condição: Estar logado na aplicação com um usuário registrado no aplicativo JPetStore Pós-Condição: Ter feito a compra do animal com sucesso PASSOS RESULTADOS ESPERADOS 1. Entre no site da aplicação; 1. Deverá abrir a página home da aplicação. 2. Clique em Sign in ; 2. Deverá retornar ao usuário dois campos para efeutar login na aplicação. 3. Informe no campo Username e password informações válidas e clique em Login ; 3. Deverá abrir a página home da aplicação com a opção Sign Out e My Account aparecendo no banner da página. 4. Ao lado esquerdo da página, escolha uma das 4. Ao clicar em uma das categorias, deverá categorias dos animais disponíveis (Fish, Dogs, retornar ao usuário uma outra página contendo Cats, Reptiles, Birds); os animais disponiveis naquela categoria. 5. Clique em um dos animais presentes na lista; 5. Deverá ser listado os tipos de animais 6. Clique em um dos animais listados para ver o detalhe do mesmo; disponíveis para aquela categoria. 6. Deverá retornar ao usuário detalhes do animal selecionado, inclusive listando a quantidade do mesmo em estoque. 7. Clique em Add to cart ; 7. Deverá retornar ao usuário a página Shopping Cart com a quantidade total de pedidos feito pelo mesmo. 8. Clique em Proced to Checkout ; 8. Deverá retornar ao usuário a página Checkout Summary contendo as informações do pedido do usuário. 9. Clique em Continue ; 9. Será listado ao usuário os seus dados pessoais de cadastro. 10. Clique em Continue ; 10. Será apresentado ao usuário um resumo da transação, contendo o endereço de cobrança e de entrega. 11. Clique em Confirm ; 11. Deverá retornar ao usuário a mensagem Thank you, your order has been submitted Clique em Sign Out ; 12. Fim do caso de teste. Fonte: Os autores (2011)

60 60 Tabela 5: Caso de teste da funcionalidade de pesquisa de um animal Título: Pesquisa com sucesso de um animal Objetivo: Efetuar a pesquisa de um animal qualquer no site informando sua categoria. Pré-Condição: Ter acesso ao aplicativo JPetStore Pós-Condição: Ter feito a pesquisa de um animal pela sua categoria com sucesso PASSOS RESULTADOS ESPERADOS 1. Entre no site da aplicação; 1. Deverá abrir a página home da aplicação. 2. Informe no campo de texto ao lado do botão 2. Deverá retornar ao usuário todos os animais Search uma das categorias de animais presentes na categoria informada. disponíveis e clique no botão Search ; 3. Clique em um dos animais retornados para 3. Deverá retornar as informações do animal. ver o seu detalhe; 4. Volte a página inicial da aplicação clicando no logo presente no banner; Fonte: Os autores (2011) 4. Deverá retornar a página inicial da aplicação. Fim do caso de teste. Estes casos de teste propostos devem refletir os passos que o usuário virtual realizará na execução do teste de esforço. Para isto, as inserções HTTP para cada passo proposto no caso teste da navegação do usuário são desenvolvidas no JMeter, obtendo como resultado final um plano de teste que pode ser visto na figura Figura 24: Caso de teste para efetuar uma compra com sucesso desenvolvido para o JMeter. Fonte: Os Autores (2011)

61 61 Para execução deste teste de desempenho no cenário hipotético proposto, tomou-se como premissa que a aplicação suporta em pico, 100 usuários simultâneos, isto significa que a aplicação está em 100% de utilização do site ao atingir esta quantidade de usuários simultâneos. De base nesta informação, foi criada uma pirâmide de usuários, que pode ser vista na figura 25, que demonstra a quantidade de usuários para os ciclos de testes que foram executados. Acima de 100 usuários, o conceito do teste de esforço já está agindo sobre a aplicação, conforme definição deste conceito de teste apresentado no capítulo 2 (seção 2.4.2), chegando a base da pirâmide com até 400% a mais da carga esperada pelo site. Figura 25: Pirâmide de usuários simultâneos utilizando o JPetStore. Fonte: Os Autores (2011) Para cada nível da pirâmide executado, devem ser definidos os parâmetros de tempo de duração da bateria e quantidade de usuários que devem estar concorrendo simultaneamente por ciclo. Na figura 26 estes atributos estão definidos para o teste hipotético em questão, onde cada ciclo tem o tempo de 5 minutos de execução e todos os usuários concorrem simultâneamente desde o instante segundo 0.

62 62 Figura 26: Atributos definidos para o caso de teste no JMeter. Fonte: Os Autores (2011) Como serão dois cenários envolvidos nesta execução, cada cenário tem um peso específico para a quantidade de usuários utilizando a aplicação, sendo necessário definir a carga de usuário conforme definido no capítulo 2 (seção 2.4.2). Na figura 27 pode ser visto o percentual da execução no portal JPetStore para cada um dos níveis da pirâmide de usuários. Figura 27: Distribuição de usuários simultâneos utilizando o JPetStore. Fonte: Os Autores (2011) Tendo definido os casos de testes, a criação do script que simulará um usuário real, a quantidade de usuário que executará este script e o percentual de carga por funcionalidade, pode-se considerar finalizada a parte da criação de um teste de desempenho. A aplicação foi instalada em um único servidor, cuja configuração de hardware do mesmo pode ser vista no Apêndice B deste documento. A previsão de duração do tempo da execução do ciclo de teste completo era de 45 minutos, já que o objetivo proposto era de executar os 9 níveis presentes na

63 63 pirâmide de usuários, conforme na figura 25. Porém no nível 7 da pirâmide, cujo total de usuário simultâneos era de 225 o que representa 125% a mais de carga esperada pela aplicação a execução foi encerrada, pois o servidor apresentou um alto consumo de CPU. Como o objetivo deste trabalho não é mensurar o desempenho do hardware e sim demonstrar a utilização do aplicativo JPlotMeter desenvolvido para o Android, foi decidido que com a execução realizada já se possuia informações suficientes. No Apêndice C presente neste documento, é possível visualizar um trecho do log obtido no JMeter com informações do ínicio da execução do teste de esforço e o instante final da mesma.

64 64 6 JPLOTMETER: UM RELATÓRIO GERENCIAL PARA O ANDROID Este capítulo apresenta como foi desenvolvida a arquitetura da solução proposta, quais foram as métricas coletadas do teste executado no JMeter e a integração do aplicativo desenvolvido para o sistema operacional Android consumindo estas informações para construção do gráfico gerencial. 6.1 ARQUITETURA DA SOLUÇÃO Os resultados das execuções dos testes feitos no JMeter armazenados em uma tabela temporária criada para o JPlotMeter são processados e expostos por um webservice para que o aplicativo no Android pudesse receber estas informações e gerar o gráfico. Um desenho técnico da aplicação pode ser visto na figura 28. Figura 28: Desenho técnico da solução JPlotMeter. Fonte: Os Autores (2011) No servidor com o JPlotmeter foram desenvolvidas quatro classes, dentre elas a AppService, HandleReturn, ConnectionMySql e a JaxWsImpl, como poder ser visto no diagrama de classes apresentado na figura 29. A classe AppService é responsável em fornecer a informação já tratada para o aplicativo no Android, onde o método consulta através de uma conexão JDBC uma tabela simples criada no MySQL, e trata as informações coletadas retornando insumo suficiente para atender a necessidade de gerar o gráfico referente ao tempo médio de resposta por ciclo de teste executado. A estrutura e script de criação do banco de dados podem ser vistas no Apêndice D.

65 65 Figura 29: Diagrama de classe servidor de aplicações. Fonte: Os Autores (2011) Para um melhor entendimento em relação à interação do usuário com o aplicativo, o diagrama de casos de uso foi elaborado, como pode ser visto na figura 30. Na tabela 6, apresenta-se a interação do usuário com o aplicativo que é bem simples. O usuário precisa ter o aplicativo JPlotMeter instalado no seu dispositivo móvel com Android. Em seguida, abrir o aplicativo que o mesmo se encarregará de mostrar o gráfico gerencial de tempo médio de resposta na tela do dispositivo. Figura 30: Diagrama de caso de uso. Fonte: Os Autores (2011)

66 66 Tabela 6: Descrição do caso de Uso Consultar desempenho do site DETALHES Nome do Caso de Uso UC1 Consulta desempenho do site Versão 1.0 Autor Os Autores Criado em: 06/10/2011 Notas: O aplicativo deverá disponibilizar, um gráfico gerencial com a análise do tempo de resposta do site ecommerce JPetStore. O aplicativo deverá disponibilizar um botão para poder atualizar os dados mostrados no gráfico. Fluxos: Fluxo Básico E01 Erro de conexão Fonte: Os autores (2011) Notas 1. O usuário abre o aplicativo JPlotMeter do seu aparelho móvel. 2. O aplicativo apresenta o gráfico gerencial. 3. Fim do Caso de uso. 1. O usuário abre o aplicativo JPlotMeter do seu aparelho móvel. 2. O aplicativo não consegue conexão com o webservice no lado do servidor, apresentando a seguinte mensagem: Verifique a conexão com o servidor. 3. Fim do Caso de uso. Tipo Fluxo Básico Fluxo de Excessão 6.2 MÉTRICAS COLETADAS DO JMETER PARA GERAÇÃO DO GRÁFICO Conforme fundamentado no capítulo 3, a cada usuário simulado pelo JMeter é gerado uma série de informações sobre a sua execução. Para o protótipo de relatório gerencial JPlotMeter, apenas três destas métricas foram necessárias: 1. Time Taken: Representa o tempo de espera desde uma solicitação do usuário ao servidor até o retorno; 2. Time Stamp: O carimbo contendo data e horário da solicitação do usuário; 3. CSIUri: É o rótulo da URL solicitada pelo usuário. Estas métricas foram armazenadas em uma tabela histórica e transitadas pela aplicação do lado do servidor para aplicação presente na plataforma Android, gerando assim a criação do gráfico representativo do tempo médio de resposta de cada uma das páginas. Para que fosse possível ter informações suficientes para a demonstração do funcionamento do relatório, foram programadas para que a cada 5 minutos de uma bateria fosse executado a pirâmide de usuários hipotética apresentada no capítulo 5

67 67 (seção 5.3), totalizando um período de 45 minutos de coletas armazenadas no banco de dados. 6.3 INTEGRAÇÃO COM O SISTEMA OPERACIONAL ANDROID Para que fosse possível representar as informações coletadas a cada ciclo de execução no JMeter de maneira visual, foi desenvolvido o aplicativo JPlotMeter para o Android. Este aplicativo consiste em duas classes, que podem ser vistas no diagrama de classes na figura 31. A classe LerArquivo é a responsável por consumir as informações do aplicativo no lado do servidor e a classe JPlotMeter é a responsável em tratar as informações e gerar o gráfico em tempo real. Para que o gráfico fosse montado de maneira padronizada, optou-se por utilizar uma API disponível para criação de gráficos, chamada jjoe64 (JJOE64, 2011). Esta API possui métodos já implementados, que recebem valores númericos e textuais para construção do gráfico, seja ele do tipo linha ou do tipo barra. Para uma melhor representação do tempo de resposta das páginas, foi utilizado o gráfico de tipo linha. Figura 31: Diagrama de classes do aplicativo JPlotMeter. Fonte: Os Autores (2011) Ao consumir as informações do lado do servidor, o aplicativo trata estas como um arquivo CSV, que nada mais é do que um texto cujo os valores são separados por algum delimitador, no caso o delimitador é a vírgula. A partir destas informações recebidas, o Time Taken é o responsável em gerar o eixo vertical que é a média de tempo de resposta em segundos e o eixo horizontal é gerado através do Time Stamp, que é a linha temporal da execução, como pode ser visto no gráfico 1.

68 68 Gráfico 1: Demonstração dos eixos do JPlotMeter. Fonte: Os Autores (2011) Cada uma das estátiscas de acesso realizada pela execução no JMeter é armazenada no banco de dados da aplicação pelo lado do servidor com seu respectivo identificador, representado na tabela pela coluna CSIUri. Este campo no gráfico gerado é a legenda, como pode ser visto no gráfico 2, sendo possível assim verificar a variação do tempo de resposta ao longo do tempo da execução, sendo que o somatório do tempo médio de resposta das páginas na última bateria executada se aproximou a 150 segundos de duração. Gráfico 2: Demonstração das legendas no JPlotMeter. Fonte: Os Autores (2011)