Automacao Testes

135
1 Automação de Testes

Transcript of Automacao Testes

Page 1: Automacao Testes

Automação de Testes

1

Automação de Testes

Page 2: Automacao 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

Page 3: Automacao Testes

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

Page 4: Automacao Testes

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

Page 5: Automacao Testes

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

Page 6: Automacao Testes

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.

Page 7: Automacao Testes

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

Page 8: Automacao Testes

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.

Page 9: Automacao Testes

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

Page 10: Automacao 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

Page 11: Automacao Testes

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.

Page 12: Automacao 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.

Page 13: Automacao Testes

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.

Page 14: Automacao Testes

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.

Page 15: Automacao Testes

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

Page 16: Automacao Testes

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.

Page 17: Automacao Testes

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/

Page 18: Automacao Testes

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:

Page 19: Automacao Testes

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”.

Page 20: Automacao Testes

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.

Page 21: Automacao Testes

Automação de Testes

21

6. Clique em [Next].

É exibida a tela confirmando locais de instalação e ícones que serão criados:

Page 22: Automacao Testes

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.

Page 23: Automacao Testes

Automação de Testes

23

11. É exibida a tela de finalização de instalação.

12. Para abri-lo basta clicar em [Finish].

Page 24: Automacao Testes

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:

Page 25: Automacao Testes

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”.

Page 26: Automacao Testes

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;

Page 27: Automacao Testes

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“.

Page 28: Automacao Testes

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)

Page 29: Automacao Testes

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.

Page 30: Automacao Testes

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".

Page 31: Automacao Testes

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.

Page 32: Automacao Testes

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.

Page 33: Automacao Testes

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.

Page 34: Automacao Testes

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.

Page 35: Automacao Testes

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

Page 36: Automacao Testes

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:

Page 37: Automacao Testes

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:

Page 38: Automacao Testes

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.

Page 39: Automacao Testes

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.

Page 40: Automacao Testes

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.

Page 41: Automacao Testes

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.

Page 42: Automacao Testes

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.

Page 43: Automacao Testes

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”.

Page 44: Automacao Testes

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”).

Page 45: Automacao Testes

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).

Page 46: Automacao Testes

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

Page 47: Automacao Testes

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.

Page 48: Automacao Testes

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.

Page 49: Automacao Testes

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.

Page 50: Automacao Testes

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.

Page 51: Automacao Testes

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.

Page 52: Automacao Testes

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.

Page 53: Automacao Testes

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:

Page 54: Automacao Testes

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:

Page 55: Automacao Testes

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

Page 56: Automacao Testes

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.

Page 57: Automacao Testes

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

Page 58: Automacao Testes

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

Page 59: Automacao Testes

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

Page 60: Automacao Testes

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:

Page 61: Automacao Testes

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.

Page 62: Automacao Testes

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

Page 64: Automacao Testes

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

Page 65: Automacao Testes

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.

Page 66: Automacao Testes

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.

Page 67: Automacao Testes

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.

Page 68: Automacao Testes

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 .

Page 69: Automacao Testes

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.

Page 70: Automacao Testes

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.

Page 71: Automacao Testes

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..

Page 72: Automacao Testes

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.

Page 73: Automacao Testes

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.

Page 74: Automacao Testes

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.

Page 75: Automacao Testes

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.

Page 76: Automacao Testes

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.

Page 77: Automacao Testes

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.

Page 78: Automacao Testes

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.

Page 79: Automacao Testes

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.

Page 80: Automacao Testes

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.

Page 81: Automacao Testes

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.

Page 82: Automacao Testes

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.

Page 83: Automacao Testes

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;

Page 84: Automacao Testes

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.

Page 85: Automacao Testes

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.

Page 86: Automacao Testes

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.

Page 87: Automacao Testes

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;

Page 88: Automacao Testes

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.

Page 89: Automacao Testes

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.

Page 90: Automacao Testes

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.

Page 91: Automacao Testes

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.

Page 92: Automacao Testes

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.

Page 93: Automacao Testes

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.

Page 94: Automacao Testes

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.

Page 95: Automacao Testes

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.

Page 96: Automacao Testes

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.

Page 97: Automacao Testes

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".

Page 98: Automacao Testes

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.

Page 99: Automacao Testes

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

Page 100: Automacao Testes

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".

Page 101: Automacao Testes

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

Page 102: Automacao Testes

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.

Page 103: Automacao Testes

Automação de Testes

103

Page 104: Automacao Testes

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á

Page 105: Automacao Testes

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:

Page 106: Automacao Testes

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”.

Page 107: Automacao Testes

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:

Page 108: Automacao Testes

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.

Page 109: Automacao Testes

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:

Page 110: Automacao Testes

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:

Page 111: Automacao Testes

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.

Page 112: Automacao Testes

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.

Page 113: Automacao Testes

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.

Page 114: Automacao Testes

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.

Page 115: Automacao Testes

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:

Page 116: Automacao Testes

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.

Page 117: Automacao Testes

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.

Page 118: Automacao Testes

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:

Page 119: Automacao Testes

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.

Page 120: Automacao Testes

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.

Page 121: Automacao Testes

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.

Page 122: Automacao Testes

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

Page 123: Automacao Testes

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:

Page 124: Automacao Testes

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.

Page 125: Automacao Testes

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.

Page 126: Automacao Testes

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.

Page 127: Automacao Testes

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

Page 128: Automacao Testes

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:

Page 129: Automacao Testes

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:

Page 130: Automacao Testes

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;

Page 131: Automacao Testes

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.

Page 132: Automacao Testes

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.

Page 133: Automacao Testes

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.

Page 134: Automacao Testes

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;

Page 135: Automacao Testes

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.