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