PortalB2B e optimização do processo de testesfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Teses/Tese_Mest_Hug… · Classe de programação Java utilizada para estender as capacidades

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Mestrado em Informática e Sistemas Estágio/Projeto Industrial

Relatório Final

PortalB2B e Otimização do Processo de Testes

Hugo Luís Rodrigues Vitória Lopes

Orientador:

João Carlos Costa Faria da Cunha

Instituto Superior de Engenharia de Coimbra

Coimbra, setembro, 2012

Portal B2B e Testes RESUMO

ii

RESUMO Este documento descreve o trabalho realizado pelo autor na empresa Present Technologies,

durante o ano letivo 2011/2012, no contexto da disciplina Estágio/Projeto Industrial do Mestrado em

Informática e Sistemas do Instituto Superior de Engenharia de Coimbra.

O estágio consistiu no desenvolvimento e implementação de uma proposta de procedimento de

testes destinada ao usufruto da Present Technologies, baseada no estudo e análise de práticas

realizadas pela organização, bem como, de recomendações existentes na literatura científica sobre

atividades de testes de software. O foco principal incidiu nos testes sobre interface de aplicações web,

explorando de um ponto de vista prático, as suas principais caraterísticas, potencialidades e limitações.

Para se apurar a adequabilidade das recomendações propostas, o procedimento de testes foi

aplicado a um produto web denominado de Portal B2B. As soluções e técnicas para implementação de

testes automáticos web foram abordadas com recurso às ferramentas WebDriver e Arquillian

Graphene.

O Portal B2B resultou de um projeto adjudicado à Present Technologies, no qual o estagiário foi

parcialmente responsável pelo desenvolvimento da interface web de um sistema de gestão Machine-

To-Machine. O cliente do projeto, dono de uma plataforma Machine-To-Machine, pretende ocupar um

lugar de referência neste segmento de mercado, onde se estima que cerca de 50 mil milhões de

dispositivos já se encontram atualmente a beneficiar deste tipo de comunicação. O principal objetivo é

a exploração de serviços inteligentes, soluções capazes de atuar e reagir perante a informação

remotamente recolhida.

O trabalho desenvolvido permitiu aumentar o conhecimento da Present Technologies na área de

Software Testing, proporcionando os seguintes resultados tecnológicos: a aplicação Portal B2B; a

proposta de otimização de testes incluindo um guia de testes e template para plano de testes;

documentação da aplicação dessa mesma proposta ao produto Portal B2B.

Portal B2B e Testes ABSTRACT

iii

ABSTRACT This document describes the work performed by the author in the company Present

Technologies, throughout the academic year 2011/2012, in the context of the discipline Estágio/Projeto

Industrial for the master's degree in Engenharia Informática e de Sistemas of the Instituto Superior de

Engenharia de Coimbra.

The internship consisted in the development and implementation of a test procedure proposal

conceived for the usufruct of the Present Technologies based on the study and analysis of practices

performed by organization and recommendations existing in the scientific literature about software

testing activities. The main focus was web interface tests, exploring from a practical point of view,

their main features, potentialities and limitations.

To ascertain the suitability of the proposed recommendations, the tests procedure was applied to

a web product named Portal B2B. The solutions and techniques for automated testing of web were

addressed using the tools WebDriver and Arquillian Graphene.

Portal B2B has resulted from a project adjudicated to Present Technologies, in which the intern

was partially responsible for the development of a web interface for a management system Machine-

To-Machine. The project’s client, owner of one Machine-To-Machine platform, has chased a place of

reference in this market segment, where it’s estimated that about 50 thousand millions of devices are

already been benefiting from this type of communication. The main goal is the exploration of

intelligent services, solutions that are able to act and react to information remotely collected.

The work developed has raised knowledge of the Present Technologies in the Software Testing

field, providing the following technological results: Portal B2B application; a proposed optimization

of tests including a test guide and template for test plan; documentation of the application of this same

proposal to the B2B Portal product.

Portal B2B e Testes PALAVRAS-CHAVE

iv

PALAVRAS-CHAVE Testes web, Testes GUI, Aplicações web, Testes funcionais, Processo de testes, Plano de testes, TMMi, Técnicas de desenho de testes web, Model-Driven Test Design, Qualidade de software, Testes Java EE

KEYWORDS Web tests, GUI tests Web applications, Functional tests, Test process, Test Plan, TMMi, Web test design techniques Model-Driven Test Design, Software Quality, Java 2EE testing

Portal B2B e Testes GLOSSÁRIO

v

GLOSSÁRIO Termo Descrição

AJAX Asynchronous JavaScript And XML – Utilização metódica das tecnologias HTTP, JavaScript e XML na comunicação assíncrona com o servidor com o intuito de receber e apresentar informação sem interromper a interface utilizador.

API Application Programming Interface – Conjunto de métodos estabelecidos por um software para utilização das suas funcionalidades.

AUT Application Under Test – Aplicação de software verificada e validada com o processo de teste.

B2B Business To Business – Comércio associado a operações de compra e venda de informações, produtos e serviços com outros parceiros de negócio.

B2C Business To Consumer – Comércio efetuado diretamente entre a empresa produtora, vendedora ou prestadora de serviços e o consumidor final.

Browser Aplicação cliente que permite a receção, interpretação e visualização de recursos disponíveis na web.

Bug Tipicamente é um erro no funcionamento comum de um software.

Build Refere-se ao processo de conversão de código-fonte em artefactos de software que podem ser posteriormente executados num computador.

ContextPath Prefixo de um caminho URL que identifica qual a aplicação web para a qual os pedidos devem ser encaminhados.

CRUD Create/Read/Update/Delete – Refletem as quatro funções base relacionadas com a persistência da informação de uma aplicação.

CDI Context Dependency Injection – Permite, através da utilização de anotações Java, injectar dependências de forma simplificada.

Change Request Tipicamente uma declaração de pedido de ajuste/alteração de uma funcionalidade de um sistema.

Checklist Lista de tarefas utilizada para compensar memória ou atenção do autor.

CSS Cascading Style Sheet - Linguagem que permite definir estilos a documentos escritos em HTML e XHTML.

Deployment Processo composto por todas as atividades necessárias para que o sistema fique disponível para uso.

DOM Document Object Model – Convenção para representação e interação com objetos em documentos HTML e XHTML independente de plataformas/linguagens.

EAR Enterprise Archive - Formato de ficheiro utilizado pelo Java EE que agrupa um ou mais módulos num arquivo apenas para que o deployment desses módulos ocorra simultaneamente de maneira consistente no servidor aplicacional.

eHealth Serviços de saúde assegurados por processos e comunicação eletrónica.

End-to-end testing Consiste no processo de teste que inclui funcionalidades de todas as camadas constituintes da arquitetura da solução.

Fleet management Solução para gestão de frota de transporte de uma companhia.

Framework Consiste numa plataforma de software (conjunto de bibliotecas, classes) reutilizável para desenvolvimento de aplicações, produtos e soluções. Pode ser vista como uma abstração de funcionalidades genéricas que podem ser personalizadas pelos programadores.

Front-end Termo generalizado para especificar a camada do sistema de software que interage diretamente com o utilizador.

GUI Graphical User Interface – representa a exteriorização visual da aplicação com a qual o utilizador tem a possibilidade de interagir.

HTML HyperText Markup Language – Linguagem de markup predominante na criação de páginas web, interpretada por um browser para disponibilização de conteúdo para o utilizador final.

HTTP HyperText Transfer Protocol – Protocolo de comunicação de nível aplicacional.

Hub Arquitetura que permite a transmissão e difusão de determinada informação em simultâneo para vários recetores.

IDE Integrated Development Environment – programa que reúne caraterísticas e ferramentas de apoio ao desenvolvimento de software com o objetive de agilizar o processo.

IEEE Institute of Electrical and Electronics Engineers – Organismo profissional dedicado à evolução


vi

e inovação tecnológica e excelência. Internet Sistema global de redes de computadores interligadas. Issue Tracker Sistema onde são mantidos e geridos vários problemas de um determinado projeto de software.

JAR Java Archive - Formato de ficheiro utilizado que agrega vários ficheiros Java .class associando meta-dados e recursos (texto, imagens e etc) num arquivo apenas para distribuição de software aplicacional numa plataforma Java.

Java Linguagem de programação orientada a objetos, derivada das linguagens de programação C e C++.

JavaScript Linguagem de script geralmente utilizada no lado do cliente das aplicações web e que permite o acesso e manipulação de dados de forma dinâmica melhorando a interface utilizador.

Java Virtual Machine ou JVM Corresponde ao componente da plataforma de software Java responsável pela execução do código (normalmente Java bytecode).

jQuery Bibliotecas da linguagem JavaScript que simplifica a interação com HMTL, tratamento de eventos, animações interações AJAX.

JSON JavaScript Object Notation - Formato de dados leve de fácil interpretação. JSP Tecnologia que providencia uma maneira simples e rápida de criar conteúdo dinâmico web.

M2M Machine To Machine – Conceito de negócio, originado pelo desenvolvimento de telemetria, utilizado para medir e transmitir automaticamente dados provindos de fontes remotas através de uma rede.

Mock Objeto utilizado durante o desenvolvimento e realização de testes que simula o comportamento de um objeto real.

MVC Model-View-Controller – Arquitetura padrão utilizada em Engenharia de Software que permite isolar a lógica computacional da interface utilizador, permitindo desenvolver e testar cada componente separadamente.

Open-Source Filosofia de desenvolvimento e distribuição de software que inclui a disponibilização do código fonte de todas as aplicações.

Quality Assurance Conjunto de atividades planeadas e sistemáticas implementadas num sistema de qualidade para que os produtos ou serviços efetuados satisfaçam os requisitos de qualidade.

RFP Request For Proposal – Processo de aquisição, onde os fornecedores são convidados a apresentar uma proposta para um serviço específico.

Sandbox JS Componente constituinte dos browsers responsável pela interpretação do código JavaScript.

Script Ficheiro executável desenvolvido numa linguagem de programação que executa uma rotina pré-definida.

Servlet Classe de programação Java utilizada para estender as capacidades dos servidores web. Utilizam o modelo de programação pedido-resposta.

Smart Metering Solução constituída pela medida de consumo por parte de um dispositivo em intervalos de tempo regulares e posteriores envios dessa informação para uma unidade centralizada para monitoria e faturação.

Smart Service Serviço inteligente capaz de agir perante informação recolhida de maneira autónoma. SQL Injection Técnica utilizada para atacar base de dados através de um site web.

Stub Semelhante ao Mock mas conserva um estado interno derivado das chamadas durante a execução dos testes.

SVN Sistema de controlo de versão desenhado especificamente para ser um substituto do CVS. Tag library Define um conjunto de tags personalizadas para utilização nas JSPs.

TestRunner Componente de framework de testes tipicamente responsável pela gestão do ciclo de vida dos testes, incluindo a sua execução.

TMMi Test Maturity Model integrated – modelo de otimização do processo de testes baseado no modelo Capability Maturity Model Integration (CMMI).

URL Uniform Resource Locator – Especifica um texto que referencia um recurso da internet.

User Stories Cenários de utilização descritos numa linguagem simplificada para que o utilizador final ou utilizador do sistema compreenda o que necessita de fazer durante a interação com o sistema.

Voucher Trata-se de um título, recibo ou documento que comprova o pagamento e o direito a um serviço ou a um produto.

VPN Virtual Private Network - Rede de comunicações privada normalmente utilizada por uma empresa ou um conjunto de empresas e/ou instituições, construída em cima de uma rede de comunicações pública (como por exemplo, a Internet).


vii

WAR Web Application Archive – Utilizado para agrupar JSPs, Java Servlet, Java .class, ficheiros XML e outros recursos que constituem uma aplicação web.

Web Abreviatura para Worl Wide Web. Sistema de documentos de diversos tipos de conteúdos interligados e acessíveis através da internet.

Wiki Termo identificativo de um conjunto de documentos em hipertexto ou o software colaborativo usado para a sua criação.

XSS Cross Site Scripting – Tipo de vulnerabilidade de segurança tipicamente associada a aplicações web, onde hackers injetam script do lado do cliente.

Portal B2B e Testes ÍNDICE

viii

ÍNDICE Resumo .................................................................................................................................................................... ii Abstract .................................................................................................................................................................. iii Palavras-Chave ....................................................................................................................................................... iv Keywords ............................................................................................................................................................... iv Glossário .................................................................................................................................................................. v Índice .................................................................................................................................................................... viii Índice de Figuras ..................................................................................................................................................... x Índice de Tabelas .................................................................................................................................................... xi 1. INTRODUÇÃO .................................................................................................................................................. 1

1.1. Apresentação do projeto/estágio ............................................................................................................ 1 1.2. Apresentação da Organização ................................................................................................................ 2 1.3. Introdução ao M2M ............................................................................................................................... 2 1.4. Motivação .............................................................................................................................................. 4 1.5. Objetivos atingidos ................................................................................................................................ 5 1.6. Estrutura do documento ......................................................................................................................... 6

2. ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES ............................................................. 8 2.1. Procedimentos de testes em vigor .......................................................................................................... 8 2.2. Resultado de projetos antecedentes ...................................................................................................... 12

2.2.1. Projeto A ..................................................................................................................................... 12 2.2.2. Projeto B ..................................................................................................................................... 13

2.3. Análise Informal .................................................................................................................................. 15 2.3.1. Ausência de uma política comum de testes ................................................................................. 15 2.3.2. Smoke tests .................................................................................................................................. 15 2.3.3. Testes no cliente .......................................................................................................................... 16 2.3.4. Formação e suporte documental ................................................................................................. 16 2.3.5. Testes automatizados ................................................................................................................... 16 2.3.6. Testes estáticos e registo de defeitos ........................................................................................... 17 2.3.7. Ensaio com Test-Driven Development ........................................................................................ 17

3. METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE ................................................................................. 18 3.1. Processos de testes ............................................................................................................................... 18

3.1.1. Contextualização de processos de testes ..................................................................................... 18 3.1.2. Otimização do processo de teste ................................................................................................. 22 3.1.3. Modelo em V ............................................................................................................................... 25 3.1.4. Metodologias de teste .................................................................................................................. 27 3.1.5. Plano de testes............................................................................................................................. 30 3.1.6. Sumário de processos de testes ................................................................................................... 33

3.2. Testes de interface web ........................................................................................................................ 34 3.2.1. Aplicações web ............................................................................................................................ 34 3.2.2. Desafios de testes web ................................................................................................................. 35 3.2.3. Contexto de testes web ................................................................................................................ 36 3.2.4. Técnicas de testes WUI ............................................................................................................... 38 3.2.5. Critérios de testes WUI ............................................................................................................... 39 3.2.6. Sumário de testes de interface web ............................................................................................. 41

3.3. Ferramentas de automatização de testes............................................................................................... 42 3.3.1. Ferramentas de testes funcionais ................................................................................................ 42


ix

3.3.2. Ferramentas de testes web .......................................................................................................... 44 3.3.3. Ferramentas de testes in-container ............................................................................................. 50 3.3.4. Ferramentas de testes JavaScript ................................................................................................ 56

4. CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES ............................................. 61 4.1. Software Testing Guide ........................................................................................................................ 61 4.2. Test Plan Template ............................................................................................................................... 64 4.3. Modelo de otimização TMMi .............................................................................................................. 66

5. CASO DE ESTUDO: PROJETO PORTAL B2B ....................................................................................................... 68 5.1. Principais Conceitos ............................................................................................................................. 68 5.2. Descrição do projeto ............................................................................................................................ 69 5.3. Arquitetura ........................................................................................................................................... 70 5.4. Tecnologias .......................................................................................................................................... 71

5.4.1. Java EE ....................................................................................................................................... 71 5.4.2. JBoss ........................................................................................................................................... 72 5.4.3. Stripes Web Framework .............................................................................................................. 72 5.4.4. Sitemesh ...................................................................................................................................... 72 5.4.5. JQuery ......................................................................................................................................... 73 5.4.6. HTML5 e CSS3 ............................................................................................................................ 73

5.5. Metodologia de desenvolvimento ........................................................................................................ 73 5.5.1. Planeamento e Especificação de requisitos ................................................................................ 73 5.5.2. Implementação ............................................................................................................................ 74 5.5.3. Validação ..................................................................................................................................... 74 5.5.4. Aceitação ..................................................................................................................................... 74

5.6. Responsabilidades................................................................................................................................ 74 5.7. Ferramentas de apoio .......................................................................................................................... 75

6. APLICAÇÃO DO NOVO PROCEDIMENTO DE TESTES ........................................................................................ 76 6.1. Planeamento ......................................................................................................................................... 76 6.2. Desenho ............................................................................................................................................... 76

6.2.1 Testes de Navegação ................................................................................................................... 76 6.2.3. Testes de Validação de entradas .................................................................................................. 78 6.2.4. Testes da estrutura HTML e CSS ................................................................................................. 80 6.2.5. Testes AJAX ................................................................................................................................. 81

6.3. Automatização e Execução .................................................................................................................. 82 6.4. Avaliação e resultados .......................................................................................................................... 85

7. CONCLUSÕES ................................................................................................................................................ 88 7.1. Revisão do trabalho realizado .............................................................................................................. 88 7.2. Dificuldades ......................................................................................................................................... 89 7.3. Trabalho futuro .................................................................................................................................... 90

8. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................... 91 9. ANEXOS ........................................................................................................................................................ 93


x

ÍNDICE DE FIGURAS Figura 1 - Mercados alvo dos contributos de M2M (com base em [1]) ................................................................... 3 Figura 2 - Smart Services ........................................................................................................................................ 3 Figura 3- Processo de desenvolvimento da Present Technologies ........................................................................... 9 Figura 4 - Diagrama de atividade do processo de teste atual para aplicações web ................................................ 16 Figura 5 – Envolvente económica de testes de software (baseado em [33]).......................................................... 19 Figura 6 Testes estáticos e dinâmicos .................................................................................................................... 21 Figura 7 - Inquérito Forrester Consulting [7] ........................................................................................................ 25 Figura 8 - Modelo em V [5] ................................................................................................................................... 27 Figura 9 - Método de desenvolvimento TAD ........................................................................................................ 28 Figura 10 - Método de desenvolvimento TDD ...................................................................................................... 28 Figura 11 - Padrão Modelo-Vista-Controlador [35] .............................................................................................. 35 Figura 12 - Utilização dos browsers no StatCounter entre 08/2011 e 08/2012 ..................................................... 38 Figura 13 - Hierarquias de teste JUnit e TestNG ................................................................................................... 43 Figura 14 - Teste de pesquisa de filme .................................................................................................................. 48 Figura 15 – Elemento assinalado pelo Watir ......................................................................................................... 50 Figura 16 - Modos de execução do Arquillian (in-container vs client) ................................................................. 54 Figura 17 – Resultado do teste QUnit ................................................................................................................... 58 Figura 18 - Resultado do teste Jasmine ................................................................................................................. 59 Figura 19 - Índice do STG ..................................................................................................................................... 62 Figura 20 - Ciclo de vida de testes ........................................................................................................................ 63 Figura 21 - Ferramentas de teste selecionadas ...................................................................................................... 64 Figura 22 - Índice do TPT ..................................................................................................................................... 65 Figura 23 - Mapeamento do processo de testes para nível 2 do TMMi ................................................................. 67 Figura 24 – Diagrama de deployment do projeto ................................................................................................... 70 Figura 25 - Composição do Portal B2B ................................................................................................................. 71 Figura 26 - Ciclo de vida em Cascata .................................................................................................................... 73 Figura 27 - Grafo referente à navegação do Portal Business ................................................................................. 77 Figura 28 - Passo 1 e 2 do wizard de edição de Utilizador .................................................................................... 79 Figura 29 - Estados da dropdown de seleção de Aplicação Vertical ...................................................................... 80 Figura 30 - Testes automáticos Portal B2B ........................................................................................................... 82 Figura 31 - Exemplo de interações com os Page Ojects ....................................................................................... 83 Figura 32 - Execução automática de testes nos browsers IE e Chrome ................................................................. 84 Figura 33 - Resultado dos testes implementados ................................................................................................... 86 Figura 34 - Diagrama de contributos do estágio .................................................................................................... 88

Portal B2B e Testes ÍNDICE DE TABELAS

xi

ÍNDICE DE TABELAS Tabela 1 – Caso de teste no Test Case Specification Template .............................................................................. 11 Tabela 2 - Resultados do projeto A ........................................................................................................................ 13 Tabela 3 - Resultados do Projeto B........................................................................................................................ 14 Tabela 4 - Descrição dos níveis de maturidade TMMi .......................................................................................... 24 Tabela 5 - Componentes do Plano de testes IEEE 629-1983 ................................................................................. 32 Tabela 6 - Componentes do Plano de testes essenciais [19] .................................................................................. 33 Tabela 7 - Resumo das atividades do ciclo de vida dos testes ............................................................................... 63 Tabela 8 - Funcionalidades macro do Portal B2B ................................................................................................. 69 Tabela 9 - Casos de teste Navegação resultantes do critério Edge-Coverage ........................................................ 78 Tabela 10 - Input Space Partitioning da operação Edição de Utilizador ............................................................... 80 Tabela 11 - Casos de teste de transição de estado .................................................................................................. 81

CAPÍTULO 1

1

1. INTRODUÇÃO

Este estágio encontra-se inserido na disciplina de “Estágio/Projeto Industrial” do Mestrado

em Informática e Sistemas do Instituto Superior de Engenharia de Coimbra, sob orientação do

Professor João Cunha. Os trabalhos foram realizados nas instalações da empresa Present

Technologies, em Coimbra, sob orientação do Eng.º Samuel Santos devido à sua disponibilidade e

conhecimento técnico do projeto desenvolvido no contexto deste estágio.

1.1. Apresentação do projeto/estágio O trabalho apresentado neste documento insere-se no contexto de desenvolvimento e testes

de aplicações web. O âmbito inicial do projeto enquadrava-se apenas na aplicação Portal B2B

para gestão de uma plataforma Machine-To-Machine de um cliente e elaboração de testes

específicos de interface utilizador web. Contudo, a empresa não dispunha de documentação sobre

os procedimentos de teste em vigor. Assim, foi considerado útil a inclusão da formalização e

melhoria destas atividades no contexto do estágio. Por fim, como prova de conceito, o

procedimento de testes foi aplicado ao Portal B2B e foram retiradas conclusões do mesmo.

O início do estágio ocorreu no dia 14 de Novembro de 2011, tendo sido o esforço repartido

da seguinte forma (valores aproximados): 40% no desenvolvimento do projeto Portal B2B, 35%

na formalização e otimização do processo de testes e investigação de testes de interface gráfica

web. Finalmente, uma parcela de 25% foi dedicada à aplicação do processo de testes ao produto

Portal B2B.

Antes da realização deste trabalho, o estagiário encontrava-se com vínculo contratual full-

time com a Present Technologies. Esta situação obrigou a que o estágio não fosse pautado pela

carga horária da disciplina. O esforço despendido no estágio foi dinamicamente acordado com a

empresa, uma vez que paralelamente o estagiário executou tarefas referentes ao desenvolvimento

de outros projetos. Foram realizadas reuniões formais com periodicidade mensal, para atualização

do estado do projeto e definição de objetivos.

O projeto de desenvolvimento de software referente ao Portal B2B foi realizado em

parceria tecnológica com o cliente e implicou a integração de mais três elementos da Present

Technologies. O componente referente à otimização do processo de testes, numa vertente

documental, foi realizado apenas com a contribuição do estagiário e orientadores visando o

estabelecimento de boas práticas e recomendações atuais na implementação de testes de software

na empresa. Foi realizada também, a aplicação do processo de testes sob o Portal B2B, no sentido

de verificar a real mais-valia na adoção futura deste processo.

INTRODUÇÃO

2

1.2. Apresentação da Organização A Present Technologies foi fundada em 2000 e tem vindo a providenciar soluções e

serviços para diferentes mercados incluindo telecomunicações, finanças, indústria e setor público.

As soluções desenvolvidas destinam-se a clientes de renome em Portugal e no estrangeiro, entre

os quais Portugal Telecom Inovação, SAPO, Critical Software, ISA, Banco BPI, Siemens, TMN,

Optimus, Vodafone, Vivo (Brasil) e CVT (Cape Vert Telecom). A empresa encontra-se sediada na

cidade de Coimbra e tem como atividade principal, trazer tecnologia de informação para o

mercado, através do desenvolvimento de soluções inovadoras e competitivas, centradas nas áreas

de negócio de soluções móveis, aplicações empresariais e aplicações/serviços de internet.

Tem na sua constituição uma equipa fortemente especializada em investigação/inovação e

desenvolvimento, sendo fator resultante do compromisso de colaboração da empresa com grupos

de investigação em Universidades e participação em projetos de I&D juntamente com parceiros

de negócio. Os seus clientes e parceiros reconhecem a qualidade e profissionalismo empregue nos

seus serviços, nomeadamente na colaboração de projetos de software e consultadoria em

tecnologias de informação.

De forma a cimentar cada vez mais os padrões de excelência e qualidade das soluções

desenvolvidas pela Present Technologies, esta implementou um sistema de gestão integrado que

se encontra neste momento certificado pelas normas de Gestão de Qualidade – ISO 9001:2008 e

de Sistemas de Gestão da Investigação, Desenvolvimento e Inovação – NP 4457:2007.

O estagiário ocupa lugar numa equipa responsável pelo suporte, gestão e construção de

aplicações web empresariais especializada na experiência avançada para o utilizador final,

seguindo as normas web e compromisso com usabilidade da interface.

1.3. Introdução ao M2M Para enquadramento do leitor, nesta secção é efetuada a descrição do conceito

comunicações Machine-To-Machine, uma vez que se trata da área de negócio do Portal B2B.

Machine-To-Machine, ou simplesmente M2M, é visto por um número de organizações cada

vez maior como uma forma rápida, confortável e económica de retirar vantagens da ligação em

rede entre máquinas e dispositivos utilizados diariamente nas vidas de todos (por exemplo em

edifícios ou em veículos), de modo a alavancar novos serviços no mercado. Pode ser visto como

um conjunto de interações entre as pessoas e os seus produtos, que permitem obter informação de

estado de um dispositivo, como a sua localização, energia, temperatura, histórico de manutenção e

níveis de produtividade. Além de operações de consulta passiva, é ainda possível atuar sobre um

ou mais dispositivos selecionados através do envio de ordens de execução.

INTRODUÇÃO

3

Nos ambientes construídos com recurso ao M2M, os conteúdos e serviços são

automaticamente entregues ao consumidor com pouca ou nenhuma intervenção/manipulação

humana, abstraindo ainda a comunicação entre os diversos dispositivos [1]. A Figura 1 mostra as

principais áreas e mercados onde se tem vindo a verificar a aceitação com sucesso das tecnologias

M2M.

Figura 1 - Mercados alvo dos contributos de M2M (com base em [1])

Os dispositivos e máquinas envolvidas no M2M acabam por beneficiar da evolução

significativa das infraestruturas de comunicação, que providencia uma maior zona de cobertura,

taxas de transmissão de dados mais rápidas e baixo custo de instalação. Estes fatores habilitam a

criação de Smart Services, aplicações inteligentes capazes de atuar e reagir perante a informação

recolhida, e são extremamente importantes na comunicação e agregação de dados de maneira

semântica e de forma autónoma.

Figura 2 - Smart Services

INTRODUÇÃO

4

Como se pode observar no diagrama da Figura 2, os Smart Services baseiam-se na

automação e controlo, na localização, na provisão e na monitorização remota de dispositivos. Os

exemplos mais conhecidos são as soluções de Smart Metering, Fleet Management, eHealth,

gestão remota de máquinas automáticas de venda, domótica, sistemas de segurança,

infraestruturas de telecomunicações e equipamentos de gás e combustível.

De acordo com um estudo de mercado realizado em 2009, as estimativas apontavam para

que existissem aproximadamente 50 mil milhões de dispositivos a beneficiar das comunicações

M2M. Dada esta escala, o número de organizações que compete por uma posição de destaque

neste nicho de mercado é cada vez maior.

Com o surgimento de cada vez mais empresas a oferecer estes tipos de serviços, tornou-se

importante para o cliente da Present Technologies, através deste projeto, ocupar um lugar neste

panorama. A gestão de serviços à medida dos seus parceiros económicos é viabilizada através da

construção de uma plataforma genérica. Por questões de confidencialidade de informação

contratual, a empresa cliente será denominada neste documento como apenas Cliente.

1.4. Motivação Atualmente, as empresas competem a um ritmo acelerado, num mercado global em que os

clientes e seus colaboradores esperam serviços fáceis de usar, inovadores, sempre disponíveis e

competitivos.

O projeto incluído neste estágio surge no contexto da proposta, submetida pela Present

Technologies como resposta a um Request For Proposal do Cliente, para o desenvolvimento e

implementação de um Portal de Operação e Manutenção (POM) e Portal de Negócio (PN) para

uma plataforma M2M. A aplicação final deve oferecer aos seus utilizadores uma experiência rica,

com conteúdos dinâmicos e uma visão de serviço centrado no utilizador. No desenvolvimento foi

utilizada a framework da Present Technologies para aplicações web Java baseada nas tecnologias

Stripes1 e EJB32.

A metodologia utilizada anteriormente, à realização do estágio, não incluía testes

automáticos web. Os testes funcionais e de regressão na empresa eram executados com base num

esforço manual considerável, que tornava as aplicações web mais suscetíveis a defeitos, o que

podia afetar a qualidade das aplicações produzidas. Para prevenir estas situações, pretende-se que

seja elaborado um estudo tendo em consideração as novas ferramentas, e técnicas utilizadas para

automatizar o processo de execução de testes à camada de apresentação web, levando à

consequente redução excessiva dos recursos despendidos na etapa de execução dos testes.

1 http://www.stripesframework.org/display/stripes/Home 2 http://www.oracle.com/technetwork/java/javaee/ejb/index.html

INTRODUÇÃO

5

Durante o decurso do estágio, surgiu a oportunidade de incluir como objetivo, a elaboração

documental de um guia de testes de software na empresa de modo a formalizar as atuais práticas

de teste em vigor na empresa e adicionar novas atividades a ter em conta para testes de interface

de utilizador, facilitando assim a entrega de produtos com um nível de qualidade mais elevado.

A solução proposta do procedimento de testes deve contribuir para a normalização da etapa

de testes de software dos atuais e futuros projetos web dentro do contexto da Present

Technologies. É pretendido que, os resultados da pesquisa e desenvolvimento efetuados durante o

decurso deste trabalho, resultem numa real e efetiva contribuição de valor para a disseminação

interna de conhecimento da área de testes de software.

Seguindo a política da empresa, todas as soluções propostas deveriam privilegiar a

utilização de tecnologias e componentes de software open source, cujo código fonte é

disponibilizado ao público permitindo a cópia, modificação e distribuição legal sem custos ou

restrições.

1.5. Objetivos atingidos No âmbito deste estágio foram atingidos os seguintes objetivos:

Desenvolver o componente de apresentação gráfica que integre com a plataforma M2M

de acordo com os requisitos especificados e APIs disponibilizadas em articulação com o

trabalho da equipa do Cliente;

Explorar e selecionar ferramentas, técnicas, critérios e políticas de teste emergentes para

front-end de aplicações web, adquirindo o know-how para a sua utilização no âmbito de

diferentes projetos;

Implementar uma proposta de procedimento de testes composto pelos documentos Test

Plan Template e Software Testing Guide, incluindo a formalização das práticas que já se

encontravam em vigor na empresa, que ateste a correção, completude, precisão,

consistência e testabilidade de um produto de software;

Validar o novo procedimento de testes através da sua aplicação ao projeto Portal B2B e

subsequente análise de resultados;

Disseminar na Present Technologies o conhecimento sobre os assuntos do estágio

relacionados com testes de software.

INTRODUÇÃO

6

1.6. Estrutura do documento Para além desta introdução, este relatório está organizado da seguinte forma:

Capítulo 2 - Análise à prática de testes de SW na Present Technologies: o objetivo

deste capítulo é apresentar e descrever as metodologias relacionadas com testes de

software, exercidas na empresa na altura do início do estágio, fornecendo assim uma

vista global e background tecnológico interno existente na empresa. Numa vertente

mais de avaliação de qualidade de software produzido, são analisados os resultados de

projetos anteriores ao estágio.

Capítulo 3 - Metodologias e práticas de testes de software: neste capítulo é

apresentada uma análise do estado da arte sobre processo de testes de software.

Inclui ainda um estudo que distingue os métodos, critérios de cobertura,

técnicas e ferramentas atualmente disponíveis e mais utilizadas para elaboração

de testes com maior foco nos testes de interface utilizador web.

Capítulo 4- Conceção de um guia e plano de testes para a Present

Technologies: dando seguimento aos capítulos anteriores, é descrito o processo

de elaboração dos documentos reguladores de testes que visam combinar as

principais tecnologias e atividades de teste que melhor se adequam à realidade

atual da empresa.

Capítulo 5 - Caso de estudo: projeto portal b2b: neste capítulo é apresentado

o projeto Portal B2B, suas funcionalidades e arquitetura, descrevendo a

metodologia utilizada no seu desenvolvimento e o papel do estagiário na

equipa. É ainda realizada uma contextualização do sistema onde foi aplicado o

procedimento de testes elaborado no estágio.

Capítulo 6 - Aplicação do novo procedimento de testes: este capítulo existe

com o objetivo de demonstrar a viabilidade dos procedimentos de teste

propostos utilizando o Portal B2B como protótipo. Após a realização da

experiência são analisados e discutidos os resultados.

Capítulo 7 - Conclusões: neste capítulo é analisada a aplicação do novo

procedimento de testes desenvolvido, sendo extrapoladas conclusões e

oportunidades de melhoria baseadas nos resultados. É ainda efetuado um

balanço sobre o trabalho realizado, com destaque para objetivos alcançados e

INTRODUÇÃO

7

dificuldades sentidas. No final são apresentadas perspetivas e aspirações

futuras do estagiário.

Capítulo 8 - Referências Bibliográficas: possui a listagem de referências que

serviram de inspiração à escrita de conteúdos do relatório.

Capítulo 9 - Anexos: Inclui a lista de anexos do relatório.

CAPÍTULO 2

8

2. ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES

Uma da pretensões pessoais a atingir com a realização do estágio foi que o trabalho

desenvolvido fosse relevante e útil para o dia-a-dia na Present Technologies. Logo numa fase

inicial foi apurado que, de uma maneira geral, os programadores desconhecem o que é esperado

deles no que diz respeito a testes de software. Este aspeto acaba por ser reforçado pela insuficiente

documentação de procedimentos ou templates que possam ser utilizados durante os projetos.

Partindo destes pressupostos, um dos objetivos deste estágio foi recomendar uma otimização do

processo informal de testes da Present Technologies.

Para cumprir este objetivo, este capítulo pretende dar a conhecer os métodos de testes

efetuados antes do novo procedimento de testes proposto neste estágio. Esta informação foi

maioritariamente extraída do processo de desenvolvimento de software existente na organização,

que se passa a descrever.

2.1. Procedimentos de testes em vigor A organização utiliza o modelo de desenvolvimento em Cascata (Waterfall). Nesta

metodologia, apenas se pode transitar para uma fase seguinte caso a anterior se encontre

completa. Não existe paralelização de fases e não contempla iterações. Esta abordagem é simples,

sistemática e ortodoxa. Uma das principais desvantagens é o facto da maioria dos erros no código

apenas serem detetados quando se realiza a fase de testes. Esta situação penaliza o projeto sendo

necessário restabelecer o equilíbrio com um aumento de tempo, orçamento ou outros recursos.

Os projetos são normalmente realizados em parceria tecnológica com outras organizações,

sendo que cada uma das organizações gere o seu plano de projeto internamente, sincronizando

ocasionalmente em reuniões de controlo do projeto. Nestes projetos, o desenvolvimento é

realizado em conjunto com equipas de outras organizações, sendo por isso muitas vezes sujeitos à

metodologia imposta pelo cliente ou parceiro. A típica curta duração dos projetos e a experiência e

maturidade da empresa ajudam a atenuar as desvantagens desta metodologia relativamente a

abordagens iterativas e incrementais.

Toda a produção de sistemas de informação da empresa é regida de acordo com o processo

de gestão de desenvolvimento de software em vigor na empresa, que se destina a todos os

colaboradores envolvidos nas atividades de gestão ou de implementação dos projetos. O processo

é certificado pela norma internacional ISO 9001:2008 e pela norma portuguesa NP 4457:2007.

Encontra-se previsto neste processo a adoção de metodologias ágeis em situações excecionais,

ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES

9

onde é considerada como a melhor opção face às caraterísticas intrínsecas dos projetos. A Present

Technologies considera os seguintes tipos de projetos:

Projeto de Desenvolvimento de Software: projeto de desenvolvimento

habitualmente impulsionado por pedido de cliente;

Projeto R&DI: especialização de projeto de desenvolvimento que contém uma

componente de inovação, explorando uma nova ideia de produto/serviço ou

tecnologia;

Projeto de Suporte e Manutenção: projeto que providencia um serviço ao cliente

baseado na manutenção ou melhoria de um produto existente;

Projeto de Design e Usabilidade: projeto cujo objetivo é preparar e desenvolver

um desenho gráfico e estudo de usabilidade para um produto/serviço.

A formalização do procedimento de testes de software da empresa incide no contexto dos

três primeiros tipos de projetos apresentados.

O processo de desenvolvimento endereça e descreve as seguintes atividades: Início do

projeto, Fase de requisitos, Fase de implementação, Fase de validação, Fase de aceitação, Fase de

garantia, Fase de suporte e manutenção e por fim Disseminação de resultados do projeto R&DI

(Figura 3).

Inicio do projecto

Fase de validação

Fase de requisitos

Fase de aceitação

Fase de suporte e manutenção

Fase de implementação

Fase de garantia

Fase de suporte e manutençãod)

Figura 3- Processo de desenvolvimento da Present Technologies

1) Início de projeto

Nesta atividade é assegurada a definição da infraestrutura para o decurso do projeto,

nomeadamente através da criação do projeto nas ferramentas de controlo de versões CVS3 e de 3 http://www.nongnu.org/cvs/


10

gestão de projetos Redmine4 adotadas pela empresa. Envolve a elaboração do plano do projeto de

alto nível de acordo com a informação recebida pelo responsável da proposta ou diretor R&DI.

Durante esta atividade o gestor de projeto define o Quality Assurance Plan (QAP) no Redmine

estabelecendo as adaptações necessárias dependentes do tipo e caraterísticas do projeto.

No documento QAP os testes de software apenas são abordados no tópico Verificação e

Validação, onde está contemplada a identificação dos tipos de testes a realizar no projeto e a

advertência de que seja utilizada a última versão estável e recomendada das ferramentas de testes.

Depois de efetuadas tarefas de administração como a definição da equipa do projeto e a

criação de plano de faturação, a atividade é concluída com a realização da KOM (Kick-Off

Meeting), onde é apresentado o projeto, a equipa, a lista de artefactos a entregar bem como os

pressupostos e riscos.

2) Fase de requisitos

Esta atividade é constituída essencialmente pela definição dos requisitos e pela elaboração

do documento de especificação da arquitetura. Através dos métodos de comunicação

estabelecidos previamente com o cliente, são detalhados os requisitos funcionais e não funcionais.

Por outro lado, na elaboração da arquitetura da solução, deve ter-se em conta a experiência

adquirida em projetos anteriores e visa identificar os componentes principais, interfaces externas

do sistema e as tecnologias mais adequadas para o projeto.

3) Fase de implementação

Num passo inicial engloba a estimativa de esforço, dependências, precedências e atribuição

das tarefas de implementação aos recursos do projeto. Depois da calendarização das tarefas no

plano ficar concluída, dá-se início ao desenvolvimento de acordo com as normas e melhores

práticas das tecnologias aplicáveis ao projeto. Esta tarefa é realizada tendo em conta os requisitos

definidos na atividade anterior, assegurando o armazenamento dos artefactos e informação

produzida num sistema de controlo de versões (interno ou disponibilizado pelo cliente). No final

desta atividade, o processo menciona a especificação de casos de teste antes da fase de validação

de acordo com o documento Test Case Specification Template já existente. Neste documento

apenas considera a descrição tabelar de casos de testes, que foi de resto reutilizada no plano de

testes concebido no âmbito deste estágio, através do preenchimento de campos típicos, entre os

quais identificador do teste, objetivo, autor, valores de entrada, valores de saída, dependências e

requisitos cobertos (Tabela 1).

4 http://www.redmine.org/


11

Tabela 1 – Caso de teste no Test Case Specification Template

Especificação de teste Identificador de teste: <PROJECT-TCS-NNNN> Última atualização: <YYYY-MM-DD> Responsabilidade: Present Technologies Versão de teste: X.Y Objetivo: Autor(es): Especificações de entrada:

1. Entrada 1. 2. Entrada 2.

Especificações de saída: 1. Saída 1. 2. Saída 2.

Dependências: PROJECT-TCS-NNNN, … Requisitos: PROJECT-SWR-NNNN,…

4) Fase de validação

Esta atividade representa o ponto onde são executados os testes definidos no documento de

especificação mencionado na atividade anterior. Inicialmente é preparada uma release do produto

para testes. À medida que são detetadas anomalias durante a execução dos testes, estas são

registadas no Redmine e/ou no issue tracker disponibilizado pelo cliente como Defect para

posterior resolução da equipa de desenvolvimento. Caso se justifique a correção de defeitos pode

dar origem a uma nova release do software para um novo ciclo de testes.

5) Fase de aceitação

Nesta atividade é disponibilizada uma nova release do produto para o cliente. Tipicamente

esta versão é alvo de testes de aceitação por parte do cliente, de onde podem resultar novos

defeitos ou melhorias que deverão ser introduzidas devidamente no issue tracker. Normalmente o

cliente fica responsável por delinear um plano de testes e, caso assim o deseje, a Present

Technologies pode disponibilizar a especificação dos casos de teste utilizada na fase de validação.

A responsabilidade destes testes é do cliente, sendo o mesmo responsável por reportar os erros à

equipa de desenvolvimento da Present Technologies. Desta ação, poderão resultar dois tipos de

diligências: análise e correção dos defeitos identificados ou implementação de Change Requests.

Numa fase posterior, o termo de aceitação é oficializado por parte do cliente e é agendada a

reunião de fecho do projeto onde serão discutidos e analisados os seus resultados. A presente

atividade termina com o preenchimento de um questionário de satisfação pelo cliente, tendo como

base o processo de análise de satisfação interno da empresa.


12

6) Fase de garantia

No processo de desenvolvimento encontra-se previsto um período de garantia, onde são

analisados eventuais defeitos reportados pelo cliente seguindo o fluxo descrito na fase de

aceitação.

7) Fase de suporte e manutenção

Atendendo ao tipo de contrato efetuado para o projeto, o período de suporte e manutenção

que pode ser ativado com um pedido formal por parte do cliente. Nesta atividade, similarmente às

anteriores, são disponibilizadas correções ou novas funcionalidades ao cliente.

8) Disseminação de resultados do projeto R&DI

Tal como o nome indica, trata-se de uma atividade específica para projeto R&DI, onde é

realizada a análise de resultados obtidos contra os objetivos definidos no início do projeto e

avaliada a ideia o que gerou o projeto, bem como as lições aprendidas.

2.2. Resultado de projetos antecedentes Nesta secção são analisados resultados de projetos finalizados antes do estágio para

conhecer melhor o efeito prático da aplicação do processo informal de testes que vigorava na

empresa.

Foram analisados dois projetos Java Enterprise Edition, adiante designados de A e B,

devido ao abrigo da confidencialidade inerente nos contratos oficializados com os clientes. As

métricas de avaliação averiguadas foram o número de bugs por funcionalidade e a percentagem de

tempo total do projeto dedicada à correção de erros (planned versus actual effort). As métricas

selecionadas providenciam a rápida e resumida informação sobre os incidentes/anomalias

ocorridos e como o projeto foi influenciado pelo custo inerente à correção destes problemas.

2.2.1. Projeto A A primeira aplicação foi construída especificamente para dispositivos móveis, tendo como

objetivo facilitar a utilização de uma bolsa online para os seus clientes. A Present Technologies foi

parte integrante em todas as fases do ciclo de desenvolvimento, tendo sido responsável pela

implementação do front-end e camada de Enterprise JavaBeans (EJB) para recolha e preparação

dos dados recebidos através de WebServices. Durante a fase de implementação e engenharia foram

executados testes unitários e testes de validação manuais. A Tabela 2 apresenta uma visão geral da

estrutura do plano e dos recursos alocados em cada uma das fases, assim como a quantidade de

defeitos detetados e o cálculo das métricas referidas.


13

Tabela 2 - Resultados do projeto A

Analisando a Tabela 2 é possível destacar que foram identificados 3,86 erros por

funcionalidade implementada e que o tempo total necessário para correção dos defeitos superou

em 5,81% o tempo inicialmente previsto na elaboração do plano do projeto. Para o cálculo destes

valores não foi considerada a fase de aceitação devido ao acentuado desvio em relação à

estimativa inicial, provocado pelos procedimentos de aceitação do cliente. As equações (1) e (2)

ilustram as expressões utilizadas para o cálculo dos valores apresentados.

𝐵𝑢𝑔𝑠 𝑝𝑜𝑟 𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒 =247 𝑏𝑢𝑔𝑠

64 𝑓𝑝′𝑠= 𝟑, 𝟖𝟔, (1)

% 𝑇𝑒𝑚𝑝𝑜 𝑟𝑒𝑎𝑙 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 − % 𝑇𝑒𝑚𝑝𝑜 𝑝𝑙𝑎𝑛𝑒𝑎𝑑𝑜 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 = 20,28% − 14,47% = 𝟓, 𝟖𝟏% (2)

2.2.2. Projeto B O Projeto B é uma aplicação web escalável e de alto desempenho que providencia as

funcionalidades necessárias para automatizar o processo de venda de vouchers. No âmbito deste

projeto, a Present Technologies foi responsável por todas as fases do ciclo de desenvolvimento,

excluindo as fases de validação e aceitação. Além dos testes unitários, foram implementados

testes de integração para validação da comunicação com interfaces de sistemas externos.


14

Tabela 3 - Resultados do Projeto B

A Tabela 3 mostra que a média aritmética dos erros detetados por funcionalidade é inferior

a um (0,29). Como os valores referentes à fase de aceitação não foram disponibilizados pelo

cliente, utilizando as medidas da fase de validação como amostra, o tempo dedicado a correções

foi prolongado em apenas 2,17%. Os valores foram calculados conforme as expressões (3) e (4).

𝐵𝑢𝑔𝑠 𝑝𝑜𝑟 𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒 =26 𝑏𝑢𝑔𝑠

93 𝑓𝑝′𝑠= 𝟎, 𝟐𝟗, (3)

% 𝑇𝑒𝑚𝑝𝑜 𝑟𝑒𝑎𝑙 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 − % 𝑇𝑒𝑚𝑝𝑜 𝑝𝑙𝑎𝑛𝑒𝑎𝑑𝑜 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 = 14,13% − 11,96% = 𝟐, 𝟏𝟕% (4)

Com base nos dados apresentados neste estudo, pode dizer-se que a aplicação do anterior

processo de testes informal não resultava em percalços significativos no que diz respeito à

qualidade observada nos artefactos produzidos. Os atrasos que maioritariamente se verificam nos

projetos são normalmente provocados por fatores externos e aos quais a Present Technologies é

completamente alheia. Torna-se assim essencial garantir a continuidade das tarefas de teste já

executadas na empresa, integrando novas tecnologias resultantes deste estágio de modo a, pelo

menos, manter o mesmo nível de qualidade.


15

2.3. Análise Informal Durante o tempo de atividade do estagiário na organização foi possível constatar que

geralmente a empresa disponibiliza os seus produtos e serviços dentro dos prazos estabelecidos.

Os dados revelados na análise de projetos na secção 2.2 conferem que a Present Technologies

apresenta um modelo de negócio sustentável, reforçado pela satisfação demonstrada pelos clientes

que acabam por regressar em futuros projetos.

A perceção dos seguintes aspetos foi extraída em reuniões do estágio e inferência dos

projetos que o estagiário tomou parte, bem como em conversa com colegas envolvidos noutros

projetos.

No âmbito deste trabalho é utilizada a definição defeito-erro-falha, tradução livre de fault-

error-failure para descrever os tipos de problemas existentes em software tal como consta em

[15]. O defeito refere-se à causa do erro, o erro a um estado erróneo interno do sistema e por fim,

falha significa a demonstração exterior do erro através do comportamento não conforme com o

que foi especificado ou é esperado.

2.3.1. Ausência de uma política comum de testes Antes da realização do estágio, a empresa não dispunha de uma política comum que

clarificasse a visão sobre objetivos e princípios de teste aos colaboradores, que pudesse depois ser

expandida por cada estratégia de teste adotada num determinado projeto. Este facto

impossibilitava uma estimativa de esforço e avaliação de resultados dos testes eficaz.

Encontrava-se previsto no documento Test Case Specification Template uma secção

referente ao plano de testes, no entanto não continha as orientações a tomar.

2.3.2. Smoke tests Relativamente a projetos de camadas de apresentação web (mobile ou não), após a

atribuição de um dado requisito a um programador, este implementa-o e executa o código para

verificar se o requisito se encontra devidamente implementado. Se for detetado um erro/defeito, o

programador efetua a sua correção e volta a executar o código novamente. Este processo

denominado de smoke tests continua até que todas as funcionalidades se encontrem

implementadas e não existam aparentes erros catastróficos.

Antes da disponibilização do software ao cliente, que geralmente é responsável pela

realização de testes mais rigorosos, são efetuados testes de validação manuais procurando passar

em revista o maior número de features implementadas, não descurando aspetos importantes como


16

o de segurança. Estes testes não são executados seguindo um processo formal. Na Figura 4 é

ilustrado o processo de teste atual através de um diagrama de atividade UML.

Figura 4 - Diagrama de atividade do processo de teste atual para aplicações web

2.3.3. Testes no cliente Normalmente o que se verifica é que o cliente fica com o ónus de realizar os testes de

validação de sistema, uma vez que é o detentor do ambiente de testes e habitualmente é um

parceiro tecnológico e de negócio e não o consumidor final. Dado que o processo de testes

anterior não se encontrava formalizado, não estavam definidos os níveis e tarefas de teste, sendo

por vezes adotadas medidas ad-hoc em projetos onde são solicitados comprovativos de qualidade

de software.

2.3.4. Formação e suporte documental Um dos problemas identificados é a inexistência de um plano que conduza à formação

interna ou externa dos colaboradores na área de testes de software ou na utilização das

ferramentas de teste adotadas. Como consequência da ausência de suporte documental para os

resultados dos testes informais, o processo atual não pode ser mensurado ou monitorizado como

seria aconselhável.

2.3.5. Testes automatizados Um aspeto positivo observado prende-se com a implementação de testes automatizados em

projetos Java, onde a Present Technologies é responsável pelo desenvolvimento da camada de

lógica de negócio ou quando existe integração com módulos ou subsistemas externos. São

utilizadas ferramentas de teste xUnit5 e in-container, isto é, com a aplicação sob teste em

5 http://en.wikipedia.org/wiki/XUnit


17

execução num container Java EE. Nos projetos referidos são concebidos testes de integração,

procurando tipicamente testar funcionalidades de interoperabilidade entre a camada de serviços e

a camada de acesso a dados. Normalmente são utilizadas técnicas informais de testes, que têm

como base as exceções que podem ser geradas nas operações invocadas aos serviços.

2.3.6. Testes estáticos e registo de defeitos Outro dos pontos positivos verificado prende-se com a análise estática do código, liderada

pelo departamento de qualidade através de revisões de código regulares, essencialmente em

projetos com forte preocupação a nível de desempenho.

Noutros projetos foi ainda utilizado o Google Docs6 para registo do resultado de testes

manuais, seguindo uma estrutura ad-hoc. Tipicamente os erros/defeitos capturados são

apropriadamente monitorizados, geridos e ordenados num issue tracker.

2.3.7. Ensaio com Test-Driven Development Tendo consciência das potencialidades da técnica TDD (Test-Driven Development),

constituinte da metodologia eXtreme Programming, foi realizada uma tentativa de aplicação, com

a qual foi possível apurar que esta abordagem não se adequa ao desenvolvimento efetuado na

empresa. A tentativa foi rapidamente abandonada devido ao fator de imprevisibilidade, que

provocava danos de produtividade bastante acentuados. Devido ao modo como o TDD se

processa, facilmente são criados muitos scripts de teste que tendem a ficar desatualizados e o

custo da sua manutenção pode ser desajustado relativamente aos prazos do projeto. Aliado a este

fator, por vezes a possibilidade de múltipla execução dos testes não é relevante em determinados

projetos.

6 https://docs.google.com

CAPÍTULO 3

18

3. METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE Esta secção fornece um background tecnológico e das metodologias referentes à área em

que o projeto esteve inserido, o que ajuda a entender as opções tomadas durante a conceção do

manual Software Testing Guide (Anexo A) e do documento Test Plan Template (Anexo B) no

capítulo 4.

Este capítulo é constituído por três subsecções: Processo de testes; Testes de interface web

e Ferramentas de automatização de testes. Na primeira é efetuada uma introdução ao que

representa um processo de testes de software, descrevendo os modelos e metodologias de suporte.

Seguidamente foram analisadas as recomendações de melhorias a implementar na elaboração do

template do plano de teste.

Ao longo da segunda subsecção, é feito um estudo sobre o paradigma de testes de interface

web, perspetivando a sua abrangência e soluções para superar os desafios atualmente impostos.

Por fim, na última subsecção é efetuada a análise das tecnologias relacionadas com os

testes web, como por exemplo o Selenium7 e o Arquillian8.

3.1. Processos de testes A doutrina de testes de software deve ser vista especialmente como uma forma de controlo

de qualidade. Trata-se de um instrumento que contribui com informação precisa, através da

interpretação dos resultados de testes, da qualidade de um sistema de informação. O processo de

teste deve providenciar uma evidência objetiva, de que o sistema e produtos associados satisfazem

inteiramente os requisitos respeitando as regras de negócio e regulamentos restritivos.

3.1.1. Contextualização de processos de testes As definições do conceito de testes de software compreendidas nas normas IEEE 610.12

Standard Glossary of Software Engineering Terminology ([27]) e Standard glossary of terms used

in Software Testing ([28]), convergem para a definição de um processo que consiste num conjunto

de atividades, estáticas e dinâmicas, atendendo ao planeamento, preparação e avaliação dos

produtos de software para determinar se satisfazem os requisitos especificados.

Similarmente ao processo de desenvolvimento de software, o processo de testes possibilita

às organizações uma maior estruturação e eficiência do trabalho desenvolvido. Uma metodologia

ou estrutura de testes de software tem a finalidade de formalizar as fases, atividades, funções,

7 http://seleniumhq.org/ 8 http://arquillian.org/

METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE

19

artefactos e responsabilidades necessárias para o planeamento e execução sistemática de testes. O

principal objetivo deste processo é expor o número máximo de falhas, dispondo de um esforço

ponderado e adequado, para determinar se um produto cumpre as especificações no ambiente para

o qual foi desenhado.

A razão pela qual o planeamento e controlo se devem iniciar simultaneamente com o

projeto é justificada pelos dados sobre quais as fases onde são originados mais defeitos, e as fases

que registam mais despesas na correção dos defeitos encontrados. Segundo o estudo presente em

[21], 85% dos defeitos são introduzidos logo nas fases iniciais do projeto, mais

pormenorizadamente na documentação de requisitos, arquitetura e desenho de interfaces do

sistema. Os dados apontam também no sentido de que a retificação dos defeitos é representada

por uma expressão logarítmica, onde por cada fase de desenvolvimento executada sem a devida

correção, o custo torna-se dez vezes superior. Como exemplo, uma falha detetada na fase de

especificação pode não ter um custo significativo. No entanto, o custo de correção da mesma,

quando detetada durante as fases de implementação e validação, oscila entre 10€ a 100€. Em

último caso, se for apenas revelada durante a fase de produção, a sua reparação pode ascender os

1000€ (hipoteticamente) [22].

Figura 5 – Envolvente económica de testes de software (baseado em [33])

Os dados extraídos na Figura 5 mostram que a qualidade é um atributo do software que

deve ser introduzido ao longo do processo de desenvolvimento, contrariando o entendimento

infundado de que os testes são uma fase secundária normalmente executada no final do projeto.

Para que se verifique a maior frequência de entrega de projetos dentro do orçamento e do

prazo estipulados, apresentando a qualidade e âmbito pretendidos, a norma disposta em [30]

aponta as seguintes atividades como sendo as essenciais para um processo genérico de testes:

Planeamento e controlo; Análise e desenho; Implementação e execução; Registo dos resultados dos testes; Verificação de completude.


20

Planeamento e controlo

Na atividade de planeamento é iniciada a elaboração do plano de teste que visa identificar o

âmbito, abordagens, riscos e recursos envolvidos nas atividades de testes. Uma vez que um dos

objetivos do estágio é a elaboração do template para o plano de testes, este documento é descrito

mais detalhadamente na secção 3.1.5. Depois de definido o plano de testes dá-se início ao

controlo projeto, comparando periodicamente o progresso atual contra o planeado. Este exercício

deve ser contínuo e dar resposta a mudanças de objetivos, estratégias de teste e/ou alterações do

projeto.

Análise e desenho

A análise, inicialmente consiste na revisão de documentos que servem de base para os

testes. Após este passo é necessário proceder à identificação dos tipos de teste para garantir a

cobertura dos componentes do sistema a testar, previamente acordados na iniciação do plano de

testes.

Numa fase posterior desta atividade, são empregues técnicas de desenho de testes definidas

na atividade de planeamento. Os casos de teste têm origem na especificação de requisitos e na

experiência retida em anteriores projetos pelos membros de equipa envolvidos. Esta atividade

incorpora as tarefas de verificação e validação (V&V), suportadas por técnicas de análise estática

e dinâmica.

Na verificação é avaliado se os componentes de software estão a ser desenvolvidos

conforme os padrões e metodologia estabelecida para o projeto (“Estamos a construir o produto

corretamente?”)[11]. Esta vertente estática implica revisões e inspeções sobre os artefactos

produzidos, não necessitando para isso da execução da aplicação. Para Java, o FindBugs9 e

Checkstyle10 são exemplo de ferramentas que analisam estaticamente o código (utilizadas em

projetos na Present Technologies).

Por outro lado, a validação recorre a técnicas para verificar a conformidade do software

implementado relativamente ao comportamento descrito nos requisitos. Envolve uma análise

dinâmica, ou seja, o código da aplicação é executado durante os testes (“Estamos a construir o

produto correto?”)[11]. Estes podem ser segmentados em testes funcionais e não funcionais. No

diagrama da Figura 6 é ilustrada a hierarquia dos conceitos apresentados nesta atividade.

9 http://findbugs.sourceforge.net/ 10 http://checkstyle.sourceforge.net/


21

Figura 6 Testes estáticos e dinâmicos

Implementação e execução

Tendo como base os casos de testes escolhidos na atividade anterior, é implementado o

código de teste de modo a executar o sistema sob teste. A execução destes testes é iniciada assim

que for disponibilizado o componente para testar e as pré-condições dos testes se encontrarem

satisfeitas. Os scripts de teste são normalmente priorizados e executados em múltiplos ciclos até

que sejam atingidos os critérios de cobertura definidos no plano. Os critérios de cobertura são

formados por um conjunto de regras que ajudam a determinar se um conjunto de testes testou

adequadamente um programa, orientando assim o processo de testes.

Quando nos testes são identificadas discrepâncias entre os resultados esperados e os

resultados reais, estas diferenças são registadas como defeitos, sendo de seguida analisadas e

corrigidas. Após a correção de um problema, é verificada se a mesma foi eficiente. Isto pode

significar uma nova execução dos testes para garantir que as correções realizadas eliminaram de

facto o problema.

Registo dos resultados dos testes

Na execução dos testes deve ser mantido um registo dos problemas identificados e

correções desenvolvidas. A avaliação do resultado da execução dos testes é considerada uma

atividade de gestão. Este registo divide-se em dois passos: primeiro é necessário colecionar

informação se o caso de teste passou ou falhou; depois é contabilizado o tempo gasto em testes

durante o projeto, calculando o desvio em relação ao tempo planeado. Para a tomada de decisão

são fornecidas métricas, tais como o número de testes que passaram e falharam, número total de

defeitos e custo adicional de esforço sobre o planeado resultante das correções.

Verificação de completude

Caso os critérios de cobertura especificados não se encontrem cumpridos, as atividades de

testes anteriores são novamente executadas. Por fim, as lições apreendidas durante o projeto são

registadas para a posterioridade e são identificadas oportunidades de melhoria no processo.


22

3.1.2. Otimização do processo de teste Algumas organizações anteveem o processo de testes como uma prática que ocupa

demasiado tempo, apresentando um custo superior ao planeado e que não fornece informação

suficiente sobre a qualidade do produto realizado [15].

Estes problemas são resolvidos com a melhoria e otimização do processo, contudo é difícil

definir quais e a ordem dos passos que devem ser realizados para melhorar e controlar o processo.

Para este fim, foram desenvolvidas várias iniciativas de modelos de otimização, como são o caso

de TMap [2], TPI [3], e TMMi [4]. De seguida é realizada uma descrição sintetizada, de forma a

dar a conhecer cada um destes modelos. O detalhe mais pormenorizado deste estudo pode ser

consultado no Anexo F.

TMap

O TMap11 é uma abordagem de gestão para a estrutura de testes em sistemas de

informação, desenvolvida pela Sogeti da Holanda. A definição do modelo é constituída por quatro

pontos fundamentais:

a) Base numa abordagem BDTM (Business Driven Test Management); b) Descreve um processo estruturado; c) Contém uma solução para testes completa; d) Método de testes adaptativo.

A caraterística principal deste modelo é a que diz respeito à orientação ao negócio das

tecnologias de informação. As decisões sobre quais os resultados de testes, tempo e orçamento

pretendidos, têm fundamento nos padrões racionais e económicos atuais e nos recursos

disponíveis (a). O modelo consiste ainda numa abordagem de teste estruturada e infraestrutural,

permitindo a contínua perceção do estado do sistema e riscos envolvido de uma maneira

controlada (b). O TMap fornece ainda, a informação sobre como se deve aplicar em forma de

exemplos, checklists, descrições técnicas, procedimentos, estruturas organizacionais e

ambientes/ferramentas de teste [2] (c). Adicionalmente, o TMap possui uma organização flexível

possibilitando a sua integração em projetos para novos sistemas, de suporte/manutenção ou para

utilização interna na empresa (in-house) (d).

O TMap apresenta uma abordagem bem definida baseada nos atributos de qualidade e na

análise de riscos. Utiliza uma estratégia centrada no que realmente é importante nos testes de

software. Tem como contrapartida, o facto da sua utilização numa pequena ou média empresa,

11 http://www.tmap.net/en


23

resultar numa solução demasiado dispendiosa. A curta duração dos projetos impossibilita a

utilização de todos os aspetos do modelo TMap [5].

Na opinião do estagiário a utilização completa do método formal TMap é extensa para

projetos de pequena dimensão ou com poucos riscos, como a maioria dos projetos verificados na

empresa. Porém não deve ser desconsiderado o conjunto de técnicas formais que permitem atingir

um certo grau de segurança na cobertura dos testes [5].

TPI

O modelo Test Process Improvement (TPI) foi desenvolvido com base no conhecimento e

experiências práticas adquiridas na implementação de processos de testes. A utilização do modelo

providencia os meios para determinar os pontos fortes e fracos de um processo atual, tendo em

vista a sua reformulação através de ações realistas e específicas.

Do ponto de vista geral, as principais considerações a ter no aperfeiçoamento do processo

devem ser, a deteção de defeitos (mais proximamente possível da sua fonte para minimizar os

custos de reparação) e disponibilizar informação sobre a qualidade do sistema o mais rapidamente

possível. Toda a avaliação e níveis de teste devem ser ajustados cuidadosamente, de modo a

fornecer uma estratégia ótima para que sejam identificados os erros mais importantes. O

progresso de todo o processo deve ser mensurado para permitir a melhoria contínua do mesmo.

O modelo TPI é segmentado em quatro perspetivas (cornerstones): o ciclo de vida (L);

organização (O); infraestrutura/ferramentas (I) e técnicas (T). Os diferentes aspetos das dimensões

dão origem às designadas Key areas, que correspondem a diferentes categorias do modelo de

otimização do processo de testes ([3]). Por exemplo, a utilização de ferramentas de teste, técnicas

de especificação de testes e relatório dos resultados. Cada Key area pode ser classificada em

níveis de maturidade e podem não ter o mesmo grau de importância para o desempenho do

processo. As dependências existentes entre as key areas e os níveis de maturidade A, B, C e D são

delineados na Test Maturity Matrix. Um procedimento é classificado num determinado nível, caso

preencha todos os requisitos desse nível (checkpoints). Um checkpoint deve ser visto como um

requisito.

Este modelo prepara a melhoria e otimização do processo de testes, com base na análise da

situação atual e nas propriedades a melhorar, determinando um conjunto de ações necessárias. Na

perspetiva do estagiário, devido às suas caraterísticas, o TPI podia se aplicado à Present

Technologies, no entanto, a determinação do nível de qualidade é ponderada pela avaliação

humana do processo o que pode incorrer de alguma subjetividade.


24

TMMi

Este modelo foi desenvolvido pela fundação TMMi sediada na República da Irlanda. Sem

fins lucrativos, a fundação, proporciona uma orientação e referência para otimização do processo

de testes e ajusta-se como modelo complementar do Capability Maturity Model Integration12

(CMMI) [4].

Tal como o CMMI, o modelo contém 5 etapas ou níveis, através dos quais é possível a uma

determinada organização evoluir o seu processo de testes improvisado e de difícil gestão para uma

versão controlada, definida, mensurada e otimizada.

A estrutura interna do TMMi detém um conjunto rico de práticas de teste que podem ser

aplicadas, de uma maneira sistemática, para suporte à melhoria gradual do processo. A

organização precisa de focar-se num conjunto de áreas processuais para obter um determinado

nível de maturidade. Devem ser questionadas quais as áreas do processo que mais beneficiam a

empresa mediante o contexto do seu ambiente de negócio. Os diferentes patamares de

consolidação da framework são descritos na Tabela 4.

Tabela 4 - Descrição dos níveis de maturidade TMMi

Níveis Descrição

Nível 1 - Inicial As organizações do nível 1 tendem a não cumprir os prazos estabelecidos, abandonar os processos em alturas de crise e demonstram incapacidade para repetir o sucesso comprometendo a qualidade dos produtos realizados.

Nível 2 - Controlado

O principal objetivo das organizações no nível 2 TMMi é a verificação de que o produto satisfaz os requisitos especificados e claramente faça a distinção teste e debug. Ao contrário do primeiro nível, os testes de software tornam-se num processo controlado que inclui o estabelecimento de uma estratégia base de testes.

Nível 3 - Definido

Neste nível, os testes deixam de ser percecionados como uma fase que sucede à fase de implementação, e passam a ser integrados totalmente no ciclo de desenvolvimento. O processo de teste formal é estabelecido e a sua otimização é completamente institucionalizada na organização.

Nível 4 – Gestão e Medição

Processo definido, bem fundamentado e mensurado, onde são definidos critérios de gestão de qualidade dos produtos e de desempenho do próprio processo. Métricas de testes são incorporadas para suporte de tomada de decisões baseada em factos.

Nível 5 – Otimização

O nível de topo deste modelo tem como objetivo a prevenção de defeitos, tendo como base todos os resultados alcançados pelas melhorias estabelecidas nos anteriores níveis de maturidade. Neste momento o processo de testes apresenta a capacidade de controlar custos e elevada eficiência nos testes. A melhoria contínua do processo fica a cargo dos procedimentos incrementais e melhorias tecnológicas.

12 http://www.sei.cmu.edu/cmmi/


25

De acordo com um estudo protagonizado pela Forrester Consulting solicitado pela

Accenture, foi possível ter a perceção de que 37% dos 201 gestores de empresas de tecnologias de

informação inquiridos, atribuíram o nível de maturidade 3 (Definido) ao processo de testes em

vigor em cada uma das suas organizações [7].

Figura 7 - Inquérito Forrester Consulting [7]

O gráfico apresentado na Figura 7 deixa antever opiniões otimistas, 43% atribuíram os

níveis 4 e 5, enquanto apenas 4% ficaram-se pelo nível 1. Estes resultados podem advir do facto

que mais de 80% dos inquiridos poderão ter respondido de modo tendencioso e sobrestimado.

Outra causa possível, pode consistir na errada interpretação dos níveis de maturidade pelos

entrevistados. Este exemplo mostra que as organizações estão interessadas em publicitar as suas

capacidades relacionadas com testes (mesmo que não corresponda à realidade) e muitas debatem-

se com a definição da sua atual situação [7].

3.1.3. Modelo em V No modelo em V, os processos de testes e de desenvolvimento estão interrelacionados,

sendo que um é responsável pela entrega dos produtos avaliados e testados pelo outro. Durante o

estudo da literatura, foi possível observar que as etapas do modelo são diferentes consoante a

organização que o adota. Isto deve-se ao facto de o modelo em V não se tratar de uma norma, mas

sim, de um princípio que pode ser ajustável mediante as necessidades.

Do lado esquerdo do modelo em V da Figura 8, são mostradas as fases em que o sistema é

construído ou convertido para solucionar um problema. Estas fases contemplam a definição de

requisitos, especificação funcional técnica e a implementação do sistema. São influenciadas pela

metodologia de desenvolvimento selecionada para o projeto.

As fases relacionadas com os testes encontram-se no lado direito do modelo em V,

conforme se pode verificar no diagrama apresentado na Figura 8. As fases vão desde os testes

executados pelos programadores no momento de implementação, até aos testes realizados pelo

fornecedor, cliente ou entidade externa que cobrem todo sistema. Estas fases representam,

implicitamente, os níveis de testes dinâmicos. Um nível de teste é um grupo de atividades de

teste, que tem como função verificar a informação de um conjunto de aspetos correlacionados do


26

sistema. No propósito deste trabalho foram escolhidos os níveis seguintes, como os mais

adequados, apesar de algumas fontes de informação consultadas apresentarem categorias

diferentes.

Testes unitários: Com base na implementação do código, o objetivo passa por

testar os componentes independentemente de outros, procurando certificar o seu correto

funcionamento. Por causa das diferenças entre linguagens de programação, não existe

consenso sobre o que a unidade representa. Neste nível é vantajoso o conhecimento que

o programador detém do código para a criação dos testes. Esta técnica é conhecida como

white-box testing.

Testes de integração: Com base na implementação do desenho e arquitetura da

solução, um conjunto de componentes é testado como grupo e são pesquisadas falhas

resultantes das interações entre os componentes.

Testes de sistema: Com base nos requisitos do sistema de informação, o objetivo

prende-se com a procura de defeitos nas funcionalidades do sistema. O objeto de teste é

o sistema completamente integrado. Estes tipos de teste devem levar em conta os

requisitos funcionais e não funcionais.

Testes de aceitação: Com base nos requisitos de utilizador, estes testes são

normalmente realizados pelo cliente que contratou uma empresa para o

desenvolvimento do produto. Por vezes, o projeto só é totalmente pago quando é aceite

a qualidade demonstrada pelo software nestes testes [18].

Através da inclusão das atividades de testes no modelo em V, exibido na Figura 8, é

possível delinear um processo de testes que se coadune com qualquer ciclo de desenvolvimento,

tradicional ou incremental. Esta solução acomoda-se facilmente e com sucesso a todo tipo de

projeto de software [6].

A realização de testes de software ainda continua a ser o método mais eficaz para detetar e

prevenir defeitos, ganhar confiança ao nível de qualidade dos produtos e minimizar custos de

desenvolvimento (quanto mais tarde forem detetados defeitos, maiores serão os custos). Os testes

funcionam como catalisador da tomada de consciência do grau de maturidade de um projeto

através de métricas.


27

Figura 8 - Modelo em V [5]

3.1.4. Metodologias de teste Tendo em vista, a implementação de testes, encontram-se disponíveis diferentes

metodologias. Na presente secção a sua descrição, bem como as suas principais vantagens e

desvantagens, são apresentadas.

Test-After Development (TAD)

Nesta primeira metodologia, a elaboração dos testes ocorre numa fase posterior ao

desenvolvimento do produto. Antes do aumento da adoção de metodologias de desenvolvimento

ágeis, que se tem vindo a registar, seguramente este foi o método mais utilizado. Destaca-se pelas

seguintes caraterísticas [8]:

Permite realizar otimização do código desenvolvido antes dos testes;

Habitualmente é atingido um nível de cobertura de 75% do código;

Não influencia diretamente o desenho da aplicação;

Pode ser considerada como uma tarefa completamente independente da implementação.

Resultante da aplicação deste estilo de desenvolvimento, podem-se registar alguns

inconvenientes. Uma vez que os testes não são tidos em conta no momento do desenho da

arquitetura da solução, o sistema pode revelar-se rígido e adverso a alterações. Estas propriedades

podem ainda implicar a escrita de mais código do que o necessário para a aplicação quando são

detetados erros ou falhas. Como se trata de uma fase póstuma da finalização do produto,

normalmente a criação dos testes é prescindida em favorecimento do cumprimento de prazos

estabelecidos para entrega do produto. A Figura 9 apresenta a sequência de tarefas associada ao

método de desenvolvimento TAD.


28

Figura 9 - Método de desenvolvimento TAD

Test-Driven Development (TDD)

O método de desenvolvimento TDD surgiu no âmbito da metodologia de desenvolvimento

eXtreme Programming13 (XP), popularizado por Kent Beck em 1999. Trata-se de uma abordagem

iterativa e incremental de desenvolvimento, desenhada para produção rápida e ágil de software. É

principalmente conhecido por expressar os requisitos em cenários de utilização do sistema (user

stories), que são traduzidos diretamente numa série de tarefas. Todos os testes têm de ser

executados com sucesso, quando novo código é integrado no sistema [17].

No TDD os testes são implementados pelo programador antes do código a ser testado.

Inicialmente é escrito o teste para falhar, só depois é escrito o código que permite que a aplicação

passe no teste. Após cada teste, é otimizado o código referente ao teste e à aplicação. Por fim é

novamente executado o teste de modo a assegurar que a melhoria implementada não provocou

nenhum erro no comportamento do sistema. Contrapondo a Figura 9, na Figura 10 é ilustrada a

sequência de tarefas prevista na metodologia TDD.

Figura 10 - Método de desenvolvimento TDD

A aplicação destes procedimentos introduz algumas vantagens, nomeadamente [8]: Permite a otimização continuada durante o desenvolvimento do código;

Contribui para a fase de desenho e arquitetura do sistema;

Funciona como parte integrante da fase de implementação;

A percentagem de cobertura possível de atingir aproxima-se de 100%.

Apesar da crescente adoção do método TDD, até ao momento, não foi possível apurar

factos que evidenciem a sua maior eficiência em relação às restantes metodologias [31]. A

presente metodologia acaba por não ser recomendada para projetos que não se destinem a nenhum

cliente ou que o cliente é reconhecido pela qualidade de realização de testes de software. Também

nos projetos pequenos, simples e diretos, a aplicação desta metodologia pode não constituir

nenhuma vantagem acima descrita.

Apesar das metodologias de desenvolvimento apresentadas normalmente se encontrarem

associados a testes unitários, a verdade é que podem ser aplicados a testes de diferente 13 http://www.extremeprogramming.org/


29

granularidade. O método TDD contém uma variante denominada de Acceptance test-driven

development (ATDD) que procura auxiliar os programadores a construir software de alta

qualidade, que responda às reais necessidades de negócio de alto nível, tal como o tradicional

TDD faz para assegurar a qualidade técnica mais baixo nível do software. Este assunto serve de

mote para a próxima metodologia.

Behavior-Driven Development (BDD)

A partir das linhas orientadoras da metodologia TDD surgiu o Behavior-driven

development, técnica concebida por Dan North [32]. Os casos de teste desenvolvidos por este

método normalmente enquadram-se no nível de testes de sistema ou de aceitação. Esta

metodologia tem como principal caraterística a utilização da linguagem natural para detalhe do

comportamento que o sistema deve assumir nos casos de teste. Permite o desenvolvimento de um

vocabulário consistente para analistas, testers, programadores e gestores, eliminando assim a

ambiguidades e falhas de comunicação, que normalmente ocorrem entre os intervenientes da parte

técnica e de gestão do projeto. Deste modo, o valor de negócio da solução é explícito nos testes,

habitualmente especificados na seguinte forma:

Given some initial context (pré-condições),

When an event occurs (execução do teste de software),

Then ensure some outcomes (resultado).

Além das premissas fundamentais Given-When-Then para descrever um caso de teste,

encontra-se previsto o operador and responsável por interligar múltiplas pré-condições (givens)

e/ou múltiplos resultados (then). A Listagem 1 ilustra a especificação de um caso de teste BDD.

Listagem 1 - Caso de teste BDD [32]

BDD Scenario 1: Account is in credit

Given the account is in credit

And the card is valid

And the dispenser contains cash

When the customer requests cash

Then ensure the account is debited

And ensure cash is dispensed

And ensure the card is returned

A especificação dos cenários BDD prevê a reutilização de pré-condições, eventos e

resultados por forma a evitar a duplicação de código de teste. Normalmente as várias ferramentas

de teste baseadas em BDD convertem os vários passos especificados em instruções de código,

criando assim um teste automatizado. O recurso a este método é especialmente útil na medida em


30

que possibilita aos programadores uma melhor compreensão das expectativas do utilizador,

focando-se no propósito da solução e abstraindo-se do detalhe técnico.

3.1.5. Plano de testes Na literatura investigada foram encontradas várias designações para representar o mesmo

documento, alguns exemplos disso são Master Test Plan, Comprehensive Test Plan e High-level

Test Plan. Para o assunto apresentado neste trabalho, o documento de testes geral será

simplesmente referido como plano de testes.

Um plano de testes pode ser genericamente definido como um documento que providencia

uma base comum ou abordagem, para atingir um determinado conjunto de objetivos. É uma

prática essencial para uma organização que pretenda desenvolver um processo de testes

controlado e que possa ser reutilizado [18].

Normalmente é despendido um terço do esforço total alocado a testes de software para a

sua conceção, sendo por vezes considerado como um memorial de entendimento entre os testers e

programadores envolvidos no projeto. A realidade é que, se o planeamento de testes não é

prontamente iniciado quando os requisitos são formados, nunca se saberá a razão pela qual se está

a testar.

A seguir é apresentada uma receita para a construção do plano de testes com base em seis

tarefas, tendo como entradas o plano do projeto e suas constantes atualizações [20]. Para esta

fórmula funcionar, o plano do projeto deve conter a totalidade das atividades para a

implementação, controlo e teste do produto. De seguida cada uma das tarefas é sucintamente

descrita.

Tarefa 1 – Identificar o tipo de projeto de Software

O planeamento eficiente de testes requer a compreensão dos atributos do projeto de

software a testar. Deve ser conduzida uma revisão sobre os requisitos, focada nas áreas de

cliente/utilizador. O projeto em curso deve ser categorizado tendo como referência os tipos

incluídos na secção 2.1.

Tarefa 2 - Compreender os riscos do projeto

De modo a assegurar os objetivos identificados, é efetuada uma avaliação dos riscos e

preocupações associadas ao projeto. Nesta tarefa são analisados diferentes aspetos do projeto,

como por exemplo:

Os requisitos são atualizados e mantidos durante a atualização das aplicações; A aplicação implementa as regras de autorização recomendadas; A integridade dos ficheiros durante a fase de manutenção;


31

Testes de desempenho são conduzidos para que o sistema consiga obter o nível de serviço quando são processados volumes de dados normais e superior ao normal.

Tarefa 3 - Selecionar técnicas de teste

As técnicas de teste devem ser selecionadas com base na sua capacidade para cumprir os

objetivos de teste. A escolha da técnica a aplicar em cada uma das fases do ciclo de vida implica a

definição de testes dinâmicos ou estáticos. O primeiro, ao contrário do segundo, envolve a

execução do software durante o teste.

Tarefa 4 - Planear testes unitários e análise

Nesta tarefa as técnicas para testes unitários são examinadas, avaliadas e geridas. As

estratégias para este tipo de testes podem ser definidas como funcional (testes a funcionalidades),

estruturada (testes não-funcionais) ou orientadas ao erro. Os testes unitários e análise são a prática

mais comum para verificar que um programa possuiu as funcionalidades definidas na

especificação. Apesar do conceito da unidade ser ambígua, a caraterística essencial é que estes

tipos de teste devem prescindir da utilização de outros componentes.

Tarefa 5 - Construir o plano de testes

O desenvolvimento de um plano de testes efetivo prende-se com o estabelecimento dos

objetivos de teste, geração da matriz de testes, administração de testes e criação do documento

referente ao plano de testes. Os objetivos de teste devem reforçar os objetivos do projeto

existentes no plano do projeto. A matriz de testes é um componente chave no plano, deve mapear

as funcionalidades que se encontram a ser testadas com as técnicas selecionadas. O componente

administrativo deve assinalar os prazos e recursos necessários para executar o plano de testes

como ilustrado na matriz de testes. O plano de teste pode resumir-se a um documento informal ou

formal, dependendo da cultura da empresa.

Tarefa 6 - Inspecionar o plano de testes

Depois de averiguada uma possível solução ajustada à conceção do plano de testes, é

imprescindível delinear a estrutura e composição do plano.

Procurando evitar a produção de extensa documentação composta por um conjunto de

dados, sem qualquer significado para a organização, o conteúdo do plano de testes deve transmitir

essencialmente o porquê, como e quando os testes devem ser criados e executados [15]. A

informação constante no plano pode ser estendida descrevendo as tarefas que têm de ser

cumpridas, quem será o responsável por cada uma, quais as ferramentas, procedimentos, técnicas

a utilizar e quanto tempo e esforço deve ser despendido. Sem a definição de um plano de testes é

altamente improvável que o nível de qualidade do software desejado seja atingido dentro do prazo

estipulado e sem aumento de recursos (colaboradores e orçamento).


32

Os documentos referentes ao plano de testes podem ser organizados de variadas maneiras

dependendo da política da organização e devem ser coordenados com o plano do projeto de

software. A norma IEEE Standard for Software and System Test Documentation 829-1983 [29]

recomenda uma lista de componentes que o documento do plano de testes deve abordar.

Os tópicos e uma resumida definição podem ser consultados na Tabela 5. A norma deve ser

utilizada como guia devendo a organização adaptar os documentos de acordo com as suas

necessidades, objetivos e políticas.

Tabela 5 - Componentes do Plano de testes IEEE 629-1983

Componentes do Plano de Testes Definição

Identificador do Plano de testes Cada plano deve conter um identificador único de modo a ser associado a um projeto e fazer parte do seu histórico.

Introdução Nesta secção é descrito o sistema a ser desenvolvido incluindo uma visão de alto-nível dos objetivos e abordagens de testes.

Itens a testar Consiste na lista de entidades do sistema a testar, deve incluir a referência e versão/revisão para cada uma das entidades.

Funcionalidades a testar Nesta secção são definidas as caraterísticas do componente ou sistema a testar.

Abordagem Inclui a descrição das atividades de teste, com um nível de detalhe suficiente para que as tarefas e suas durações possam ser facilmente calculáveis.

Critério Pass/Fail Dado o caso de teste é definido o critério que permite decidir se um determinado teste passou ou falhou durante a sua execução.

Critério de Suspensão e retoma Nesta secção são descritos os critérios para suspender e retomar as atividades inerentes aos testes baseados nos efeitos ou nível de severidade das falhas registadas.

Artefactos de testes Consiste na determinação de quais os artefactos relacionados com testes, devem ser entregues ao cliente do projeto.

Tarefas de testes Neste capítulo são identificados todas as atividades de testes e suas dependências, normalmente sob a forma de Work Breakdown Structure (WBS).

Ambiente de testes Consiste na descrição das necessidades de software e hardware para a execução dos testes.

Responsabilidades Identificação do pessoal responsável pelas tarefas relacionadas com os testes.

Pessoal e necessidades de formação Descrição do pessoal e níveis de competências necessários para exercer as responsabilidades listadas anteriormente.

Agendamento As durações das tarefas de teste são estabelecidas e registadas.

Riscos e contingências Nesta secção são registados todos os riscos envolvidos na realização de testes.

Aprovações O Plano de testes deve ser revisto pelas pessoas designadas pela organização.

Uma vez que que não é possível testar um software até que todos os seus erros sejam

revelados, devem ser definidas condições específicas através da definição de subconjuntos de

testes, para que se considerem como finalizadas as tarefas relativas as testes.


33

Tendo em conta que o plano é uma parte crucial do processo de testes, em [19] é definida

uma lista de componentes alternativa e mais recente que a referenciada pela norma IEEE 629-

1983 ([29]). Esta lista pode ser consultada na Tabela 6.

Tabela 6 - Componentes do Plano de testes essenciais [19]

Componentes do Plano de Testes Definição Objetivos Definição dos objetivos para cada fase de teste.

Critério de completude Designação do critério para especificar quando uma determinada fase de teste é considerada como finalizada.

Agendamento Agendamento para cada fase de testes. Responsabilidades Omisso por ser similar ao componente descrito em IEEE 629-1993.

Casos de teste e normas Métodos sistemáticos para identificar, elaborar e armazenar os casos de teste necessários.

Ferramentas Identificação das ferramentas necessárias para a realização dos testes.

Configuração de hardware Determinação das configurações de hardware ou dispositivos envolvidos nos testes.

Integração Definição de como serão arquitetados os testes, por exemplo top-down incremental.

Procedimentos de rastreabilidade Identificação dos métodos para rastrear o progresso dos testes. Procedimento de registo Descrição dos meios definidos para o registo dos erros encontrados.

Testes de regressão Testes realizados após correção ou desenvolvimento de uma melhoria funcional garantindo o anterior correto funcionamento do sistema.

3.1.6. Sumário de processos de testes Neste capítulo foi feito o levantamento do estado de arte que foi refletido na elaboração dos

documentos Software Testing Guide e Test Plan Template. Em primeiro lugar, foi apresentada uma

visão geral do que é um processo de testes, como pode ser estruturado no modelo em V e

otimizado com base nos modelos TMap, TPI e TMMi. De acordo com as suas propriedades e

tendo em vista o contexto da empresa, o modelo TMMi foi selecionado para orientar o processo

de criação do procedimento de testes. Com a implementação do procedimento de testes concebido

neste estágio deve ser possível alcançar/consolidar o nível de maturidade 2 (Controlado) do

TMMi.

De seguida, numa vertente mais prática, foi apresentado um olhar breve sobre as

metodologias habitualmente utilizadas. Cada uma das metodologias está intrinsecamente ligada a

um tipo de testes diferente, por exemplo, o BDD é mais apropriado para testes de sistema ou de

aceitação, enquanto o TDD é mais aconselhado para testes unitários. O capítulo é concluído com a

investigação da documentação relevante para a organização e composição do documento plano de

testes.


34

3.2. Testes de interface web Nesta secção é disponibilizada uma visão mais específica sobre conceitos e soluções

utilizadas para testes front-end ou de interface de utilizador para aplicações web, incluindo a

envolvente tecnológica.

A imparável evolução das aplicações web dinâmicas alterou a indústria tecnológica para

sempre, e tão rapidamente como são construídas, também necessitam de ser testadas. Todavia a

área de investigação relacionada com o teste de interfaces web modernas não se encontra muito

explorada. A maior parte do conhecimento existente atualmente divide-se em dois tipos de testes:

testes funcionais e testes ao GUI (Grafical User Interface) de aplicações web. A componente de

investigação deste trabalho incide no segundo tipo mencionado, pois é considerada a área de teste

onde atualmente a organização não fornece uma resposta adequada e assertiva.

3.2.1. Aplicações web Aplicação web é um termo para designar sistemas informáticos alocados num servidor web,

desenvolvidos para serem executados num browser utilizando o protocolo Hyper Text Transfer

Protocol (HTTP). As principais vantagens das aplicações web, ao contrário das aplicações

desktop, são a simples atualização e manutenção da aplicação no servidor, impercetíveis aos

utilizadores. Apesar da simplicidade concetual, as aplicações tendem a aumentar a sua

complexidade.

As aplicações são compostas por relativamente pequenos componentes de software

distribuídos, que executam de modo concorrencial com partilha de memória utilizando

tecnologias que se estão constantemente a inovar. O protocolo HTTP é stateless, isto quer dizer

que cada par pedido/resposta entre o cliente e servidor é independente. Para que o estado

aplicacional seja mantido, tem de se recorrer a técnicas como Cookies, objetos de sessão ou base

de dados.

Uma página web pode ser armazenada como um ficheiro HTML estático ou pode ser

dinamicamente gerada por software como por exemplo Java Server Page, Servlet ou Active

Server Page. O conteúdo e estrutura da página dinâmica podem ser influenciados por valores

introduzidos anteriormente pelo utilizador, estado do servidor web, ou valores referentes à

localização do utilizador, browser utilizado, sistema operativo ou até mesmo a hora a que foi

realizado o pedido [15]. É necessário contemplar este ambiente único onde as aplicações se

encontram, para testar eficientemente o sistema.

Atualmente, a maioria das aplicações desta natureza ainda recorrem ao padrão arquitetural

Modelo-Vista-Controlador (MVC), para assegurar a separação de responsabilidades entre os


35

componentes e promover o baixo acoplamento [35]. Foi especialmente idealizado para separar os

dados de sistema da sua representação gráfica. A camada Modelo é responsável pela persistência e

acesso aos dados através do mapeamento que é feito para entidades de negócio. A Vista, por sua

vez, apresenta a informação visual dos dados solicitados pelo utilizador. Por fim, o Controlador é

um mecanismo que orquestra a comunicação entre a Vista e o Modelo. Na Figura 11 são

ilustrados os constituintes do padrão MVC.

Figura 11 - Padrão Modelo-Vista-Controlador [35]

O teste automático do componente Vista (envolvendo os componentes Controlador e

Modelo), também são denominados de testes front-end ou end-to.end, ainda são considerados um

conceito relativamente recente em tecnologias de informação e detém um vasto conjunto de

desafios.

3.2.2. Desafios de testes web Ultimamente a internet tem-se tornado num dos principais meios para o comércio mundial,

o que quer dizer que as falhas de software podem resultar em consequências desastrosas em

termos económicos para uma organização. A grande concorrência existente entre as organizações

impõe exigências acerca da fiabilidade e consistência deste tipo produto, caso contrário verifica-

se uma diminuição da lealdade e aumento de taxas de abandono por parte do utilizador/cliente.

O desenho e construção de testes está normalmente associado a dificuldades impostas pelo

elevado número de elementos e componentes interdependentes, que não são possíveis de controlar

por parte de quem está a testar. Dando seguimento a esta justificação, os testers devem ter a

preocupação de compreender como as alterações das tecnologias afetam os testes e como

implementar os diferentes cenários de teste que enderecem os requisitos.

A seguinte lista exemplifica alguns dos exemplos de desafios associados ao teste de

aplicações web [19]:


36

1. Vasto número de utilizadores: Os utilizadores da aplicação possuem diferentes

conjuntos de conhecimentos, utilizam uma variedade de diferentes browsers,

sistemas operativos e/ou dispositivos;

2. Ambiente de negócio: Diferentes localizações geográficas, fusos horários, taxas

e linguagens têm de ser acomodados pela solução;

3. Ambiente de teste: Para testar apropriadamente a aplicação é necessário duplicar

o ambiente de produção para construir o ambiente de teste de modo a não

influenciar com a normal exploração do negócio. Implica a utilização de

servidores web, aplicacionais, de base de dados idênticos;

4. Segurança: Devido à facilidade de acesso associada a estas aplicações, são

necessários procedimentos para evitar ataques como SQL Injection14 ou Cross

Site Scripting (XSS)15.

A popularidade do AJAX16 no desenvolvimento de aplicações web contribuiu como mais

um desafio no teste de aplicações deste tipo. De entre os vários, destacam-se a comunicação

assíncrona e o fluxo de dados entre o cliente e servidor habitualmente através de fragmentos XML

ou JSON.

3.2.3. Contexto de testes web A qualidade das aplicações web é definida pelo valor percecionado durante a sua utilização,

se o cliente ou utilizador final não se encontrarem satisfeitos, a qualidade da aplicação não é

aceitável. Tipicamente a interação do utilizador é contida na camada de apresentação da aplicação

web. Os testes de interface web incidem sobre esta camada e estão incluídos na categoria de testes

funcionais mas com algumas propriedades exclusivas, uma vez que se focam essencialmente nos

aspetos visuais da aplicação. A natureza destes testes permite a seguinte categorização:

Testes de sistema GUI: Testes de sistema através da interface gráfica de utilizador.

Testes GUI: Verificam se todos os controlos UI funcionam tal como esperado. São

analisados outros aspetos como por exemplo navegação da aplicação, onde se verifica se

é permitida a navegação do utilizador para todas as páginas que deveria.

Testes de regressão: Verificam a interface utilizador após a realização de alterações.

Tipicamente recorrem a ferramentas capture-replay, que permitem a criação, execução e

verificação dos resultados dos testes reportando as diferenças encontradas.

14 http://en.wikipedia.org/wiki/SQL_injection 15 http://en.wikipedia.org/wiki/Cross-site_scripting 16 http://pt.wikipedia.org/wiki/AJAX_(programação)


37

Testes de validação de entradas: Avaliam a capacidade do sistema reconhecer e

responder corretamente a valores inválidos de entrada.

As categorias referidas acima representam o âmbito dos testes estudados neste estágio,

adiante designados de testes WUI (Web User Interface). Mais especificamente, concentram-se em

testes a funcionalidade, navegação, apresentação e compatibilidade dos browsers. Não se

encontram incluídos aspetos como compatibilidade de sistema operativo, desempenho, segurança

e privacidade.

As ações habitualmente envolvidas nos testes WUI são [36]:

1. Testar se todos os links estão a funcionar devidamente e inexistência de páginas órfãs (páginas que não se encontram ligadas a outras);

2. Testar formulários, que inclui a verificação se as mensagens de erro, de aviso e de sucesso são corretamente apresentadas;

3. Testar HTML e CSS, consiste em verificar se a página se encontra com a estrutura e aplicação de estilos CSS correta, com base na interação com página no browser.

4. Testar a compatibilidade entre browsers inclui a validação de JavaScript e operações AJAX implementadas na aplicação.

A compatibilidade em múltiplos browsers deve ser cuidadosamente atendida como objetivo

destes testes. Os browsers web são provavelmente o software mais utilizado diariamente, onde se

têm destacado MS Internet Explorer17, Mozilla Firefox18, Google Chrome19, Opera20 e Safari21. A

sua principal funcionalidade é apresentar recursos web através do conteúdo devolvido pelos

pedidos HTTP enviados ao servidor. O modo como o browser interpreta e exibe os ficheiros

encontra-se definido nas especificações de HTML e CSS mantidas pela organização World Wide

Web Consortium (W3C). Nos gráficos dispostos na Figura 12 podemos observar que a utilização

do Chrome superou a utilização do Internet Explorer no último ano (Agosto de 2011 a Agosto de

2012) em todo mundo bem como em Portugal [34].

Os principais dados extraídos relativamente ao mês de Agosto de 2012, mostram que o

Chrome é mundialmente utilizado por 33,57% de utilizadores contra 32,83% do Internet Explorer.

No mesmo mês, em relação a Portugal, o Chrome apresenta uma adoção de 39,34% contra a taxa

de 33,40% do Internet Explorer.

17 http://windows.microsoft.com/en-us/internet-explorer/products/ie/home 18 http://www.mozilla.org/pt-PT/firefox/new/ 19 https://www.google.com/intl/pt-pt/chrome/browser/?hl=pt-pt 20 http://www.opera.com/ 21 http://www.apple.com/safari/


38

Figura 12 - Utilização dos browsers no StatCounter22 entre 08/2011 e 08/2012

A consulta atualizada destas estatísticas permitem retirar ilações sobre a tendência dos

utilizadores na preferência dos browsers, útil para conhecer quais os browsers que devem ser

considerados prioritários nos testes à interface de aplicações web.

3.2.4. Técnicas de testes WUI As técnicas existem para melhorar a seleção de testes que otimizam o processo, sem que

provoque a sensação de que foram excluídas as principais ou grandes áreas do sistema na

cobertura de testes.

Testes baseados em captura/reprodução

O mais comum para testes de interface é a existência de uma infraestrutura que suporta a

captura e reprodução dos cenários de utilização. Uma das formas de implementar este método por

forma a obter um resultado é gravar as interações do utilizador com a aplicação e reproduzi-las

durante a fase de execução dos testes. Um exemplo deste tipo de ferramentas é o Selenium IDE23,

ferramenta analisada no Anexo E. Apesar de esta técnica ser recomendada, para testes funcionais

web que exercitam a GUI da aplicação sob o ponto de vista do utilizador, apresenta algumas

limitações como por exemplo não possibilita a adição de ciclos ou avaliação de condições. A sua

utilização é apenas aconselhada quando se pretende exportar e complementar os testes para uma

framework de testes tipo JUnit ou TestNG.

Testes baseados em scripts

As técnicas para construção de scripts de testes automáticos são similares às técnicas de

utilizadas para o desenvolvimento de sistemas de software. Tipicamente os scripts contêm dados e

instruções para a framework de teste. Os exemplos mais conhecidos desta técnica prendem-se

scripts estruturados e scripts data-driven.

22 http://statcounter.com/ 23 http://seleniumhq.org/projects/ide/


39

No primeiro caso, tal como as linguagens de programação estruturadas, estes testes

utilizam, instruções condicionais e ciclos, garantindo uma flexibilidade não existente nos scripts

resultantes das ferramentas de captura/reprodução.

No caso dos scripts data-driven, referem-se a scripts mais abrangentes que leem valores de

entradas de teste ou resultados esperados a partir de um ficheiro de dados ou base de dados. Isto

permite o desacoplamento dos dados de teste dos próprios testes, possibilitando a reutilização

dessa informação para múltiplos testes.

Padrão de desenho Page Object

O padrão Page Object é uma técnica extremamente útil para separar a lógica ortogonal de

teste das funcionalidades de uma página da aplicação e os mecanismos de interação com essa

funcionalidade. Atua como uma API de uma página HTML e expõe os “serviços”

disponibilizados por essa página, abstraindo a interna implementação da página. Todos esses

“serviços” são implementados numa classe designada de Page Object ([38]). Cada “serviço”

disponibilizado e invocado pelo código de teste deve ter como parâmetro de saída outro objeto do

tipo Page Object, permitindo assim encadear múltiplos métodos de ações (Method Chaining).

A aplicação desta técnica permite obter as seguintes vantagens:

DSL legível para os testes;

Promove a reutilização e reduz a duplicação de código;

Permite criar testes mais robustos;

Centraliza o acoplamento de UI (UI é alterada num único local);

Abstração da implementação da página para executar as ações de UI; Agnóstico à framework de teste.

A título de exemplo, supondo que se pretendia desenvolver o Page Object referente à

página de autenticação da aplicação web, este deveria conter um método loginAs onde seriam

passados como argumento o nome e palavra-chave de acesso. Caso os dados introduzidos fossem

corretos, este Page Object deveria devolver um novo Page Object referente à página inicial da

aplicação. Caso contrário seria devolvido o Page Object da página de login com a apresentação da

mensagem de erro de falha de autenticação.

3.2.5. Critérios de testes WUI Uma vez que não é possível testar 100% um sistema, os critérios de cobertura servem para

decidir sobre quais devem ser os valores de entrada a utilizar nos testes. A comunidade de testes

de software acredita que a utilização efetiva de critérios de cobertura aumenta a probabilidade dos

engenheiros de teste detetarem as falhas num programa e assegurem um maior grau de qualidade.


40

Testes baseados em Casos de uso

Tal como qualquer outra aplicação, as aplicações web possuem documentos que descrevem

os seus requisitos a nível de utilizador e do sistema, no documento de especificação de requisitos

de software. Normalmente a descrição destes requisitos é efetuada recorrendo ao diagrama e

descrição tabelar de casos de uso UML. Uma das técnicas informais para o desenho e construção

de testes passa por traduzir esta informação numa lista de casos de teste [14]. Normalmente para

uma validação mínima considera-se que, pelo menos, um caso de teste deve cobrir um caso de

uso.

Navegação e links

Tendo como base Model-Driven Test Design, Amman e Offut [16] propõem a modelação da

aplicação web numa estrutura do tipo grafo, em que os “nós” representam a páginas e as ligações,

links existentes dentro das páginas. A construção do grafo é iniciada com uma página introdutória,

sendo depois aplicado o algoritmo de pesquisa de largura (breath-first) para todos os links dessa

página. No final devem ser criados o mínimo casos de testes que garantam a cobertura de todas as

ligações. Este critério é conhecido como Edge Coverage ou Branch Coverage. A abordagem

Model-Driven Test Design ou Model-Based Testing consiste em extrapolar o modelo/estrutura de

um artefacto de projeto, podendo referir-se ou não a código, e gerar os requisitos de teste a partir

da aplicação de um critério de cobertura formal. Neste caso, o desenho de testes pode ser baseado

em critérios e/ou no conhecimento humano do domínio. Apesar de este modelo ser mais adequado

para o teste de funcionalidade de aplicações web estáticas, o seu usufruto permite validar com

eficácia testes que se prendem com transições entre páginas da aplicação, como por exemplo,

teste de navegação ou de links.

Validação de entradas

O teste de software de uma forma geral consiste na seleção de conjuntos finitos de valores

para um domínio de entrada, como exemplo, parâmetros de um método, dados de um ficheiro,

variáveis ou campos introduzidos pelo utilizador na interface. A técnica que permite particionar

cada entrada em regiões é denominada na literatura por Input Domain Characterization, Input

Space Partitioning ou Partição por equivalência.

A estratégia consiste em dividir cada domínio de uma entrada em blocos, de modo que

sejam satisfeitas duas restrições: os blocos têm de ser disjuntos (sem sobreposição) e a união dos

blocos tem de cobrir o domínio total da entrada. Os casos de teste gerados resultam da aplicação

de critérios tendo em conta a combinação dos valores contidos em cada bloco definido. Por

exemplo, o critério Each Choice Coverage define que pelo menos um valor de cada bloco de uma

entrada deve ser utilizado num caso de teste.


41

Validação de elementos da página

A interface utilizador web é orientada a eventos (event-driven), em que eventos são ações

efetuadas pelo utilizador, como por exemplo movimento e cliques do rato ou introdução de dados

num formulário através do teclado. Para estes testes recomenda-se a aplicação de critérios sobre

uma máquina de estados extraída do GUI. Cada evento protagonizado pelo utilizador provoca

uma transição de estados. Nesta abordagem o caminho composto pelas ligações entre os estados

representam um caso de teste. O facto do resultado esperado ser indicado simplesmente por um

estado final é apontado como a principal vantagem desta solução. Num primeiro trabalho que se

destinava a determinar se uma interface utilizador foi adequadamente testado, Memon, Soffa e

Pollack, apresentaram critérios de cobertura que utilizam eventos e sequência de eventos, como

meio para medir a adequabilidade dos testes. Defendem a decomposição do GUI em

componentes, sendo cada um utilizado como unidade base de teste [9]. Porém esta abordagem

apresenta a desvantagem de registar o crescimento exponencial de estados que se tem de verificar,

mesmo nas interfaces compostas por poucos elementos.

Fluxo de eventos

Posteriormente Memon A. propôs um modelo para teste de aplicação web que consolida

soluções Model-based testing denominado de event-flow model [10]. O artigo contribuiu ainda

com melhorias ao modelo apresentado recorrendo a técnicas especializadas ESESs (event-space

exploration strategies). Estas técnicas são específicas para verificação do modelo, geração de

casos de teste e criação de oráculo de teste (mecanismo que determina se um determinado teste

falha ou passa). Todas as técnicas de teste apresentadas funcionam eficazmente quando aplicada a

sistemas web simples, mas revelam insuficiências em aplicações de maior complexidade e

dimensão.

Checklists

Em [37] Steve Miller contribuiu com uma lista de casos de teste informal tendo como base

a perspetiva empírica da engenharia de testes. Os casos de teste são identificados com recurso a

exploratory testing, termo celebrizado por Cem Kaner que define uma abordagem de teste que

promove a liberdade e responsabilidade do tester na otimização contínua da qualidade do software

testing paralelamente ao desenvolvimento do projeto.

3.2.6. Sumário de testes de interface web A temática envolvente dos testes de interface web continua a ser um dos principais alvos de

investigação no meio académico e profissional. Em parte deve-se ao seu constante caráter

dinâmico e evolutivo. Apesar do extenso número de trabalhos já realizados, do desenvolvimento


42

de frameworks de testes cada vez mais robustas, ainda não foram encontradas soluções eficazes e

eficientes de modo a mitigar todos os desafios e limitações dos testes WUI.

3.3. Ferramentas de automatização de testes A escolha da realização de testes manuais ou automáticos é influenciada pelos aspetos

económicos envolvidos num projeto de software. A construção e manutenção de um teste

automático é normalmente maior do que o equivalente manual. Contudo, esse esforço é

recompensado posteriormente com a rápida execução e verificação dos casos de teste. Além disto,

não tem a desvantagem de estar sujeito a erro humano como se verifica nos testes manuais [12].

As ferramentas de testes automáticos permitem a minimização do esforço laboral,

envolvido na execução repetida dos testes, e viabilizam o aumento de cobertura do software

devido à manutenção de um maior número de casos de testes. Todas as aplicações candidatas

teriam obrigatoriamente de ser código-aberto para estar em conformidade com a política seguida

pela organização.

Os testes de regressão apenas são adequados quando automatizados, para assim, assegurar a

contínua qualidade da solução durante a implementação de correções ou modificações.

Baseado nestes pressupostos, esta secção explora o espetro de ferramentas existentes para

servir de apoio às atividades de teste presentes no STG da Present Technologies. Para este efeito

foi produzido o relatório existente no Anexo E, que contém o resultado detalhado da análise

informal de ferramentas de testes automáticos Java web incluindo descrição dos protótipos

desenvolvidos. De seguida são expostos os pontos-chave, no entanto, para melhor esclarecimento

não é dispensada a consulta do respetivo anexo.

3.3.1. Ferramentas de testes funcionais A seleção da ferramenta de testes vocacionada para testes funcionais no universo Java

incide predominantemente sobre o JUnit24 e TestNG25. As duas frameworks caraterizam-se por ter

código-aberto e por facilitar a implementação de testes automatizados. Habitualmente associadas

à implementação de testes unitários, as ferramentas são genéricas ao ponto de possibilitar a

implementação de testes de outra granularidade (integração, sistema e aceitação). Foi realizada

uma comparação das funcionalidades de cada uma com o objetivo de eleger a mais adequada para

a empresa.

O JUnit teve sua origem no SUnit, uma iniciativa de Kent Beck que consistia na criação de

testes a objetos utilizando Smalltalk [23]. Por outro lado, o TestNG desenvolvido por Cédric Beust 24 http://www.junit.org/ 25 http://testng.org


43

tinha como intuito introduzir novas funcionalidades de modo a tornar a utilização mais amigável e

robusta do que JUnit e NUnit.

Ambas possibilitam a execução repetida e automática dos testes. A utilização integrada com

Eclipse IDE26, ferramenta de desenvolvimento maioritariamente utilizada na Present

Technologies, simplifica a visualização imediata dos resultados e tempo gasto na execução dos

testes.

De modo a identificar as principais diferenças entre JUnit e TestNG foram desenvolvidos

protótipos que procuravam exercitar as principais funcionalidades de cada uma das tecnologias. A

implementação de um caso de teste é em tudo semelhante, bastando colocar a anotação @Test no

método de uma classe e utilizar um método estático com prefixo assert para efetuar a comparação

do resultado real como o esperado. A Listagem 2 exibe a implementação de um teste exemplo que

valida o método Math.sqrt, simultaneamente nas duas frameworks.

Listagem 2 – Exemplo de teste da raiz quadrada

JUnit TestNG import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class SimpleTest {

@Test

public void testSquareRoot() {

assertEquals(2.0, Math.sqrt(4.0), 0.0);

}

}

import static org.testng.Assert.assertEquals;

import org.testng.annotations.Test;

public class SimpleTest {

@Test

public void testSquareRoot() {

assertEquals(Math.sqrt(4.0), 2.0, 0.0);

}

}

A diferença mais notória apreendida logo no início do estudo prende-se com a hierarquia

(Figura 13) e ciclo de vida dos testes. Para o JUnit o conceito de teste refere-se ao método

anotado com @Test, já no TestNG representa um nível intermédio entre a suite e classe de teste.

Figura 13 - Hierarquias de teste JUnit e TestNG

O ciclo de vida de um teste é composto por métodos que permitem a preparação, execução,

validação e limpeza do teste. Estas fases são disponibilizadas sob a forma de anotações com

prefixos @Before e @After. No entanto, o TestNG oferece um ciclo de vida mais rico, dispondo 26 http://eclipse.org/


44

de mais fases onde é possível estender as funcionalidades de preparação e limpeza de dados ou

configuração de teste.

Posteriormente a investigação evoluiu no sentido de conhecer funcionalidades mais

avançadas, como por exemplo o suporte de exceções, criação de suites de testes, segmentação de

testes em categorias, parametrização de testes. As duas frameworks facilmente cumprem estas

utilidades de um modo bastante similar.

No entanto, existe uma caraterística marcada por duas políticas completamente divergentes,

que se refere à dependência entre testes. O JUnit defende que todos os testes devem ser

executados independentemente de outros. Em contrapartida o TestNG, recorrendo ao argumento

que todas instruções do código são executadas sequencialmente, aposta na definição de relações

de dependência obtendo assim uma execução de testes otimizada ([24]). Esta funcionalidade é

assegurada pela utilização das anotações @DependsOnGroups e @DependsOnMethods. A análise

comparativa destas ferramentas foi concluída com um exemplo de automatização em conjunto

com o plugin Surefire27 do Maven, aconselhado para a execução de testes unitários durante o build

do projeto.

Em termos funcionais, o TestNG revela alguma superioridade em relação ao JUnit, embora

contenha funcionalidades nucleares semelhantes. Contudo, o JUnit é a framework de testes

escolhida pela Present Technologies devido à sua consistente integração com Arquillian

(ferramenta descrita mais à frente). Atualmente a integração desta ferramenta com o TestNG inclui

algumas limitações como se pode constatar em https://issues.jboss.org/browse/ARQ-919.

3.3.2. Ferramentas de testes web O trabalho inicial desenvolvido na área de teste a aplicações web focava-se essencialmente

na validação estática do lado do cliente, garantindo essencialmente que não existiam links

inválidos à disposição do utilizador. Nos dias de hoje, unicamente este tipo de verificação é

manifestamente insuficiente, devido à atual complexidade e proliferação de aplicações web [15].

As ferramentas em baixo foram avaliadas consoante os seguintes critérios informais:

Capacidade de criação de scripts de testes robustos, de modo a garantir que o seu valor perdure após alterações e modificações do software;

Flexibilidade para a geração e alteração dos scripts;

Minimização do impacto no processo de gestão de desenvolvimento. Pesando a reputação e notoriedade, as ferramentas avaliadas para escrita de testes da

camada de apresentação foram o HtmlUnit, Selenium e Watir.

27 http://maven.apache.org/plugins/maven-surefire-plugin/

https://issues.jboss.org/browse/ARQ-919


45

HtmlUnit

O HtmlUnit28, impulsionado por Mike Bowler da Gargoyle Software Inc., é tido como um

headless browser29 escrito em Java, este não exibe qualquer interface gráfico, sendo os testes

executados contra um browser simulado. Fornece uma API rica que permite testar todos os

aspetos de uma aplicação web e manipular o conteúdo HTML e JavaScript. A adequabilidade

desta framework insere-se nos cenários onde se pretende manter um estado conversacional

durante o acesso a um conjunto de páginas web, por exemplo, processo de autenticação ou gestão

de cookies. A implementação de um teste HtmlUnit consiste na escrita de instruções de código

que simulam a ações de um utilizador no browser, tais como obter página, inserir dados, ler

conteúdo e pressionar botões e links [23]. Na Listagem 3 é ilustrada a implementação de um caso

de teste simples utilizando o HtmlUnit e JUnit, onde é verificada a página resultante da seleção de

um link.

Listagem 3 - Caso de teste exemplo HtmlUnit

HtmlUnit […]

public class ImdbTests {

private static URL URL;

private static WebClient webClient;

@BeforeClass

public static void setUpBeforeClass() throws MalformedURLException {

webClient = new WebClient();

URL = new URL("http://www.imdb.com");

}

@AfterClass

public static void tearDownAfterClass() {

webClient.closeAllWindows();

}

@Test

public void accessImdb() throws FailingHttpStatusCodeException, MalformedURLException,

IOException {

HtmlPage initialPage = webClient.getPage(URL);

assertEquals("The Internet Movie Database (IMDb)", initialPage.getTitleText());

HtmlAnchor topLink = initialPage.getAnchorByText("Top 250");

HtmlPage top250Page = topLink.click();

assertEquals("IMDb Top 250", top250Page.getTitleText());

}

}

[…]

28 http://htmlunit.sourceforge.net/ 29 http://en.wikipedia.org/wiki/Headless_system


46

Através da Listagem 3 é possível observar que o objeto WebClient representa o browser

fictício, principal ponto de entrada, responsável pela realização de pedidos de páginas específicas

e obtenção das respetivas respostas. O browser simulado é inicializado na mesma máquina virtual

Java (JVM) onde são executados os testes. Neste exemplo a página inicial do endereço

www.imdb.com é solicitada através da invocação do método getPage(URL). Depois de pesquisado o

link intitulado “Top 250” (getAnchorByText(“Top 250”)), este é pressionado através da instrução

topLink.click(). Esta instrução implica a realização de um pedido interno cujo resultado é um objeto

do tipo HtmlPage. Por fim, é verificado se o título desta página resultante é igual ao texto “IMDb Top

250”. O exemplo serve apenas para fins ilustrativos, pois a pesquisa de links a partir do seu texto é

altamente desaconselhada devido à frequente alteração e internacionalização da aplicação (o teste

falha quando utilizadas outras línguas suportadas pela aplicação).

Os testes automatizados web ganharam uma nova dimensão com a introdução do HtmlUnit

no mercado, no entanto acabaram por surgir ferramentas mais robustas que visam o teste em

browsers reais como é o caso do Selenium e Watir.

Selenium

O projeto Selenium30 é composto por um conjunto de componentes que suportam a criação

facilitada de testes de aplicações web, refletindo exatamente o que os utilizadores observam e

produzem no browser. Originalmente desenvolvido por Jason Huggins na empresa ThoughtWorks

é constituído pelos subprojetos Selenium IDE, Selenium 1.0 (RemoteControl), Selenium 2.0

(WebDriver) e Selenium Grid. Por uma questão de relevância, a descrição neste documento é

centrada apenas no Selenium 2.0. Os restantes componentes encontram-se detalhados no Anexo E.

A versão 2.0 do Selenium resultou da sinergia com o WebDriver (Google), da qual

resultaram os seguintes benefícios [13]:

A ferramenta deixa de estar confinada à sandbox de JavaScript dos browsers;

API mais intuitiva e simples para interação com o DOM (Document Object Model);

Suporte transversal dos principais browsers existentes, incluindo plataformas móveis.

Atualmente o Selenium disponibiliza implementações de drivers de múltiplos browsers,

entre os quais o HtmlUnit revisto anteriormente, Mozilla Firefox, MS Internet Explorer, Google

Chrome, Opera, Safari, Android e BlackBerry. Alguns dos drivers são implementados na

linguagem nativa do respetivo browser, enquanto outros são implementados diretamente em

JavaScript.

30 http://seleniumhq.org/


47

Tal como o WebClient no HtmlUnit, o objeto principal do Selenium é a interface WebDriver

que permite o controlo da interface gráfica da aplicação web, como por exemplo selecionar os

elementos da página, representados pela interface WebElement.

Na Listagem 4 é demonstrado um caso de teste que serve para verificar o mecanismo de

pesquisa constante na aplicação web www.imdb.com. No exemplo foi utilizado o driver

correspondente à implementação do browser Mozilla Firefox.

Listagem 4 - Caso de teste exemplo Selenium

Selenium public class ImdbTest {

private static WebDriver driver;

@BeforeClass

public static void setUpBeforeClass() throws Exception {

driver = new FirefoxDriver();

}

@AfterClass

public static void tearDownAfterClass() throws Exception {

driver.quit();

}

@Test

public void searchMovie() {

driver.get("http://www.imdb.com");

assertEquals(driver.getTitle(), "The Internet Movie Database (IMDb)");

WebElement searchInput = driver.findElement(By.id("navbar-query"));

searchInput.sendKeys("the godfather");

WebElement submitSearchButton = driver.findElement(By.id("navbar-submit-button"));

submitSearchButton.click();

assertTrue(driver.getPageSource().contains("The Godfather: Part II"));

assertTrue(driver.getPageSource().contains("The Godfather: Part III"));

}

}

Através do método get(“http://www.imdb.com”) é solicitada a página inicial da aplicação sob

teste. Após verificação da página com base no seu título, a seleção da caixa de texto de pesquisa é

efetuada através da instrução findElement(By.id(“navbar-query”). Este método contém um argumento

do tipo By, que define um conjunto de métodos estáticos para localizar um elemento. A opções de

pesquisa podem ser efetuadas pelo atributo id (usado no exemplo), atributo name, XPATH31, CSS,

texto e tag do elemento HTML.

Quando a pesquisa é efetuada com sucesso no método findElement(), é devolvido um objeto

do tipo WebElement, que encapsula toda a informação do elemento DOM pretendido.

Posteriormente foram utilizados os métodos de interação sendKeys() e click() para introduzir o termo

31 http://www.w3.org/TR/xpath/


48

a pesquisar e pressionar o botão de pesquisa. No final do teste foi verificado se de facto o

conteúdo da página resultante dispunha da informação pretendida.

Quando executado o teste no browser Firefox, é inserida uma indicação no canto inferior

direito de que está a ser controlado pelo Selenium. As ações decorrentes do teste são reproduzidas

no browser e finalmente é terminado sem qualquer intervenção manual (Figura 14).

Com este teste ficou demonstrado que o Selenium pode ser utilizado em testes de validação

semântica da informação apresentada numa determinada página web. Além do conteúdo, é ainda

possível validar a forma e estrutura da página recorrendo a métodos como getLocation() ou getSize().

Este tipo de validação deve ser utilizado com alguma prudência, pois cada browser dispõe do seu

próprio algoritmo de apresentação dos elementos, o que faz com que a mesma página contenha

pequenas diferenças quando apresentada em diferentes browsers.

A pesquisa do Selenium terminou com a análise do módulo Remote WebDriver que

providencia um meio para controlar vários browsers em máquinas remotas, bastante útil quando

se pretende a execução dos testes simultaneamente em ambientes completamente diferentes.

Figura 14 - Teste de pesquisa de filme

Watir

Visto como uma das principais alternativas ao Selenium, o Watir é uma biblioteca código-

livre BSD (Berkeley Software Distribution) utlizada para automatizar o teste a aplicações web

através da escrita de scripts de fácil interpretação e manutenção, parcialmente desenvolvida por


49

Bret Pettichord. As principais áreas de atuação desta ferramenta são testes de sistema de grande

escala, automatização de testes funcionais e de aceitação.

Muito à semelhança do Selenium, o Watir permite controlar o browser imitando as

operações típicas dos utilizadores, como por exemplo selecionar links e preencher formulários. De

base apenas é suportado o browser MS Internet Explorer, sendo necessário instalar um plugin

específico para utilizar outros browsers (gem watir-webdriver) [25].

Para o estudo desta ferramenta foi imprescindível a aprendizagem das operações básicas da

linguagem Ruby, bem como da API do Watir. Ruby é uma linguagem de programação dinâmica

de alto nível, o que faz com a sua aprendizagem seja fácil. Devido a estas propriedades, o número

de linhas de código por teste reduziram drasticamente em relação ao HtmlUnit e Selenium. Os

seus conceitos chave são:

Watir::Browser, representação lógica do browser que se pretende controlar;

Método goto permite o reencaminhamento para uma página específica;

Método include serve para verificar a presença de texto num determinado elemento. De seguida é apresentada a implementação do caso de teste da Listagem 5, mas desta vez

portado para Ruby e Watir.

Listagem 5 - Caso de teste exemplo Watir

Watir require 'test/unit'

require 'watir-webdriver'

class IMDB < Test::Unit::TestCase

def test_0000

$browser = Watir::Browser.new :ff

$browser.goto 'http://www.imdb.com'

end

def test_0001

assert($browser.title.include?( 'The Internet Movie Database (IMDb)'))

t = $browser.text_field(:name, 'q')

t.flash

t.set('the godfather')

b = $browser.button(:id, 'navbar-submit-button')

b.click

assert($browser.text.include?( 'The Godfather: Part II'))

assert($browser.text.include?( 'The Godfather: Part III'))

end

def test_9999

$browser.close

end

end

Os blocos test_0000 e test_9999 foram implementados com o único propósito de instanciar e

finalizar o browser antes e após a execução de todos testes. Esta solução é possível porque os


50

testes são executados por ordem alfabética, deste modo fica garantida a disponibilidade do

browser nos blocos de teste intermédios. Os objetivos dos métodos de acesso e interação são

idênticos aos do Selenium, no entanto esta ferramenta destaca-se por conter uma funcionalidade

única.

Em tempo de execução do teste é possível assinalar visualmente um determinado elemento

da página através do comando flash, tal como ilustrado no campo de texto de pesquisa da Figura

15.

Figura 15 – Elemento assinalado pelo Watir

Conclusão

No que diz respeito a eficiência de captura de interações UI (User Interface), área principal

de investigação deste relatório, o Selenium apresenta vantagens sobre o Watir, tais como o seu

vasto conjunto de browsers suportados, incluindo os principais móveis (à data de elaboração deste

documento: FF6, FF5, FF4, FF3, IE9, IE8, IE7, Safari3, Safari2, Opera9, Opera8, Android 2.16

e iOS). A fidelidade com que são replicadas as várias operações sobre a UI é fruto do maior

amadurecimento da ferramenta. O Watir apresenta alguns inconvenientes como dificuldade em

escrever testes para aplicações baseadas em AJAX. Esta ferramenta não lida bem com o

tratamento de pop-ups ou variações dinâmicas do DOM.

Para uma pequena, média empresa esta ferramenta facilmente se adequa e adapta ao dia-a-

dia dos projetos de aplicações Web, não requerendo muito tempo de aprendizagem. Além disso,

tem uma forte comunidade de suporte facilitando assim a resolução de problemas emergentes.

Visto como solução mais robusta, completa e amadurecida, foi escolhida conjuntamente como

ferramenta para desenvolvimento de testes automatizados Web no âmbito deste projeto.

3.3.3. Ferramentas de testes in-container Um dos problemas identificados durante a implementação de testes funcionais web foi a

obrigatoriedade da aplicação alvo de testes ter de se encontrar completamente disponível num

servidor web, mesmo quando se pretende testar apenas um componente. Isto pode conduzir à


51

despesa de esforço e tempo no build e instalação da aplicação no ambiente testes, que deveriam

ser investidos na implementação e execução dos testes.

Adicionalmente são utilizados artifícios designados de Mock e Stub, objetos que simulam o

comportamento de objetos reais, para substituir a iniciação do servidor aplicacional web ou

componentes da aplicação ainda em desenvolvimento. No entanto, o uso destes mecanismos leva

ao aumento de manutenção de código e a um falso sentido de segurança porque o sistema a testar,

não obtém respostas reais mas sim simuladas. Ainda aliado a estes problemas, por vezes, o

programador subverte o verdadeiro sentido destes mecanismos e utiliza-os somente para que os

testes sejam executados com sucesso.

Arquillian

Partindo destes pressupostos, a ferramenta Arquillian32 foi adotada como resposta a esta

problemática pela Present Technologies. O uso desta ferramenta já se verificava antes da

realização deste estágio. O Arquillian é um projeto inovador que permite reduzir a complexidade

na criação e execução de testes de integração no ambiente de execução pretendido. Neste caso, o

termo in-container refere-se à execução de testes com a aplicação instalada e em execução num

container Java EE. Esta ferramenta teve como base o JBoss Test Harness desenvolvido por Pete

Muir para a framework Seam.

O objetivo do Arquillian é permitir funcionalidades como:

Gestão do ciclo de vida do container; Envolve o teste e as suas dependências num arquivo utilizando o ShrinkWrap33; Deploy automático do arquivo no container; Execução dos testes dentro ou contra o container; Captura e apresentação dos resultados.

Para explicar como funciona o Arquillian foi construída uma infraestrutura composta pela

entidade Movie e o bean Movie Service que expõe as funcionalidades típicas de CRUD

(Create/Read/Update/Delete) da entidade Movie. Estas classes serviram como exemplo de uma

aplicação a testar (Listagem 6).

Listagem 6 - Infraestrutura para teste Arquillian

Entidade Movie @Entity

public class Movie implements Serializable {

@Id

@GeneratedValue(strategy = GenerationType.IDENTITY)

32 http://www.jboss.org/arquillian.html 33 http://www.jboss.org/shrinkwrap


52

@Column(nullable = false)

private Long id;

@Column(length = 50, nullable = false)

private String name;

@Column(length = 200, nullable = true)

private String director;

@Column(length = 20, nullable = true)

private String type;

@Column(nullable = true)

private Integer year;

[...]

}

Movie Service @Stateless

@LocalBean

@TransactionAttribute(TransactionAttributeType.REQUIRED)

public class MovieService {

@TransactionAttribute(TransactionAttributeType.SUPPORTS)

public Movie getMovieById(Long id) { [...] }

@TransactionAttribute(TransactionAttributeType.SUPPORTS)

public List<Movie> getMovies() { [...] }

public Movie insertMovie(Movie movie) { [...] }

public Movie updateMovie(Movie movie) throws MovieException { [...] }

public void deleteMovie(Long id) throws MovieException { [...] }

}

O caso de teste exemplo incidiu sobre a operação que permite adicionar um novo filme

(insertMovie) disponibilizada pelo MovieService, no entanto, as implementações destes métodos

foram omissas por não manifestar relevância relativamente ao assunto em questão. Na Listagem 7

é apresentado código referente ao teste Arquillian.

Listagem 7 - Caso de teste exemplo Arquillian

Arquillian @RunWith(Arquillian.class)

public class MovieServiceIT {

private static Long id;

@Inject

private MovieService service;

@Deployment

public static JavaArchive createDeployment() throws IOException {

return ShrinkWrap

.create(JavaArchive.class, "movie-ejb.jar")

.addClasses(MovieService.class, Movie.class, MovieException.class)

.addAsManifestResource("test-persistence.xml", "persistence.xml")

.addAsManifestResource("jboss-deployment-structure.xml")


53

.addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));

}

@Test

public void insertMovie() {

Movie movie = new Movie ();

movie.setName("Rear Window");

movie.setDirector("Alfred Hitchcock");

movie = service.insertMovie(movie);

id = movie.getId();

Assert.assertEquals("Rear Window", movie.getName());

}

}

Como se trata de uma ferramenta genérica, o Arquillian necessita de ser integrado com uma

framework de testes funcionais, neste exemplo foi utilizado o JUnit. A anotação

@RunWith(Arquillian.class) ao nível da classe de teste indica ao JUnit que o controlador de teste

(TestRunner) a utilizar deve ser o disponibilizado pelo Arquillian.

O Arquillian permite a partilha de recursos entre a aplicação e os testes através de CDI

(Context and Dependency injection). Por exemplo, é possível injetar managed beans, EJBs e

outros recursos Java EE diretamente nos testes utilizando a anotação @Inject, tal como

exemplificado no exemplo com o MovieService.

O ShrinkWrap, por sua vez, é utilizado para criação do arquivo de teste, isolando assim as

classes e recursos exclusivamente necessários para viabilizar a execução do teste. No exemplo

acima, o arquivo movie-ejb.jar é somente constituído pelas classes especificados no método

addClasses e recursos definidos no método addAsManifestResource. Estes micro-deployments visam a

poupança de tempo durante o ciclo de codificação-teste-codificação.

Por fim, o método anotado com @Test refere-se a um caso de teste típico JUnit, mais

especificamente, consiste em verificar se a introdução de um novo filme foi realizada com

sucesso.

Quando executado o teste, o TestRunner do Arquillian pesquisa o método estático anotado

com @Deployment para obter o arquivo de teste e posteriormente efetua o deploy deste arquivo no

container configurado (neste teste foi utilizado o JBoss AS 7). De seguida os testes são executados

contra o arquivo em execução no container e são recolhidos os resultados. Após a realização de

todos os testes, o TestRunner remove o arquivo deploy do container.

Contraponto com o plugin Surefire do Maven, para execução destes testes foi utilizado o

plugin Failsafe34, desenhado para testes de integração. Os testes Arquillian inserem-se nesta

categoria, pois são testados módulos em grupo. Por exemplo, no caso de teste exemplo foi

34 http://maven.apache.org/plugins/maven-failsafe-plugin/


54

utilizado o MovieService, enriquecido com todas as carateríticas que o container fornece a este

tipo de objetos.

Apesar de ter sido utilizado o JBoss Application Server 7.1 no protótipo, o Arquillian

suporta outros servidores aplicacionais, tais como o Tomcat, GlassFish e Jetty. Os testes

Arquillian são agnósticos ao container usado, não é preciso alterar a sua implementação para que

o teste funcione corretamente noutro container, apenas são alteradas as dependências no build do

Maven.

Drone e Graphene

Mais recentemente foram desenvolvidas as extensões Arquillian Drone35 e Arquillian

Graphene36. O Drone possibilita a gestão automática do ciclo de vida dos componentes

necessários para testes a interfaces web, enquanto o Graphene não é mais do que um Selenium

melhorado e focado para um rápido desenvolvimento em ambientes Java. O Drone constrói e gere

a utilização de ferramentas de teste web, tais como Selenium 1.0, Selenium 2.0 WD ou Graphene.

Para utilização do Drone é necessário conhecer os modos de execução de testes possíveis

do Arquillian. No exemplo anterior foi demonstrado o modo in-container (por omissão), isto é, os

testes são executados dentro do container. Por outro lado, no modo cliente os testes são

executados numa JVM cliente do container. Este modo de execução é considerado o ideal para a

execução de testes WUI e pode ser ativado adicionando o atributo “testable = false” à anotação

@Deployment ou acrescentar a anotação @RunAsClient aos métodos de teste pretendidos (modo

híbrido). A Figura 16 dá uma visão de alto nível dos modos de execução previstos no Arquillian.

Figura 16 - Modos de execução do Arquillian (in-container vs client)

O próximo teste exemplo ilustra os passos necessários para utilizar o Drone juntamente

com o Graphene. O objetivo do teste passa novamente por verificar que um determinado filme é

adicionado com sucesso, mas desta vez utilizando a interface web do sistema. Foi por isso

35 https://docs.jboss.org/author/display/ARQ/Drone 36 https://docs.jboss.org/author/display/ARQGRA/Home


55

construída uma pequena aplicação web com base na framework Stripes37 (descrita no capítulo 5),

que continha um formulário para a adicionar filmes.

Listagem 8 - Caso de teste exemplo Drone e Graphene

Drone e Graphene @RunWith(Arquillian.class)

@RunAsClient

public class MovieTestsIT {

@Drone

GrapheneSelenium driver;

protected JQueryLocator ADD_MOVIE_LINK = jq("a:contains('Add Movie')");

protected NameLocator NAME_FIELD = name("movie.name");

protected NameLocator DIRECTOR_FIELD = name("movie.director");

protected NameLocator TYPE_FIELD = name("movie.type");

protected NameLocator YEAR_FIELD = name("movie.year");

protected IdLocator SAVE_BUTTON = id("save");

protected JQueryLocator STRIPES_ERROR = jq("div:contains('Please fix the following

errors:')");

protected JQueryLocator STRIPES_SUCCESS_MSG = jq("li:contains('The movie was successfully

inserted!')");

@Deployment

public static EnterpriseArchive createDeployment() throws IOException {

[…]

return ear;

}

@Test

public void addMovieWithInfo(@ArquillianResource URL baseURL) throws IOException {

waitModel.until(elementPresent.locator(NAME_FIELD));

driver.type(NAME_FIELD, "One Flew Over the Cuckoo's Nest");

driver.type(DIRECTOR_FIELD, "Milos Forman");

driver.type(TYPE_FIELD, "Drama");

driver.type(YEAR_FIELD, "1975");

waitForHttp(driver).click(SAVE_BUTTON);

Assert.assertTrue("Stripes success message!",

driver.isElementPresent(STRIPES_SUCCESS_MSG));

}

}

Como é possível observar, a implementação não difere muito de um típico teste Arquillian.

O método anotado com @Deployment foi reutilizado do exemplo disposto na Listagem 7. A

presença da anotação @Drone permite injetar uma instância de uma framework de teste web e

assegura a sua existência até à execução do último teste da classe.

Neste caso foi utilizada uma instância do Graphene, cuja uma das vantagens, é incluir uma

estratégia de localização de elementos baseada em jQuery38(Listagem 8). Por exemplo, a

37 http://www.stripesframework.org/display/stripes/Home 38 http://jquery.com/


56

instrução protected JQueryLocator ADD_MOVIE_LINK = jq(“a:contains('Add Movie’)”) permite localizar

links que contenham o texto “Add Movie”.

Outra vantagem significativa da extensão Graphene é a API dedicada para testes AJAX. Os

métodos waitModel e waitForHttp devem ser utilizados quando se pretende aguardar a resposta de

invocações assíncronas. No caso do primeiro método, o teste fica suspenso até que o elemento

pretendido se encontre disponível no DOM da página. Relativamente ao segundo método, este

permite que o teste fique suspenso até ser devolvida a resposta de um pedido HTTP, normalmente

protagonizado ao clicar num link ou na submissão de um formulário.

A análise destas ferramentas não inclui qualquer comparação com ferramentas alternativas,

tendo servido para o estagiário ganhar know-how na sua utilização. O Arquillian já se encontrava

em utilização na empresa, tendo sido adotado o Drone e Graphene durante o estágio. Uma das

principais vantagens da adoção destas ferramentas é a sua disponibilidade para integrar com o

Selenium 1 e 2.

Outro aspeto fundamental nos testes de validação de interface web diz respeito à lógica,

normalmente em JavaScript, existente do lado cliente (browser). Na próxima secção serão

analisadas ferramentas de testes destinadas a esta tecnologia.

3.3.4. Ferramentas de testes JavaScript Nos últimos anos tem-se verificado uma crescente e acentuada adoção da linguagem

JavaScript, em grande parte, devido à disponibilização de bibliotecas robustas com suporte de

múltiplos browsers (cross-browser). Esta linguagem foi originalmente desenvolvida por Brendan

Eich para o extinto Netscape em 1995. A linguagem acabou por ser normalizada pela ECMA

International como ECMA 262, também conhecida como a norma ECMAScript39.

Com recurso a ferramentas de testes web referidas anteriormente é possível testar código

JavaScript, nomeadamente através da verificação da estrutura DOM ou verificação do resultado

consequente dos eventos realizados sob uma página web. Porém, este método é inadequado

porque a execução destes testes tende a ser lenta devido ao controlo e carregamento das páginas.

Além deste fator, a lógica de aplicações web do lado cliente nem sempre resultam na alteração do

aspeto visual da aplicação.

Partindo destes pressupostos a comunidade tem redirecionado esforços para criar

ferramentas que permitam dotar a linguagem com um ambiente de desenvolvimento focado na

construção de aplicações com maior qualidade [26]. Neste âmbito, foram examinadas as

ferramentas QUnit e Jasmine.

39 http://www.ecmascript.org/


57

QUnit

O QUnit40 baseia-se no conceito xUnit já referido anteriormente, popularizado pelo JUnit.

Trata-se de uma framework de testes JavaScript robusta e de fácil utilização, desenvolvida pela

equipa do jQuery. A maioria das frameworks de teste disponíveis atualmente para JavaScript

utiliza um TestRunner in-browser. Isto quer dizer que os testes têm de ser executados

internamente no browser através do carregamento de um ficheiro HTML que inclui o código a

testar, a framework de teste e os testes. Seguindo esta abordagem na Listagem 9 encontra-se a

implementação do ficheiro HTML qunitExample.html e o código referente a um teste

(qunitTests.js) sobre uma função que valida se um determinado valor é par (qunitPrototype.js).

Listagem 9 - Caso de teste simples QUnit

qunitExample.html <html>

<head>

<title>QUnit Prototype</title>

<link rel="stylesheet" href="qunit.css" type="text/css" media="screen" />

<script src="http://code.jquery.com/jquery-latest.js"></script>

<script type="text/javascript" src="qunit.js"></script>



<script type="text/javascript" src="qunitPrototype.js"></script>



<script type="text/javascript" src="qunitTests.js"></script>

</head>

<body>

<h1 id="qunit-header">QUnit simple example</h1>

<h2 id="qunit-banner"></h2>

<div id="qunit-testrunner-toolbar"></div>

<h2 id="qunit-userAgent"></h2>

<ol id="qunit-tests"></ol>

<div id="qunit-fixture">test markup, will be hidden</div>

</body>

</html>

qunitPrototype.js qunitTests.js

function isEven(val) {

return val % 2 === 0;

}

test('isEven()', function() {

ok(isEven(0), '0 é um número par');

ok(isEven(2), '2 é um número par');

ok(isEven(-4), '4 é um número par');

ok(!isEven(1), '1 é um número ímpar');

ok(!isEven(-7), '-7 é um número ímpar');

});

No ficheiro qunitTests.js pode-se observar a utilização de duas funções base da API do

QUnit, test e ok. Tal como o nome sugere, a primeira função adiciona um novo teste, enquanto ok é

uma função de asserção equivalente a assertTrue do JUnit, ou seja, o teste passa se o primeiro

argumento for verdadeiro (avaliado a true). A Figura 17 demonstra o ficheiro qunitExample.html

no browser Mozilla Firefox.

40 http://qunitjs.com/


58

Figura 17 – Resultado do teste QUnit

Através do output gerado é possível constatar instantaneamente que todos os testes foram

executados com sucesso. Junto ao título da página (“QUnit simple example”) encontram-se

dispostas as opções: noglobals e notrycatch. Ativando a primeira, o teste falha se foi introduzida

uma nova variável global (nova propriedade no objeto window), a segunda indica que os testes

não devem ser encapsulados num bloco try-catch. Depois da informação sobre o browser e

sistema utilizado, é mostrado o resultado de cada teste. É possível efetuar o drill-drown de cada

teste, de modo a visualizar qual o resultado de cada asserção constituinte.

A API fornecida pela framework é simples mas detém praticamente todas a funções

essenciais, nomeadamente a segmentação dos testes em grupos, funções de asserção básicas e

suporte a testes assíncronos (asyncTest).

Jasmine

O Jasmine41 é uma ferramenta de teste BDD para JavaScript que se diferencia por não

necessitar de especificar qualquer elemento HTML (QUnit necessita deste tipo de elementos para

apresentação de resultados dos testes). Após o download da aplicação para que esta fique apta a

funcionar, deve ser alterado o ficheiro SpecRunner.html de modo a incluir a aplicação a testar,

bem como os testes. Reutilizando o caso de teste exemplo QUnit, na Listagem 10 é demonstrada a

implementação para Jasmine.

Listagem 10 - Caso de teste simples Jasmine

SpecRunner.html […]



<script type="text/javascript" src="spec/specExample.js"></script>



<script type="text/javascript" src="src/jasmineExample.js"></script>

[…]

jasmineExample.js function isEven(val) {

41 http://pivotal.github.com/jasmine/


59

return val % 2 === 0;

}

specExample.js describe('Check pair number', function() {

it('0 é um número par', function() {

expect(isEven(0)).toBeTruthy();

});

it('2 é um número par', function() {

expect(isEven(2)).toBeTruthy();

});

it('-4 é um número par', function() {

expect(isEven(-4)).toBeTruthy();

});

it('1 é um número ímpar', function() {

expect(isEven(1)).not.toBeTruthy();

});

it('-7 é um número ímpar', function() {

expect(isEven(-7)).not.toBeTruthy();

});

});

Os testes Jasmine iniciam-se com a declaração de uma suite de testes (describe). Esta função

global aceita dois argumentos, um texto identificativo e a função que implementa a suite, que se

traduz num conjunto de specs. A spec é considerada a unidade principal da framework e é

definida através da função it.

Cada spec pode conter uma ou mais expetativas (expect) que representa o resultado esperado

de um determinado teste. Funções designadas de matchers têm o propósito de comparar os

resultados reais com os esperados, tal como toBeTruthy no exemplo acima.

Do ponto de vista arquitetural, apresenta uma extrema flexibilidade que permite ao próprio

programador de testes implementar a suite, spec e matchers, dado que estes são simplesmente

funções JavaScript. Na Figura 18 temos a expressão do resultado da execução do teste.

Figura 18 - Resultado do teste Jasmine

Tendo em conta a prevenção da duplicação de código, o Jasmine fornece as funções

beforeEach e afterEach que são executadas antes e depois de cada caso de teste. Para além disso,

possibilita a construção de testes com base em hierarquia de suites e definição de estruturas

equiparadas a Mocks que mantêm o número e conteúdo das invocações (spies). Os testes

assíncronos são garantidos pela função waitsFor, interrompendo a execução até que a condição

definida seja verdadeira.


60

Conclusão

Concluindo a análise de ferramentas com vista a criação e automatização de testes em

JavaScript, tanto o QUnit como o Jasmine apresentaram-se como opções viáveis. Porém, de uma

maneira geral, o Jasmine conseguiu cobrir todas as funcionalidades prestadas pelo QUnit e exibir

outras adicionais.

Nomeadamente o facto de ser extremamente flexível ao ponto de ser possível definir as

próprias funções de asserção (matchers). Em relação às suites de teste (describe) e specs como se

tratam de funções JavaScript, existe uma extrema liberdade para implementar o código de teste.

Outra vantagem da API fornecida é a facilitada a criação e interação com Mocks (Spies).

Tendo como base estas conclusões, o Jasmine foi a ferramenta de elaboração de testes

JavaScript adotada pela empresa.

Considerando vantagens e desvantagens de cada uma das ferramentas descritas nesta

secção (3.3) e tipos de projetos, foi feita a seleção de ferramentas mais adequadas para o

desenvolvimento de testes na empresa. As ferramentas escolhidas farão parte do Software Testing

Guide, cuja elaboração deste documento irá ser abordada no seguinte capítulo.

CAPÍTULO 4

61

4. CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES Inicialmente estava previsto a conceção de um processo de testes para inclusão no sistema

de integrado de gestão da Present Technologies, objeto de avaliação no âmbito da norma ISO

9001:2008. No entanto, após algumas reuniões com o departamento de gestão de qualidade (e

gestão de topo) da empresa e pesando os pontos a favor e contra, concluiu-se que o momento não

era oportuno para introdução de um processo desta natureza. A implementação das práticas e

objetivos de um processo rigoroso resultaria numa tarefa contraproducente para os recursos da

empresa, provocando entorpecimento inadequado no funcionamento diário da organização.

Posteriormente foi aceite por todos os intervenientes no estágio, a conveniente substituição

de um processo rigoroso pela elaboração de um guia de testes de software e melhoria do plano de

testes, agregando as recomendações e boas práticas atuais para o auxílio dos programadores nas

atividades de testes.

Neste capítulo é efetuada uma explicação sobre a elaboração do Software Testing Guide e

Test Plan Template, adiante designados de STG e TPT respetivamente, e o modo como foram

influenciados pela investigação apresentada nos capítulos 2 e 3. Os documentos STG e TPT

encontram-se nos Anexos C e D e devem ser encarados como complemento desta secção. Os

documentos foram redigidos em inglês por se tratar da língua adotada pela Present Technologies

para documentação interna.

4.1. Software Testing Guide Antes do desenvolvimento do STG foram discutidos os objetivos de negócio e necessidades

da organização para determinar a abordagem a considerar para esta tarefa. Foi delineada uma

política visando a missão da organização, as necessidades do cliente em relação aos produtos, a

validação dos produtos, a prevenção de defeitos, a redução do tempo de execução de testes e por

fim, tornar a qualidade dos produtos visível.

Apesar de estar prevista a implementação e execução de testes nos projetos desenvolvidos

pela empresa, estes não são abrangidos por uma base ou fundamento que os imponha. Neste

sentido a elaboração deste manual serviria para ajudar a Present Technologies a estabelecer um

processo de testes sustentado pelas melhores práticas e princípios existentes na literatura de

engenharia de software. A Figura 19 mostra o índice do documento STG.

CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES

62

Figura 19 - Índice do STG

O capítulo inicial do STG comunica o objetivo, a audiência, definições, referências e

estrutura do documento mencionado. Este documento inclui o detalhe de conceitos básicos de

testes de software que procuram enquadrar o leitor e criar uma linguagem franca que deve ser

utilizada para a partilha e debate de ideias sobre esta temática.

Qualquer processo de testes deve conter a definição de um conjunto de fases e seus

objetivos, e isto foi cumprido com a definição do novo ciclo de vida de testes detalhado no

capítulo 3 do STG (Figura 20).

Todas as atividades coexistem no ciclo de vida do desenvolvimento. Resumidamente o

ciclo de vida dos testes é composto pelas fases sequenciais de Planeamento, Desenho, Automação,

Execução e Avaliação. A fase de execução de testes de carga é opcional, ocorre apenas em

projetos que o justifiquem. Convém salientar que a fase de análise de defeitos encontra-se prevista

em qualquer fase do ciclo de desenvolvimento posterior à fase de implementação. As tarefas

constituintes de cada fase podem ser consultadas no Anexo A, contudo é apresentado um resumo

na Tabela 7.


63

Test Planning

Requirement Implementation / Engeneering

Test Execution

Validation ValidationAcceptance

Warranty Support and Maintenance

Test Design

Test Evaluation

Analyze issues

SRSStandards and templates

Software Testing HandbookTest tools information

Approved Test Plan

Test Case SpecificationTest Tools

Closed

Source Code

Test Tools

Test Documentation Completed

Regression Tests

Test Automation

Test Criteria

Test Design Error

Performance Test Execution

Test Metrics

Solution Delivered

Defect ReportedChange Requests

Test Report

Test Tools

SRS

Test Design Error

Figura 20 - Ciclo de vida de testes

Tabela 7 - Resumo das atividades do ciclo de vida dos testes

Tarefa Descrição

Testing Planning Nesta tarefa são tomadas as decisões que permitem definir quais os tipos e critérios de testes a adotar.

Test Design Esta secção inclui a especificação de casos de teste baseada nos critérios escolhidos na tarefa anterior.

Test Automation Consiste na produção de scripts dos testes unitários, integração e de sistema.

Test Execution Todos os testes são executados com os valores de entrada selecionados e são verificados os valores de saída de modo a comprovar o comportamento esperado do sistema.

Test Evaluation São avaliados os resultados de teste e aplicadas técnicas apropriadas para medir o nível de qualidade do produto.

Analyse Issues Os erros detetados são reportados aos programadores para correção e novo ciclo de testes.

A seleção de ferramentas de automatização de testes foi apoiada por algumas caraterísticas

fundamentais, tais como a diminuição do esforço implicado na implementação de testes e a

construção de testes úteis que retenham o seu valor durante a evolução do projeto. O diagrama da

Figura 21 apresenta as ferramentas eleitas e qual o seu contexto de atuação.

Durante o estudo, o TestNG revelou alguma superioridade em relação ao JUnit no que diz

respeito a termos funcionais, designadamente no suporte a testes dependentes e a um ciclo de vida

de teste com maior número de fases. No entanto, uma vez que as funcionalidades nucleares são

equiparadas e a integração com Arquillian é mais consistente, o JUnit foi a framework base de

testes escolhida pela Present Technologies.


64

Figura 21 - Ferramentas de teste selecionadas

Com base pesquisa efetuada, foi possível constatar que a combinação da ferramenta

Arquillian e as suas extensões Drone e Graphene representam uma solução completa para testes

interface web e in-container. Existem diversas vantagens, muitas delas, já referidas anteriormente

na secção 3.3.3 e estão associadas à gestão automática do container (inicialização/paragem) e de

ferramentas de teste web, o enriquecimento dos testes com CDI, a construção dinâmica do

arquivo alvo de teste e captura de resultados dos testes.

Apesar de ser recente, este conjunto de ferramentas já regista um elevado grau de adoção e

uma forte comunidade de suporte. A utilização do Selenium não deve ser descartada, pode ser

considerada como alternativa viável ou integrada com Arquillian/Drone/Graphene para testes

web.

Relativamente a testes do lado cliente, o Jasmine conseguiu exceder todas as

funcionalidades suportadas pelo QUnit. Esta ferramenta foi selecionada pela flexibilidade

demonstrada e API fornecida. Outra motivação para esta decisão deveu-se à existência do Jasmine

Maven Plugin42, que permite a execução dos testes Jasmine durante o ciclo de build do Maven.

No capítulo 5 são descritas as abordagens e técnicas principais para o desenho dos casos de

testes WUI. Estas devem ser utilizadas para definir o subconjunto de casos de teste e os scripts de

teste que deverão ser implementados e executados para garantir a conformidade da especificação

do sistema.

O documento STG termina com uma base onde são mantidos, recursos didáticos na web

cuja consulta é recomendada para atualização e aquisição de informação relevante sobre testes de

software.

4.2. Test Plan Template O processo de testes requer um planeamento cuidado e uma fase de preparação antes que

qualquer ação mensurável seja implementada. O esforço contabilizado nas tarefas de teste deve 42 http://searls.github.com/jasmine-maven-plugin/


65

ter em consideração os riscos e a decisão de quanto tempo e orçamento serão necessários para

reduzir o nível de incerteza em relação à qualidade do produto desenvolvido.

A pessoa encarregada da criação do plano de teste, para um determinado projeto, deve ter a

preocupação de que o mesmo também serve para facultar informação sobre o progresso e

qualidade destinada à gestão do projeto.

Não obstante a estes factos, em projetos de pequena dimensão pode ser exagerado aplicar

todas as boas práticas de testes. Assim, a estrutura do plano de testes deve ser moldada consoante

as necessidades e tipo de projeto, assegurando a realização de todas as tarefas essenciais.

Figura 22 - Índice do TPT

Os pontos cobertos pelo documento podem ser consultados no índice presente na Figura 22.

Principalmente baseado na norma IEEE 829-1983 ([29]) foi deliberado que o documento

produzido teria obrigatoriamente que retratar as seguintes a secções: Abordagem de teste,

Critérios de teste e Casos de teste. O preenchimento da Matriz de Rastreabilidade e Artefactos dos

testes seriam opcionalmente adicionados caso se justificasse.

A Abordagem de teste constitui a parte fulcral do documento, sendo definido o âmbito e

instrumentos para se proceder à realização dos testes. Inclui a determinação das funcionalidades a

testar, as que não devem ser testadas, quais os níveis de teste, ferramentas utilizadas e descrição

do ambiente utilizado para testes.

No TPT está contemplado um capítulo dedicado à especificação de critérios de cobertura a

utilizar no desenho de casos de teste. Estes critérios devem ser segmentados por cada nível de


66

teste escolhido. Deverão ficar explícitos os objetivos e requisitos de teste e níveis de cobertura

planeados.

A especificação dos casos de teste é efetuada num capítulo próprio para o efeito. Um caso

de teste é normalmente constituído por um conjunto de valores de entrada, condições de execução

de uma ou mais operações e resultados esperados ou valores de saída. O desenho dos casos de

teste e preparação dos dados de teste são atividades fundamentais no planeamento de testes. A

descrição tabelar dos casos de teste apenas deve ser elaborada para testes de sistema. Os únicos

campos obrigatórios são a descrição e o resultado esperado.

No capítulo Matriz de rastreabilidade é possível fazer o mapeamento entre os requisitos de

software e os casos de teste que o cobrem, visando a identificação precisa dos testes de regressão

a executar quando uma determinada funcionalidade foi alterada.

Para finalizar, na última secção do TPT consta a listagem de artefactos produzidos no

âmbito dos testes à aplicação.

4.3. Modelo de otimização TMMi Dos modelos de otimização do processo de testes listados em 3.1.2, o modelo TMMi foi

selecionado como o mais ajustado para orientar a criação da documentação referida por conter

simples e claras diretrizes para cada área relacionada com testes. Para além disso, tem-se

verificado uma crescente adoção deste modelo tanto no contexto empresarial como no contexto

académico.

O levantamento das ações essenciais para a melhoria do processo foi fundamentado nas

áreas de processo que precisavam de ser aperfeiçoadas na empresa.

Embora não seja completamente preciso, atualmente o processo informal em vigor na

empresa encontra-se entre o nível 1 e 2, sendo o objetivo deste estágio a consolidação do nível 2

(Controlado) de maturidade.

Partindo deste objetivo optou-se por adotar o modelo em V, apropriado para a metodologia

de desenvolvimento em Cascata (Waterfall), de uso recorrente na empresa. É facilmente

integrado, sem alterar ou perturbar o fluxo do processo de desenvolvimento e contempla a

introdução das atividades de teste logo no início do projeto. A aplicação do modelo em V no novo

o ciclo de vida de testes pode ser consultada na Figura 23.


67

Figura 23 - Mapeamento do processo de testes para nível 2 do TMMi

No diagrama da Figura 23 pode observar-se que o novo ciclo de vida de testes de software

proposto reflete todas as áreas de processo recomendadas pelo nível 2 (Controlado) do modelo de

otimização TMMi.

A fase do modelo em V planeamento sucede-se à fase de especificação de requisitos e é

onde se inicia a elaboração do documento do plano de testes. Esta fase e o documento STG

endereçam as formalidades de “Política e Estratégia de Testes” e o “Planeamento de Testes” do

modelo TMMi. As formalidades “Desenho e Execução de Testes” e “Ambiente de Testes” são

asseguradas pelas fases de desenho de testes, automatização de testes e pelo conjunto de fases

relativas à execução de testes (testes unitários, integração, sistemas e de carga) do modelo em V.

As fases de execução sucedem à fase de implementação do ciclo de desenvolvimento.

A fase de execução de testes de aceitação não é contemplada por ser considerada como

responsabilidade do domínio do cliente. Por fim, a formalidade “Monitoria e Controlo” prevista

no TMMi é abrangida nas fases transversais de análise de defeitos e avaliação dos testes do

modelo em V.

CAPÍTULO 5

68

5. CASO DE ESTUDO: PROJETO PORTAL B2B O Portal B2B é uma aplicação web baseada no padrão Java EE (Java Enterprise Edition)

concebida para a gestão de uma plataforma M2M. O seu objetivo é mediar funcionalidades como

gestão de clientes, perfis, utilizadores, dispositivos, contas de serviço, relatórios e alarmes.

5.1. Principais Conceitos Para melhor enquadrar o leitor na interpretação dos documentos desenvolvidos no âmbito

do estágio, são explicados de seguida uma série de conceitos do Portal B2B.

Cliente A entidade que adquire uma licença para utilizar a plataforma M2M.

Aplicação Vertical (silo vertical) Lógica de negócio alimentada por eventos provenientes dos dispositivos, com capacidade de gerar dados para compor indicadores, e atuar em dispositivos.

Dispositivo Mecanismo com capacidades de um sensor que pode também ser um atuador ou elemento que recebe comandos.

Capacidade de dispositivo

Funcionalidade básica do dispositivo utilizada ou não no serviço a disponibilizar na plataforma.

Alarme Evento significativo que pode conter um conjunto de notificações associado.

Alerta Notificação de um alarme ou de outro acontecimento. A notificação é uma mensagem enviada para informar um acontecimento, ou entregar informação de alertas ou relatórios.

Conta de serviço Associação de um utilizador consumidor a vários dispositivos no contexto de um cliente. Cada conta pertence a uma aplicação vertical.

Perfil de dispositivo Pertence à plataforma, e é um conjunto de privilégios de utilização do dispositivo.

Perfil de utilizador Pertence à plataforma, disponibiliza-se a um cliente e é um conjunto de privilégios de utilizador.

Relatório Conjunto de informações, utilizado para reportar resultados parciais ou totais de uma determinada atividade.

CASO DE ESTUDO: PROJETO PORTAL B2B

69

Utilizador É uma agente que utiliza serviços disponibilizados pela plataforma. Possui uma conta de utilizador.

Consumidor Capaz de efetuar login na plataforma, tem um perfil próprio e pertence ao consumidor.

Gestão Capaz de efetuar login na plataforma, tem um perfil próprio e pertence à gestão da plataforma. Entre outros, este utilizador pode por exemplo criar clientes.

Cliente Capaz de efetuar login na plataforma, tem um perfil próprio e pertence ao cliente. Entre outros, este utilizador tem a ele associado grupos de contas de serviço.

5.2. Descrição do projeto O Portal B2B visa a integração com um projeto realizado pela equipa de desenvolvimento

do Cliente, designado de Machine-To-Machine (M2M ou MTOM). Este projeto consiste numa

plataforma genérica de gestão de controlo de dispositivos remotos. O contexto deste projeto

implica a implementação e/ou integração de lógicas de negócio e extração de conhecimento

baseados nos dados recebidos e atuação sobre os dispositivos geridos. O objetivo da plataforma é

posicionar-se em dois segmentos de mercado: B2B (Business-to-Business) e B2C (Business-to-

Consumer).

Por vertente B2B entende-se que, o cliente principal típico deste género de plataforma é um

parceiro comercial interessado essencialmente em aplicações de Smart Metering. Por outro lado

na perspetiva B2C, os destinatários são os consumidores finais que acedem à plataforma para

efetuar consultas e operações sobre os seus dispositivos.

Tomando como referência a release 1.0.0 do Portal B2B, versão criada após a realização

dos testes de aceitação do Cliente, apresenta como principais funcionalidades as descritas na

Tabela 8.

Tabela 8 - Funcionalidades macro do Portal B2B

Portal Business Código Funcionalidade PB2B-001 Efetuar login de um utilizador do sistema

PB2B-002 Alterar credenciais de acesso de um utilizador

PB2B-003 Efetuar logout de um utilizador do sistema

PB2B-004 Recuperar as credenciais de acesso

PB2B-005 Gerir aprovisionamento de utilizadores do cliente (Adicionar/Listar/Detalhes/Editar/Remover)

PB2B-006 Listar o(s) perfis da plataforma

PB2B-007 Gerir notificações (Adicionar/Listar/Detalhes/Editar/Remover)

VA Location Código Funcionalidade


70

PB2B-008 Consultar relatórios

PB2B-009 Consultar relatório de histórico de eventos

PB2B-010 Consultar os dados mais recentes dos dispositivos

PB2B-011 Obter leitura de um dispositivo

PB2B-012 Obter conjunto de leituras de dispositivos

PB2B-013 Ativar/Desativar dispositivo

PB2B-014 Gerir dispositivos (Adicionar/Listar/Detalhes/Editar/Remover)

PB2B-015 Gerir grupos de dispositivos (Adicionar/Listar/Detalhes/Editar/Remover)

PB2B-016 Remover conjunto de dispositivos

PB2B-017 Gerir conta de serviço

PB2B-018 Ativar/descativar conta

PB2B-019 Gerir grupos de contas de serviço (Adicionar/Listar/Detalhes/Editar/Remover)

PB2B-020 Associar dispositivos a contas

PB2B-021 Visualizar os Relatórios

PB2B-022 Exposição de funcionalidades dos silos verticais

PB2B-023 Gerir alarmística (Adicionar/Listar/Detalhes/Editar/Remover alarmes)

5.3. Arquitetura A Figura 24 mostra um diagrama de deployment dos vários artefactos do projeto. A equipa

da Present Technologies envolvida no projeto foi incumbida de desenhar e implementar três

aplicações web (WAR): Portal O&M; Portal Business e Portal VA Location (no servidor

aplicacional esquerdo).

Application server

PortalO&M.war

Deployment diagram

PortalBusiness.war VALocation.war

Mtom-core-client.jar

Mtom-sdb-client.jarMtom-va-location-

client.jar

Application server

Mtom-sdb.jar

Mtom-sdb-location.jar

Remote interface

(JSR 177)

Figura 24 – Diagrama de deployment do projeto

O Portal B2B, representativo do âmbito deste estágio, quer na vertente de desenvolvimento,

quer na vertente de aplicação do procedimento de teste, é na realidade composto pelos

componentes Portal Business e Portal VA Location (Figura 25).


71

Figura 25 - Composição do Portal B2B

Ainda na Figura 24 temos os serviços disponibilizados pela plataforma M2M através do

componente Service Delivery Broker (mtom-sdb e mtom-sdb-location), constantes no servidor

aplicacional apresentado no lado direito da figura. A equipa de desenvolvimento do Cliente foi

responsável pelo desenho e implementação destes serviços.

O componente Service Delivery Broker diz respeito a um conjunto de APIs que recorre ao

mecanismo Remote Interface JEE2 sobre o servidor aplicacional JBoss 6.0, para permitir deste

modo a comunicação com serviços que se encontrem alojados num servidor aplicacional remoto.

A arquitetura estabelecida possibilita a inserção de novas lógicas de negócio, tendo em

consideração a constante evolução dos serviços. Garante-se ainda a segurança de toda a

informação envolvida assim como a escalabilidade, grande disponibilidade e performance.

A aplicação vertical Localização (VA Location) surge no contexto de prova de conceito

para comprovar a extensibilidade e escalabilidade da solução. Esta aplicação disponibiliza

automaticamente funcionalidades de georreferenciação sobre os dispositivos geridos.

5.4. Tecnologias O desenvolvimento dos componentes da plataforma foram maioritariamente

implementados em Java EE e Stripes. De seguida, mencionam-se as principais tecnologias que

caraterizam o Portal B2B e com as quais o estagiário teve contato.

5.4.1. Java EE A plataforma Java EE43 é bastante utilizada para a programação de servidores em Java,

possuindo funcionalidades de tolerância a falhas e de criação de software para sistemas

distribuídos e multicamada, baseada em componentes modulares que correm num servidor

aplicacional. Esta plataforma inclui a especificação de API’s como o JDBC, JMS, WebServices e

define como os coordenar. Também inclui funcionalidades únicas como EJB, Servlets, JSP, entre

outras. Destaca-se a utilização de uma funcionalidade recente da especificação Servlets 3.0, que se

prende com Web Module Deployment Descriptor Fragments. Com os Web Fragments (web-

fragment.xml) todo ou apenas parte da configuração do ficheiro web.xml pode ser guardada

diretamente num JAR ou na pasta META-INF da aplicação.

43 http://www.oracle.com/technetwork/java/javaee/overview/index.html


72

5.4.2. JBoss Um dos servidores aplicacionais baseados em Java EE é o JBoss Application Server44. A

sua base Java permite-lhe o correto funcionamento em qualquer plataforma que a suporte. A

versão utilizada deste servidor foi 6.0.0, que disponibiliza todas as funcionalidades da plataforma

Java EE 6, para além de serviços adicionais de clustering, load balancing, persistência e

integração com JMS (Java Message Service). O módulo JAAS (Java Authentication and

Authorization Service) foi usado para implementar um mecanismo transversal de autenticação e

autorização da aplicação.

O plugin Java EE Cache Filter45 providencia um conjunto de Servlets que permitem

definir, de modo transparente, headers HTTP para ativar/desativar a cache dos browsers.

Para registo das operações e eventos realizados durante o exercício da aplicação foi

utilizada a framework de logging SLF4j (Simple Logging Facade for Java).

5.4.3. Stripes Web Framework Stripes46 é uma framework de desenvolvimento de web MVC e incide maioritariamente nos

componentes Controlador e Vista. Esta ferramenta é focada para a construção da lógica de

apresentação das aplicações web. Possui as funcionalidades que permitem a associação inteligente

entre parâmetros e eventos do URL para Java, autoloading das classes Stripes sem necessidade de

configuração XML, validação com base num mecanismo de anotações, internacionalização,

tratamento de erros, interceptors e fácil integração com AJAX. No fundo é uma framework

orientada à ação e destaca-se pela minimização de configuração exigida para executar aplicação

web.

5.4.4. Sitemesh Para o layout e template das páginas constituintes da aplicação foi utilizada a framework

Sitemesh 47. É leve, flexível e baseia-se no padrão de desenho decorator que permite uma clara

separação entre o conteúdo e a apresentação, permitindo a repetição automática de

blocos/fragmentos nas diversas páginas.

44 http://www.jboss.org/jbossas/ 45 http://code.google.com/p/cache-filter/ 46 http://www.stripesframework.org/display/stripes/Home 47 http://wiki.sitemesh.org/display/sitemesh/Home


73

5.4.5. JQuery No que diz respeito a implementação em JavaScript, foi aplicada a framework jQuery48. Os

múltiplos fatores considerados para a utilização desta biblioteca foram a compatibilidade multi-

browser, seletores CSS3, funções utilitárias, fácil acesso ao DOM, animações e jQuery UI que

disponibiliza gratuitamente um conjunto de componentes gráficos prontos a utilizar.

5.4.6. HTML5 e CSS3 O HTML5 e CSS3 introduzem novas funcionalidades que são necessárias para aplicações

web modernas e que podem beneficiar os programadores e utilizadores da Internet. Estes novos

standards incorporam funcionalidades que antes, apenas eram possíveis com recurso a plugins

nos browsers, tal como a reprodução nativa de vídeo e a funcionalidade de drag-and-drop.

5.5. Metodologia de desenvolvimento Esta secção surge com o intuito de se descrever a metodologia utilizada no projeto. Este

processo de produção tem o objetivo de desenvolver sistemas. É constituído por várias atividades

e contempla o modelo de desenvolvimento clássico em Cascata e Iterativo.

Tendo como base este processo, o projeto adotou o modelo em Cascata, o mais adequado às

suas caraterísticas, onde o conhecimento inicial dos requisitos era elevado e não era previsível a

existência de alterações. Este modelo traduziu-se num único ciclo iniciado com o planeamento,

seguida das fases de especificação de requisitos, implementação, validação e aceitação. Este ciclo

encontra-se representado na Figura 26.

Figura 26 - Ciclo de vida em Cascata

5.5.1. Planeamento e Especificação de requisitos A fase de planeamento diz respeito à primeira fase do processo de desenvolvimento, após

solicitação de um produto por parte de um cliente. É nesta fase que a Especificação de Requisitos

de Software começa a ganhar forma, documento fundamental para se conhecer o que se vai

implementar e qual o resultado esperado.

48 http://jquery.com/


74

A listagem de requisitos do projeto Portal B2B pode ser consultada no complemento Anexo

C, encontrando-se expostos apenas os relevantes para apresentação deste trabalho.

5.5.2. Implementação A atividade de implementação compreendeu a análise e o desenho do sistema, com o

objetivo de se evidenciar a arquitetura adotada e a solução concebida, a desenvolver na fase de

construção. Do trabalho efetuado pelo estagiário saiu como produto, os artefactos de software

referentes às aplicações web já mencionadas.

Durante esta fase, foram desenvolvidos os componentes que respondem à arquitetura

definida e aos requisitos especificados. O produto obtido no final desta fase foi, em parceria com

a equipa de desenvolvimento do Cliente, todos os componentes constituintes da plataforma M2M.

5.5.3. Validação Após a fase de construção foram efetuados testes por parte do Cliente aos componentes

desenvolvidos, de modo a garantir que os requisitos foram cumpridos e que o funcionamento da

plataforma foi o desejado. Nesta fase, foi elaborado um documento de Especificação de Casos de

teste com a estrutura até então em vigor na empresa.

Durante esta fase, os testes foram executadas manualmente, de forma a encontrar falhas

e/ou defeitos de funcionalidades e de conteúdos. Terminada a fase de validação, o produto foi

entregue ao Cliente para que fossem realizados os testes de aceitação.

5.5.4. Aceitação Uma vez disponibilizado o produto para aceitação, foram realizados testes que visavam

demonstrar que o sistema entregue e instalado de raiz satisfazia os objetivos iniciais de negócio.

A correta implementação dos requisitos e funcionalidades esperadas, de acordo com a

especificação de requisitos de utilizador, foi verificada no ambiente de sistema do Cliente. A

divulgação dos erros detetados, para futura correção da parte da equipa de desenvolvimento da

Present Technologies, traduziu-se numa tarefa da responsabilidade do Cliente.

5.6. Responsabilidades Tal como referido anteriormente, as tarefas realizadas pelo estagiário no contexto do

desenvolvimento do projeto Portal B2B compreendem a implementação da camada de

apresentação, realização de testes de validação e posterior elaboração do manual de utilizador. No

decurso destas atividades, o estagiário foi-se especializando no conhecimento das ferramentas de

desenvolvimento de aplicações Java aplicadas pela empresa.


75

5.7. Ferramentas de apoio A gestão do projeto foi realizada através das ferramentas web de gestão de projetos

Confluence e JIRA da Atlassian49. Estas ferramentas foram disponibilizadas a partir do domínio

do Cliente, sendo o seu acesso remoto efetuado através de uma rede VPN. Este recurso

possibilitou:

Consulta de uma Wiki dedicada ao projeto que possibilitou a partilha de conhecimento en-

tre todos os intervenientes do projeto;

Gestão de tarefas viabilizando assim os pedidos feitos pelas duas equipas;

Visualização e perceção do planeamento, milestones e evolução do projeto.

Com o objetivo de evitar problemas adjacentes ao desenvolvimento das duas equipas em

paralelo, foi utilizado o sistema de controlo de versões SVN, que para além de possibilitar a

sincronização de versões de ficheiros, mantém um histórico de todas essas versões.

Para a automatização do processo de construção do software foi utilizada a ferramenta

Apache Maven50. O processo de construção e as dependências do projeto são definidos num

ficheiro XML, o que facilita a utilização de módulos desenvolvidos pelas equipas envolventes, de

uma forma automática e organizada.

A principal ferramenta de desenvolvimento foi o Eclipse IDE, amplamente utilizado para

projetos Java e possui uma vasta gama de plugins para o auxiliar os programadores durante a fase

de implementação. Por exemplo, a persistência do código e controlo de versões foi feito com

recurso ao plugin SVN.

49 http://www.atlassian.com/ 50 http://maven.apache.org/

CAPÍTULO 6

76

6. APLICAÇÃO DO NOVO PROCEDIMENTO DE TESTES Este capítulo fornece uma descrição da aplicação do procedimento de testes, inserido no

documento STG e conceção do plano de testes para o Portal B2B. Para a realização dos testes,

foram consideradas as seguintes atividades: Planeamento, Desenho, Automatização, Execução e

Avaliação dos testes.

De notar que, esta metodologia de testes foi aplicada ao projeto após a sua conclusão e

aceitação pelo Cliente, devendo o teor deste capítulo ser entendido como exemplo piloto e prova

de eficácia do processo proposto.

6.1. Planeamento O intuito desta fase consistiu em deliberar a estratégia de testes a adotar, requisitos de teste,

especificação de casos de teste e outros aspetos relevantes. A informação deveria, sem exceção,

constar no documento referente ao plano de testes do projeto. Para se ter melhor perceção de

quais os dados envolvidos, pode ser consultado o Anexo D.

A estratégia delineada, especificou que deveria ser criado de pelo menos um caso de teste

referente a cada uma das categorias expostas na secção 3.2.3. Esta decisão foi efetuada pesando o

esforço e tempo para a realização dos testes, por forma a extrair conhecimento suficiente da

qualidade do sistema.

6.2. Desenho A especificação de testes teve como objetivo definir o seu domínio, garantir a qualidade do

produto construído e que este cumprisse os requisitos definidos. Foram especificados testes de

sistema, procurando verificar o comportamento do sistema desenvolvido, como um todo. Apenas

foi verificada a satisfação dos requisitos funcionais expostos pela interface web, não tendo sido

abordados aspetos de usabilidade ou de desempenho. Todos os testes executados estão definidos

no Anexo D. Nas subsecções seguintes, são demonstrados os testes considerados e técnicas que

permitiram a seleção de casos de testes.

6.2.1 Testes de Navegação Os testes de navegação implementados recaíram apenas sobre o componente Portal

Business. Foi aplicado um critério cobrindo uma estrutura em grafo, do mapa do site da aplicação

Portal Business, previsto no método Model-Driven Test Design.

APLICAÇÃO DO NOVO PROCEDIMENTO

77

Figura 27 - Grafo referente à navegação do Portal Business

Cada nó do grafo constante na Figura 27 representa uma página. As transições entre

páginas, possibilitados por eventos ou links, são representadas pelas ligações entre nós. Da página

inicial de autenticação (nó 1), o utilizador pode navegar para a página inicial (nó 2), caso

introduza corretamente as credenciais. Caso contrário, manter-se-á na mesma página com

informação de valores incorretos.

Uma vez na página inicial, o utilizador tem à sua disposição quatro áreas: “Minha conta”;

área de gestão de Utilizadores; área de gestão de Perfis e área de gestão de Notificações. O acesso

ao componente VA Location encontra-se representado através da ligação entre o nó 1 e o nó 7.

Observando o grafo presente na Figura 27, facilmente se percebe que a área de gestão de

Utilizadores possibilita as operações de CRUD (Create/Read/Update/Delete) sobre a entidade

Utilizador. Por outro lado, as restantes áreas disponibilizam apenas consulta de informação. Dada

a complexidade das transições possíveis entre páginas, para nós finais foram consideradas páginas

onde não era possível transitar para uma nova (nós 8,9,10 e 11). Traduzindo o grafo formalmente

em expressões, temos:

𝑁 = {1,2,3,4,5,6,7,8,9,10,11} (𝑁ó𝑠)

𝑁0 = 1 (𝑁Ó 𝑖𝑛𝑖𝑐𝑖𝑎𝑙); 𝑁𝑓 = {7,8,9,10,11}(𝑁Ó𝑠 𝑓𝑖𝑛𝑎𝑖𝑠)

Posteriormente foi escolhido o critério Edge-Coverage (Model-Driven Design Test). Este

critério define como requisitos de teste, a visita de todas as transições compostas por um ou mais


78

nós. As razões que levaram à escolha deste critério foram a sua simplicidade, eficácia e

recomendação [16]. Na prática, o conjunto de casos de teste teve de incluir todas as transições

previstas no grafo. Assim sendo, todos os requisitos de teste podem ser traduzidos pela seguinte

expressão:

𝑇𝑅 = {(1,2), (2,3), (2,4), (2,5), (2,6), (2,7), (4,9), (4,10), (4,11), (5,8), (3,4), (4,3), (4,5), (5,4), (5,6), (6,5)}

Um caminho de teste, isto é, um caminho que começa num nó inicial e termina no nó final

representa um caso de teste. Os casos de teste são apresentados na Tabela 9.

Tabela 9 - Casos de teste Navegação resultantes do critério Edge-Coverage

Casos de Teste Navegação – Edge Coverage Teste Caminho Descrição do Caso de teste TestB2B-001 [1,2,7] Navegar para a página inicial de Aplicação Vertical Localização através da página

inicial do Portal Business. TestB2B-002 [1,2,4,10] Navegar para a página de Detalhe de utilizador através da página inicial do Portal

Business. TestB2B-003 [1,2,4,11] Navegar para a página de Edição de utilizador através da página inicial do Portal

Business. TestB2B-004 [1,2,3,4,9] Navegar para a página de Adição de utilizador após área “Minha conta”. TestB2B-005 [1,2,5,4,9] Navegar para a página de Adição de utilizador após área de Perfis. TestB2B-006 [1,2,4,5,8] Navegar para a página de Detalhe de perfil após área de Utilizadores. TestB2B-007 [1,2,6,5,8] Navegar para a página de Detalhe de perfil após área de Notificações. TestB2B-008 [1,2,4,3,4,9] Navegar para a página de Adição de utilizador após round-trip na área “Minha

conta”. TestB2B-009 [1,2,5,6,5,8] Navegar para a página de Detalhe de perfil após round-trip na área de Notificações.

6.2.3. Testes de Validação de entradas Estes testes foram realizados de acordo com a técnica Input Space Partitioning,

anteriormente apresentada no tópico 3.2.4 (Model-Driven Test Design). Neste sentido, é

apresentado um exemplo de aplicação da técnica, tendo como objetivo explicar como se processa.

Os casos de teste incidem na funcionalidade que possibilita a edição de um Utilizador, incluída na

funcionalidade macro PB2B-005 da Tabela 8.

Numa primeira fase foram identificadas todas as entradas da funcionalidade escolhida. Para

este efeito, na Figura 28 é apresentado um screenshot da página que reflete a operação

mencionada. A edição de um Utilizador é possibilitada através de um Wizard, ou seja, o

formulário para alteração da informação está dividido por passos que facilitam o seu

preenchimento. Por questões de confidencialidade, foram retiradas todas as imagens, logótipos ou

marcas registadas que possibilitassem a identificação do Cliente.


79

Figura 28 - Passo 1 e 2 do wizard de edição de Utilizador

Através da Figura 28 facilmente se identifica o seguinte conjunto de entradas: Nome;

Estado; Descrição; Email; Telemóvel; Telefone; Perfil; Grupo de dispositivo. Depois da

identificação das entradas, foi modelado o domínio de entradas. Esta tarefa consiste no

particionamento de cada entrada num conjunto de blocos. Cada um destes blocos representa um

conjunto de valores possíveis para uma determinada entrada. Os blocos são determinados tendo

em conta uma caraterística da respetiva entrada.

Convém referir que não foram propostos valores superiores a 127 e 14 nos campos Nome

Telefone respetivamente, porque a própria interface de utilizador impõe esses limites através do

atributo “maxLength”. Por fim, tendo em vista a criação de casos de testes, foi aplicado o critério

Each-Choice. Este critério determina que pelo menos um valor de um bloco seja contemplado por


80

um teste. Visualizando a Tabela 10, facilmente se percebe que o número de caso de testes

resultante da aplicação deste critério é igual ao número de blocos da maior caraterística.

Tabela 10 - Input Space Partitioning da operação Edição de Utilizador

Input Space Partitioning Entrada Caraterística Bloco 1 Bloco 2 Bloco 3 Bloco 4 Nome Tamanho (Nº de carateres) 0 >0 e <127 127

Login Tamanho (Nº de carateres) 0 >0 e <8 >8

Estado Opções possíveis Ativo Inativo

Descrição Tamanho (Nº de carateres) 0 1 >1 e <512 >512

Email Tamanho domínio (Nº de carateres) Inválido Válido

Telemóvel Posicionamento do sinal “+” 0 >0

Telefone Tamanho (Número de dígitos) 0 >0 e <14 14

Perfil Opções possíveis Admin Management

Profile

profile

Grupo Opções possíveis Grupo de

dispositivos

Assim, os casos de testes selecionados são:

TestB2B10 = (Nome:[0]; Login:[0]; Estado:[Activo]; Descriçao:[0]; Email:[inválido]; Telemovel:[0];

Telefone:[0]; Perfil:[Admin Management Profile]; Gupo:[Grupo de dispositivos]);

TestB2B11 = (Nome:[>0 e <127]; Login:[>0 e <8]; Estado:[Inactivo]; Descriçao:[1]; Email:[válido];

Telemovel:[ >0]; Telefone:[ >0 e <14]; Perfil:[profile]; Gupo:[Grupo de dispositivos]);

TestB2B12 = (Nome:[127]; Login:[>8]; Estado:[ Activo]; Descriçao:[ >1 e <512]; Email: [inválido];

Telemovel:[0]; Telefone:[14]; Perfil:[Admin Management Profile]; Gupo:[Grupo de dispositivos]);

TestB2B13 = (Nome:[0]; Login:[0]; Estado:[Ativo]; Descrição:[>512]; Email:[válido]; Telemóvel:[0];

Telefone:[0]; Perfil:[Admin Management Profile]; Grupo:[Grupo de dispositivos]);

6.2.4. Testes da estrutura HTML e CSS Nesta secção é apresentada uma técnica para testar a estrutura HTML e regras de CSS

aplicadas a um elemento de uma página da aplicação. Ao contrário das secções anteriores, neste

caso não é apresentado um critério formal, mas sim, uma solução possível para este tipo de teste

com a aplicação Graphene. No cabeçalho da página inicial do Portal Business encontra-se uma

dropdown que, ao ser pressionada, apresenta as possíveis aplicações verticais, às quais o

utilizador pode aceder. A Figura 29 ilustra os três estados que elemento pode exibir.

Figura 29 - Estados da dropdown de seleção de Aplicação Vertical

Com base nesta máquina de estado é possível extrair três casos de teste correspondente a

cada transição de estado. Assim sendo, os testes resultantes são:


81

Tabela 11 - Casos de teste de transição de estado

Teste Estado inicial Evento Estado final TestB2B14 Dropdown fechada

(imagem de fundo bgDropdown0.png) click() Dropdown aberta

(cor de fundo #333333) TestB2B15 Dropdown aberta

(cor de fundo #333333) mouseOver() Dropdown aberta

(cor de fundo #0099AB) TestB2B16 Dropdown aberta

(cor de fundo #333333) click() Dropdown fechada

(imagem de fundo bgDropdown0.png)

Os testes presentes na Tabela 11 são possíveis através dos seguintes métodos

disponibilizados pelo Graphene:

click – simula o evento clique do rato sobre um elemento específico. mouseOver – simula o evento sobreposição (hover) do rato sobre um elemento

específico. mouseOut – simula o evento de retirada do rato sobre um elemento específico.

O Graphene suporta ainda a ação de drag-and-drop, evento que possibilita mover um

elemento HTML de uma posição para outra na página. Este método da API permite testar fases

particulares deste evento, como por exemplo start, mouseOut, move, enter e drop.

6.2.5. Testes AJAX Em quase todas as interações com uma aplicação a testar, existe a necessidade de aguardar

pela finalização de certas ações. Por exemplo, aguardar por uma reação despoletada por uma

interação assíncrona por parte do utilizador numa determinada página.

Com o Graphene é possível assegurar que a próxima interação não inicie antes que a

anterior tenha sido completamente finalizada. No exemplo da Listagem 11, o teste é suspenso até

que uma determinada condição se encontre satisfeita (elementPresent.locator(textCount)).

Listagem 11 - Mecanismo de Wait do Graphene com timeout

Wait Wait.waitSelenium.timeout(60000).interval(1500).until(elementPresent.locator(textCount));

A instrução anterior indica que, em intervalos de 1,5 segundos, é testada a presença do

elemento identificado com a referência textCount. Se a condição não é satisfeita após 60

segundos, é gerada uma exceção de timeout.

Este mecanismo é extremamente útil para testes a comunicações assíncronas, que resultam

em alterações ao DOM, providenciadas pelo AJAX. De modo similar ao anterior, é

disponibilizado também o método demonstrado na Listagem 12 para aguardar que o texto contido

num determinado elemento seja o esperado.


82

Listagem 12 - Mecanismo de Wait apropriado para invocações AJAX

Wait

waitAjax.until(countEquals.text("1"));

6.3. Automatização e Execução O processo de automatização dos testes consistiu na utilização de software para controlar a

execução dos testes, comparação entre as respostas obtidas dos testes de sistema e os resultados

esperados. Também foram contempladas as funções para estabelecimento das condições de

realização dos testes e outras funções de controlo e limpeza dos mesmos. Esta é a única forma de

possuir um processo eficaz de testes de regressão. Como se tratam de tarefas repetitivas, são

ideais para serem automatizadas em vez de serem realizadas por humanos.

Deste modo, depois de se definir e escrever um teste para a aplicação, o fluxo de execução

adotado é demonstrado na Figura 30.

Figura 30 - Testes automáticos Portal B2B

Para cada página da aplicação envolvida em testes foi criado um Page Object que continha

as respetivas funcionalidades (1). Depois deste mapeamento, para cada teste foi declarado o

resultado esperado, definidas condições iniciais, condições finais e operações de Page Objects

necessários (2). Neste projeto foi utilizado o conjunto de ferramentas Arquillian, incluindo Drone

(modo cliente) e Graphene, para implementar o código dos testes automáticos (3). Por fim, a

execução dos testes e consequente emissão do relatório sucesso/falha foi realizada pela ferramenta

Maven, através do plugin Failsafe (4). A Figura 31 mostra um diagrama que exemplifica as

interações entre Page Objects através dos seus serviços.

Verificou-se que a implementação dos casos de teste automáticos através das ferramentas

Arquillian/Drone/Graphene foi simples e prática, concluindo-se que estas são uma ótima solução

para testes de interface web. Possibilitam a produção de scripts de teste de elevada qualidade

capazes de poderem serem mantidos e reutilizados, caraterísticas importantes para obter sucesso

na automatização.


83

De notar, que previamente foram instalados os browsers Mozilla Firefox, Google Chrome e

MS Internet Explorer 9.0 no ambiente de testes. Para viabilizar a execução de todos os testes nos

browsers especificados, foi necessário alterar o parâmetro de configuração no ficheiro

arquillian.xml. Este ficheiro de configuração é demonstrado na Listagem 13.

Figura 31 - Exemplo de interações com os Page Ojects

Listagem 13 - Configuração de browsers para executar testes no Arquillian

Arquillian.xml <?xml version="1.0" encoding="UTF-8"?> <arquillian xmlns="http://jboss.com/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian-1.0.xsd"> <extension qualifier="webdriver"> <property name="browserCapabilities">firefox</property> <property name="browserCapabilities">internetExplorer</property> <property name="browserCapabilities">chrome</property> <property name="browserCapabilities">opera</property> <property name="browserCapabilities">htmlUnit</property> <property name="remoteReusable">true</property> <property name="remoteAddress">http://localhost:4444/wd/hub/</property> <property name="javascriptEnabled">true</property>  <property name="chromeDriverBinary">…\chromedriver.exe</property> </extension> </arquillian>

A Figura 32 demonstra a execução automática de um teste nos browsers MS Internet

Explorer 9.0 e Google Chrome.

Tomando como exemplo o teste de navegação TestB2B-001, na Listagem 14 é ilustrada a

composição típica de um script de teste Arquillian/Drone/Graphene utilizando o Selenium 2

(WebDriver) como controlador do browser para teste.


84

Figura 32 - Execução automática de testes nos browsers IE e Chrome

Listagem 14 - Exemplo de teste automático Arquillian/Drone/Graphene

TestB2B-001 @RunWith(Arquillian.class) @Category({ NavigationTests.class }) public class NavigationTestsIT { @Drone private WebDriver browser; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private VALocationPage vaLocationPage; private void loadAndLogin() throws MalformedURLException { URL applicationURL = new URL("http://localhost:8080/mtom-pn"); browser.navigate().to(applicationURL); assertEquals(ResourcesSingleton.INSTANCE.getResource("login.title"), browser.getTitle()); loginPage.loginAs("admin", "portaladmin1"); assertEquals(ResourcesSingleton.INSTANCE.getResource("home.title"), browser.getTitle()); } /** * B2B-001 * * @throws MalformedURLException */ @Test @InSequence(0) public void testB2B001() throws MalformedURLException { loadAndLogin(); homePage.navigateToVALocation(); assertEquals("Dispositivos", browser.getTitle()); vaLocationPage.goBackToPortalBusiness(); assertEquals(ResourcesSingleton.INSTANCE.getResource("home.title"), browser.getTitle()); }

Exemplo de Page Object (HomePage) public class HomePage extends PortalB2BPage {

Indica ao Drone que é utilizado o Selenium 2 (WD) como framework de testes web

Indica que o objeto vaLocationPage é um Page Object

Utiliza o WebDriver para obter a página inicial da aplicação e utiliza o “serviço” loginAs do Page Object loginPage

Utilização dos “serviços” navigateToVaLocation e goBackToPortalBusiness durante o teste


85

@FindBy(css = "#clientUserMenu a") private WebElement clientUserMenuTab; @FindBy(css = "#notificationMenu a") private WebElement notificationMenuTab; @FindBy(css = "#userProfileMenu a") private WebElement profileMenuTab; @FindBy(css = "a div.applicationLogo img") private WebElement vaLocationLink; @FindBy(css = "div.dropDownContainer") private WebElement vaDropdown; @FindBy(css = "div.dropDownContainer button") private WebElement buttonVaDropdown; // getters and setters public void navigateToVALocation() { guardHttp(vaLocationLink).click(); waitModel().until((element(By.tagName("h1")).textContains("Dispositivos"))); }

}

6.4. Avaliação e resultados Devido aos constrangimentos provocados pelo tempo e esforço dedicado, não foi

implementado um conjunto exaustivo de casos de teste. Neste sentido, o principal objetivo passou

por exercitar um pequeno conjunto de casos de teste cobrindo as categorias de navegação,

validação de entradas e transição de estados de um elemento HTML.

O relatório de resultado dos testes foi automaticamente emitido plugin do JUnit no Eclipse,

que assegurou a proteção do sistema contra estados considerados erróneos ou que pudessem

prejudicar o seu correto funcionamento (Figura 33).

Exemplo de localização de um elemento HTML da página, neste caso o link que redireciona para a página da VA Location

Exemplo de “serviço” navegar para página VA Location


86

Figura 33 - Resultado dos testes implementados

No decorrer do processo, a identificação de defeitos não foi considerada prioritária, uma

vez que a versão escolhida do software se referia a uma versão estável, tendo já passado por

anteriores fases de validação interna e externa (testes de aceitação). Devido a este facto, não foi

detetado nenhum erro na interface web da aplicação.

Tomando como base as experiências realizadas durante a automatização dos testes

concluiu-se que ocorreu uma redução de cerca de 96,94% de esforço na execução dos testes. Se

cada caso de teste implementado for executado manualmente, pode demorar mais de 1 minuto.

Isto porque é exigida a atenção visual da pessoa que realiza o teste e a utilização de um debugger

ao estilo do firebug51 para percecionar algum problema na interface gráfico. Por outro lado, os

testes automáticos tiveram uma duração total de 29,34 segundos. Esta poupança pode ser

comprovada com o seguinte cálculo:

𝑃𝑜𝑢𝑝𝑎𝑛ç𝑎 𝑑𝑒 𝑒𝑠𝑓𝑜𝑟ç𝑜 = 100% − 29,34 ∗ 100

960 (60 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 𝑥 16 𝑡𝑒𝑠𝑡𝑒𝑠)% = 𝟗𝟔, 𝟗𝟒%

Apesar desta significativa redução, não é contabilizado o tempo inicialmente é gasto na

construção dos page objects. Porém após este lento início, a situação é invertida na manutenção

de antigos e conceção de novos testes.

O critério de cobertura através de grafo sem repetições de páginas acabou por apresentar

um número aceitável de casos de teste a implementar. Outro dos fatores que beneficiam o critério

utilizado, deve-se à sua fácil compreensão.

51 http://getfirebug.com/


87

Relativamente à aplicação do critério Each-Choice do Input Space Domain, resultou numa

mais valia porque introduziu nos testes, o conhecimento do domínio e da especificação dos

requisitos do sistema. Revelou-se bastante útil na identificação de possíveis erros relacionados

com os tipos dos parâmetros envolvidos no módulo em teste. No entanto, futuramente devem ser

avaliadas alternativas a este critério, de forma a acrescentar também o teste de relacionamento

entre os valores a testar.

Não foi possível apurar os impactos que teriam sido provocados pela aplicação do

procedimento de testes durante o desenvolvimento de um projeto, dado que esta experiência

tratou-se de um ensaio realizado após a conceção do produto final.

Contudo, a sequência de fases do ciclo de testes proposto no procedimento, revelou um

caminho sequencial apropriado e produtivo para testes web.

CAPÍTULO 7

88

7. CONCLUSÕES

Este capítulo expõe uma análise ao estudo e experiência realizada para assegurar a eficácia

e viabilidade da implementação do procedimento de testes. De seguida, apresentam-se algumas

dificuldades sentidas durante o desenvolvimento da dissertação. O capítulo termina com uma

abordagem ao trabalho futuro para melhorar o procedimento e implementação de testes na

organização.

7.1. Revisão do trabalho realizado Neste documento foi apresentada uma solução formal e capaz para o desenvolvimento e

implementação de testes web adequada às necessidades da Present Technologies. A título

conclusivo, é apresentada na Figura 34 uma visão dos principais contributos do trabalho do

estagiário, para o Portal B2B e para a Present Technologies.

Na parte superior da figura, encontram-se dispostas as tarefas em que os principais

produtos foram os documentos constituintes da proposta de procedimento de testes elaborada

(Capítulo 4), e na parte inferior estão representadas as tarefas relacionadas com a implementação

da interface gráfico web da aplicação Portal B2B (Capítulo 5).

Numa segunda fase, as saídas resultantes destas duas tarefas foram combinadas numa, que

consistiu na aplicação do procedimento de testes ao Portal B2B, no sentido de comprovar o real

valor do conjunto de regulamentos propostos nos documentos STG e TPT. Como resultado

adicional, a qualidade da aplicação PortalB2B foi corroborada pelos resultados dos testes

concebidos durante esta fase.

Figura 34 - Diagrama de contributos do estágio

CONCLUSÕES

89

De uma forma geral, considera-se que foram atingidos todos os objetivos inicialmente

propostos e que o estágio foi bem-sucedido. O estagiário sente-se satisfeito com as competências

adquiridas durante este período.

O trabalho realizado no primeiro semestre, de um ponto de vista técnico, consistiu

essencialmente na aquisição de conhecimentos no desenvolvimento de aplicações web com

recurso a tecnologias Stripes, Java EE, JavaScript, HTML e CSS. Estes conhecimentos adquiridos

foram preponderantes no âmbito dos testes para a aplicação desenvolvida.

A segunda metade do estágio tornou-se mais aliciante, desafiante e enriquecedora. A

possibilidade de trabalhar com tecnologias na vanguarda como a suite Arquillian foi um fator de

motivação. Para além desta abordagem técnica, também foi importante, para a concretização dos

objetivos do estágio, o estudo realizado sobre a contextualização envolvente de recomendações e

sugestões formais para as atividades de testes de software.

Adquiriu-se uma maior sensibilidade para a importância da realização de testes, com vista à

melhoria da qualidade do software desenvolvido. Pode considerar-se que os resultados obtidos,

durante a criação dos scripts automáticos, foram os desejados e que, o trabalho realizado, consiste

numa prova de conceito e um ponto de partida para a implementação do procedimento de testes

proposto.

Foi também desafiante a dimensão do projeto, uma vez que o estagiário já se encontrava

com vínculo laboral com a Present Technologies, o que obrigou a uma conciliação de esforços

dedicado ao desenvolvimento de outros projetos independentes ao estágio.

7.2. Dificuldades A principal dificuldade sentida na utilização do processo de testes esteve associada ao

equilíbrio entre o tempo a despender e o conjunto finito de condições do sistema que devem ser

alvo de teste. É da responsabilidade de cada projeto a definição dos critérios de cobertura a

aplicar, desde que resulte numa razoável evidência da qualidade do sistema.

Os aspetos da interface gráfica web são difíceis de testar de forma automática. Podem

existir desalinhamentos de campos percetíveis apenas a olho humano, ou tecnologias como AJAX

em que é necessário interagir com a interface para se poder realizar as tarefas. Constatou-se que

não existe uma solução gratuita, capaz e viável para a geração automática de casos de teste de

aplicações web.

No entanto, investigações recentes apontam que se trata de uma área de engenharia de

software muita adesão e que o entusiasmo à volta da simplificação deste tipo de teste não

esmoreceu.

CONCLUSÕES

90

7.3. Trabalho futuro Perante as dificuldades observadas torna-se necessário o desenvolvimento de trabalhos

futuros que poderão tornar o procedimento de testes mais eficiente e robusto.

Recomenda-se que a documentação interna da Present Technologies, proposta no âmbito

deste projeto, seja melhorada iterativa e continuadamente, de modo a refletir ainda mais as

necessidades da empresa. Para além disso, deveria ser recolhido o feedback da aplicação deste

procedimento de testes noutros projetos para validar a sua efetiva utilidade.

A produção manual de casos de teste torna-se complicada para aplicações web que possuam

um elevado número de funcionalidades. Para solucionar este problema, deve ser realizado um

trabalho de acompanhamento da evolução das tecnologias de testes web, sobre técnicas ou

mecanismos ideais para geração automática de casos de teste. Recomenda-se ainda que seja

realizado um estudo com maior profundidade sobre a seleção de critérios de cobertura mais

eficientes para deteção de falhas que possam surgir.

Num futuro próximo, seria benéfica a utilização de uma ferramenta de integração contínua,

para assim, possibilitar o agendamento de builds e execução de testes. Um dos exemplos deste

tipo de ferramentas é o Jenkins52. Com base na sua utilidade e resultados obtidos na realização de

projetos anteriores, o estagiário aconselha o uso desta ferramenta na Present Technologies para

gestão contínua do software. As suas principais vantagens são:

Automação do processo de build (possibilitando o agendamento a cada alteração);

Automação de testes unitários, integração e sistema (JUnit e Selenium);

Apresentação do relatório dos resultados de teste e configuração de alarmística

associada aos defeitos encontrados;

Controlo e gestão do ciclo de releases de software.

No cômputo geral, esta aplicação providencia aos programadores, arquitetos de software e

gestores, uma melhor noção do progresso de desenvolvimento e qualidade do código dos projetos.

Faz ainda parte dos planos do estagiário a criação e divulgação na Wiki da Present

Technologies, as principais conclusões retiradas deste estágio, mais especificamente em relação às

técnicas e ferramentas adotadas para testes de interface web. Finalmente, e pela crescente

necessidade de ter uma qualidade elevada nos produtos da empresa, tomando em consideração as

propostas assumidas neste estágio, o estagiário encoraja os gestores de topo a aumentarem o seu

investimento na formação e realização de atividades de testes.

52 http://jenkins-ci.org/

CAPÍTULO 8

91

8. REFERÊNCIAS BIBLIOGRÁFICAS As referências utilizadas ao longo deste relatório são à frente designadas. É feita a

segmentação por 4 categorias: Artigos científicos, Livros, Normas e Sites Web.

Artigos científicos

[1] The FocalPoint Group. M2M White Paper: The Growth of Device Connectivity.

[2] Koomen, T., Aalst, L., Broekman, B., Vroon, M. (2007). TMap® Next for result-driven

testing.

[3] Andersin, J. (2004). TPI – a model for Test Process Improvement.

[4] TMMi Foundation. (2012). Test Maturity Model integration Release 1.0.

[5] Lamers, P., Betrancourt, A. (2004) Developing a suitable structured testing approach for a

small web development company.

[6] Londesbrough, I. (2008). A Test Process for all Lifecycles.

[7] Accenture. (2010). Test Maturity Model integrated (TMMi) for Process Improvement.

[8] Jeff, L. (2007). Doing TDD Well.

[9] Memon, A., Soffa, M., Pollack, M. (2001). Coverage Criteria for GUI Testing.

[10] Memon, A. (2006). An event-flow model of GUI-based applications for testing.

[11] Boehm, B. (1981). Software Engineering Economics.

[12] Crispin, L. (2009). Making Test Automation Work in Agile Projects.

[13] Stine, M. (2010). Selenium 2.0: Using the Webdriver API to Create Robust User

Acceptance Tests.

[14] Heumann, J. (2001). Generating Test Cases From Use Cases.

Livros

[15] Naik, K., Tripathy, P. (2008). Software Testing and Quality Assurance. [16] Ammann, P., Offutt, J. (2008). Introduction to: Software Testing. [17] Pressman, R. (2005). Software Engineering a Practitiones’s Approach. [18] Ilene, B. (2003). Pratical Software Testing – A Process-Oriented Approach. [19] Myers, G. (2004). The Art of Software Testing 2ª Ed. [20] Perry, W. (2006). Effective Methods for Software Testing. [21] Jones, C. (1996). Applied Software Management: Assuring Productivity and Quality. [22] Patton, R. (2006). Software Testing, 2nd Edition. [23] Tahchiev, P., Leme, F., Massol, V., Grefory, G. (2011). JUnit in Action 2nd Edition. [24] Beust, C., Suleiman, H. (2008). Next Generation Java™ Testing. [25] Filipin, Z. (2011). Watir book 0.7.1. [26] Johansen, C. (2011). Test-Driven JavaScript Development.

REFERÊNCIAS BIBLIOGRÁFICAS

92

Normas

[27] IEEE (1990). 610.12 Standard Glossary of Software Engineering Terminology. [28] ISTQB (2010). Standard glossary of terms used in Software Testing V2.1. [29] IEEE 829-1983 (2008). Standard for Software and System Test Documentation. [30] British Computer Society (1997). BS7925-2 Standard for Software Component Testing.

Sites Web

[31] Jens, S. (2012). TDD: Do We Really Have To Do It? http://java.dzone.com/articles/tdd-do-we-really-have-do-it

[32] Dan, N. (2006). Introducing BDD. http://dannorth.net/introducing-bdd/ [33] User Interface Test Automation - EggPlant Innovates!

http://www.innovationlaunchpad.cabinetoffice.gov.uk/Page/ViewIdea?ideaid=438 [34] StatCounter GlobalStats. http://gs.statcounter.com [35] Wikipédia “MVC”. http://pt.wikipedia.org/wiki/MVC [36] Web Testing: Complete Guide to Test Web Applications. http://www.guru99.com/web-

application-testing.html [37] Miller, S. (2009). 35 Test Cases for User Interface Testing

http://www.embeddedstar.com/weblog/2009/08/23/pragmatic-ui-tests/ [38] Stewart, S. (2011). Page Objects

http://code.google.com/p/selenium/wiki/PageObjects

http://java.dzone.com/articles/tdd-do-we-really-have-do-it

http://java.dzone.com/articles/tdd-do-we-really-have-do-it

http://dannorth.net/introducing-bdd/

http://www.innovationlaunchpad.cabinetoffice.gov.uk/Page/ViewIdea?ideaid=438

http://gs.statcounter.com/

http://pt.wikipedia.org/wiki/MVC

http://www.guru99.com/web-application-testing.html

http://www.guru99.com/web-application-testing.html

http://www.embeddedstar.com/weblog/2009/08/23/pragmatic-ui-tests/

http://code.google.com/p/selenium/wiki/PageObjects

CAPÍTULO 9

93

9. ANEXOS A seguinte listagem identifica os anexos presentes em suporte digital, complementares a

este documento:

Anexo A – Software Testing Guide

Anexo B – Test Plan Template

Anexo C – Requisitos do Portal B2B

Anexo D – Plano de testes Portal B2B

Anexo E – Análise de ferramentas de testes

Anexo F – Análise dos modelos de otimização do processo de testes

Documents

PortalB2B e optimização do processo de testesfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Teses/Tese_Mest_Hug… · Classe de programação Java utilizada para estender as capacidades