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

Limeira - SP
2010
 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
10. Apêndices............................................................................................................ 86
 viii

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

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

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

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

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

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

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
“bugs” e 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 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 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 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 usuário pode interagir com a aplicação
por meio de um “prompt” ou “Shell” do 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 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 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 “drivers” e “stubs”, estes podem ser
desenvolvidos em vários níveis de funcionalidade, o “driver” chama o código
alvo, passa parâmetros e trata os resultados do código chamado, os “stubs”
representam 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

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

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.

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

Figura 8 – Selenium IDE

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

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 runs” e “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.

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

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 Melhoria na gestão, com Maior satisfação do
operacionais - ao maior visibilidade e cliente, em conseqüência
otimizar a alocação e o transparência sobre as da redução do tempo de
despacho das atividades operações e a força de resposta dos serviços,
e das penalizações por trabalho. correspondendo assim às
não-cumprimento de expectativas geradas.
tarefas.

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
1ª Capacitação Estudo da ferramenta Selenium e seu uso com
o Java.
2ª Gravação dos Scripts e Início da gravação dos scripts usando o
Exportação para Eclipse Selenium IDE no Firefox.
Criação dos métodos auxiliares e genéricos.
3ª 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
“clique” do 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).
Para cada BA, através de cálculos, identifica em qual coluna o mesmo será
apresentado e o detalha.
 37

No detalhamento, verifica se o BA em questão foi detalhado corretamente.

Depois, verifica se todos os BAs abertos estão na coluna Total (detalhando
todos e conferindo no detalhamento).
Realiza outra consulta Prazos dos BAs (Visualização por estrutura).
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).
Por último, verifica se todos os BAs abertos estão na coluna Total (detalhando
todos e conferindo no detalhamento).
Para encerrar exclui da base todos os BAs abertos.

TesteBAsSemExecutorSemEstrutra.java
Abertura de 2 BAs (... até 48h, 0h até 2h) que vão ficar em R (Situação “A
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).
Através de cálculos, identifica em qual coluna o BA está e o detalha. No
detalhamento, verifica se o BA foi detalhado corretamente.
Verifica se todos os BAs abertos estão na coluna Total.
Realiza outra consulta na “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 o BA deve ser apresentado).
Verifica se todos os BAs abertos estão na coluna Total.
Para encerrar exclui da base de dados todos os BAs abertos.

TesteRefresh.java
Abertura de 1 BA (6h às 12h).
Realiza uma consulta na “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.
Abertura de outro BA para a mesma coluna.
Clica no botão de Refresh.
Identifica em qual coluna o BA está e o detalha. Verifica se a quantidade foi
incrementada corretamente.
Para encerrar excluímos da base de dados todos os BAs abertos.

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.
Para encerrar exclui da base de dados todos os BAs abertos.

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

Realiza a consulta na “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.

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

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.

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.properties” foi 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.properties” ser 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
102h37min 1262h20min
Total
(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.sleep” era 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.properties” e 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 BAs” serem 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).

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

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

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 “logoff” na Shell até o
“login” para 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

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.

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.

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.

Figura 20 – Gráfico: Limpar a massa de dados

O comando “deleta” usava 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 “select” para ver se o BA foi
 54

aberto ou se ocorreu algum erro na Shell no sqlplus. Esse “select” retornava 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.

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 BAs”
no 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

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

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
“xpath” de 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 BAs” no 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

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 A” e “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 BAs” no

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.

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

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.

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 - Web application testing system. Disponível em:

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 -
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.
[13] Caetano, C. TestExpert – Blogs – Introdução à Automação de Testes
Funcionais. Disponível em: http://www.testexpert.com.br/?q=node/178 Último
acesso em: 30 mai. 2010.
[14] BURNSTEIN I. Pratical Software Testing: A Process Oriented Approach.
 65

Springer-Verlag, Berlin, 2002.

[15] Beust, C.; Suleiman, H. Upper Next Generation Java™. Testing TestNG and
Advanced Concepts. Addison-Wesley, 2008.
[16] OpenQA. How Selenium Works. Disponível em:
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 and Love the Unit Test). Disponível em:
http://cmcpb.blogs.ilrt.org/2007/09/17/writing-effective-javascript-code-or-how-i-
learned-to-stop-worrying-and-love-the-unit-test/ Último acesso em: 30 mai. 2010.
[18] Pimentel, F. - Rodando scripts do Selenium no Visual Studio. Disponível em:
http://fpimentel88.wordpress.com/2009/01/31/rodando-scripts-do-selenium-no-
visual-studio/ Último acesso em: 30 mai. 2010.
[19] SeleniumHQ - Introducing Selenium - Supported Browsers. Disponível em:
http://seleniumhq.org/docs/01_introducing_selenium.html#supported-browsers
Ú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.
[21] Selenium Grid – How it works. Disponível em: http://selenium-
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-
bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-
/USD/ViewProductDetail-Start?ProductRef=jdk-6u14-oth-JPR@CDS-
CDS_Developer Último acesso em: 30 mai. 2010.
[23] Eclipse Downloads. Disponível em:
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/
R-3.4.2-200902111700/eclipse-SDK-3.4.2-win32.zip Último acesso em: 30 mai.
2010.
[24] TestNG – Download. Disponível em: http://testng.org/doc/download.html Último
acesso em: 30 mai. 2010.
[25] CPqD – CPqD Workforce. Disponível em:
http://www.cpqd.com.br/site/ContentView.php?cd=570&Busca=workforce.
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

Figura A - 1. Propriedades do sistema

Figura A - 2. Variáveis de ambiente

 68

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:

http://release.seleniumhq.org/selenium-remote-control/1.0.1/selenium-remote-control-1.0.1-dist.zip.
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

Figura A - 4. Download do Selenium

Figura A - 5. Download do Selenium IDE

 71

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

Figura A - 7. Selenium IDE no menu Ferramentas

 72

Figura A - 8. Janela do Selenium IDE

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

 73

Figura A - 10. Prompt com Selenium Server

Figura A - 11. BAT para executar o Selenium Server

 74

3 Eclipse

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

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR1/
eclipse-jee-galileo-SR1-win32.zip. Veja a Figura A - 12.

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

Figura A - 12. Download do Eclipse

Figura A - 13. Criação do projeto

 77

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

 78

Figura A - 15. Package Explorer do projeto

 79

Figura A - 17. Propriedades do projeto

Figura A - 16. Referenced Libraries

 80

Figura A - 18. Bibliotecas

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

 81

Figura A - 20. Pasta com o arquivo de console

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.

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

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.

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

2. Código da restrição (Usado com o “config.properties”):

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

Figura A - 22. Arquivo config.properties

 84

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:

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 properties utilizado é o que está no pacote arquivosComuns.
Para utilizar o novo log (no formato HTML) é preciso alterar o trecho antigo pelo trecho destacado em
verde na figura abaixo:
 85

Figura A - 25. Criação do log

No SVN, os arquivos já se encontram na nova estrutura.

Os arquivos dos pacotes testeSinergia.weblince.prazos e testeSinergia.weblince.logOperacoes já
contemplam as alterações acima descritas.
 86

10. Apêndices

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

 87

Apêndice B – Tabela de tempos para comparação do teste manual e o

automático
 88

As células em cor verde representam que os testes foram feitos com o detalhamento
de todos os níveis de todos os BAs, por isso caiu o desempenho.
As células em laranja representam os testes que tiveram mudança no detalhamento,
agora o detalhamento de um único BA é feito em todos os níveis da estrutura
organizacional, a partir disso foram feitos os detalhamentos dos outros
BAs nas colunas normalmente, pois a grade de vencimento já se encontrava no
último nível da estrutura organizacional.

Apêndice C – Tabela com as configurações dos computadores usados na

comparação entre os testes

Micros usados na comparação:

A – Micro Estagiário (IE 6 ) B - Micro Funcionário (IE 7)
Pentium 4 - 1.500 MHz - 1 GB RAM Pentium D - 2.793MHz - 1GB RAM
C - Micro Automação (IE 7)
Pentium 4 - 1.500 MHz - 1GB RAM
Observação: O micro de automação não tinha mais nenhum programa rodando (tirando os
processos comuns do sistema e os do antivírus) usando o processador junto com o Eclipse e
o Selenium Server. Basicamente o processador ficou dedicado aos processos relacionados
com o teste automatizado.
(I) (II) Os testes realizados no servidor e nos outros micros já estavam com a métodos
genéricos atualizada na visualização por estrutura para a melhora do desempenho.
Além dessa mudança, também já estava com a alteração do log.
A estrutura do workspace de automação também já estava atualizada.
(III) Script executado no IE 6.
 89

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

testador

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

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

 90

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

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

 91

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

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

 92

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

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

 93

Figura F - 2. Diagrama de classes geral do projeto