Universidade Estadual de Maringá Departamento de Informática Curso de Especialização em Desenvolvimento de Sistemas para Web

Transcrição

1 Universidade Estadual de Maringá Departamento de Informática Curso de Especialização em Desenvolvimento de Sistemas para Web Estudo da Ferramenta Selenium IDE para Testes Automatizados de Aplicações Web Diego Varussa Pereira TCC-2012 Maringá - Paraná 2012

2 Universidade Estadual de Maringá Departamento de Informática Curso de Especialização em Desenvolvimento de Sistemas para Web Estudo da Ferramenta Selenium IDE para Testes Automatizados de Aplicações Web Diego Varussa Pereira TCC-2012 Trabalho de Conclusão de Curso apresentado ao Departamento de Informática, do Curso de Especialização, da Universidade Estadual de Maringá. Orientador: Prof. Ms. Flávio Rogério Uber Maringá - Paraná 2012 i

3 Diego Varussa Pereira ESTUDO DA FERRAMENTA SELENIUM IDE PARA TESTES AUTOMATIZADOS DE APLICAÇÕES WEB Projeto de Monografia apresentado como requisito parcial para a aprovação no curso de Pós Graduação em Desenvolvimento de Sistemas para Web da Universidade Estadual de Maringá, pela Banca Examinadora formada pelos seguintes membros: Orientador: Prof. Ms. Flávio Rogério Uber Departamento de Informática, CTC, DIN Prof. Ms. Munif Gebara Junior Departamento de Informática, CTC, DIN Prof. Dr. Dante Alves Medeiros Filho Departamento de Informática, CTC, DIN Maringá - Paraná 2012 ii

4 Agradecimentos Agradeço a Deus, por mais do que me criar, deu propósito à minha vida. Vem dele tudo o que sou, o que tenho e o que espero. Aos meus pais Valdir José Pereira e Assunta Donizeti Varussa Pereira pela educação dada, incentivo e esforços realizados para que eu chegasse a esta etapa da minha vida. Aos meus irmãos e demais familiares por todo suporte oferecido. Aos colegas e amigos por todas as contribuições tanto diretas quanto indiretas para a construção deste trabalho. Ao Prof. Flávio Rogério Uber pela orientação e ajuda na elaboração e execução do Projeto Monográfico. A todos, os meus sinceros e profundos agradecimentos. iii

5 Resumo A necessidade de desenvolver software com qualidade é de fundamental importância no mercado atual, onde a evolução nesse setor ocorre de maneira extremamente rápida. A prática de testes em software é uma etapa dentro do processo de desenvolvimento de software que objetiva detectar eventuais falhas antes que o produto chegue ao cliente, sendo um elemento crucial para que o produto atenda suas expectativas. Este trabalho visa demonstrar que a utilização de testes automáticos com a ferramenta Selenium IDE permite diminuir o tempo gasto no desenvolvimento e manutenção de aplicações web. Palavras chaves Testes de software; Teste de Regressão; Aplicação Web; iv

6 Abstract The necessity to develop high quality software is of paramount importance for the current market, where developments in this sector occur extremely fast. The practice of software testing is a step in the process of software development which aims to detect faults before the product reaches the customer, being a crucial element in order to be sure that the product meets its expectations. This paper demonstrates that the use of automated testing with Selenium IDE tool allows to reduce the time spent in the development and maintenance of web applications. Keywords Software testing; Regression Testing; Web application. v

7 Índice 1. Revisão Bibliográfica Engenharia de Software Teste em software Tipos de testes Níveis de testes Técnicas de testes Automação de testes Selenium Escolha da Ferramenta Plataformas Screenshot Características Suporte Requisitos Mínimos Diferencial Limitações da Ferramenta Recursos Selenium IDE Selenium RC (Remote-Control) Selenium WebDrive Selenium GRID Utilização da Ferramenta Selenium IDE Processos Realizados Ambiente de Execução Sistema Utilizado Elaboração dos Testes Resultados Obtidos Gerenciamento de Falhas Conclusão Referências Bibliográficas Referências Consultadas vi

8 Índice de Tabelas Tabela 1 Classificação dos níveis de testes Tabela 2 Técnicas de testes aplicadas por nível de teste Tabela 3 Testes manuais vs. testes automatizados Tabela 4 Características do Selenium Tabela 5 Dados dos casos de teste Tabela 6 Tempo de testes manuais vs. testes automatizados vii

9 Índice de Figuras Figura 1 Screenshot da ferramenta Selenium Figura 2 URL Base Figura 3 Barra de Fast Slow Figura 4 Botões de manipulação dos testes Figura 5 Botão de gravação das ações executadas Figura 6 Abas tabela e código-fonte Figura 7 Comandos Figura 8 Campos de interação Figura 9 Área de informações Figura 10 Casos de teste Figura 11 Casos de teste gerados pela ferramenta Figura 12 Plugin para captura de tela quando houver erro Figura 13 Screenshot de erro gerada pelo plugin viii

10 Introdução A necessidade da informatização dos dados e de se aperfeiçoar os serviços de controle dentro das empresas, aumenta o índice de empresas e organizações que estão recorrendo à utilização de softwares. Nos processos de desenvolvimento de software, a prática de testes exerce um papel de extrema importância quando integrado desde o início nas fases de desenvolvimento do software. A redução de custos de desenvolvimento e manutenção são alguns dos benefícios dessa etapa, porém pode-se destacar o aumento de falhas encontradas no sistema antes de chegar aos clientes, pois a escala de uma falha em um sistema que controla uma empresa podem ser imensa. Como a aplicação de testes de maneira manual é muito trabalhosa, muitas vezes sendo mal estruturada, há a necessidade de se empregar ferramentas ao apoio nas atividades de teste. São inúmeras as ferramentas de testes gratuitas ou pagas, simples ou complexas, cada uma com suas particularidades. O projeto limita-se a realizar testes automatizados utilizando a ferramenta Selenium IDE para verificar se utilizando a mesma pode-se reduzir o tempo de desenvolvimento e manutenção de aplicações web. E para conseguir esse objetivo os seguintes passos foram seguidos: Estudo da documentação oficial da ferramenta Selenium IDE; Elaboração de testes com a ferramenta; Analise dos resultados obtidos; 1

11 1. Revisão Bibliográfica Serão descritos os conceitos de engenharia de software, além de um detalhamento dos tipos, técnicas e níveis de testes de software. 1.1 Engenharia de Software Pressman (2006) se baseia na definição de Fritz Bauer (1969). Bauer dizia que a Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais. Ainda Pressman (2006) afirma que os métodos da engenharia de software detalham como construir o sistema, destacando as tarefas como: planejamento e estimativa de projeto, análise de requisitos de software, projeto da estrutura de dados, arquitetura de programa, codificação, testes e manutenção. Para Sommerville (2007), a engenharia de software é uma disciplina da engenharia, que surgiu da necessidade de técnicas e métodos para controlar a complexidade inerente aos grandes sistemas de software, cujo objetivo é o desenvolvimento de sistemas de software com boa relação custo-benefício. Por fim Rocha (2001), afirma que a engenharia de software pode ser vista de forma objetiva, como o estabelecimento e o uso dos princípios básicos da engenharia, com a finalidade de desenvolver software de maneira sistemática e econômica, resultando em um produto confiável e eficiente. Ela abrange um conjunto de três elementos fundamentais: métodos, ferramentas e procedimentos, que possibilitam o controle do processo de desenvolvimento do software e oferece uma base para construção de software de alta qualidade. 1.2 Teste em software Pressman (2006) define três objetivos dos testes com base em Fritz Bauer (1990). O primeiro é definido que a atividade de teste é o processo de executar um programa com intenção de descobrir um erro. Outra definição diz que um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto. O último 2

12 objetivo é definido como um teste bem-sucedido é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.. De acordo com Masiero et al. (2006): A importância da realização de testes deve-se ao fato das outras atividades que fornecem uma garantia de qualidade de software serem insuficientes para a descoberta dos erros introduzidos ao longo do desenvolvimento do software. Apesar de ser impossível provar que um software está absolutamente correto por meio de testes, a sua utilização fornece evidências da conformidade com as funcionalidades especificadas. Além disso, uma atividade de teste conduzida de forma sistemática e criteriosa auxilia no entendimento dos artefatos testados e evidencia as características mínimas do ponto de vista da qualidade do software. Segundo Myers (2004), o custo da correção de defeitos tende a subir quanto mais tarde o mesmo é encontrado, isto é, a etapa de testes deve ser realizada desde as primeiras fases do ciclo de desenvolvimento do software, garantindo dessa forma que os custos evidenciados pelos erros encontrados sejam minimizados. Rex Black (1999), afirmava que o defeito tinha seu custo aumentado em uma proporção de 10 para cada fase passada, então o quanto antes o defeito é encontrado, mais barato será o custo desta correção. Algumas etapas são fundamentais para a realização dos testes. Podemos citar duas delas que influenciam diretamente para o sucesso dos testes: a estratégia e planejamento dos testes. A estratégia dos testes segundo Caetano (2010) é onde se define quais tipos de testes devem ser testados, quais técnicas serão utilizadas e em quais níveis serão testados. Algumas atividades são realizadas nessa etapa: Avaliar requisitos do sistema. Identificar e analisar riscos para o negócio. Analisar as possibilidades de testes para minimizar os riscos. Estabelecer os tipos e técnicas de teste a serem realizados. Definir prioridades para os testes. Estabelecer quais produtos serão inspecionados. 3

13 A outra etapa, o planejamento dos testes, é definida por Caetano (2010) como etapa que descreve todos os testes requeridos, os recursos e os prazos necessários para realizá-los. O plano de teste deve estar alinhado com a estratégia de testes. As atividades realizadas para o desenvolvimento do plano de teste são: Definir os objetivos dos testes, os dados para realizá-los, os procedimentos de teste, critérios de aceitação / rejeição, necessidade de revisão técnica. Estimar esforço necessário. Definir Infra-estrutura (hardware /software/ferramenta) a ser utilizada. Identificar a mensuração do sistema a ser testado. Os testes podem ser classificados em diversas formas, abaixo serão detalhadas essas classificações por tipos, níveis e técnicas: Tipos de testes Peters et al. (2001) se baseia na definição de Coward (1997) para classificar as diversas formas de testes. Coward (1997) separa o teste em dois grupos, o teste de caixa preta e teste de caixa branca. O teste de caixa preta, também chamado de teste funcional que tem como foco avaliar o comportamento externo do programa sem se preocupar com código fonte. O objetivo desse teste é fornecer uma entrada e analisar se a saída é a esperada. Esse teste enfatiza as entradas, saídas e princípios funcionais de um módulo de software. Segundo Pressman (2006), o teste de caixa preta possibilita que o engenheiro de software derive conjuntos de condições de entrada que exercitem completamente todos os requisitos funcionais para um programa. Pressman (2006) diz que esse teste tem como finalidade descobrir erros de funções incorretas ou ausentes, erros de interface, erros nas estruturas de dados ou no acesso a banco de dados externos, erros de desempenho e erros de inicialização e término. Já o teste de caixa branca, também chamado de teste estrutural, é definido segundo Coward (1997), como teste que trata da estrutura de código para um módulo de software, e enfatiza o projeto detalhado do software em vez das funções (caixas pretas). O foco desse teste é técnico, visando que o programa funcione de forma estruturalmente correta e o objetivo está em realizar testes se baseando no código fonte. Segundo Pressman (2006) usando métodos de teste 4

14 de caixa branca, o engenheiro de testes pode derivar os casos de teste que (1) garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez; (2) exercitem todas as decisões lógicas para valores falsos ou verdadeiros; (3) executem todos os laços em suas fronteiras e dentro de seus limites operacionais; (4) exercitem as estruturas de dados internas para garantir a sua validade Níveis de testes O teste de software é executado em níveis distintos por todo o ciclo de vida de um software. Peters et al. (2001) classificam os níveis de testes segundo a Tabela 1. Teste Definição Objetivo Rastreabilidade Verificar a Garantir que a Rastrear cada teste implementação do lógica do programa em relação ao Componente ou Unidade projeto de um elemento de software (ex: esteja completa e correta. Garantir que o componente projeto detalhado função, módulo). trabalhe conforme projetado. Elementos de Garantir que os Rastrear cada teste hardware e objetivos do em relação ao software são projeto são projeto de alto Integração combinados e satisfeitos. nível. testados até todo o sistema estar integrado. Teste de integração Garantir que o Rastrear o teste Sistema de todo o hardware software como uma para verificação e software. entidade completa dos requisitos do 5

15 esteja de acordo sistema. com os requisitos operacionais correspondentes. Determinar se os Garantir que os Rastrear cada teste resultados do teste objetivos dos para verificação satisfazem aos participantes dos requisitos dos Aceitação critérios de aceitação dos estejam satisfeitos. participantes. participantes do sistema de software. Tabela 1 Classificação dos níveis de testes. As principais características de cada nível são apresentadas segundo Caetano (2010) da seguinte forma: Nível de componente ou unidade: Testes realizados em uma unidade independente do produto. Estágio mais baixo da escala de teste. Aplicado nos menores componentes de código criados, visando garantir que estes atendem às especificações funcionais e de arquitetura. Geralmente realizado pelo desenvolvedor que construiu a unidade. Nível de integração: Testes realizados ao término de cada iteração. Em um ambiente operacional controlado. Objetiva validar a exatidão e perfeição na execução de suas funções, referentes aos casos de uso da iteração. 6

16 Normalmente feito pelo analista de sistemas para um módulo ou conjunto de programas. Nível de sistema: Testes realizados em um sistema como um todo. Dentro de um ambiente operacional controlado. Para validar a exatidão e perfeição na execução de suas funções, acompanhando cenários sistêmicos elaborados pelo profissional de requisitos do projeto. Normalmente feito pelo analista de testes em ambiente de testes. Nível de aceitação: Verifica se o sistema tem condições de ser colocado em produção, com base nos seus critérios de aceitação. É a última ação de teste antes da implantação do software, sendo de responsabilidade do cliente. Objetiva verificar se o software está pronto e pode ser usado por usuários finais para executar as funções e tarefas para as quais foi construído. Normalmente feito pelo usuário em ambiente de homologação Técnicas de testes São inúmeras as técnicas de testes, e cada técnica pode ser aplicada em vários dos níveis de testes. De acordo com a classificação de Pressman (2006), foi construída uma tabela que mostra a relação das técnicas de testes aplicadas por nível de testes, como pode ser observado na Tabela 2: Unidade Integração Sistema Aceitação Teste da Fumaça X Teste de Carga X X Teste de Configuração X Teste de Contenção X X Teste de Desempenho X X Teste de Estresse X X Teste de Estrutura X X X Teste de Instalação X 7

17 Teste de Integridade X Teste de Interface X Teste de Regressão X X Teste de Segurança X X Teste de Volume X X Teste Funcional X X X Teste Unitário X Tabela 2 Técnicas de testes aplicadas por nível de teste. Já Bastos et al. (2007) classificam as técnicas apresentadas na Tabela 2 de acordo com o FURPS. A sigla FURPS é derivada das palavras inglesas funcionability, usability, reliability, performance e suportability e é definida por Grady e Caswell (1987) como modelos da qualidade de software. Esses modelos são: funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade. A seguir será apresentada essa classificação para cada modelo do FURPS segundo Bastos et al. (2007) e um detalhamento de cada técnica apresentada: Funcionalidade (Funcionability) Pressman (2006) define o modelo funcionalidade avaliando-se o conjunto de características e as capacidades do programa, a generalidade das funções que são entregues e a segurança do sistema Global. Dentre as técnicas de testes do modelo de funcionalidade classificados por Bastos et al. (2007), Caetano (2010) define da seguinte forma: Teste Funcional - Teste que foca a validação das funções do elemento a ser testado. Teste de Regressão - Teste no qual se verifica se as partes do software foram afetadas por alguma alteração no sistema, dessa forma, validando se essas continuam funcionando normalmente. Teste Volume - Nesse teste é testado a suportabilidade do software a um determinado volume de dados, acessos, etc. Esse teste submete a aplicação ao volume definido nos seus requisitos. 8

18 Teste de Segurança - Teste para garantir que os dados (ou sistemas) possam ser acessados apenas por autorizados Usabilidade (Usability) Para Pressman (2006) o modelo de usabilidade é avaliado considerando os fatores humanos, a estética global, a consistência e a documentação. A técnica de teste de interface classificada por Bastos et al. (2007) como modelo de usabilidade, é definida por Caetano (2010) como: Teste de Interface - Teste que verifica a interação do usuário com o aplicativo, garantindo acesso e navegação apropriados. Verifica-se também a utilização dos padrões de interface da organização Confiabilidade (Reliability) Segundo Pressman (2006) a confiabilidade é avaliada medindo-se a freqüência e a gravidade de falhas, a acurácia dos resultados de saída, o tempo médio entre falhas, a capacidade de recuperarem falhas e a previsibilidade do programa. Dentre as técnicas de testes do modelo de confiabilidade classificados por Bastos et al. (2007), Caetano (2010) define da seguinte forma: Teste de integridade (robustez) - Teste que verifica a resistência à falhas e a compatibilidade técnica em relação à linguagem, sintaxe e utilização de recursos. Teste de estrutura - Teste que avalia o sistema quanto ao design e formação. Em geral, é realizado em aplicativos Web, garantindo que todos os links estejam conectados, que o conteúdo apropriado seja exibido e que não haja conteúdo órfão. Teste de estresse - Teste para avaliar como o sistema responde em condições anormais. Podem ser testados com cargas de trabalho extremas, memória 9

19 insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados. Teste da fumaça - Exercita o sistema em uma única passagem, normalmente utilizando script de execução automática Desempenho (Performance) De acordo com Pressman (2006), o desempenho é medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos e a eficiência em operações realizadas no sistema. Dentre as técnicas de testes do modelo de desempenho classificados por Bastos et al. (2007), Caetano (2010) define da seguinte forma: Teste de contenção - Teste para verificar se os itens de teste podem lidar de forma aceitável com as demandas de vários atores no mesmo recurso (registros de dados, memória, etc.). Teste de carga - Teste usado para validar e avaliar a aceitabilidade dos limites operacionais de um sistema de acordo com cargas de trabalho variáveis, enquanto o sistema em teste permanece constante. Perfil de desempenho - Teste em que o perfil de andamento do item de teste é monitorado (fluxo de execução, acesso a dados e chamadas de função, a fim de identificar e lidar com gargalos de desempenho e processos ineficientes) Suportabilidade (Suportability) Para Pressman (2006), a suportabilidade combina a capacidade de ampliar o software, adaptabilidade, capacidade de serviço, capacidade de teste, compatibilidade, configurabilidade, facilidade de instalação e facilidade de detecção de erros. As duas técnicas de testes do modelo de suportabilidade classificados por Bastos et al. (2007), é definido por Caetano (2010) como: 10

20 Teste de configuração - Teste para garantir que o item de teste funcione conforme o esperado em diferentes configurações de hardware e/ou software. Teste de instalação - Teste destinado a garantir que o item de teste seja instalado conforme o esperado em diferentes configurações de hardware e/ou software e sob diferentes condições. 1.3 Automação de testes Segundo Pressman (2006), ferramentas que podem reduzir tempo de teste (sem reduzir a eficácia) são muito valiosas.. Bastos et al. (2007) definem que é necessária a utilização de uma ferramenta de teste quando existirem fortes pressões para melhorar a qualidade, quando o projeto tiver situações que não possam ser testadas adequadamente pelos métodos tradicionais ou quando o perfil dos softwares desenvolvidos for complexo e com impacto no negócio. Delamaro et al. (2007) complementam dizendo que a aplicação de critérios de teste sem o apoio de ferramentas automatizadas tende a ser uma atividade propensa a erros e limitadas a programas muitos simples. São várias as categorias das ferramentas de testes, Miller (1979) descreve uma série delas que podemos destacar: analisadores estáticos, auditores de código, processadores de asserção, geradores de arquivos de teste, geradores de dados de teste, verificadores de teste, bancadas de teste e comparadores de saída, cada ferramenta com seus objetivos. Os ganhos com a utilização de ferramentas de testes são diversos. Uma das vantagens mais evidentes com o uso de ferramentas de testes é a redução de tempo. Um comparativo em horas entre testes manuais e automatizados pode ser visto mais claramente na Tabela 3 segundo Bartié (2002): 11

21 Tabela 3 Testes manuais vs. testes automatizados. A automação de testes trás consigo muitos benéficos, porém, segundo Caetano (2010), nem sempre uma técnica de teste pode ser automatizada, por exemplo, a técnica de teste que objetiva testar a usabilidade do sistema, não se pode substituir a sensibilidade humana por uma ferramenta. 12

22 2. Selenium Segundo SeleniumHQ (2012), Selenium é um conjunto robusto de ferramentas open source que apóia o desenvolvimento rápido de automação de teste, oferecendo um rico conjunto de funções de teste de aplicações baseadas na Web. Estas operações são muito flexíveis, permitindo muitas opções para a localização de elementos da interface do usuário e comparar os resultados dos testes esperado contra o comportamento obtido. É uma ferramenta de fácil uso e eficiente para desenvolver casos de teste, permitindo os testes de aceitação ou funcional, regressão e de desempenho. 2.1 Escolha da Ferramenta Vários fatores influenciaram na escolha da ferramenta Selenium IDE, alguns deles são: Ela é uma ferramenta open source. Possui uma comunidade de utilizadores muito ampla ao redor do mundo. Sua documentação é muito completa. A curva de aprendizagem para poder utilizar a ferramenta é baixa. Seu recurso de gravação das ações do usuário na página agiliza muito na criação dos casos de teste. 2.2 Plataformas O Selenium oferece suporte ao navegador Mozilla Firefox 2 ou superior. Quanto ao sistema operacional, essa ferramenta suporta as plataformas Windows, OS X, Linux, Solaris e outros. 2.3 Screenshot A Figura 1 demonstra a interface da ferramenta, quando a mesma é aberta através do navegador Mozilla Firefox sem nenhum caso de teste gravado. 13

23 Figura 1 Screenshot da ferramenta Selenium. 2.4 Características Conforme pode-se ver, a Tabela 4 ilustra as características do Selenium como um todo, pois a mesmo é um conjunto de quatro ferramentas que são o Selenium IDE, Selenium RC, Selenium WebDrive e Selenium GRID. Essas ferramentas são detalhadas mais adiante. 14

24 É um conjunto de quatro ferramentas open source: Selenium IDE, Selenium RC/Selenium WebDrive e Selenium GRID. Suporte as linguagens Java, C#, Perl, PHP, Python, Ruby, entre outras. É possível executar testes em qualquer navegador com suporte a JavaScript. Suporta diversos Sistemas Operacionais. Ambiente integrado para a elaboração dos casos de teste. Open source. Permite gravação e reprodução das ações feitas. Autocomplete para todos os comandos do Selenium comum. Permite debug dos scripts e utilização de breakpoints. Teste funcional com integração a outras linguagens e frameworks como PHPUnit. Teste de regressão. Teste de desempenho. Salvar testes em HTML, scripts Ruby, ou qualquer outro formato. Suporta extensões do usuário. Pode ser customizado através de plugins. Provê um vasto conjunto de comandos, permitindo simulação do comportamento do usuário e verificação do comportamento do sistema. Tabela 4 Características do Selenium. 15

25 2.5 Suporte A SeleniumHQ oferece várias opções de suporte, tais como: Grupo de Usuários - Nesse grupo, são discutidos problemas enfrentados e são postadas as soluções. Sala de Bate-Papo - Permite que questões importantes sejam solucionadas rapidamente. Registrar Defeito - A SeleniumHQ possui uma área onde os usuários podem registrar defeitos encontrados da ferramenta e possam acompanhar a situação dos mesmos. Lista de Empresas - No próprio site da SeleniumHQ, é mantida uma lista de empresas que oferecem suporte a essa ferramenta. 2.6 Requisitos Mínimos A SeleniumHQ não especifica nenhum requisito mínimo para o Selenium, Um dos motivos por não ter essa especificação se dá pelo fato da ferramenta funcionar através de um plugin do navegador Mozilla Firefox. 2.7 Diferencial O que diferencia o Selenium de outras ferramentas é que além de ela permitir testes funcionais, de regressão e desempenho, ela é open source. Ela se destaca entre as demais ferramentas gratuitas pelo fato de ser a mais completa, permitindo integração com várias linguagens, outros frameworks, além de suportar inúmeros navegadores e sistemas operacionais. 2.8 Limitações da Ferramenta Um ponto fraco da ferramenta Selenium IDE é a dependência do navegador Mozilla Firefox, pois não existem extensões para outros navegadores. Outro ponto é ao criar um caso de teste dentro de uma suíte de testes, o mesmo deve ser salvo e a suíte de testes 16

26 também deve ser salva, pois salvando somente o caso de teste, ao fechar a ferramenta ele será perdido. 2.9 Recursos O Selenium é composto de quatro ferramentas principais. A seguir serão detalhados esses recursos: Selenium IDE Segundo Santos e outros (2009), a Selenium IDE é um ambiente de desenvolvimento integrado para construção de casos de teste. Ele opera como uma extensão do Firefox e provê interfaces amigáveis para o desenvolvimento e execução de conjuntos de testes. O Selenium IDE é uma ferramenta do tipo record-and-playback, ou seja, ela captura as ações executadas pelo testador e gera um script que permite a re-execução das ações feitas, automatizando assim, o teste. Sua instalação é simples: basta abrir o arquivo de instalação pelo Firefox Selenium RC (Remote-Control) Segundo Santos e outros (2009), a Selenium RC possibilita uma maior flexibilidade ao testador, permitindo a construção de lógicas de teste mais complexas, a partir do uso de uma linguagem de programação. Para isso, ele provê uma API (Application Programming Interface) e bibliotecas para cada uma das linguagens suportadas: HTML, Java, C#, Perl, PHP, Python, e Ruby Selenium WebDrive Enquanto o Selenium RC executa uma aplicação JavaScript dentro do navegador, o WebDriver usa extensões ou recursos nativos oferecidos pelo próprio navegador para controlá-lo diretamente. 17

27 2.9.4 Selenium GRID Segundo Santos e outros (2009), a Selenium Grid permite distribuir os testes em múltiplas máquinas, reduzindo assim o tempo gasto na execução de um conjunto de testes. Ele é ideal para escalonar conjuntos de testes grandes ou conjuntos que devem ser executadas em múltiplos ambientes. O Selenium Grid atua executando múltiplas instâncias do Selenium RC em paralelo de forma transparente, fazendo com que os testes não precisem se preocupar com a infra-estrutura utilizada. 18

28 3. Utilização da Ferramenta Selenium IDE O Selenium IDE possibilita salvar vários casos de teste em um suíte de testes, onde é possível executar todos os casos de teste automaticamente um após o outro, assim o teste de regressão pode ser facilmente executado com essa ferramenta, pois quando se for desenvolver uma nova funcionalidade pode-se testar muito facilmente todos as outras desenvolvidas anteriormente, desse jeito verificando se essa nova funcionalidade causou algum erro nas outras ou não. A seguir será demonstrado o processo de utilização da ferramenta Selenium IDE. Para abrir a ferramenta deve-se ir ao menu ferramentas do Firefox e depois em Selenium IDE, assim abrirá a janela da ferramenta. 19

29 Figura 2 URL Base. Ao observar a Figura 2 pode-se ver destacado a URL Base, que serve para definir o caminho do sistema ou site que se pretende fazer os testes. Figura 3 Barra de Fast Slow. Logo abaixo da URL Base, pode-se observar na Figura 3 que existe uma barra onde à possibilidade de definir a velocidade que os testes sejam executados, isso é muito útil, já que as vezes precisa-se visualizar os testes ao mesmo tempo que estão rodando. 20

30 Figura 4 Botões de manipulação dos testes. Conforme podemos observar na área demarcada da Figura 4, o primeiro play roda uma suíte, ou seja, ele roda um conjunto de vários testes de uma vez só, na ordem em que estão abertos. O segundo play serve para rodar apenas o arquivo de teste que está aberto atualmente, ele roda todos os comandos do teste a partir do ponto inicial. O botão de pausa serve para interromper o processamento dos testes no meio de sua execução e o de iteração serve para o debug dos testes. 21

31 Figura 5 Botão de gravação das ações executadas. A Figura 5 mostra com destaque o botão de gravação, que fica alinhado à direita e serve para gravar todos os passos que são feitos na página. 22

32 Figura 6 Abas tabela e código-fonte. Observando a Figura 6, pode-se ver que na primeira aba se consegue criar o teste com o uso do assistente, na segunda aba se pode editar o teste pelo seu código-fonte. Esse código-fonte pode ser o padrão HTML, ou ser modificado pelo menu da ferramenta. As linguagens disponíveis são: Java, C#, Perl, PHP, Python e Ruby, além do HTML. 23

33 Figura 7 Comandos. Na área marcada da Figura 7 é onde ficam os comandos na ordem em que são acionados, mas pode-se inserir algum comando entre dois já existentes 24

34 Figura 8 Campos de interação. A área em destaque da Figura 8 mostra os campos onde se pode interagir com os comandos, ou seja, inserir e editar comandos para o teste. O primeiro deles é o item comando, que é a ação a ser feita, tal como verificar algum item presente, abrir uma URL, entre outros. O segundo campo de entrada é o alvo, que é um valor a ser passado como parâmetro para o comando, esse valor varia de comando para comando. Por exemplo, ele pode assumir um valor de elemento DOM, que pode variar desde um valor de ID de elemento ou um XPATH para dar mais flexibilidade de busca e elementos. Na frente desse campo há um botão de procurar, que é muito útil quando se está desenvolvendo o teste, pois nele pode-se, por exemplo, verificar se uma busca por um elemento XPATH está correta e se está validando o campo certo. O Terceiro 25

35 campo de entrada é chamado de valor e serve para quando uma ação tem mais de um parâmetro, normalmente serve para definir algum valor em um campo, como por exemplo, preencher um input. Figura 9 Área de informações. Na Figura 9, a área marcada serve para acompanhar os logs de informações e erros dos testes, ou ter uma referência de comandos do Selenium, para caso se esqueça quais parâmetros são passados para algum comando ou saber o formato do tipo de entrada. 26

36 Figura 10 Casos de teste. A Figura 10 possui um destaque na área onde ficam todos os testes abertos ou uma suíte de testes, que são conjuntos de testes inteiros para um módulo ou sistema. 27

37 4. Processos Realizados Nesta seção é demonstrado o ambiente utilizado para a elaboração dos testes, o sistema utilizado para isso e a análise dos resultados obtidos através dos mesmos. 4.1 Ambiente de Execução Para a elaboração dos testes foi utilizado o seguinte ambiente de trabalho: Hardware o Processador: Intel Core 2 Duo CPU 2.00GHz 2 o Memória: 2,8 GiB Software o Linux Ubuntu 12.04, 32-bit o Mozilla Firefox o Selenium IDE Sistema Utilizado No processo de criação dos casos de teste foram analisadas 10 páginas que compõe a área administrativa de um site e uma página que é site em si. Todos o dados são salvos em um banco de dados MySQL e o sistema é feito na linguagem PHP. A área administrativa desse site só pode acessada através de um login e senha de acesso, também nessa área existe um local para alteração de senha caso necessário, e através dessa área administrativa se pode gerenciar todo o conteúdo dinâmico que aparece no site. Também há a possibilidade de gerenciar contas de novos usuários para acesso. A maioria dos cadastros desse site é composto por uma tela onde mostra uma lista de todos os itens cadastrados até o momento, junto com a opção de excluí-lo caso necessário, uma tela onde se pode cadastrar um novo item, e uma última que permite a edição do mesmo. Somente as telas de alteração de senha e configurações permitem a edição dos dados. 28

38 Já o site em si, consiste de uma única página trabalhada com JavaScript, CSS e HTML que mostra o conteúdo dinâmico inserido pela área administrativa. 4.3 Elaboração dos Testes Para a criação dos casos de teste, a ferramenta tem um recurso que grava todas as ações realizadas, assim gerando vários casos de teste que podem ser agrupados em uma suíte de testes. Figura 11 Casos de teste gerados pela ferramenta. 29

39 A Figura 11 mostra a janela da ferramenta com vários casos de teste gerados. Se por algum motivo a ferramenta não consiga gravar alguma parte mais específica do teste através do botão de gravação, o mesmo pode ser configurado manualmente através da interface da ferramenta. Para cada página, foram obtidos os tempos da elaboração do testes com o uso da ferramenta e efetuado o teste de forma manual. Na Tabela 5 são demonstrados os tempos de criação destes casos de teste, e um comparativo do tempo entre o teste manual e o teste utilizando a ferramenta: Página Testada Elaboração do Teste Teste Manual Teste Automatizado Login 00:01:24 00:00:12 00:00:04 Feitos/Categorias 00:06:54 00:00:27 00:00:08 Feitos/Feitos 00:08:24 00:00:49 00:00:08 Habilidades/Categorias 00:01:36 00:00:29 00:00:07 Habilidades/Habilidades 00:04:26 00:00:41 00:00:09 Portfólio/Categoria 00:01:23 00:00:27 00:00:08 Portfólio/Portfólio 00:03:27 00:00:55 00:00:09 Configurações 00:02:44 00:00:22 00:00:05 Gerenciar Usuário 00:05:26 00:00:48 00:00:09 Alterar Senha 00:02:11 00:00:25 00:00:06 Site Completo 00:07:23 00:01:33 00:00:12 Total 00:45:18 00:07:08 00:01:25 Tabela 5 Dados dos casos de teste. 4.4 Resultados Obtidos Com as informações de tempo gasto por execução dos testes, foi feito uma previsão dos mesmos comparando teste manual e teste com a ferramenta como pode ser visto na Tabela 6. 30

40 Vezes MANUAL SELENIUM IDE Diferença Tempo Soma Tempo Soma 1 00:07:08 00:07:08 00:46:43 00:46:43 00:39: :07:08 00:14:16 00:01:25 00:48:08 00:33: :07:08 00:21:24 00:01:25 00:49:33 00:28: :07:08 00:28:32 00:01:25 00:50:58 00:22: :07:08 00:35:40 00:01:25 00:52:23 00:16: :07:08 00:42:48 00:01:25 00:53:48 00:11: :07:08 00:49:56 00:01:25 00:55:13 00:05: :07:08 00:57:04 00:01:25 00:56:38-00:00:26 Tabela 6 Tempo de testes manuais vs. testes automatizados. Observa-se também na Tabela 6 que conforme a quantidade de vezes que os testes são executados a diferença vai diminuindo. O tempo para execução dos testes manuais são os mesmos, pois leva em consideração apenas o tempo necessário para realização dos testes no sistema. Já o tempo do Selenium IDE na primeira vez considera os tempos de criação dos casos de teste e execução dos testes, as demais vezes consideram somente o tempo de execução dos testes com a ferramenta. Pode-se verificar de forma clara que há uma diferença considerável de tempo entre os testes manuais e com a ferramenta. Analisando os valores de tempo gasto, podemos ver que em apenas 8 vezes que executamos os testes, a ferramenta consegue superar os testes manuais em questão de tempo, assim a partir deste ponto começa a ser vantagem a utilização ferramenta Selenium IDE. 4.5 Gerenciamento de Falhas Uma falha descoberta no teste manual, na maioria das vezes se tem dificuldade de fazer uma nova simulação desse erro, além de ser necessário uma documentação desse erro para ser encaminhado a uma equipe de desenvolvimento. Mas a extensão Selenium IDE possibilita que se possa adicionar mais funcionalidades com a adição de plugins, um deles é o ScreenShot of Fail, que possibilita que a ferramenta salve uma screenshot da tela onde o erro ocorreu. Na Figura 12 pode ser visto esse plugin em funcionamento. 31

41 Figura 12 Plugin para captura de tela quando houver erro. Ao instalar o plugin aparecerá um novo botão na interface do Selenium IDE, que pode ser visto na área marcada da Figura 12, quando o mesmo for ativado, passará a salvar uma screenshot dos os erros encontrados pela ferramenta. 32

42 Figura 13 Screenshot de erro gerada pelo plugin. Um exemplo da screenshot gerada pelo plugin pode ser visto na Figura 13, o plugin quanto encontra um erro salva a screenshot em uma pasta nomeada com a data e hora que o mesmo acorreu. 33

43 5. Conclusão O tempo gasto com testes manuais e com a manutenção de aplicações web sem testes adequados (normalmente por falta de tempo da equipe responsável) é muito alto de modo que se faz necessário a busca por ferramentas que permitam, além de reduzir este tempo, melhorar a qualidade dos testes aplicados. Neste contexto o estudo da ferramenta Selenium IDE visou identificar suas características para avaliar a possibilidade de diminuir esse tempo com o auxilio da mesma. E nesse trabalho também foram apresentados os conceitos de testes, seus níveis, tipos e técnicas. No decorrer do trabalho surgiram dificuldades que, se por um lado atrapalharam o seu desenvolvimento, por outro permitiram que, ao superá-las, fosse possível atingir um nível mais elevado na definição dos conceitos e na análise prática realizada. A principal dificuldade foi com a ferramenta PHPUnit que seria o tema dessa monografia mas ao se tomar conhecimento de sua documentação, que quando analisada, foi percebido que sua complexidade era maior do que o esperado, para seu pleno entendimento, assim podendo estourar o tempo para a entrega deste trabalho. Mas essa barreira foi ultrapassada ao pesquisar e encontrar outra ferramenta para automação de testes, o Selenium IDE que, em vez de efetuar testes de caixa branca, seria testes de caixa preta, e nesse tipo de teste o conhecimento prévio já era suficiente para completude do trabalho no tempo programado. Outro ponto levantado é a questão dos conceitos dos testes. São inúmeros os autores que detalham os testes, seus conceitos e suas divisões de maneira diferenciada. Alguns os classificam como tipos de testes, outros, como técnicas, outros ainda como níveis de teste, porém essas definições não seguem um padrão, dificultando o entendimento e estruturação dos mesmos. Diversos indicadores foram levantados, analisados e comparados, comprovando que a ferramenta Selenium IDE é capaz de testar um número superior de testes em um tempo bem menor do que testes manuais. Ficou evidente também a sua utilidade ao executar testes de regressão, pois sua funcionalidade de gravar vários casos de testes um uma suíte de testes facilita muito, podendo com um único clique re-executar todos os testes gravados até o momento, quando uma nova funcionalidade for inserida no sistema. 34

44 O tempo dedicado ao estudo da ferramenta PHPUnit não foi perdido, pois foi descoberto que e mesma pode ser integrada com o Selenium WebDrive. Utilizando o Selenium IDE, com o plugin Selenium IDE: PHP Formatters ele pode exportar os casos de teste para linguagem PHP e assim pode ser usado com a ferramenta PHPUnit, possibilitando que o os testes possam ser executados em outros navegadores que o Selenium WebDrive suporta e não somente o Firefox. Mas essa integração e analise será deixada para uma próxima oportunidade de pesquisa, pois esse não é o foco desse trabalho. 35

45 6. Referências Bibliográficas BARTIÉ, A Garantia da qualidade de Software. São Paulo: Campus, BASTOS, Aderson; et al. Base de conhecimento em teste de software. São Paulo: Martins, CAETANO, Cristiano. Base de Conhecimento em Teste de Software: Módulo 2 - Planejando os Testes, COWARD, P. D. A review of software testing. In Software Engineering, M. Dorfma, R. DELAMARO, Eduardo Márcio; et al. Introdução ao teste de software. Rio de Janeiro: Elsevier, p. MASIERO, Paulo Cesar, et al. Teste de Software Orientado a Objetos e a Aspectos: Teoria e Prática, MYERS, G. The Art of Software Testing. John Wiley & Sons, 2 nd Edition, PETERS, James F., et al. Engenharia de Software: teoria e prática. 1ª ed. Rio de Janeiro: CAMPUS, PRESSMAN, Roger S. Estratégias de Teste de software. In: PRESSMAN, Roger S, Engenharia de Software. São Paulo: McGraw Hill, ª Ed. BLACK, Rex. Managing the Testing Process, 1e, Best Practices series. New York: Microsoft Press, ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves. Qualidade de Software Teoria e Prática. São Paulo: Prentice Hall, SANTOS, I. S.; SANTOS NETO, P. Automação de Testes Funcionais com o Selenium, ISBN ERCEMAPI Escola Regional de Computação (Ceará, Maranhão e Piauí) p SeleniumHQ. Selenium Documentation. Disponível em: Acesso em jun SOMMERVILLE, Ian. Teste de software. In: SOMMERVILLE, Ian, Engenharia de Software. São Paulo: Pearson Addison Wesley, ª Ed. 36

46 7. Referências Consultadas BERGMANN, Sebastian. PHPUnit Manual. Disponível em: Acesso em jan SUK, Cristiano. Seleção e Avaliação de Ferramentas de Apoio às Atividades de Testes em Software, Voltadas à Micro e Pequenas Empresas. Maringá, novembro, p. 49. Monografia (Trabalho de Conclusão de Curso de Informática) - Departamento de Informática, Universidade Estadual de Maringá. NOGUEIRA, Elias. Sem Bugs Testes de Qualidade de Software. Disponível em: Acesso em jun