Teste de Software Web

Prévia do material em texto

Universidade do Minho
Escola de Engenharia
Departamento de Informática
Tiago Filipe Andrade Brito
Testes em Aplicações Web
Outubro 2016
Universidade do Minho
Escola de Engenharia
Departamento de Informática
Tiago Filipe Andrade Brito
Testes em Aplicações Web
Master dissertation
Master Degree in Computer Science
Dissertation supervised by
António Luís Pinto Ferreira de Sousa
Daniela Duarte da Costa
October 2016
A G R A D E C I M E N T O S
Antes de mais gostaria de agradecer e dedicar este trabalho aos meus pais por todo o apoio
dado ao longo destes anos, por acreditarem em mim e por contribuírem com o seu melhor
para o meu desenvolvimento pessoal e profissional, pois sem eles não seria possível chegar
onde cheguei.
Quero também agradecer:
• Ao meu orientador, Prof. António Sousa e à minha diretora Daniela Costa por todo
todo o apoio e contribuição dada no desenvolvimento deste estudo.
• A toda a equipa de desenvolvimento Web da Eurotux, por todo o apoio, ideias e
conhecimento transmitido.
• Ao Prof. Vítor Fonte, por todas as oportunidades que me forneceu.
• À minha irmã e cunhado, Carla e Fernando por incentivarem-me sempre a dar o meu
melhor e a não desistir.
• Ao meu sobrinho, Eduardo por todos os momentos de descontração que proporcio-
nou.
• À Fabiola Silva, por todo o apoio que me deu quando mais precisava.
• A todos os meus amigos que me apoiaram ao longo deste percurso.
i
A B S T R A C T
With the evolution of technology more and more software applications are designed to run
in a Web browser, being commonly known as Web applications. As a method to ensure the
quality of these applications, the tests are attracting today more and more attention from
both the academic and business communities.
Having a well-defined test strategy from the beginning of the project and applying them
during the development phase, ensures the quality of the final software by reducing the
risk of unforeseen problems at later stages. Such problems translate into increased cost
of implementation and reduced profitability of the project to the supplier. It may also
postpone the projet delivery which result in customer dissatisfaction.
On the other hand, the constant software upgrades, imposed by the highly competitive
market of today, increase the risk of destroying previously implemented features (called
regression). For this reason, it is required that the testing strategy is not only defined and
implemented during the design, but also after each step of development in order to ensure
that the development does not breaks already existing functionality.
Repeated tests, covering all the software at each delivery, is a challenge to organizations
due to its high cost and increased possibility of human error.
For all these reasons, the Web development team supervisors at Eurotux supported this
research work and allowed the resulting prototype to be applied in real projects, developed
over the last few months, thus defining a testing strategy aiming to increase customer
satisfaction, profitability of the projects and the motivation of the team itself.
Several methodologies were studied to allow automate testing of Web applications. Auto-
mated testing ensures that the software is in accordance with all the defined specifications,
maintaining the confidence of all stakeholders in the expected software quality throughout
its life cycle.
Some comparative studies were evaluated, being analysed in detail the methodologies
for functional testing and regression testing, Selenium tools for defining automatic testing
integrated with the Alloy Analyser tool, in order to evaluate the quality of the formal
specification.
After such analysis, a prototype tool named WebTest was developed in order to build and
run automated tests. A report containing the generated test results is then sent to the web
application development team, to help keeping track of existing faults in software quality.
Lastly the prototype was used in several production projects at Eurotux, receiving highly
ii
iii
positive reviews from both developers and managers, leveraging the time spent testing
software after each consecutive update.
R E S U M O
Com a evolução da tecnologia cada vez mais aplicações de software são desenvolvidas para
correrem sob um browser de Internet, sendo normalmente designadas de aplicações Web.
Como método de assegurar a qualidade destas aplicações, os testes atraem cada vez mais a
atenção das comunidades académica e empresarial.
Ter uma estratégia de testes bem definida desde o início do projeto, e executar os mesmos
durante a fase de desenvolvimento, além de assegurar a qualidade do software, reduz o
risco de surgirem problemas imprevistos numa fase posterior do projeto, que aumentam o
custo de implementação e consequentemente diminuem a rentabilidade do projeto para a
empresa fornecedora, e ainda provocam atrasos que normalmente resultam na insatisfação
do cliente.
Por outro lado, as constantes evoluções do software, que o mercado altamente competi-
tivo de hoje obriga, aumentam o risco de destruir funcionalidades implementadas anteri-
ormente (chamada Regressão). Por este motivo, é necessária que a estratégia de testes seja
não só definida e implementada durante o projeto, mas também após o seu fecho.
A repetição dos testes que cobrem todo o software em cada momento de entrega, são um
desafio para as organizações, na medida em que o seu custo é elevado, e dado que existe a
possibilidade de falha humana.
Por todos estes motivos, os responsáveis pela equipa de desenvolvimento Web da Euro-
tux apoiaram este trabalho de investigação e permitiram que o mesmo fosse aplicado em
projetos reais desenvolvidos ao longo dos últimos meses, com o objetivo de ser definida
uma estratégia de testes que permitisse tornar o processo de desenvolvimento Web mais
robusto, aumentando a qualidade das soluções desenvolvidas. Pretendia-se essencialmente
definir uma estratégia de testes automáticos que diminuísse a possibilidade de erro humano
na execução dos testes, e que permitisse aumentar a rentabilidade dos projetos gastando
menos horas na fase de verificação.
Foram assim estudadas várias metodologias, tendo sido os testes funcionais que assegu-
ram a concordância da parte funcional do software face às suas especificações, e os testes
de regressão que garantem que o novo código não introduz erros, o foco da presente dis-
sertação. Foram ainda realizados alguns estudos comparativos de ferramentas, tendo sido
escolhido o Selenium para definição de testes automáticos em conjunto com a ferramenta
Alloy Analyser para avaliação da qualidade da especificação.
Após a escolha das ferramentas que mais se adequaram aos objetivos propostos neste
estudo, foi desenvolvida uma ferramenta denominada WebTest que permite a programação
iv
v
automática de testes funcionais e produz relatórios que são enviados por email, permitindo
à equipa de desenvolvimento Web acompanhar o nível de qualidade do seu software.
A WebTest foi utilizada em projetos reais da empresa, e o feedback por parte da equipa
e dos seus responsáveis foi bastante positiva. Com a WebTest foi possível reduzir o tempo
gasto com os testes nos projetos e garantir a qualidade da solução apesar das alterações de
requisitos e incremento de funcionalidades no software.
C O N T E Ú D O
1 introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Engenharia de Software e a importância dos testes . . . . . . . . . . . . 4
2.3 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 8
2.3.2 Metodologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Relacionamento métodos/metodologias . . . . . . . . . . . . . . 11
2.3.4 Testes nas aplicações WEB . . . . . . . . . . . . . . . . . . . . . . 12
2.3.5 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.6 Comparação de ferramentas . . . . . . . . . . . . . . . . . . . . . 15
2.3.7 Seleção de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Evolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 Linguagens/Ferramentas de especificação formal . . . . . . . . . 18
2.4.4 Comparação de Linguagens/Ferramentas . . . . . . . . . . . . . 20
2.4.5 Seleção de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Análise às ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Verificação formal - Alloy . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Testes - Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.3 União de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1 Plataforma de testes e verificação . . . . . . . . . . . . . . . . . . 25
3 ferramenta de testes selenium . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Selenium Remote Control . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Selenium IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3 Selenium WebDriver . . . . . . . . . . . . . . . . . . . . . . . . . . 30
vi
Conteúdo vii
3.3.4 Selenium Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Selenium v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Selenium v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 As potencialidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 ferramenta de automação de testes e qualidade - webtest . . . 35
4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Ambiente de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Carregamento de ficheiros . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.1 O ficheiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Implementação da Selenium Grid . . . . . . . . . . . . . . . . . . . . . . 42
4.6 Casos de teste genéricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Testes específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Execução em paralelo e com parâmetros . . . . . . . . . . . . . . . . . . 48
4.9 Validação de modelos Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11 GUI - Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . 51
4.12 Parâmetros da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.12.1 Execução programada . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.13 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 avaliação da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Caso de teste 1 - TeraBunker . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Caso de teste 2 - Site de media . . . . . . . . . . . . . . . . . . . . . . . . 56
6 conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1 Síntese das conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
a instalação e configuração da java virtual machine . . . . . . . 72
b instalação e configuração do postfix . . . . . . . . . . . . . . . . . . 73
c instalação e configuração da selenium grid . . . . . . . . . . . . . 74
d execução da aplicação desenvolvida . . . . . . . . . . . . . . . . . . 78
e exemplo ficheiro json de configuração . . . . . . . . . . . . . . . . . 79
f exemplo classe externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
g código - caso de teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
L I S TA D E F I G U R A S
Figura 1 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figura 2 White Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 3 Verificação estática e dinâmica . . . . . . . . . . . . . . . . . . . 12
Figura 4 Funcionamento Selenium Web Driver . . . . . . . . . . . . . . . 14
Figura 5 Funcionamento Sahi . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figura 6 Evolução qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 7 Selo correção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 8 Componentes Selenium . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 9 Selenium Remote Control . . . . . . . . . . . . . . . . . . . . . . 29
Figura 10 Selenium IDE v2.9.1 . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 11 Selenium Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 12 Componentes Selenium v2 . . . . . . . . . . . . . . . . . . . . . . 32
Figura 13 Estrutura aplicação WebTest . . . . . . . . . . . . . . . . . . . . . 37
Figura 14 Infraestrutura Selenium Grid . . . . . . . . . . . . . . . . . . . . 42
Figura 15 Execução em paralelo . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 16 Verificação modelo Alloy . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 17 Relatório de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 18 Interface gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 19 Resultados caso de teste - TeraBunker . . . . . . . . . . . . . . . 55
Figura 20 Resultados caso de teste - site de media . . . . . . . . . . . . . . 56
Figura 21 Resultados caso de teste - site de media . . . . . . . . . . . . . . 57
Figura 22 Evolução validação . . . . . . . . . . . . . . . . . . . . . . . . . . 57
viii
L I S TA D E TA B E L A S
Tabela 1 Relacionamento métodos/metodologias . . . . . . . . . . . . . . 11
Tabela 2 Comparação de ferramentas . . . . . . . . . . . . . . . . . . . . . 15
Tabela 3 Comparação de linguagens/ferramentas qualidade . . . . . . . 20
Tabela 4 Planeamento desenvolvimento . . . . . . . . . . . . . . . . . . . 36
ix
L I S TA D E C Ó D I G O S
2.1 Código Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Código Alloy - Asserções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Exemplo código Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 JSON - Configuração geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 JSON - Objeto configuração ambiente . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 JSON - Objeto data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 JSON - Teste externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 JSON - Teste Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6 Classe Externa - Anotação . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Classe Externa - Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Classe Externa - Parametrização . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9 Classe Externa - Construtor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.10 Acesso WebDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.11 Acesso dados teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.12 Acesso relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 Classe Externa - Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.14 Carregamento de classes externas . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.15 Execução programada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.16 Geração de Cron Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1 Instalação JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.2 Verificação versão JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.3 Configuração ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.1 Instalação postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.2 Instalação mailutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.3 Teste de envio email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.1 Download Selenium 2.53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.2 Execução Selenium HUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.3 Selenium HUB a correr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.4 Exemplo JSON configuração nodo . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.5 Execução nodo Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
x
Lista de Códigos xi
C.6 Interface Web Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
D.1 Execução WebTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
E.1 Exemplo ficheiro JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
F.1 Exemplo classe externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
G.1 Código caso de teste 1 - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
G.2 Código caso de teste 1 - Pasta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
1
I N T R O D U Ç Ã O
1.1 enquadramento
Ao longo dos anos, as técnicas e ferramentas para desenvolvimento de software têm vindo a
ser aprimoradas e cada vez mais utilizadas em diferentes aplicações. Uma das maiores pre-
ocupações do desenvolvimento de software está relacionada com a qualidade dos sistemas
desenvolvidos e, consequentemente, com a sua estabilidade no ambiente de produção.
Uma falha num sistema pode causar prejuízos financeiros, comprometimento de crono-
gramas, falta de confiança na aplicação por parte dos seus utilizadores e, em situações mais
extremas, até a perda de vida humana. Exemplo disso, foi o equipamento de radioterapia
Therac-25, que devido a uma falha de software, foram causados pelo menos seis acidentes (Leve-
son and Turner [60]) entre 1985 e 1987, nos quais os pacientes receberam grandes doses de
radiação que resultaram em graves problemas, incluindo a morte de alguns.
Para reduzir o risco de falhas, as organizações que desenvolvem software começaram
progressivamente a ter a necessidade de adotar um processo de desenvolvimento formal,
incluindo a execução de testes para verificação do software desenvolvido.
Também os responsáveis da Eurotux, onde existe um departamento de desenvolvimento
Web desde 2004, têm estas preocupações e têm vindo, ao longo dos anos, a sistematizar o
processo de desenvolvimento. Uma das falhas desse processo estava sobretudo relacionado
com a qualidade do produto no momento da entrega, e na manutenção da qualidade ao
longo do ciclo de vida da aplicação. Todas as aplicações Web devem ser testadas cuidado-
samente de forma a assegurar que a aplicação é confiável e está conforme a especificação
aprovada pelo cliente. As aplicações Web tipicamente ficam em manutenção a uma velocidade
maior do que qualquer outro tipo de sistemas de software e esta manutenção consiste normalmente
em pequenas mudanças incrementais (Kirda et al. [59]).
Na sequência de uma entrevista com a diretora do departamento de desenvolvimento
Web da Eurotux, foram identificados os seguintes problemas:
• o software é normalmente entregue em vários sprints, mas em cada entrega é neces-
sário testar todo o sistema;
1
1.2. Estrutura do documento 2
• o atual número de browsers e dispositivos aumenta consideravelmente o custo dos
testes na medida em que exige a repetição dos mesmos nos diferentes ambientes;
• têm sido recorrentes as falhas nos testes realizados, ou porque não foi testado deter-
minado ambiente ou porque os casos testados foram insuficientes.
Com a realização de testes manuais de aplicações Web é impossível garantir que todos
os erros sejam encontrados e retificados, uma vez que seria necessário uma quantidade
extremamente elevada de testes, não sendo possível realizá-los a todos manualmente, des-
perdiçando tempo (Wang and Du [120]). Para acomodar estas alterações, os testes devem
ser automatizados e adaptáveis face à constante evolução dos Web browsers, de forma a
garantir a estabilidade e perfeição do software desenvolvido.
Perante este cenário, o que se pretende com este trabalho de investigação é assegurar
que o processo de desenvolvimento Web da Eurotux se torna mais robusto relativamente à
vertente dos testes, de forma a aumentar a qualidade do software produzido e consequen-
temente a satisfação do cliente.
Para tal, serão estudadas ferramentas que permitam a realização de testes em vários
browsers de forma automática, bem como linguagens que assegurem a qualidade quer da
especificação, quer da implementação das funcionalidades. Juntando ambas será possível
correr testes de forma fácil, simples e recorrente para que seja possível detetar e corrigir
todos os erros encontrados antes do lançamento da aplicação ou da nova funcionalidade.
De forma a alcançar este resultado são definidos os seguintes objetivos:
• selecionar uma ferramenta de testes que permita correr testes em vários browsers e
sistemas operativos
• selecionar uma ferramenta de verificação formal de forma a validar a especificação
• desenvolver uma ferramenta de testes e verificação formal que englobe ambas as ferra-
mentas escolhidas e que permita a execução de testes genéricos, bem como específicos
de um projeto
• obter relatórios detalhados dos testes executados
• permitir a execução da ferramenta desenvolvida de forma automática
1.2 estrutura do documento
A partir deste capítulo introdutório, a presente dissertação encontra-se organizada em seis
capítulos. No Estado da Arte (Capítulo 2) é feita uma introdução à temática dos testes
explicando os principais conceitos e metodologias. São analisadas ferramentas de testes e
1.2. Estrutura do documento 3
comparadas entre si. Nesse mesmo capítulo é também abordada a qualidade do software
e como esta se encontra relacionada com os testes. São também comparadas várias lingua-
gens que permitem a modelação da especificação do software. Este termina com a avaliação
da ferramenta de teste e linguagem de modelação escolhidas.
No Capítulo 3 é descrita uma análise mais aprofundada da ferramenta que será utilizada
para a realização dos testes. Neste capítulo será possível então conhecer a história da ferra-
menta e os seus componentes.
Posteriormente, no capítulo 4 explica-se o desenvolvimento efetuado de forma a atingir
os objetivos identificados anteriormente. É apresentada a arquitetura do sistema e o seu
desenvolvimento.
No capítulo 5 são apresentados testes à arquiteturaimplementada, com recursos a casos
reais, bem como uma análise sobre objetivos que foram atingidos ao utilizar o software
desenvolvido.
Finalmente no capítulo 6, são dadas algumas pistas de uma possível investigação futura, e
ainda as principais conclusões sobre todo o trabalho realizado.
2
E S TA D O D A A RT E
2.1 introdução
O presente capítulo pretende apresentar o estado da arte relativamente às metodologias
e ferramentas de testes de software (Selenium [104], Sahi [101] e Watir [122]) e ainda as
linguagens utilizadas para garantir a qualidade do software (VDM [13], Object-Z [119], OCL
[83], Alloy [72]). Este capítulo inicia-se com uma secção introdutória sobre a importância
dos testes na engenharia de software, e termina com a avaliação das ferramentas escolhidas
e as principais conclusões.
2.2 engenharia de software e a importância dos testes
A Engenharia de Software é uma área da computação que se foca na especificação, desen-
volvimento e manutenção de sistemas de software. A evolução nesta área é notória, e cada
vez mais as organizações investem recursos de forma a garantir a qualidade do software
produzido (Pressman [90]).
Vários estudos [34, 12] demonstram que apesar das empresas de TI se preocuparem cada
vez mais com a qualidade do software, muitas deixam de parte um importante segmento
de qualquer projeto de software: os testes. As vantagens e limitações dos testes são bem
conhecidas e existe um grande debate sobre a automatização de testes (Berner et al. [12],
Ramler and Wolfmaier [93]). Pode tomar-se como exemplo deste debate, os casos de estudo
Kim et al. [58] e Talby et al. [109] que demonstram a importância dos testes de software,
embora também importe referir, que estes devem ser realizados por fases (Myers et al.
[77], Kaner [55]). No entanto, surge uma questão pertinente:
Does the practice of software testing effectively meet industry needs?
— Software testing and industry needs, Glass et al. [34]
4
2.3. Software Testing 5
De forma a responder corretamente a esta questão, seria necessário fazer um estudo
completo e exaustivo à indústria, uma vez que cada segmento teria as suas respetivas ne-
cessidades e esse não é objetivo do presente estudo. No entanto, é seguro afirmar que a
utilização de uma má abordagem aos testes, pode ter um impacto real na situação econó-
mica de uma empresa (Tassey [110]). Os testes são por norma realizados manualmente e
pela pessoa responsável pela implementação, o que se traduz num enorme erro na medida
em que quem programa, ao testar o seu próprio código já se encontra num ciclo ’vicioso’
aplicando casos de teste genéricos, e que muitas vezes não refletem o comportamento do
utilizador final (Reason [95]), principalmente quando este tem pouco à vontade na inte-
ração com interfaces de software. Esta situação é bastante problemática, e por vezes as
organizações não lhe dão a devida atenção.
No entanto, algumas empresas já dispõem de equipas dedicadas a testes. A única função é
encontrar erros no software de forma a que eles não cheguem a um ambiente de produção.
Outras empresas dedicam-se à metodologia Agile [32], introduzindo o termo de Agile tes-
ting onde fazem desenvolvimento focado nos testes ao longo do projeto. No entanto pode
haver uma rejeição de qualquer teste que não possa ser automatizado de forma eficiente
(Crispin and House [22]), o que pode causar problemas em alguns casos. No entanto, este
método tem tido um feedback positivo (Talby et al. [109], Mosley and Posey [75]).
Mas será mesmo necessário a empresa incluir uma equipa de testes? Com o avanço
das tecnologias e dos métodos formais cada vez menos as organizações adotam processos
manuais, optando sempre que possível por processos automáticos. Dado o contexto em
que este estudo se insere, o foco deste trabalho estará em eliminar a interação humana
nos testes, e permitir correr testes realizados de forma automática logo desde o início de
um projeto. No entanto, para alcançar tal objetivo é necessário garantir que o projeto
tem uma boa especificação formal. Ou seja, é importante garantir a qualidade da própria
especificação, pois só desta forma é possível avançar com o desenvolvimento do software,
e em simultâneo realizar testes automáticos.
Nas secções seguintes, será explorada a vertente do testing, as suas técnicas, metodolo-
gias e ferramentas, bem como a qualidade e quais as ferramentas que permitem garantir
que os testes se encontram corretos e de acordo com a especificação.
2.3 software testing
O termo de testing surgiu da necessidade de encontrar erros no software produzido (Sawant
et al. [103]).
Erros, ou utilizando o termo inglês Bugs são falhas no software que podem ou não ser
2.3. Software Testing 6
críticas, resultando simplesmente na paragem inesperada de um programa sem graves con-
sequências, ou ter um impacto crítico num sistema que resulte em mortes humanas como
no caso do Therac-25 [60] referido anteriormente. Outros exemplos de falhas graves são o
bug The Y2K (Year 2000) Bug [113] que se traduziu em várias centenas de biliões de dóla-
res gastos, e o Patriot Missile Defense System, que em 1991 o sistema falhou ao defender-se
de vários mísseis devido a um erro no relógio interno após 14h de funcionamento (Patton
[87]).
Devido à ocorrência de erros, surge a necessidade do testing, uma técnica para avaliar as
capacidades de um programa ou produto e determinar se está de acordo com a sua especi-
ficação (Sawant et al. [103]).
Assim pode ser considerada a seguinte definição:
The process of executing a software system to determine whether it matches its speci-
fication and executes in its intended environment.
— What Is Software Testing? And Why Is It So Hard?, Whittaker [124]
Do ponto de vista histórico, o conceito de testing surge em 1957, sendo que em 1956 era
o período do debugging1 não existindo diferença entre testes e debugging.
No período de 1957-1978, ocorreu a separação entre testing e debugging. Neste período
também surgiu o conceito de validação formal dos requisitos.
O período de 1979-1982, ficou conhecido como o período destrutivo, onde o objetivo era
encontrar erros no software.
De 1983 a 1987 é classificado como o período orientado à avaliação, em que o objetivo era
que durante o tempo de vida do software, fosse feita uma avaliação do produto e medida
a sua qualidade.
Desde 1988 que vivemos num período de prevenção. É dada importância à correspondência
entre o software e a sua especificação de forma a detetar e prevenir falhas.
— Gelperin and Hetzel [33]
O principal objetivo dos testes nas aplicações Web é correr a aplicação usando combina-
ções de inputs e estados de forma a descobrir falhas no software (Lucca and Fasolino [65]).
Estes testes necessitam de ser vistos como um processo de desenvolvimento que é efetuado
ao longo do projeto e não apenas no final. O processo de desenvolvimento e testes deve
ser visto como um único processo, de forma a tornar os testes o mais eficientes possíveis.
Desta forma é necessário gerir este processo por fases. Logo desde o início quando está
a ser tratada a parte da especificação e requisitos do projeto, os testes devem também ser
planeados. Assim ao longo do projeto, conforme vai sendo construido e codificado, devem
ser executados testes unitários que permitem testar os outputs (Secção 2.3.2), bem como
1 Processo de encontrar e remover um erro específico do programa. Um processo manual.
2.3. Software Testing 7
na fase de integração devem ser corridos os seus respetivos testes. Desta forma, é possível
garantir que o produto resultante está de acordo com os requisitos e especificação antes de
ser lançado (Ammann and Offutt [4]).
Garantir a correta especificação de um projeto é crucial, no entanto é uma tarefa compli-
cada devido à quantidade de cenários possíveis. Apesar dos testes ajudarem nesta tarefa,
a sua implementação torna-se complexa devido às dificuldades inerentes aos testes. De
forma a analisarmos essas dificuldades, podemos dividir a abordagem de testing em 4
fases conformeWhittaker [124]:
• Fase 1 - Modelação do ambiente de software
• Fase 2 - Selecionar cenários de teste
• Fase 3 - Correr e avaliar os cenários de teste
• Fase 4 - Medir o progresso dos testes
Segue-se uma breve descrição de cada uma dessas fases:
fase 1
• Os testers2 têm de identificar e simular as interfaces que um sistema de software usa
e enumerar os inputs por cada interface.
• Os testers têm de entender a interação do utilizador que cai fora do controlo do
software em teste.
Nesta primeira fase os testers deparam-se com dois grandes problemas. Como identificar
e simular as interfaces, uma tarefa complexa, devido aos 4 tipos de interface existentes
(Humanas, Software, Sistema de ficheiros e Comunicação), e a mais complexa e um pouco
imprevisível, como entender a interação do utilizador que cai fora do controlo do software
em teste.
fase 2
• Existe um número infinito de cenários de teste.
Devido à grande quantidade de cenários de teste possíveis, é muito difícil garantir que
todos são abrangidos. Assim a melhor abordagem será gerar o maior número possível de
testes, de forma a tentar cobrir o maior número de cenários.
2 As pessoas que testam o software.
2.3. Software Testing 8
fase 3
• Os testers tentam automatizar os cenários de teste o melhor que conseguirem.
Face à grande quantidade de cenários existem sempre algumas limitações (tecnologia
utilizada) no que toca a automatizar os cenários de teste. Assim o tester tenta automatizar
o melhor que conseguir.
fase 4
• As medidas de contagem dão pouca visão sobre os progressos dos testes.
No final dos testes estarem feitos, surgem sempre perguntas como:
- Será que testei para erros comuns de programação?
- Será que testei todo o código?
- Será que corri todos os cenários que espero que um utilizador execute?
Este tipo de perguntas no final é muito comum, e devido ao erro humano é possível que
algumas tenham uma resposta negativa.
Em suma, existem diversos problemas na escrita e implementação de testes. Problemas
estes que podem ser atenuados com ferramentas de coverage3 e verificação formal, tal
como será analisado mais à frente neste capítulo. De seguida, serão analisados os tipos e
metodologias das ferramentas de teste.
2.3.1 Métodos
Existem três métodos de testing que podem ser aplicados às aplicações Web.
Black box
Figura 1.: Black Box Testing
3 Indica percentagem de código testado
2.3. Software Testing 9
Black box, ou caixa preta, é uma técnica de testing que não contém nenhuma informação
da funcionalidade e estrutura interna do sistema, tal como mostra na Figura 1. Nesta
técnica o tester apenas sabe os inputs e os resultados produzidos, não sabe como o sistema
chegou a esses resultados. Geralmente este método é considerado como teste funcional
(Nidhra [79]).
White Box
Figura 2.: White Box Testing
White box, ou caixa branca, é uma técnica de testing que ao contrário da black box, tem
conhecimento da estrutura e lógica interna. Isto permite, que seja feita uma análise mais
aprofundada, tal como a coverage do código escrito e lógica. Neste caso ao encontrar um
problema o tester tem de verificar no código qual o pedaço que está a causar o problema
(Khan [57]).
Grey Box
Grey box, ou caixa cinza, é uma técnica de testing que aumenta a cobertura dos testes ao
permitirmos focar em todas as camadas de qualquer sistema complexo pela combinação
das duas técnicas referidas anteriormente (Khan [57]). Esta técnica surgiu devido a vários
estudos (Linzhang et al. [63], Chen et al. [20], Liu and Chen [64]), onde sugerem a utilização
de uma técnica que seria uma mistura entre as técnicas de black e white box considerando
tanto a estrutura externa como interna. Esta técnica é também bastante bem adaptada aos
testes de aplicações Web (Acharya and Pandya [1]).
2.3.2 Metodologias
Nesta Secção será feita uma breve análise às várias metodologias de testes existentes, e de
seguida feita uma análise das metodologias focadas nas aplicações Web que se enquadram
no desenvolvimento desta dissertação.
2.3. Software Testing 10
Testes unitários
Unit testing, ou testes unitários são os testes individuais ou de grupos das unidades rela-
cionadas (Ieee [42]). Os testes unitários têm como objetivo garantir que os outputs estejam
de acordo com o estipulado. São feitos por pedaços de código, ou mesmo apenas a uma
função/método de forma a validar o seu funcionamento. Estes testes focam-se em desco-
brir defeitos que são propriedades de todo o sistema em vez dos componentes individuais
(Lucca and Fasolino [65]).
Testes funcionais
O objetivo dos testes funcionais é assegurar a concordância da parte funcional do software
face às suas especificações (Ibrahim and Keshk [41]).
Esta é uma das metodologias de testing mais importante nas aplicações Web, e dado o
contexto em que este estudo se insere, será um dos focos deste trabalho. É aqui que se
consegue garantir que a uma aplicação se encontra de acordo com os requisitos e especifi-
cações. Com esta metodologia de teste verifica-se a sintaxe HTML, links, e muitas outras
componentes das aplicações Web.
Testes de sistema
Com esta metodologia consegue-se garantir que a aplicação Web irá correr de acordo com
o estabelecido nas várias plataformas e browsers de Internet (Beizer [10]).
Testes de stress
Testes de stress são também uma parte importante nas aplicações Web. É necessário garantir
que as aplicações Web (incluindo os servidores) aguentam os pedidos dos utilizadores de
forma eficiente e sem falhar (Patton [87]).
Teste de performance
É necessário garantir que as aplicações Web independentemente da quantidade de utilizado-
res em simultâneo irão responder num tempo aceitável. Estes testes são a forma de garantir
que tal acontece (Weyuker and Vokolos [123]).
Testes de usabilidade
Os testes de usabilidade são geralmente efetuados com um grupo de utilizadores externos,
sem conhecimento da plataforma, que recebem certas tarefas para realizarem e são observa-
dos por uma ou mais pessoas, de forma a obter feedback das dificuldades encontradas por
2.3. Software Testing 11
Tabela 1.: Relacionamento métodos/metodologias
Black Box White Box Grey Box
Unitários X
Funcionais X
Sistema X
Stress X
Performance X
Usabilidade X
Aceitação X
Regressão X X X
Beta X
esses utilizadores. A partir destes testes surgem sugestões de melhorias para a plataforma
(Brinkman et al. [15]).
Testes de aceitação
Estes são o tipo de testes que são feitos pelo cliente para assegurar que o produto vai de
encontro aos requisitos e funciona como previsto. Estes enquadram-se nos testes "black
box".
Testes de regressão
Os testes de regressão são os testes realizados após uma alteração no código do software.
Geralmente devem ser corridos após a implementação de uma funcionalidade/correção,
de forma a garantir que o novo código não introduz erros, e que não afetou o código
existente. Este tipo de testes é muito importante, pois com eles é possível evitar a quebra
de funcionalidades. Este tipo de testes enquadram-se nos testes "black box"(Kim et al. [58]).
Testes beta
Estes são os testes realizados por utilizadores finais, sendo uma equipa fora da área de
desenvolvimento. A ideia é encontrar erros inesperados. Este tipo de testes enquadram-se
nos testes "black box".
2.3.3 Relacionamento métodos/metodologias
Conforme pode ser observado na Tabela 1, é possível verificar para cada metodologia o
seu relacionamento com o tipo de testes. Na sua maior parte pertencem ao Black Box por
não terem conhecimento da lógica interna do sistema. No caso dos testes de regressão é
possível observar que pertencem aos 3 tipos existentes.
2.3. Software Testing 12
2.3.4 Testes nas aplicações WEB
Aplicando o conceito de testing às aplicações Web, é possível dividir as metodologias indi-
cadas anteriormente em dois tipos de verificação, a estática e a dinâmica (Ricca and Tonella
[97]). A estática baseia-se em fazer uma verificação ao nível da página HTML e detetar
falhas. Esta pode passar por verificar os caminhos percorridos peloutilizador ou no ca-
minho que a informação faz de forma a verificar se tudo corre bem. Mais detalhes sobre
a análise estática pode ser encontrado no livro de Ricca and Tonella [96]. Esta verificação
permite também tratar das questões de páginas que não podem ser alcançadas a partir da
página principal. Existem também os casos dos links quebrados que podem ser facilmente
detetados com este tipo de verificação.
A verificação dinâmica já se enquadra no método do white box, pois ao contrário da verifi-
cação estática o código já é executado, e faz validações dos resultados com o esperado. Esta
verificação é efetuada a todos os níveis e tanto pode ser black box como white box (Fairley
[30]).
Figura 3.: Verificação estática e dinâmica
Focando nas metodologias abordadas anteriormente, e dado o contexto em que este es-
tudo se insere, as mais importantes no desenvolvimento desta dissertação serão as de testes
funcionais, de forma a ser possível testar toda a funcionalidade de uma aplicação Web e ve-
rificar se a implementação está de acordo com os requisitos e especificação, bem como os
testes de regressão. Com estas duas metodologias será possível verificar a qualidade da
aplicação Web desenvolvida ao longo de todo o processo de desenvolvimento. Com elas
será possível analisar problemas em links, design, compatibilidades entre browsers desktop
e mobile, entre muitas outras (Ricca and Tonella [98]). O facto de aliar estas metodologias
com a geração de testes automáticos permitirá que este processo se torne bastante simples
2.3. Software Testing 13
de executar.
Na Figura 3 pode observar-se a hierarquia de testes e verificação descritas.
2.3.5 Ferramentas
Nesta secção será feita uma análise das ferramentas que permitem efetuar testes às apli-
cações Web e escolher a que mais se adequa ao contexto em que este estudo está a ser
realizado. Visto o objetivo desde documento ser a aplicação de testes ao nível do browser,
serão apenas apresentadas as ferramentas que o permitem fazer. Como também se pre-
tende reduzir o número de horas investidas em testes de forma a aumentar a rentabilidade
dos projetos, as ferramentas estudadas são apenas as que permitem automatizar todo este
processo.
Selenium [104] é uma ferramenta open-source. Da informação recolhida através de vá-
rios fóruns, páginas e incluindo o grupo oficial de discussão do Selenium, esta é a ferra-
menta mais utilizada pela comunidade de testes de aplicações Web. Usa javascript e iframes
para embutir o sistema de automação de testes no browser, permitindo correr no próprio
browser e utilizar as capacidades dadas por esse browser permitindo controlar a aplicação
Web em teste. Isto permite que os mesmos scripts de teste possam ser utilizados por múlti-
plos browsers e múltiplas plataformas (Holmes and Kellogg [38]). Também está preparada
para funcionar nas versões atuais e mais antigas do Internet Explorer [68], Firefox [76], Ch-
rome [36], Opera [84] e Safari [100], bem com os browsers dos dispositivos móveis.
É uma ferramenta para realizar testes funcionais à aplicação Web. Tem disponível coman-
dos para simular a navegação de um utilizador pelo browser e também permite testar AJAX
devido aos comandos especiais disponíveis(waitForText, waitForCondition, e waitForSelec-
tion).
Tudo isto é possível devido ao Selenium WebDriver, permitindo construir conjuntos ro-
bustos de testes de regressão baseados no browser. Uma grande vantagem do Selenium
WebDriver é também o facto de permitir escalar e distribuir scripts por vários ambientes,
facilitando assim os testes em simultâneo e em maior quantidade.
Esta framework conta também com vários patrocinadores, tais como o BrowserStack [16],
SauceLabs [102], Tricentis [116] e SmartBear [108].
O Selenium WebDriver funciona de forma bastante simples: para cada comando Sele-
nium é criado um pedido HTTP e enviado para o driver do browser que por sua vez usa
o HTTP Server para obter o pedido enviado. De seguida os comandos são executados no
browser e é enviado o estado da execução de volta para o HTTP Server que por sua vez
envia o estado de volta para o script de automatização. Conforme a Figura 4 pode ser
2.3. Software Testing 14
Figura 4.: Funcionamento Selenium Web Driver
Fonte: Quora [92]
observado o seu funcionamento em que o programador fornece as instruções ao driver do
browser, sendo que este é responsável por enviar os comandos ao browser de forma a serem
executados.
Sahi [101] é uma ferramenta open-source que permite gravar um percurso de navegação
numa aplicação web e fazer o replay da mesma nos vários browsers. Tem disponível dri-
vers em várias linguagens para escrever as scripts de teste, suporta Ajax e conteúdos Web
dinâmicos (IBM [39]). É semelhante em características ao Selenium, no entanto dispõe de
duas opções, a versão open-source e a versão PRO que é uma versão paga. É de destacar
alguns dos seus clientes, tais como a Chanel [19], Tesco [111], EMC2 [28] e muitos mais que
podem ser consultados no site oficial [101]. Uma grande vantagem desta ferramenta é a
existência de comandos como near e in que permitem identificar mais facilmente elementos
na estrutura HTML do documento. Outra grande vantagem passa por não existir a preocu-
pação de lidar com os tempos de espera devido ás chamadas AJAX.
A Figura 5 apresenta o funcionamento desta ferramenta, para facilitar a sua compreensão,
que de forma geral, funciona como um servidor proxy, sendo que nos pedidos HTTP efetu-
ados é injetado código Javascript de forma a controlar o browser.
Watir [122] é mais uma ferramenta open-source com a licença BSD [17], com uma grande
comunidade. Esta diferencia-se devido ao facto de ser escrita em Ruby. É de realçar aqui
grandes clientes tais como Oracle [85], Facebook [29] e Yahoo [126]. Uma caraterística impor-
tante é o facto que para executar testes nos vários browsers utiliza o seu próprio WebDriver,
que no entanto é nada mais do que um elemento que incorpora o Selenium WebDriver.
Uma limitação atual da Watir é o facto de apenas ser possível correr uma driver por pro-
cesso Ruby [122]. Outra desvantagem é a quantidade de documentação disponível em
2.3. Software Testing 15
Figura 5.: Funcionamento Sahi
Fonte: ThoughtWorks [114]
comparação com as outras, sendo que neste caso ainda é pouca a documentação disponível
face ás suas concorrentes.
2.3.6 Comparação de ferramentas
Tendo em conta a informação recolhida das páginas oficiais das ferramentas, para o estudo
em causa, bem como no artigo Singh and Tarika [107], foram escolhidas as características
mais importantes, que podem ser visualizadas e comparadas na Tabela 2.
Tabela 2.: Comparação de ferramentas
Selenium Sahi Watir
Open Source Sim Sim Sim
Comunidade Grande Média Grande
Corre em vários browser/SO Sim Sim Sim
Suporte mobile Sim Sim Sim
Suporta o playback em paralelo Sim Sim Sim
Documentação Muita Muita Pouca
Geração de relatórios Sim(Através de bibliotecas) Sim Sim(Plugins)
Preço Grátis $695/ano Grátis
Além destes dados, a partir do artigo Singh and Tarika [107], concluímos que a perfor-
mance é no geral melhor na Selenium, sendo que a Watir ainda se encontra um pouco
abaixo em termos de performance.
2.4. Qualidade 16
2.3.7 Seleção de ferramentas
O estudo comparativo foi apresentado aos responsáveis pela equipa de desenvolvimento
Web da Eurotux. Apesar da Sahi apresentar algumas vantagens perante as outras, tem
uma grande desvantagem, o facto de ter a versão paga. Infelizmente a versão gratuita
da ferramenta é muito limitada, e na Eurotux privilegia-se a utilização de software open
source. Como tal, a escolha seria entre a Selenium e a Watir. Dado o artigo já referido
anteriormente (Singh and Tarika [107]) é possível retirar conclusões bastante pertinentes
a nível de performance, sendo que entre estas duas a Selenium é a que obteve a maior
pontuação. O facto de permitir mais linguagens também é uma mais valia assim como o
facto de ter mais documentação disponível.
Ficou por isso decidido analisar a ferramenta Selenium de formaa garantir que atinge os
objetivos.
2.4 qualidade
2.4.1 Definição
A qualidade do software baseia-se em obter software livre de bugs ou defeitos, que vá
de encontro com os seus requisitos e especificação. A norma ISO 8402-1986 [44] define
qualidade da seguinte forma:
The totality of features and characteristics of a product or service that bears its ability
to satisfy stated or implied needs
— Norma 8402-1986, ISO [44]
A qualidade é importantíssima para que os utilizadores tenham confiança no software,
mas para a conseguir atingir também tem de ser garantido que os testes executados têm
qualidade suficiente. Mas o que é qualidade ao certo?
An attitude you bring to your work wich is reflected in the properties of your product
— Software Quality, Testing & Metrics, Cusick [24]
Mas que atitude deve ser essa? Essa atitude passa por implementar logo desde o início
testes corretos com base nos requisitos do projeto. De forma mais sucinta, a qualidade de
software tem como principal objetivo a normalização de processos de desenvolvimento,
sendo o principal objetivo o de garantir que o produto final satisfaça as expectativas do
cliente.
O fator mais importante para o cliente a nível da qualidade é o perfeito funcionamento
2.4. Qualidade 17
das funcionalidades do software. Estas devem funcionar como esperado e não falhar em
situação alguma.
No entanto desenvolver software com qualidade de acordo com as necessidades do cliente
é uma tarefa complicada. O sucesso, aceitação e falha do software depende do seu nível de
qualidade (Kastro and Bener [56]). No geral, pode ser considerada como o comportamento
satisfatório do produto, que pode ser a nível funcional ou não funcional (Singh and Singh
[106]).
Uma das definições mais completas é dada por Crosby [23]:
The first erroneous assumption is that quality means goodness, or luxury or shininess.
The word “quality” is often used to signify the relative worth of something in such
phrases as “good quality”, “bad quality” and “quality of life” - which means different
things to each and every person. As follows quality must be defined as “conformance
to requirements” if we are to manage it. Consequently, the nonconformance detected is
the absence of quality, quality problems become nonconformance problems, and quality
becomes definable
— Quality is free: The art of making quality certain, Crosby [23]
Assim, é possível afirmar que software de qualidade é software que está apto para a sua
finalidade (Northrop [80]).
2.4.2 Evolução
A preocupação de obter qualidade (Quality Assurance) nos produtos (software ou outro
tipo) já vem desde muito atrás sendo que as suas raízes datam aos tempos da idade média,
mas apenas há 27 anos devido a preocupações de segurança por parte dos serviços militares
dos Estados Unidos da América foi implementado o standard MIL-STD-105E [71], em que
definia Tabelas de referência de forma a fazer verificações de segurança nos equipamentos.
Desde esse momento a preocupação com a qualidade foi sempre crescendo. Conforme a
Figura 6 é possível observar uma descrição da evolução da qualidade ao longos dos últimos
anos, sendo que nos anos 60 existe o controlo de qualidade, nos anos 70 temos a garantia
de qualidade, nos anos 80 evoluiu para a gestão da qualidade, e dos anos 90 até atualmente
evoluiu para a gestão da qualidade total.
Cada vez mais a qualidade é importante no dia a dia. Quer sejam produtos de software,
ou doutra natureza, a qualidade tem de estar presente e cada vez mais esses padrões se
tornam rigorosos.
Podem ser consultadas mais informações acerca da evolução da qualidade em Warrier and
McGillen [121].
2.4. Qualidade 18
Figura 6.: Evolução qualidade
Fonte: Mohamed [74]
Relativamente à qualidade no software foi necessário desenvolver ferramentas que ga-
rantissem através de métodos formais que a sua modelação se encontrava correta (Almeida
et al. [3]). Assim começaram a surgir ferramentas de modelação e análise de abstrações de
software. De seguida será feita uma introdução e análise às linguagens e ferramentas mais
importantes.
2.4.3 Linguagens/Ferramentas de especificação formal
Nesta secção será feita uma análise das linguagens/ferramentas de especificação formal que
permitem validar a especificação de um projeto Web. Com base na investigação efetuada
sobre este tema na pesquisa do Google e dos documentos verificados, foram selecionadas
as linguagens/ferramentas com o maior número de referências encontradas.
VDM [13] ou Vienna Development Method, é uma linguagem de especificação que per-
mite efetuar a modelação de sistemas informáticos e analisar a sua especificação e identificar
defeitos, numa fase inicial do desenvolvimento do projeto (Fitzgerald et al. [31]).
2.4. Qualidade 19
Esta linguagem é originária da IBM, nomeadamente do IBM’s Vienna Laboratory, desen-
volvida em meados de 1970 por Cliff Jones e Dines Bjorner. A VDM também inclui uma
linguagem de especificação chamada VDM-SL (VDM Specification Language) [86].
Após o desenvolvimento da VDM apareceram algumas ferramentas para verificar as espe-
cificações VDM, mas estas ferramentas eram mais para projetos informais. Em 1988, Peter
Froome desenvolveu uma ferramenta chamada SpecBox [2]. Esta ferramenta é utilizada em
sistemas de comboios, segurança e até em instalações nucleares.
Existem também outras ferramentas para verificar a especificação VDM, tais como IFAD
VDM-SL [27] e Centaur-VDM [125] que trazem um ambiente gráfico.
Object-Z / Z [119] é uma extensão da linguagem de especificação Z focada em facili-
tar a especificação utilizando objetos. A linguagem Z foi desenvolvida em 1977 por Jean-
Raymond Abrial na Universidade de Oxford.
Esta linguagem utiliza a notação matemática usada em cálculo lambda.
OCL [83] é uma linguagem declarativa para descrever regras que se aplicam aos mode-
los UML tendo sido desenvolvida na IBM [40]. Inicialmente foi desenhada para ser uma
linguagem de anotações para diagramas UML [82], sem incluir qualquer notação textual
para declarações. No entanto variações da OCL, tais como a USE-OCL [118] ultrapassam
esta limitação.
A OCL é baseada na lógica de primeira ordem, no entanto usa uma sintaxe semelhante às
linguagens de programação e relacionada com a sintaxe do UML. Algumas das ferramen-
tas que suportam o OCL são a Octopus [81], e as Eclipse Model Development Tools [26].
Algumas das funcionalidades são a interpretação de OCL em testes e geração de código.
Esta linguagem tem um problema grande em que não pode ser aplicada a especificações
de tempo real devido à falta da possibilidade de declarar estados e a sua evolução ao longo
do tempo (Clark and Warmer [21]).
Devido a esta restrição não será considerada como opção, visto não se adequar aos objeti-
vos.
Alloy Analyser [72] é uma ferramenta que utiliza a linguagem específica chamada Alloy
[72]. A linguagem é de especificação declarativa para expressar estruturas, e permite cons-
truir modelos utilizando uma técnica baseada no tempo e com base de objetos. O Alloy foi
inspirado pela notação da linguagem Z (Jacky [46]) e foi criada para suportar os chamados
Métodos Formais leves [45]. Esta ferramenta, permite com base na especificação declarada,
2.4. Qualidade 20
gerar testes automáticos e correr os mesmos de forma a garantir que a especificação se
encontra correta e sem falhas.
Tal como a linguagem Z, o Alloy descreve as estruturas em espaço e tempo, com um
número mínimo de notações matemáticas, sendo ainda mais simples que a Z.
No Alloy, tudo são relações e utiliza lógica não especializada o que facilita a escrita.
Permite o acesso a contra exemplos o que é ótimo para se verificar quais os problemas da
especificação. Toda a análise realizada pelo Alloy é feita por redução ao SAT (satisfiability).
O Alloy tem uma característica muito importante para o contexto em que este estudo
se insere: o facto de ser escrito em JAVA e poder ser utilizado como biblioteca. Desta
forma é possível integrar com a ferramenta escolhida para a automação dos testes e juntar
osmétodos formais à automação e geração de testes. Assim, não só se garante que a
especificação se encontra correta, como também os testes executados sobre o projeto de
software.
2.4.4 Comparação de Linguagens/Ferramentas
Com base nas páginas oficiais das linguagens/ferramentas de especificação formal, e nos ar-
tigos Mikusiak et al. [70] e Jones [53] foram identificadas as características mais importantes
sendo apresentadas e comparadas na Tabela 3.
Tabela 3.: Comparação de linguagens/ferramentas qualidade
OCL VDM Object-Z Alloy
Integração fácil com Java Sim Sim Não Sim
Especificações de tempo real Sim Sim(VDM-RT) Não Sim
Lógica de primeira ordem Sim Sim Sim Sim
Permite ser automaticamente analisada Sim Não Não Sim
Notação ASCII Não Não Não Sim
Comparando a linguagem Alloy com a Linguagem Z, uma das vantagens da linguagem
Z face ao Alloy é ter uma notação matemática mais rica tornando-a mais expressiva. No
entanto, o Alloy trabalha melhor com a lógica de primeira ordem [43].
2.4.5 Seleção de ferramentas
O estudo comparativo foi apresentado aos responsáveis pela equipa de desenvolvimento
Web da Eurotux. A escolha recaiu sobre a linguagem Alloy juntamente com a sua ferra-
menta Alloy Analyser. O facto de ter a possibilidade de ser incluído noutro projeto por via
2.5. Análise às ferramentas 21
da biblioteca JAVA é uma enorme vantagem. Assim será possível verificar que os testes
gerados estão corretos, evitando a execução de testes errados que levam à perda de tempo
e induzindo em erro quem analisa os resultados. Ficou por isso decidido analisar a lingua-
gem Alloy em conjunto com a ferramenta Selenium de forma a garantir que juntas atingem
os objetivos a que este estudo se propõe.
2.5 análise às ferramentas
Nesta secção será feita uma análise individual às ferramentas selecionadas de testes e veri-
ficação formal, bem como a possibilidade da utilização de ambas na ferramenta a desenvol-
ver.
2.5.1 Verificação formal - Alloy
Assumindo uma aplicação Web genérica que possui uma página de login, considere-se a
seguinte especificação:
Um utilizador contém apenas um login.
O login é composto por um username e uma password, bem como a relação
para o seu respetivo dono.
Esta especificação, apesar de muito simples, é a mais usual de ser utilizada. Modelando
esta especificação para a linguagem Alloy obtem-se no Código 2.1:
sig Email {}
sig Password {}
sig User {
login: one Login
}
sig Login {
email: one Email ,
password: one Password ,
owner: one User ,
}
fact {
all u:User | u.login.owner = u
}
Código 2.1: Código Alloy
2.5. Análise às ferramentas 22
Neste código verificamos que define os elementos Email e Password, tendo definido o
utilizador como contendo apenas um login (utilizando a palavra one), e o Login como
tendo um Email, uma password, e um utilizador. Temos ainda descrito que para todos os
utilizadores o dono do seu login será ele próprio.
De forma a corrermos este teste basta adicionar a asserção4 com as propriedades a verifi-
car:
assert a {
all l:Login | one l.owner
all u:User | one u.login.email
all u:User | u.login.owner = u
}
check a for 4
Código 2.2: Código Alloy - Asserções
Neste caso estamos a verificar que para todos os logins apenas existe 1 dono, para todos
os utilizadores apenas existe um email associado, e que o dono do login associado é ele
próprio.
De seguida executamos o comando check para validar, sendo que neste momento são
gerados testes e corridos contra o modelo indicado. Ao executar a verificação deste modelo
não é encontrado um contra exemplo, ou seja, a especificação encontra-se correta com base
nas asserções pedidas.
Mas será que esta especificação se encontra mesmo correta? Adicionemos às asserções
a regra "all e:Email | (#e. email = 1)". Esta regra verifica que para todos os emails, um
email apenas pode estar associado a 1 login(campo email do login). Neste caso ao correr
novamente o teste, verificamos que foi encontrado um contra exemplo, pois existe um
email que se encontra associado a dois logins. Tudo isto deriva da má especificação dada
inicialmente, pois faltava especificar que um email apenas pode estar associado a um login,
caso contrário poderia o mesmo email ter várias contas associadas.
Com este teste, foi possível detetar uma falha na especificação de um projeto, e assim
proceder à sua correção.
2.5.2 Testes - Selenium
Com o teste anterior em Alloy verificamos a especificação de um requisito, que agora sa-
bemos que se encontra correta. Assim, agora resta testar de forma funcional esse mesmo
4 Proposição que se julga verdadeira
2.6. Conclusões 23
requisito. Para tal, será utilizada ferramenta Selenium para efetuar essa verificação. Um
teste utilizando o Selenium baseado na especificação pode ser observado no Código 2.3:
from selenium import webdriver
from selenium.webdriver.common.keys import Keys
import time
browser = webdriver.Firefox ()
browser.get("https :// localhost/login.php")
time.sleep (10)
username = browser.find_element_by_id("username")
password = browser.find_element_by_id("password")
username.send_keys("utilizador")
password.send_keys("palavra passe")
login_attempt = browser.find_element_by_xpath("//*[ @type=’submit ’]")
login_attempt.submit ()
Código 2.3: Exemplo código Selenium
Com este teste conseguidos validar se os elementos para o login existem na página, e
conseguimos simular a interação humana e efetuar o login na página. Assim, utilizando
vários testes deste género seria possível testar logins, e até tentar encontrar falhas no sistema
de login.
Este é um simples teste que permite verificar se os campos existem e tentar efetuar o
login na página, mas muito mais é possível através da API do Selenium.
2.5.3 União de ferramentas
Com base nos dois exemplo indicados anteriormente foi possível verificar se a especificação
se encontrava correta e com recurso ao Selenium, verificar a sua componente funcional.
Um ponto a explorar será certamente aproveitar os casos de testes gerados pelo Alloy para
efetuar a verificação da modelação, e injetar esses mesmos casos no Selenium de forma a
garantir de imediato uma enorme quantidade de testes. No entanto, face à complexidade
de tal implementação, esta ficará como trabalho futuro a realizar.
2.6 conclusões
De acordo com o objetivo geral desta dissertação, que é assegurar que o processo de de-
senvolvimento Web da Eurotux se torna mais robusto relativamente à vertente dos testes,
de forma a aumentar a qualidade do software produzido, para que seja possível mitigar os
2.6. Conclusões 24
problemas descritos pela diretora do departamento na entrevista inicial, deste Capítulo é
importante reter o seguinte:
• Apesar das empresas de TI se preocuparem cada vez mais com a qualidade do soft-
ware, muitas deixam de parte um importante segmento de qualquer projeto de soft-
ware: os testes.
• Os testes são por norma realizados manualmente e pela pessoa responsável pela im-
plementação, o que se traduz num enorme erro na medida em que quem programa,
ao testar o seu próprio código já se encontra num ciclo ’vicioso’.
• O foco deste trabalho estará em eliminar a interação humana nos testes, e permitir
correr testes realizados de forma automática logo desde o início de um projeto. No
entanto, para alcançar tal objetivo é necessário garantir que o projeto tem uma boa
especificação. Ou seja, é importante garantir a qualidade da própria especificação,
pois só desta forma é possível avançar com o desenvolvimento do software, e em
simultâneo realizar testes automáticos
• Das várias metodologias de testes existentes, o presente estudo irá focar-se essenci-
almente nos testes funcionais que asseguram a concordância da parte funcional do
software face às suas especificações, e nos testes de regressão que garantem que o
novo código não introduz erros.
• Relativamente à ferramenta de testing, a Eurotux decidiu optar pela utilização do
Selenium. Esta é uma ferramenta open source, com uma forte comunidade e bastante
documentação acessível, permite várias linguagens e temboas classificações ao nível
da performance.
• Quanto à qualidade a escolha da Eurotux foi a linguagem Alloy juntamente com a
sua ferramenta Alloy Analyser. O facto de ter a possibilidade de ser incluído a outro
projeto por via da biblioteca JAVA é uma enorme vantagem. Assim será possível
verificar se os testes gerados estão corretos, e evitar a execução de testes errados que
levam à perda de tempo e induzindo em erro quem analisa os resultados.
• A avaliação realizada ao Selenium e à linguagem Alloy demonstram que é possível
através do Alloy Analyser validar o requisito/especificação e com o Selenium verificar
a sua componente funcional.
Em suma, a escolha passa por Selenium + Alloy. A sua junção permitirá uma sólida e
robusta geração, verificação e execução de testes, de forma automática e simples. Existe
também a vantagem de utilizar ferramentas/linguagens que são open source, ajudando
2.6. Conclusões 25
a comunidade a ter melhor software de forma a podermos garantir a aplicação do selo
representado na Figura 7.
Figura 7.: Selo correção
Fonte: José Nuno Oliveira, MFES - Uminho
Após o estudo das várias metodologias e a escolha das ferramentas/linguagens, importa
agora definir o próximo passo.
2.6.1 Plataforma de testes e verificação
Tendo tido em conta as principais possibilidades de ferramentas/linguagens a utilizar, a
utilização do Selenium (na parte de testing) e Alloy (na parte de qualidade) certamente
apresenta um grande desafio. No entanto, tal como referido anteriormente, é possível
juntar as duas devido à biblioteca Java do Alloy e ao Selenium poder ser codificado em Java,
facilitando assim a integração de ambas. Desta forma, o próximo passo será desenvolver
um projeto Java, que possibilite, dada a especificação do projeto introduzida pelo utilizador,
efetuar uma verificação através do Alloy se essa especificação se encontra correta, e se tal
for verdade então gerar testes e correr automaticamente através do Selenium nas várias
plataformas e browsers.
Assim sendo, o projeto a desenvolver deve ter como base as seguintes características:
• Ser capaz de receber a especificação de um projeto de software Web (por páginas, ou
global);
• Ser capaz de interpretar essa especificação e validar que se encontra correta;
• Gerar com base na especificação os respetivos testes;
• Correr os respetivos testes em diversas plataformas, sistemas operativos e browsers;
2.6. Conclusões 26
• Gerar relatórios com os resultados;
Podem ainda ser consideradas algumas características secundárias, nomeadamente a exe-
cução de todo o processo através do terminal, de forma a poder ser executado remotamente
de forma fácil, e a execução automática ao longo do tempo de forma programada pelo uti-
lizador.
Antes de descrever a arquitetura do projeto a implementar, segue-se no próximo capítulo
uma descrição da ferramenta central deste estudo, o Selenium, assim como a sua história,
origem e evolução.
3
F E R R A M E N TA D E T E S T E S S E L E N I U M
3.1 introdução
Com base na ferramenta identificada no capítulo anterior, de forma a atingir os objetivos
pretendidos de construir um sistema robusto e automático de testes, é necessário analisar
de forma aprofundada a ferramenta de testes Selenium. Assim, neste capítulo será apre-
sentada a sua história, de onde surgiu e como evoluiu. Será também feita uma análise a
todos os seus componentes, sendo esta uma parte importante para o desenvolvimento do
sistema, bem como uma análise às suas principais versões e diferenças entre elas.
3.2 história
O Selenium é uma ferramenta que já existe desde 2004, tendo sido originalmente produzida
por Jason Huggins como uma ferramenta interna da empresa ThoughtWorks [115], com o
objetivo de testar um software de gestão de tempo interno e despesas, escrito em Python e
utilizando a framework Plone. No desenvolvimento desta ferramenta, Jason já contou com
a ajuda de Paul Gross e Jie Tina Wang. Ainda em 2004 foi lançada a primeira versão open
source da ferramenta denominada "Selenium Remote Control (RC)".
Mais tarde, quando Paul Hammant viu a demonstração da ferramenta, começaram a surgir
as ideias de tornar a ferramenta open source, bem como aplicar a casos mais abrangentes
e de forma genérica. Assim, com a ajuda de diversos intervenientes o "Selenium Remote
Control (RC)"foi evoluindo para a ferramenta Selenium que iremos utilizar neste projeto.
Esta ferramenta devido à sua evolução ao longo dos anos dispõe de diversos componentes
que podem ser utilizados, permitindo assim efetuar testes rapidamente e diretamente a
partir do browser, ou construir algo mais robusto de forma a ser possível testar de forma
continua e exaustiva diversas aplicações Web através de uma rede de várias máquinas.
Esta ferramenta conta com o apoio de várias entidades, das quais destacamos Browser
Stack [16] e Sauce Labs [102], empresas que se dedicam a disponibilizar configurações para
27
3.3. Componentes 28
testes mais fáceis na cloud. O nome Selenium surgiu a partir de um email de Jason Huggins
a gozar com o competidor Mercury a indicar que conseguiria curar o envenenamento de
mercúrio ao tomar suplementos de selénio (Selenium em inglês). Os colegas ao ter recebido
o email gostaram do nome e daí surgir o nome da ferramenta.
3.3 componentes
O Selenium, face à sua complexidade encontra-se dividida em 4 componentes. Cada um
destes componentes é responsável por uma parte importante da ferramenta, fornecendo
pequenas funcionalidades, construindo assim no seu todo uma ferramenta especializada
em testes. Na Figura 8 pode ser observada a estrutura da ferramenta, bem como os seus
diversos componentes, nomeadamente o IDE, Remote Control, WebDriver e Grid, que serão
alvo de uma análise nas próximas secções.
Figura 8.: Componentes Selenium
3.3.1 Selenium Remote Control
Este componente é um servidor escrito em Java que permite comandar os browsers e as-
sim efetuar testes a qualquer site HTTP utilizando um browser com javascript ativo. O
Selenium Remote Control é essencialmente divido em duas partes, o servidor que permite
interagir com o browser e efetuar ações como pedidos HTTP, abrir e fechar browsers, e a se-
gunda parte as bibliotecas para os clientes de forma a poder comandar através de diversas
linguagens o servidor e assim, interagir com ele. De forma mais específica, o Selenium Re-
mote Control é responsável por receber os comandos Selenium, executá-los e indicar o seu
resultado ao nosso programa, injetando no browser o seu núcleo, podendo assim executar
os comandos no browser. Por sua vez as bibliotecas do lado do cliente são responsáveis por
3.3. Componentes 29
permitir a partir de várias linguagens interagir com o Selenium Server. Este funcionamento
é o normal na versão 1 do Selenium.
No caso da versão 2 este componente será associado a outro como poderemos ver mais
à frente, alterando um pouco o funcionamento geral, sendo a principal diferença a inclu-
são de um WebDriver API e o abandono da injeção dos comandos através de Javascript.
Atualmente o Selenium Remote Control dispõe de bibliotecas para as linguagens Java [47],
C# [18], Python [91], Ruby [99], PHP [89], Perl [88] e Javascript [48], sendo que toda a
documentação se encontra disponível na página oficial [94].
Na Figura 9 podemos observar o funcionamento geral do Selenium RC. De forma sucinta,
os scripts são enviados ao Servidor Selenium, que irá iniciar e terminar as sessões dos
browsers e efetuar os pedidos HTTP necessários à página de forma a correr os testes.
Figura 9.: Selenium Remote Control
3.3.2 Selenium IDE
O Selenium IDE (Integrated Development Environment) trata-se de um plugin para o brow-
ser Firefox que permite de forma simples gravar, editar e fazer debug sobre testes, sendo
que anteriormente era chamado de Selenium Recorder. Esta ferramenta foi criada por
Shinya Kasatani no Japão e doada ao projeto em 2006. Dispõe também de uma interface
gráfica bastante apelativa, sendo ideal para novos utilizadores que queiram apenas efetuar
testes simples e deforma rápida à sua plataforma Web. Esta ferramenta ao permitir gravar
as ações, faz com que qualquer utilizador possa rapidamente, sem grande custo efetuar os
testes pretendidos.
Toda a documentação pode ser consultada na página oficial [105].
3.3. Componentes 30
Figura 10.: Selenium IDE v2.9.1
3.3.3 Selenium WebDriver
Com a evolução do Selenium, e também dos computadores e da Web, surge a necessidade
de implementar novos sistemas mais robustos para melhorar e ultrapassar algumas limita-
ções dos sistemas antigos utilizados. Assim surge a integração da WebDriver no projeto
Selenium. A Selenium WebDriver foi também pensada de forma a melhorar a compatibili-
dade com páginas Web dinâmicas (AJAX) entre outros aspetos.
Ao efetuar pedidos diretos aos recursos nativos dos browsers disponíveis para automa-
ção a sua execução torna-se mais rápida do que com o Selenium RC, no entanto nem todos
os browsers dispõem das mesmas capacidades, um exemplo disso é no Google Chrome ser
possível aceder aos erros e warnings que aparecem na consola e nos restantes browsers não
existir essa opção, pelo que é importante ter em atenção durante a escrita do teste que este
não falhe por incompatibilidade com o browser.
Juntamente com a Selenium WebDriver veio a sua respetiva API de forma a se poder escre-
ver os testes e interagir com a mesma.
3.3.4 Selenium Grid
A Selenium Grid não é nada mais do que uma rede de nodos interligados a um servidor.
A grid é construida tendo um Servidor centralizado Selenium HUB (Selenium HUB) a ser exe-
cutado, e depois tendo vários nodos com diversos browsers, sistemas operativos e versões
3.3. Componentes 31
a ligarem-se ao Selenium HUB dizendo que estão disponíveis para receber comandos.
Desta forma os pedidos dos testes são feitos diretamente ao Selenium HUB, sendo responsá-
vel por verificar se existe um nodo disponível com as configurações pretendidas e despacha
esse teste para esse nodo. No caso de ser efetuado um pedido ao Selenium HUB e não
existindo nenhum nodo disponível naquele momento, o pedido ficará em lista de espera
até ser possível. Desta forma o Selenium HUB trata de toda a parte de direcionar os testes e
executar de acordo os recursos de cada máquina, otimizando sempre o seu funcionamento.
Esta grid é essencial para o projeto a desenvolver, uma vez que se pretende ter a execução
de múltiplos testes a várias páginas HTTP em simultâneo.
Figura 11.: Selenium Grid
A Figura 11 apresenta como é construida uma Grid do Selenium, sendo possível ligar e
desligar nodos sempre que necessário.
O funcionamento geral é o Selenium HUB ficar à espera de ligações na porta definida, e os
nodos ligam-se ao Selenium HUB através dessa mesma porta, sendo que depois então te-
mos os nodos disponíveis para utilização. No caso de um nodo perder a ligação, é efetuada
uma tentativa de estabelecer a ligação durante um período de tempo estipulado e caso não
seja possível esse nodo é removido da Grid.
Se for necessário verificar quais os nodos que estão disponíveis, bem como browsers e
sistemas operativos, basta aceder pelo browser ao endereço "http://<ip do hub>:<porta do
hub>/grid/console", e rapidamente é apresentada uma visualização geral de toda a Grid
disponível. No caso de um browser estar em uso o ícone é apresentado também com uma
opacidade mais baixa, indicando que está em uso.
3.4. Selenium v2 32
3.4 selenium v2
O Selenium ao atingir a versão 2.0 sofreu grandes alterações, sendo que a principal é a
união dos componentes Selenium RC com o WebDriver, ficando assim com 3 componentes
em vez de 4.
Figura 12.: Componentes Selenium v2
Com esta atualização passaram a ser suportados browsers mais modernos, bem como
inúmeras correções de erros, e melhoramentos na plataforma. No entanto a verdadeira
grande mudança é a união dos componentes e o facto de ter acrescentado a WebDriver API
para Python [91], Ruby [99], Java [47] e C# [18].
Com estas alterações tudo passa a ser corrido nativamente no browser de forma segura
e mais simples, uma vez que a comunicação é feita diretamente ao browser, ao contrário
de anteriormente que seria com o javascript a interagir com o browser. Assim todos os
eventos utilizados no browser são nativos e invocados ao nível do sistema operativo. Um
dos pontos também importantes foi a garantia da compatibilidade do novo sistema com a
grid.
Desta forma cada vez mais o Selenium se tornava uma ferramenta robusta e que muitos
utilizavam. O facto de dispor da nova WebDriver API, uma API bastante simples que
facilita o trabalho de escrever e correr testes.
3.5 selenium v3
Apesar de ainda estar em desenvolvimento, esta versão já se encontra no estado de Beta
e incluí uma grande mudança, sendo que a implementação original do Selenium Remote
3.6. As potencialidades 33
Control (Versão 1) foi removida, forçando todos os utilizadores a abandonar esse tipo de
implementação e mudar para as WebDriver API. Outras alterações são a obrigação de utili-
zar Java 8 (a última versão disponibilizada pela Oracle), o suporte ao Firefox é agora feito
através da Mozilla’s gecko driver, o suporte ao safari é fornecido pelo Mac OS através da
webdriver da Apple, o suporte ao Microsoft Edge é fornecido através do servidor WebDri-
ver da Microsoft, e outra que pode vir a ter impacto na utilização da aplicação produzida é
o abandono do suporte a versão inferiores à 9 do Internet Explorer.
3.6 as potencialidades
Devido ao Selenium se tratar de um projeto open-source recebeu de imediato bastante apoio
da comunidade. Assim, surgem frequentemente novas funcionalidades e melhorias para o
projeto, bem como plugins para várias linguagens. Na página de downloads do Selenium
é possível observar a quantidade de plugins, desenvolvidos por terceiros, disponíveis para
este projeto. Face ao tempo que já existe, também se consegue facilmente obter suporte
para a resolução de vários problemas através de uma simples pesquisa na Web.
A comprovar a importância e dimensão desta ferramenta, a framework Web Django já
possui de raiz a possibilidade da execução de testes através do Selenium, sendo que para
isso apenas é necessário instalar o pacote do Selenium.
Com o Selenium é possível automatizar todo o processo de teste de uma página Web face
ao aspeto funcional, pelo que se pode "simular"totalmente a interação de um ser humano
com a aplicação Web que se está a testar e assim detetar de imediato os mais pequenos erros
que por vezes passam despercebidos ao programador.
O Selenium interage com uma diversidade de browsers (Google Chrome [36], Firefox [76],
Internet Explorer [68], Safari [100], Opera [84] e até o novo browser Edge da Microsoft [67])
e dispositivos (iOS [8], Android [35], Windows Phone [69] ou até mesmo BlackBerry 10
[14]). Um exemplo de utilização é configurar o Selenium para aceder a uma página em dis-
positivos desktop e móveis, e tirar um printscreen a cada, enviado depois um relatório com
as imagens para que possam ser verificadas por alguém para se assegurar que o seu web-
site responsivo não quebrou nada com o último commit que foi efetuado. Num exemplo
mais avançado, essa tarefa pode ser delegada ao Selenium, indicando-lhe as coordenadas
de cada elemento para verificar que nenhum elemento saiu do seu lugar.
3.7. Conclusões 34
3.7 conclusões
Feita a análise aprofundada da ferramenta de Selenium, é possível concluir que vai total-
mente de encontro com o objetivo da automatização de testes. Através do seu servidor
central e da rede de nodos interligados será possível enviar os vários testes e executá-los
nos ambientes pretendidos, obtendo assim uma maior cobertura de casos. Assim, com
base nas necessidades indicadas anteriormente, é necessário construir uma rede de nodos
(Grid) de forma a permitir ter vários ambientes disponíveis para testes, sendo que desta
rede será necessário ter no mínimo duas máquinas, uma a funcionar como Selenium HUB
e outra a funcionar como nodo. Estes nodos devem ter sistemas operativos diferentes, no-
meadamente Windows e Linux, de forma a termos