Sei sulla pagina 1di 25

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

2. REVISÃO DA LITERATURA ...................................................................................... 15


2.1. QUALIDADE DE SOFTWARE ................................................................................ 15
2.1.1. FATORES DE QUALIDADE ............................................................................. 16
2.1.2. O DILEMA DA QUALIDADE DE SOFTWARE............................................... 18
2.1.3. CUSTO DA QUALIDADE .................................................................................. 19
2.1.4. COMO 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 ....................................................................................... 30
2.3. INOVAÇÃO EM TESTE DE SOFTWARE .............................................................. 32
2.3.1. AUTOMAÇÃO DE TESTES............................................................................... 33
2.3.2. TESTES MANUAIS X TESTES AUTOMATIZADOS ..................................... 34
2.3.3. PRINCÍPIOS DA AUTOMAÇÃO DE TESTE ................................................... 35
2.3.4. QUESTÕES ACERCA DA AUTOMAÇÃO ....................................................... 36

3. MÉTODO......................................................................................................................... 37
3.1. SELENIUM ................................................................................................................ 37
3.1.1. POR QUE USAR SELENIUM?........................................................................... 38
3.1.2. PLUGINS ............................................................................................................. 39
3.2. SELENIUM IDE ........................................................................................................ 40
3.2.1. CRIAÇÃO DOS SCRIPTS DE TESTE ............................................................... 41
3.2.2. EXECUÇÃO DOS 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 TESTES 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 DE TESTE JUNIT ................................................ 48


3.4.3. EXECUÇÃO DO 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 XML .................................................................. 55
3.5.4. CONFIGURANDO A REDE ............................................................................... 57
3.5.5. EXECUÇÃO DOS TESTES ................................................................................ 59

4. ESTUDO DE CASO ........................................................................................................ 60


4.1. AMBIENTE DE TESTE ............................................................................................ 60
4.2. FERRAMENTA ......................................................................................................... 62
4.3. COMPARATIVO DOS RESULTADOS DE 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 software “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 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 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 exemplo, funções e recursos.

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

2.1.1. FATORES DE QUALIDADE

A ISO/IEC 250001, conhecida como SQuaRE (System and Software Quality


Requirements 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 Completude: Capacidade em que as funcionalidades abrangem todos os


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

 Eficiência do Desempenho

o Tempo de Comportamento: Capacidade de tempo de resposta, processamento


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

 Compatibilidade

o 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 Reconhecibilidade: Capacidade em que o usuário reconhece se o software


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

1
ISO/IEC 25000:2014. System and software engineeiring. Disponível em:
<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64764>. Acesso em:
07/12/2015
17

o Proteção contra erros: Capacidade em que o sistema possui e evitar erros de


manuseio por parte do usuário.
o 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.
o Acessibilidade: Capacidade em que o software possui de ser operado por
diversos tipos de usuários, de diferentes necessidades.

 Confiabilidade

o Maturidade: Capacidade que o software possui em atender necessidades de


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

 Segurança

o Confidencialidade: Capacidade que o software possui de disponibilizar


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

 Manutenibilidade

o Modularidade: Capacidade que o software possui de ter seus componentes


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

 Portabilidade

o Adaptabilidade: Capacidade do software de se adaptar aos mais variados tipos


de ambientes.
o Instabilidade: Capacidade de o software ser instalado e desinstalado de um
ambiente.
o 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 meio-
termo 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.”.

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 — não apenas para os usuários finais, 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.

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 de prevenção à detecção de falhas internas e externas. Através dos 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 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
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 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 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 caos.

Controle de Qualidade: Aplica-se uma série de etapas de teste para descobrir erros na lógica
de processamento, na manipulação de dados e na 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 a 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 melhor seu tempo nas atividades 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: Selenium IDE, Selenium
Remote Control, Selenium WebDriver e Selenium Grid. 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 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, permitindo ao usuário testar as aplicações web nas mais
diversas formas de automação, como por exemplo:

 Criar e executar scripts de 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.

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

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

3
SELENIUM HQ BROWSER AUTOMATION. Selenium Projects. Disponível em: <
http://www.seleniumhq.org/projects/>. Acesso em: 07/11/2015
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.

Flow Control: Adiciona comandos de repetição ao script de teste.

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, exportando-
os 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 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 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 IDE4 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 Plugins. Disponível em: <
http://www.seleniumhq.org/projects/ide/>. Acesso em: 08/11/2015
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 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

Bugs Encontrados15
Caso de Teste Manual (s) Automatizado (s) Diferença (%)
Login Inválido 0 0 0
Efetuar Login 0 0 0
Validar Campos Obrigatórios Cliente 0 0 0
Cadastrar Cliente 0 0 0
Validar Campos Obrigatórios Usuários 0 0 0
Cadastrar Usuário 0 0 0
Validar Falha Envio Email 0 0 0
Validar Sucesso Envio Email 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 durante 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 (%)
Login Inválido 20 6 233,33
Efetuar Login 17 7 142,86
Validar Campos Obrigatórios Cliente 68 25 172,00
Cadastrar Cliente 65 25 160,00
Validar Campos Obrigatórios Usuários 18 15 20,00
Cadastrar Usuário 42 18 133,33
Validar Falha Envio Email 30 15 100,00
Validar Sucesso Envio Email 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

Bugs Encontrados
Caso de Teste Manual (s) Automatizado (s) Diferença (%)
Login Inválido 0 1 100
Efetuar Login 0 1 100
Validar Campos Obrigatórios Cliente 0 1 100
Cadastrar Cliente 1 2 50
Validar Campos Obrigatórios Usuários 0 0 0
Cadastrar Usuário 0 1 100
Validar Falha Envio Email 0 1 100
Validar Sucesso Envio Email 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.

Potrebbero piacerti anche