automação de testes de regressão - selenium
TRANSCRIPT
UNIVERSIDADE DO SUL DE SANTA CATARINA
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM
Palhoça
2013
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Flavio Ceci, M.Eng.
Palhoça
2013
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina.
Palhoça, 29 de junho de 2013.
______________________________________________________ Professor e orientador Flavio Ceci, M.Eng.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Prof. Jean Carlo Rossa Hauck, Dr. Universidade do Sul de Santa Catarina
______________________________________________________
Alessandra Mohr. Convidada
Dedico esse trabalho à minha família que
sempre me apoiou. Ao meu namorado Rafael
que com seu amor me manteve motivada nessa
etapa da minha vida. Ao nosso orientador
Flávio que foi prestativo e nos ajudou em
todos os momentos.
Maiele Perosa Ranzan
Dedico, com muito carinho, essa monografia à
minha família e, principalmente, à minha
namorada Adriana e à minha mãe Carla
Beatriz que não mediram esforços para a
realização desse trabalho e pela compreensão
que tiveram comigo nos momentos de
dificuldade. E a todos meus amigos que me
apoiaram e me acompanharam na minha vida
acadêmica.
Rodrigo Susin de Oliveira
AGRADECIMENTOS
Maiele Perosa Ranzan agradece
Essa monografia foi elaborada, acima de tudo, com muita dedicação e força de
vontade minha e do meu amigo Rodrigo; porém, muitas pessoas participaram direta ou
indiretamente dela. Nesse espaço, quero agradecer a todos que ajudaram a concluí-la.
Primeiramente, agradeço aos meus pais que sempre me apoiaram em toda a minha
caminhada e que nesse momento foram fundamentais como ponto de equilíbrio e força.
Ao meu namorado Rafael que, com toda sua paciência, compreensão e amor,
tornou-se essencial para que eu conseguisse seguir em frente, perdoando muitos momentos
em que tive que ficar ausente em função desse projeto.
Meus agradecimentos sinceros ao amigo e parceiro dessa jornada, Rodrigo, que
me acompanhou em diversos trabalhos acadêmicos e na presente monografia. Acredito que
sem sua ajuda esse ciclo teria sido muito mais difícil.
Ao nosso Orientador Prof. Flávio Ceci pelo incentivo, simpatia e presteza no
auxílio às atividades e discussões sobre o andamento desse estudo de caso. Com certeza, seu
apoio foi imprescindível e jamais esqueceremos.
A Profª Maria Inês pela tarefa de multiplicar seus conhecimentos ministrando a
disciplina que nos conduziu a essa obra.
Aos colegas que nos forneceram o protótipo para que utilizássemos como base
para a construção do estudo de caso e aos testadores que disponibilizaram seu tempo para
realização dos testes manuais do protótipo.
E, por fim, o meu muito obrigada aos membros da banca por terem aceito nosso
convite, agregando seus conhecimentos.
Rodrigo Susin de Oliveira agradece
A toda minha família pelo apoio dado nessa empreitada, principalmente, a meu
pai, minha mãe, minha irmã e minha namorada que sempre me incentivaram e estiveram ao
meu lado nos momentos difíceis.
Aos meus colegas, José Fernando e Giovani Brunel Paes, que permitiram a
divulgação do protótipo Projector dessa monografia.
Aos colegas, Rodrigo Veleda e Luiz Santana, por disponibilizar a modelagem do
protótipo Projector.
Agradeço aos Testadores que foram prestativos na execução do estudo de caso.
Novamente, agradeço à minha mãe, Carla Beatriz Susin de Oliveira, por fazer a
correção desse trabalho.
À Banda Infinito Restrito que me liberou dos ensaios para trabalhar na
monografia e que, também, me compreendeu nos dias de estresse.
À minha colega e amiga Maiele Perosa Ranzan por ser tão paciente no
desenvolvimento do trabalho e por estar sempre motivada ao longo dessa jornada.
Ao meu amigo e Profº Orientador Flávio Ceci, pelos ensinamentos, estímulo,
apoio e dedicação nessa trajetória.
Enfim, agradeço a todos que direta ou indiretamente participaram do
desenvolvimento da presente monografia.
“Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que
aponta uma nova direção.” (Steve Jobs).
RESUMO
A área de testes está ocupando um espaço cada vez maior nas organizações de
desenvolvimento de software, pois se observa que com a mesma é possível aumentar a
qualidade de uma aplicação, gerando maior satisfação para seu cliente final. Existem diversas
técnicas e tipos que classificam os testes de software, dentre os quais o de regressão. Este, por
sua vez, costumeiramente é manual; sendo assim, suscetível a falhas em sua execução. Como
forma de minimizar esse problema, surgiu o conceito de automação de teste, onde existe um
ferramental vasto para sua concepção. Nesse estudo de caso, adotou-se o framework Selenium
que automatizou uma rotina de testes regressivos em um protótipo web, desenvolvido durante
a graduação, por acadêmicos do curso de Sistemas de Informação da Unisul. Os mesmos
testes foram executados manualmente com o apoio de dois participantes que responderam a
um questionário. Os resultados obtidos depois de feita a comparação entre a prática manual e
a automatizada foram satisfatórios, uma vez que se notou um ganho, principalmente, nas
questões de tempo e qualidade do teste aplicando a técnica automática.
Palavras-chave: Teste de software, Automação, Framework Selenium.
ABSTRACT, RÉSUMÉ OU RESUMEN
The test area is occupying a growing space on the software development organization,
because we note that with that it is possible to increase the quality of an application,
generating greater satisfaction to your final client. There are many techniques and kinds of
regression. This, on the other hand, customarily is manual; thus, where there is a vast tooling
to its conception. In this case studies, was adopted the “framework Selenium” which
automated a regression tests routine in a prototype web, developed during graduation, by the
course of Information System Unisul academics. The same tests were manually executed with
the help of two participants that answered a survey. The obtained results after the comparison
was made between the manual practice and the automated were satisfactory results, since a
gain was noted, manly, in things like time and test quality applied the automated technique.
Keywords: Software test, Automation, Framework Selenium.
LISTA DE ILUSTRAÇÕES
Figura 1 – Atividades do modelo cascata ................................................................................. 26 Figura 2 - Custo de modificação .............................................................................................. 26 Figura 3 - Modelo Incremental ................................................................................................. 28 Figura 4 - Atividades da Prototipação ...................................................................................... 29 Figura 5 - Iterações do modelo espiral ..................................................................................... 30 Figura 6 - Custo de mudanças nas metodologias ágeis ............................................................ 32 Figura 7 - Funcionamento do Scrum ........................................................................................ 35 Figura 8 - Custo de correção dos problemas ............................................................................ 38 Figura 9 - Visão do teste caixa-preta ........................................................................................ 43 Figura 10 - Visão do teste caixa-branca ................................................................................... 46 Figura 11 - Etapas metodológicas ............................................................................................ 57 Figura 12 - Esboço da Solução ................................................................................................. 59 Figura 13 - Etapas do questionário ........................................................................................... 61 Figura 14 - Visão geral do ICONIX ......................................................................................... 66 Figura 15 - Diagrama de Atores ............................................................................................... 68 Figura 16 - Requisitos Funcionais ............................................................................................ 70 Figura 17 - Requisitos não funcionais ...................................................................................... 72 Figura 18 - Tela de cadastro dos projetos ................................................................................. 73 Figura 19 - Tela de cadastro das atividades .............................................................................. 74 Figura 20 - Casos de Uso .......................................................................................................... 75 Figura 21 - Cadastrar Projeto ................................................................................................... 76 Figura 22 - Cadastrar Atividade ............................................................................................... 77 Figura 23 - Diagrama de Domínio ............................................................................................ 78 Figura 24 - Diagrama de Robustez ........................................................................................... 79 Figura 25 - Diagrama de Sequência - Login............................................................................. 80 Figura 26 - Cadastrar Perfil ...................................................................................................... 81 Figura 27 - Cadastrar Usuário .................................................................................................. 82 Figura 28 - Cadastrar clientes ................................................................................................... 83 Figura 29 - Emissão de relatórios ............................................................................................. 84 Figura 30 - Cadastro de marco ................................................................................................. 85 Figura 31 - Cadastrar projeto .................................................................................................... 86 Figura 32 - Cadastro de cronograma ........................................................................................ 87 Figura 33 - Cadastrar atividade ................................................................................................ 88 Figura 34 - Cadastro de status .................................................................................................. 89 Figura 35 - Registro de hora da atividade ................................................................................ 90 Figura 36 - Consultar andamento do projeto ............................................................................ 91 Figura 37 - Diagrama de Classes .............................................................................................. 92 Figura 38 - Arquitetura do Projector ........................................................................................ 94 Figura 39 - Cadastrar projeto no Projector ............................................................................... 97 Figura 40 - Listagem de projetos no Projector ......................................................................... 98 Figura 41 - Cadastro de cronograma no Projector .................................................................... 98 Figura 42 - Cadastro de atividade no Projector ........................................................................ 99 Figura 43 - Listagem das atividades no Projector .................................................................... 99 Figura 44 - Fluxograma da elaboração do teste ...................................................................... 101 Figura 45 - Funcionamento Selenium RC .............................................................................. 109
Figura 46 - Exemplo WebDriver em Java .............................................................................. 111 Figura 47 - Pacote de entidades .............................................................................................. 113 Figura 48 - Pacote core ........................................................................................................... 114 Figura 49 - Arquivos de configuração .................................................................................... 115 Figura 50 - Pacote testcase ..................................................................................................... 116 Figura 51 - Pacote util ............................................................................................................ 117 Figura 52 - Cadastro de Atividade .......................................................................................... 119 Figura 53 - Cadastro de atividade campos obrigatórios ......................................................... 120 Figura 54 - Grid de atividades ................................................................................................ 120 Figura 55 - Início da execução ............................................................................................... 123 Figura 56 - Acesso ao sistema ................................................................................................ 124 Figura 57 - Execução incorreta ............................................................................................... 125 Figura 58 - Detecção do bug pelo Testador X ........................................................................ 126 Figura 59 - Testador X finaliza o teste ................................................................................... 127 Figura 60 - Testador Y conclui o teste manual ....................................................................... 128 Figura 61 - Início da execução automatizada ......................................................................... 129 Figura 62 – Abertura automática no navegador ..................................................................... 130 Figura 63 - Componente calendário ....................................................................................... 131 Figura 64 - Automação encontra bug ..................................................................................... 132 Figura 65 - Teste automatizado de salvar cronograma ........................................................... 132 Figura 66 - Fim do teste automatizado ................................................................................... 133 Figura 67 - Log da automação ................................................................................................ 134 Figura 68 - Log da automação apresentando o bug ................................................................ 135
LISTA DE QUADROS
Quadro 1 - Ferramentas comerciais .......................................................................................... 50 Quadro 2 - Ferramentas acadêmicas ......................................................................................... 51 Quadro 3 - Comparações entre manual e automatizado ......................................................... 136 Quadro 4 - Prós e contras da automação ................................................................................ 138 Quadro 5 - Prós e contras do teste manual ............................................................................. 138
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 16
1.1 PROBLEMÁTICA .......................................................................................................................17 1.2 OBJETIVOS .................................................................................................................................19 1.2.1 Objetivo geral ...........................................................................................................................19 1.2.2 Objetivos específicos ................................................................................................................19 1.3 JUSTIFICATIVA .........................................................................................................................19 1.4 ESTRUTURA DA MONOGRAFIA ............................................................................................21
2 REVISÃO BIBLIOGRÁFICA ..................................................................................................... 22
2.1 A CRISE DE SOFTWARE ............................................................................................................22 2.2 ENGENHARIA DE SOFTWARE ...............................................................................................23 2.2.1 Metodologias de Desenvolvimento ..........................................................................................24 2.2.1.1 Metodologias Tradicionais ..................................................................................................... 25 2.2.1.1.1 Modelo clássico ...................................................................................................................25 2.2.1.1.2 Modelo Incremental .............................................................................................................27 2.2.1.1.3 Prototipação ........................................................................................................................28 2.2.1.1.4 Modelo espiral .....................................................................................................................30 2.2.1.2 Metodologias Ágeis................................................................................................................ 31 2.2.1.2.1 Extreme Programming (XP) ................................................................................................32 2.2.1.2.2 Scrum ...................................................................................................................................34 2.3 TESTES DE SOFTWARE ...........................................................................................................36 2.3.1 Técnicas para Teste de Software ............................................................................................39 2.3.1.1 Teste de unidade ..................................................................................................................... 40 2.3.1.2 Teste de integração ................................................................................................................. 40 2.3.1.3 Teste de sistema ..................................................................................................................... 41 2.3.1.4 Teste de aceitação................................................................................................................... 41 2.3.1.5 Tipos de teste .......................................................................................................................... 42 2.3.1.5.1 Testes de caixa-preta ...........................................................................................................42 2.3.1.5.1.1 Testes de requisitos .......................................................................................................... 43 2.3.1.5.1.2 Testes de regressão ........................................................................................................... 44 2.3.1.5.1.3 Testes de tratamento de erros ........................................................................................... 45 2.3.1.5.1.4 Testes de interconexão ..................................................................................................... 45 2.3.1.5.2 Teste de caixa branca ..........................................................................................................45 2.3.1.5.2.1 Testes de estresse ............................................................................................................. 46 2.3.1.5.2.2 Testes de performance ...................................................................................................... 47 2.3.1.5.2.3 Testes de recuperação ....................................................................................................... 47 2.3.1.5.2.4 Testes de segurança .......................................................................................................... 47 2.3.1.5.3 Testes não-funcionais...........................................................................................................48 2.3.1.5.3.1 Testes de usabilidade ........................................................................................................ 48 2.3.1.5.3.2 Teste de instalação ........................................................................................................... 48 2.3.2 Automatização de Testes de Software ....................................................................................49 2.3.2.1 Ferramentas para automação de teste ..................................................................................... 50 2.3.2.2 Tendências para as ferramentas de automação ....................................................................... 52 2.3.2.3 Automação de Teste x Teste de Regressão ............................................................................ 53
3 MÉTODO....................................................................................................................................... 55
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................................55 3.2 ETAPAS METODOLÓGICAS ....................................................................................................56 3.3 DESENHO DA SOLUÇÃO .........................................................................................................58 3.4 CARACTERÍSTICAS DO ESTUDO DE CASO .........................................................................59
3.4.1 Cenário proposto ......................................................................................................................60 3.4.2 Objetivos ...................................................................................................................................60 3.4.3 Ferramentas utilizadas ............................................................................................................61 3.4.4 Perfil dos profissionais envolvidos ..........................................................................................62 3.4.5 Avaliação dos resultados .........................................................................................................62 3.5 DELIMITAÇÕES .........................................................................................................................62
4 PROJETO DE SOLUÇÃO DO PROTÓTIPO ........................................................................... 64
4.1 DEFINIÇÃO DE TÉCNICA E METODOLOGIA ......................................................................64 4.1.1 Unified modeling language (UML) .........................................................................................64 4.1.2 Iconix .........................................................................................................................................65 4.1.3 Orientação a Objetos (OO) .....................................................................................................66 4.2 DESCRIÇÃO DO PROTÓTIPO UTILIZADO NO ESTUDO DE CASO ..................................67 4.2.1 Atores ........................................................................................................................................68 4.2.2 Requisitos ..................................................................................................................................69 4.2.2.1 Requisitos Funcionais ............................................................................................................ 69 4.2.2.2 Requisitos Não Funcionais ..................................................................................................... 71 4.2.3 Protótipos de Interface ............................................................................................................72 4.2.4 Casos de Uso .............................................................................................................................74 4.2.5 Modelo de Domínio ..................................................................................................................78 4.2.6 Diagramas de Robustez ...........................................................................................................78 4.2.7 Diagramas de Sequência..........................................................................................................79 4.2.8 Diagrama de Classe..................................................................................................................91 4.3 RESUMO DO CAPÍTULO ..........................................................................................................92
5 AUTOMATIZAÇÃO DE TESTES DE SOFTWARE ............................................................... 93
5.1 SISTEMA DESENVOLVIDO PARA O ESTUDO DE CASO ...................................................93 5.1.1 Tecnologias utilizadas ..............................................................................................................93 5.1.1.1 Enterprise Architect................................................................................................................ 95 5.1.1.2 Eclipse .................................................................................................................................... 95 5.1.1.3 Hibernate ................................................................................................................................ 95 5.1.1.4 Java ......................................................................................................................................... 96 5.1.1.5 Java Server Faces ................................................................................................................... 96 5.1.1.6 MySQL ................................................................................................................................... 96 5.1.1.7 Apache Tomcat ...................................................................................................................... 97 5.1.2 Descrição do sistema ................................................................................................................97 5.2 CASOS DE TESTE ....................................................................................................................100 5.2.1 Método ....................................................................................................................................100 5.2.2 Ferramentas utilizadas ..........................................................................................................102 5.2.3 Roteiro de teste .......................................................................................................................102 5.2.3.1 Teste Salvar Projeto ............................................................................................................. 102 5.2.3.2 Teste salvar projeto com cliente ........................................................................................... 103 5.2.3.3 Teste editar projeto ............................................................................................................... 103 5.2.3.4 Teste excluir projeto ............................................................................................................. 104 5.2.3.5 Teste cadastrar atividade ...................................................................................................... 105 5.2.3.6 Teste cadastrar atividade com cronograma .......................................................................... 105 5.2.3.7 Teste cadastrar atividade completo ...................................................................................... 106 5.2.3.8 Teste de efetuar login com usuário válido ............................................................................ 107 5.2.3.9 Teste de efetuar login com usuário inválido ........................................................................ 107 5.2.3.10 Teste de salvar cronograma ................................................................................................ 108 5.3 AUTOMATIZAÇÃO DE TESTES ............................................................................................108 5.3.1 Ferramentas utilizadas ..........................................................................................................112 5.3.2 Automação dos casos de teste ................................................................................................112 5.4 ESTUDO DE CASO ...................................................................................................................118 5.4.1 Bugs inseridos no sistema ......................................................................................................119 5.4.2 Seleção dos atores ...................................................................................................................121
5.4.3 Execução manual dos casos de teste .....................................................................................121 5.4.4 Execução automatizada dos casos de teste ...........................................................................128 5.4.5 Resultados obtidos .................................................................................................................135 5.5 AVALIAÇÃO DOS RESULTADOS .........................................................................................137
6 CONCLUSÕES E TRABALHOS FUTUROS.......................................................................... 140
6.1 CONCLUSÕES ..........................................................................................................................140 6.2 TRABALHOS FUTUROS .........................................................................................................141
REFERÊNCIAS ................................................................................................................................ 142
APÊNDICES ...................................................................................................................................... 146
APÊNDICE A – QUESTIONÁRIO ................................................................................................. 147
ANEXOS ............................................................................................................................................ 149
ANEXO A – QUESTIONÁRIO DO TESTADOR X ..................................................................... 150
ANEXO B – QUESTIONÁRIO DO TESTADOR Y ..................................................................... 153
16
1 INTRODUÇÃO
No desenvolvimento de software ocorrem situações em que o sistema é entregue
ao cliente com qualidade baixa, ou seja, mesmo respeitando e seguindo corretamente as etapas
de desenvolvimento de software, análise, construção, testes, correções de defeitos e reteste, o
mesmo ainda pode conter erros.
Um problema bastante comum na rotina das organizações são os curtos prazos nos
projetos. Deste modo o sistema acaba sendo entregue às pressas e com poucos testes, não
garantindo sua qualidade e eficiência.
De acordo com o autor de diversos livros na área de qualidade de software,
Molinari (2003), os defeitos encontrados na fase de implantação podem ser até cem vezes
mais caros do que se tivessem sido descobertos antes do software ser entregue ao cliente final.
Para Inthurn (2001, p. 21), desenvolver softwares com qualidade significa:
“alinhamento total entre as necessidades/expectativas dos usuários e especificações geradas.
Alinhamento total entre as especificações aprovadas e o produto construído, e o produto final
com a menor quantidade de erros possíveis.”.
Segundo Hetzel (1987), através do teste consegue-se adquirir confiança no fato de
que um sistema pode ser usado com uma margem de risco aceitável, descobrir erros e
deficiências de um sistema, determinar os recursos do sistema e fornecer informações sobre a
qualidade de um software.
Segundo Casimiro (2011), investindo em teste de software pode-se reduzir em
70% o índice de retrabalho de correções de falhas de produção, reduzir em 50% do tempo de
homologação de uma nova versão, aumentar em 90% o índice de falhas detectadas antes da
produção, diminuir em 95% a terminação anormal de um processo, e aumentar a abrangência
dos testes.
O investimento em teste é de suma importância para garantir uma boa qualidade
no software, porém os testes manuais nem sempre atendem com rapidez e eficácia as
expectativas. Contudo, automatizar alguns processos e etapas do teste pode agilizar a
execução do mesmo, tendo em vista que o teste manual estará sempre exposto a falhas pelo
fato de serem executados por seres humanos.
Para Bartié (2002), a automação de testes requer um esforço inicial, porém
fornece eficiência, rapidez e confiabilidade que pode não ser atingida com procedimentos
manuais.
17
No processo de desenvolvimento de software a automatização funciona como
recurso para a redução no esforço em atividades de testes manuais, que, por muitas vezes, são
repetitivas. Por fim, permite a execução automática de rotinas de teste com o objetivo de
aumentar a qualidade do produto e minimizar falhas humanas.
As seções seguintes explanam a respeito da problemática levantada para o estudo
de caso, os objetivos que se pretende alcançar, uma justificativa para a escolha do tema e a
estrutura da presente monografia.
1.1 PROBLEMÁTICA
Na década de 60, os softwares eram desenvolvidos de forma primitiva não
havendo organização ou planejamento. No processo de construção de uma aplicação havia
muitas dificuldades, pois a demanda e a complexidade dos sistemas cresciam. De acordo com
o engenheiro de software norte-americano Pressman (2004), os problemas que ocorriam
tinham relação com a organização das equipes, uma vez que estas não possuíam total
conhecimento técnico para desenvolver, prestar suporte e dar manutenção em uma solução.
Faltava uma correta análise de requisitos somada a poucos investimentos na questão da
qualidade do sistema.
Apesar das práticas errôneas serem reconhecidas e apontadas, muitas delas ainda
perduram nos tempos atuais. Segundo Koscianski e Soares (2007, p. 172), “sem uma
definição precisa daquilo que se pretende construir, perde-se tempo, mais erros são cometidos
e a qualidade do produto final é incerta”.
Como forma de sanar os problemas e buscar uma solução para a crise, os
princípios da Engenharia de Software foram criados e difundidos. De acordo com Pressman
(2004), todas as deficiências na elaboração e construção de um sistema começaram a ser
sanadas com o surgimento do conceito de Engenharia de Software que trouxe consigo a
oportunidade de novos rumos para as pesquisas em tecnologia.
Segundo o especialista na área e autor de diversos livros, Sérgio Luiz Tonsig
(2008), no ano de 1968, foi realizada uma conferência internacional na Alemanha cujo
objetivo era encontrar soluções para os problemas que assolavam o desenvolvimento de
software; foi a partir desta que o termo “Engenharia de Software” ficou conhecido.
18
Com a criação dos métodos, o desenvolvimento começou a ser executado e
construído em etapas. O primeiro modelo criado foi o Cascata que, segundo Pressman (2001),
é um modelo pesado e composto de atividades sequenciais para levantamento de requisitos,
análise, projeto, implementação, teste, implantação e manutenção.
Pode-se perceber que em grande parte dos métodos existe uma etapa de testes. O
escritor Pressman (2002) destacou que a prática de teste é um fator de extrema importância na
qualidade de uma aplicação, uma vez que representa a revisão das especificações.
Devido à importância dos testes, nas etapas de desenvolvimento, criou-se um
ciclo para o mesmo que é composto por procedimentos iniciais, planejamento, preparação,
especificação, execução e entrega.
No ciclo de execução do teste, o procedimento a ser seguido, geralmente, é
manual. O diretor da Associação Latino-Americana de Teste de Software (ALATS),
Anderson Bastos et al. , destacou em seu livro Base de conhecimento em teste de software
(2007), que os testes devem ser executados por regressão ou por partes toda vez que surgirem
alterações nas aplicações ou novas versões e devem possuir ambiente preparado para tal
rotina.
O teste de regressão tem a necessidade de ser repetitivo e executado a cada
correção de erro ou em caso de novas implementações no sistema. De acordo com Pressman
(2006), o software é modificado cada vez que um novo módulo ou uma nova funcionalidade é
adicionado. Essa modificação pode gerar problemas que não existiam. Por isso, há a
necessidade de executar testes novamente após a realização de modificações para garantir que
não existam efeitos colaterais indesejáveis. Para este tipo de rotina dá-se o nome de testes de
regressão.
Como visto, a quantidade de testes que precisam ser efetuados, muitas vezes, de
forma manual e a necessidade de executar o teste de regressão a cada nova implementação,
transforma a atividade em algo repetitivo. Outros problemas podem ser apontados, tais como:
repetição das mesmas rotinas de teste que torna o serviço oneroso e lento, o tempo gasto na
sua execução e as falhas humanas que podem ocorrer.
Para diminuir a quantidade (custo) dos esforços e minimizar o tempo de execução
dos testes, faz-se necessário a automatização dos testes de regressão.
Em função do que foi exposto, a seguinte pergunta é apresentada: É possível
minimizar custo/esforço e economizar tempo automatizando os testes de software?
19
1.2 OBJETIVOS
Serão apresentados a seguir os objetivos gerais e específicos dessa monografia.
1.2.1 Objetivo geral
Verificar as contribuições dadas pelo uso do framework Selenium ao processo de
automação de testes de regressão a partir de um estudo de caso.
1.2.2 Objetivos específicos
Os objetivos específicos estão descritos a seguir:
• Utilizar uma aplicação web, já existente, como cenário para o estudo de
caso;
• Elaborar os casos de teste para efetuar o teste de regressão de maneira
manual;
• Desenvolver os testes automatizados para atender o cenário proposto;
• Comparar os resultados obtidos a partir do teste de regressão de maneira
manual e automatizado utilizando o framework Selenium.
1.3 JUSTIFICATIVA
A crise de software tornou-se um marco na história do desenvolvimento de
softwares, pois até então essa tarefa era executada de maneira desorganizada, com
20
pouquíssima documentação e sem planejamento, o que culminava em um produto final de
baixa qualidade.
Foi nesse contexto que surgiu a necessidade de modificar esse processo de
desenvolvimento de aplicações, tornando-o mais estruturado, padronizado, documentado e
com um planejamento coerente para que, dessa forma, as necessidades do cliente fossem
atendidas corretamente.
Os testes de software ocorriam integrados ao desenvolvimento, conforme Bastos
et al. (2007, p.11), “Durante as décadas de 1970, 1980 e 1990, os testes eram efetuados pelos
próprios desenvolvedores do software, cobrindo aquilo que hoje chamamos de testes unitários
e testes de integração”.
A qualidade do produto não era assegurada, pois muitos problemas eram
encontrados somente quando os sistemas já se encontravam em produção, tornando sua
correção muito mais cara e onerosa. Ainda de acordo com Bastos et al. (2007), os defeitos de
um software representam um risco para uma organização e pode afetar diretamente a sua
imagem perante seus clientes. Devido a esses fatores os testes começaram a ter uma
importância maior, contribuindo diretamente na qualidade dos produtos.
Como forma de garantir a eficácia de uma aplicação, os testes precisaram ser um
processo paralelo e executado por especialistas na área.
Com o passar dos anos e a adoção cada vez maior dessa prática, diversas
ferramentas surgiram para auxiliar no procedimento dos testes. Notou-se que, em
determinados tipos de teste, a rotina era onerosa e repetitiva e que em algumas situações nem
todos os defeitos do produto eram encontrados previamente, devido à falha humana no
processo de testar. Uma das formas de sanar essa lacuna é o uso de ferramentas que
automatizem as rotinas.
Conforme Bastos et al. (2007) existem recursos computacionais para criação de
dados para testes. Eles apuram tanto as variáveis normais para cada elemento de dado quanto
às variáveis anormais e possíveis erros. É nesse contexto que os autores desse trabalho
pretendem apresentar o framework 1Selenium, com intuito de utilizá-lo para automatização do
teste de regressão.
O presente trabalho possui uma relevância tanto do ponto de vista pessoal para
seus autores, uma vez que lhes agrega conhecimento a respeito de um tema que é do interesse
1 Para Fayad et al (1999), um framework é um conjunto de classes que constitui um projeto abstrato para a
solução de uma família de problemas.
21
de ambos, quanto para a empresa em que trabalham, pois irá aprimorar e otimizar as rotinas
de teste.
1.4 ESTRUTURA DA MONOGRAFIA
O trabalho é apresentado sistematicamente na seguinte estrutura:
Capítulo 1 – Apresenta uma introdução do assunto com uma problemática, os
objetivos e a justificativa.
Capítulo 2 – Contém uma revisão bibliográfica que possui como foco principal a
área de testes de software e sua automatização.
Capítulo 3 – Nesse é descrito o método utilizado, as etapas e delimitações.
Capitulo 4 – Esse capítulo tem como função apresentar as informações sobre a
modelagem do protótipo de software desenvolvido para a aplicação dos testes automatizados
e manuais.
Capítulo 5 - Desenvolvimento da aplicação de automação de testes utilizando o
framework Selenium e elaboração dos casos de teste para o mesmo. Nessa etapa também será
apresentada a modelagem para o software que será testado.
E, por fim, o Capítulo 6 que possui as conclusões da monografia e ideias para
trabalhos futuros.
22
2 REVISÃO BIBLIOGRÁFICA
Esse capítulo dedica-se a apresentar a fundamentação teórica a respeito dos temas
que cercam a Engenharia de Software, dentre eles serão abordados: a crise de software, os
métodos de desenvolvimento, a prática e os tipos de testes e a automatização dos mesmos.
2.1 A CRISE DE SOFTWARE
Após o surgimento dos sistemas operacionais, que dentre suas inúmeras vantagens
trouxe a possibilidade de integração entre hardware e software, a atividade de programação
de aplicativos tornou-se mais viável, uma vez que ambos foram mais amplamente difundidos.
As interfaces começaram a ficar mais amigáveis para os usuários e os computadores pessoais
tornaram-se mais acessíveis, fazendo parte da rotina tanto das empresas quanto das pessoas
em suas casas.
A evolução dos computadores aconteceu de maneira rápida e isto gerou alguns
problemas, já que o desenvolvimento de software não acompanhou da forma mais correta esta
nova realidade.
Segundo Dijkstra (1972):
A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos, isso se tornou um problema pequeno e agora que temos computadores gigantescos, programar tornou-se um problema gigantesco. (DIJIKSTRA, 1972 apud KOSCIANSKI; SOARES, 2007, p. 21).
O termo “crise do software” surgiu por volta da década de 60 e abrange todo o
conjunto de problemas e deficiências no processo de desenvolvimento de um aplicativo
(definição, codificação, implantação e manutenção). (MAFFEO, 1992).
Na época as aplicações eram desenvolvidas sem um método que as guiasse, ou
seja, a construção do software era desorganizada e não seguia padrões de boas práticas,
tampouco havia a preocupação com a qualidade do que estava sendo entregue ao cliente final.
Isto acarretou em problemas diversos, tais como: a baixa qualidade, os atrasos frequentes no
23
projeto, a falta de atendimento aos requisitos do cliente, que gerava manutenções constantes,
dentre outros.
Segundo Deek et al (2005), os fracassos de projeto; as perdas econômicas; os
atrasos na entrega; o mercados competitivos e uma exigência crescente para a qualidade e
confiabilidade de um aplicativo sem custos abusivos impulsionaram a criação de diversas
práticas para tentar solucionar estes gargalos. A partir dessas necessidades surgiu o que
conhecemos atualmente como “Engenharia de Software”.
2.2 ENGENHARIA DE SOFTWARE
O termo ficou conhecido a partir da década de 60 e segundo Koscianski e Soares
(2007) uma das primeiras vezes que se utilizou o tema “Engenharia de Software”, foi em uma
conferência realizada em 1968, na Alemanha, por uma entidade que a princípio não possuía
relação com a área e que se chamava Comitê de Ciência da NATO (North Atlantic Treaty
Organisation – Organização do Tratado do Atlântico Norte).
Segundo Pressman (1995, p.31):
A engenharia de software é um rebento da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais – métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtivamente.
A fim de associar o termo Engenharia ao conceito de desenvolvimento das
aplicações, o IEEE (Institute of Electrical and Electronics Engineers – Instituto de
Engenheiros Elétricos e Eletrônicos), que é a maior associação profissional do mundo
dedicada a avanços tecnológicos, no ano de 1990, destacou que a Engenharia de Software
possuía uma abordagem sistemática, disciplinada e quantificada ao desenvolvimento,
operação e manutenção de software.
Esta engenharia é dividida em camadas, que possuem como foco principal a
qualidade final do produto. O meio para se chegar até esse objetivo é o constante
aperfeiçoamento do processo de desenvolvimento, que consiste na criação de documentos,
artefatos e marcos que são capazes de representar o contexto do software, levando em
24
consideração recursos, ferramentas, prazos, restrições e outros aspectos que envolvem o
desenvolvimento de uma aplicação (PRESSMAN, 2002).
Como ferramental da Engenharia de Software, elaborou-se as metodologias de
desenvolvimento de software, que são apresentadas com mais detalhes na próxima seção.
2.2.1 Metodologias de Desenvolvimento
O uso de metodologias de desenvolvimento de software pelas organizações
representa uma resposta aos problemas encontrados na concepção de sistemas e também
busca atender às camadas de controle da Engenharia de Software. Conceitualmente, elas são
um conjunto de atividades que apoiam a produção de aplicações. Outra definição dada pelo
autor, acadêmico e consultor na área Ian Sommerville (2003) é a de que modelar um processo
pode ser entendido como “uma representação abstrata [...]. Cada modelo de processo
representa um processo a partir de uma perspectiva particular, de uma maneira que
proporciona apenas informações parciais sobre o processo” (SOMMERVILLE, 2003, p.36).
Segundo Koscianski e Soares (2007), as metodologias podem ser classificadas em
dois grupos: as metodologias tradicionais, que possuem como foco a documentação de cada
etapa do desenvolvimento do software e as metodologias ágeis que são adequadas nos casos
em que a mudança dos requisitos é frequente.
O autor Ian Sommerville (2003) destaca que, mesmo existindo diversas
metodologias para o desenvolvimento, algumas etapas são comuns a todas elas, tais como:
• Especificação: trata-se da definição do funcionamento e características
da aplicação;
• Projeto e Implementação: esta etapa contempla a produção de
diagramas, de acordo com as especificações feitas pelo cliente, que serão
implementados através de linguagens de programação;
• Validação: fase de testes no produto e revisão dos requisitos;
• Evolução: atividades de manutenção na aplicação. Nesse passo ocorre a
adaptação às novas necessidades solicitadas pelo cliente.
As principais metodologias serão apresentadas, de maneira mais detalhada, nas
seções seguintes.
25
2.2.1.1 Metodologias Tradicionais
As metodologias tradicionais também são conhecidas como orientadas à
documentação, pois surgiram de um paradigma de desenvolvimento de software distinto do
que vivemos atualmente, uma vez que eram baseados apenas em mainframes e terminais
(ROYCE, 1970).
Na época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores era limitado e não existiam ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Em razão disso, o software era todo planejado e documentado antes de ser implementado. (KOSCIANSKI; SOARES, 2007, p. 191).
Para Pressman (2002), as metodologias tradicionais são aplicadas aos casos em
que os requisitos não sofrem alterações no decorrer do projeto de software.
Dentre os modelos tradicionais encontram-se o clássico ou cascata, o incremental,
a prototipação e o espiral.
2.2.1.1.1 Modelo clássico
O modelo clássico, que também ficou conhecido como cascata, é o mais antigo e
difundido na engenharia de software (PRESSMAN, 1995). Ele traz consigo um paradigma de
desenvolvimento sequencial e possui uma abordagem sistemática.
Na figura 1, pode-se observar o ciclo de desenvolvimento clássico com suas
atividades.
26
Figura 1 – Atividades do modelo cascata
Fonte: Adaptado de Pressman (1995, p. 33)
Para Pressman (1995), este modelo, com o passar dos anos, sofreu severas críticas
e foi colocado em dúvida a sua aplicabilidade, já que os projetos raramente seguem o fluxo
sequencial que o modelo propõe. De acordo com Koscianski e Soares (2007), quanto maior
for a progressão do desenvolvimento do projeto, maior será também o custo das alterações no
mesmo. A figura 2 exemplifica essa situação.
Figura 2 - Custo de modificação
Fonte: http://imasters.com.br/artigo/18732/agile/sem-boas-praticas-de-engenharia-nao-ha-agilidade
27
Segundo Koscianski e Soares (2007, p.192), “o modelo clássico dominou a forma
de desenvolvimento de software até o início da década de 1990, apesar das advertências dos
pesquisadores da área e dos desenvolvedores, que identificaram os problemas gerados ao se
adotar essa visão sequencial de tarefas”.
Embora esse modelo possua alguns pontos negativos, serviu como base para
diversos paradigmas, que surgiram na sequência além de ser uma solução para a abordagem
informal de desenvolvimento que culminou na crise.
2.2.1.1.2 Modelo Incremental
O modelo incremental derivou do modelo cascata. Esse modelo possui como
conceito principal o desenvolvimento de forma incremental, onde em cada incremento novas
funcionalidades serão adicionadas e modificações podem ser inseridas até que o produto seja
finalizado.
Para Sommerville (2003):
Uma vez identificados os incrementos, os requisitos para as funções a serem entregues no primeiro incremento são definidos em detalhes, e esse incremento é desenvolvido [...] Durante esse desenvolvimento, outras análises de requisitos para os incrementos seguintes podem ocorrer, mas as mudanças nos requisitos para o incremento atual não são aceitas (SOMMERVILLE, 2003, p.44).
A cada conclusão de um incremento uma prévia é enviada ao cliente, que pode
colocar o sistema em operação.
A figura 3 ilustra o método de desenvolvimento incremental.
28
Figura 3 - Modelo Incremental
Fonte: http://inf.unisul.br/~vera/egs/aula01.htm
De acordo com Sommerville (2003, p.44), “os incrementos dever ser
relativamente pequenos” onde em cada um deve haver uma funcionalidade. Nesse modelo os
requisitos não são detalhados até que a implementação esteja concluída, o que dificulta o
mapeamento dos requisitos solicitados pelo cliente.
2.2.1.1.3 Prototipação
A prototipação é um processo que possibilita ao desenvolvedor criar um modelo
da aplicação que será implementada. (PRESSMAN, 1995).
O mesmo autor ainda afirma que esse modelo pode assumir três formas:
1. O protótipo em papel que apresenta a interação homem-máquina para que
o usuário entenda o processo de interações que irão ocorrer no projeto;
2. Um protótipo de trabalho que mostra uma parte do software;
3. Uma aplicação que executa uma prévia da funcionalidade solicitada pelo
cliente.
A figura 4 apresenta a sequência de atividades para o modelo de prototipação.
29
Figura 4 - Atividades da Prototipação
Fonte: Pressman (1995, p. 36)
O protótipo geralmente serve como uma visão prévia do sistema e se torna muito
útil na identificação de requisitos. (PRESSMAN, 1995).
Assim como o modelo cascata, esse também possui fragilidades e uma delas, na
opinião de Pressman (1995), é a de que o cliente geralmente confunde o protótipo com uma
versão de trabalho e acaba exigindo que o mesmo se torne o produto final.
Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da engenharia de software. A chave é definir-se as regras do jogo logo no começo; ou seja, o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos. Ele será depois descartado [...] (PRESSMAN, 1995, p.38)
Na seção seguinte, será apresentado o modelo espiral, que surgiu como forma de
unir os pontos positivos tanto do modelo cascata quanto do modelo de prototipação.
30
2.2.1.1.4 Modelo espiral
O modelo espiral surgiu como solução às fragilidades de seus antecessores. Ele
representa o processo como uma espiral, onde cada volta indica uma fase do projeto. Nesse
modelo há um novo elemento: a análise de risco.
De acordo com Sommerville (2003), “os riscos resultam em problemas no projeto,
como a possibilidade de exceder no prazo e no custo previstos; portanto, minimizar riscos é
uma atividade de gerenciamento de projeto muito importante”. (SOMMERVILLE, 2003,
p.46).
Na figura 5 observam-se as iterações do modelo em questão.
Figura 5 - Iterações do modelo espiral
Fonte: Pressman (1995, p.39)
As iterações nesse modelo iniciam-se no centro e avançam para fora da espiral,
sendo que em qualquer etapa da evolução é possível obter protótipos.
31
De acordo com Pressman (1995), o modelo espiral pode ser utilizado como forma
de refinar os requisitos, simulações e o auxílio de outros modelos de desenvolvimento.
Segundo Sommerville (2003):
Não há fases fixas, como especificação ou projeto, no modelo em espiral. [...] A prototipação pode ser utilizada em uma espiral para resolver dúvidas relativas aos requisitos e, portanto, reduzir riscos. Essa fase pode ser seguida por um desenvolvimento em cascata convencional. (SOMMERVILLE, 2003, p.46).
Na próxima seção será apresentada a definição e as principais metodologias ágeis
de desenvolvimento.
2.2.1.2 Metodologias Ágeis
Em fevereiro de 2001, um grupo denominado Aliança Ágil, que era formado por
dezessete pesquisadores dentre eles praticantes de diversas metodologias de desenvolvimento,
assinou em Utah, nos EUA, o Manifesto para o Desenvolvimento Ágil de Software.
De acordo com Ambler (2004, p.23), esse manifesto continha quatro declarações:
Indivíduos e iterações valem mais que processos e ferramentas; um software funcionando vale mais que documentação extensa; a colaboração do cliente vale mais que negociação de contrato; responder às mudanças vale mais que seguir um plano.
Para Koscianski e Soares (2007, p.194):
O Manifesto Ágil não rejeita processos e ferramentas, documentação, negociação de contratos nem planejamento, mas simplesmente mostra que estes tem importância secundária quando comparados com os indivíduos, com o software executável, com a colaboração dos clientes e as respostas rápidas às mudanças.
Esse novo conceito de gestão e desenvolvimento de software possui dentre suas
características a divisão do problema em produtos menores, uma maior interação entre equipe
e cliente e são mais adaptáveis a mudanças. De acordo com Koscianski e Soares (2007,
p.193), “As metodologias ágeis são adequadas para situações em que a mudança de requisitos
é frequente. Para ser realmente considerada ágil, a metodologia deve aceitar a mudança em
vez de tentar prever o futuro”. Dessa forma, o foco da metodologia não é a mudança em si,
32
mas, sim como a equipe irá responder às modificações dos requisitos de um software que
serão frequentes durante o processo de desenvolvimento.
O custo das mudanças no decorrer do projeto de uma aplicação é inferior quando
se utilizam metodologias ágeis. A curva da figura 6 cresce menos ao longo do tempo se
comparada com a da figura 2, que expressava os custos de modificação no modelo cascata. De
acordo com Soares (2004), as metodologias ágeis “... incentivam a mudança nos requisitos,
pois dessa forma é possível realmente entregar ao cliente o produto que ele precisa”.
Figura 6 - Custo de mudanças nas metodologias ágeis
Fonte: Soares (2004)
Na opinião de Koscianski e Soares (2007), as metodologias ágeis mais conhecidas
são a Extreme Programming e a Scrum, ambas serão descritas a seguir:
2.2.1.2.1 Extreme Programming (XP)
A Extreme Programming (XP) possui como foco equipes de desenvolvimento
pequenas e médias e são utilizadas nos casos em que os requisitos sofrem diversas
modificações.
33
Para Koscianski e Soares (2007), as principais características que diferem a XP
das demais metodologias são:
• Comunicação entre os envolvidos é constante;
• O Feedback está sempre presente;
• Abordagem incremental.
A XP utiliza práticas que, à primeira vista, podem parecer incomuns e elas devem
ser aplicadas em forma de conjunto, pois isoladamente não possuem o mesmo efeito.
Para Astels, Miller e Novak (2002), as principais atividades ou “princípios
extremos” da Extreme Programming são:
• Cliente sempre presente: O cliente deve participar ativamente do projeto,
sanando as dúvidas referentes aos requisitos, tomando decisões e
fornecendo o feedback sobre o produto;
• Uso de metáforas: Trata-se de uma representação de um recurso ou
conceito no desenvolvimento do produto, minimizando o uso de alguns
termos técnicos, tornando mais simples o entendimento do problema.
• Planejamento: Os projetos necessitam de um planejamento inicial. A
princípio ele não necessita de muito detalhamento, basta que se tenha
conhecimento dos riscos, o caminho a ser percorrido e o que será feito
para que se alcance o objetivo. O cliente fica responsável pela tomada de
decisões sobre os problemas dos negócios e a equipe de desenvolvimento
possui como responsabilidade a parte técnica.
• Reuniões curtas: As reuniões devem ser breves e diárias, onde o que será
discutido são as atividades que cada membro desempenhou no dia
anterior.
• Testes: A validação do projeto ocorre durante todo o processo. Os testes
são escritos antes do código e uma tarefa não pode ser concluída até que
não haja um conjunto de casos de teste para a mesma.
• Projeto simplificado: A aplicação deve atender aos requisitos atuais. O
projeto deve ser compreensível e o código sucinto.
• Programação em pares: O software deve ser desenvolvido por uma dupla
de programadores, ou seja, ambos trabalharão no mesmo computador.
34
• Código padronizado: A equipe deve adotar um conjunto de padrões para
o código, onde todos os membros devem concordar e seguir.
• Propriedade coletiva: O código da aplicação pertence a todos os
membros da equipe. Dessa forma, todos possuem acesso e são
responsáveis pelo mesmo.
• Integração contínua: o código produzido, depois de ser testado e validado,
será integrado ao sistema que, por sua vez, deve ser testado a cada nova
integração. Assim, o produto é construído de forma gradativa.
• Refatoração: É a melhoria do software internamente sem afetar a estrutura
externa. É uma forma de simplificar o código e minimizar a chance de
defeitos.
• Releases em incrementos pequenos: São versões pequenas do produto
que serão entregues ao cliente. Desse modo, ele fornece o feedback
constante a respeito do software.
• Trabalho semanal de 40 horas: Para a XP o funcionário deve trabalhar
até 40 horas por semana, evitando horas extras.
• Alterações: A equipe deve ser flexível às mudanças que irão ocorrer nos
requisitos do projeto.
A XP, assim como as demais metodologias, possui características positivas e
negativas que deverão ser levadas em consideração pelos gestores no momento de sua
implantação.
Na seção seguinte, será apresentada outra metodologia ágil bastante difundida
atualmente: o Scrum.
2.2.1.2.2 Scrum
O Scrum surgiu em 1990 e foi criado por Jeff Sutherland e sua equipe. De acordo
com Pressman (2006), essa metodologia, assim como o XP, é ideal para projetos que possuam
alterações constantes e prazos curtos.
35
Para Soares (2004, p.5) “a Scrum apresenta uma abordagem empírica que aplica
algumas ideias da teoria de controle de processos industriais para o desenvolvimento de
softwares, reintroduzindo as ideias de flexibilidade, adaptabilidade e produtividade”.
Essa metodologia é semelhante ao XP no que diz respeito ao tamanho das equipes
e a instabilidade dos requisitos.
Dentre os itens característicos do Scrum, está o backlog que seria uma lista com as
pendências, requisitos ou características do projeto. O gerente do projeto avalia quais são as
prioridades, à medida que novos itens são inseridos no escopo. (PRESSMAN, 2006).
O desenvolvimento é feito em ciclos iterativos chamados de sprints, que possuem
duração de até trinta dias com a definição das tarefas de cada membro. As equipes são
chamadas de times e possuem até dez pessoas. As reuniões são curtas, com no máximo 15
minutos, e devem ser executadas diariamente. (KOSCIANSKI; SOARES, 2007).
Dentro de cada time existe um Scrum Master que possui como responsabilidades:
a aplicação dos conceitos do Scrum, conduzir as reuniões, incentivar a colaboração dos
colaboradores dentro do time e minimizar os impedimentos.
A figura 7 ilustra o funcionamento do Scrum.
Figura 7 - Funcionamento do Scrum
Fonte: http://www.heptagon.com.br/scrum
De acordo com Koscianski e Soares (2007), o Scrum possui três fases principais:
36
• Pré-planejamento (pre-game phase): os requisitos encontram-se
ordenados por prioridade no backlog. Nessa fase será definida a equipe de
desenvolvimento, as ferramentas para o mesmo, a identificação das
ameaças para o projeto e possíveis treinamentos.
• Desenvolvimento (game phase): É a fase de construção do software em
sprints onde são controlados os riscos e novas funcionalidades serão
inseridas. O desenvolvimento segue uma métrica: análise, projeto,
implementação e testes.
• Pós-planejamento (post-game phase): Na etapa de pós-planejamento são
executados os testes finais, a integração da aplicação e a documentação
que será entregue ao usuário. Nessa fase são realizadas reuniões para
finalizar o sprint e apresentar o projeto atual para o cliente.
O Scrum fornece uma divisão de tarefas de forma clara, prioriza a comunicação
entre os membros do time, fornece soluções rápidas aos impedimentos que possam surgir,
dentre outras características.
2.3 TESTES DE SOFTWARE
O desenvolvimento de software não é uma tarefa simples de se desempenhar,
dependendo do tamanho e dimensão do problema essa atividade pode se tornar complexa e
custosa. Segundo os autores Delamaro, Jino e Maldonado (2007, p.1), a atividade de
desenvolvimento “[...] pode se tornar bastante complexa, dependendo das características e
dimensões do sistema a ser criado.”.
Além da complexidade na criação dos softwares, existe outro fator importante que
deve ser levado em consideração: a qualidade.
Segundo Pressman:
“Qualidade de software é a satisfação de requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo o software desenvolvido profissionalmente.” (PRESSMAN, 2006, p. 349).
37
A qualidade é uma sequência metódica que possui etapas e ferramentas para que
se tenha um processo ou produto dentro de uma conformidade com a intenção de evitar e
eliminar falhas. (BARTIÉ, 2002).
Para obter qualidade no software desde o início de sua construção são necessários
investimentos. Para Molinari (2003, p. 22 e 23) “o custo total efetivo do gerenciamento de
qualidade é a soma dos quatro fatores: prevenção + inspeção + falha interna + falha externa.”.
A prevenção é o ato de identificar os erros antes que eles apareçam; já o custo de
inspeção tem como foco a medição, avaliação e auditoria dos produtos conforme os padrões e
especificações. O custo de falhas internas é identificado a partir dos testes. O custo de falhas
externa são falhas identificadas pelos clientes, que necessitam de correção.
De acordo com Müller et al (2007), os testes devem fornecer dados que possam
auxiliar a tomada de decisão dentro do projeto, para as fases seguintes do desenvolvimento de
um software ou até mesmo da sua implantação. Portanto, o êxito de um processo de testes
baseia-se em encontrar um defeito e corrigi-lo o quanto antes, assim, os custos de correção
serão menores.
Conforme ilustra a figura 8, o custo da correção de um erro é imensamente maior
quando o software já está em fase de produção.
38
Figura 8 - Custo de correção dos problemas
Fonte: Bastos et al. (2007, p. 19)
O conceito de qualidade está diretamente ligado à prática de testes, conforme
Bartié (2002, p.18) “na verdade, o processo de qualidade de software utiliza-se dos testes em
todo o ciclo de desenvolvimento, de forma a garantir tanto o processo de engenharia quanto o
produto de software desenvolvido.”.
Bartié (2002) afirma que durante o processo de desenvolvimento de software
existem duas fases principais. A primeira consiste em planejar e levantar as informações sobre
o sistema; nesse caso, aplicam-se os testes de verificação, e na segunda fase, onde já existe
um produto em construção executam-se os testes de validação.
A função da verificação é observar se o sistema está de acordo basicamente com
os requisitos funcionais e não funcionais já a validação é a etapa de verificar se a aplicação
está sendo construída da forma correta. Nesse caso, a mesma será avaliada e uma bateria de
testes será executada. (SOMMERVILLE, 2003).
“Os testes de verificação podem ser entendidos como um processo de auditoria de atividades e avaliação de documentos gerados durante todas as fases do processo de engenharia de software. As verificações devem ser aplicadas a todos os produtos (documentos, gráficos, manuais, código-fonte) que são produzidas em cada etapa do
39
processo [...] A principal característica dos testes de verificação é o fato de não envolver o processamento de softwares.” (BARTIÉ, 2002, p.37). Os testes de validação podem ser entendidos como um processo formal de avaliação de produtos tecnológicos que podem ser aplicados em componentes isolados, módulos existentes ou mesmo nos sistemas como um todo [...] A característica dos testes de validação é a presença física do software e de seu processamento em um ambiente [...]. (BARTIÉ, 2002, p.38)
De acordo com Glen Myers citado por Pressman (1995, p. 788), existem três
regras que são os objetivos do teste:
1. A atividade de teste procura descobrir um erro na aplicação;
2. Para um caso de teste ser visto como bom ele deve ter uma grande probabilidade de
achar um erro ainda desconhecido;
3. Um teste que revela um erro ainda não descoberto é chamado de bem sucedido.
Nota-se com base nos objetivos acima citados que para uma atividade de teste ser
considerada bem sucedida, deve reportar o maior número possível de erros. Para Koscianski e
Soares (2007, p. 337) “o objetivo do teste é encontrar defeitos, revelando que o
funcionamento do software em uma determinada situação não está de acordo com o
esperado.”.
Müller et al (2007) defende que a rigorosidade nos testes em sistemas e nas
documentações colaboram para a redução dos riscos causados pela ocorrência de um
comportamento indesejado em ambiente operacional.
Na opinião de Rezende (1999, p.252), a prática de testes “[...] é de fundamental
importância no desenvolvimento de sistemas [...], ela pode garantir o sucesso do mesmo, pois
se todos os requisitos funcionais forem testados, provavelmente o cliente e/ou usuário estará
satisfeito”.
2.3.1 Técnicas para Teste de Software
Em algum momento do projeto de desenvolvimento de uma aplicação os
requisitos serão implementados e deverão estar de acordo com o que foi solicitado pelo
cliente. Nesse momento, os testes, para que essa validação seja feita, são colocados em prática
(BARTIÉ, 2002).
40
De acordo com Pezzè e Young (2008, p.30), “a escolha do conjunto de técnicas de
teste e análise depende das restrições de qualidade, custo, prazo e recursos no
desenvolvimento de um produto em particular”.
As técnicas para teste de software serão apresentadas nas seções seguintes.
2.3.1.1 Teste de unidade
Segundo Bartié (2002), a etapa de testes de unidade é a primeira a ser executada,
pois possui como meta testar partes individuais do sistema.
Esse tipo de teste está relacionado com a estrutura interna do software. Portanto, o
profissional que fará essa etapa deve possuir conhecimento do código; geralmente, são
realizados pelo próprio desenvolvedor.
Nessa estratégia de testes, o objetivo é executar o software de forma a exercitar adequadamente toda a estrutura interna de um componente, como os desvios condicionais, os laços de processamento e todos os possíveis caminhos alternativos de execução. Desta forma, estaremos validando a estrutura interna do componente e atestando a capacidade de processamento sob os mais variados cenários de execução. (BARTIÉ, 2002, p.140)
O teste de unidade avalia algumas partes do código-fonte, buscando a validação
dos dados que serão armazenados, bem como a verificação do comportamento que a aplicação
apresentará no momento em que dados incorretos sejam inseridos. (INTHURN, 2001).
2.3.1.2 Teste de integração
Os testes de integração representam a continuidade dos testes unitários. Nessa
etapa, a função principal é avaliar a compatibilidade e integração entre os componentes do
sistema, pois, cada vez que uma alteração é feita, pode comprometer as demais partes da
aplicação. (BARTIÉ, 2002).
Para Molinari (2003) os testes de integração garantem o funcionamento da
aplicação como um conjunto das funcionalidades.
41
Bartié (2002, p.149) ainda afirma que esse tipo de teste valida “as interfaces entre
componentes da mesma arquitetura tecnológica. Essas [...] representam as trocas dinâmicas de
informações que ocorrem entre componentes durante a execução de um software”.
2.3.1.3 Teste de sistema
Os testes de sistema iniciam-se logo após o término dos testes de integração e
devem simular o ambiente, no qual essa aplicação irá ser instalada e validar todas as suas
funcionalidades.
De acordo com Bartié (2002, p.154), “como os testes de sistemas contam com
uma infraestrutura mais complexa de hardware (mais próximo do ambiente real de produção)
[...] deveriam concentrar-se mais nos aspectos de performance, segurança, disponibilidade,
instalação, recuperação, entre outros”.
Para Bastos et al. (2007) esta etapa só poderá ser finalizada quando a equipe de
testes aprovar a ida do software para a produção.
2.3.1.4 Teste de aceitação
Os testes de aceitação representam o último passo do processo de testes. Segundo
Bartié (2002), nessa parte o aplicativo será disponibilizado para o usuário que poderá verificar
se todas as funcionalidades previstas no planejamento inicial encontram-se no produto final.
O mesmo autor ainda faz uma ressalva: “assim como nos testes de sistema, os procedimentos
de aceite deverão ser realizados a cada ciclo de implementação da solução, permitindo
correções antecipadas [...]” (BARTIÉ, 2002, p.157).
42
2.3.1.5 Tipos de teste
Para a execução dos testes existem diversas técnicas, tais como: testes funcionais
ou caixa-preta que compreendem os testes de requisitos, testes de regressão, teste de
tratamento de erro e teste de interconexão; teste estrutural ou caixa-branca que abrangem o
teste de estresse, o teste de performance, o teste de recuperação e o de segurança; por fim,
existem os testes não funcionais que fazem parte destes o teste de usabilidade e o de
instalação.
A seguir são abordados os principais conceitos sobre estes tipos de testes.
2.3.1.5.1 Testes de caixa-preta
Segundo Rios e Trayahú (2006), os testes funcionais ou caixa-preta são realizados
sem que haja necessidade de ter conhecimento do código-fonte e se atentam apenas a
verificação dos requisitos.
Para Bartié (2002, p.105) “não é seu objetivo verificar como ocorrem
internamente os processamentos no software, mas se o algoritmo inserido [...] produz os
resultados esperados”.
A figura 9 ilustra a visão desse tipo de teste.
43
Figura 9 - Visão do teste caixa-preta
Fonte: adaptado de Bartié (2002, p. 107)
Fazem parte dos testes de caixa-preta: os testes de requisitos, testes de regressão,
testes de tratamento de erros e os de interconexão.
2.3.1.5.1.1 Testes de requisitos
Os testes de requisitos, como o próprio nome já diz, atentam-se exclusivamente
aos requisitos solicitados pelo cliente ou usuário final do sistema. Para Bartié (2002, p.107)
“são baseados nos documentos de requisitos e modelados através de especificações funcionais
e suplementares”.
Por pertencerem ao grupo dos testes funcionais não necessitam de conhecimento
da estrutura interna da aplicação.
44
2.3.1.5.1.2 Testes de regressão
As aplicações sofrem constantes modificações, novos módulos são inseridos e
funcionalidades são adicionadas. Cada alteração dessas podem gerar problemas no software.
Nesse caso, há a necessidade da execução de testes após cada nova implementação, como
forma de prevenção para efeitos colaterais indesejáveis. Os testes de regressão são aplicados
toda vez que o produto é modificado.
Segundo Young (2008, p. 454), “algumas vezes mesmo uma pequena alteração
pode produzir resultados inesperados que levam a falhas”. O mesmo autor ainda destaca que a
regressão basicamente é o processo de executar repetidamente os casos de teste que foram
criados para o software.
Esse tipo de teste pode ser subdivido em dois subgrupos: regressão total e
regressão parcial.
Segundo Alexandre Bartié (2002), os testes de regressão total são realizados sem
exceções, trata-se de um processo sem riscos, porém com custo elevado “[...] Essa escolha
deve estar baseada em uma análise crítica na relação custos versus riscos e em um bom
processo de rastreabilidade de requisitos” (BARTIÉ, 2002, p.197).
Os testes de regressão parcial são executados a partir de um subconjunto dos
casos de teste. Para Bartié “esse subconjunto deve ser identificado através de uma afinidade
de negócio existente entre os casos de teste e as alterações realizadas”. (BARTIÉ, 2002,
p.197). Esse tipo de teste possui custos menores, porém o risco de algum caso de teste
importante deixar de ser selecionado é alto, tornando o processo frágil.
Segundo Young (2008, p. 454), destaca uma característica importante quando são
utilizados os testes de regressão:
Alterações na versão do software podem influenciar no formato das entradas e saídas e os casos de teste podem não ser executáveis sem as alterações correspondentes. Mesmo modificações simples nas estruturas de dados [...] podem invalidar os casos iniciais ou os resultados comparáveis com os novos. Além disso, alguns casos de teste podem ficar obsoletos uma vez que testam funcionalidades do software que foram modificadas, substituídas ou removidas na nova versão.
Por se tratar de uma atividade repetitiva, nos últimos anos tem-se falado em
automação dos testes de regressão. Esse tema será explicado na seção 2.3.2.
45
2.3.1.5.1.3 Testes de tratamento de erros
Os testes de tratamento de erros, como o próprio nome indica, é a capacidade que
a aplicação possui para tratar e prevenir os possíveis erros que ocorram.
De acordo com Bastos et al. (2007), o responsável por esse tipo de teste deve
possuir como foco: verificar se as condições de erro são reconhecidas pelo sistema, observar
se a responsabilidade pelo processamento do erro foi atribuída ao componente correto e
visualizar o controle que o software possui sobre os erros que surgem no decorrer do
processo.
2.3.1.5.1.4 Testes de interconexão
Os testes de interconexão garantem o funcionamento de aplicações conectadas a
outros softwares. De acordo com Bastos et al. (2007, p. 64), “Os testes de interconexão
devem ser conduzidos sempre que existir uma mudança nos parâmetros entre softwares de
aplicações.”.
2.3.1.5.2 Teste de caixa branca
De acordo com Pressman (1995, p. 793), “o teste de caixa branca é um método de
projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar
casos de teste.”.
Esse tipo de teste também é conhecido como estrutural e, nesse caso, o analista
possui conhecimento do software e de suas estruturas internas. Dessa forma, ele pode escolher
quais componentes serão testados, agregando mais precisão ao teste. (KOSCIANSKI;
SOARES, 2007, p. 343).
A figura 10 apresenta uma visão dos testes de caixa-branca.
46
Figura 10 - Visão do teste caixa-branca
Fonte: Adaptado de Bartié (2002, p. 107)
Os testes de caixa-branca englobam: testes de estresse, teste de performance, teste
de recuperação e o teste de segurança.
2.3.1.5.2.1 Testes de estresse
De acordo com Koscianski e Soares (2007, p. 347), “O teste de estresse é
realizado para submeter o software a situações extremas.”. O mesmo autor afirma que esse
tipo de teste é muito utilizado em aplicações onde a eficiência seja um requisito importante
como nos seguintes casos, por exemplo:
47
• Servidores web que recebem solicitação de diversos usuários;
• Na indústria;
• Jogos para computador.
2.3.1.5.2.2 Testes de performance
Nesse tipo de teste ocorre uma comparação entre a quantidade de transações
efetuadas e o tempo de resposta do sistema em condições extremas. O cenário deve ser
especificado com bastante atenção. Para Bartié (2002) os testes são executados, verificando-se
alguns itens:
• Levantar os requisitos de desempenho;
• Simular uma quantidade de usuários executando a mesma tarefa
simultaneamente;
• Simular a porcentagem de tráfego na rede.
2.3.1.5.2.3 Testes de recuperação
Os testes de recuperação “tem por objetivo avaliar o comportamento do software
após a ocorrência de um erro ou de determinadas condições anormais”. (BARTIÉ, 2002,
p.118). O mesmo autor destaca que uma maneira de simular erros, para esse caso, seria
interromper o acesso à rede ou ao processamento desligando o servidor, por exemplo. Isso
simula qual será a capacidade da aplicação recuperar os dados que estavam sendo processados
naquele momento.
2.3.1.5.2.4 Testes de segurança
Para Bartié (2002, p.116) os testes de segurança “tem por objetivo detectar falhas
de segurança que podem comprometer o sigilo e a fidelidade das informações, bem como
provocar perdas de dados ou interrupções de processamento”.
48
Nesse passo ocorre uma avaliação do software para que se possa saber qual o
nível de segurança para os dados que o mesmo oferece. Um exemplo disso seria tentar acessar
dados de nível gerencial com um perfil de usuário comum. A tentativa de descobrir senhas e
obter backups de informações sigilosas também são técnicas do teste de segurança.
2.3.1.5.3 Testes não-funcionais
Trata-se de outra categoria para teste, o International Software Testing
Qualifications Board (2007) não possui como objetivo a verificação de funcionalidades ou
requisitos, como nos testes de caixa preta ou branca. Nesse caso, observa-se itens como
usabilidade do sistema e o processo de instalação do mesmo.
2.3.1.5.3.1 Testes de usabilidade
O teste de usabilidade analisa os itens do software de acordo com a perspectiva do
usuário final.
Dessa forma, esses testes focalizam a facilidade de navegação entre as telas da aplicação, a clareza de textos e mensagens que são apresentados ao usuário, o volume reduzido de interações para realizar uma determinada função, padronização visual, entre outros aspectos. (BARTIÉ, 2002, p.114).
O objetivo principal é mensurar a facilidade que o usuário terá em manipular o
software de modo intuitivo e simples. Para Bartié (2002) oferecer telas de ajuda também é
uma característica importante de usabilidade.
2.3.1.5.3.2 Teste de instalação
Como o próprio nome já descreve, deve-se verificar o processo de instalação da
aplicação. O ideal seria que o cliente também validasse esse processo.
Para Bartié (2002) pode ser interessante aplicar diversos tipos de instalação
simulando várias situações:
49
• Realizar a instalação pela primeira vez;
• Instalar o software em ambientes diferentes;
• Realizar a instalação da aplicação após a mesma já ter sido instalada;
• Verificar se a instalação atende os requisitos do cliente.
2.3.2 Automatização de Testes de Software
Testar um software é uma sequência de passos minuciosa que pode se tornar
cansativa. Uma alternativa para proporcionar a entrega de produtos confiáveis em menor
tempo é a realização de teste de software de maneira automatizada. (DUSTIN, 2002).
Segundo Pezzè e Young (2008), a automação pode melhorar a eficiência de
algumas das atividades de qualidade, como também se tonar uma necessidade para
implementações de futuras melhorias no processo de testes de software.
Assim, é necessário saber quando automatizar. Molinari (2003) cita que a
automação de teste faz-se necessário nas seguintes situações:
• Quando os testes que utilizam as técnicas de regressão ou de confirmação
repetem constantemente;
• Quando há o uso de testes aleatórios (testes “random” ou “monkey”) que
utilizam caminhos aleatórios gravados por dentro da aplicação e de grande
quantidade de dados de teste;
• Quando os testes de carga, volume, capacidade exigem muita gente para
simular e efetuar o teste;
• Quando se faz teste de componentes (unidade) os quais devem ser retestado
várias vezes.
Para efetuar a automação de testes, investimentos são imprescindíveis; esforços
como análise e planejamento são precisos para conseguir atingir esse objetivo. Molinari
(2003) destaca que automação de teste é um investimento alto, onde existe uma combinação
de pessoas, técnicas, processos, tempo e foco. Por conta desses investimentos, muitas
50
organizações não veem a automação de teste com bons olhos e, muitas vezes, essa alternativa
é descartada.
No mercado atual, existem ferramentas que auxiliam na automação de teste e que
visam diminuir o investimento na prática da automação. Molinari (2003), destaca que
investimentos empregados em automação consistem em escolha do tipo de ferramenta,
verificação na licença da ferramenta, hardware gasto na instalação das ferramentas,
treinamentos, manutenção nos scripts de teste e suporte ao fornecedor.
A seguir, serão expostas algumas ferramentas de automação existentes no âmbito
comercial, acadêmico e após serão exibidos as novas tendências de ferramentas.
2.3.2.1 Ferramentas para automação de teste
De acordo com Molinari (2003), existem ferramentas para automação de testes e
as mesmas são classificadas em dois grupos: as ferramentas comerciais e as acadêmicas.
Uma ferramenta comercial, para Molinari (2003, p.107), “[...] foca as
funcionalidades”. Abaixo, pode-se observar, no quadro 1, uma lista com sua classificação:
Quadro 1 - Ferramentas comerciais Tipo Descrição
Test Design Ajuda na decisão da escolha do teste que
precisa ser executado
GUI Test Drivers & Capture/Replay Ajudam na execução de teste que façam uso
de uma “graphical user interface”,
independente se a aplicação será Web,
Client-Server, Java, dentre outros.
Load & Performance Ferramentas especializadas em dar “uma
carga pesada de dados” ao sistema, também
conhecido como ferramenta do “test-driver”.
Non-GUI Test Drivers & Test Managers Ferramentas de automação de execução dos
testes com uma interface gráfica. Podem
trabalhar com grandes suítes de testes.
51
Test Implementation Ferramentas que ajudam na implementação
dos testes. Um exemplo típico seria a geração
automática de sub-rotinas para tratamento de
falhas óbvias no programa.
Test Evaluation Ferramentas que ajuda a avaliar a qualidade
dos seus testes. A ferramenta de análise de
cobertura de código. (“code coverage”) seria
um exemplo.
Static Analysis Ferramentas que analisam o programa sem
executá-lo. Ferramentas de métricas
pertencem a esta categoria.
Defect Tracking Ferramentas que ajudam a gerenciar um
“banco de dados” com os defeitos
encontrados.
Fonte: Baseado em Molinari, 2002.
No caso da ferramenta acadêmica, Molinari (2003, p. 107) afirma que a mesma
“[...] foca a sua forma básica de concepção”. Sendo assim, no quadro 2, pode-se observar a
classificação da mesma:
Quadro 2 - Ferramentas acadêmicas Tipo Descrição
Capture/Replay Captura os comandos executados por
usuários e os executam.
Code Auditors Análise e auditoria de código que está sendo
testado.
Debuggers Ferramentas típicas dos programadores, que
visam retirar erros básicos do código
desenvolvido.
Standards Checkers Ferramentas que permitem verificar padrões
de interface.
Structural Analyzers Ferramentas que permitem analisar a
52
estrutura de aplicação-alvo teste.
Test Coverage Analyzer Análises de cobertura de código.
Test Data Extraction Ferramenta de extração e verificação de
dados para teste.
Test Data Generators Ferramentas de geração de massas de dados
para teste.
Test Management Ferramenta de gerenciamento de teste.
Fonte: Baseado em Molinari, 2002.
2.3.2.2 Tendências para as ferramentas de automação
Segundo Molinari (2003), as novas tendências de ferramentas de automação de
testes estarão focadas em testes funcional, testes de regressão, testes de performance, testes de
carga, ferramentas que atende o planejamento de testes, testes de monitoração e ferramentas
de teste estrutural.
Segundo Fernandes (2006), no mercado, não existem ferramentas que suportam
todos os ambientes de operação de programas. É provável que nenhuma delas seja capaz de
atender todos os requisitos de uma organização, visto que múltiplas tecnologias são
empregadas em diversos projetos.
Conforme a evolução dos sistemas, novos mercados e ferramentas surgirão a
partir de uma boa análise das necessidades de testes e um bom planejamento, tornando-se
possível agregar valores e exibir ganhos efetivo para a organização. Segundo Foote e Yoder
apud Molinari (2003), “Se você pensa que uma arquitetura boa é cara, tente então uma má
arquitetura”.
Segundo Pezzè e Young (2008):
“O foco não está na escolha de um conjunto particular de “melhores” ferramentas para todos os momentos e situações, mas na continuidade de um processo racional de identificação e instalação de automações visando obter o melhor resultado à medida que a organização, o processo e a tecnologia evoluem.”.
53
2.3.2.3 Automação de Teste x Teste de Regressão
Segundo Oliveira (2007, p.46), “um teste de regressão corresponde à re-execução
de um teste outrora realizado com sucesso sob um conjunto de funcionalidades do sistema.”.
A execução de testes de regressão tem o propósito de reavaliar o comportamento
do software, quando ocorrem modificações e a automatização do teste permite a identificação
rápida de defeitos, além de agilizar o processo de depuração e permitir a captura e análise dos
resultados de teste de forma consistente. (BINDER 1999).
Fernandes (2006) afirma que é comum presenciar a falsa expectativa de que todo
teste poderá ser automatizado mediante a compra de determinada ferramenta. Há casos em
que a automação não é possível ou é mais cara que a execução manual dos testes.
Os autores Pezzè e Young (2008) destacam que o julgamento e solução criativa de
problemas permanecem fora do domínio da automação, enquanto tarefas simples e repetitivas
normalmente são fáceis de automatizar.
É preciso, então, analisar e planejar quais os testes automatizar. Segundo Black
(2007) apud Oliveira (2007, p.47), existe algumas técnicas para selecionar subconjuntos de
testes de regressão e são elas:
• Uso de Rastreabilidade: identificar testes relacionados a descrições do
comportamento do sistema, como elementos de especificação de
requisitos, elementos de especificação de projeto ou análise de riscos;
• Uso de Análise de Mudança: nesse caso, devem ser analisadas descrições
estruturadas do sistema para descobrir como os efeitos de mudança se
propagariam através do sistema;
• Uso de Análise de Risco de Qualidade: priorizar testes que verificam áreas
de maior risco.
Para Dustin (2002) o conjunto de teste de regressão necessita ser automatizado e
deve ser executado em um ambiente estável para que sua execução seja aprimorada com o
mínimo possível de recursos. Caso os testes não sejam automatizados, a atividade de testes de
regressão torna-se excessivamente detalhada e repetitiva.
54
Um conjunto ou suíte de teste de regressão pode compreender tanto testes de
caixa-branca quanto testes caixa-preta. Uma prática comum quando se trabalha com
Integração Contínua é automatizar testes de caixa-branca, garantindo uma maior
confiabilidade ao código desenvolvido. (GOIS, 2007).
A automação de teste é um investimento que visa economizar custos futuros no
processo de desenvolvimento de software. Sabe-se que, para automatizar testes, são
necessários esforços. Contudo, o desafio da automação consiste em verificar custos,
identificar os benefícios e, principalmente, efetuar a escolha certa de quais testes serão
automatizados.
55
3 MÉTODO
Esse capítulo aborda a metodologia presente nessa monografia, apresentando o
tipo de pesquisa que será adotado, as etapas metodológicas da pesquisa, um esboço da solução
e as delimitações da pesquisa.
De acordo com Menezes e Silva (2005, p. 25), a metodologia científica pode ser
definida como “[...] o conjunto de processo ou operações mentais que se devem empregar na
investigação. É a linha de raciocínio adotada no processo de pesquisa”.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
De acordo com Menezes e Silva (2005, p. 20), “pesquisa é um conjunto de ações,
propostas para encontrar a solução para um problema, que têm por base procedimento
racionais e sistemáticos. A pesquisa é realizada quando se tem um problema e não se têm
informações para solucioná-lo”.
Existem diversas formas de se definir os tipos de pesquisas, dentre elas temos: a
pesquisa básica, aplicada, quantitativa, qualitativa, exploratória, descritiva, explicativa,
bibliográfica documental, experimental, levantamento, estudo de caso, expost-facto, ação e
participante. (MENEZES E SILVA, 2005, p. 20).
Esse trabalho classifica-se quanto à sua natureza como uma pesquisa aplicada,
quanto sua abordagem como pesquisa qualitativa, tendo como objetivos uma pesquisa
exploratória e de acordo com os procedimentos técnicos, classifica-se como pesquisa
bibliográfica e estudo de caso.
Segundo Menezes e Silva (2001, p. 20) “pesquisa aplicada objetiva gerar
conhecimento para aplicação prática dirigidos à solução de problemas específicos."
Gil (1999, p.42) ainda coloca que a pesquisa “Tem um caráter pragmático, é um
processo formal e sistemático de desenvolvimento do método científico. O objetivo
fundamental da pesquisa é descobrir respostas para problemas mediante o emprego de
procedimentos científicos”.
56
De acordo com Menezes e Silva (2005, p. 20), pesquisa qualitativa significa:
[...] um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzido em números. A interpretação dos fenômenos e a atribuição de significados são básicas no processo de pesquisa qualitativa. Não requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta para coleta de dados e o pesquisador é o instrumento-chave. É descritiva. Os pesquisadores tendem a analisar seus dados indutivamente. O processo e seu significado são os focos principais de abordagem.
Do ponto de vista dos objetivos, a presente monografia apresenta uma pesquisa
exploratória que, segundo Menezes e Silva (2005), visa proporcionar maior familiaridade com
o problema, tendo como objetivo torná-lo explícito ou construir hipóteses. Essa pesquisa
envolve levantamento bibliográfico, entrevistas com pessoas com experiências práticas e
análise de exemplos que auxiliem a compreensão do problema.
De acordo com o ponto de vista dos procedimentos técnicos, essa monografia
apresenta duas características: a pesquisa bibliográfica e o estudo de caso. Menezes e Silva
(2005) afirmam que uma pesquisa bibliográfica é aquela que foi elaborada a partir de um
material previamente publicado, sendo exemplos deste: livros, artigos e publicações
disponibilizadas na internet. Os mesmos autores destacam que um estudo de caso pode ser
definido como uma pesquisa que envolve um estudo profundo e exaustivo de um ou poucos
objetos, permitindo o seu amplo e detalhado conhecimento.
3.2 ETAPAS METODOLÓGICAS
Uma das etapas metodológicas iniciais representa a revisão bibliográfica que
serve de base para todo o trabalho. Após, será efetuado em paralelo às tarefas de
desenvolvimento dos testes automatizados e de estudo de uma aplicação web já existente
chamada Projector, que servirá de base, tanto para execução dos testes de regressão manual,
quanto para o teste automatizado. Em seguida, serão colocados em prática os testes manuais e
os automatizados, para que se possa fazer uma análise comparativa. Por fim, serão extraídas
as conclusões de ambos os procedimentos de teste.
A figura 11 ilustra esse processo.
57
Figura 11 - Etapas metodológicas
Fonte: Elaborado pelos autores, 2013
58
3.3 DESENHO DA SOLUÇÃO
Esse projeto utilizará um sistema web chamado Projector, que foi desenvolvido
durante o curso de graduação em Sistemas de Informação como trabalho final da disciplina de
Engenharia de Software, não sendo, portanto, um produto comercial. Essa aplicação consiste
em uma solução para gestão de projetos da área de TI.
O objetivo será aplicar os testes de regressão manuais e automatizados com o
apoio de profissionais da área, a fim de comparar as duas abordagens. Os testes elaborados
pertencem a algumas funcionalidades do Projector.
A rotina manual será escrita em um documento e entregue aos participantes
envolvidos para que os mesmos a executem em um primeiro momento. Em seguida, eles
acompanharão os mesmos testes feitos anteriormente de maneira automática.
Os casos automatizados são criados a partir de um script na ferramenta Selenium.
A figura 12 irá ilustrar essa proposta de solução.
59
Figura 12 - Esboço da Solução
Fonte: Elaborado pelos autores, 2013
3.4 CARACTERÍSTICAS DO ESTUDO DE CASO
Para que se possa avaliar o uso do teste automatizado sobre o uso dos testes
manuais, formulou-se um estudo de caso. Essa seção tem como função apresentar mais
informações sobre o mesmo.
60
3.4.1 Cenário proposto
Como forma de aplicar os conceitos da automação, foi utilizado o protótipo de
sistema web denominado Projector, que possui seu foco em gerenciamento de projetos. Essa
aplicação servirá de base para o desenvolvimento dos testes de regressão automatizados. Nela
foram introduzidos alguns bugs2 propositalmente para que seja possível visualizar dois casos:
• Caso 1: Onde alguma funcionalidade está operando de forma incorreta ao
esperado;
• Caso 2: Quando não ocorre nenhum problema e a funcionalidade está de
acordo com os requisitos.
Haverá a criação de casos de testes manuais, a fim de validar algumas funções do
Projector e as mesmas rotinas serão testadas, utilizando um sistema de automação, de modo
que se possam identificar pontos positivos e negativos de cada abordagem.
3.4.2 Objetivos
O estudo de caso possui os seguintes objetivos:
• Identificar as diferenças entre testes manuais e automatizados, levantando
suas vantagens e desvantagens;
• Colher as informações dos profissionais que utilizarão o sistema através de
um questionário;
• Verificar no contexto dos testes de regressão automatizados qual caso de
teste apresenta maior vantagem utilizando esse procedimento.
2 Bug é um “[...] defeito no software que, caso mantido, pode provocar falhas no sistema.” (HETZEL, 1987, p.
15).
61
3.4.3 Ferramentas utilizadas
Os softwares que aqui estão descritos servem como ferramenta para o estudo e
execução da proposta.
Os casos de teste são documentados com o auxílio do Microsoft Office Word
2010.
A automação dos testes no Projector é concebida com o apoio do Selenium.
A modelagem do sistema Projector já havia sido criada com a utilização da
ferramenta Entreprise Architect, onde é possível visualizar maiores detalhes de sua estrutura
interna.
Para apoio no comparativo entre a proposta de automação e a manual, há a
aplicação de um questionário para alguns profissionais da área de teste, como forma de
levantar a percepção dos envolvidos. O mesmo estrutura-se em duas partes e a figura 13
demonstra de forma meramente ilustrativa as etapas.
Figura 13 - Etapas do questionário
Fonte: Elaborado pelos autores
Pode-se identificar duas partes:
1. Identificação de dados pessoais dos participantes, tais como: idade, nível
de escolaridade, cargo que ocupa na área de teste e há quanto tempo está
nessa área;
2. Levantamento das percepções que os participantes obtiveram após
execução do teste manual;
Esse questionário encontra-se no Apêndice A, no final do trabalho.
62
3.4.4 Perfil dos profissionais envolvidos
Para auxiliar no estudo de caso, haverá o apoio de alguns profissionais graduados
em cursos da área de Tecnologia da Informação e que atuam profissionalmente como analistas
de teste, possuindo, portanto, a experiência necessária para a função.
O papel deles é executar os testes de regressão manuais e automatizados criados
para a aplicação Projector, resultando em uma coleta de opiniões a respeito desses cenários.
Essas concepções serão extraídas do questionário, servindo como apoio nas considerações
finais sobre a proposta do trabalho.
3.4.5 Avaliação dos resultados
A avaliação dos resultados obtidos no estudo de caso dar-se-á através do
questionário, onde serão feitas planilhas com dados que servirão de base para uma análise dos
resultados. O questionário será aplicado aos indivíduos envolvidos nas rotinas de teste e suas
percepções e opiniões a respeito da proposta, como também serão utilizadas no resultado
final.
3.5 DELIMITAÇÕES
Esse trabalho apresenta delimitações, que são descritas a seguir.
Profissionais da área: serão utilizados como base apenas profissionais da área de
teste, ou seja, não se aplica a usuários leigos no assunto.
• Não será desenvolvida uma aplicação web. A presente monografia utilizará
uma já existente como estudo de caso;
63
• O teste automatizado será exclusivo da aplicação web que será utilizada de
base;
• Toda e qualquer alteração no sistema poderá intervir diretamente nos
testes;
• Não serão apresentados os logs específicos da execução dos testes.
64
4 PROJETO DE SOLUÇÃO DO PROTÓTIPO
Nesse capítulo haverá uma breve descrição do sistema web que será utilizado no
estudo de caso, bem como os diagramas principais que o compõe. Com base nessa aplicação
serão executados os casos de teste manuais e automatizados. Ambos estarão descritos nas
próximas seções.
4.1 DEFINIÇÃO DE TÉCNICA E METODOLOGIA
De acordo com Fachin (2001, p. 29), os métodos e as técnicas possuem uma
relação, mas são conceitos distintos em alguns aspectos.
A técnica é um “modo de fazer de forma mais hábil, mais seguro, mais perfeito,
algum tipo de atividade, arte ou ofício” (GALLIANO, 1986, p. 6).
Já o método, conforme Garcia (1998, p. 44), apresenta um procedimento racional
e ordenado, constituído por instrumentos básicos, que implica utilizar a reflexão e a
experimentação, para proceder ao longo do caminho e alcançar os objetivos preestabelecidos
no planejamento da pesquisa.
4.1.1 Unified modeling language (UML)
A UML (Unified Modeling Language), segundo Rezende (1999, p. 201), é “uma
notação ou uma padronização unificada de modelagem (diagramação e desenvolvimento) de
software”. O mesmo autor ainda acrescenta que se trata de uma linguagem para modelagem
não sendo, portanto, uma metodologia de desenvolvimento.
Bell (tradução nossa, 2003) afirma que os diagramas UML mais utilizados são:
diagrama de casos de uso, diagrama de classe, diagrama de sequência, diagrama de estados,
diagrama de atividade, diagrama de componentes e diagrama de implantação.
65
• Diagrama de caso de uso - Para Rumbaugh et al. (2000, p.217), esse diagrama é
responsável por “captar o comportamento pretendido do sistema que está sendo
desenvolvido, sem ser necessário especificar como esse comportamento é
implementado”.
• Diagrama de classe - São usados para exibir as classes e interfaces de um sistema, bem
como suas relações. (RUMBAUGH et al. , 2000).
• Diagrama de sequência - De acordo com Eriksson e Penker (2000), eles são usados
para explorar e visualizar a sequência de objetos em interações uns com os outros.
• Diagrama de estado - A ideia é de estudar certos tipos de lógicas que envolvem
transições possíveis entre diferentes estados. (FURLAN, 1998)
• Diagrama de atividade – Nesse caso serão apresentados os fluxos das atividades de
controle do sistema. (RUMBAUGH et al., 2000)
• Diagrama de componentes – Analisam e gerenciam dependências entre componentes
ou entre interfaces de componentes. Podem ser arquivos de código-fonte, bibliotecas
ou programas executáveis. (ERIKSSON; PENKER, 2000)
• Diagrama de implantação – Furlan (1998) explica que esse diagrama tem como
propósito mostrar a organização de hardware e a ligação do software aos dispositivos
físicos.
4.1.2 Iconix
Segundo Guimarães et al., (2007) o ICONIX pode ser definido como um processo
de desenvolvimento de software cuja metodologia utilizada é simples e prática, tendo um
componente de análise e representação de problemas sólido e eficaz.
Para Rosenberg (tradução nossa, 2005, p. 58) dentro do ICONIX tudo tem um
propósito primordial. O mesmo autor ainda explica alguns elementos que compõem o
ICONIX:
• Diagrama de Robustez: Explica as exigências de comportamento, relacionando-as ao
modelo de objeto;
• Diagrama de Sequência: Atribui funções para as classes, mostrando seu
comportamento;
66
• Modelo de domínio: Descreve os objetos do mundo real e os relacionamentos;
• Modelo de casos de uso: Define os requisitos de comportamento.
A seguir será ilustrado na figura 14 o processo do ICONIX.
Figura 14 - Visão geral do ICONIX
Fonte: Baseado em Rosenberg (2005, p. 45).
4.1.3 Orientação a Objetos (OO)
A orientação a objetos (OO) pode ser entendida como uma junção de objetos que
integram-se à estrutura de dados e possuem um comportamento. (BLAHA; RUMBAUGH,
2006, p.1).
De acordo com Bezerra (2002, p.6), “O paradigma da orientação a objetos
visualiza um sistema de software como uma coleção de agentes interconectados chamados
objetos. Cada objeto é responsável por realizar tarefas específicas”. O mesmo autor ainda
destaca que é essa interação que executa uma tarefa computacional.
67
Para Sommerville (2003), o processo de uma orientação a objetos compreende o
projeto das classes dos objetos e as relações entre elas.
Um projeto que possua esse mecanismo compreende três etapas que juntas
formam um processo de desenvolvimento. (SOMMERVILLE, 2003, p. 221). São elas:
• A análise: compreende a fase de modelagem do sistema OO. Os objetos que serão
identificados possuem relação com as entidades e operações do problema a ser
implementado;
• O projeto: desenvolve um modelo OO para implementar os requisitos levantados. Os
objetos, nesse caso, possuem relação com a solução;
• A programação: codifica o projeto com o apoio de uma linguagem de programação
OO.
4.2 DESCRIÇÃO DO PROTÓTIPO UTILIZADO NO ESTUDO DE CASO
Para o estudo de caso, será utilizado um protótipo de uma aplicação web que foi
desenvolvida por um grupo de acadêmicos do curso de graduação em Sistemas de
Informação, cuja modelagem foi construída por Luiz Henrique Sant’ana e Rodrigo Veleda e a
programação do sistema por Rodrigo Susin de Oliveira, Giovani Brunel Paes e José Fernando
Meyer. O protótipo foi construído para atender o trabalho final da disciplina de Engenharia de
Software III.
O sistema consiste numa aplicação para gestão de projetos, onde são possíveis:
• Cadastro, edição e exclusão de um projeto;
• Apontamento de horas gastas em cada projeto;
• Cadastro de usuários do sistema;
• Cadastro, edição e exclusão de uma atividade.
68
4.2.1 Atores
O sistema possui cinco atores, conforme ilustra a figura 15.
Figura 15 - Diagrama de Atores
Fonte: Elaborado pelos autores do sistema
No sistema que será utilizado, existem cinco atores, são eles:
• Usuário: é um ator padrão que manipula o sistema. Possui a permissão de
logar no sistema e atualizar o andamento das atividades de um projeto;
• Gerente: possui privilégio do usuário, pois herda suas funções. Possui
permissão para cadastrar projetos, cronograma, marcos, status e
atividades;
• Administrador (Admin): usuário root da aplicação que possui todos os
privilégios do gerente e do usuário. Possui como responsabilidade os
cadastros de perfil, usuário e cliente;
• Cliente: possui um login no sistema para poder acompanhar o andamento
das atividades;
• Sistema: possui o conjunto das funcionalidades do próprio.
69
4.2.2 Requisitos
Segundo Sommerville (2003, p. 82), “os requisitos do usuário devem ser escritos
para gerentes do cliente e dos fornecedores, que não tenham um conhecimento técnico
detalhado do sistema”.
As próximas seções especificam os dois tipos de requisitos do sistema: os
funcionais e os não funcionais.
4.2.2.1 Requisitos Funcionais
Os requisitos funcionais, segundo Sommerville (2003), contêm as declarações de
serviço que o sistema deve fornecer, o comportamento que o mesmo deve ter em
determinadas situações e como deve reagir a entrada de dados específicos.
A figura 16 ilustra os requisitos funcionais do sistema.
70
Figura 16 - Requisitos Funcionais
Fonte: Elaborado pelos autores do sistema
Abaixo serão apresentados os requisitos funcionais do sistema:
• RF001 - O sistema deve permitir o cadastro de projetos;
• RF002 - O sistema deve permitir o cadastro de atividades relacionadas a
um projeto;
71
• RF003 - O sistema deve permitir o cadastro de marcos relacionados a um
projeto;
• RF004 - O sistema deve permitir o registro diário da realização das
atividades;
• RF005 - O sistema deve emitir relatórios de acompanhamento dos
projetos;
• RF006 - O sistema deve permitir o cadastro de usuários;
• RF007 - O sistema deve permitir o cadastro de clientes;
• RF008 - O sistema deve restringir o acesso através de um login e senha;
• RF009 - O sistema deve ter um usuário master cadastrado por padrão;
• RF010 - O sistema deve permitir o cadastro de cronogramas;
• RF011 - O sistema deve permitir o cadastro de perfis de usuários;
• RF012 - O sistema deve permitir o cadastro de status.
4.2.2.2 Requisitos Não Funcionais
De acordo com Sommerville (2003, p.80), os requisitos não funcionais “são
restrições sobre os serviços ou as funções oferecidas pelo sistema. Eles incluem restrições de
timing, restrições sobre o processo de desenvolvimento e padrões”.
A figura 17 ilustra os requisitos não funcionais do sistema.
72
Figura 17 - Requisitos não funcionais
Fonte: Elaborado pelos autores do sistema
Abaixo serão apresentados os requisitos não funcionais do sistema:
• RNF001 - Sistema deve ter senhas criptografadas;
• RNF002 - Sistema deve possuir tempo de resposta inferior a 5 segundos -
Para Windows e Linux;
• RNF003 - Sistema deve ser web;
• RNF004 - Sistema deve ser compatível com o browser Google Chrome 6
ou superior;
• RNF005 - Sistema deve ser compatível com o browser Microsoft Internet
Explorer 8 ou superior;
• RNF006 - Sistema deve ser compatível com o browser Mozilla Firefox 4
ou superior.
4.2.3 Protótipos de Interface
A figura 18 demonstra o protótipo da tela de cadastro dos projetos.
73
Figura 18 - Tela de cadastro dos projetos
Fonte: Elaborado pelos autores do sistema
Na figura 19, é possível observar o protótipo da tela de cadastro das atividades
que o projeto possui.
74
Figura 19 - Tela de cadastro das atividades
Fonte: Elaborado pelos autores do sistema
4.2.4 Casos de Uso
A figura 20 ilustra a modelagem dos casos de uso do sistema.
75
Figura 20 - Casos de Uso
Fonte: Elaborado pelos autores do sistema
Abaixo, a figura 21 ilustra o fluxo principal e os fluxos alternativos para o caso de
uso cadastrar projeto:
76
Figura 21 - Cadastrar Projeto act US001 - Cadastrar projeto_Activ ityGraph
Start
Sistema mostra tela: TEL025 - Login - Gerente
Gerente clica em Gerenciar Projetos
Alternate1
Gerente clica em Adicionar
Sistema mostra formulário: TEL001 - Cadastrar projetos -
Adicionar
Gerente preenche dados
Sistema mostra tela de cadastrado com sucesso:
TEL036 - Salv o com sucesso
FlowEnd1
Gerente seleciona projeto
Gerente clica em Editar selecionado
Sistema mostra formulário: TEL002 -
Cadastrar projeto - Editar
Gerente edita dados
Sistema mostra tela de dados salv os com
sucesso: TEL036 - Salv o com sucesso
FlowEnd2
Gerente seleciona linha
Sistema mostra tela de confirmar exclusão: TEL027 - Confirmar
Exclusão
Gerente confirma
Sistema mostra tela de excluido com sucesso: TEL028 - Excluir com
sucesso
FlowEnd3
Sistema mostra tela: TEL003 - Cadastrar projeto
- Listar
End
[Adicionar] [Editar] [Excluir]
Fonte: Elaborado pelos autores do sistema
77
A figura 22 ilustra o fluxo principal e os fluxos alternativos do caso de uso
cadastrar atividades.
Figura 22 - Cadastrar Atividade act US003 - Cadastrar ativ idades_Activ ityGraph
Start
Sistema mostra tela: TEL025 - Login - Gerente
Gerente clica em Gerenciar ativ idades
Alternate1
Gerente seleciona linha
Gerente clica em Excluir selecionado
Sistema mostra tela de confirmar exclusão: TEL027 - Confirmar
Exclusão
Gerente confirma exclusão
Sistema mostra tela de excluido com sucesso: TEL028 - Excluir com
sucesso
FlowEnd1
Gerente seleciona linha
Gerente clica em Editar selecionado
Sistema mostra formulário: TEL005 -
Cadastrar Ativ idades - Editar
Gerente edita dados
Sistema mostra tela de salv o com sucesso: TEL036 - Salv o com
sucesso
FlowEnd2
Gerente clica em Adicionar
Sistema mostra formulário: TEL004 -
Cadastrar ativ idades - Adicionar
Gerente edita dados
Sistema mostra tela de salv o com sucesso: TEL036 - Salvo com
sucesso
FlowEnd3
Sistema lista as ativ idades de um
cronograma selecionado: TEL006 - Cadastrar ativ idades - Listar
End
[Excluir] [Editar] [Adicionar]
Fonte: Elaborado pelos autores do sistema
78
4.2.5 Modelo de Domínio
A figura 23 ilustra o diagrama de domínio do sistema.
Figura 23 - Diagrama de Domínio
Fonte: Elaborado pelos autores do sistema
4.2.6 Diagramas de Robustez
A figura 24 apresenta o Diagrama de Robustez do software.
79
Fonte: Elaborado pelos autores do sistema
4.2.7 Diagramas de Sequência
A figura 25 demonstra o diagrama de sequência de login na aplicação.
Figura 24 - Diagrama de Robustez
80
Fonte: Elaborado pelos autores do sistema
Figura 25 - Diagrama de Sequência - Login
81
A imagem 26 apresenta o diagrama de sequência da ação de cadastrar perfis na
aplicação.
Figura 26 - Cadastrar Perfil
Fonte: Elaborado pelos autores do sistema
A figura 27 apresenta o diagrama de sequência da ação de cadastrar usuário na
aplicação.
82
Figura 27 - Cadastrar Usuário
Fonte: Elaborado pelos autores do sistema
A figura 28 apresenta o diagrama de sequência da ação de cadastrar clientes na
aplicação.
83
Figura 28 - Cadastrar clientes
Fonte: Elaborado pelos autores do sistema
A figura 29 apresenta o diagrama de sequência da emissão de relatórios do
Projector.
84
Figura 29 - Emissão de relatórios
Fonte: Elaborado pelos autores do sistema
A figura 30 ilustra o diagrama de sequência para cadastro de marco dos projetos.
85
Figura 30 - Cadastro de marco
Fonte: Elaborado pelos autores do sistema
A figura 31 demonstra o diagrama de sequência para cadastro de projetos.
86
Figura 31 - Cadastrar projeto
Fonte: Elaborado pelos autores do sistema
A figura 32 apresenta o diagrama de sequência do cadastro de um cronograma.
87
Figura 32 - Cadastro de cronograma
Fonte: Elaborado pelos autores do sistema
A figura 33 apresenta o diagrama de sequência do cadastro das atividades para um
projeto.
88
Figura 33 - Cadastrar atividade
Fonte: Elaborado pelos autores do sistema
A figura 34 ilustra o diagrama de sequência do cadastro de status para um projeto.
89
Figura 34 - Cadastro de status
Fonte: Elaborado pelos autores do sistema
A figura 35 demonstra o diagrama de sequência da atualização de horas de uma
atividade.
90
Figura 35 - Registro de hora da atividade
Fonte: Elaborado pelos autores do sistema
A figura 36 apresenta o diagrama de sequência para a ação de consultar o
andamento de um projeto.
91
Figura 36 - Consultar andamento do projeto
Fonte: Elaborado pelos autores do sistema
4.2.8 Diagrama de Classe
A figura 37 mostra o diagrama de classe do sistema.
92
Figura 37 - Diagrama de Classes
Fonte: Elaborado pelos autores do sistema
4.3 RESUMO DO CAPÍTULO
Nesse capítulo foi apresentada a diferenciação entre técnica e metodologia, os
principais conceitos sobre a UML e seus diagramas mais comuns, uma visão geral do Iconix
citando seus elementos e um embasamento teórico sobre orientação a objetos.
Além desses temas, também foi exposto uma explicação sobre o protótipo
utilizado no estudo de caso e sua modelagem utilizando a UML.
A seção seguinte aborda os detalhes sobre o desenvolvimento da solução proposta
de automatização para os testes do protótipo estudado.
93
5 AUTOMATIZAÇÃO DE TESTES DE SOFTWARE
Nesse capítulo são apresentados os detalhes sobre o desenvolvimento da
automação dos testes do protótipo, contendo uma descrição sobre o sistema envolvido no
estudo de caso.
Nas seções que seguem é descrito o ferramental utilizado no protótipo, bem como
a explicação de seu funcionamento. Posteriormente, serão mostrados os casos de testes
manuais criados para o protótipo incluindo o diagrama dos mesmos.
Após o levantamento das características anteriores, haverá uma explanação sobre
a automação de testes realizada nesse estudo de caso.
Por fim, será apresentada a avaliação dos resultados obtidos.
5.1 SISTEMA DESENVOLVIDO PARA O ESTUDO DE CASO
O protótipo utilizado para o estudo de caso é um sistema web e foi concebido para
gerenciar projetos. Nele são possíveis as ações referentes ao cadastro de projetos, atividades e
cronograma havendo uma associação entre eles.
O sistema possui outras ações como o cadastro de usuários e seus perfis, a
emissão de relatórios gerenciais, o cadastro de marco do projeto e o status.
5.1.1 Tecnologias utilizadas
Para o desenvolvimento do protótipo foi utilizada a linguagem de programação
Java, a implementação web foi concebida, utilizando-se a tecnologia Java Server Faces (JSF),
o banco de dados utilizado foi o MySQL, um framework de persistência chamado Hibernate e
o servidor Apache Tomcat.
94
A seguir, estão descritas as ferramentas utilizadas durante o desenvolvimento.
• Enterprise Architect – Ferramenta de desenvolvimento em UML;
• Eclipse Indigo - Ferramenta utilizada na edição do código fonte da
linguagem de programação (Java, JSF);
• Hibernate – Framework para persistência dos dados;
• Java – Linguagem de programação;
• JSF – Framework para implementação web, baseado em Java;
• MySQL – Banco de dados do protótipo;
• Servidor Tomcat – Servidor utilizado para conexão do sistema via Web.
A figura 38 mostra um desenho esquemático da arquitetura do protótipo Projector.
Figura 38 - Arquitetura do Projector
Fonte: Elaborado pelos autores do sistema
Nas subseções que seguem, estarão descritas as ferramentas utilizadas no
Projector, de maneira mais detalhada.
95
5.1.1.1 Enterprise Architect
De acordo com o Sparx System (2013), a ferramenta Enterprise Architect (EA)
possui os recursos da linguagem UML para criação de modelos na arquitetura de sistemas.
O EA disponibiliza, dentre seus diversos recursos, a modelagem para o ciclo de
vida de softwares e Engenharia de Sistemas, além de gerar relatórios e documentos detalhados
dos projetos.
Com este software foi possível realizar a modelagem do protótipo utilizado para o
estudo de caso e com base nesses modelos a solução foi codificada.
5.1.1.2 Eclipse
O Eclipse é uma ferramenta IDE (Integrated Development Environment), ou seja,
um ambiente integrado para desenvolvimento de software.
5.1.1.3 Hibernate
Segundo o site oficial do Hibernate (2013), o mesmo trata-se de um framework
que permite o desenvolvimento de classes persistentes do sistema.
Ele possui tecnologia Java e efetua o mapeamento de objetos relacionais em
bancos que utilizam linguagem HQL e SQL.
96
5.1.1.4 Java
O Java é uma tecnologia criada pela Sun e, atualmente, pertencente a Oracle.
Segundo o site oficial da Oracle (2013), o Java “é a base de praticamente todos os tipos de
aplicativos em rede, e é o padrão global para desenvolvimento e fornecimento de aplicativos
para celular, jogos, conteúdo on-line e software corporativo”.
5.1.1.5 Java Server Faces
O framework utilizado para o desenvolvimento web foi o JSF (Java Server
Faces), pois é incorporado ao J2EE (Java 2 Enterprise Edition), onde é possível o
desenvolvimento na linguagem Java.
5.1.1.6 MySQL
O sistema para gerenciamento de banco de dados utilizado foi o MySQL
Enterprise Edition. Ele possui código aberto e fornece todo apoio à linguagem SQL e modelo
Entidade-Relacionamento.
Segundo o site oficial (2013), esse produto inclui o mais completo conjunto de
funcionalidades avançadas, ferramentas de gestão e apoio técnico para gerenciamento de
banco de dados.
97
5.1.1.7 Apache Tomcat
O Tomcat, de acordo com seu site oficial (2013), é uma ferramenta de código
aberto para servir de container às tecnologias Java Servlet e Java Server Pages.
No caso do protótipo Projector, o Tomcat foi o servidor web HTTP do mesmo.
5.1.2 Descrição do sistema
O Projector é um protótipo para gerenciamento de projetos. Suas principais
funcionalidades são:
• Cadastro de Projeto – o usuário pode cadastrar, editar ou excluir um
projeto. Os campos disponíveis para o cadastro são: nome, o gerente
responsável, a data de entrega, a data prevista para conclusão, o cliente e o
status conforme demonstra a figura 39.
Figura 39 - Cadastrar projeto no Projector
Fonte: Elaborado pelos autores do sistema Projector
• Na imagem 40 é possível visualizar a tela de listagem dos projetos, onde são encontradas informações do nome do projeto, o gerente, a data de entrega e data prevista, o cliente e o status em que o mesmo se encontra.
98
Figura 40 - Listagem de projetos no Projector
Fonte: Elaborado pelos autores do sistema Projector
• Cadastro de Cronograma – Nessa etapa é possível selecionar um projeto e
adicionar um comentário. Com isso, o cronograma fica associado ao
projeto.
A figura 41 apresenta a tela desse processo.
Figura 41 - Cadastro de cronograma no Projector
Fonte: Elaborado pelos autores do sistema Projector
99
• Cadastro de Atividade – Cada projeto pode possuir uma ou mais atividades
associadas. Os campos do cadastro são: o cronograma, o título, uma
descrição, a data inicial e final e o responsável.
A imagem 42 mostra a tela desse funcionamento.
Figura 42 - Cadastro de atividade no Projector
Fonte: Elaborado pelos autores do sistema Projector
• Na figura 43 é possível visualizar a tela de listagem das atividades, podendo editar e excluir as mesmas. Na listagem é apresentado o título da atividade, uma descrição, o responsável, a data inicial e final, o progresso atual, a quantidade de horas gastas e o status da mesma.
Figura 43 - Listagem das atividades no Projector
100
Fonte: Elaborado pelos autores do sistema Projector
As informações a respeito do responsável pelas atividades e do cliente que cada
projeto possui são inseridas na base de dados, não havendo, portanto, uma interface para o
cadastro das mesmas.
5.2 CASOS DE TESTE
Os casos de teste manuais foram criados com base nas principais funcionalidades
do Projector. Foram analisados casos de uso, diagrama de sequência e as regras de negócio do
sistema e a partir dos mesmos criaram-se os testes de regressão.
Nas subseções que seguem, serão apresentados: o método utilizado para a criação
dos casos de teste, o ferramental escolhido para apoiar e uma modelagem dos casos de teste.
5.2.1 Método
Foi feito um estudo do sistema com base na modelagem do mesmo. A partir disto,
elaborou-se um teste de regressão para cada uma das seguintes funcionalidades:
• Cadastrar, editar e excluir projeto;
• Cadastrar um projeto selecionando um cliente;
• Cadastrar cronograma;
• Cadastrar atividade preenchendo apenas campos obrigatórios;
• Cadastrar atividade preenchendo, além dos campos obrigatórios, o
cronograma;
• Cadastrar atividade com todos os campos;
• Efetuar login com um usuário válido para o sistema;
101
A figura 44 demonstra um fluxograma com as etapas envolvidas na elaboração
dos casos de teste de regressão.
Figura 44 - Fluxograma da elaboração do teste
Fonte: Elaborado pelos autores
Esses testes de regressão foram feitos a partir da interface do protótipo e
documentados. O documento contém uma breve descrição do teste, os casos de teste que
serão executados para cada funcionalidade e o resultado esperado. Esse arquivo serve de
roteiro para a execução do teste manual e será utilizado como regra para a automação.
102
5.2.2 Ferramentas utilizadas
O Enterprise Architect serviu como apoio para a visualização da modelagem do
protótipo Projector e a partir dela foi possível elaborar as rotinas para teste.
Na criação do roteiro para o teste manual utilizou-se a ferramenta Microsoft
Office Word versão 2010, que de acordo com seu site oficial (2013), trata-se de “um
processador de texto que apresenta um conjunto de recursos”. A partir dele, foi gerado um
documento de texto contendo as informações pertinentes à rotina de teste.
5.2.3 Roteiro de teste
Para execução do teste manual elaborou-se um roteiro contendo a quantidade de
dez casos de teste, conforme apresentados nas seções seguintes.
5.2.3.1 Teste Salvar Projeto
O Teste de salvar projeto consiste em efetuar login no sistema, cadastrar um novo
projeto preenchendo apenas os campos obrigatórios e verificar se o projeto cadastrado é
listado na grid de projetos cadastrados. Seguem os passos para sua execução:
1) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
2) Logar com o usuário administrador do sistema, (Login: root e senha:
root);
3) Acessar o menu “Gerenciar Projetos”;
4) Clicar no item menu “Cadastrar”;
5) Preencher os campos obrigatórios “Nome” e “Data Prevista”;
103
6) Clicar no botão salvar;
7) Clicar no botão continuar na tela de feedback do cadastro;
8) Verificar projeto exibido na grid;
9) Apagar dados na base de teste.
5.2.3.2 Teste salvar projeto com cliente
O Teste para salvar projeto inserindo um cliente consiste em efetuar login no
sistema, cadastrar um novo projeto preenchendo os campos obrigatórios e selecionando um
cliente. Após verificar se o projeto cadastrado é listado na grid de projetos cadastrados:
1) Inserir um registro na tabela “cliente”;
2) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
3) Logar com o usuário administrador do sistema, (Login: root e senha:
root);
4) Acessar o menu “Gerenciar Projetos”;
5) Clicar no item menu “Cadastrar”;
6) Preencher os campos obrigatórios “Nome” e “Data Prevista”;
7) Clicar no botão salvar;
8) Clicar no botão continuar na tela de feedback do cadastro;
9) Verificar projeto exibido na grid;
10) Apagar dados na base de teste.
5.2.3.3 Teste editar projeto
O teste de editar um projeto consiste em inserir um registro na tabela “projeto”,
efetuar login no sistema, editar projeto cadastrado na base de dados através da interface do
104
sistema, alterar apenas os campos obrigatórios e verificar se o projeto editado é listado na grid
corretamente.
1) Inserir registro na base de dados na tabela “projeto”;
2) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
3) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
4) Acessar o menu “Gerenciar Projetos”;
5) Clicar no item menu “Listar”;
6) Selecionar o projeto que foi inserido na base de dados na grid;
7) Clicar no botão “Editar Selecionado”;
8) Alterar e preencher os campos obrigatórios “Nome” e “Data Prevista”;
9) Clicar no botão salvar;
10) Clicar no botão continuar na tela de feedback do cadastro;
11) Verificar se o projeto editado é exibido na grid;
12) Apagar dados na base de teste.
5.2.3.4 Teste excluir projeto
O teste de exclusão de um projeto consiste em inserir um registro na tabela
“projeto”, efetuar login no sistema, excluir projeto cadastrado na base de dados através da
interface do sistema e verificar se o projeto excluído não é listado na grid.
1) Inserir registro na base de dados na tabela “projeto”;
2) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
3) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
4) Acessar o menu “Gerenciar Projetos”;
5) Clicar no item menu “Listar”;
6) Selecionar o projeto que foi inserido na base de dados na grid;
105
7) Clicar no botão “Excluir Selecionado”;
8) Clicar no botão “Sim” da tela de confirmação de exclusão de projetos;
9) Visualizar mensagem de exclusão do projeto;
10) Verificar se o projeto excluído não está sendo exibido na grid.
5.2.3.5 Teste cadastrar atividade
O teste de cadastrar atividade consiste em efetuar login no sistema, cadastrar uma
nova atividade preenchendo apenas os campos obrigatórios e verificar se a atividade
cadastrada é listada na grid de atividades cadastradas.
1) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
2) Logar com o usuário administrador do sistema, (Login: root e senha: root);
3) Acessar o menu “Gerenciar Atividades”;
4) Clicar no item menu “Cadastrar”;
5) Preencher os campos obrigatórios “Título”, “Descrição”, “Data inicial” e
“Data Final”;
6) Clicar no botão salvar;
7) Clicar no botão continuar na tela de feedback do cadastro;
8) Verificar se a atividade está sendo listada na grid de atividades;
9) Apagar dados na base de teste.
5.2.3.6 Teste cadastrar atividade com cronograma
O teste para cadastro de uma atividade inserindo o cronograma consiste em
efetuar login no sistema, cadastrar uma nova atividade preenchendo os campos obrigatórios e
106
selecionando um cronograma. Após verificar se a atividade cadastrada é listada na grid de
atividades cadastradas:
1) Inserir registro na base de dados na tabela “cronograma”;
2) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
3) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
4) Acessar o menu “Gerenciar Atividades”;
5) Clicar no item menu “Cadastrar”;
6) Selecionar cronograma inserido na base de dados;
7) Preencher os campos obrigatórios “Título”, “Descrição”, “Data inicial” e
“Data Final”;
8) Clicar no botão salvar;
9) Clicar no botão continuar na tela de feedback do cadastro;
10) Verificar se a atividade está sendo listada na grid de atividades;
11) Apagar dados na base de teste.
5.2.3.7 Teste cadastrar atividade completo
O teste de cadastro de atividade preenchendo todos os campos consiste em efetuar
login no sistema, cadastrar uma nova atividade preenchendo os campos obrigatórios,
selecionando um cronograma e selecionando um responsável. Em seguida, verificar se a
atividade cadastrada é listada na grid de atividades cadastradas.
1) Inserir registro na base de dados na tabela “cronograma”;
2) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
3) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
4) Acessar o menu “Gerenciar Atividades”;
5) Clicar no item menu “Cadastrar”;
6) Selecionar cronograma inserido na base de dados;
107
7) Preencher os campos obrigatórios “Título”, “Descrição”, “Data inicial” e
“Data Final”;
8) Selecionar um responsável;
9) Clicar no botão salvar;
10) Clicar no botão continuar na tela de feedback do cadastro;
11) Verificar se a atividade está sendo listada na grid de atividades;
12) Apagar dados na base de teste.
5.2.3.8 Teste de efetuar login com usuário válido
O teste para efetuar login com um usuário válido baseia-se em entrar no sistema
com o usuário administrador do mesmo, através dos seguintes passos:
1) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
2) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
3) Verificar se o login foi válido.
5.2.3.9 Teste de efetuar login com usuário inválido
O teste para efetuar login com um usuário inválido consiste em tentar entrar no
sistema inserindo dados incorretos no login, através dos seguintes passos:
1) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
2) Logar com um usuário incorreto, (Login: usuario e senha: usuario);
3) Verificar se apresenta mensagem de login inválido.
108
5.2.3.10 Teste de salvar cronograma
O teste para salvar um cronograma consiste em efetuar login no sistema, cadastrar
um novo cronograma preenchendo apenas os campos obrigatórios e verificar se a tela
principal do sistema é exibida. Seguem os passos para sua execução:
1) Acessar aplicação através do navegador Chrome -
http://localhost:8080/Projector/login.jsf;
2) Logar com o usuário administrador do sistema , (Login: root e senha:
root);
3) Acessar o menu “Gerenciar Cronograma”;
4) Clicar no item menu “Cadastrar”;
5) Preencher os campo obrigatório “Comentários”;
6) Clicar no botão salvar;
7) Clicar no botão continuar na tela de feedback do cadastro;
8) Verificar se a tela principal do sistema é exibida;
9) Apagar dados na base de teste.
5.3 AUTOMATIZAÇÃO DE TESTES
O Selenium, de acordo com seu site oficial (2013), “é um conjunto de ferramentas
para automatizar navegadores em várias plataformas”. É um framework gratuito e suporta
diversas linguagens de programação, dentre elas: Java, PHP, Phyton, Ruby, e outras.
O Selenium versão 2.0 ou Selenium WebDriver é uma junção da versão 1.0 com a
API3 WebDriver.
A versão do Selenium 1.0 é conhecida como projeto Selenium Remote Control
(RC). Nele é possível escrever testes automatizados de interface de sistemas web em diversas
linguagens de programação, em sites HTTP que utilizam navegadores que possuem Javascript
3 A API (Application Programming Interface), é uma interface com conjunto de padrões de programação que
permite a construção de aplicativos e a sua utilização. (http://www.tecmundo.com.br/programacao/1807-o-que-e-api-.htm)
109
mainstream. Abaixo, na figura 45, é apresentada a estrutura de funcionamento dessa
ferramenta.
Figura 45 - Funcionamento Selenium RC
Fonte: Site Oficial do Selenium (2013)
Como mostrou a figura 45, o Selenium versão 1.0 é dividido em duas partes
principais:
1. Um servidor que inicia automaticamente e atua como um proxy HTTP para
solicitações da Web a partir deles;
2. Bibliotecas para utilização em diversas linguagens para diferentes tipos de
navegadores.
110
O Selenium versão 2.0 surgiu com o objetivo de incorporar junto ao navegador
suporte à automatização de teste, onde não é preciso haver um servidor que atue como proxy
HTTP.
Foi adicionada uma biblioteca WebDriver junto ao Selenium 1.0 para que o
navegador ficasse responsável em dar suporte à automatização de teste. Com essa junção
surgiu o projeto Selenium versão 2.0 ou Selenium WebDriver.
De acordo com o site oficial (2013), “dirigir um navegador de forma nativa como
um usuário local ou em uma máquina remota usando o Selenium servidor marca um salto em
frente em termos de automação de browsers”.
“[...] A integração da API WebDriver é projetada para fornecer uma interface de programação simples, mais concisa, além de abordar algumas limitações na API do Selenium-RC. Selenium-WebDriver foi desenvolvido para melhor e apoiar páginas web dinâmicas, onde os elementos de uma página podem ser alteradas sem a própria página que está sendo recarregada. O objetivo do WebDriver é fornecer uma API orientada a objeto bem projetada que fornece suporte melhorado para os modernos problemas avançados de testes web-app”. (Site Oficial, tradução nossa, 2013).
O Selenium-WebDriver faz chamadas diretas para o navegador usando o suporte
nativo de cada um para automação. Na linguagem de programação Java, utilizam-se classes
de aplicação específicas para cada navegador ou plataforma, sendo necessário o uso da
interface WebDriver. Segue a descrição de algumas dessas classes:
• AndroidDriver – Classe específica para a plataforma móvel Android;
• ChromeDriver – Classe para o navegador Google Chrome;
• EventFiringWebDriver – Wrapper que suporta registrar uma
WebDriverEventListener;
• FirefoxDriver - Utilizado para o navegador Mozilla Firefox;
• HtmlUnitDriver - Implementação do WebDriver baseado no framework
HtmlUnit para aplicações web de teste;
• InternetExplorerDriver - Utilizado para o navegador Internet Explorer;
• IPhoneDriver – Classe para a plataforma móvel IOS da Apple;
• PhantomJSDriver - Fornece uma maneira de acessar PhantomJS para
executar os testes através da criação de uma instância PhantomJSDriver;
• RemoteWebDriver – Implementação do WebDriver Remoto;
• SafariDriver - Utilizado para o navegador Safari.
111
A figura 46 representa um exemplo de codificação do WebDriver na linguagem
Java.
Figura 46 - Exemplo WebDriver em Java
Fonte: Site oficial do Selenium, 2013
Conforme o exemplo acima, primeiro é necessário criar a instância do WebDriver
do navegador. Nesse caso, utilizou-se o Mozilla Firefox, com ela criada é possível acessar
uma página web através do método “get” do controlador. Após o acesso da página é possível
encontrar elementos da página utilizando o método “findElement” do controlador em
112
conjunto com a interface “By”. Encontrado o elemento, é possível enviar textos através do
método sendKeys da interface WebElement. Com a interface WebDriverWait é possível
estipular um tempo para aguardar a condição desejada. É possível exibir título da página a
partir do controlador e, por fim, fechar o browser através do método “quit”.
5.3.1 Ferramentas utilizadas
As ferramentas utilizadas na automatização dos testes foram as mesmas citadas na
seção 5.1.1. Além dessas, foi utilizado um plugin para o navegador Mozilla Firefox, o
Selenium IDE, outro plugin chamado FireBug, onde é possível inspecionar componentes web
com a intenção de descobrir a estrutura do componente para conseguir efetuar a manipulação
com o Selenium, utilizou-se o WebDriver do Google Chrome e o JUnit como framework para
executar a automação.
5.3.2 Automação dos casos de teste
Para elaborar e desenvolver os casos de testes automatizados foi necessário
efetuar estudos e análises nos casos de uso do sistema Projector e no framework Selenium.
Após essas análises, foi possível implementar uma base do projeto de automação,
optando-se por utilizar frameworks e APIs gratuitas como forma de suprir as necessidades que
surgiram com a integração juntamente ao Projector. Os frameworks escolhidos foram:
• JPA;
• Hibernate;
• JUnit;
• WebDriver.
113
O projeto base da automação tem como objetivo auditar os logs de teste,
estabelecer conexões com o banco de dados, gerenciar o EntityManager e executar sua rotina
de teste através do framework JUnit.
Na figura 47, é apresentada a estrutura hierárquica do projeto de automação
denominado “Automacao”; nela é exibida a relação com o protótipo Projector.
Figura 47 - Pacote de entidades
Fonte: Elaborado pelos autores, 2013.
Conforme exibido na figura acima, o pacote “br.com.projector.entities” utiliza o
framework Hibernate que é responsável por efetuar o mapeamento dos atributos para o
modelo relacional da aplicação Projector. Sendo assim, é possível com o projeto da
automação criar, manipular e excluir objetos que representam as entidades do Projector.
Na figura 48, é exibida a estrutura base do projeto de automação que gerencia e
configura uma seção de teste. Nessa figura, pode-se observar que o pacote “br.com.tcc.core”
contém as classes responsáveis em criar toda a infraestrutura da automação. A classe
“TestRunner.java” é a principal desse pacote, pois através dela é possível executar o caso de
teste sobrescrevendo o método “testRunner” da super classe “Runner” que pertence ao
framework JUnit. Essa classe também é responsável por configurar o ambiente de teste,
executar os testes escolhidos pelo usuário, imprimir o log, dentre outras funções.
114
Figura 48 - Pacote core
Fonte: Elaborado pelos autores, 2013.
Com objetivo de facilitar algumas configurações e tornar possível a execução de
mais de um teste, foram criados dois arquivos que auxiliam nesse processo de configuração
dos mesmos.
A partir do arquivo “testeframework.properties” o usuário consegue escolher qual
navegador web deseja executar a automação, o usuário e senha que efetuará o login no
sistema e definição da página principal que é aberta pela automação no browser. O segundo
arquivo chamado “testList.txt” contém o caminho absoluto de cada classe de teste. Com ele é
possível inserir o caminho completo dos testes desenvolvidos, para serem executados na
ordem em que foram escritos no mesmo.
A figura 49 exibe essa estrutura de pacote que contém esses dois arquivos de
configuração.
115
Figura 49 - Arquivos de configuração
Fonte: Elaborado pelos autores, 2013.
Após essa base criada para automação, foi necessário apenas implementar classes
que contém a rotina de testes.
A figura 50 exibe o pacote “br.com.tcc.testcase” que contém rotinas de testes.
116
Figura 50 - Pacote testcase
Fonte: Elaborado pelos autores, 2013.
Para criar uma rotina de teste que será gerenciada pelo projeto base da automação
faz-se necessário seguir a seguinte estrutura:
• A classe de teste deve estender a classe “BaseCasoDeTeste”;
• Implementar os métodos “configure”, “execute” e “cleanup”.
A classe “BaseCasoDeTeste” possui os métodos abstratos “configure”, “execute”
e “cleanup”. Ela é abstrata e utilizada pela classe “TestRunner”. Esta, por sua vez, é a
principal da automação.
Toda classe de teste que herda a classe abstrata é encarregada em implementar
esse três métodos, os quais devem ser desenvolvidos com os seguintes conceitos:
• Método configure: Nesse método deve-se efetuar toda a configuração do
ambiente para o caso de teste, como, por exemplo, popular uma entidade e
117
persisti-la na base de dados, a partir disto é possível manipular esse objeto
na execução de um caso de teste;
• Método execute: Nesse método é necessário executar toda a rotina de teste.
Nele todas as interações com a interface do sistema precisam ser
desenvolvidas;
• Método cleanup: Com esse método é possível limpar todos os dados da
base de dados criados pelo teste que foi executado. Isto se dá através do
Entity Manager, que efetua a remoção desses registros criados pela rotina
do teste.
Para auxiliar e melhor organizar a implementação dos casos de teste, criou-se um
pacote chamado “br.com.tcc.util”, onde é possível criar classes utilitárias dos seus casos de
teste. A figura 51 exibe a estrutura do pacote.
Figura 51 - Pacote util
Fonte: Elaborado pelos autores, 2013.
118
Seguindo os conceitos descritos acima e utilizando a base da automação, foi
possível automatizar os seguintes casos de testes:
• Cadastrar, editar e excluir projeto;
• Cadastrar um projeto selecionando um cliente;
• Cadastrar cronograma;
• Cadastrar atividade preenchendo apenas campos obrigatórios;
• Cadastrar atividade preenchendo, além dos campos obrigatórios, o
cronograma;
• Cadastrar atividade com todos os campos;
• Efetuar login com um usuário válido para o sistema;
• Tentativa de login com usuário inválido no sistema.
Depois de todos os testes automatizados, sua execução é feita a partir do JUnit.
Caso se trate de uma lista de teste, é necessário especificar o caminho do arquivo que será lido
nos argumentos da JVM (Java Virtual Machine), com o comando “-DtestList=
C:\workspace\Automacao\resource\testList.txt”.
5.4 ESTUDO DE CASO
O estudo de caso foi idealizado para comparar a automação de testes de regressão
versus a prática manual. Sabe-se que, quando ocorrem alterações no código-fonte do sistema,
existe a necessidade de um teste de regressão como auxílio na garantia da integridade do
mesmo. Partindo desse princípio, nas seções que seguem, apresentam-se as mudanças feitas
no sistema, a execução do teste automático e manual de regressão, o perfil dos participantes
escolhidos para executar o teste manualmente e os resultados obtidos a partir desses estudos.
119
5.4.1 Bugs inseridos no sistema
Para simular um cenário onde o teste encontra um bug no sistema, foi inserido um
erro propositalmente em uma rotina do protótipo Projector.
Implementou-se uma lógica que altera o fluxo básico do cadastro de uma
atividade preenchendo apenas os campos obrigatórios. O problema consiste em o sistema
informar que a atividade foi cadastrada com sucesso, porém a mesma não é persistida no
banco e tampouco apresentada na interface de listagem das atividades.
A figura 52 apresenta a tela de cadastro de uma atividade onde o usuário
preencheu os campos obrigatórios e clicou no botão “salvar”.
Figura 52 - Cadastro de Atividade
Fonte: Elaborado pelos autores, 2013.
Na figura 53, é possível perceber que apesar da mensagem de “Cadastro efetuado
com sucesso”, o sistema retorna para a tela de cadastro e a listagem não é exibida. O correto
seria apresentar a tela contendo a listagem das atividades.
120
Figura 53 - Cadastro de atividade campos obrigatórios
Fonte: Elaborado pelos autores, 2013.
A figura 54 demonstra a confirmação do bug, onde o usuário acessa a listagem
das atividades para se certificar de que a mesma não foi cadastrada, pois na interface a
atividade cadastrada anteriormente não é apresentada.
Figura 54 - Grid de atividades
Fonte: Elaborado pelos autores, 2013.
121
5.4.2 Seleção dos atores
Para a execução dos testes manuais, foram escolhidas duas pessoas que atuam na
área de teste e qualidade de software. Para o estudo de caso, tratar-se-á com nomes fictícios,
tais como “Testador X” e “Testador Y”.
O Testador X tem 24 anos de idade, possui grau superior incompleto em Ciência
da Computação, atua há três anos, em uma empresa na região da grande Florianópolis, com o
cargo de Analista de Testes e possuindo o papel de Scrum Master de sua equipe.
O Testador Y possui 25 anos de idade, graduação incompleta em um curso de
Telecomunicações, atua há dois anos na área de teste. Atualmente, desempenha o cargo de
Testador na mesma empresa do outro participante.
Ambos aceitaram participar do estudo de caso, permitiram, também, uma
filmagem enquanto executaram os testes manuais, porém para obter sigilo de suas
identidades, seus rostos e nomes não foram apresentados no vídeo, no questionário aplicado e
na presente monografia. Após a confirmação de suas participações, receberam a modelagem e
os casos de teste do Projector para estudo.
O questionário respondido por ambos os participantes encontra-se nos Anexos A e
B, no final do trabalho.
5.4.3 Execução manual dos casos de teste
Para efetuar os testes manuais foram configurados dois computadores que
possuíam o sistema Projector executando localmente, o Enterprise Architect com a
modelagem do mesmo, o MySQL Workbench 5.2 contendo as instruções SQL para execução
do teste e um documento de texto com os casos de teste.
Os dois testadores não sabiam da existência de um bug no protótipo, pois foi o
primeiro contato com a interface do protótipo que tiveram, até então só haviam visualizado os
diagramas da modelagem do Projector e os casos de teste. Eles foram filmados durante a
122
ação, no dia 07 de maio de 2013. O vídeo4 possui dezesseis minutos e oito segundos, e é
possível visualizar todas as ações de testes manuais.
O Testador X executou os testes da maneira correta encontrando um bug no
sistema, conforme previsto. O mesmo seguiu corretamente a sequência de passos do
documento disponibilizado com os casos de teste manuais.
No início do teste, o Testador Y conseguiu executar corretamente os dois
primeiros casos de teste. Através do vídeo, é possível visualizar que o mesmo consulta os
casos de teste a cada ação efetuada na interface do Projector. Entretanto, no terceiro teste, ele
cometeu um equívoco, excluindo o registro na base de dados e depois tentou apagar
novamente o mesmo na interface. Essa ação não seguiu a ordem estipulada no documento dos
casos de teste e devido a isso, o sistema não estava preparado para tratar a sequência
executada pelo Testador Y. Dessa forma, os problemas reportados por ele na verdade tratam-
se de comportamentos que não foram previstos no desenvolvimento do protótipo e tampouco
na elaboração dos casos de teste.
A figura 55 apresenta o início do procedimento, onde os testadores encontram-se
lendo os casos de teste no documento de texto.
4 O vídeo está disponível através de um serviço de armazenamento de arquivos conhecido como Dropbox. Pode
ser visualizado através do link: https://dl.dropboxusercontent.com/u/44381684/TestesManuais.MPG
123
Figura 55 - Início da execução
Fonte: Elaborado pelos autores, 2013.
Na figura 56, é possível perceber o momento em que ambos abrem a aplicação
Projector para iniciar os testes.
124
Figura 56 - Acesso ao sistema
Fonte: Elaborado pelos autores, 2013.
A figura 57 apresenta o momento em que o Testador Y realiza a rotina incorreta
do teste, que desencadeou em resultados inconsistentes no protótipo. A ação ocorreu em um
minuto e trinta e nove segundos após o início dos testes.
125
Figura 57 - Execução incorreta
Fonte: Elaborado pelos autores, 2013.
Na figura 58, é apresentado o momento que o Testador X, posicionado na
esquerda do vídeo, encontrou o bug no teste de “Cadastrar atividade com campos
obrigatórios”. A operação durou doze minutos e treze segundos após o teste ser iniciado.
126
Figura 58 - Detecção do bug pelo Testador X
Fonte: Elaborado pelos autores, 2013.
A figura 59 demonstra o momento em que o Testador X conclui o teste com
duração de quinze minutos e trinta de nove segundos após o início da rotina de execução.
127
Figura 59 - Testador X finaliza o teste
Fonte: Elaborado pelos autores, 2013.
A figura 60 mostra o momento em que o Testador Y finaliza seu teste, que
ocorreu em dezesseis minutos e oito segundos após o início da rotina de teste manual.
128
Figura 60 - Testador Y conclui o teste manual
Fonte: Elaborado pelos autores, 2013.
5.4.4 Execução automatizada dos casos de teste
A execução dos testes automatizados deu-se através da ferramenta Eclipse. Foram
executados dez testes em sequência utilizando a opção de execução em lista, que foi explicado
na seção 5.2.3. O tempo total gasto na execução do teste foi de dois minutos e quarenta e três
segundos. Ao final, foi gerado um log no navegador com o resultado para cada teste
juntamente com a captura da tela no momento em que se efetua a validação do mesmo.
Existem duas classificações de resultado. Assim, cada teste pode ser definido em:
• Passou: Quando o caso de teste automatizado atendeu a rotina desejada
e não foram encontrados bugs na funcionalidade.
129
• Falhou: Quando o caso de teste automatizado encontrou algum
problema em sua execução. Caso ocorra um problema, o caso de teste
trata a execução do mesmo como um bug do sistema.
Através do resultado exibido no fim do teste, tornou-se possível verificar a
classificação de cada teste, sendo possível identificar problemas em sua execução.
Com base nesse resultado, identificou-se um bug no “Teste Cadastrar Atividade”.
O erro ocorreu na validação da rotina de teste, pois a mesma necessitava da confirmação do
cadastro da atividade. Essa validação não foi positiva após seu cadastro, uma vez que a
atividade cadastrada deveria ser exibida na tela de listagem das atividades. Sendo assim, a
execução da rotina de teste obteve um problema.
A fim de exibir a execução da automação, foi gravado um vídeo5 com duração de
três minutos e vinte e oito segundos, que expõe a execução da lista de teste. Nele é possível
garantir a integridade da automação, pois se consegue visualizar o notebook e mouse em que o
roteiro de teste foi executado.
A figura 61 exibe o início da execução da automação.
Figura 61 - Início da execução automatizada
Fonte: Elaborado pelos autores, 2013.
5 O vídeo está disponível no Dropbox através do link:
https://dl.dropboxusercontent.com/u/44381684/ExecucaoAutomacao2.AVI
130
Após a execução através da ferramenta Eclipse, uma instância do navegador é
carregada, nela o Selenium WebDriver acessa a página principal do sistema Projector,
conforme visualizado na figura 62.
Figura 62 – Abertura automática no navegador
Fonte: Elaborado pelos autores, 2013.
Aos vinte e dois segundos do vídeo é possível visualizar o Selenium WebDriver
acessando e interagindo com o componente Calendário do framework JSF.
A figura 63 apresenta o momento dessa interação.
131
Figura 63 - Componente calendário
Fonte: Elaborado pelos autores, 2013.
A figura 64 exibe o momento em que a automação executa o teste que contém o
bug. Nela o Selenium WebDriver executa a ação que salva o cadastro do
“TesteSalvarAtividade” e efetua a validação do mesmo, aguardando a listagem que contém as
atividades. A automação executa essa rotina no período de um minuto e vinte e nove
segundos após o início da gravação.
132
Figura 64 - Automação encontra bug
Fonte: Elaborado pelos autores, 2013.
Mesmo após uma rotina de teste falhar a automação continua executando os
próximos casos de teste.
A figura 65 exibe o “TesteSalvarCronograma”, o mesmo é um teste subsequente
ao que contém o bug.
Figura 65 - Teste automatizado de salvar cronograma
Fonte: Elaborado pelos autores, 2013.
133
Nota-se que no período de dois minutos e quarenta e sete segundos a execução de
teste chega ao fim.
A figura 66 exibe esse momento.
Figura 66 - Fim do teste automatizado
Fonte: Elaborado pelos autores, 2013.
Após toda execução do teste automatizado é exibido o resultado de cada rotina
executada.
A figura 67 exibe o log do primeiro caso de teste executado, seu status “Passou”
informa que o teste foi executado com sucesso e nenhum bug foi detectado no mesmo.
134
Figura 67 - Log da automação
Fonte: Elaborado pelos autores, 2013.
Na figura 68 é possível visualizar o log do “TesteCadastrarAtividade” que contém
o status “Falhou”, ou seja, houve um problema na execução da rotina. Esse problema foi
tratado como bug pela automação. Nela é possível visualizar a captura da tela no momento em
que o Selenium WebDriver aguarda que a listagem das atividades seja exibida com o registro
da mesma.
135
Figura 68 - Log da automação apresentando o bug
Fonte: Elaborado pelos autores, 2013.
Por fim, foi possível verificar que a automação conseguiu interagir de forma
prática e rápida com o sistema Projector, a execução da rotina de teste foi um sucesso e o bug
previsto no sistema foi detectado pela automação.
5.4.5 Resultados obtidos
Os resultados foram obtidos com base em três fatores que seguem.
1. Elaboração e execução dos testes manuais;
2. Respostas do questionário aplicado;
3. Automatização dos testes e execução dos mesmos.
Os dados foram levantados a partir da filmagem de ambos os testes, onde foram
analisados o tempo decorrido em cada execução, a comparação dos resultados nos dois casos
e a eficácia na execução dos mesmos.
As respostas do questionário contribuíram para obter as percepções dos
envolvidos no teste manual.
136
O quadro 03 apresenta a comparação entre as duas situações.
Quadro 3 - Comparações entre manual e automatizado
Métricas Teste Manual Teste Automatizado
Tempo gasto para elaboração 6 horas 32 horas
Tempo de Execução 16:08:00 02:43:00
Eficácia do Teste Bom Ótimo
Quantidade de Bugs encontrados
Testador X: 1 bug Testador Y: 3 bugs
1 bug
Tempo gasto no estudo do Projector pelos testadores
4 horas Não se aplica
Total de horas 10:16:08 32:02:43
Fonte: Elaborado pelos autores, 2013.
O tempo gasto na elaboração do teste manual envolve quatro horas no estudo da
modelagem mais duas horas para escrever os casos de teste.
O tempo gasto na criação do teste automatizado compreende as quatro horas de
estudo da modelagem, vinte horas para desenvolvimento da estrutura básica do projeto de
automação, seis horas para implementação dos casos de teste automatizados e duas horas para
escrever o documento de texto que contém os casos de testes.
Os resultados foram coletados através do questionário contendo a percepção dos
envolvidos e a análise feita pelos autores da presente monografia. Com isso, foi possível
definir a eficácia e eficiência do teste. Para correlacionar, ambas foram utilizadas quatro
métricas de avaliação, são elas:
� Ruim: Nesse caso o teste foi mal sucedido, ou por falta de compreensão do
mesmo, ou por possíveis falhas na execução do teste;
� Regular: Foi atendido parcialmente o escopo de teste previsto;
� Bom: O escopo de teste foi atendido, mas com alguma falha na sua
execução;
� Ótimo: Escopo de teste foi totalmente atendido.
137
Com base na tabela, a próxima seção aborda as avaliações dos resultados.
5.5 AVALIAÇÃO DOS RESULTADOS
Conforme quadro 3, pode-se perceber uma discrepância no tempo de execução
dos dois testes. Analisando a tabela, o tempo total gasto incluindo o estudo, construção e
desenvolvimento da automatização foi de trinta e duas horas e dois minutos, já a execução e
elaboração do teste manual foi de dez horas e dezesseis minutos.
Comparando as duas situações, em primeiro momento, o teste manual apresenta
menor tempo para chegar ao seu objetivo de um teste de regressão. Porém, sempre que houver
mudanças no código-fonte do sistema, será necessário executar outra bateria de testes para
garantir qualidade e integridade do mesmo.
Na situação do estudo de caso onde se envolveu dois profissionais na área, em
situações que houvesse a necessidade de mais bateria de testes de regressão, os mesmos
resultados, diferenças de experiência e execução diferente continuariam a existir. Como o
teste manual é executado por seres humanos, dificilmente há cem por cento de garantia na sua
execução. Em contra partida, após o desenvolvimento da automação, o mesmo teste sempre
será executado. O tempo de sua execução sempre será o mesmo e existe a garantia de que a
bateria de teste está sendo executada corretamente.
Em situações da necessidade de execução de mais baterias de teste, a automação
tem menos custo que o teste manual. O teste manual tem gastos com a hora do profissional
que executa e valida o teste, tem um tempo maior para ser desempenhado e não possui cem
por cento de garantia de teste. A automação tem um custo maior no início para ser
desenvolvida, porém o custo dela é apenas com manutenção. Seu tempo de execução é
sempre menor que o tempo de execução manual.
O quadro 04 apresenta um levantamento das vantagens e desvantagens
encontradas na execução do teste automatizado.
138
Quadro 4 - Prós e contras da automação Teste Automatizado
Prós Contras
Tempo de execução Investimentos iniciais
Quantidade de repetições Manutenções
Agilidade na detecção de bugs Não é tão abrangente quanto o manual
Garantia na execução correta do roteiro do teste Menor percepção de bugs
Fonte: Elaborado pelos autores, 2013.
Conforme o quadro 04, levantou-se como vantagens o tempo curto na execução
do teste, a quantidade de repetições, a agilidade na detecção do bug, pois a automação executa
a sequência definida na sua implementação.
Como desvantagem dessa prática, existem manutenções no caso de teste, caso
haja mudanças no sistema. Os investimentos iniciais podem ser altos, uma vez que depende
de um estudo da linguagem utilizada na automação e de tempo no desenvolvimento de seu
código-fonte. Algumas questões sobre usabilidade da interface são melhor percebidas em
testes manuais, já que a automação executa um roteiro pré-definido e não se atenta a questões
de qualidade do software.
Quadro 5 - Prós e contras do teste manual Teste Manual
Prós Contras
Abrangência do teste Maiores investimentos
Melhores análises de usabilidade Desgastes na execução do mesmo teste
Maiores validações dos bugs Tempo de execução é alto
Grandes percepções de bugs Não há 100% de garantia no teste
Fonte: Elaborado pelos autores, 2013.
Conforme o quadro 05, levantou-se como vantagens a abrangência que o teste
manual pode alcançar, pois é possível verificar a usabilidade do sistema, por exemplo, que no
caso da automação isso não é possível e a validação de bugs já encontrados previamente. As
desvantagens encontradas foram os investimentos em pessoas capacitadas para execução
manual dos testes, o desgaste que há na execução dos mesmos pois, há diversas repetições das
rotinas de teste durante o processo de homologação, o tempo de execução é mais alto que o da
automação, uma vez que depende de matéria humana para ser executado e não há uma total
garantia de que o teste foi executado conforme o esperado.
Nesse estudo de caso, a automação, a partir do framework Selenium, foi a solução
mais adequada, pois se verificou que com os testes manuais houve erros na execução
139
realizada por um dos participantes e esse é um fato que pode ocorrer com frequência em uma
equipe de teste. A automação garantiu a eficiência e eficácia do teste, pois detectou o bug em
menor tempo e executou a lista em um período menor que o teste manual.
140
6 CONCLUSÕES E TRABALHOS FUTUROS
Para atender o estudo de caso foi necessário criar e aplicar os testes manuais e
automatizados, utilizando como base um protótipo de um sistema web. Com base nisso, foram
levantadas as conclusões da presente monografia, bem como sugestões de trabalho futuros.
6.1 CONCLUSÕES
Qualquer alteração que ocorra no desenvolvimento de um sistema, faz-se
necessário a aplicação de um teste de regressão como forma de minimizar problemas que
venham a ser encontrados pelo usuário final. Esses testes, dependendo do tamanho do
sistema, podem ser onerosos tanto para quem irá executar quanto para a empresa que terá um
custo com o tempo gasto em tal tarefa.
Na tentativa de diminuir os custos e esforços, foi aplicado um estudo de caso que
visa encontrar um método de teste que realize o mesmo trabalho de maneira rápida e precisa.
Isso se deu através da automatização dos testes de regressão utilizando o framework
Selenium. A partir desse estudo, aplicaram-se os mesmos testes de regressão de forma manual
e automática, comparando os resultados obtidos em ambos.
Notou-se que na execução manual houve falhas humanas que comprometeram o
resultado final bem como a qualidade e eficácia do teste. Executando o teste automatizado, os
esforços e custos foram superados, uma vez que a automação executa o mesmo teste de forma
rápida e consegue garantir uma precisão maior.
Os custos da automação são maiores na sua fase de implantação, por causa de
estudos do framework e o próprio desenvolvimento, porém é possível reverter esses custos.
Os testes automatizados não possuem limites de execução depois de desenvolvidos. Pode-se
aplicar essa rotina de teste quantas vezes forem necessárias, já que o teste manual cada vez
que é executado, possui um custo de tempo e esforço. Com isso, o custo da automação
torna-se menor em comparação ao teste manual.
141
Em casos de mudanças na aplicação a ser testada, existe um custo adicional para
automação, pois se faz necessário a manutenção do mesmo. Contudo, esses custos não
superam os custos da aplicação de testes manuais, já que a execução automatizada é mais
rápida e economiza tempo e esforços em testes repetitivos.
Utilizando o framework Selenium, foi possível atender ao estudo de caso, uma
vez que o mesmo possui uma documentação completa em seu site oficial e também possui
uma comunidade ativa na internet, tornando fácil sua implantação. Por ser um software livres
não há custos para sua utilização. Isso foi possível através do mesmo diminuir o tempo de
execuções de testes, obter repetições na execução dos mesmos, ser ágil na detecção de bugs e
garantir a execução correta do roteiro de teste.
A aplicação do teste automático é abrangente, pois se consegue capturar bugs de
forma mais precisa, agindo como ferramenta de auxílio na qualidade de um software. Sua
manutenção não é algo complexo e os desenvolvimentos de novos casos de teste seguem o
mesmo caminho de testes já implementados. Ao contrário do ser humano, a automação
consegue executar atividades repetitivas sem que haja oneração e cansaço na execução dos
mesmos. Com isso os testadores podem se dedicar a atividades de análise as tarefas que
envolvam análises e reflexões.
6.2 TRABALHOS FUTUROS
Para a presente monografia foi apresentado um estudo de caso de teste de
regressão que foram executados manual e automaticamente. Após a automação, podem ser
abertas diversas vertentes para estudos futuros.
Existem outros tipos de teste que pode ser aplicada a automação; porém, nesse
estudo de caso utilizou-se o de regressão.
Sugere-se, também, que se desenvolva a criação de logs mais específicos para o
teste, onde a cada ação executada pela automação seja auditada, bem como logs mais
detalhados dos erros encontrados, e que se aplique o framework Selenium com outras
linguagens de programação, utilizando outros navegadores além do Google Chrome. E para
finalizar, que seja implantada a automação em uma empresa como forma de analisar seus
resultados no cotidiano organizacional.
142
REFERÊNCIAS
AMBLER, Scott W. Modelagem ágil: Práticas eficazes para a programação extrema e o processo unificado. Porto Alegre: Bookman, 2004. APACHE TOMCAT. Apache Tomcat. Disponível em: <http://tomcat.apache.org/> Acesso em: 22 abr. 2013 ASTELS, David; MILLER, Granville; NOVAK Miroslav. Extreme Programming: guia prático. Rio de Janeiro: Campus, 2002. BARTIÉ, Alexandre. Garantia da qualidade de software: As melhores práticas de Engenharia de Software aplicadas à sua empresa. Rio de Janeiro: Campus, 2002. BASTOS, Anderson et al. Base de conhecimento em teste de software. 2. ed. São Paulo: Martins, 2007. BELL, Donald. UML basics: An introduction to the Unified Modeling Language. 2003. Disponível em: <http://www.ibm.com/developerworks/rational/library/769.html>. Acesso em: 21 mai. 2011. BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML. Rio de Janeiro: Campus, 2002. BINDER, R. V. Testing Object-Oriented Systems: Models, Patterns, and Tools. 1ª Ed. Massachusetts: Addison Wesley, 1999. BLACK, Rex. Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional. John Wiley & Sons. 2007. BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML 2. 2. Ed. Rio de Janeiro: Campus, 2006. CASIMIRO, Rebeca. Fundamentos de Teste de Software. 2011. Disponível em: <http://pt.scribd.com/doc/54571508/Fundamentos-de-Teste-de-Software>. Acesso em: 16 ago. 2012. DEEK, F. P.; MCHUGH, J. A.; ELJABIRI, O. M. Strategic software engineering: an
interdisciplinary approach. Auerbach, 2005, pp.173-188.
DELAMARO, Márcio Eduardo; JINO, Mario; MALDONADO, Carlos José. Introdução do Teste de Software. Rio de Janeiro: Elsevier, 2007. DUSTIN, Elfried. Effective Software Testing: 50 Specific Ways to Improve Your Testing. Addison Wesley Professional; 1 st edition, 2002.
143
ERIKSSON, Hans-Erik; PENKER, Magnus. Business Modeling with UML. Estados Unidos: Wiley & Sons, 2000. 459p. FACHIN, Odília. Fundamentos de metodologia. 3. ed. São Paulo: Saraiva, 2001. FAYAD, M. E.; Schimidt & D. C.; Johnson, R. E. Implementing application frameworks: object-oriented frameworks at work. New York: J. Wiley, 1999. FERNANDES, Ricardo Silva Melo. Automação de Testes Baseada em Palavras-Chave Utilizando a Ferramenta Rational Functional Tester. 2006. 50 p. Trabalho de Conclusão de Curso – Universidade Federal de Pernambuco, Recife. FURLAN, José David. Modelagem de objetos através da UML. São Paulo: Makron Books,1998 GALLIANO, A. G. O método científico: teoria e prática. São Paulo: Harbra, 1986.
GARCIA, E. A. C. Manual de sistematização e normalização de documentos técnicos.São Paulo: Atlas, 1998. GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999
GÓIS, Francisco Nauber Bernardo, OLIVEIRA, Rafael Braga de, FARIAS, Pedro Porfírio Muniz. Desenvolvimento de Software Utilizando Integração Contínua. ERCEMAPI 2007 - Escola Regional de Computação - Ceará Maranhão – Piauí. GUIMARÃES, Gabriel; MEDEIROS, Rodrigo; ROSSINI, Tiago; SILVA, George; SILVA, Gilbert. Utilizando ICONIX no desenvolvimento de aplicações delphi. In: CONGRESSO DE PESQUISA E INOVAÇÃO DA REDE NORTE NORDESTE DE EDUCAÇÃO TECNOLÓGICA, 2., 2007, João Pessoa. Anais eletrônicos... Disponível em: <http://www.redenet.edu.br/publicacoes/publicacoes.php?tipo=1&area2=Inform%E1tica#>. Acesso em: 20 maio 2011.
HETZEL, Willian. Guia completo ao teste de software. Rio de Janeiro: Campus, 1987. HIBERNATE. Por que o Hibernate. disponível em: <http://www.hibernate.org/about/why-
hibernate> Acesso em 22 de abril de 2013.
IEEE. IEEE standard glossary of software engineering terminology. Standard 610.12,
IEEE Computer Society Press, 1990
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD. Base de conhecimento para certificação em teste. Versão 2007. INTHURN, Cândida. Qualidade & teste de software. Florianópolis: Visual Books, 2001.
144
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007 MAFFEO, Bruno. Engenharia de software e especificação de sistemas. 1 ed. Rio de Janeiro: Campus, 1992 MENEZES, Estera Muszkat; SILVA, Edna Lúcia da. Metodologia da pesquisa e elaboração de dissertação. 4. ed. ver. atual. Florianópolis: UFSC, 2005.
_________. Metodologia da Pesquisa e Elaboração de Dissertação. Universidade Federal de Santa Catarina, Florianópolis, 2001.
MICROSOFT. Microsoft Office Word 2010. Disponível em: <http://www.microsoft.com/portugal/educacao/suiteaprendizagem/msWord.html> Acesso em: 29 abr. 2013.
MOLINARI, Leonardo. Testes de Software: Produzindo sistemas melhores e mais confiáveis. São Paulo: Érica, 2003. MÜLLER, Thomas et al. Base de conhecimento para Certificação em Teste: Foundation Level Syllabus. Comissão Internacional para Qualificação de Teste de Software, 2007. p.77 MYSQL. MySQL Enterprise Edition. Disponível em: < http://www.mysql.com/products/enterprise/ > Acesso em: 22 abr. 2013 OLIVEIRA, Rafael Braga de. Framework Functest: Aplicando padrões de Software na Automação de Testes Funcionais. Fortaleza, 2007. ORACLE. Por que Java. Disponível em: <http://www.oracle.com/br/technologies/java/overview/index.html> Acesso em: 22 abr. 2013. PEZZÈ, Mauro; YOUNG, Michal. Teste e análise de software: processos, princípios e técnicas. Porto Alegre: Bookman, 2008. PRESSMAN, Roger S. Engenharia de software. Roger S. Pressman; tradução José Carlos Barbosa dos Santos; revisão técnica José Carlos Maldonado, Paulo Cesar Masiero, Rosely Sanches. São Paulo: Pearson Makron Books, 1995. PRESSMAN, Roger S. Engenharia de software. 5 ed. São Paulo: McGraw Hill, 2001. _________. Engenharia de Software. 5 ed. São Paulo: McGraw Hill, 2002. _________. Software Engineering: A Practitioner’s Approach, 6 ed, São Paulo: McGraw-Hill, 2004. _________. Engenharia de Software. 6. ed, São Paulo: McGrawHill, 2006.
145
REZENDE, Denis A. Engenharia de Software e Sistemas de Informação. Rio de Janeiro: Brasport, 1999. RIOS, Emerson; TRAYAHÚ FILHO, Moreira. Teste de software. 2a ed. Rio de Janeiro: Alta Books, 2006. ROSENBERG, Doug; STEPHENS, Matt; COPE, Mark Collins-. Agile Development with ICONIX Process: People, Process, and Pragmatism. New York: Apress , 2005.
ROYCE, W. Managing the Development of Large Software Systems: Concepts and Techniques. Proc. IEEE Westcon, Los Angeles, 1970 RUMBAUGH, James; BOOCH, Grady; JACOBSON, Ivar. UML: Guia do usuário. Rio de Janeiro: Campus, 2000. SANTIAGO, Israel; Automação de Testes Funcionais. PMP: 02 de maio de 2010. Disponível em: <http://www.slideshare.net/powerirs/automao-de-teste-funcionais-selenium-3936751>. Acesso em: 16 ago. 2012. SOARES, Michel dos Santos. Metodologias Ágeis Extreme Proggamming e Scrum para desenvolvimento de software. Revista Eletrônica de Sistemas de Informação, Conselheiro Lafaiete, v.3, n.1, 2004. Disponível em: <http://revistas.facecla.com.br/index.php/reinfo/issue/archive> . Acessado em: 08 out. 2012. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. SPARX SYSTEMS. Enterprise Architect. Disponível em: <http://www.sparxsystems.com.au/products/ea/index.html> Acesso em 22 abril de 2013. TONSIG, Sérgio Luiz. Engenharia de Software: Análise e Projetos de Sistemas. 2a ed. Rio de Janeiro: Editora Ciência Moderna Ltda, 2008.
146
APÊNDICES
147
APÊNDICE A – QUESTIONÁRIO
UNIVERSIDADE DO SUL DE SANTA CATARINA Título do Trabalho: AUTOMAÇÃO DE TESTES DE REGRESSÃO: UM ESTUDO DE CASO
UTILIZANDO O FRAMEWORK SELENIUM.
Alunos: Maiele Perosa Ranzan e Rodrigo Susin de Oliveira
Orientador: Flávio Ceci QUESTIONÁRIO – TESTES MANUAIS Informações: Este questionário tem por objetivo levantar as percepções dos participantes sobre o
teste manual aplicado no protótipo Projector, bem como suas opiniões a respeito das rotinas de teste
e ferramentas utilizadas.
Solicitamos a sua colaboração no preenchimento das questões.
IDENTIFICAÇÃO DO PARTICIPANTE
Qual é a sua idade?
____________________________________________________________________________
Qual é a sua escolaridade?
____________________________________________________________________________
____________________________________________________________________________
Atua na área de testes e/ou qualidade de software? Se a resposta for positiva, qual é o seu cargo e
há quanto tempo atua nesta área?
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
ROTINA DE TESTE
A modelagem disponibilizada na ferramenta Enterprise Architect lhe auxiliou na execução dos casos
de teste?
( ) A modelagem auxiliou o entendimento.
( ) A modelagem auxiliou parcialmente.
( ) A modelagem não auxiliou.
Os casos de teste disponibilizados são de fácil entendimento? Justifique sua resposta.
( ) Os casos de teste são de fácil compreensão.
( ) Alguns pontos não foram compreendidos.
( ) Os casos de teste não são de fácil entendimento.
____________________________________________________________________________
____________________________________________________________________________
148
Qual foi a quantidade de bugs que você encontrou e em qual (is) caso (s) de teste?
( ) Nenhum bug foi encontrado
( ) 1 a 2 bug (s)
( ) 3 ou mais bugs
____________________________________________________________________________
____________________________________________________________________________
A infraestrutura disponibilizada para o ambiente de teste foi suficiente para a execução?
( ) Suficiente.
( ) Parcialmente suficiente.
( ) Não foi suficiente.
A rotina de teste elaborada (casos de teste, modelagem e infraestrutura) atende o teste de
regressão?
( ) Atende completamente.
( ) Atende parcialmente.
( ) Não atende.
Das alternativas abaixo qual melhor define a seguinte pergunta: A automação dos testes de
regressão auxilia na prevenção e detecção de erros?
( ) É de grande valia para o auxílio e detecção de erros.
( ) Em poucos casos.
( ) Não auxilia ou Não se aplica.
Das alterativas abaixo, qual melhor se encaixa no tempo gasto em estudo e execução do teste?
( ) O tempo gasto foi conforme esperado.
( ) O tempo gasto foi conforme esperado, mas poderia ser otimizado.
( ) Gastou-se muito tempo para estudo e execução dos testes.
( ) O tempo gasto superou as expectativas positivamente.
149
ANEXOS
150
ANEXO A – Questionário do Testador X
151
152
153
ANEXO B – Questionário do Testador Y
154
155