Você está na página 1de 65

TESTES AUTOMATIZADOS NO PROCESSO DE

DESENVOLVIMENTO DE SOFTWARES

Leonardo Roxo Pessanha Izabel

Projeto de Graduao apresentado ao Curso de


Engenharia Eletrnica e de Computao da Escola
Politcnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessrios
obteno do ttulo de Engenheiro.

Orientador: Antnio Cludio Gmez de Sousa

Rio de Janeiro

Dezembro de 2014
TESTES AUTOMATIZADOS NO PROCESSO DE
DESENVOLVIMENTO DE SOFTWARES

Leonardo Roxo Pessanha Izabel

PROJETO DE GRADUAO SUBMETIDO AO CORPO DOCENTE DO CURSO


DE ENGENHARIA ELETRNICA E DE COMPUTAO DA ESCOLA
POLITCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO
PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU DE
ENGENHEIRO ELETRNICO E DE COMPUTAO

Autor:

_________________________________________________

Leonardo Roxo Pessanha Izabel

Orientador:

_________________________________________________

Prof. Antnio Cludio Gmez de Sousa, Dr.

Examinador:

_________________________________________________

Prof. Aloysio de Castro Pinto Pedroza, Dr.

Examinador:

_________________________________________________

Prof. Ricardo Rhomberg Martins, D. Sc.

Rio de Janeiro RJ, Brasil

Dezembro de 2014

ii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politcnica Departamento de Eletrnica e de Computao

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitria

Rio de Janeiro RJ CEP 21949-900

Este exemplar de propriedade da Universidade Federal do Rio de Janeiro, que


poder inclu-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.

permitida a meno, reproduo parcial ou integral e a transmisso entre


bibliotecas deste trabalho, sem modificao de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadmica, comentrios e citaes, desde que sem
finalidade comercial e que seja feita a referncia bibliogrfica completa.

Os conceitos expressos neste trabalho so de responsabilidade do(s) autor(es).

iii
DEDICATRIA

Aos meus pais, irmo, madrinha e amigos que tanto me ajudaram na longa
caminhada que resultou neste trabalho e na concluso do curso.

iv
AGRADECIMENTO

Ao povo brasileiro que contribuiu de forma significativa minha formao e


estada nesta Universidade. Este projeto uma pequena forma de retribuir o investimento
e confiana em mim depositados.

v
RESUMO

O projeto consiste em um estudo sobre a automao de testes durante o


desenvolvimento de um software. Para nos aprofundarmos nesse tema, realizamos um
estudo sobre todos os principais conceitos e os diferentes tipos de testes.

Alm disso, selecionamos algumas das mais utilizadas ferramentas do mercado


de modo a entender um pouco mais seu funcionamento e suas aplicaes na rea de
automao de testes.

Com o objetivo de ilustrar o funcionamento de um teste automatizado,


exemplificamos, atravs de um estudo de caso, a construo e o funcionamento de um
projeto automatizado.

Palavras-Chave: testes, automao, software, qualidade.

vi
ABSTRACT

The project consists of a study of the automation of testing during the


development of software. To understand better this subject, we conducted a study on all
the key concepts and the different types of tests.

In addition, we selected some of the most used tools in the market in order to
understand its operation and its applications in test automation area.

In order to illustrate the operation of an automated test, we exemplified it by


constructing a case study.

Key-words: test, automation, software, quality.

vii
Sumrio
Captulo 1 ...................................................................................................................................... 1
Introduo ..................................................................................................................................... 1
1.1. Ttulo ............................................................................................................................. 1
1.2. nfase ............................................................................................................................ 1
1.3. Tema .............................................................................................................................. 1
1.4. Delimitao ................................................................................................................... 1
1.5. Localizao ................................................................................................................... 1
1.6. Justificativa ................................................................................................................... 2
1.7. Objetivo ......................................................................................................................... 2
1.8. Metodologia .................................................................................................................. 3
Captulo 2 ...................................................................................................................................... 4
Testes e Qualidade (Software) ...................................................................................................... 4
2.1. A necessidade de se testar um software ........................................................................ 4
2.2. Definio de Teste......................................................................................................... 5
2.3. Conceitos ....................................................................................................................... 7
2.3.1. Erro (Error) ............................................................................................................ 7
2.3.2. Defeito (Defect) ..................................................................................................... 7
2.3.3. Falha (Failure) ....................................................................................................... 7
2.3.4. Verificao ................................................................................................................ 8
2.3.5. Validao................................................................................................................... 8
2.3.6. Teste .......................................................................................................................... 8
2.3.7. Depurao.................................................................................................................. 9
2.4. Modelos / Mtodos ........................................................................................................ 9
2.4.1. Modelo Caixa-Preta................................................................................................... 9
2.4.2. Modelo Caixa-Branca ............................................................................................. 10
2.4.3. Modelo Caixa-Cinza ............................................................................................... 10
2.5. Tipos de Teste ............................................................................................................. 10
2.5.1. Testes Unitrios ....................................................................................................... 11
2.5.2. Testes de Integrao ................................................................................................ 11
2.5.3. Testes de Sistema .................................................................................................... 11

viii
2.5.4. Testes Funcionais .................................................................................................... 12
2.5.5. Aceitao ................................................................................................................. 12
2.5.5.1. Testes Alfa........................................................................................................... 13
2.5.5.2. Testes Beta .......................................................................................................... 13
2.5.6. Testes de Regresso ................................................................................................ 13
2.5.7. Testes No-Funcionais ............................................................................................ 13
2.5.7.1. Testes de Desempenho ........................................................................................ 13
2.5.7.1.1. Testes de Carga ................................................................................................... 14
2.5.7.1.2. Testes de Stress ................................................................................................... 14
2.5.7.2. Testes de Segurana ............................................................................................ 15
2.5.7.3. Testes de Portabilidade........................................................................................ 15
Captulo 3 .................................................................................................................................... 17
Automao de Testes .................................................................................................................. 17
3.1. Definio ..................................................................................................................... 17
3.2. Quando no automatizar? ............................................................................................ 17
3.3. Casos para automatizao de testes ............................................................................. 18
3.3.1. Testes de Carga e Desempenho ............................................................................... 18
3.3.2. Testes de Regresso ................................................................................................ 18
3.3.3. Testes manuais repetitivos ...................................................................................... 18
3.3.4. Testes de Unidade ................................................................................................... 18
3.3.5. Preparao de pr-condies ................................................................................... 18
3.4. Ferramentas de Automao ......................................................................................... 19
3.4.1. JUnit ........................................................................................................................ 19
3.4.2. Selenium 2.0 ............................................................................................................ 19
3.4.3. Jenkins ..................................................................................................................... 21
3.4.4. Git ............................................................................................................................ 22
3.4.5. GitHub ..................................................................................................................... 22
3.4.6. Eclipse ..................................................................................................................... 22
3.4.7. Ant ........................................................................................................................... 22
Captulo 4 .................................................................................................................................... 23
Online Bank Management System .............................................................................................. 23
4.1. Definio ..................................................................................................................... 23
4.2. Arquitetura .................................................................................................................. 23
4.2.1. Aplicao Web ........................................................................................................ 23

ix
4.2.2. Banco de dados........................................................................................................ 24
4.3. Fluxos de funcionamento do Sistema.......................................................................... 25
4.3.1. Autenticao ............................................................................................................ 25
4.3.2. Cadastro de novo usurio ........................................................................................ 25
4.3.3. Boas vindas ............................................................................................................. 26
4.3.4. Criar conta ............................................................................................................... 27
4.3.5. Depositar ................................................................................................................. 28
4.3.6. Sacar ........................................................................................................................ 28
4.3.7. Verificar saldo ......................................................................................................... 29
4.3.8. Movimentao entre contas ..................................................................................... 30
4.3.9. Relatrio de movimentaes ................................................................................... 31
4.4. Casos de testes............................................................................................................. 31
Captulo 5 .................................................................................................................................... 33
Automao de Teste - Estudo de Caso ........................................................................................ 33
5.1. Viso Geral.................................................................................................................. 33
5.2. Implementao da automao de testes de Interface com o Selenium ........................ 33
5.3. Implementao da automatizao de testes com o Ant ............................................... 35
5.4. Integrao Contnua com Jenkins................................................................................ 38
5.5. Manuteno do ciclo de Integrao Contnua (CI) ..................................................... 41
Captulo 6 .................................................................................................................................... 42
Resultados e Concluses ............................................................................................................. 42
6.1. Resultados ................................................................................................................... 42
6.2. Concluso .................................................................................................................... 43
Referncias .................................................................................................................................. 44
Bibliografia ................................................................................................................................. 45
Apndice A.................................................................................................................................. 46
Casos de Teste ............................................................................................................................. 46

x
Lista de Figuras
Figura 1 Erro x Defeito x Falha ................................................................................................... 8
Figura 2 Modelo caixa preta ....................................................................................................... 9
Figura 3 Modelo caixa branca .................................................................................................. 10
Figura 4 Selenium IDE............................................................................................................... 20
Figura 5 Exportao de casos de testes ................................................................................... 20
Figura 6 Modelo de comunicaao entre a pgina web, o servelet e o server ......................... 24
Figura 7 Modelo de comunicao entre a aplicao Java e o banco ODBC ............................. 24
Figura 8 - Imagem ilustrando tela de autenticao .................................................................... 25
Figura 9 - Imagem ilustrando tela de registro de novo usurio .................................................. 26
Figura 10 - Imagem ilustrando tela de boas vindas .................................................................... 27
Figura 11 - Imagem ilustrando tela de criao de conta ............................................................. 27
Figura 12 - Imagem ilustrando tela de depsito ......................................................................... 28
Figura 13 - Imagem ilustrando tela de saque .............................................................................. 29
Figura 14 - Imagem ilustrando tela de requisio de saldo ........................................................ 29
Figura 15 Imagem ilustrando tela de exibio de saldo ........................................................... 30
Figura 16 - Imagem ilustrando tela de transferncias ................................................................ 30
Figura 17 Imagem ilustrando tela do relatrio de movimentaes ......................................... 31
Figura 18 Configurao de velocidade do Selenium IDE .......................................................... 34
Figura 19 Opo para executar os testes com o JUnit ............................................................. 35
Figura 20 Configuraes bsicas do Eclipse para utilizar o Ant ............................................... 36
Figura 21 Gerao do arquivo build.xml .................................................................................. 36
Figura 22 Configurao da execuo do arquivo build.xml ..................................................... 37
Figura 23 Resultados dos testes ............................................................................................... 38
Figura 24 Configuraes dos caminhos do JDK e do Ant ......................................................... 39
Figura 25 Configurao do servidor SMTP ............................................................................... 39
Figura 26 Trigger do GitHub ..................................................................................................... 40
Figura 27 Configurao do Trigger ........................................................................................... 40
Figura 28 Configurao do Ant ................................................................................................. 40
Figura 29 - Configurao do Relatrio de JUnit .......................................................................... 41
Figura 30 Configurao de e-mail............................................................................................. 41

xi
Captulo 1
Introduo
1.1. Ttulo

Testes Automatizados no Processo de Desenvolvimento de Softwares

1.2. nfase

Computao

1.3. Tema

O tema do trabalho o estudo do processo de testes durante o desenvolvimento


de softwares de modo a seguir padres de qualidade. Nesse sentido, pretende-se
responder a questo relacionada ao esforo gasto em um processo de teste de um
software feito manualmente. A hiptese inicial que se deve automatizar todo e
qualquer teste que venha a ser feito em um determinado software. Dessa forma, sempre
que qualquer correo ou atualizao seja feita no software ser possvel avaliar o
impacto dessas modificaes.

1.4. Delimitao

O objeto de estudo a automatizao de testes de software seguindo padres de


qualidade. A anlise das diversas metodologias e ferramentas de testes tem por
finalidade orientar em diferentes cenrios de testes como proceder com excelncia de
modo a diminuir esforos.

1.5. Localizao

No processo de desenvolvimento de softwares, comum, antes de


colocar um sistema em produo, submeter o software a um processo de avaliao de
qualidade. Esse controle de qualidade foi, e em muitos casos ainda , realizado com
auxlio de testes manuais executados por usurios ou mesmo equipes especializadas em
testes. Esse tipo de metodologia, quando aplicada a grandes sistemas de software, tem
frequentemente se mostrado ineficaz gerando uma excessiva quantidade de erros no

1
produto, aumentando assim os esforos na sua manuteno. Uma alternativa a essa
metodologia a automatizao de testes. Este trabalho localiza-se nesse ltimo mtodo,
onde a utilizao de ferramentas de automatizao de testes permite testes mais eficazes
de forma a adequar um software aos padres de qualidade.

1.6. Justificativa

A cada dia que passa, o mundo moderno est mais imerso no universo
computacional. Durante o dia-a-dia, o ser humano se depara constantemente com
softwares em quase todos os lugares.

Cada aparelho ou dispositivo portador de um sistema de software teve durante


seu processo de desenvolvimento centenas ou at milhares de defeitos encontrados e
corrigidos por seus desenvolvedores e testadores. Ainda assim, comum um usurio
encontrar possveis erros e defeitos nesses sistemas durante a sua utilizao. Percebeu-
se que com o aumento dos sistemas, a depurao de todos os possveis erros a cada
modificao feita no sistema torna-se uma tarefa de esforo muito elevado. Nesse
cenrio surgiu o conceito da automatizao de testes.

O presente projeto um estudo dos mtodos de testes e padres de qualidade de


servios na rea de desenvolvimento de software. Tal estudo abordar como deve ser
feita a automatizao de cada tipo de teste analisando a utilizao de ferramentas
disponveis no mercado.

Assim, a importncia desse trabalho reside na premissa de que em projetos de


sistemas de software num ambiente profissional necessria a utilizao de testes
automatizados de forma a manter um bom produto (menor nmero possvel de falhas)
com preo competitivo.

1.7. Objetivo

O objetivo geral , ento, realizar um estudo que possa reunir todos os mtodos
de testes contemporneos e relacion-los com ferramentas de automao. Dessa forma,
tem-se como objetivos especficos: (1) estudar os diferentes tipos de testes existentes;
(2) estudar diversas ferramentas de automao existentes no mercado; (3) analisar os
melhores casos entre tipo de teste versus ferramenta; (4) realizar um estudo de caso.

2
1.8. Metodologia

Este trabalho ir abordar diversos tipos de testes em diferentes ferramentas.


Tendo em vista esse objetivo, a primeira etapa ser realizar um levantamento dos
mtodos de testes mais produtivos e utilizados em sua respectiva categoria atualmente.
Dessa forma, nesse primeiro momento ser feita uma pesquisa qualitativa.

Em relao automatizao de testes, ser feito um levantamento de algumas


ferramentas do mercado que conseguem cobrir os testes estudados previamente. Aps
esse levantamento, diante das ferramentas pesquisadas, sero escolhidas para a
realizao de testes aquelas que conseguirem cobrir uma maior quantidade de categorias
de testes estudados e possibilitarem sua utilizao livre (Open Source) ou possurem um
perodo de uso para conhecer a ferramenta (Trial).

Por fim, pretende-se aplicar esse conhecimento adquirido realizando um estudo


de caso.

O xito deste trabalho est centrado na determinao de como realizar diversos


tipos de testes nas ferramentas mais apropriadas. Tal xito reside tambm na realizao
de um teste completo realizado em um software de cdigo aberto, inserindo possveis
erros e verificando se os resultados ocorrem como esperado.

3
Captulo 2
Testes e Qualidade (Software)
Neste captulo veremos os principais conceitos de testes de software aplicados
de modo a garantir padres aceitveis de qualidade.

2.1. A necessidade de se testar um software

O objetivo do desenvolvimento de um software a resoluo de um problema


real existente no nosso mundo, atravs de comandos escritos que sero interpretados por
um computador.

Ao analisar essa frase j possvel perceber que quando um desenvolvedor


prope-se a construir um software, diversas falhas podero surgir no andamento desse
processo.

Em primeiro lugar, h casos em que a falha ocorre simplesmente na resoluo do


problema real. O desenvolvedor pode vir a criar uma soluo que resolva parte do
problema analisado. Consequentemente, estaria ignorando outros cenrios que,
possivelmente, viriam a ocorrer durante a utilizao da ferramenta por outros usurios.

Em segundo lugar, o erro pode ocorrer na escrita dos comandos. As linguagens


de programao, como o prprio nome define, so linguagens e, portanto envolvem
ambiguidades. Muitos so os casos em que, no nosso dia-a-dia, ns nos deparamos com
falhas no entendimento entre humanos por ambiguidade na comunicao. Logo,
comum que isso ocorra tambm quando tentamos comandar um computador atravs
desse mesmo meio.

Por ltimo, importante ressaltar que ao se escrever um software para resolver


um problema mais elaborado, o grau de complexidade do cdigo tambm aumenta.
Dessa forma, em muitas ocasies, o prprio desenvolvedor perde o rastro do significado
de todas as linhas de seu cdigo. Isso pode vir a ser um problema grave, quando ele
efetuar uma modificao em algum pedao do cdigo e esquecer o impacto da mudana
nas outras funes que ele programou. Consequentemente, ele estaria inserindo novos

4
erros, os quais desconhece, e que s viro a ser detectados posteriormente pelo usurio
final.

Em resumo, perceptvel o alto risco de ser produzir um software com defeitos


(vulgarmente chamados tambm por bugs). Esse risco o que justifica a utilizao de
testes no processo de desenvolvimento. Testar reduz esse risco.

pensando em reduzir esse risco que se criaram os processos de Quality


Assurance (QA). Tais processos tm como objetivo produzir softwares de melhor
qualidade, ou seja, com o menor ndice de erros possvel.

claro que sempre existiro defeitos em um cdigo. Por mais que se teste
exaustivamente, nunca possvel verificar todas as possibilidades de entradas e sadas
de uma aplicao. Porm, processos de qualidade visam testar um software com o
objetivo de se obter um padro mnimo de qualidade. Assim, o nmero de defeitos que
seria encontrado pelos usurios finais reduzido, gerando um software melhor.

Em suma, todos os processos de qualidade almejam criar o melhor software


possvel dentro de um tempo aceitvel. Esse software ideal facilmente entendido
citando-se Bruce Sterling em The Hacker Crackdown: The best software is that
which has been tested by thousands of users under thousands of different conditions,
over years. It is then known as "stable." This does NOT mean that the software is now
flawless, free of bugs. It generally means that there are plenty of bugs in it, but the bugs
are well-identified and fairly well understood.[4]

2.2. Definio de Teste

Testar um software consiste em execut-lo de acordo como foi especificado,


para determinar se ele ir comportar como esperado no ambiente para o qual ele foi
projetado. O indivduo que responsvel por essa funo conhecido como tester (ou
testador se traduzirmos). Cabe ao tester a rdua misso de garantir a qualidade do
software antes que este v para o usurio final (ou cliente, quando numa relao
comercial).

Para executar essa misso com excelncia, um tester profissional precisa assumir
uma atitude totalmente contrria a de um desenvolvedor. Enquanto o desenvolvedor
tenta fazer seu software em construo funcionar perfeitamente, o tester possui um

5
papel destrutivo, tentando, de todas as formas, provar para o desenvolvedor que o
programa possui falhas. Por esse motivo, no se recomenda que os testes sejam feitos
pelo desenvolvedor.

claro que um desenvolvedor capaz de assumir esse papel, porm ele assume
uma viso otimista ao criar seu software. Existe uma tendncia lgica que faz com que o
desenvolvedor acredite que suas modificaes esto sempre aperfeioando o software,
criando a soluo perfeita para o problema inicial. Porm, isso apenas uma suposio,
que se no for devidamente testada, no agrega nenhuma qualidade ao produto,
resultando assim em usurios insatisfeitos com defeitos no software. Alm disso,
estudos empricos comprovam que 50 % das modificaes feitas no cdigo pelo
desenvolvedor na verdade inserem outros defeitos no cdigo em diversos outros pontos
do software.

Ao executar um teste, o profissional de teste parte da premissa que o software


no est funcionando corretamente. Ele assume o fato de que o sistema est
comprometido com diversos defeitos e que o seu papel desvend-las antes que um
usurio o faa.

Essas duas mentalidades citadas (testador e desenvolvedor) so totalmente


contraditrias e conflituosas, tornando-se muito complicado para apenas uma pessoa
assumir os dois papis no mesmo projeto.

Por outro lado, apesar de ser recomendvel que o desenvolvedor no assuma o


papel de tester em um mesmo projeto, ele deve sim testar seu software desde o incio da
codificao. Isso significa que, por mais que tenhamos um profissional focado em
testar, cabe ao desenvolvedor verificar seu cdigo ao mximo, de modo a minimizar os
defeitos existentes que viriam a ser encontradas mais a frente no processo de teste.

Segundo Barry Boehm[5], um defeito encontrado no desenvolvimento do design


e requisitos da soluo custa 10 vezes menos que um encontrado na codificao em si e
100 vezes menos do que um encontrado na entrega do produto. Portanto, o quanto antes
os desenvolvedores e os testers comearem a testar o produto, menos custoso o projeto
ser e ter, definitivamente, muito mais qualidade.

6
Em suma, para atingir bons padres de qualidade espera-se que no
desenvolvimento de um software existam diversas etapas com diversos tipos de testes
que viro a ser executados, no somente pelo tester, mas tambm pelo desenvolvedor.

2.3. Conceitos

Existem alguns conceitos importantes que compem o universo de teste de


software. Por mais simples que eles possam parecer, em muitos casos eles se
confundem devido ambiguidade de sentidos que podem assumir na linguagem do dia-
a-dia humano. Porm, dentro do escopo de engenharia de software, cada termo que ser
citado abaixo tem seu prprio significado.

2.3.1. Erro (Error)

Um erro um desvio do que foi concordado pela especificao de requisitos. O


erro de um desenvolvedor pode gerar defeitos no software.

2.3.2. Defeito (Defect)

Um defeito inserido no cdigo de um software quando um desenvolvedor


comete algum erro. Dessa forma, apenas um erro pode gerar vrios defeitos em um
determinado cdigo ou vrios erros podem vir a causar apenas um defeito.

2.3.3. Falha (Failure)

Uma falha um comportamento operacional do software diferente do esperado


pelo usurio. Uma falha pode ter sido causada por diversos defeitos e alguns defeitos
podem nunca causar uma falha.

7
Figura 1 Erro x Defeito x Falha
Fonte: Artigo Engenharia de Software - Introduo a Teste de Software [1]

2.3.4. Verificao

Verificar um software consiste em aferir que o produto internamente


consistente. Ou seja, significa garantir que o software atende especificao de
requisitos. A grande maioria dos testes consiste em testes de verificao, em que o
produto verificado em circunstncias especificadas para garantir a sada esperada.
Em resumo, quando se decide verificar um software, deve-se fazer a seguinte pergunta:
Estamos construindo corretamente o produto?.

2.3.5. Validao

Validar um software consiste em garantir que o produto est de acordo com as


expectativas do cliente ou usurio. Validar vai alm de apenas verificar se o sistema est
de acordo com as especificaes de requisitos de modo a aferir que o sistema faz
realmente aquilo que o usurio final espera que ele faa. Em resumo, quando se decide
validar um software, deve-se fazer a seguinte pergunta: Estamos construindo o produto
correto?.

2.3.6. Teste

Teste um processo para executar um software ou sistema com o objetivo de


revelar a presena de defeitos. Com esse objetivo, o teste tem como meta aumentar a
confiana sobre o software testado.

8
2.3.7. Depurao

Depurar um processo posterior ao teste. Ele ocorre aps o teste encontrar


alguma falha no sistema ou no software testado e consiste em uma busca no cdigo
fonte ou na especificao do software para encontrar e corrigir a falta ou defeito que
gerou esse erro.

2.4. Modelos / Mtodos

Existem basicamente trs diferentes modelos de teste que podem ser executados
de modo a aferir o funcionamento de um software:

2.4.1. Modelo Caixa-Preta

A tcnica consiste em testar sem que se possua nenhum conhecimento do


funcionamento interior da aplicao que est sendo testada. O testador no possui
conhecimento da arquitetura do sistema e no tem acesso ao cdigo fonte.
Normalmente, quando um testador est executando um teste com o modelo caixa-preta,
ele interage apenas com a interface do sistema, provendo entradas e examinando as
sadas sem saber como e onde essas entradas esto sendo utilizadas.

Figura 2 Modelo caixa preta


Fonte: Understanding White box Testing and Black box Testing Approaches [2]

9
2.4.2. Modelo Caixa-Branca

A tcnica consiste em executar uma investigao da lgica interna e da estrutura


do cdigo fonte. O modelo de teste caixa-branca tambm conhecido como glass
testing (teste de vidro) ou teste caixa aberta. Para conseguir executar um teste caixa
branca em uma aplicao, o testador precisa possuir um conhecimento do
funcionamento interno do cdigo fonte.

Figura 3 Modelo caixa branca


Fonte: Understanding White box Testing and Black box Testing Approaches [2]

2.4.3. Modelo Caixa-Cinza

O modelo caixa-cinza oriundo dos mtodos caixa-preta e caixa-branca. O


modelo consiste em uma mescla de ambos os casos, adequando-os ao teste de maneira a
gerar um teste mais efetivo.

Apesar de ser oriundo da mistura de ambos, o modelo tem uma caracterstica


importante: feito pela interface somente, ou seja, apesar de ele considerar o cdigo
durante o planejamento do teste, durante a execuo se utilizam apenas as entradas e
sadas do modelo caixa preta.

2.5. Tipos de Teste

O planejamento dos testes deve ocorrer em diferentes nveis e em paralelo ao


desenvolvimento do software. Abaixo so definidos alguns tipos de teste de software:

10
2.5.1. Testes Unitrios

Testes Unitrios tm como objetivo averiguar as menores unidades de software


desenvolvidas. Formalmente o IEEE o define como: Atividade capaz de testar
unidades de hardware ou software ou grupo de unidades relacionadas.

Para realizar esse tipo de teste, deve-se primeiramente selecionar qual ser a
unidade. Tal escolha uma deciso de projeto, no existindo, portanto, um caminho
nico e correto a ser seguido. Por exemplo, um testador de um software que utiliza uma
linguagem orientada a objeto pode escolher seus mtodos como menor unidade em
determinado projeto. Em outros casos talvez no seja necessrio tal nvel de
detalhamento e o testador poder utilizar as prprias classes como a unidade do teste.

O indivduo responsvel pela execuo deste tipo de teste o prprio


desenvolvedor, principalmente devido ao fato de ser um teste caixa-branca. Ou seja, o
testador precisa visualizar o cdigo de modo a preparar e executar o teste.

2.5.2. Testes de Integrao

Testes de Integrao tm como objetivo verificar como cada parte do software se


relaciona com as outras. Em outras palavras o IEEE o define como: Teste no qual os
componentes de software, componentes de hardware, ou ambos so combinados e
testados para avaliar a interao entre eles.

Para realizar esse tipo de teste, existem duas estratgias que podem ser seguidas:
Bottom-Up integration ou Top-Down integration. Elas definem o caminho que o
testador pretende seguir na integrao partindo dos membros de nvel mais baixos ou de
nvel mais alto. Novamente tal deciso uma escolha de projeto.

Testes de Integrao so executados na maioria dos casos pelos prprios


desenvolvedores, pois necessrio acesso ao cdigo.

2.5.3. Testes de Sistema

Testes de Sistema tm como objetivo identificar as funes que o software deve


realizar (especificao dos requisitos, casos de uso). O IEEE o define como: Teste
conduzido em um sistema completo e integrado para avaliar se o sistema est de acordo
com os requisitos especificados.

11
Testes de Sistema devem ser executados por uma equipe de teste externa, ou
seja, nenhum desenvolvedor deve participar desse teste. um teste de caixa-preta, ou
seja, o testador no precisar conhecer o interior do software para execut-lo.

O teste ir consistir na simples utilizao do software em diversas condies de


modo a verificar seu comportamento em cada caso.

Os testes de sistema se dividem em duas novas classes de teste: Testes


Funcionais e Testes No-Funcionais.

2.5.4. Testes Funcionais

Testes funcionais tm como objetivo verificar se o sistema est funcionando de


acordo como se espera independente da estrutura do sistema, ou seja, nesse caso
qualquer fator de interferncia externa fora do esperado do sistema no deve ser levado
em conta.

Testes funcionais so basicamente o modelo de teste caixa-preta aplicado aos


casos de testes que aferem as funcionalidades do sistema ou software que est sendo
desenvolvido.

2.5.5. Aceitao

Teste de Aceitao tem como objetivo aferir se o software est de acordo com os
padres de qualidade mnimos definidos na especificao de modo que seja aceito pelo
cliente ou usurio.

Em alguns casos, o cliente do projeto utiliza alguns dos usurios finais do


produto com vistas a aferir se o produto est satisfatrio (UAT -User Acceptance
Testing).

Testes de aceitao envolvem em muitos casos os prprios artefatos gerados


alm do cdigo em si. Manuais, documentaes, material de treinamento, entre outros
artefatos so testados de modo a perceber se o projeto, e no somente o produto, tem
qualidade.

Usualmente os testes de aceitao so feitos somente aps a consolidao de


todo o produto, ou seja, aps todos os testes funcionais e no-funcionais terem sido
executados e os erros encontrados no processo, corrigidos.

12
Existem dois subtipos de testes que se enquadram como testes de aceitao:

2.5.5.1. Testes Alfa

Consistem no teste de aceitao feito por um nmero restrito e escolhido de


usurios. executado dentro do ambiente de desenvolvimento, na maioria dos casos.

2.5.5.2. Testes Beta

Consistem no teste de aceitao feito em maior escala, onde os testadores so os


prprios usurios. Os testes beta so normalmente a ltima fronteira antes da entrega de
um software para o cliente ou para o mercado em si.

2.5.6. Testes de Regresso

Testes de Regresso no so exatamente um tipo de teste e sim mais uma


estratgia para a reduo de efeitos colaterais. Consistem em aplicar, a cada nova verso
do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos
de teste anteriores do sistema. Podem ser aplicados em qualquer nvel de teste.

Dessa forma, evita-se que ao modificar ou consertar um erro o desenvolvedor


insira um erro crtico que afetar os casos de testes j executados.

Por ser um teste longo (soma de todos os testes j executados) e por ser
executado diversas vezes (a cada criao de verso) ele se torna um dos maiores
argumentos da automao de testes.

2.5.7. Testes No-Funcionais

Testes no-funcionais tm como objetivo aferir o funcionamento do sistema em


condies extremas. Por se tratarem de condies incomuns o universo de testes no-
funcionais muito grande. Abaixo sero definidos os principais tipos de testes no
funcionais:

2.5.7.1. Testes de Desempenho

Testes de desempenho, como o prprio nome j diz, tm como objetivo validar


se o sistema funciona em situaes mais prximas na realidade a qual ele ser exposto.
O teste tem como meta aferir se o software reagir nos tempos esperados mediante

13
pedidos e acessos de mais de um usurio. Alm disso, mede-se como o software reagiria
em condies mais extremas de falta de conexo, ou intermitncia na rede.

Os testes de desempenho se dividem em dois tipos de testes:

2.5.7.1.1. Testes de Carga

Testes de carga consistem na simples verificao do comportamento do sistema


mediante a aplicao de uma carga mxima de acessos e manipulaes de dados de
entrada.

Podem ser executados em condies normais, simulando a realidade em que se


pretende inserir o sistema, ou em condies de pico, simulando condies extremas que
podem vir a ocorrer devido a alguma anomalia.

Testes de carga so executados, na grande maioria dos casos, com a ajuda de


ferramentas automticas como Load Runner, AppLoader, IBM Rational Performance
Tester, Apache JMeter, Silk Performer, Visual Studio Load Test etc.

Nessas ferramentas so definidos usurios virtuais que executaram scripts


selecionados de maneira a efetuar o teste de carga no software. A quantidade de
usurios facilmente ajustada em suas configuraes de acordo com os requisitos do
sistema.

2.5.7.1.2. Testes de Stress

Testes de stress visam aferir o comportamento do software sob condies


anormais. Durante a execuo de um teste de stress retiram-se recursos aplicando uma
carga acima dos limites definidos pelos requisitos.

O principal foco testar a aplicao em condies extremas de modo a encontrar


o ponto no qual o software deixa de funcionar, conhecida como breaking point.

Testes de stress podem ser executados em diferentes cenrios, abaixo se


encontram alguns deles:

Conexo intermitente com o banco de dados


Conexo intermitente na rede

14
Aplicando carga atravs de diferentes processos que consomem
memria, processamento no servidor.
Aplicando carga atravs de diferentes processos que consomem
memria, processamento no cliente.

2.5.7.2. Testes de Segurana

Testes de segurana so um tipo de teste que tem como objetivo expor todas as
possveis vulnerabilidades que um sistema possui. Dessa forma, pode-se determinar se
os dados e recursos do seu software esto devidamente protegidos contra um possvel
ataque externo.

Existem 4 diferentes reas que devem ser consideradas durante a execuo de


um teste de segurana:

Segurana da Rede: visa descobrir vulnerabilidades da infraestrutura da


rede do sistema.
Segurana dos softwares do sistema: visa descobrir vulnerabilidades nos
softwares, com os quais o sistema em questo se comunica e dos quais
depende.
Segurana da aplicao no cliente: visa garantir que o cliente no seja
manipulado.
Segurana da aplicao no servidor: visa garantir que o servidor
robusto o suficiente de modo a no permitir qualquer acesso de intrusos.

Existem infinitas formas de invadir um sistema, logo existem infinitos tipos e


formas de proteger e testar um software, de forma a garantir sua segurana. Por mais
difcil que seja criar um software totalmente seguro contra tudo, dependendo da
criticidade da funcionalidade do software, deve-se utilizar ao mximo esse tipo de teste.

2.5.7.3. Testes de Portabilidade

Testes de portabilidade, como do prprio nome se infere, visam validar se o


software desenvolvido pode ser utilizado em diferentes ambientes. Hardwares, sistemas
operacionais e navegadores costumam ser os maiores focos dos testes de portabilidade.

15
Tais testes tm grande valor para sistemas multi-plataforma que tentam atingir todos os
tipos de clientes com sua aplicao.

Dessa forma, vemos abaixo alguns exemplos bsicos mais utilizados de testes de
portabilidade:

Transferir o software de um computador para outro;


Construir o executvel para testar o software em diferentes plataformas
de sistema operacional;
Utilizar diferentes navegadores para testar a aplicao.

Testes de portabilidade exigem que o sistema em si tenha sido construdo com o


intuito de ser portvel.

16
Captulo 3
Automao de Testes
Neste captulo, estudaremos os principais casos e aplicaes para automao de
testes, assim como algumas ferramentas largamente utilizadas nesses processos.

3.1. Definio

Automao de testes, por definio, consiste em utilizar um software externo


(que no faa parte do software que est sendo testado) para controlar a execuo dos
testes e a comparao dos resultados encontrados com os resultados esperados. Atravs
desse processo, podem-se automatizar algumas tarefas de teste repetitivas, porm
necessrias, que fazem parte do fluxo de teste de um software ou adicionar novos testes
que seriam muito trabalhosos, e consequentemente custosos para serem executados
manualmente.

3.2. Quando no automatizar?

A automao de testes tem como objetivo reduzir esforos em tarefas repetitivas,


logo nem todos os testes devem ser automatizados. Antes de se inserir esse processo em
um projeto deve-se analisar qual o volume de testes que seu software necessita e o
tempo que gasto para executar essas baterias de testes. Se o projeto em questo tiver
uma complexidade muito pequena de modo que o volume de teste para aferir a
qualidade do sistema muito baixo, o esforo para inserir essa metodologia de testes
pode ser mais custoso do que a manuteno dos testes manuais. Somado a isso, o tempo
para a execuo dos testes automticos no seriam, nesse caso, to menores que os
manuais.

Outro fator importante que o teste automatizado, como qualquer outro


software, comunica-se com o software que est sendo testado atravs de uma interface.
Se essa interface sofre constantes modificaes, seus testes sofrero alteraes tambm.
Esse o pior cenrio para a automao de testes. Em casos como esse a automao deve
ser evitada, pois os testes automticos sero constantemente alterados manualmente,
contrariando totalmente os princpios do processo em si.

17
3.3. Casos para automatizao de testes

3.3.1. Testes de Carga e Desempenho

Testes automticos so um pr-requisito para esses tipos de teste. impraticvel


economicamente utilizar 100 ou mais usurios, durante um teste, para acessar um
sistema simultaneamente a fim de a avaliar a qualidade do sistema sob tais condies.

3.3.2. Testes de Regresso

uma das melhores aplicaes da automao de testes. Testes de regresso


usualmente custam muito tempo para serem executados manualmente e so muito
suscetveis a erro humano devido, ao seu nvel de repetitividade. Ao automatizar, reduz-
se drasticamente a possibilidade de o sistema ir para produo com a insero de um
novo defeito em uma funcionalidade antiga. Alm disso, o ganho em tempo de
execuo dos testes geralmente justifica a sua utilizao.

3.3.3. Testes manuais repetitivos

Nesses casos, a grande vantagem do teste automtico se deve reduo de erros


propriamente. Testes manuais repetitivos normalmente exigem um grande nvel de
concentrao do tester de modo que ele no se distraia devido a um cansao psicolgico
da repetio. Assim sendo, justifica-se a automao nos casos em que se verifica que
seus testes tm obtido resultados no verdadeiros devido falha humana.

3.3.4. Testes de Unidade

Com a existncia de tantas ferramentas gratuitas de testes unitrios pra quase


todas as linguagens, no utiliza-las simplesmente contra produtivo. O ganho em tempo
ao utilizar essas ferramentas justifica sua utilizao na maioria dos casos.

3.3.5. Preparao de pr-condies

Ferramentas de automao de testes podem e devem ser usadas para preparar


ambientes de teste como condies iniciais ou entradas que viro a ser utilizadas nos
testes. claro que esse jamais ser o primeiro passo a ser dado quando se pretende
automatizar um software, porm uma vez que se possua a ferramenta deve-se utiliz-la
de modo a maximizar a produtividade.

18
3.4. Ferramentas de Automao

Neste captulo, veremos, dentre as ferramentas estudadas, as escolhidas para a


realizao do estudo de caso.

3.4.1. JUnit

O JUnit um framework open-source, criado por Erich Gamma e Kent Beck,


com suporte criao de testes unitrios automatizados na linguagem de
programao Java.

O framework facilita na gerao do cdigo a realizao dos testes automatizados


com apresentao de resultados.

Ao utilizar a ferramenta, possvel criar rapidamente e automaticamente um


teste para cada mtodo de uma classe, gerando assim um script de teste em questo de
segundos. Cada verificao de mtodo aferida de modo a avaliar se mediante entradas
definidas e resultados esperados a classe funciona da forma esperada.

Uma vez feito isso, os testes so executados rapidamente sem que, para isso, seja
interrompido o processo de desenvolvimento. Ao final, o JUnit checa os resultados dos
testes e fornece uma resposta imediata exibindo possveis falhas.

Alm disso, permite criar uma hierarquia de testes que possibilitar testar apenas
uma parte do sistema ou todo ele.

Somado a isso, o JUnit amplamente utilizado pelos desenvolvedores da


comunidade cdigo-aberto, possuindo um grande nmero de exemplos online que
podem ajudar qualquer iniciante nessa rea de automao.

3.4.2. Selenium 2.0

Selenium 2.0, ou Selenium WebDriver como tambm conhecido, um


framework multi-plataforma para testes de interface em aplicaes web desenvolvidos
por Jason Huggins em 2004.

O software possui sua prpria IDE (Selenium IDE) para gravao e execuo de
scripts de teste, que o usurio pode utilizar sem qualquer conhecimento de linguagens
de programao. O Selenium IDE consiste em um plugin do navegador Firefox.

19
Figura 4 Selenium IDE

A gravao de testes funciona de maneira simples: basta executar o caso de teste


manualmente enquanto o IDE armazena todos os passos seguidos.

Feito isso, o tester pode utilizar o prprio IDE para executar o plano de teste
utilizando o Firefox como navegador de teste ou exportar os testes em alguma das
linguagens possveis e execut-lo no seu prprio IDE com o navegador que desejar.

Figura 5 Exportao de casos de testes

20
O IDE permite o gerenciamento de vrios casos de testes, alm de viabilizar a
criao de um plano de teste que possua vrios casos de teste inclusos.

3.4.3. Jenkins

Jenkins uma aplicao de cdigo aberto escrita em Java que implementa o


conceito de Integrao Contnua.

O conceito de Integrao Contnua pode ser facilmente entendido citando Martin


Fowler: Integrao Contnua uma pratica de desenvolvimento de software onde os
membros de um time integram seu trabalho frequentemente, geralmente cada pessoa
integra pelo menos diariamente podendo haver mltiplas integraes por dia. Cada
integrao verificada por um build automatizado (incluindo testes) para detectar erros
de integrao o mais rpido possvel. Muitos times acham que essa abordagem leva a
uma significante reduo nos problemas de integrao e permite que um time
desenvolva software coeso mais rapidamente. [6].

Seguindo esse conceito, o Jenkins atua monitorando a execuo de tarefas do


dia-a-dia de desenvolvimento alertando aos responsveis caso algo inesperado ocorra.

Dessa forma, o Jenkins se foca basicamente em:

Construir builds de softwares continuamente onde se encarrega de gerar um


build para seu software no intervalo de tempo desejado ou aps algum evento
desejado.
Rodar testes
Executar tarefas externas possuindo completa integrao com diversos
sistemas operacionais, possvel programar o Jenkins para executar qualquer
tarefa externa sendo ela local ou remota
Alertar usurios em casos de falhas ao executar qualquer das outras tarefas
citadas acima o Jenkins pode ser utilizado para disparar um e-mail para os
responsveis pelos sistemas alertando possveis falhas.

Para executar todas essas tarefas o Jenkins dispe de uma base de milhares de
plugins, os quais so utilizados para comunicar o servidor da aplicao com os outros
servios necessrios.

21
3.4.4. Git

Git um software livre de controle de verso distribudo desenvolvido por Linus


Torvalds para o desenvolvimento do Linux Kernel (ncleo do Linux). Consiste em um
sistema de gerenciamento de cdigo fonte que visa acelerar o desenvolvimento.

O Git funciona atravs da criao de um ou mais repositrios que possuem


histrico completo e habilidade total de acompanhamento das revises, no dependente
de acesso a uma rede ou a um servidor central.

3.4.5. GitHub

GitHub um servio online de armazenamento compartilhado para projetos de


software que utiliza o sistema de controle de versionamento Git. escrito em Ruby on
Rails pelos desenvolvedores da empresa Chris Wanstrath, PJ Hyett e Tom Preston.

3.4.6. Eclipse

Eclipse um IDE para desenvolvimento na linguagem Java. O projeto Eclipse


foi iniciado na IBM que desenvolveu a primeira verso do produto e doou-o
como software livre para a comunidade. Apesar de ser feito para o desenvolvimento em
Java, o IDE suporta vrias outras linguagens a partir de plugins.

3.4.7. Ant

Apache Ant uma biblioteca Java e uma ferramenta de linha de comando com
objetivo de conduzir processos descritos em arquivos de build. O principal uso do Ant
consiste em construir builds de aplicaes Java.

Ant fornece uma srie de tarefas que podem ser feitas durante a construo do
build de uma aplicao tais como: compilar, testar e executar outras aplicaes Java.

A biblioteca do Apache Ant j vem automaticamente na instalao de algumas


IDE como por exemplo o Eclipse Luna, que ser utilizado durante o estudo de caso
deste projeto.

22
Captulo 4
Online Bank Management System
Neste captulo, veremos um pouco do software que servir de caso de estudo
para a automatizao de testes deste projeto.

4.1. Definio

Online Bank Management System consiste em um sistema bancrio


simplificado desenvolvido por Tousif Khan, disponvel para download no site
TechZoo[1]. O projeto tem fins educacionais visando ajudar iniciantes que desejam
aprender a utilizar Java Server Pages (ou JSP como usualmente conhecido).

O software consiste em uma pgina, na qual qualquer usurio pode se cadastrar


para criar sua prpria conta bancria. Aps uma simples validao de usurio e senha, o
usurio ter ao seu dispor algumas das mais corriqueiras aes bancrias como saques,
depsitos, transferncias, entre outros.

Este prottipo de banco online ser utilizado como exemplo para a automao de
testes em software a ser estudada posteriormente neste projeto.

4.2. Arquitetura

4.2.1. Aplicao Web

A aplicao web foi inteiramente desenvolvida em Java Server Pages (JSP).

JSP consiste em uma tecnologia que permite ao desenvolvedor de pginas


para Internet produzir aplicaes, que acessem a um banco de dados, geradas
dinamicamente, baseadas em HTML (neste caso) e utilizando a linguagem de
programao Java.

Para implantar e executar o Java Server Pages, um servidor web compatvel com
um container Servlet necessrio.

23
Figura 6 Modelo de comunicaao entre a pgina web, o servelet e o server
Fonte: Relationship between Servlet and JSP [3]

Essa comunicao (descrita na figura 6) ocorre de maneira que sempre que um


cliente fizer um pedido, fazendo o cadastro no site, por exemplo, ele ser enviado para o
servidor web como um pedido HTML. O servidor web (atravs do container servlet) ir
traduzir esse pedido HTML para JSP, execut-lo e devolver uma resposta em HTML
para o cliente.

Nesse caso utilizamos o Apache Tomcat, que o IDE Netbeans 8.0 possui, como
servidor web.

4.2.2. Banco de dados

A aplicao utilizou um banco de dados Microsoft Access para armazenar todas


as informaes relevantes de seus processos.

Banco de Aplicao
ODBC Java
Dados Access Ponte ODBC - JDBC
Driver
(.mbd) JDBC API

(
Figura 7 Modelo de comunicao entre a aplicao Java e o banco ODBC

24
Como se pode verificar na figura 7, a aplicao faz pedidos atravs da biblioteca
JDBC (Java Database Connectivity), que por meio de uma ponte JDBC ODBC
alcana o driver da ODBC (Open Database Connectivity) da Microsoft, que acessa o
banco de dados Microsoft Access encontrado no interior de um arquivo de extenso
mdb.

4.3. Fluxos de funcionamento do Sistema

O Sistema basicamente composto por 9 telas diferentes. Abaixo ser explicado


o funcionamento esperado de cada uma delas.

4.3.1. Autenticao

Ao acessar o endereo do site do banco, o usurio direcionado para a tela de


autenticao. O cliente que j possui cadastro no banco deve inserir seu usurio, sua
senha e clicar no boto Submit. Dessa forma ele ser direcionado para a tela de Boas
Vindas.

Figura 8 - Imagem ilustrando tela de autenticao

Caso o cliente esteja acessando o endereo do site pela primeira vez, ele deve
clicar em Click Here de modo a navegar para a tela de Cadastro de novo usurio.

4.3.2. Cadastro de novo usurio

Ao clicar no boto Click Here da tela de Autenticao, o novo cliente ser


redirecionado para a pgina de cadastro exibida abaixo:

25
Figura 9 - Imagem ilustrando tela de registro de novo usurio

Nessa tela, o usurio deve preencher os campos com seus dados pessoais e, ao
final, clicar em Create Account. Caso ele deseje apagar os dados inseridos, o cliente
deve clicar no boto Reset.

Aps a criao da nova conta, ser exibida uma mensagem de confirmao


informando que a conta foi criada com sucesso, ou seja, os dados foram inseridos no
banco. Em caso negativo, se houver algum problema de conexo com o banco de dados,
por exemplo, o cliente receber uma mensagem informando o insucesso.

4.3.3. Boas vindas

Nessa tela visualiza-se uma breve explicao dos servios que o software
Online Bank pretende oferecer aos seus clientes.

26
Figura 10 - Imagem ilustrando tela de boas vindas

No lado esquerdo nota-se um menu com todas as opes de aes que o cliente
pode executar no banco.

4.3.4. Criar conta

Ao clicar na opo Create Account o cliente indicado para a tela de criao


de conta bancria. Nessa tela, o usurio pode escolher o tipo de conta que ele pretende
abrir no banco e detalhar qualquer outra informao relevante dessa conta que ele deseje
armazenar.

Figura 11 - Imagem ilustrando tela de criao de conta

27
Ao pressionar o boto Create Account, o usurio dever receber uma
mensagem de confirmao da criao da nova conta ou de falha (em caso de algum
problema tcnico).

4.3.5. Depositar

Ao clicar na opo Deposite, o cliente indicado para a tela de depsito em


conta bancria. Nessa tela, o usurio pode escolher em qual conta ele pretende depositar
o dinheiro e qual o valor a ser depositado.

Figura 12 - Imagem ilustrando tela de depsito

Ao pressionar o boto Deposite Amount, o usurio dever receber uma


mensagem de confirmao do depsito ou de falha (em caso de algum problema
tcnico).

4.3.6. Sacar

Ao clicar na opo Do Withdraw, o cliente indicado para a tela de saque de


conta bancria. Nessa tela, o usurio poder escolher de qual conta ele pretende sacar o
dinheiro e qual o valor a ser sacado.

28
Figura 13 - Imagem ilustrando tela de saque

Ao pressionar o boto Withdraw Amount, o usurio dever receber uma


mensagem de confirmao de saque ou de falha (em caso de algum problema tcnico).

4.3.7. Verificar saldo

Ao clicar na opo Get Balance, o cliente indicado para a tela de verificao


de saldo da conta bancria. Nessa tela, o usurio poder escolher de qual conta ele
pretende visualizar o saldo.

Figura 14 - Imagem ilustrando tela de requisio de saldo

Ao pressionar o boto Check Balance, o sistema ir exibir o saldo na seguinte


tela:

29
Figura 15 Imagem ilustrando tela de exibio de saldo

4.3.8. Movimentao entre contas

Ao clicar na opo Transfer Amount, o cliente indicado para a tela de


transferncias bancrias. Nessa tela, o usurio poder escolher qual a conta de origem
da movimentao, a conta destino, qual o valor a ser movimentado e detalhar qualquer
outra informao relevante dessa movimentao que ele deseje armazenar.

Figura 16 - Imagem ilustrando tela de transferncias

Ao pressionar o boto Transfer Amount, o usurio dever receber uma


mensagem de confirmao da movimentao ou de falha (em caso de algum problema
tcnico).

30
4.3.9. Relatrio de movimentaes

Ao clicar na opo View Report, o cliente indicado para a tela de Relatrio


de movimentaes. Nessa tela, o usurio poder visualizar todo o histrico de
movimentaes executada no seu cadastro.

Figura 17 Imagem ilustrando tela do relatrio de movimentaes

4.4. Casos de testes

Por se tratar de um software educacional, sem relacionamentos cliente-


desenvolvedor, o desenvolvedor no se preocupou com a gerao de nenhum artefato ou
documento que explicasse corretamente os requisitos ou formas de uso do nosso
sistema. Assim sendo, todo o fluxo do sistema descrito acima foi deduzido
empiricamente.

Sem ter em mos nenhum documento de requisito ou de casos de uso, o que


seria altamente invivel em uma situao real, coube a anlise de testes desse sistema
basear os testes do software no fluxo do sistema j explicado.

Em um primeiro ponto, considerando que boa parte do sistema j est construda


focamos nossos casos testes na parte funcional do sistema, seguindo o modelo caixa
preta. Dessa forma, qualquer melhoria que venha a ser feita no sistema por um
desenvolvedor, protegeria o funcionamento do resto do sistema de qualquer insero de
defeitos.

Em segundo lugar, voltamos nossa ateno para o cdigo, de modo a criar


alguns testes caixa branca, para garantir o funcionamento dos principais mtodos do
sistema. Porm essa tentativa se mostrou improdutiva e falha.

31
Considerando que o projeto do Online Bank j estava implementado e
funcionando sem qualquer teste unitrio, a insero desse tipo de teste nos obrigaria a
alterar grande parte da estrutura de cdigo. Aps algumas anlises e estudo no cdigo,
conclumos no ser uma boa prtica a criao de testes unitrios para sistemas de cdigo
legado que no tenham tido qualquer preocupao com esse tipo de teste durante a sua
construo.

Por se tratar de uma ferramenta web, que seria exposta a qualquer pessoa do
mundo via internet, nos preocupamos em realizar casos de testes no-funcionais. Em
primeiro lugar, a portabilidade torna-se quase uma exigncia para qualquer sistema que
ser acessado via navegadores. Dessa forma, geramos testes de portabilidade de modo a
garantir o funcionamento do sistema em diversos navegadores utilizados ao redor do
mundo.

Alm disso, por se tratar de um sistema bancrio, a segurana deve ser vista
como uma das principais virtudes do sistema. Portanto, foram preparados casos de
testes que garantissem que o sistema seria seguro contra qualquer intruso.

Por fim, geramos casos de testes de modo a garantir o desempenho do nosso


sistema mediante a quantidade de usurios que o sistema viria a ter. Nesse ponto, por
esse projeto no visar testes reais, os nmeros de acessos considerados foram pequenos
e irreais usados apenas como caso de estudo.

Ainda discutindo desempenho, descartamos casos de testes de stress. Por se


tratar de um caso de estudo com poucos recursos de memria e desempenho, qualquer
valor obtido nesse tipo de teste no possuiria significado algum.

Todos os testes citados nesse captulo se encontram no Apndice A.

32
Captulo 5
Automao de Teste - Estudo de Caso
Neste captulo sero exemplificados, atravs de um estudo de caso, todos os
principais conceitos estudados para a realizao e automatizao de um projeto de
software de uma pgina web.

5.1. Viso Geral

O estudo que implementaremos consiste em uma aplicao de integrao


contnua na qual desenvolvedores e testadores podero trabalhar em conjunto, enquanto
testes automatizados sero executados sempre que uma nova verso de cdigo for
validada no repositrio.

A automao consiste em dois projetos separados: o primeiro diz respeito


aplicao em si (Online Bank) e o segundo trata-se de um projeto de testes.

O projeto de testes ser configurado com o construtor de arquivos Ant de modo


que sempre que uma nova build sua for construda, ele execute seus prprios testes
em seguida.

Por fim adicionaremos ambos os projetos no Jenkins de modo que a construo


do projeto de testes seja atrelada construo do projeto principal, gerando assim um
teste automatizado para todas as novas verses de cdigo para o programa principal.
Nos casos de falhas nos testes acionaremos os desenvolvedores atravs de um e-mail,
reportando que erros ocorreram na nova verso do Online Bank.

5.2. Implementao da automao de testes de Interface com o


Selenium

A utilizao do Selenium na automao de testes deste projeto teve como


objetivo testar todas as principais funcionalidades da interface do software com o
usurio final.

33
Dessa maneira, o principal foco desta etapa de testes foram os testes de sistema
(funcionais). Consequentemente, ao final da preparao de todo o projeto de teste, este
artefato se tornar um poderoso teste de regresso.

Como foi dito no captulo 3, onde foi explicado o funcionamento da ferramenta


Selenium WebDriver, utilizamos o Selenium IDE para gravar todos os casos de testes
no navegador Firefox.

Aps a gravao de todos os casos de testes, executamos todo o caderno de


testes (Test Suit) utilizando o prprio Selenium IDE de modo a aferir o funcionamento
de todos os testes, bem como se se os resultados dos testes condiziam com a realidade
do software. Por j possuirmos conhecimento da velocidade da execuo dos testes nos
projetos exportados pelo Selenium no formato de teste unitrio do JUnit, utilizamos a
velocidade mxima configurvel no Selenium IDE na execuo.

Figura 18 Configurao de velocidade do Selenium IDE

Dessa forma, podemos garantir que a velocidade de execuo do teste nesse


momento ser a mesma que a do JUnit, quando este executar os testes automticos
posteriormente.

Tendo feito isso, o prximo passo que tomamos foi a exportao dos casos de
teste do Selenium. A utilizao do conceito de Test Suit importante para a
organizao dos testes dentro do prprio Selenium IDE, porm no necessria ao se
exportar no formato do JUnit 4. O construtor Ant se encarregar de reunir todos os
casos de teste e execut-los.

Dessa maneira, exportamos somente os casos de teste gerando para cada um


deles um arquivo com nome do caso de teste e extenso .java.

Em seguida, tendo em posse todos os arquivos de teste, iniciamos a configurao


do IDE Eclipse, onde a soluo responsvel pela execuo dos testes da aplicao
principal (Online Bank) ser implementada.

34
Criamos, portanto, um novo projeto no Eclipse IDE, onde adicionamos todos os
arquivos de testes ao projeto.

5.3. Implementao da automatizao de testes com o Ant

Nesse ponto, j possumos todos os testes de interface previamente adicionados


em uma soluo do Eclipse. A seguir, devemos preparar o Eclipse e o projeto de testes
de modo a gerar um arquivo de construo (build.xml) que ir executar todos os testes
durante esse processo.

Primeiramente, iremos adicionar ao projeto todas as bibliotecas do Selenium


WebDriver (todos os arquivos .jar), que podem ser obtidos gratuitamente no site
oficial do software. Teremos, tambm, que adicionar a biblioteca do JUnit 4 ao projeto
de teste.

Tendo feito isso j ser possvel executar separadamente cada caso de teste
manualmente. Para isso, basta clicar com o boto direito do mouse no arquivo do caso
de teste (.java) e selecionar o caminho Run As -> JUnit Test, como pode ser visto na
figura abaixo:

Figura 19 Opo para executar os testes com o JUnit

O prximo passo que tomamos foi aferir a configurao do Ant Apache dentro
do Eclipse. Para isso, basta clicarmos na barra de ferramentas do Eclipse em Windows
-> Preferences e na janela de preferncias que se abrir quando selecionamos Ant ->
Runtime no menu do lado esquerdo.

35
Figura 20 Configuraes bsicas do Eclipse para utilizar o Ant

A aba Classpath deve possuir dentro de Ant Home Entries todos os arquivos
.jar de biblioteca do Ant Apache. Dentro de Global Entries deve constar o arquivo
tools.jar do Java Development Kit (JDK). Caso o Eclipse j no tenha essas
configuraes feitas por padro, devemos prepar-las manualmente antes de prosseguir.

Em seguida, criaremos o arquivo build.xml que utilizar o Ant Apache


descrito anteriormente. Para isso, basta clicar com o boto direito no nome do projeto e
selecionar a opo Export.

Figura 21 Gerao do arquivo build.xml

36
Feito isso, selecionamos dentro de General a opo Ant Builders e clicamos
em Next. Na tela seguinte verificamos se as configuraes do projeto, nome do
arquivo de build esto correto e clicamos em Finish. Desse modo, surgir no
projeto um arquivo com o nome build.xml.

Tendo gerado o arquivo de build com sucesso o nosso projeto j est pronto
para ser utilizado na integrao contnua do Jenkins, porm antes de avanarmos para
esse passo devemos testar localmente se a build ir testar a nossa aplicao
corretamente.

Para executarmos a build de modo semelhante a qual o Jenkins far


posteriormente clicamos com o boto direito no arquivo de build recm-gerado e
selecionamos Run As -> Ant Build. Em seguida visualizaremos a seguinte tela:

Figura 22 Configurao da execuo do arquivo build.xml

Nessa janela possvel selecionar os mtodos Ant que desejamos executar


durante a construo do projeto. Selecionamos as seguintes opes: build, todos os
casos de testes e a opo junit report. No campo Target execution order ordenamos

37
de maneira que a build seja feita antes dos testes e o junitreport seja feito aps.
Feito isso, clicamos em Run e aguardamos enquanto todos os nossos casos de teste
so executados no navegador Firefox automaticamente.

Ao fim dos testes, o JUnit ir criar uma pasta junit dentro do nosso projeto
com todos os resultados em forma de paginas HTML. Ao abrirmos a pgina
index.html podemos verificar se os resultados dos testes foram de acordo com o
esperado.

Figura 23 Resultados dos testes

5.4. Integrao Contnua com Jenkins

Com toda a soluo de testes construda e o arquivo de construo (build.xml)


configurado com o Ant (de modo que os testes podem ser executados durante a
construo), precisamos apenas configurar o Jenkins para iniciar o ciclo de integrao
contnua no projeto.

Primeiramente, sero necessrios alguns plugins do Jenkins. No menu de


gerncia de plugins deve ser efetuado o download dos seguintes plugins:

GitHub Plugin;
Ant Plugin;
JUnit Plugin;

Aps o download e a instalao dos plugins, devemos configurar os caminhos


do JDK e do Ant nas configuraes de sistema do Jenkins, como pode ser visto abaixo:

38
Figura 24 Configuraes dos caminhos do JDK e do Ant

Alm disso, ser necessrio que configuremos, na mesma pgina de


configurao de sistema, o servidor SMTP de envio de e-mails. No caso desse projeto
utilizamos o servio do gmail para realizar esse envio, como pode ser visto abaixo:

Figura 25 Configurao do servidor SMTP

Feito isso, o Jenkins j est com seu sistema devidamente configurado. Para
completarmos o ciclo de integrao basta que configuremos ambos os projetos como
Novos Jobs.

Para isso criamos um primeiro Job como um projeto de estilo livre no Jenkins
e o configuramos para construir builds do projeto principal Online Bank. Nesse
caso, foi utilizado o GitHub como repositrio para esse projeto.

39
Figura 26 Trigger do GitHub

Marcamos a opo acima para tornar automtica a gerao de builds sempre


que o desenvolvedor realizar um commit de um novo cdigo.

Por fim um segundo Job configurado. Este ser responsvel pelo projeto de
testes que criamos anteriormente.

O segundo Job tambm criado como projeto de estilo livre e configurado


para construir builds do projeto de testes Bank Selenium Test.

Figura 27 Configurao do Trigger

Como o projeto de testes deve ser executado logo aps cada construo do
projeto Online Bank, utilizamos o trigger descrito na figura 27 para acionar a
execuo desse projeto sempre que houver build estvel do projeto principal.

Figura 28 Configurao do Ant

Alm disso, devemos acionar todos os mtodos Ant das classes de teste geradas
para serem executadas durante a construo do build do projeto de testes, como
descrito na figura 28.

40
Figura 29 - Configurao do Relatrio de JUnit

So definidos tambm a origem e quais os arquivos que o relatrio dos testes do


JUnit utilizar para reportar os resultados dos testes. Isso pode ser observado na figura
29.

Figura 30 Configurao de e-mail

Por fim, configuramos a notificao de e-mail descrita na figura 30, na qual


definida quem deve ser acionado em caso de falhas na construo do projeto.

5.5. Manuteno do ciclo de Integrao Contnua (CI)

A manuteno do ciclo deve ser e foi construda de modo que ambos os projetos
(teste e desenvolvimento) possam evoluir sem que um atrapalhe o outro. Como vimos, a
ideia principal da automatizao reduzir esforos, logo seria inaceitvel que nosso
projeto tivesse um gargalo baseado na comunicao desenvolvedor-tester.

Os desenvolvedores tero total liberdade para avanar na codificao, tendo


sempre em mente que os testes so baseados na interface, ou seja, qualquer modificao
que afete isso resultar em uma verso falha do projeto.

Da mesma maneira os testers podem melhorar os casos de testes existentes ou


criar mais casos testando-os sempre na verso mais atual do cdigo.

41
Captulo 6
Resultados e Concluses
Neste captulo, apresentaremos uma anlise dos resultados obtidos com este
estudo sobre automao de testes na rea de software e as concluses tiradas baseadas
nesses resultados.

6.1. Resultados

Analisando todo o estudo que foi feito e o resultado atingido com a construo
da integrao contnua para desenvolvimento e teste do software Online Bank,
conclui-se que este projeto de graduao atingiu o resultado esperado.

Atravs desse estudo foi possvel chegar a um melhor entendimento dos


conceitos de testes, suas nomenclaturas e principais modelos.

Alm disso, adquirimos conhecimento sobre os diversos tipos de testes e seus


principais casos de aplicao. Somado a isso, entendemos experimentalmente, durante o
caso de estudo que nem todos os testes se aplicam em todas as situaes. Isso pode ser
percebido ao tentar inserir testes unitrios em um cdigo legado j em uso.

Ao longo do estudo de caso, conseguimos aprender sobre diversas ferramentas


de automao de software, entendendo seu funcionamento e configuraes.

Por fim, analisando a integrao que foi construda integrando o teste e o


desenvolvimento, acreditamos que o objetivo principal desse estudo foi obtido.

42
6.2. Concluso

Atravs do estudo apresentado por esse projeto foi possvel perceber que em
qualquer software, do mais simples ao mais complicado, sempre necessrio que sejam
definidos e executados testes antes da entrega para o usurio final. Tal afirmativa se
baseia nos princpios de qualidade que todo usurio deseja ter ao utilizar qualquer
ferramenta.

Somado a isso, percebemos que a premissa de que todo teste deve ser
automatizado se mostrou invlida. Automatizar tem grande valor na maioria dos casos,
porm existem situaes que sua insero encarece o projeto alm de requisitar uma
manuteno longa e constante. Dessa forma, nesses casos os testes manuais ainda so
mais efetivos e econmicos.

Dentro do universo de automao, fomos capazes de perceber que os testes de


regresso passam a ter um valor mais significante. Ao automatizar esse teste, o projeto
passar a ter um uma proteo contra a insero de novos defeitos que alerta prontamente
ao desenvolvedor.

Quanto ao estudo de caso, conclumos que teve imenso valor de aprendizado.


Apesar de o sistema bancrio utilizado ser extremamente simples, o que facilitaria a
resoluo de qualquer defeito que encontramos durante os testes, ele serviu como um
exemplo prtico representando um software mais complexo em uma situao real. E
mesmo sendo simples j foi possvel perceber a dificuldade que existe em se aplicar o
conceito de teste unitrio em projetos que j esto em andamento com cdigo legado.

Ao fim do estudo de caso, percebemos que o fato de utilizarmos o servidor


Apache TomCat vinculado ao Netbeans foi um facilitador. Porm em uma situao mais
real isso ter que ser automatizado tambm atravs do Jenkins.

43
Referncias
[1] Artigo Engenharia de Software - Introduo a Teste de Software, disponvel em
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-
software/8035(acessado em 23/11/2014).

[2] Understanding White box Testing and Black box Testing Approaches, disponvel
em http://blog.testing-whiz.com/2011/11/understanding-white-box-testing-
and.html(acessado em 23/11/2014).

[3] Relationship between Servlet and JSP, disponvel em


http://www.herongyang.com/JSP/Servlet-Relationship-between-Servlet-and-
JSP.html(acessado em 26/11/2014).

[4]STERLING, B. The Hacker Crackdown: Law and Disorder on the Electronic


Frontier. Bantam Books, 1992

[5]BOEHM, BARRY W. and PHILIP N. PAPACIO. Understanding and Controlling


Software Costs, IEEE Transactions on Software Engineering, v. 14, no. 10, October
1988, pp. 1462-1477.

[6]FOWLER, MARTIN. Continuous Integration,


http://martinfowler.com/articles/originalContinuousIntegration.html (acessado em
23/11/2014).

44
Bibliografia
Artigo Engenharia de Software - Introduo a Teste de Software,
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-
software/8035 (Acessado em 23/11/2014).

Understanding White box Testing and Black box Testing Approaches,


http://blog.testing-whiz.com/2011/11/understanding-white-box-testing-and.html
(Acessado em 23/11/2014).

Testes de unidade com JUnit,


http://www.devmedia.com.br/testes-de-unidade-com-junit/4637 (Acessado em
23/11/2014).

Testes de Integrao com Java e JUnit,


http://www.devmedia.com.br/testes-de-integracao-com-java-e-junit/25662 (Acessado
em 23/11/2014).

JUnit - Implementando testes unitrios em Java Parte I,


http://www.devmedia.com.br/junit-implementando-testes-unitarios-em-java-parte-
i/1432 (Acessado em 23/11/2014).

Understanding White box Testing and Black box Testing Approaches,


http://blog.testing-whiz.com/2011/11/understanding-white-box-testing-and.html
(Acessado em 23/11/2014).

TechZoo,
http://www.techzoo.org/projects/online-bank-management-system-project-in-java.html
(Acessado em 23/11/2014).

45
Apndice A
Casos de Teste
Caso de Teste: 001 Criar Usurio

Objetivo: Validar a criao de novos usurios.

Precondies:

Ter acesso pgina inicial do site Online Bank


(http://localhost:8084/Bank);

Step: Ao: Resultado esperado:

1 Clicar na opo Click Here Sistema deve navegar at a pgina para


logo aps a mensagem Want to registro de novo usurio.
create a new account?.

2 Preencha os campos: Todos os campos devem ser apagados.


Username, Password,
Address, E-mail e Mobile
com valores vlidos. Escolha
uma pergunta secreta em
Security Question e preencha
uma resposta em Answer.

Clique em Reset.

3 Preencha os campos: Sistema navega para uma tela com a


Username, Password, confirmao de criao de usurio
Address, E-mail e Mobile exibindo a seguinte mensagem:
com valores vlidos. Escolha Account is Created Successfully.
uma pergunta secreta em Click Here to Login and Acticvate Your
Security Question e preencha Account..
uma resposta em Answer.

46
Clique em Create Account.

4 Clique em Click Here. Sistema redireciona para a tela inicial


de Login.

5 Preencha o Login com o Sistema autentica o usurio e mostra a


Username recm-criado e seu tela inicial da conta do usurio.
respectivo Password.

Clique em Submit.

6 Clique em LogOut. Sistema redireciona para a tela inicial


de Login.

Resultados:

Comentrios:

Caso de Teste: 002 Navegabilidade sem conta bancria

Objetivo: Validar navegabilidade no site sem possuir nenhuma conta bancria.

Precondies:

Ter efetuado Login com um usurio que no possua contas no banco;

Step: Ao: Resultado esperado:

1 Clique na opo Deposite. Sistema deve navegar para uma nova


tela informando que o usurio no
possui conta bancria com a seguinte
mensagem: Your do not have any
account created.
To create Your Account Click Here.
Or to Log out Click Here.

2 Clique na opo DoWithdraw. Sistema deve navegar para uma nova


tela informando que o usurio no

47
possui conta bancria com a seguinte
mensagem: Your do not have any
account created.
To create Your Account Click Here.
Or to Log out Click Here.

3 Clique na opo Get Balance. Sistema deve navegar para uma nova
tela informando que o usurio no
possui conta bancria com a seguinte
mensagem: Your do not have any
account created.
To create Your Account Click Here.
Or to Log out Click Here.

4 Clique na opo Transfer Sistema deve navegar para uma nova


Amount. tela informando que o usurio no
possui conta bancria com a seguinte
mensagem: Your do not have any
account created.
To create Your Account Click Here.
Or to Log out Click Here.

5 Clique na opo View Report. Sistema deve navegar para uma nova
tela informando que o usurio no
possui conta bancria com a seguinte
mensagem: Your do not have any
account created.
To create Your Account Click Here.
Or to Log out Click Here.

6 Clique na opo Click Here Sistema deve ser redirecionado para tela
que efetuar o Log out. de Login.

7 Efetue novamente o Login com Sistema deve navegar para uma nova
o mesmo usurio. tela informando que o usurio no
possui conta bancria com a seguinte

48
mensagem: Your do not have any
Clique novamente na opo
account created.
View Report.
To create Your Account Click Here.
Or to Log out Click Here.

8 Clique na opo Click Here Sistema navega para a tela Create


para criar nova conta bancria. Account.

Resultados:

Comentrios:

Caso de Teste: 003 Criar conta bancria

Objetivo: Validar a criao de conta bancria.

Precondies:

Ter efetuado Login com um usurio;

Step: Ao: Resultado esperado:

1 Clique na opo Create Sistema navega para a tela Create


Account. Account com os campos Account
Holder Name e Account Number
previamente preenchidos e
desabilitados para edio.

2 Selecione um tipo de conta em A conta criada com sucesso e o


Account Type e escreva algum Sistema navega at uma pgina de
comentrio em Account confirmao com a seguinte mensagem:
Details. Your account is successfully created.
and Account No. is <Account
Clique em Create Account
Number>.
To Deposit Amount in Your
Account Click Here
To Withdraw From Account Click

49
Here.

Resultados:

Comentrios:

Caso de Teste: 004 Depositar

Objetivo: Validar depsitos na conta bancria.

Precondies:

Ter efetuado Login com um usurio;

Step: Ao: Resultado esperado:

1 Clique em Deposite Sistema navega para a tela Deposite


com o campo Account Holder Name
previamente preenchido e desabilitado
para edio.

2 Selecione o nmero de uma O depsito efetuado com sucesso e o


conta em Account Number e Sistema navega at uma pgina de
defina o valor que ser confirmao com a seguinte mensagem:
depositado no campo Deposite Your Amount is Successfully
Amount Deposited into Acount. Your current
Balance is: <$$> Rs.
Clique no boto Deposite
To Deposit Amount in Your
Amount.
Account Click Here
To Withdraw From Account Click
Here.

Resultados:

Comentrios:

50
Caso de Teste: 005 Saques

Objetivo: Validar saques na conta bancria.

Precondies:

Ter efetuado Login com um usurio;

Step: Ao: Resultado esperado:

1 Clique em Do Withdraw Sistema navega para a tela Withdraw


com o campo Account Holder Name
previamente preenchido e desabilitado
para edio.

2 Selecione o nmero de uma O saque efetuado com sucesso e o


conta em Account Number e Sistema navega at uma pgina de
defina o valor (que exista na confirmao com a seguinte mensagem:
conta) que ser sacado no campo Your Amount is Successfully
Withdraw Amount Withdraw from Acount.
To Deposit Amount in Your
Clique no boto Withdraw
Account Click Here
Amount.
To Withdraw From Account Click
Here.

Resultados:

Comentrios:

Caso de Teste: 006 Balano

Objetivo: Validar visualizao de balano da conta bancria.

Precondies:

Ter efetuado Login com um usurio;

Step: Ao: Resultado esperado:

51
1 Clique em Get Balance Sistema navega para a tela Get
Balance com o campo Account
Holder Name previamente preenchido
e desabilitado para edio.

2 Selecione o nmero de uma O sistema atualiza a pgina exibindo o


conta em Select Account No.. saldo atual da conta no campo Current
Balance, seguido pela seguinte
Clique no boto Check
mensagem: Your Amount is
Balance.
Successfully Withdraw from Acount.
To Deposit Amount in Your
Account Click Here
To Withdraw From Account Click
Here.

Resultados:

Comentrios:

Caso de Teste: 007 Transferncias

Objetivo: Validar transferncias de conta bancria.

Precondies:

Ter efetuado Login com um usurio;


Existirem ao menos 2 contas bancrias no sistema;

Step: Ao: Resultado esperado:

1 Clique em Transfer Amount Sistema navega para a tela Transfer


Amount com o campo Account
Holder Name previamente preenchido
e desabilitado para edio.

2 Selecione o nmero de uma A transferncia efetuada com sucesso

52
conta origem da transferncia e o Sistema navega at uma pgina de
em Select Source Account confirmao com a seguinte mensagem:
No., selecione o nmero de Your Amount <$$> is Successfully
uma conta destino da Transfer to Acount <Account
transferncia em Select Number>. To Deposit Amount in Your
Destination Account No., Account Click Here
defina o valor (disponvel na To Withdraw From Account Click
conta) que ser transferido no Here.
campo Amount e defina algum
comentrio para a transao em
Details.Clique no boto
Transfer Amount.

Resultados:

Comentrios:

Caso de Teste: 008 Relatrio

Objetivo: Validar gerao de relatrio de transaes.

Precondies:

Ter efetuado Login com um usurio;


Ter ao menos uma conta com esse usurio com ao menos uma transao
realizada;

Step: Ao: Resultado esperado:

1 Clique em View Report O Sistema exibe uma tela com todas as


transaes j executadas exibindo as
colunas: Acc No., Operation,
Amt, Balance e Date Time.

Resultados:

Comentrios:

53
54