Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Faculdade de Tecnologia - FT
Limeira - SP
2010
ii
ORIENTADORA:
Profª. Dra. Regina Lúcia de Oliveira Moraes
Limeira - SP
2010
iv
DEDICATÓRIA
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.
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
Lista de figuras
Lista de tabelas
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
1.2. Objetivo
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.1. Confiabilidade
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
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
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.
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
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
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].
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.
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.
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
4.2.5. Selenium RC
4.3. Utilização
5. Estudo de Caso
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
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
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
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
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
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.
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
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
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
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.
Arquivos comuns:
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
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.
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
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.
Essa etapa era feita somente no teste manual, pois nos scripts esses dados eram
obtidos automaticamente no código e no arquivo “config.properties”.
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
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
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.
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
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
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.
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
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.
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
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).
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
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
8. Referências Bibliográficas
9. Anexos
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”.
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.
Extrair os arquivos para a pasta “C:\automacao”, conforme a padronização definida pela equipe de
automação. Veja a Figura A - 9.
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
3 Eclipse
Abrir o Eclipse.
O Eclipse solicitará o endereço do Workspace, que é onde serão salvos todos os seus projetos. Você
pode criar uma pasta chamada “workspace” dentro do diretório de Automação. Ex:
C:\automacao\workspace. Assim todos os arquivos relacionados à Automação ficarão num mesmo
diretório.
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”.
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
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.
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.
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.
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):
No Eclipse, “Package Explorer”, clicar duas vezes sobre o arquivo (ex: TestRefresh.java).
Clicar em Run->Run AS-> Junit test.
IMPORTANTE
10. Apêndices
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.
testador