Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................... 13
1.1. OBJETIVOS ............................................................................................................... 13
1.2. ORGANIZAÇÃO DO DOCUMENTO ..................................................................... 14
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
5. CONCLUSÃO ................................................................................................................. 67
REFERÊNCIAS ..................................................................................................................... 68
GLOSSÁRIO .......................................................................................................................... 69
ANEXOS ................................................................................................................................. 71
APÊNDICES ........................................................................................................................... 79
13
1. INTRODUÇÃO
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.
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.
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.
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 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
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
Eficiência do Desempenho
Compatibilidade
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
Confiabilidade
Segurança
Manutenibilidade
Portabilidade
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.
“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
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?
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
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:
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.
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
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:
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.
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”.
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
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.
O ciclo é composto por seis etapas, sendo quatro delas sequenciais e duas paralelas.
Abaixo, segue a descrição e função de cada etapa:
3. MÉTODO
3.1. SELENIUM
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.
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
Selenium IDE Button: Permite alternar a exibição da IDE do Selenium. Seja em um pop-up
ou no próprio frame do browser.
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
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.
1) Barra de Ferramentas
Possui as funcionalidades que gerenciam os testes como gravar, executar, pausar, etc.
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.
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.
Para salvar o teste, basta ir à opção Arquivo > Salvar Teste. O arquivo deve ser salvo
no formato .html. Ex: EnviarMensagem.html.
42
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).
4
SELENIUM HQ BROWSER AUTOMATION. Selenium IDE Plugins. Disponível em: <
http://www.seleniumhq.org/projects/ide/>. Acesso em: 08/11/2015
63
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:
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
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
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
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
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
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.