Embed Size (px)
Citation preview
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
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
i
Dedico este trabalho aos
meus pais, cuja fé em mim
me ensinou a ter fé em mim
mesmo.
iii
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.
v
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.
vii
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.
ix
Índice
Agradecimentos iii
Resumo v
Abstract vii
Índice ix
Lista de Figuras xiii
Lista de Tabelas xv
!omenclatura xvii
1 Introdução 1
1.1 Objectivos 2
1.2 Estrutura do Relatório 3
2 Enquadramento Empresarial 4
2.1 Equipa de QMS 4
2.2 Enquadramento Pessoal na Equipa 5
3 Ferramentas existentes no Mercado 7
3.1 Enquadramento Histórico 7
3.2 Selenium IDE 7
3.3 iMacros 9
3.4 Watir 9
3.5 TestMaker 10
3.6 Winrunner 11
3.7 Quick Test Pro 11
3.8 LoadRunner 12
3.9 Conclusão 13
4 Testes de Software 14
4.1 Introdução 14
4.2 Objectivo dos Testes de Software 15
x
4.3 Terminologia 16
4.4 Porquê realizar testes de Software? 16
4.5 Enquadramento da Fase de Teste 17
4.6 Fases de Teste 21
4.7 Plano de Teste 22
4.8 Caso de Teste 23
4.9 Tipos de Teste 24
4.10 Tipos de Testes / Nível do processo de Teste 29
4.11 Técnicas de Testes de Software 29
4.11.1 Teste White-Box (Caixa-Branca) 30
4.11.2 Teste Black-Box (Caixa-Preta) 31
4.12 Custos da Qualidade em Testes de Software 31
4.13 Uma nova abordagem: Automatização 33
4.14 Porquê Automatizar? 34
4.15 Âmbito da Automatização na Optimus 34
5 Automatismos 36
5.1 Introdução 36
5.2 Arquitectura dos Testes de Regressão 38
5.3 Ferramenta de Automatização Quick Test Pro 39
5.4 Principais Funcionalidades da Ferramenta QuickTest Professional 41
5.5 Técnicas para implementação de scripts de testes automáticos 43
5.6 Fases de Construção de um Script 46
5.7 Estrutura de um Servidor de Testes de Regressão 48
5.8 Ferramenta Quality Center 51
5.9 Arquitectura de funcionamento Quality Center-QTP 54
5.10 Produtos Automatizados 55
5.11 Arquitectura dos Testes de Carga 55
5.12 Fases de Construção de um Script 56
5.13 Ferramenta LoadRunner 57
6 DashBoard 62
6.1 Introdução 62
6.2 Estrutura do Servidor 62
xi
6.3 Funcionalidades da Ferramenta Splunk 63
6.4 DashBoard QMSAnalyser 66
6.5 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 0ewsLetter da Equipa de QMS 86
Exemplo de Email de Execução de Testes de Carga 87
xii
xiii
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 4.10. 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 5.10. Estrutura de um script de Teste de Regressão implementado na equipa QMS.
Figura 5.11. Estrutura da pasta sourcecode um servidor de Teste de Regressão.
Figura 5.12. Estrutura de um servidor de Teste de Regressão.
xiv
Figura 5.13. Ferramenta Quality Center (Página Login).
Figura 5.14. Ferramenta Quality Center (Página Test Plan).
Figura 5.15. Ferramenta Quality Center (Página Test Lab).
Figura 5.16. Ferramenta Quality Center (Página Test Instance Properties).
Figura 5.17. Sincronização da ferramenta Quality Center com servidor de Testes de Regressão.
Figura 5.18. Scripts Automatizados.
Figura 5.19 Arquitectura dos Scripts de Carga.
Figura 5.20. Estrutura de um script de Teste de Carga implementado na equipa QMS.
Figura 5.21. Ferramenta LoadRunner.
Figura 5.22. Janela de definição dos Dados de Teste.
Figura 5.23. Estrutura de um script de Teste de Carga.
Figura 5.24. LoadRunner Controller (Definição de Cenário).
Figura 5.25. LoadRunner Controller (Análise da evolução do Cenário).
Figura 5.26. 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 6.10. DashBoard QMSAnaliser – Problema 3.
xv
Lista de Tabelas
Tabela 3.1. Ferramentas de Automatização.
Tabela 4.1. Características da Norma ISO/IEC 9126.
Tabela 4.2. Fase/Tipo de Testes.
xvii
!omenclatura
Abreviaturas
ISSO Internacional Standard Organization
IEEE Institute of Electrical and Electronics Engineers
HP Hewlett-Packard
ISTQB International Software Testing Qualifications Board
QMS Quality Management Systems
QMS-CM Quality Management Systems - Configuration Management
QMS-CA Quality Management Systems - Quality Assurance
QMS-IQM Quality Management Systems - Integrated Quality Management
QMS-TST Quality Management Systems - Test
Logs 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 Programa de software escrito em linguagem de script
Patches Ficheiro de actualização ou melhoria de um determinado software
Web Word wide Web
TI Tecnologia da Informação
SI Sistemas da Informação
Browser Expressão utilizada para descrever 0avegador de Internet
Site Expressão utilizada para descrever Portal
SOA Service-Oriented Architecture
DHCP Dynamic Host Control Protocol
D0S Domain 0ame System
FTP File Transfer Protocol
TFTP Trivial File Transfer Protocol
http Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IP Internet Protocol
TCP Transmission Control Protocol
xviii
SMTP Simple Mail Transfer Protocol
POP Post Office Protocol
IMAP Internet Message Access Protocol
HSDPA High-Speed Downlink Packet Access
Downlink Capacidade/velocidade de transferência de dados utilizando o protocolo
HSDPA
Plugin/ Add-in / Add-on
Programa de software usado para adicionar funções a outros programas,
fornecendo alguma funcionalidade especial ou muito específica
XML eXtensible Markup Language
HTML HyperText Markup Language
PHP Hypertext Preprocessor
SGPS Sociedade Gestora de Participações Sociais
GSM Global System for Mobile Communications
GPRS General Packet Radio Service
UMTS Universal Mobile Telecommunication System
1
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
2
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.
3
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.
4
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 1998. 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:
5
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 2010.
6
7
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, é
8
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.
9
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 multi-
plataforma, 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
10
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.
11
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.
12
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.
13
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.
14
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
15
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 9126. 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 9126.
Característica Sub-característica Pergunta chave para a sub-característica
Funcionalidade
(satisfaz as
necessidades?)
Adequação Propõe-se a fazer o que é apropriado? Acurácia Faz o que foi proposto de forma correcta? Interoperbilidade Interage com os sistemas especificados? Conformidade Está de acordo com as normas, leis, etc.? Segurança de acesso Evita acesso não autorizado aos dados?
Confiabilidade
(é imune a falhas?)
Maturidade Com que frequência apresenta falhas? Tolerância a falhas Ocorrendo falhas, como reage? Recuperabilidade É capaz de recuperar dados em caso de falha?
Usabilidade
(é fácil de usar?)
Intelegibilidade É fácil entender o conceito e a aplicação? Apreensibilidade É fácil de aprender a 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?
Manuseabilidade
(é fácil de
modificar?)
Analisabilidade É fácil de encontrar uma falha, quando ocorre? Modificabilidade É fácil modificar e adaptar? Estabilidade Há grande risco quando se faz alterações? 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?
16
(é fácil de usar
noutro ambiente?)
Conformidade Está de acordo com padrões de portabilidade? Capac. para substituir É 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.º 610.12-1990 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
17
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
18
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
19
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 4.2.
20
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.
21
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
22
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.
23
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:
24
- 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)
25
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;
26
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 baseia-
se no ponto de vista funcional e pode envolver actividades que cruzam as fronteiras de diversas
27
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)
28
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
29
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.
4.10 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
30
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].
4.11.1 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.
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 baseia-
se 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].
Dados de Entrada Dados de Saída
31
4.11.2 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.
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.
4.12 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]:
Dados de Entrada Dados de Saída
32
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
33
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 4.10. Custos da correcção de erro (adaptado de [Miguel, 2004]).
4.13 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
34
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].
4.14 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].
4.15 Â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 é
35
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.
36
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:
37
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
4.11.2);
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
38
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
39
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.
40
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.
41
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).
42
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.
43
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;
44
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
45
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.
46
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.
47
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
48
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 5.10. 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:
49
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, COMMO0,
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;
50
Figura 5.11. 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
0otepad;
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.
51
Figura 5.12. 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.
52
Figura 5.13. 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 5.14. Ferramenta Quality Center (Página Test Plan).
53
Para a execução dos Testes de Regressão automatizados é utilizada a opção Test Lab, como
ilustra a Figura 5.15. 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 5.15. 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 5.16. Ferramenta Quality Center (Página Test Instance Properties).
54
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 5.17. 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
55
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.
5.10 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 5.18. O número de
scripts realizados num determinado período de tempo é apresentado através da 0ewLetter de QMS.
No Anexo III, na Secção "Exemplo de 0ewsLetter da Equipa de QMS" apresenta-se o exemplo da
0ewsLetter 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 5.18. Scripts Automatizados.
5.11 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
56
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.
5.12 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.
57
Figura 5.20. Estrutura de um script de Teste de Carga implementado na equipa QMS.
5.13 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.
58
Figura 5.21. 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 5.22. Janela de definição dos Dados de Teste.
59
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.
Figura 5.23. 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.
Logs de Debug
60
Figura 5.24. 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 5.25. 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
61
Figura 5.26. Este relatório permite efectuar uma análise detalhada da resposta do servidor a
múltiplas solicitações ao longo do tempo.
Figura 5.26. 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 Email de Execução de Testes de Carga" apresenta-se
o email que é enviado com as conclusões fundamentadas do relatório gerado pela ferramenta
LoadRunner.
62
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
63
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.
64
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 6.4.
65
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.
66
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.
67
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.
68
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.
Figura 6.10. 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.
A
B
69
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.
70
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.
71
Referências
[Almeida, 2010 ] "Teste de Software Limitações e Benefícios". Disponível em http://www.spinsp.org.br/apresentacao/57teste_de_software.pdf, 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 http://anielacole.wordpress.com/tag/scripts/, 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 9126”. Disponível em http://tconline.feevale.br/tc/files/0002_1582.pdf , 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 http://vqv.com.br/es/esm03_GestaoDeTestes.pdf, visitado a última vez 22 de Março [Celapar, 2009] "Evolução de Software". Disponível em http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=299, 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 http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida, 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” , 2004. [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 http://www.cpqd.com.br/file.upload/08_artigoforum_automacao-testes-boss.pdf, visitado a última vez em 5 de Novembro de 2010 [Ferramentas, 2010] “Qualidade Software”. Disponível em http://blog.prasabermais.com/2010/02/15/histrico-da-evoluo-das-ferramentas-para-testes-e-qualidade-de-software/, visitado a última vez 15 de Fevereiro de 2010 [Fewster at al , 1999] M.Fewster e D.Grahm, “Software Test Automation”, Addison-Wesley, 1999. [Horch, 1996] Horch, J., “Practical Guide to Software Quality Management”, Artech House Publishers, London, 1996
72
[IEEE, 1990] IEEE. Ieee standard glossary of software engineering terminology. Standard 610.12, 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 http://www.macoratti.net/08/08/tst_sw2.htm, visitado a última vez 22 de Março de 2010 [Mariana, 2010] "TESTES DE SOFTWARE NO WEBPOSGRAD NTI/UFPB". Disponível em http://www.di.ufpb.br/~alan/disciplinas/estagio/relatorios/Mariana.pdf, visitado a última vez 22 de Março de 2010 [Martha, 2008] Maria Martha, "A importância dos testes automatizados".Disponível em http://marthahuback.wordpress.com/2008/12/10/a-importancia-dos-testes-automatizados/, visitado a última vez 19 de Novembro de 2010 [Manutenibilidade, 2010] “Manutenibilidade”. Disponível em http://pt.wikipedia.org/wiki/Manutenibilidade, 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 www.optimus.pt, 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 http://www.fp2.com.br/fernando/engenharia/Aula02-CicloDeVida_6s.pdf, 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 http://www.pushtotest.com/help-and-reference/introduction-to-pushtotest-testmaker -methodology, visitado a última vez em 2010 [Qualidade, 2010] “Qualidade de Software”. Disponível em http://pt.wikipedia.org/wiki/Qualidade_de_software, 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, 2001
73
[Ron, 2005] Ron Patton, “Software Testing”, Sams Publishing, 2005 [Ruby, 2010] “Linguagem-Ruby”. Disponível em http://www.devmedia.com.br/post-8226-Conhecendo-a-Linguagem-Ruby.html, visitado a última vez em 2010 [Sommerville, 2000] Sommerville. “Software Engineering”, Addison-Wesley, 2000 [Sonaecom, 2010] “ÁREAS DE 0EGÓCIO”. Disponível em www.sonaecom.pt, visitado a última vez em 2010 [Teste, 2010] “Teste de Software”, http://pt.wikipedia.org/wiki/Teste_de_software, visitado a última vez em 12 de dezembro de 2010 [Testexpert, 2009] “Testes de Software”, Disponível em http://www.testexpert.com.br/?q=node/171 , visitado a última vez em 2009 [Tozelli, 2008] Paulo Tozelli, "Processo de Teste de Software". Disponível em http://www.artigonal.com/programacao-artigos/processo-de-teste-de-software-505672.html , visitado a última vez 19 de Fevereiro de 2010 [Travassos at al, 2007] "Teste de Software". Disponível em http://lens.cos.ufrj.br:8080/portalESE/cos722/testes, visitado a última vez 22 de Março [Vinicius, 2008] Vinicius Sabadoti, "Histórico sobre Testes de Software". Disponível em http://viniciussabadoti.wordpress.com/2010/08/03/historico-sobre-testes-de-software/, 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 http://www.wintrust.pt/portal/page/portal/WINTRUST/PUBLICACOES/DOCUMENTOS_TECNICOS/2006_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 http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf , visitado a última vez 19 de Novembro de 2010
74
75
Anexo I – Exemplo de Caso de Teste
Exemplo Caso de Teste – Site CPM
Especificação de Teste Automático
Script!ame CPM_ADD_REMOVE_OCCS_QTP Descrição do script Adição de OCCs a um contracto no CPM Produtos envolvidos CPM 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 http://webdav.optimus.pt/public/COMMON_TST/WS_R1_0/TestAutomation/TAF/CPM/CPM_ADD_REMOVE_OCCS_QTP/Add_OCCs.htm http://webdav.optimus.pt/public/COMMON_TST/WS_R1_0/TestAutomation/TAF/CPM/CPM_ADD_REMOVE_OCCS_QTP/Remove_OCCs.htm Variáveis a utilizar pelo script Link: http://lx3qmsrhcpm02/ User: QMS8 Pass:
76
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;
77
return 0; Exception
When NO_DATA_FOUND Then return aa+1; When Others Then return aa+2; end;
78
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
79
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 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
80
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''' 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]"
81
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”)
82
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")
83
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]"
84
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
85
'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
writeTD 1,"Erro: Tarifário Incorrecto ", " Tarifario "&environment.Value("check_Tarifario_Kanguru") Environment.Value("rc")=False checkAction "Tarifário Incorrecto"
end if
86
Anexo III – Exemplos de Relatórios
Exemplo de 0ewsLetter da Equipa de QMS
87
Exemplo de Email de Execução de Testes de Carga
![2008-02-15 MCC Analise de um ambiente de · rios estudos realizados pela American Productivity Quality Center (APQC) pode-se ob-servar essa tendência [Lemons, 2002], [Lemons, 2005],](https://img.document.onl/doc/110x75/6070d0283f7f4448f17f4d74/2008-02-15-mcc-analise-de-um-ambiente-de-rios-estudos-realizados-pela-american-productivity.jpg)
