vi

RESUMO

A cada ano que passa, as empresas de software vm aceitando o desafio de oferecer

produtos/servios de qualidade aos seus respectivos clientes em prazo absurdamente curtos. O
problema que muitas delas no esto preparadas para tal faanha. Para entregar no prazo,
muitos softwares so mal testados antes mesmos de serem disponibilizados em ambiente de
produo. E o desfecho disso tudo no 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 automao. Para isso contamos com uma excelente ferramenta gratuita
chamada Selenium, que fornece inmeros recursos para garantir testes rpidos sem abrir mo
da qualidade. Importante ressaltar que no se trata de um manual da ferramenta, mas sim
exemplos prticos dos benefcios que ela pode oferecer deixando em aberto a possibilidade de
melhorias ao ser explorada.

Palavras-chave: software, qualidade, bugs, teste, automao.

 xi

SUMRIO

1. INTRODUO ............................................................................................................... 13
1.1. OBJETIVOS ............................................................................................................... 13
1.2. ORGANIZAO DO DOCUMENTO ..................................................................... 14

2. REVISO 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 ALCANAR 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. TCNICAS DE TESTE ....................................................................................... 30
2.3. INOVAO EM TESTE DE SOFTWARE .............................................................. 32
2.3.1. AUTOMAO DE TESTES............................................................................... 33
2.3.2. TESTES MANUAIS X TESTES AUTOMATIZADOS ..................................... 34
2.3.3. PRINCPIOS DA AUTOMAO DE TESTE ................................................... 35
2.3.4. QUESTES ACERCA DA AUTOMAO ....................................................... 36

3. MTODO......................................................................................................................... 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. CRIAO DOS SCRIPTS DE TESTE ............................................................... 41
3.2.2. EXECUO DOS SCRIPTS DE TESTE ........................................................... 42
3.2.3. EXPORTANDO OS SCRIPTS DE TESTE ......................................................... 42
3.3. SELENIUM REMOTE CONTROL........................................................................... 44
3.3.1. EXECUO DOS TESTES CROSS-BROWSER .............................................. 45
3.4. SELENIUM WEBDRIVER ....................................................................................... 46
3.4.1. CONFIGURAO DO PROJETO DE TESTE .................................................. 46
 xii

3.4.2. ESTRUTURA DA CLASSE DE TESTE JUNIT ................................................ 48

3.4.3. EXECUO DO TESTE ..................................................................................... 50
3.5. SELENIUM GRID ..................................................................................................... 51
3.5.1. CONFIGURAO 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. EXECUO 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. CONCLUSO ................................................................................................................. 67

REFERNCIAS ..................................................................................................................... 68

GLOSSRIO .......................................................................................................................... 69

ANEXOS ................................................................................................................................. 71

APNDICES ........................................................................................................................... 79
 13

1. INTRODUO

A preocupao com a qualidade de software cresceu medida que a imagem das

empresas passou a ficar cada vez mais exposta ao pblico mediante ao surgimento dos
sistemas web.

Por volta de 1990, grandes empresas desse ramo reconheciam que bilhes de dlares
estavam sendo desperdiados em softwares que no apresentavam caractersticas e
funcionalidades prometidas. Viviam aquele dilema de querer produzir o software perfeito,
mas sem ter tempo e esforo necessrios para a tal faanha. Isso as levaram a procurar novos
meios de aperfeioar a qualidade. E um desses caminhos foi o aprimoramento das atividades
relacionadas a teste de software por meio da automao.

Diferente da filosofia que muitas organizaes seguem, ter um ambiente de testes

automatizados no algo to custoso e complexo como parece ser. Com o conhecimento bem
difundido, hoje temos a disposio diversas ferramentas de automao open sources, que com
apenas uns cliques, j possvel criar scripts de testes eficientes que validam as
funcionalidades do sistema quantas vezes for preciso de forma automtica. 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 disponveis no Selenium
e os benefcios que eles podem trazer para organizaes que desejam implementar um
ambiente de teste sem burocracia ou at mesmo aquelas organizaes que j possuem esse
ambiente, mas que almejam melhorar, seja no sentido de custos como tambm 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 simultneos em diferentes ambientes
 14

1.2. ORGANIZAO DO DOCUMENTO

Este documento est organizado em mais quatro captulos, alm desse introdutrio. O
prximo captulo apresenta a reviso de algumas obras literrias que abordam assuntos
relacionados Qualidade de Software, Teste de Software e Inovao em Teste de Software.
No captulo 3, encontra-se um manual prtico das ferramentas que compe a sute Selenium.
J a implementao da proposta (estudo de caso) e descrita no captulo 4. E finalizando, segue
a concluso no capitulo 5, onde descrito a importncia 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. REVISO DA LITERATURA

Este captulo apresenta uma reviso de algumas obras literrias que abordam assuntos
envolvidos no tema central desse trabalho. Dentre eles temos: Qualidade de Software, Teste
de Software e Inovao em Teste de Software.

2.1. QUALIDADE DE SOFTWARE

Definir qualidade no algo trivial quanto parece. Para Presumam (2011), qualidade
em software e algo que precisa ser definido em um nvel mais pragmtico. Para isso, ele se
baseia no conceito de David Gravai (Gar84), que defini o tema em cinco pontos de vista
diferentes:

Viso Transcendental: Sustenta que a qualidade algo que se reconhece imediatamente,

mas no se consegue definir explicitamente.

Viso do Usurio: V a qualidade em termos das metas especificas de um usurio final. Se

um produto atende essas metas, ele apresenta qualidade.

Viso do Fabricante: Defini qualidade em termos de especificao original do produto. Se o

produto atende as especificaes, ele apresenta qualidade.

Viso do Produto: Sugere que a qualidade pode ser ligada a caractersticas inerentes de um
produto, como por exemplo, funes e recursos.

Viso 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 aperfeioar a avaliao de qualidade do software.

Em sua diviso ISO/IEC 2501n, encontramos o modelo ISO/IEC 25010, que defini
as caractersticas e subcaractersticas que um software precisa ter para ser considerado um
software de qualidade.

Adequao Funcional

o Completude: Capacidade em que as funcionalidades abrangem todos os

requisitos do usurio.
o Exatido: Capacidade em que o sistema apresenta resultados corretos.
o Adequao: Capacidade em que as funcionalidades possuem em se adequar
aos requisitos do usurio.

Eficincia do Desempenho

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

ou transferncia das requisies efetuadas pelo sistema.
o Utilizao de Recursos: Capacidade em que os recursos (processador,
memria, etc) so utilizados pelo sistema.
o Capacidade: Capacidade em que o sistema suporta as transaes.

Compatibilidade

o Coexistncia: 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
informaes) um com outro.
Usabilidade

o Reconhecibilidade: Capacidade em que o usurio reconhece se o software

atende bem suas necessidades.
o Apreensibilidade: Capacidade em que o software pode ser usado por usurios
especficos para atender objetivos especficos em nvel de aprendizagem.
o Operacionalidade: Capacidade que o usurio possui em operar o software.

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

o Proteo contra erros: Capacidade em que o sistema possui e evitar erros de

manuseio por parte do usurio.
o Esttica da interface: Capacidade em que a interface do sistema possui em se
interagir de forma satisfatria e agradvel com o usurio.
o Acessibilidade: Capacidade em que o software possui de ser operado por
diversos tipos de usurios, de diferentes necessidades.

Confiabilidade

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

Confiabilidade em operaes normais.
o Tolerncia 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 aps as interrupes.

Segurana

o Confidencialidade: Capacidade que o software possui de disponibilizar

informaes apenas para usurios autorizados.
o Integridade: Capacidade em que o software possui de impedir acessos ou
alteraes indevidas.
o No repdio: Capacidade do software em reconhecer a veracidade de certas
aes e eventos para no repudi-los em outro momento.
o Prestao de contas: Capacidade que software possui de atribuir um ao 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 Reutilizao: 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 tambm de identificar as devidas correes.
o Modificabilidade: Capacidade do software possui de no apresentar falhas aps
as modificaes, seja por melhoria ou por correo de erros.
o Testabilidade: Capacidade do software de se enquadrar aos critrios 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 substitudo por outro
em menor impacto possvel.

2.1.2. O DILEMA DA QUALIDADE DE SOFTWARE

Sobre qualidade nas organizaes, 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 pssima qualidade, perdemos porque
ningum ir querer compr-los. Se, por outro lado, gastamos um tempo infinito, um
esforo extremamente grande e grandes somas de dinheiro para construir um
software absolutamente perfeito, ento isso levar muito tempo para ser completado,
e o custo de produo ser to alto que iremos falncia. Ou perdemos a
oportunidade de mercado ou ento simplesmente esgotamos todos os nossos
recursos. Dessa maneira, os profissionais dessa rea tentam encontrar aquele meio-
termo mgico onde o produto e suficientemente bom para no ser rejeitado logo de
cara, como por exemplo, durante uma avaliao, mas tambm no 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 decises, Pressman (2011), aconselha que tomar
o tempo necessrio para fazer o certo na primeira vez nunca uma deciso errada.
 19

2.1.3. CUSTO DA QUALIDADE

Ainda sobre o dilema, comum nos depararmos com a seguinte objeo apresentada
por muitas empresas: Sabemos que a qualidade importante, mas ela nos custa tempo e
dinheiro em demasia para obter o nvel de qualidade de software que realmente desejamos..

Para Pressman (2011), no h dvida nenhuma que a qualidade tem um preo, mas a
falta dela tambm tem um preo no apenas para os usurios finais, que tero que conviver
com um software com erros, mas tambm para a organizao de software que o criou e, alm
de tudo, ter de fazer manuteno. E isso nos leva a seguinte questo: Qual custo deveramos
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, execuo ou

falta da mesma. So classificados em:

Custo de preveno: Incluem o custo de atividades de gerenciamento necessrias para

planejar e coordenar todas as atividades de controle e garantia da qualidade. O custo de
atividades tcnicas 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 avaliao: Incluem atividades para a compreenso aprofundada de condio do

produto a primeira vez atravs de cada processo. Entre os exemplos de custos de avaliao
temos:

Custo para realizao de revises tcnicas para produtos resultantes de engenharia de

software.
Custo para coleta de dados e avaliao de mtricas.
Custo de testes e depurao.

Custo de falhas: So 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 necessrio para realizar trabalhos (reparos) para corrigir um erro.

Custo que ocorre quando trabalhos geram, inadvertidamente, efeitos colaterais que
devem ser reduzidos.
Custos associados reunio de mtricas de qualidade que permitem a uma organizao
avaliar os modos de falha.

Por outro lado, os custos de falhas externas esto associados a defeitos encontrados
aps o produto ter sido entregue ao cliente. Custos esse provenientes de reclamaes,
devoluo/substituio de produtos, suporte por telefone/mal e at custos por mo de obra
associada garantia do produto.

Quanto ao valor aproximado dos custos, isso fica relativo medida um erro/defeito vai
progredindo da etapa de preveno deteco de falhas internas e externas. Atravs dos dados
coletados por Boehm e Basili (Boe01b), a Cigital Inc (Cig07) exemplifica esse cenrio atravs
da ilustrao abaixo:

Figura 1 - Custo relativo correo de erros e defeitos

Fonte: Pressman (2011, p.367)

 21

Como vemos na Figura 2.1, o custo mdio da indstria de software para corrigir um
defeito durante a gerao de cdigo aproximadamente US$ 977 por erro. O custo mdio
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 usurio final (falha externa), chegando a um valor de aproximadamente de
US$ 14.102 por erro.

Essa anlise levou Pressman (2011) concluso de que mesmo a organizao de

software tendo custos equivalentes metade da mdia do setor, a economia de custos
associados a atividades iniciais de controle com garantia de qualidade considervel.

2.1.4. COMO ALCANAR A QUALIDADE?

A qualidade de software no aparece simplesmente do nada. Ela o resultado de um

bom gerenciamento de projeto e uma prtica consistente de engenharia de software, afirma
Pressman (2011). Esse gerenciamento e prtica so aplicados no contexto de quatro grandes
atividades que ajudam uma equipe a atingir o alto padro de qualidade em software. So elas:

Mtodos 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 caractersticas que levem a um
software com as dimenses e fatores de qualidade.

Tcnicas de Gerenciamento de Software: A qualidade de software afetada positivamente

quando um gerente de projeto usar estimativas para verificar que as datas de entrega so
plausveis. Quando as dependncias de cronograma forem entendidas e a equipe resistir
tentao de usar atalhos. Quando o planejamento de riscos for conduzido de moda que os
problemas no gerem caos.

Controle de Qualidade: Aplica-se uma srie de etapas de teste para descobrir erros na lgica
de processamento, na manipulao de dados e na comunicao de interface. Uma combinao
de medies e realimentao (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 funes de auditoria e de relatrios

que possibilita uma avaliao de efetividade e da completude das aes de controle de
qualidade. Tem como objetivo fornecer ao pessoal tcnico administrativo os dados
necessrios para ser informados sobre a qualidade do produto, ganhando, portanto,
entendimento e confiana de que as aes para atingir a qualidade desejada do produto esto
funcionando.

2.2. TESTE DE SOFTWARE

Teste de Software uma boa prtica realizada em um desenvolvimento de software, onde

seu principal objetivo, segundo Bastos (2012), reduzir os riscos que as aplicaes podem
trazer para os negcios. E para Pressman (2011), um bom teste aquele que possui uma srie
de caractersticas que o permite encontrar o maior nmero de erros possveis com o mnimo
de esforo.

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 verificao e validao, que por sinal, so
termos com sentidos completamente diferentes.

Verificao: testes que permitem verificar se o software est sendo construdo corretamente.
Validao: teste que permitem validar se o software est fazendo o que foi definido nos
requisitos.

Em outras palavras:

Verificao: A forma que construmos o software est correta?

Validao: O software que construirmos, est correto?

Em aplicaes 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 lgicos do software e as colaboraes entre componentes so testados, exercitando
conjuntos especficos de condies e/ou ciclos.

Teste de Caixa Preta: Faz referncia a testes realizados na interface do software. Examina
alguns aspectos fundamentais de um sistema, com pouca preocupao em relao estrutura
lgica interna do software.

2.2.1. PROCESSO DE TESTE

De acordo com Bastos (2012), pressupe que o processo de teste esteja em paralelo ao
processo de desenvolvimento. Para isso, ele menciona a utilizao 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 comeam do mesmo ponto. Na
etapa de especificao, enquanto a equipe de desenvolvimento encarregada de capturar e
documentar os requisitos com o propsito de desenvolver o sistema, a equipe de teste realizar
o mesmo procedimento, porm com a finalidade de testar o sistema. Ao entrar na etapa de
execuo, testes de verificao e validao so respectivamente aplicados em conjunto
construo e instalao/manuteno do sistema.
 24

importante ressaltar, que o conceito V focado nas etapas de especificao e

execuo 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 didtica e de fcil visualizao.

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 descrio e funo de cada etapa:

Procedimentos Iniciais: Etapa onde realizado um estudo aprofundado dos requisitos de

negcios do sistema a ser desenvolvido. Garantindo que o mesmo esteja completo de sem
redundncias. Aps isso, devem ser definidas as principais atividades de testes que sero
executadas.

Planejamento: Etapa que consiste na elaborao de uma estratgia de teste e um plano de

teste, visando minimizar os principais riscos ao negcio e fornecer caminhos para as prximas
etapas.
 37

3. MTODO

Nesse captulo ser apresentada a proposta de automao de testes atravs do conjunto

de ferramentas Selenium, que so elas: Selenium IDE, Selenium RC, Selenium WebDriver e
Selenium Grid

3.1. SELENIUM

Em 2004, o testador Jason Higging estava testando uma aplicao 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 no suportavam mais ficar dependentes da ferramenta Quick Test, da
empresa Mercury, que por sinal era paga e bem cara. Na qumica, o antdoto do Mercrio o
Selnio. 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 verso do
Selenium em 2008.
 38

Hoje, o Selenium3 uma sute 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 automao dos testes funcionais de forma
prtica e eficiente.

Figura 7 - Ferramentas do Selenium.

Fonte: SeleniumHQ Browser Automation

3.1.1. POR QUE USAR SELENIUM?

Embora j existam diversas ferramentas de automao de teste, o Selenium se destaca

por ser um conjunto de ferramentas, permitindo ao usurio testar as aplicaes web nas mais
diversas formas de automao, como por exemplo:

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

Realizar Testes de Carga/Estresse atravs da execuo 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 negcios.

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. Disponvel em: <
http://www.seleniumhq.org/projects/>. Acesso em: 07/11/2015
 39

3.1.2. PLUGINS

Os plug-ins podem ser novas extenses (.xpi) do browser Firefox ou arquivos

javascript (.js), que tem o caminho apontado no prprio IDE do Selenium.

Segue a lista dos principais plug-ins:

Selenium IDE Button: Permite alternar a exibio da IDE do Selenium. Seja em um pop-up
ou no prprio frame do browser.

Flow Control: Adiciona comandos de repetio ao script de teste.

ScreenShot on Fail: Registra um print screen da tela no momento em que ocorreu um erro na
execuo 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 relatrio com um visual mais bonito e
legvel.
 40

3.2. SELENIUM IDE

Uma extenso para o browser Firefox, onde o usurio 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 aplicao web, como por exemplo: acesso a uma
url, clique no boto, digitao no campo, verificao de texto na pgina e entre outros.

Figura 8 - IDE do Selenium.

Fonte: Autoria prpria

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 compe a sute de teste em uso.
 41

3) Editor de Script
Espao 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 execuo do caso de teste selecionado.

3.2.1. CRIAO 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
formulrio e clicar no boto Enviar.

Figura 9 - Script para enviar mensagem.

Fonte: Autoria prpria

Para salvar o teste, basta ir opo Arquivo > Salvar Teste. O arquivo deve ser salvo
no formato .html. Ex: EnviarMensagem.html.
 42

3.2.2. EXECUO DOS SCRIPTS DE TESTE

Ao clicar no boto 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 padro, o Selenium IDE4 salva o script no formato HyperText Markup Language
(.html). Porm, possvel export-lo em outro formato para que possa ser integrado a projetos
de teste (como veremos no captulo 3.3).

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

Figura 10 - Exportao do caso de teste no formato Java.

Fonte: Autoria prpria

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

4.3. COMPARATIVO DOS RESULTADOS DE TESTE

Para facilitar a visualizao, segue abaixo os comparativos dos resultados entre os testes
manuais e automatizados. A coluna Diferena mostra a eficincia em porcentagem dos testes
automatizados para com os testes manuais. Os nmeros chegam a impressionar, veja:

Selenium Test v1.0

Tempo de Execuo
Caso de Teste Manual (s) Automatizado (s) Diferena (%)
Login Invlido 22 6 266,67
Efetuar Login 18 10 80,00
Validar Campos Obrigatrios Cliente 59 24 145,83
Cadastrar Cliente 57 21 171,43
Validar Campos Obrigatrios Usurios 21 13 61,54
Cadastrar Usurio 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 execuo (verso 1).
Fonte: Autoria prpria

Grfico 1 - Comparativo dos testes por tempo de execuo (verso 1).

Fonte: Autoria prpria
 64

Bugs Encontrados15
Caso de Teste Manual (s) Automatizado (s) Diferena (%)
Login Invlido 0 0 0
Efetuar Login 0 0 0
Validar Campos Obrigatrios Cliente 0 0 0
Cadastrar Cliente 0 0 0
Validar Campos Obrigatrios Usurios 0 0 0
Cadastrar Usurio 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 (verso 1).

Fonte: Autoria prpria

Grfico 2 - Comparativo dos testes por bugs encontrados (verso 1).

Fonte: Autoria prpria

15
J que o Selenium Test v1.0 foi testada diversas vezes durante o desenvolvimento, no houve indcios de bugs
neste relatrio.
 65

Selenium Test v2.0

Tempo de Execuo
Caso de Teste Manual (s) Automatizado (s) Diferena (%)
Login Invlido 20 6 233,33
Efetuar Login 17 7 142,86
Validar Campos Obrigatrios Cliente 68 25 172,00
Cadastrar Cliente 65 25 160,00
Validar Campos Obrigatrios Usurios 18 15 20,00
Cadastrar Usurio 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 execuo (verso 2).

Fonte: Autoria prpria

Grfico 3 - Comparativo dos testes por tempo de execuo (verso 2).

Fonte: Autoria prpria
 66

Bugs Encontrados
Caso de Teste Manual (s) Automatizado (s) Diferena (%)
Login Invlido 0 1 100
Efetuar Login 0 1 100
Validar Campos Obrigatrios Cliente 0 1 100
Cadastrar Cliente 1 2 50
Validar Campos Obrigatrios Usurios 0 0 0
Cadastrar Usurio 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 (verso 2).

Fonte: Autoria prpria

Grfico 4 - Comparativo dos testes por bugs encontrados (verso 2).

Fonte: Autoria prpria

Notou a enorme diferena com relao s verses dos relatrios? Fica notrio que o
testador (Felipe Lima) tentou demonstrar eficincia no tempo de execuo dos testes, no
dando muita ateno aos pequenos detalhes. Isso explica o porqu encontrou apenas um bug,
quando na verdade, havia mais sete escondidos na aplicao.

J o rob, conseguiu detectar todos os bugs em um tempo bem menor, provando em

nmeros, que possvel sim manter um equilbrio satisfatrio entre o Tempo e a Qualidade.