PortalB2B e Otimização do Processo de Testes

Tamanho: px
Começar a partir da página:

Download "PortalB2B e Otimização do Processo de Testes"

Transcrição

1 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

2 Portal B2B e Testes RESUMO 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. ii

3 Portal B2B e Testes ABSTRACT 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. iii

4 Portal B2B e Testes PALAVRAS-CHAVE 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 iv

5 Portal B2B e Testes GLOSSÁRIO GLOSSÁRIO Termo AJAX API AUT B2B B2C Browser Bug Build ContextPath CRUD CDI Change Request Checklist CSS Deployment DOM EAR ehealth End-to-end testing Fleet management Framework Front-end GUI HTML HTTP Hub IDE IEEE Descrição 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. Application Programming Interface Conjunto de métodos estabelecidos por um software para utilização das suas funcionalidades. Application Under Test Aplicação de software verificada e validada com o processo de teste. 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. Business To Consumer Comércio efetuado diretamente entre a empresa produtora, vendedora ou prestadora de serviços e o consumidor final. Aplicação cliente que permite a receção, interpretação e visualização de recursos disponíveis na web. Tipicamente é um erro no funcionamento comum de um software. Refere-se ao processo de conversão de código-fonte em artefactos de software que podem ser posteriormente executados num computador. Prefixo de um caminho URL que identifica qual a aplicação web para a qual os pedidos devem ser encaminhados. Create/Read/Update/Delete Refletem as quatro funções base relacionadas com a persistência da informação de uma aplicação. Context Dependency Injection Permite, através da utilização de anotações Java, injectar dependências de forma simplificada. Tipicamente uma declaração de pedido de ajuste/alteração de uma funcionalidade de um sistema. Lista de tarefas utilizada para compensar memória ou atenção do autor. Cascading Style Sheet - Linguagem que permite definir estilos a documentos escritos em HTML e XHTML. Processo composto por todas as atividades necessárias para que o sistema fique disponível para uso. Document Object Model Convenção para representação e interação com objetos em documentos HTML e XHTML independente de plataformas/linguagens. 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. Serviços de saúde assegurados por processos e comunicação eletrónica. Consiste no processo de teste que inclui funcionalidades de todas as camadas constituintes da arquitetura da solução. Solução para gestão de frota de transporte de uma companhia. 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. Termo generalizado para especificar a camada do sistema de software que interage diretamente com o utilizador. Graphical User Interface representa a exteriorização visual da aplicação com a qual o utilizador tem a possibilidade de interagir. 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. HyperText Transfer Protocol Protocolo de comunicação de nível aplicacional. Arquitetura que permite a transmissão e difusão de determinada informação em simultâneo para vários recetores. Integrated Development Environment programa que reúne caraterísticas e ferramentas de apoio ao desenvolvimento de software com o objetive de agilizar o processo. Institute of Electrical and Electronics Engineers Organismo profissional dedicado à evolução v

6 Portal B2B e Testes GLOSSÁRIO Internet Issue Tracker JAR Java JavaScript Java Virtual Machine ou JVM jquery JSON JSP M2M Mock MVC Open-Source Quality Assurance RFP Sandbox JS Script Servlet Smart Metering Smart Service SQL Injection Stub SVN Tag library TestRunner TMMi URL User Stories Voucher VPN e inovação tecnológica e excelência. Sistema global de redes de computadores interligadas. Sistema onde são mantidos e geridos vários problemas de um determinado projeto de software. 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. Linguagem de programação orientada a objetos, derivada das linguagens de programação C e C++. 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. Corresponde ao componente da plataforma de software Java responsável pela execução do código (normalmente Java bytecode). Bibliotecas da linguagem JavaScript que simplifica a interação com HMTL, tratamento de eventos, animações interações AJAX. JavaScript Object Notation - Formato de dados leve de fácil interpretação. Tecnologia que providencia uma maneira simples e rápida de criar conteúdo dinâmico web. 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. Objeto utilizado durante o desenvolvimento e realização de testes que simula o comportamento de um objeto real. 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. Filosofia de desenvolvimento e distribuição de software que inclui a disponibilização do código fonte de todas as aplicações. 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. Request For Proposal Processo de aquisição, onde os fornecedores são convidados a apresentar uma proposta para um serviço específico. Componente constituinte dos browsers responsável pela interpretação do código JavaScript. Ficheiro executável desenvolvido numa linguagem de programação que executa uma rotina pré-definida. Classe de programação Java utilizada para estender as capacidades dos servidores web. Utilizam o modelo de programação pedido-resposta. 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. Serviço inteligente capaz de agir perante informação recolhida de maneira autónoma. Técnica utilizada para atacar base de dados através de um site web. Semelhante ao Mock mas conserva um estado interno derivado das chamadas durante a execução dos testes. Sistema de controlo de versão desenhado especificamente para ser um substituto do CVS. Define um conjunto de tags personalizadas para utilização nas JSPs. Componente de framework de testes tipicamente responsável pela gestão do ciclo de vida dos testes, incluindo a sua execução. Test Maturity Model integrated modelo de otimização do processo de testes baseado no modelo Capability Maturity Model Integration (CMMI). Uniform Resource Locator Especifica um texto que referencia um recurso da internet. 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. Trata-se de um título, recibo ou documento que comprova o pagamento e o direito a um serviço ou a um produto. 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). vi

7 Portal B2B e Testes GLOSSÁRIO WAR Web Wiki XSS Web Application Archive Utilizado para agrupar JSPs, Java Servlet, Java.class, ficheiros XML e outros recursos que constituem uma aplicação web. Abreviatura para Worl Wide Web. Sistema de documentos de diversos tipos de conteúdos interligados e acessíveis através da internet. Termo identificativo de um conjunto de documentos em hipertexto ou o software colaborativo usado para a sua criação. Cross Site Scripting Tipo de vulnerabilidade de segurança tipicamente associada a aplicações web, onde hackers injetam script do lado do cliente. vii

8 Portal B2B e Testes ÍNDICE Í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 Apresentação do projeto/estágio Apresentação da Organização Introdução ao M2M Motivação Objetivos atingidos Estrutura do documento ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES Procedimentos de testes em vigor Resultado de projetos antecedentes Projeto A Projeto B Análise Informal Ausência de uma política comum de testes Smoke tests Testes no cliente Formação e suporte documental Testes automatizados Testes estáticos e registo de defeitos Ensaio com Test-Driven Development METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE Processos de testes Contextualização de processos de testes Otimização do processo de teste Modelo em V Metodologias de teste Plano de testes Sumário de processos de testes Testes de interface web Aplicações web Desafios de testes web Contexto de testes web Técnicas de testes WUI Critérios de testes WUI Sumário de testes de interface web Ferramentas de automatização de testes Ferramentas de testes funcionais viii

9 Portal B2B e Testes ÍNDICE Ferramentas de testes web Ferramentas de testes in-container Ferramentas de testes JavaScript CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES Software Testing Guide Test Plan Template Modelo de otimização TMMi CASO DE ESTUDO: PROJETO PORTAL B2B Principais Conceitos Descrição do projeto Arquitetura Tecnologias Java EE JBoss Stripes Web Framework Sitemesh JQuery HTML5 e CSS Metodologia de desenvolvimento Planeamento e Especificação de requisitos Implementação Validação Aceitação Responsabilidades Ferramentas de apoio APLICAÇÃO DO NOVO PROCEDIMENTO DE TESTES Planeamento Desenho Testes de Navegação Testes de Validação de entradas Testes da estrutura HTML e CSS Testes AJAX Automatização e Execução Avaliação e resultados CONCLUSÕES Revisão do trabalho realizado Dificuldades Trabalho futuro REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS ix

10 Portal B2B e Testes ÍNDICE Í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 Figura 5 Envolvente económica de testes de software (baseado em [33]) Figura 6 Testes estáticos e dinâmicos Figura 7 - Inquérito Forrester Consulting [7] Figura 8 - Modelo em V [5] Figura 9 - Método de desenvolvimento TAD Figura 10 - Método de desenvolvimento TDD Figura 11 - Padrão Modelo-Vista-Controlador [35] Figura 12 - Utilização dos browsers no StatCounter entre 08/2011 e 08/ Figura 13 - Hierarquias de teste JUnit e TestNG Figura 14 - Teste de pesquisa de filme Figura 15 Elemento assinalado pelo Watir Figura 16 - Modos de execução do Arquillian (in-container vs client) Figura 17 Resultado do teste QUnit Figura 18 - Resultado do teste Jasmine Figura 19 - Índice do STG Figura 20 - Ciclo de vida de testes Figura 21 - Ferramentas de teste selecionadas Figura 22 - Índice do TPT Figura 23 - Mapeamento do processo de testes para nível 2 do TMMi Figura 24 Diagrama de deployment do projeto Figura 25 - Composição do Portal B2B Figura 26 - Ciclo de vida em Cascata Figura 27 - Grafo referente à navegação do Portal Business Figura 28 - Passo 1 e 2 do wizard de edição de Utilizador Figura 29 - Estados da dropdown de seleção de Aplicação Vertical Figura 30 - Testes automáticos Portal B2B Figura 31 - Exemplo de interações com os Page Ojects Figura 32 - Execução automática de testes nos browsers IE e Chrome Figura 33 - Resultado dos testes implementados Figura 34 - Diagrama de contributos do estágio x

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

12 CAPÍTULO 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 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 fulltime 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. 1

13 INTRODUÇÃO 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 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. 2

14 INTRODUÇÃO 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 3

15 INTRODUÇÃO 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 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 Stripes 1 e EJB3 2. 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

16 INTRODUÇÃO 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 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. 5

17 INTRODUÇÃO 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 6

18 INTRODUÇÃO 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. 7

19 CAPÍTULO 2 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 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, 8

20 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 requisitos Fase de implementação Fase de validação Fase de aceitação Fase de garantia Fase de suporte e manutenção d) Fase de suporte e manutenção 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 CVS 3 e de 3 9

21 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES gestão de projetos Redmine 4 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)

22 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 Entrada 2. Especificações de saída: 1. Saída 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. 11

23 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 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 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. 12

24 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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. Bugs por Funcionalidade = 247 bugs 64 fp s = 3, 86, (1) % Tempo real correções % Tempo planeado correções = 20,28% 14,47% = 5, 81% (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. 13

25 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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). Bugs por Funcionalidade = 26 bugs 93 fp = 0, 29, (3) s % Tempo real correções % Tempo planeado correções = 14,13% 11,96% = 2, 17% (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. 14

26 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 faulterror-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 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 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 15

27 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 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 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 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 xunit 5 e in-container, isto é, com a aplicação sob teste em 5 16

28 ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES 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 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 Docs 6 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 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 17

29 CAPÍTULO 3 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 Selenium 7 e o Arquillian 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 Contextualização de processos de testes As definições do conceito de testes de software compreendidas nas normas IEEE 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,

30 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 19

31 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 FindBugs 9 e Checkstyle 10 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

32 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 21

33 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 TMap 11 é 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,

34 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 23

35 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Integration 12 (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 Nível 1 - Inicial Nível 2 - Controlado Nível 3 - Definido Nível 4 Gestão e Medição Nível 5 Otimização Descrição 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. 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. 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. 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. 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

36 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 debatemse com a definição da sua atual situação [7] 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 25

37 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 26

38 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE Figura 8 - Modelo em V [5] 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. 27

39 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Programming 13 (XP), popularizado por Kent Beck em 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

40 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 29

41 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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; 30

42 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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). 31

43 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 [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 Componentes do Plano de Testes Identificador do Plano de testes Introdução Itens a testar Funcionalidades a testar Abordagem Critério Pass/Fail Critério de Suspensão e retoma Artefactos de testes Tarefas de testes Ambiente de testes Responsabilidades Pessoal e necessidades de formação Agendamento Riscos e contingências Aprovações Definição Cada plano deve conter um identificador único de modo a ser associado a um projeto e fazer parte do seu histórico. Nesta secção é descrito o sistema a ser desenvolvido incluindo uma visão de alto-nível dos objetivos e abordagens de testes. Consiste na lista de entidades do sistema a testar, deve incluir a referência e versão/revisão para cada uma das entidades. Nesta secção são definidas as caraterísticas do componente ou sistema a testar. 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. Dado o caso de teste é definido o critério que permite decidir se um determinado teste passou ou falhou durante a sua execução. 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. Consiste na determinação de quais os artefactos relacionados com testes, devem ser entregues ao cliente do projeto. Neste capítulo são identificados todas as atividades de testes e suas dependências, normalmente sob a forma de Work Breakdown Structure (WBS). Consiste na descrição das necessidades de software e hardware para a execução dos testes. Identificação do pessoal responsável pelas tarefas relacionadas com os testes. Descrição do pessoal e níveis de competências necessários para exercer as responsabilidades listadas anteriormente. As durações das tarefas de teste são estabelecidas e registadas. Nesta secção são registados todos os riscos envolvidos na realização de testes. 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. 32

44 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 ([29]). Esta lista pode ser consultada na Tabela 6. Tabela 6 - Componentes do Plano de testes essenciais [19] Componentes do Plano de Testes Objetivos Critério de completude Agendamento Definição Definição dos objetivos para cada fase de teste. Designação do critério para especificar quando uma determinada fase de teste é considerada como finalizada. Agendamento para cada fase de testes. Responsabilidades Omisso por ser similar ao componente descrito em IEEE Casos de teste e normas Ferramentas Configuração de hardware Integração Procedimentos de rastreabilidade Procedimento de registo Testes de regressão Sumário de processos de testes Métodos sistemáticos para identificar, elaborar e armazenar os casos de teste necessários. Identificação das ferramentas necessárias para a realização dos testes. Determinação das configurações de hardware ou dispositivos envolvidos nos testes. Definição de como serão arquitetados os testes, por exemplo top-down incremental. Identificação dos métodos para rastrear o progresso dos testes. Descrição dos meios definidos para o registo dos erros encontrados. Testes realizados após correção ou desenvolvimento de uma melhoria funcional garantindo o anterior correto funcionamento do sistema. 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. 33

45 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 34

46 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 verificase 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]: 35

47 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Injection 14 ou Cross Site Scripting (XSS) 15. A popularidade do AJAX 16 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 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

48 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Explorer 17, Mozilla Firefox 18, Google Chrome 19, Opera 20 e Safari 21. 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 https://www.google.com/intl/pt-pt/chrome/browser/?hl=pt-pt

49 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE Figura 12 - Utilização dos browsers no StatCounter 22 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 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 IDE 23, 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

50 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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. 39

51 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 40

52 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 41

53 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 Ferramentas de testes funcionais A seleção da ferramenta de testes vocacionada para testes funcionais no universo Java incide predominantemente sobre o JUnit 24 e TestNG 25. 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

54 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 IDE 26, 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 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 import static org.junit.assert.assertequals; import org.junit.test; TestNG import static org.testng.assert.assertequals; import org.testng.annotations.test; public class SimpleTest public void testsquareroot() { assertequals(2.0, Math.sqrt(4.0), 0.0); } } public class SimpleTest 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 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 No entanto, o TestNG oferece um ciclo de vida mais rico, dispondo

55 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 A análise comparativa destas ferramentas foi concluída com um exemplo de automatização em conjunto com o plugin Surefire 27 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 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

56 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE HtmlUnit O HtmlUnit 28, impulsionado por Mike Bowler da Gargoyle Software Inc., é tido como um headless browser 29 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 public static void setupbeforeclass() throws MalformedURLException { webclient = new WebClient(); URL = new URL("http://www.imdb.com"); public static void teardownafterclass() { webclient.closeallwindows(); 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());

57 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 é 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 Selenium 30 é 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

58 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 public static void setupbeforeclass() throws Exception { driver = new FirefoxDriver(); public static void teardownafterclass() throws Exception { driver.quit(); 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( ) é 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, XPATH 31, 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

59 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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ódigolivre 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 48

60 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 49

61 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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-adia 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 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 à 50

62 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Arquillian 32 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 ShrinkWrap 33 ; 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 public class Movie implements = GenerationType.IDENTITY)

63 METODOLOGIAS E PRÁTICAS DE TESTES DE = false) private Long = 50, nullable = false) private String = 200, nullable = true) private String = 20, nullable = true) private String = true) private Integer year; [...] } @TransactionAttribute(TransactionAttributeType.REQUIRED) public class MovieService public Movie getmoviebyid(long id) { [...] 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 public class MovieServiceIT { private static Long private MovieService 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") 52

64 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE }.addasmanifestresource(emptyasset.instance, 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 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 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 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 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 Failsafe 34, 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

65 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Drone 35 e Arquillian Graphene 36. 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 à ou acrescentar a 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 54

66 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE construída uma pequena aplicação web com base na framework Stripes 37 (descrita no capítulo 5), que continha um formulário para a adicionar filmes. Listagem 8 - Caso de teste exemplo Drone e Graphene Drone public class MovieTestsIT 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 public static EnterpriseArchive createdeployment() throws IOException { [ ] return ear; public void 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 foi reutilizado do exemplo disposto na Listagem 7. A presença da 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 jquery 38 (Listagem 8). Por exemplo, a

67 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 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 A linguagem acabou por ser normalizada pela ECMA International como ECMA 262, também conhecida como a norma ECMAScript 39. 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

68 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE QUnit O QUnit 40 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> <!-- project source code files --> <script type="text/javascript" src="qunitprototype.js"></script> <!-- test files --> <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

69 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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 Jasmine 41 é 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 [ ] <!-- include spec files here... --> <script type="text/javascript" src="spec/specexample.js"></script> <!-- include source files here... --> <script type="text/javascript" src="src/jasmineexample.js"></script> [ ] jasmineexample.js function iseven(val) {

70 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE } 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. 59

71 METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE 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. 60

72 CAPÍTULO 4 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 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. 61

73 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES 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. 62

74 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES Requirement Test Planning SRS Standards and templates Test tools information Software Testing Handbook SRS Approved Test Plan Test Criteria Test Design Implementation / Engeneering Source Code Test Case Specification Test Tools Validation Validation Acceptance Warranty Support and Maintenance Test Automation Test Tools Test Execution Test Tools Test Design Error Test Evaluation Test Metrics Test Design Error Performance Test Execution Test Report Solution Delivered Analyze issues Test Documentation Completed Closed Change Requests Defect Reported Regression Tests Figura 20 - Ciclo de vida de testes Tabela 7 - Resumo das atividades do ciclo de vida dos testes Tarefa Testing Planning Test Design Test Automation Descrição Nesta tarefa são tomadas as decisões que permitem definir quais os tipos e critérios de testes a adotar. Esta secção inclui a especificação de casos de teste baseada nos critérios escolhidos na tarefa anterior. Consiste na produção de scripts dos testes unitários, integração e de sistema. Test Execution Test Evaluation Analyse Issues 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. São avaliados os resultados de teste e aplicadas técnicas apropriadas para medir o nível de qualidade do produto. 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. 63

75 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES 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 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 Plugin 42, 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 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

76 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES 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 ([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 65

77 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES 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 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

78 CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES 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. 67

79 CAPÍTULO 5 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 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. 68

80 CASO DE ESTUDO: PROJETO PORTAL B2B 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 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 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) Código Funcionalidade VA Location 69

81 CASO DE ESTUDO: PROJETO PORTAL B2B 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). Deployment diagram Application server Application server PortalO&M.war PortalBusiness.war VALocation.war Remote interface (JSR 177) Mtom-sdb.jar Mtom-sdb-client.jar Mtom-va-locationclient.jar Mtom-sdblocation.jar Mtom-core-client.jar 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). 70

82 CASO DE ESTUDO: PROJETO PORTAL B2B 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 JEE 2 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 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 Java EE A plataforma Java EE 43 é 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 (webfragment.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

83 CASO DE ESTUDO: PROJETO PORTAL B2B JBoss Um dos servidores aplicacionais baseados em Java EE é o JBoss Application Server 44. 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 Filter 45 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) Stripes Web Framework Stripes 46 é 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 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

84 CASO DE ESTUDO: PROJETO PORTAL B2B JQuery No que diz respeito a implementação em JavaScript, foi aplicada a framework jquery 48. Os múltiplos fatores considerados para a utilização desta biblioteca foram a compatibilidade multibrowser, 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 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 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 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

85 CASO DE ESTUDO: PROJETO PORTAL B2B 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 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 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 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 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. 74

86 CASO DE ESTUDO: PROJETO PORTAL B2B 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 Atlassian 49. 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 entre 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 Maven 50. 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

87 CAPÍTULO 6 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 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 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 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 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. 76

88 APLICAÇÃO DO NOVO PROCEDIMENTO 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: N = {1,2,3,4,5,6,7,8,9,10,11} (Nós) N0 = 1 (NÓ inicial); Nf = {7,8,9,10,11}(NÓs finais) 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 77

89 APLICAÇÃO DO NOVO PROCEDIMENTO 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: TR = {(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 Testes de Validação de entradas Estes testes foram realizados de acordo com a técnica Input Space Partitioning, anteriormente apresentada no tópico (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. 78

90 APLICAÇÃO DO NOVO PROCEDIMENTO 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; ; 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 79

91 APLICAÇÃO DO NOVO PROCEDIMENTO 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 < 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 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]; [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]; [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]; [inválido]; Telemovel:[0]; Telefone:[14]; Perfil:[Admin Management Profile]; Gupo:[Grupo de dispositivos]); TestB2B13 = (Nome:[0]; Login:[0]; Estado:[Ativo]; Descrição:[>512]; [válido]; Telemóvel:[0]; Telefone:[0]; Perfil:[Admin Management Profile]; Grupo:[Grupo de dispositivos]); 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: 80

92 APLICAÇÃO DO NOVO PROCEDIMENTO 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 TestB2B16 Dropdown aberta (cor de fundo #333333) Dropdown aberta (cor de fundo #333333) mouseover() click() Dropdown aberta (cor de fundo #0099AB) 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 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. 81

93 APLICAÇÃO DO NOVO PROCEDIMENTO 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. 82

94 APLICAÇÃO DO NOVO PROCEDIMENTO 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/xmlschemainstance" xsi:schemalocation=" <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> <!-- ChromeDriver only --> <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. 83

95 APLICAÇÃO DO NOVO PROCEDIMENTO Figura 32 - Execução automática de testes nos browsers IE e Chrome Listagem 14 - Exemplo de teste automático NavigationTests.class }) public class NavigationTestsIT private WebDriver private LoginPage private HomePage private VALocationPage valocationpage; Indica ao Drone que é utilizado o Selenium 2 (WD) como framework de testes web Indica que o objeto valocationpage é um Page Object 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 * 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 { 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 84

96 APLICAÇÃO DO NOVO = "#clientusermenu a") private WebElement = "#notificationmenu a") private WebElement = "#userprofilemenu a") private WebElement profilemenutab; Exemplo de localização de um elemento HTML da página, neste caso o link que redireciona para a página da VA = "a div.applicationlogo img") private WebElement = "div.dropdowncontainer") private WebElement = "div.dropdowncontainer button") private WebElement buttonvadropdown; Exemplo de serviço navegar para página VA Location } // 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). 85

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

ARQUITETURA DO SISTEMA ERP PEGASUS

ARQUITETURA DO SISTEMA ERP PEGASUS ARQUITETURA DO SISTEMA ERP PEGASUS Elaborado por: Bruno Duarte Nogueira Arquiteto de Software Data: 05/03/2012 1 Sumário 1. Introdução... 3 2. Tecnologias... 3 2.1. Web Tier... 3 2.1.1. Facelets 1.1.14...

Leia mais

5.1 Introdução. 5.2 Project Management Institute (PMI)

5.1 Introdução. 5.2 Project Management Institute (PMI) 5 NORMALIZAÇÃO DA GESTÃO DE PROJETOS 5.1 Introdução Embora tradicionalmente o esforço de normalização pertença à International Standards Organization (ISO), no caso da gestão de projetos a iniciativa tem

Leia mais

Gestão da qualidade do software

Gestão da qualidade do software Gestão da qualidade do software Empenhada em assegurar que o nível de qualidade requerido de um produto de software é atingido Envolve a definição de normas e procedimentos de qualidade apropriados, e

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1 r Indice Introdução.......................................... 1 Parte I - Um Modelo de Gestão de Projectos 1- Características da Gestão de Projectos 11 1.1 Definição de Projecto 11 1.2 Projectos e Estratégia

Leia mais

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS Rodrigo das Neves Wagner Luiz Gustavo Galves Mählmann Resumo: O presente artigo trata de um projeto de desenvolvimento de uma aplicação para uma produtora de eventos,

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

YMT REQUISITOS FUNCIONAIS + REFLEXÃO VIABILIDADE TÉCNICA

YMT REQUISITOS FUNCIONAIS + REFLEXÃO VIABILIDADE TÉCNICA REQUISITOS FUNCIONAIS + REFLEXÃO VIABILIDADE TÉCNICA YMT DeCA NTC ANO3 PROJECTO NTC SEM2 RENATO COSTA RICARDO CARVALHO TIAGO FIGUEIREDO MARTIM SANTOS JOÃO ELVAS REQUISITOS FUNCIONAIS 1. Paradigma de interacção

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projetos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

Fundação Universidade Estadual de Maringá

Fundação Universidade Estadual de Maringá Fundação Universidade Estadual de Maringá PAD/DIRETORIA DE MATERIAL E PATRIMÔNIO AVISO DE LICITAÇÃO EDITAL 485/2007 CONCORRÊNCIA PÚBLICA - PROC.: N 15344/2007 OBJETO: CONTRATAÇÃO DE UMA EMPRESA ESPECIALIZADA

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

a. A plataforma recomendada é Web, com arquitetura Microsoft.Net; b. A linguagem recomendada para codificação de Sistemas de Informações é C#;

a. A plataforma recomendada é Web, com arquitetura Microsoft.Net; b. A linguagem recomendada para codificação de Sistemas de Informações é C#; 1. OBJETIVO O objetivo deste documento é definir as normas e os padrões que deverão ser adotados pelos desenvolvedores da equipe interna e externa (fornecedores) que venham a desenvolver soluções de software

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos. Requisitos para a 3ª entrega do projecto.

Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Loja Virtual 5 de Maio de 2008 Índice Índice...2 1 Sumário...3 2 Requisitos...3

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

Desenvolvimento e disponibilização de Conteúdos para a Internet

Desenvolvimento e disponibilização de Conteúdos para a Internet Desenvolvimento e disponibilização de Conteúdos para a Internet Por Matheus Orion Principais tecnologias front-end HTML CSS JAVASCRIPT AJAX JQUERY FLASH JAVA APPLET Linguagens que executam no cliente HTML

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

12 EXCEL MACROS E APLICAÇÕES

12 EXCEL MACROS E APLICAÇÕES INTRODUÇÃO O principal objetivo deste livro é auxiliar o leitor na sua aprendizagem sobre os recursos avançados do Excel em especial na interligação com o Visual Basic for Applications (VBA). Pretende-se

Leia mais

CURSO DE SISTEMAS DE INFORMAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO 1 CURSO DE SISTEMAS DE INFORMAÇÃO EMENTÁRIO DAS DISCIPLINAS 2011.1 BRUSQUE (SC) 2015 2 SUMÁRIO 1ª FASE... 4 01 ARQUITETURA DE COMPUTADORES... 4 02 FILOSOFIA... 4 03 FUNDAMENTOS MATEMÁTICOS PARA COMPUTAÇÃO...

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Serviço de Solução de Replicação de Dados HP para Virtual Copy 3PAR

Serviço de Solução de Replicação de Dados HP para Virtual Copy 3PAR Serviço de Solução de Replicação de Dados HP para Virtual Copy 3PAR Serviços HP Care Pack Dados técnicos O Serviço de Solução de Replicação de Dados HP para Virtual Copy 3PAR fornece implementação do produto

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

O produto. Caraterísticas gerais e arquitetura do sistema

O produto. Caraterísticas gerais e arquitetura do sistema sistema integrado de processamento e gestão bibliográfica - versão 2012 Informática Formação e Serviços, Lda - Web: http://www.bibliosoft.pt Email: bibliosoft@bibliosoft.pt O produto O sistema biblio.net

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

O seu escritório na nuvem - basta usar o browser.

O seu escritório na nuvem - basta usar o browser. 02 O seu escritório na nuvem - basta usar o browser. As soluções tecnológicas que encontra para melhorar a colaboração na sua empresa são muito caras e complexas? Pretende tornar as suas equipas mais ágeis

Leia mais

Plataforma de Gestão de Actualizações de Software Descrição do Problema

Plataforma de Gestão de Actualizações de Software Descrição do Problema Plataforma de Gestão de Actualizações de Software Descrição do Problema Pedro Miguel Barros Morgado Índice Introdução... 3 Ponto.C... 4 Descrição do Problema... 5 Bibliografia... 7 2 Introdução No mundo

Leia mais

Tese Mestrado Manuel Teixeira Apresentaça o da Proposta de Tese

Tese Mestrado Manuel Teixeira Apresentaça o da Proposta de Tese Tese Mestrado Manuel Teixeira Apresentaça o da Proposta de Tese Título Desenvolvimento e Comercialização de Software de Gestão multiplataforma em regime de Aluguer Objetivos Extensão de um Software de

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software 2º Semestre de 2006/2007 Terceiro enunciado detalhado do projecto: Portal OurDocs ic-es+alameda@mega.ist.utl.pt ic-es+tagus@mega.ist.utl.pt 1. Introdução O terceiro enunciado do

Leia mais

Seu dia é mais inteligente

Seu dia é mais inteligente Seu dia é mais inteligente O 2007 Microsoft Office system é uma plataforma de soluções inteligentes para tarefas operacionais, estratégicas e organizacionais. O conjunto de aplicativos e servidores e a

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

ANEXO 09 PERFIS PROFISSIONAIS MÍNIMOS

ANEXO 09 PERFIS PROFISSIONAIS MÍNIMOS ANEXO 09 PERFIS PROFISSIONAIS MÍNIMOS As qualificações técnicas exigidas para os profissionais que executarão os serviços contratados deverão ser comprovados por meio dos diplomas, certificados, registros

Leia mais

Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua

Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua Janeiro 2015 Área de Desenvolvimento Departamento de Arquitetura e Desenvolvimento Agenda Processo

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

WWW - World Wide Web

WWW - World Wide Web WWW World Wide Web WWW Cap. 9.1 WWW - World Wide Web Idéia básica do WWW: Estratégia de acesso a uma teia (WEB) de documentos referenciados (linked) em computadores na Internet (ou Rede TCP/IP privada)

Leia mais

Introdução. Aulas. ltodi.est.ips.pt/es. Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas

Introdução. Aulas. ltodi.est.ips.pt/es. Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas Sumário Introdução Joaquim Filipe João Ascenso Engenharia de Software 2005/06 EST, Setúbal Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas 2

Leia mais

SCC-0263. Técnicas de Programação para WEB. Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br

SCC-0263. Técnicas de Programação para WEB. Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br SCC-0263 Técnicas de Programação para WEB Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br 1 Cronograma Fundamentos sobre servidores e clientes Linguagens Server e Client side

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Proposta de Estágio Ano letivo 2011 / 2012 Tema: SISMS - sistema integrado de suporte e monitorização para serviços comerciais

Proposta de Estágio Ano letivo 2011 / 2012 Tema: SISMS - sistema integrado de suporte e monitorização para serviços comerciais Proposta de Estágio Ano letivo 2011 / 2012 Tema: SISMS - sistema integrado de suporte e monitorização para serviços comerciais A Load Interactive A Load-Interactive Lda. é uma start-up tecnológica que

Leia mais

Principais inovações baseadas em nuvem Relatório de início rápido do SAP HANA Enterprise Cloud para [Nome do cliente]

Principais inovações baseadas em nuvem Relatório de início rápido do SAP HANA Enterprise Cloud para [Nome do cliente] Principais inovações baseadas em nuvem Relatório de início rápido do SAP HANA Enterprise Cloud para [Nome do cliente] [Data] Página 1 de 10 DECLARAÇÃO DE CONFIDENCIALIDADE E EXCEÇÕES DA SAP Este documento

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais

HP NonStop Server Capacity Planning

HP NonStop Server Capacity Planning HP NonStop Server Capacity Planning Serviços HP Dados técnicos Determinar futuros requisitos de capacidade de hardware para sistemas NonStop de processamento de transações online em constante crescimento

Leia mais

PROGRAMAÇÃO PARA INTERNET RICA RICH INTERNET APPLICATIONS

PROGRAMAÇÃO PARA INTERNET RICA RICH INTERNET APPLICATIONS PROGRAMAÇÃO PARA INTERNET RICA RICH INTERNET APPLICATIONS Prof. Dr. Daniel Caetano 2012-1 Objetivos Apresentar o que é uma Aplicação Rica para Internet Contextualizar tais aplicações na Web e os desafios

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Modelação, Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Test O Matic 10 de Maio de 2009 1 Índice 1 Índice... 1 2 Sumário...

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Assinare consiste na oferta de soluções e serviços na área da identificação electrónica.!

Assinare consiste na oferta de soluções e serviços na área da identificação electrónica.! Assinare Apresentação Assinare consiste na oferta de soluções e serviços na área da identificação electrónica. De forma a responder ao ambiente altamente competitivo a que as empresas e organizações hoje

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

Interface Homem Máquina para Domótica baseado em tecnologias Web

Interface Homem Máquina para Domótica baseado em tecnologias Web Interface Homem Máquina para Domótica baseado em tecnologias Web João Alexandre Oliveira Ferreira Dissertação realizada sob a orientação do Professor Doutor Mário de Sousa do Departamento de Engenharia

Leia mais

X10, Protocolo de comunicação X10, GPIO, Raspberry Pi, Interfaces X10, XHTML, CSS, PHP, JAVA, XML, XOM

X10, Protocolo de comunicação X10, GPIO, Raspberry Pi, Interfaces X10, XHTML, CSS, PHP, JAVA, XML, XOM Lista de Projetos Esta lista pretende mostrar alguns projetos realizados durante a licenciatura em Engenharia Informática, sendo que alguns projetos forma omitidos devido a sua menor importância CIICESI

Leia mais

ONE TOONE CURSOS PARTICULARES HTML5 + CSS3 + ADOBE DREAMWEAVER CC

ONE TOONE CURSOS PARTICULARES HTML5 + CSS3 + ADOBE DREAMWEAVER CC ONE TOONE CURSOS PARTICULARES HTML5 + CSS3 + ADOBE DREAMWEAVER CC Plano do Curso. Curso One. Os Cursos desenvolvidos pela One To One, são reflexo da experiência profissional no âmbito da Formação, do Design

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente 1. Quais os componentes de um sistema cliente-servidor? Clientes e servidores 2. Na visão do hardware, defina o que é cliente e o que é servidor: Clientes. Qualquer computador conectado ao sistema via

Leia mais

Oportunidades 05/05/2015

Oportunidades 05/05/2015 Oportunidades 05/05/2015 Sobre a Daitan: A Daitan é uma empresa brasileira, localizada em Campinas. Seu foco é a exportação de Serviços de Outsourcing em P&D e Serviços Profissionais em Telecomunicações,

Leia mais

Escola Superior de Tecnologia de Setúbal. Projecto Final

Escola Superior de Tecnologia de Setúbal. Projecto Final Instituto Politécnico de Setúbal Escola Superior de Tecnologia de Setúbal Departamento de Sistemas e Informática Projecto Final Computação na Internet Ano Lectivo 2002/2003 Portal de Jogos Executado por:

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projectos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

System Quality Assurance

System Quality Assurance System Quality Assurance Visão Reduzir os custos inerentes à existência de defeitos em produção, em sistemas de alta complexidade funcional e de elevada heterogeneidade tecnológica, através de um conjunto

Leia mais

Áreas de utilização do GED e o que levar em consideração no Projeto de Implantação de GED em uma empresa Simone de Abreu

Áreas de utilização do GED e o que levar em consideração no Projeto de Implantação de GED em uma empresa Simone de Abreu Áreas de utilização do GED e o que levar em consideração no Projeto de Implantação de GED em uma empresa Simone de Abreu Cerca de dois milhões de pessoas estão trabalhando em aproximadamente 300 mil projetos

Leia mais

Antonio Gomes de Araujo Laboratório de Eletrônica Industrial, Escola SENAI Anchieta São Paulo

Antonio Gomes de Araujo Laboratório de Eletrônica Industrial, Escola SENAI Anchieta São Paulo Antonio Gomes de Araujo Laboratório de Eletrônica Industrial, Escola SENAI Anchieta São Paulo Toshi-ichi Tachibana Departamento de Engenharia Naval e Oceânica, Escola Politécnica da Universidade São Paulo

Leia mais

ANEXO VII PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP. Processo de Desenvolvimento de Sistemas

ANEXO VII PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP. Processo de Desenvolvimento de Sistemas ANEXO VII PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP Processo de Desenvolvimento de Sistemas MDP - Metodologia de Desenvolvimento PROCERGS - é uma estrutura básica de definição de processos

Leia mais

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação O Business Analytics for Microsoft Business Solutions Navision ajuda-o a ter maior controlo do seu negócio, tomar rapidamente melhores decisões e equipar os seus funcionários para que estes possam contribuir

Leia mais

Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE

Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE 1 Sumário Sumário... 2 1 INTRODUÇÃO... 3 1.1 Propósito... 3 1.2 Escopo... 3 1.3 Referências... 3 2 DIRETRIZES...

Leia mais

DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0

DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0 DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0 Índice 1 - Objetivo 2 - Descrição do ambiente 2.1. Tecnologias utilizadas 2.2. Estrutura de pastas 2.3. Bibliotecas já incluídas 3 - Características gerais 4 - Criando

Leia mais

Análise estruturada de sistemas

Análise estruturada de sistemas Análise estruturada de sistemas Prof. Marcel O que é Engenharia de software Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de

Leia mais

HAT Programação Auditoria Pós. 12.1.x. abril de 2015. Versão: 2.0

HAT Programação Auditoria Pós. 12.1.x. abril de 2015. Versão: 2.0 HAT Programação Auditoria Pós 12.1.x abril de 2015 Versão: 2.0 1 Sumário 1 Introdução... 3 2 Visão do Processo... 3 3 Serviço... 5 4 Dataset... 7 5 Formulário Principal AuditoriaPos... 9 6 Arquitetura

Leia mais

Unidade 4 Concepção de WEBSITES. Fundamentos do planeamento de um website 1.1. Regras para um website eficaz 1.1.1.

Unidade 4 Concepção de WEBSITES. Fundamentos do planeamento de um website 1.1. Regras para um website eficaz 1.1.1. Unidade 4 Concepção de WEBSITES Fundamentos do planeamento de um website 1.1. Regras para um website eficaz 1.1.1. Sobre o conteúdo 1 Regras para um website eficaz sobre o conteúdo Um website é composto

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering.

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering. Parte I Requirement Engineering Gestão de Projectos Informáticos Gestão do Âmbito (Scope Management) Requirement Engineering Introduzir as noções requisitos de sistema e processo de engª de requisitos

Leia mais

Portal Web para empresa de materiais de construção civil CasaMais

Portal Web para empresa de materiais de construção civil CasaMais Portal Web para empresa de materiais de construção civil CasaMais Gilberto Leonel Dias Pereira nº 26634 Trabalho realizado sob a orientação de: Professor João Paulo Ribeiro Pereira Informática de Gestão

Leia mais

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 0 2 4 6 8 10 33 34 35 36 37 38 39 40 resolução de problemas recolha e tratamento da informação planeamento / organizção inovação

Leia mais

Fundamentos de Java. Prof. Marcelo Cohen. 1. Histórico

Fundamentos de Java. Prof. Marcelo Cohen. 1. Histórico Fundamentos de Java Prof. Marcelo Cohen 1. Histórico 1990 linguagem Oak; desenvolvimento de software embutido para eletrodomésticos S.O. para o controle de uma rede de eletrodomésticos o surgimento da

Leia mais

SICOP Sistema de Inovação, Controlo e Optimização de Produtos

SICOP Sistema de Inovação, Controlo e Optimização de Produtos SICOP Sistema de Inovação, Controlo e Optimização de Produtos Célia Alves, Liliana Monteiro, Fernanda Barbosa, Ana Borges, Jorge Barbosa* Resumo De modo a facilitar e estandardizar o ciclo de desenvolvimento,

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição INSTITUTO SUPERIOR DE CIÊNCIAS DO TRABALHO E DA EMPRESA Departamento de Ciências e Tecnologias de Informação DCTI Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI ANEXO 1 Instituição

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

CATÁLOGO DE SERVIÇOS. Consultores Associados de Organizações e Informática, Lda

CATÁLOGO DE SERVIÇOS. Consultores Associados de Organizações e Informática, Lda CATÁLOGO DE SERVIÇOS Consultores Associados de Organizações e Informática, Lda ÍNDICE ÍNDICE 2 HISTÓRICO DE ALTERAÇÕES 2 1 INTRODUÇÃO 3 2 A CASO 4 2.1 Apresentação 4 2.2 Visão, Missão e Valores 4 3 SERVIÇOS

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

MÓDULO Programação para Web 2

MÓDULO Programação para Web 2 MÓDULO Programação para Web 2 Sistemas Web na JEE OBJETIVO DO MÓDULO Arquitetura Web em aplicações JEE Conceitos iniciais Desenvolvimento Web Aplicações web tornam-se mais e mais importantes Mais e mais

Leia mais