Sei sulla pagina 1di 105

Universidade Estadual de Campinas - UNICAMP Faculdade de Tecnologia - FT

Automação em Testes de Software - Utilização da ferramenta Selenium

Eliza Fabiane Martins Ribeiro

Limeira - SP

2010

RA: 043161

ii

Universidade Estadual de Campinas - UNICAMP Faculdade de Tecnologia - FT

Automação em Testes de Software - Utilização da ferramenta Selenium

Eliza Fabiane Martins Ribeiro

RA: 043161

ORIENTADORA:

Profª. Dra. Regina Lúcia de Oliveira Moraes

Trabalho de Estágio Supervisionado apresentado à Faculdade de Tecnologia FT da Universidade Estadual de Campinas como requisito parcial de conclusão do curso de Tecnologia em Análise e Desenvolvimento de Sistemas.

Limeira - SP

2010

iv

DEDICATÓRIA

Dedico este trabalho a minha família, amigos e muitas outras pessoas queridas que sempre fizeram questão de me

ajudar quando precisava,

e sei que sem essa

ajuda não seria possível

realizar um dos meus

sonhos, o de estar me tornando um profissional

de Tecnologia hoje.

v

AGRADECIMENTOS

Agradeço a Deus por ter fé em mim mesma e no que posso fazer, por ter perseverança e persistir no meu sonho.

Agradeço à professora orientadora Regina Lúcia de Oliveira Moraes, por lutar por nós alunos e buscar sempre o melhor para nossa Faculdade. Agradeço por ela acreditar em mim quando resolvi dar o meu primeiro passo na área de Testes de Software.

Agradeço a toda a equipe de testes do CPqD Workforce, com quem eu trabalhei no ano de 2009. Este ano foi muito importante para o meu aprendizado, agradeço à minha coordenadora de estágio Beatriz Cardoso Mamede Bernardi, por apostar no meu trabalho e por permitir que eu pudesse utilizar o Projeto de Automação de Testes da nossa diretoria como base para este trabalho. Agradeço em especial ao analista de teste Paulo Miguel do Amaral Rosa, pelas descobertas feitas no Projeto de Automação e pela paciência e boa vontade em compartilhar os seus conhecimentos com toda a equipe.

vi

Sumário

1. Introdução

2

2. Conceitos de Testes de Software

5

3. Automação de Testes

10

4. Ferramenta para Automação de Testes Selenium

17

5. Estudo de Caso

27

6. Resultados

46

7. Conclusão

61

8. Referências Bibliográficas

64

 

9. Anexos

66

10.

Apêndices

86

vii

Índice

1.

Introdução

2

1.1. Contexto e Motivação

3

1.2. Objetivo

 

3

2.

Conceitos de Testes de Software

5

2.1. Confiabilidade

 

5

2.2. Verificação e Validação

6

2.3. Testes de Software

7

3.

Automação de Testes

10

3.1.

Tipos de Automação

13

4.

Ferramenta para Automação de Testes Selenium

17

4.1. Introdução à Ferramenta

17

4.2. Instalação no Ambiente de Testes

22

4.2.1. Java

 

23

4.2.2. Eclipse

23

4.2.3. Selenium

IDE

25

4.2.4. Selenium

Core

25

4.2.5. Selenium

RC

26

4.3.

Utilização

26

5.

Estudo de Caso

27

5.1.

Descrição do Sistema

27

5.2.

Motivação

 

28

5.3.

Protótipos dos Scripts

29

5.5.

Explicação rápida sobre os 18 scripts criados

36

5.5.

Considerações finais

43

6.

Resultados

46

6.1. Análise de Resultados

48

6.2. Etapa 1 Preparar SQLs para a abertura dos BAs

48

6.3. Etapa 2 Preparar planilha auxiliar para os BAs

49

6.4. Etapa 3 Preparar a shell para o sqlplus

50

6.5. Etapa 4 Leitura do roteiro de teste

51

6.6. Etapa 5 Preparar a escala de trabalho dos técnicos da massa

52

6.7. Etapa 6 Limpar a massa de dados (deleta)

52

6.8. Etapa 7 Abertura dos 17 BAs

53

6.9. Etapa 8 Consulta na régua de prazos, visualização por executor

54

6.10. Etapa 9 Consulta na coluna total, visualização por executor

55

6.11. Etapa 10 Consulta na régua de prazos, visualização por estrutura

56

6.12. Etapa 11 Consulta na coluna total, visualização por estrutura

57

6.13. Etapa 12 Deleção dos BAs abertos pelo script

58

6.14. Etapa 13 Tempo de perda com erro

59

7. Conclusão

 

61

8. Referências Bibliográficas

64

9. Anexos

 

66

Anexo A Guia usado para a preparação do ambiente de testes automatizados

66

1 Java SE Development Kit

66

2 Selenium IDE, Selenium Core, Selenium Remote Control

69

3 Eclipse

 

74

4 Rodar o teste no Eclipse

82

viii

Apêndice A Planilha auxiliar para abertura de BAs para o teste manual

Apêndice B Tabela de tempos para comparação do teste manual e o automático 87 Apêndice C Tabela com as configurações dos computadores usados na

comparação entre os testes

Apêndice D Diagrama de Caso de Uso das principais ações feitas pelo testador .89

Apêndice E Diagrama de Classes da Consulta Prazos dos BAs

88

86

92

ix

Lista de figuras

Figura

1

Entraves à Qualidade

6

Figura 2 Verificação e validação dinâmica e estática

7

Figura

3

Fases de teste Modelo em V

9

Figura

4

Workbench de testes

12

Figura

5

Paradigmas para

automação

16

Figura

6

Como funciona o

Selenium

18

Figura 7 Interface do Selenium Core

19

Figura

8

Selenium IDE

21

Figura 9 Execução do Selenium Server

21

Figura 10 Selenium Grid em vários ambientes

22

Figura 11 JUnit, Eclipse e Selenium

24

Figura 12 TestNG, Eclipse e Selenium

25

Figura 13 Menu de Escolha de Scripts para Execução Automatizada

39

Figura 14 Gráfico: Resultado final da comparação

47

Figura 15 Gráfico: Preparar os SQLs para abertura dos BAs

49

Figura 16 Gráfico: Preparar planilha para abertura dos BAs

50

Figura 17 Gráfico: Preparar a Shell do sqlplus para a abertura dos BAs

51

Figura 18 Gráfico: Leitura do roteiro

51

Figura 19 Gráfico: Preparar escala de trabalho dos técnicos

52

Figura 20 Gráfico: Limpar a massa de dados

53

Figura 21 Gráfico: Abertura dos 17 BAs

54

Figura 22 Gráfico: Weblince grade de vencimento - executor

55

Figura 23 Gráfico: Weblince total executor

56

Figura 24 Gráfico: Weblince grade de vencimento - estrutura

57

Figura 25 Gráfico: Weblince total estrutura

58

Figura

26

Gráfico: Exclusão dos BAs

59

Figura 27 Gráfico: Perda com erro

59

Figura A - 1. Propriedades do sistema

67

Figura A - 2. Variáveis de ambiente

67

Figura A - 3. Editar variável de sistema

68

Figura A - 4. Download do Selenium

70

Figura A - 5. Download do Selenium IDE

70

Figura A - 6. Instalação da extensão no Firefox

71

Figura A - 7. Selenium IDE no menu Ferramentas

71

Figura A - 8. Janela do Selenium IDE

72

Figura A - 9. Diretório de Automação

72

Figura A - 10. Prompt com Selenium Server

73

Figura A - 11. BAT para executar o Selenium Server

73

Figura A - 12. Download do Eclipse

76

Figura A - 13. Criação do projeto

76

Figura A - 14. Adição das bibliotecas e JARs

77

Figura A - 15. Package Explorer do projeto

78

Figura A - 16. Referenced Libraries

79

Figura A - 17. Propriedades do projeto

79

Figura A - 18. Bibliotecas

80

Figura A - 19. Workspace no diretório de automação

80

Figura A - 20. Pasta com o arquivo de console

81

Figura A - 21. Configurando a exportação do console

81

x

Figura A - 22. Arquivo config.properties

83

Figura A - 23. Editando o config.properties

84

Figura A - 24. Import dos arquivos comuns

84

Figura A - 25. Criação do log

85

Figura E - 1. Visão geral das ações do testador

89

Figura E - 2. Ação de localizar o BA e seus dados na área de detalhamento

89

Figura E - 3. Ação de localizar o executor do BA

90

Figura E - 4. Ação de localizar a estrutura organizacional do BA

90

Figura E - 5. Ação de localizar o BA na grade de vencimentos

91

Figura E - 6. Ação de inserir os dados da massa nos filtros da consulta

91

Figura F - 1. Diagrama geral dos scripts criados e o menu

92

Figura F - 2. Diagrama de classes geral do projeto

93

xi

Lista de tabelas

Tabela 01. Entraves à Qualidade

5

Tabela 02. Benefícios mais importantes do CPqD Workforce

28

Tabela 03. Etapas para o processo de automação

30

Tabela 04. Esforço no projeto de Automação

42

Tabela 05. Quantidade de linhas de código

43

xii

Resumo

A qualidade é algo que nos últimos tempos tem sido buscada incessantemente pelo homem, em todas as áreas de atuação, seja nos estudos, na área pessoal, no lazer, na saúde, no trabalho, enfim ela está em qualquer ação que envolva o ser humano. Seguindo essa busca por qualidade dentro de um trabalho, temos aqui neste documento, a busca de qualidade dentro do desenvolvimento do software. Garantir a qualidade de um produto de software implica em definir boas metodologias de teste de software. Neste trabalho será mostrado como um processo de testes pode ser otimizado com o uso de testes automatizados como parte do processo de validação de software.

xiii

Abstract

In recent years, quality has been pursued incessantly by the humanity, in all acting

areas , such as education, personal lives, leisure, health, work, in short it is in any action involving the human being. Following the search for quality in a work, we have

in this document, the search for quality in software development. This work presents

a testing process that can be improved by the use of automated testing as part of

software validation.

2

1. Introdução

Atualmente as empresas em busca de uma maior qualidade em seus produtos ou serviços estão recorrendo cada vez mais aos produtos de software. Com o advento de novas tecnologias elas conseguem aperfeiçoar qualquer processo de produção utilizando máquinas e computadores. Porém, para controlar essa importante quantidade de informação é preciso criar sistemas de software robustos, eficazes e eficientes permitindo que o produto gerado ou o serviço seja produzido da melhor maneira, com o máximo de qualidade,

e com uma relação custo-benefício boa para a empresa e ótima para o usuário final.

Dessa forma, para atingir a qualidade no software é preciso também atingir a qualidade nos processos da empresa à procura do desenvolvimento de um sistema específico. Criar um software não é somente criar um mini-modelo do sistema real, mas criar uma forma de tornar esse sistema real mais organizado, mais palpável, mais mensurável, a ponto de permitir às empresas poder reduzir ao máximo possível

os seus custos e com isso poder gerar mais lucro. Assim como as empresas buscam a qualidade nos seus produtos, as empresas de tecnologia também o fazem e é dessa forma que a equipe de testes entra no processo de desenvolvimento de um software. Ela vai garantir a qualidade

necessária ao sistema e essa garantia será feita com base na solicitacão do cliente. Porém, sendo uma equipe humana, ela é passível de erros, podem ocorrer problemas no projeto de testes, na interpretação dos casos de usos, na criação dos roteiros, na execução dos roteiros, entre outros. Ou seja, o próprio processo de teste

é passível de falhas e, neste caso, o software não terá sua qualidade garantida e quem pode perder muito é o cliente, pois ao usar o sistema irá encontrar muitos defeitos e alguns podem trazer impactos muito graves. Por isso, nesse trabalho, será apresentada uma abordagem sobre testes de software e a sua automação como um meio de melhorar o processo de testes e garantir mais qualidade ao software desenvolvido. Como parte dessa busca pela melhoria de um processo de teste, foi escolhida uma ferramenta de automação e este uso será apresentado em um Estudo de Caso.

3

1.1. Contexto e Motivação

Com o aumento da demanda por produtos de software e novas tecnologias, as

empresas de TI constantemente precisam buscar novas formas de desenvolver software, proporcionando uma maior rapidez de entrega para o cliente, porém sem perder a qualidade do produto. Da mesma forma, a equipe de testes também precisa buscar novas formas de testar um software, para acompanhar a demanda dos clientes. É nesse contexto que surgem os testes baseados em scripts. Eles são implementados por ferramentas de automação, além de outros critérios usados no intuito de acelerar o processo de testes sem perder a eficácia e eficiência do mesmo.

O processo de testes de software é caro, por isso, em muitas empresas, ele ainda

não é feito adequadamente, sendo deixado em segundo plano, quando na verdade deveria ser uma prioridade da empresa. Se um software desenvolvido não pode ser testado, podemos dizer que ele tem sérios problemas, por isso hoje cada vez mais,

o desenvolvimento se relaciona cada vez mais com os testes, para permitir ao

software criado ser testável em todos os seus aspectos. Sendo um processo caro é preciso ser bem executado. Para isso, a automação vem sendo aplicada, pois ela permite a automatização de vários pontos de um processo de teste, garantindo não só um maior ganho de tempo pela equipe de testes

diminuindo o seu custo, como também, uma forma de ter mais qualidade no processo, garantindo uma maior cobertura de testes para o software em desenvolvimento. Manualmente, a obtenção de uma boa cobertura é inviável devido ao tempo reservado para o processo de testes. A importância dos testes e da automação desta atividade motivou a aluna a estudar este tópico.

1.2. Objetivo

Considerando o contexto apresentado, o objetivo deste trabalho foi aplicar testes automatizados em alguns pontos do processo de teste de um sistema real, desenvolvido no programa de estágio em que a aluna participou e verificar suas métricas para poder comparar o tempo necessário para se testar um software com base em scripts de testes automatizados e com base no teste manual. O sistema é crítico e controla toda a força de trabalho de empresas de telecomunicações, principalmente no ramo de telefonia.

4

O sistema controla essa força de trabalho dando um suporte para várias operações dentro das empresas de telecomunicações, ele controla todos os serviços técnicos realizados pelos funcionários dessas empresas, tanto os relacionados com suporte aos clientes, quanto suporte aos equipamentos integrantes da rede de comunicação avariados ou em manutenção. No estágio surgiu a oportunidade de se utilizar uma ferramenta de automação, o Selenium [01], pois foi a ferramenta escolhida pela empresa para se trabalhar com automação de testes. O uso de ferramentas de automação de teste era um anseio do gerente do projeto ao insistir que a equipe começasse a trabalhar com testes automatizados, para melhorar o desempenho dos testes. A empresa, onde o estágio da aluna foi desenvolvido, é o CPqD [02], uma fundação de direito privado, e o sistema utilizado nesse trabalho é o CPqD Workforce, um sistema de suporte a operações, gerenciador de força de trabalho e fluxo de execução das atividades em empresas prestadoras de serviços, entre outras.

5

2. Conceitos de Testes de Software

Neste capítulo serão apresentados alguns conceitos básicos relacionados com Testes de Software. Estes conceitos são importantes para se compreender a importância do processo de testes dentro do desenvolvimento de produtos de software.

2.1. Confiabilidade

A confiabilidade de um software é a garantia de que ele foi desenvolvido corretamente e que seus requisitos estão de acordo com o especificado. Ela torna o comportamento do software consistente. O assunto é extenso, porém a Tabela 01 [03] [04] [05] mostra alguns termos muito importantes para os testes de software e relacionados à confiabilidade.

Tabela 01. Entraves à Qualidade

Termo

 

Descrição

 

Engano

Comportamento humano que resulta na introdução de falhas ou um resultado incorreto em um sistema.

Falha de sistema

Uma característica do sistema que pode levar a um erro de sistema. Por exemplo, a falha em iniciar uma variável pode levar a um valor errado quando esta for usada. A falha, na verdade, é a manifestação no software de um engano cometido pelo desenvolvedor.

Erro de sistema

É

a diferença entre

a resposta

obtida e a resposta

esperada

pelo

sistema

de

acordo

com

a

sua

especificação.

 

Defeito do sistema

Um evento que ocorre em algum momento, quando o sistema não fornece um serviço conforme esperado por seus usuários, isto é, conforme especificado.

A Figura 1 na próxima página resume estes conceitos e as relações que eles possuem uns com os outros, mostrando assim o universo dos entraves à qualidade.

6

6 Figura 1 – Entraves à Qualidade 2.2. Verificação e Validação V & V [03] é

Figura 1 Entraves à Qualidade

2.2. Verificação e Validação

V & V [03] é como são conhecidos os processos de verificação e validação de um

software. Ocorrem durante todo o processo de desenvolvimento, durante cada fase

do processo de software, para garantir a qualidade do produto.

A validação determina se estamos criando o produto correto. É o produto solicitado

pelo cliente? Atende às suas expectativas? O produto está em conformidade com os requisitos? A verificação determina se estamos criando o produto corretamente. O produto está em conformidade com o requerido no início desta fase de

desenvolvimento?

O

objetivo desses processos é garantir um sistema confiável e bom o suficiente para

o

uso. Porém, o nível de confiabilidade muda de acordo com a situação. Um cliente

que tenha um sistema crítico vai exigir uma alta confiança no produto, mas um cliente com uma restrição de cronograma e não disposto a investir muito, pode tolerar um sistema apresentando falhas desde que não sejam muito prejudiciais ao uso esperado do sistema. Também devemos lembrar o fato da liderança de um mercado, pois isso faz as empresas liberem produtos de software sem estarem totalmente testados e depurados. Dentro da Verificação e Validação (V & V) tem-se uma abordagem estática nela não é necessário executar o sistema para fazer a verificação e a validação; e a abordagem dinâmica, onde verifica-se e valida-se executando o sistema. Na primeira abordagem pode-se citar a Inspeção ou Revisão por Pares, sendo verificados documentos como os de requisitos, diagramas de projeto e o código- fonte, como também podem ser feitas análises automatizadas. Na segunda, citam-

7

se os Testes de Software, onde são usados os dados de testes e analisadas as saídas do software observando o seu comportamento e sua utilidade operacionalmente. Observe a Figura 2 [03].

e sua utilidade operacionalmente. Observe a Figura 2 [03]. Figura 2 – Verificação e validação dinâmica

Figura 2 Verificação e validação dinâmica e estática

O teste será sempre a técnica principal de verificação e validação de software, porque exercita o programa usando dados reais baseados nos dados do cliente ou até mesmo fornecidos por eles. Os testes podem ser classificados em dois tipos

[03]:

Teste de validação mostra para o cliente que o software atende aos requisitos.eles. Os testes podem ser classificados em dois tipos [03]: Teste de verificação de defeitos mostra

Teste de verificação de defeitos mostra as inconsistências entre o programa e sua especificação. Os dois testes se complementam na verdade, pois durante os testes de validação você encontra defeitos, e durante os testes de verificação de defeitos você consegue validar os requisitos. Assim, não existe uma regra rígida para definir os dois durante o processo geral de testes.mostra para o cliente que o software atende aos requisitos. 2.3. Testes de Software O objetivo

2.3. Testes de Software

O objetivo desse processo é descobrir falhas ou defeitos o mais cedo possível, por meio de diversos testes, que podem ser aplicados no código durante a etapa de

8

desenvolvimento e também nos protótipos ou no próprio sistema, pois o processo de testes possui uma metodologia composta de técnicas de teste, níveis de teste, além dos diversos tipos de testes. Além disso, como foi dito anteriormente, o teste irá garantir ao cliente e também ao desenvolvedor que o software atende aos requisitos e está pronto para o uso. Enfim, garantir a qualidade do produto. São os seguintes os níveis ou fases de teste:

Teste de unidade [06]: são testadas as menores partes individuais testáveis do sistema. Podem ser funções ou métodos de um objeto, grupos de classes (clusters), entre outros; Teste de componentes [07]: são testados os componentes individuais (uma ou mais unidades integradas) para verificar se está de acordo com a especificação funcional ou se sua estrutura está de acordo com o solicitado; Teste de integração [06]: são testadas as integrações entre os componentes do sistema e as suas interfaces. Podem ser grandes grupos de classes, subsistemas ou somente componentes, aqui já se verifica os defeitos relacionados a problemas nas interfaces; Teste de sistema [06]: são testados todos os componentes integrados incluindo outros sistemas. Aqui é testado o sistema a ser entregue ao cliente e já ocorre a validação dos requisitos da especificação do sistema. Teste de regressão [08]: é retestado o sistema depois de um componente novo ser integrado ou parte do sistema receber alguma alteração. Serve para verificar se a parte inalterada do sistema que estava funcionando bem na versão anterior ainda continua funcionando adequadamente. Assim, é garantido que as novas alterações não causaram a regressão do sistema na nova versão. Para o teste de regressão é muito importante selecionar somente os casos de teste das partes do software realmente alteradas ou impactadas pelas modificações na nova versão, caso contrário, perde-se muito tempo reexecutando partes inalteradas do sistema sem nenhuma relação com as partes alteradas, gerando um custo muito grande de reteste e um desperdício de tempo para a equipe de testes [09]. Além das fases citadas, ainda temos o Teste de aceitação (feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema) [10].

(feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema)
(feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema)
(feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema)
(feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema)
(feito pelos clientes) e o Teste de operação (feito pelos administradores do ambiente final do sistema)

9

Normalmente, as fases de unidade, componente e integração são realizadas pela equipe de desenvolvimento do sistema, pois será preciso um conhecimento maior do código. A equipe de testes normalmente trabalha mais com a fase de sistema e regressão. O modelo em “V”, como é chamado o modelo apresentado na Figura 3 [04] apresenta as fases de desenvolvimento onde se espera que cada tipo de teste seja planejado para que o tempo na fase de teste, que é crítico para a equipe, seja otimizado.

de teste, que é crítico para a equipe, seja otimizado. Figura 3 – Fases de teste

Figura 3 Fases de teste Modelo em V

Seguindo outra classificação podem-se citar as técnicas de teste caixa-preta (baseadas na especificação) e caixa-branca (baseadas na implementação). Também classificando quanto aos tipos de teste, podemos citar o teste funcional, teste de desempenho, teste de carga (stress), teste de confiabilidade, teste de usabilidade, teste de segurança, teste de portabilidade, teste de instalação e teste de recuperação. O foco deste trabalho são os testes de sistema e os testes de regressão, principalmente este último, pois é nesse tipo de teste onde podemos melhor aplicar os conceitos de automação de testes. Dessa forma, agregamos mais valor ao processo de testes e ao profissional que irá realizar os testes de regressão.

10

3. Automação de Testes

O custo de implantar uma equipe de testes é grande, pode custar até 50% do custo

total do desenvolvimento [03] [06], portanto utilizar técnicas para reduzir esse custo

é essencial, não somente para aumentar a qualidade do teste e diminuição de seu tempo, mas também para não permitir que a falta de recursos financeiros em um

projeto prejudique a fase de testes. Entre as ações a serem feitas para diminuir o tempo/custo de testes, podemos citar [06]: a utilização de várias técnicas de Verificação e Validação; fazer um bom reuso dos casos de teste já prontos; integrar a equipe de testes e desenvolvimento (isso ajuda a criar códigos testáveis); trabalhar com estratégias de testes baseadas em riscos (isso irá aumentar a eficácia dos testes); e utilizar ferramentas e outras metodologias para melhorar a eficiência dos testes. São muitas as razões para se implantar a automação de testes, entre elas, redução de tempo e esforço da equipe de testes (o que resulta na redução do custo total da equipe), aumento da eficácia e eficiência dos casos de teste da equipe, aumento da precisão e cobertura dos testes (em alguns casos um testador manualmente não consegue atingir os objetivos de um caso de teste), melhora do processo de testes, retorno mais rápido para os clientes e para os desenvolvedores sobre o resultado de um teste, possibilidade de se trabalhar com uma combinação muito grande de testes, dentre outras.

É claro, implementar a automação em um processo de testes também não é fácil e

tem um custo, este em princípio pode ser maior do que continuar a usar o método

tradicional, porém a partir do momento em que a equipe já estiver preparada para usar as ferramentas de automação, os benefícios da automação começam a surgir.

É muito importante analisar todo o processo de testes dentro de um sistema e

verificar quais pontos poderiam ser automatizados e com isso reduzir os custos de testes. Existem algumas atividades dentro dos testes são facilmente automatizadas, mas outras demandam mais tempo, ou talvez nem possam se beneficiar da automação. Podemos citar como exemplo a ser automatizado, um caso de teste para desempenho ou carga, neles são repetidas centenas de vezes a mesma operação de cadastro, somente com alteração de alguns dados. Fazer isso manualmente levaria muito tempo, e o testador ainda correria o risco de inserir alguma informação

11

errada, sem contar o fator psicológico, pois seria muito desestimulante realizar um teste repetitivo como esse. Outro exemplo pode ser um teste de regressão. O teste de regressão já representa um prejuízo direto, pois na verdade você vai retestar algo já testado anteriormente e que estava funcionando bem. A automação aqui reduziria o tempo de custo da re- execução, principalmente nos casos dos casos de teste não apresentarem problemas. Neste caso, a experiência do projetista pode focar nos pontos onde o sistema pode realmente apresentar problemas na nova versão e deixar as partes aparentemente sem problemas para o teste automatizado executar. Esta escolha pode ser baseada nas dependências entre os componentes de software. Analisando os dois exemplos, podemos notar que algumas atividades necessitam fortemente de automação. Vale ressaltar da necessidade de ter um processo muito bem sedimentado para aplicar a automação corretamente e assim reduzir custos e melhorar a eficácia e precisão. É preciso analisar o valor de cada atividade e o seu custo corrente para o teste, qual a dimensão da atividade requerida, se ela fica menos custosa com a automação, e qual o custo de obter ou construir uma ferramenta para dar suporte à automação [09]. Assim, para criar um Workbench (conjunto de ferramentas que integradas irão ajudar no processo de testes) completo para testes, leva-se muito tempo [03]. Normalmente, somente em sistemas de grande porte encontramos uma estrutura completa como essa. Veja um exemplo de Workbench completo na Figura 4 [03] na próxima página.

12

12 Figura 4 – Workbench de testes Além disso, existem outros pontos que precisam ser analisados

Figura 4 Workbench de testes

Além disso, existem outros pontos que precisam ser analisados quando se deseja fazer a automação de testes [11] [12]. Ao escolher as ferramentas de teste é necessário saber qual o nível de dificuldade para se aprender a usá-la, como será a manutenção dos testes gerados, qual a diferença de tempo em relação a um teste manual. Outra questão é o tempo. Quando se tem um teste muito complexo é preciso verificar se vale à pena criar um teste automatizado ou deixar um testador mais experiente realizar o teste manualmente. Da mesma forma, se um teste automatizado for muito complexo, ele provavelmente só vai ser executado por testadores mais experientes com a automação. Isso é uma desvantagem, pois uma das idéias de se criar testes automatizados é também facilitar o entendimento do teste, permitindo sua execução por testadores menos experientes. Outro ponto é a própria capacitação do testador que irá trabalhar com a automação; é preciso disponibilizar um tempo reservado para se dedicar a este trabalho, pois ele precisará estar apto para saber focar em quais casos de testes a automação será eficiente e, além disso, determinar quanto tempo ele levará para preparar o teste automatizado. Assim, o nível de experiência do testador é muito importante.

13

O ambiente onde vai ser executado o teste automatizado precisa estar livre de bugse qualquer variável que possa torná-lo instável, pois poderá prejudicar o resultado dos testes e até mesmo a sua execução. Também é preciso verificar se o sistema exige um ambiente específico no qual o teste automatizado não possa ser replicado. Podemos citar sistemas que necessitem de outros produtos de software embarcados ou aqueles em tempo real. O Sistema em Testes (SUT) [11] também precisa ser previamente analisado, pois existem muitas tecnologias, linguagens, interfaces, entre outros, que podem ser usados para o desenvolvimento de um sistema. Portanto a experiência dos programadores é fundamental para o código gerado ser automatizável. Eles precisam gerar códigos padronizados para os testes automatizados poderem rastrear com precisão as ações dos usuários, mensagens de erros/acertos, localização de variáveis, dentre outros elementos. Portanto, quando se pensa em automatizar testes em um sistema a implementação precisa estar preparada para receber a automação. A documentação do teste automatizado também precisa ser analisada, pois quando se trabalha com um processo de testes, e é exigido uma documentação mais detalhada, um teste automatizado pode dificultar o desenvolvimento da documentação. Nesse caso, é preciso criar maneiras de se copiar as telas (screenshots) e gerar logs dentro de cada ação realizada no teste, dessa forma essas informações podem ser usadas na documentação. Além disso, o processo de testes precisa ser estável, pois somente assim é possível trabalhar eficientemente com a automação. Existem muitos prós e contras sobre a automação de testes, porém cabe sempre à equipe responsável, aos projetistas, coordenadores, analistas e testadores, analisar em conjunto, inclusive com os desenvolvedores, a melhor forma de implantar a automação em um sistema em testes.

3.1. Tipos de Automação

A automação pode ser aplicada de várias formas [13] [11]. Quando ela é baseada na interface gráfica do sistema, o teste automatizado irá se comportar como um usuário normal, fazendo todas as ações possíveis na tela do sistema, tais como, selecionar, abrir e fechar opções, selecionar itens em caixas de opção e de seleção, percorrer menus, responder as opções das janelas de mensagens ou alertas. Quando ela é

14

baseada na lógica de negócio o teste automatizado não interage com a interface gráfica. Nesse caso, é necessário fazer alterações no código do sistema, para torná- lo mais fácil de testar e para expor as suas funcionalidades. Podem-se citar alguns tipos de automação:

Baseados na interface gráfica (Capture/Playback ): é utilizada uma ferramenta que captura todas as ações feitas pelo o usuário Capture/Playback): é utilizada uma ferramenta que captura todas as ações feitas pelo o usuário na tela. Portanto, é necessário ser feito pelo menos uma execução manual do caso de teste, para gravar as ações. A gravação é salva na forma de um script linear de ações, este pode ser re-executado posteriormente. Vale ressaltar a criação de um teste, se este somente reproduz uma ação de entradas não é um teste automatizado, pois para ser considerado teste automatizado, a saída precisa ser automatizada e ser clara e legível para o testador. Esses scripts são muito úteis quando se tem um caso de teste simples para automatizar, pois não necessitam de muito conhecimento de implementação para criá-los. O ponto fraco é a dificuldade de reutilizar devido aos dados gravados e se o sistema sofrer alguma alteração na interface gráfica, todo o script pode ser perdido, pois ele se torna vulnerável, pois o conteúdo gravado na execução manual já não reproduz o atual estado da interface. Além disso, o custo para manutenção é alto;

Dirigidos a dados (Data-Driven ): é um refinamento dos testes baseados na interface gráfica. Neste caso, é utilizado Data-Driven): é um refinamento dos testes baseados na interface gráfica. Neste caso, é utilizado um mecanismo que permite reutilizar os scripts de teste gravados, porém, com dados diferentes. Isso é uma vantagem, pois além de reusar o script, podemos diminuir a sua complexidade, criando scripts menores e mais fáceis de entender, isto facilita a manutenção dos mesmos. Os Data-Driven são semelhantes às bibliotecas assim podem ser inseridos no código do sistema para facilitar a manutenção. A criação de um Data-Driven pode ser complexa e necessita de mais conhecimento em automação de testes e programação, pois não é tão simples quanto um script linear. Porém, depois de se ter um pronto e sem erros, outros casos de teste podem ser realizados a partir dele facilmente, somente alterando os valores da entrada. Normalmente os Data-Driven são usados em sistemas mais complexos, portanto necessitam de muitos testes; para sistemas simples não é recomendado;

15

Dirigidos à palavra-chave (Keyword-Driven ): é um teste criado basicamente para dar suporte aos testes de aceitação. Os Keyword-Driven): é um teste criado basicamente para dar suporte aos testes de aceitação. Os testes são feitos normalmente na interface gráfica, porém são baseados nas palavras-chaves disponibilizadas pela ferramenta de automação. São comandos em alto-nível representando a ação do usuário, gravados em scripts separados. A Keyword-Driven é na verdade um Data-Driven mais especializado, pois agora é possível realizar outras ações com o Data-Driven, ao invés de somente mudar as entradas para os testes;

Baseados na linha de comando (Command Line Interface - CLI): é usada uma interface de linha de comando onde o Command Line Interface - CLI): é usada uma interface de linha de comando onde o usuário pode interagir com a aplicação por meio de um promptou “Shelldo sistema operacional. A CLI vai interpretar os comandos e parâmetros, executá-los e mostrar os resultados. O interessante aqui é o teste não ficar dependente da interface gráfica para executar as suas funções do sistema.

Baseados em API (Application Programming Interface ): é usada uma API para executar os testes, devido ao fato Application Programming Interface): é usada uma API para executar os testes, devido ao fato da aplicação não ser dependente da interface gráfica do sistema. O objetivo de uma API é fornecer uma interface para o mundo exterior.

Test Harness: é usado para testar a regra de negócio, principalmente nas funcionalidades críticas que exigem : é usado para testar a regra de negócio, principalmente nas funcionalidades críticas que exigem cálculos e variações, demorados ou não, sendo assim, muito difíceis de serem testadas manualmente [14]. Não é utilizada a interface gráfica aqui. Também se pode testar APIs e é conhecido como Automated Test Framework. É um código auxiliar criado para testar unidades ou componentes, trabalha com driverse stubs, estes podem ser desenvolvidos em vários níveis de funcionalidade, o driverchama o código alvo, passa parâmetros e trata os resultados do código chamado, os stubsrepresentam os módulos chamados e devem devolver um resultado conforme o especificado para o módulo.

Na Figura 5 [13] na próximpa página é apresentado um resumo dos paradigmas de automação, apresentando suas vantagens e desvantagens.

16

16 Figura 5 – Paradigmas para automação

Figura 5 Paradigmas para automação

17

4. Ferramenta para Automação de Testes Selenium

Neste capítulo será apresentada a ferramenta de automação Selenium IDE e Selenium Remote Control. O Selenium foi utilizado no projeto de Automação de Testes durante o estágio no CPqD. Através desse projeto, foi feito o estudo de caso apresentado neste trabalho.

4.1. Introdução à Ferramenta

A ferramenta Selenium [01] é um framework open-source distribuída pela equipe

OpenQA [01], uma organização que trabalha com projetos voltados para a qualidade de software. É uma ferramenta de suporte para o gerenciamento de testes automatizados para sistemas Web.

O Selenium é capaz de reconhecer muitas linguagens de programação, pode

trabalhar com Python, Java, Rails, entre outras, permitindo usá-lo nos mais variados sistemas Web, uma grande vantagem se a equipe de testes trabalha com sistemas escritos em linguagens diferentes. Foi desenvolvido para ser executado em vários browsers e plataformas, porém, nas pesquisas realizadas, a maioria dos usuários o usa trabalhando com o Windows e o Firefox ou Internet Explorer. Acredita-se que seja devido ao fato de ainda serem muitos os sistemas desenvolvidos para o sistema operacional Windows.

A automação explorada pelo Selenium é baseada na Interface Gráfica do sistema,

como foi apresentado na seção anterior. O Selenium trabalha de várias formas diferentes, tudo vai depender do tipo de sistema a ser testado e do navegador (browser) a ser usado para os testes automatizados. A Figura 6 [16] na próxima página apresenta um esquema do seu funcionamento.

O

Selenium tem várias ferramentas, elas podem ser usadas em conjunto para criar

os

testes automatizados: Selenium Core, Selenium Grid, Selenium IDE, Selenium

Remote Control (RC), Cubic Test e o Bromine. O Selenium Core será descontinuado, pois os desenvolvedores de teste podem trabalhar diretamente com

o Selenium RC e fazer as mesmas ações contempladas no Core.

18

18 Figura 6 – Como funciona o Selenium

Figura 6 Como funciona o Selenium

19

O Selenium Core permite que os testes sejam executados diretamente no

navegador escolhido, exatamente como o usuário iria executar. Ele cria um

navegador com quatro frames separados, o maior é onde fica o sistema a ser testado e na parte superior tem-se três divisões.

No canto esquerdo tem-se a suíte de testes será executada no sistema (deve ser

gravada antes pelo Selenium IDE). No centro tem-se o código HTML gerado pelo IDE, com isso pode-se acompanhar o andamento da execução do teste. O Core usa cores para mostrar os passos já realizados, e se estão corretos ou não, de acordo com o teste. O vermelho aponta uma parte com erro, o verde mostra que o teste passou sem problemas. No canto direito são apresentados os controles do Core (Selenium TestRunner), os botões para executar, pausar a aplicação e outras opções. A Figura 7 [17] apresenta a interface do Selenium Core.

e outras opções. A Figura 7 [17] apresenta a interface do Selenium Core. Figura 7 –

Figura 7 Interface do Selenium Core

20

O Selenium IDE é uma extensão para o Firefox, sendo uma ferramenta base para

todo o framework Selenium, porque é utilizado em conjunto com as outras

ferramentas. O IDE é quem faz as gravações dos scripts de testes a serem executados nas outras ferramentas.

Os scripts gravados são, na verdade, todas as ações feitas pelo usuário no sistema

Web. A ferramenta grava todas as ações ligadas ao teclado e ao mouse quando o usuário interage com o sistema. Portanto, se for feita alguma ação diferente da esperada pelo sistema o IDE não vai gravar, assim como não grava, por exemplo, o fechamento do navegador pelo botão fechar, pois é algo inerente ao navegador e não ao sistema em si. Um exemplo de gravação é apresentado na Figura 8 na próxima página.

A linguagem usada para gravar os scripts gera um arquivo HTML aonde todas as

ações são guardadas em sequência numa forma de tabela com três colunas (Comando, Alvo e Valor). Essa é a vantagem de usar o IDE, ele retira o trabalho de programar todas essas ações do usuário. Além disso, ele permite ao teste ser exportado para outras linguagens de programação. Através dessa exportação é possível executar os casos de testes gravados no Firefox pelo IDE, em outros

navegadores utilizando o Remote Control.

O Selenium RC permite incrementar os testes gerados pelo IDE utilizando outras

linguagens de programação. Incorpora-se ao código exportado pelo IDE os comandos, bibliotecas da linguagem com os quais se estiver trabalhando.

O RC tem uma Interface de Programação de Aplicativos (API - Application

Programming Interface) e drivers cliente para as seguintes linguagens: HTML, Java, C#, Perl, PHP, Python, e Ruby, além do driver servidor, o selenium server. Ele deve sempre ser executado antes dos testes se iniciarem. Deve-se acompanhar o andamento dos testes pelo prompt. Normalmente, ele utiliza a porta 4444 do

computador para o servidor [18], observe a Figura 9 na próxima página. Isso permite ao seu teste flexibilidade, pois o que não for possível capturar pelo IDE

ou até mesmo comparar, pode ser realizado tentando usar o código da própria

linguagem escolhida em conjunto com o Selenium RC e programar a ação ou

comparação.

No

site de documentação do Selenium pode ser encontrada uma tabela com a lista

de

navegadores e sistemas operacionais suportados pela ferramenta [19].

21

21 Figura 8 – Selenium IDE Figura 9 – Execução do Selenium Server

Figura 8 Selenium IDE

21 Figura 8 – Selenium IDE Figura 9 – Execução do Selenium Server

Figura 9 Execução do Selenium Server

22

O Selenium Grid é como o Remote Control, porém permite que mais de um teste

seja executado ao mesmo tempo [20]. Gera várias instâncias para o Selenium Server, isso permite rodar o mesmo teste em máquinas diferentes, navegadores diferentes e sistemas operacionais diferentes, tudo paralelamente controlado pelo Hub do Selenium Server.

O Hub vai gerar um proxy para cada ação a ser executada no navegador e delegar

essa ação para algum RC ocioso, limitando a concorrência em cada RC e distribuindo os testes por toda a infra-estrutura do Grid. Este é quem vai executar a ação no RC de verdade. O funcionamento do Grid é apresentado na Figura 10 [21].

O funcionamento do Grid é apresentado na Figura 10 [21]. Figura 10 – Selenium Grid em

Figura 10 Selenium Grid em vários ambientes

Somente com o Grid é possível fazer testes em paralelo com o Selenium. O Java tem as ferramentas de teste TestNG parallel runse Parallel JUnit, elas podem ser usadas em conjunto com o Selenium.

4.2. Instalação no Ambiente de Testes

A instalação da ferramenta no ambiente de testes seguiu a sequência dos subitens abaixo relacionados. A instalação desses produtos de software foi necessária devido

23

ao tipo de linguagem em que foi desenvolvido o sistema e de sua execução ser feita no navegador Internet Explorer. Mais detalhes são apresentados no Anexo A. Os computadores utilizados para testar a ferramenta tinham instalado o sistema operacional Windows XP. Além disso, todas as ferramentas e produtos de software instalados foram colocados na pasta raiz (C:\) do Windows, pois as instalações que foram colocadas em outros locais apresentaram problemas durante a execução da ferramenta.

4.2.1. Java

O Java instalado é o Java Development Kit Standard Edition 6 (JDK 1.6) [22]. O

Java foi utilizado para executar o Selenium RC, e este usou o driver para o Java executar o Selenium Server, além de ser utilizado no Eclipse. O Java foi escolhido pela equipe por ser uma linguagem mais conhecida entre os colaboradores da equipe e pelas vantagens da própria linguagem, pois ela pode oferecer mais controle na implementação dos testes.

4.2.2. Eclipse

A IDE Eclipse [23] foi escolhida por ser um software open-source e por ter bons

resultados de desempenho na execução de projetos em Java. Foi utilizada para a implementação dos testes exportados pelo Selenium IDE e também para fazer todas as modificações necessárias no código do teste. A versão do Eclipse instalada é o Eclipse Classic 3.4.2, mais conhecida como Eclipse Ganymede.

Quando se utiliza o Remote Control com o Eclipse é necessário realizar algumas configurações no Java Project no Eclipse, caso contrário, a ferramenta não funcionará corretamente. Primeiramente, todos os testes exportados pelo IDE, precisam estar com a extensão “.java”.

No Eclipse deve ser criado um Java Project e importar os arquivos exportados pelo IDE. Esses arquivos serão colocados dentro de um pacote com.tests, este é um pacote usado pelo JUnit, conforme é apresentado na Figura 11 na próxima página.

O Eclipse usa o JUnit 3.0 ou 4.0 para executar o teste, portanto é preciso que o

JUnit esteja adicionado como biblioteca nas propriedades do projeto. O JUnit normalmente já vem instalado no Eclipse, somente sendo necessário adicioná-lo às propriedades dos projetos. Caso ele não esteja disponível na versão, é preciso fazer

24

uma atualização do Eclipse, isso deve ser feito pelo próprio Eclipse no menu Help em Software Updates.

pelo próprio Eclipse no menu Help em Software Updates. Figura 11 – JUnit, Eclipse e Selenium

Figura 11 JUnit, Eclipse e Selenium

Da mesma forma que o JUnit, todos os drivers do Remote Control precisam estar adicionados às propriedades no Java Project. Se não forem adicionados, o Eclipse não entenderá os comandos criados pelo Selenium IDE para o arquivo de teste. É importante verificar se o Selenium Server está sendo executado, pois caso não esteja, o Eclipse acusará erro no TestRunner. Outra ferramenta que pode ser usada no lugar do JUnit é o TestNG, conforme é apresentado na Figura 12 na próxima página. Para instalar é preciso fazer a atualização do Eclipse e localizar a url com os dados da ferramenta [24]. Além disso, é preciso configurar as classes usadas para gerar os relatórios de execução dos testes.

25

25 Figura 12 – TestNG, Eclipse e Selenium 4.2.3. Selenium IDE Selenium IDE é uma extensão

Figura 12 TestNG, Eclipse e Selenium

4.2.3. Selenium IDE

Selenium IDE é uma extensão do Firefox. Para instalá-lo é necessário entrar na opção de Complementos do Firefox, ela fica no menu Ferramentas. Copie o arquivo contendo a extensão para dentro da aba de Extensões dos Complementos. Automaticamente, o Firefox vai começar a instalação da nova extensão. Reinicie o Firefox e o Selenium IDE já poderá ser utilizado.

4.2.4. Selenium Core

O Selenium Core não precisa ser instalado ou configurado, somente descompacte a pasta e já poderá ser usado. Para usá-lo é preciso copiar a pasta “core”, dentro do Selenium Core, dentro da pasta Web onde fica o Webserver do sistema a ser testado. Além disso, ele precisa estar disponível no mesmo endereço e porta que o sistema vai ser executado.

26

4.2.5. Selenium RC

O Selenium Remote Control é configurado no Eclipse como foi explicado

anteriormente. Somente descompacte a pasta na raiz do sistema e depois adicione

os drivers dentro das propriedades dos projetos. Os drivers podem ser importados

direto no Eclipse sem ser preciso algum projeto. Dessa forma, ficam como padrão

para todos os projetos criados.

4.3. Utilização

A equipe de testes deverá utilizar a ferramenta para a automação daqueles testes que levam muito tempo para serem executados manualmente, principalmente os testes relacionados com consultas e retorno de resultados. Nesses casos, existem muitos itens na tela, os parâmetros da consulta, portanto pode haver uma combinação muito grande desses parâmetros. Também estão incluídos os testes de regressão, estes poderão ser feitos com a ajuda da ferramenta, principalmente os relacionados com mudança de interface gráfica e algumas funções básicas. Futuramente é preciso verificar a possibilidade

de criar as massas de dados para alguns sistemas com o uso da ferramenta, pois

dependendo do teste a ser feito com a massa de dados, a criação da mesma demora muito tempo. O estudo da ferramenta pela equipe de testes tinha começado fazia pouco tempo, quando este estudo de caso foi desenvolvido. Portanto, nas primeiras semanas,

ainda não era possível avaliar o que mais a ferramenta poderia automatizar dentro

do sistema escolhido e quais seriam os benefícios com relação à diminuição do

tempo de teste. Juntando-se a isso, tínhamos o fato de não sabermos ainda se o sistema tinha sido desenvolvido para receber a automação de testes. Isto é um ponto muito importante, pois nas primeiras utilizações da ferramenta foi possível perceber no sistema, alguns pontos aonde ele não recebeu a automação completamente. Nesses casos, a equipe de desenvolvimento do sistema foi contatada, para decidir

se algo poderia ser feito na próxima versão do sistema para o sistema melhorar no quesito automação de testes e consequentemente a qualidade de software.

27

5. Estudo de Caso

Nesta seção será apresentado o estudo de caso escolhido, desenvolvido no local de estágio da discente. O sistema foi desenvolvido por uma equipe técnica seguindo o modelo CMMI 3, além de outros padrões de qualidade. As diversas áreas de atuação exigidas pelo CMMI estão presentes e no caso da autora, a equipe na qual atuou foi a de Testes, onde estavam envolvidas as áreas de qualidade e de engenharia de software.

5.1. Descrição do Sistema

O sistema em que será aplicada a automação chama-se CPqD Workforce [25]. Este

sistema controla toda a força de trabalho de grandes empresas, como foi dito na

seção contendo o objetivo deste trabalho. É um sistema robusto com muitas aplicações distintas, tanto no nível desktop quanto Web. O CPqD Workforce é um sistema muito utilizado hoje em empresas de grande porte da área de Telecomunicações e TV, mas também está sendo inserido na área de empresas de energia.

O sistema dá suporte a vários tipos de operações dentro das empresas de

telecomunicações, fazendo um gerenciamento completo de toda a força de trabalho

da empresa, seja ela interna ou externa. Trabalha com um grande volume de dados,

inclusive em formato de áudio, pois tem um ótimo sistema de voz.

O sistema é capaz de gerenciar cada uma das etapas da prestação dos serviços

internos ou externos, e pode também obter informações de outros sistemas como o ERP e também de sistemas de alarmes. Todos os acionamentos de equipamentos

de segurança e também dos técnicos são feitos por um complexo código que analisa

a situação e toma a decisão automática de acordo com o serviço a ser executado. Tudo isso garante uma redução no tempo total de execução dos serviços, pois a resposta automática do sistema diminui o tempo de resposta à solicitação do cliente,

e garante um acompanhamento mais fiel de todas as etapas dos serviços sendo

executados, conseguindo assim cumprir prazos com mais eficiência e melhor qualidade do serviço. A Tabela 02 [25] apresenta os benefícios mais importantes do sistema.

A tecnologia utilizada para a implementação do sistema é bastante flexível e escalável, o sistema consegue trabalhar gerenciando até milhares de técnicos ao

28

mesmo tempo, disponibilizando muitos tipos de relatórios, inclusive relatórios totalmente configuráveis de acordo com a necessidade do usuário. A arquitetura do sistema é aberta, com isso é possível implantá-lo em diversas plataformas e também fazer a sua integração com outros sistemas. O sistema trabalha em conjunto com telefones fixos e celulares, permitindo assim aos técnicos serem localizados mais facilmente. Com a ajuda desses aparelhos, os técnicos podem receber todas as ordens de serviço automaticamente e enviar, através dos mesmos, o andamento do serviço a ser prestado. É como se fosse uma caixa de mensagens, onde cada mensagem representa um serviço. O técnico recebe todos os serviços a serem feitos, por exemplo, no celular. Estes serviços já estarão sendo enviados de acordo com a sua prioridade e a informação sobre a necessidade de se fazer um deslocamento. Além disso, é possível inserir e solicitar os materiais utilizados, dentre outras informações que podem complementar as informações já cadastradas no sistema e disponíveis para os técnicos na forma de uma simples caixa de seleção.

Tabela 02. Benefícios mais importantes do CPqD Workforce

Custo

 

Gestão

 

Cliente

Redução de custos operacionais - ao otimizar a alocação e o despacho das atividades e das penalizações por não-cumprimento de tarefas.

Melhoria

na

gestão,

com

Maior satisfação do cliente, em conseqüência da redução do tempo de resposta dos serviços, correspondendo assim às expectativas geradas.

maior

visibilidade

e

transparência

 

sobre

as

operações

e

a

força

de

trabalho.

5.2. Motivação

Como foi apresentado no início deste documento, a motivação para toda a equipe foi o empenho do gerente do nosso projeto para melhorar o desempenho dos testes e reduzir seus custos com o uso da automação. Somava-se a isso o fato de toda a equipe desejar encontrar uma forma de reduzir o tempo de execução e o custo de alocação de recurso para alguns tipos de testes. Como exemplo, podemos citar os testes de regressão em algumas telas de consultas, estes eram realizados frequentemente. O problema nesse caso era somente algumas informações serem alteradas e mesmo assim era necessário fazer toda uma navegação para verificar uma possível regressão.

29

Além do teste de regressão, ainda podemos citar os casos em onde tinha-se a

criação das massas de dados para os testes. As massas de dados eram sempre criadas pelos analistas de testes e testadores, sendo específicas para cada tipo de teste e de determinadas especificações. Elas permaneciam armazenadas nos servidores de testes, e sempre que possível, eram reutilizadas em outros testes.

O problema era o tempo de criação de uma massa de dados partindo do zero, este

era muito grande, principalmente se o testador não tivesse um bom conhecimento prévio do sistema. Dessa maneira, o tempo previsto para o teste podia ser constantemente excedido, pois se o testador não tivesse conseguido criar a massa de dados rapidamente e eficientemente, o início de execução real do teste acabava atrasando. Outro fator problemático é a complexidade da massa de dados. Alguns testes podem ser muito simples, e ter apenas uma simples relação entre tabelas na massa de dados, porém outros testes podem exigir uma relação mais complexa, sendo necessária a análise de mais de um caso de uso e outras documentações de requisitos para se chegar ao ponto exigido pelo teste. Assim, o que um testador experiente consegue decidir com base na sua experiência, um novo testador só

conseguirá fazê-lo depois de muita leitura e muitas tentativas. Nesses casos, seria uma grande vantagem poder criar tipos específicos de massas de dados. Assim para cada tipo de teste poderia ser executado um teste automático de criação de massa de dados, permitindo ao testador poder fazer outra atividade enquanto o teste era executado automaticamente, tendo também a garantia de que a massa de dados estaria correta de acordo com o tipo de teste. Somando-se a esses casos, tínhamos ainda a situação dos testes para verificar interfaces de navegação. Nesses casos, onde é necessário analisar os elementos visuais da interface e buscar as inconformidades, um teste automatizado também pode ser feito, buscando os campos, mensagens e outras informações a serem apresentadas na tela para os usuários. Estes são alguns dos exemplos citados em reuniões da equipe para o qual os testes automatizados poderiam ser de grande valor e ajuda.

5.3. Protótipos dos Scripts

O estudo estava sendo desenvolvido em etapas. Veja mais detalhes das etapas na

Tabela 03. Como a metodologia de automação era nova para os integrantes da

30

equipe, a coordenação do projeto decidiu separar três integrantes da equipe, para que esses ficassem responsáveis por estudar e aplicar a ferramenta de automação

de testes.

Tabela 03. Etapas para o processo de automação

Etapa

Tarefa

Descrição

Capacitação

Estudo da ferramenta Selenium e seu uso com o Java.

Gravação dos Scripts e Exportação para Eclipse

Início da gravação dos scripts usando o Selenium IDE no Firefox. Criação dos métodos auxiliares e genéricos.

Métodos específicos

Criação de métodos específicos para cada caso de teste que necessitasse.

Na primeira etapa, estes integrantes tiveram um tempo de alocação separado, somente para o desenvolvimento dos seus estudos em relação à ferramenta de automação. A idéia inicial era uma capacitação na ferramenta, para conhecer o seu funcionamento, seus conceitos para os testes, comandos e sua linguagem em geral. Um colaborador de outro projeto fez uma apresentação da ferramenta, pois este colaborador já estava trabalhando com a ferramenta há algum tempo. A diferença entre os projetos era que no caso do projeto do colaborador, a ferramenta estava sendo utilizada com o Python e no caso da nossa equipe de testes, a ferramenta seria utilizada para aplicativos em Java. Foram feitas reuniões com a equipe de automação para verificar o andamento dos estudos e as conclusões tiradas. Questões sobre a capacidade de a ferramenta superar as expectativas da equipe e sobre o prazo para se começar a realizar os testes automatizados o mais breve possível, dentre outras, foram discutidas. Outro ponto nessa primeira etapa foi a escolha da parte do CPqD Workforce que seria utilizada para iniciar os testes da ferramenta. Foi escolhido o sistema Weblince, pois é muito utilizado no ambiente do cliente e algumas de suas consultas são muito importantes. Isto foi definido pela coordenadora e pelos analistas de testes, pois tinham um conhecimento maior de qual consulta seria mais importante para se testar a automação.

O sistema Weblince faz parte do CPqD Workforce. Ele provê uma interface web

onde os administradores conseguem acessar informações de todas as operações e

de todos os técnicos, essas informações são geradas através das mais diversas

31

consultas, sedo permitido a construção de consultas nos casos em que as padronizadas e já disponibilizadas no sistema não forem suficientes. Depois de escolhido o sistema e a consulta para iniciar os estudos foi definida a segunda etapa. Nessa etapa, os integrantes da equipe de automação começaram a gravar os scripts com o Selenium IDE no navegador Firefox. Os scripts podiam ser modificados direto no IDE ou podiam ser exportados para um arquivo Java, para serem utilizados pelo Selenium RC junto com o Selenium Server e o Eclipse Ganymede [14] [22]. Nesta etapa foram identificados alguns entraves à automação devido ao tipo de

implementação de alguns objetos dentro do sistema. A maior dificuldade encontrada foi com os alerts criados com Java Script. A ferramenta não conseguia identificar esse tipo de objeto na tela e com isso toda a execução do teste ficava comprometida, pois algumas ações dos usuários eram esperadas através dos alerts

e não podiam ser reproduzidas.

Por consequência disso, todas as ações do menu de ações que aparecem no resultado da consulta não foram automatizadas, pois não foi possível clicar nos botões de ação que ficavam dentro do menu. Outras funções relacionadas com

imagens e cores nas tabelas também não puderam ser automatizadas, pois não foi

possível encontrar uma forma de fazer o Selenium reconhecer e relacionar as cores

e mudanças nas imagens como diferentes situações para o sistema.

O sistema tinha somente alguns pontos de códigos que podiam ser visualizados pela equipe de testes e isso também dependia do tipo de editor de HTML sendo utilizado, pois os mais simples não conseguiam entender a linguagem Perl acoplada no XML da página. O problema com o alert foi repassado para a equipe de implementação, inclusive como sugestão de melhoria da qualidade do sistema para as versões futuras, dessa maneira a automação poderia ser realmente aplicada facilmente no sistema. A automação poderia não somente ser utilizada pela equipe de testes, mas também pelos próprios implementadores, pois poderiam utilizar a ferramenta para trabalhar com testes unitários além de outros tipos de teste. Depois de contornados os problemas com os alerts (eles ainda existiam até a conclusão deste trabalho) os integrantes da equipe passaram a usar os scripts criados no Selenium IDE como base para capturar as ações dentro da tela do

32

sistema, e todas as outras alterações passaram a ser feitas pelo Eclipse, usando programação com o Selenium RC e o Java. Além disso, os códigos dos scripts começaram a ser reescritos no Eclipse para se tornarem mais genéricos, pois o IDE grava no script exatamente os valores inseridos pelo usuário nos campos da tela. No caso de uma reutilização do script, essa opção não é interessante, pois nem sempre a massa de dados usada nos testes é criada do zero ou mantida na mesma base e no mesmo servidor. Sendo assim os scripts podem ou não encontrar as informações que estavam gravadas nos links acionados, como também podem duplicar uma mesma ação sobre um dado já consolidado. Dessa forma, começou-se a usar métodos para receber e passar os valores (parâmetros) procurados para as funções do Selenium, ao invés de passá-los diretamente. Além disso, foram criados métodos para permitir localizar na tela os links que pudessem estar relacionados com esses valores. Também foram inseridas algumas operações, pois por alguma razão, estas não foram capturadas corretamente pelo IDE, além das verificações de labels e outros campos. Outros métodos também foram adicionados. Um deles visava as verificações de dados diretos nas bases de dados usadas pelo sistema. Com isso não era necessário que o testador fosse buscar a inserção ou outra operação diretamente no sistema, pois o resultado de uma ação do usuário no script já trazia um select no banco de dados e a resposta da consulta. Isso ajudou a verificar inclusive se os dados estavam sendo corretamente gravados no banco de dados. Foram criados métodos para trabalhar com datas. A hora corrente do teste era capturada e com ela foi possível criar as datas usadas na abertura dos bilhetes, além de gerar datas para o arquivo de log. Outros métodos trabalhavam a ação de cliquedo testador em vários pontos da consulta. Depois da finalização dos protótipos de scripts e o levantamento dos métodos mais comuns, a terceira etapa da equipe foi implementar alguns métodos mais específicos não desenvolvidos até aquele momento e estes seriam úteis para o início dos testes e para preparar um script completo para um caso de teste do roteiro de testes e executá-lo.

33

5.4. Scripts e roteiro da Consulta Prazos dos BAs do Weblince

A partir dos estudos dos protótipos gravados e alterados no Eclipse, foi possível

preparar a gravação do script de navegação geral da consulta Prazos dos BAs

(Bilhetes de Atividades). Essa consulta foi escolhida por ser muito utilizada no cliente

e porque, nos últimos tempos, estava sofrendo pequenas alterações e estas exigiam testes de regressão.

O BA representa no sistema uma espécie de ticket de suporte relacionado a algum

tipo de tarefa a ser realizada por algum técnico. O bilhete tem várias informações a

respeito da tarefa a ser executada: como local, tipo de reclamação, tipo de suporte, necessidade de deslocamento, quantidade e tipo de material usado na tarefa, tempo gasto durante a execução, dentre outras informações. Essa navegação geral consistia basicamente em verificar os bilhetes abertos pelo sistema dentro da grade de tempos de vencimentos, e numa segunda parte detalharmos os dados de cada coluna dessa grade. As ações de despacho dentre outras não foram automatizadas, devido ao problema com os alerts. Veja mais detalhes nos diagramas de casos de uso no Apêndice E.

A consulta Prazos dos BAs do Weblince, mostra ao usuário o prazo de vencimento

dos BAs abertos no sistema, o tempo de vencimento desses bilhetes de acordo com

a data de promessa e a hora de promessa do bilhete em relação ao tempo corrente

da sua visualização. Além disso, tem uma coluna específica para os bilhetes sem vencimento.

A grade é organizada de acordo com os parâmetros passados para a consulta e têm

dois tipos de visualização, uma ordenada por executor, onde são agrupados os

bilhetes de acordo com o técnico que deverá executá-lo, e a outra ordenada por estrutura organizacional, onde os bilhetes são agrupados de acordo com os níveis de uma determinada estrutura organizacional.

O roteiro criado para a execução do script possui um total de 418 subcasos de teste,

sendo a maioria de repetição devido aos números de BAs abertos. O roteiro contempla assim: a execução de 15 scripts, eles testam os filtros de parâmetros da consulta, um teste completo para verificação das duas visualizações, um teste completo para verificar o resultado da consulta, quando não se tem um executor e uma estrutura organizacional, e por fim, um teste para verificar a atualização dos resultados da consulta depois de um Refresh ser executado na tela.

34

O primeiro caso de teste é sobre o script do teste completo com executor e com a

estrutura organizacional. Este é o maior script, portanto é o caso de teste possuindo mais subcasos dentro do roteiro. Este caso será relatado com mais detalhes, pois engloba quase todas as ações dos outros scripts menores, além do fato de trabalhar com mais BAs.

O caso de teste começa com a abertura dos 17 BAs, sendo cada um deles para uma

coluna da grade de vencimentos dos BAs. Serão abertos na seguinte ordem de colunas: Sem Prazo (O BA não tem data de promessa), 28 dias a (BA com data de promessa maior ou igual a 28 dias), 21 dias a 28 dias (BA com data de promessa maior ou igual a 21 dias e menor que 28 dias), 12 a 24 (B A com data de promessa maior ou igual a 12 horas e menor que 24 horas), 6 a 12 (BA com data de promessa maior ou igual a 6 horas e menor que 12 horas), seguindo de 2h em 2h até a coluna de 0 a 2 (BA com data de promessa maior ou igual a 0 horas e menor que 2 horas), todos essas colunas representam BAs com situação em dia além de outras não citadas. Colunas para representar os BAs atrasados, isto é, a sua data de promessa já está vencida em relação ao tempo corrente de visualização, foram testadas nos

seguintes intervalos: 24 a 0 horas (BA com data de promessa maior ou igual a 24 horas de atraso e menor que 0 horas), 48 a 24 horas, … a 48 (BA com data de promessa maior que 48 horas). A segunda parte do roteiro trata do acesso à consulta no Weblince. Depois de todos os BAs acima serem abertos, o próximo passo era localizá-los na consulta Prazos dos BAs e verificar se eles estavam aparecendo corretamente nas colunas da grade de vencimentos e no detalhamento dos BAs relacionados com os links das colunas.

A primeira parte do script verifica os BAs na visualização por executor. São

passados como parâmetros da consulta: UF, Localidade e Estação, esses valores estão relacionados com a massa de dados preparada para a automação. Depois de passados os parâmetros os resultados da consulta são mostrados na tela de resultados onde fica a grade de vencimentos dos BAs. Na grade de vencimentos o roteiro contém as seguintes ações: clicar no link correspondente a cada coluna da grade dentro da linha do executor da massa, e checar no detalhamento se o BA aberto anteriormente consta corretamente na coluna específica, de acordo com o tempo de vencimento.

35

A partir disso, deve-se verificar alguns dados do BA na área de detalhamento, tais como, o número do BA, seu vencimento e sua data de promessa. Essas informações precisam estar corretas de acordo com os dados passados na abertura do BA. Todas essas ações são repetidas na visualização por estrutura organizacional, a única diferença nesse caso, era não termos mais os BAs distribuídos por executores, mas sim pelos níveis da estrutura organizacional. Em relação aos níveis, deve-se considerar sete níveis, estes podem ou não estar completos, para se definir a estrutura organizacional de uma determinada massa de dados. Basicamente, sempre o primeiro nível é tido como dado obrigatório, os demais níveis podem ou não serem preenchidos. No caso da massa de testes usada, todos os níveis da estrutura organizacional foram inseridos, dessa forma os BAs abertos anteriormente estavam relacionados com todos esses níveis. Portanto, no momento da visualização dos resultados da consulta todos os níveis eram acessados até se chegar ao último nível, onde o teste com a grade de vencimentos era feito. A mudança de uma visualização para outra era feita da seguinte maneira: depois do último BA ser detalhado na área de detalhamento da coluna Total na visualização por executor, o script voltava para a tela de parâmetros da consulta; nova consulta era feita usando os mesmos valores de parâmetros anteriormente passados e a opção por visualização por estrutura organizacional. Todo o processo na grade de vencimentos começava, o script fazia novamente o detalhamento de todos os BAs na coluna Total e para finalizar saia da consulta e todos os BAs abertos eram excluídos do sistema. Com isso, garantíamos que os próximos scripts a serem executados na mesma massa não sofreriam interferência devido ao número muito grande de BAs presentes no resultado da consulta. Alguns pontos devem ser esclarecidos sobre o roteiro. Ele foi criado baseado na execução do script e no que o script é capaz de fazer, com seus cálculos e seus métodos. Para executar o roteiro manualmente, como foi feito e será mostrado no Capítulo 6, foi necessário para o testador fazer mais ações, além das descritas no roteiro, como por exemplo, calcular os vencimentos dos BAs de acordo com a data e hora corrente da visualização. Outras características dos scripts devem ser apontadas, eles não só realizavam as ações manuais dos testadores, mas também faziam outras verificações importantes para o teste, verificações no banco de dados, por exemplo, para verificar a abertura

36

dos bilhetes e outros dados relacionados a eles, sua correta gravação nas tabelas do banco, dentre outras que poderiam ser muito demoradas se feitas manualmente. Todas essas verificações eram criadas usando a linguagem Java, pois nesses casos não era necessário o uso dos comandos do Selenium RC. A gravação de logs também era feita a cada execução dos scripts. Os logs continham as ações principais a serem feitas pelo script durante toda a sua execução. Também foram relatados erros e alguns de seus significados, por exemplo, erros de conexão com o banco de dados, erros de conexão com a interface de abertura de bilhetes, dentre outros. Pelo log era possível analisar o tempo de execução de cada ação do script, pois em cada método havia um ponto de início e fim gravado no log. O tempo total de teste também era gravado no log, sendo mais uma facilidade para o testador. Algumas ações gravadas no log não estavam relacionadas com a consulta em si, como no exemplo de verificações gerais para facilitar o trabalho do testador, cálculos, dentre outros.

5.5. Explicação rápida sobre os 18 scripts criados

A seguir segue uma explicação rápida sobre os scripts criados durante a automação da consulta Prazos dos BAs. Veja no Apêndice D, os diagramas de caso de uso do projeto, onde se pode ter uma visão geral das ações que o testador irá fazer e consequentemente as ações a serem feitas pelo o script, tanto visualmente quanto internamente no código do teste. Veja também, no Apêndice E, os diagramas de classes, onde se pode ter uma idéia da relação entre as principais classes criadas. O diagrama está simplificado, não levando em consideração todos os detalhes das classes nem a relação entre os pacotes dentro do projeto.

TesteCompletoExecutorEstrutura.java Abertura de 17 BAs (um para cada coluna da grade de vencimentos) para o mesmo executor.

Realiza uma consulta Prazos dos BAs (Visualização por executor).cada coluna da grade de vencimentos) para o mesmo executor. Para cada BA, através de cálculos,

Para cada BA, através de cálculos, identifica em qual coluna o mesmo será apresentado e o detalha.coluna da grade de vencimentos) para o mesmo executor. Realiza uma consulta Prazos dos BAs (Visualização

37

No detalhamento, verifica se o BA em questão foi detalhado corretamente.37 Depois, verifica se todos os BAs abertos estão na coluna Total (detalhando todos e conferindo

Depois, verifica se todos os BAs abertos estão na coluna Total (detalhando todos e conferindo no detalhamento).verifica se o BA em questão foi detalhado corretamente. Realiza outra consulta Prazos dos BAs (Visualização

Realiza outra consulta Prazos dos BAs (Visualização por estrutura).Total (detalhando todos e conferindo no detalhamento). Utiliza os mesmos BAs já abertos anteriormente, e para

Utiliza os mesmos BAs já abertos anteriormente, e para cada um deles, clica nos níveis da estrutura do BA em questão, e quando chegar no último nível detalha o BA (utiliza os mesmos cálculos para saber em qual coluna o BA deve ser apresentado).consulta Prazos dos BAs (Visualização por estrutura). Por último, verifica se todos os BAs abertos estão

Por último, verifica se todos os BAs abertos estão na coluna Total (detalhando todos e conferindo no detalhamento).para saber em qual coluna o BA deve ser apresentado). Para encerrar exclui da base todos

Para encerrar exclui da base todos os BAs abertos.Total (detalhando todos e conferindo no detalhamento). TesteBAsSemExecutorSemEstrutra.java Abertura de 2 BAs (

TesteBAsSemExecutorSemEstrutra.java

Abertura de 2 BAs (

programar”, esta indica a designação do bilhete de atividade para um técnico, mas ainda não despachado para a fila do mesmo).

Realiza uma consulta na “ Prazos dos BAs ” (Visualização por executor). Prazos dos BAs(Visualização por executor).

Através de cálculos, identifica em qual coluna o BA está e o detalha. No detalhamento, verifica se o BA foi detalhado corretamente.na “ Prazos dos BAs ” (Visualização por executor). Verifica se todos os BAs abertos estão

Verifica se todos os BAs abertos estão na coluna Total.detalhamento, verifica se o BA foi detalhado corretamente. Realiza outra consulta na “ Prazos dos BAs

Realiza outra consulta na “ Prazos dos BAs ” (Visualização por estrutura). Utiliza os mesmos BAs já abertos anteriormente. Prazos dos BAs(Visualização por estrutura). Utiliza os mesmos BAs já abertos anteriormente.

Como não há estrutura para os BAs, não irá detalhar nenhum nível, apenas clica no link da coluna onde se encontra (utiliza os mesmos cálculos para saber em que coluna link da coluna onde se encontra (utiliza os mesmos cálculos para saber em que coluna o BA deve ser apresentado).

Verifica se todos os BAs abertos estão na coluna Total.para saber em que coluna o BA deve ser apresentado). Para encerrar exclui da base de

Para encerrar exclui da base de dados todos os BAs abertos.Verifica se todos os BAs abertos estão na coluna Total. até 48h, 0h até 2h) que

até 48h, 0h até 2h) que vão ficar em R (Situação “A

TesteRefresh.java Abertura de 1 BA (6h às 12h).

Realiza uma consulta na “ Prazos dos BAs ” (Visualização por executor). Prazos dos BAs(Visualização por executor).

38

Através de cálculos, identifica em qual coluna o BA está e o detalha. No detalhamento, verifica se o BA foi detalhado corretamente. Armazena a quantidade de BAs exibida na coluna.38 Abertura de outro BA para a mesma coluna. Clica no botão de Refresh . Identifica

Abertura de outro BA para a mesma coluna.Armazena a quantidade de BAs exibida na coluna. Clica no botão de Refresh . Identifica em

Clica no botão de Refresh . Refresh.

Identifica em qual coluna o BA está e o detalha. Verifica se a quantidade foi incrementada corretamente.outro BA para a mesma coluna. Clica no botão de Refresh . Para encerrar excluímos da

Para encerrar excluímos da base de dados todos os BAs abertos.Verifica se a quantidade foi incrementada corretamente. Scripts para checagem de Filtros: As seguintes ações são

Scripts para checagem de Filtros:

As seguintes ações são comuns em todos os scripts de filtros:

Através de cálculos, identifica em qual coluna o BA está e o detalha. No detalhamento, verifica se o BA foi detalhado corretamente. Armazena a quantidade de BAs exibida na coluna.ações são comuns em todos os scripts de filtros: Para encerrar exclui da base de dados

Para encerrar exclui da base de dados todos os BAs abertos.Armazena a quantidade de BAs exibida na coluna. Os pontos de diferença nos scripts de filtros

Os pontos de diferença nos scripts de filtros estão relacionados com o tipo de visualização, que em alguns casos é Visualização por Executor e em outros é Visualização por Estrutura. Além disso, também temos as mudanças nos filtros usados: COS, UF, Localidade, Estação, Nível, Código do Nível, Contratada, Microárea, Área Técnica e Atividade, Tipo Cliente e Tipo Produto, Não Conectado, Conectado, No Turno, Macroatividade, Ramificação da Área Técnica, Prioridade. Alguns exemplos de scripts de filtro:

TesteFiltros1.java

Abertura de 1 BA (0h às 2h).

Realiza a consulta na “ Prazos dos BAs ” (Visualização por executor) com os filtros: COS, UF, Localidade e Prazos dos BAs(Visualização por executor) com os filtros: COS, UF, Localidade e Estação.

TesteFiltros12.java

Abertura de 1 BA (0h às 2h).

Retira o técnico da escala de trabalho para o dia corrente, depois da abertura do BA antes de fazer a consulta.por executor) com os filtros: COS, UF, Localidade e Estação. TesteFiltros12.java Abertura de 1 BA (0h

39

Realiza a consulta na “ Prazos dos BAs ” (Visualização por executor) com os filtros: COS, UF, Localidade, Estação, Prazos dos BAs(Visualização por executor) com os filtros: COS, UF, Localidade, Estação, No Turno, Macroatividade e Atividade.

Depois que realiza a consulta atualiza a escala de trabalho do técnico novamente.Localidade, Estação, No Turno, Macroatividade e Atividade. TesteFiltros15.java Abertura de 2 BA (2h às 4h). Um

TesteFiltros15.java

Abertura de 2 BA (2h às 4h). Um de serviço e outro corretivo.

Realiza a consulta na “ Prazos dos BAs ” (Visualização por estrutura) com os filtros: COS, UF, Localidade, Estação Prazos dos BAs(Visualização por estrutura) com os filtros: COS, UF, Localidade, Estação e Área Técnica e Natureza = C (corretiva).

Depois faz uma nova abertura de 1 BA (2h a 4h) do tipo preventivo, e com os mesmos filtros acima, somente mudando a Natureza = P.Estação e Área Técnica e Natureza = C (corretiva). Arquivos auxiliares: Menu.java Menu.java é um arquivo

Arquivos auxiliares:

Menu.java Menu.java é um arquivo utilizado para facilitar o acesso a todos os scripts acima mencionados. O menu contém uma caixa de seleção para cada script criado. Com isso é possível executar mais de um tipo de script em sequência, além de poder selecionar todos com um único “clique”. A Figura 13 apresenta a interface para a escolha dos filtros para a execução automatizada.

para a escolha dos filtros para a execução automatizada. Figura 13 – Menu de Escolha de

Figura 13 Menu de Escolha de Scripts para Execução Automatizada

40

Arquivos comuns:

Arquivos criados para auxiliar o andamento da classe Métodos Genéricos. Esses arquivos são usados na execução de todos os scripts criados. Foram criados com a intenção de melhorar o desempenho do código e permitir um acesso mais rápido a certas informações dos BAs abertos.

BA.java

A classe BA contém todas as informações sobre os BAs a serem utilizadas durante

a execução dos scripts. Contêm informações como o número do BA, executor, data

de promessa, UF, localidade, estação, níveis da estrutura organizacional, área técnica, ocorrência, vencimento, situação e uma variável auxiliar para a localização do clique nas linhas da grade.

Executor.java

A classe Executor contém todas as informações sobre os executores da massa de

dados usada. A classe é utilizada para facilitar o acesso aos executores da massa de dados, através da informação das suas matrículas e através de uma lista na qual guarda todos os BAs relacionados com aquele executor. Ela é utilizada principalmente quando se têm mais de um executor na massa de dados.

HTMLFormater.java

A classe HTMLFormater é utilizada para formatar a estrutura do arquivo de log.

Inicialmente o log foi criado com um simples arquivo .txt, porém com a melhoria do mesmo ele passou a ser gerado como um arquivo html, isso facilita na visualização

das ações que ocorrem dentro dos scripts, além de permitir funções mais avançadas, como mudança de cores e tamanho das fontes, inserção de imagens, dentre outros.

MetodosGenericos.java

A classe MetodosGenericos é muito importante, pois ela contém todos os métodos

não integrados ao código gerado automaticamente pelo Selenium IDE. Através dela são feitas as principais operações que ocorrem nos scripts, verificações no banco de

41

dados, cálculos, conexões com o banco, conexões com a interface de abertura de BAs, gravação do arquivo de log, dentre muitos outros.

O código dentro dos scripts é basicamente relativo ao caso de teste que ele

executava, porém a classe MetodosGenericos é a base, sendo a estrutura mantendo coesos todos os scripts. Todos os métodos criados durante o projeto, tudo

considerado importante e necessário em uma possível reutilização de código foi inserido nela. Com isso, evita-se que vários métodos fiquem espalhados em vários arquivos dentro da estrutura dos projetos de automação. Com a centralização de tudo o que era

criado nessa única classe, ficou mais fácil controlar as alterações realizadas pelos testadores e também manter uma melhor organização da estrutura dos projetos, pensando inclusive nos novos projetos.

A maior parte das ações mais complexas relacionadas aos cliques do usuário está

nessa classe, como por exemplo, a localização dos cliques na grade, a localização

do BA na área de detalhamento.

Também estão nela outras ações complementares como as inserções e atualizações no banco de dados, os cálculos de vencimentos dos BAs, os cálculos

das datas para a abertura automática dos BAs de acordo com a data corrente de visualização.

config.properties

O arquivo “config.properties” foi criado para permitir as configurações das massas de dados serem alteradas em cada execução do script. Como foi falado em capítulos anteriores, o Selenium IDE grava exatamente os dados que inserimos nos campos

no script, isso não é viável para a reutilização do mesmo. Dessa forma, é necessário

deixar o script genérico, porém para isso acontecer é preciso permitir que o testador

possa inserir as informações da sua massa de dados nos scripts.

O

grande problema nessa inserção é a necessidade do testador conhecer um pouco

de

programação, para entender onde exatamente precisará alterar os valores dentro

do

script. Além disso, ele precisará saber todas as posições nas quais deverá fazer

essa mudança no código, pois se esquecer de alterar alguma linha de código e deixar um valor antigo, o teste já estará comprometido ao ser executado. Outro ponto a ser lembrado é o tempo para o testador identificar a linha de código correta a ser alterada, e para fazer a alteração corretamente. Isto poderia exigir

42

muito tempo, portanto não estaria condizente com um dos objetivos da automação

que é reduzir o tempo de teste.

Devido a esses fatores o arquivo config.propertiesfoi criado. Com ele era possível

alterar as informações de uma massa de dados diretamente neste arquivo, não

sendo mais necessário ao testador buscar no código os pontos onde deveria haver a

alteração. Outro ponto era o arquivo ser bem simples. Era um arquivo de texto

comum, assim poderia ser aberto no Notepad do Windows, por exemplo. O arquivo

continha as entradas que são como os índices de um banco, e o conteúdo dessas

entradas são os valores a serem alterados pelos testadores. O script vai ao código,

verifica qual entrada ele deve procurar, vai até o config.properties, localiza e traz o

valor da referida entrada. Com isso, esse valor já fica na memória armazenado.

Quando na execução do script esse dado for requisitado, ele já estará disponível,

não sendo necessário ao config.propertiesser lido várias vezes durante a

execução.

Assim, qualquer dado poderia ser alterado futuramente em outras execuções, por

exemplo, informações de conexão com o banco de dados (login, senha, domínio,

IP), informações do sistema Weblince (login, senha, URL), e as próprias informações

das massas de dados, já estarão colocados no config.properties.

Para finalizar segue a Tabela 04 mostrando o tempo total gasto pela equipe de

testes durante o projeto de automação relatado nesse trabalho, e na Tabela 05 na

próxima página, a quantidade de linhas que cada código de script continha.

Tabela 04. Esforço no projeto de Automação

Colaboradores

Capacitação

Automação

Colaborador 1

62h37min

418h20min

Colaborador 2

20h

432h

Colaborador 3

20h

412h

Total

102h37min

1262h20min

(4dias 6horas 37min)

(52dias 14horas 20min)

43

Tabela 05. Quantidade de linhas de código

Script

Quantidade de linhas

TesteCompletoExecutorEstrutura.java

534

TesteBAsSemExecutorSemEstrutra.java

301

TesteRefresh.java

275

TesteFiltros1.java

216

TesteFiltros2.java

218

TesteFiltros3.java

212

TesteFiltros4.java

223

TesteFiltros5.java

227

TesteFiltros6.java

234

TesteFiltros7.java

238

TesteFiltros8.java

236

TesteFiltros9.java

208

TesteFiltros10.java

288

TesteFiltros11.java

218

TesteFiltros12.java

230

TesteFiltros13.java

207

TesteFiltros14.java

205

TesteFiltros15.java

275

Menu.java

1098

BA.java

414

Executor.java

74

HTMLFormater.java

26

MetodosGenericos.java

2949

config.properties

53

Total

9159

5.5. Considerações finais

As configurações de todas as ferramentas utilizadas, assim como do ambiente de automação precisam ser idênticas nas máquinas de todos os testadores, pois isso pode gerar erros na codificação ou na execução do script de teste. Embora tenha sido necessária essa adequação do ambiente em todas as máquinas, devido a diferença nos processadores, foi possível notar que alguns comandos como o thread.sleep” não apresentou o mesmo resultado em processadores diferentes. O thread.sleepera igual em todas as máquinas, porém algumas vezes não era suficiente, pois também dependia do estado do processador, assim poderiam ocorrer erros de time-out” tanto num processador mais lento, quanto num mais rápido.

44

Além dessas restrições, era preciso ficar atento aos scripts gravados pelo Selenium IDE. Muitas vezes os scripts eram exportados pelo IDE na sequência errada de cliques, principalmente quando se tinha área de frames na tela, quando era preciso reconhecer a hierarquia das tabelas dentro do frame para poder arrumar corretamente o script no Eclipse. Também foi preciso estar atento às condições do ambiente do sistema. Caso o sistema estivesse mais lento, a execução do script seria influenciada, algumas ações podiam não ser realizadas devido a um não carregamento da tela, ou demora no cache para atualizar os dados da consulta. Assim além do Weblince estar disponível, a consulta de Prazos dos BAs também precisava estar. Todos os processos usados pelo script, que estavam relacionados com outras interfaces precisavam ser verificados antes da execução, pois, por exemplo, a abertura dos BAs era feita pela interface Vitria. Se os processos dela não estivessem executando, os BAs não seriam abertos e o teste ficaria comprometido, parando logo no início da execução. Essa interface permitia a abertura dos BAs usando a shell do sqlplus fazendo todas as ações relacionadas com a abertura, para permitir que nenhum bilhete aberto não fosse integrado ao sistema. Além disso, tínhamos as conexões com o banco de dados e era necessário checar as contas de acesso ao banco de dados no config.propertiese ver se tinha mudado algo na configuração do ambiente. Todas essas alterações são muito importantes, pois alteram o ambiente de testes e assim podem danificar o andamento dos scripts gerando erros. Portanto, a equipe de teste precisa estar ligada às ações da equipe de desenvolvimento, pois muitas das mudanças citadas podem ser causadas por atualizações no sistema, feitas pelas equipes de desenvolvimento ou de bancos de dados, sem que a equipe de testes tenha o conhecimento. Mudanças na massa de dados também podiam alterar a execução, por exemplo, se era necessário a programação automática de BAs, caso uma massa estivesse com programação manual seria necessário mudá-la antes de executar os testes. A escala de trabalho dos técnicos da massa dos testadores também precisava ser verificada antes da execução dos scripts. Outro ponto era a exclusão dos bilhetes abertos depois do final da execução dos testes. O excesso de bilhetes aumentava o tempo de execução dos testes, pois o

45

Selenium perdia mais tempo para encontrar os últimos BAs abertos, no meio de tantos que retornavam no detalhamento de um link da grade de vencimentos. Outra questão a ser relatada é o uso do Internet Explorer. Quando em execução o Selenium Server tinha dificuldades para executar os scripts, às vezes dando erros logo no início da execução devido ao navegador. Isso acontecia tanto com o IE 6 quanto com o IE 7. Também notou-se que quando o Selenium Server já estava com uma janela do IE aberta, caso fosse necessário abrir outra janela do navegador para fazer qualquer outra atividade, o Selenium Server algumas vezes se perdia, e causava um erro parando o teste independente do ponto em que estava. O Eclipse também tinha um comportamento estranho quando se executava um script. Ficava difícil tentar usar as funcionalidades do Eclipse para alterar outros scripts em desenvolvimento, por causa dos que estavam em execução. O Eclipse ficava lento, sendo difícil fazer qualquer tipo de alteração. Era mais seguro fazer outra tarefa e esperar o script terminar de executar, para depois voltar para o Eclipse. Além disso, também é bom evitar fazer um script numa versão do Eclipse e depois compartilhar com alguém utilizando outra versão. Foram encontrados problemas para executar scripts gerados primeiramente no Ganymede e depois importados no Galileu, por exemplo.

46

6. Resultados

Como foi dito no Estudo de Caso desse trabalho, o objetivo do mesmo era fazer uma pequena comparação entre o teste manual e o teste automatizado utilizando os scripts criados com a ajuda da ferramenta Selenium. Depois dos scripts da consulta Prazos dos BAsserem finalizados e depois das

últimas atualizações para melhora do desempenho, foi iniciado o processo de comparação entre os testes. A seguir será relatado como foi o procedimento para a comparação e como foram os resultados.

O script TesteCompletoExecutorEstrutura.java foi dividido em etapas, para ser

possível medir o tempo do teste manual e do teste automático. Algumas etapas são

manuais para os dois testes a serem comparados. Veja no Apêndice B a tabela contendo todos os tempos das execuções do script. No Apêndice C temos as configurações dos três computadores usados na comparação e algumas informações relacionadas com as comparações realizadas.

A

primeira parte da comparação foi fazer o teste manual usando o roteiro criado para

o

script TesteCompletoExecutorEstrutura.java. O teste manual foi feito no

microcomputador A (no caso era o computador da estagiária) utilizando o Internet Explorer 6, cujo resultado é apresentado na Figura 14 (Manual primeira barra do

gráfico).

A segunda parte da comparação foi fazer o teste automático no mesmo

microcomputador. O resultado desta segunda parte também pode ser visto na no gráfico na Figura 14 (Automático A segunda barra do gráfico). Como se pode notar

o tempo do teste automático, acabou sendo maior que o teste manual no mesmo computador, sendo aproximadamente 34 minutos mais demorado.

A terceira parte da comparação foi fazer o teste automático no microcomputador B

(no caso era o microcomputador de um colaborador da equipe de testes, também no

grupo de automação). O computador dele tinha a mesma quantidade de memória que o da estagiária, porém, o processador era diferente tendo quase o dobro de processamento e o teste foi feito no Internet Explorer 7. O resultado pode ser visto

no gráfico da Figura 14 (Automático B terceira barra do gráfico).

A quarta até sétima comparação foram feitas considerando as mudanças no script

para a melhoria do desempenho do mesmo. Essa mudança estava relacionada com

os testes na visualização por estrutura organizacional.

47

A quarta parte da comparação foi fazer o teste automático no servidor de

automação. Esse microcomputador tinha a mesma configuração do microcomputador A, aquele usado pela estagiária, a única diferença é que o teste no servidor de automação foi feito com o Internet Explorer 7. O gráfico da Figura 14 na próxima página apresenta este resultado sob título Automático C (quarta barra do gráfico).

O

teste automático foi repetido no microcomputador B, para verificar se a mudança

no

script melhoraria o tempo final de teste no computador mais potente usado para

os

testes. Sob o título de Automático B (I) (quinta barra do gráfico da Figura 14) este

resultado é apresentado.

A sexta parte da comparação foi refazer o teste automático no microcomputador A,

para verificar se o tempo melhoraria com a mudança no script. O resultado pode ser visto no gráfico na Figura 14 sob título Automático A (II) sexta barra do gráfico).

A sétima e última parte da comparação foi refazer o teste automático no servidor de

automação, utilizando o Internet Explorer 6, para verificar se o navegador poderia estar influenciando no tempo de teste, uma vez que na quarta parte da comparação o teste foi feito com o IE 7. Este resultado é apresentado sob o título Automático C

(III) (sétima barra do gráfico na Figura 14).

Automático C (III) (sétima barra do gráfico na Figura 14). Figura 14 – Gráfico: Resultado final

Figura 14 Gráfico: Resultado final da comparação

48

6.1. Análise de Resultados

Pelo gráfico apresentado na Figura 14 nota-se a redução no tempo total do teste para o microcomputador A e para o B. A mudança feita no script para a melhora do desempenho na visualização por estrutura teve um bom resultado. Quando se analisa o microcomputador A na primeira execução o tempo total foi de 301,98 minutos. Na reexecução, considerando a mudança no script, o tempo passou para 186,56 minutos, quase metade do tempo da primeira execução. Quando se analisa o micro B na primeira execução o tempo total foi de 139,38 minutos, passando a 84,14 minutos com a mudança do script, confirmando a redução do tempo em quase 50%. Analisando ainda os tempos obtidos nos testes efetuados no microcomputador B, percebe-se claramente: um processador mais veloz influencia significativamente o tempo final de teste. Nesse caso, o tempo de teste foi menor que a metade do tempo apresentado quando o teste foi efetuado no microcomputador A. Outro ponto a ser notado é o micro servidor e o microcomputador A terem a mesma configuração, mas apresentaram diferenças no tempo total, isto pode ter ocorrido, pois no servidor somente o script de automação estava sendo executado na máquina, porém como o microcomputador A era de uso do testador, outros programas (outros navegadores, cliente de e-mail, programas do Office ou OpenOffice, etc.) estavam concorrendo com o tempo de processamento do processador. A última comparação se refere à diferença de tempo de execução entre o Internet Explorer 6 e o IE 7. Esse teste foi feito no microcomputador servidor. Pelo tempo final podemos confirmar uma diferença de tempo mínima. Ocorrendo basicamente devido ao tempo de espera colocado no código para o Selenium não ter um erro de time-outno IE, concluindo que o navegador não influenciou nos resultados obtidos. Seguem nas próximas seções uma explicação rápida sobre cada etapa dentro do script “TesteCompletoExecutorEstrutura”.

6.2. Etapa 1 Preparar SQLs para a abertura dos BAs

Etapa 1 (Figura 15) - A etapa 1 do script consistiu em preparar o SQL de acordo com a massa de dados de automação e alguns dados internos para a abertura dos BAs.

49

A Figura 15 apresenta o tempo despendido para esta tarefa que foi totalmente

manual. No caso foram abertos BAs do tipo serviço.

manual. No caso foram abertos BAs do tipo serviço. Figura 15 – Gráfico: Preparar os SQLs

Figura 15 Gráfico: Preparar os SQLs para abertura dos BAs

Essa etapa era feita somente no teste manual, pois nos scripts esses dados eram obtidos automaticamente no código e no arquivo config.properties.

6.3. Etapa 2 Preparar planilha auxiliar para os BAs

Etapa 2 (Figura 16) - Foi feita uma planilha auxiliar para ajudar no cálculo automático da data de promessa, data de início e fim de execução, data de anormalidade e o vencimento do BA de acordo com a data corrente. Essa planilha serve para gerar os valores a serem colocados no SQL da Etapa 1 e para disparar o BA numa determinada data/hora de abertura. Como na Etapa 1, essa atividade só era feita no teste manual, pois nos scripts todas as datas usadas para o cadastro dos BAs eram calculadas automaticamente de acordo com a data corrente do teste. Veja a planilha

no

Apêndice A.

O

tempo apresentado é o total de tempo utilizado para criar e atualizar a planilha,

até que se chegasse à forma final da planilha, respeitando os métodos de abertura do BA e do cálculo das datas que estavam no script. Esse tempo foi anexado à comparação, pois para se realizar o teste manual era mais rápido trabalhar com uma planilha, pois seria muito difícil abrir os BAs de acordo com as datas e horas colocadas no SQL, sem antes saber todas as datas usadas pelo BA.

50

50 Figura 16 – Gráfico: Preparar planilha para abertura dos BAs 6.4. Etapa 3 – Preparar

Figura 16 Gráfico: Preparar planilha para abertura dos BAs

6.4. Etapa 3 Preparar a shell para o sqlplus

Etapa 3 (Figura 17) Nesta etapa foi obtido o tempo desde o “logoffna Shell até o loginpara fazer o envio dos 17 BAs pela interface Vitria. Era preciso “logar” na conta da base usada pela interface em toda abertura de BA, pois dessa forma o script SQL de abertura não correria o risco de ter o mesmo ID para BAs diferentes, o que implicaria em erros na abertura. Também, dessa forma, seria possível usar sempre a mesma chamada para a entrada do ID no prompt do sqlplus. Se não fosse feito esse processo, seria preciso alterar a chamada para o ID do BA no SQL antes de cada execução no sqlplus, pois só assim o sqlplus não iria usar um ID já usado anteriormente na abertura de um novo BA.

51

51 Figura 17 – Gráfico: Preparar a Shell do sqlplus para a abertura dos BAs 6.5.

Figura 17 Gráfico: Preparar a Shell do sqlplus para a abertura dos BAs

6.5. Etapa 4 Leitura do roteiro de teste

Etapa 4 (Figura 18) - Tempo que foi gasto pelo testador para ler os casos de uso no roteiro e as outras informações necessárias para executar o teste manual. Essa etapa também só era realizada no teste manual, pois nos scripts o roteiro já está incluso diretamente no código.

pois nos scripts o roteiro já está incluso diretamente no código. Figura 18 – Gráfico: Leitura

Figura 18 Gráfico: Leitura do roteiro

52

6.6. Etapa 5 Preparar a escala de trabalho dos técnicos da massa

Etapa 5 (Figura 19) - A escala de trabalho dos técnicos da massa de automação, ainda não estava automatizada para ser atualizada no início do script, então, para evitar erros, era preciso preencher a escala mensal completa de cada técnico da massa de automação, para que ela correspondesse ao mês corrente de execução do teste. Os BAs tinham diferentes datas de execução, essas datas podiam chegar até um período de 30 dias anterior ou posterior a data de abertura. Caso a escala não estivesse corretamente atualizada, ao abrir um BA a programação automática de distribuição dos BAs para o técnico poderia não encontrar a data escolhida para a execução. Nesse caso, o BA não apareceria na consulta para o técnico escolhido na massa de automação, pois não teria nenhum técnico atribuído a ele.

pois não teria nenhum técnico atribuído a ele. Figura 19 – Gráfico: Preparar escala de trabalho

Figura 19 Gráfico: Preparar escala de trabalho dos técnicos

6.7. Etapa 6 Limpar a massa de dados (deleta)

Etapa 6 (Figura 20) - Antes de começar a executar o script é necessário excluir todos os antigos BAs que estão na massa de dados de automação, para evitar erros no script. Isso é feito direto pela base usando o comando “deleta”, um script SQL de

53

remoção de BAs. Esse tempo médio de deleção representava aproximadamente uns 50 BAs.

médio de deleção representava aproximadamente uns 50 BAs. Figura 20 – Gráfico: Limpar a massa de

Figura 20 Gráfico: Limpar a massa de dados

O comando “deletausava um arquivo no qual colocávamos todos os números dos BAs a serem excluídos. Esses valores eram retirados do sistema desktop SGE. Então, era preciso ir ao SGE e fazer uma consulta para retornar os BAs relacionados com a massa de dados de automação em questão. Quanto maior é a quantidade de BAs presentes na massa de dados durante a execução do script de automação, maior seria o tempo gasto pelo Selenium para encontrar os BAs abertos. Isso influencia o tempo final de teste, pois o Selenium perdia tempo passando por BAs antigos presentes na massa de dados e que não faziam parte da atual execução do script.

6.8. Etapa 7 Abertura dos 17 BAs

Etapa 7 (Figura 21) Nessa etapa era feita a abertura dos 17 BAs usando a interface Vitria. Para o caso do teste manual era preciso executar o SQL para abertura de BA, inserir um valor para o ID do documento associado relacionado ao BA, sendo esse ID único. Depois de cada abertura era preciso executar um selectpara ver se o BA foi

54

aberto ou se ocorreu algum erro na Shell no sqlplus. Esse “selectretornava o número do BA aberto ou o código do erro de abertura. Em toda a abertura manual dos 17 BAs era necessário refazer o processo acima. As Etapas 1, 2 e 3 estavam relacionadas com a Etapa 6. No caso dos outros testes os scripts faziam todas essas etapas automaticamente.

os scripts faziam todas essas etapas automaticamente. Figura 21 – Gráfico: Abertura dos 17 BAs 6.9.

Figura 21 Gráfico: Abertura dos 17 BAs

6.9. Etapa 8 Consulta na régua de prazos, visualização por executor

Etapa 8 (Figura 22) Esta etapa consistia em entrar na consulta Prazos dos BAsno Weblince e fazer uma visualização por executor. Era feita toda a verificação pela grade de vencimento (régua de prazos), sem passar pela coluna Total, e depois era feito o detalhamento da coluna na área de detalhamento. O script entrava em cada link na coluna e procurava a quantidade de BAs abertos relacionados com aquele teste. No caso sempre era 1 BA por coluna, então o script localizava a coluna que teria o BA que ele estava procurando, clicava na coluna e depois procurava o BA no detalhamento.

55

55 Figura 22 – Gráfico: Weblince – grade de vencimento - executor Nessa etapa no caso

Figura 22 Gráfico: Weblince grade de vencimento - executor

Nessa etapa no caso do teste manual, era necessário que o testador verificasse o tempo de vencimento do BA, pois ele precisaria saber exatamente em qual coluna o BA deveria aparecer, por isso esse tempo foi colocado na planilha de abertura, juntamente com a data corrente da visualização do BA na consulta (Veja o Apêndice A). Depois na área de detalhamento era necessário verificar se o tempo de vencimento estava aparecendo corretamente de acordo com a planilha de abertura,

o número do BA e a data de promessa. O script realiza esses passos automaticamente.

6.10. Etapa 9 Consulta na coluna total, visualização por executor

Etapa 9 (Figura 23) Esta etapa consistia em entrar na consulta Prazos dos BAs

no Weblince e fazer uma visualização por executor, porém, nesse caso, somente o

tempo do clique e detalhamento de todos os BAs da coluna Total é contado. O processo é similar ao da Etapa 8, porém, nesse caso, somente uma coluna é

selecionada e todos os BAs estarão nela para serem detalhados.

56

56 Figura 23 – Gráfico: Weblince – total – executor Nesta etapa o teste manual foi

Figura 23 Gráfico: Weblince total executor

Nesta etapa o teste manual foi mais rápido que os automáticos, pois o testador já possuía os dados dos BAs da etapa anterior (porque fazia o detalhamento deles dentro de cada coluna), isto facilitava a visualização, pois aqui não entrava a verificação do tempo de vencimento em relação às colunas da grade, afinal estávamos na coluna Total. Então para o testador era só clicar no link na coluna e checar todos os BAs ao mesmo tempo no detalhamento. O script demorava mais tempo, pois o tempo de procura de todos os BAs no detalhamento, nesse caso, era maior que o tempo humano. Nesse caso, não foi possível encontrar uma forma de tornar essa busca no detalhamento mais rápida, pois poderia ser um problema de desempenho do próprio Selenium ao localizar o xpathde cada BA dentro da área de detalhamento.

6.11. Etapa 10 Consulta na régua de prazos, visualização por estrutura

Etapa 10 (Figura 24) Parecida com a Etapa 8, esta etapa consistia em entrar na consulta Prazos dos BAsno Weblince e fazer uma visualização por estrutura organizacional. Da mesma forma que a Etapa 8, nesta etapa era feita toda a verificação pela grade de vencimento, sem passar pela coluna Total, e depois era feito o detalhamento da coluna na área de detalhamento.

57

57 Figura 24 – Gráfico: Weblince – grade de vencimento - estrutura A diferença aqui é

Figura 24 Gráfico: Weblince grade de vencimento - estrutura

A diferença aqui é que antes de entrar na grade de vencimento era necessário clicar em todos os níveis da estrutura organizacional, até chegar ao último nível (N = 7). Quando a consulta chegava no último nível é que os testes na grade de vencimento começavam, tal como na Etapa 8. Nessa etapa o teste manual também foi mais rápido, novamente devido ao fato de o testador já possuir algumas informações verificadas anteriormente nos BAs. A única mudança nesta etapa é o tempo de vencimento em relação ao tempo da etapa de visualização por executor, mas esse tempo poderia ser facilmente recalculado com a ajuda da planilha de abertura. Ao observar o gráfico da Figura 24, percebe-se a grande diferença de tempo entre os testes Automático Ae Automático A (II), isso se deve à mudança no script na parte de visualização por estrutura para a melhora do desempenho, como foi explicado no gráfico de resumo geral de comparação dos tempos (Figura 14).

6.12. Etapa 11 Consulta na coluna total, visualização por estrutura

Etapa 11 (Figura 25) - Consistia em entrar na consulta Prazos dos BAsno Weblince e fazer uma visualização por estrutura organizacional. Como na Etapa 10, também era necessário selecionar os níveis até atingir o último nível para depois iniciar os testes. Porém, aqui somente o tempo do clique e detalhamento de todos os BAs da coluna Total é contado. É um processo similar ao da Etapa 9 só que em outra visualização. Novamente o teste manual também foi mais rápido, devido ao

58

fato de o testador já possuir algumas informações verificadas anteriormente nos BAs e o condicionamento do testador ser mais rápido que a verificação do Selenium.

testador ser mais rápido que a verificação do Selenium. Figura 25 – Gráfico: Weblince – total

Figura 25 Gráfico: Weblince total estrutura

6.13. Etapa 12 Deleção dos BAs abertos pelo script

Etapa 12 (Figura 26) Nesta etapa temos o tempo gasto para excluir os BAs completamente da base de dados. Usamos o mesmo script SQL do comando deleta, citado na Etapa 6. A diferença é que agora ele está inserido entre o código do script de automação. Ele retira de uma lista gravada pelo script o número de todos os BAs abertos e depois apaga todos automaticamente. No caso do teste manual é executado o comando “deleta” da mesma forma que na Etapa 6.

59

59 Figura 26 – Gráfico: Exclusão dos BAs 6.14. Etapa 13 – Tempo de perda com

Figura 26 Gráfico: Exclusão dos BAs

6.14. Etapa 13 Tempo de perda com erro

Etapa 13 (Figura 27) No gráfico da figura 27 é apresentado o tempo gasto com erros na leitura, interpretação ou execução do roteiro. Somente usado nos casos de testes manuais. Aqui entram os erros de análise do testador. Não são considerados os erros do sistema que podem atrapalhar o andamento dos testes automáticos.

os erros do sistema que podem atrapalhar o andamento dos testes automáticos. Figura 27 – Gráfico:

Figura 27 Gráfico: Perda com erro

60

Ao final do processo foi possível perceber que restrições nas máquinas usadas, tornam o teste automatizado lento. Além disso, o processamento paralelo com outros programas também impacta negativamente o tempo de execução dos testes automatizados. Por isso a importância do isolamento total do ambiente de automação. Também foi possível perceber que os testes manuais não perdem sua importância, pois em alguns pontos são mais eficientes que os automatizados, por exemplo, na verificação dos bilhetes na área de detalhamento. O olho humano era mais rápido que o Selenium. Além disso, outros pontos onde era exigida a ação de procurar itens em caixas de seleção e preencher campos input também se mostraram mais rápida manualmente. No caso dos testes automatizados foi possível observar a melhora de tempo com relação às verificações relacionadas com o cálculo dos vencimentos dos bilhetes, abertura de bilhetes e exclusão, preparação da shell, dos scripts SQL, dentre outros itens realizados totalmente incorporados ao código, porém nos testes manuais demoram bem mais. Além disso, o tempo é otimizado pelo fato de não ocorrem algumas ações humanas, tais como a falta de atenção, interrupções diversas, dentre outras.

61

7. Conclusão

Nesse trabalho, percebeu-se em pouco tempo, como a automação de testes pode mudar o tempo relacionado com o esforço para executar um teste. Com essa pequena comparação realizada no Estudo de Caso já foi possível ver a diferença entre um teste manual e um teste automático quando este é bem planejado e quando se tem noção dos pontos fracos e fortes da ferramenta utilizada. Foi possível perceber as vantagens e desvantagens de ambos os tipos de testes, pois ficou claro que em alguns pontos a capacidade humana de analisar um dado ainda não pode ser ultrapassada pela máquina. Por esse motivo, em algumas comparações feitas, o teste manual ainda foi mais rápido que o automático. Porém em outras ações, principalmente aquelas mais manuais e repetitivas, o teste automático se mostrou mais ágil. Um exemplo desse caso é a abertura dos BAs, esta trabalhava integrada com a interface Vitria e com o Oracle. Outras ações relacionadas aos cálculos com datas e vencimentos também tiveram um bom desempenho, pois o script é muito mais confiável em seus cálculos e as chances de erro são mínimas. Diante de tudo isso, foi possível perceber que a utilização de scripts automatizados realmente pode auxiliar e muito algumas ações repetitivas em testes de regressão a serem realizados pelos testadores. Outro ponto importante é a questão do ambiente de automação de testes. As comparações em sua maioria foram feitas nos computadores dos colaboradores, porém ao mesmo tempo eles os utilizavam para efetuar outras ações. Também foi feita a comparação em um servidor de automação independente e esta experiência mostrou que, embora a idéia de automatizar permita que o testador faça outras ações enquanto o teste automatizado é executado, seria bem melhor ter um ambiente com servidores separados somente para executar os scripts de automação. A execução de um script é delicada e qualquer problema externo ocorrido em outro aplicativo sendo executado na mesma máquina, pode comprometer o teste. Normalmente os computadores sempre têm processos rodando o tempo todo, como antivírus, atualizações automáticas do Sistema Operacional, atualizações dos mais diversos produtos de software. Todas essas aplicações podem quebrar a execução de um teste automatizado.

62

O teste automatizado precisa de um ambiente seguro para ser executado, onde se tenha a certeza de que nenhum outro processo ou ação errada por engano do testador feitos na máquina irá atrapalhar o desempenho do script, pois o que buscamos é um tempo menor e uma qualidade maior sem perda de tempo ou inconsistência durante a execução. Com foco na questão humana, para um projeto de automação dentro de uma equipe de testes ser bem-sucedido, a equipe precisa contar com a ajuda da equipe de desenvolvimento, uma vez que o software sob teste automatizado precisa ter um código automatizável. Um código desenvolvido com foco na automatização permite aos scripts serem mais facilmente gravados pelo IDE e editados no Eclipse. Muitas opções de verificações, cálculos, cliques, dentre outras ações podem ser realizadas com mais facilidade, sendo possível maior cobertura das áreas do sistema a ser testado. Essas facilidades permitirão um ganho de tempo maior, primeiramente para a equipe de testes, pois terá mais tempo para se dedicar aos testes mais complexos e para uma correta elaboração de artefatos para a comprovação dos testes perante os clientes. Assim como a equipe de teste, a equipe de desenvolvimento também será beneficiada, porque poderá começar a usar os scripts automatizados em testes mais simples, como os testes de integração, as possibilidades para eles testarem também cresce, e com isso o número de defeitos causados, por exemplo, por esquecimento dos desenvolvedores, pode ser diminuído. Além desse envolvimento entre as equipes de teste e de desenvolvimento, é necessário aos colaboradores da equipe de teste que irão trabalhar com a automação terem conhecimentos prévios sobre algumas questões. É preciso nessa equipe gostar da tarefa de programação e ter curiosidade em aprender novos conceitos, para que se sintam à vontade na nova posição, pois um bom script de automação além de depender de um bom planejamento depende de uma boa programação. Dessa forma, é preciso escolher pessoas realmente interessadas em trabalhar com automação e que tenham algum conhecimento prévio de programação e facilidade para trabalhar com ela, pois a maior parte da criação de um script vem da programação pura e não do script exportado pelo IDE. A automação não precisa ser imposta a toda a equipe de testes, pois cada colaborador tem sua particularidade e assim cada um tem seu papel importante

63

dentro da equipe. Dessa forma, é necessário descobrir os pontos fortes de cada perfil de colaborador e definir assim o melhor tipo de atividade para cada membro da equipe. Em relação ao aprendizado de novos conceitos, os treinamentos internos, seminários, congressos e outros, tanto na área de testes/automação quanto na área de programação podem ajudar e muito. É muito mais fácil aprender com as experiências vividas por outras equipes de testes. Trocar conhecimento entre equipes é uma forma rápida de obter a ajuda que se precisa, principalmente quando a equipe de automação está começando o seu aprendizado, como foi o caso da equipe focada nesse trabalho. Esse modelo de transferência de conhecimento além de bastante eficaz evita gastos vultuosos com cursos que nem sempre surtem o efeito desejado. Essa troca de experiência traz não só a atualização dos conceitos técnicos dos colaboradores como também os motiva a querer sempre melhorar e buscar aprender coisas novas, além de permitir que eles estejam atualizados com as tendências mais recentes disponíveis no mercado e se alinhem com os novos anseios dos clientes.

64

8. Referências Bibliográficas

[01] SeleniumHQ

http://seleniumhq.org/ Último acesso em: 30 mai. 2010. [02] CPqD Soluções e Produtos CPqD Workforce. Disponível em:

http://www.cpqd.com.br/site/ContentView.php?cd=570 Último acesso em: 30 mai. 2010. [03] SOMMERVILLE, I. Engenharia de Software. Prentice Hall, 8ª ed., 2007.

[04] Dev-Media Biblioteca Digital DevMedia - Artigo Engenharia de Software -

Web

application

testing

system.

Disponível

-

em:

Introdução a Teste de Software. Disponível

em:

http://www.devmedia.com.br/articles/viewcomp.asp?comp=8035 Último acesso em: 30 mai. 2010. [05] MORAES, R. L. O. Notas de aula. Fundamentos de Testes. Faculdade de Tecnologia, Unicamp, 2006. [06] MARTINS, E. Notas de aula. Testes de Softwares. Fundamentos. Instituto de Computação, Unicamp, 2001. [07] BEIZER, B. Sofware Testing Techniques. International Thomson Computer Press, 2ª ed, 1990. [08] VIEIRA, V. G.; MARTINS, E. Notas de aula. Seminário de Teste 2001. Teste de Regressão. Instituto de Computação, Unicamp, 2001. [09] PEZZÈ, M.; YOUNG. M. Software Testing and Analysis: Process, Principles and Techniques. John Wiley & Sons, Inc., 2008. [10] PATUCI, G. O. Aplicação de uma metodologia em Testes Sistêmicos. 2007. 76f. Trabalho de Conclusão de Curso. Estágio Supervisionado CESET, Unicamp, Limeira-SP. [11] FEWSTER M.; GRAHAM D. Software Test Automation. Effective use of test execution tools. ACM-Press New York and Addison-Wesley, 1999.

[12] Abril Tecnologia e Informação Automação de Teste de Software. Disponível em: http://blogs.abril.com.br/blogdocampos/2008/09/automacao-teste- software.html Último acesso em: 30 mai. 2010.

Testes

[13] Caetano, C. TestExpert

Funcionais. Disponível em: http://www.testexpert.com.br/?q=node/178 Último acesso em: 30 mai. 2010.

A Process Oriented Approach.

[14] BURNSTEIN I. Pratical Software Testing:

Blogs

Introdução

à

Automação

de

65

Springer-Verlag, Berlin, 2002. [15] Beust, C.; Suleiman, H. Upper Next Generation Java™. Testing TestNG and Advanced Concepts. Addison-Wesley, 2008.

em:

[16] OpenQA.

How

Selenium

Works.

Disponível

http://seleniumhq.org/about/how.html Acessado dia 30 mai. 2010.

[17] Chris’ Blog - Writing Effective Javascript Code (or How I Learned to Stop

Worrying

learned-to-stop-worrying-and-love-the-unit-test/ Último acesso em: 30 mai. 2010.

em:

and

Love

the

Unit

Test).

Disponível

[18] Pimentel, F. - Rodando scripts do Selenium no Visual Studio. Disponível em:

visual-studio/ Último acesso em: 30 mai. 2010. [19] SeleniumHQ - Introducing Selenium - Supported Browsers. Disponível em:

Último acesso em: 30 mai. 2010. [20] Caelum Ensino e Inovação - Integração Continua - Builds rápidos com Grids e paralelismo. Disponível em: http://blog.caelum.com.br/tag/selenium-grid/ Último

acesso em: 30 mai. 2010.

grid.seleniumhq.org/how_it_works.html Último acesso em: 30 mai. 2010. [22] Sun - Java SE Development Kit 6u14. Disponível em: https://cds.sun.com/is-

[21] Selenium

Grid

How

it

works.

Disponível

em:

CDS_Developer Último acesso em: 30 mai. 2010.

em:

2010.

[24] TestNG Download. Disponível em: http://testng.org/doc/download.html Último

[23] Eclipse

Downloads.

Disponível

acesso em: 30 mai. 2010.

[25] CPqD

CPqD

Workforce.

Disponível

em:

Acessado dia 30 mai. 2010.

66

9. Anexos

Anexo A Guia usado para a preparação do ambiente de testes automatizados

Guia para Preparação do Ambiente de Automação de Testes CPqD - Workforce

Siga as etapas abaixo para criar o ambiente de testes. Atenção: A versão do Java utilizada neste guia foi a “1.6.0_12”.

1 Java SE Development Kit

Recuperar a instalação: http://java.sun.com/javase/downloads/widget/jdk_netbeans.jsp Instalar na pasta C:\java.

Selecionar com o botão direito em Meu computador. Após, selecionar Propriedades. Na aba “avançado”, selecionar Variáveis de Ambiente. Veja a Figura A - 1. No campo Nome da variável, informar JAVA_HOME. No campo Valor da variável, informar C:\Java\jdk1.6.0_12 Selecionar OK. Veja a Figura A - 2.

Na lista de variáveis do sistema, localizar a variável PATH, selecioná-la e em seguida Editar. No final do campo Valor da variável, adicionar o valor ;%JAVA_HOME%\bin Veja a Figura A - 3.

67

67 Figura A - 1. Propriedades do sistema Figura A - 2. Variáveis de ambiente

Figura A - 1. Propriedades do sistema

67 Figura A - 1. Propriedades do sistema Figura A - 2. Variáveis de ambiente

Figura A - 2. Variáveis de ambiente

68

68 Figura A - 3. Editar variável de sistema

Figura A - 3. Editar variável de sistema

69

2 Selenium IDE, Selenium Core, Selenium Remote Control

Maiores detalhes da ferramenta podem ser encontrados no site da OpenQA [01].

Baixar os arquivos do Selenium Core: http://release.seleniumhq.org/selenium-core/1.0.1/selenium- core-1.0.1.zip. Veja a Figura A - 4. Extrair os arquivos para a pasta “C:\automacao”.

Baixar os arquivos do Selenium Remote Control:

Veja a Figura A - 4.

Baixar o Selenium IDE: http://release.openqa.org/selenium-ide/1.0.2/selenium-ide-1.0.2.xpi. Veja a Figura A - 4 e a Figura A - 5. Para instalar, abrir o Firefox e ir a Arquivo -> Abrir arquivo. Selecionar o arquivo selenium-ide- 1.0.2.xpi. O Firefox solicitará confirmação para instalar o complemento. Confirmar a instalação e reiniciar o Firefox. Veja a Figura A - 6 como é a solicitação de instalação, o Selenium IDE fica instalado no menu Ferramentas, veja a Figura A - 7, veja na Figura A - 8 a janela do Selenium IDE já preparada para a gravação (botão com um círculo vermelho no canto superior direito ativado).

Extrair os arquivos para a pasta “C:\automacao”, conforme a padronização definida pela equipe de automação. Veja a Figura A - 9.

Subir o servidor do Selenium:

Acessar o prompt de comando (Iniciar->Executar, digitar cmd e clicar em OK). Ir para a pasta C:\automacao\selenium-remote-control-1.0-beta-2-dist\selenium-remote-control-1.0- beta-2\selenium-server-1.0-beta-2 (cd C:\automacao\selenium-remote-control-1.0-beta-2-

dist\selenium-remote-control-1.0-beta-2\selenium-server-1.0-beta-2).

Digitar “java –jar selenium-server.jar” e teclar “Enter”. Veja na Figura A - 10 o servidor já ativado.

Para facilitar você pode criar um arquivo executável “.bat” com os comandos acima, dessa maneira você não precisa entrar no prompt toda vez que for subir o servidor do Selenium.

Exemplo:

Abra o Notepad e cole os comandos abaixo:

@echo off c:

cd \automacao\selenium-remote-control-1.0-beta-2-dist\selenium-remote-control-1.0-beta-2\selenium-

server-1.0-beta-2

java -jar selenium-server.jar

Verifique se cada comando está numa linha separada, veja em Formatar->Quebra automática de linha. Salve o arquivo com o nome que você queira, lembrando que será um “.bat” e não um “.txt”. Ex: selenium_server.bat. Veja a Figura A - 11.

70

70 Figura A - 4. Download do Selenium Figura A - 5. Download do Selenium IDE

Figura A - 4. Download do Selenium

70 Figura A - 4. Download do Selenium Figura A - 5. Download do Selenium IDE

Figura A - 5. Download do Selenium IDE

71

71 Figura A - 6. Instalação da extensão no Firefox Figura A - 7. Selenium IDE

Figura A - 6. Instalação da extensão no Firefox

71 Figura A - 6. Instalação da extensão no Firefox Figura A - 7. Selenium IDE

Figura A - 7. Selenium IDE no menu Ferramentas

72

72 Figura A - 8. Janela do Selenium IDE Figura A - 9. Diretório de Automação

Figura A - 8. Janela do Selenium IDE

72 Figura A - 8. Janela do Selenium IDE Figura A - 9. Diretório de Automação

Figura A - 9. Diretório de Automação

73

73 Figura A - 10. Prompt com Selenium Server Figura A - 11. BAT para executar

Figura A - 10. Prompt com Selenium Server

73 Figura A - 10. Prompt com Selenium Server Figura A - 11. BAT para executar

Figura A - 11. BAT para executar o Selenium Server

74

3 Eclipse

Instalar na pasta “C:\automacao” (C:\automacao\Eclipse).

Abrir o Eclipse.

O Eclipse solicitará o endereço do Workspace, que é onde serão salvos todos os seus projetos. Você

pode criar uma pasta chamada “workspace” dentro do diretório de Automação. Ex:

C:\automacao\workspace. Assim todos os arquivos relacionados à Automação ficarão num mesmo diretório.

Depois de aberto o Eclipse Ir em “File -> New -> Java Project”. No campo Project Name informar “Automacao”. Clicar em Next. Na aba Libraries, clicar em “Add Library”. Selecionar o Junit e clicar em Next. Selecionar o Junit 4 e clicar em Finish. Veja a Figura A - 13.

Na aba Libraries, clicar em “Add External JARs”.

Ir na pasta C:\automacao\selenium-remote-control-1.0-beta-2\selenium-java-client-driver-1.0-beta-2,

selecionar o arquivo selenium-java-client-driver.jar e clicar em Abrir.

Veja a Figura A - 14.

Clicar novamente em “Add External JARs”. Ir à pasta “C:\automacao\selenium-remote-control-1.0- beta-2-dist\selenium-server-1.0-beta-2, selecionar o arquivo “selenium-server.jar” e clicar em Abrir.

Clicar novamente em “Add External JARs”. Procurar pelo arquivo “ojdbc14.jar” (que se encontra na pasta “jdbc\lib“ da instalação do Oracle (ex: C:\oracle\product\10.2.0\client_2\jdbc\lib\”). Clicar em Abrir e Após em Ok.

Clicar novamente em “Add External JARs”. Procurar pelo arquivo “commons-lang-2.4.jar. Clicar em Abrir e Após em Ok”.

Confirmar a criação do Projeto. Clicar com o botão direito sobre a pasta do Projeto (lado direito da tela do Eclipse) e ir a New - >Package. Informar “testeSinergia.weblince.prazos” e clicar em Ok. Copiar os arquivos “.java” do projeto de automação e colar dentro desse pacote. Você também tem a opção de importar os arquivos (Botão direito do mouse -> Import -> File System). E também pode copiar os arquivos diretos no diretório:

C:\automacao\workspace\Automacao\src\testeSinergia\weblince\prazos Antes de entrar no Eclipse, depois que estiver no programa você deve dar um Refresh no projeto para garantir que os arquivos estarão atualizados Veja na Figura A - 15 e na Figura A - 16 como fica a árvore do nosso projeto no Package Explorer do Eclipse.

Repita os mesmos procedimentos do parágrafo acima para criar o pacote chamado “arquivosComuns”. Este pacote foi recentemente criado, pois com o início da criação dos scripts de

75

automação da consulta Carga de Executores, houve a necessidade de alterar alguns métodos da classe MetodosGenericos.java e reorganizar a estrutura do Projeto Automação. Veja na Figura A -

15.

Note que os arquivos “BA.java”, “Executor.java”, “HTMLFormatter.java” (novo arquivo), “MetodosGenericos.java” e “config.properties” foram movidos para o pacote “arquivosComuns” (não estão mais nos outros pacotes).

Para acessar as propriedades do projeto e fazer outras alterações nas bibliotecas ou nos drivers, selecione o projeto Automação no Package e clique com o botão direito do mouse. No menu aberto entre em Properties. Veja a Figura A - 17 e a abaixo Figura A - 18.

Como última configuração, antes de iniciar a execução dos testes no ambiente, será necessário criar uma pasta chamada “logs” dentro do diretório de automação. As baterias de testes geram um arquivo de texto, e todos estão configurados para serem salvos no diretório: C:\automacao\logs. Veja como deve ficar a estrutura do diretório de automação na Figura A - 19.

Os logs criados têm as informações mais importantes para localizar os pontos de execução das ações do Selenium no teste, porém muitas outras informações de cálculos, criação de listas e outros métodos, ficam aparecendo somente no Console do Eclipse, porém o console é temporário, assim que você rodar outro teste ele é limpo e as informações anteriores são apagadas. Em alguns momentos pode ser interessante guardar as informações do console, para tentar identificar melhor o que está acontecendo. Para isso você pode configurar o Eclipse para exportar os dados do console e um arquivo de texto. Com isso toda vez que você rodar um script ele terá a console toda gravada nesse arquivo de texto. Você pode adicionar vários consoles num mesmo arquivo ou sobrescrever em cada execução. Para isso você deve criar no diretório de Automação uma pasta chamada “console” e dentro dela criar um arquivo txt chamado “console.txt”, com isso você já estará salvando os dados do console. Veja a Figura A - 20. Entre no menu Run -> Run Configurations, selecione o java que você deseja salvar os dados do console. Depois clique na aba “Common”, na área “Standard Input and Output”, você clica em “File System”, seleciona a opção “File” e indique o caminho do arquivo de texto do console:

C:\automacao\console\console.txt

Depois disso, você pode escolher se deseja adicionar sempre os resultados nesse mesmo arquivo, selecionando a opção “Append” ou deixá-la desmarcada, com isso a cada nova execução o arquivo “console.txt” será limpo e receberá novos dados. Depois clique em “Apply”. Com isso você já pode executar os testes que o console deste “.java” será salvo. Veja a Figura A - 21.

76

76 Figura A - 12. Download do Eclipse Figura A - 13. Criação do projeto

Figura A - 12. Download do Eclipse

76 Figura A - 12. Download do Eclipse Figura A - 13. Criação do projeto
76 Figura A - 12. Download do Eclipse Figura A - 13. Criação do projeto

Figura A - 13. Criação do projeto

77

77 Figura A - 14. Adição das bibliotecas e JARs

Figura A - 14. Adição das bibliotecas e JARs

78

78 Figura A - 15. Package Explorer do projeto
78 Figura A - 15. Package Explorer do projeto

Figura A - 15. Package Explorer do projeto

79

79 Figura A - 16. Referenced Libraries Figura A - 17. Propriedades do projeto

Figura A - 16. Referenced Libraries

79 Figura A - 16. Referenced Libraries Figura A - 17. Propriedades do projeto

Figura A - 17. Propriedades do projeto

80

80 Figura A - 18. Bibliotecas Figura A - 19. Workspace no diretório de automação

Figura A - 18. Bibliotecas

80 Figura A - 18. Bibliotecas Figura A - 19. Workspace no diretório de automação

Figura A - 19. Workspace no diretório de automação

81

81 Figura A - 20. Pasta com o arquivo de console Figura A - 21. Configurando

Figura A - 20. Pasta com o arquivo de console

81 Figura A - 20. Pasta com o arquivo de console Figura A - 21. Configurando

Figura A - 21. Configurando a exportação do console

82

4 Rodar o teste no Eclipse

Para que seja possível rodar o teste automatizado, deverá ser iniciado o servidor do Selenium.

Além disso, é preciso verificar se os dados da massa estão corretos no arquivo config.properties. Esse arquivo de configuração é usado pelo Eclipse para capturar alguns dados da massa do testador, na execução do script. Lembre-se que cada teste vai necessitar de uma alteração nesse arquivo, portanto verifique sua massa antes de executar os testes. Veja a Figura A - 22 e a Figura A - 23. Lembre-se que muitas outras informações podem ser adicionadas no “config.properties”, para que o script fique o mais genérico possível.

Veja mais informações importantes sobre os imports” e o “config” nos códigos no final deste guia.

CUIDADOS ANTES DE EXECUTAR:

O ideal é que cada testador tenha a sua própria massa de automação, assim não ocorrerão problemas durante a execução dos testes. Verifiquem nas tabelas de cadastro do SGE as massas de automação cadastradas e crie a sua própria baseada nessas (AUT1, AUT2 e AUT3), lembrando de criar sua própria estação e seus técnicos. Alguns scripts foram criados em estação específica, verifique no código.códigos no final deste guia. CUIDADOS ANTES DE EXECUTAR: É preciso estar atento na hora de

É preciso estar atento na hora de reutilizar os scripts, pois os scripts criados precisam que a Estação seja passada como parâmetro da busca, caso você não use esse filtro irá dar erro na execução do script. Caso tenha dúvida verifique a estrutura da massa de dados criada para os testes automatizados.criados em estação específica, verifique no código. Além da estação, é preciso estar atento à qual

Além da estação, é preciso estar atento à qual área técnica você vai enviar o BA, pois cada técnico tem sua área técnica de acordo com a estação, caso você abra um script que foi feito para rodar numa estação e área técnica, e você insere outra área no código, irá dar erro no script, o BA não irá aparecer no resultado da consulta de acordo com o que foi passado na restrição e o clique não será feito.da massa de dados criada para os testes automatizados. Preste atenção nos arquivos da baterias, que

Preste atenção nos arquivos da baterias, que os dados que ficam no “config.properties” são usados como parâmetros dos filtros, por isso, a área técnica que é passada “config.properties” são usados como parâmetros dos filtros, por isso, a área técnica que é passada no método de abertura de BA precisa corresponder com os dados do “config.properties”.

Exemplos:

1. Os testes com filtros foram criados na Estação AUT3 (AU, LA, TX), e os demais testes na AUT1 (área técnica TX e LA) ou AUT2 (área técnica EL e LA, contratada NORT). O estado é RN, a localidade é AUT e o COS é CAUT.

83

restricao = "BA_PROGRAMACAO.UF_PR like '"+UF+"'" + "and BA_PROGRAMACAO.COD_LOCALIDADE_PR like '"+localidade+"'" + "and BA_PROGRAMACAO.COD_ESTACAO_PR like '"+estacao +"'";

3. Código de chamada do abreBA (A área técnica passada para esse BA é TX, esse é o único campo no código que poderá ser alterado, por causa da estação e do técnico cadastrado. A estação, a UF e a localidade são passadas usando o valor que está no config.properties):

numBA = abreBA(logger,"VITRIA", docAssoc, "S", UF, locali dade , estacao , "TX "," ","A", 2);

Os scripts foram elaborados e executados no ambiente Sinergia. Além disso, os principais cadastros feitos têm a palavra automação ou uma parte dela, para facilitar a identificação da massa de automação. Verifique nas tabelas de cadastro no SGE.

Depois de verificar os pontos acima você pode executar os scripts.

No Eclipse, “Package Explorer”, clicar duas vezes sobre o arquivo (ex: TestRefresh.java). Clicar em Run->Run AS-> Junit test.

o arquivo (ex: TestRefresh.java). Clicar em Run->Run AS-> Junit test. Figura A - 22. Arquivo config.properties

Figura A - 22. Arquivo config.properties

84

84 Figura A - 23. Editando o config.properties IMPORTANTE Os imports das classes BA.java e MétodosGenericos.java

Figura A - 23. Editando o config.properties

IMPORTANTE

Os imports das classes BA.java e MétodosGenericos.java devem seguir o exemplo da Figura A - 24 abaixo:

devem seguir o exemplo da Figura A - 24 abaixo : Figura A - 24. Import

Figura A - 24. Import dos arquivos comuns

O método carregaProperties (destacado em vermelho na Figura A 25 abaixo) deve ser chamado com o caminho do arquivo config.properties a ser utilizado. No exemplo da figura, o prope