Automatização de Testes de Software

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

Download "Automatização de Testes de Software"

Transcrição

1 Instituto Politécnico de Coimbra Instituto Superior de Engenharia Automatização de Testes de Software Dashboard QMSanalyser Márcio Filipe Alves Carvalho Relatório de Estágio para obtenção do Grau de Mestre em Automação e Comunicações em Sistemas de Energia COIMBRA Dezembro de 2010

2

3 Instituto Politécnico de Coimbra Instituto Superior de Engenharia Automatização de Testes de Software Dashboard QMSanalyser Orientador(es): Fernando José Pimentel Lopes Professor Coordenador, ISEC Inácio de Sousa Adelino da Fonseca Professor Adjunto, ISEC Mário Bugalhão Director QMS Team, Optimus Paulo Grilo Manager QMS Team, Optimus Paulo Isménio Team Leader QMS-TST, Optimus Márcio Filipe Alves Carvalho Relatório de Estágio para obtenção do Grau de Mestre em Automação e Comunicações em Sistemas de Energia COIMBRA Dezembro de 2010

4

5 Dedico este trabalho aos meus pais, cuja fé em mim me ensinou a ter fé em mim mesmo. i

6

7 Agradecimentos Agradeço aos professores orientadores Doutor Fernando José Pimentel Lopes e Doutor Inácio de Sousa Adelino da Fonseca, pelo apoio e disponibilidade manifestada, aos meus orientadores na empresa Optimus, Doutor Mário João Bugalhão, Doutor Paulo Morgado Grilo, Eng. Paulo António Isménio, pelas oportunidades, pelas ideias e sugestões apresentadas, pela atenção e apoio. Aos professores que tive durante toda a minha vida, pois foram os semeadores de ideias que contribuíram para o meu desenvolvimento intelectual. À minha família, em especial aos meus pais e irmã, pelo apoio e compreensão. Para finalizar, o meu grande agradecimento aos meus amigos e companheiros de trabalho pela convivência e amizade nos bons e maus momentos. iii

8

9 Resumo Elaborado no âmbito do Mestrado em Automação e Comunicações em Sistemas de Energia, o presente Relatório de Estágio descreve o trabalho desenvolvido na empresa Optimus na equipa de Quality Management Systems (QMS). A equipa de QMS tem como principal objectivo a garantia de qualidade de qualquer software que se destine a ser utilizado na empresa Optimus. Esta garantia, consiste em assegurar a qualidade de um software associado aos processos de negócio da empresa, efectuando diversos tipos de testes. Assim, o presente relatório apresenta metodologias e processos utilizados em Testes de Software. Testar um software, é um dos processos do seu ciclo de desenvolvimento com o objectivo de exercitar um conjunto de acções nesse software a fim de identificar possíveis erros. Por norma, estes testes são previamente definidos e realizados manualmente. Assim, para a realização deste Estágio foi lançado o desafio de automatizar casos de teste com o auxílio de ferramentas específicas, analisar o resultado final do automatismo e ter a possibilidade de, através de um DashBoard, analisar os erros gerados no servidor do software. Palavras chave: Qualidade de software; Testes de software; Quality Management Systems; Software em Processos de Negócios. v

10

11 Abstract Prepared under the Master in Automation and Communications in Energy Systems, this Internship Report describes the work carried out at Optimus, in the Quality Management Systems (QMS) team. The major goal of the QMS team is to achieve quality assurance of the software that is intended to be used at the Optimus company. This is required to ensure the quality of the software programs associated with the company's business processes, by conducting various types of tests. Therefore, this report presents methodologies and processes used in software testing. Software testing is a process of a software development cycle, achieved by performing a set of "actions" in the software, in order to identify possible errors. As a rule, these tests are pre-defined and manually performed. Thus, in the present Internship the challenge was to automatize test cases with the help of specific tools, to analyze the outcome of the automatism and be able to, through a developed DashBoard, analyze the errors generated in the software server. Keywords: Software Quality, Software Testing, Quality Management Systems, Software Process and Business. vii

12

13 Índice Agradecimentos iii Resumo v Abstract vii Índice ix Lista de Figuras xiii Lista de Tabelas xv omenclatura xvii 1 Introdução Objectivos Estrutura do Relatório 3 2 Enquadramento Empresarial Equipa de QMS Enquadramento Pessoal na Equipa 5 3 Ferramentas existentes no Mercado Enquadramento Histórico Selenium IDE imacros Watir TestMaker Winrunner Quick Test Pro LoadRunner Conclusão 13 4 Testes de Software Introdução Objectivo dos Testes de Software 15 ix

14 4.3 Terminologia Porquê realizar testes de Software? Enquadramento da Fase de Teste Fases de Teste Plano de Teste Caso de Teste Tipos de Teste Tipos de Testes / Nível do processo de Teste Técnicas de Testes de Software Teste White-Box (Caixa-Branca) Teste Black-Box (Caixa-Preta) Custos da Qualidade em Testes de Software Uma nova abordagem: Automatização Porquê Automatizar? Âmbito da Automatização na Optimus 34 5 Automatismos Introdução Arquitectura dos Testes de Regressão Ferramenta de Automatização Quick Test Pro Principais Funcionalidades da Ferramenta QuickTest Professional Técnicas para implementação de scripts de testes automáticos Fases de Construção de um Script Estrutura de um Servidor de Testes de Regressão Ferramenta Quality Center Arquitectura de funcionamento Quality Center-QTP Produtos Automatizados Arquitectura dos Testes de Carga Fases de Construção de um Script Ferramenta LoadRunner 57 6 DashBoard Introdução Estrutura do Servidor 62 x

15 6.3 Funcionalidades da Ferramenta Splunk DashBoard QMSAnalyser Demonstração da utilidade da Ferramenta 67 7 Conclusão 69 Referências 71 Anexo I Exemplo de Caso de Teste 75 Exemplo Caso de Teste Site CPM 75 Anexo II - Exemplos de Automatismos 78 Exemplo Script Quality Center Site CPM 78 Exemplo Script Controlo ou Principal Site CPM 78 Exemplo Script Suporte Site CPM 79 Exemplo Script Suporte Login Site CPM 80 Exemplo Script Suporte Logout Site CPM 81 Exemplo Script Controlo ou Principal Site Optimus 81 Exemplo Script Suporte Site Optimus 81 Exemplo Script Suporte Login Site Optimus 83 Exemplo Script Suporte Logout Site Optimus 84 Exemplo Script Controlo ou Principal Site Kanguru 84 Exemplo Script Suporte Site Kanguru 84 Anexo III Exemplos de Relatórios 86 Exemplo de ewsletter da Equipa de QMS 86 Exemplo de de Execução de Testes de Carga 87 xi

16 xii

17 Lista de Figuras Figura 3.1. Software Selenium IDE (add-ons). Figura 3.2. Software Selenium IDE. Figura 3.3. Software imacros. Figura 3.4. Software Watir. Figura 3.5. Software TestMaker. Figura 3.6. Software Winrunner. Figura 3.7. Software Quick Test Profissional. Figura 3.8. Software Loadrunner. Figura 4.1. Modelo de Ciclo de Vida em Cascata (adaptado de [Sommerville, 2000] ). Figura 4.2. Modelo de Ciclo de Vida em V (adaptada de [Pressman,2000]). Figura 4.2. Modelo de Ciclo de Vida em V (adaptada de [Pressman,2000]). Figura 4.3. Visão Geral de um Processo de Testes (adaptada de [Sommerville, 2000]). Figura 4.4. Plano de Testes. Figura 4.5. Exemplo de um Caso de Teste. Figura 4.6. Diferenças entre Teste de Carga/Volume/Stress. Figura 4.7. Técnica de White-Box ou (Caixa-Branca). Figura 4.8. Técnica de Caixa Preta ou Black-Box. Figura 4.9. Custos da Qualidade (adaptado de [Miguel, 2004]). Figura Custos da correcção de erro (adaptado de [Miguel, 2004]). Figura 5.1. Actividades de teste para automatizar casos de teste na equipa de QMS [adaptado de Correia at al, 2004]. Figura 5.2. Arquitectura Testes de Regressão Equipa de QMS. Figura 5.3. Add-ins da Ferramenta QuickTest Professional. Figura 5.4. Ferramenta QuickTest Professional. Figura 5.5. Ferramenta QuickTest Professional (Record). Figura 5.6. Ferramenta QuickTest Professional (Object Repository). Figura 5.7. Ferramenta QuickTest Professional (CheckPoints). Figura 5.8. Exemplo da estrutura de um Script (Técnica Keyword-driven). Figura 5.9. Fases de construção de um script. Figura Estrutura de um script de Teste de Regressão implementado na equipa QMS. Figura Estrutura da pasta sourcecode um servidor de Teste de Regressão. Figura Estrutura de um servidor de Teste de Regressão. xiii

18 Figura Ferramenta Quality Center (Página Login). Figura Ferramenta Quality Center (Página Test Plan). Figura Ferramenta Quality Center (Página Test Lab). Figura Ferramenta Quality Center (Página Test Instance Properties). Figura Sincronização da ferramenta Quality Center com servidor de Testes de Regressão. Figura Scripts Automatizados. Figura 5.19 Arquitectura dos Scripts de Carga. Figura Estrutura de um script de Teste de Carga implementado na equipa QMS. Figura Ferramenta LoadRunner. Figura Janela de definição dos Dados de Teste. Figura Estrutura de um script de Teste de Carga. Figura LoadRunner Controller (Definição de Cenário). Figura LoadRunner Controller (Análise da evolução do Cenário). Figura LoadRunner Analysis (Análise do Resultado do Cenário). Figura 6.1. Estrutura Servidor Splunk. Figura 6.2. Definir Pesquisa no Splunk. Figura 6.3. Opções disponibilizadas pela ferramenta. Figura 6.4. Opção Data Inputs. Figura 6.5. Opção main. Figura 6.6. Opção Indexes. Figura 6.7. DashBoard QMSAnaliser. Figura 6.8. DashBoard QMSAnaliser Problema 1. Figura 6.9. DashBoard QMSAnaliser Problema 2. Figura DashBoard QMSAnaliser Problema 3. xiv

19 Lista de Tabelas Tabela 3.1. Ferramentas de Automatização. Tabela 4.1. Características da Norma ISO/IEC Tabela 4.2. Fase/Tipo de Testes. xv

20

21 omenclatura Abreviaturas ISSO IEEE HP ISTQB QMS QMS-CM QMS-CA QMS-IQM QMS-TST Logs Internacional Standard Organization Institute of Electrical and Electronics Engineers Hewlett-Packard International Software Testing Qualifications Board Quality Management Systems Quality Management Systems - Configuration Management Quality Management Systems - Quality Assurance Quality Management Systems - Integrated Quality Management Quality Management Systems - Test Expressão utilizada para descrever o processo de registo de eventos num ficheiro de dados num determinado servidor DashBoard Expressão utilizada para indicar um "painel de indicadores" Script Patches Web TI SI Browser Site SOA DHCP D S FTP TFTP http HTTPS IP TCP Programa de software escrito em linguagem de script Ficheiro de actualização ou melhoria de um determinado software Word wide Web Tecnologia da Informação Sistemas da Informação Expressão utilizada para descrever avegador de Internet Expressão utilizada para descrever Portal Service-Oriented Architecture Dynamic Host Control Protocol Domain ame System File Transfer Protocol Trivial File Transfer Protocol Hyper Text Transfer Protocol Hyper Text Transfer Protocol Secure Internet Protocol Transmission Control Protocol xvii

22 SMTP POP IMAP HSDPA Downlink Plugin/ Add-in / Add-on XML HTML PHP SGPS GSM GPRS UMTS Simple Mail Transfer Protocol Post Office Protocol Internet Message Access Protocol High-Speed Downlink Packet Access Capacidade/velocidade de transferência de dados utilizando o protocolo HSDPA Programa de software usado para adicionar funções a outros programas, fornecendo alguma funcionalidade especial ou muito específica extensible Markup Language HyperText Markup Language Hypertext Preprocessor Sociedade Gestora de Participações Sociais Global System for Mobile Communications General Packet Radio Service Universal Mobile Telecommunication System xviii

23 1 Introdução Um dos grandes desafios para a Engenharia de Software tem sido desenvolver software de qualidade tendo em conta o prazo, o esforço e os custos estabelecidos. Ao mesmo tempo que se requer software cada vez mais complexo, o mercado exige produtos de maior qualidade. Nesta direcção, as empresas que desenvolvem software têm-se preocupado cada vez mais com a qualidade dos produtos de software que criam. Desta forma, as empresas têm criado mecanismos para que a qualidade possa ser planeada, controlada, avaliada e alcançada [Rocha at al,2001]. Controlar a qualidade de sistemas de software é um grande desafio devido à alta complexidade dos produtos e às inúmeras dificuldades relacionadas com o processo de desenvolvimento, que envolve questões humanas, técnicas, burocráticas, de negócio e políticas. Idealmente, os sistemas de software devem não só fazer correctamente o que o cliente necessita, mas também fazê-lo de forma segura, eficiente e escalável, flexível, de fácil manutenção e evolução. Salvo honrosas excepções, na indústria de desenvolvimento de software, estas características são muitas vezes asseguradas através de testes manuais, após a finalização de módulos específicos ou até mesmo do software completo. O teste pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode, e normalmente, varia significativamente de sistema para sistema. Segundo a norma ISO 9126, norma ISO que estabelece um modelo de qualidade para produtos de software e que se enquadra no modelo de qualidade das normas da família 9000, os atributos qualitativos previstos são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De forma geral, medir o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de verificação, a expectativa do cliente diz respeito ao processo de validação do software [Qualidade, 2010]. Assim, um teste de software pode definir-se como o processo de executar o software de forma controlada com o objectivo de avaliar se o mesmo se comporta conforme o especificado [Beizer, 1995]. A actividade de testes é uma etapa crítica para o desenvolvimento de um software. Embora durante todo o processo de desenvolvimento sejam utilizados métodos, técnicas e ferramentas com o objectivo de evitar que erros sejam introduzidos no produto, não significa que sejam eliminados 1

24 todos os erros, assim a actividade contínua de testes ao longo do desenvolvimento e depois da conclusão do software é de fundamental importância para a eliminação dos erros que persistem. A execução de testes de software pode ser efectuada tanto de forma manual como automatizada. A execução manual consiste na reprodução por uma pessoa do teste previamente definido e documentado. Já a execução automática consiste na automação do processo do teste manual. Para a execução dos testes automatizados são desenvolvidos scripts que simulam as tarefas manuais e serão executados automaticamente. Cada uma destas formas tem as suas vantagens e desvantagens, no entanto, salienta-se que os testes manuais têm um grande problema em relação ao tempo de execução, assim como em relação ao número de vezes que podem ser executados num curto espaço de tempo. A realização de testes automatizados, além de possibilitar a redução do ciclo de testes, também permite aumentar a abrangência dos testes e, consequentemente, a sua qualidade, porque permite que os Testers (ver Secção 4.3) utilizem os seus esforços noutros tipos de teste ou em testes que não possam ser automatizados. 1.1 Objectivos O objectivo deste Estágio passa por aplicar conhecimentos já adquiridos, assim como aumentar o nível de conhecimento sobre testes de software. Juntamente com o levantamento de ferramentas existentes no mercado, vamos automatizar casos de testes, analisar erros de um determinado software e analisar os logs de um determinado servidor utilizando um DashBoard. A metodologia de funcionamento do DashBoard é similar à metodologia de um sensor inteligente, isto é, o DashBoard está sempre a escutar a actividade gerada nos logs e segundo condições pré-definidas, tomará decisões e efectuará tarefas associadas à decisão. O dashboard, também terá a possibilidade de definir novas condições de decisão. A actividade gerada nos logs surge dos automatismos criados tendo como base casos de teste. Estes automatismos, são scripts implementados utilizando ferramentas específicas. Os scripts realizarão a navegação por uma determinada página Web, efectuarão a inserção e selecção de dados, assim como a detecção de falhas na referida página. Por fim, efectuaram uma validação consultando dados numa Base de Dados Oracle. Nesta sequência, serão implementados vários scripts tendo em conta algumas das aplicações Web existentes na empresa Optimus. 2

25 1.2 Estrutura do Relatório Estruturalmente este trabalho está dividido em sete capítulos, cada um composto por sub-capítulos. O relatório inicia-se com uma introdução, que inclui os objectivos e as linhas gerais propostas para o período de Estágio. Assim, no Capítulo I, Introdução, como referido anteriormente, é desenvolvida uma introdução e são apresentados os objectivos, tendo como base o tema do Estágio. O Capítulo II, Ferramentas existentes no Mercado, é dedicado à análise de ferramentas existentes no mercado para a automatização de casos de teste e para a análise de logs de servidores. O Capítulo III, Enquadramento Empresarial, retrata o enquadramento geral, do qual faz parte uma descrição da equipa onde foi desenvolvido o Estágio, os objectivos e a sua importância. O Capítulo IV, Testes de Software, faz uma introdução aos testes de software, tipos de testes, metodologias, vantagens e desvantagens da automatização de testes. O Capítulo V, Automatismos, aborda os automatismos desenvolvidos ao longo do Estágio, descreve a sua arquitectura e modo de funcionamento, tendo em conta as ferramentas já utilizadas na empresa e a forma como os Testers podem interagir com os automatismos sem causar impacto na forma como já funcionavam. Neste capítulo, além da descrição das ferramentas utilizadas, também são abordadas as características de funcionamento dessas mesmas ferramentas. O Capítulo VI, DashBoard, apresenta a arquitectura implementada para o desenvolvimento do DashBoard, a metodologia de funcionamento e as suas características. O Capítulo VII, Conclusão, proporciona uma análise e reflexão sobre o trabalho apresentado assim como um conjunto de sugestões para desenvolvimentos futuros. No Anexo I e no Anexo II, encontram-se um Caso de Teste e um conjunto de scripts exemplo, respectivamente. Por fim, no Anexo III, encontram-se exemplos da informação enviada para outras equipas da área de Sistemas de Informação da empresa Optimus, relativa aos scripts automatizados. Por razões de confidencialidade o número de exemplos é limitado. 3

26 2 Enquadramento Empresarial O presente Estágio foi realizado na equipa de Quality Management System da empresa Optimus. Esta equipa destaca as políticas e procedimentos necessários para a melhoria e controlo da qualidade de software das diversas aplicações desenvolvidas pela empresa Optimus. A Optimus é uma operadora de Telecomunicações Móveis Portuguesa, sendo portadora de licenças de utilização GSM e UMTS e é gerida a 100% pela Sonaecom SGPS. A Sonaecom actua em três áreas principais de negócio, designadamente: Telecomunicações (Optimus); Media (Público) e Software e Sistemas de Informação (Bizdirect, Mainroad, WeDo e Saphety). Constituída no final de 1997 como Optimus Telecomunicações, S.A., iniciou as suas operações no sistema GSM em 15 de Setembro de Em 2005, com o nome comercial de Kanguru, lança o serviço de Internet sem fios através do GPRS e 3G, com velocidades de downlink acima de 386 kbits/s. Este serviço sofreu uma mudança nas suas características em Maio de 2006 com o lançamento do Kanguru Xpress, que utiliza HSDPA (protocolo de telefonia móvel também chamado 3.5G) com uma velocidade acima dos 1.8 Mbits/s. A 8 de Janeiro de 2008 é lançada oficialmente a nova imagem da empresa. O boomerang, utilizado nos últimos 10 anos, foi trocado pelo magma, transmitindo uma ideia de organismo vivo, moderno e facilmente moldável. Em 2010, acontece a fusão da Optimus com a Clix, sendo a Optimus a empresa única de telecomunicações da Sonaecom. Com a integração total do Clix, a Optimus é hoje o único operador integrado de telecomunicações em Portugal e a marca única da Sonaecom para o sector das Telecomunicações. Cobrindo todos os segmentos de mercado - Residencial, Particulares, Mass Business, Corporate e Wholesalede conta com cerca de 4 milhões de utilizadores, dos quais 3,3 milhões no móvel e 514 mil no fixo, servindo directamente 1 em cada 3 utilizadores em Portugal (empresas e particulares) com soluções de última geração de Voz, Internet, Televisão e Dados, através de terminais móveis ou fixos, permitindo-lhes usufruir de múltiplas soluções adaptáveis a cada perfil [Sonaecom, 2010] [Optimus, 2010]. 2.1 Equipa de QMS A equipa de QMS divide-se em quatro sub-equipas: 4

27 Integrated Quality Management (QMS-IQM) A equipa IQM visa estabelecer o contacto com as outras áreas que vão trabalhar com a equipa de QMS, isto é, assegura o envolvimento das outras equipas com a equipa de QMS de forma a reduzir o risco de integração e sincronização com as outras equipas de outras áreas. Esta equipa faz uma ponte com as outras áreas de negócio existindo assim uma melhor comunicação entre equipas; Configuration Management (QMS-CM) A equipa de CM, tem como função coordenar e controlar: código, requisitos, documentação, problemas, solicitações de mudança, ferramentas / compiladores / bibliotecas / patches; Quality Assurance (QMS-QA) A equipa de QA é responsável por garantir a qualidade do produto ao longo do tempo. É responsável por verificar que durante a fase de produção os problemas encontrados no produto são resolvidos e restantes funcionalidades continuam a funcionar correctamente; Test (QMS-TST ) Tendo como referencia as normas elaboradas pela International Software Testing Qualifications Board (ISTQB) a equipa de Test (TST) é responsável pela fase de testes de software das diversas aplicações desenvolvidas pela empresa Optimus. A fase de testes desempenha um papel crucial na garantia da qualidade do software, uma vez que valida o cumprimento dos requisitos definidos. A equipa de QMS-TST é responsável pelo registo e gestão de defeitos do software a testar. A equipa efectua o relacionamento directo entre defeitos e casos de teste, isto é, para cada caso de teste falhado é disponibilizada a informação do defeito associado. 2.2 Enquadramento Pessoal na Equipa A realização deste Estágio foi associada à equipa QMS-TST. Para o período de duração do Estágio foi lançado o objectivo de automatizar casos de testes e analisar os respectivos erros, utilizando ferramentas específicas para automatização. Outro objectivo proposto foi encontrar uma forma de analisar os logs de um determinado servidor utilizando um DashBoard. Assim, ao longo deste relatório descrevem-se as actividades exercidas assim como as ferramentas utilizadas. O Estágio decorreu de Janeiro a Setembro de

28 6

29 3 Ferramentas existentes no Mercado Tendo em conta os objectivos propostos para a realização do Estágio, o presente capítulo vai descrever algumas das ferramentas existentes no mercado. As características das respectivas ferramentas serão utilizadas para determinar a melhor estratégia a seguir durante o período de Estágio. Descreve-se nesta Secção algumas das ferramentas existentes no mercado que permitem realizarem a tarefa de automatização de casos de teste de software. 3.1 Enquadramento Histórico As primeiras ferramentas de testes de software surgiram por volta de 1980 e as suas principais funcionalidades baseavam-se no debuging do software. Após essas ferramentas ganharem popularidade, surgiram as ferramentas de gestão de testes que tinham como objectivo organizar e guardar dados dos testes, organizarem o resultado da execução dos testes e apresentar relatórios de testes. Por volta de 1995 surgiram as primeiras ferramentas para automatização de casos de testes. Estas eram inicialmente focadas em medições básicas de algumas plataformas. Hoje em dia as ferramentas de automatização são de fácil utilização e permitem realizar um maior número de funções em relação às ferramentas desenvolvidas inicialmente. De salientar, que este tipo de ferramentas encontra-se em crescente desenvolvimento e é uma aposta das grandes companhias de software como IBM e a HP. Este facto, deve-se à automatização de testes de software ser vista como uma das principais medidas para melhorar a eficiência da actividade de teste, agregar qualidade ao produto e antecipar a descoberta de falhas e incompatibilidades, reduzindo assim o custo do projecto e melhorando a produtividade a vários níveis [Ferramentas, 2010] [Vinicius, 2008] [Fantinato at al, 2008]. Assim, várias soluções têm surgido no mercado, sendo algumas delas descritas no sub-capítulo seguinte. 3.2 Selenium IDE Selenium IDE é uma ferramenta que permite testar aplicações Web de forma automatizada. É um Add-on do Firefox como se pode visualizar pela Figura 3.1 e o seu modo de funcionamento consiste em gravar passo-a-passo os testes que o utilizador realiza na aplicação, isto é, grava exactamente as acções que o utilizador de uma aplicação Web realiza. Com os testes gravados, é 7

30 possível executar repetidamente as acções previamente realizadas. Dessa forma, o utilizador precisará de executar os testes manualmente apenas uma única vez e o processo repetitivo será realizado pela ferramenta. Figura 3.1. Software Selenium IDE (add-ons). Como se pode visualizar na Figura 3.2, o Selenium IDE fica instalado na caixa de ferramentas do Firefox. O modo de utilização consiste em abrir o Selenium IDE, seleccionar a opção de gravar, minimizar a janela e começar a realizar os testes. Enquanto o teste é executado, a ferramenta está a gravar todos os passos. Ao acabar de executar um caso de teste e maximizar a aplicação novamente e após parar o modo de gravação automático, pode-se observar os comandos gerados pela aplicação, que são função dos passos executados pelo operador. Figura 3.2. Software Selenium IDE. O teste deve ser gravado no formato.html. Assim, os testes podem ser abertos posteriormente e executados automaticamente. Esta ferramenta é de fácil instalação e utilização mas não pode ser utilizada noutros Browsers como por exemplo Internet Explorer, nem pode ser utilizado noutros tipos de aplicações. 8

31 3.3 imacros O Software imacros foi desenvolvido para automatizar as tarefas mais repetitivas na Web como visitar os mesmos sites todos os dias, preencher formulários, lembrar senhas, realizar download de informações de outros sites, capturar a Web (conseguir dados de múltiplos sites), etc. A grande vantagem é que se pode manter as Macros no computador para utilização própria, ou pode-se partilhá-las com outros utilizadores adicionando-as a um Blog ou Intranet da empresa. A Figura 3.3 ilustra o interface do Software imacros. O seu modo de funcionamento consiste em seleccionar o botão de Play e começar a realizar os testes. Enquanto o teste é executado, o imacros grava todos os passos. Ao acabar de executar um caso de teste, ao seleccionar o botão Stop termina a gravação e pode-se observar os comandos gerados. Para executar novamente a navegação basta seleccionar no botão Play (Loop) (Figura.3.2). Figura 3.3. Software imacros. 3.4 Watir Watir é uma biblioteca para a linguagem Ruby que permite interagir com o Internet Explorer, Firefox e até o Safari (usando uma biblioteca especifica) para simular a experiência de navegação do utilizador no sistema. Os scripts de teste são escritos na linguagem de programação Ruby, como se pode visualizar pela Figura 3.4. Ruby é uma linguagem relativamente recente. Foi criada em 1995 pelo japonês Yuri Matsumoto. Uma linguagem directa, orientada a objectos, simples de se aprender e trabalhar. Com muitas semelhanças ao Perl, SmallTalk e Python. Uma Linguagem multiplataforma, sendo assim suportada por diversos tipos de sistemas operativos como Linux, Windows, e outros [Ruby, 2010]. Possui muitas features interessantes como o Ruby Gems, Code Blocks, Mixins, entre outras. No entanto, o Watir já não é tão fácil de instalar e utilizar como o Selenium ou 9

32 o imacros. Esta ferramenta é mais complexa mas apresenta mais funcionalidades em relação ao software Selenium ou imacros. Figura 3.4. Software Watir. 3.5 TestMaker A ferramenta PushToTest Test Maker ou como é chamada TestMaker, é uma ferramenta baseada na arquitetura SOA(Service-Oriented Architecture) e é Open-Source. Na Figura 3.5 apresenta-se uma ilustração da ferramenta. Nela é possível fazer Testes de Funcionalidade, Testes Unitários, Testes de Integração, Testes de Regressão e Testes de Carga em aplicações SOA, incluindo Wizards e Recorders (gravação de scripts), sendo a sua interface muito amigável e de fácil utilização pelos analistas de testes. Inúmeras linguagens são suportadas pela ferramenta como PHP, Ruby, Java e outras, além de claro dar suporte a Web Services, AJAX e protocolos como HTTP, HTTPS, SOAP, XML, SMTP, POP e IMAP [Pushtotest, 2009] [Testexpert,2009]. Figura 3.5. Software TestMaker. 10

33 3.6 Winrunner O WinRunner é uma ferramenta do tipo Capture and Playback, isto é, grava passo a passo as acções que o utilizador de uma aplicação Web realiza e de seguida permite executar essas acções. A interface com o utilizador apresenta-se na Figura 3.6. A ferramenta WinRunner fornece uma linguagem estruturada, semelhante a C, chamada TSL (Test Script Language). O seu funcionamento é muito semelhante ao funcionamento das ferramentas referidas anteriormente, no entanto, o código gerado é diferente e permite criar scripts de maior complexidade. Figura 3.6. Software Winrunner. 3.7 Quick Test Pro O QuickTest Professional (QTP) é uma evolução da ferramenta Winrunner. Esta ferramenta elimina algumas limitações da ferramenta Winrunner e oferece mais funcionalidades, como por exemplo, Add-ins para interligação com outras ferramentas. Tal como o Winrunner, o seu funcionamento é do tipo Capture and Playback. Na Figura 3.7 ilustra-se a interface com o utilizador. O QuickTest Professional usa a linguagem Visual Basic Scripting Edition (VBScript) para especificar uma actividade executada na aplicação em teste. De salientar que o código produzido pelo QTP é gerado como em todas as ferramentas referidas até ao momento. 11

34 Figura 3.7. Software Quick Test Profissional. 3.8 LoadRunner O LoadRunner é também uma ferramenta do tipo Capture and Playback. O LoadRunner usa a linguagem C para gerar código quando utilizado por exemplo para simular um caso de teste. No entanto, este software, além de permitir criar automatismos, serve para simular vários utilizadores a utilizarem simultaneamente uma aplicação, ou seja, permite efectuar testes de carga. Uma ilustração do interface é apresentada na Figura 3.8. Figura 3.8. Software Loadrunner. 12

35 3.9 Conclusão Para a realização de testes automatizados existem ferramentas prontas que auxiliam na criação, desenvolvimento e manutenção desses testes. Estas permitem que scripts com testes automatizados sejam criados, alterados e executados. Assim, tendo em mente o que são testes automatizados, o ponto de partida para este estágio foi efectuar um levantamento das tecnologias existentes no mercado. Do conjunto das ferramentas pesquisadas, algumas são gratuitas e outras não, todas possuem vários pontos positivos, e também vários pontos negativos. A Tabela 3.1 ilustra de forma comparativa algumas das características deste conjunto de ferramentas. Tabela 3.1. Ferramentas de Automatização. Ferramentas Caracteristicas LoadRunner Winrunner QTP TestMaker Watir imacros Selenium Tempo de Aprendizagem Alta Alta Alta Média Média Média Média Versatilidade Alta Alta Alta Média Baixa Baixa Baixa Estabilidade Alta Alta Alta Média Média Média Média Actualizações Hewlett-Packard Hewlett-Packard Hewlett-Packard pushtotest Linguagem Ruby e framework Watir Firefox Framework Selenium Open Source Não Não Não Sim Sim Sim Sim Depois de analisadas e testadas as ferramentas, e tendo em consideração os objectivos propostos, concluiu-se que a ferramenta QuickTest Professional e a ferramenta LoadRunner são as que melhor satisfazem os requisitos. Estas são ferramentas poderosas que permitem a criação de testes automatizados de todos os tipos, para todas as aplicações. Esta flexibilidade obtém-se adicionando os Add-Ins disponíveis para cada caso específico. Além disso, estas ferramentas já são uma referência no mercado, são estáveis e versáteis. No entanto, são ferramentas completas e com alguma complexidade, caso se pretenda ir para além de gravar e executar, logo, necessitam de tempo de aprendizagem para poderem ser convenientemente exploradas. Outra grande vantagem destas ferramentas é que possibilitam a interligação com outras ferramentas da HP, utilizadas na equipa de QMS. 13

36 4 Testes de Software Nos últimos anos, tem-se constatado que o mercado de desenvolvimento de software aumentou a sua competitividade, devido à modernização das tecnologias envolvidas e devido ao amadurecimento da capacidade em desenvolver software. Assim, a gama de soluções em tecnologias da informação, para atender às necessidades das organizações consumidoras, tem aumentado consideravelmente, o que acaba por dificultar a escolha dos utilizadores, no momento de adquirir um produto. Neste cenário de competitividade, as organizações consumidoras na ocasião de optar por um software, baseiam-se cada vez mais em critérios de qualidade. Um dos pilares para a garantia dessa qualidade do produto de software é o processo de teste. Com o objectivo de se conhecer melhor como o processo de teste faz parte da garantia de qualidade de um produto de software, abordam-se neste capítulo alguns conceitos, metodologias e técnicas de testes de software. Esta abordagem teórica é de elevada importância dado que é a partir dessa fundamentação que se realiza toda a actividade de testes na equipa de QMS-TST [Azevedo, 2008] [Tozelli, 2008] [Ferramentas, 2010]. 4.1 Introdução No mercado de software actual a preocupação por criar produtos de qualidade e sem erros tem conduzido a que as empresas procurem modelos e processos que garantam qualidade de forma a satisfazer as necessidades dos seus clientes. Projectos mal sucedidos, com prazos vencidos e produtos com defeitos, conduzem à insatisfação dos clientes, a gastos elevados com manutenção e comprometem a imagem da empresa. Garantir a qualidade do software representa um conjunto de actividades de prevenção que devem ser aplicadas e geridas ao longo de todo o processo de desenvolvimento, envolvendo revisões técnicas formais, múltiplas fases de teste, controle da documentação de software e das mudanças nos procedimentos, a fim de garantir ao cliente que o software desenvolvido estará de acordo com as especificações e atendendo às suas necessidades [Pressmann, 1995] [Myers et al, 2004]. Estas actividades de prevenção começam no início do processo de desenvolvimento do software, com a revisão dos requisitos, e continuam até que o teste do produto esteja completo e 14

37 implantado. Através destes procedimentos pode-se obter melhorias drásticas na eficácia e eficiência dos testes, e consequentemente aumentar a qualidade do software [Bastos, 2007]. Ao longo deste Capítulo descrevem-se conceitos e procedimentos utilizados para a obtenção da qualidade de um software pela equipa de QMS. Apresenta-se os objectivos e os benefícios da fase de testes, assim como, o seu enquadramento na fase de desenvolvimento de um software. 4.2 Objectivo dos Testes de Software O objectivo principal de um teste de software consiste em definir se a implementação deste cumpre todas as especificações e expectativas definidas e esperadas pelo cliente, ou seja, o objectivo é verificar se o que foi especificado na fase de requisitos é o que realmente foi desenvolvido. Quando se verifica se o software implementado cumpre todas as especificações e expectativas definidas e esperadas pelo cliente, também se procura por erros no software. O teste de software deve ser visto como uma parcela no processo de qualidade deste. Para se classificar um software com um determinado padrão de qualidade, este tem de possuir determinados atributos definidos segundo a norma ISO/IEC Esta norma foi publicada em 1991 e representa a actual padronização mundial para a qualidade de produtos de software. Assim, a norma ISO 9126 é utilizada para a definição dos requisitos de qualidade de um produto de software. Esta estabelece critérios ou medidas de qualidade tais como: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade, tal como ilustrado na Tabela 4.1 [Pressmann, 1995] [IEEE, 1990] [Pfleeger, 2004]. Tabela 4.1. Características da Norma ISO/IEC Característica Sub-característica Pergunta chave para a sub-característica Adequação Propõe-se a fazer o que é apropriado? Funcionalidade Acurácia Faz o que foi proposto de forma correcta? (satisfaz as Interoperbilidade Interage com os sistemas especificados? necessidades?) Conformidade Está de acordo com as normas, leis, etc.? Segurança de acesso Evita acesso não autorizado aos dados? Maturidade Com que frequência apresenta falhas? Confiabilidade Tolerância a falhas Ocorrendo falhas, como reage? (é imune a falhas?) Recuperabilidade É capaz de recuperar dados em caso de falha? Intelegibilidade É fácil entender o conceito e a aplicação? Usabilidade Apreensibilidade É fácil de aprender a usar? (é fácil de usar?) Operacionalidade É fácil de utilizar e controlar? Eficiência Tempo Qual é o tempo de resposta, a velocidade de execução? Recursos Quanto utiliza de recursos da máq? Durante quanto tempo? Analisabilidade É fácil de encontrar uma falha, quando ocorre? Manuseabilidade Modificabilidade É fácil modificar e adaptar? (é fácil de Estabilidade Há grande risco quando se faz alterações? modificar?) Testabilidade É fácil testar quando se faz alterações? Portabilidade Adaptabilidade É fácil adaptar a outros ambientes? Capac. para ser instalado É fácil instalar noutros ambientes? 15

38 (é fácil de usar noutro ambiente?) Conformidade Capac. para substituir Está de acordo com padrões de portabilidade? É fácil substituir outro? A Tabela 4.1 apresenta um conjunto de características e sub-características, definidas na norma que devem ser verificadas pelo software, para que este seja considerado um "software de qualidade". 4.3 Terminologia O IEEE tem realizado vários esforços de padronização, entre eles a definição da terminologia utilizada no contexto da Engenharia de Software. O padrão IEEE N.º diferencia os termos [IEEE, 1990]: defeito (fault) Passo, processo ou definição de dados incorrecto, como por exemplo, comando incorrecto; engano (mistake) Acção humana que produz um resultado incorrecto, como por exemplo, uma acção incorrecta realizada pelo programador; erro (error) Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermédio incorrecto ou resultado inesperado na execução do programa constitui um erro; falha (failure) Produção de uma saída incorrecta em relação ao especificado; Tester Responsável por realizar tarefas que vão desde o levantamento de requisitos até à execução do teste; Especificação dos requisitos Define (tudo) aquilo que o utilizador pretende de um determinado sistema/produto. 4.4 Porquê realizar testes de Software? Existem vários factores que justificam a realização de testes de software. No entanto, os principais factores que levam os gestores de Tecnologias de Informação (TI) à realização de testes de software são a diminuição do risco, a diminuição dos custos associados à produção e manutenção e garantir que todas as especificações e expectativas definidas e esperadas pelo cliente ou serviço 16

39 são cumpridas, para que não exista a insatisfação do cliente ou serviço. Outro factor que torna extremamente importante a realização de testes de software é o facto das organizações dependerem cada vez mais de sistemas que suportam os seus processos vitais de negócio. Além disso, os sistemas de informação estão a tornar-se cada vez mais complexos, incluindo muitas componentes. Associado a estes aspectos está a vertente financeira, um dos elementos que mais preocupa os gestores na área das TI. Assim, os custos podem ser elevados se não se testar devidamente o software. Nomeadamente, se forem associados à perda de qualidade com impacto nos produtos disponibilizados ou nos serviços prestados ao cliente [William, 2000][Ron, 2005][Almeida, 2010 ]. Além dos benefícios da prática de testes de software já descritos na Secção 4.4, outros benefícios práticos e importantes são [Teste, 2010] : - Optimização do processo de desenvolvimento; - Melhoria da qualidade na cadeia de desenvolvimento (requisitos, implementação, documentação); - Garantia de entrega dos requisitos; - Imposição de critérios de qualidade bem definidos e claros aos fornecedores de software; - Cliente mais satisfeito. Outro benefício importante da prática de testes tem a ver com o custo final da resolução de erros (ver Secção 4.12). 4.5 Enquadramento da Fase de Teste A Fase de Testes enquadra-se numa das etapas do ciclo de desenvolvimento do software, no entanto, a fase de testes é executada conforme o modelo de desenvolvimento do software. Alguns dos modelos de desenvolvimento de software mais utilizados são: Modelo em Cascata, Modelo em Espiral, Modelo Bottom-Up, Modelo Top-Down, Modelo V, Programação Extrema e Scrum. Contudo, nesta Secção, vão-se apenas abordar dois modelos, um mais recente e bastante utilizado, o modelo de Ciclo de Vida em V, e outro não tão recente, o modelo de Ciclo de Vida em Cascata ou Clássico. O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em Engenharia de Software e está na base do desenvolvimento de outros modelos utilizados actualmente [Almeida, 2010 ] [Prass, 2010] [Ciclos, 2010]. De salientar, que neste relatório não se pretende descrever detalhadamente os vários modelos de desenvolvimento de software, apenas se pretende situar de forma simplificada onde é realizada a Fase de Teste tendo como base modelos de desenvolvimento usados na construção de projectos de software. Assim, o modelo de Ciclo de Vida 17

40 em Cascata ou Clássico consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado como ilustra a Figura 4.1. Figura 4.1. Modelo de Ciclo de Vida em Cascata (adaptado de [Sommerville, 2000]). Os nomes dados em cada passo do ciclo variam, assim como varia a definição exacta de cada um deles, mas basicamente o ciclo de vida começa com [Celapar, 2009] [Pressmann, 1995] [Sommerville, 2000]: Levantamento de Requisitos É a fase em que o profissional de informática deve estar directamente ligado ao cliente. Exige um trabalho em equipa para a recolha das necessidades do cliente em relação ao desenvolvimento do sistema em termos de: funções, dados, hardware, etc. Esses requisitos podem ser classificados como: - Funcionais: devem descrever o que o software deverá fazer; - Não funcionais: segurança, integridade, riscos e restrições, problemas de negócio, etc. - De desenvolvimento e manutenção: cronograma, testes, prioridade das funções etc; Análise de Requisitos Constitui a modelação lógica do sistema. Nesta fase, os requisitos levantados são transformados em modelos. O resultado desta fase deve ser um documento ou vários documentos que sejam: inteligíveis, precisos, completos, consistentes, sem ambiguidade e facilmente modificáveis. Estes documentos servirão de instrumento de comunicação entre o programador e cliente; Projecto 18

41 Nesta fase, os modelos teóricos são transformados em modelos físicos, os quais devem estar mais próximos da implementação. São características da fase de projecto: - Definição de interface; - Definição de estrutura de dados; - Definição de módulos; - etc. A fase de Projecto permite que o software possa ser avaliado antes da programação ter início; Implementação Tradução do projecto numa forma que seja legível pela máquina; Testes Os testes são realizados após a implementação. São realizados vários tipos de testes como por exemplo, internamente a um módulo, linha a linha, ou testes de integração dos módulos; Manutenção A fase de manutenção pode ser: - Correctiva: Erros podem ser encontrados durante o funcionamento do sistema; - Adaptativa: O cliente pode propor alguma mudança que implique mudanças de alguns procedimentos, como, por exemplo, nova versão do sistema operativo, etc; - Preventiva: Mudar o sistema em função de mudanças necessárias para manter sua fiabilidade e eficiência, como, por exemplo, reorganizar a Base de Dados, etc. Outro modelo muito utilizado é o modelo em V. Neste modelo os processos de desenvolvimento e testes são definidos, alinhados e iniciam-se em simultâneo. No conceito do Ciclo de Vida em V, os processos de fazer e verificar convergem do início até o fim do projecto, conforme mostra a Figura

42 Figura 4.2. Modelo de Ciclo de Vida em V (adaptada de [Pressman, 2000]). Este modelo baseia-se em verificar o software durante todo o ciclo de desenvolvimento, para conseguir uma detecção antecipada dos erros. Cada módulo no processo de desenvolvimento é avaliado, verificado, validado e testado. Os módulos de cada fase necessitam de ser verificados e validados para se assegurar que estão completos e correctos. O trabalho prossegue para a fase seguinte quando todos os pontos do projecto duma fase se encontram conforme as exigências de verificação e validação. Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo de desenvolvimento do software, ao contrário de outros que só fazem testes no fim do ciclo. Este modelo especifica diferentes fases de teste, como por exemplo: testes de unidade, testes de integração e testes de sistema ou testes de aceitação [Macoratti, 2008]. O modelo em V retracta a importância do teste do software no início do desenvolvimento do ciclo e aumenta a qualidade do software, porque este é testado várias vezes ao longo do ciclo [William, 2000] [Pfleeger, 2004]. Em geral, este modelo reforça a ideia de que o teste é uma parte integrante do ciclo de desenvolvimento do software. Pode-se verificar, tendo como base os dois modelos de desenvolvimento de software referidos nesta Secção, que a fase de testes é elaborada de acordo com o modelo de desenvolvimento escolhido pelas equipas. 20

43 4.6 Fases de Teste Devido à complexidade dos sistemas a actividade de testes deve ser efectuada ao longo de diferentes estágios. O processo de testes mais utilizado é composto por cinco estágios, como ilustra a Figura 4.3. Figura 4.3. Visão Geral de um Processo de Testes (adaptada de [Sommerville, 2000]). O processo é iterativo, em que a informação produzida em cada estágio, poderá fluir entre estágios adjacentes. Os estágios do processo de testes segundo [Sommerville, 2000] [Correia at al, 2004] são: Testes de Unidade Os componentes individuais são testados independentemente de outros componentes para certificação de que operam correctamente; Testes de Módulo Um Módulo é uma colecção de Componentes relacionados tais como classes, tipos abstractos de dados ou um conjunto de procedimentos ou funções. Durante este Estágio cada módulo é testado individualmente. Testes de unidade e de módulo fazem parte do processo de implementação e são da responsabilidade dos programadores que participaram no desenvolvimento do componente alvo e/ou o componente para testar o componente alvo; Testes de Sub-Sistema ou Testes de Integração Esta fase envolve o teste de módulos integrados em sub-sistemas. Os sub-sistemas podem ser desenhados e implementados independentemente. Um problema comum em grandes sistemas está na integração das interfaces entre os módulos dos sub-sistemas. Estes testes 21

44 devem portanto concentrar-se no exercício rigoroso de tais interfaces para detecção de possíveis erros; Testes de Sistema Os sub-sistemas são integrados para formarem um único sistema. O processo deste tipo de teste irá detectar falhas resultantes das interacções entre sub-sistemas e componentes de sistema; Testes de Aceitação Este é o Estágio final do processo de testes antes do sistema ser aceite para uso operacional. O sistema é testado com dados fornecidos pelo utilizador final, ao contrário de dados fictícios ou simulados. Os testes de aceitação revelam principalmente erros e omissões na definição dos requisitos, pois através do uso de dados reais o sistema é exercitado de formas variadas. 4.7 Plano de Teste O Plano de Testes é um documento que especifica como, quando, onde, quem, o porquê e o quê sobre o teste. Descreve os objectivos dos testes a serem realizados e detalha cada um deles. Também, são registados os recursos necessários para a realização dos testes. Este documento é caracterizado por identificar informações e componentes de software no projecto a serem testados, listar requisitos recomendados para teste, especificar e descrever estratégias de teste a serem utilizadas, identificar os recursos e definir o esforço de teste previsto [Mariana, 2010] [Pressman, 1995]. Faz parte também da actividade de planeamento determinar quais são os testes mais importantes e que deverão ser executados. A Figura 4.4 ilustra um exemplo de um Plano de Testes elaborado na empresa Optimus. 22

45 Figura 4.4. Plano de Testes. 4.8 Caso de Teste O Caso de Teste é um conjunto de condições usadas para realizar testes de software numa Fase de Testes. Um Caso de Teste possui as entradas a inserir no sistema/programa e saídas esperadas. Isto é, o caso de teste deve definir a saída esperada, de forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente analisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as condições válidas [Myers et al,, 2004]. Assim, os casos de teste servem como base para que os Testers possam executar os testes manualmente, mas podem ser criados com o intuito de serem automatizados. No entanto, seja qual for finalidade, devem sempre cobrir o máximo de situações possíveis. Os campos necessários para um Caso de Teste segundo a norma IEEE 829 são: 23

46 - Identificador do Caso de Teste; - Itens de teste; - Especificações de entrada; - Especificações de saída; - Ambiente necessário; - Exigências especiais; - Dependências. Como exemplo, apresenta-se na Figura 4.5 um exemplo de um Caso de Teste realizado na empresa Optimus. Figura 4.5. Exemplo de um Caso de Teste. 4.9 Tipos de Teste Tendo como referência os diferentes estágios num processo de testes, Testes de Unidade, Testes de Módulo, Testes de Sub-Sistema ou Testes de Integração, Testes de Sistema e Testes de Aceitação, dentro de cada um destes estágios são elaborados diferentes tipos de teste, onde cada tipo de teste desempenha um papel diferente e com objectivos bem distintos. Segundo o International Software Testing Qualifications Board (ISTQB) alguns dos testes elaborados nos estágios do processo de testes são [Wintrust, 2006] [Travassos at al, 2007] [Caetano, 2009]: Teste de Componentes (Component Test) Tipo de Teste Unitário que foca o teste num bloco de código ainda mais pequeno que uma unidade executável. Por exemplo, uma sub-rotina ou uma classe de um objecto. Este tipo de teste é apropriado para aplicações que são desenvolvidas segundo uma aproximação Orientada a Objectos; Testes de Concorrência (Concurrent Test) 24

47 Tipo de Teste Unitário que avalia a capacidade do módulo ou programa em ser utilizado/chamado por múltiplos utilizadores em simultâneo; Testes de Memória (Storage Test) Serve para testar se a memória ocupada por um dado componente está de acordo com o objectivo (quer memória - RAM - quer memória secundária - disco); Teste de Touchpoint É uma forma Teste de Unitário. Um teste de Touchpoint é usado durante a manutenção do sistema. A intenção deste teste é testar as linhas de código alteradas e prescindir do teste às partes não modificadas; Testes Unitários (Unit Test) Um Teste Unitário é um tipo de teste desenhado para testar um único módulo da aplicação como um ecrã, página, programa ou subrotina. Este teste, tenta cobrir todas as instruções e ramificações do código desse módulo. Os testes unitários incluem normalmente os Testes Negativos e Positivos, designadamente: - Teste Positivo: é quando se introduz uma entrada válida e se espera que a acção termine de acordo com os requisitos; - Teste Negativo: é quando se introduz uma entrada inválida e se espera que a acção termine com uma mensagem de erro; Testes Funcionais (Functional Test) Os Testes Funcionais permitem demonstrar, de forma sistemática, que as funções disponibilizadas estão de acordo com o especificado nos requisitos técnicos e requisitos de negócio, na documentação do sistema e nos manuais de utilizador. Uma distinção chave dos testes funcionais é que estes são orientados na perspectiva dos especialistas da aplicação. Os Testes Funcionais centram-se à volta dos seguintes pontos: - Input Válido Intervalos de valores válidos que o sistema deverá aceitar; - Input Inválido Intervalos de valores inválidos que o sistema deverá rejeitar; - Funções Funções que deverão ser executadas; - Output Intervalos de valores de saída que deverão ser testados; - Sistemas/Procedimentos sistemas ou procedimentos com os quais o sistema dialoga que deverão ser chamados. A preparação e organização dos testes funcionais devem ser focadas nos requisitos, nas funções chave, ou nos casos de testes especiais. Adicionalmente, o teste deve considerar uma cobertura das funcionalidades de forma sistemática, para que seja possível identificar os processos de negócio e os campos de informação; 25

48 Testes de Integração (Integration Test) O Teste de Integração é desenhado para testar grupos de módulos de forma a assegurar que os dados e respectivos procedimentos de controle estão a fluir adequadamente entre esses módulos. Os Testes de Integração demonstram que apesar dos componentes funcionarem satisfatoriamente a nível individual (como demonstram os Testes Unitários bem sucedidos), a sua combinação está correcta e consistente. Testes de Integração visam especificamente expor os problemas que surjam da combinação dos componentes; Testes de Sistema (System Test) O Teste de Sistema é um tipo de teste desenhado para verificar a aplicação na sua plenitude. Este teste é executado depois da aplicação estar completamente integrada e concluída. Com este teste pretende-se validar os requisitos funcionais; Teste de Portabilidade (Portability Test) Tipo de teste que verifica a eficácia de transferir o sistema para outro ambiente; Teste de Coexistência (Coexistence Test) Tipo de teste desenhado para verificar a co-habitação da aplicação com outros componentes que não estejam directamente ligados a ela. A intenção deste tipo de teste é testar como a aplicação interage com outros componentes do seu ambiente, como por exemplo periféricos partilhados, plataformas partilhadas, etc; Teste de Desinstalação (Backout Test) Este é um tipo de teste desenhado para validar os procedimentos de desinstalação da aplicação. A intenção deste teste é verificar que uma aplicação pode ser retirada de produção e a versão anterior re-instalada se necessário. O seu objectivo é provar que existe um mecanismo de recuperação seguro e que pode ser invocado se necessário. Este teste é executado normalmente em sintonia com um Teste de Implementação; Testes de Segurança (Security Test) Testes baseados em objectivos de segurança específicos (Ex: um mecanismo de protecção de memória de um sistema operativo, injecção de SQL ou mecanismos de segurança de dados); Testes de Disaster Recovery (Disaster Recovery Test) Tipo de teste desenhado para recuperar de uma quebra ou perda de dados na aplicação seguindo um plano pré-definido. Também podem ser chamados de Testes de Indisponibilidade; Testes End to End (End to End Test) É um tipo de Teste de Integração bastante abrangente pois vai desde o input original, atravessando todos os componentes da aplicação, até ao output final. Este tipo de teste baseiase no ponto de vista funcional e pode envolver actividades que cruzam as fronteiras de diversas 26

49 aplicações. Um exemplo deste tipo de teste pode ser o teste da entrada de uma encomenda, expedição do produto e emissão da factura; Testes de Implementação ou Testes de Instalação (Implementation Test) Tipo de teste que visa validar os procedimentos de instalação da aplicação e não o seu código. Do leque de validações possíveis há que considerar se há tempo suficiente para instalar as alterações, nomeadamente, tempo para converter ficheiros, executar utilitários e promover a aplicação para o ambiente de produção; Testes Paralelos (Parallel Test) Tipo de teste que é desenhado para determinar se as funções novas do sistema, ou funções alteradas, funcionam da mesma forma que uma versão anterior ou uma versão de outra aplicação com o mesmo fim. Normalmente, os Testes Paralelos são efectuados usando os dados de entrada do actual ambiente de produção para serem processados pelo novo sistema de forma a avaliar se os seus dados de saída são os mesmos. Testes Paralelos são particularmente úteis quando se está a redesenhar um novo sistema para uma nova plataforma sem fazer grandes mudanças a nível funcional; Testes de Smoke Test Tipo de teste desenhado para executar as funções mais críticas da aplicação com os dados mais usuais. Este teste é geralmente executado após a compilação da aplicação para validar que a mesma está pronta para entrar no ciclo de teste, ou seja, este teste é utilizado como pré-teste para ajudar a determinar se a aplicação está pronta para testes mais rigorosos (de acordo com o plano de testes); Testes de Performance (Performance Test) Testes de Performance determinam a performance da aplicação em produção bem como da sua infra-estrutura de suporte sob determinadas condições. Os Testes de Performance são usados para medir certas características do sistema tais como, velocidade de processamento, tempo de resposta, consumo dos recursos, nº de pedidos por segundo e eficiência. O termo Testes de Performance é utilizado frequentemente para referir não só testes de performance mas também testes de stress, carga e de volume; Teste de Aceitação (Acceptance Test) Teste de Aceitação é um tipo de teste desenhado para simular, o mais aproximado possível, a utilização real da aplicação. Este teste inclui o envolvimento do utilizador final da aplicação; Testes de Regressão (Regression Test) 27

50 O Teste de Regressão consiste na aplicação de testes à versão mais recente do software, para garantir que não surgiram novos defeitos nos componentes já testados. Se, ao juntar um novo componente, ou devido a alterações em componentes do sistema, surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu. Os Testes de Regressão são compostos por um conjunto de testes que são executados sempre que qualquer componente da aplicação é alterado. Com esta política ganha-se a confiança que o sistema continuará a funcionar apesar dos novos requisitos implementados, isto é, este tipo de teste garante que um determinado produto que sofreu novas actualizações continua a funcionar correctamente; Testes de Carga (Load Test) Simulação da carga prevista dentro dos requisitos operacionais do sistema; Testes de Stress (Stress Test) Teste direccionado para avaliar um sistema ou um componente do sistema no limite (ou para além do limite) dos requisitos especificados. O desempenho e as funções normais de um sistema são confrontados com situações anormais. Este tipo de teste é geralmente desenhado para exceder os requisitos do desempenho normal da aplicação e determinar o limite máximo das suas capacidades; Testes de Volume (Volume Test) Simula o volume de transacções máximo esperado e respectivos acessos no período de maior tráfego para se perceber o impacto na rede, nos tempos de resposta e noutros componentes da infra-estrutura. É uma variação de Testes de Stress. O esquema da Figura 4.6 ilustra a diferença entre estes tipos de teste; Figura 4.6. Diferenças entre Teste de Carga/Volume/Stress. Testes de Usabilidade (Usability Test) Tipo de teste desenhado para verificar se a utilização da aplicação por parte do utilizador está de acordo com as suas necessidades. Um Teste de Usabilidade é tipicamente executado 28

51 por utilizadores finais como parte da fase de desenho, utilizando para o efeito um protótipo. O objectivo é simular o ambiente normal de trabalho; Testes de Documentação (Documentation Test) Testes que se preocupam com a qualidade da documentação para os utilizadores finais. Por exemplo, verificam que os documentos são claros e concisos, e que são usados os exemplos nos documentos para criar os casos de teste Tipos de Testes / ível do processo de Teste Nesta Secção assimila-se os Tipos de Testes apresentados na Secção anterior com Fase de Teste apresentado na Secção 4.6. Assim, a Tabela 4.2 relaciona cada tipo de teste, bem como a fase em que o mesmo se aplica, tendo em conta o nível do processo de teste. Tabela 4.2. Fase/Tipo de Testes. Fase Unitário Integração Integração Sistema Aceitação Aceitação Componentes Componentes Componentes Carga Aceitação Aceitação Concorrência Concorrência Funcional /Integração Coexistência Carga Beta Memória Regressão Desinstalação Documentação Carga Touchpoint Segurança Disaster & Recovery Regressão Performance Tipo Unitário Funcional Stress Piloto de Usabilidade Stress Teste Instalação Volume Volume Paralelos Portabilidade Regressão Segurança Smoke Stress Sistema Volume Ambiente Desenvolvimento Qualidade Pré - Produção Produção 4.11 Técnicas de Testes de Software Uma grande variedade de técnicas é utilizada para realizar o projecto de casos de teste para software. Estas técnicas fornecem mecanismos que podem ajudar na elaboração dos casos de teste e fornecem uma probabilidade maior de descobrir erros. Qualquer produto que passa por Engenharia 29

52 de Software (e não só) por ser testado de duas maneiras: (1) sabendo a função específica para a qual foi projectada para realizar, podem ser realizados testes que demonstrem que a função está plenamente operacional; (2) sabendo como é o funcionamento interno de um produto, podem ser realizados testes para garantir que todas as engrenagens combinam, isto é, que as operações internas são realizadas de acordo com as especificações e que todos os componentes internos foram adequadamente exercitados. A primeira abordagem de teste chama-se técnica de teste White-Box ou Caixa-Branca e a segunda, técnica de teste Black-Box ou Caixa-Preta [Nina, 2007] [Pressman, 1995] Teste White-Box (Caixa-Branca) Este tipo de técnica de teste avalia o comportamento interno do componente de software, como ilustra a Figura 4.7. A técnica de Caixa-Branca opera directamente sobre o código-fonte do componente. Os aspectos avaliados neste teste dependerão da complexidade e da tecnologia que determinaram a construção do componente de software. Dados de Entrada Dados de Saída Figura 4.7. Técnica de White-Box ou (Caixa-Branca). O programador responsável pelos testes tem acesso ao código fonte da aplicação e pode construir códigos para efectuar a ligação de bibliotecas e componentes. Esta técnica de teste baseiase num conjunto de métodos que, garantem que todos os caminhos independentes de um módulo tenham sido exercitados pelo menos uma vez, que executem todos os ciclos nos seus limites e dentro dos seus intervalos operacionais, e exercitem as estruturas de dados internas para garantir a sua validade. Estes testes podem ser testes manuais ou testes efectuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação, reconhecidas pelo mercado de software. A técnica de teste de Caixa-Branca é recomendada para as fases de Teste da Unidade e Teste da Integração, cuja responsabilidade principal, em geral, fica a cargo dos programadores do software, que por sua vez conhecem bem o código-fonte produzido [Ireland, 1991] [Pressman, 1995]. 30

53 Teste Black-Box (Caixa-Preta) Este tipo de técnica de teste consiste em verificar a saída dos dados usando vários tipos de entradas de dados, como ilustra a Figura 4.8. Neste tipo de técnica os dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Dados de Entrada Dados de Saída Figura 4.8. Técnica de Caixa Preta ou Black-Box. A técnica Black-Box utiliza um conjunto de dados de entrada que vão exercitar todos os requisitos funcionais do software. Este tipo de técnica tenta encontrar, por exemplo, erros de interface, erros de estrutura de dados ou de acesso a bases de dados, erros de comportamento e desempenho. Com este objectivo, utiliza vários métodos que são: métodos de teste baseados em grafo, particionamento de equivalência, teste de comparação, teste de matriz ortogonal [Nina, 2007] [Beizer, 1995] [Pressman, 1995]. No entanto, com base nas literaturas pesquisadas, a técnica de teste de Caixa Preta também pode ser chamada de técnica de teste funcional. No âmbito deste Estágio, esta técnica de teste foi utilizada no desenvolvimento de casos de teste para automatização. Nos anexos, na Secção Exemplo de Caso de Teste encontra-se um exemplo de um caso de teste para automatizar. Este foi desenvolvido utilizando os conceitos referidos nesta Secção. Por exemplo, os dados utilizados ao longo do teste são inseridos e no final da execução do teste são validados Custos da Qualidade em Testes de Software O custo da qualidade inclui todos os custos decorrentes da procura de qualidade ou da execução de actividades relacionadas com a qualidade [Pressman, 1995]. A medição do custo da qualidade pode ser usada para comparar o custo de um produto final, para determinar a diferença relativamente a um produto similar, ou por exemplo usar-se para avaliar o custo adicional de se falhar a satisfação dos requisitos da qualidade imposto pelo cliente. Assim, os custos da qualidade podem ser vistos de duas formas. A primeira, mais simplista, encara dois tipos de custos [Miguel, 2004]: 31

54 Custos da Conformidade Custos associados à formação, treino, verificações, validações, teste, manutenção, calibragem, auditorias; Custos da ão-conformidade Incluem itens como desperdícios, trabalho adicional de correcção de erros, reparações em garantias, devolução de produtos e gestão de reclamações. O outro método de classificar os custos da qualidade leva em consideração todos os itens que contribuem para a sua formação. Estes itens podem ser descritos como [Horch, 1996], [Miguel, 2004]: Custos de Prevenção Custos visíveis orientados para a satisfação dos requisitos do cliente (revisão de desenho, treino, planeamento da qualidade, inspecções a fornecedores, etc.). Ou seja, tem a ver com a estratégia de incorporação da qualidade; Custos de Avaliação Custos associados com a avaliação e testes do produto ou processo, para garantir que satisfaz os requisitos do cliente. Ou seja, tem a ver com a estratégia de controlo de qualidade; Custos de Falhas Internas Custos associados com a falha de processos em fazer produtos aceitáveis para o cliente (reescrever especificações e planos, voltar a rever após a correcção de defeitos, voltar a testar após a correcção de defeitos, etc); Custos de Falhas Externas Custos associados com a determinação, pelo cliente, de que os seus requisitos não foram satisfeitos (tratamento de reclamações de clientes, visitas ao cliente para resolução de queixas, perda de clientes, perda de oportunidades, etc.). Este tipo de custo está associado com a estratégia de preservação da qualidade. Podemos considerar que os dois primeiros custos representam os custos de incorporar a qualidade e os dois últimos representam os custos das falhas. A Figura 4.9 ilustra os resultados esperados pelo sistema de gestão da qualidade nos custos da qualidade. Numa organização sem um sistema de gestão da qualidade, os custos da qualidade têm a estrutura indicada no gráfico da 32

55 esquerda; o gráfico da direita mostra que a introdução de um sistema de gestão da qualidade permite obter economias significativas. Figura 4.9. Custos da Qualidade (adaptado de [Miguel, 2004]). Podemos assim concluir que o investimento sério na prevenção provoca uma diminuição em todos os outros custos, com especial incidência nos custos devido às falhas internas e externas. Como podemos analisar pela Figura 4.10 quanto mais tarde se encontra uma falha/erro, maior será o seu custo. Figura Custos da correcção de erro (adaptado de [Miguel, 2004]) Uma nova abordagem: Automatização Muitas das metodologias de Engenharia de Software recomendam que todas as pessoas envolvidas num projecto (programadores, gestores, equipas de homologação e até mesmo os 33

56 clientes) trabalhem com o objectivo de controlar a qualidade do produto todos os dias e a todo o momento, pois acreditam que prevenir defeitos é mais fácil e barato que identificá-los e corrigi-los. Assim, cada vez mais é recomendado testes automatizados para ajudar a garantir a qualidade dos sistemas de software. Testes automatizados são programas ou scripts simples que exercitam funcionalidades do sistema a ser testado e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem é que todos os casos de teste podem ser facilmente e rapidamente repetidos, a qualquer momento e com pouco esforço [Kon at al, 2008] [Aniela, 2010] [Sommerville, 2000] Porquê Automatizar? A necessidade de automatizar deve-se essencialmente à necessidade de repetir os testes a qualquer momento. Assim, com a elaboração de automatismos torna-se possível, e com extrema facilidade, executar todos os testes quando se desejar, permitindo assim analisar se existem mudanças no sistema. A reprodutibilidade dos testes permite simular identicamente e inúmeras vezes situações específicas, garantindo que passos importantes não serão ignorados por falha humana, facilitando a identificação de um possível comportamento não desejado. Além disso, como os casos para verificação são descritos através de um código interpretado por um computador, é possível criar situações de testes bem mais elaboradas e complexas do que as realizadas manualmente, possibilitando qualquer combinação de comandos e operações. Permite que os Testers estejam mais preocupados com outras tarefas críticas e impossíveis de automatizar, em vez, de estarem a executar tarefas rotineiras. Outro ponto importante da automatização, é que permite de forma trivial simular centenas de utilizadores a acederam a um sistema ou a inserirem milhares de registos numa base de dados, o que não é fazível com testes manuais. Todas estas características ajudam a solucionar os problemas encontrados nos testes manuais, diminuindo a quantidade de erros e aumentando a qualidade do software [Kon at al, 2008] [Aniela, 2010] [Martha, 2008] [Nina, 2007] Âmbito da Automatização na Optimus Com o objectivo de aumentar a qualidade, dentro dos processos de negócio core, a Equipa de QMS da Optimus decidiu automatizar casos de teste, assim como, algumas tarefas rotineiras que antes eram realizados manualmente, de forma a ajudar os colaboradores a economizar tempo e energia a fazerem o seu trabalho. Assim, depois de executar manualmente o caso de teste, este é 34

57 automatizado com o auxílio da ferramenta Quick Test Professional para garantir que não surgem novos defeitos nos componentes já testados. A este tipo de teste atribui-se o nome de Teste de Regressão (ver Secção 4.9). Outro tipo de teste resultante da automatização de um caso de teste é o Teste de Carga/Stress/Volume (ver Secção 4.9). Estes têm um objectivo bem distinto dos Testes de Regressão, pois, o seu objectivo não é encontrar defeitos nos componentes já testados, mas sim simular vários utilizadores a utilizarem a mesma aplicação e verificar o comportamento do servidor da aplicação. De salientar que a única diferença entre Teste de Carga, de Stress e de Volume encontra-se no número de utilizadores simulados durante a execução dos respectivos testes. Assim, ao longo do Capítulo 5, vamos apenas fazer referencia a Teste de Carga, dado que os Testes de Stress e de Volume apenas simulam mais utilizadores. Para este tipo de teste utiliza-se a ferramenta Loadrunner. No Capítulo 5 serão retratados estes tipos de teste, Testes de Regressão e Testes de Carga, acompanhados de alguns exemplos práticos implementados no âmbito deste Estágio. 35

58 5 Automatismos Neste Capítulo abordam-se os automatismos desenvolvidos ao longo do Estágio, é apresentada a sua arquitectura e o seu modo de funcionamento, assim como as ferramentas utilizadas e as suas principais características. Ao longo deste Capítulo serão também apresentadas as metodologias utilizadas justificando a sua aplicação com exemplos do Site Optimus e do Site CPM. Estes Sites são dos produtos com maior número de automatismos desenvolvidos ao longo do período de Estágio (ver Secção 5.10). 5.1 Introdução Com a presente introdução pretende-se enquadrar a fase de desenvolvimento de scripts tendo em conta as metodologias da equipa de Quality Management Systems (QMS) na empresa Optimus. Assim, de forma simples e resumida descreve-se o enquadramento da fase de desenvolvimento de scripts durante as fases da actividade de teste. Estas são normalmente realizadas na seguinte sequência: (1) Identificação, (2) Desenho, (3) Construção, (4) Execução e (5) Comparação, como mostra a Figura 5.1. No entanto, nem sempre é possível realizar estas actividades na sequência apresentada. Por vezes, quando se está numa fase intercalar, verifica-se que existe informação, dados ou validações que deviam ter sido descritas numa fase anterior. Devido a este facto, por vezes tem que se repetir o processo ciclicamente até se darem por concluídas todas as fases [Fewster at al, 1999] [Correia at al, 2004] [Sommerville, 2000]. Tendo como base a Figura 5.1 pode-se descrever individualmente cada uma das fases: 36

59 Figura 5.1. Actividades de teste para automatizar casos de teste na equipa de QMS (adaptado de [Correia at al, 2004]). Identificação Nesta primeira etapa, o Tester determinará o alvo a verificar, identificando as condições de teste (itens ou eventos) que precisam ser verificados por cada teste. As condições de teste são descrições de circunstâncias que devem ser examinadas. A abordagem usualmente usada pela equipa de QMS nesta fase é a abordagem de testes funcionais ou Black-Box (ver Secção ); Desenho O desenho dos casos de teste determinará como as condições de testes serão verificadas. Um caso de teste é um conjunto de passos realizados em sequência e com um objectivo comum verificar/validar. Para a correcta execução de um caso de teste é necessário fornecer os dados de entrada e respectivas saídas. Os pré-requisitos para realização dos testes, tais como variáveis do ambiente de execução ou estado da base de dados, devem ser explicitados para cada caso de teste. A saída ou resultado esperado inclui a criação ou visualização de itens, a modificação ou actualização de itens (em base de dados, por exemplo) ou a remoção de itens. No Anexo I, na Secção Exemplo de Caso de Teste - Site CPM apresenta-se um caso de teste realizado no âmbito do Estágio para o Site CPM. Neste exemplo pode-se verificar a query de dados de entrada e de validação, assim como a sequência a realizar pelo script; Implementação 37

60 Nesta fase os casos de teste são transformados em scripts de teste. No entanto, um script pode executar mais que um caso de teste. Conforme o objectivo final, o script é desenvolvido com o auxílio das ferramentas QTP (caso se automatizem casos de testes para testes de regressão) ou LoadRunner (caso se automatizem casos de teste para teste de carga) e é guardado num ficheiro com a extensão definida automaticamente pela ferramenta utilizada na sua implementação. Como exemplo, apresenta-se no Anexo II, na Secção Exemplo Script de Suporte - Site CPM um script que ilustra a navegação efectuada no respectivo site e no final executa a actividade de validação (neste caso chama uma função para consultar uma base de dados); Execução Nesta actividade são executados os scripts de teste. Caso se pretenda executar um script de testes de regressão (ver Secção 5.2) utiliza-se a ferramenta Quality Center (ver Secção 5.8) permitindo assim lançar os scripts remotamente e serem executados por qualquer Tester, caso se pretenda executar um script de teste de carga (ver Secção 5.13) este deve ser executado apenas pelo programador; Comparação Os resultados obtidos do sistema sob teste são utilizados para determinação da validação do teste. Existem dois resultados possíveis: Failed (Falhou) ou Passed (Passou). Por norma, são realizadas várias verificações durante a execução do script do caso de teste mas, por exemplo, resultados que fazem modificações de registos numa base de dados podem apenas ser comparados depois da execução do caso de teste estar finalizado. Por exemplo, o script que se encontra no Anexo II, Secção Exemplo Script Suporte Site CPM retrata esta situação. É efectuada a navegação no respectivo site e no final é executada a actividade de validação, ou seja, é utilizada uma função para consultar uma base de dados (ver Secção 5.6). Contudo, quando estamos perante os testes de regressão é a ferramenta Quality Center que apresenta o resultado final assim como as comparações e verificações dos dados realizadas ao longo do script (ver Secção 5.8). Todavia, caso se executem scripts de testes de carga, a validação é apresentada num relatório gerado automaticamente pela ferramenta (ver Secção 5.13); 5.2 Arquitectura dos Testes de Regressão A arquitectura dos testes de regressão foi desenhada tendo em conta as ferramentas já utilizadas pelos Testers e a ferramenta QTP. O objectivo principal, foi definir uma forma que fosse simples para os Testers utilizarem as ferramentas com que já tinham afinidade. Uma dessas 38

61 ferramentas é o Quality Center, tendo-se verificado que esta ferramenta conseguia interagir com a ferramenta QTP. Assim, na sequência deste Estágio, integrou-se o QTP com a ferramenta Quality Center. Esta ferramenta, muito utilizada pelos Testers, serve para estes definirem, gravarem e executarem um caso de teste. Então, definiu-se que a ferramenta Quality Center iria fazer a ponte entre os Testers e os automatismos criados pela ferramenta QTP. Como se pode observar na Figura 5.2, pode-se afirmar que a arquitectura dos testes de regressão é constituída por um utilizador (usualmente um Tester, mas pode ser o programador ou gestor de equipa), (para mandar executar um caso de teste automático), um servidor com a ferramenta Quality Center, (para guardar os dados e resultados do caso de teste), e um servidor com a ferramenta QTP, (para executar os scripts que executam o caso de teste automatizado). Figura 5.2. Arquitectura Testes de Regressão Equipa de QMS. O funcionamento da arquitectura, consiste no Tester (quem mais utiliza a ferramenta) aceder ao interface da ferramenta Quality Center via Web, escolher o caso de teste automatizado, definir os dados de teste que pretende que o script utilize (ver Secção 5.8), definir o servidor onde pretende executar o caso de teste automatizado, e de seguida ordenar a execução num servidor com a ferramenta QTP. 5.3 Ferramenta de Automatização Quick Test Pro Como descrito anteriormente, o QTP é uma ferramenta de Capture and Replay. Esta ferramenta foi inicialmente desenvolvida pela empresa Mercury Interactive e adquirida pela empresa HP. Como ilustra a Figura 5.3, esta ferramenta usa vários Add-ins (por exemplo, ActiveX, VisualBasic, Web) para melhorar a velocidade de execução e para melhor reconhecer as aplicações em teste. 39

62 Figura 5.3. Add-ins da Ferramenta QuickTest Professional. O modo de funcionamento do QTP baseia-se no reconhecimento de objectos de uma aplicação ou página Web. Isto é, a ferramenta reconhece as propriedades de um determinado objecto (por exemplo: um Button, uma TextBox, uma ComboBox), armazena essas propriedades num local centralizado chamado de Repositório de Objectos (Object Repository) e gera uma linha de código referenciando esse objecto no repositório. A Figura 5.4 apresenta a interface do Repositório de Objectos. Assim, quando o programador que implementa a automatização dos casos de teste efectua uma navegação, a ferramenta vai guardando os dados, as propriedades dos objectos que vão sendo utilizados na navegação, e gerando o código do script. Terminada esta fase, quando se executa o script, o código gerado para um determinado objecto vai comparar as propriedades desse objecto no repositório de objectos com as propriedades da aplicação. Isto é, os objectos da aplicação ou página Web são identificados / reconhecidos pela comparação das suas propriedades com as propriedades armazenadas no repositório de objectos. 40

63 Figura 5.4. Ferramenta QuickTest Professional. Caso as propriedades no repositório de objectos sejam diferentes das encontradas na aplicação é gerada uma mensagem de erro. Os Add-ins disponibilizados pela ferramenta são muito úteis para o reconhecimento das propriedades dos objectos nos diversos tipos de aplicações. 5.4 Principais Funcionalidades da Ferramenta QuickTest Professional A ferramenta QTP, tal como outras ferramentas que permitem a automatização de casos de teste, apresenta um conjunto elevado de funcionalidades, no entanto, no contexto deste Estágio as funcionalidades com maior relevância são (Figura 5.5, 5.6, 5.7): Reconhecimento automático dos objectos e respectiva geração automática de código Figura 5.5. Ferramenta QuickTest Professional (Record). 41

64 Repositório comum de Objectos (Object Repository) Figura 5.6. Ferramenta QuickTest Professional (Object Repository). Introdução de verificação de pontos (Checkpoints) Os Checkpoints permitem verificar que uma determinada característica da aplicação existe. Com esta funcionalidade é possível comparar o resultado real com os resultados esperados pré-definidos. Existem vários tipos de Checkpoints, tais como, Standard Checkpoint, Text Checkpoint, Bitmap Checkpoint, Database Checkpoint, e XML Checkpoint, como apresentado na Figura 5.7. O Database Checkpoint é, por norma, pouco utilizado. O mais comum é efectuar-se uma consulta à base de dados através de funções implementadas na linguagem de programação Visual Basic. 42

65 Figura 5.7. Ferramenta QuickTest Professional (CheckPoints). 5.5 Técnicas para implementação de scripts de testes automáticos Nesta secção vamos descrever as técnicas utilizadas para a implementação de scripts no âmbito do Estágio, exemplificando com um caso prático em funcionamento. As técnicas para implementação de scripts de testes automáticos são semelhantes às técnicas de programação. Para a implementação de scripts, usando-se como referencia [Fewster at al, 1999] [Sommerville, 2000] [Correia at al, 2004], foram desenvolvidos vários scripts utilizando as técnicas consideradas pelos autores que se resumem-se a cinco: Scripts Lineares A técnica de scripts lineares é obtida a partir da gravação feita por uma ferramenta Capture and Replay ou (gravação e execução). É uma forma rápida de iniciar a implementação de scripts para testes automáticos, pois não requer conhecimento da linguagem oferecida pela ferramenta. No entanto, estes scripts não são úteis num plano a longo prazo. Normalmente, possuem informação excessiva e repetida, dados registados junto às acções (hard-coded) e estão muito associados a particularidades do sistema na fase da gravação, o que os torna bastante vulneráveis a mudanças no sistema a ser testado; 43

66 Scripts Estruturados Esta técnica de implementação de scripts Estruturados utiliza estruturas de controlo como If, For, Loop,etc, o que garante uma flexibilidade não existente nos scripts lineares; Scripts Partilhados Com esta técnica pretende-se implementar scripts que podem ser usados por mais de um caso de teste. Os scripts partilhados podem ser específicos a uma aplicação ou independentes da aplicação. Uma vez identificado um conjunto de acções úteis para mais de um teste, um script partilhado deve ser criado e disponibilizado para invocação a partir de qualquer outro teste. As informações variáveis devem ser passadas como parâmetro, tal como acontece na invocação de uma função na programação estruturada, de forma a se utilizar em vários scripts partilhados. No âmbito deste Estágio, a implementação de testes automáticos através desta técnica e das anteriores foi apenas utilizada para demonstração do funcionamento das ferramentas QTP e Loadrunner, dado que estas técnicas não utilizam os dados de teste ou os resultados esperados a partir de um ficheiro de dados, Excel ou base de dados; Scripts Data-driven Com esta técnica, são implementados scripts mais abrangentes. Estes utilizam dados de forma dinâmica, isto é, lêem os dados a utilizar durante o script ou os resultados esperados a partir de um ficheiro de dados, tabela de dados, ou base de dados evitando dados hard-coded no próprio script. Esta técnica permite que novos casos de teste sejam realizados, uma vez que em alguns casos a existência de novos casos de teste pode ser expressa pela inclusão de novas entradas numa tabela de dados, sem nenhuma alteração no script. Muitas ferramentas de Capture and Replay encorajam à utilização desta técnica fornecendo mecanismos para armazenamento de dados de entrada em ficheiro texto e atribuição dos mesmos, durante a execução, a variáveis do script. Esta técnica foi a mais utilizada no desenvolvimento de scripts durante o Estágio. Como exemplo da implementação desta técnica pode-se observar um exemplo do script do Site CPM no Anexo II, Secção Exemplo Script de Suporte - Site CPM. Pode-se observar a utilização das variáveis ao longo do script. De salientar que o valor destas variáveis foi definido no Quality Center; Scripts Keyword-driven Na técnica data-driven, a navegação e acções realizadas são as mesmas para cada caso de teste e o conhecimento lógico sobre os testes está contido no ficheiro de dados e no script de controlo ou principal, os quais precisam ser sincronizados. A técnica keyword-driven combina 44

67 a técnica data-driven com a possibilidade de especificar os casos de teste de forma menos detalhada. O script de controlo tem habilidade de interpretar estas keywords (palavras-chave), as quais estão implementadas fora do script de controlo. Esta separação na implementação das keywords requer um nível adicional de implementação técnica, que é efectuado através dos chamados scripts de suporte. Temos portanto três estruturas básicas que são os ficheiros de teste, onde se define as keywords, o script de controlo, e os scripts de suporte. No âmbito deste Estágio esta técnica é muito utilizada dado que através de keywords definidas nos dados de teste, existe a possibilidade de construir scripts de controlo mais dinâmicos aumentando assim a possibilidade de criar um maior número de casos de teste para a aplicação a verificar. Na Figura 5.8 apresenta-se como se aplica esta técnica em vários scripts do Site CPM. O exemplo consiste em mostrar a forma como através da keyword definida nos dados a utilizar pelos scripts, o script de controlo define qual o script de suporte a utilizar. Neste caso, pretende-se adicionar/remover um cliente ou efectuar descontos directo/crédito. A acção depende das keywords invocadas nos dados para utilizar durante a execução dos scripts. No entanto, apenas se utiliza um script de controlo e um conjunto definido de scripts de suporte. 45

68 Figura 5.8. Exemplo da estrutura de um Script (Técnica Keyword-driven). Esta última técnica, Keyword-driven, e a técnica Data-driven, são as técnicas mais utilizadas na implementação dos scripts realizados neste Estágio. 5.6 Fases de Construção de um Script Para a elaboração de um script pode-se dizer, de forma simplificada, que são necessárias três fases, como é ilustrado na Figura 5.9, que são: (1) Criar Script, (2) Executar Script, (3) Analisar Test Result. 46

69 Figura 5.9. Fases de construção de um script. (1) Criar Script Esta primeira fase é a fase mais demorada e mais importante. Tendo em conta o caso de teste para automatizar, nesta fase realiza-se a gravação dos objectos, simulando uma navegação delineada no caso de teste. De seguida, definem-se as variáveis dinâmicas no script e as variáveis para utilizar os scripts de suporte; (2) Executar Script Nesta fase, é efectuado o debug do script; (3) Analisar Resultados Por fim, esta última fase consiste em analisar o resultado gerado pela própria ferramenta. No caso de se utilizar a ferramenta QTP é gerado um relatório - o TestResult. Este relatório serve para validar se os objectos utilizados pelo script estão efectivamente presentes na aplicação que se está a testar. Isto é, este relatório permite analisar se por exemplo, quando se selecciona um objecto, se é apresentada a janela correcta. Permite também analisar se uma função que é utilizada no script é executada com sucesso. Caso se utilize a ferramenta Loadrunner o resultado do script é apresentado na própria ferramenta na interface principal na zona de logs (ver Secção 5.13). Os parágrafos anteriores descrevem o conjunto de fases para desenvolver um script. No entanto, quando se está a executar um Teste de Regressão Automatizado, não se está a executar um script mas sim um conjunto de scripts geridos por um script de controlo ou principal. Isto é, a gestão dos scripts a utilizar é efectuada por um script de controlo e este realiza a sincronização com os vários scripts para que se concretize a navegação definida no caso de teste. O script de controlo executa de forma sequencial cada um dos scripts individuais. Assim, inicialmente executa o Script Init, onde são inicializadas as variáveis necessárias para se poder iniciar a navegação numa determinada aplicação. De seguida, executa o Script de Login, onde realiza a operação de login. O script seguinte a ser executado é o Script de Navegação. Este realiza a navegação e introduz os 47

70 dados necessários dentro da aplicação, e pode também utilizar outros Scripts de Suporte para auxiliar a navegação. O Script Navegação realiza, como última operação, a validação. Esta validação pode ser um checkpoint, por exemplo para verificar que determinado valor surge na janela da página Web, ou pode ser utilizada uma função de validação. Por fim, o último script a ser executado é o Script de Logout. A Figura 5.10 apresenta o caso mais comum de scripts em Testes de Regressão realizados no âmbito deste Estágio. Figura Estrutura de um script de Teste de Regressão implementado na equipa QMS. De salientar, que Get_TestData é uma função que tem como objectivo obter os dados a utilizar no script. A query a utilizar e a Base de Dados a consultar são definidos na ferramenta Quality Center. Esta metodologia é também utilizada quando se define uma função de validação no script de Navegação. 5.7 Estrutura de um Servidor de Testes de Regressão De forma a ser possível executar vários scripts em vários servidores definiu-se uma estrutura standard para utilizar sempre que se pretende que um determinado servidor executa Testes de Regressão. Tendo em conta este objectivo, definiu-se a seguinte estrutura: Na directoria C:\ existe uma pasta com o nome CQOS. Dentro dessa pasta existe um conjunto de pastas que são: 48

71 backup Utilizada para realizar backups dos scripts, de dados, logs, etc; logs Para colocar os logs, por exemplo, de um servidor Unix, de consulta a uma base de dados, etc; ScreenShots Para colocar os screenshots realizados durante a navegação do script. Normalmente, estes screenshots são criados quando o script encontrou um erro de navegação. Estes erros surgem devido à introdução de dados incorrectos na aplicação em teste, ou de um erro no GUI da aplicação em teste; scripts Local onde se situam os ficheiros.bat e.exe necessários para executar tarefas auxiliares nos scripts de suporte; setup Usada para colocar o ficheiro.xml usado para iniciar o processo de consulta a base de dados de testes; sourcecode Usada para guardar todos os scripts de controlo e scripts de suporte. Esta pasta tem como sub-pasta a QTP e a pasta QTP_TAF. A primeira possui uma sub-pasta, COMMO, que tem guardadas todas as funções e procedimentos comuns a todos os scripts. A segunda pasta, QTP_TAF, é constituída por sub-pastas com o nome das aplicações/produtos automatizados. Dentro destas sub-pastas são armazenados todos os scripts de controlo e scripts de suporte do conjunto de aplicações/produtos, como se ilustra na Figura 5.11; 49

72 Figura Estrutura da pasta sourcecode de um servidor de Testes de Regressão. template Utilizada para guardar templates de scripts, documentos de automatização, etc; TestData Utilizada para guardar ficheiros de TestData, como por exemplo um Excel ou um otepad; temp É utilizada durante a execução de um script e serve para armazenar dados temporários. A Figura 5.12 permite visualizar a disposição das pastas dentro da directoria C:\CQOS. Esta estrutura existe em todos os servidores que executam os Testes de Regressão. 50

73 Figura Estrutura de um servidor de Teste de Regressão. 5.8 Ferramenta Quality Center A ferramenta Quality Center, apresentada na Figura 5.13, é desenvolvida pela Hewlett-Packard tendo como principal objectivo a gestão de testes. A utilização desta ferramenta define-se por actividades geradas através da interface Web disponibilizada pela ferramenta. Esta apresenta vários tipos de funcionalidades, no entanto, as suas funcionalidades principais resumem-se em quatro secções: gestão de requisitos (Requirements), gestão de Casos de Teste (Test Plan), execução dos testes (Test Lab) e gestão de defeitos (Defects). O Quality Center permite também armazenar os procedimentos de teste e controlar as versões dos mesmos. Também controla o estado actual dos testes comparando os resultados esperados com os resultados obtidos, permitindo assim gerir os defeitos encontrados durante a execução dos testes. 51

74 Figura Ferramenta Quality Center (Página Login). Para a elaboração dos testes de regressão utilizam-se as opções para criar, executar e analisar testes automáticos. As restantes opções permitem aceder a opções de execução e gestão de testes manuais. Na ferramenta Quality Center utiliza-se a opção Test Plan para criar um teste automático. Nesta opção define-se também a query de dados de teste, (que pode ser dinâmica ou não), a query de validação de dados de teste e a base de dados onde se executam as querys referenciadas. Como se ilustra na Figura 5.14, pode-se visualizar um exemplo de caso de teste e a respectiva query de dados de teste e de validação. Figura Ferramenta Quality Center (Página Test Plan). 52

75 Para a execução dos Testes de Regressão automatizados é utilizada a opção Test Lab, como ilustra a Figura Nesta opção, é definido qual o servidor onde vão ser executados os testes e selecciona-se a opção Run All para se proceder à execução dos respectivos testes. Figura Ferramenta Quality Center (Página Test Lab). Depois de executados os testes, procede-se à verificação dos resultados e analisa-se se o teste passou em todas as instruções. Analisam-se também mensagens enviadas durante a execução do teste. Como se apresenta na Figura 5.16 pode-se visualizar um exemplo dos resultados gerados para um determinado caso de teste. Figura Ferramenta Quality Center (Página Test Instance Properties). 53

76 5.9 Arquitectura de funcionamento Quality Center-QTP Para se lançar remotamente um script guardado num servidor de Teste de Regressão utiliza-se a ferramenta Quality Center (QC). Esta ferramenta guarda num repositório um script desenvolvido na ferramenta QTP. O script contém o caminho para o script de controlo e para os scripts de suporte que existem em qualquer servidor de teste de regressão para uma determina aplicação. No entanto, apenas é definido no script, guardado na ferramenta QC, para executar o script de controlo (ver exemplo de script no Anexo II, Secção Exemplo Script Quality Center - Site CPM ). Assim, quando se executa um caso de teste automatizado na ferramenta QC, esta ferramenta vai executar o script associado a esse caso de teste, guardado no repositório. De seguida, o script guardado na ferramenta QC vai ligar-se remotamente ao servidor de teste de regressão definido, que por sua vez executa o script de controlo definido dentro do script guardado na ferramenta de QC. A Figura 5.17 ilustra este passo. Figura Sincronização da ferramenta Quality Center com servidor de Testes de Regressão. Ao longo da navegação, vão sendo enviadas mensagens para o repositório do Quality Center. Estas mensagens contêm informação dos objectos que vão sendo analisados ao longo de qualquer script. No final de executar o script de controlo, a ferramenta Quality Center apresenta o resultado 54

77 de Passed, caso tenha executado todas as instruções dos scripts com sucesso, ou Failed, caso tenha encontrado algum erro nas instruções definidas em um ou mais scripts Produtos Automatizados Até à data de entrega deste Relatório, e no âmbito deste Estágio, foram automatizados cerca de 185 casos de teste de diversos produtos como se pode analisar pela Figura O número de scripts realizados num determinado período de tempo é apresentado através da ewletter de QMS. No Anexo III, na Secção "Exemplo de ewsletter da Equipa de QMS" apresenta-se o exemplo da ewsletter que é enviada para outras equipas da área de Sistemas de Informação da empresa Optimus. No entanto, existem dois produtos que se destacam. Um é o Site CPM, que é uma aplicação Web utilizada pelos Call Centers. A razão desta aplicação ter um elevado número de automatismos, deve-se ao facto de ser uma aplicação de extrema importância para a empresa Optimus. Permite efectuar a consulta de todos os dados de todos os clientes e é utilizada em larga escala. Um erro nesta aplicação pode ter consequências muito negativas para o cliente, logo, também para a empresa. A outra aplicação que tem um elevado número de automatismos é o Site Optimus. Este está a sofrer constantes alterações logo, pretende-se garantir que determinadas operações que estavam a funcionar não sofreram nenhum impacto devido às alterações recentes realizadas. Figura Scripts Automatizados Arquitectura dos Testes de Carga A arquitectura de Testes de Carga é ligeiramente diferente da arquitectura dos Testes de Regressão. Como se pode verificar na Figura 5.19, apenas existe o programador e o servidor com a 55

78 ferramenta LoadRunner. Ou seja, ao contrário dos testes de regressão, estes testes são executados e analisados pelo programador e não pelo Tester. Como referido no Capítulo III, este tipo de teste tem como objectivo simular vários utilizadores a executarem várias operações numa determinada aplicação, de forma que se possa verificar o seu comportamento evolutivo. Figura 5.19 Arquitectura dos Scripts de Carga Fases de Construção de um Script Neste tipo de teste, as fases e metodologias de desenvolvimento do script dentro do servidor Loadrunner, são iguais às fases e metodologias utilizadas no servidor de Testes de Regressão. Pela ilustração da Figura 5.20 pode-se analisar a estrutura de um script de Testes de Carga. De salientar, que estes não utilizam nenhuma função para ler os dados a utilizar no script, os dados são definidos numa das funcionalidades da ferramenta Loadrunner (ver Secção 5.13). A única e grande diferença é na linguagem de programação. Para a elaboração dos automatismos dos testes de regressão, a linguagem de programação utilizada foi o Visual Basic (VB) enquanto para este tipo de teste a linguagem de programação utilizada foi a linguagem C. No Anexo II, na Secção Exemplo de Script LoadRunner - Site CPM encontra-se um exemplo de um script desenvolvido na ferramenta Load Runner, de acordo com esta descrição. 56

79 Figura Estrutura de um script de Teste de Carga implementado na equipa QMS Ferramenta LoadRunner O LoadRunner (Figura 5.21) é uma ferramenta desenhada para realizar testes de volume, carga ou stress. Esta ferramenta é constituída por dois componentes, o LoadRunner Virtual User Generator (para implementar os scripts) e o LoadRunner Controller (para executar cenários de testes de volume, carga ou stress). O modo de funcionamento desta ferramenta é semelhante ao QTP, ou seja, é também uma ferramenta do tipo Capture and Playback. No entanto, usa a linguagem C para gerar código. Por outro lado, quando utilizada por exemplo para simular um caso de teste, e ao nível da execução do script, não se visualiza a execução da aplicação como acontece com a ferramenta QTP. 57

80 Figura Ferramenta LoadRunner. Embora sejam bastantes as semelhanças com a ferramenta QTP, existem algumas diferenças internas. Algumas dessas diferenças são ao nível da definição de dados de teste e de configurações do script. Como mostra a Figura 5.22 os dados de teste são introduzidos numa janela dentro do script e não definidos noutra aplicação. Figura Janela de definição dos Dados de Teste. 58

81 Conhecendo-se a ferramenta QTP facilmente se utiliza o LoadRunner dado que os interfaces de utilização de ambas as ferramentas são idênticos. Para se elaborar um script os conceitos a utilizar são os mesmos para ambas as ferramentas. Na Figura 5.23 apresenta-se a estrutura de um script de Testes de Carga realizado no âmbito deste Estágio. Logs de Debug Figura Estrutura de um script de Teste de Carga. Depois de se elaborar um script, executamos o script com a ferramenta LoadRunner Controller (componente da ferramenta LoadRunner). Isto é, implementamos o script com o auxílio da ferramenta LoadRunner Virtual User Generator e com o auxílio da ferramenta LoadRunner Controller vamos simular um cenário de n utilizadores a executarem um script ou vários scripts de uma determinada aplicação, durante um determinado período de tempo. A Figura 5.24 permite visualizar a definição de um cenário, assumindo um determinado período de tempo, para um script específico. 59

82 Figura LoadRunner Controller (Definição de Cenário). Para acompanhar a evolução do número de utilizadores a provocarem carga num servidor, o LoadRunner Controller tem uma opção que permite visualizar este tipo de comportamento, assim como analisar os erros que possam ser detectados. A Figura 5.25 ilustra essa evolução. Figura LoadRunner Controller (Análise da evolução do Cenário). No final da execução do cenário definido, a ferramenta LoadRunner Controller gera um relatório que permite visualizar o comportamento do servidor da aplicação em teste, como mostra a 60

83 Figura Este relatório permite efectuar uma análise detalhada da resposta do servidor a múltiplas solicitações ao longo do tempo. Figura LoadRunner Analysis (Análise do Resultado do Cenário). O relatório gerado pela ferramenta é utilizado para tirar conclusões sobre o comportamento de determinado servidor tendo em conta número de utilizadores a provocarem carga. Essas conclusões são enviadas para as equipas responsáveis pelas aplicações e pelo servidor sujeito aos testes de carga. No Anexo III, na Secção "Exemplo de de Execução de Testes de Carga" apresenta-se o que é enviado com as conclusões fundamentadas do relatório gerado pela ferramenta LoadRunner. 61

84 6 DashBoard 6.1 Introdução Tendo em conta a elevada quantidade de informação gerada pelos Testes de Regressão e pelos Testes de Carga nos logs dos servidores, verificou-se a necessidade de encontrar uma solução para encontrar erros de forma fácil e rápida. Assim, com o objectivo de permitir à equipa de QMS uma análise mais fácil e rápida dos erros aplicacionais, instalou-se e configurou-se uma ferramenta de análise gráfica de logs. Esta ferramenta foi seleccionada depois de realizada uma pesquisa sobre ferramentas de logs. Nesta pesquisa, apenas a ferramenta Splunk respondeu aos seguintes requisitos: geração de eventos de modo estatístico, possibilidade de drill-down sobre os erros encontrados, leitura de qualquer formato de ficheiro de log e possibilidade de elaboração de regras de pesquisa para encontrar erros específicos. Outras ferramentas como por exemplo, a ferramenta AWStats, Piwik, Webalizer e Web Log Analyzer Analysis apenas permitem gerar de forma estatística dados e não permitem seleccionar ou visualizar esses dados pormenorizadamente. Assim, para atingir os objectivos, propostos no âmbito deste Estágio, definiu-se que a ferramenta a utilizar iria ser a ferramenta Splunk. A versão utilizada é a versão freeware que apresenta apenas restrições ao nível da quantidade de informação indexada. 6.2 Estrutura do Servidor Para a instalação ferramenta Splunk foi instalado um servidor Linux Red Hat, e definida uma estrutura dentro desse servidor para copiar os logs dos servidores em teste para dentro dessa estrutura. Assim, definiu-se a seguinte estrutura: /work/<nome da aplicação>/<nome do servidor>. O funcionamento da cópia de logs, assemelha-se a um sensor que periodicamente executa uma tarefa. Assim, criaram-se mecanismos para que o servidor de 5 em 5 minutos efectuasse uma cópia dos logs do servidor aplicacional para a estrutura definida. A Figura 6.1 ilustra a forma de funcionamento da estrutura implementada. Quando é efectuada uma cópia de logs de um servidor aplicacional, o Splunk analisa automaticamente se existem alterações nos logs dentro da estrutura implementada. O princípio de funcionamento da ferramenta consiste em ler os dados copiados para a estrutura, indexar esses dados, comparar se existem alterações em relação à última indexação e 62

85 apresentar os dados de forma estatística tendo em conta a regra definida para pesquisar nos logs (ver Secção 6.3). Figura 6.1. Estrutura Servidor Splunk. 6.3 Funcionalidades da Ferramenta Splunk As características que se destacam nesta ferramenta são a indexação e análise de qualquer tipo de log em tempo real. Além disso, esta ferramenta permite realizar pesquisas dentro dos logs indexados, assim como realizar Drill-Down sobre os erros. A Figura 6.2 ilustra como se pode criar uma regra para realizar uma pesquisa na ferramenta Splunk. 63

86 Figura 6.2. Definir Pesquisa no Splunk. Na opção Manager da ferramenta, como se apresenta na Figura 6.3, é o local onde se encontram as várias opções para realizar as configurações possíveis da ferramenta. No entanto, as duas opções mais importantes são a opção de definição do caminho dos logs e a opção de definição do tamanho do ficheiro dos dados indexados. Figura 6.3. Opções disponibilizadas pela ferramenta. Para se definir o local onde se encontram os logs na estrutura do servidor é utilizada a opção Data Inputs, como se apresenta na Figura

87 Figura 6.4. Opção Data Inputs. No Splunk, para se realizar a gestão do tamanho dos dados a indexar, selecciona-se a opção main, como apresenta a Figura 6.5. Esta funcionalidade é importante porque permite que se controle o tamanho do ficheiro de indexação, podendo-se ajustar o tamanho do ficheiro conforme as limitações do servidor no qual a ferramenta é instalada. Figura 6.5. Opção main. Caso de pretenda guardar mais do que um ficheiro de dados de indexação, a Figura 6.6 ilustra as opções para realizar essa configuração. 65

88 Figura 6.6. Opção Indexes. 6.4 DashBoard QMSAnalyser O DashBoard utilizado para exemplo nesta secção, apresenta dois gráficos, um corresponde aos logs do servidor do Site CPM e outro aos logs de Middleware TIBCO. O Middleware é a designação genérica utilizada para referir aos sistemas de software que se executam entre aplicações e sistemas operativos. O nome TIBCO é o nome designado pela empresa TIBCO Software Inc. que implementou o Middleware TIBCO. Assim, o Middleware TIBCO é utilizado para mover ou transportar dados entre programas que utilizam diferentes protocolos de comunicação, plataformas e dependências do sistema operativo. Foram escolhidos estes dois produtos uma vez que se encontravam em fase de testes no período da realização deste Estágio. Os eventos mostrados na Figura 6.7 são as ocorrências resultantes da pesquisa das seguintes strings: error, exception, runtime e ora. Também foi definido que o intervalo temporal a apresentar é de 24 horas, ou seja, são apenas apresentados os eventos gerados nas últimas 24 horas. 66

89 Figura 6.7. DashBoard QMSAnalyser. 6.5 Demonstração da utilidade da Ferramenta Na Figura 6.8 pode-se verificar que existe um período de tempo em que não ocorrem erros, depois de se efectuar uma análise através da ferramenta verificou-se que o servidor do Site CPM estava em baixo. Figura 6.8. DashBoard QMSAnalyser Problema 1. Outra situação é apresentada na Figura 6.9 onde se pode visualizar que ocorreu um elevado número de erros num determinado horário. Neste caso, foi um erro gerado pela própria aplicação às 5:00 AM. 67

90 Figura 6.9. DashBoard QMSAnalyser Problema 2. Por último é apresentada na Figura 6.10 a situação em que o servidor esteve desligado até as 8:00 AM (selecção A). Expõe-se ainda o resultado do DashBoard quando não são encontrados dados novos indexados nas últimas 24 horas. A B Figura DashBoard QMSAnalyser Problema 3. Esta ferramenta demonstrou muita utilidade para a equipa de QMS e para outras equipas como por exemplo a Equipa de Manutenção. As suas funcionalidades e a forma simples de utilizar foram factores fundamentais para que outras equipas passassem a utilizar esta ferramenta de forma intensiva. 68

91 7 Conclusão A realização deste Estágio proporcionou uma oportunidade excepcional para colocar em prática conhecimentos e experiências adquiridos ao nível académico, no âmbito da Licenciatura em Engenharia Electrotécnica e do Mestrado em Automação e Comunicações em Sistemas de Energia do Instituto Superior de Engenharia de Coimbra. Por outro lado, proporcionou a aquisição de novos conhecimentos ao nível do Projecto de Software dos Testes de Software e das Ferramentas de Automatização de Casos de Teste. Inicialmente, foram encontradas algumas dificuldades, principalmente na interligação da ferramenta QTP com as bases de dados e na adaptação à linguagem específica relacionada com os processos de negócio utilizados na empresa Optimus. Surgiram também alguns problemas devido ao facto de se estarem a utilizar ferramentas sem existir experiência anterior, como o caso do QTP e Loadrunner. No entanto, existiu uma fase de adaptação progressiva às ferramentas que tornou possível uma relativa naturalidade e confiança quando da automatização dos casos de teste. Outra dificuldade, dado que apenas existiam os conhecimentos e experiência académicos, foi a utilização do Linux. As dificuldades revelaram-se principalmente ao nível da instalação da ferramenta Splunk, assim como na implementação da metodologia necessária para que o servidor onde é instalado o Splunk possa obter os ficheiros de log de outros servidores da empresa Optimus. Todos os problemas que foram surgindo ao longo do Estágio foram solucionados da melhor forma, através de pesquisa individual e apoio de outros elementos da Equipa QMS, o que tornou a experiência mais enriquecedora, dado o objectivo de encontrar a solução para ultrapassar cada problema específico. Para trabalhos futuros, e como valorização mais imediata do trabalho desenvolvido, propõe-se o desenvolvimento de scripts para testes de regressão que deverão funcionar em vários Browsers, como por exemplo Safari, Opera e Camino. 69

92 Por fim, conclui-se que os objectivos propostos no âmbito deste Estágio foram alcançados com sucesso. A nível profissional foi uma experiência muito enriquecedora, pela integração numa realidade empresarial e pela exposição a conceitos não utilizados anteriormente. Em termos pessoais foi uma experiência também bastante positiva devido ao ambiente muito saudável e de cooperação existente na equipa de QMS da empresa Optimus. 70

93 Referências [Almeida, 2010 ] "Teste de Software Limitações e Benefícios". Disponível em visitado a última vez em 3 de junho de 2010 [Andrew, 2005] Andrew Stellman&Jennifer Greene, Applied Software Project Management, O REILLY, 2005 [Aniela, 2010] Aniela Cole, "Automatização de testes".disponível em visitado a última vez 19 de Novembro de 2010 [Azevedo, 2008] Samanta Pinto De Azevedo, MODELO DE AVALIAÇÃO DA QUALIDADE FUNCIONAL DE SOFTWARE BASEADO NA NORMA NBR ISO/IEC Disponível em visitado a última vez 19 de Fevereiro de 2010 [Beizer, 1995] Beizer, B., Black-Box Testing: techniques for funcional testing of software and system, Wiley,New York, 1995 [Bastos, 2007] Bastos, Anderson. Base de conhecimento em teste de software, 2007 [Caetano, 2009] "Engenharia de Software Magazine Gestão de Testes". Disponível em visitado a última vez 22 de Março [Celapar, 2009] "Evolução de Software". Disponível em visitado a última vez 22 de Março de 2010 [Cem at al, 2001] Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software Testing, John Wiley & Sons, Ins, 2001 [Ciclos, 2010] "Modelos ciclo de vida". Disponível em visitado a última vez em 3 de junho de 2010 [Correia et al, 2004] Simone Antunes Correia, Alberto Rodrigues da Silva, Artigo Técnicas para Construção de Testes Funcionais Automáticos, [Fantinato at al, 2008] Marcelo Fantinato, Adriano C. R. da Cunha, Sindo V. Dias, Sueli A.Mizuno, Cleida A. Q. Cunha, "AutoTest Um Framework Reutilizável para a Automação de Teste Funcional de Software". Disponível em visitado a última vez em 5 de Novembro de 2010 [Ferramentas, 2010] Qualidade Software. Disponível em visitado a última vez 15 de Fevereiro de 2010 [Fewster at al, 1999] M.Fewster e D.Grahm, Software Test Automation, Addison-Wesley, [Horch, 1996] Horch, J., Practical Guide to Software Quality Management, Artech House Publishers, London,

94 [IEEE, 1990] IEEE. Ieee standard glossary of software engineering terminology. Standard , IEEE Press, 1990 [Ireland, 1991] Ireland, L., Quality Management for Projects & Programs, Project Management Institute, Inc, 1991 [Jack, 1999] Jack Falk, Cem Kaner, Hung Quoc Nguyen, Testing Computer Software, Jonh Wiley & Sons,Inc, 1999 [Jenner, 1995] Michael G. Jenner, Software Quality Management and IS0 9001, Jonh Wiley & Sons,Inc, 1995 [Macoratti, 2008] "Um esboço sobre o processo de Testes de Software". Disponível em visitado a última vez 22 de Março de 2010 [Mariana, 2010] "TESTES DE SOFTWARE NO WEBPOSGRAD NTI/UFPB". Disponível em visitado a última vez 22 de Março de 2010 [Martha, 2008] Maria Martha, "A importância dos testes automatizados".disponível em visitado a última vez 19 de Novembro de 2010 [Manutenibilidade, 2010] Manutenibilidade. Disponível em visitado a última vez em 7 de dezembro de 2010 [Miguel, 2003] Antonio Miguel, Gestão de Projectos de Software, FCA, 2003 [Miguel, 2004] Antonio Miguel, Gestão Moderna de Projectos, FCA, 2004 [Myers et al, 2004] MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, 2004 [Nina, 2007] Nina S. Godbole, Software Quality Assurence Principles and Practice, Alpha Science, 2007 [Optimus, 2010] Sobre a Optimus. Disponível em visitado a última vez em 2010 [Pfleeger, 2004] PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática, Pearson Brasil, 2004 [Prass, 2010] Fernando Prass, "Engenharia de Software". Disponível em visitado a última vez em 3 de junho de 2010 [Pressmann, 1995] Pressmann, Roger S. Engenharia de Software,Pearson Makron Books, 1995 [Pushtotest, 2009] Testmaker, Disponível em -methodology, visitado a última vez em 2010 [Qualidade, 2010] Qualidade de Software. Disponível em visitado a última vez em 5 de outubro de 2010 [Rocha et al,2001] Rocha, Ana Regina, Maldonado, José, Weber, Kival. Qualidade de Software: teoria e prática. Prentice Hall,

95 [Ron, 2005] Ron Patton, Software Testing, Sams Publishing, 2005 [Ruby, 2010] Linguagem-Ruby. Disponível em Linguagem-Ruby.html, visitado a última vez em 2010 [Sommerville, 2000] Sommerville. Software Engineering, Addison-Wesley, 2000 [Sonaecom, 2010] ÁREAS DE EGÓCIO. Disponível em visitado a última vez em 2010 [Teste, 2010] Teste de Software, visitado a última vez em 12 de dezembro de 2010 [Testexpert, 2009] Testes de Software, Disponível em visitado a última vez em 2009 [Tozelli, 2008] Paulo Tozelli, "Processo de Teste de Software". Disponível em visitado a última vez 19 de Fevereiro de 2010 [Travassos at al, 2007] "Teste de Software". Disponível em visitado a última vez 22 de Março [Vinicius, 2008] Vinicius Sabadoti, "Histórico sobre Testes de Software". Disponível em visitado a última vez em 5 de Novembro de 2010 [William, 2000] William E. Lewis, Software Testing and Continuous Quality Improvement, Auerbach, 2000 [Wintrust, 2006] "Melhoria de Conhecimentos em Garantia de Qualidade no Software". Disponível em 6_0719_Tipos_de_teste.pdf, visitado a última vez 22 de Março [Kon at al, 2008] Paulo Cheque Bernardo e Fabio Kon, "A Importância dos Testes Automatizados". Disponível em visitado a última vez 19 de Novembro de

96 74

97 Anexo I Exemplo de Caso de Teste Exemplo Caso de Teste Site CPM Script ame CPM_ADD_REMOVE_OCCS_QTP Descrição do script Adição de OCCs a um contracto no CPM Produtos envolvidos CPM Especificação de Teste Automático Acções do script Abrir o browser, colocar o link identidificado nas variáveis, user e password. Carregar no botão SonaeCom. (*1) Colocar o parâmetro IDConta no campo Conta, carregar no botão Procurar, seleccionar na árvore o msisdn identificado no campo MSISDN, escolher o menu Descontos e Créditos, escolher o submenu que tenha o texto identificado no parâmetro Action. No caso de ser escolhida a opção Atribuição de OCCs é seleccionado o serviço identificado no parâmetro Action e escolhido o rádio button Débito, a favor da SonaeCom ou Crédito, a favor do Cliente consuante o valor do parametro DebitoCredito seja D ou C. De seguida o valor do parâmetro Quantia é colocado no campo Quantia. O primeiro valor da listbox da esquerda é escolhido e carregado na seta para a direita verde, passando o valor escolhido para a listbox da direita. No fim é carregado no botão Confirmar. No caso de ser escolhida a opção Remoção de OCCs é escolhida a primeira linha para o MSISDN em causa e escolhido o botão Remover. De seguida escolhe-se o link Voltar à janela principal. Caso existam mais interacções serão executadas neste ponto, retomando o local (*1). Deverá ser depois feito o logout carregando no botão Sair CPM. Wink D_REMOVE_OCCS_QTP/Add_OCCs.htm D_REMOVE_OCCS_QTP/Remove_OCCs.htm Variáveis a utilizar pelo script Link: User: QMS8 Pass: 75

98 Input Data do script Ordem Campo Descrição 1 IDConta ID da conta a pesquisar 2 MSISDN MSISDN a seleccionar na arvore 3 Action Texto do menu pretendido Atribuicao de OCCs ou Remocao de OCCs 4 Servico Serviço seleccionado (apenas usado no caso de Atribuição de OCCs) 5 DebitoCredito Indicação se é a débito ou a crédito (apenas usado no caso de Atribuição de OCCs) 6 Quantia Quantia em euros (apenas usado no caso de atribuição de OCCs) Query de input data SELECT cus.custcode IDConta,a.dn_num MSISDN,'Atribuição de OCCs' Action,'Acerto de Bónus' Servico,'D' DebitoCredito,'121.00' Quantia,cus.customer_id,SYSDATE from directory_number a, contr_services_cap b, contract_all c, curr_co_status d, customer_all cus where c.tmcode=123 and not exists ( select '1' from CUST_BCH_PROCESS CBP where cbp.customer_id =c.customer_id ) and c.co_id=d.co_id and d.ch_status='a' and b.co_id=c.co_id and b.cs_deactiv_date is null and a.dn_id=b.dn_id and cus.customer_id=c.customer_id and c.tmcode in (select tmcode from opclass_rate_plan where upper(consume_des) like 'OPTIMUS') and not exists (select 1 from fees f where f.customer_id=cus.customer_id and username='qms8') and cus.customer_id>10000 and rownum<=2 Query de validação select TSTAUTO_CPM_ADD_REMOVE_OCCS_1(<<param5>>,<<param4>>,'QMS8') RES from dual CREATE OR REPLACE FUNCTION tstauto_cpm_add_remove_occs_1 (acc IN String, amt IN String, iuser IN String) RETURN Number IS lonres Number; ccid number; aa number; BEGIN --ccid:=0; lonres:=0; aa:=10; ccid:=acc; aa:=20; select count(*) into lonres from fees where customer_id=ccid and amount=to_number(amt) and username=iuser; aa:=30; if nvl(lonres, 0) >= 1 then return 1; end if; 76

99 return 0; Exception When NO_DATA_FOUND Then return aa+1; When Others Then return aa+2; end; 77

100 Anexo II - Exemplos de Automatismos Exemplo Script Quality Center Site CPM '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' CONFIGURACOES TD '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Qc_Startup_Vars "CPM_ADD_REMOVE_OCCS_TST","CPM","CPM_EXPECTED","Action1 [CPM_LOGIN]","Action1 [CPM_LOGOUT]" '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' ACÇÃO PRINCIPAL '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [CPM_ADD_REMOVE_OCCS_TEST] [2]", oneiteration Exemplo Script Controlo ou Principal Site CPM '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' KILL PROCESSES START '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SystemUtil.CloseProcessByName("IEXPLORE.EXE") SystemUtil.CloseProcessByName("CLOCK.EXE") ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START init ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [init]", oneiteration '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START MNEMONIC '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' inimnemonica "Task0", "mnemonicatask0", "CPM_TST_AVAILABILITY" inimnemonica "Login", "mnemonicalogin", "CPM_QTP_LOGIN" inimnemonica "Task1", "mnemonicatask1", "CPM_TST_PESQUISA_CONTA" inimnemonica "Task2", "mnemonicatask2", "CPM_TST_SELECCIONAR_DESCONTOS_CREDITOS" inimnemonica "Task3", "mnemonicatask3", "CPM_TST_ALTERAR_DADOS_CONTA" inimnemonica "Task4", "mnemonicatask4", "CPM_TST_VOLTAR_JANELA_PRINCIPAL" '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''AVAILABILITY & LOGIN ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' accao.runeval Environment.Value("actionLogin"), Environment.Value("actionLogout") 'RunAction "Action1 [CPM_LOGIN]", oneiteration '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START Get TestData '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 'Obter TestData gettestdataconfig IdTestData,Parametros,valorarray ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START TASKS '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [CPM_ADD_REMOVE_OCCS_TST] [2]", alliterations ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''' LOGOUT ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [CPM_LOGOUT] [2]", oneiteration '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' KILL PROCESSES END 78

101 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SystemUtil.CloseProcessByName("IEXPLORE.EXE") SystemUtil.CloseProcessByName("CLOCK.EXE") Exemplo Script Suporte Site CPM ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 1 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Dim ArrayQuery ArrayQuery = Array("MSISDN","DESCBASE","AGENTE","CUSTID","ESCOLHA_MENU") For jarray=0 to ubound(arrayquery) Environment.Value(""& ArrayQuery(jArray)&"")=DataTable.GetSheet("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]").GetParameter("Col_"&jArray&"").Value Next If environment("escolha_menu")="dd" Then Environment.Value("selectOptions")="Descontos_Creditos/DescontosDirectos" else Environment.Value("selectOptions")="Descontos_Creditos/Atribuicao_de_Descontos_Sobre_Mensalidades" End If writetd 0,"Key test data","values:"&environment.value("msisdn")&"; "&Environment.Value("DESCBASE")&"; "&Environment.Value("AGENTE") ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 1 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Procurar MSISDN", environment.value("mnemonicatask1"), 3, "Task1Error", False RunAction "Action1 [PesquisaMSISDN] [CPM_COMMON]", oneiteration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 2 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Seleccionar Servios", environment.value("mnemonicatask2"), 4, "Task2Error", False RunAction "Action1 [SeleccionarOpcoesCPM] [CPM_COMMON]", oneiteration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 3 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Preencher dados", environment.value("mnemonicatask3"), 5, "Task3Error", False Environment.Value("DESCBASE")=replace(Environment.Value("DESCBASE"),"0","") checkpathobject Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebList("cboNewRate"),"WebList(cboNewRate) - Exist " Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebList("cboNewRate").Select Environment.Value("DESCBASE") checkpathobject Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebList("cbDealers"),"WebList(cbDealers) - Exist " Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebList("cbDealers").Select Environment.Value("AGENTE") checkpathobject Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebButton("Validar Dealer"),"WebButton(Validar Dealer) - Exist " Browser("Customer Process Management").Page("Customer Process Management").Frame("main_5").WebButton("Validar Dealer").Click ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 5 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Confirmar Alteracao de Servios", environment.value("mnemonicatask5"), 7, "Task5Error", False If Environment.value("intrusivo")=False Then RunAction "Action1 [ClickCancelarLimpar] [CPM_COMMON]", oneiteration else RunAction "Action1 [ClickConfirmar] [CPM_COMMON]", oneiteration 79

102 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 6 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Voltar Janela Principal", environment.value("mnemonicatask6"), 8, "Task6Error", False RunAction "Action1 [VoltarJanelaPrincipal] [CPM_COMMON]", oneiteration '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START VALIDATION ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' checkvalitation end if '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' END TASKS '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Exemplo Script Suporte Login Site CPM initransaccao "Acesso", environment.value("mnemonicatask0"), 1, "Availability Error", False initvars writetd 0,"Key config","login:"&environment.value("url")&"; "&Environment.Value("userName") environment.value("rc") = initbrowser () 'Regista Transacao environment.value("transaccaoactual").regista MercuryTimers("Timer1").ElapsedTime, "WebEdit Username - Exist", "Action1 [CPM_LOGOUT]" '''''''''''''''''''''''''''''''''''''''' ''' LOGIN '''''''''''''''''''''''''''''''''''''''' initransaccao "Acesso", environment.value("mnemonicalogin"), 2, "Login Error", False environment.value("rc")=browser("credits Login Page").Page("Credits Login Page_3").WebEdit("txtUser").Exist(Environment.Value("WaitTime")) checkaction "WebEdit username - Exist" Browser("Credits Login Page").Page("Credits Login Page_3").WebEdit("txtUser").Set(Environment.Value("userName") environment.value("rc")=browser("credits Login Page").Page("Credits Login Page_3").WebEdit("txtPasswd").Exist Environment.Value("WaitTime")) checkaction "WebEdit - pwd - Exist" Browser("Credits Login Page").Page("Credits Login Page_3").WebEdit("txtPasswd").Set(Environment.Value("passWord")) '==>> BUTTON environment.value("rc")=browser("credits Login Page").Page("Credits Login Page_2").WebButton("LOGIN").Exist (Environment.Value("WaitTime")) checkaction "Image - Entrar - Exists" Browser("Credits Login Page").Page("Credits Login Page_2").WebButton("LOGIN").Click cmd_timer "Start", environment.value("transaccaoactual").mnemonica 'inicia contagem environment.value("rc")= Browser("Credits Login Page").Page("Customer Process Management").Frame("fraSearch").WebButton("Procurar").Exist(Environment.Value("WaitTime")) cmd_timer "Stop", environment.value("transaccaoactual").mnemonica 'termina contagem Environment.Value("accessTime") = MercuryTimers("Timer1").ElapsedTime checkaction " Page - Customer Process Management - Exist" environment.value("transaccaoactual").regista MercuryTimers("Timer1").ElapsedTime, "Page - Customer Process Management - Exist", "Action1 [CPM_LOGOUT]" 80

103 Exemplo Script Suporte Logout Site CPM '''''''''''''''''''''''''''''''''''''''' ''' LOGOUT '''''''''''''''''''''''''''''''''''''''' Browser("Customer Process Management").Page("Customer Process Management").Frame("rSide").Link("Sair do CPM").Click Browser("Customer Process Management").Page("Credits Login Page").Sync Browser("Customer Process Management").Close Exemplo Script Controlo ou Principal Site Optimus '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START init ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [init]", oneiteration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''Get Values from F_CONFIG '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' getconfig "peaktimeend", "PEAK_TIME_END_INT_1" getconfig "peaktimebegin", "PEAK_TIME_BEGIN_INT_1" getconfig "username", "USER" getconfig "password", "PASSWORD" getconfig "url", "SOPT_URL" ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START MNEMONIC ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' inimnemonica "Task0", "mnemonicatask0", "SOPT_TST_AVAILABILITY" inimnemonica "Login", "mnemonicalogin", "SOPT_QTP_LOGIN" inimnemonica "Task1", "mnemonicatask1", "SOPT_QTP_GESTAO_CONTA" inimnemonica "Task2", "mnemonicatask2", "SOPT_QTP_EMPRESAS_PROFISSIONAIS" inimnemonica "Task3", "mnemonicatask3", "SOPT_QTP_EMPRESAS_PROFISSIONAIS" '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START Get TestData '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 'Obter Test Data gettestdata IdTestData,Parametros,valorarray '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' ACTIONS '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' call RunAction ("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]", alliterations ) Exemplo Script Suporte Site Optimus ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 'Produtos envolvidos: STOPTIMUS 'Versão em que foi implementado: WS_R.1.15 'TestData: ver definição de váriaveis em baixo 'Validações efectuadas pelo script: O script tem por objectivo efectuar o envio de MMS através da Gestão de Conta, devem ser efectuados check points de sucesso de envio ' validamos também as mensagens de erro caso a imagem seja maior que o valor máximo ou que o ficheiro não seja do tipo imagem. ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 1 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Dim ArrayQuery ArrayQuery = Array("p_msisdn "," p_password "," p_assunto_mms " p_assunto_mms " p_ficheiro_mms "," p_texto_mms ", p_msisdn_destino, p_ficheiro_mms_grande, p_ficheiro_mms_exe, validatarifario_testdata ) 81

104 For jarray=0 to ubound(arrayquery) Environment.Value(""& ArrayQuery(jArray)&"")=DataTable.GetSheet("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]").GetParameter("Col_"&jArray&"").Value Next writetd 0,"Key test data","values:"& Environment("p_msisdn")&"; "&Environment("p_password") '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''AVAILABILITY & LOGIN ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "OPT_Login [OPT_COMMON_ACTIONS] [2]", oneiteration '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' START TASK 1 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' initransaccao "Procurar Rede", environment.value("mnemonicatask1"), 3, "Task1Error", False environment.value("rc")=browser("optimus Particulares").Page("OPTIMUS Particulares").Link("Gestão de Conta").Exist (Environment.Value("WaitTime")) checkaction "Link(Gestão de Conta) - Exist" Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares").Link("Gestão de Conta").Click RunAction "Check_URL [OPT_COMMON_ACTIONS]", oneiteration ' Inicio de novo código environment.value("rc")= Browser("OPTIMUS Particulares").Page("particulares» Optimus").Link("Enviar SMS e MMS").Exist (Environment.Value("WaitTime")) checkaction "Link(Enviar SMS e MMS) - Exist" Browser("OPTIMUS Particulares").Page("particulares» Optimus").Link("Enviar SMS e MMS").Click 'Envio de SMS com sucesso environment.value("rc")=browser("optimus Particulares").Page("particulares» Optimus_2").Link("MMS").Exist (Environment.Value("WaitTime")) checkaction "Link(MMS) - Exist" Browser("OPTIMUS Particulares").Page("particulares» Optimus_2").Link("MMS").Click environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t").Set Environment ("p_assunto_mms") environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar").WebFile("ctl00$MainContentPlaceHolder$f").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar").WebFile("ctl00$MainContentPlaceHolder$f").Set Environment("p_ficheiro_mms") environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t_2").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t_2").Set Environment ("p_texto_mms") environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t_3").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" rowser("optimus Particulares").Page("particulares»...» Enviar").WebEdit("ctl00$MainContentPlaceHolder$t_3").Set Environment ("p_msisdn_destino") 'Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_3").Link("Lista de contactos").click Executa se for Intrusivo If environment.value("intrusivo")=true Then environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar").Image("Enviar").Exist (Environment.Value("WaitTime")) checkaction "Image(Enviar) - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar").Image("Enviar").Click ' COLOCAR check point de validação de sucesso ' Validação de tamanho de ficheiro environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar_2").WebFile("ctl00$MainContentPlaceHolder$f").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").WebFile("ctl00$MainContentPlaceHolder$f").Set Environment ("p_ficheiro_mms_grande") 82

105 environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar_2").Image("Enviar").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").Image("Enviar").Click Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").WebElement("A imagem seleccionada").check CheckPoint("A imagem seleccionada excede o tamanho máximo de 300 KB!") ' Validação de tipo de ficheiro environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar_2").WebFile("ctl00$MainContentPlaceHolder$f").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").WebFile("ctl00$MainContentPlaceHolder$f").Set Environment("p_ficheiro_mms_exe") environment.value("rc")=browser("optimus Particulares").Page("particulares»...» Enviar_2").Image("Enviar").Exist (Environment.Value("WaitTime")) checkaction "Image(Enviar) - Exist" Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").Image("Enviar").Click Browser("OPTIMUS Particulares").Page("particulares»...» Enviar_2").WebElement("O ficheiro seleccionado").check CheckPoint("O ficheiro seleccionado não é do tipo imagem!") end if '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' LOGOUT ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "OPT_Logout [OPT_COMMON_ACTIONS] [2]", oneiteration Exemplo Script Suporte Login Site Optimus '''''''''''''''''''''''''''''''''''''''' ''' LOGIN '''''''''''''''''''''''''''''''''''''''' initransaccao "Acesso", environment.value("mnemonicalogin"), 2, "Login Error", False environment.value("rc")=browser("optimus Particulares").Page("OPTIMUS Particulares").Link("login").Exist (Environment.Value("WaitTime")) checkaction "Link(login) - Exist" Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares").Link("login").Click environment.value("rc")=browser("optimus Particulares").Page("particulares» Optimus").WebEdit("ctl00$MainContentPlaceHolder$T").Exist (Environment.Value("WaitTime")) checkaction "WebEdit Msisdn - Exist" Browser("OPTIMUS Particulares").Page("particulares» Optimus_2").WebEdit("ctl00$MainContentPlaceHolder$T").Set Environment("p_msisdn") environment.value("rc")=browser("optimus Particulares").Page("particulares» Optimus").WebEdit("ctl00$MainContentPlaceHolder$T_2").Exist (Environment.Value("WaitTime")) checkaction "WebEdit - pwd - Exist" Browser("OPTIMUS Particulares").Page("particulares» Optimus_2").WebEdit("ctl00$MainContentPlaceHolder$T_2").Set Environment("p_password") '==>> BUTTON environment.value("rc")=browser("optimus Particulares").Page("particulares» Optimus").Image("Login").Exist (Environment.Value("WaitTime")) checkaction "Image - Entrar - Exists" Browser("OPTIMUS Particulares").Page("particulares» Optimus").Image("Login").Click cmd_timer "Start", environment.value("transaccaoactual").mnemonica 'inicia contagem Browser("OPTIMUS Particulares").Sync environment.value("rc")= Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares_2").Link("logout").Exist(Environment.Value("waitTimeLogin")) cmd_timer "Stop", environment.value("transaccaoactual").mnemonica 'termina contagem Environment.Value("accessTime") = MercuryTimers("Timer1").ElapsedTime checkaction " Link(logout) - Exist" environment.value("transaccaoactual").regista MercuryTimers("Timer1").ElapsedTime, "Link(logout) - Exist", "OPT_Logout [OPT_COMMON_ACTIONS]" 83

106 Exemplo Script Suporte Logout Site Optimus '''''''''''''''''''''''''''''''''''''''' ''' LOGOUT '''''''''''''''''''''''''''''''''''''''' ' Acção comum de Logout no Site Optimus como cliente particular. ' Para invocar esta acção, o script deve estar numa página principal onde exista o link geral de logout. ' Click na opção de Logout Environment.Value("rc")=Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares").Link("logout").Exist (Environment.Value("WaitTime")) checkaction "Link(Logout) - Exist" Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares").Link("logout").Click Environment.Value("rc")=Browser("OPTIMUS Particulares").Page("OPTIMUS Particulares_2").Link("login").Exist (Environment.Value("WaitTime")) checkaction "Link(Efectuou Logout) - Exist" WebUtil.DeleteCookies Exemplo Script Controlo ou Principal Site Kanguru '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START init ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [init]", oneiteration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' START Mnemonic ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' inimnemonica "Task0", "mnemonicatask0", "STOPT_TST_AVAILABILITY" inimnemonica "Login", "mnemonicalogin", "STOPT_QTP_LOGIN" '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START Get TestData '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' Inicializar Test Data e Variáveis da Config gettestdata_config valorarray, numln, numcol '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' START Script Navigation '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Action1 [SOPT_KANG_GESTCONTA_TST] [2]", oneiteration Exemplo Script Suporte Site Kanguru ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '' READ TESTDATA '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Environment("p_msisdn")=DataTable.GetSheet("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]").GetParameter("Col_0").Value Environment("p_password")=DataTable.GetSheet("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]").GetParameter("Col_1").Value Environment("valitation_Tarifario")=DataTable.GetSheet("Action1 ["&Environment.Value("NAME_SUBSCRIPT")&"]").GetParameter("Col_2").Value writetd 0,"Key test data","values: "&Environment("p_msisdn")&"; "&Environment("p_password")&"; "&Environment("valitation_Tarifario") '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''AVAILABILITY & LOGIN ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction Environment.Value("actionLogin"), oneiteration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''' Click Gestão de Conta ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' RunAction "Click_Gestao_Conta [OPT_COMMON_ACTIONS] [2]", oneiteration 'Browser("OPTIMUS Particulares").Page("particulares» Kanguru").Sync 84

107 'Browser("OPTIMUS Particulares").Page("particulares» Kanguru").WebElement("Kanguru Portátil Basic").Output CheckPoint("Kanguru Portátil Basic CC") Browser("OPTIMUS Particulares").Page("particulares» Kanguru_2").Sync Browser("OPTIMUS Particulares").Page("particulares» Kanguru_2").Output CheckPoint("particulares» Kanguru» Gestão de Conta") If environment.value("check_tarifario_kanguru")=environment("valitation_tarifario") then writetd 0,"Tarifário Kanguru Portátil Basic CC ", " Tarifario "&environment.value("check_tarifario_kanguru") else end if writetd 1,"Erro: Tarifário Incorrecto ", " Tarifario "&environment.value("check_tarifario_kanguru") Environment.Value("rc")=False checkaction "Tarifário Incorrecto" 85

108 Anexo III Exemplos de Relatórios Exemplo de ewsletter da Equipa de QMS 86

109 Exemplo de de Execução de Testes de Carga 87

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste)

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste) Melhoria de Conhecimentos em Garantia de Qualidade no Software (Tipos de Teste) Av. Conde de Valbom, nº 30 8º 1050-068 Lisboa Telf: +351 213 510 540 Fax: +351 213 510 549 Controlo do Documento Elaborado

Leia mais

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações Sistemas Multimédia Arquitectura Protocolar Simples Modelo OSI TCP/IP Redes e Comunicações Francisco Maia famaia@gmail.com Já estudado... Motivação Breve História Conceitos Básicos Tipos de Redes Componentes

Leia mais

Verificação e Validação

Verificação e Validação Verificação e Validação Patrícia Macedo Joaquim Filipe João Ascenso 2005/2006 EST, Setúbal Verificação e Validação Verificação Garante que o software cumpre as especificações Consistência interna Estamos

Leia mais

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G Escola Superior de Gestão de Santarém Pedido de Registo do CET Instalação e Manutenção de Redes e Sistemas Informáticos Peça Instrutória G Conteúdo programático sumário de cada unidade de formação TÉCNICAS

Leia mais

Escola Básica 2, 3 de Lamaçães Planificação Anual 2007/08 Tecnologias de Informação e Comunicação

Escola Básica 2, 3 de Lamaçães Planificação Anual 2007/08 Tecnologias de Informação e Comunicação Escola Básica 2, 3 de Lamaçães Planificação Anual 2007/08 Tecnologias de Informação e Comunicação Unidade de Ensino/Aprendizagem Tecnologias da Informação e Comunicação Conceitos Introdutórios Conceitos

Leia mais

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem:

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem: Descrição de Serviços Serviços de Planeamento e Empresarial Os Serviços de Planeamento e Empresarial fornecem serviços de consultoria e prototipagem para facilitar a agenda do Licenciado relativa à inovação

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005 ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade 2005 Estrutura da Norma 0. Introdução 1. Campo de Aplicação 2. Referência Normativa 3. Termos e Definições 4. Sistema de Gestã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

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft A solução MB DOX oferece uma vantagem competitiva às empresas, com a redução do custo de operação, e dá um impulso à factura

Leia mais

A VISTA BACKSTAGE PRINCIPAIS OPÇÕES NO ECRÃ DE ACESSO

A VISTA BACKSTAGE PRINCIPAIS OPÇÕES NO ECRÃ DE ACESSO DOMINE A 110% ACCESS 2010 A VISTA BACKSTAGE Assim que é activado o Access, é visualizado o ecrã principal de acesso na nova vista Backstage. Após aceder ao Access 2010, no canto superior esquerdo do Friso,

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Conceitos Sistema da informação e comunicação N.º de Aulas

Conceitos Sistema da informação e comunicação N.º de Aulas PLANIFICAÇÃO AGRUPAMENTO ANUAL - DE TECNOLOGIAS ANO ESCOLAS LECTIVO DR. VIEIRA DE CARVALHO 9º ANO 2008/2009 DA INFORMAÇÃO E COMUNICAÇÃO Tecnologias 1º Período Conceitos Sistema da informação e comunicaçã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

Planificação Anual. Planificação de Médio Prazo (1.º Período) Tecnologias da Informação e Comunicação. 9º Ano

Planificação Anual. Planificação de Médio Prazo (1.º Período) Tecnologias da Informação e Comunicação. 9º Ano Escola Básica do 2º e 3º Ciclos João Afonso de Aveiro Departamento de Matemática e Ciências Experimentais Secção de Informática Planificação Anual (1.º Período) Ano lectivo 2010/2011 Tecnologias da Informação

Leia mais

3. Engenharia de Requisitos

3. Engenharia de Requisitos Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton)

Leia mais

Vídeo Vigilância Abordagem Open-Source

Vídeo Vigilância Abordagem Open-Source Vídeo Vigilância Abordagem Open-Source Alunos: Justino Santos, Paulo Neto E-mail: eic10428@student.estg.ipleiria.pt, eic10438@student.estg.ipleiria.pt Orientadores: Prof. Filipe Neves, Prof. Paulo Costa

Leia mais

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO Robson L. Nascimento 1, Késsia R. C. Marchi¹ 1 Universidade Paranaense (UNIPAR) Paranavaí-PR-Brasil robsonluisn@yahoo.com.br,

Leia mais

ESCOLA SECUNDÁRIA MANUEL DA FONSECA, SANTIAGO DO CACÉM GRUPO DISICPLINAR - Informática ANO: 8º TICT2 ANO LECTIVO: 2008/2009 p.1/9

ESCOLA SECUNDÁRIA MANUEL DA FONSECA, SANTIAGO DO CACÉM GRUPO DISICPLINAR - Informática ANO: 8º TICT2 ANO LECTIVO: 2008/2009 p.1/9 ANO: 8º TICT2 ANO LECTIVO: 2008/2009 p.1/9 Módulo 1 Tecnologias da Informação e Comunicação 1.1 Conceitos Essenciais Conceitos Básicos o Informática o Tecnologias da Informação o Tecnologias da Informação

Leia mais

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Leia mais

Linha Silk: a maneira leve para testar, desenvolver e gerenciar

Linha Silk: a maneira leve para testar, desenvolver e gerenciar Linha : a maneira leve para testar, desenvolver e gerenciar Leve Criado apenas com a funcionalidade que você precisa Barato Do uso gratuito ao licenciamento flexível Eficiente Software fácil de usar e

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

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

manual instalação e configuração v13 1

manual instalação e configuração v13 1 manual instalação e configuração v13 1 Conteúdo Introdução... 3 Conteúdo do DVD:... 3 Instalação e configuração do ERP... 4 Instalação do ERP... 4 Configuração do ERP... 6 Como actualização de versão...

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 13 Web Services Web Services

Leia mais

1. Contratos de aluguer automóvel

1. Contratos de aluguer automóvel 1. Contratos de aluguer automóvel Pretende-se desenvolver um Sistema Informático para apoio à gestão de Contratos de Aluguer automóvel de Longa-duração (SICAL) que permita efectuar, cancelar e modificar

Leia mais

1 Ajuda da Internet M vel Clix

1 Ajuda da Internet M vel Clix 1 Ajuda da Internet M vel Clix Descrição geral Esta aplicação permite Ligar/Desligar por intermédio de uma PC Card / Modem USB. Janela principal da Internet M vel Clix Indica o estado de roaming Minimizes

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade e Auditorias (Mestrado em Engenharia Alimentar) Gestão da Qualidade (Mestrado em Biocombustívies) ESAC/João Noronha Novembro

Leia mais

Introdução à Tecnologia Web. Ferramentas e Tecnologias de Desenvolvimento Web. Profª MSc. Elizabete Munzlinger www.elizabete.com.

Introdução à Tecnologia Web. Ferramentas e Tecnologias de Desenvolvimento Web. Profª MSc. Elizabete Munzlinger www.elizabete.com. IntroduçãoàTecnologiaWeb FerramentaseTecnologiasde DesenvolvimentoWeb ProfªMSc.ElizabeteMunzlinger www.elizabete.com.br ProfªMSc.ElizabeteMunzlinger www.elizabete.com.br FerramentaseTecnologiasde DesenvolvimentoWeb

Leia mais

Introdução. 1.1. Âmbito do Documento

Introdução. 1.1. Âmbito do Documento Introdução Embora o conceito de virtualização, não seja um conceito novo, o uso desta tecnologia vem crescendo exponencialmente nas infra-estruturas de TI. Este crescimento deve-se sobretudo aos benefícios

Leia mais

Qpoint Rumo à Excelência Empresarial

Qpoint Rumo à Excelência Empresarial 2 PRIMAVERA BSS Qpoint Rumo à Excelência Empresarial Numa era em que a competitividade entre as organizações é decisiva para o sucesso empresarial, a aposta na qualidade e na melhoria contínua da performance

Leia mais

Versão 1.0. [08.02.2012] 2012, Portugal - Efacec Sistemas de Gestão S.A. Todos os direitos reservados. 1

Versão 1.0. [08.02.2012] 2012, Portugal - Efacec Sistemas de Gestão S.A. Todos os direitos reservados. 1 Copyright 2012 Efacec Todos os direitos reservados. Não é permitida qualquer cópia, reprodução, transmissão ou utilização deste documento sem a prévia autorização escrita da Efacec Sistemas de Gestão S.A.

Leia mais

Quality Assurance & Test Center. Experiência, Metodologia e Ferramentas

Quality Assurance & Test Center. Experiência, Metodologia e Ferramentas Experiência, Metodologia e Ferramentas Março de 2008 Índice 1. Enquadramento 3 2. Experiência e referências 3 2.1 Evolução e principais projectos 3 2.2 Certificações 4 3. Metodologia de testes Link 4 3.1

Leia mais

Projecto SDAC 2010. Sistema Operativo Open Source. Curso: Técnico de Gestão de Equipamentos Informáticos

Projecto SDAC 2010. Sistema Operativo Open Source. Curso: Técnico de Gestão de Equipamentos Informáticos Projecto SDAC 2010 Sistema Operativo Open Source Curso: Técnico de Gestão de Equipamentos Informáticos Disciplina: Sistemas Digitais e Arquitectura de Computadores Professores: Catarina Santos/Paulo Guimarães

Leia mais

Acronis Servidor de Licença. Manual do Utilizador

Acronis Servidor de Licença. Manual do Utilizador Acronis Servidor de Licença Manual do Utilizador ÍNDICE 1. INTRODUÇÃO... 3 1.1 Descrição geral... 3 1.2 Política de licenças... 3 2. SISTEMAS OPERATIVOS SUPORTADOS... 4 3. INSTALAR O SERVIDOR DE LICENÇA

Leia mais

A Gestão de Configurações suporte dos Sistemas de Informação

A Gestão de Configurações suporte dos Sistemas de Informação A Gestão de Configurações suporte dos Sistemas de Informação O funcionamento dos sistemas e tecnologias de informação e comunicação têm nas organizações um papel cada vez mais crítico na medida em que

Leia mais

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10)

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10) Questionário Nível Avaliado Gerador de plano de teste Gerador de dados Função/característica do produto Gestão dos dados do plano de teste (51) Perguntas Pontuação Selenium BadBoy Canoo A ferramenta auilia

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

Acronis Backup & Recovery 10 Server para Linux. Update 5. Guia da Instalação

Acronis Backup & Recovery 10 Server para Linux. Update 5. Guia da Instalação Acronis Backup & Recovery 10 Server para Linux Update 5 Guia da Instalação Índice 1 Antes da instalação...3 1.1 Componentes do Acronis Backup & Recovery 10... 3 1.1.1 Agente para Linux... 3 1.1.2 Consola

Leia mais

DESAFIO ETAPA 1 Passo 1

DESAFIO ETAPA 1 Passo 1 DESAFIO Um dos maiores avanços percebidos pela área de qualidade de software foi comprovar que a qualidade de um produto final (software) é uma consequência do processo pelo qual esse software foi desenvolvido.

Leia mais

Enunciado do Projecto

Enunciado do Projecto C O M P U T A Ç Ã O M Ó V E L 2 0 0 7 / 2 0 0 8 Enunciado do Projecto 17 de Março de 2008 1. Objectivos Desenvolver uma aplicação num domínio aplicacional específico que envolva replicação e sincronizaçã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

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17 Documento técnico HP Quality Center Atualize o desempenho Índice Sobre a atualização do HP Quality Center 2 Introdução 2 Público-alvo 2 Definição 3 Determine a necessidade de uma atualização do HP Quality

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

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Uma visão mais detalhada do software HP LoadRunner

Uma visão mais detalhada do software HP LoadRunner Boletim técnico Uma visão mais detalhada do software HP LoadRunner Índice Um novo enfoque no teste de desempenho: a solução HP LoadRunner 3 A solução HP LoadRunner e a terminologia dos testes de desempenho

Leia mais

Rede de Laboratórios de Produtividade de Software

Rede de Laboratórios de Produtividade de Software Rede de Laboratórios de Produtividade de Software Testes em aplicações WEB Uma Visão Geral Programa de Capacitação em Testes de Software Desktop system WEB system Ambiente de aplicativo da Web Rede de

Leia mais

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com Fundamentos em Teste de Software Vinicius V. Pessoni viniciuspessoni@gmail.com Objetivos do treinamento 1. Expor os fundamentos de Teste de Software; 2. Conceituar os Níveis de Teste; 3. Detalhar sobre

Leia mais

Conversão do POC para o SNC

Conversão do POC para o SNC Manual do Utilizador Conversão do POC para o SNC Data última versão: 18.02.2010 Versão: 128 Data criação: 3.12.2009 Faro R. Dr. José Filipe Alvares, 31 8005-220 FARO Telf. +351 289 899 620 Fax. +351 289

Leia mais

Extracto on Line Aplicação Local Guia do Utilizador

Extracto on Line Aplicação Local Guia do Utilizador Extracto on Line Aplicação Local Guia do Utilizador Índice 1. Sobre o Guia... 4 1.1 Objectivo... 4 1.2 Utilização do Guia... 4 1.3 Acrónimos e Abreviações... 4 2. Introdução ao Extracto on Line Aplicação

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

Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia

Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia Engenharia Informática Redes e Computadores 2006/2007 Levantamento e Inventariação de Rede Privada Rafael Esteves Alves Forno

Leia mais

Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000

Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000 Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000 Serviços HP Dados técnicos O Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000

Leia mais

PERIVER PLATAFORMA SOFTWARE REQUIREMENT SPECIFICATION. Periver_SoftwareRequirementSpecification_2008-03-31_v1.0.doc. Versão 1.0

PERIVER PLATAFORMA SOFTWARE REQUIREMENT SPECIFICATION. Periver_SoftwareRequirementSpecification_2008-03-31_v1.0.doc. Versão 1.0 PLATAFORMA Versão 1.0 31 de Março de 2008 TABELA DE REVISÕES Versão Autores Descrição da Versão Aprovadores Data António Rocha Cristina Rodrigues André Ligeiro V0.1r Dinis Monteiro Versão inicial António

Leia mais

geral@centroatlantico.pt www.centroatlantico.pt Impressão e acabamento: Inova 1ª edição: Outubro de 2003 ISBN: 972-8426-76-3 Depósito legal: 202574/03

geral@centroatlantico.pt www.centroatlantico.pt Impressão e acabamento: Inova 1ª edição: Outubro de 2003 ISBN: 972-8426-76-3 Depósito legal: 202574/03 FICHEIROS COM EXEMPLOS Envie um e-mail* para software@centroatlantico.pt para conhecer os endereços de Internet de onde poderá fazer o download dos ficheiros com os exemplos deste livro. * O leitor consente,

Leia mais

Sistemas de informação (S.I.)

Sistemas de informação (S.I.) Sistemas de informação (S.I.) Índice geral: Contents Índice geral: 1 SISTEMAS DE INFORMAÇÃO Sistemas de Gestão Empresarial 3 TIPOS DE SISTEMAS DE INFORMAÇÃO 5 SEGURANÇA NOS SISTEMAS DE INFORMAÇÃO 6 Noções

Leia mais

Ferramentas como, por exemplo, linhas de conexão, formas automáticas, sombras pendentes, WordArt, etc.

Ferramentas como, por exemplo, linhas de conexão, formas automáticas, sombras pendentes, WordArt, etc. Ambiente de trabalho Ambiente de trabalho Porquê criar páginas web? A World Wide Web é a melhor forma das pessoas comunicarem umas com as outras. Nos dias de hoje, é importante poder comunicar com outras

Leia mais

Bosch Video Management System Assegurando o futuro com IP

Bosch Video Management System Assegurando o futuro com IP Bosch Video Management System Assegurando o futuro com IP Segurança de vídeo IP Tudo interligado O Bosch Video Management System (VMS) gere todo o áudio e vídeo digital e IP, além de todos os dados de

Leia mais

SISTEMAS DE GESTÃO DA QUALIDADE

SISTEMAS DE GESTÃO DA QUALIDADE SISTEMAS DE GESTÃO DA QUALIDADE Objectivos do Curso. No final deste os alunos deverão: Identificar os principais objectivos associados à implementação de Sistemas de Gestão da Qualidade (SGQ) Compreender

Leia mais

Gestão Total da Manutenção: Sistema GTM

Gestão Total da Manutenção: Sistema GTM Gestão Total da Manutenção: Sistema GTM por Engº João Barata (jbarata@ctcv.pt), CTCV Inovação Centro Tecnológico da Cerâmica e do Vidro 1. - INTRODUÇÃO Os sub-sistemas de gestão, qualquer que seja o seu

Leia mais

Lista de Exercício: PARTE 1

Lista de Exercício: PARTE 1 Lista de Exercício: PARTE 1 1. Questão (Cód.:10750) (sem.:2a) de 0,50 O protocolo da camada de aplicação, responsável pelo recebimento de mensagens eletrônicas é: ( ) IP ( ) TCP ( ) POP Cadastrada por:

Leia mais

Informação legal... 4 Frequently Asked Questions (FAQ)... 6 Quickstart Tutorial... 9

Informação legal... 4 Frequently Asked Questions (FAQ)... 6 Quickstart Tutorial... 9 Índice Introdução ao ELMS e ao MSDNAA... 3 Informação legal... 4 Frequently Asked Questions (FAQ)... 6 Quickstart Tutorial... 9 O presente documento destina se a auxiliar todos os alunos que sejam beneficiários

Leia mais

Soluções de Gestão de Clientes e Impressão Universal

Soluções de Gestão de Clientes e Impressão Universal Soluções de Gestão de Clientes e Impressão Universal Manual do utilizador Copyright 2007 Hewlett-Packard Development Company, L.P. Windows é uma marca registada da Microsoft Corporation nos E.U.A. As informações

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Manual do Nero ControlCenter

Manual do Nero ControlCenter Manual do Nero ControlCenter Nero AG Informações sobre direitos de autor e marcas O manual do Nero ControlCenter e todo o seu conteúdo estão protegidos pelos direitos de autor e são propriedade da Nero

Leia mais

Relatório Técnico Final Projecto nº 22838

Relatório Técnico Final Projecto nº 22838 SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) Leadership Business Consulting Relatório Técnico Final Projecto nº 22838 1 ÍNDICE 1. O Projecto 1.1. Os objectivos e a estrutura

Leia mais

604 wifi. Visite www.archos.com/manuals para transferir a versão mais recente deste manual.

604 wifi. Visite www.archos.com/manuals para transferir a versão mais recente deste manual. 604 wifi FUNÇÕES WIFI e Internet Suplemento ao Manual do Utilizador ARCHOS 504/604 Versão 1.2 Visite www.archos.com/manuals para transferir a versão mais recente deste manual. Este manual contém informações

Leia mais

Software da Impressora

Software da Impressora Software da Impressora Acerca do Software da Impressora O software Epson inclui o controlador de impressão e o EPSON Status Monitor 3. O controlador de impressão é um software que permite controlar a impressora

Leia mais

Guia de Rede. Configuração do Windows Utilizar um Servidor de Impressão Monitorizar e Configurar a Impressora Apêndice

Guia de Rede. Configuração do Windows Utilizar um Servidor de Impressão Monitorizar e Configurar a Impressora Apêndice Guia de Rede 1 2 3 4 Configuração do Windows Utilizar um Servidor de Impressão Monitorizar e Configurar a Impressora Apêndice Leia este manual cuidadosamente antes de utilizar o equipamento e mantenha-o

Leia mais

VM Card. Referência das Definições Web das Funções Avançadas. Manuais do Utilizador

VM Card. Referência das Definições Web das Funções Avançadas. Manuais do Utilizador VM Card Manuais do Utilizador Referência das Definições Web das Funções Avançadas 1 Introdução 2 Ecrãs 3 Definição de Arranque 4 Informações de Função Avançada 5 Instalar 6 Desinstalar 7 Ferramentas do

Leia mais

geral@centroatlantico.pt www.centroatlantico.pt Impressão e acabamento: Inova 1ª edição: Novembro de 2004

geral@centroatlantico.pt www.centroatlantico.pt Impressão e acabamento: Inova 1ª edição: Novembro de 2004 FICHEIROS COM EXEMPLOS Envie um e-mail* para software@centroatlantico.pt para conhecer os endereços de Internet de onde poderá fazer o download dos ficheiros com os exemplos deste livro. Reservados todos

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

Centro Atlântico, Lda., 2011 Ap. 413 4764-901 V. N. Famalicão, Portugal Tel. 808 20 22 21. geral@centroatlantico.pt www.centroatlantico.

Centro Atlântico, Lda., 2011 Ap. 413 4764-901 V. N. Famalicão, Portugal Tel. 808 20 22 21. geral@centroatlantico.pt www.centroatlantico. Reservados todos os direitos por Centro Atlântico, Lda. Qualquer reprodução, incluindo fotocópia, só pode ser feita com autorização expressa dos editores da obra. Microsoft Excel 2010 Colecção: Software

Leia mais

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe.

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe. Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto FeaRSe 6 de Maio de 2010 Índice Índice... 1 1 Sumário... 2 2 Requisitos...

Leia mais

TABELA 3.1 Requisitos do Windows Server 2008 Standard

TABELA 3.1 Requisitos do Windows Server 2008 Standard 3 3INSTALAÇÃO DE UM SERVIDOR 2008 Feita a apresentação das funcionalidades do Windows Server 2008, eis que chega a hora mais desejada: a da implementação do nosso servidor. No entanto não é de todo recomendável

Leia mais

Comunicação sem fios (somente em alguns modelos) Manual do utilizador

Comunicação sem fios (somente em alguns modelos) Manual do utilizador Comunicação sem fios (somente em alguns modelos) Manual do utilizador Copyright 2007 Hewlett-Packard Development Company, L.P. Windows é uma marca registada da Microsoft Corporation nos E.U.A. Bluetooth

Leia mais

MANUAL DE CONSULTA RÁPIDA DO MODEM OPTIONS FOR NOKIA 7650. Copyright 2002 Nokia. Todos os direitos reservados 9354493 Issue 2

MANUAL DE CONSULTA RÁPIDA DO MODEM OPTIONS FOR NOKIA 7650. Copyright 2002 Nokia. Todos os direitos reservados 9354493 Issue 2 MANUAL DE CONSULTA RÁPIDA DO MODEM OPTIONS FOR NOKIA 7650 Copyright 2002 Nokia. Todos os direitos reservados 9354493 Issue 2 Índice 1. INTRODUÇÃO...1 2. INSTALAR O MODEM OPTIONS FOR NOKIA 7650...1 3. SELECCIONAR

Leia mais

Tipos de teste de software

Tipos de teste de software Tipos de teste de software Volnys Borges Bernal volnys@lsi.usp.br Adilson Hira ayhira@lsi.usp.br Laboratório de Sistemas Integráveis Departamento de Sistemas Eletrônicos Escola Politécnica da USP Sumário

Leia mais

Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária)

Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária) Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária) /curriculum Julho de 2008 Versão 1.1 1 Introdução O objectivo deste guia é auxiliar o utilizador da Plataforma

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

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

Manual do Utilizador

Manual do Utilizador Faculdade de Ciências e Tecnologia da Universidade de Coimbra Departamento de Engenharia Electrotécnica e Computadores Software de Localização GSM para o modem Siemens MC35i Manual do Utilizador Índice

Leia mais

EKM Visão Geral. Vinicius Strugata João Aguirre Ricardo Damian

EKM Visão Geral. Vinicius Strugata João Aguirre Ricardo Damian EKM Visão Geral Vinicius Strugata João Aguirre Ricardo Damian EKM 2.0 Desafios na Simulação de Engenharia PAGE 2? Cenário 1: Colaboração Cenário 2: Reutilização Vários analistas trabalhando no mesmo Projeto

Leia mais

Manual de Utilização Rápida Vodafone Connect Pen K3772-Z

Manual de Utilização Rápida Vodafone Connect Pen K3772-Z Manual de Utilização Rápida Vodafone Connect Pen K3772-Z Bem-vindo ao mundo da Banda Larga Móvel 1 2 3 4 5 6 8 9 9 10 12 Bem-vindo Configuração da Connect Pen Iniciar a aplicação Ligar Janela Normal Definições

Leia mais

ZS Rest. Manual Avançado. Instalação em Rede. v2011

ZS Rest. Manual Avançado. Instalação em Rede. v2011 Manual Avançado Instalação em Rede v2011 1 1. Índice 2. Introdução... 2 3. Hardware... 3 b) Servidor:... 3 c) Rede:... 3 d) Pontos de Venda... 4 4. SQL Server... 5 e) Configurar porta estática:... 5 5.

Leia mais

Guia de utilização. Acesso Universal

Guia de utilização. Acesso Universal Guia de utilização Março de 2009 Índice Preâmbulo... 3 Acesso à Plataforma... 4 Área de Trabalho... 5 Apresentar Propostas... 12 Classificar Documentos... 20 Submeter a Proposta... 21 Solicitação de Esclarecimentos/Comunicações...

Leia mais

Negócios à Sua dimensão

Negócios à Sua dimensão Negócios à Sua dimensão O seu Software de Gestão acompanha-o? O ArtSOFT pode ser a solução de gestão da sua empresa. O ArtSOFT Profissional permite o controlo total sobre a gestão da sua empresa, assegura

Leia mais

GUIA DE INSTALAÇÃO DE SOFTWARE

GUIA DE INSTALAÇÃO DE SOFTWARE GUIA DE INSTALAÇÃO DE SOFTWARE SISTEMA MULTIFUNÇÕES DIGITAL Página INTRODUÇÃO ANTES DA INSTALAÇÃO INSTALAR O DRIVER DA IMPRESSORA LIGAÇÃO A UM COMPUTADOR 9 CONFIGURAR O CONTROLADOR DA IMPRESSORA 0 COMO

Leia mais

ZS Rest. Manual Avançado. Gestão de Stocks Local. v2011

ZS Rest. Manual Avançado. Gestão de Stocks Local. v2011 Manual Avançado Gestão de Stocks Local v2011 1 1. Índice 2. Introdução... 3 3. Iniciar o ZSRest FrontOffice... 4 4. Produto... 5 b) Activar gestão de stocks... 5 i. Opção: Faz gestão de stocks... 5 ii.

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

[Documentação de Utilização Correio Electrónico dos Estudantes da ESTG]

[Documentação de Utilização Correio Electrónico dos Estudantes da ESTG] [Documentação de Utilização Correio Electrónico dos Estudantes da ESTG] Unidade De Administração de Sistemas Serviços Informáticos Instituto Politécnico de Leiria 10-07-2009 Controlo do Documento Autor

Leia mais

Porque as suas regras de negócio são específicas, precisa de uma sua solução de gestão que permite gerir essa diferença.

Porque as suas regras de negócio são específicas, precisa de uma sua solução de gestão que permite gerir essa diferença. Porquê NEXT Vision Porque as suas regras de negócio são específicas, precisa de uma sua solução de gestão que permite gerir essa diferença.... Poder de adaptação Porque cabe a si decidir como pretende

Leia mais

MANUAL DE CONSULTA RÁPIDA DO NOKIA MODEM OPTIONS. Copyright 2003 Nokia. Todos os direitos reservados 9356515 Issue 1

MANUAL DE CONSULTA RÁPIDA DO NOKIA MODEM OPTIONS. Copyright 2003 Nokia. Todos os direitos reservados 9356515 Issue 1 MANUAL DE CONSULTA RÁPIDA DO NOKIA MODEM OPTIONS Copyright 2003 Nokia. Todos os direitos reservados 9356515 Issue 1 Índice 1. INTRODUÇÃO...1 2. INSTALAR O NOKIA MODEM OPTIONS...1 3. LIGAR O NOKIA 6600

Leia mais

Sistema de Certificação de Competências TIC

Sistema de Certificação de Competências TIC Sistema de Certificação de Competências TIC Portal das Escolas Manual de Utilizador INDICE 1 Introdução... 5 1.1 Sistema de formação e certificação de competências TIC...6 1.1.1 Processo de certificação

Leia mais

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc. Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web

Leia mais

Optimização de processos e ferramentas de Controlo e Gestão em Sistemas de Protecção, Comando e Controlo

Optimização de processos e ferramentas de Controlo e Gestão em Sistemas de Protecção, Comando e Controlo Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Optimização de processos e ferramentas de Controlo e Gestão em Sistemas de Protecção, Comando e Controlo PDI Preparação para Dissertação

Leia mais

Introdução à Internet

Introdução à Internet Introdução à Internet Paulo Santos v. 2.0-2012 1 Índice 1 Introdução à Internet... 3 1.1 Conceitos base... 3 1.1.1 O que é a internet?... 3 1.1.2 O que é preciso para aceder à internet?... 3 1.1.3 Que

Leia mais