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
 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
 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
 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
 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
 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
 Índice

1. Revisão Bibliográfica ............................................................................................... 2

1.1 Engenharia de Software .................................................................................... 2
1.2 Teste em software ............................................................................................. 2
1.2.1 Tipos de testes .......................................................................................... 4
1.2.2 Níveis de testes ......................................................................................... 5
1.2.3 Técnicas de testes ..................................................................................... 7
1.3 Automação de testes ....................................................................................... 11
2. Selenium ................................................................................................................. 13
2.1 Escolha da Ferramenta.................................................................................... 13
2.2 Plataformas ..................................................................................................... 13
2.3 Screenshot ....................................................................................................... 13
2.4 Características ................................................................................................. 14
2.5 Suporte ............................................................................................................ 16
2.6 Requisitos Mínimos ........................................................................................ 16
2.7 Diferencial ...................................................................................................... 16
2.8 Limitações da Ferramenta .............................................................................. 16
2.9 Recursos ......................................................................................................... 17
2.9.1 Selenium IDE ......................................................................................... 17
2.9.2 Selenium RC (Remote-Control) ............................................................. 17
2.9.3 Selenium WebDrive ............................................................................... 17
2.9.4 Selenium GRID ...................................................................................... 18
3. Utilização da Ferramenta Selenium IDE ................................................................ 19
4. Processos Realizados .............................................................................................. 28
4.1 Ambiente de Execução ....................................................................................... 28
4.2 Sistema Utilizado................................................................................................ 28
4.3 Elaboração dos Testes ........................................................................................ 29
4.4 Resultados Obtidos ............................................................................................. 30
4.5 Gerenciamento de Falhas.................................................................................... 31
5. Conclusão ............................................................................................................... 34
6. Referências Bibliográficas ...................................................................................... 36
7. Referências Consultadas ......................................................................................... 37

vi
 Índice de Tabelas

Tabela 1 – Classificação dos níveis de testes. .................................................................. 6

Tabela 2 – Técnicas de testes aplicadas por nível de teste. .............................................. 8
Tabela 3 – Testes manuais vs. testes automatizados. ..................................................... 12
Tabela 4 – Características do Selenium.......................................................................... 15
Tabela 5 – Dados dos casos de teste. .............................................................................. 30
Tabela 6 – Tempo de testes manuais vs. testes automatizados. ..................................... 31

vii
 Índice de Figuras

Figura 1 – Screenshot da ferramenta Selenium. ............................................................. 14

Figura 2 – URL Base. ..................................................................................................... 20
Figura 3 – Barra de Fast Slow. ....................................................................................... 20
Figura 4 – Botões de manipulação dos testes. ................................................................ 21
Figura 5 – Botão de gravação das ações executadas. ..................................................... 22
Figura 6 – Abas tabela e código-fonte. ........................................................................... 23
Figura 7 – Comandos. ..................................................................................................... 24
Figura 8 – Campos de interação. .................................................................................... 25
Figura 9 – Área de informações. .................................................................................... 26
Figura 10 – Casos de teste. ............................................................................................. 27
Figura 11 – Casos de teste gerados pela ferramenta....................................................... 29
Figura 12 – Plugin para captura de tela quando houver erro.......................................... 32
Figura 13 – Screenshot de erro gerada pelo plugin. ....................................................... 33

viii
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
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
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
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:

1.2.1 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
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.”.

1.2.2 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
projeto de um esteja completa e projeto detalhado
Componente ou
elemento de correta. Garantir
Unidade
software (ex: que o componente
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
 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
critérios de estejam satisfeitos. participantes.
Aceitação
aceitação dos
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
 • 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.

1.2.3 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
 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:

1.2.3.1 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
 • Teste de Segurança - Teste para garantir que os dados (ou sistemas) possam ser
acessados apenas por autorizados.

1.2.3.2 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.

1.2.3.3 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
 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.

1.2.3.4 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).

1.2.3.5 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
 • 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
 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
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
 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
É 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
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
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:

2.9.1 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.

2.9.2 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.

2.9.3 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
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
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
 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
 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
 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
 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
 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
 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
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
 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
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 T6400 @ 2.00GHz × 2

o Memória: 2,8 GiB

• Software

o Linux Ubuntu 12.04, 32-bit

o Mozilla Firefox 16.0.2

o Selenium IDE 1.9.1

4.2 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
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
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
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:35
2 00:07:08 00:14:16 00:01:25 00:48:08 00:33:52
3 00:07:08 00:21:24 00:01:25 00:49:33 00:28:09
4 00:07:08 00:28:32 00:01:25 00:50:58 00:22:26
5 00:07:08 00:35:40 00:01:25 00:52:23 00:16:43
6 00:07:08 00:42:48 00:01:25 00:53:48 00:11:00
7 00:07:08 00:49:56 00:01:25 00:55:13 00:05:17
8 00: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
 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
 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
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
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
6. Referências Bibliográficas
BARTIÉ, A Garantia da qualidade de Software. São Paulo: Campus, 2002.
BASTOS, Aderson; et al. Base de conhecimento em teste de software. São Paulo:
Martins, 2007.
CAETANO, Cristiano. Base de Conhecimento em Teste de Software: Módulo 2 -
Planejando os Testes, 2010.
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, 2007. 359 p.
MASIERO, Paulo Cesar, et al. Teste de Software Orientado a Objetos e a Aspectos:
Teoria e Prática, 2006.
MYERS, G. The Art of Software Testing. John Wiley & Sons, 2nd Edition, 2004.
PETERS, James F., et al. Engenharia de Software: teoria e prática. 1ª ed. Rio de Janeiro:
CAMPUS, 2001.

PRESSMAN, Roger S. Estratégias de Teste de software. In: PRESSMAN, Roger S,

Engenharia de Software. São Paulo: McGraw Hill, 2006. 6ª Ed.

BLACK, Rex. Managing the Testing Process, 1e, “Best Practices” series. New York:
Microsoft Press, 1999.

ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival
Chaves. Qualidade de Software – Teoria e Prática. São Paulo: Prentice Hall, 2001.

SANTOS, I. S.; SANTOS NETO, P. Automação de Testes Funcionais com o Selenium,

ISBN 9788576692. ERCEMAPI 2009 - Escola Regional de Computação (Ceará,
Maranhão e Piauí). 2009. p. 27-52.

SeleniumHQ. Selenium Documentation. Disponível em: http://seleniumhq.org/docs/.

Acesso em jun. 2012.

SOMMERVILLE, Ian. Teste de software. In: SOMMERVILLE, Ian, Engenharia de

Software. São Paulo: Pearson Addison Wesley, 2007. 8ª Ed.

36
7. Referências Consultadas
BERGMANN, Sebastian. PHPUnit Manual. Disponível em:
http://www.phpunit.de/manual/3.7/en/index.html. Acesso em jan. 2012.

SUK, Cristiano. Seleção e Avaliação de Ferramentas de Apoio às Atividades de Testes

em Software, Voltadas à Micro e Pequenas Empresas. Maringá, novembro, 2010. 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:

http://sembugs.blogspot.com.br/. Acesso em jun. 2012.

37