Automação de Testes
1
Automação de Testes
Automação de Testes
2
Todos os direitos reservados para Alfamídia LTDA.
AVISO DE RESPONSABILIDADE
As informações contidas neste material de treinamento são distribuídas “NO ESTADO
EM QUE SE ENCONTRAM”, sem qualquer garantia, expressa ou implícita. Embora
todas as precauções tenham sido tomadas na preparação deste material, a Alfamídia
LTDA. não tem qualquer responsabilidade sobre qualquer pessoa ou entidade com
respeito à responsabilidade, perda ou danos causados, ou alegadamente causados, direta
ou indiretamente, pelas instruções contidas neste material ou pelo software de
computador e produtos de hardware aqui descritos.
11/ 2012 - Versão 1.0
Alfamídia LTDA
www.alfamidia.com.br
Automação de Testes
3
UNIDADE 1 OBJETIVOS E GANHOS COM A APLICAÇÃO DE AUTOMAÇÃO NOS TESTES .......................... 6
1.1 O CICLO DE VIDA DOS TESTES AUTOMATIZADOS ............................................................................. 6 1.1.1 Objetivos dos testes automatizados ........................................................................................................ 6
1.2 BENEFÍCIOS DA AUTOMAÇÃO DOS TESTES ....................................................................................... 6 1.2.1 ROI e custos ............................................................................................................................................ 7
UNIDADE 2 TIPOS DE AUTOMAÇÃO ................................................................................................................... 9
2.1 CAIXA BRANCA ............................................................................................................................. 10 2.1.1 Unitários ............................................................................................................................................... 10
2.2 CAIXA PRETA ................................................................................................................................ 10 2.2.1 Funcional .............................................................................................................................................. 10 2.2.2 Performance ......................................................................................................................................... 10
2.3 GESTÃO ........................................................................................................................................ 10 2.3.1 Gestão de defeitos ................................................................................................................................. 10 2.3.2 Gestão de testes .................................................................................................................................... 11 2.3.3 Massa de dados .................................................................................................................................... 11
UNIDADE 3 FERRAMENTAS MAIS UTILIZADAS NO MERCADO DE AUTOMAÇÃO ...................................... 12
3.1 FERRAMENTAS PAGAS .................................................................................................................. 12 3.1.1 IBM ....................................................................................................................................................... 12 3.1.2 HP ......................................................................................................................................................... 13 3.1.3 Automated QA ...................................................................................................................................... 13
3.2 FERRAMENTAS FREE ..................................................................................................................... 13
UNIDADE 4 CONHECENDO O AMBIENTE E INSTALANDO FERRAMENTAS ................................................. 15
4.1 AMBIENTE DE TESTES ................................................................................................................... 15 4.1.1 Infraestrutura necessária ..................................................................................................................... 15 4.1.2 Massa de dados .................................................................................................................................... 16
4.2 CONFIGURANDO E INSTALANDO AS FERRAMENTAS ....................................................................... 17 4.2.1 E então vamos configurar e instalar o WampServer? .......................................................................... 17 4.2.2 Colocando as aplicações para funcionar ............................................................................................. 18 4.2.3 Executando as aplicações ..................................................................................................................... 25
UNIDADE 5 GERENCIAMENTO DE CASOS DE TESTE E EXECUÇÃO COM TESTLINK ................................ 26
5.1 GESTÃO DE TESTES COM TESTLINK .............................................................................................. 26 5.1.1 Objetivos ............................................................................................................................................... 26 5.1.2 Instalando a ferramenta ....................................................................................................................... 27 5.1.3 Estrutura geral ..................................................................................................................................... 29 5.1.4 Definições Básicas ................................................................................................................................ 29 5.1.5 Exemplo simples de fluxo de trabalho no TestLink; ............................................................................. 30 5.1.6 Algumas configurações antes de iniciar ............................................................................................... 32
5.2 PROJETO DE TESTE ........................................................................................................................ 32 5.2.1 Editando um projeto ............................................................................................................................. 34
5.3 INVENTÁRIO .................................................................................................................................. 35 5.4 ESPECIFICAÇÕES DE TESTE ........................................................................................................... 35 5.5 ADICIONANDO REQUISITOS ........................................................................................................... 36
5.5.1 Editando Especificação de Requisitos .................................................................................................. 37 5.5.2 Adicionando Casos de Teste ................................................................................................................. 39 5.5.3 Associando Casos de Teste aos Requisitos ........................................................................................... 44 5.5.4 Associando Palavras Chaves aos Casos de Testes ............................................................................... 45 5.5.5 Criação e exclusão de Planos de Teste ................................................................................................ 46 5.5.6 Criando Baselines / Releases ................................................................................................................ 46 5.5.7 Adicionando casos de teste ao Plano de Teste ..................................................................................... 47 5.5.8 Atribuição de execução de teste ........................................................................................................... 49
5.6 PLATAFORMAS .............................................................................................................................. 49 5.7 PRIORIZANDO TESTES ................................................................................................................... 50 5.8 MARCOS ....................................................................................................................................... 51
Automação de Testes
4
5.8.1 Executando os Casos de Teste .............................................................................................................. 51 FILTRAGEM DE CASOS DE TESTE ............................................................................................................ 52 ÁRVORE ................................................................................................................................................. 52 STATUS DO TESTE ................................................................................................................................... 53 INSERINDO RESULTADOS DO TESTE ........................................................................................................ 53
5.8.2 Relatórios de teste e métricas ............................................................................................................... 53 5.8.3 Métricas gerais de Planos de Testes..................................................................................................... 53 5.8.4 Resultados por palavra-chave .............................................................................................................. 54 5.8.5 Resultados por Dono ............................................................................................................................ 54 5.8.6 Visão geral do status da Baseline ......................................................................................................... 54 5.8.7 Métricas da Query ................................................................................................................................ 54 5.8.8 Relatórios de casos de testes bloqueados, com falha e não executados ............................................... 56 5.8.9 Relatório de Testes ............................................................................................................................... 56 5.8.10 Gráficos ................................................................................................................................................ 56 5.8.11 Total de Bugs para cada caso de teste ................................................................................................. 57 5.8.12 Como adicionar um novo relatório ...................................................................................................... 57 5.8.13 Administração de usuários ................................................................................................................... 57 5.8.14 Campos personalizados ........................................................................................................................ 59 5.8.15 Importação de dados ............................................................................................................................ 60 5.8.16 Importação e exportação de projetos de testes ..................................................................................... 61 5.8.17 Importação e exportação de testes de Suites ........................................................................................ 62 5.8.18 Just one Caso de Teste .......................................................................................................................... 64 5.8.19 Todos os casos de testes no Suite ......................................................................................................... 64 5.8.20 Importação/Exportação de requisitos de software ............................................................................... 65 5.8.21 Importando casos de testes para o Excel via XML ............................................................................... 65 5.8.22 Importando arquivo XML no TestLink ................................................................................................. 67
UNIDADE 6 GERENCIANDO DEFEITOS COM MANTIS BUG TRACKER ......................................................... 68
6.1 GESTÃO DE DEFEITOS COM MANTIS BUG TRACKER ...................................................................... 68 6.1.1 Objetivos ............................................................................................................................................... 68 6.1.2 Instalação da ferramenta ...................................................................................................................... 68 6.1.3 Login no Mantis .................................................................................................................................... 69 6.1.4 Página inicial ....................................................................................................................................... 70 6.1.5 Criando um novo projeto ...................................................................................................................... 70 6.1.6 Criando e modificando um bug ............................................................................................................ 72 6.1.7 Meus Bugs ............................................................................................................................................ 75 6.1.8 Sumário dos Bugs ................................................................................................................................. 76 6.1.9 News ..................................................................................................................................................... 77 6.1.10 Change Log .......................................................................................................................................... 78 6.1.11 Documentação do projeto..................................................................................................................... 79 6.1.12 Configuração do Mantis ....................................................................................................................... 80
UNIDADE 7 TESTE DE PERFORMANCE, CARGA E STRESS COM JMETER ................................................. 81
7.1 O QUE É O JMETER? ...................................................................................................................... 81 7.2 INSTALANDO O JMETER ................................................................................................................ 83 7.3 COMPONENTES DO JMETER .......................................................................................................... 84
7.3.1 Elementos Básicos ................................................................................................................................ 84 7.3.2 Sampler ................................................................................................................................................. 87
HTTP REQUEST ..................................................................................................................................... 87 7.3.3 Logic Controllers .................................................................................................................................. 88
SIMPLE CONTROLLER ............................................................................................................................. 88 LOOP CONTROLLER ................................................................................................................................ 89 ONCE ONLY CONTROLLER ..................................................................................................................... 90 INTERLEAVE CONTROLLER ..................................................................................................................... 90 IF CONTROLLER ...................................................................................................................................... 91
7.3.4 Listeners ............................................................................................................................................... 91 VIEW RESULTS TREE .............................................................................................................................. 91 ASSERTION RESULTS .............................................................................................................................. 92
Automação de Testes
5
GRAPH RESULTS ..................................................................................................................................... 93 7.3.5 Configurations Elements ...................................................................................................................... 93
HTTP COOKIE MANAGER ...................................................................................................................... 94 HTTP REQUEST DEFAULTS .................................................................................................................... 94
7.3.6 Assertions ............................................................................................................................................. 95 RESPONSE ASSERTION ............................................................................................................................ 95 DURATION ASSERTION ........................................................................................................................... 96
7.3.7 Timers ................................................................................................................................................... 96 7.3.8 Pre-Processors ..................................................................................................................................... 97 7.3.9 Post-Processors .................................................................................................................................... 98
7.4 CRIANDO TESTES DE DESEMPENHO E ESTRESSE AUTOMATIZADOS ................................................ 98
UNIDADE 8 TESTE FUNCIONAL COM BADBOY ............................................................................................. 104
8.1 COMO INSTALAR O BADBOY? ..................................................................................................... 104 8.2 CONHECENDO O BADBOY ........................................................................................................... 110
8.2.1 Gravando ............................................................................................................................................ 110 8.2.2 Criando testes ..................................................................................................................................... 111 8.2.3 Árvore do script .................................................................................................................................. 111
8.3 VAMOS GRAVAR NOSSO PRIMEIRO SCRIPT? ................................................................................. 113 8.4 AUTOMATIZANDO O SCRIPT ........................................................................................................ 118
8.4.1 Request Mode ..................................................................................................................................... 118 8.4.2 Navigation Mode ................................................................................................................................ 118 8.4.3 Navigations ......................................................................................................................................... 119 8.4.4 Gravando navegações ........................................................................................................................ 119 8.4.5 Tipos de itens de navegação ............................................................................................................... 120 8.4.6 Referências de navegação .................................................................................................................. 120 8.4.7 Propriedades de navegação ............................................................................................................... 121 8.4.8 Variáveis ............................................................................................................................................. 122 8.4.9 Adicionando Variáveis ....................................................................................................................... 123 8.4.10 Variáveis de visualização ................................................................................................................... 123 8.4.11 Editar Variáveis .................................................................................................................................. 124 8.4.12 Usando variáveis ................................................................................................................................ 124 8.4.13 Variável lista de valor ........................................................................................................................ 124 8.4.14 Variáveis de Incremento ..................................................................................................................... 124 8.4.15 Assertions/Asserções .......................................................................................................................... 125 8.4.16 Forma como as Asserções funcionam ................................................................................................ 125 8.4.17 Adicionando Asserções ....................................................................................................................... 125 8.4.18 Checks ................................................................................................................................................ 126
8.5 SALVANDO E ENTENDENDO O RESULTADO DO SCRIPT ................................................................. 126 8.5.1 Summary View .................................................................................................................................... 127
8.6 FERRAMENTAS ............................................................................................................................ 127 USANDO DATA SOURCES ..................................................................................................................... 127 ADICIONANDO DATA SOURCE .............................................................................................................. 129 8.7 BADBOY EM LINHA DE COMANDO ............................................................................................... 131 8.8 USANDO BADBOY COM AJAX .................................................................................................... 132
8.8.1 Entendendo as requisições Ajax ......................................................................................................... 132 8.8.2 Gravação de páginas AJAX no Request Mode ................................................................................... 132 8.8.3 Gravando páginas AJAX no Navigation Mode ................................................................................... 133 8.8.4 A reprodução de páginas AJAX no Navigation Mode ........................................................................ 133
8.9 USANDO O BADBOY COM JMETER .............................................................................................. 134 8.9.1 Limitações........................................................................................................................................... 134
Automação de Testes
6
Unidade 1
Objetivos e ganhos com a aplicação de
automação nos testes
1.1 O ciclo de vida dos testes automatizados
1.1.1 Objetivos dos testes automatizados
Com as mudanças que vem ocorrendo no mundo do desenvolvimento e novas práticas,
os prazos estão ficando cada vez mais curtos. O software sendo novo gera muitos
Planos de testes, Casos de testes e principalmente Bugs, e com isso precisa-se de um
controle que muitas vezes o “Excel” já não nos atende.
Aí entram algumas ferramentas que se bem utilizadas podem facilitar este controle e
manuseio de tudo que é gerado no ciclo de testes.
As ferramentas nas quais devem facilitar nossas vidas são: ferramenta de BugTracker,
ferramentas para gerenciar os planos e casos de testes, ferramentas para gerar métricas e
ferramentas para automatizar testes manuais.
Além do pouco tempo que cada vez mais encurta para a execução dos testes, temos um
agravante principalmente em softwares que já estão em produção e sofrem mudanças ao
longo de sua vida.
Certas vezes, uma alteração é feita e por menor que ela seja são feitos testes de
regressão conforme a necessidade. Uma atividade que foi criada em 5 horas pode se
tornar em testes para 5 dias. Nestes casos a automação de tudo que foi feito até o
momento pode ajudar e muito e principalmente automatizar os testes funcionais podem
ser uma sacada de mestre.
Se tudo for utilizado da melhor forma podemos ficar tranquilos em relação à qualidade
dos produtos a serem entregues, à redução de custo e tempo.
1.2 Benefícios da automação dos testes
Existem muitos benefícios ao automatizarmos os testes, abaixo seguem os principais:
Redução de custos
Como os testes manuais são feitos por pessoas e estas possuem custos, logo ao se
reduzir o tempo de testes que estas pessoas executarão, estaremos reduzindo os custos
em relação a elas nestas tarefas.
Automação de Testes
7
Redução de tempo nos testes e nos resultados
As ferramentas de automação são muito mais rápidas na execução, há cenários que de
vários minutos podem ser executados automaticamente em segundos. Claro que
dependendo da forma que são feitos, dependem do “start” de uma pessoa, mas depois
apenas analisam os resultados que já foram exibidos pelas ferramentas.
Redução de erros humanos na execução de testes manuais
Como a execução é feita automaticamente, isso evita elimina os riscos que as pessoas
podem conforme os vícios, fazer. Seja no esquecimento de algum cenário, seja na forma
errada de executá-los. Isso não impede que um teste automatizado mal planejado possa
apresentar erros de cenários visto que quem cria é uma pessoa.
Maior cobertura nos testes e software mais seguro e confiável
Apesar de a criação de um script de testes ser mais demorado para escrever do que um
cenário, ganhamos em tempo de execução. Quanto mais scripts forem criados, mais
cobertura teremos aos testes. Consequentemente o software a ser entregue é mais
confiável.
Execução de testes em qualquer horário e ininterruptos
Ao contrário do profissional, o teste automatizado pode ser executado a qualquer
momento, inclusive nas madrugadas e finais de semana se estiverem programados para
isso. Enquanto os casos forem de sucesso o teste pode ser ininterrupto até que haja
algum erro. Ficando assim o software sempre sendo testado.
Execução dos testes em diversas plataformas
Com o avanço as ferramentas de teste estão cada vez mais suportando diferentes
ambientes (Sistemas Operacionais e Browsers) o que facilita na replicação destes testes
e garantindo maior abrangência nas possibilidades.
1.2.1 ROI e custos
Automação de testes é vista geralmente como uma maneira de reduzir os custos dos
testes, aumentar a cobertura e a efetividade e diminuir as fases de testes. De certa forma
isso está correto e é de extrema importância para se identificar uma empresa cujo
controle de qualidade queira se tornar maduro. Entretanto deve-se lembrar, que o custo
disso inicialmente não será tão reduzido e de que isso não elimina os testes manuais, os
quais são cruciais para testar aplicações de software principalmente em fase de
iniciação.
Automação de testes envolve maiores custos iniciais e deve ser levado em consideração
como um investimento a longo prazo. Realizar um ROI para sua automação planejada
Automação de Testes
8
pode entretanto lhe ajudar a entender bem logo no início o retorno atual que você irá
obter dos seus investimentos e assim você poderá pesar aquele contra os benefícios que
você irá ganhar com a automação.
O ROI nos auxilia a quantificar os custos do projeto de testes e é indicado que seja feito
desde seu início, tanto com o tempo gasto no aprendizado das ferramentas quanto na
execução dos testes já automatizados. Necessitamos avaliar todas as informações e
comparar com os testes manuais para se chegar num resultado onde se possa justificar
custos posteriores.
O ROI pode ser calculado da seguinte forma, dividindo os benefícios da automação
pelos custos de esforço para automatizar.
ROI
Geralmente o custo de automação são todos os envolvidos, direta e indiretamente neste
processo como hardware, software (licenças), treinamentos, tempo de desenvolvimento
de teste, etc. os benefícios serão visualizados por um determinado tempo, reduzindo os
testes manuais, melhorando a capacidade de descoberta de defeitos e de ter a capacidade
de ser executado 24hs/dia.
Automação de Testes
9
Unidade 2
Tipos de automação Ferramentas de teste são para ser um apoio ao processo de testes, visando uma execução
mais rápida, mais barata ou até mesmo que execuções que não sejam viáveis
manualmente possam ser executadas.
Sabemos que a melhor utilização dos testes é mesclar os testes manuais com os
automatizados. Podemos agrupá-los em algumas categorias de ferramentas:
De automação de testes de regressão;
De gestão de defeitos;
De teste de performance;
Manuais;
De rastreabilidade;
De gestão de testes;
De cobertura de testes.
Dentro destas categorias em que podemos aplicar os testes, exibida pela figura abaixo
iremos apresentar as principais dentro o projeto de teste:
Planejamento Execução Finalização
Ferramentas de apoio
Automação de Testes
Gestão de defeitos
Gestão de testes
Automação de Testes
10
2.1 Caixa branca
2.1.1 Unitários
Dentro da técnica de caixa-branca sabemos que executamos os testes unitários que tem
por objetivo validar a estrutura interna e a lógica da aplicação desenvolvida (ou a ser).
Sabemos também que a execução deste tipo fica a cargo da equipe de desenvolvimento
do software, pois é esta equipe que possui os conhecimentos necessários para tal.
2.2 Caixa preta
2.2.1 Funcional
A técnica de teste funcional confronta todos os requisitos do sistema, a fim de tornar
válida toda a requisição do cliente. E que além de validar os requisitos são aplicadas
algumas técnicas para provar o principal objetivo do teste de software: aprovar que a
aplicação funciona.
2.2.2 Performance
Nos testes de performance submetemos nossa aplicação a um número conhecido de
usuários sob utilização padrão de acordo com os requisitos, e que o sistema deve manter
um desenvolvimento aceitável sem que ocorram erros.
É claro que se não tivermos informações relevantes para aplicarmos uma combinação
das técnicas de Carga e Stress para descobrir os limites da aplicação e assim determinar,
basicamente, o número de usuários suportados sob determinado cenário com um tempo
de resposta adequado.
2.3 Gestão
2.3.1 Gestão de defeitos
A gestão de defeitos é um dos itens de maior utilização no processo de testes, pois é
nesse momento até o final do projeto que vamos arquivando (guardando) os defeitos e
acompanhando para a solução do mesmo.
É importante salientar que o envolvimento não é somente da equipe de teste, mas
também da equipe de desenvolvimento. A gestão de defeitos é uma das ferramentas que
Automação de Testes
11
auxiliam os testadores a acompanhar quais erros existem nas aplicações e quem pode
resolvê-los.
2.3.2 Gestão de testes
É na gestão de testes que efetuamos todo o planejamento de teste, elaboramos os
documentos necessários para os testes nos sistemas e coletamos as métricas para que
esta sirva como base para a tomada de decisão. A gestão também inclui o
acompanhamento das atividades de testes e análise de risco do projeto. (análise sobre o
que já foi efetuado no projeto).
2.3.3 Massa de dados
Sabemos que a geração de massa de dados é um item fundamental para o sucesso dos
testes. Esta massa de dados pode ser gerada aleatoriamente, conforme a sua
necessidade, mas é importante lembrar que quem for criar a massa de dados, deve ter
profundo conhecimento sobre os dados a serem inseridos na base de teste, para que a
mesma em vez de facilitar nossa vida, não acabe prejudicando o trabalho dos testes.
Automação de Testes
12
Unidade 3
Ferramentas mais utilizadas no mercado de
automação
O próximo passo é adquirir ferramentas, e não necessariamente adquirir significa
comprar, pois há muitas ferramentas Open Source (free). Caso nenhuma ferramenta
seja satisfatória para seus tipos de softwares ou tipos de testes, sejam elas pagas ou
free, pode-se também desenvolvê-la.
Como desenvolver pode ser muito custoso, as empresas adotam cada vez mais as
ferramentas já disponíveis no mercado. As ferramentas disponíveis são variadas, e
sua escolha depende do quanto as empresas estão dispostas a investir
financeiramente ou em tempo.
3.1 Ferramentas Pagas
Conheceremos ferramentas das três empresas líderes de mercado, sem entrar em
mérito de valores:
3.1.1 IBM
A IBM é uma gigante em ferramentas para automação, aqui vamos citar 3 das que
podem ser utilizadas para testes:
RationalFunctionalTester: uma solução de teste funcional e de regressão
automatizada para equipes de QA preocupadas com a qualidade de seus aplicativos
Java™baseados na Web, Microsoft® Visual Studio .NET®, baseados em terminal,
SAP, Siebel e Web 2.0.
RationalPerformanceTester: uma solução de teste de carregamento e desempenho
para equipes preocupadas com a escalabilidade de seus aplicativos baseados na
Web.
RationalRobot: uma ferramenta de automação para equipes de QA para aplicativos
de teste de cliente/servidor. Permite detecção de defeito, inclui etapas de teste e
gerenciamento de teste, suporta diversas tecnologias de UI. Inclui gerenciamento de
teste embutido, integra-se com as ferramentas do IBM RationalUnifiedProcess.
Automação de Testes
13
3.1.2 HP
Inicialmente quem possuía as ferramentas para automação de testes da HP era a
Mercury, por isso muitos dos nomes ainda podem estar associados a este nome. No
entanto hoje fazem parte da HP.
HP LoadRunner: é a ferramenta considerada como a melhor no mercado para
validação de desempenho. Ele evita problemas de desempenho, detectando gargalos
antes de uma implantação ou atualização de sistema.
HP QuickTest Professional: também muito conhecido como QTP, é uma
ferramenta para automação de testes, utiliza o conceito de keyword-drive para
facilitar a criação e manutenção dos testes.
3.1.3 Automated QA
É uma empresa jovem no mercado, e focada em produtos e serviços voltados ao
desenvolvimento de projetos de garantia da qualidade de software. Suas ferramentas
estão sendo fortes concorrentes das demais ferramentas devido seu baixo custo.
TestComplete: oferece o mesmo conjunto de funcionalidades que os seus principais
concorrentes.
Possibilita criar testes unitários, funcionais, regressão e performance.Por se tratar de
uma ferramenta de baixo custo, hoje muitas empresas, inclusive as de grande porte,
estão migrando ou adquirindo essa ferramenta, tendo em vista da facilidade em
poder se trabalhar com ela. Um dos destaques é o suporte nativo para a automação
de sistema desenvolvidos em várias tecnologias, tais como: .NET, Java, Visual
Basic, Borland Delphi, WEB, PowerBuilder, FoxPro, entre outros.
Além disso, o TestComplete oferece recursos para a realização de testes de
desempenho para aplicações WEB e testes funcionais de WEB Services.
3.2 Ferramentas Free
O mercado de ferramentas free vem ganhando cada vez mais espaço, e o principal
motivo é o de não haver custo inicial com a aplicação. A maioria das ferramentas hoje
possuem todas as funcionalidades de ferramentas pagas. Embora a maioria também seja
mais complexa de ser utilizada, o mundo free possui cada vez mais pessoas utilizando
estas ferramentas, e o suporte a cada uma delas é colaborativo.
Um ponto onde elas deixam a desejar é que elas não possuem uma integração entre as
diversas ferramentas existentes no mercado, questão que as ferramentas pagas atacam
com os chamados Quality Centers.
Automação de Testes
14
Neste curso abordaremos ferramentas que possam ser implantadas com baixo custo
dentro de cada empresa. O foco será compreender o funcionamento básico das
ferramentas free mais utilizadas no meio da automação de teste.
Automação de Testes
15
Unidade 4
Conhecendo o ambiente e instalando
ferramentas
4.1 Ambiente de testes
4.1.1 Infraestrutura necessária
O ambiente tem total importância no projeto de teste, não sendo apenas hardware, mas
também:
Pessoal;
Ambiente físico;
Documentação;
Rede;
Software;
Suprimentos.
Quanto maior o nível do ambiente, maior deve ser sua capacidade de reproduzir todas as
características do cliente. Vamos pensar que, por exemplo, em erros que ocorrem no dia
a dia. Erros em páginas web podem ocorrer em diferentes navegadores, erros de
aplicativo em diferentes sistemas operacionais e assim por diante. De acordo com as
configurações mínimas exigidas para a instalação do sistema já estamos definindo nosso
ambiente.
Não é a toa que nas ferramentas de bugtracker temos um campo para dizer em qual SO
o erro ocorreu.
A cada nível de teste temos a diferenciação de ambiente. Estes ambientes podem nem
pertencer exclusivamente a equipe de teste, mas precisam ser salientadas:
Atributos Nível
Unitário Integração Sistema Aceitação
Escopo Unidade
individual
Unidades
Grandes
Sistema
inteiro
Simulação da
Produção
Equipe Desenvolvedores Desenvolvedores
e Testadores Testadores
Testadores e
usuários
Volume de
dados Pequeno Pequeno Grande Grande
Origem de
dados Criação manual Criação manual
Criação
por
processo
Dados reais
Automação de Testes
16
Interfaces N/A N/A Simuladas Reais/Simuladas
Ambientes Desenvolvimento Desenvolvimento Testes Produção
Dentro do ambiente de testes, temos uma infra-estrutura básica para comportar os testes
automatizados:
Servidor de aplicativos
Servidor que irá conter os programas utilizados para gerenciamento, controle e
execução de testes. Também contem aplicação de suporte.
Ambiente virtualizado
Ambiente para simular os ambientes descritos como propício para a utilização
do sistema. Pode-se criar as máquinas virtuais para testar um erro específico
com a configuração do cliente.
Sistema alvo (SUT)
É a aplicação que será o alvo dos testes, pode ser um servidor específico ou
mesmo um ambiente virtualizado.
Banco de dados
Sempre necessário para a maioria das aplicações, temos que possuir um banco
exclusivo e controlado para a execução dos testes.
4.1.2 Massa de dados
A massa de dados é um fator muito importante na preparação do ambiente, pois em
alguns níveis como unidade e integração ele pode ter uma baixa relevância, mas para
um teste de carga ele tem um peso muito grande.
O ambiente de testes deve ser um local isolado de todos os outros ambientes e com
todas as características do ambiente do cliente, ou ambiente de produção como também
é chamado.
Uma alternativa que já está sendo muito utilizada por empresas é a virtualização. Ela
elimina custos de hardwares físicos possibilitando não só ter menos custo, mas também
redução de tempo para preparação do ambiente de teste.
Mas é necessário que se tome muito cuidado: não utilizem ambiente virtualizado para
teste de performance, uma vez que emularmos o ambiente, teremos perda de
performance e utilização maior do hardware.
Automação de Testes
17
4.2 Configurando e instalando as ferramentas
4.2.1 E então vamos configurar e instalar o WampServer?
Antes de conhecermos sobre as ferramentas de automação de testes, iremos conhecer
uma aplicação que nos dará apoio para instalarmos e executarmos ouras ferramentas,
como TestLink e Mantis, por exemplo.
Estas ferramentas possuem algo em comum, elas necessitam ser instaladas e
configuradas e dependem de instalação de outras 3 aplicações: Apache, MySQL e PHP.
O Apache é um servidor web HTTP para exibição de páginas web.
O MySQL é um sistema gerenciador de banco de dados (SGBD), e é muito
utilizado.
O PHP é uma linguagem de programação interpretada para a web.
Como necessitamos destas 3 aplicações, é muito tedioso e complicada a sua instalação e
suas configurações para que consigamos utilizar o TestLink e o Mantis.
O propósito do Wamp, é exatamente este, facilitar estas instalações, unindo estas 3
aplicações já configuradas e dependendo apenas de um download, que seria do
WampServer.
Esta ferramenta é única e exclusiva para o uso da AMP (Apache + MySQL + PHP), em
ambiente Windows e traz as ultimas versões da AMP, além de conter outras ferramentas
de apoio.
Podemos encontrar estas ferramentas em:
Apache: http://httpd.apache.org/
MySQL: www.mysql.com/
PHP: www.php.net/
Wamp: www.wampserver.com/en/
Automação de Testes
18
4.2.2 Colocando as aplicações para funcionar
É muito simples a instalação do WampServer, mas veremos aqui o passo a passo para
que futuramente você consiga utilizá-lo como um guia.
Primeiramente faça o download do WampServer na versão que mais lhe agradar.
1. Clique no executável.
Será exibida a tela questionando se você realmente deseja executar o software:
2. Clique em [Executar].
Será exibida a tela das ferramentas e versões que o Wamp que fez o download
possui:
Automação de Testes
19
3. Clique em [Next].
É a tela de termos de aceite, caso esteja de acordo, então selecione a opção “I accept
the agreement”.
Automação de Testes
20
4. Clique em [Next].
Será exibida a tela onde mostra o local a ser instalado. Caso deseje escolher outro
local selecione outro.
5. Clique em [Next].
É exibida a tela onde você informa se deseja que seja criado um ícone na área de
trabalho e/ou no menu iniciar.
Selecione opções.
Automação de Testes
21
6. Clique em [Next].
É exibida a tela confirmando locais de instalação e ícones que serão criados:
Automação de Testes
22
7. Clique em [Install].
É exibida a tela com o progresso da instalação.
8. Caso o Firefox esteja instalado, é informado que o mesmo foi detetcado em seu
computador e se deseja que este seja o browser padrão para o WampServer.
9. Clique em [Sim].
... finalizando instalação...
10. É exibida a tela de Parâmetros do PHP.
Em SMTP mantenha “localhost” e em e-mail altere se necessário.
Automação de Testes
23
11. É exibida a tela de finalização de instalação.
12. Para abri-lo basta clicar em [Finish].
Automação de Testes
24
Pronto! Agora que o Wamp já está instalado, podemos alterar a sua linguagem:
No ícone da barra de tarefas, clique com o botão direito sobre o ícone do Wamp >>
Selecione a opção “Language” >> em seguida selecione a opção “Portuguese”.
Feito, configuração de linguagem alterada!
Com o botão esquerdo do mouse, clique sobre o ícone do Wamp.
Será exibido o menu:
Automação de Testes
25
4.2.3 Executando as aplicações
Todas as aplicações que necessitam de PHP, MySQL e Apache são inseridas no
diretório “www” do Wamp: C:\wamp\www\
Estas aplicações estarão disponíveis através do endereço localhost. Podemos visualizar
a aplicação das duas maneiras abaixo, digitadas no browser:
1) http://localhost/nome_da_pasta ou
2) http://localhost/ e selecionando a pasta listada no item “Your projetcs”.
Automação de Testes
26
Unidade 5
Gerenciamento de casos de teste e execução
com TestLink
5.1 Gestão de testes com TestLink
5.1.1 Objetivos
O TestLink é uma ferramenta de gestão de testes, onde seu principal intuito é gerenciar
planos e casos de testes, além também de habilitar a simulação de execução trazendo
métricas para cada projeto. Com ela podemos criar diversos projetos de testes e atribuir
planos e casos de teste a eles, bem como rastrear requisitos do sistema para cada plano
ou caso de teste.
O TestLink é uma aplicação Open Source cujo principal objetivo é gerenciar as
atividades de testes de um projeto. Por meio do TestLink você poderá criar Casos de
Teste e organizá-los em Suites de Teste.
Você também poderá associar um conjunto de Casos de Teste a um testador e
acompanhar os resultados da execução dos testes, assim como, gerar relatórios com
diversas métricas para o acompanhamento da execução dos testes.
O TestLink oferece um recurso para que você possa registrar e organizar os requisitos
do projeto, assim como, associar os Casos de Teste aos requisitos. Dessa forma, você
poderá garantir o rastreamento entre os requisitos e os Casos de Teste por meio de uma
matriz de rastreabilidade.
Adicionalmente, o TestLink permite a integração com Mantis. Por meio dessa
integração, quando um Caso de Teste falhar, você conseguirá associar os Bugs
cadastrados no Mantis a este Caso de Teste.
Entre as diversas funcionalidades oferecidas pelo TestLink, devemos destacar as
seguintes:
Pode ser executado em qualquer plataforma que suportar PHP/Apache/Mysql
(Windows, Linux, Mac, Solaris, AS400/i5, etc);
Traduzido em várias línguas diferentes (incluindo "Brazil Portuguese");
Controle de acesso e níveis de permissões por papéis (Líder, Testador, etc);
Os casos de testes são organizados hierarquicamente em suítes;
Automação de Testes
27
Os casos de testes podem ser classificados por palavras-chave ("keyword") para
facilitar a pesquisa e organização;
Criação ilimitada de projetos e casos de testes;
Os ciclos de testes podem ser priorizados e atribuídos aos testadores;
Gerador interno de relatórios e gráficos (possibilidade para exportar os dados
nos formatos CSV, Excel e Word);
Integração com ferramentas de gestão de defeitos (Bugzilla, Mantis, Jira);
O download pode ser feito em http://www.teamst.org/ .
5.1.2 Instalando a ferramenta
1) Efetue o download em http://www.teamst.org/ >> Menu “Download” >> Será
aberta nova janela.
2) Selecione a versão TestLink 1.9.3
3) Clique em testlink-1.9.3.tar.gz e aguarde que o download inicie. Será salvo em
C:\Users\Nome_usuário\Downloads
4) Clique no .Rar e descompacte os arquivos dentro da pasta C:\wamp\www .
5) Utilizando o WampServer, vá em PHPMyAdmin e crie um banco de dados com
o nome de TestLink.
6) Após criar o bd, no arquivo "php.ini" alterar as questões abaixo:
o Max_execution_time de 30 para 120;
o session.gc_maxlifetime de 1440 para 5000;
o Salvar o arquivo e após reinciar o WampServer.
7) Execute a aplicação via http://localhost/
8) O sistema questionará sobre instalar uma nova versão ou atualizar uma versão já
existente:
9) Solicite criar uma nova versão clicando no link “New Installation“.
Automação de Testes
28
A instalação é dividida em cinco passos:
Acceptance of License (Aceite da Licença)
Basicamente ler e aceitar a licença marcando o checkbox “I agree to the terms
set out in this license.”
Verification of System and configuration Requisitoss (Verificação do sistema e
configurações requeridas)
O sistema avalia as configurações do computador em que o TestLink será
instalado. Caso tenha algum problema, ele será apresentado para correções.
Quando a mensagem “Your system is prepared for TestLink configuration (no
fatal problem found).” for apresentada, basta solicitar “Continue”.
Definition of DB access (Definição do acesso ao Banco de Dados)
Neste tutorial só apresentaremos a instalação usando a máquina local e o MySql
como banco de dados. Informe o nome do banco de dados criado, neste caso “testlink”, usuário e senha
do “root” do banco de dados. Inclua também o usuário que criamos e a senha escolhida, logo após solicite
“Progress TestLink Setup”.
Criar DB, testlink DB user, structures and default data & Criar configuration
file. (Criação do usuário do Banco de dados, estruturas e dados padrões e criação
do arquivo de configuração)
Verify the procedure result (Verificação dos resultados do procedimento)
Automação de Testes
29
Continue to TestLink login. (Continue para o login do TestLink).
5.1.3 Estrutura geral
Há três fundamentos no TestLink: Projeto de Teste, Plano de Teste e Usuário. Todos os
outros dados são relações ou atributos desta base.
5.1.4 Definições Básicas
Primeiro, vamos definir os termos que são utilizados no Testlink:
Teste: descreve uma tarefa de teste através de passos (ações, cenário) e
resultados esperados. O caso de teste é o elemento fundamental do TestLink.
Test Suite: (Suite Test Case) organiza Casos de Teste em unidades. Subdivide
uma especificação de teste em partes lógicas.
Automação de Testes
30
Plano de Teste: é criado quando você pretende executar casos de teste. Planos de
teste são feitos dos casos de teste a partir do projeto de teste atual. Um plano de
teste inclui Builds, Marcos, atribuição de usuário e resultados do teste.
Projeto de Teste: é algo que vai existir sempre no Testlink. Um projeto de teste
sofre muitas versões diferentes ao longo de sua vida. Um projeto de teste inclui
especificações de teste com Casos de Teste, Requisitos e palavras-chave.
Usuários dentro do projeto definem papéis.
Usuário: cada usuário TestLink tem um papel que define as características
disponíveis.
5.1.5 Exemplo simples de fluxo de trabalho no TestLink;
1. O Administrador cria um projeto de teste "Fast Food" e mais dois usuários,
Adam com direitos "Líder" e Bela com direitos "Tester Sênior".
2. O Líder Adam importa Requisitos de Software e parte desses requisitos gera
casos de teste vazias. Ele reorganizá-os em duas suites de teste: "peixe" e
"Chips".
3. A Tester Bela descreve um cenário de teste (cria um conteúdo de Casos de Teste
vazias) usando estas especificação de teste que está organizado em suites de
testes.
4. Adam cria a palavra-chave "teste de regressão" e atribui esta palavra-chave para
10 destes casos de testes.
5. Adam cria um Plano de Teste "Fish & Chips 1", Build "Fish 0,1" e liga todos os
casos de teste em Suite de Teste "Fish" para este Plano de Teste. Ele atribui a si
mesmo e a Bela como recursos para este Plano de Teste também.
6. Agora, os desenvolvedores Liberaram a primeira versão. Adam e Bela executam
e gravam o teste com o resultado: 5 passado, uma falha e 4 estão bloqueadas.
7. Os Desenvolvedores fazer uma nova build "Fish 0,2" e Bela testa apenas os
casos de teste que falharam e foram bloqueados. Desta vez estes testes passaram,
e com isso eles também testam novamente todos os casos de teste com palavras-
chave "teste de regressão".
Automação de Testes
31
8. Um gerente dessa equipe Quer ver os resultados. O Administrador explica a ele
que ele pode criar uma conta na página de login. O Gerente o faz. Ele tem
padrão "Gerente" direitos e pode ver os resultados de teste e casos de testes. Ele
pode ver que tudo o que passou no relatório geral ;-) e problemas na Build "Fish
0.1" em um relatório específico para Build.1.
9. Mais tarde, os desenvolvedores finalmente, adicionam também a funcionalidade
"Chips". Adam cria um Plano de Teste "Fish & Chips 2". Ele pode reutilizar o
primeiro plano de teste como modelo. Todos os Casos de Teste "Fish" e os
papéis serão adicionados automaticamente. Ele cria um novo Build "Fish 1.1" e
vincula todos os Casos de Teste "chips" a este plano de teste também.
10. Agora o teste começa como de costume.
11. Mais tarde, o Administrador cria um novo projeto de teste para outro produto
"Hot Dog". Mas esta é de uma outra equipe de teste e história diferente.
Automação de Testes
32
5.1.6 Algumas configurações antes de iniciar
No TestLink para facilitar seu entendimento, ao logar, vá até “My Settings” e solicite o
“Locale” para “Portuguese (Brazil)”.
No arquivo “C:\wamp\www\testlink\config.inc.php”:
Aqui não veremos todas as opções de configurações que podemos realizar no arquivo de
configurações do TesLink, mas salientar que arquivo pode ser alterado visando otimizar
esta ferramenta para ser mais usual, produtiva e atrativa para seus usuários e
desenvolvedores.
Ocultando Avisos de segurança: Vá até a linha “$tlCfg-
>config_check_warning_mode = ‘FILE’;” e modifique o “File” por “SILENT”.
Removendo o registro de novos usuários: Vá até a linha “$tlCfg- >user_self_signup = TRUE;” e modifique o “TRUE” por “FALSE”.
Mudando o Idioma padrão para português: Vá até a linha “$tlCfg-
>default_language = ‘en_GB’;” e modifique o “en_GB” por “pt_br”.
Criando padrão de login: Mude o valor da expressão regular na linha “$tlCfg-
>validation_cfg->user_login_valid_regex=’/^[\w \- .]+$/’;”. por exemplo, para ter um
login com “nome.sobrenome”, mude a regex para “/^[\w \-]+\.+[\w \-]+$/”.
Incluindo o logotipo da sua empresa no Sistema: Salve o logotipo da empresa no
formato PNG, preferencialmente nas dimensões ”115/53″. Salve esse arquivo no
diretório “C:\wamp\www\testlink\gui\themes\default\images”. Vá até a linha “$tlCfg-
>company_logo = ‘company_logo.png’;” e modifique o texto “company_logo.png”
para o nome do arquivo que salvou no diretório citado acima.
Mensagens de boas vindas, aviso ou emergência: Vá até a linha “$tlCfg->login_info
= ”; ” e inclua o texto entre as aspas simples. Esse texto será apresentado na tela de
login. Na imagem abaixo podem ser vistas algumas das mudanças, ressaltando esta. Ordenação alfabética dos projetos: Vá até a linha “$tlCfg->gui-
>tprojetcs_combo_order_by = ‘ORDER BY nodes_hierarchy.id DESC’;” e modifique
o conteúdo entre as aspas por “ORDER BY name”.
5.2 Projeto de teste
Assim que o TestLink for instalado e configurado, a sua primeira ação deverá ser criar
um novo projeto. Para tal tarefa, ou você já estará na página “Gerenciar Projeto de
Teste” ou clicará no link principal do TestLink no canto superior esquerdo, após clicar
em breve será exibida a página “Gerenciar projeto de Teste: Criar um novo projeto”,
conforme o exemplo apresentado abaixo.
Automação de Testes
33
É importante ressaltar que durante a criação do projeto, você poderá desabilitar o
recurso de funcionalidade e requisitos oferecido pelo TestLink, caso você utilize alguma
outra ferramenta para este fim.
Após preenchidos os campos conforme seu interesse, basta clicar em [Criar].
Pronto, agora você possui um projeto.
Automação de Testes
34
5.2.1 Editando um projeto
Para editar um projeto é muito simples, basta ir no meu Início e clicar em Gerenciar
Projeto de Teste como mostra imagem abaixo:
Será exibida a lista contendo os projetos, clique sobre ele e edite o que quiser, após
clicar em [Salvar].
É importante ressaltar que não é interessante deletar um projeto, visto que todas suas
informações serão perdidas. Se possível sempre inative seu projeto quando não quiser
mais utilizá-lo.
Automação de Testes
35
5.3 Inventário
Os usuários podem listar seu hardware em uma tabela por projeto. O recurso deve ser
ativado na página de edição do projeto. Por default os líderes podem editar esta página e
testadores podem apenas navegar. O link Inventário está disponível na página principal,
no menu "Projeto de Teste".
A página Inventário oferece três ações: criar, Editar e Deletar.
A tabela mostra todos os dispositivos e permite a classificação em qualquer campo.
Selecione a opção "Criar" para definir um dispositivo. Os parâmetros a seguir são
suportados:
Nome do host (valor obrigatório exclusivo);
Endereço IP;
Objetivo (texto simples com maximamente 2000 caracteres);
Hardware (texto simples com maximamente 2000 caracteres);
Notas (texto simples com maximamente 2000 caracteres);
Dono (opcional) pode ser qualquer pessoa que tenha pelo menos a capacidade de
ver.
Para Editar e Excluir requer uma linha selecionada.
5.4 Especificações de Teste
Automação de Testes
36
O TestLink quebra a estrutura de especificação de teste em Suites e Casos de teste.
Estes níveis persistem em todo o aplicativo. Um projeto de teste tem apenas uma
especificação de testes.
Planejamos implementar as seguintes habilidades: padrões de teste, processo de revisão
e status de casos de teste, estrutura de caso de teste (por exemplo o design de passo a
passo).
5.5 Adicionando requisitos
Assim que o projeto for criado, o próximo passo é a criação dos requisitos (caso você
tenha habilitado o recurso de funcionalidade e requisitos). Primeiro, você deverá
adicionar uma Especificação de Requisito.
Para realizar tal tarefa, vá para a seção “Requisitos” e então clique no menu
“Especificar Requisitos”.
A página “Especificação de Requisitos” deverá ser exibida, conforme o exemplo
apresentado na figura abaixo:
Automação de Testes
37
Para adicionar uma Especificação de Requisitos, devemos clicar sobre o projeto
desejado e após clicar em “Nova Especificação de Requisito”:
É importante salientar que segundo a organização do TestLink, cada requisito deve ser
associado a uma Especificação de Requisito, que representa a grosso modo um
agrupador de requisitos semelhantes (algo como uma suíte ou seção de requisitos.
5.5.1 Editando Especificação de Requisitos
Tão logo a Especificação de Requisito seja criada, você deverá clicar sobre ela. A
página “Editar Especificação de Requisitos” deverá ser exibida, conforme o exemplo
apresentado abaixo:
Automação de Testes
38
Nesta página você poderá importar os requisitos por meio de um arquivo externo
(*.CSV) ou adicionar o requisito manualmente. Observe ainda que, nesta página você
poderá também visualizar a lista de requisitos existentes, assim como, gerar um
relatório (por meio do botão “Visualizar Impressão”).
Para adicionar um requisito manualmente, você deverá clicar no botão “Criar Novo
Requisito”:
A página “Criando um Novo Requisito” deverá ser exibida, conforme a seguinte tela.
Convém lembrar, aliás, que durante a criação do requisito, você poderá identificar no
campo “Status” se o requisito é testável ou não e qual o “Tipo” dele.
Automação de Testes
39
Após salvar a tela já é atualizada com a informações do requisito inserido.
5.5.2 Adicionando Casos de Teste
Pressupondo que os requisitos já foram criados, o próximo passo deve ser a criação dos
Casos de Teste. Em primeiro lugar, no entanto, você deverá criar uma Especificação de
Teste. Para tal tarefa, clique no menu “Especificação”. A página “Especificação de
Testes” deverá ser exibida, conforme o exemplo apresentado.
Automação de Testes
40
Nesta página clique sobre o projeto e após clique em no botão “Nova Suite de Teste”:
De forma similar aos requisitos, a Especificação de Teste deverá obedecer a uma
organização hierárquica definida pelo TestLink. Nessa condição, segundo a hierarquia
do TestLink, cada Especificação de Teste é composta por um ou mais Suites, que por
sua vez pode ter uma ou mais Casos de Teste.
Automação de Testes
41
Uma vez que o Suite for criado, você deverá selecioná-lo na lista dos componentes
disponíveis:
Aqui você pode tanto criar um novo Suite dentro deste como pode já Criar um caso de
teste.
Automação de Testes
42
O TestLink também permite a impressão dos Casos de Teste. Para realizar tal tarefa,
você deverá ir para a seção “Especificar Testes” e então clicar no menu “Imprimir
Casos de Teste”. A página “Imprimir Casos de Teste” deverá ser exibida.
Automação de Testes
43
Nesta página você deverá selecionar a Categoria que você deseja imprimir e configurar
as opções de impressão na seção “Opções do documento”.
Automação de Testes
44
5.5.3 Associando Casos de Teste aos Requisitos
Conforme comentado anteriormente, o TestLink permite que você possa associar os
Casos de Teste aos requisitos. Dessa forma, você poderá garantir o rastreamento entre
os requisitos e os Casos de Teste por meio de uma matriz de rastreabilidade. Para
realizar tal tarefa, você deverá ir para a seção “Requisitos” e então clicar no menu
“Selecionar Requisitos”.
A página “Atribuir requisitos ao Caso de Teste” deverá ser exibida, conforme o
exemplo abaixo. Nesta página você deverá selecionar o Caso de Teste desejado, depois
selecionar os requisitos disponíveis e, por último, associar o Caso de Teste aos
requisitos (por meio do botão “Atribuir”).
Automação de Testes
45
PS.: Um requisito só pode ser atribuído se este for o Requisito de Operação, então
primeiro cria-se um Requisito Pai <como feature por exemplo> e após cria-se um
requisito operacional vinculado a este Requisito pai.
5.5.4 Associando Palavras Chaves aos Casos de Testes
O TestLink permite que uma palavra-chave seja associada aos Casos de Teste. As
palavras chaves facilitam a realização de pesquisas ou filtros dos Casos de Teste
disponíveis. Para criar uma Palavra Chave você deverá ir para a seção “Projeto de
Teste” e então clicar no menu “Gerenciar palavra-chave”. A página “Nova Palavra
Chave” deverá ser exibida.
Tão logo as palavras chaves sejam criadas, você poderá associa-las aos Casos de Teste.
As Palavras-chave podem ser atribuídas a casos de testes a partir da tela de atribuição de
palavras-chave ou através da gestão de Casos de Teste (individualmente).
Automação de Testes
46
Os usuários têm a capacidade de filtrar por palavras-chave em:
Árvore de navegação de especificação de teste;
Busca de Casos de Teste de especificação de teste;
Adicionar Casos de Teste em um conjunto de testes (plano de teste);
"Executar teste" página.
5.5.5 Criação e exclusão de Planos de Teste
Planos de teste podem ser criados a partir do "Gerenciar Plano de Teste" na página
principal por usuários com privilégios para o projeto de teste atual. Pressione o botão
"Criar" e inserir os dados.
A definição do Plano de Teste consiste em título, descrição (formato html) e status
opção "Ativo".
A descrição deve incluir as seguintes informações em relação aos processos da
empresa: Resumo / Scopo;
Featues a serem testadas;
Funções a não serem testadas;
Critérios de teste (para passar o produto testado);
O ambiente de teste de Infraestrutura;
As ferramentas de teste;
Riscos;
Referências (plano de produto ou solicitação de alteração, documentos de
Qualidade, etc).
Planos de teste são compostos de casos de teste importados de uma especificação de
teste com um tempo determinado. Planos de teste podem ser criados a partir de outros
Planos de Teste. Isso permite aos usuários criar planos de teste de casos de teste que
existem um prazo de tempo desejado. Isso pode ser necessário quando se cria um Plano
de teste para um patch. Para que um usuário possa ver um plano de teste, o mesmo deve
ter os direitos apropriados.
Planos de teste podem ser excluídos pelos usuários com privilégios. Excluindo os
Planos de Testes de forma permanente exclui tanto o plano de teste e todos os seus
dados correspondentes, incluindo os casos de teste, resultados, etc Isso deve ser
utilizado apenas para casos especiais. Opcionalmente Planos de Teste podem ser
desativados na mesma página, que suprime a exibição de menus de seleção.
5.5.6 Criando Baselines / Releases
À medida que se queira executar os Casos de Teste de um Suite de teste você deverá
criar um “Baselines / Releases”. Um usuário com privilégios de líder pode seguir o link
" Baselines / Releases" no menu “Gerenciar Plano de Teste” na página principal.
Uma Baselines / Releases é uma versão específica de software. Cada projeto em uma
empresa é composta de muitas versões. No TestLink, a execução é baseada em
Automação de Testes
47
“Baselines / Releases” e Casos de Teste. Se não houver “Baselines / Releases” criados
para um projeto, a tela de execução não irá permitir que você execute-a. A tela de
métricas também será exibida completamente em branco.
Cada “Baselines / Releases” é identificado através de título. Ele inclui descrição
(formato html) e dois estados:
Ativo / Inativo;
Aberto / fechado.
5.5.7 Adicionando casos de teste ao Plano de Teste
O conteúdo do plano de teste é definido pela adição de um conjunto de testes (de Casos
de Teste) a partir da especificação de testes. No menu “Conteúdo do plano de teste” use
o link "Adicionar / Remover Casos de Teste" na página inicial. Dados de especificação
de teste podem ser filtrados por palavras-chave. Depois que os dados forem associados a
um plano de teste, o mesmo é marcado com uma seleção.
Automação de Testes
48
Pode-se escolher casos de teste através da caixa de seleção e clique em "Adicionar
selecionadas" para definir o conjunto de teste. Clique ícone de check para selecionar
todos os casos de teste em cada Suite de Teste. Todos os casos de teste podem ser
adicionados clicando no rótulo sob o título Suite de Teste.
Uma certa versão de um caso de teste é atribuído a um Plano de Teste. Pode-se atualizar
a versão para depois testar se o caso de teste for atualizado. O conteúdo de uma versão
do caso de teste executado não pode ser modificado.
Dica: um plano de teste tem apenas um conjunto de casos de teste. Pode-se adicionar
novos casos de teste durante o teste, mas isso afeta as métricas de versões mais antigas,
como os novos casos de teste contam como "não executar" para aqueles versões. Na
maioria dos casos isto não é importante. Se, contudo, isso é importante para você, você
tem duas opções:
Criar um plano de teste novo para a segunda fase de testes.
Usar palavras-chave para reconhecer as fases de teste dentro de um plano de teste.
Automação de Testes
49
5.5.8 Atribuição de execução de teste
Você pode atribuir casos de teste para a execução para diferentes usuários. Atribuição a
execução do teste afeta tanto a execução e relatórios. Nos usuários de tela de execução
tem a capacidade de classificar os casos de teste executáveis para ver os que foram
atribuídas. Nos relatórios, há uma tabela que apresenta os casos de teste restantes por
testador. Se não houver um testador de caso de teste atribuído o padrão é nenhum. Um
Tester também pode ver as métricas de seu / seus próprios testes executados na página
principal, se essas métricas são ativados.
5.6 Plataformas
A Plataforma descreve uma "unidade" de casos de teste que pode ser executada. Por
exemplo, uma plataforma pode ser um navegador, um sistema operacional, um
equipamento de hardware ou configuração. Um plano de teste pode ter plataformas
associadas que são escolhidas quando um caso de teste é executado.
Um projeto de teste pode ter várias plataformas que precisam ser testadas. Por exemplo,
um site precisa ser testado em diferentes navegadores, ou um aplicativo precisa ser
executado em diferentes sistemas operacionais ou equipamentos de hardware. O
TestLink chama a isso de conceito de Plataformas. As plataformas são uma maneira de
conectar casos de teste em um plano de teste e a uma plataforma específica de software,
equipamento ou configuração.
Automação de Testes
50
Para usar o recurso de plataformas, algumas plataformas devem primeiro ser criadas em
"Gerenciamento de Plataforma" (acessível a partir da página principal).
Selecione um plano de teste e clique em "Adicionar / Remover plataformas". Atribuir
plataformas para um plano de teste, movendo-os para o painel direito e Salvar.
Agora casos de teste podem ser adicionados ao Plano de Teste. Isso é feito da mesma
forma normalmente, como a exceção de que um caso de teste deve ser verificado uma
vez para cada plataforma que deve ser executado.
O próximo passo é atribuir os usuários a executar os casos de teste. Você é livre para
associar usuários como você deseja. Uma possibilidade é ter um usuário para executar
um caso de teste em todas as plataformas. Outra forma é permitir que um usuário
execute todos os casos de teste em uma plataforma, ou uma mistura dos dois.
Quando múltiplas plataformas são utilizadas na etapa de execução do TestLink, ele
recebe uma opção de filtro adicional. Verifique se a seleção da plataforma está definido
para a plataforma que você está indo para executar em casos de teste.
Relatórios de testes incluem a plataforma nas métricas.
5.7 Priorizando testes
Prioridade de teste é um recurso opcional. Normalmente, algumas características de
uma versão são novas ou sujeitas a um forte desenvolvimento, que devem receber mais
atenção. Por outro lado, algumas características foram quase intocadas, e para estes
apenas os testes mais importantes precisam ser executados.
Configuração: Esse recurso deve ser ativado em nível de projeto de teste pelo
administrador ("Gerenciamento de projetos de Teste" na página principal).
O parâmetro de prioridade de teste é definido como uma combinação de importância e
urgência do caso de teste e Suite em um plano de teste. Prioridade de teste pode ser
utilizado como uma definição do filtro para a execução do teste e é também relatado em
métricas.
TestLink dá aos usuários a capacidade de atribuir importância a casos de testes. Existem
três níveis:
alta, média e baixa. Este valor é ajustável durante o projeto de teste na especificação de
testes.
Urgência é o segundo parâmetro que afeta a prioridade de teste. Urgência é definido
para um certo plano de teste e não depende de Importância de teste.
Automação de Testes
51
Se você copiar um Plano de Teste, a urgência não é copiada. Um conjunto diferente de
urgência é esperado.
O TestLink combina esses dois atributos em níveis de prioridade alta, média e baixa. A
prioridade deve ajudar a escolher o conjunto certo de execução para testar em primeiro
lugar.
5.8 Marcos
O líder de teste pode definir um marco numa determinada data com um objetivo de
percentual esperado de testes finais. Este objetivo pode ser definido por três níveis de
prioridade, no caso de que priorização de teste é permitida.
5.8.1 Executando os Casos de Teste
A execução do teste está disponível depois de:
A especificação de teste estar escrita.
Um plano de teste ter sido criado.
Casos de Teste foram adicionados ao Plano de Teste.
Pelo menos uma Baseline foi criada.
Testadores receberam direitos apropriados para trabalhar com o presente Plano
de Teste.
Selecione a opção "Executar Testes" no menu superior ou na página principal para
navegar na tela de "Execução de Caso de Testes". O painel à esquerda permite a
navegação dentro dos casos de teste através de um menu árvore, e o set-up de
configurações e filtros. A janela de execução mostra informação relevante sobre um
caso de teste e permite a entrada de resultados do teste.
O painel de navegação é constituído por “Configurações” e “Filtros” no menu de árvore
contendo Casos de Teste.
Automação de Testes
52
Os usuários podem especificar o plano de teste para qual caso de teste deve ser
executado. Casos de Teste apenas pertencentes a esse plano de teste são mostrados.
Os usuários devem especificar a Baseline em teste, selecionando a partir da lista de
versões ativas. Sua Baseline mais recente por default é definida. Geralmente cada caso
de teste é executado apenas uma vez contra cada Baseline. No entanto, é possível
executá-lo várias vezes (talvez se o testador cometeu um erro).
Filtragem de Casos de Teste
Essa tabela permite ao usuário filtrar os casos de teste para navegação inteligente antes
de serem executadas.
Você deve clicar em "Aplicar filtro" para aplicar uma nova configuração do filtro.
Árvore
O menu da árvore no painel de navegação mostra a lista escolhida de Casos de Teste no
Plano de Teste. Ele permite que o caso de teste apropriado seja aberto para a execução
do teste no quadro à direita. Suites de teste no menu são reforçadas por um breve status
de teste após o título. Isso dá uma contagem de um código de cores de casos de teste:
não-executado, passou, falhou e bloqueado, respectivamente.
Automação de Testes
53
Status do teste
A execução é o processo de atribuição de um resultado (aprovação, reprovação,
bloqueado) para um caso de teste para um Build específica. Um caso de teste
'bloqueado' não pode ser testado, por algum motivo (por exemplo, um problema na
configuração impede que uma função de ser executado).
Inserindo Resultados do teste
O resultado do teste é mostrado através de um clique em um Suite de teste ou caso de
teste no painel de navegação. O título mostra a Baseline atual e dono. A barra colorida
indica o status do caso de teste. A caixa amarela inclui o cenário de teste do caso de
teste.
5.8.2 Relatórios de teste e métricas
Os relatórios de testes e métricas são acessados clicando em “Resultados” ou
“Relatórios de testes e métricas” nos links na página principal. Relatórios e métricas
baseiam-se no Plano de Teste selecionado (do menu da combobox). A página que é
mostrada ao usuário inclui: o painel direito será preenchido com instruções sobre como
usar os controles e como cada relatório é produzido.
O painel esquerdo é usado para navegar por cada relatório e por controles operacionais
que controlam o efeito e o comportamento dos relatórios que são mostrados. O botão
“Imprimir” inicializa a impressão do painel direito (nenhuma navegação será impressa).
Todos os relatórios de teste (exceto gráficos) podem ser gerados em 1 de 3 formatos: 1-
Normal: relatório é exibido na página web (html). 2-MS Excel: relatório é exportado
para o Microsoft Excel. 3-HTML e-mail: relatório é enviado ao endereço de e-mail do
usuário.
Existem atualmente nove relatórios separados para escolher sua finalidade e suas
funções são explicadas a seguir. Atualmente, não há relatórios que compilam os
resultados de vários planos de testes.
5.8.3 Métricas gerais de Planos de Testes
Esta parte mostrará apenas o mais atual status de um Plano de teste para testes de Suite,
proprietário e palavra-chave. A maioria dos “status atual” são determinadas pelos mais
recentes casos de testes de build executadas no dia. Por exemplo, se um caso de teste foi
executado durante vários builds, apenas o mais recente resultado é tido em conta.
“Último Resultado do teste” é um conceito usado em muitos relatórios e é determinado
como se segue:
Automação de Testes
54
1) A ordem na qual os builds são adicionados no plano de teste determina qual build é
mais recente. Os resultados do mais recente build terá precendentes de builds mais
velhos. Por exemplo, se você marcar um teste como “falha” no Build 1 e marcá-lo como
“passou” no Build 2, seu último resultado será “passou”.
2) Se um caso de teste é executado múltiplas vezes, sobre o mesmo build, a execução
mais recente terá precedência. Por exemplo, se Build 3 é liberado para a sua equipe e o
testador 1 marca como “passou” 2 horas da tarde e o testador 2 marca como “falha” 3
horas da tarde, ele aparecerá como “falhou”. 3) Casos de testes classificados como “não
executados” contra um build não são tidos em conta. Por exemplo, se você marca um
caso como “passou” no Build1e não executá-lo em Build 2, o último resultado será
considerado como “passou”.
A lista dos resultados de cada nível superior Suite. Total de casos, passou, falhou,
bloqueados, não executados e o percentual completo. Um caso de teste “completo” é um
processo que tem sido marcado como passou, falhou ou bloqueado. Resultados de nível
superior de Suites incluem todas as suítes mais novas.
5.8.4 Resultados por palavra-chave
Lista todas as palavras-chave que são atribuídas a processos no Plano de teste atual e os
resultados que lhes estão associados.
5.8.5 Resultados por Dono
Lista cada proprietário que tem casos de testes atribuídos no atual Plano de Teste. Casos
de testes que não são atribuídos são tallied under the “unassigned” heading.
5.8.6 Visão geral do status da Baseline
Lista a execução de resultado para cada build. Para cada build, o total de casos de testes,
total que passou, % que passou, total que falhou, % que falhou, bloqueados, %
bloqueados, não executados e % de não executados são exibidos. Se um caso de teste
foi executado duas vezes, no mesmo build, a mais recente execução será tomada em
conta.
5.8.7 Métricas da Query
Este relatório é constituído por um formulário de página de consulta e uma página de
consulta de resultados que contém os dados questionados.
Formulário da página de consulta:
Automação de Testes
55
O usuário é apresentado com uma página de consulta com quatro controles. Cada
controle é definido para um padrão o qual maximiza o número de casos de teste e builds
que a consulta deverá ser executada.
Alterando os controles, permite ao usuário filtrar os resultados e gerar relatórios
específicos para proprietário específico, palavra-chave, Suite e combinações de build.
Palavra-chave - 0→1 palavras-chave podem ser selecionadas. Por padrão- nenhuma
palavra-chave é selecionada. Se uma palavra-chave não está selecionada, então todos os
casos de teste serão considerados independente das atribuições das palavras-chaves.
As palavras-chave são atribuídas na especificação de testes ou nas páginas de
gerenciamento de palavra-chave.
Palavras-chave, atribuídas aos casos de testes, abrangerão todos os planos de testes e
abrangem a todas as versões de um caso de teste. Se você está interessado no resultado
de uma determinada palavra-chave, então você deve alterar esse controle.
Proprietário: 0→1 proprietários podem ser selecionados. Por padrão, nenhum
proprietário é selecionado. Se um proprietário não é selecionado, então todos os casos
de testes serão considerados independentemente do proprietário assignado. Atualmente,
não há nenhuma funcionalidade de pesquisa de casos de testes para “não atribuído”. A
propriedade é atribuída através de execução de “Atribuir Casos de Testes” e é feito em
uma base per Plano de Teste. Se você estiver interessado no trabalho realizado por um
determinado testador, você deve alterar esse controle.
Nível superior de Suite: 0→n nível superior de Suites podem ser selecionados. Por
padrão, todas as Suites são selecionadas.
Apenas Suites, que são selecionadas, serão consultadas para resultar métricas. Se você
estiver apenas no intested dos resultados de uma determinada Suite, você deve alterar
esse controle.
Baseia - 1→n builds podem ser selecionados. Por padrão - todos os Builds são
selecionados. Apenas execuções realizadas em Builds que você selecionar serão tidos
em conta quando se produzir métricas. Por exemplo: se você quiser ver quantos casos
de teste foram executados nos últimos 3 Builds, você altera este controle.
Palavra-chave, proprietário e nível superior de seleções de Suite irão ditar o número de
casos de teste a partir do seu Plano de teste que são usados para calcular por Suite e por
métricas de planos de testes. Por exemplo: se você seleciona proprietário = “Greg”,
palavra-chave = “Prioridade 1” e todos os testes de Suite disponíveis, apenas o casod de
teste de Prioridade 1 atribuído a Greg serão considerados. O ”# Casos de Teste” totais
que serão vistos no relatório serão influenciados por estes 3 controles.
Seleções de build irão influenciar se um processo considerado “passou”, “falhou”,
“bloqueou” ou “não foi executado“. Refira-se a “Resultado do último teste” de regras
Automação de Testes
56
que aparecem acima. Pressione o “enviar” para avançar com a consulta e exibir a página
de saída.
A página do relatório exibirá:
1- Os parâmetros utilizados para criar o relatório. 2- Totais de todo o plano de teste. 3-
Uma discriminação dos totais por Suite (soma/passou/falhou/bloqueados/não
executados) e todas as execuções realizadas nessa Suite. Se um Caso de Teste foi
executado mais de uma vez em múltiplos Builds, serão exibidas todas as execuções que
foram registradas contra os Builds selecionados. Contudo, faça um resumo para que
Suite só inclua o “Resultado do último teste” para os builds selecionados.
5.8.8 Relatórios de casos de testes bloqueados, com falha e não
executados
Estes relatórios mostram todos os casos de testes bloqueados, com falha e não
executados atualmente. A lógica do “Resultadodo último teste” (o que é descrito acima
em Métricas gerais dos planos de teste) é novamente empregada para determinar se um
Caso de Teste deve ser considerado bloqueado, com falha ou não executado. Relatórios
de casos de teste bloqueados ou com falha exibirão os Bugs associados se o usuário
estiver usando uma abordagem de bug integrada no sistema de monitoramento.
5.8.9 Relatório de Testes
Ver status de cada casos de teste em cada Baseline. Se um Caso de Teste foi executado
várias vezes na mesma Baseline, o resultado da mais recente execução será utilizado. É
recomendado exportar este relatório no formato Excel para facilitar a navegação se um
grande conjunto de dados está sendo usado.
5.8.10 Gráficos
Esta página de relatório requer que o navegador tenha um plugin flash. A lógica do
“Resultado do último teste” é usada para os quatro gráficos que você verá. Os gráficos
estão animados para ajudar o usuário visualizar as métricas do plano de teste atual. Os
quatro gráficos fornecidos são:
1. Gráfico de pie com a visão geral do que passou/falhou/bloqueou e não executado
nos casos de testes;
2. Gráfico de barras com os resultados por palavra-chave;
3. Gráfico de barras com os resultados por proprietário;
4. Gráfico de barras com os resultados por nível superior de Suite.
Automação de Testes
57
As barras, no gráfico de barras, são coloridas para que o usuário possa identificar o
número aproximado dos casos que passaram, falharam, bloqueados e não executados.
Ele utiliza tecnologia flash fornecidas por http://www.maani.us apresentando os
resultados em um Formato gráfico.
5.8.11 Total de Bugs para cada caso de teste
Esse relatório mostra cada caso de teste com todos os Bugs associados a ele para todo o
projeto. Este relatório está disponível somente se o Sistema de Bug Tracking estiver
conectado.
5.8.12 Como adicionar um novo relatório
Copie um dos atuais relatórios e modifique-o de acordo com a sua necessidade.
Não se esqueça que usamos modelos de renderização
(<testlink_root>/gui/templates/<report_name>.tpl) e lógica
(<testlink_root>/lib/resultados/<report_name>.php).
Recomendamos reutilizar as funções existentes para colher dados para o relatório, ao
invés de criar novas. Editar <testlink_root>/lib/resultados/resultsNavigator.php para
adicionar um link para o seu novo relatório.
Existe um array que poderia ser facilmente melhorado. Você deve adicionar uma nova
URL e “nome da palavra-chave” do relatório.
Você pode modificar o estilo CSS de um relatório. Sugerimos criar novas classes, em
vez de modificar os atuais (para evitar alterações indesejadas em outras páginas). Se
você contribuir, seu(s) novo(s) relatório(s) através do nosso tracker, você pode
encontrá-lo também nas próximas versões… Caso contrário, corre o risco de que não irá
trabalhar para a próxima versão principal.
5.8.13 Administração de usuários
Configurações da conta
Cada usuário do sistema será capaz de editar suas próprias informações através da
Conta configurações da janela (link “Personal” na barra de menu).
O TestLink permite usuários, com direitos de administrador, de criar, editar e excluir
usuários dentro do sistema. No entanto, TestLink não permite que os administradores
visualizem ou editem senhas do usuário. Se os usuários esquecem suas senhas, há um
link, na tela de login, que irá enviar suas senhas utilizadas com base em seu nome de
usuário e endereço de e-mail que entrou.
Permissões dos papéis
Automação de Testes
58
O TestLink é construído com 6 diferentes níveis de permissão padrões. Alterando esses
direitos de manipulação pelo link de administração do usuário que pode ser acessado
pelo administrador. Estes níveis de permissão são os seguintes:
Guest: Um guest só tem permissão para visualizar casos de testes e métricas do projeto.
Executor de teste: Um testador fora da empresa que só tem permissões para executar
testes atribuídos a eles.
Teste Designer: Um usuário pode funcionar completamente com especificação de testes
e requisitos.
Analista de Testes: Um testador pode ver, criar, editar e excluir casos de testes, bem
como executá-los. Faltam testadores para as permissões de gerir planos de testes, gerir
projetos de testes, criar marcos ou ceder direitos. Inicialmente testador, testador sênior.
Líder de teste: Um líder tem todas as permissões como um testador, mas também as
capacidades de ganho para gerir planos de testes, atribuir direitos, criar marcos e
gerenciar palavras-chave.
Admininstrator: Um administrador tem todas as possíveis permissões (líder plus com a
capacidade de gerenciar projetos de testes e usuários). Nota:as necessidades de planos
de testes são relacionadas com características de também atribuir um Plano de Teste
para estar disponível. Veja Atribuição de Plano de Teste.
Funções de usuário
Há papéis pré-definidos de usuários. O administrador tem a capacidade adequada de
alterar os dados dentro do TestLink. Cada usuário tem atribuído apenas um desses
papéis. Se você ver a tabela você verá linhas para cada um dos níveis de permissões
(guest, testador, testador sênior, líder, administrador). A segunda coluna contém todos
os direitos dos diferentes níveis que serão definidos abaixo. Estes níveis foram
determinados como norma para o uso, mas eles podem ser editados para definir novas
funções (por um administrador experiente). A tabela do usuário contém uma chave
estrangeira que aponta para o nível de permissão adequado na tabela dos direitos.
Atribuição de plano de teste
Os usuários podem ver apenas os planos de testes atribuídos. Para ganhar permissões de
Planos de testes um usuário líder ou administrador deve dar-lhes direitos através do link
“Definir direitos de usuário/projeto” dentro de “Gerenciamento de Plano de teste”.
Todos os usuários do sistema, por padrão, não têm permissão para ver planos de testes
recém-criados(exceto para a criação de Plano de testes que podem ser criados por eles
Automação de Testes
59
mesmos). As permissões de Planos de Testes Zero significa que os usuários não verão
nenhum Plano de teste no combobox na tela principal.
Existe uma tabela com os direitos do plano de teste(ou seja, onde os usuários poderão
ver qual Plano de teste). Esta tabela é constituída de uma combinação de id de usuários
e id de projeto. A página principal contém um código que verifica se o usuário efetuou
login nas permissões adequadas (e, em seguida, mostra os projetos permitidos. Não é
recomendado que este seja cortado.
5.8.14 Campos personalizados
As definições de campos personalizados consistem em um sistema amplo, ou seja, não é
possível definir dois campos com o mesmo ID. Depois de ter criado um campo
personalizado, você precisa associá-lo ao Projeto de Teste que você deseja usar. O
campo personalizado foi implementado utilizando uma mistura de funcionalidade dos
modelos Mantis (http://www.Mantisbt.org/) e dotprojetc (http://www.dotprojetc.net/).
Mostrar/Exibir atributos
Mostrar em design: O campo personalizado será exibido durante a especificação
do caso de teste.
Exibido na execução: O usuário será capaz de atribuir/alterar o valor do campo
personalizado durante a especificação do caso de teste: Os campos
personalizados deverão ser exibidos durante a execução do caso de teste.
Permitir em execução: O usuário será capaz de atribuir/alterar o campo
personalizado durante a execução do caso de teste. Os valores atribuídos serão
salvos.
Exemplo 1.
Custom Field: Adicionaritional Notes Type: string applicable to Suites de Teste, to be
edited ONLY during Caso de Teste specification, but useful to be seen during test
execution.
show on design = YES
enable on design = YES show on execution = YES enable on execution = NO
Exemplo 2.
Custom Field: Operating System Type: list
applicable to Casos de Teste, to be edited ONLY during Caso de Teste EXECUTION,
unused during Caso de Teste DESIGN.
show on design =NO enable on design = NO
Automação de Testes
60
show on execution = YES
enable on execution = NO
5.8.15 Importação de dados
A TestLink suporta diversas maneiras de compartilhar dados.
Importação e Exportação de palavras-chave
Exemplo de XML com palavras-chave:
Automação de Testes
61
5.8.16 Importação e exportação de projetos de testes
O usuário pode importar ou exportar projetos de testes incluindo a descrição do projeto,
a especificação de testes e palavras-chave. As próximas duas fotos mostram a árvore de
menu com os dados e os mesmos dados do arquivo XML.
Automação de Testes
62
5.8.17 Importação e exportação de testes de Suites
Exemplo de XML – Teste de Suite dentro de palavras-chave
Automação de Testes
63
Exemplo de XML – Teste de suíte com palavras-chave
Automação de Testes
64
5.8.18 Just one Caso de Teste
Exemplo de arquivo de XML:
5.8.19 Todos os casos de testes no Suite
Automação de Testes
65
5.8.20 Importação/Exportação de requisitos de software
5.8.21 Importando casos de testes para o Excel via XML
Criando arquivo XML para importação no TestLink
Etapa 1: Exportar um ou mais casos de testes do TestLink dentro de um arquivo XML.
Etapa 2: Abrir novo documento em branco spread sheet document file.
Etapa 3: Navegue através do menu Dados> XML> Importação e selecione o arquivo
XML. Cria estrutura adequada em Excel.
Automação de Testes
66
Etapa 4: Depois aparecerá uma caixa de diálogo perguntando “Onde você deseja
colocar os dados?”
Etapa 5: Escolha uma opção “Escolher um XML existente da lista” com a primeira
célula $A$1.
Etapa 6: Você será capaz de ver as seguintes colunas: nome, resumo, etapas e
resultados esperados.
Etapa 7: Copie este arquivo em seus dados nesse sentido e salve o arquivo de dados em
formato XML (*.XML).
Etapa 8: Verifique se o arquivo XML pode ser aberto com a ajuda do internet explorer.
Automação de Testes
67
5.8.22 Importando arquivo XML no TestLink
Etapa 1: Entrar no TestLink > Selecione seu projeto na lista dropdown.
Etapa 2: Clique na Especificação > Criar Nova Suite > Escolha Suite > Clique em
Importar casos de testes.
Etapa 3: Navegue para o arquivo XML, apresente-o e você terá feita a importação.
Automação de Testes
68
Unidade 6
Gerenciando defeitos com Mantis Bug
Tracker
6.1 Gestão de defeitos com Mantis Bug Tracker
6.1.1 Objetivos
O Mantis é uma ferramenta Web de Gestão de defeitos OpenSource, independe de
plataforma (qualquer uma que suporte php4 e banco MySQL), multi-linguagem
(incluindo o português), envio de e-mails, relatório de defeitos, multiusuário, etc.
O principal propósito desta ferramenta é ser uma ferramenta de gestão de defeitos leve e
simples. Também tem as premissas de ter uma navegação simples, sem frames, sem
javascript, sem animações, etc. Isso para garantir a velocidade e leveza desta
ferramenta.
O Mantis roda em praticamente todos os servidores como Windows, Linux, Solaris,
etc., sendo free para uso não comercial e comercial. Ocupa pouco espaço em disco,
sendo 6 MB da instalação e de 10 a 20 MB de espaço para 2 mi de issues com alguns
anexos.
Os pré-requisitos básico para a instalação e funcionamento do Mantis são:
PHP 4.0.6 ou superior;
Banco de Dados (MySQL ou PostgreSQL);
Servidor Web (apache ou IIS).
O download do Mantis pode ser feito em: http://www.Mantisbt.org/download.php
Com ele você pode configurar e administrar todas as informações necessárias para que
possa ser clara a que projeto a issue está relacionada (então podem ser criados projetos,
subprojetos, versões, campos personalizados, etc.).
É utilizada em diversas empresas para gestão de defeitos.
6.1.2 Instalação da ferramenta
1) Efetuar o download da ultima versão em www.Mantisbt.org/download.php . >>
Descompactar o arquivo no servidor Apache: C:\wamp\www .
Automação de Testes
69
2) Clicar no .Rar e descompactar os arquivos dentro da pasta C:\wamp\www .
3) Utilizando o WampServer, vá em PHPMyAdmin e crie um banco de dados com
o nome de Mantis.
4) Execute a aplicação via http://localhost/
5) Na janela Pre-Installation Check, preencha os campos username com 'root' e o
campo password fica nulo.
6) Deixe os valores default nos demais campos. <Altere nome do banco>
7) Pressione o botão Install/Upgrade Database.
8) Abra o seu navegador e acesse o seguinte endereço:
(http://localhost/mantis/login_page.php).
9) Faça o login com o usuário padrão (administrator/root). Lembre-se de mudar a
senha deste usuário.
10) Caso você prefira utilizar esta ferramenta com todos os textos traduzidos para a
língua portuguesa, então siga os passos descritos abaixo:
11) Faça o login normalmente com o seu usuário e senha.
12) Clique no menu “My Account” e então selecione a opção “Preferences”.
13) No campo Language selecione a opção "portuguese_brazil".
14) Pressione o botão "Update Prefs".
6.1.3 Login no Mantis
Entrando com username administrator e password root já estaremos no Mantis. Se
uma conta não existir, estiver desabilitada ou com a senha incorreta podemos recuperar
a senha, por exemplo, pelo link Lost your password. Podemos configurar a o cadastro
de usuários diretamente na tela de login, pelo link <> podemos remover o link de
cadastro de usuário da página de login ou mesmo habilitar uma conta anônima.
Automação de Testes
70
Para cadastrar uma nova conta de acesso precisamos informar um e-mail válido e um
único nome de usuário. O e-mail servirá para receber informações sobre as issues.
Assim que um novo cadastro é feito uma senha randômica é criada e enviada para o
usuário, que será trocada logo após o primeiro acesso.
6.1.4 Página inicial
Acessamos a página principal logo após o login, Nela podemos ver as ultimas notícias
cadastradas dentro do próprio Mantis, a data e hora de ultimo acesse o total de Bugs
abertos e “relatados por mim” (no caso vocês). Este dois últimos itens são clicáveis,
onde o Mantis efetua um filtro exibindo quais são estas issues.
6.1.5 Criando um novo projeto
Tão logo o Mantis seja instalado e configurado, a sua primeira ação deverá ser cadastrar um
novo projeto para que seja possível cadastrar Bugs e utilizar as demais funcionalidades.
Para tal tarefa, você deverá clicar no menu “Manage” e então selecionar a opção “Manage
Projects”. A página “Adicionar Project” deverá ser exibida, conforme o exemplo
apresentado na figura abaixo.
Automação de Testes
71
Nesta página você poderá fornecer diversas informações sobre o projeto, como por
exemplo: o Nome do projeto, Status, Descrição do projeto entre outras informações. Uma
vez que o projeto for cadastrado, você poderá selecioná-lo na lista de projetos existentes e
inserir informações adicionais, tais como: SubProjetos, Categorias, Versões, Campos
Personalizados, Usuários do projeto, entre outras informações conforme o exemplo
apresentado na figura abaixo..
Automação de Testes
72
6.1.6 Criando e modificando um bug
Para registrar (cadastrar) um bug no Mantis, você deverá clicar no menu “Report Issue”. A
página “Enter Report Details” deverá ser exibida. Nesta página você deverá preencher os
campos de acordo com o comportamento do bug encontrado. Se for necessário você poderá
anexar alguma imagem ou arquivo para auxiliar o entendimento e evidenciar a existência do
bug. O Mantis oferece também a opção de registro de Bugs por meio de uma página
avançada “Advanced Report”. A página “Advanced Report” exibe novos campos de
preenchimento. Esta página é usada normalmente por usuários mais experientes que
conseguem fornecer mais detalhes sobre o bug encontrado.
Automação de Testes
73
Se for necessário você poderá ver a lista dos Bugs existentes. Para tal tarefa, você deverá
clicar no menu “View Issues”. A página “Viewing Issues” deverá ser exibida. Esta página,
por default, lista todos os Bugs abertos. No entanto, você poderá configurar filtros
específicos conforme a sua necessidade com base nos campos de filtragem exibidos na parte
superior desta página. O Mantis também permite que você salve o filtro para posterior
utilização.
Automação de Testes
74
É importante ressaltar que os Bugs listados são apresentados em diferentes cores. Cada cor
significa o status do bug conforme a legenda apresentada na parte inferior desta página você
poderá clicar sobre qualquer bug da lista a fim de abrir a página “Viewing Issue” e
modificar qualquer informação relacionada ao bug.
Automação de Testes
75
Uma vez dentro desta página, além de modificar as informações do bug, você poderá criar
uma associação de relacionamento com outros Bugs (relacionado a, filho de, pai de, etc) e
também poderá selecionar a opção para monitorar o bug e receber um e-mail sempre que
alguma informação for modificada.
6.1.7 Meus Bugs
O Mantis oferece uma página onde você poderá visualizar de forma resumida e consolidada
todos os Bugs. Para visualizar esta página, você deverá clicar no menu “My View”.
Basicamente, esta página exibe os Bugs registrados, atribuídos e monitorados por você.
Além dessas informações, você poderá também visualizar os Bugs recentemente
modificados, Bugs que não foram atribuídos e assim por diante, como pode visto no
exemplo apresentado na Figura 28. De qualquer maneira, caso seja necessário, você poderá
modificar os filtros default usados para exibir as informações nesta página por meio do link
“[^]” existente em cada seção.
Automação de Testes
76
6.1.8 Sumário dos Bugs
O Mantis oferece uma página onde você poderá visualizar o sumário de todos os Bugs
registrados. Para tal tarefa, você deverá clicar no menu “Summary”. Nesta página, você
poderá visualizar o sumário dos Bugs, gerar relatórios e gráficos com estatísticas.
Automação de Testes
77
6.1.9 News
O Mantis também oferece uma funcionalidade para a divulgação de notícias “Novos”. Por
meio desta funcionalidade, você poderá registrar qualquer novidade ou aviso aos demais
usuários do Mantis. Para tal tarefa, você deverá clicar no menu “News”. A página “Add
News” deverá ser exibida. A notícia registrada poderá ser vista na página principal do
Mantis.
Automação de Testes
78
6.1.10 Change Log
Por meio do Change Log, você poderá ver todas as correções associadas a um determinado
release (versão). Para visualizar o Change Log, você deverá clicar no menu “Change Log.
Automação de Testes
79
6.1.11 Documentação do projeto
Outra funcionalidade interessante é a possibilidade de adicionar a documentação do projeto
no Mantis. Para realizar tal tarefa, você deverá clicar no menu “Docs” e fazer o upload dos
documentos.
Automação de Testes
80
6.1.12 Configuração do Mantis
O Mantis oferece uma série de páginas de configurações que você poderá utilizar para
realizar customizações a fim de atender as suas necessidades. Para tal tarefa, você deverá
clicar no menu “Manage”. Basicamente, esta página exibe as diversas áreas que você
poderá realizar algum tipo de customização tais como: criação de campos personalizados,
gestão de usuários, configuração de workflows, notificação por email, entre outros.
Automação de Testes
81
Unidade 7
Teste de performance, carga e stress com
JMeter
7.1 O que é o JMeter?
O Apache JMeter, é uma aplicação desktop projetada para a realização de testes de
desempenho e estresse em aplicações cliente/servidor, tais como aplicações Web. Ele
pode ser usado para simular cargas de trabalho em um servidor, rede, aplicações ou
mesmo em um objeto, testando sua robustez. O seu desenvolvedor original foi Stefanno
Mazzochi, membro da Apache Software Foundation, mas hoje a ferramenta, que é Open
Source, é resultado do trabalho de milhares de pessoas.
Por ser uma ferramenta inteiramente escrita em Java, o JMeter é compatível com
qualquer ambiente capaz de suportar a máquina virtual Java versão 1.4 ou superior. O
JMeter também permite a criação de testes para diversos protocolos, como HTTP,
JDBC, FTP, SOAP, dentre outros, podendo inclusive ser utilizada para testar objetos
implementados em Java.
Além de poder ser usado para criação e execução de testes de desempenho e estresse, o
JMeter também permite a realização de testes funcionais. Isso é possível graças aos
vários tipos de asserções que ele possui e que podem ser usadas para verificar os
resultados das requisições enviadas ao objeto de teste. Essas asserções aceitam inclusive
expressões regulares, o que lhes agrega mais poder e flexibilidade.
No JMeter, a organização dos elementos que compõe o teste é feita através de uma
árvore hierárquica, cuja raiz é o Plano de Teste (TestPlan). Na Figura abaixo é possível
observar a árvore mencionada. Alguns elementos da árvore de teste são hierárquicos,
como os Listeners (relatórios) e as Assertions (asserções), pertencendo e referenciando a
outros elementos da ordem hierárquica superior. Outros elementos, como os Samplers
(requisições), são primariamente ordenados e, portanto, a ordem na qual aparecem
verticalmente na árvore determina sua ordem de execução.
Automação de Testes
82
Essa organização também é refletida no arquivo XML gerado pela ferramenta para a
persistência dos elementos. Nesse arquivo, cada elemento do script de teste corresponde
a um elemento na estrutura XML.
Automação de Testes
83
Quanto a execução dos testes com o JMeter, ela pode ser feita de duas formas: em uma
máquina só ou de forma distribuída, na qual o esforço do teste é distribuído dentre
diversas máquinas. A partilha do esforço do teste é uma característica muito importante
e muitas vezes necessária para a correta execução dos testes de desempenho e estresse.
É através dela que os testadores podem conseguir uma maior fidelidade na recriação de
cenários de teste, pois com a distribuição da execução do teste entre várias máquinas
evita-se gargalos tanto de processamento quanto de caminhos na rede do sistema sob
teste.
7.2 Instalando o JMeter
1) Acesse o site http://jmeter.apache.org/download_jmeter.cgi para fazer o
download da ferramenta;
2) Descompacte o arquivo em uma pasta de sua preferência;
3) Localize o arquivo “.jar” através do caminho <pasta
jmeter>/bin/ApacheJMeter.jar;
Automação de Testes
84
4) Execute o arquivo “ApacheJMeter.jar” com dois clique, pronto logo se abre a
janela principal.
7.3 Componentes do JMeter
Um Plano de Testes é para o JMeter um conjunto de elementos que descrevem uma
série de passos que serão executados. Assim, um teste bem definido geralmente
incorpora vários componentes do JMeter. Para adicionar, deletar, copiar ou mover um
elemento (componente) de um script de teste, basta clicar com o botão direito do mouse
sobre o elemento e escolher a opção desejada. Um componente também pode "conter"
outro componente.
Nesse caso, diz-se que um é o "filho", o que está a uma hierarquia inferior, e o outro é o
"pai", que está em uma hierarquia superior a do filho e com o qual o filho está ligado.
Na primeira figura exibida nessa unidade, por exemplo, o primeiro "Duration Assertion"
é filho da requisição nomeada de "Login", todos os elementos da mesma hierarquia ou
inferior ao dessa requisição são filhos do Thread Group, que é por sua vez filho do Test
Plan.
O JMeter possui vários componentes que podem ser usados na criação dos testes.
Essa sessão, entretanto, abordará apenas aqueles mais usados e diretamente ligados à
criação e execução de testes automatizados para sistemas Web.
7.3.1 Elementos Básicos
Os elementos denominados aqui como "Básicos", são os componentes do JMeter que
devem estar presentes em todos os testes criados/executados com ele. Os elementos
referidos são:
Test Plan: componente que representa o plano de teste;
WorkBench: é uma espécie de "área de trabalho". Assim, todos os elementos
que forem seu filho não serão executados: eles são utilizados apenas como área
de armazenamento temporário, para a composição do teste;
Thread Group: contém a configuração do grupo de usuários virtuais, onde cada
usuário corresponde a uma thread que é lançada e controlada pelo JMeter e que
simula a navegação do usuário na aplicação sob teste.
Os dois primeiros elementos citados anteriormente estão presentes no script de teste
desde o momento em que o JMeter é iniciado. Já o Thread Group deve ser adicionado
manualmente. A primeira ação a ser feita após a adição do Thread Group é configurar o
Test Plan, ilustrado abaixo.
Automação de Testes
85
Nele é possível definir um nome identificador para o Plano do Teste, adicionar
comentários, criar variáveis globais, que são visíveis por todas as requisições do plano
de teste em questão, além de permitir a definição de parâmetros ou comportamentos
comuns a todos os testes. Além disso, o Test Plan contém duas caixas de seleção
(checkbox):
"Functional Testing", que se selecionada faz com que o JMeter grave os dados
retornados do servidor para cada requisição feita. Essa opção interfere
significamente no desempenho da ferramenta e, portanto, não deve estar
marcada no caso de um teste de desempenho ou estresse.
"Run each Thread Group separately", com o qual pode-se definir se os grupos de
usuários virtuais serão executados simultaneamente ou sequencialmente.
Automação de Testes
86
Como supracitado, o Thread Group, ilustrado na próxima figura, representa um grupo
de usuários virtuais. Podemos ter vários Threads Groups ligados ao Test Plan, e todos
os outros elementos, com exceção do WorkBench, devem ser adicionados como filho de
algum Thread Group.
Na criação de testes com o JMeter, após configurar o Test Plan, o testador deve
configurar o Thread Group, ou seja, deve definir suas propriedades.
"Number of threads": o número de threads que executarão os testes, ou seja, o
número de usuários virtuais. Cada thread irá executar o plano de teste de forma
independentemente das outras threads que estão executando, por isso threads
múltiplas são usadas para simular conexões concorrentes na aplicação sob teste;
"Ramp-Up Period": define a frequência de lançamento das threads. Se forem
definidas 10 threads e um ramp-up de 100s, então o JMeter levará 100s para
iniciar todas as threads, ou seja, uma thread será iniciada a cada 10s.
"Loop Count": define quantas vezes o plano de teste será executado. Logo, caso
seja marcado o checkBox "Forever", o teste entrará em execução infinta e o
valor definido no Loop Count será desconsiderado.
"Scheduler": através do qual pode-se definir um horário para o início e término
da execução dos testes. Ao contrário das citadas anteriormente, a configuração
dessa propriedade é opcional.
Automação de Testes
87
7.3.2 Sampler
Samplers são componentes que representam cada requisição que o JMeter fará ao
servidor quando o plano de teste for executado. No caso de um sistema Web, cada
operação ou mudança de página corresponde a uma requisição. O JMeter contém vários
tipos de Samplers, como por exemplo, Requisições FTP, Requisições HTTP,
Requisições JDBC, dentre outros. Cada Sampler contém várias propriedades que podem
ser configuradas. Como o objetivo deste artigo é apresentar a automação de testes de
desempenho e estresse para aplicações web, apresentamos a seguir apenas a requisição
HTTP.
HTTP Request
O HTTP Request permite o envio de requisições HTTP/HTTPS ou arquivos para um
servidor Web. Na figura abaixo apresentamos um exemplo de um HTTP Request
adicionado a um Plano de Teste.
Dentre as propriedades desse elemento podemos destacar:
"Name": o nome da requisição;
"Server": URL ou endereço ip do servidor Web;
Automação de Testes
88
"Port": a porta a ser usada. Por default ela já está configurada como 80.
"Protocol": define se a requisição é HTTP, HTTPS or FILE (para enviar arquivo
ao servidor);
"Method": define o método de submissão dos dados. Os principais métodos são
o GET, no qual os dados são enviados na própria URL, e POST, onde os dados
são enviados "ocultamente"na requisição, ou seja, não são visíveis na URL;
"Path": o path da página testada;
"Send Parameters With the Request": no qual adicionamos todos os parâmetros
e os seus respectivos valores para serem enviados junto com a requisição;
7.3.3 Logic Controllers
Os Logic Controllers são usados para alterar a execução do plano do teste. Com eles é
possível, por exemplo, selecionar qual requisição será enviada dentre um conjunto de
requisições, repetir a execução de requisições e executar requisições somente sob certas
condições. Serão apresentados aqui os principais controladores lógicos: "Simple
Controller", "Loop Controller", "Once only Controller", "Interleave Controller" e "If
Controller".
Simple Controller
Os Simple Controllers são elementos que não causam nenhuma alteração na execução
dos testes, sendo utilizado somente para organizar a árvore do plano de teste. Com ele o
usuário pode agrupar Samplers e outros elementos de forma a deixar o teste mais
organizado e inteligível. Uma ilustração dessa situação pode ser visualizada na imagem
abaixo, onde três Simpler Controller são usados para agrupar as requisições de forma a
permitir a fácil identificação de quais delas são executadas em cada um dos dois casos
de uso, Login ou Usuario, do sistem sob teste.
Automação de Testes
89
Loop Controller
O Loop Controller , imagem abaixo, é o componente no qual é possivel determinar
quantas vezes um certo grupo de requisições deve ser executado. Esse elemento atua
independentemente da propriedade "Loop Count"do Thread Group. Assim, se o plano
de teste foi configurado para ser executado três vezes e existe uma "requisição A"que
está como filho de um Loop Controller configurado para ser executado 2 vezes, então a
requisição em questão será executada 3 * 2 = 6 vezes.
Automação de Testes
90
Once Only Controller
O Once Only Controller, ilustrado na figura abaixo, permite que as requisições
controladas por ele, assim como seus filhos, sejam executados uma única vez por cada
thread. Dessa forma, a requisição que está sobre o efeito desse elemento só será
executada na primeira iteração do teste. Testes que requerem um único login para
estabelecer a sessão podem ser criados utilizando uma requisição que faça o login como
filho de um Once Only Controller.
Assim, o login só é executado apenas uma vez por cada thread.
Interleave Controller
O Interleave Controller é usado para alternar entre seus filhos a cada iteração, com base
na ordem em que eles estão dispostos. No exemplo ilustrado na próxima imagem,
apresentamos um teste que foi configurado para iterar duas vezes, tendo a seguinte
sequência de execução: Requisição A, Requisição B, Requisição A, Requisição C.
O JMeter também possui o Random Controller, que é similar ao Interleave Controller.
A única diferença entre eles é o fato desse não alternar entre as requisições com base na
ordem em que foram colocadas. O Random Controller simplesmente escolhe
aleatoriamente um dos seus filhos a cada iteração.
Automação de Testes
91
If Controller
Com o If Controller é possível colocar uma condição que será avaliada para definir se o
seu filho vai ser executado ou não. No exemplo ilustrado na figura abaixo, a "requisição
A"só será executada se a variável "var"tiver valor menor que 10. É importante observar
também como é feita a referência a variáveis no JMeter: devemos utilizar o nome da
variável (var) entre chaves e precedida de cifrão ($).
7.3.4 Listeners
Para visualizar os resultados dos testes é necessário adicionar um Listener ao plano de
teste. Os Listeners capturam os dados das informações durante a execução dos testes e
criam relatórios e gráficos com os resultados obtidos. Além de exibir os resultados, os
listeners também possibilitam a geração de um arquivo, que pode ser inclusive uma
planilha eletrônica, contendo tais resultados. Existem vários tipos de Listeners, mas
apenas três serão abordados a seguir : "View Results Tree", "Assertion Results" e
"Graph Results".
View Results Tree
O View Results Tree é um listener que mostra uma árvore com as respostas de todos os
samplers, permitindo assim que o testador veja o resultado de cada sampler que foi
executado.
Através dele, o usuário também toma conhecimento do tempo gasto para obtenção da
resposta, além de outras informações associadas à requisição, como por exemplo, a
URL acessada e os parâmetros enviados. Esse elemento também permite visualizar o
resultado de várias formas diferentes, como por exemplo, no formato texto, HTML ou
XML. A figura abaixo ilustra a utilização desse listener. A partir da figura podemos
observar que esse Listener é ideal para visualizar o que exatamente o usuário final
deveria de acordo com cada requisição.
Automação de Testes
92
Assertion Results
O Assertion Results permite uma visualização do resultado das asserções que falharam.
Além de indicar qual requisição teve falha na asserção, ele indica qual asserção falhou
(Response ou Duration), e o porquê da falha. No exemplo ilustrado na figura abaixo,
por exemplo, ele mostra que o Response Assertion da "requisição A"falhou, pois ele
procurou pela palavra "teste"e não a encontrou na página resultante da execução dessa
requisição.
Automação de Testes
93
Graph Results
O Graph Results, ilustrado na figura abaixo, gera um gráfico que plota os tempos de
todas as requisições, o desvio padrão, a média e a taxa de requisições realizadas por
segundo. O testador tem a possibilidade de optar por quais desses dados ele quer
visualizar no gráfico e esse Listener, assim como os outros, permite a indicação de um
arquivo para exportar a visualização gerada.
7.3.5 Configurations Elements
Os Configurations Elements são elementos que podem adicionar ou modificar dados das
requisições. Os principais Configurations Elements utilizados em testes para aplicações
Web são o "HTTP Cookie Manager", usado para manter a sessão, e o "HTTP Request
Defaults", para definir o servidor que será usado por todas as requisições HTTP da sua
hierarquia ou inferior.
Automação de Testes
94
HTTP Cookie Manager
Esse elemento, ilustrado na figura abaixo, pode ser usado de duas formas: sem
preencher nenhum valor ou configurando o Cookie manualmente. No primeiro caso,
esse componente guarda e envia os cookies como um browser e atua como se houvesse
um Cookie Manager para cada thread. Isso quer dizer que após o JMeter receber a
resposta de uma requisição, se ela contiver um cookie, esse será armazenado e enviado
para as próximas requisições para o mesmo site. Já no segundo, quando o testador
adiciona manualmente um cookie, o Cookie Manager servirá para compartilhar o
mesmo cookie entre todas as threads.
HTTP Request Defaults
Esse elemento permite a definição de propriedades para serem utilizados por todas as
requsisições HTTP da sua mesma hierarquia ou e, uma hierarquia inferior. Se um teste
contiver, por exemplo, 30 requisições para um mesmo site, então elas provavelmente
acessarão o mesmo servidor. Assim, ao invés de definirmos em cada HTTP Request o
servidor, colocamos o endereço do servidor apenas no HTTP Request Defaults,
ilustrado na figura abaixo, restando às HTTP Requests definir apenas os path e os
parâmetros das páginas testadas.
Automação de Testes
95
7.3.6 Assertions
Os Assertions permitem a validação das respostas recebidas do servidor que está sendo
testado. Com as assertions, o testador obtém a certeza de que a aplicação está
retornando o resultado esperado. Isso porque ela faz com que o JMeter procure
determinado texto dentro do conteúdo retornado de uma requisição. Se o texto não for
encontrado a asserção falhará. Em testes para servidores Web, duas assertions são muito
utilizadas: "Response Assertion"e "Duration Assertion".
Response Assertion
O Response Assertion faz com que o JMeter procure por um determinado texto,
definido pelo testador, na requisição obtida como resposta. A procura por esse texto é
feito utilizando-se o sistema de expressão regular presente na ferramenta. Caso o texto
não seja encontrado, a asserção falhará e aparecerá no Assertion Results em vermelho,
aparecendo destacado no View Results Tree, caso esses elementes estejam adicionados
a um plano de teste. Na figura abaixo , por exemplo, temos uma Response Assertion
que possui um único objetivo, que é encontrar a palavra "teste"na reposta da requisição
a qual ele está associado.
Automação de Testes
96
Duration Assertion
O Duration Assertion, ilustrado na figura abaixo, é usado para definir o tempo máximo
que o sistema tem para responder a uma requisição. Caso a obtenção da resposta demore
mais que o tempo definido, a asserção falhará. Essa assertion é muito utilizada, pois a
partir dela podemos verificar o atendimento a um dos principais requisitos de
desempenho: o tempo de resposta das requisições.
7.3.7 Timers
Por default, o JMeter envia as requisições das threads sem pausar um tempo entre elas.
Isso significa que as requisições serão disparadas rapidamente, uma seguida da outra.
Como os usuários sempre analisam os resultados obtidos antes de executar a próxima
ação, Timers devem ser usados para simular paradas entre as requisições, tornando-as
mais realistas. Existem vários tipos de timers, mas para simplificar, apresentamos aqui
apenas o mais simples deles, o "Constant Timer", ilustrado na figura abaixo. Esse timer
define o tempo em milisegundos que cada thread deve aguardar entre as requisições.
Automação de Testes
97
7.3.8 Pre-Processors
Um Pre-Processor é um elemento que executa certas ações antes da requisição ser
enviada.
Eles são utilizados para modificar características ou atualizar valores de variáveis das
requisições antes que estas sejam executadas. Dentre os Pre-Processors disponíveis
temos o Counter, ilustrado na figura abaixo, que representa um contador que pode ser
referenciado em qualquer lugar do Plano de Testes. Ele pode ser usado, por exemplo,
para colocar um valor único em um certo campo em cada iteração. Para isso, basta
colocar como valor desse campo uma string qualquer seguido da referência à variável
que contém o valor do contador, o "Reference Name"do contador. Suponhamos, por
exemplo, que temos como parâmetro de uma requisição, um campo com nome "login",
cujo valor deve ser único toda vez que essa requisição for executada. Uma possível
solução seria acrescentar um contador, definir suas propriedades (valor inicial, vamor
máximo, incremento, nome da variável) e colocar "login${cont}", onde "cont"é o nome
da variável do contador, como valor do campo "login".
Automação de Testes
98
7.3.9 Post-Processors
Um Post-Processor é um elemento que executa uma ação depois que uma requisição é
executada. Geralmente eles são utilizados para processar os dados recebidos da
requisição e os seus resultados são utilizados para modificar as requisições seguintes.
Dentre os Post-Processors, destacamos o Regular Expression Extractor, ilustrado na
figura abaixo, que permite ao testador extrair valores da resposta proveniente do
servidor a partir de expressões regulares.
7.4 Criando testes de desempenho e estresse
automatizados
Esta sessão tem por objetivo apresentar um pequeno exemplo de utilização da
ferramenta para a automação de testes de desempenho e estresse de um sistema Web. O
objeto de teste referido é uma parte de um gerador (sistema) de páginas Web para
usuários leigos.
A função desse gerador é tornar simples a criação de páginas, seguindo um formato pré-
estabelecido.
Os usuários do sistema podem criar menus laterais, notícias, destaques, usuários para
administrar as páginas e links para outras páginas e arquivos. Esse sistema possui no
total 8 casos de uso, mas iremos abordar aqui apenas o caso de uso Usuários, que
corresponde as operações de inclusão, alteração, busca e remoção de um usuário desse
sistema.
Para iniciar a criação desse teste, primeira coisa a ser feita é a inserção do Thread Group
e configuração do nosso Test Plan. Com base nos requisitos definidos para esse sistema,
configuramos o teste para 100 usuários simultâneos a serem disparados em 50
segundos. Também colocamos o teste para repetir por três vezes, para assim
confirmarmos os padrões de comportamento do sistema, como por exemplo, a
identificação de que certa operação sempre demora mais que o esperado. Para
mantermos o teste organizado adicionamos quatro Simpler Controllers, cada um
nomeado com a operação cujas requisições filhos irão realizar. O resultado pode ser
visualizado na figura abaixo.
Automação de Testes
99
Em seguida, adicionamos os listeners, o View Resulsts in Tree e o Graph Results.
E como os testes seriam todos para um mesmo servidor, acrescentamos também o
HTTP Request Defaults, configurando-o com o endereço do servidor que será testado e
o HTTP Cookie Manager, pois para acessar o sistema é preciso logar e é necessário
manter a sessão do usuário logado para permanecer no sistema. O estado do Test Plan
com essas cofigurações é ilustrado na figura abaixo.
Por fim, basta colocar as requisições que realizam as operações, bem como as asserções
para verificar o atendimento aos requisitos de desempenho. Primeiro criamos a
Automação de Testes
100
requisição "Login", cuja função é fazer o usuário virtual logar na página. Como já
tínhamos configurado o HTTP Request Default, só precisamos agora definir o path e os
parâmetros da página testada, que no caso da requisição "Login"são os campos login e
senha.
Existem características importantes que devem ser observadas nesse ponto. Em primeiro
lugar, o path supracitado não é qualquer path do sistema. O path em questão é o path
que tratará os dados provenientes da requisição. Logo, para a configuração correta,
muitas vezes é necessário olhar o código-fonte da página ou algum documento que
tenha toda a configuração dela, a fim de descobrir qual página receberá aqueles dados.
Na página de login do usuário, por exemplo, verificamos que a página que trata os
dados é a própria página que os recebe. Assim, o path dessa requisição é o mesmo path
onde o usuário insere os dados. Isso pode ser facilmente visualizado através do código-
fonte da página onde o usuário insere o login e a senha, ilustrado na próxima figura.
Nele observamos que a ação do formulário que recebe o login e a senha está em branco,
concluindo então que ela própria recebe e trata o login e a senha.
Outro detalhe que merece ser mencionado está relacionado aos re-direcionamentos de
alguns sistemas Web. No sistema utilizado neste trabalho, por exemplo, quando o
usuário efetua a operação de login, o sistema redireciona para a mesma página, se o
login falhar, ou para a página principal caso o login seja bem sucedido. O problema é
que se a opção Follow Redirects não estiver marcada, o JMeter não "seguirá"esse
redirecionamento e, portanto, continuará na mesma página para o qual os dados foram
enviados. Assim, devemos desmarcar a opção Redirect Automatically, que não segue os
re-direcionamentos que vem como resposta de uma requisição, e marcar a opção Follow
Redirects.
Além disso, devemos colocar como método de submissão aquele utilizado pela página
(GET,POST,...) e adicionar os parametros necessários. No nosso exemplo, a partir do
código-fonte, ilustrado na fugura anterior, identificamos que o método utilizado é o
POST e observamos que os campos necessários não eram somente "login"e "senha".
Automação de Testes
101
Para o correto funcionamento da requisição é necessário colocar também o campo
"enviado".
Isso porque os campos hidden são usados pela página para identificar a submissão de
dados, logo são campos necessários para a execução da operação requisitada. Nesse
caso devemos preencher os valores respectivos dos campos login e senha, colocando
também o valor do campo "enviado"como sendo o valor definido na sua propriedade
value, ou seja, o valor "ok". Como resultado de todas essas configurações, o login foi
bem sucedido, como é visto na figura abaixo.
Como basta um login para cada usuário virtual, colocamos a requisição de login como
filho do controlador Once Only Controller. Continuando a automação do teste,
inserirmos uma Response Assertion, para nos certificarmos que a página alvo foi
alcançada e um Duration Assertion, para medirmos o tempo gasto para responder a essa
requisição.
Por último, devemos criar as outras requisições seguindo os mesmos passos:
descobrindo o path, colocando os campos, o método, adicionando um duration e um
response assertion.
Feitas todas as requisições, notamos que algumas asserções da requisição de Inserção de
Usuário falhavam. Observamos então que isso acontecia porque na inserção de Usuário
o campo "login", que nesse caso era o nome de login do usuário, deveria ser único para
cada usuário. Adicionamos então um Count, e modificamos o valor do campo login para
usuario${cont}, em que "cont"é o nome da variável que contém o valor do contador.
Isso significa que durante a execução desses testes estamos inserindo usuários com os
logins usuario1, usuario2, usuario3, etc, ou seja, criaremos um login único para cada
Automação de Testes
102
usuário. Feito isso, temos agora um teste automatizado de desempenho e estresse para o
caso de uso Usuário, teste esse visualizado na figura abaixo.
Além da construção dos testes, a análise dos seus resultados é importante para se
identificar as áreas críticas do sistema. Os resultados da execução do nosso exemplo, em
forma de gráfico, podem ser visualizados na próxima imagem. Com esses dados, aliados
aos resultados exibidos no View Results Tree, adicionado ao plano de teste, podem ser
utilizados pelo testador para avaliar sobre o atendimento da aplicação aos requisitos de
desempenho existentes.
Automação de Testes
103
Automação de Testes
104
Unidade 8
Teste funcional com Badboy
Uma ferramenta para automação de testes fácil de usar. O aplicativo grava tudo o que o
usuário faz na página web como requisições, parâmetros, alerts, etc.. É possível alterar
parâmetros das páginas que estão sendo testadas, efetuar asserções por texto (simples ou
HTML). A seguir, abordaremos a estrutura básica do BadBoy e suas principais
funcionalidades.
8.1 Como instalar o BadBoy?
Acesse o site da ferramenta através do endereço: http://www.badboy.com.au/. A figura
apresenta a página principal do aplicativo, veja:
No menu à esquerda, clique em DOWNLOAD para baixar o software. Nesta primeira
parte, a página da ferramenta Badboy informa aos usuários, que a mesma está
Automação de Testes
105
disponível gratuitamente. Mas, é necessário verificar o contrato de licença antes de
baixar o aplicativo.
O Cadastro para baixar o software é solicitado, mas toda a informação é opcional, você
poderá pular esta etapa clicando no botão (Continue >>).
Atenção: Esta etapa é opcional.
O download da versão 2.1.3 é recomendado para novos usuários. Mas, você pode optar
por baixar versões mais antigas que estão mais estáveis, ou ainda, as versões beta que
têm características melhores, mas não são tão bem testado. Abaixo as versões que se
encontram disponíveis:
Automação de Testes
106
Ao clicar no link “Download”, a janela exibida na figura abaixo abrirá
automaticamente, observe:
O próximo passo é clicar novamente no botão <Download> para baixar o arquivo de
instalação do aplicativo. Na sequência, o usuário visualizará um feedback (retorno da
informação) de que o software está sendo salvo em um diretório do seu computador.
Normalmente, os arquivos são direcionados para a pasta Downloads, no caminho
“C:\Downloads”.
Automação de Testes
107
Para prosseguir com os procedimentos de instalação, clique duas vezes no arquivo
“BadboyInstaller-2.1.3.exe”.
Caso você estiver baixando o software através do Sistema Operacional – Windows, a
janela será mostrada na tela:
A figura abaixo apresenta a tela em que o usuário deve aceitar a licença da ferramenta
BadBoy para fazer uso das funcionalidades do software. Para continuar com a
instalação, clique no botão em destaque abaixo:
Automação de Testes
108
A próxima imagem exibe o caminho em que a ferramenta está sendo salva, bem como o
diretório que conterá o arquivo executável:
Ao clicar no botão <Install>, o usuário visualizará a janela que mostra a extração dos
arquivos do software.
Em seguida, abre-se uma tela perguntando ao usuário se o sistema pode adicionar o
aplicativo aos Programas do seu computador.
Automação de Testes
109
Para finalizar a instalação da ferramenta BadBoy, clique no botão <Close>.
Caso a ferramenta não abrir automaticamente após você finalizar a instalação, acesse
menu >> Todos os programas, e selecione o programa BadBoy, conforme o ícone em
destaque:
Essa será a tela principal a ser exibida:
Automação de Testes
110
8.2 Conhecendo o BadBoy
8.2.1 Gravando
Como o Badboy trabalha no conceito de Record-and-Play (gravar e executar), você
percebe que logo que iniciamos o programa o modo gravação já está ativo, a fim de
capturar todas nossas ações nas iterações das páginas web.
Podemos ativar ou desativar a gravação pelo botão Record:
Automação de Testes
111
Sabemos que o mesmo está ativo quando o botão é pressionado ou quando há a
palavra recording no título do programa como na imagem acima.
Então sempre que você quiser parar uma gravação é necessário clicar sobre o botão
Record ou sobre o botão Stop Playing conforme abaixo:
8.2.2 Criando testes
Aqui no badboy há distinção entre Test Suite (Suite de Teste), Test (Teste) e Step
(passo). Essa separação facilita no agrupamento de funcionalidades.
Um Test Suite é a maior é o maior na hierarquia, sendo de certo modo o nosso caso
de teste, agrupando diversos Tests e diversos Steps.
Um Test pode ser utilizado como um agrupador de funções executadas cque possuam
relação entre si, como por exemplo, “Efetuar login” sendo que cada Test pode ter uma
ou mais iterações.
Um Step é uma ação do sistema, geralmente cada ação de requisição é tratado como
um passo. Por exemplo: toda vez que clicamos e algo, seja um botão ou link numa
página web ele gera uma requisição.
Assim que entramos no Badboy a estrutura básica da Árvore de Script, exibe a
organização como Test Suit, Test e Step:
8.2.3 Árvore do script
A árvore exibe toda a iteração que temos no sistema web, o qual estamos executando.
Automação de Testes
112
A figura acima mostra um script que foi criado para pesquisar o site da Alfamídia no
site Google.
Executando
Para executarmos os scripts de testes tremos de utilizar os botões localizados na barra de
ferramentas, ou clicando com o botão direito sobre o Test Suite, Test, ou Step desejado.
Automação de Testes
113
Há duas formas de executarmos os scripts: passo-a-passo ou execução contínua.
Para executarmos o passo-a-passo temos de clicar no botão [Play] ou se for execução
contínua temos de clicar em [Play All].
Play executa o conjuntos de Tests (para execução e verficação) do browser, para
seguir com a execução basta clicar em [Play] novamente.
Play All executa todo o script sem esperar pela verificação do browser.
Rewind volta um estado de execução.
Play Single Request executa somente o resquest selecionado.
8.3 Vamos gravar nosso primeiro script?
Abra o badboy, será exibia a tela inicial. Perceba que o botão de [Record] já iniciou em
modo ativado.
Clique duas vezes sobre o item TestSuite1, será exbida a pop-up “Documentation” . No
campo “Name for this item” preencha com <Pesquisando “Alfamídia” no Google>, se
quiser pode inserir uma descrição mais detalhada no campo abaixo deste.
Automação de Testes
114
E Test1 repita o mesmo processo com um nome de sua escolha.
Em Step, clique duas vezes sobre ele, será exbida a pop-up “Documentation” . No
campo “Name for this item” preencha com <Acessando o Google>.
Na barra de URL informe o endereço: www.google.com.br e clique em [Enter]. Uma
request será criada contendo www.google.com.br e uma response associada com o
tempo de carregamento.
Automação de Testes
115
Na barra de ferramentas clique no botão [Create new step] , será criado um novo
step chamado Step2. Altere o nome deste para <Preencher a caixa de pesquisa com
"Alfamídia"> .
Ná página do Google informe “Alfamídia” e clique em [Pesquisa Google]. Uma request
será criada contendo “/search”, juntamente a uma response e vários outros parâmetros.
Crie outro Step e chame-o de < Verificar a existência desta palavra>. Selecione o texto
na ágina do Google conforme abaixo:
Automação de Testes
116
Vá na barra de ferramentas e clique no botão [Create Easy Assertion] . Na árevore
do script de test será criado um item “Check for text”, clique duas vezes sobre ele e
altere o valor de “Action” para <Mark as Failed>.
Essa asserção verificará se existe a palavra “Alfamídia” na página do Google, caso não
existe o badboy marca como falha e continua a execução do script.
Automação de Testes
117
Crie um novo step e coloque seu nome como < Clicar em "Alfamídia">, clique no link
da lista de resultado de busca do Google ode esteja o da Alfamídia. Será criado um
request para o site da Alfamídia.
Na barra de ferramentas clique em [Save] e salve com o nome e local que desejar.
Pronto, gravamos nosso primeiro script.
Automação de Testes
118
8.4 Automatizando o script
8.4.1 Request Mode
Neste método o Badboy registra as solicitações HTTP que são enviados do navegador
para o servidor, incluindo todos os seus parâmetros e outras informações. Em um
sentido simplista, você pode pensar sobre requests simplesmente como URLs, como o
endereço de sua página web. Há vantagens que utilizam este modo:
Requests são independentes do layout e aparência das páginas da web que você
está testando. Isto significa que se o layout das páginas web muda seu teste
continuará a funcionar.
Requests funcionam perfeitamente com Badboy em testes de carga. que também
podem ser exportados para o JMeter para fazer testes de carga e stress. Embora o
Badboy possa carregar páginas de teste usando Navegações, eles não funcionam
tão eficientemente - por isso, se você precisa fazer o teste de carga em níveis
mais elevados, registrando seus testes com requests podem funcionar melhor.
No entanto, existem também algumas desvantagens importantes:
Em alguns casos, os requests podem ser mais difíceis de se trabalhar. Isto
porque os requests substituem completamente as informações enviadas da
página web para o servidor com as informações HTTP gravadas. Às vezes, as
páginas web colocam informações na página que tem de ser especialmente
calculado toda vez que um usuário vai para a página. Nesse caso, os requests
precisam ter seus parâmetros alterados para usar variáveis depois de gravá-los.
Enquanto Requests são independentes do layout e da aparência, às vezes isso
pode ser uma desvantagem. Por exemplo, imagine que você edite uma página e
apague acidentalmente o botão de "logon". Você provavelmente gosta que seu
teste falhe para que você possa encontrar e corrigir o problema. No entanto,
quando você usa requests isso não vai acontecer! Em vez disso, o Badboy vai
jogar a solicitação da mesma forma, independentemente de o botão de logon está
lá ou não. Claro, você pode verificar explicitamente se o botão de início de
sessão está lá usando um Assertion, mas para isso você teria que criar a asserção
de antecedência - que seria muito trabalhoso para verificar cada item que você
gravar dessa maneira. Em vez disso, o modo de navegação pode ajudar a superar
este problema.
8.4.2 Navigation Mode
Neste método o Badboy irá gravar qual elemento navegador que você clicou. Quando
você reproduzir, em vez de repetir a solicitação HTTP que foi enviada anteriormente, o
Badboy vai encontrar o elemento navegador original que você clicou quando a gravação
simular um clique sobre ele.
Este método tem as seguintes vantagens:
Automação de Testes
119
Em algumas páginas é muito mais fácil de se trabalhar. Isto é especialmente
verdadeiro para páginas complexas, tais como páginas de logon. A razão é que a
navegação é repetir a interação com o navegador e deixar o navegador fazer o
trabalho de criação do request.
Porque navegações explícitas exercitam a interface do usuário que são muito
melhores para os problemas que travam caso a interface esteja quebrada. No
exemplo acima, para o método de request, se você tivesse gravado o seu botão
de "logon" como navegação o teste seria um fracasso se alguém tivesse apagado
o botão da página.
A principal desvantagem do modo de navegação é que muitas vezes você não
pode usar este modo para a execução de testes de carga. Isso ocorre porque o
mecanismo de teste de carga é executado sem exibir qualquer interface de
usuário, e, portanto, não pode executar Navegações. Outra desvantagem é que os
seus testes dependerá dos itens estarem presentes e corretos na interface
utilizada para o trabalho. Assim, se o seu objetivo principal é apenas para testar
se a funcionalidade do seu site funciona sem se preocupar com a interface do
usuário, o modo de request pode ser melhor.
A diferença entre estes dois modos é muito importante. A escolha que você faz na
gravação terá um grande efeito sobre a forma como seus scripts se adaptarão às
mudanças em seu site.
8.4.3 Navigations
Navigations são um tipo de item no Badboy, que registra cliques ou ativação de
elementos de interface do usuário na janela do navegador. Quando você gravar uma
navegação, ele encontra o elemento browser que foi clicado (ou navegou de outra
forma, por exemplo, clicando em espaço ou entrar) e se recorda dele. Quando você
reproduz, o Badboy encontra o mesmo elemento e simula novamente um clique sobre
ele para que o navegador execute a mesma navegação novamente.
8.4.4 Gravando navegações
Por default, o Badboy registra os requests em vez das navegações. No entanto, você
pode facilmente alternar entre os modos de gravação a qualquer momento. Você pode
fazer isso através dos seguintes métodos:
Clique no 'N' botão na barra de ferramentas para alternar entre os modos;
Pressione Ctrl+Alt+N para alternar entre os modos de navegação;
Para alternar entre os modos durante a gravação de apenas um único item basta
segurar as teclas Ctrl+Alt pressionadas enquanto clica ou navega na página. Isso
irá alterar o modo de gravação enquanto mantiver as teclas pressionadas.
Automação de Testes
120
8.4.5 Tipos de itens de navegação
O Badboy irá gravar diferentes tipos de itens de navegação em seu script, dependendo
do tipo de elemento que você clicar e também como esse elemento é representado na
página que você está gravando. A tabela abaixo mostra os três diferentes tipos de item
que você vai ver:
Tipo de Navegação Descrição
Representa um clique em um link. Isto pode ser
qualquer tipo de ligação, incluindo um link de
imagem ou de outro conteúdo não textual.
Um clique sobre um botão. Estes são geralmente
botões em formulários, tais como botões de envio.
Um clique sobre um item diverso na página.
Freqüentemente estas ocorrem quando na página
foi utilizado um JavaScript para responder a "on-
click" cliques em elementos da página que gera
numa navegação de página ou um envio de
formulário.
8.4.6 Referências de navegação
Páginas da Web podem mudar frequentemente de forma bastante significativa em seu
layout, tamanho e forma, e muitas vezes podem ter vários elementos que são
semelhantes ou se parecem o mesmo. Devido a isso, o Badboy utiliza maneiras
diferentes de identificar os elementos, a fim de assegurar que ele encontrará o correto e
que foi originalmente registrado na reprodução. A informação que o Badboy utiliza para
identificar o elemento é chamada de "referência". Quando você grava um clique em um
elemento, o Badboy usa a seguinte lógica para encontrar uma referência para ele:
Se tem um id, então ele irá gravar o id do elemento;
Se ele tem um nome único atribuído, então ele irá gravar o nome;
Se for um link ou um botão e tem texto visível (como o rótulo do botão), então
ele vai gravar o texto e identificar o item por meio do texto.
Se não for nenhum dos outros métodos de aplicação, então ele vai identificar o
elemento pela sua posição browser DOM, usando uma expressão JavaScript.
Automação de Testes
121
8.4.7 Propriedades de navegação
Se quiser, você pode abrir as propriedades de navegação e definir as informações de
referência a si mesmo. A figura abaixo mostra como o diálogo de propriedades parece:
A tabela a seguir descreve as propriedades diferentes que você pode definir:
Propriedade Descrição
Element
Reference Isto identifica o elemento a ser navegado. Como este será
interpretado depende do tipo de referência.
Automação de Testes
122
Element Type
Determina como o texto de referência é usado.
For Visible Text, a referência é interpretado como o
rótulo ou o conteúdo da página visível que as
exibições de elementos (por exemplo, o conteúdo
exibido por um link, o texto em um botão ou uma
dica de ferramenta que descreve o item).
For Id/Name, a referência é interpretado como um
ID ou conjunto nome no elemento a ser navegado.
Se você escolher "JavaScript Reference", o Badboy
irá executar o texto como JavaScript que deve
retornar o item a ser navegado. Você pode usar isso
para escrever uma lógica mais complexa para
encontrar o elemento a ser navegado.
Element Filter
Define o tipo de elementos que devem ser considerados
para combinar o texto de referência. Isso ajuda a garantir
que o Badboy escolherá o elemento correto por triagem,
fora todos os elementos que não combinam com o filtro.
Você pode escolher "Links", "Buttons" ou "All Elements".
Index
Faz com que o Badboy utilize a ocorrência especificada do
elemento correspondente na página. Por exemplo, se houver
três botões chamados 'Sair' na página, você pode fazer o
Badboy usar o terceiro, especificando "2" na propriedade
Index. Note que esta propriedade default é "0", assim que a
primeira ocorrência (o padrão) for especificado usando o
"0" e o segundo é especificado usando "1" e assim por
diante.
Use Regex
Match
Faz com que a navegação trate a referência como uma
expressão regular durante a tentativa de combinar
elementos da página. Isso é útil quando elemento que
deseja acessar muda a cada execução. Esta opção só se
aplica ao "Visible Text Reference" tipo de referência.
Se você tiver problemas na sua navegação para localizar o elemento certo, você pode
clicar sobre a navegação e escolher "Highlight Element" para mostrar qual elemento na
página será o alvo. Se ele atinge o caminho errado, então você pode incrementar a
opção "Index" nas propriedades para encontrar o próximo item na página até encontrar o
elemento correto.
8.4.8 Variáveis
As variáveis são uma característica fundamental do Badboy. Elas permitem que você
personalize itens de script como são reproduzidas em tempo de execução, de modo que
você possa criar scripts que se comportem de forma inteligente em vez de simplesmente
Automação de Testes
123
repetir a mesma ação e outra vez. Esta seção descreve como você pode adicionar e usar
variáveis em scripts do Badboy.
8.4.9 Adicionando Variáveis
Há várias maneiras de adicionar variáveis no Badboy. Primeiro, você pode adicioná-las
diretamente clicando na janela variável no canto inferior esquerdo da tela.
A fim de fazer a adição de variáveis o Badboy oferece duas formas mais fáceis de se de
fazer isso:
• Clique com o botão direito do mouse em um parâmetro na árvore de script e selecione
"Add as Variable ..." ou "Add Linked Variable". A primeira delas irá simplesmente
adicionar uma variável com o mesmo nome que o parâmetro. O segundo irá adicionar
uma variável e procurar o valor em todos os outros parâmetros no script, ligando todos
os parâmetros com o mesmo valor da variável a ele.
• Use a opção no menu "Tools > Create Hostname Variable". Este é especificamente
para a criação de uma variável para controlar o nome do host de todos os seus requests.
8.4.10 Variáveis de visualização
Você pode ver todas as variáveis que você adicionou ao seu script na aba Variable. Este
ponto de vista é um guia na visualização de resumo que é normalmente no canto inferior
esquerdo da janela do Badboy (embora você pode movê-lo arrastando-o). A figura
abaixo mostra como a aba Variable mostra:
Automação de Testes
124
8.4.11 Editar Variáveis
Editando o valor de uma variável pode ser realizada através da abertura de sua janela de
propriedades - basta clicar sobre a variável e selecione "Propriedades".
8.4.12 Usando variáveis
Você pode usar variáveis quase em qualquer lugar que você possa inserir um valor no
Badboy. Para usar uma variável, se referam a ela, colocando-a dentro de chaves com um
cifrão na frente. Por exemplo, para usar uma variável "foo", você pode definir um
campo no Badboy ser "$ {foo}". Também é possível usar uma variável incorporado no
meio de outro texto. Por exemplo, se uma variável é chamada de "animal" e tem um
valor "sapo", então eu posso fazer uma frase "o $ {} é verde", usando a variável.
Quando Badboy desempenha seu script que irá substituir os valores das variáveis em
que você colocar referências de variáveis.
8.4.13 Variável lista de valor
Variáveis no Badboy tem dois componentes:
• O valor atual (este é o valor que é usado quando a variável é avaliada em seu script);
• Uma lista de valores futuros;
Você pode definir a lista de valores que uma variável tem abrindo a janela de
propriedades da variável (duplo clique no aba variável ou clique direito e selecione
"Propriedades"). Quando você faz isso, você pode adicionar uma lista de valores para a
variável. Se você quer fazer uma expressão que se refere a um determinado valor em
uma lista variável de valor, então você pode colocar o índice do valor entre colchetes
após o nome da variável. Por exemplo, $ {animal [3]} remete para o quarto valor na
lista de valores para o "animal" variável. (Note que os valores das variáveis são
numeradas a partir de zero!).
8.4.14 Variáveis de Incremento
Uma forma poderosa de usar variáveis torna-se evidente quando você combiná-os com
os "incrementos". Incrementar significa simplesmente alterar o valor de uma variável
para um novo valor, com base em uma estratégia que você pode especificar. Por padrão,
o Badboy vai olhar primeiro para o próximo valor na lista de valores variáveis. Se a
variável não tem uma lista de valores definidos em seguida, ela só vai atribuir um valor
aleatório para a variável.
Automação de Testes
125
8.4.15 Assertions/Asserções
Testar um site pode ser uma tarefa frustrante tediosa e monótona. O Badboy ajuda a
facilitar essa tarefa, automatizando a reprodução de scripts de teste, mas você ainda vai
adoecer de ver cada tela, para ver se funcionou da forma esperada. Você pode se
perguntar, não poderia o Badboy ajudar com isso também? Este é o lugar onde
Asserções entram em jogo.
8.4.16 Forma como as Asserções funcionam
Asserções são maneiras que você pode dizer ao Badboy para executar verificações
automáticas a fim de certificar-se de que o seu site está funcionando como você espera.
Você pode pensar em uma asserção como uma "declaração de verdade" algo que diz
que é verdade sobre o seu site. Se você fizer esta declaração, o Badboy pode ter certeza
que é verdadeiro e avisar caso ele não seja.
Asserção no Badboy são feitas de duas partes:
• O item de declaração em si - descreve como verificações são executadas e o que fazer
quando eles falham;
• Checks - estes são itens que são adicionados como filhos da asserção e examinar
aspectos diferentes da página ou o script para determinar se a sua asserção passa ou
falha.
8.4.17 Adicionando Asserções
Você pode adicionar uma asserção em qualquer lugar em seu script apenas arrastando
uma da caixa de ferramentas. Uma nova asserção adicionada ao seu roteiro aparece
como um símbolo de interrogação como mostrado abaixo:
O ponto de interrogação indica que a asserção não foi testada ainda. Quando a asserção
executar, irá mudar para um carrapato ou uma cruz, dependendo se a asserção encontrou
para ser verdadeira.
Automação de Testes
126
8.4.18 Checks
Uma asserção por si só não irá verificar nada e sempre passar - você precisa adicionar
Checks a partir da caixa de ferramentas para ele descrever as propriedades da página a
ser verificada. Existem vários tipos diferentes de itens de Checks que Badboy suporta.
A tabela abaixo mostra alguns dos tipos diferentes:
Nome Ícone Descrição
Content
Check
Verifica a presença de algum texto na página.
Response
Check
Verifica características de tempo de resposta e
tamanho
Color
Check
Verifica cores específicas na página. Você
pode especificar uma gama de cores e
localização aproximada para permitir pequenas
variações.
Summary
Check
Verifica o resumo das informações para itens
no script. Por exemplo, ele pode verificar o
número de vezes que um item foi executado,
havia erro ou expirou.
JScript
Check
Executa JScript que você forneceu e passa ou
não a asserção com baseando se o JScript
retorna "verdadeiro" ou "falso".
Variable
Check
Verifica o valor de uma variável para ver se
ele corresponde a uma expressão regular que
você forneceu.
Window
Caption
Check
Procura por uma janela com a legenda que
você especificar e, opcionalmente, olhar para
uma janela filho (como um botão, um campo
de texto, caixa, etc) com o texto especificado.
Esta verificação não corresponde texto no
conteúdo da web, apenas em janelas nativas.
8.5 Salvando e entendendo o resultado do script
Quando reproduzir o seu script, o Badboy trará as estatísticas de registros sobre cada
página executada, assim você pode acompanhar o progresso e rever o que aconteceu. O
Badboy torna possível ver rapidamente essas informações sobre qualquer item em seu
script através da Summary View.
Automação de Testes
127
8.5.1 Summary View
O Summary View é uma exibição com abas que é exibida por padrão no canto inferior
esquerdo da janela principal do seu Badboy A figura abaixo mostra como fica:
A tabela a seguir explica os números que são mostrados no resumo:
Statistic Description
Played O número de itens de script que executou e retornou uma
resposta.
Succeeded O número de itens de script que executou e retornou uma
resposta bem sucedida.
Failed O número de itens de script que executou e retornou uma
resposta de erro
Assertions O número de asserções que falharam.
Warnings
O número de Warnings gerados. Os Warnings são problemas
que ocorrem durante a execução que não a impedem de
concluir, mas podem indicar problemas com o script ou o seu
site. Por exemplo, se uma página vivencia erros de JavaScript,
ou se um Form Populator executa mas não consegue encontrar
o formulário especificado então warnings serão registrados
como parte da resposta para cada item.
Timeouts O número de Timeouts que ocorreram.
Avg Time (ms) A média de tempo em milissegundos para itens que
executaram e receberam uma resposta.
Max Time
(ms) O tempo máximo para qualquer gravação individual que teve
resposta.
8.6 Ferramentas
Usando Data Sources
Automação de Testes
128
Aplicações sofisticadas podem precisar testar o mesmo script usando uma série de
valores de a sua entrada. Por exemplo, você pode querer testar todas as condições de
limite para uma operação , o que acontece quando alguém pedir quantidades de 0, 5, 10,
1000 de um item em particular? Fazer este tipo de operações em que você deseja
executar o mesmo script ao longo de muitos valores diferentes para um parâmetro (ou
variável) é muito fácil ligando seus scripts a uma fonte de dados como um arquivo de
banco de dados de planilha ou texto.
O Badboy suporta a leitura de valores para as variáveis através de duas técnicas
diferentes:
• Usando uma ferramenta Setter variável da caixa de ferramentas;
• Utilizar fontes de dados ODBC para ler diretamente a partir de um banco de dados ou
planilha;
Esta seção descreve a segunda dessas opções: como você pode conectar o Badboy
diretamente a uma fonte de dados, como um banco de dados ou uma planilha. Isto
significa que se você configurar uma fonte de dados ODBC (que pode ser qualquer
coisa desde um banco de dados Oracle a um arquivo de texto separado por vírgulas),
então o Badboy pode ler valores de variáveis a partir dele e quando as variáveis são
incrementadas no seu script ele irá percorrer os valores em sua fonte.
Isso ajuda a utilizar um arquivo do Excel como um exemplo - mas lembre-se que você
pode usar qualquer fonte ODBC.
Outra forma de ler os dados do Excel é primeiro exportar os dados da planilha no
formato CSV selecionando o Arquivo > Salvar como, e em seguida, escolher CSV
como o formato de arquivo em Excel. Uma vez exportado como CSV, você pode ler
dados em suas variáveis usando o "conteúdo do arquivo" opção em uma ferramenta de
Variable Setter.
Por padrão O Badboy requer fontes de dados para satisfazer determinados requisitos.
(Nota:. Você pode mudar ou evitar esses requisitos, se você souber escrever SQL para
sua fonte de)
1. Todos os valores para todas as variáveis devem aparecer em uma única tabela;
2. A tabela deve ter títulos de colunas que correspondem aos nomes de variáveis que
você deseja ler;
3. Os valores para as variáveis devem aparecer nas colunas correspondentes;
4. Opcionalmente, pode incluir uma coluna chamada "SEQ". Se esta coluna existe,
então ele irá ser usada para ordenar os valores que serão lidos a partir da fonte de dados.
Deve ser um tipo de dados classificáveis (valores inteiros são sugeridos). Note que, se a
coluna não existe, então não há garantia sobre a ordem na qual os valores serão usados.
Aqui mostraremos como um exemplo de planilha Excel pode satisfazer esses critérios:
Automação de Testes
129
Isso mostra como você poderia criar um arquivo do Excel para carregar os valores para
as variáveis "Pieces" e "weight". Note que todos os nomes são case sensitive, e que em
alguns casos o ODBC pode converter os nomes para upper case, sem pedir a você.
Você vai precisar experimentar com sua fonte de dados para fazer isso direito.
Adicionando Data Source
Data source são configurados no Badboy, adicionando os itens "data source" da sua
caixa de ferramentas em seu script.
A imagem abaixo mostra como um item de Data Source é exibido depois de adicionar a
um script:
Quando você adicionar um item de Data Source para o seu script você terá como
escolher todas as fontes de dados ODBC em seu sistema. Alguns Data Source devem
ser definidos com antecedência usando o painel de controle do seu computador (a partir
do menu Iniciar, escolha Configurações> Painel de controle > Ferramentas
Administrativas > Fonte de Dados (ODBC) (depende da versão do windows) . Outras
fontes de dados, como por exemplo arquivos do Excel, podem ser acessados
diretamente do Badboy. Para arquivos do Excel deve haver uma "Excel Files" na opção
do menu drop-down (você deve ter o Excel, juntamente com seus drivers ODBC
instalados). Selecione esta opção e o Badboy irá ler o arquivo e mostrar as planilhas
dentro.
Você deve então selecionar a planilha a partir da qual você gostaria que Badboy
carregasse os valores. Depois de ter selecionada a planilha, no Badboy, você voltará
para a página de Data Source Properties onde você pode selecionar outras preferências
para como que dados devem ser carregados. O diagrama abaixo mostra a página de
propriedades para configurar uma fonte de dados:
Automação de Testes
130
Um cenário muito comum é carregar valores de uma fonte de dados e, em seguida,
repetir uma etapa para cada linha de valores na fonte de dados. O Badboy faz isso com
uma forma muito fácil de fazer, usando as propriedades de looping de Step. Você pode
fazer isso tomando as seguintes ações:
• Adicionar a fonte de dados para o seu script para carregar os dados;
• Após a fonte de dados, adicionar um novo Step;
• Coloque as ações que você deseja que ocorra para cada linha do conjunto de dados
para o novo Step;
• Execute a fonte de dados uma vez para carregar as variáveis;
Automação de Testes
131
• Ajuste a nova etapa dar um loop sobre uma das variáveis carregadas por sua fonte de
dados;
Quando tiver terminado, seu script seria algo parecido a figura abaixo:
8.7 Badboy em linha de comando
Se desejar, você pode executar a versão completa gráfica de Badboy a partir da linha de
comando (por exemplo, a partir de um prompt de comando ou em um script em lotes).
Para fazer isso, basta colocar o diretório de instalação Badboy em seu sistema variável
de ambiente PATH. Então você pode executar badboy como:
badboy
Se você deseja abrir um script chamado "myscript.bb", então você pode dar a ele como
um argumento:
badboy myscript.bb
Há uma série de opções que você pode usar para carregar e executar scripts de
diferentes formas a partir da linha de comando.
Flag de Linha de
Comando Descrição
/play Inicia o script após abrir o documento.
/playAll Reproduz inteiro depois de abrir o documento, sem parar em
Passos.
/autoExit Provoca o Badboy para sair automaticamente quando chega ao
final do script.
/D <name>=<value> Define uma variável para o script para usar. Exemplo:
badboy /D foo=bar myscript.bb
/nosplash Previne a tela inicial que está sendo mostrado na inicialização.
Automação de Testes
132
8.8 Usando Badboy com AJAX
Muitos sites modernos e os aplicativos usam uma técnica conhecida como "AJAX" para
atualização de conteúdo em uma página em segundo plano, sem atualizar a página. O
Badboy é projetado para suportar gravar e reproduzir este tipo de aplicação. Esta seção
explica como o Badboy lida com páginas web AJAX e dá algumas dicas para a criação
de testes de sucesso.
8.8.1 Entendendo as requisições Ajax
Requisições de AJAX diferem em aspectos importantes de requisições regulares. O
aspecto mais importante de requisições de AJAX é que elas não provocam diretamente
no navegador web para carregar uma nova página quando terminar. Em vez disso,
quando as requisições AJAX concluem elas chamam uma função JavaScript existente
na página que lançou a requisição AJAX. Essa função JavaScript pode fazer todos os
tipos de coisas - pode atualizar a página dinamicamente, definir variáveis de JavaScript,
preencher formulários na página - que pode até lançar mais requisições AJAX ou
provocar um carregamento de página real para ocorrer.
8.8.2 Gravação de páginas AJAX no Request Mode
Quando você gravar no request mode, o BadBoy detecta e registra requisições de AJAX
diretamente em seu script. Requsisições AJAX são semelhantes a requisições regulares,
mas elas são de cor cinza. A tabela abaixo mostra como as solicitações AJAX aparenta
em relação às requests normais:
Reproduzindo requisições AJAX
Por causa da natureza diferente de requisições de AJAX, o Badboy as reproduz de
forma diferente para requisições normais. O Badboy envia a requisição de AJAX para o
servidor, mas não chama o JavaScript subseqüente tratado para a requisição original.
Essa importante diferença significa que quando o Badboy desempenhar uma requisição
de AJAX, você não pode ver a tela de atualização como o faz quando a mesma ação
acontece manualmente. No entanto o que aconteceu foi que o servidor web tenha
processado o pedido e agora crê e se comporta como se a página esteja atualizada.
Como as atualizações podem estar faltando na tela depois de uma requisição de AJAX é
executada, você pode não ser capaz de usar assertions que verificam o conteúdo da
página para verificar se a requisição de AJAX conseguiu.
Automação de Testes
133
Você pode se preocupar que o teste então, não funciona corretamente porque a atividade
posterior causada por uma requisição de AJAX não é executada. No entanto, este não é
geralmente problemático pois o Badboy registrou todas as interações com o servidor
web: se a requisição de AJAX passou a fazer outra requsição de AJAX então o Badboy
terá registrado a requisição posterior e vai reproduzi-la novamente. Por outro lado, se a
requisição de AJAX realmente chamou um carregamento de página, então Badboy terá
registrado também. Assim, embora possa haver casos em que a interface de usuário não
refletem as atualizações causadas por uma requisição de AJAX, o servidor é mantido
sempre atualizado corretamente, e o carregamento da próxima página fará com que o
conteúdo correto seja exibido.
8.8.3 Gravando páginas AJAX no Navigation Mode
Para o teste funcional, o modo de navegação geralmente é o melhor modo para usar em
gravar aplicações web baseadas em AJAX, pelo menos para aquelas ações específicas
na aplicação que usam requsições AJAX. Na verdade, você provavelmente não vai notar
nenhuma diferença em como Navigations são registrados para interações AJAX. No
entanto, se você analisar mais de perto você verá algumas pequenas diferenças:
Se você abrir as propriedades você vai ver que a opção "Passive Navigation"
está selecionada;
Sob o ponto de navegação você pode ver um item de AJAX request gravado
para mostrar a requisição de AJAX que ocorreu quando o item foi clicado.
8.8.4 A reprodução de páginas AJAX no Navigation Mode
Quando as interações AJAX gravadas no modo de navegação são reproduzidas para não
fazer nada específico ao iniciar a requisição AJAX. Pelo contrário, ela simula um clique
do mouse sobre o elemento para que o navegador inicie a interação AJAX como se o
usuário tivesse feito isso.
Uma vez que o pedido de AJAX seja iniciada pelo navegador, o Badboy observa, espera
que ela termine, e então registra o tempo de resposta, tamanho e outros atributos são
registrados como uma resposta para a navegação.
Após a requisição de AJAX completa, o browser chama todas as manipulações normais
que ocorre quando a página é navegada manualmente. Devido a isso é atualizada a
página com conteúdo novo e você pode usar asserções para verificar o conteúdo exibido
na página, assim como você faria em um aplicativo não AJAX.
Automação de Testes
134
8.9 Usando o Badboy com JMeter
Enquanto o Badboy oferece alguns elementos característicos de teste de carga, para
fazer testes de estresse reais muitas vezes precisamos de muito mais. Ao invés de tentar
oferecer todas as características de um produto completo de teste de carga, o Badboy se
integra com um produto livre Open Source chamado JMeter. O JMeter é executado pela
Apache Software Foundation e é free e Open Source.
O Badboy integra com o JMeter, permitindo que você salve seus scripts no formato de
arquivo JMeter para que você possa abri-los e executá-los no JMeter. Este suporte
significa que você pode usar para gravar seus scripts para fazer testes funcionais, e
salvar o mesmo script como um arquivo JMeter para fazer testes de desempenho usando
o poder do JMeter!
Exportar um script em formato JMeter é muito simples. Basta gravar seu script e
navegar até File-> Export to JMeter.
8.9.1 Limitações
Infelizmente, há algumas limitações do BadBoy ao apoio ao JMeter. Essas limitações
existem porque as características do JMeter e do Badboy não correspondem exatamente
um ao outro e, em alguns casos, não é possível exportar itens diretamente.
As seguintes limitações devem ser observadas:
JScript não podem ser exportados. o JMeter não pode executar JScript porque
ele não tem uma janela de navegador incorporado. Itens de JScript serão
ignorados no roteiro quando você fizer a sua exportação;
Fontes de dados não são exportados. o JMeter tem seu próprio conceito para
substituir fontes de dados. Quando você exporta o arquivo, todas as suas
variáveisserão criadas no JMeter como "User Parameters". Você pode, se quiser,
fornecer um arquivo para o JMeter ler valores de variáveis;
Incrementos não são exportados. o JMeter não utiliza incrementos para
modificar variáveis. Pelo contrário, as variáveis são automaticamente
modificadas pela iteração de um ciclo, e sa presença de um modificador de
parâmetros do usuário;
Navegações não são exportadas. Navegações também necessitam em ter
presente a janela do navegador e, portanto, não pode ser suportado diretamente
pelo JMeter. Você pode simular se quiser usando recursos o JMeter;
Automação de Testes
135
Asserções são exportadas, mas podem precisar de ajustes. O Badboy tentará
exportar as asserções para o JMeter, mas devido a pequenas diferenças na forma
como lidar com asserções entre JMeter e O Badboy é possível que eles nem
sempre funcionem da mesma maneira. O Badboy verifica automaticamente por
estes problemas e irá alertá-lo com uma mensagem, depois da exportação que
contenham detalhes sobre o que pode ter de ser ajustado.