testes em aplicações web - universidade do minho · testes em aplicações web outubro 2016....

Universidade do MinhoEscola de EngenhariaDepartamento de Informática

Tiago Filipe Andrade Brito

Testes em Aplicações Web

Outubro 2016

Universidade do MinhoEscola de EngenhariaDepartamento de Informática

Tiago Filipe Andrade Brito

Testes em Aplicações Web

Master dissertationMaster Degree in Computer Science

Dissertation supervised byAntónio Luís Pinto Ferreira de SousaDaniela 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 apoiodado ao longo destes anos, por acreditarem em mim e por contribuírem com o seu melhorpara o meu desenvolvimento pessoal e profissional, pois sem eles não seria possível chegaronde cheguei.

Quero também agradecer:

• Ao meu orientador, Prof. António Sousa e à minha diretora Daniela Costa por todotodo o apoio e contribuição dada no desenvolvimento deste estudo.

• A toda a equipa de desenvolvimento Web da Eurotux, por todo o apoio, ideias econhecimento 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 meumelhor 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 runin a Web browser, being commonly known as Web applications. As a method to ensure thequality of these applications, the tests are attracting today more and more attention fromboth the academic and business communities.

Having a well-defined test strategy from the beginning of the project and applying themduring the development phase, ensures the quality of the final software by reducing therisk of unforeseen problems at later stages. Such problems translate into increased costof implementation and reduced profitability of the project to the supplier. It may alsopostpone the projet delivery which result in customer dissatisfaction.

On the other hand, the constant software upgrades, imposed by the highly competitivemarket of today, increase the risk of destroying previously implemented features (calledregression). For this reason, it is required that the testing strategy is not only defined andimplemented during the design, but also after each step of development in order to ensurethat the development does not breaks already existing functionality.

Repeated tests, covering all the software at each delivery, is a challenge to organizationsdue to its high cost and increased possibility of human error.

For all these reasons, the Web development team supervisors at Eurotux supported thisresearch work and allowed the resulting prototype to be applied in real projects, developedover the last few months, thus defining a testing strategy aiming to increase customersatisfaction, 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 throughoutits life cycle.

Some comparative studies were evaluated, being analysed in detail the methodologiesfor functional testing and regression testing, Selenium tools for defining automatic testingintegrated with the Alloy Analyser tool, in order to evaluate the quality of the formalspecification.

After such analysis, a prototype tool named WebTest was developed in order to build andrun automated tests. A report containing the generated test results is then sent to the webapplication 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 testingsoftware 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 paracorrerem 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 aatenção das comunidades académica e empresarial.

Ter uma estratégia de testes bem definida desde o início do projeto, e executar os mesmosdurante a fase de desenvolvimento, além de assegurar a qualidade do software, reduz orisco de surgirem problemas imprevistos numa fase posterior do projeto, que aumentam ocusto de implementação e consequentemente diminuem a rentabilidade do projeto para aempresa fornecedora, e ainda provocam atrasos que normalmente resultam na insatisfaçãodo 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 sejanã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 umdesafio para as organizações, na medida em que o seu custo é elevado, e dado que existe apossibilidade 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 emprojetos reais desenvolvidos ao longo dos últimos meses, com o objetivo de ser definidauma estratégia de testes que permitisse tornar o processo de desenvolvimento Web maisrobusto, aumentando a qualidade das soluções desenvolvidas. Pretendia-se essencialmentedefinir uma estratégia de testes automáticos que diminuísse a possibilidade de erro humanona execução dos testes, e que permitisse aumentar a rentabilidade dos projetos gastandomenos 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 testesde 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 sidoescolhido o Selenium para definição de testes automáticos em conjunto com a ferramentaAlloy Analyser para avaliação da qualidade da especificação.

Após a escolha das ferramentas que mais se adequaram aos objetivos propostos nesteestudo, 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 equipae dos seus responsáveis foi bastante positiva. Com a WebTest foi possível reduzir o tempogasto com os testes nos projetos e garantir a qualidade da solução apesar das alterações derequisitos 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 aser 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 sistemasdesenvolvidos 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 maisextremas, até a perda de vida humana. Exemplo disso, foi o equipamento de radioterapiaTherac-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 deradiação que resultaram em graves problemas, incluindo a morte de alguns.

Para reduzir o risco de falhas, as organizações que desenvolvem software começaramprogressivamente 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 desenvolvimentoWeb desde 2004, têm estas preocupações e têm vindo, ao longo dos anos, a sistematizar oprocesso de desenvolvimento. Uma das falhas desse processo estava sobretudo relacionadocom a qualidade do produto no momento da entrega, e na manutenção da qualidade aolongo 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çãoaprovada pelo cliente. As aplicações Web tipicamente ficam em manutenção a uma velocidademaior do que qualquer outro tipo de sistemas de software e esta manutenção consiste normalmenteem pequenas mudanças incrementais (Kirda et al. [59]).

Na sequência de uma entrevista com a diretora do departamento de desenvolvimentoWeb 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 dostestes 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 todosos erros sejam encontrados e retificados, uma vez que seria necessário uma quantidadeextremamente 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 devemser automatizados e adaptáveis face à constante evolução dos Web browsers, de forma agarantir a estabilidade e perfeição do software desenvolvido.

Perante este cenário, o que se pretende com este trabalho de investigação é assegurarque 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áriosbrowsers de forma automática, bem como linguagens que assegurem a qualidade quer daespecificação, quer da implementação das funcionalidades. Juntando ambas será possívelcorrer testes de forma fácil, simples e recorrente para que seja possível detetar e corrigirtodos 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 esistemas 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íficosde 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 seiscapítulos. No Estado da Arte (Capítulo 2) é feita uma introdução à temática dos testesexplicando 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 softwaree 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çãoda ferramenta de teste e linguagem de modelação escolhidas.No Capítulo 3 é descrita uma análise mais aprofundada da ferramenta que será utilizadapara 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 atingiros objetivos identificados anteriormente. É apresentada a arquitetura do sistema e o seudesenvolvimento.No capítulo 5 são apresentados testes à arquitetura implementada, com recursos a casosreais, bem como uma análise sobre objetivos que foram atingidos ao utilizar o softwaredesenvolvido.Finalmente no capítulo 6, são dadas algumas pistas de uma possível investigação futura, eainda 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 metodologiase ferramentas de testes de software (Selenium [104], Sahi [101] e Watir [122]) e ainda aslinguagens 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ânciados testes na engenharia de software, e termina com a avaliação das ferramentas escolhidase 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 cadavez mais as organizações investem recursos de forma a garantir a qualidade do softwareproduzido (Pressman [90]).

Vários estudos [34, 12] demonstram que apesar das empresas de TI se preocuparem cadavez mais com a qualidade do software, muitas deixam de parte um importante segmentode qualquer projeto de software: os testes. As vantagens e limitações dos testes são bemconhecidas 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 estudoKim 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 estudocompleto 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 autilizaçã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 epela pessoa responsável pela implementação, o que se traduz num enorme erro na medidaem 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 doutilizador 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 asorganizaçõ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 podehaver 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, estemé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çodas tecnologias e dos métodos formais cada vez menos as organizações adotam processosmanuais, optando sempre que possível por processos automáticos. Dado o contexto emque este estudo se insere, o foco deste trabalho estará em eliminar a interação humananos testes, e permitir correr testes realizados de forma automática logo desde o início deum projeto. No entanto, para alcançar tal objetivo é necessário garantir que o projetotem uma boa especificação formal. Ou seja, é importante garantir a qualidade da própriaespecificaçã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 garantirque 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 (Sawantet al. [103]).Erros, ou utilizando o termo inglês Bugs são falhas no software que podem ou não ser


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 comono caso do Therac-25 [60] referido anteriormente. Outros exemplos de falhas graves são obug 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-sede 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 ascapacidades 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 erao 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íodotambé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 eraencontrar erros no software.De 1983 a 1987 é classificado como o período orientado à avaliação, em que o objetivo eraque durante o tempo de vida do software, fosse feita uma avaliação do produto e medidaa sua qualidade.Desde 1988 que vivemos num período de prevenção. É dada importância à correspondênciaentre 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 é efetuadoao longo do projeto e não apenas no final. O processo de desenvolvimento e testes deveser 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 serplaneados. Assim ao longo do projeto, conforme vai sendo construido e codificado, devemser 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.


na fase de integração devem ser corridos os seus respetivos testes. Desta forma, é possívelgarantir que o produto resultante está de acordo com os requisitos e especificação antes deser 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. Deforma a analisarmos essas dificuldades, podemos dividir a abordagem de testing em 4

fases conforme Whittaker [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 usae enumerar os inputs por cada interface.

• Os testers têm de entender a interação do utilizador que cai fora do controlo dosoftware em teste.

Nesta primeira fase os testers deparam-se com dois grandes problemas. Como identificare 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 poucoimprevisível, como entender a interação do utilizador que cai fora do controlo do softwareem 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 quetodos são abrangidos. Assim a melhor abordagem será gerar o maior número possível detestes, de forma a tentar cobrir o maior número de cenários.

2 As pessoas que testam o software.


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 (tecnologiautilizada) no que toca a automatizar os cenários de teste. Assim o tester tenta automatizaro 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 quealgumas tenham uma resposta negativa.

Em suma, existem diversos problemas na escrita e implementação de testes. Problemasestes que podem ser atenuados com ferramentas de coverage3 e verificação formal, talcomo será analisado mais à frente neste capítulo. De seguida, serão analisados os tipos emetodologias 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


Black box, ou caixa preta, é uma técnica de testing que não contém nenhuma informaçãoda funcionalidade e estrutura interna do sistema, tal como mostra na Figura 1. Nestatécnica o tester apenas sabe os inputs e os resultados produzidos, não sabe como o sistemachegou 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, temconhecimento da estrutura e lógica interna. Isto permite, que seja feita uma análise maisaprofundada, tal como a coverage do código escrito e lógica. Neste caso ao encontrar umproblema 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 aopermitirmos focar em todas as camadas de qualquer sistema complexo pela combinaçãodas duas técnicas referidas anteriormente (Khan [57]). Esta técnica surgiu devido a váriosestudos (Linzhang et al. [63], Chen et al. [20], Liu and Chen [64]), onde sugerem a utilizaçãode uma técnica que seria uma mistura entre as técnicas de black e white box considerandotanto a estrutura externa como interna. Esta técnica é também bastante bem adaptada aostestes 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 deseguida feita uma análise das metodologias focadas nas aplicações Web que se enquadramno desenvolvimento desta dissertação.


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 estejamde acordo com o estipulado. São feitos por pedaços de código, ou mesmo apenas a umafunçã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 softwareface às suas especificações (Ibrahim and Keshk [41]).Esta é uma das metodologias de testing mais importante nas aplicações Web, e dado ocontexto em que este estudo se insere, será um dos focos deste trabalho. É aqui que seconsegue 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 outrascomponentes das aplicações Web.

Testes de sistema

Com esta metodologia consegue-se garantir que a aplicação Web irá correr de acordo como 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 garantirque as aplicações Web (incluindo os servidores) aguentam os pedidos dos utilizadores deforma 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 garantirque 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


Tabela 1.: Relacionamento métodos/metodologias

Black Box White Box Grey Box

Unitários XFuncionais XSistema XStress XPerformance XUsabilidade XAceitação XRegressão X X XBeta 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 deencontro aos requisitos e funciona como previsto. Estes enquadram-se nos testes "blackbox".

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ódigoexistente. Este tipo de testes é muito importante, pois com eles é possível evitar a quebrade 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 dedesenvolvimento. A ideia é encontrar erros inesperados. Este tipo de testes enquadram-senos testes "black box".

2.3.3 Relacionamento métodos/metodologias

Conforme pode ser observado na Tabela 1, é possível verificar para cada metodologia oseu relacionamento com o tipo de testes. Na sua maior parte pertencem ao Black Box pornã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.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 detetarfalhas. Esta pode passar por verificar os caminhos percorridos pelo utilizador ou no ca-minho que a informação faz de forma a verificar se tudo corre bem. Mais detalhes sobrea análise estática pode ser encontrado no livro de Ricca and Tonella [96]. Esta verificaçãopermite também tratar das questões de páginas que não podem ser alcançadas a partir dapágina principal. Existem também os casos dos links quebrados que podem ser facilmentedetetados 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. Estaverificaçã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 testesfuncionais, 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 ostestes de regressão. Com estas duas metodologias será possível verificar a qualidade daaplicação Web desenvolvida ao longo de todo o processo de desenvolvimento. Com elasserá possível analisar problemas em links, design, compatibilidades entre browsers desktope mobile, entre muitas outras (Ricca and Tonella [98]). O facto de aliar estas metodologiascom a geração de testes automáticos permitirá que este processo se torne bastante simples


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 serrealizado. 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 rentabilidadedos projetos, as ferramentas estudadas são apenas as que permitem automatizar todo esteprocesso.

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 iframespara embutir o sistema de automação de testes no browser, permitindo correr no própriobrowser e utilizar as capacidades dadas por esse browser permitindo controlar a aplicaçãoWeb 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á preparadapara 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 AJAXdevido 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 SeleniumWebDriver é 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 usao HTTP Server para obter o pedido enviado. De seguida os comandos são executados nobrowser e é enviado o estado da execução de volta para o HTTP Server que por sua vezenvia o estado de volta para o script de automatização. Conforme a Figura 4 pode ser


Figura 4.: Funcionamento Selenium Web Driver

Fonte: Quora [92]

observado o seu funcionamento em que o programador fornece as instruções ao driver dobrowser, sendo que este é responsável por enviar os comandos ao browser de forma a seremexecutados.

Sahi [101] é uma ferramenta open-source que permite gravar um percurso de navegaçãonuma 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 Webdinâmicos (IBM [39]). É semelhante em características ao Selenium, no entanto dispõe deduas opções, a versão open-source e a versão PRO que é uma versão paga. É de destacaralguns dos seus clientes, tais como a Chanel [19], Tesco [111], EMC2 [28] e muitos mais quepodem ser consultados no site oficial [101]. Uma grande vantagem desta ferramenta é aexistência de comandos como near e in que permitem identificar mais facilmente elementosna 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 grandecomunidade. Esta diferencia-se devido ao facto de ser escrita em Ruby. É de realçar aquigrandes 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


Figura 5.: Funcionamento Sahi

Fonte: ThoughtWorks [114]

comparação com as outras, sendo que neste caso ainda é pouca a documentação disponívelface á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 estudoem causa, bem como no artigo Singh and Tarika [107], foram escolhidas as característicasmais importantes, que podem ser visualizadas e comparadas na Tabela 2.

Tabela 2.: Comparação de ferramentas

Selenium Sahi Watir

Open Source Sim Sim SimComunidade Grande Média GrandeCorre em vários browser/SO Sim Sim SimSuporte mobile Sim Sim SimSuporta o playback em paralelo Sim Sim SimDocumentação Muita Muita PoucaGeraçã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 poucoabaixo 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 desenvolvimentoWeb da Eurotux. Apesar da Sahi apresentar algumas vantagens perante as outras, temuma grande desvantagem, o facto de ter a versão paga. Infelizmente a versão gratuitada ferramenta é muito limitada, e na Eurotux privilegia-se a utilização de software opensource. Como tal, a escolha seria entre a Selenium e a Watir. Dado o artigo já referidoanteriormente (Singh and Tarika [107]) é possível retirar conclusões bastante pertinentesa nível de performance, sendo que entre estas duas a Selenium é a que obteve a maiorpontuação. O facto de permitir mais linguagens também é uma mais valia assim como ofacto de ter mais documentação disponível.Ficou por isso decidido analisar a ferramenta Selenium de forma a garantir que atinge osobjetivos.

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] definequalidade da seguinte forma:

The totality of features and characteristics of a product or service that bears its abilityto 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êmqualidade 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íciotestes corretos com base nos requisitos do projeto. De forma mais sucinta, a qualidade desoftware 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 docliente.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 emsituaçã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 dequalidade (Kastro and Bener [56]). No geral, pode ser considerada como o comportamentosatisfató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 suchphrases as “good quality”, “bad quality” and “quality of life” - which means differentthings to each and every person. As follows quality must be defined as “conformanceto requirements” if we are to manage it. Consequently, the nonconformance detected isthe absence of quality, quality problems become nonconformance problems, and qualitybecomes 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 suafinalidade (Northrop [80]).

2.4.2 Evolução

A preocupação de obter qualidade (Quality Assurance) nos produtos (software ou outrotipo) 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 militaresdos Estados Unidos da América foi implementado o standard MIL-STD-105E [71], em quedefinia 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 aFigura 6 é possível observar uma descrição da evolução da qualidade ao longos dos últimosanos, sendo que nos anos 60 existe o controlo de qualidade, nos anos 70 temos a garantiade qualidade, nos anos 80 evoluiu para a gestão da qualidade, e dos anos 90 até atualmenteevoluiu 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 setornam rigorosos.Podem ser consultadas mais informações acerca da evolução da qualidade em Warrier andMcGillen [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 (Almeidaet al. [3]). Assim começaram a surgir ferramentas de modelação e análise de abstrações desoftware. De seguida será feita uma introdução e análise às linguagens e ferramentas maisimportantes.

2.4.3 Linguagens/Ferramentas de especificação formal

Nesta secção será feita uma análise das linguagens/ferramentas de especificação formal quepermitem validar a especificação de um projeto Web. Com base na investigação efetuadasobre este tema na pesquisa do Google e dos documentos verificados, foram selecionadasas 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 identificardefeitos, 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 umalinguagem 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, PeterFroome desenvolveu uma ferramenta chamada SpecBox [2]. Esta ferramenta é utilizada emsistemas de comboios, segurança e até em instalações nucleares.Existem também outras ferramentas para verificar a especificação VDM, tais como IFADVDM-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 umalinguagem de anotações para diagramas UML [82], sem incluir qualquer notação textualpara declarações. No entanto variações da OCL, tais como a USE-OCL [118] ultrapassamesta limitação.A OCL é baseada na lógica de primeira ordem, no entanto usa uma sintaxe semelhante àslinguagens 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çõesde tempo real devido à falta da possibilidade de declarar estados e a sua evolução ao longodo 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 foiinspirado pela notação da linguagem Z (Jacky [46]) e foi criada para suportar os chamadosMé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 seencontra correta e sem falhas.

Tal como a linguagem Z, o Alloy descreve as estruturas em espaço e tempo, com umnú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 daespecificaçã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 estudose insere: o facto de ser escrito em JAVA e poder ser utilizado como biblioteca. Destaforma é possível integrar com a ferramenta escolhida para a automação dos testes e juntaros métodos formais à automação e geração de testes. Assim, não só se garante que aespecificação se encontra correta, como também os testes executados sobre o projeto desoftware.

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 importantessendo apresentadas e comparadas na Tabela 3.

Tabela 3.: Comparação de linguagens/ferramentas qualidadeOCL VDM Object-Z Alloy

Integração fácil com Java Sim Sim Não SimEspecificações de tempo real Sim Sim(VDM-RT) Não SimLógica de primeira ordem Sim Sim Sim SimPermite ser automaticamente analisada Sim Não Não SimNotação ASCII Não Não Não Sim

Comparando a linguagem Alloy com a Linguagem Z, uma das vantagens da linguagemZ face ao Alloy é ter uma notação matemática mais rica tornando-a mais expressiva. Noentanto, 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 desenvolvimentoWeb 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 testesgerados estão corretos, evitando a execução de testes errados que levam à perda de tempoe 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 atingemos 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 aseguinte 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. Modelandoesta 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 outilizador como contendo apenas um login (utilizando a palavra one), e o Login comotendo um Email, uma password, e um utilizador. Temos ainda descrito que para todos osutilizadores 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.ownerall u:User | one u.login.emailall 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 todosos utilizadores apenas existe um email associado, e que o dono do login associado é elepróprio.

De seguida executamos o comando check para validar, sendo que neste momento sãogerados testes e corridos contra o modelo indicado. Ao executar a verificação deste modelonão é encontrado um contra exemplo, ou seja, a especificação encontra-se correta com basenas asserções pedidas.Mas será que esta especificação se encontra mesmo correta? Adicionemos às asserçõesa regra "all e:Email | (#e. email = 1)". Esta regra verifica que para todos os emails, umemail apenas pode estar associado a 1 login(campo email do login). Neste caso ao corrernovamente o teste, verificamos que foi encontrado um contra exemplo, pois existe umemail que se encontra associado a dois logins. Tudo isto deriva da má especificação dadainicialmente, 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 assimproceder à 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. Umteste utilizando o Selenium baseado na especificação pode ser observado no Código 2.3:

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysimport 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, econseguimos simular a interação humana e efetuar o login na página. Assim, utilizandovários testes deste género seria possível testar logins, e até tentar encontrar falhas no sistemade login.

Este é um simples teste que permite verificar se os campos existem e tentar efetuar ologin 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çãose 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 paraefetuar a verificação da modelação, e injetar esses mesmos casos no Selenium de forma agarantir de imediato uma enorme quantidade de testes. No entanto, face à complexidadede 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 permitircorrer testes realizados de forma automática logo desde o início de um projeto. Noentanto, para alcançar tal objetivo é necessário garantir que o projeto tem uma boaespecificaçã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 emsimultâ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 dosoftware face às suas especificações, e nos testes de regressão que garantem que onovo código não introduz erros.

• Relativamente à ferramenta de testing, a Eurotux decidiu optar pela utilização doSelenium. Esta é uma ferramenta open source, com uma forte comunidade e bastantedocumentação acessível, permite várias linguagens e tem boas classificações ao nívelda performance.

• Quanto à qualidade a escolha da Eurotux foi a linguagem Alloy juntamente com asua ferramenta Alloy Analyser. O facto de ter a possibilidade de ser incluído a outroprojeto por via da biblioteca JAVA é uma enorme vantagem. Assim será possívelverificar se os testes gerados estão corretos, e evitar a execução de testes errados quelevam à perda de tempo e induzindo em erro quem analisa os resultados.

• A avaliação realizada ao Selenium e à linguagem Alloy demonstram que é possívelatravés do Alloy Analyser validar o requisito/especificação e com o Selenium verificara sua componente funcional.

Em suma, a escolha passa por Selenium + Alloy. A sua junção permitirá uma sólida erobusta geração, verificação e execução de testes, de forma automática e simples. Existetambé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 selorepresentado 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, importaagora 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, autilização do Selenium (na parte de testing) e Alloy (na parte de qualidade) certamenteapresenta um grande desafio. No entanto, tal como referido anteriormente, é possíveljuntar 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á desenvolverum 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 talfor verdade então gerar testes e correr automaticamente através do Selenium nas váriasplataformas 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, ouglobal);

• 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 remotamentede 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ítulouma 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 objetivospretendidos de construir um sistema robusto e automático de testes, é necessário analisarde 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 atodos os seus componentes, sendo esta uma parte importante para o desenvolvimento dosistema, 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 produzidapor Jason Huggins como uma ferramenta interna da empresa ThoughtWorks [115], com oobjetivo de testar um software de gestão de tempo interno e despesas, escrito em Python eutilizando a framework Plone. No desenvolvimento desta ferramenta, Jason já contou coma ajuda de Paul Gross e Jie Tina Wang. Ainda em 2004 foi lançada a primeira versão opensource da ferramenta denominada "Selenium Remote Control (RC)".Mais tarde, quando Paul Hammant viu a demonstração da ferramenta, começaram a surgiras ideias de tornar a ferramenta open source, bem como aplicar a casos mais abrangentese de forma genérica. Assim, com a ajuda de diversos intervenientes o "Selenium RemoteControl (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 componentesque podem ser utilizados, permitindo assim efetuar testes rapidamente e diretamente apartir do browser, ou construir algo mais robusto de forma a ser possível testar de formacontinua 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 BrowserStack [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 Hugginsa gozar com o competidor Mercury a indicar que conseguiria curar o envenenamento demercúrio ao tomar suplementos de selénio (Selenium em inglês). Os colegas ao ter recebidoo 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 umdestes componentes é responsável por uma parte importante da ferramenta, fornecendopequenas funcionalidades, construindo assim no seu todo uma ferramenta especializadaem testes. Na Figura 8 pode ser observada a estrutura da ferramenta, bem como os seusdiversos componentes, nomeadamente o IDE, Remote Control, WebDriver e Grid, que serãoalvo 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. OSelenium Remote Control é essencialmente divido em duas partes, o servidor que permiteinteragir 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 diversaslinguagens 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 seuresultado ao nosso programa, injetando no browser o seu núcleo, podendo assim executaros 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 adocumentaçã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 dosbrowsers 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, sendoque anteriormente era chamado de Selenium Recorder. Esta ferramenta foi criada porShinya Kasatani no Japão e doada ao projeto em 2006. Dispõe também de uma interfacegráfica bastante apelativa, sendo ideal para novos utilizadores que queiram apenas efetuartestes simples e de forma rápida à sua plataforma Web. Esta ferramenta ao permitir gravaras ações, faz com que qualquer utilizador possa rapidamente, sem grande custo efetuar ostestes 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 necessidadede implementar novos sistemas mais robustos para melhorar e ultrapassar algumas limita-ções dos sistemas antigos utilizados. Assim surge a integração da WebDriver no projetoSelenium. 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 todosos browsers dispõem das mesmas capacidades, um exemplo disso é no Google Chrome serpossível aceder aos erros e warnings que aparecem na consola e nos restantes browsers nãoexistir essa opção, pelo que é importante ter em atenção durante a escrita do teste que estenã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 despachaesse teste para esse nodo. No caso de ser efetuado um pedido ao Selenium HUB e nãoexistindo nenhum nodo disponível naquele momento, o pedido ficará em lista de esperaaté ser possível. Desta forma o Selenium HUB trata de toda a parte de direcionar os testes eexecutar 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çãode 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 edesligar nodos sempre que necessário.O funcionamento geral é o Selenium HUB ficar à espera de ligações na porta definida, e osnodos 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, é efetuadauma tentativa de estabelecer a ligação durante um período de tempo estipulado e caso nãoseja possível esse nodo é removido da Grid.

Se for necessário verificar quais os nodos que estão disponíveis, bem como browsers esistemas operativos, basta aceder pelo browser ao endereço "http://<ip do hub>:<porta dohub>/grid/console", e rapidamente é apresentada uma visualização geral de toda a Griddisponível. No caso de um browser estar em uso o ícone é apresentado também com umaopacidade 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 é aunião dos componentes Selenium RC com o WebDriver, ficando assim com 3 componentesem vez de 4.

Figura 12.: Componentes Selenium v2

Com esta atualização passaram a ser suportados browsers mais modernos, bem comoinúmeras correções de erros, e melhoramentos na plataforma. No entanto a verdadeiragrande mudança é a união dos componentes e o facto de ter acrescentado a WebDriver APIpara Python [91], Ruby [99], Java [47] e C# [18].Com estas alterações tudo passa a ser corrido nativamente no browser de forma segurae mais simples, uma vez que a comunicação é feita diretamente ao browser, ao contráriode anteriormente que seria com o javascript a interagir com o browser. Assim todos oseventos utilizados no browser são nativos e invocados ao nível do sistema operativo. Umdos pontos também importantes foi a garantia da compatibilidade do novo sistema com agrid.

Desta forma cada vez mais o Selenium se tornava uma ferramenta robusta e que muitosutilizavam. O facto de dispor da nova WebDriver API, uma API bastante simples quefacilita 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 Betae 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 deimplementaçã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 feitoatravés da Mozilla’s gecko driver, o suporte ao safari é fornecido pelo Mac OS através dawebdriver 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 apoioda comunidade. Assim, surgem frequentemente novas funcionalidades e melhorias para oprojeto, 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 paraeste projeto. Face ao tempo que já existe, também se consegue facilmente obter suportepara 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 paraisso apenas é necessário instalar o pacote do Selenium.

Com o Selenium é possível automatizar todo o processo de teste de uma página Web faceao aspeto funcional, pelo que se pode "simular"totalmente a interação de um ser humanocom a aplicação Web que se está a testar e assim detetar de imediato os mais pequenos errosque 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 comas 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 exemplomais avançado, essa tarefa pode ser delegada ao Selenium, indicando-lhe as coordenadasde 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 servidorcentral e da rede de nodos interligados será possível enviar os vários testes e executá-losnos ambientes pretendidos, obtendo assim uma maior cobertura de casos. Assim, combase 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 destarede será necessário ter no mínimo duas máquinas, uma a funcionar como Selenium HUBe outra a funcionar como nodo. Estes nodos devem ter sistemas operativos diferentes, no-meadamente Windows e Linux, de forma a termos acesso aos browsers Internet Explorer,Edge, Chrome, Firefox e Opera. No caso de existir a necessidade de utilizar outro browser,facilmente este objetivo pode ser alcançado ligando uma nova máquina ao Selenium HUB.

4

F E R R A M E N TA D E A U T O M A Ç Ã O D E T E S T E S E Q U A L I D A D E -W E B T E S T

4.1 introdução

Após a análise que incluiu um conjunto de ferramentas e a avaliação das suas potenciali-dades, é necessário implementar uma solução que inclua o software de testing Selenium eque permita facilmente e de forma programada efetuar testes aos websites, bem como pos-sibilitar a execução de testes escritos em específico para um projeto. Assim, neste capítuloserá explicado todo o desenvolvimento efetuado da ferramenta denominada por WebTest,responsável pela automatização da execução de testes, as decisões tomadas e os problemase soluções encontradas.

Após análise mais aprofundada das características indicadas no capítulo 2 foram defini-dos os seguintes requisitos para aplicação:

• Permitir a execução de todo o processo através do terminal, de forma a poder serexecutado remotamente;

• Execução automática ao longo do tempo de forma programada pelo utilizador;

• Correr testes em diversas plataformas, sistemas operativos e browsers;

• Gerar relatórios com os resultados;

• Permitir a execução de classes de testes externas ao projeto;

• Leitura de ficheiros JSON com as configurações dos testes;

• Implementação de testes genéricos e possíveis de aplicar a qualquer página Web;

• Permitir a criação do ficheiro de configuração de testes de forma simples;

• Ser possível receber uma especificação em Alloy e validar se está correta.

Concluída a identificação dos requisitos a implementar na nova solução, foi elaboradoum cronograma do projeto, conforme a Tabela 4.

35

4.2. Ambiente de desenvolvimento 36

Tabela 4.: Planeamento desenvolvimento

Fev Mar Abr Mai Jun Jul Ago Set

Preparação ambiente desenvolvimento •(Secção 4.2)

Estudo arquitetura (Secção 4.3) •Implementação (Capítulo 4) • • • • • •Testes e avaliação de desempenho •

(Capítulo 5)

Cada uma das fases apresentadas no cronograma da Tabela 4, encontra-se descrita nasrespetivas secções. No entanto, é pertinente desde já, subdividir a fase de implementaçãonas seguintes tarefas:

- Carregamento de ficheiros (Secção 4.4)

- Ligação ao Selenium Grid (Secção 4.5)

- Identificação e implementação de testes genéricos (Secção 4.6)

- Implementação de mecanismo de testes específicos (Secção 4.7)

- Implementação do paralelismo (Secção 4.8)

- Validação de modelos Alloy (Secção 4.9)

- Geração de relatórios (Secção 4.10)

- Implementação da interface gráfica (Secção 4.11)

Concluindo, este capítulo encontra-se dividido em várias secções, sendo que cada umadelas pretende descrever pormenorizadamente o desenvolvimento efetuado para atingircada uma das funcionalidades necessárias.

4.2 ambiente de desenvolvimento

Conforme verificado na Tabela 4 o primeiro passo trata-se da preparação do ambiente dedesenvolvimento. Após a análise efetuada, e por conhecimento prévio das tecnologias aserem utilizadas, foi selecionado o sistema operativo Linux Mint [62], e o IDE IntelliJ IDEA[51] para o desenvolvimento da ferramenta WebTest. De forma a assegurar o histórico dasmodificações ao código, e garantir que não existiam perdas será também utilizado o sistemade controlo de versões SVN [7].

4.3. Arquitetura 37

4.3 arquitetura

Figura 13.: Estrutura aplicação WebTest

Na Figura 13 pode ser verificado que o projeto divide-se em 5 módulos principais, sendoque 4 deles irão corresponder a packages Java, e outro a uma ferramenta externa.O seu funcionamento é simples, sendo que o projeto receberá um ficheiro no formato JSONque deverá ser interpretado pela aplicação através do package File. De seguida através dopackage General irão ser carregados todos os testes e comunicado ao Selenium HUB ostestes a executar, que por sua vez delega aos nodos do Selenium. Por fim a aplicação recebeas respostas necessárias do Selenium HUB e processa essas mesmas respostas, onde depoisé indicado o resultado através do Exit Code1 do programa. Todos os packages serão alvode uma análise aprofundada nas próximas secções.

4.3.1 Dependências

Para o correto funcionamento do projeto, é necessário também proceder a uma análisedas dependências necessárias. Após essa análise foi concluído que seriam necessárias asseguintes dependências, sendo todas elas incluídas através do Maven2:

SELENIUM V2.53.1 [104] Esta será uma das principais dependências do projeto. Esta depen-dência é necessária de forma a ser possível aceder a todas as funcionalidades do

1 Código de saída do programa. Indica o seu resultado.2 Sistema de gestão de dependências

4.4. Carregamento de ficheiros 38

Selenium e interagir com os WebDrivers. Será através desta que é feita a comunicaçãocom o Selenium HUB.

JUNIT V4.12 [54] Visto estarmos a desenvolver uma plataforma direcionada a testes, é in-cluído também o JUnit, de forma a ser possível utilizar os seus comandos para calcularo resultado final da execução dos testes.

JUNIT TOOLBOX V2.2 [66] Esta é uma extensão ao JUnit desenvolvida Michael Tamm quedispõe de uma classe denominada por "ParallelParameterized"que permite ter testesparametrizados em paralelo, ultrapassando assim esta limitação do JUnit.

GSON V2.7 [37] Gson da Google é a responsável por toda a interpretação do ficheiro JSON,visto converter JSON para objetos em Java e vice versa.

EXTENT REPORTS V2.41.1 [6] Esta dependência foi desenvolvida por Anshoo Arora e permiteter um relatório produzido em .html com gráficos e bastantes detalhes da execuçãode cada teste.

JCOMMANDER V1.48 [49] Disponibiliza uma forma simples de tratar de parâmetros no soft-ware produzido.

UNIREST JAVA V1.4.9 [117] Devido a ser necessário interagir com serviços externos direta-mente, foi adicionada esta dependência que dispõe de um conjunto de bibliotecas depedidos HTTP.

SIMPLE JAVA MAIL V4.1.1 [11] Uma vez que a aplicação vai ser executada de forma progra-mada, é necessário também proceder ao envio de emails com os relatórios, sendo estaa função desta dependência.

JGOODIES FORMS V1.9.0 [52] Visto também ser necessária uma interface gráfica, foi adicio-nada esta dependência de forma a fornecer alguns componentes gráficos.

4.4 carregamento de ficheiros

Todo o código responsável pelo carregamentos de ficheiros no formato JSON, encontra-seno package denominado como "file". Neste package encontram-se todas as classes necessá-rias que descrevem o formato de um ficheiro JSON que o programa irá ler. Com recurso àbiblioteca Gson [37], é possível traduzir um ficheiro JSON num objeto Java de forma muitosimples, bem como o contrário.


4.4.1 O ficheiro

O ficheiro JSON recebido com as configurações dos testes a correr, bem como as configura-ções gerais encontra-se dividido em 4 secções, nomeadamente configurações gerais, testesa correr, classes de teste externas e modelos Alloy.

Um exemplo completo deste ficheiro poderá ser encontrado no Apêndice E.

Configurações gerais

Nas configurações gerais apenas é necessário indicar 3 parâmetros, o "reports_path"queindica o caminho onde todos os relatórios gerados das execuções serão guardados, o"test_name"onde deve ser indicado um nome que identifique o teste, e o "selenium_address"quedeve conter o endereço para o Selenium HUB.

"general_config":

"reports_path": "/home/tfb/projects/webtest -report/","test_name": "Main","selenium_address": "http ://127.0.0.1:4444/ wd/hub"

,

Código 4.1: JSON - Configuração geral

Testes a correr

Dos testes genéricos já embutidos no software, nesta secção estão identificados os que sepretende executar e os seus respetivos parâmetros. Esta parte do ficheiro é muito simplista,pelo que deve receber um objeto JSON com a chave e o nome do teste. No interior desseobjeto deve ser sempre incluído a indicação dos ambientes onde se pretende executar orespetivo teste. Essa indicação é dada pela declaração de um objeto denominado por "exe-cute_on", onde é possível indicar:

• platform - O sistema operativo onde deve ser executado o teste.

• browser - O browser onde será executado

• version - A versão do browser

Exemplo:


"execute_on": [

"platform": "LINUX","browser": "chrome"

],

Código 4.2: JSON - Objeto configuração ambiente

No caso deste objeto, no mínimo o browser tem de ser indicado, sendo que no caso deser o único mencionado, o sistema irá admitir como sistema operativo um qualquer, bemcomo a versão.De seguida é necessário também indicar um objeto ’data’ que tem como objetivo passar osparâmetros necessários ao teste para executar, parâmetros esses que podem ser:

• url - O URL da página onde deve ser executado o teste (Este endereço pode ser relativoou completo como pode ser visto na secção 4.12)

• expected - O valor que o teste deveria obter, por exemplo no caso da verificação dotítulo da página

• form_id - O id do formulário em questão a testar

• form_data - A lista de objetos com exemplos de inputs para submeter em formulários

Neste objeto, no mínimo o url tem de ser indicado

"data": [

"url": "https ://www.websiteexemplo.pt/","expected": "WebSite"

,

"url": "https ://www.websiteexemplo.pt/seccao/noticias/","expected": "WebSite - Notícias"

]

Código 4.3: JSON - Objeto data


Classes de testes externas a correr

Visto uma das funcionalidades principais do software necessária ser o da inclusão de testesespecíficos ao projeto, estes testes podem ser descritos pelo objeto external_tests no ficheiroJSON, onde basta indicar com um objeto o identificador do teste, objetos da seguinte forma:

• name - O nome do teste a executar

• execute_on - A lista de objetos com as indicações a executar tal como visto no pontoanterior

• external_config - Um objeto com:

class_path - O caminho para a pasta onde se encontra a class Java

filename - O nome do ficheiro class em Java

class_name - O nome da class especificada

• data - A lista de objetos data tal como visto na secção anteriormente

"external_tests": "teste externo":

"name": "teste externo","execute_on": [


],"external_config":

"class_path": "/home/tfb/exemplos/","filename": "HelloWorld","class_name": "HelloWorld"

,"data": [


,

"url": "https ://www.websiteexemplo.pt/exemplo","expected": "WebSite"

]

,

4.5. Implementação da Selenium Grid 42

Código 4.4: JSON - Teste externo

Modelos Alloy

Para indicar à ferramenta desenvolvida que devem ser verificados modelos Alloy bastapassar um objeto da mesma forma que os anteriores, com os seguintes parâmetros:

• name - O nome a dar ao modelo de Alloy

• model_path - O caminho completo para o ficheiro Alloy

• check_for_counter_examples - true se deve verificar contra exemplos, false caso con-trário

"alloy_models": "login":

"name": "login","model_path": "/home/tfb/exemplos/login.als","check_for_counter_examples": true

Código 4.5: JSON - Teste Alloy

4.5 implementação da selenium grid

Figura 14.: Infraestrutura Selenium Grid

Tal como identificado anteriormente, de forma a atingir o objetivo pretendido é necessárioa construção de uma Selenium Grid onde os testes possam correr. Conforme falado coma diretora de desenvolvimento Web da Eurotux, face às necessidades atuais foi decido aimplementação de uma Selenium Grid com a configuração identificada na Figura 14 comduas máquinas em funcionamento. A máquina principal terá um Linux CentoOS [61] eatuará como Selenium HUB e também como nodo de forma a poupar recursos. A segunda

4.6. Casos de teste genéricos 43

máquina terá o sistema operativo Microsoft Windows 10. Relativamente a browsers, no totalficarão disponíveis o Chrome, Firefox, Internet Explorer e Microsoft Edge. Foi tambémestudada a possibilidade da adição de um browser Safari, no entanto como requer umamáquina física da Apple, este nodo será ativado apenas quando necessário.

4.6 casos de teste genéricos

No package testing encontram-se as classes de testes genéricos implementadas. Segue umbreve detalhe das mesmas:

PAGETITLETEST Responsável por testar o título de uma página. O seu funcionamento ébastante simples, tal como aceder ao url e verificar se na página está disponível a tag<title> e validar de acordo com o fornecido com o ficheiro JSON se são iguais. Nocaso de não ser fornecido nenhum valor com o atributo ’expected’ no ficheiro JSON oteste apenas verifica se a página tem title e deteta o seu valor.

ALTIMGTEST Teste responsável por verificar se todas as imagens presentes na página pos-suem um alt definido. No caso de não ter alt definido o relatório irá indicar umaviso.

BROKENLINKTEST Este teste verifica se existe algum link não funcional na página. Estaverificação é efetuado obtendo todos os href das tags <a> e efetuando um pedido aesse mesmo url obtido. De seguida é analisado o código HTTP devolvido.

TAGSOGTEST Cada vez mais as redes sociais estão presentes nas páginas Web e então surgeeste teste que verifica se as tags opengraph3 utilizadas pelo Facebook, existem e estãodefinidas na página.

TAGSTWITTERTEST Este teste é semelhante ao anterior, apenas centralizado no Twitter.

W3CTEST Um dos testes mais importantes é o da validação W3C4. Este teste valida jun-tamente do webservice se a página indicada passa na validação W3C. No caso de avalidação não passar, o sistema irá colocar no relatório as falhas encontradas.

GENERALCONSOLETEST Este teste é específico do Google Chrome. Neste teste é possívelaceder à consola do browser e detetar os warnings e erros que foram apresentadosapós o carregamento da página. Este teste torna-se muito importante, pois permitefacilmente detetar problemas com javascript na página, entre outros.

FAVICONTEST Testa a existência de um Fav Icon na página.

3 Protocolo Opengraph - Grafo que permite a descrição de conteúdo e a sua ligação às redes sociais4 Validação de um conjunto de padrões de forma a unificar as páginas de internet

4.7. Testes específicos 44

SEOTEST Testa a existência de tags H1 e H2 na página.

REDIRECTTEST Testa redirecionamentos de links, por exemplo, o teste abre a página X e éindicado no ficheiro JSON que deveria ir para a Y, o teste compara o endereço paraonde foi redirecionado para verificar se é igual ao Y.

FORMTEST O teste responsável pelos formulários que permite efetuar uma validação dosseus campos e detetar erros ao introduzir caracteres especiais bem como outros ele-mentos. Permite também efetuar a sua submissão e validar.

4.7 testes específicos

A execução de classes de teste externas foi um dos pontos que apresentou diversos desafios.Um dos principais objetivos seria que a classe escrita teria de ter apenas o código essencialà execução do teste, sendo que esse objetivo foi cumprido dentro dos possíveis. Assim épossível escrever uma simples classe Java com um teste específico para um projeto, sendodepois carregada e compilada em ’run time’ pela aplicação.Desta forma apenas é necessário criar a classe com os seus respetivos import, e seguiralgumas guias:

AnotarÉ necessário anotar a classe com o código "@RunWith(Parameterized.class)". Esta anotaçãovai permitir que a classe utilize os dados incorporados no ficheiro JSON fornecido inicial-mente.

@RunWith(Parameterized.class)

Código 4.6: Classe Externa - Anotação

ExtenderA classe deve estender a class base, nomeadamente a BaseTest

public class Teste extends BaseTest

Código 4.7: Classe Externa - Extender

ParameterizarÉ necessário também fornecer o método responsável por obter a informação do ficheiroJSON, este método geralmente será sempre parecido, apenas mudando o identificador do


teste. No entanto não foi possível passar este código para uma classe mais genérica devidoà classe de Parametrização.

@Parameterized.Parameterspublic static List <Data > getData () throws Exception

return Main.getConf ().getTestConfigs ().get("teste externo2").getData ();

Código 4.8: Classe Externa - Parametrização

ConstruirConstruir o construtor principal da classe de forma a poder ser instanciada. Este construtordeve sempre receber um objeto do tipo Data e fazer uso da classe acima através do co-mando ’super(data)’. Após isto devem ser definidos os detalhes do teste através do métodosetDetails disponível na classe BaseTest.

public Teste(Data data)super(data);super.setDetails("teste externo2", "Page Title test", "External", "

Example", "");

Código 4.9: Classe Externa - Construtor

TestarImplementar o método com todo o código responsável por executar o teste. Este métododeve ser sempre anotado com @Test de forma a ser interpretado como um teste pelo JUnit.A partir daqui é possível aceder à WebDriver da seguinte forma:

WebDriver driver = super.getDriver ();

Código 4.10: Acesso WebDriver

e ao objeto Data:

Data data = super.getMyData ();

Código 4.11: Acesso dados teste

Devemos também utilizar:

ExtentTest test = Main.getConf ().getExtent ().startTest(data.getUrl ());

Código 4.12: Acesso relatórios


De forma a imprimir os resultados pretendidos para o relatório.De seguida efetuar todos os passos do teste e por fim colocar super.getTest().appendChild(test);para juntar este teste no relatório de forma organizada, e utilizar o método ’assertTrue(result);”de forma ao JUnit efetuar a respetiva avaliação.

Exemplo:

@Testpublic void goToWebPage ()

WebDriver driver = super.getDriver ();Data data = super.getMyData ();

driver.get(data.getUrl ());

Boolean result = false;String title = driver.getTitle ();String expected = data.getExpected ();


if(title.equals(expected)) test.log(LogStatus.PASS , "Got: " + title);result = true;

elsetest.log(LogStatus.FAIL , "Not Matched. Got: ’" + title + "’ And

expected: ’" + expected + "’");

super.getTest ().appendChild(test);

assertTrue(result);

Código 4.13: Classe Externa - Teste

Um template genérico de uma classe externa pode ser consultado no anexo F.

Obviamente que levanta uma questão de segurança sobre a aplicação, no entanto vistoser uma aplicação utilizada para testes internos, a responsabilidade será de quem a está aexecutar. Carregar uma classe externa a um projeto Java não é algo trivial, pelo que tevede ser tratado de forma minuciosa e cuidada. Assim, através de uma função chamada decompileAndLoadJavaCode disponível no ficheiro Common.java do package general é efetuadoo carregamento e compilação em Run Time, função cujo código é o seguinte:


public static Class <?> compileAndLoadJavaCode(String class_url , Stringconfig_path , String config_name) throws

ClassNotFoundException , IOException

Class <?> loadedClass = null;File file = new File(class_url);DiagnosticCollector <JavaFileObject > diagnostics = new

DiagnosticCollector <JavaFileObject >();JavaCompiler compiler = ToolProvider.getSystemJavaCompiler ();StandardJavaFileManager fileManager = compiler.getStandardFileManager(

diagnostics , null , null);

Iterable <? extends JavaFileObject > compilationUnit= fileManager.getJavaFileObjectsFromFiles(Collections.

singletonList(file));JavaCompiler.CompilationTask task = compiler.getTask(

null ,fileManager ,diagnostics ,null ,null ,compilationUnit);

if (task.call()) File file_path = new File(config_path);URLClassLoader classLoader = new URLClassLoader(new URL []

file_path.toURI ().toURL());

loadedClass = classLoader.loadClass(config_name); else

for (Diagnostic <? extends JavaFileObject > diagnostic : diagnostics.getDiagnostics ()) System.out.format("Found problem on line %d in %s%n",

diagnostic.getLineNumber (),diagnostic.getSource ().toUri());

fileManager.close ();

return loadedClass;

Código 4.14: Carregamento de classes externas

Esta função recebe 3 argumentos, sendo o primeiro o caminho completo para a localiza-ção do ficheiro .java, o caminho até à pasta onde está localização o ficheiro .java, e o nome

4.8. Execução em paralelo e com parâmetros 48

do ficheiro. Assim, o ficheiro é carregado para a memória, e com recurso ao Java Compiler écarregada a classe para o projeto. No caso da classe conter algum erro, esse erro é indicadono relatório final e abortado o carregamento da classe.

4.8 execução em paralelo e com parâmetros

Uma vez que esta aplicação será utilizada de forma programada e com uma grande quan-tidade de testes, apesar de a Selenium Grid já efetuar uma boa gestão da distribuição detestes seria necessário do lado aplicacional a utilização de paralelismo no software, de formaa poderem ser enviados o maior número de testes possíveis para a grid. Outra necessidadeface à quantidade e tipos de testes seria a utilização de testes com parâmetros, e para taltemos a class ’Parameterized’ disponível no JUnit, no entanto esta classe não nos permitea execução dos testes parametrizados em paralelo. Assim com recurso à JUnit Toolbox de’Michael Tamm’ e ’Stefan Birkner’ foi implementada a utilização da classe ’ParallelPara-meterized’ que permite fazer exatamente o pretendido. Assim neste caso, bastaria apenassubstituir as anotações já presentes com @RunWith(Parameterized.class) pela equivalente@RunWith(ParallelParameterized.class).Assim, com base nesta anotações é permitido através de um mapeamento existente efetuadoapós o carregamento do ficheiro JSON com os objetos do Selenium a indicar os ambientesnecessários, denominados por DesiredCapabilities, configurar os parâmetros iniciais para ostestes, ou seja, logo de início temos uma lista de ambientes que será percorrida utilizandoThreads em java, em que para cada ambiente serão executados os testes indicados para per-correr naquele ambiente, sendo que tudo isto acontece concorrentemente. Num exemploprático, tendo dois ambientes configurados, Chrome no Windows e Firefox no Linux, paracada um destes ambientes será ao mesmo tempo executado os testes indicados para cadaum deles, confome pode ser visualizado na Figura 15.

É aqui que também é feita a configuração inicial das WebDrivers do Selenium, sendo quepara cada ambiente é efetuada a configuração e ligação da respetiva WebDriver. No finaldos trabalhos relativos aquele ambiente, a ligação à WebDriver é terminada, concluindoassim uma sessão de testes. A um nível mais baixo, relativamente aos testes em si, estestambém possuem Parâmetros, que são indicados da mesma forma que o anterior, massendo que a anotação utilizada será a primeira indicada, uma vez que apenas queremosa parametrização nesta zona e não o paralelismo. Assim, para cada objeto ’data’ lido do

4.9. Validação de modelos Alloy 49

Figura 15.: Execução em paralelo

ficheiro JSON para cada teste, será da mesma forma iterado sobre essa lista e executado oteste n vezes com o seus respetivos parâmetros.

Todo este funcionamento encontra-se codificado na classe ’ParallelTest’ disponível nopackage ’general’.

4.9 validação de modelos alloy

Os modelos Alloy são verificados com recurso à ferramenta Alloy Analyser, utilizando asua API. Conforme pode ser observando na Figura 16 para cada modelo fornecido atravésdo ficheiro de configuração JSON é indicada a sua localização à ferramenta WebTest. Deseguida, a ferramenta utilizando um sistema de threads5 efetua o carregamento para me-mória do respetivo modelo e utilizando a API do Alloy Analyser é efetuada a sua traduçãopara o solver KodKod [73]. Após esta tradução ser realizada, com recurso ao SAT SolverSAT4J [9], é encontrado uma solução do respetivo modelo, onde é possível existirem contraexemplos.No caso de não serem encontrados contra exemplos significa que o modelo (especificação)pode ao não ser válida. Esta situação decorre uma vez que está depende do número decomputações que indicamos no modelo para serem verificadas. No caso de ser efetuada

5 Processo independente executado concorrentemente

4.10. Relatórios 50

apenas uma interação não é garantido que o modelo esteja correto, no entanto no caso decolocar quatro ou mais, devido ao número de casos que o Alloy aplica já podemos conside-rar que se encontra correto.É possível indicar um número ainda maior, no entanto é necessário garantir que a máquinapossui recursos suficientes para efetuar as verificações em grande número e em poucotempo. No caso de serem encontrados contra exemplos, significa que o modelo não seencontra correto, ou seja, a especificação não está correta.

Figura 16.: Verificação modelo Alloy

A ideia principal é utilizar os contra exemplos gerados pelo Alloy no Selenium aumen-tando assim o número de casos de testes aplicados. No entanto, esta solução ainda não seencontra implementada devido à sua enorme complexidade. Através do estudo [25], e daferramenta TestEra [112] concluí-se que é possível efetuar o indicado, sendo este um dospontos a efetuar no futuro.

4.10 relatórios

Os relatórios na execução de testes são essenciais e devem ser o mais descritivos possíveispara existir uma rápida interpretação do problema detetado. Também é considerado saberque teste executou, quando começou e acabou e onde foi executado.Com base nestas necessidades era altura de procurar um bom sistema de relatórios. As-sim surgiu o Extent Reports de Anshoo Arora [5]. Um sistema de relatórios fácil de utilizarque gera um documento em HTML com toda a informação dos testes corridos, incluindográficos. Este sistema gera um relatório que permite agrupar testes por categorias. Outra

4.11. GUI - Graphical User Interface 51

grande vantagem desde sistema, é que se encontra atualmente com uma atividade bastantegrande em termos de atualizações, sendo que neste momento está a ser implementada umanova versão melhorada.Com este sistema é possível caracterizar os testes atribuindo categorias à nossa escolha parauma melhor filtragem. Referente a cada teste temos 7 caracterizações disponíveis de classi-ficação, sendo elas Pass, Fail, Warning, Fatal, Error, Skip e Unknown, pelo que podemosmanualmente indicar a sua classificação. Outra vantagem deste sistema é a presença de umecrã com a informação resumida de toda a execução, onde são mostrados alguns gráficos,com a indicação do número de testes em cada classificação, bem como é apresentado otempo de execução dos testes e as percentagens de testes passados. Outra vantagem é apossibilidade de inclusão de screenshots associados à descrição de um teste. Outra das fun-cionalidades é a possibilidade de pesquisa pelos testes realizados permitindo assim filtraros testes.

Figura 17.: Relatório de testes

4.11 gui - graphical user interface

Apesar de manualmente ser possível criar o ficheiro de configuração JSON, de forma aevitar erros e tornar o processo mais simples, foi necessário implementar uma interfacegráfica que permitisse a geração e edição deste ficheiro.Assim, foi construida uma interface simples com 4 separadores correspondentes às 4 àreasdo ficheiro descritas anteriormente.

Cada uma destas àreas corresponde aos blocos do ficheiro JSON indicadas em 4.4. Nestainterface pode ser efetuado o carregamento de um ficheiro já existente, ou então gerar umficheiro novo.

4.12. Parâmetros da ferramenta 52

Figura 18.: Interface gráfica

4.12 parâmetros da ferramenta

Visto um dos requisitos ser a execução através do terminal, com recurso à dependênciaJCommander, foram disponibilizados os seguintes parâmetros:

• -c, --config: permite indicar o ficheiro de configuração de testes (Caminho completo)

• -a, --address: permite indicar um endereço base para utilizar nos testes. Esta situaçãoé util no caso da integração continua com o Jenkins por exemplo. Onde o endereçofinal da página terá sempre um ip diferente consoante o container lançado pelo Jen-kins.

• -ir, --ignore-result: caso seja true o resultado do programa será sempre de sucesso

• -g, --gui: Permite lançar a interface gráfica.

Desta forma, não só é possível executar manualmente a ferramenta através do terminal,como é possível automatizar o processo de execução de testes através de um Cron Job6,ou até mesmo utilizando ferramentas como o Jenkins [50], uma ferramenta de integraçãocontínua que permite correr os testes sempre que o código é atualizado.

6 Tarefa agendada nos sistemas Unix

4.12. Parâmetros da ferramenta 53

4.12.1 Execução programada

De forma a proceder à execução programada pelo utilizador para a repetição de testes deforma contínua, com recurso a um Cron Job é possível proceder a esse agendamento. Porexemplo, basta colocar a seguinte linha no ficheiro cron para executar todas as segundasfeiras às 5h15m:

15 5 * * 1 java -jar /home/tfb/SELENIUM/WebTest.jar --config /home/tfb/SELENIUM/tests/websiteexemplo.json

Código 4.15: Execução programada

Geração de Cron Jobs automática

De forma a ser possível automatizar este processo, pode ser indicado no ficheiro de confi-gurações dos testes, os Cron Jobs que se pretende ativar. Para tal bastará apenas no ficheiro,na parte das general_config indicar a lista dos crons que são pretendidos da seguinte forma:

"cronjob": ["15 5 * * 1","15 5 * * 3","15 5 * * 5"

]

Código 4.16: Geração de Cron Job

Assim, o sistema ao efetuar a primeira execução manual irá verificar se os Cron Jobsestão definidos, e caso não estejam serão gerados automaticamente.

Integração Contínua

De forma a ser automatizado o processo da execução de testes de acordo com os commits7

efetuados para o repositório de controlo de versões, é possivel ligar a ferramenta desenvol-vida a um sistema de integração contínua, como por exemplo, o Jenkins [50]. Desta formaapenas terá de ser configurado no Jenkins o respetivo comando a executar com os argu-mentos pretendidos. Um caso especial e preparado a pensar nesta solução é o argumento–address que permite indicar um endereço base, permitindo assim que o Jenkins crie oscontainers8 necessários e coloque o código em funcionamento e fornecer o endereço dessecontainer à ferramenta de testes e verificação. Por sua vez, o ficheiro de configuração de

7 Envio de código para controlo de versões8 Ambiente isolado

4.13. Conclusões 54

testes agora em vez de indicar o endereço total dos caminhos a aceder, apenas necessita deter indicado os caminhos relativos.

4.13 conclusões

Finalizado o desenvolvimento da ferramenta de testes e verificação formal WebTest dosrequisitos identificados na secção 4.1 conclui-se que todos foram alcançados, salientado osseguintes:

• É possível receber um ficheiro de configuração JSON com as configurações dos testes,sejam genéricos, específicos, ou modelos Alloy;

• Enviar testes ao Selenium HUB para que possam ser distribuídos pelos vários nodosdisponíveis na Grid;

• Obter um relatório em formato .html com a descrição dos resultados dos testes;

• Gerar um ficheiro JSON de configuração através da interface gráfica;

• Agendar o funcionamento automático da ferramenta através de Cron Jobs ou Jenkins;

• A execução é rápida devido ao paralelismo implementado.

Em suma, foi desenvolvida uma ferramenta de testes e verificação formal capaz de corrertestes de forma automática e recorrente.

5

AVA L I A Ç Ã O D A A R Q U I T E T U R A

Neste capítulo serão apresentados alguns casos de estudo realizados de forma a testartodo o sistema. Como exemplo, serão demonstrados os testes realizados a um produtodesenvolvido pela Eurotux denominado TeraBunker, que permite a criação de backups deforma segura. Será também apresentado um exemplo de um caso real de um website demedia onde poderemos verificar os problemas encontrados no respetivo website, e como ascorreções resultantes destes testes permitiram melhorar e evoluir a aplicação.

5.1 caso de teste 1 - terabunker

De forma a testar a ferramenta WebTest, a mesma foi utilizada sobre um produto real aser desenvolvido pela Eurotux. Neste caso de estudo será demonstrado o teste à páginade login, bem como à funcionalidade de criação de uma pasta para backups. Este testeencontra-se a correr semanalmente de forma a garantir que as funcionalidades não falhamem situação alguma.

Figura 19.: Resultados caso de teste - TeraBunker

Uma fez que serão feitos testes específicos a este projeto, foi necessário proceder à criaçãodas respetivas classes java para serem carregadas na ferramenta, sendo que estas classes

55

5.2. Caso de teste 2 - Site de media 56

podem ser consultadas no anexo G. No caso do teste de login, será testado se com dadoserrados é negado o acesso à plataforma. No caso do teste de criação da pasta de backups,são simulados os cliques do utilizador ao navegar na página, efetuando o procedimentonecessário para a criação da mesma.Em simultâneo com os testes específicos foram também executados os testes genéricos,nomeadamente a verificação do título da página e a existência da propriedade "alt"nasimagens.

Após uma das execuções foram obtidos os resultados presentes na Figura 19 onde sepode observar que todos os testes passaram com sucesso, tendo o teste executado em 2

minutos e 37 segundos.

5.2 caso de teste 2 - site de media

Assumindo um website de media com uma média de 1398669 visitas nos últimos três mesesde acordo com o ranking NetScope [78], e com uma homepage com 23 artigos e diversasimagens, este website dispõe de uma página de detalhe para cada artigo. Como caso deteste serão inicialmente aplicados alguns testes mais genéricos que poderão ser aplicados aqualquer website, tais como a verificação do título da página, a validação das normas W3C,a existência de alt nas imagens e a validação de SEO1.

Figura 20.: Resultados caso de teste - site de media

Com base nos testes indicados acima foi construido o ficheiro de configurações de teste apassar à WebTest que por sua vez irá comunicar com o Selenium e devolver os resultados.Após a primeira execução destes testes nas referidas páginas foi obtido um resultado de 19

% de validação conforme pode ser verificado no gráfico da Figura 20.

1 Conjunto de elementos para optimização de motores de busca


Após consulta detalha do relatório relatório produzido, foi possível analisar os proble-mas encontrados, e proceder à correção desses mesmos pontos. Após a correção ter sidoefetuada, e de o teste ter sido executado novamente, foram obtidos os resultados apresen-tados na Figura 21, sendo que neste caso já foi obtido 66 % de validação, sendo o restantede apenas warnings.

Figura 21.: Resultados caso de teste - site de media

Mais pormenorizadamente, através do gráfico representado na Figura 22 é possível ana-lisar a evolução ao longo do tempo.

Figura 22.: Evolução validação

Assim com base em apenas testes genéricos que podem ser aplicados a qualquer website,já foi possível proceder à melhoria de um website que se encontrava com problemas. Como agendamento destes mesmos testes conseguimos verificar se alguma alteração no website


possa ter provocado algum erro, atingindo assim o objetivo inicial de ter testes de formaprogramada a verificar periodicamente determinado website.

6

C O N C L U S Ã O

Este estudo tinha como principal objetivo assegurar que o processo de desenvolvimentoWeb da Eurotux se tornava mais robusto relativamente à vertente dos testes, bem comoa eliminar a interação humana nos testes, permitindo que estes fossem executados auto-maticamente. Isto porque, na entrevista inicial que decorreu com a diretora do departa-mento, foram identificados problemas como a necessidade de testar todo o software emcada entrega, o atual número de browsers e dispositivos aumentar consideravelmente ocusto associado aos testes e a frequência de falhas humanas na execução dos testes.

No presente capítulo, resumem-se os aspetos centrais desenvolvidos na dissertação paraprosseguir esse objetivo, sintetizam-se as suas principais conclusões (Secção 6.1) e apresentam-se algumas sugestões de trabalho futuro (Secção 6.2).

No Capítulo 2 está descrito o estado da arte relativamente aos testes e à qualidade desoftware, foram analisadas as principais ferramentas e escolhidas as que viriam a integrara solução implementada ao longo deste estudo. Deste capítulo foi possível perceber queapesar das empresas de TI se preocuparem cada vez mais com a qualidade do software,ainda não é dada a devida importância aos testes. Que estes são por norma realizadosmanualmente e pela pessoa responsável pela implementação.

Desse capítulo foi ainda importante perceber que para garantir a qualidade do software, énecessário garantir a qualidade da especificação e só dessa forma é possível automatizar ostestes. Foram ainda analisadas várias metodologias, e decidiu-se no presente estudo, focaressencialmente nos testes funcionais que asseguram a concordância da parte funcional dosoftware face às suas especificações, e nos testes de regressão que garantem que o novocódigo não introduz erros.

O Capítulo 3 permitiu aprofundar o conhecimento sobre a ferramenta de testes escolhida,a sua arquitetura e funcionamento. No capítulo 4 foi descrita a solução implementadacom recurso à ferramenta descrita no capítulo anterior, e no capítulo 5 foram realizados

59

6.1. Síntese das conclusões 60

vários testes que comprovaram que o software resultante deste estudo, vai ao encontro dosobjetivos definidos inicialmente, conforme se detalha na Secção 6.1.

6.1 síntese das conclusões

Esta secção começa por recordar os objetivos específicos deste estudo.

• Selecionar uma ferramenta de testes que permita correr testes em vários browsers esistemas 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íficosde um projeto

• Obter relatórios detalhados dos testes executados

• Permitir a execução da ferramenta desenvolvida de forma automática

Para atingir estes objetivos, foi realizado um levantamento dos vários tipos de testesexistentes, bem como das linguagens de verificação formal. Desse estudo concluiu-se combase nas necessidades da equipa de desenvolvimento que os testes funcionais e de regressãoseriam o foco, de forma a assegurar a concordância da parte funcional do software face àssuas especificações ao longo do ciclo de vida da aplicação. Após análise, a Eurotux decidiuoptar pela utilização do Selenium, uma ferramenta de testing que permite testar em váriosambientes (browsers, dispositivos e sistemas operativos).

Relativamente à vertente de verificação formal foi decido a utilização da linguagem Alloy,juntamente com a sua ferramenta Alloy Analyser, de forma a assegurar a qualidade dosrequisitos.

Com base nas escolhas, foi necessário desenvolver uma solução de testes e verificaçãoformal que juntasse ambas as ferramentas selecionadas pela Eurotux numa só. Esta fer-ramenta, denominada como WebTest, permite correr testes genéricos, específicos, e atéefetuar a verificação de modelos Alloy de forma automática. Esta permite também a suaexecução de forma programada através de Cron Jobs, automatizando assim todo o processo

6.2. Trabalho futuro 61

e permitindo efetuar testes de regressão. A monitorização do resultado dos testes pode serconsultada em relatórios enviados por email.

A WebTest encontra-se atualmente em funcionamento, aplicando testes a projetos reaisdesenvolvidos ao longo dos últimos meses. Com a sua utilização foi possível constatar oseguinte:

• Embora os testes demorem mais tempo a iniciar, devido à necessidade de programar oteste, no total do projeto o tempo dedicado aos testes reduz-se, na medida em que estanova metodologia aplicada ao processo de desenvolvimento web da Eurotux, permitea repetição dos testes a cada nova release do projeto, sendo o custo dessa repetiçãomuito reduzido;

• Foi possível também observar que o número de casos testados aumentou, porque aoautomatizar os testes é possível dedicar mais tempo a definir os casos a testar e menosna sua execução;

• Como os testes são automáticos, é possível garantir que todos os casos previstos inici-almente são testados a cada execução e em todos os ambientes definidos.

Concluindo, a ferramenta WebTest tem-se verificado muito útil no processo de desenvol-vimento web da Eurotux, estando disponível numa máquina central, de forma a poder serutilizada por qualquer departamento da empresa. Esta solução foi ainda integrada com aferramenta de integração continua utilizada na Eurotux, Jenkins, de forma a correr testesautomáticos periodicamente, sendo os seus resultados enviados por email para a equipa.

Numa reunião com os responsáveis da equipa de desenvolvimento web da Eurotux, sobreas conclusões deste estudo, foi possível obter um feedback positivo sobre a utilização daWebTest e a perspetiva de que com o uso recorrente da mesma será possível aumentar asatisfação dos clientes relativamente à qualidade do software produzido.

6.2 trabalho futuro

Face a todo o desenvolvimento efetuado, foi necessário refletir sobre possíveis evoluçõesdesta solução de testes. Já na fase final deste trabalho, decorreu uma reunião com a equipade desenvolvimento web da Eurotux, da qual resultaram as seguintes sugestões:

• A implementação de prioridades nos testes. Com estas prioridades será possívelpermitir que testes que levem mais tempo a ser executados, ou que têm mais impor-tância, sejam executados primeiro. Assim o engenheiro de software não terá de ficar

6.2. Trabalho futuro 62

à espera que chegue a vez do teste que lhe importa que seja executado. Também podeser considerado uma execução por fases, onde os testes com maior prioridade seriamexecutados, e no final seria logo enviado um relatório do resultado da sua execução,e a ferramenta continuaria a executar os restantes testes.

• Outra sugestão passa pela implementação de uma página web onde poderiam serconsultados em tempo real os testes que estão a ser executados e os seus resultados.Desta forma, considerando uma execução manual, o engenheiro de software poderiavisualizar em tempo real o estado dos seus testes, em vez de ter de esperar pelorelatório no final.

Dada a importância que a solução adquiriu no processo de desenvolvimento web daEurotux, está prevista a evolução da ferramenta para que estas e outras sugestões possamser implementadas, permitindo melhorar continuamente o software produzido por estaequipa.

B I B L I O G R A F I A

[1] Shivani Acharya and V Pandya. Bridge between Black Box and White Box–GrayBox Testing Technique. International Journal of Electronics and Computer Science Engine-ering, 2(1):175–85, 2013. URL http://www.estdl.org/wp-content/uploads/2013/03/

Volume-2Number-1PP-175-185.pdf.

[2] Adelard. SpecBox, September 2016. URL http://www.adelard.com/services/

SoftwareTools/SpecBox/.

[3] José Bacelar Almeida, Maria João Frade, Jorge Sousa Pinto, and Simão Melo deSousa. Rigorous Software Development. Springer, 2011. ISBN 978-0-85729-017-5. doi: 10.1007/978-0-85729-018-2. URL http://www.springerlink.com/index/10.

1007/978-0-85729-018-2.

[4] Paul Ammann and Jeff Offutt. Introduction to Software Testing, volume 54. Cam-bridge University Press, 2008. ISBN 9780521880381. URL http://www.amazon.com/

Introduction-Software-Testing-Paul-Ammann/dp/0521880386.

[5] Anshoo Arora. Extent Reports, September 2016. URL http://extentreports.

relevantcodes.com/.

[6] Anshoo Arora GitHub. Anshoo Arora GitHub, September 2016. URL https:

//github.com/anshooarora/extentreports-java.

[7] Apache. SubVersion, September 2016. URL https://subversion.apache.org/.

[8] Apple. iOS, September 2016. URL https://www.apple.com/pt/ios/ios-10/.

[9] Artois University. Sat4j, September 2016. URL http://www.sat4j.org/.

[10] Boris Beizer. Software System Testing and Quality Assurance. Van Nostrand ReinholdCo., New York, NY, USA, 1984. ISBN 0-442-21306-9.

[11] Benny Bottema. SImple Java Mail, September 2016. URL https://github.com/

bbottema/simple-java-mail.

[12] S. Berner, R. Weber, and R.K. Keller. Observations and lessons learned from auto-mated testing. Proceedings. 27th International Conference on Software Engineering, 2005.ICSE 2005., pages 571–579, 2005. doi: 10.1109/ICSE.2005.1553603.

63

http://www.estdl.org/wp-content/uploads/2013/03/Volume-2Number-1PP-175-185.pdf

http://www.estdl.org/wp-content/uploads/2013/03/Volume-2Number-1PP-175-185.pdf

http://www.adelard.com/services/SoftwareTools/SpecBox/

http://www.adelard.com/services/SoftwareTools/SpecBox/

http://www.springerlink.com/index/10.1007/978-0-85729-018-2

http://www.springerlink.com/index/10.1007/978-0-85729-018-2

http://www.amazon.com/Introduction-Software-Testing-Paul-Ammann/dp/0521880386

http://www.amazon.com/Introduction-Software-Testing-Paul-Ammann/dp/0521880386

http://extentreports.relevantcodes.com/

http://extentreports.relevantcodes.com/

https://github.com/anshooarora/extentreports-java

https://github.com/anshooarora/extentreports-java

https://subversion.apache.org/

https://www.apple.com/pt/ios/ios-10/

http://www.sat4j.org/

https://github.com/bbottema/simple-java-mail

https://github.com/bbottema/simple-java-mail

Bibliografia 64

[13] D Bjørner and C B Jones. The Vienna Development Method: The Meta-Language, vo-lume 61. 1978. ISBN 3540087664. doi: 10.1007/3-540-08766-4. URL http://www.

springerlink.com/index/10.1007/3-540-08766-4.

[14] BlackBerry. BlackBerry, September 2016. URL http://global.blackberry.com/en/

home.html.

[15] W.-P. Brinkman, R. Haakma, and D.G. Bouwhuis. Component-Specific Usability Tes-ting. IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans,38(5):1143–1155, 2008. ISSN 1083-4427. doi: 10.1109/TSMCA.2008.2001056. URLhttp://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4604822.

[16] Browser Stack. Browser Stack, September 2016. URL https://www.browserstack.

com/.

[17] BSD. BSD License, September 2016. URL http://www.gnu.org/licenses/bsd.html.

en.

[18] C#. C#, September 2016. URL https://msdn.microsoft.com/en-us/library/

67ef8sbd.aspx.

[19] Chanel. Chanel, September 2016. URL http://www.chanel.com/.

[20] Huo Yan Chen, T H Tse, F T Chan, and T Y Chen. In Black and White: An IntegratedApproach to Class-level Testing of Object-oriented Programs. ACM Trans. Softw. Eng.Methodol., 7(3):250–295, 1998. ISSN 1049-331X. doi: 10.1145/287000.287004. URLhttp://doi.acm.org/10.1145/287000.287004.

[21] Tony Clark and Jos Warmer. Object Modeling with the OCL - The Rationale behindthe Object Constraint Language. Lecture Notes in Computer Science, 2263, 2002. URLhttp://link.springer.com/content/pdf/10.1007/3-540-45669-4.pdf.

[22] Lisa Crispin and Tip House. Testing extreme programming. Addison-Wesley Professio-nal, 2003.

[23] Philip B. Crosby. Quality is free: The art of making quality certain. McGraw-Hill Compa-nies, 1979. ISBN 0070145121. doi: 10.2172/1025774.

[24] James J. Cusick. Software Quality, Testing, & Metrics. In AT&T Wireless Techday, 2000.ISBN 9789604743049.

[25] Franscisco Ricardo Pinto DA SILVA. Geração automática de testes a partir de especificaçõesalgébricas. PhD thesis, 2012.

http://www.springerlink.com/index/10.1007/3-540-08766-4

http://www.springerlink.com/index/10.1007/3-540-08766-4

http://global.blackberry.com/en/home.html

http://global.blackberry.com/en/home.html

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4604822

https://www.browserstack.com/

https://www.browserstack.com/

http://www.gnu.org/licenses/bsd.html.en

http://www.gnu.org/licenses/bsd.html.en

https://msdn.microsoft.com/en-us/library/67ef8sbd.aspx

https://msdn.microsoft.com/en-us/library/67ef8sbd.aspx

http://www.chanel.com/

http://doi.acm.org/10.1145/287000.287004

http://link.springer.com/content/pdf/10.1007/3-540-45669-4.pdf

Bibliografia 65

[26] Eclipse Model Development Tools. Eclipse Model Development Tools, September2016. URL http://www.eclipse.org/modeling/mdt/?project=ocl.

[27] René Elmstrøm, Peter Gorm Larsen, and Poul Bøgh Lassen. The ifad vdm-sl toolbox:A practical approach to formal specifications. SIGPLAN Not., 29(9):77–80, September1994. ISSN 0362-1340. doi: 10.1145/185009.185028. URL http://doi.acm.org/10.

1145/185009.185028.

[28] EMC 2. EMC 2, September 2016. URL https://www.emc.com.

[29] Facebook. Facebook, September 2016. URL http://www.facebook.com.

[30] R Fairley. Tutorial: Static Analysis and Dynamic Testing of Computer Software. Com-puter, 11(4):14–23, 1978. ISSN 0018-9162.

[31] John S. Fitzgerald, Peter Gorm Larsen, and Marcel Verhoef. Vienna DevelopmentMethod. John Wiley & Sons, Inc., 2007. ISBN 9780470050118.

[32] Martin Fowler and Jim Highsmith. The agile manifesto. Software Development, 9

(August):28–35, 2001. ISSN 10708588. doi: 10.1177/004057368303900411. URL http:

//www.pmp-projects.org/Agile-Manifesto.pdf%5Cnhttp://andrey.hristov.

com/fht-stuttgart/The_Agile_Manifesto_SDMagazine.pdf%5Cnhttp:

//www.pmp-projects.org/Agile-Manifesto.pdf.

[33] David Gelperin and Bill Hetzel. The Growth of Software Testing. Communications ofthe ACM, 31(6):687–695, 1998.

[34] R L Glass, R Collard, A Bertolino, J Bach, and C Kaner. Software testing and indus-try needs. IEEE Software, 23(4):55–57, 2006. ISSN 0253-0465. doi: 10.1109/MS.2006.113. URL http://www.computer.org/portal/cms_docs_software/software/

homepage/2006/s4055.pdf.

[35] Google. Android, September 2016. URL https://www.android.com/intl/pt_pt/.

[36] Google. Chrome, September 2016. URL https://www.google.com/chrome/browser/

desktop/index.html.

[37] Gson GitHub. Gson GitHub, September 2016. URL https://github.com/google/

gson.

[38] Antawan Holmes and Marc Kellogg. Automating functional tests using selenium.Proceedings - AGILE Conference, 2006, 2006:270–275, 2006. doi: 10.1109/AGILE.2006.19.

[39] IBM. Automate web application testing with Sahi. IBM, pages 1–10, 2011. URLhttp://www.ibm.com/developerworks/web/library/wa-sahi/index.html.

http://www.eclipse.org/modeling/mdt/?project=ocl

http://doi.acm.org/10.1145/185009.185028

http://doi.acm.org/10.1145/185009.185028

https://www.emc.com

http://www.facebook.com

http://www.pmp-projects.org/Agile-Manifesto.pdf%5Cnhttp://andrey.hristov.com/fht-stuttgart/The_Agile_Manifesto_SDMagazine.pdf%5Cnhttp://www.pmp-projects.org/Agile-Manifesto.pdf




http://www.computer.org/portal/cms_docs_software/software/homepage/2006/s4055.pdf

http://www.computer.org/portal/cms_docs_software/software/homepage/2006/s4055.pdf

https://www.android.com/intl/pt_pt/

https://www.google.com/chrome/browser/desktop/index.html

https://www.google.com/chrome/browser/desktop/index.html

https://github.com/google/gson

https://github.com/google/gson

http://www.ibm.com/developerworks/web/library/wa-sahi/index.html

Bibliografia 66

[40] IBM. IBM, September 2016. URL https://www.ibm.com/us-en/.

[41] Amal Ibrahim and Arabi Keshk. Quality Testing. In Signal Processing, pages 1071–1076, 2007.

[42] Ieee. IEEE Standard Glossary of Software Engineering Terminology. Office, 121990

(1):1, 1990. ISSN 0-7381-0391-8. doi: 10.1109/IEEESTD.1990.101064. URL http://

ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342.

[43] Imperial College London. A guide to Alloy, September 2016. URLhttps://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_on_alloy/

Web/alternatives.php.

[44] ISO. ISO 8402-1986, September 2016. URL http://www.iso.org/iso/catalogue_

detail.htm?csnumber=15570.

[45] D. Jackson. Lightweight Formal Methods, 2001. ISSN 16113349. URL http://www.

springerlink.com/index/YA3TE2C3K7YWN04G.pdf.

[46] Jonathan Jacky. The Way of Z: Practical Programming with Formal Methods. CambridgeUniversity Press, New York, NY, USA, 1996. ISBN 0-521-55976-6.

[47] Java. Java, September 2016. URL http://www.oracle.com/technetwork/java/

index-138747.html.

[48] Javascript. Javascript, September 2016. URL https://www.javascript.com/.

[49] JCommander Oficial Page. JCommander Oficial Page, September 2016. URL http:

//jcommander.org/.

[50] Jenkins. Jenkins, September 2016. URL https://jenkins.io/.

[51] JetBrains. Intellij IDEA, September 2016. URL https://www.jetbrains.com/idea/.

[52] JGoodies Software GmbH. JGoodies Forms, September 2016. URL http://www.

jgoodies.com/freeware/libraries/forms/.

[53] Cliff B Jones. Systematic software development using VDM, volume 2. Prentice-HallEnglewood Cliffs, NJ, 1986.

[54] JUnit. JUnit, September 2016. URL http://junit.org/junit4/.

[55] Cem Kaner. Software testing as a social science. In IFIP Working Group 10.4 meetingon Software Dependability, 2004.

https://www.ibm.com/us-en/

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342

https://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_on_alloy/Web/alternatives.php

https://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_on_alloy/Web/alternatives.php

http://www.iso.org/iso/catalogue_detail.htm?csnumber=15570

http://www.iso.org/iso/catalogue_detail.htm?csnumber=15570

http://www.springerlink.com/index/YA3TE2C3K7YWN04G.pdf

http://www.springerlink.com/index/YA3TE2C3K7YWN04G.pdf

http://www.oracle.com/technetwork/java/index-138747.html

http://www.oracle.com/technetwork/java/index-138747.html

https://www.javascript.com/

http://jcommander.org/

http://jcommander.org/

https://jenkins.io/

https://www.jetbrains.com/idea/

http://www.jgoodies.com/freeware/libraries/forms/

http://www.jgoodies.com/freeware/libraries/forms/

http://junit.org/junit4/

Bibliografia 67

[56] Yomi Kastro and Ayse Basar Bener. A defect prediction method for software ver-sioning. Software Quality Journal, 16:543–562, 2008. ISSN 09639314. doi: 10.1007/s11219-008-9053-8.

[57] Mohd Ehmer Khan. A Comparative Study of White Box , Black Box and Grey BoxTesting Techniques. International Journal of Advanced Computer Science and Applications,3(6):12–15, 2012.

[58] Jung-Min Kim, Adam Porter, and Gregg Rothermel. An empirical study of regressiontest application frequency. Software Testing, Verification and Reliability, 15(September2004):257–279, 2005. ISSN 1099-1689. doi: 10.1002/stvr.326.

[59] E. Kirda, M. Jazayeri, C. Kerer, and M. Schranz. Experiences in engineering flexibleWeb services. IEEE Multimedia, 8(1):58–65, 2001. ISSN 1070986X. doi: 10.1109/93.923954. URL http://www.computer.org/csdl/mags/mu/2001/01/u1058.html.

[60] Nancy G Leveson and Clark S Turner. An Investigation of the Therac-25 Accidents.Computer, 26(7):18–41, 1993. ISSN 00189162. doi: 10.1109/MC.1993.274940. URLhttp://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=274940.

[61] Linux. CentOS, September 2016. URL https://www.centos.org/.

[62] Linux. Linux Mint, September 2016. URL https://www.linuxmint.com/.

[63] Wang Linzhang, Yuan Jiesong, Yu Xiaofeng, Hu Jun, Li Xuandong, and Zheng Guoli-ang. Generating test cases from uml activity diagram based on gray-box method. InSoftware Engineering Conference, 2004. 11th Asia-Pacific, pages 284–291, Nov 2004. doi:10.1109/APSEC.2004.55.

[64] Shaoying Liu and Yuting Chen. A relation-based method combining functionaland structural testing for test case generation. Journal of Systems and Software, 81

(2):234–248, 2008. ISSN 0164-1212. doi: 10.1016/j.jss.2007.05.036. URL http://www.

sciencedirect.com/science/article/pii/S0164121207001276.

[65] G Lucca and A Fasolino. Web application testing. Web Engineering, 2006. URL http:

//www.springerlink.com/index/L86612228K454W34.pdf.

[66] Michael Tamm GitHub. Michael Tamm GitHub, September 2016. URL https://

github.com/MichaelTamm/junit-toolbox.

[67] Microsoft. Edge, September 2016. URL https://www.microsoft.com/pt-pt/

windows/microsoft-edge.

[68] Microsoft. Internet Explorer, September 2016. URL https://support.microsoft.

com/pt-pt/help/17621/internet-explorer-downloads.

http://www.computer.org/csdl/mags/mu/2001/01/u1058.html

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=274940

https://www.centos.org/

https://www.linuxmint.com/

http://www.sciencedirect.com/science/article/pii/S0164121207001276

http://www.sciencedirect.com/science/article/pii/S0164121207001276

http://www.springerlink.com/index/L86612228K454W34.pdf

http://www.springerlink.com/index/L86612228K454W34.pdf

https://github.com/MichaelTamm/junit-toolbox

https://github.com/MichaelTamm/junit-toolbox

https://www.microsoft.com/pt-pt/windows/microsoft-edge

https://www.microsoft.com/pt-pt/windows/microsoft-edge

https://support.microsoft.com/pt-pt/help/17621/internet-explorer-downloads

https://support.microsoft.com/pt-pt/help/17621/internet-explorer-downloads

Bibliografia 68

[69] Microsoft. Windows Phone, September 2016. URL http://www.windowscentral.com/

windows-phone.

[70] L Mikusiak, M Adamy, and T Seidmann. Publishing Formal Specifications in Z nota-tion on the WWW. Proc. Conf. on Theory and Practice of Sw Development (TAPSOFT 97),1214:871–874, 1997. ISSN 16113349.

[71] MIL-STD-105E. MIL-STD-105E, 1989. URL https://archive.org/details/

MIL-STD-105E_1.

[72] MIT. Alloy, September 2016. URL http://alloy.mit.edu/alloy/index.html.

[73] MIT. kodkod, September 2016. URL http://alloy.mit.edu/kodkod/.

[74] Mohamed. Mohamed, September 2016. URL http://www.qualindustri.com/

quality/history.

[75] Daniel J Mosley and Bruce A Posey. Just enough software test automation. Prentice HallProfessional, 2002.

[76] Mozzila. Firefox, September 2016. URL https://www.mozilla.org/pt-PT/firefox/

new/.

[77] Glenford J Myers, Todd M Thomas, and Corey Sandler. The Art of Software Testing,volume 1. John Wiley & Sons, 2004. ISBN 0471469122. doi: 10.1002/stvr.321. URLhttp://www.worldcat.org/oclc/65982801.

[78] NetScope. Ranking Setembro, September 2016. URL http://www.netscope.

marktest.pt/.

[79] Srinivas Nidhra. Black Box and White Box Testing Techniques - A Literature Re-view. International Journal of Embedded Systems and Applications, 2(2):29–50, 2012. ISSN18395171. doi: 10.5121/ijesa.2012.2204.

[80] Linda Northrop. Let’s teach architecting high quality software. Software EngineeringEducation Conference, Proceedings, 2006:5, 2006. ISSN 10930175. doi: 10.1109/CSEET.2006.23.

[81] Octopus. Octopus, September 2016. URL http://octopus.sourceforge.net/.

[82] Omg. UML 2.4.1 Superstructure Specification. October, 02(August):1–786, 2004. doi:formal/2011-08-06.

[83] OMG. Object Constraint Language (OCL) Specification v2.4. Technical report, 2014.URL http://www.omg.org/spec/OCL/2.4.

http://www.windowscentral.com/windows-phone

http://www.windowscentral.com/windows-phone

https://archive.org/details/MIL-STD-105E_1

https://archive.org/details/MIL-STD-105E_1

http://alloy.mit.edu/alloy/index.html

http://alloy.mit.edu/kodkod/

http://www.qualindustri.com/quality/history

http://www.qualindustri.com/quality/history

https://www.mozilla.org/pt-PT/firefox/new/

https://www.mozilla.org/pt-PT/firefox/new/

http://www.worldcat.org/oclc/65982801

http://www.netscope.marktest.pt/

http://www.netscope.marktest.pt/

http://octopus.sourceforge.net/

http://www.omg.org/spec/OCL/2.4

Bibliografia 69

[84] Opera. Opera, September 2016. URL https://www.opera.com/pt.

[85] Oracle. Oracle, September 2016. URL https://www.oracle.com/pt/index.html.

[86] Graeme I. Parkin. The programming language standards scene, ten years on Paper15: Vienna Development Method Specification Language (VDM-SL). Computer Stan-dards and Interfaces, 16(5-6):527–530, 1994. ISSN 09205489. doi: 10.1016/0920-5489(94)90035-3.

[87] Ron Patton. Software Testing. Springer, 2001. ISBN 0672319837. URL http://scholar.

google.com/scholar?hl=en&btnG=Search&q=intitle:No+Title#0.

[88] Perl. Perl, September 2016. URL https://www.perl.org/.

[89] PHP. PHP, September 2016. URL http://php.net/.

[90] Roger S Pressman. Software engineering: a practitioner’s approach 8/e. Palgrave Macmil-lan, 2015.

[91] Python. Python, September 2016. URL https://www.python.org/.

[92] Quora. Quora, September 2016. URL https://www.quora.com/

How-does-the-Selenium-WebDriver-work.

[93] Rudolf Ramler and Klaus Wolfmaier. Economic Perspectives in Test Automation :Balancing Automated and Manual Testing with Opportunity Cost. Quality Assurance,pages 85–91, 2006. ISSN 02705257. doi: 10.1145/1138929.1138946. URL http://

portal.acm.org/citation.cfm?doid=1138929.1138946.

[94] RC. RC, September 2016. URL http://www.seleniumhq.org/projects/

remote-control/.

[95] James Reason. Human error. Cambridge university press, 1990.

[96] F. Ricca and P. Tonella. Web site analysis: structure and evolution. In SoftwareMaintenance, 2000. Proceedings. International Conference on, pages 76–86, 2000. doi:10.1109/ICSM.2000.883017.

[97] F Ricca and P Tonella. Analysis and testing of Web applications. Proceedings ofthe 23rd International Conference on Software Engineering ICSE 2001, 47(6):25–34, 2001.ISSN 00221686. doi: 10.1109/ICSE.2001.919078. URL http://ieeexplore.ieee.org/

lpdocs/epic03/wrapper.htm?arnumber=919078.

https://www.opera.com/pt

https://www.oracle.com/pt/index.html

http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:No+Title#0

http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:No+Title#0

https://www.perl.org/

http://php.net/

https://www.python.org/

https://www.quora.com/How-does-the-Selenium-WebDriver-work

https://www.quora.com/How-does-the-Selenium-WebDriver-work

http://portal.acm.org/citation.cfm?doid=1138929.1138946

http://portal.acm.org/citation.cfm?doid=1138929.1138946

http://www.seleniumhq.org/projects/remote-control/

http://www.seleniumhq.org/projects/remote-control/

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=919078


Bibliografia 70

[98] F. Ricca and P. Tonella. Web Testing: a Roadmap for the Empirical Research. InSeventh IEEE International Symposium on Web Site Evolution, pages 63–70, 2005. ISBN 0-7695-2470-2. doi: 10.1109/WSE.2005.23. URL http://ieeexplore.ieee.org/lpdocs/

epic03/wrapper.htm?arnumber=1517982.

[99] Ruby. Ruby, September 2016. URL http://www.ruby-lang.org/en/.

[100] Safari. Safari, September 2016. URL http://www.apple.com/safari/.

[101] Sahi. Sahi, September 2016. URL http://sahipro.com/.

[102] Sauce Labs. Sauce Labs, September 2016. URL https://saucelabs.com/.

[103] Abhijit a Sawant, Pranit H Bari, and P M Chawan. Software Testing Techniques andStrategies. Journal of Engineering Research & Applications, 2(3):980–986, 2012.

[104] Selenium. Selenium HQ, September 2016. URL http://www.seleniumhq.org/.

[105] SeleniumIDE. SeleniumIDE, September 2016. URL http://www.seleniumhq.org/

docs/02_selenium_ide.jsp.

[106] Arun Singh and Rajesh Singh. Assuring Software Quality using data mining metho-dology: A literature study. 2013 International Conference on Information Systems andComputer Networks, pages 108–113, 2013. doi: 10.1109/ICISCON.2013.6524184. URLhttp://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6524184.

[107] Inderjeet Singh and Bindia Tarika. Comparative analysis of open source automatedsoftware testing tools: Selenium, sikuli and watir. International Journal of Information& Computation Technology, 2014.

[108] SmartBear. SmartBear, September 2016. URL https://smartbear.com/.

[109] D Talby, A Keren, O Hazzan, and Y Dubinsky. Agile software testing in a large-scaleproject, 2006. ISSN 0740-7459.

[110] Gregory Tassey. The economic impacts of inadequate infrastructure for software tes-ting. National Institute of Standards and Technology, RTI Project, 7007(011), 2002.

[111] Tesco. Tesco, September 2016. URL http://www.tesco.com/.

[112] TestEra. TestEra, September 2016. URL http://cs.txstate.edu/~g_y10/testera/.

[113] R Thomsett. The year 2000 bug: a forgotten lesson. IEEE Software, 15(4):91–93,95,1998. ISSN 0740-7459. doi: 10.1109/52.687956.

[114] ThoughtWorks. ThoughtWorks, September 2016. URL https://www.thoughtworks.

com/insights/blog/introduction-sahi-part-1.



http://www.ruby-lang.org/en/

http://www.apple.com/safari/

http://sahipro.com/

https://saucelabs.com/

http://www.seleniumhq.org/

http://www.seleniumhq.org/docs/02_selenium_ide.jsp

http://www.seleniumhq.org/docs/02_selenium_ide.jsp


https://smartbear.com/

http://www.tesco.com/

http://cs.txstate.edu/~g_y10/testera/

https://www.thoughtworks.com/insights/blog/introduction-sahi-part-1

https://www.thoughtworks.com/insights/blog/introduction-sahi-part-1

Bibliografia 71

[115] ThoughtWorks. ThoughtWorks, September 2016. URL https://www.thoughtworks.

com/pt.

[116] Tricentis. Tricentis, September 2016. URL http://www.tricentis.com/.

[117] Unirest. Unirest, September 2016. URL http://unirest.io/java.html.

[118] USE-OCL. USE-OCL, September 2016. URL http://sourceforge.net/projects/

useocl/.

[119] Samuel H. Valentine. The programming language Z–. Information and Software Tech-nology, 37(5-6):293–301, 1995. ISSN 09505849. doi: 10.1016/0950-5849(95)99365-T.

[120] Fei Wang and Wencai Du. A test automation framework based on WEB. Proceedings -2012 IEEE/ACIS 11th International Conference on Computer and Information Science, ICIS2012, pages 683–687, 2012. doi: 10.1109/ICIS.2012.21.

[121] Sarita Warrier and Brian McGillen. The evolution of quality improvement. Medicineand health, Rhode Island, 94:211–212, 2011. ISSN 1086-5462.

[122] Watir. Watir, September 2016. URL https://watir.com/.

[123] Elaine J. Weyuker and Filippos I. Vokolos. Experience with performance testingof software systems: Issues, an approach, and case study. IEEE Transactions onSoftware Engineering, 26(12):1147–1156, 2000. ISSN 0098-5589. doi: http://doi.ieeecomputersociety.org/10.1109/32.888628.

[124] James a Whittaker. What Is Software Testing ? And Why Is It So Hard ? Softwaretesting. Ieee Software, 17(1):70–79, 2009.

[125] James C. P. Woodcock and Peter G. Larsen, editors. Tool Descriptions, pages 679–689.Springer Berlin Heidelberg, Berlin, Heidelberg, 1993. ISBN 978-3-540-47623-8. doi:10.1007/BFb0024674. URL http://dx.doi.org/10.1007/BFb0024674.

[126] Yahoo. Yahoo, September 2016. URL http://www.yahoo.com.

https://www.thoughtworks.com/pt

https://www.thoughtworks.com/pt

http://www.tricentis.com/

http://unirest.io/java.html

http://sourceforge.net/projects/useocl/

http://sourceforge.net/projects/useocl/

https://watir.com/

http://dx.doi.org/10.1007/BFb0024674

http://www.yahoo.com

AI N S TA L A Ç Ã O E C O N F I G U R A Ç Ã O D A J AVA V I RT U A L M A C H I N E

Sendo a Java Virtual Machine essencial para a execução deste projeto, neste capítulo serádescrito todos os passos necessários para a sua instalação sobre um ambiente Linux Ubuntu.Será assumido que o sistema operativo se encontra atualizado.No caso de ser necessário editar o código Java do projeto será necessário ter o JDK - JavaDevelopment Kit instalado, no entanto caso o intuito seja apenas executar o projeto bastaráinstalar o JRE - Java Runtime Environment. Como o JDK já inclui o JRE, será apenasapresentado o processo de instalação do JDK.Desta forma, basta adicionar o repositório aos já existentes do Ubuntu. Para tal bastaráexecutar:

sudo add -apt -repository ppa:webupd8team/javasudo apt -get updatesudo apt -get install oracle -java8 -installer

Código A.1: Instalação JVM

Após a execução destes comandos para verificarmos se a instalação correu normalmentebasta executar o seguinte comando que nos indica a versão do java instalado:

java -versionjava version "1.8.0 _05"Java (TM) SE Runtime Environment (build 1.8.0_05 -b13)Java HotSpot (TM) 64-Bit Server VM (build 25.5-b02 , mixed mode)

Código A.2: Verificação versão JVM

Por fim apenas é necessário efetuar a configuração das variáveis de ambiente. Para tal,basta executar o seguinte comando que instala um pacote do novo repositório adicionado:

sudo apt -get install oracle -java8 -set -default

Código A.3: Configuração ambiente

72

BI N S TA L A Ç Ã O E C O N F I G U R A Ç Ã O D O P O S T F I X

De forma a ser possível enviar emails a partir da máquina onde o projeto se encontra acorrer é necessário proceder à instalação e configuração do postfix. Assim para a instalaçãodo postfix no sistema operativo Linux Ubuntu basta executar:

sudo apt -get install postfix

Código B.1: Instalação postfix

Ao executar este comando irá aparecer um ecrã azul a pedir o tipo de configuração queestá a ser feita, que neste caso deve ser "Internet Site". De seguida é necessário indicar umnome para utilizar para o dominio por defeito nos emails, sendo que neste caso podemosdeixar o nome que é apresentado, ou alterar caso pretendido.Após a instalação ter terminado, de forma a validarmos a configuração iremos instalar umnovo pacote que nos permitirá testar de forma simples o envio. Assim basta executar:

sudo apt -get install mailutils

Código B.2: Instalação mailutils

E efetuar um envio de teste com:

echo "This is the body of the email" | mail -s "This is the subject line"[email protected]

Código B.3: Teste de envio email

Se tudo correr bem, será recebido endereço indicado o respetivo email.

73

CI N S TA L A Ç Ã O E C O N F I G U R A Ç Ã O D A S E L E N I U M G R I D

Neste capítulo será descrito como instalar e configurar uma rede de nodos Selenium, de-nominados por Selenium Grid. Será assumido que já se encontra instalado na máquinaprincipal (HUB) tanto o Java Runtime Environment, bem como o postfix, e nos nodos estaráinstalado também o Java Runtime Environment. Será assumido um sistema de exemplo de5 máquinas fisicas, sendo uma a principal (HUB) com sistema operativo Linux, um nodoLinux, um nodo MAC OS X, e dois nodos com Windows XP e Windows 10 respetivamente,conforme a Figura 11.Conforme indicado no capítulo 3 já existe a versão 3.0 do Selenium, no entanto devido aainda se encontrar em versão beta, a versão utilizada foi a versão 2.53, pelo que este capítuloserá baseado nessa mesma versão.

Uma vez que o Selenium é distribuído como um programa java, vem no formato .jar,sendo que o programa em si não é efetivamente instalado, mas sim executado apenas.Como a versão mais recente já está disponível para download na página principal, de formaa fazer download da versão 2.53 teremos de aceder ao arquivo de versões disponível em:

http://selenium -release.storage.googleapis.com/index.html?path =2.53/

Código C.1: Download Selenium 2.53

Assim, no endereço basta fazer download do arquivo selenium-server-standalone-2.53.1.jare guardar onde desejarmos, como por exemplo na home do sistema Linux.Este ficheiro seráo mesmo utilizado para todas as máquinas.De forma a executar o Selenium em modo hub bastará apenas através do terminal na pastaonde se encontra o ficheiro executar:

java -jar selenium -server -standalone -2.53.1. jar -role hub

Código C.2: Execução Selenium HUB

Ao indicarmos o parametro -role hub indicamos que deve ser lançado no modo de servi-dor. Desta forma já teremos uma máquina a efetuar todo o trabalho principal, pelo que será

74

75

ela a responsável por receber os testes e comunicar com os nodos. Se o servidor inicializarcom sucesso deve ser apresentada o seguinte resultado:

15:07:59.294 INFO - Launching a standalone Selenium Server15:07:59.322 INFO - Java: Oracle Corporation 25.91- b1415:07:59.322 INFO - OS: Linux 4.4.0-21- generic amd6415:07:59.332 INFO - v2.53.1 , with Core v2 .53.1. Built from revision a36b8b115:07:59.383 INFO - Driver provider org.openqa.selenium.ie.

InternetExplorerDriver registration is skipped:registration capabilities Capabilities [ ensureCleanSession=true , browserName=

internet explorer , version=, platform=WINDOWS ] does not match the currentplatform LINUX

15:07:59.384 INFO - Driver provider org.openqa.selenium.edge.EdgeDriverregistration is skipped:

registration capabilities Capabilities [ browserName=MicrosoftEdge , version=,platform=WINDOWS ] does not match the current platform LINUX

15:07:59.384 INFO - Driver class not found: com.opera.core.systems.OperaDriver15:07:59.384 INFO - Driver provider com.opera.core.systems.OperaDriver is not

registered15:07:59.385 INFO - Driver provider org.openqa.selenium.safari.SafariDriver

registration is skipped:registration capabilities Capabilities [ browserName=safari , version=,

platform=MAC] does not match the current platform LINUX15:07:59.385 INFO - Driver class not found: org.openqa.selenium.htmlunit.

HtmlUnitDriver15:07:59.385 INFO - Driver provider org.openqa.selenium.htmlunit.

HtmlUnitDriver is not registered15:07:59.428 INFO - RemoteWebDriver instances should connect to: http://

127.0.0.1:4444/ wd/hub15:07:59.428 INFO - Selenium Server is up and running

Código C.3: Selenium HUB a correr

Desta forma, como podemos verificar no output, o servidor encontra-se a correr, sendoque os nodos devem-se ligar a http://127.0.0.1:4444/wd/hub no caso de serem locais, ouentão utilizando o endereço IP externo da respetiva máquina.

Para configurar os nodos com o Sistema Operativo Linux, o comando será semelhante,no entanto terão de ser passados diferentes parâmetros. De forma a facilitar a configuração,estes parâmetros também pode ser passados através de um ficheiro de configuração JSON.Assim, deverá ser criado um ficheiro com o seguinte conteúdo (Considerando a configura-ção de uma máquina Windows 10):

"capabilities":

[

76

"browserName": "firefox","maxInstances": 5,"platform": "WINDOWS"

,

"browserName": "chrome","maxInstances": 5,

,

"browserName": "internet explorer","maxInstances": 1,

],

"configuration":

"proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy","maxSession": 5,"port": 5555,"register": true ,"registerCycle": 5000,"hubPort": 4444,"hubHost": "127.0.0.1"

Código C.4: Exemplo JSON configuração nodo

Este ficheiro encontra-se estruturado em dois blocos, sendo que o primeira indica osbrowsers que vão estar disponíveis na máquina para serem utilizados, e o segundo defineas configurações gerais de ligação ao HUB, entre outros.De forma pormenorizada, na secção capabilities deverão ser definidos os browsers, bemcomo o sistema operativo, e o número máximo de instâncias em simultâneo. Na secção deconfigurations, indicando o endereço da máquina do hub, a porta, e outras configuraçõesimportantes.

Assim, com base no ficheiro indicado anteriormente para colocar em execução um nodonuma máquina deve ser executado o seguinte comando (considerando o ficheiro com onome node.json:

java -jar selenium -server -standalone -2.53.1. jar -role node -nodeConfig node.json

Código C.5: Execução nodo Selenium

77

No caso das máquina com o Sistema Operativo Windows, a sua execução é igual.

Agora já temos os nodos registados todos no hub podemos aceder através do browser a:

http://<ip-da-maquina >:4444/ grid/

Código C.6: Interface Web Selenium

e verificar quais os nodos disponíveis, bem como os browsers disponíveis e em utilização.A partir deste momento a grid encontra-se configurada e já é possível ser utilizada normal-mente.

DE X E C U Ç Ã O D A A P L I C A Ç Ã O D E S E N V O LV I D A

Conforme indicado no capítulo 4, a aplicação desenvolvida encontra-se disponível em Java,nomeadamente num ficheiro .jar e tal como o Selenium, pode ser executada através domesmo modo, em ambiente Unix ou Windows, com os parâmetros indicados em 4.12, porexemplo:

java -jar WebTest.jar -c config.json

Código D.1: Execução WebTest

Relativamente aos parâmetros o argumento -c é obrigatório, uma vez que é o ficheiroprincipal que indica todos os testes que serão executados.Desta forma a aplicação irá executar todo o processo necessário e enviar a informação aohub do selenium. No final o resultado é indicado através do Exit Code1, além do ficheirocom o relatório produzido.

1 Código com resultado da execução do programa

78

EE X E M P L O F I C H E I R O J S O N D E C O N F I G U R A Ç Ã O

"general_config":

"reports_path": "/home/tfb/projects/webtest -report/","test_name": "Main","selenium_address": "http ://127.0.0.1:4444/ wd/hub"

,"tests_to_run":

"pageTitleTest": "execute_on": [


],"data": [


,

"url": "https ://www.websiteexemplo.pt/seccao/noticias/","expected": "WebSite - Notícias"

]

,"AltImgTest":

"execute_on": [


],"data": [

79

80

"url": "https ://www.websiteexemplo.pt/"

],"BrokenLinkTest":

"execute_on": [


],"data": [


]

,"TagsOGTest":

"execute_on": [

"platform": "LINUX","browser": "firefox"

],"data": [

"url": "https ://www.websiteexemplo.pt/noticias/noticia -1/"

]

,"TagsTwitterTest":

"execute_on": [

"browser": "chrome"

],"data": [


]

,"W3CTest":

"execute_on": [

"browser": "chrome"

81

],"data": [


]

,"GeneralConsoleTest":

"execute_on": [

"browser": "chrome"

],"data": [


]

,"FavIconTest":

"execute_on": [

"browser": "firefox"

],"data": [


]

,"SEOTest":

"execute_on": [

"browser": "chrome"

],"data": [


]

,"FormTest":

"execute_on": [

"platform": "LINUX",

82

"browser": "chrome"

],"data": [

"url": "https ://www.websiteexemplo.pt/examples/simple.html

","form_id": "demo -form","form_data" : [

"text": "Exemplo de texto no campo","email": "[email protected]","checkbox": true ,"positive": true

,

"text": "Exemplo de te219083090 ’’","email": "tfb@sss","checkbox": false ,"positive": false

]

]

,"RedirectTest":

"execute_on": [

"browser": "chrome"

],"data": [

"url": "https ://www.websiteexemplo.pt/asdasdasd","expected": "https ://www.websiteexemplo.pt/"

]

,"external_tests":

"teste externo": "name": "teste externo","execute_on": [


83


"class_path": "/home/tfb/exemplos/","filename": "HelloWorld","class_name": "HelloWorld"

,"data": [


,

"url": "https ://www.websiteexemplo.pt/exemplo","expected": "WebSite"

]

,"teste externo2":

"name": "teste externo2","execute_on": [



"class_path": "/home/tfb/exemplos/","filename": "Teste","class_name": "Teste"

,"data": [


,


]

,"alloy_models":

"login": "name": "login","model_path": "/home/tfb/exemplos/login.als","check_for_counter_examples": true

84

Código E.1: Exemplo ficheiro JSON

FE X E M P L O C L A S S E E X T E R N A

import com.relevantcodes.extentreports.ExtentTest;import com.relevantcodes.extentreports.LogStatus;import file.Data;import general.Main;import testing.BaseTest;import org.junit.Before;import org.junit.Test;import org.junit.runner.RunWith;import org.junit.runners.Parameterized;import org.openqa.selenium.WebDriver;

import java.util.List;

import static org.junit.Assert.assertTrue;

/**** This class tests an certain web page* for it’s title.* It receives the title to check , and the link of* the web page.** @author tfb*/

@RunWith(Parameterized.class)public class HelloWorld extends BaseTest

/*** This method returns all data witch is going* to be used in test** @return The Data that is going to be used* @throws Exception*/

85

86


return Main.getConf ().getTestConfigs ().get("teste externo").getData ();

/*** Main constructor** @param data Data to be used in test*/

public HelloWorld(Data data)super(data);super.setDetails("teste externo", "Page Title Test - HELLOWORLD", "

External", "Example", "");

/*** This method goes to web page and compares the title*/


WebDriver driver = super.getDriver ();Data data = super.getMyData ();


Boolean result = false;String title = driver.getTitle ();String expected = data.getExpected ();


if(title.equals(expected)) test.log(LogStatus.PASS , "Got: " + title);result = true;

elsetest.log(LogStatus.FAIL , "Not Matched. Got: ’" + title + "’ And

expected: ’" + expected + "’");


assertTrue(result);

Código F.1: Exemplo classe externa

GC Ó D I G O - C A S O D E T E S T E 1

teste de login

import com.relevantcodes.extentreports.ExtentTest;import com.relevantcodes.extentreports.LogStatus;import file.Data;import general.Main;import testing.BaseTest;import org.junit.Before;import org.junit.Test;import org.junit.runner.RunWith;import org.junit.runners.Parameterized;import org.openqa.selenium.WebDriver;import org.openqa.selenium.By;import org.openqa.selenium.WebElement;



/**** @author tfb*/

@RunWith(Parameterized.class)public class TeraLogin extends BaseTest


@Parameterized.Parameters

87

88

public static List <Data > getData () throws Exception return Main.getConf ().getTestConfigs ().get("tera login").getData ();

/*** Main constructor** @param data Data to be used in test*/

public TeraLogin(Data data)super(data);super.setDetails("tera login", "Test login", "External", "Example", ""

);


WebDriver driver = super.getDriver ();Data data = super.getMyData ();String expected = data.getUrl ();


Boolean result = false;WebElement form = driver.findElement(By.id("login -form"));WebElement username_field = driver.findElement(By.id("id_username"));WebElement password_field = driver.findElement(By.id("id_password"));

username_field.sendKeys("user_wrong");password_field.sendKeys("password_wrong");

form.submit ();


if(driver.getCurrentUrl ().equals(expected)) test.log(LogStatus.PASS , "Login Failed");result = true;

elsetest.log(LogStatus.FAIL , "Got other page");


assertTrue(result);

89

Código G.1: Código caso de teste 1 - Login

teste de criação de pasta

import com.relevantcodes.extentreports.ExtentTest;import com.relevantcodes.extentreports.LogStatus;import file.Data;import general.Main;import testing.BaseTest;import org.junit.Before;import org.junit.Test;import org.junit.runner.RunWith;import org.junit.runners.Parameterized;import org.openqa.selenium.WebDriver;import org.openqa.selenium.By;import org.openqa.selenium.WebElement;



/***** @author tfb*/

@RunWith(Parameterized.class)public class TeraTest extends BaseTest



return Main.getConf ().getTestConfigs ().get("tera login").getData ();

/**

90

* Main constructor** @param data Data to be used in test*/

public TeraTest(Data data)super(data);super.setDetails("tera login folder", "Test login folder", "External",

"Example", "");


WebDriver driver = super.getDriver ();Data data = super.getMyData ();String expected = "http ://10.10.10.247/";


Boolean result = false;WebElement form = driver.findElement(By.id("login -form"));WebElement username_field = driver.findElement(By.id("id_username"));WebElement password_field = driver.findElement(By.id("id_password"));

username_field.sendKeys("user");password_field.sendKeys("pass");

form.submit ();


if(driver.getCurrentUrl ().equals(expected)) test.log(LogStatus.PASS , "Login OK");

elsetest.log(LogStatus.FAIL , "Login Failed" + driver.getCurrentUrl ());

WebElement backup_button = driver.findElement(By.cssSelector("a[href=’/dashboard/backups/’]"));

backup_button.click ();

WebElement folder_create = driver.findElement(By.cssSelector("a[href=’/dashboard/backups/detail/’]"));

folder_create.click ();

WebElement name_input = driver.findElement(By.cssSelector("input[name=’name ’]"));

91

name_input.sendKeys("test");

WebElement create_form = driver.findElement(By.id("createBackupForm"));

create_form.submit ();

WebElement table = driver.findElement(By.id("backupstable"));

List <WebElement > tableRows = table.findElements(By.tagName("tr"));for (WebElement row : tableRows) WebElement td = row.findElement(By.cssSelector("td[class=’name ’]"));if (td.getText ().equals("test"))

result = true;

if(result)

test.log(LogStatus.PASS , "Folder detected");else

test.log(LogStatus.FAIL , "Folder not detected");


assertTrue(result);

Código G.2: Código caso de teste 1 - Pasta

testes em aplicações web - universidade do minho · testes em aplicações web outubro 2016....

Documents