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

Este ano foi muito importante para o meu aprendizado.v AGRADECIMENTOS Agradeço a Deus por ter fé em mim mesma e no que posso fazer. com quem eu trabalhei no ano de 2009. Agradeço à professora orientadora Regina Lúcia de Oliveira Moraes. Agradeço por ela acreditar em mim quando resolvi dar o meu primeiro passo na área de Testes de Software. . agradeço à minha coordenadora de estágio Beatriz Cardoso Mamede Bernardi. por ter perseverança e persistir no meu sonho. 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. pelas descobertas feitas no Projeto de Automação e pela paciência e boa vontade em compartilhar os seus conhecimentos com toda a equipe. Agradeço em especial ao analista de teste Paulo Miguel do Amaral Rosa. por lutar por nós alunos e buscar sempre o melhor para nossa Faculdade. Agradeço a toda a equipe de testes do CPqD Workforce.

....... 66 10....................................... Anexos ..........................................vi Sumário 1......................................................................................................................................................................... Conclusão ............ Automação de Testes........................ Resultados .................................................................................................... Referências Bibliográficas ................................................... 86 . Introdução ................................................................... 2 2.......................... 10 4................... 61 8................................................. Apêndices................... 46 7................... 5 3.. Estudo de Caso ........................................................ Conceitos de Testes de Software ................................................... 64 9..... Ferramenta para Automação de Testes – Selenium ................................. 17 5....................................................... 27 6..................................................................................................................

.. 59 7......................................1.................. Introdução à Ferramenta .. Etapa 4 – Leitura do roteiro de teste .... 43 6.............................................................................2..2..................................... Apêndices............ Anexos .......................................... Referências Bibliográficas .... Utilização . Selenium Core ......... Eclipse ............ 55 6................................2........................................ Confiabilidade ..................................................... Instalação no Ambiente de Testes ........................................................ 51 6........................ 27 5....................3...................... 66 Anexo A – Guia usado para a preparação do ambiente de testes automatizados ........................................3.......... 54 6.... 28 5................................1............................................. 13 4............1................................ 50 6..2.......................................................... Etapa 2 – Preparar planilha auxiliar para os BAs ....................................... 6 2....................... 3 1..........................5................................... 25 4..................... 17 4.................. Etapa 7 – Abertura dos 17 BAs ...................................................................................... Selenium IDE ............. 69 3 Eclipse ....................................................................................................... Etapa 8 – Consulta na régua de prazos..................... Análise de Resultados ...... Etapa 3 – Preparar a shell para o sqlplus.. 49 6....................... 22 4................... 64 9.5..... 86 ...1.............................................. 36 5........4............... 7 3..................1...................vii Índice 1........1.... 3 2...................13........................................... 10 3......................................... Considerações finais . 46 6...................12..................................................................... Resultados .........2....2.......... 48 6.................................................................. Selenium Core....................................14........ Testes de Software.........................................5..........................2....... Descrição do Sistema................... 56 6...........................................6................................... 2 1..................................................................... 82 10............................................................8................................................... Verificação e Validação ........................................ 48 6........ visualização por executor . 52 6......................................................5.................9....... 5 2............................................................. 23 4.... Ferramenta para Automação de Testes – Selenium ........................ 57 6........................10............................................................................................................................................................................ Estudo de Caso ........7.................................... 17 4................... 23 4.. 27 5.................... Etapa 13 – Tempo de perda com erro ................ Protótipos dos Scripts.................................. 74 4 Rodar o teste no Eclipse ...... 61 8....................11..... 26 4........................... 52 6............... 53 6..............................................................................................................2.... Etapa 1 – Preparar SQLs para a abertura dos BAs......2.............................................3........... 26 5. visualização por estrutura.................................................................................. 29 5....................................................................... Etapa 12 – Deleção dos BAs abertos pelo script .............. Conceitos de Testes de Software ...........................................................3.................... Conclusão ...................................... Explicação rápida sobre os 18 scripts criados.............................. Objetivo ............. Motivação .... Contexto e Motivação ......................................... Selenium RC .............................4.................. visualização por executor .......... Etapa 6 – Limpar a massa de dados (deleta) ........................... 25 4... Tipos de Automação............. Java .............................3......................................2............... Automação de Testes............... Etapa 9 – Consulta na coluna total... Etapa 5 – Preparar a escala de trabalho dos técnicos da massa ...... visualização por estrutura ....................................................................................................................................................................................................... Introdução ................. 66 1 Java SE Development Kit ......................2...... 58 6................................................. Etapa 10 – Consulta na régua de prazos..................... 5 2.............. Selenium Remote Control ......................1.............. 66 2 Selenium IDE...................................................... Etapa 11 – Consulta na coluna total...................

............................................................. 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 ....... 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 ........................................ 92 ........viii Apêndice A – Planilha auxiliar para abertura de BAs para o teste manual....

........... 81 ....8.................................... 73 Figura A .................................................................................................................... 57 Figura 25 – Gráfico: Weblince – total – estrutura .............. Eclipse e Selenium............... Diretório de Automação ............ 71 Figura A ............... Prompt com Selenium Server ................... 77 Figura A .......... BAT para executar o Selenium Server................ Download do Selenium .......................................................................................... 70 Figura A .............................................. 67 Figura A .....................................16. 21 Figura 9 – Execução do Selenium Server ........... Eclipse e Selenium ......................................................................4..............14.......9................. 76 Figura A .................................................. 67 Figura A ......................... 24 Figura 12 – TestNG......................................................................................................................estrutura ................................................................................................. Selenium IDE no menu Ferramentas ............. Pasta com o arquivo de console ....................................................................................................................................... 39 Figura 14 – Gráfico: Resultado final da comparação .. 25 Figura 13 – Menu de Escolha de Scripts para Execução Automatizada .................................. 72 Figura A ......................................................2....................................6............ 53 Figura 21 – Gráfico: Abertura dos 17 BAs .............................. 71 Figura A ....11.....18............................................................................................... 12 Figura 5 – Paradigmas para automação ...................................20.. Variáveis de ambiente . Workspace no diretório de automação ..................................12....................... 76 Figura A .................... 16 Figura 6 – Como funciona o Selenium ..... 79 Figura A ...........................3........................... 52 Figura 20 – Gráfico: Limpar a massa de dados .................. 72 Figura A ...... Download do Selenium IDE ............ 6 Figura 2 – Verificação e validação dinâmica e estática .5.................................................................................................................................... Janela do Selenium IDE .............. Propriedades do projeto.................................... 19 Figura 8 – Selenium IDE ............. 58 Figura 26 – Gráfico: Exclusão dos BAs .. 80 Figura A .................... 80 Figura A .............................................................................. Instalação da extensão no Firefox . Download do Eclipse ................................. 81 Figura A .executor ............ 68 Figura A ...................................................... 9 Figura 4 – Workbench de testes .........................................1........................................... Referenced Libraries ........................ 47 Figura 15 – Gráfico: Preparar os SQLs para abertura dos BAs ............................................................................................ 55 Figura 23 – Gráfico: Weblince – total – executor ........ 51 Figura 18 – Gráfico: Leitura do roteiro ...................... 50 Figura 17 – Gráfico: Preparar a Shell do sqlplus para a abertura dos BAs .......................................................................15. 70 Figura A ..................................................................................................... 59 Figura 27 – Gráfico: Perda com erro .................................7... 7 Figura 3 – Fases de teste – Modelo em V .........19........ Adição das bibliotecas e JARs.......13. Package Explorer do projeto.................... Editar variável de sistema ............ 56 Figura 24 – Gráfico: Weblince – grade de vencimento ..................17............... 18 Figura 7 – Interface do Selenium Core .............10.................. 73 Figura A ................................................... 49 Figura 16 – Gráfico: Preparar planilha para abertura dos BAs ............................................................... 59 Figura A ...................... 21 Figura 10 – Selenium Grid em vários ambientes ........ 22 Figura 11 – JUnit..... Configurando a exportação do console ................................ Criação do projeto ................. Bibliotecas .................. 79 Figura A .................... 54 Figura 22 – Gráfico: Weblince – grade de vencimento ..........................21....ix Lista de figuras Figura 1 – Entraves à Qualidade ................................................................................................................. 51 Figura 19 – Gráfico: Preparar escala de trabalho dos técnicos .................................................................... 78 Figura A ........................ Propriedades do sistema ................

............................. 84 Figura A .......... Import dos arquivos comuns .................25. Diagrama de classes geral do projeto .............................. 92 Figura F ......... Ação de inserir os dados da massa nos filtros da consulta .............................................3..... 89 Figura E ....4....... Editando o config.................... Ação de localizar o BA na grade de vencimentos ........................ 93 .........23...................................................... 90 Figura E ...5....22.................6.................1.2...................................1. 91 Figura E .......... Ação de localizar a estrutura organizacional do BA...........properties ........ 84 Figura A ...... 85 Figura E ...2...................... Criação do log.. Arquivo config.............................. 91 Figura F ............................................... Ação de localizar o executor do BA .......... Visão geral das ações do testador .................................properties ................. 89 Figura E ..... Ação de localizar o BA e seus dados na área de detalhamento ....... 90 Figura E ....24............ Diagrama geral dos scripts criados e o menu ....x Figura A .................. 83 Figura A .....

.............................. 43 .......................................................................................... Benefícios mais importantes do CPqD Workforce .......... Esforço no projeto de Automação ...................... 28 Tabela 03...........................................xi Lista de tabelas Tabela 01. 42 Tabela 05................... Etapas para o processo de automação ........ Quantidade de linhas de código ......................... 5 Tabela 02........ Entraves à Qualidade ......................... 30 Tabela 04............

enfim ela está em qualquer ação que envolva o ser humano. seja nos estudos. no lazer. em todas as áreas de atuação. . na área pessoal. 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.xii Resumo A qualidade é algo que nos últimos tempos tem sido buscada incessantemente pelo homem. 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. no trabalho. na saúde. Seguindo essa busca por qualidade dentro de um trabalho. temos aqui neste documento.

in short it is in any action involving the human being. health. quality has been pursued incessantly by the humanity. leisure. we have in this document. in all acting areas . personal lives. This work presents a testing process that can be improved by the use of automated testing as part of software validation. such as education. work. Following the search for quality in a work.xiii Abstract In recent years. . the search for quality in software development.

entre outros. podem ocorrer problemas no projeto de testes. neste caso. . mais mensurável. Porém. com o máximo de qualidade. Dessa forma. Assim como as empresas buscam a qualidade nos seus produtos. o próprio processo de teste é passível de falhas e. na execução dos roteiros. e com uma relação custo-benefício boa para a empresa e ótima para o usuário final. Porém. 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. Por isso. mas criar uma forma de tornar esse sistema real mais organizado. Com o advento de novas tecnologias elas conseguem aperfeiçoar qualquer processo de produção utilizando máquinas e computadores. pois ao usar o sistema irá encontrar muitos defeitos e alguns podem trazer impactos muito graves. nesse trabalho. Ela vai garantir a qualidade necessária ao sistema e essa garantia será feita com base na solicitacão do cliente. foi escolhida uma ferramenta de automação e este uso será apresentado em um Estudo de Caso. as empresas de tecnologia também o fazem e é dessa forma que a equipe de testes entra no processo de desenvolvimento de um software. eficazes e eficientes permitindo que o produto gerado ou o serviço seja produzido da melhor maneira.2 1. na interpretação dos casos de usos. para controlar essa importante quantidade de informação é preciso criar sistemas de software robustos. a ponto de permitir às empresas poder reduzir ao máximo possível os seus custos e com isso poder gerar mais lucro. 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. sendo uma equipe humana. mais palpável. Como parte dessa busca pela melhoria de um processo de teste. ela é passível de erros. 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. o software não terá sua qualidade garantida e quem pode perder muito é o cliente. na criação dos roteiros. Ou seja.

para permitir ao software criado ser testável em todos os seus aspectos. a equipe de testes também precisa buscar novas formas de testar um software. ele ainda não é feito adequadamente.1. Para isso. 1. por isso hoje cada vez mais.2. por isso. em muitas empresas. sendo deixado em segundo plano. a automação vem sendo aplicada. Contexto e Motivação Com o aumento da demanda por produtos de software e novas tecnologias. Se um software desenvolvido não pode ser testado. Eles são implementados por ferramentas de automação. garantindo uma maior cobertura de testes para o software em desenvolvimento. quando na verdade deveria ser uma prioridade da empresa. pois ela permite a automatização de vários pontos de um processo de teste. como também. O processo de testes de software é caro. a obtenção de uma boa cobertura é inviável devido ao tempo reservado para o processo de testes. Sendo um processo caro é preciso ser bem executado. principalmente no ramo de telefonia. Objetivo Considerando o contexto apresentado. proporcionando uma maior rapidez de entrega para o cliente. garantindo não só um maior ganho de tempo pela equipe de testes diminuindo o seu custo. A importância dos testes e da automação desta atividade motivou a aluna a estudar este tópico. 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. as empresas de TI constantemente precisam buscar novas formas de desenvolver software.3 1. Manualmente. para acompanhar a demanda dos clientes. porém sem perder a qualidade do produto. 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 sistema é crítico e controla toda a força de trabalho de empresas de telecomunicações. Da mesma forma. o objetivo deste trabalho foi aplicar testes automatizados em alguns pontos do processo de teste de um sistema real. podemos dizer que ele tem sérios problemas. o desenvolvimento se relaciona cada vez mais com os testes. uma forma de ter mais qualidade no processo. É nesse contexto que surgem os testes baseados em scripts. .

é o CPqD [02]. onde o estágio da aluna foi desenvolvido. o Selenium [01]. tanto os relacionados com suporte aos clientes. uma fundação de direito privado. e o sistema utilizado nesse trabalho é o CPqD Workforce. quanto suporte aos equipamentos integrantes da rede de comunicação avariados ou em manutenção. 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. No estágio surgiu a oportunidade de se utilizar uma ferramenta de automação. 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. . pois foi a ferramenta escolhida pela empresa para se trabalhar com automação de testes. ele controla todos os serviços técnicos realizados pelos funcionários dessas empresas. entre outras.4 O sistema controla essa força de trabalho dando um suporte para várias operações dentro das empresas de telecomunicações. A empresa. para melhorar o desempenho dos testes.

Tabela 01. Por exemplo. mostrando assim o universo dos entraves à qualidade. Uma característica do sistema que pode levar a um erro de sistema. Estes conceitos são importantes para se compreender a importância do processo de testes dentro do desenvolvimento de produtos de software. isto é. a falha em iniciar uma variável pode levar a um valor errado quando esta for usada. É a diferença entre a resposta obtida e a resposta esperada pelo sistema de acordo com a sua especificação. Um evento que ocorre em algum momento.1. Ela torna o comportamento do software consistente. Erro de sistema Defeito do sistema A Figura 1 na próxima página resume estes conceitos e as relações que eles possuem uns com os outros. 2. Entraves à Qualidade Termo Engano Falha de sistema Descrição Comportamento humano que resulta na introdução de falhas ou um resultado incorreto em um sistema. 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. porém a Tabela 01 [03] [04] [05] mostra alguns termos muito importantes para os testes de software e relacionados à confiabilidade.5 2. Conceitos de Testes de Software Neste capítulo serão apresentados alguns conceitos básicos relacionados com Testes de Software. . na verdade. conforme especificado. A falha. quando o sistema não fornece um serviço conforme esperado por seus usuários. O assunto é extenso. é a manifestação no software de um engano cometido pelo desenvolvedor.

diagramas de projeto e o códigofonte.6 Figura 1 – Entraves à Qualidade 2. A validação determina se estamos criando o produto correto. Ocorrem durante todo o processo de desenvolvimento. o nível de confiabilidade muda de acordo com a situação. para garantir a qualidade do produto. Na segunda.2. 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. e a abordagem dinâmica. Porém. citam- . É 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. pois isso faz as empresas liberem produtos de software sem estarem totalmente testados e depurados. Também devemos lembrar o fato da liderança de um mercado. pode tolerar um sistema apresentando falhas desde que não sejam muito prejudiciais ao uso esperado do sistema. Verificação e Validação V & V [03] é como são conhecidos os processos de verificação e validação de um software. 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. onde verifica-se e valida-se executando o sistema. durante cada fase do processo de software. como também podem ser feitas análises automatizadas. sendo verificados documentos como os de requisitos. Na primeira abordagem pode-se citar a Inspeção ou Revisão por Pares. 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.

7 se os Testes de Software. 2. por meio de diversos testes. Os dois testes se complementam na verdade. Teste de verificação de defeitos mostra as inconsistências entre o programa e sua especificação. Observe a Figura 2 [03]. que podem ser aplicados no código durante a etapa de . Os testes podem ser classificados em dois tipos [03]: Teste de validação mostra para o cliente que o software atende aos requisitos. onde são usados os dados de testes e analisadas as saídas do software observando o seu comportamento e sua utilidade operacionalmente. porque exercita o programa usando dados reais baseados nos dados do cliente ou até mesmo fornecidos por eles. não existe uma regra rígida para definir os dois durante o processo geral de testes. Assim. pois durante os testes de validação você encontra defeitos. 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.3. Testes de Software O objetivo desse processo é descobrir falhas ou defeitos o mais cedo possível. e durante os testes de verificação de defeitos você consegue validar os requisitos.

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]. Podem ser grandes grupos de classes. o teste irá garantir ao cliente e também ao desenvolvedor que o software atende aos requisitos e está pronto para o uso. níveis de teste. subsistemas ou somente componentes. garantir a qualidade do produto. Teste de sistema [06]: são testados todos os componentes integrados incluindo outros sistemas. Assim. caso contrário. Além disso. entre outros. gerando um custo muito grande de reteste e um desperdício de tempo para a equipe de testes [09]. Teste de regressão [08]: é retestado o sistema depois de um componente novo ser integrado ou parte do sistema receber alguma alteração. além dos diversos tipos de testes. 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. aqui já se verifica os defeitos relacionados a problemas nas interfaces. como foi dito anteriormente. Além das fases citadas. grupos de classes (clusters). . Enfim. Teste de integração [06]: são testadas as integrações entre os componentes do sistema e as suas interfaces. 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. 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. pois o processo de testes possui uma metodologia composta de técnicas de teste. Serve para verificar se a parte inalterada do sistema que estava funcionando bem na versão anterior ainda continua funcionando adequadamente. Aqui é testado o sistema a ser entregue ao cliente e já ocorre a validação dos requisitos da especificação do sistema. Podem ser funções ou métodos de um objeto. perde-se muito tempo reexecutando partes inalteradas do sistema sem nenhuma relação com as partes alteradas. é garantido que as novas alterações não causaram a regressão do sistema na nova versão.8 desenvolvimento e também nos protótipos ou no próprio sistema.

agregamos mais valor ao processo de testes e ao profissional que irá realizar os testes de regressão. A equipe de testes normalmente trabalha mais com a fase de sistema e regressão. seja otimizado. teste de segurança. Também classificando quanto aos tipos de teste. teste de instalação e teste de recuperação. teste de desempenho. O foco deste trabalho são os testes de sistema e os testes de regressão. podemos citar o teste funcional. 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. 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). as fases de unidade. componente e integração são realizadas pela equipe de desenvolvimento do sistema. Dessa forma. . teste de usabilidade. teste de carga (stress). O modelo em “V”.9 Normalmente. teste de portabilidade. pois será preciso um conhecimento maior do código. pois é nesse tipo de teste onde podemos melhor aplicar os conceitos de automação de testes. principalmente este último. teste de confiabilidade.

retorno mais rápido para os clientes e para os desenvolvedores sobre o resultado de um teste. entre elas. porém a partir do momento em que a equipe já estiver preparada para usar as ferramentas de automação. É 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. um caso de teste para desempenho ou carga. mas também para não permitir que a falta de recursos financeiros em um projeto prejudique a fase de testes. fazer um bom reuso dos casos de teste já prontos. trabalhar com estratégias de testes baseadas em riscos (isso irá aumentar a eficácia dos testes). redução de tempo e esforço da equipe de testes (o que resulta na redução do custo total da equipe). É claro. 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). implementar a automação em um processo de testes também não é fácil e tem um custo. portanto utilizar técnicas para reduzir esse custo é essencial. os benefícios da automação começam a surgir. São muitas as razões para se implantar a automação de testes. não somente para aumentar a qualidade do teste e diminuição de seu tempo. e utilizar ferramentas e outras metodologias para melhorar a eficiência dos testes. Automação de Testes O custo de implantar uma equipe de testes é grande. 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. neles são repetidas centenas de vezes a mesma operação de cadastro. mas outras demandam mais tempo. ou talvez nem possam se beneficiar da automação. e o testador ainda correria o risco de inserir alguma informação . dentre outras. Fazer isso manualmente levaria muito tempo.10 3. Podemos citar como exemplo a ser automatizado. Existem algumas atividades dentro dos testes são facilmente automatizadas. pode custar até 50% do custo total do desenvolvimento [03] [06]. integrar a equipe de testes e desenvolvimento (isso ajuda a criar códigos testáveis). este em princípio pode ser maior do que continuar a usar o método tradicional. melhora do processo de testes. possibilidade de se trabalhar com uma combinação muito grande de testes. somente com alteração de alguns dados. aumento da eficácia e eficiência dos casos de teste da equipe.

pois seria muito desestimulante realizar um teste repetitivo como esse. Normalmente. se ela fica menos custosa com a automação. pois na verdade você vai retestar algo já testado anteriormente e que estava funcionando bem. e qual o custo de obter ou construir uma ferramenta para dar suporte à automação [09]. para criar um Workbench (conjunto de ferramentas que integradas irão ajudar no processo de testes) completo para testes. sem contar o fator psicológico. somente em sistemas de grande porte encontramos uma estrutura completa como essa. Assim. Esta escolha pode ser baseada nas dependências entre os componentes de software. O teste de regressão já representa um prejuízo direto. Analisando os dois exemplos. principalmente nos casos dos casos de teste não apresentarem problemas.11 errada. qual a dimensão da atividade requerida. É preciso analisar o valor de cada atividade e o seu custo corrente para o teste. 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. 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. A automação aqui reduziria o tempo de custo da reexecução. Neste caso. Veja um exemplo de Workbench completo na Figura 4 [03] na próxima página. Outro exemplo pode ser um teste de regressão. . podemos notar que algumas atividades necessitam fortemente de automação. leva-se muito tempo [03].

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

o teste automatizado irá se comportar como um usuário normal. Tipos de Automação A automação pode ser aplicada de várias formas [13] [11]. Eles precisam gerar códigos padronizados para os testes automatizados poderem rastrear com precisão as ações dos usuários. pois quando se trabalha com um processo de testes. dentre outros elementos. dessa forma essas informações podem ser usadas na documentação. Portanto a experiência dos programadores é fundamental para o código gerado ser automatizável. selecionar. pois existem muitas tecnologias. coordenadores. quando se pensa em automatizar testes em um sistema a implementação precisa estar preparada para receber a automação. Além disso. o processo de testes precisa ser estável.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. um teste automatizado pode dificultar o desenvolvimento da documentação. que podem ser usados para o desenvolvimento de um sistema. O Sistema em Testes (SUT) [11] também precisa ser previamente analisado. responder as opções das janelas de mensagens ou alertas. mensagens de erros/acertos. pois poderá prejudicar o resultado dos testes e até mesmo a sua execução. pois somente assim é possível trabalhar eficientemente com a automação. Também é preciso verificar se o sistema exige um ambiente específico no qual o teste automatizado não possa ser replicado. 3. Podemos citar sistemas que necessitem de outros produtos de software embarcados ou aqueles em tempo real. A documentação do teste automatizado também precisa ser analisada. selecionar itens em caixas de opção e de seleção. interfaces. Nesse caso. e é exigido uma documentação mais detalhada. analistas e testadores.1. Quando ela é baseada na interface gráfica do sistema. porém cabe sempre à equipe responsável. entre outros. Portanto. é preciso criar maneiras de se copiar as telas (“screenshots”) e gerar logs dentro de cada ação realizada no teste. localização de variáveis. tais como. Existem muitos prós e contras sobre a automação de testes. Quando ela é . a melhor forma de implantar a automação em um sistema em testes. analisar em conjunto. inclusive com os desenvolvedores. linguagens. percorrer menus. abrir e fechar opções. fazendo todas as ações possíveis na tela do sistema. aos projetistas.

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

elas podem ser usadas em conjunto para criar os testes automatizados: Selenium Core. Selenium Grid. entre outras. Java. Introdução à Ferramenta A ferramenta Selenium [01] é um framework open-source distribuída pela equipe OpenQA [01]. O Selenium foi utilizado no projeto de Automação de Testes durante o estágio no CPqD. como foi apresentado na seção anterior.1. Ferramenta para Automação de Testes – Selenium Neste capítulo será apresentada a ferramenta de automação Selenium IDE e Selenium Remote Control. 4. A automação explorada pelo Selenium é baseada na Interface Gráfica do sistema. Através desse projeto. pois os desenvolvedores de teste podem trabalhar diretamente com o Selenium RC e fazer as mesmas ações contempladas no Core. a maioria dos usuários o usa trabalhando com o Windows e o Firefox ou Internet Explorer. Rails. O Selenium tem várias ferramentas. uma organização que trabalha com projetos voltados para a qualidade de software. permitindo usá-lo nos mais variados sistemas Web. pode trabalhar com Python. Selenium Remote Control (RC). tudo vai depender do tipo de sistema a ser testado e do navegador (browser) a ser usado para os testes automatizados. O Selenium Core será descontinuado. A Figura 6 [16] na próxima página apresenta um esquema do seu funcionamento. É uma ferramenta de suporte para o gerenciamento de testes automatizados para sistemas Web. . foi feito o estudo de caso apresentado neste trabalho. O Selenium trabalha de várias formas diferentes.17 4. porém. Acredita-se que seja devido ao fato de ainda serem muitos os sistemas desenvolvidos para o sistema operacional Windows. Cubic Test e o Bromine. Selenium IDE. Foi desenvolvido para ser executado em vários browsers e plataformas. uma grande vantagem se a equipe de testes trabalha com sistemas escritos em linguagens diferentes. nas pesquisas realizadas. O Selenium é capaz de reconhecer muitas linguagens de programação.

18 Figura 6 – Como funciona o Selenium .

No centro tem-se o código HTML gerado pelo IDE. A Figura 7 [17] apresenta a interface do Selenium Core. No canto direito são apresentados os controles do Core (Selenium TestRunner). os botões para executar. de acordo com o teste. No canto esquerdo tem-se a suíte de testes será executada no sistema (deve ser gravada antes pelo Selenium IDE). e se estão corretos ou não. O vermelho aponta uma parte com erro. com isso pode-se acompanhar o andamento da execução do teste. Figura 7 – Interface do Selenium Core . exatamente como o usuário iria executar. O Core usa cores para mostrar os passos já realizados. o maior é onde fica o sistema a ser testado e na parte superior tem-se três divisões.19 O Selenium Core permite que os testes sejam executados diretamente no navegador escolhido. Ele cria um navegador com quatro frames separados. pausar a aplicação e outras opções. o verde mostra que o teste passou sem problemas.

O IDE é quem faz as gravações dos scripts de testes a serem executados nas outras ferramentas. Incorpora-se ao código exportado pelo IDE os comandos. Além disso. pois é algo inerente ao navegador e não ao sistema em si. PHP. se for feita alguma ação diferente da esperada pelo sistema o IDE não vai gravar. na verdade. Os scripts gravados são. ele utiliza a porta 4444 do computador para o servidor [18]. O Selenium RC permite incrementar os testes gerados pelo IDE utilizando outras linguagens de programação. Um exemplo de gravação é apresentado na Figura 8 na próxima página. pois o que não for possível capturar pelo IDE ou até mesmo comparar. todas as ações feitas pelo usuário no sistema Web. . Perl. Ele deve sempre ser executado antes dos testes se iniciarem. ele retira o trabalho de programar todas essas ações do usuário. o fechamento do navegador pelo botão fechar. O RC tem uma Interface de Programação de Aplicativos (API . Alvo e Valor). bibliotecas da linguagem com os quais se estiver trabalhando. 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. No site de documentação do Selenium pode ser encontrada uma tabela com a lista de navegadores e sistemas operacionais suportados pela ferramenta [19]. por exemplo. além do driver servidor.20 O Selenium IDE é uma extensão para o Firefox. observe a Figura 9 na próxima página. porque é utilizado em conjunto com as outras ferramentas. Essa é a vantagem de usar o IDE. assim como não grava. Java. Através dessa exportação é possível executar os casos de testes gravados no Firefox pelo IDE. Deve-se acompanhar o andamento dos testes pelo prompt. C#. em outros navegadores utilizando o Remote Control. sendo uma ferramenta base para todo o framework Selenium. o selenium server. Isso permite ao seu teste flexibilidade.Application Programming Interface) e drivers cliente para as seguintes linguagens: HTML. Portanto. 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. ele permite ao teste ser exportado para outras linguagens de programação. Python. Normalmente. A ferramenta grava todas as ações ligadas ao teclado e ao mouse quando o usuário interage com o sistema. e Ruby.

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

22 O Selenium Grid é como o Remote Control. Figura 10 – Selenium Grid em vários ambientes Somente com o Grid é possível fazer testes em paralelo com o Selenium. Este é quem vai executar a ação no RC de verdade. elas podem ser usadas em conjunto com o Selenium. O funcionamento do Grid é apresentado na Figura 10 [21]. tudo paralelamente controlado pelo Hub do Selenium Server. O Java tem as ferramentas de teste “TestNG parallel runs” e “Parallel JUnit”. 4. Gera várias instâncias para o Selenium Server. Instalação no Ambiente de Testes A instalação da ferramenta no ambiente de testes seguiu a sequência dos subitens abaixo relacionados. limitando a concorrência em cada RC e distribuindo os testes por toda a infra-estrutura do Grid.2. porém permite que mais de um teste seja executado ao mesmo tempo [20]. isso permite rodar o mesmo teste em máquinas diferentes. navegadores diferentes e sistemas operacionais diferentes. A instalação desses produtos de software foi necessária devido . O Hub vai gerar um proxy para cada ação a ser executada no navegador e delegar essa ação para algum RC ocioso.

Caso ele não esteja disponível na versão. este é um pacote usado pelo JUnit. mais conhecida como Eclipse Ganymede. Mais detalhes são apresentados no Anexo A.2.1. somente sendo necessário adicioná-lo às propriedades dos projetos.2.java”. pois ela pode oferecer mais controle na implementação dos testes. e este usou o driver para o Java executar o Selenium Server. todos os testes exportados pelo IDE.tests”.23 ao tipo de linguagem em que foi desenvolvido o sistema e de sua execução ser feita no navegador Internet Explorer. 4. O Eclipse usa o JUnit 3. A versão do Eclipse instalada é o Eclipse Classic 3. caso contrário. No Eclipse deve ser criado um Java Project e importar os arquivos exportados pelo IDE. a ferramenta não funcionará corretamente. Os computadores utilizados para testar a ferramenta tinham instalado o sistema operacional Windows XP. pois as instalações que foram colocadas em outros locais apresentaram problemas durante a execução da ferramenta. todas as ferramentas e produtos de software instalados foram colocados na pasta raiz (C:\) do Windows. conforme é apresentado na Figura 11 na próxima página. 4. precisam estar com a extensão “. O Java foi escolhido pela equipe por ser uma linguagem mais conhecida entre os colaboradores da equipe e pelas vantagens da própria linguagem.6) [22]. é preciso fazer .2. O Java foi utilizado para executar o Selenium RC.4. 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.0 ou 4. Primeiramente. Esses arquivos serão colocados dentro de um pacote “com. Java O Java instalado é o Java Development Kit Standard Edition 6 (JDK 1.0 para executar o teste. O JUnit normalmente já vem instalado no Eclipse. Quando se utiliza o Remote Control com o Eclipse é necessário realizar algumas configurações no Java Project no Eclipse. além de ser utilizado no Eclipse.2. Além disso. portanto é preciso que o JUnit esteja adicionado como biblioteca nas propriedades do projeto. 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.

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

dentro do Selenium Core. .2.3. 4. ela fica no menu Ferramentas. dentro da pasta Web onde fica o Webserver do sistema a ser testado. Para usá-lo é preciso copiar a pasta “core”. Reinicie o Firefox e o Selenium IDE já poderá ser utilizado. Para instalá-lo é necessário entrar na opção de Complementos do Firefox. Copie o arquivo contendo a extensão para dentro da aba de Extensões dos Complementos. Eclipse e Selenium 4.2. Selenium IDE Selenium IDE é uma extensão do Firefox. somente descompacte a pasta e já poderá ser usado.4.25 Figura 12 – TestNG. Além disso. o Firefox vai começar a instalação da nova extensão. Automaticamente. ele precisa estar disponível no mesmo endereço e porta que o sistema vai ser executado. Selenium Core O Selenium Core não precisa ser instalado ou configurado.

Portanto. . a criação da mesma demora muito tempo. ficam como padrão para todos os projetos criados. quando este estudo de caso foi desenvolvido. pois nas primeiras utilizações da ferramenta foi possível perceber no sistema.5. os parâmetros da consulta.26 4. Dessa forma. Juntando-se a isso. principalmente os testes relacionados com consultas e retorno de resultados.3. Somente descompacte a pasta na raiz do sistema e depois adicione os drivers dentro das propriedades dos projetos.2. Nesses casos. 4. O estudo da ferramenta pela equipe de testes tinha começado fazia pouco tempo. Selenium RC O Selenium Remote Control é configurado no Eclipse como foi explicado anteriormente. tínhamos o fato de não sabermos ainda se o sistema tinha sido desenvolvido para receber a automação de testes. a equipe de desenvolvimento do sistema foi contatada. Utilização A equipe de testes deverá utilizar a ferramenta para a automação daqueles testes que levam muito tempo para serem executados manualmente. Os drivers podem ser importados direto no Eclipse sem ser preciso algum projeto. estes poderão ser feitos com a ajuda da ferramenta. alguns pontos aonde ele não recebeu a automação completamente. existem muitos itens na tela. Isto é um ponto muito importante. pois dependendo do teste a ser feito com a massa de dados. nas primeiras semanas. portanto pode haver uma combinação muito grande desses parâmetros. 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. Também estão incluídos os testes de regressão. Futuramente é preciso verificar a possibilidade de criar as massas de dados para alguns sistemas com o uso da ferramenta. Nesses casos. 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. principalmente os relacionados com mudança de interface gráfica e algumas funções básicas.

tanto no nível desktop quanto Web. seja ela interna ou externa. como foi dito na seção contendo o objetivo deste trabalho. desenvolvido no local de estágio da discente. Este sistema controla toda a força de trabalho de grandes empresas. O CPqD Workforce é um sistema muito utilizado hoje em empresas de grande porte da área de Telecomunicações e TV. Tudo isso garante uma redução no tempo total de execução dos serviços. mas também está sendo inserido na área de empresas de energia. inclusive em formato de áudio. A tecnologia utilizada para a implementação do sistema é bastante flexível e escalável. 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. 5.27 5. Descrição do Sistema O sistema em que será aplicada a automação chama-se CPqD Workforce [25]. É um sistema robusto com muitas aplicações distintas. pois a resposta automática do sistema diminui o tempo de resposta à solicitação do cliente. O sistema é capaz de gerenciar cada uma das etapas da prestação dos serviços internos ou externos. o sistema consegue trabalhar gerenciando até milhares de técnicos ao . A Tabela 02 [25] apresenta os benefícios mais importantes do sistema. O sistema foi desenvolvido por uma equipe técnica seguindo o modelo CMMI 3. onde estavam envolvidas as áreas de qualidade e de engenharia de software. e garante um acompanhamento mais fiel de todas as etapas dos serviços sendo executados. além de outros padrões de qualidade. e pode também obter informações de outros sistemas como o ERP e também de sistemas de alarmes. O sistema dá suporte a vários tipos de operações dentro das empresas de telecomunicações. pois tem um ótimo sistema de voz. fazendo um gerenciamento completo de toda a força de trabalho da empresa. Estudo de Caso Nesta seção será apresentado o estudo de caso escolhido. 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.1. Trabalha com um grande volume de dados. conseguindo assim cumprir prazos com mais eficiência e melhor qualidade do serviço.

Benefícios mais importantes do CPqD Workforce Custo Redução de custos operacionais ao otimizar a alocação e o despacho das atividades e das penalizações por não-cumprimento de tarefas. estes eram realizados frequentemente. Cliente Maior satisfação do cliente. 5. É como se fosse uma caixa de mensagens. 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. 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. A arquitetura do sistema é aberta.2. Tabela 02. 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. permitindo assim aos técnicos serem localizados mais facilmente. inclusive relatórios totalmente configuráveis de acordo com a necessidade do usuário. no celular. . podemos citar os testes de regressão em algumas telas de consultas. Motivação Como foi apresentado no início deste documento. os técnicos podem receber todas as ordens de serviço automaticamente e enviar. é possível inserir e solicitar os materiais utilizados. Como exemplo. através dos mesmos. Gestão Melhoria na gestão. com isso é possível implantá-lo em diversas plataformas e também fazer a sua integração com outros sistemas. o andamento do serviço a ser prestado. em conseqüência da redução do tempo de resposta dos serviços. O sistema trabalha em conjunto com telefones fixos e celulares. Com a ajuda desses aparelhos. com maior visibilidade e transparência sobre as operações e a força de trabalho. disponibilizando muitos tipos de relatórios. por exemplo.28 mesmo tempo. Além disso. onde cada mensagem representa um serviç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. correspondendo assim às expectativas geradas. O técnico recebe todos os serviços a serem feitos. 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.

o que um testador experiente consegue decidir com base na sua experiência. As massas de dados eram sempre criadas pelos analistas de testes e testadores. seria uma grande vantagem poder criar tipos específicos de massas de dados. principalmente se o testador não tivesse um bom conhecimento prévio do sistema.3. mensagens e outras informações a serem apresentadas na tela para os usuários. pois se o testador não tivesse conseguido criar a massa de dados rapidamente e eficientemente. Protótipos dos Scripts O estudo estava sendo desenvolvido em etapas. um novo testador só conseguirá fazê-lo depois de muita leitura e muitas tentativas. tendo também a garantia de que a massa de dados estaria correta de acordo com o tipo de teste. Assim. Nesses casos. e ter apenas uma simples relação entre tabelas na massa de dados. Como a metodologia de automação era nova para os integrantes da . sendo específicas para cada tipo de teste e de determinadas especificações. Nesses casos.29 Além do teste de regressão. O problema era o tempo de criação de uma massa de dados partindo do zero. buscando os campos. Veja mais detalhes das etapas na Tabela 03. este era muito grande. ainda podemos citar os casos em onde tinha-se a criação das massas de dados para os testes. tínhamos ainda a situação dos testes para verificar interfaces de navegação. 5. porém outros testes podem exigir uma relação mais complexa. Outro fator problemático é a complexidade da massa de dados. eram reutilizadas em outros testes. o início de execução real do teste acabava atrasando. 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. permitindo ao testador poder fazer outra atividade enquanto o teste era executado automaticamente. um teste automatizado também pode ser feito. Dessa maneira. Elas permaneciam armazenadas nos servidores de testes. onde é necessário analisar os elementos visuais da interface e buscar as inconformidades. Assim para cada tipo de teste poderia ser executado um teste automático de criação de massa de dados. o tempo previsto para o teste podia ser constantemente excedido. e sempre que possível. 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. Somando-se a esses casos. Alguns testes podem ser muito simples.

Na primeira etapa. seus conceitos para os testes. Foi escolhido o sistema Weblince. a ferramenta estava sendo utilizada com o Python e no caso da nossa equipe de testes. 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. Tabela 03. somente para o desenvolvimento dos seus estudos em relação à ferramenta de automação.30 equipe. para que esses ficassem responsáveis por estudar e aplicar a ferramenta de automação de testes. comandos e sua linguagem em geral. Um colaborador de outro projeto fez uma apresentação da ferramenta. Criação de métodos específicos para cada caso de teste que necessitasse. estes integrantes tiveram um tempo de alocação separado. A diferença entre os projetos era que no caso do projeto do colaborador. Criação dos métodos auxiliares e genéricos. dentre outras. A idéia inicial era uma capacitação na ferramenta. Outro ponto nessa primeira etapa foi a escolha da parte do CPqD Workforce que seria utilizada para iniciar os testes da ferramenta. 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. O sistema Weblince faz parte do CPqD Workforce. para conhecer o seu funcionamento. Isto foi definido pela coordenadora e pelos analistas de testes. a coordenação do projeto decidiu separar três integrantes da equipe. Etapas para o processo de automação Etapa 1ª 2ª 3ª Tarefa Capacitação Gravação dos Scripts e Exportação para Eclipse Métodos específicos Descrição Estudo da ferramenta Selenium e seu uso com o Java. pois tinham um conhecimento maior de qual consulta seria mais importante para se testar a automação. essas informações são geradas através das mais diversas . Início da gravação dos scripts usando o Selenium IDE no Firefox. foram discutidas. pois este colaborador já estava trabalhando com a ferramenta há algum tempo. Ele provê uma interface web onde os administradores conseguem acessar informações de todas as operações e de todos os técnicos. pois é muito utilizado no ambiente do cliente e algumas de suas consultas são muito importantes.

pois não foi possível clicar nos botões de ação que ficavam dentro do menu. todas as ações do menu de ações que aparecem no resultado da consulta não foram automatizadas.31 consultas. Por consequência disso. A maior dificuldade encontrada foi com os alerts criados com Java Script. mas também pelos próprios implementadores. Os scripts podiam ser modificados direto no IDE ou podiam ser exportados para um arquivo Java. O problema com o alert foi repassado para a equipe de implementação. Depois de escolhido o sistema e a consulta para iniciar os estudos foi definida a segunda etapa. inclusive como sugestão de melhoria da qualidade do sistema para as versões futuras. 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 . Nessa etapa. Outras funções relacionadas com imagens e cores nas tabelas também não puderam ser automatizadas. pois poderiam utilizar a ferramenta para trabalhar com testes unitários além de outros tipos de teste. Nesta etapa foram identificados alguns entraves à automação devido ao tipo de implementação de alguns objetos dentro do 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. para serem utilizados pelo Selenium RC junto com o Selenium Server e o Eclipse Ganymede [14] [22]. A automação poderia não somente ser utilizada pela equipe de testes. dessa maneira a automação poderia ser realmente aplicada facilmente no sistema. pois os mais simples não conseguiam entender a linguagem Perl acoplada no XML da página. os integrantes da equipe de automação começaram a gravar os scripts com o Selenium IDE no navegador Firefox. pois algumas ações dos usuários eram esperadas através dos alerts e não podiam ser reproduzidas. sedo permitido a construção de consultas nos casos em que as padronizadas e já disponibilizadas no sistema não forem suficientes. A ferramenta não conseguia identificar esse tipo de objeto na tela e com isso toda a execução do teste ficava comprometida. 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.

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. 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. Dessa forma. como também podem duplicar uma mesma ação sobre um dado já consolidado. e todas as outras alterações passaram a ser feitas pelo Eclipse. Outros métodos trabalhavam a ação de “clique” do testador em vários pontos da consulta. Além disso. estas não foram capturadas corretamente pelo IDE. Foram criados métodos para trabalhar com datas. pois o IDE grava no script exatamente os valores inseridos pelo usuário nos campos da tela. pois nem sempre a massa de dados usada nos testes é criada do zero ou mantida na mesma base e no mesmo servidor. Além disso. além de gerar datas para o arquivo de log. começou-se a usar métodos para receber e passar os valores (parâmetros) procurados para as funções do Selenium. foram criados métodos para permitir localizar na tela os links que pudessem estar relacionados com esses valores. essa opção não é interessante. Sendo assim os scripts podem ou não encontrar as informações que estavam gravadas nos links acionados. A hora corrente do teste era capturada e com ela foi possível criar as datas usadas na abertura dos bilhetes. No caso de uma reutilização do script. Isso ajudou a verificar inclusive se os dados estavam sendo corretamente gravados no banco de dados. 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. os códigos dos scripts começaram a ser reescritos no Eclipse para se tornarem mais genéricos. pois por alguma razão. Também foram inseridas algumas operações.32 sistema. usando programação com o Selenium RC e o Java. além das verificações de labels e outros campos. Depois da finalização dos protótipos de scripts e o levantamento dos métodos mais comuns. ao invés de passá-los diretamente.

A grade é organizada de acordo com os parâmetros passados para a consulta e têm dois tipos de visualização. O roteiro contempla assim: a execução de 15 scripts. tempo gasto durante a execução. onde são agrupados os bilhetes de acordo com o técnico que deverá executá-lo. eles testam os filtros de parâmetros da consulta. As ações de despacho dentre outras não foram automatizadas. e a outra ordenada por estrutura organizacional. uma ordenada por executor. necessidade de deslocamento. . foi possível preparar a gravação do script de navegação geral da consulta Prazos dos BAs (Bilhetes de Atividades). tipo de reclamação. 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. O roteiro criado para a execução do script possui um total de 418 subcasos de teste. 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.4. Além disso. um teste completo para verificação das duas visualizações. tipo de suporte. Scripts e roteiro da Consulta Prazos dos BAs do Weblince A partir dos estudos dos protótipos gravados e alterados no Eclipse. Essa consulta foi escolhida por ser muito utilizada no cliente e porque. onde os bilhetes são agrupados de acordo com os níveis de uma determinada estrutura organizacional. mostra ao usuário o prazo de vencimento dos BAs abertos no sistema. quantidade e tipo de material usado na tarefa. um teste completo para verificar o resultado da consulta. Veja mais detalhes nos diagramas de casos de uso no Apêndice E. devido ao problema com os alerts. O bilhete tem várias informações a respeito da tarefa a ser executada: como local.33 5. A consulta Prazos dos BAs do Weblince. um teste para verificar a atualização dos resultados da consulta depois de um Refresh ser executado na tela. estava sofrendo pequenas alterações e estas exigiam testes de regressão. Essa navegação geral consistia basicamente em verificar os bilhetes abertos pelo sistema dentro da grade de tempos de vencimentos. nos últimos tempos. quando não se tem um executor e uma estrutura organizacional. dentre outras informações. sendo a maioria de repetição devido aos números de BAs abertos. e por fim. e numa segunda parte detalharmos os dados de cada coluna dessa grade. tem uma coluna específica para os bilhetes sem vencimento.

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). 6 a 12 (BA com data de promessa maior ou igual a 6 horas e menor que 12 horas). São passados como parâmetros da consulta: UF. Serão abertos na seguinte ordem de colunas: Sem Prazo (O BA não tem data de promessa). 21 dias a 28 dias (BA com data de promessa maior ou igual a 21 dias e menor que 28 dias). sendo cada um deles para uma coluna da grade de vencimentos dos BAs. Depois de todos os BAs acima serem abertos. Localidade e Estação. isto é. Este caso será relatado com mais detalhes. 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. pois engloba quase todas as ações dos outros scripts menores. a sua data de promessa já está vencida em relação ao tempo corrente de visualização. 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. 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). 48 a 24 horas. além do fato de trabalhar com mais BAs. A primeira parte do script verifica os BAs na visualização por executor.34 O primeiro caso de teste é sobre o script do teste completo com executor e com a estrutura organizacional. Colunas para representar os BAs atrasados. portanto é o caso de teste possuindo mais subcasos dentro do roteiro. esses valores estão relacionados com a massa de dados preparada para a automação. 28 dias a … (BA com data de promessa maior ou igual a 28 dias). A segunda parte do roteiro trata do acesso à consulta no Weblince. todos essas colunas representam BAs com situação em dia além de outras não citadas. … a 48 (BA com data de promessa maior que 48 horas). Este é o maior script. 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. 12 a 24 (B A com data de promessa maior ou igual a 12 horas e menor que 24 horas). e checar no detalhamento se o BA aberto anteriormente consta corretamente na coluna específica. . O caso de teste começa com a abertura dos 17 BAs. de acordo com o tempo de vencimento.

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

pois nesses casos não era necessário o uso dos comandos do Selenium RC. através de cálculos. O diagrama está simplificado. dentre outras que poderiam ser muito demoradas se feitas manualmente. Para cada BA. pois em cada método havia um ponto de início e fim gravado no log. Algumas ações gravadas no log não estavam relacionadas com a consulta em si. Veja também. dentre outros. 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. Todas essas verificações eram criadas usando a linguagem Java. por exemplo. cálculos. 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. os diagramas de caso de uso do projeto.5. 5. Realiza uma consulta Prazos dos BAs (Visualização por executor). no Apêndice E. tanto visualmente quanto internamente no código do teste. Veja no Apêndice D. Também foram relatados erros e alguns de seus significados. sendo mais uma facilidade para o testador. Os logs continham as ações principais a serem feitas pelo script durante toda a sua execução. A gravação de logs também era feita a cada execução dos scripts. O tempo total de teste também era gravado no log. . identifica em qual coluna o mesmo será apresentado e o detalha. não levando em consideração todos os detalhes das classes nem a relação entre os pacotes dentro do projeto. onde se pode ter uma idéia da relação entre as principais classes criadas. os diagramas de classes. como no exemplo de verificações gerais para facilitar o trabalho do testador.java Abertura de 17 BAs (um para cada coluna da grade de vencimentos) para o mesmo executor. erros de conexão com a interface de abertura de bilhetes. sua correta gravação nas tabelas do banco. dentre outros. TesteCompletoExecutorEstrutura. Pelo log era possível analisar o tempo de execução de cada ação do script. erros de conexão com o banco de dados.36 dos bilhetes e outros dados relacionados a eles.

Realiza outra consulta Prazos dos BAs (Visualização por estrutura). Realiza uma consulta na “Prazos dos BAs” (Visualização por executor). não irá detalhar nenhum nível.. Utiliza os mesmos BAs já abertos anteriormente. Para encerrar exclui da base de dados todos os BAs abertos. verifica se todos os BAs abertos estão na coluna Total (detalhando todos e conferindo no detalhamento). Depois. No detalhamento. mas ainda não despachado para a fila do mesmo). e para cada um deles. TesteBAsSemExecutorSemEstrutra. clica nos níveis da estrutura do BA em questão. Como não há estrutura para os BAs. Utiliza os mesmos BAs já abertos anteriormente. verifica se o BA foi detalhado corretamente. 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). TesteRefresh. verifica se todos os BAs abertos estão na coluna Total (detalhando todos e conferindo no detalhamento). verifica se o BA em questão foi detalhado corretamente. Por último. Para encerrar exclui da base todos os BAs abertos. Verifica se todos os BAs abertos estão na coluna Total. Verifica se todos os BAs abertos estão na coluna Total.java Abertura de 2 BAs (.java Abertura de 1 BA (6h às 12h). Realiza outra consulta na “Prazos dos BAs” (Visualização por estrutura). Através de cálculos. esta indica a designação do bilhete de atividade para um técnico. até 48h. Realiza uma consulta na “Prazos dos BAs” (Visualização por executor).. identifica em qual coluna o BA está e o detalha. 0h até 2h) que vão ficar em R (Situação “A programar”.37 No detalhamento. apenas clica no link da coluna onde se encontra (utiliza os mesmos cálculos para saber em que coluna o BA deve ser apresentado). .

Alguns exemplos de scripts de filtro: TesteFiltros1. Tipo Cliente e Tipo Produto. Clica no botão de Refresh. TesteFiltros12. Os pontos de diferença nos scripts de filtros estão relacionados com o tipo de visualização. No detalhamento. Área Técnica e Atividade. . Armazena a quantidade de BAs exibida na coluna. No detalhamento. identifica em qual coluna o BA está e o detalha. Estação. UF. verifica se o BA foi detalhado corretamente. Prioridade. Localidade. No Turno. Para encerrar excluímos da base de dados todos os BAs abertos. identifica em qual coluna o BA está e o detalha. Contratada. também temos as mudanças nos filtros usados: COS. Microárea. verifica se o BA foi detalhado corretamente. Para encerrar exclui da base de dados todos os BAs abertos. Conectado. depois da abertura do BA antes de fazer a consulta. Retira o técnico da escala de trabalho para o dia corrente. Além disso. Armazena a quantidade de BAs exibida na coluna.java Abertura de 1 BA (0h às 2h). Abertura de outro BA para a mesma coluna. Realiza a consulta na “Prazos dos BAs” (Visualização por executor) com os filtros: COS. Identifica em qual coluna o BA está e o detalha. Ramificação da Área Técnica.38 Através de cálculos. Código do Nível. Macroatividade. Nível. Não Conectado.java Abertura de 1 BA (0h às 2h). Localidade e Estação. Verifica se a quantidade foi incrementada corretamente. Scripts para checagem de Filtros: As seguintes ações são comuns em todos os scripts de filtros: Através de cálculos. que em alguns casos é Visualização por Executor e em outros é Visualização por Estrutura. UF.

Figura 13 – Menu de Escolha de Scripts para Execução Automatizada . Arquivos auxiliares: Menu.39 Realiza a consulta na “Prazos dos BAs” (Visualização por executor) com os filtros: COS. Estação e Área Técnica e Natureza = C (corretiva). Macroatividade e Atividade. e com os mesmos filtros acima. Depois faz uma nova abertura de 1 BA (2h a 4h) do tipo preventivo. Localidade.java é um arquivo utilizado para facilitar o acesso a todos os scripts acima mencionados.java Menu. Localidade. O menu contém uma caixa de seleção para cada script criado. TesteFiltros15. Estação. Realiza a consulta na “Prazos dos BAs” (Visualização por estrutura) com os filtros: COS. Depois que realiza a consulta atualiza a escala de trabalho do técnico novamente. somente mudando a Natureza = P.java Abertura de 2 BA (2h às 4h). além de poder selecionar todos com um único “clique”. UF. Com isso é possível executar mais de um tipo de script em sequência. Um de serviço e outro corretivo. No Turno. UF. A Figura 13 apresenta a interface para a escolha dos filtros para a execução automatizada.

área técnica. Executor. vencimento. 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. HTMLFormater. executor. porém com a melhoria do mesmo ele passou a ser gerado como um arquivo “html”.40 Arquivos comuns: Arquivos criados para auxiliar o andamento da classe Métodos Genéricos.java A classe Executor contém todas as informações sobre os executores da massa de dados usada. Contêm informações como o número do BA. Esses arquivos são usados na execução de todos os scripts criados. Através dela são feitas as principais operações que ocorrem nos scripts. estação. A classe é utilizada para facilitar o acesso aos executores da massa de dados. UF. como mudança de cores e tamanho das fontes. além de permitir funções mais avançadas. situação e uma variável auxiliar para a localização do clique nas linhas da grade.txt”. Inicialmente o log foi criado com um simples arquivo “.java A classe HTMLFormater é utilizada para formatar a estrutura do arquivo de log. ocorrência. inserção de imagens. 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. dentre outros. verificações no banco de .java A classe BA contém todas as informações sobre os BAs a serem utilizadas durante a execução dos scripts.java A classe MetodosGenericos é muito importante. níveis da estrutura organizacional. MetodosGenericos. isso facilita na visualização das ações que ocorrem dentro dos scripts. data de promessa. Ela é utilizada principalmente quando se têm mais de um executor na massa de dados. pois ela contém todos os métodos não integrados ao código gerado automaticamente pelo Selenium IDE. localidade. BA.

O grande problema nessa inserção é a necessidade do testador conhecer um pouco de programação. tudo considerado importante e necessário em uma possível reutilização de código foi inserido nela. pensando inclusive nos novos projetos. config. Outro ponto a ser lembrado é o tempo para o testador identificar a linha de código correta a ser alterada. porém a classe MetodosGenericos é a base. o teste já estará comprometido ao ser executado. sendo a estrutura mantendo coesos todos os scripts. conexões com a interface de abertura de BAs. ficou mais fácil controlar as alterações realizadas pelos testadores e também manter uma melhor organização da estrutura dos projetos.41 dados.properties” foi criado para permitir as configurações das massas de dados serem alteradas em cada execução do script. Também estão nela outras ações complementares como as inserções e atualizações no banco de dados. gravação do arquivo de log. porém para isso acontecer é preciso permitir que o testador possa inserir as informações da sua massa de dados nos scripts. Dessa forma. os cálculos de vencimentos dos BAs. dentre muitos outros. Além disso. o Selenium IDE grava exatamente os dados que inserimos nos campos no script. os cálculos das datas para a abertura automática dos BAs de acordo com a data corrente de visualização. Com a centralização de tudo o que era criado nessa única classe. Como foi falado em capítulos anteriores. a localização dos cliques na grade. A maior parte das ações mais complexas relacionadas aos cliques do usuário está nessa classe. é necessário deixar o script genérico. isso não é viável para a reutilização do mesmo. Isto poderia exigir . e para fazer a alteração corretamente. evita-se que vários métodos fiquem espalhados em vários arquivos dentro da estrutura dos projetos de automação. para entender onde exatamente precisará alterar os valores dentro do script. cálculos. a localização do BA na área de detalhamento.properties O arquivo “config. pois se esquecer de alterar alguma linha de código e deixar um valor antigo. ele precisará saber todas as posições nas quais deverá fazer essa mudança no código. Todos os métodos criados durante o projeto. O código dentro dos scripts é basicamente relativo ao caso de teste que ele executava. conexões com o banco. Com isso. como por exemplo.

Tabela 04. informações do sistema Weblince (login. Assim. por exemplo. informações de conexão com o banco de dados (login. já estarão colocados no “config. por exemplo. portanto não estaria condizente com um dos objetivos da automação que é reduzir o tempo de teste.properties” foi criado. e na Tabela 05 na próxima página. domínio. esse valor já fica na memória armazenado. Com ele era possível alterar as informações de uma massa de dados diretamente neste arquivo. e o conteúdo dessas entradas são os valores a serem alterados pelos testadores. verifica qual entrada ele deve procurar. ele já estará disponível. Devido a esses fatores o arquivo “config. localiza e traz o valor da referida entrada. URL). O arquivo continha as entradas que são como os índices de um banco. Para finalizar segue a Tabela 04 mostrando o tempo total gasto pela equipe de testes durante o projeto de automação relatado nesse trabalho. Outro ponto era o arquivo ser bem simples.properties”. Com isso.properties” ser lido várias vezes durante a execução.42 muito tempo. IP). não sendo mais necessário ao testador buscar no código os pontos onde deveria haver a alteração. assim poderia ser aberto no Notepad do Windows. a quantidade de linhas que cada código de script continha. senha. não sendo necessário ao “config. Era um arquivo de texto comum. vai até o “config. Quando na execução do script esse dado for requisitado. senha. e as próprias informações das massas de dados. qualquer dado poderia ser alterado futuramente em outras execuções. Esforço no projeto de Automação Colaboradores Capacitação Automação Colaborador 1 Colaborador 2 Colaborador 3 Total 62h37min 20h 20h 102h37min (4dias 6horas 37min) 418h20min 432h 412h 1262h20min (52dias 14horas 20min) . O script vai ao código.properties”.

foi possível notar que alguns comandos como o “thread. Quantidade de linhas de código Script Quantidade de linhas TesteCompletoExecutorEstrutura.java TesteFiltros6.java config.java TesteFiltros4.java TesteRefresh.java Executor. Embora tenha sido necessária essa adequação do ambiente em todas as máquinas.properties Total 534 301 275 216 218 212 223 227 234 238 236 208 288 218 230 207 205 275 1098 414 74 26 2949 53 9159 5.java TesteFiltros3.java TesteFiltros8.java TesteFiltros13.java TesteFiltros15.java BA.sleep” era igual em todas as máquinas.java TesteFiltros10.java TesteFiltros1.java TesteFiltros14. quanto num mais rápido.java HTMLFormater.java TesteFiltros12.java TesteFiltros5. Considerações finais As configurações de todas as ferramentas utilizadas.java TesteBAsSemExecutorSemEstrutra.java TesteFiltros11.java TesteFiltros9. O “thread.5. assim poderiam ocorrer erros de “time-out” tanto num processador mais lento.java MetodosGenericos.sleep” não apresentou o mesmo resultado em processadores diferentes.java TesteFiltros7. porém algumas vezes não era suficiente. devido a diferença nos processadores. assim como do ambiente de automação precisam ser idênticas nas máquinas de todos os testadores. pois também dependia do estado do processador.java TesteFiltros2. pois isso pode gerar erros na codificação ou na execução do script de teste. .43 Tabela 05.java Menu.

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

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

O script TesteCompletoExecutorEstrutura.java foi dividido em etapas. Veja no Apêndice B a tabela contendo todos os tempos das execuções do script. e algumas . Algumas etapas são manuais para os dois testes a serem comparados. A quarta até sétima comparação foram feitas considerando as mudanças no script para a melhoria do desempenho do mesmo. 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. foi iniciado o processo de comparação entre os testes. O teste manual foi feito no microcomputador A (no caso era o computador da estagiária) utilizando o Internet Explorer 6. acabou sendo maior que o teste manual no mesmo computador. também no grupo de automação). Como se pode notar o tempo do teste automático. No Apêndice C temos as configurações dos três computadores usados na comparação informações relacionadas com as comparações realizadas. sendo aproximadamente 34 minutos mais demorado. o processador era diferente tendo quase o dobro de processamento e o teste foi feito no Internet Explorer 7. O computador dele tinha a mesma quantidade de memória que o da estagiária.java. 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). cujo resultado é apresentado na Figura 14 (Manual – primeira barra do gráfico). Depois dos scripts da consulta “Prazos dos BAs” serem finalizados e depois das últimas atualizações para melhora do desempenho. Essa mudança estava relacionada com os testes na visualização por estrutura organizacional. A primeira parte da comparação foi fazer o teste manual usando o roteiro criado para o script TesteCompletoExecutorEstrutura. A seguir será relatado como foi o procedimento para a comparação e como foram os resultados. Resultados Como foi dito no Estudo de Caso desse trabalho.46 6. 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. porém. para ser possível medir o tempo do teste manual e do teste automático. A segunda parte da comparação foi fazer o teste automático no mesmo microcomputador. O resultado pode ser visto no gráfico da Figura 14 (Automático B – terceira barra do gráfico).

para verificar se o tempo melhoraria com a mudança no script. O teste automático foi repetido no microcomputador B. aquele usado pela estagiária. para verificar se a mudança no script melhoraria o tempo final de teste no computador mais potente usado para os testes. Figura 14 – Gráfico: Resultado final da comparação . a única diferença é que o teste no servidor de automação foi feito com o Internet Explorer 7. A sétima e última parte da comparação foi refazer o teste automático no servidor de automação.47 A quarta parte da comparação foi fazer o teste automático no servidor de automação. O resultado pode ser visto no gráfico na Figura 14 sob título Automático A (II) – sexta barra do gráfico). utilizando o Internet Explorer 6. 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). para verificar se o navegador poderia estar influenciando no tempo de teste. Esse microcomputador tinha a mesma configuração do microcomputador A. Sob o título de Automático B (I) (quinta barra do gráfico da Figura 14) este resultado é apresentado. 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). A sexta parte da comparação foi refazer o teste automático no microcomputador A.

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

pois nos scripts esses dados eram obtidos automaticamente no código e no arquivo “config.3. data de início e fim de execução.49 A Figura 15 apresenta o tempo despendido para esta tarefa que foi totalmente manual. essa atividade só era feita no teste manual. Etapa 2 – Preparar planilha auxiliar para os BAs Etapa 2 (Figura 16) . pois seria muito difícil abrir os BAs de acordo com as datas e horas colocadas no SQL. 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. No caso foram abertos BAs do tipo serviço. respeitando os métodos de abertura do BA e do cálculo das datas que estavam no script. O tempo apresentado é o total de tempo utilizado para criar e atualizar a planilha. Veja a planilha no Apêndice A. 6.properties”. Como na Etapa 1. data de anormalidade e o vencimento do BA de acordo com a data corrente. pois nos scripts todas as datas usadas para o cadastro dos BAs eram calculadas automaticamente de acordo com a data corrente do teste. até que se chegasse à forma final da planilha. .Foi feita uma planilha auxiliar para ajudar no cálculo automático da data de promessa. sem antes saber todas as datas usadas pelo BA. pois para se realizar o teste manual era mais rápido trabalhar com uma planilha. Figura 15 – Gráfico: Preparar os SQLs para abertura dos BAs Essa etapa era feita somente no teste manual. Esse tempo foi anexado à comparação.

seria preciso alterar a chamada para o ID do BA no SQL antes de cada execução no sqlplus. . seria possível usar sempre a mesma chamada para a entrada do ID no prompt do sqlplus.50 Figura 16 – Gráfico: Preparar planilha para abertura dos BAs 6. Se não fosse feito esse processo. Também. pois só assim o sqlplus não iria usar um ID já usado anteriormente na abertura de um novo 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. Era preciso “logar” na conta da base usada pela interface em toda abertura de BA. 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.4. dessa forma.

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.51 Figura 17 – Gráfico: Preparar a Shell do sqlplus para a abertura dos BAs 6. Etapa 4 – Leitura do roteiro de teste Etapa 4 (Figura 18) .5. pois nos scripts o roteiro já está incluso diretamente no código. Figura 18 – Gráfico: Leitura do roteiro . Essa etapa também só era realizada no teste manual.

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. essas datas podiam chegar até um período de 30 dias anterior ou posterior a data de abertura.7.52 6.6.A escala de trabalho dos técnicos da massa de automação. para que ela correspondesse ao mês corrente de execução do teste. Etapa 5 – Preparar a escala de trabalho dos técnicos da massa Etapa 5 (Figura 19) . Figura 19 – Gráfico: Preparar escala de trabalho dos técnicos 6. Nesse caso. Os BAs tinham diferentes datas de execução. um script SQL de . era preciso preencher a escala mensal completa de cada técnico da massa de automação. então. pois não teria nenhum técnico atribuído a ele. Isso é feito direto pela base usando o comando “deleta”. Etapa 6 – Limpar a massa de dados (deleta) Etapa 6 (Figura 20) . Caso a escala não estivesse corretamente atualizada. o BA não apareceria na consulta para o técnico escolhido na massa de automação. ainda não estava automatizada para ser atualizada no início do script.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. para evitar erros.

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. inserir um valor para o ID do documento associado relacionado ao BA. 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. Depois de cada abertura era preciso executar um “select” para ver se o BA foi . 6. Então. Para o caso do teste manual era preciso executar o SQL para abertura de BA. sendo esse ID único. maior seria o tempo gasto pelo Selenium para encontrar os BAs abertos. Isso influencia o tempo final de teste. Esses valores eram retirados do sistema desktop SGE.8. 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. Etapa 7 – Abertura dos 17 BAs Etapa 7 (Figura 21) – Nessa etapa era feita a abertura dos 17 BAs usando a interface Vitria.53 remoção de BAs. Quanto maior é a quantidade de BAs presentes na massa de dados durante a execução do script de automação.

As Etapas 1. . 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. Em toda a abertura manual dos 17 BAs era necessário refazer o processo acima.9. Figura 21 – Gráfico: Abertura dos 17 BAs 6. Era feita toda a verificação pela grade de vencimento (régua de prazos). clicava na coluna e depois procurava o BA no detalhamento. Esse “select” retornava o número do BA aberto ou o código do erro de abertura. então o script localizava a coluna que teria o BA que ele estava procurando. No caso dos outros testes os scripts faziam todas essas etapas automaticamente. 2 e 3 estavam relacionadas com a Etapa 6. sem passar pela coluna Total. O script entrava em cada link na coluna e procurava a quantidade de BAs abertos relacionados com aquele teste. Etapa 8 – Consulta na régua de prazos.54 aberto ou se ocorreu algum erro na Shell no sqlplus. e depois era feito o detalhamento da coluna na área de detalhamento. No caso sempre era 1 BA por coluna.

Etapa 9 – Consulta na coluna total. . porém. 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 isso esse tempo foi colocado na planilha de abertura. 6. juntamente com a data corrente da visualização do BA na consulta (Veja o Apêndice A). era necessário que o testador verificasse o tempo de vencimento do BA. nesse caso. o número do BA e a data de promessa.10. nesse caso. somente o tempo do clique e detalhamento de todos os BAs da coluna Total é contado. O processo é similar ao da Etapa 8. O script realiza esses passos automaticamente. Depois na área de detalhamento era necessário verificar se o tempo de vencimento estava aparecendo corretamente de acordo com a planilha de abertura. pois ele precisaria saber exatamente em qual coluna o BA deveria aparecer. somente uma coluna é selecionada e todos os BAs estarão nela para serem detalhados.55 Figura 22 – Gráfico: Weblince – grade de vencimento .executor Nessa etapa no caso do teste manual. porém.

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.

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. Figura 27 – Gráfico: Perda com erro . 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.14. Somente usado nos casos de testes manuais.59 Figura 26 – Gráfico: Exclusão dos BAs 6.

abertura de bilhetes e exclusão. Além disso. Além disso. por exemplo. preparação da shell. dentre outros itens realizados totalmente incorporados ao código. dentre outras. na verificação dos bilhetes na área de detalhamento. 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. interrupções diversas. Além disso.60 Ao final do processo foi possível perceber que restrições nas máquinas usadas. tornam o teste automatizado lento. tais como a falta de atenção. dos scripts SQL. pois em alguns pontos são mais eficientes que os automatizados. 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. . Por isso a importância do isolamento total do ambiente de automação. porém nos testes manuais demoram bem mais. o processamento paralelo com outros programas também impacta negativamente o tempo de execução dos testes automatizados. Também foi possível perceber que os testes manuais não perdem sua importância. O olho humano era mais rápido que o Selenium. o tempo é otimizado pelo fato de não ocorrem algumas ações humanas.

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

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

os treinamentos internos. tanto na área de testes/automação quanto na área de programação podem ajudar e muito. como foi o caso da equipe focada nesse trabalho. 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. seminários. Em relação ao aprendizado de novos conceitos.63 dentro da equipe. principalmente quando a equipe de automação está começando o seu aprendizado. Trocar conhecimento entre equipes é uma forma rápida de obter a ajuda que se precisa. Esse modelo de transferência de conhecimento além de bastante eficaz evita gastos vultuosos com cursos que nem sempre surtem o efeito desejado. Dessa forma. congressos e outros. . 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. É muito mais fácil aprender com as experiências vividas por outras equipes de testes. é necessário descobrir os pontos fortes de cada perfil de colaborador e definir assim o melhor tipo de atividade para cada membro da equipe.

2001. Instituto de Computação. Aplicação de uma metodologia em Testes Sistêmicos. Unicamp. Prentice Hall. Disponível em: http://blogs. O. [13] Caetano.html Último acesso em: 30 mai. ACM-Press New York and Addison-Wesley. 2010. [14] BURNSTEIN I. Disponível em: http://www.. Seminário de Teste – 2001.cpqd. O. TestExpert – Blogs – Introdução à Automação de Testes Funcionais.com. Pratical Software Testing: A Process Oriented Approach. Unicamp. E. G. Disponível Disponível em: em: http://seleniumhq. 1999. [09] PEZZÈ. MARTINS. [08] VIEIRA. Notas de aula. Fundamentos. Software Test Automation.asp?comp=8035 Último acesso em: 30 mai. [12] Abril – Tecnologia e Informação – Automação de Teste de Software. [03] SOMMERVILLE. . 2010. Referências Bibliográficas [01] SeleniumHQ [02] CPqD – Web e application Produtos – testing CPqD system.php?cd=570 Último acesso em: 30 mai..64 8.devmedia. R.br/?q=node/178 Último acesso em: 30 mai. YOUNG. I. C. Limeira-SP. 2010. Software Testing and Analysis: Process.Artigo Engenharia de Software Introdução a Teste de Software. Sofware Testing Techniques. Workforce. Engenharia de Software. International Thomson Computer Press. Soluções http://www. Principles and Techniques. Fundamentos de Testes.com. John Wiley & Sons. 8ª ed. Disponível em: http://www. GRAHAM D. 2007.. M. [05] MORAES. Inc. Notas de aula.br/articles/viewcomp. Faculdade de Tecnologia. Teste de Regressão..testexpert. V. [07] BEIZER. 76f.. Unicamp. Instituto de Computação. Unicamp. [06] MARTINS.br/blogdocampos/2008/09/automacao-testesoftware.com.br/site/ContentView.abril. G. [11] FEWSTER M. Testes de Softwares. 2010. 2ª ed. 2007. Effective use of test execution tools. E. 2006. 2010.org/ Último acesso em: 30 mai. [04] Dev-Media – Biblioteca Digital DevMedia . [10] PATUCI. Trabalho de Conclusão de Curso. 1990. L. 2008. B. 2001. Notas de aula. M. Estágio Supervisionado – CESET.com.

Integração Continua .enfinity/WFS/CDS-CDS_Developer-Site/en_US//USD/ViewProductDetail-Start?ProductRef=jdk-6u14-oth-JPR@CDSCDS_Developer Último acesso em: 30 mai. Disponível em: http://cmcpb. 2010.html Último acesso em: 30 mai.php?cd=570&Busca=workforce..wordpress. [25] CPqD – CPqD Workforce.org/how_it_works. Upper Next Generation Java™.Rodando scripts do Selenium no Visual Studio.br/site/ContentView.eclipse. Disponível em: https://cds. 2010. [24] TestNG – Download. 2010.org/2007/09/17/writing-effective-javascript-code-or-how-ilearned-to-stop-worrying-and-love-the-unit-test/ Último acesso em: 30 mai.org/doc/download.Java SE Development Kit 6u14. 2010.zip Último acesso em: 30 mai.Supported Browsers.4. Berlin. Disponível em: http://seleniumgrid. 2010. [18] Pimentel. [21] Selenium Grid – How it works. .cpqd. Disponível em: http://www. 2010. Addison-Wesley.com/isbin/INTERSHOP. C. [15] Beust. H. Disponível em: http://seleniumhq.com.65 Springer-Verlag. F. Disponível em: http://seleniumhq.com.org/downloads/download.seleniumhq. 2010. .Builds rápidos com Grids e paralelismo. Disponível em: http://testng. 2002.br/tag/selenium-grid/ Último acesso em: 30 mai. [20] Caelum Ensino e Inovação .2-200902111700/eclipse-SDK-3. Suleiman. Disponível em: http://blog.4.org/about/how. Disponível em: http://www. 2008.php?file=/eclipse/downloads/drops/ R-3. [16] OpenQA. How Selenium Works.com/2009/01/31/rodando-scripts-do-selenium-novisual-studio/ Último acesso em: 30 mai. 2010.Writing Effective Javascript Code (or How I Learned to Stop Worrying and Love the Unit Test).Introducing Selenium . Testing TestNG and Advanced Concepts. Disponível em: http://fpimentel88.2-win32. [22] Sun . [23] Eclipse Downloads.sun.html Último acesso em: 30 mai. Acessado dia 30 mai. [19] SeleniumHQ .caelum.ilrt.blogs.org/docs/01_introducing_selenium. 2010. 2010.html Acessado dia 30 mai. [17] Chris’ Blog .html#supported-browsers Último acesso em: 30 mai.

com/javase/downloads/widget/jdk_netbeans. 1 Java SE Development Kit Recuperar a instalação: http://java. No final do campo Valor da variável.0_12 Selecionar OK. Selecionar com o botão direito em Meu computador.6. adicionar o valor . Veja a Figura A .%JAVA_HOME%\bin Veja a Figura A . Na aba “avançado”. localizar a variável PATH. 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 . Atenção: A versão do Java utilizada neste guia foi a “1. selecionar Propriedades. selecioná-la e em seguida Editar. No campo Nome da variável. Após. selecionar Variáveis de Ambiente. informar JAVA_HOME.Workforce Siga as etapas abaixo para criar o ambiente de testes. informar C:\Java\jdk1.6. Veja a Figura A . .sun.1.jsp Instalar na pasta C:\java.2. Na lista de variáveis do sistema.0_12”. No campo Valor da variável.66 9.3.

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

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

1-dist. Para facilitar você pode criar um arquivo executável “.bat.6 como é a solicitação de instalação. Digitar “java –jar selenium-server.1/selenium-remote-control-1.0-beta-2-dist\selenium-remote-control-1.0-beta-2). veja a Figura A . Veja a Figura A .org/selenium-remote-control/1.69 2 Selenium IDE. Extrair os arquivos para a pasta “C:\automacao”. Selenium Remote Control Maiores detalhes da ferramenta podem ser encontrados no site da OpenQA [01].0-beta-2\seleniumserver-1. Veja a Figura A . Exemplo: Abra o Notepad e cole os comandos abaixo: @echo off c: cd \automacao\selenium-remote-control-1.9.0.bat” e não um “.0. Salve o arquivo com o nome que você queira. O Firefox solicitará confirmação para instalar o complemento. Veja na Figura A . Selenium Core. conforme a padronização definida pela equipe de automação.0. digitar cmd e clicar em OK). Extrair os arquivos para a pasta “C:\automacao”.zip. Ex: selenium_server. veja na Figura A . Para instalar. Baixar os arquivos do Selenium Core: http://release.0.seleniumhq. lembrando que será um “.4.seleniumhq. abrir o Firefox e ir a Arquivo -> Abrir arquivo.11. Baixar o Selenium IDE: http://release.1.txt”.jar” e teclar “Enter”. Veja a Figura A . Subir o servidor do Selenium: Acessar o prompt de comando (Iniciar->Executar. Baixar os arquivos do Selenium Remote Control: http://release. Veja a Figura A . Ir para a pasta C:\automacao\selenium-remote-control-1.4.2.0. Selecionar o arquivo selenium-ide1. veja em Formatar->Quebra automática de linha.xpi.org/selenium-ide/1.0-beta-2 (cd C:\automacao\selenium-remote-control-1.0-beta-2dist\selenium-remote-control-1.7. Veja a Figura A .2.0-beta-2 java -jar selenium-server.5.bat” com os comandos acima.jar Verifique se cada comando está numa linha separada.0beta-2\selenium-server-1. dessa maneira você não precisa entrar no prompt toda vez que for subir o servidor do Selenium. Veja a Figura A .openqa.org/selenium-core/1.xpi. o Selenium IDE fica instalado no menu Ferramentas.0-beta-2-dist\selenium-remote-control-1.0-beta-2\selenium-server-1. .1/seleniumcore-1.8 a janela do Selenium IDE já preparada para a gravação (botão com um círculo vermelho no canto superior direito ativado).0.zip. Confirmar a instalação e reiniciar o Firefox.0.4 e a Figura A .2/selenium-ide-1.10 o servidor já ativado.

70 Figura A .4.5. Download do Selenium Figura A . Download do Selenium IDE .

Selenium IDE no menu Ferramentas .71 Figura A . Instalação da extensão no Firefox Figura A .7.6.

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

11. BAT para executar o Selenium Server .10.73 Figura A . Prompt com Selenium Server Figura A .

Depois de aberto o Eclipse. Assim todos os arquivos relacionados à Automação ficarão num mesmo diretório.jar e clicar em Abrir. Clicar em Abrir e Após em Ok.php?file=/technology/epp/downloads/release/galileo/SR1/ eclipse-jee-galileo-SR1-win32. http://www.jar. selecionar o arquivo selenium-java-client-driver. Você pode criar uma pasta chamada “workspace” dentro do diretório de Automação. Clicar novamente em “Add External JARs”. Selecionar o Junit 4 e clicar em Finish. Informar “testeSinergia.13. Repita os mesmos procedimentos do parágrafo acima para criar o pacote chamado “arquivosComuns”. Clicar novamente em “Add External JARs”. depois que estiver no programa você deve dar um Refresh no projeto para garantir que os arquivos estarão atualizados Veja na Figura A . que é onde serão salvos todos os seus projetos.0-beta-2. Clicar em Abrir e Após em Ok”..0-beta-2\selenium-java-client-driver-1.0\client_2\jdbc\lib\”).jar” (que se encontra na pasta “jdbc\lib“ da instalação do Oracle (ex: C:\oracle\product\10.prazos” e clicar em Ok.jar” e clicar em Abrir.4. clicar em “Add External JARs”. Na aba Libraries. pois com o início da criação dos scripts de . Este pacote foi recentemente criado. Clicar novamente em “Add External JARs”. Selecionar o Junit e clicar em Next..weblince. Ir na pasta C:\automacao\selenium-remote-control-1.eclipse. O Eclipse solicitará o endereço do Workspace.java” do projeto de automação e colar dentro desse pacote.15 e na Figura A . Ex: C:\automacao\workspace. Clicar em Next. Procurar pelo arquivo “commons-lang-2. Procurar pelo arquivo “ojdbc14. selecionar o arquivo “selenium-server. Veja a Figura A . Você também tem a opção de importar os arquivos (Botão direito do mouse -> Import -> File System).14. E também pode copiar os arquivos diretos no diretório: C:\automacao\workspace\Automacao\src\testeSinergia\weblince\prazos Antes de entrar no Eclipse.zip. Veja a Figura A . Na aba Libraries.0-beta-2. No campo Project Name informar “Automacao”. clicar em “Add Library”. Copiar os arquivos “. Clicar com o botão direito sobre a pasta do Projeto (lado direito da tela do Eclipse) e ir a New >Package.0beta-2-dist\selenium-server-1.16 como fica a árvore do nosso projeto no Package Explorer do Eclipse.12. Veja a Figura A . Ir em “File -> New -> Java Project”.74 3 Eclipse Instalar na pasta “C:\automacao” (C:\automacao\Eclipse).org/downloads/download. Confirmar a criação do Projeto.2. Ir à pasta “C:\automacao\selenium-remote-control-1. Abrir o Eclipse.

18. seleciona a opção “File” e indique o caminho do arquivo de texto do console: C:\automacao\console\console. Você pode adicionar vários consoles num mesmo arquivo ou sobrescrever em cada execução. você clica em “File System”. “MetodosGenericos.java”. Note que os arquivos “BA.21. selecionando a opção “Append” ou deixá-la desmarcada. selecione o projeto Automação no Package e clique com o botão direito do mouse. “Executor. Para isso você pode configurar o Eclipse para exportar os dados do console e um arquivo de texto. ficam aparecendo somente no Console do Eclipse. assim que você rodar outro teste ele é limpo e as informações anteriores são apagadas.java”. Veja a Figura A . Veja na Figura A 15. com isso a cada nova execução o arquivo “console. Entre no menu Run -> Run Configurations. As baterias de testes geram um arquivo de texto. na área “Standard Input and Output”. Os logs criados têm as informações mais importantes para localizar os pontos de execução das ações do Selenium no teste.19. porém muitas outras informações de cálculos.txt Depois disso.75 automação da consulta Carga de Executores. Com isso toda vez que você rodar um script ele terá a console toda gravada nesse arquivo de texto.properties” foram movidos para o pacote “arquivosComuns” (não estão mais nos outros pacotes). Como última configuração. Veja como deve ficar a estrutura do diretório de automação na Figura A .java e reorganizar a estrutura do Projeto Automação.17 e a abaixo Figura A . Para isso você deve criar no diretório de Automação uma pasta chamada “console” e dentro dela criar um arquivo txt chamado “console. Depois clique em “Apply”. você pode escolher se deseja adicionar sempre os resultados nesse mesmo arquivo. e todos estão configurados para serem salvos no diretório: C:\automacao\logs. Veja a Figura A . porém o console é temporário. .java” (novo arquivo). com isso você já estará salvando os dados do console.java” e “config. Em alguns momentos pode ser interessante guardar as informações do console. Com isso você já pode executar os testes que o console deste “.txt” será limpo e receberá novos dados. será necessário criar uma pasta chamada “logs” dentro do diretório de automação. Para acessar as propriedades do projeto e fazer outras alterações nas bibliotecas ou nos drivers. para tentar identificar melhor o que está acontecendo. Veja a Figura A .20. “HTMLFormatter. antes de iniciar a execução dos testes no ambiente. houve a necessidade de alterar alguns métodos da classe MetodosGenericos. criação de listas e outros métodos. selecione o java que você deseja salvar os dados do console.txt”. No menu aberto entre em Properties.java” será salvo. Depois clique na aba “Common”.

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 . Package Explorer do projeto .15.

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

Bibliotecas Figura A .80 Figura A .18.19. Workspace no diretório de automação .

81 Figura A . Configurando a exportação do console .21. Pasta com o arquivo de console Figura A .20.

TX).23.  Veja mais informações importantes sobre os “imports” e o “config” nos códigos no final deste guia. para que o script fique o mais genérico possível. O estado é RN.properties” são usados como parâmetros dos filtros. Lembre-se que cada teste vai necessitar de uma alteração nesse arquivo. a localidade é AUT e o COS é CAUT.22 e a Figura A . Os testes com filtros foram criados na Estação AUT3 (AU. Código da restrição (Usado com o “config. Verifiquem nas tabelas de cadastro do SGE as massas de automação cadastradas e crie a sua própria baseada nessas (AUT1. CUIDADOS ANTES DE EXECUTAR: O ideal é que cada testador tenha a sua própria massa de automação. verifique no código. a área técnica que é passada no método de abertura de BA precisa corresponder com os dados do “config. é preciso verificar se os dados da massa estão corretos no arquivo config.properties”. Alguns scripts foram criados em estação específica. na execução do script. irá dar erro no script. contratada NORT).properties. lembrando de criar sua própria estação e seus técnicos. AUT2 e AUT3). caso você não use esse filtro irá dar erro na execução do script. assim não ocorrerão problemas durante a execução dos testes.properties”. que os dados que ficam no “config. 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. pois cada técnico tem sua área técnica de acordo com a estação. Além disso. Preste atenção nos arquivos da baterias. caso você abra um script que foi feito para rodar numa estação e área técnica. Além da estação. pois os scripts criados precisam que a Estação seja passada como parâmetro da busca.82 4 Rodar o teste no Eclipse  Para que seja possível rodar o teste automatizado. Veja a Figura A . e você insere outra área no código. 2. deverá ser iniciado o servidor do Selenium. LA. Exemplos: 1.properties”): . e os demais testes na AUT1 (área técnica TX e LA) ou AUT2 (área técnica EL e LA. por isso. portanto verifique sua massa antes de executar os testes. Caso tenha dúvida verifique a estrutura da massa de dados criada para os testes automatizados. É preciso estar atento na hora de reutilizar os scripts. Lembre-se que muitas outras informações podem ser adicionadas no “config. Esse arquivo de configuração é usado pelo Eclipse para capturar alguns dados da massa do testador. é preciso estar atento à qual área técnica você vai enviar o BA.

83 restricao = "BA_PROGRAMACAO. docAssoc." "."A". “Package Explorer”."VITRIA". 3.properties): numBA = abreBA(logger.COD_LOCALIDADE_PR like '"+localidade+"'" + "and BA_PROGRAMACAO. 2). Os scripts foram elaborados e executados no ambiente Sinergia. a UF e a localidade são passadas usando o valor que está no config. localidade. estacao. Arquivo config. Além disso. os principais cadastros feitos têm a palavra automação ou uma parte dela. UF.22.UF_PR like '"+UF+"'" + "and BA_PROGRAMACAO.java). clicar duas vezes sobre o arquivo (ex: TestRefresh. A estação. No Eclipse. Figura A . "S". Código de chamada do abreBA (A área técnica passada para esse BA é TX. Depois de verificar os pontos acima você pode executar os scripts. esse é o único campo no código que poderá ser alterado.properties . "TX". para facilitar a identificação da massa de automação.COD_ESTACAO_PR like '"+estacao+"'". Verifique nas tabelas de cadastro no SGE. por causa da estação e do técnico cadastrado. Clicar em Run->Run AS-> Junit test.

Para utilizar o novo log (no formato HTML) é preciso alterar o trecho antigo pelo trecho destacado em verde na figura abaixo: . 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. o properties utilizado é o que está no pacote arquivosComuns.java e MétodosGenericos.properties a ser utilizado. No exemplo da figura.24 abaixo: Figura A .java devem seguir o exemplo da Figura A .properties IMPORTANTE Os imports das classes BA.23.24. Editando o config.84 Figura A .

85 Figura A . os arquivos já se encontram na nova estrutura. .prazos e testeSinergia. Os arquivos dos pacotes testeSinergia. Criação do log No SVN.weblince.25.weblince.logOperacoes já contemplam as alterações acima descritas.

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

87 Apêndice B – Tabela de tempos para comparação do teste manual e o automático .

1. A estrutura do workspace de automação também já estava atualizada. também já estava com a alteração do log. Além dessa mudança.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.500 MHz . pois a grade de vencimento já se encontrava no último nível da estrutura organizacional.1 GB RAM Pentium D . por isso caiu o desempenho. As células em laranja representam os testes que tiveram mudança no detalhamento. Basicamente o processador ficou dedicado aos processos relacionados com o teste automatizado.1. agora o detalhamento de um único BA é feito em todos os níveis da estrutura organizacional. .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.1GB RAM C .Micro Funcionário (IE 7) Pentium 4 .500 MHz . a partir disso foram feitos os detalhamentos dos outros BAs nas colunas normalmente.2. (III) Script executado no IE 6. (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.793MHz . 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 Automação (IE 7) Pentium 4 .

1.2. Ação de localizar o BA e seus dados na área de detalhamento .89 Apêndice D – Diagrama de Caso de Uso das principais ações feitas pelo testador Figura E . Visão geral das ações do testador Figura E .

Ação de localizar a estrutura organizacional do BA . Ação de localizar o executor do BA Figura E .4.90 Figura E .3.

6. Ação de inserir os dados da massa nos filtros da consulta . Ação de localizar o BA na grade de vencimentos Figura E .91 Figura E .5.

92 Apêndice E – Diagrama de Classes da Consulta Prazos dos BAs Figura F . Diagrama geral dos scripts criados e o menu .1.

Diagrama de classes geral do projeto .93 Figura F .2.

Sign up to vote on this title
UsefulNot useful