Automatizando Testes de Software Com Selenium

vi

RESUMO

A cada ano que passa, as empresas de software vêm aceitando o desafio de oferecer produtos/serviços de qualidade aos seus respectivos cli entes em prazo absurdamente curtos. O problema é que muitas delas não estão preparadas para tal façanha. Para entregar no prazo, muitos softwares são mal testados antes mesmos de serem disponibilizados em ambiente de produção. E o desfecho desfe cho disso tudo não pode ser outro: softwares incompletos e/ou cheios de bugs. Percebendo essa realidade, essa monografia estimula o autor a inovar seu ambiente de teste por meio da automação. Para isso contamos com uma excelente ferramenta gratuita chamada Selenium, que fornece inúmeros recursos para garantir testes rápidos sem abrir mão da qualidade. Importante ressaltar que não se trata de um manual da ferramenta, mas sim exemplos práticos dos benefícios que ela pode oferecer deixando em aberto a possibilidade de melhorias ao ser explorada.

Palavras-chave:

software, qualidade, bugs, teste, automação.

xi

SUMÁRIO

1. INTRODUÇÃO ............................................ ................................................................... ............................................. ............................................ ...................... 13 1.1. OBJETIVOS ............................................ ................................................................... ............................................. ............................................ ...................... 13 1.2. ORGANIZAÇÃO DO DOCUMENTO DOCUMENTO ........................................... .................................................................. .......................... ... 14 2. REVISÃO DA LITERATURA .......................................... ................................................................. ............................................ .....................15 2.1. QUALIDADE DE SOFTWARE SOFTWARE ........................................... .................................................................. ..................................... .............. 15 2.1.1. FATORES DE QUALIDADE ............................................ ................................................................... ................................. .......... 16 2.1.2. O DILEMA DILEMA DA QUALIDADE DE SOFTWARE..................... SOFTWARE............................................ .......................... ... 18 2.1.3. CUSTO DA QUALIDADE QUALIDADE ......................................... ............................................................... ......................................... ................... 19 2.1.4. COMO ALCANÇAR ALCANÇAR A QUALIDADE? ........................................... ............................................................. .................. 21 2.2. TESTE DE SOFTWARE ........................................... .................................................................. ............................................. ......................... ... 22 2.2.1. PROCESSO DE TESTE........................................... .................................................................. ............................................ ..................... 23 2.2.2. AMBIENTE DE TESTE .......................................... ................................................................. ............................................ ..................... 25 2.2.3. TÉCNICAS DE TESTE TESTE ........................................... .................................................................. ............................................ ..................... 30 2.3. INOVAÇÃO EM TESTE DE SOFTWARE SOFTWARE ........................................... .............................................................. ................... 32 2.3.1. AUTOMAÇÃO DE TESTES TESTES.......................................... ................................................................. ..................................... .............. 33 2.3.2. TESTES MANUAIS X TESTES TESTES AUTOMATIZADOS AUTOMATIZADOS .......................... ..................................... ........... 34 2.3.3. PRINCÍPIOS DA AUTOMAÇÃO AUTOMAÇÃO DE TESTE ............................................ ................................................... ....... 35 2.3.4. QUESTÕES ACERCA ACERCA DA AUTOMAÇÃO AUTOMAÇÃO............................................. ....................................................... .......... 36 3. MÉTODO ........................................... .................................................................. ............................................. ............................................. ................................. .......... 37 3.1. SELENIUM .......................................... ................................................................ ............................................ ............................................. .......................... ... 37 3.1.1. POR QUE QUE USAR USAR SELENIUM?................... SELENIUM?.......................................... .............................................. ................................. .......... 38 3.1.2. PLUGINS .......................................... ................................................................. ............................................. ............................................ ...................... 39 3.2. SELENIUM IDE IDE ......................................... ............................................................... ............................................ ......................................... ................... 40 3.2.1. CRIAÇÃO DOS SCRIPTS DE TESTE ............................................ ............................................................... ................... 41 3.2.2. EXECUÇÃO DOS SCRIPTS SCRIPTS DE TESTE ............................................. ........................................................... .............. 42 3.2.3. EXPORTANDO OS SCRIPTS DE TESTE ........................................... ......................................................... .............. 42 3.3. SELENIUM REMOTE CONTROL.......................................... ................................................................. ................................. .......... 44 3.3.1. EXECUÇÃO DOS DOS TESTES CROSS-BROWSER CROSS-BROWSER ........................................... .............................................. ... 45 3.4. SELENIUM WEBDRIVER ........................................... .................................................................. ............................................ ..................... 46 3.4.1. CONFIGURAÇÃO DO PROJETO DE TESTE ........................................... .................................................. ....... 46

xii

3.4.2. ESTRUTURA DA CLASSE CLASSE DE TESTE JUNIT .......................... ................................................ ...................... 48 3.4.3. EXECUÇÃO DO TESTE TESTE............................................ ................................................................... ......................................... .................. 50 3.5. SELENIUM GRID .......................................... ................................................................ ............................................ ..................................... ............... 51 3.5.1. CONFIGURAÇÃO DO PROJETO DE TESTE ........................................... .................................................. ....... 51 3.5.2. ESTRUTURA DA CLASSE DE TESTE TESTNG ............................................ ............................................ 52 3.5.3. ESTRUTURA DO ARQUIVO ARQUIVO XML ......................... ............................................... ......................................... ................... 55 3.5.4. CONFIGURANDO A REDE .......................................... ................................................................. ..................................... .............. 57 3.5.5. EXECUÇÃO DOS TESTES TESTES ........................................... .................................................................. ..................................... .............. 59

4. ESTUDO DE CASO ......................................... ............................................................... ............................................ ......................................... ................... 60 4.1. AMBIENTE DE TESTE ............................................ ................................................................... ............................................. ......................... ... 60 4.2. FERRAMENTA .......................................... ................................................................ ............................................ ......................................... ................... 62 4.3. COMPARATIVO DOS RESULTADOS DE TESTE......................................... TESTE................................................ ....... 63 5. CONCLUSÃO ........................................... ................................................................. ............................................ ............................................. .......................... ... 67 REFERÊNCIAS ........................................... ................................................................. ............................................ ............................................. .............................. ....... 68 GLOSSÁRIO ............................................ ................................................................... ............................................. ............................................. ................................. .......... 69 ANEXOS ............................................ .................................................................. ............................................ ............................................ ......................................... ................... 71 APÊNDICES ............................................. .................................................................... ............................................. ............................................. ................................. .......... 79

13

1.

INTRODUÇÃO A preocupação com a qualidade de software cresceu à medida que a imagem das

empresas passou a ficar cada vez mais exposta ao público mediante ao surgimento dos sistemas web. Por volta de 1990, grandes empresas desse ramo reconheciam que bilhões de dólares estavam sendo desperdiçados em softwares que não apresentavam características e funcionalidades prometidas. Viviam aquele dilema de querer produzir o soft ware “perfeito”, mas sem ter tempo e esforço necessários para a tal façanha. Isso as levaram a procurar novos meios de aperfeiçoar a qualidade. E um desses caminhos foi o aprimoramento das atividades relacionadas a teste de software por meio da automação. Diferente da filosofia que muitas organizações seguem, ter um ambiente de testes automatizados não é algo tão custoso e complexo como parece ser. Com o conhecimento conhecimento bem difundido, hoje temos a disposição diversas ferramentas de automação open sources, que com apenas uns cliques, já é possível criar scripts de testes eficientes que validam as funcionalidades do sistema quantas vezes for preciso de forma automática. Um bom exemplo disso é o uso da ferramenta Selenium, a qual será a proposta desse trabalho.

1.1. OBJETIVOS Essa monografia tem por objetivo apresentar todos os recursos disponíveis no Selenium e os benefícios que eles podem trazer para organizações que desejam implementar um ambiente de teste sem burocracia ou até mesmo aquelas organizações que já possuem esse ambiente, mas que almejam melhorar, seja no sentido de custos como também em praticidade. Aqui, o leitor pode acompanhar as atividades como: ●

Gravar/reproduzir scripts de testes

●

Exportar/integrar scripts de testes a um projeto de teste.

●

Executar testes em diferentes browsers

●

Executar testes simultâneos em diferentes dif erentes ambientes

14

1.2. ORGANIZAÇÃO DO DOCUMENTO Este documento est á organizado em mais quatro capítulos, além desse introdutório. O próximo capítulo apresenta a revisão de algumas obras literárias que abordam assuntos relacionados à Qualidade de Software, Teste de Software e Inovação em Teste de Software. No capítulo 3, encontra-se um manual prático das ferramentas que compõe a suíte Selenium. Já a implementação da proposta (estudo de caso) e descrita no capítulo 4. E finalizando, segue a conclusão no capitulo 5, onde é descrito a importância de automatizar os testes, o que a ferramenta Selenium contribuiu de acordo com o estudo de caso e o que ela contribuirá futuramente ao ser mais explorada.

15

2.

REVISÃO DA LITERATURA Este capítulo apresenta uma revisão de algumas obras literárias que abordam assuntos

envolvidos no tema central desse trabalho. Dentre eles temos: Qualidade de Software, Teste de Software e Inovação em Teste de Software.

2.1. QUALIDADE DE SOFTWARE Definir qualidade não é algo trivial quanto parece. Para Presumam (2011), qualidade em software e algo que precisa ser definido em um nível mais pragmático. Para isso, ele se baseia no conceito de David Gravai (Gar84), que defini o tema em cinco pontos de vista diferentes:

Visão Transcendental: Sustenta que a qualidade é algo que se reconhece imediatamente, mas não se consegue definir explicitamente.

Visão do Usu ário: Vê a qualidade em termos das metas especificas de um usuário final. Se um produto atende essas metas, ele apresenta qualidade.

Visão do Fabricante: Defini qualidade em termos de especifica ção original do produto. Se o produto atende as especifica ções, ele apresenta qualidade.

Visão do Produto: Sugere que a qualidade pode ser ligada a características inerentes de um produto, como por por exemplo, funções funções e recursos. recursos.

Visão do Valor: Mede a qualidade tomando como base o quanto um cliente estaria disposto a pagar pelo produto. produto.

16

2.1.1. FATORES DE QUALIDADE A ISO/IEC 25000 1, conhecida como SQuaRE (System and Software Quality Requirements Requireme nts and Evaluation), uniu as normas ISO/IEC 9126 (modelo) e ISO/IEC 14598 (processo) com o objetivo de aperfeiçoar a avaliação de qualidade do software. Em sua divisão ISO/IEC 2501n , encontramos o modelo ISO/IEC 25010 , que defini as características e subcaracterísticas que um software precisa ter para ser considerado um “software de qualidade”. 

Adequação Funcional o o o



Completude: Capacidade em que as funcionalidades abrangem todos os requisitos do usuário. Exatidão: Capacidade em que o sistema apresenta resultados corretos. Adequação: Capacidade em que as funcionalidades possuem em se adequar aos requisitos do usuário.

Eficiência do Desempenho o o o

Tempo de Comportamento: Capacidade de tempo de resposta, processamento ou transferência das requisições efetuadas pelo sistema. Utilização de Recursos: Capacidade em que os recursos (processador, memória, etc) são utilizados pelo sistema. Capacidade: Capacidade: Capacidade em que o sistema suporta as transações.



Compatibilidade



Coexistência: Capacidade em que o software se desempenha ao compartilhar o mesmo ambiente com outros softwares. o Interoperabilidade: Capacidade em que os softwares se comunicam (troca de informações) um com outro. Usabilidade o

o o o

1

R econhecibilidade: econhecibilidade: Capacidade em que o usuário reconhece se o software atende bem suas necessidades. Apreensibilidade: Capacidade em que o software pode ser usado por usuários específicos para atender objetivos específicos em nível de aprendizagem. Operacionalidade: Operacionalidade: Capacidade que o usuário possui em operar o software.

ISO/IEC 25000:2014. System and software engineeiring. Disponível . >. Acesso 07/12/2015

em: em:

17 o o o



Confiabilidade o o o



Maturidade: Capacidade que o software possui em atender necessidades de Confiabilidade em operações normais. Tolerância a falhas: Capacidade que o software possui de funcionar bem, mesmo com falha de hardware ou demais softwares. Recuperabilidade: Capacidade que o software tem de voltar ao seu estado normal após as interrupções.

Segurança o o o o o



Proteção contra erros: Capacidade em que o sistema possui e evitar erros de manuseio por parte do usuário. Estética da interface: Capacidade em que a interface do sistema possui em se interagir de forma satisfatória e agradável com o usuário. Acessibilidade: Capacidade em que o software possui de ser operado por diversos tipos de usuários, de diferentes necessidades.

Confidencialidade: Capacidade que o software possui de disponibilizar informações apenas para usuários autorizados. Integridade: Capacidade em que o software possui de impedir acessos ou alterações indevidas. Não repúdio: Capacidade do software em reconhecer reconhecer a veracidade de certas ações e eventos para não repudiá-los em outro momento. Prestação de contas: Capacidade que software possui de atribuir um ação a uma entidade. Autenticidade: Capacidade de o software reconhecer a verdadeira identidade de um recurso.

Manutenibilidade o o o o o

Modularidade: Capacidade que o software possui de ter seus componentes trocados sem haver impacto entre eles. Reutilização: Capacidade que o ativo tem em ser reutilizado em mais de um sistema. Analisabilidade: Capacidade de o software medir os impactos das trocas de componentes componentes como também de identificar as devidas correções. Modificabilidade: Capacidade do software possui de não apresentar falhas após as modificações, seja por melhoria ou por correção de erros. Testabilidade: Capacidade Capacidade do software de se enquadrar aos critérios de testes.

18 

Portabilidade o o o

Adaptabilidade: Capacidade do software de se adaptar aos mais variados tipos de ambientes. Instabilidade: Capacidade de o software ser instalado e desinstalado de um ambiente. Substitutibilidade: Capacidade de o software tem em ser substituído por outro em menor impacto possível.

2.1.2. O DILEMA DA QUALIDADE DE SOFTWARE Sobre qualidade nas organizações, Pressman (2011) cita uma entrevista (Ven03) publicada na internet, onde Bertrand Meyer discute o que chamamos de dilema da

qualidade: Se produzirmos um sistema de software de péssima qualidade, perdemos porque ninguém irá querer comprá-los. Se, por outro lado, gastamos um tempo infinito, um esforço extremamente grande e grandes somas de dinheiro para construir um software absolutamente perfeito, então isso levará muito tempo para ser completado, e o custo de produção será tão alto que iremos à falência. Ou perdemos a oportunidade de mercado ou então simplesmente esgotamos todos os nossos recursos. Dessa maneira, os profissionais dessa área tentam encontrar aquele meiotermo mágico onde o produto e suficientemente bom para não ser rejeitado logo de cara, como por exemplo, durante uma avaliação, mas também não é o objeto de tamanho protecionismo e trabalho que levaria muito tempo ou que custaria demasiadamente para ser finalizado.

Em outras palavras, esse dilema refere-se à Lei de Meskimen, que diz: “Nunca há tempo para fazer a coisa certa, mas sempre há tempo para fazê -la de novo. ”.

Embora haja pontos negativos para ambas as decisões, Pressman (2011), aconselha que tomar o tempo necessário para fazer o certo na primeira vez nunca é uma decisão errada.

19

2.1.3. CUSTO DA QUALIDADE Ainda sobre o dilema, é comum nos depararmos com a seguinte objeção apresentada por muitas empresas: “Sabemos que a qualidade é importante, mas ela nos custa tempo e dinheiro em demasia para obter o nível de qualidade de software que realmente desejamos. desejamos. ”. Para Pressman (2011), não há dúvida nenhuma que a qualidade tem um preço, mas a falta dela também tem um preço — preço — não não apenas para os usuários finais, fi nais, que terão que conviver com um software com erros, mas também para a organização de software que o criou e, além de tudo, terá de fazer manutenção. E isso nos leva a seguinte questão: Qual custo deveríamos nos preocupar? O custo da alta qualidade ou o custo gerado por uma baixa qualidade? Os custos da qualidade englobam todos os custos envolvidos na busca, execução ou falta da mesma. São classificados em:

Custo de prevenção : Incluem o custo de atividades de gerenciamento necessárias para planejar e coordenar todas as atividades de controle e garantia da qualidade. O custo de atividades técnicas adicionais para desenvolver modelos completos de requisitos e de projeto. Custos de planejamento de testes e o custo de todo o treinamento associado a essas atividades. atividades.

Custo de avaliação : Incluem atividades para a compreensão aprofundada de condição do produto “a primeira vez através de” cada processo. Entre os exemplos de custos de avaliação temos:



Custo para realização de revisões técnicas para produtos resultantes de engenharia de software.



Custo para coleta de dados e avaliação de métricas.



Custo de testes e depuração.

Custo de falhas : São aqueles que desapareceriam caso nenhum erro tivesse surgido antes ou depois da entrega de um produto a clientes. Esses custos podem ser subdivididos em custos de falhas internas e custos de falhas externas. Os custos de falhas internas ocorrem quando se detecta um erro em um produto antes dele se entregue e abrangem:

20 

Custo necessário para realizar trabalhos (reparos) para corrigir um erro.



Custo que ocorre quando trabalhos geram, inadvertidamente, efeitos colaterais que devem ser reduzidos.



Custos associados reunião de métricas de qualidade que permitem a uma organização avaliar os modos de falha. Por outro lado, os custos de falhas externas estão associados a defeitos encontrados

após o produto ter sido entregue ao cliente. Custos esse provenientes de reclamações, devolução/substituição de produtos, suporte por telefone/mal e até custos por mão de obra associada à garantia do produto. Quanto ao valor aproximado dos custos, isso fica relativo à medida um erro/defeito vai progredindo da etapa etapa de prevenção prevenção à detecção detecção de falhas internas internas e externas. Através Através dos dados dados coletados por Boehm e Basili (Boe01b), a Cigital Inc (Cig07) exemplifica esse cenário através da ilustração abaixo:

Figura 1 - Custo relativo à correção de erros err os e defeitos Fonte: Pressman (2011, p.367)

21

Como vemos na Figura 2.1, o custo médio da indústria de software para corrigir um defeito durante a geração de código é aproximadamente US$ 977 por erro. O custo médio para corrigir o mesmo erro caso ele tenha sido descoberto durante os testes (falha interna) do do sistema, passa a ser de US$ 7.136 por erro. E esse custo pode dobrar, caso o erro seja detectado pelo usuário final (falha externa), chegando a um valor de aproximadamente de US$ 14.102 por erro. Essa análise levou Pressman (2011) à conclusão de que mesmo a organização de software tendo custos equivalentes à metade da média do setor, a economia de custos associados a atividades iniciais de controle com garantia de qualidade é considerável.

2.1.4. COMO ALCANÇAR A QUALIDADE? A qualidade de software não aparece simplesmente do nada. Ela é o resultado de um bom gerenciamento gerenciamento de projeto e uma prática consistente de engenharia de software, afirma Pressman (2011). Esse gerenciamento e prática são aplicados no contexto de quatro grandes atividades que ajudam uma equipe a atingir o alto padrão de qualidade em software. São elas:

Métodos de Engenharia de Software: Se a expectativa é construir software de qualidade, é importante entender o problema a ser resolvido. Ter a capacidade de criar um projeto de que seja adequado ao problema e, ao mesmo tempo, apresentar características que levem a um software com as dimensões e fatores de qualidade.

Técnicas de Gerenciamento de Software: A qualidade de software é afetada positivamente quando um gerente de projeto usar estimativas para verificar que as datas de entrega são plausíveis. Quando as dependências dependências de cronograma forem entendidas e a equipe resistir à tentação de usar atalhos. Quando o planejamento de riscos for conduzido de moda que os problemas não gerem gerem caos.

Controle de Qualidade: Aplica-se uma série de etapas de teste para descobrir erros na lógica ló gica de processamento, na manipulação de dados e na comunicação comunicação de interface. Uma combinação de medições e realimentação ( feedback ) permite a uma equipe de software ajustar o processo quando qualquer um desses produtos resultantes deixe de atender as metas estabelecidas para a qualidade.

22

Garantia da Qualidade: Consiste em um conjunto de funções de auditoria e de relatórios que possibilita uma avaliação de efetividade e da completude das ações de controle de qualidade. Tem como objetivo fornecer ao pessoal técnico administrativo os dados necessários para ser informados sobre a qualidade do produto, ganhando, portanto, entendimento e confiança de que as ações para atingir a qualidade desejada do produto estão funcionando.

2.2. TESTE DE SOFTWARE Teste de Software é uma boa prática realizada em um desenvolvimento de software, onde seu principal objetivo, segundo Bastos (2012), é reduzir os riscos que as aplicações podem trazer para os negócios. E para Pressman (2011), um bom teste é aquele que possui uma série de características que o permite encontrar o maior número de erros possíveis com o mínimo de esforço. Ainda no conceito de teste, Bastos (2012), relata que grandes modelos de melhoria de processos de desenvolvimento de software tais como CMMI e MPS. BR contemplaram as atividades de testes, identificando-as nas áreas de verificação e validação, que por sinal, são termos com sentidos completamente diferentes.

Verificação: testes que permitem verificar se o software está sendo construído corretamente. Validação: teste que permitem validar se o software está fazendo o que foi definido nos requisitos. Em outras palavras:

Verificação: A forma que construímos o software está correta? Validação: O software que construirmos, está correto? Em aplicações convencionais, Pressman (2011) diz que o software é testado em duas perspectivas diferentes: caixa branca e caixa preta.

23

Teste de Caixa Branca : Fundamenta-se em um exame rigoroso do detalhe procedimental. Os caminhos lógicos do software e as colaborações entre componentes são testados, exercitando conjuntos específicos de condições e/ou ciclos.

Teste de Caixa Preta : Faz referência a testes realizados na interface do software. Examina alguns aspectos fundamentais de um sistema, com pouca preocupação em relação à estrutura lógica interna do software.

2.2.1. PROCESSO DE TESTE De acordo com Bastos (2012), pressupõe que o processo de teste esteja em paralelo ao processo de desenvolvimento. Para isso, ele menciona menciona a utilização utilização do

conceito “V”.

Figura 2 - Conceito “V” de teste de software Fonte: Bastos (2012, p.41)

Como podemos ver na figura 2.2, ambas as equipes começam do mesmo ponto. Na etapa de especificação, enquanto a equipe de desenvolvimento é encarregada de capturar e documentar os requisitos com o propósito de desenvolver o sistema, a equipe de teste realizar o mesmo procedimento, porém com a finalidade de testar o sistema. Ao entrar na etapa de execução, testes de verificação e validação são respectivamente aplicados em conjunto à construção e instalação/manutenção do sistema.

24

É importante ressaltar, que o conceito “V” é focado nas etapas de especificação e execução do processo de teste. A forma mais abrangente do processo é descrita no que chamamos de Ciclo de Vida de Testes . Ao mencionar o livro Teste de Software, Bastos (2012) diz que os autores Rios (2003) e Moreira (2003), utilizam a metodologia Test Management (TMap) para ilustrar o ciclo de vida de testes de forma bem didática e de fácil visualização.

Figura 3 - Modelo 3P x 3E do ciclo de vida dos testes. Fonte: Bastos (2012, p.45)

O ciclo é composto por seis etapas, sendo quatro delas sequenciais e duas paralelas. Abaixo, segue a descrição e função de cada etapa:

Procedimentos Iniciais: Etapa onde é realizado um estudo aprofundado dos requisitos de negócios do sistema a ser desenvolvido. Garantindo que o mesmo esteja completo de sem redundâncias. Após isso, devem ser definidas as principais atividades de testes que serão executadas.

Planejamento: Etapa que consiste na elaboração de uma estratégia de teste e um plano de teste, visando minimizar os principais riscos ao negócio e fornecer caminhos para as próximas etapas.

37

3.

MÉTODO Nesse capítulo será apresentada a proposta de automação de testes através do conjunto

de ferramentas Selenium, que são elas: Selenium IDE, Selenium RC, Selenium WebDriver e Selenium Grid

3.1. SELENIUM Em 2004, o testador Jason Higging estava testando uma aplicação interna da ThoughtWorks (empresa que tem como foco desenvolvimento ágil de software), quando percebeu que poderia gerenciar ger enciar melhor mel hor seu tempo nas atividades ati vidades de teste manuais. Para isso, ele criou uma biblioteca Javascript que interagia com o browser , que logo em breve, passaria a interagir com demais browsers. A esse projeto foi lhe concedido o nome de Selenium, que na verdade, trata-se de uma analogia sobre uma ferramenta teste alternativa ( open source) para testadores que não suportavam mais ficar dependentes da ferramenta Quick Test, da empresa Mercury, que por sinal era paga e bem cara. Na química, o antídoto do Mercúrio é o Selênio. Está aí, o porquê do nome.

Ao chegar ao ano de 2006, o engenheiro da Google chamado Simon Stewart resolveu explorar mais ainda a biblioteca Selenium, criando assim o projeto WebDriver, onde acabou sendo mesclado com a antiga biblioteca (Selenium RC), dando origem a segunda versão do Selenium em 2008.

38

Hoje, o Selenium3 é uma suíte composta pelas ferramentas:

Remote Control, Selenium WebDriver e Selenium Grid .

Selenium IDE, Selenium

Cada um com uma finalidade,

mas com objetivos em comum, que é garantir a automação dos testes funcionais de forma prática e eficiente.

Figura 7 - Ferramentas do Selenium. Fonte: SeleniumHQ – Browser Browser Automation

3.1.1. POR QUE USAR SELENIUM? Embora já existam diversas ferramentas de automação de teste, o Selenium se destaca por ser um conjunto de ferramentas, f erramentas, permitindo ao usuário testar tes tar as aplicações web nas mais diversas formas de automação, como por exemplo:



Criar e executar scripts de d e testes independente do browser ou sistema operacional.



Realizar Testes de Carga/Estresse através da execução de teste em diversos browsers, provenientes de um ou mais computadores. computadores.



Adicionar plug-ins que permitem elaborar scripts de testes robustos e que atendem as necessidades dos negócios.



3

Integrar os scripts de teste a um projeto de teste, seja em Java, C#, PHP, Python ou Ruby.

Selenium SELENIUM HQ BROWSER AUTOMATION. http://www.seleniumhq.org/projects/>. Acesso em: 07/11/2015 http://www.seleniumhq.org/projects/>.

Projects .

Disponível

em:

<

39

3.1.2. PLUGINS Os plug-ins podem ser novas extensões (.xpi) do browser Firefox ou arquivos javascript (.js), que tem o caminho apontado no próprio IDE do Selenium.

Segue a lista dos principais plug-ins:

Selenium IDE Button:

Permite alternar a exibição da IDE do Selenium. Seja em um pop-up

ou no próprio frame do browser . de teste. Flow Control: Adiciona comandos de repetição ao script de

ScreenShot on Fail: Registra um print screen da tela no momento em que ocorreu um erro na execução do teste.

CSV File Reader: Adiciona comandos que faz com que os scripts de testes se interagem com dados armazenados em arquivos .csv.

PHP Formatters: Converte a sintaxe dos scripts de teste para a linguagem php, exportandoos para um novo arquivo no formato .php.

XML Formatters:

Converte a sintaxe dos scripts de teste para a linguagem XML,

exportando-os para um novo arquivo no formato .xml

Pretty Report: Exporta os resultados de testes em um relatório com um visual mais bonito e legível.

40

3.2. SELENIUM IDE Uma extensão para o browser Firefox, onde o usuário pode criar, editar, executar e depurar os scripts de teste. Conta com uma lista de comandos (os mesmos usados na biblioteca WebDriver) que interagem com a aplicação web, como por exemplo: acesso aces so a uma url, clique no botão, digitação no campo, verificação de texto na página e entre outros.

Figura 8 - IDE do Selenium. Fonte: Autoria própria

1) Barra de Ferramentas Possui as funcionalidades que gerenciam os testes como gravar, executar, pausar, etc.

2) Lista de Casos de Teste Lista dos casos de teste que compõe a suíte de teste em uso.

41

3) Editor de Script Espaço para editar o script do do caso de teste selecionado, podendo definir o step em que o teste irá iniciar ou parar.

4) Rodapé Log da execução do caso de teste selecionado.

3.2.1. CRIAÇÃO DOS SCRIPTS DE TESTE Nesse exemplo, enviaremos uma mensagem para o site

Crowdtest.

Para isso será

criando o script : EnviarMensagem.

O roteiro do teste consiste em acessar a url base, clicar no menu Contato, preencher o formulário e clicar no botão Enviar.

Figura 9 - Script para enviar mensagem. Fonte: Autoria própria

Para salvar o teste, basta ir à opção Arquivo > Salvar Teste . O arquivo deve ser salvo no formato .html. Ex: EnviarMensagem.html.

42

3.2.2. EXECUÇÃO DOS SCRIPTS DE TESTE Ao clicar no botão

Executar,

inicia-se o teste, validando as etapas: Acessar Tela de

Contato (Anexo A), Preencher Campos (Anexo B) e Enviar Mensagem (Anexo C).

3.2.3. EXPORTANDO OS SCRIPTS DE TESTE Por padrão, o Selenium IDE 4 salva o script no formato HyperText Markup Language (.html). Porém, é possível exportá-lo em outro formato para que possa ser integrado a projetos de teste (como veremos no capítulo 3.3).

Na imagem a seguir, o caso de teste é exportado no formato Java (.java):

Figura 10 - Exportação do caso de teste no formato Java. Fonte: Autoria própria

4

SELENIUM HQ BROWSER AUTOMATION. Selenium IDE http://www.seleniumhq.org/projects/ide/>. Acesso em: 08/11/2015 http://www.seleniumhq.org/projects/ide/>

Plugins.

Disponível

em:

<

63

4.3. COMPARATIVO DOS RESULTADOS DE TESTE Para facilitar a visualização, segue abaixo os comparativos dos resultados entre os testes manuais e automatizados. A coluna Diferença mostra a eficiência em porcentagem dos testes automatizados para com os testes manuais. Os números chegam a impressionar, veja:

Selenium Test v1.0

Tempo de Execução Caso de Teste

Manual (s) Automatizado (s) Diferença (%)

Login Inválido Inváli do

22

6

266,67

Efetuar Login

18

10

80,00

Validar Campos Obrigatórios Cliente

59

24

145,83

Cadastrar Cliente

57

21

171,43

Validar Campos Obrigatórios Usuários 21

13

61,54

Cadastrar Usuário

45

16

181,25

Validar Falha Envio Email

30

13

130,77

Validar Sucesso Envio Email

33

15

120,00

Quadro 12 - Comparativo dos testes por tempo de execução (versão 1). Fonte: Autoria própria

Gráfico 1 - Comparativo dos testes por tempo de execução (versão 1). Fonte: Autoria própria

64

Caso de Teste

Bugs Encontrados15 Manual (s) Automatizado (s) Diferença (%)


0

0

0

Efetuar Login

0

0

0


0

0

0

Cadastrar Cliente

0

0

0


0

0

Cadastrar Usuário

0

0

0


0

0

0


0

0

0

Quadro 13 - Comparativo dos testes por bugs encontrados (versão 1). Fonte: Autoria própria

Gráfico 2 - Comparativo dos testes por bugs encontrados (versão 1). Fonte: Autoria própria

15

Já que o Selenium Test v1.0 foi testada diversas vezes d urante o desenvolvimento, não houve indícios de bugs neste relatório.

65

Selenium Test v2.0

Tempo de Execução Caso de Teste

Manual (s) Automatizado (s) Diferença (%)


20

6

233,33

Efetuar Login

17

7

142,86


68

25

172,00

Cadastrar Cliente

65

25

160,00


15

20,00

Cadastrar Usuário

42

18

133,33


30

15

100,00


31

14

121,43

Quadro 14 - Comparativo dos testes por tempo de execução (versão 2). Fonte: Autoria própria

Gráfico 3 - Comparativo dos testes por tempo de execução (versão 2). Fonte: Autoria própria

66

Caso de Teste

Bugs Encontrados Encontrados Manual (s) Automatizado (s) Diferença (%)


0

1

100

Efetuar Login

0

1

100


0

1

100

Cadastrar Cliente

1

2

50


0

0

Cadastrar Usuário

0

1

100


0

1

100


0

1

100

Quadro 15 - Comparativo dos testes por bugs encontrados (versão 2). Fonte: Autoria própria

Gráfico 4 - Comparativo dos testes por bugs encontrados (versão 2). Fonte: Autoria própria

Notou a enorme diferença com relação às versões dos relatórios? Fica notório que o testador (Felipe Lima) tentou demonstrar eficiência no tempo de execução dos testes, não dando muita atenção aos pequenos detalhes. Isso explica o porquê encontrou apenas um bug, quando na verdade, havia mais sete escondidos na aplicação.

Já o “robô”, conseguiu detectar todos os bugs em um tempo bem menor, provando em números, que é possível sim manter um equilíbrio satisfatório entre o Tempo e a Qualidade.

Automatizando Testes de Software Com Selenium

Recommend Documents