You are on page 1of 16

MINISTRIO DA EDUCAO

SECRETARIA DE EDUCAO MDIA E TECNOLGICA


INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA DE
RORAIMA
Campus Boa Vista

Integrante 01
Integrante 02
Integrante 03
Integrante 04
Integrante 05

TESTE DE REGRESSO DE SOFTWARE

Trabalho de avaliao apresentado na


disciplina de Engenharia de Software I do
curso superior em Anlise e
Desenvolvimento de Sistemas do Instituto
de Educao e Tecnologia de Roraima
como requisito complementar avaliativo.
Orientador(a): Prof.(a) Esp. Denise de
Andrade

Boa Vista, Roraima, Brasil


2017
RESUMO

Este trabalho apresenta uma viso geral sobre teste de software e a importncia de sua
aplicao nas etapas de criao de uma aplicao, abordando de forma mais profunda o
processo de desenvolvimento dirigido testes (TDD, do ingls Test-Drive Development) que
abrange entre alguns benefcios o uso e melhoria dos teste de regresso.
Os teste de regresso sero discutido e esmiuados detalhadamente, abordando as etapas
de aplicao e benefcios gerados por sua implementao. O desenvolvimento de uma aplicao
experimental ser uma parte importante ao entendimento de como devem ser realizado um
roteiro de teste de software, assim como identificao do que deve ou no ser planejado e
testado.
O uso de ferramentas que auxiliem nas etapas do teste de regresso tomara por base a
ferramenta JUnit disponvel para ambientes de desenvolvimento JAVA, ambiente o qual ser
desenvolvido a aplicao de base de testes.
SUMARIO
INTRODUO

O teste de software um processo de execuo de um produto para determinar se ele


atingiu suas especificaes e funcionou corretamente no ambiente ao qual ele foi projetado,
revelando falhas do produto para que a causa destas falhas sejam identificadas e corrigidas pela
equipe de desenvolvimento antes da entrega final. Por conta dessa caracterstica dizemos que
sua natureza destrutiva e no construtiva, de forma que visa o aumento da confiana de
um produto atravs da exposio de seus problemas antes da sua entrega ao usurio final.
O objetivo principal do teste de software demostrar ao desenvolvedor e ao cliente que
o software atende aos seus requisitos e descobrir situaes em que o software se comporta de
maneira incorreta, indesejada ou diferente das especificaes. Os teste de software porem no
podem demostrar que o software livre de defeitos ou se seu comportamento ser como o
especificado em qualquer situao, como afirmou Edsger Dijkstra, um dos primeiros
colaboradores da engenharia de software (DIJKSTRA et al. 1972):
Os teste podem mostrar apenas a presena de erros, e no sua ausncia
O teste de software parte de um amplo processo de verifica e validao, ao qual ideal
para identificar se estamos construindo o produto certo e de maneira certa, de forma a garantir
que o software est pronto para seu propsito. Fagan (1960) relata que mais de 60% dos erros
poderiam ser detectados por meio de inspees informais no cdigo fonte de um programa,
porem as diferentes interaes entre partes de um programa geram defeitos que no so to
facilmente detectados atravs de inspees, dar-se ai a necessidade dos teste de software.
Na prtica o processo de teste de software envolve uma mistura de teste manuais e
automatizados. O Desenvolvimento Dirigido a Teste (TDD) compem uma desta etapa, ao qual
voc desenvolve um cdigo de forma incremental. A prxima etapa de desenvolvimento do
software s ser alcanada aps o cdigo desenvolvido atualmente ter passado nos testes. Um
argumento forte a favor do Desenvolvimento Dirigido a Teste que ele ajuda os programadores
a compreender exatamente o que determinado segmento do software deve fazer.
Um dos grandes benefcios do Desenvolvimento Dirigido a Teste que ele reduz os
custo dos teste de regresso, testes estes que so realizados em um programa previamente
testado aps alguma modificao feita, de forma a assegurar que defeitos no tenham sido
introduzidos ou mascarados nas reas no alteradas do software como resultado da referida
modificao.
1. TESTE DE REGRESSO UMA ABORDAGEM CONCEITUAL

Teste de regresso um conjunto de teste realizados de forma incremental enquanto


um programa desenvolvido (SOMMERVILLE, 2011). Em poucas palavras, devemos
garantir que a funcionalidade de um software j testado, continue a funcionar aps o mesmo
sofrer alguma implementao ou manuteno.
Neste ponto o teste de regresso se mostrar muito importante para a garantia do
software entregue, pois devemos evitar que uma funcionalidade que o cliente j utiliza no
deixe de funcionar uma vez que o software sofra uma atualizao da verso.
Normalmente este tipo de teste realizado por meio de um ferramenta de automao,
a falta de tempo ou indisponibilidade de pessoal da equipe faz com que muitas vezes este
teste seja deixado em segundo plano. Porem este um erro grave, nos teste de regresso
costumam encontrar mais erros que a primeira verificao, isso se d pela maior
familiaridade com o sistema, de forma que defeitos que passaram despercebidos possam ser
solucionados.
O roteiro para os teste de regresso podem ser de trs tipo:

Casos de teste que abrangem toda funcionalidade do sistema.


Casos de teste apenas para as funcionalidade que foram modificadas.
Novos casos de teste para as funcionalidades que foram afetadas pela mudana.

2. IDENTIFICANDO ETAPAS PARA TESTES DE REGRESSO

Uma boa abordagem fundamental para que o teste de regresso seja executado de
forma eficiente, uma identificao pontual onde estes teste devem ser realizados reduz
tempo e custo de produo e garante que o produto ser entregue o mais breve possvel ao
cliente, so elas:

Rastreabilidade: Identifica quais funcionalidades podem ser afetadas por


um mudana no software.
Rotinas crticas: Identifica junto ao cliente quais so as rotinas mais
utilizadas por ele, dentre essas definir quais so as crticas, as quais de
maneira alguma devem apresentar problemas.
Teste redundantes: Identifica teste que realizam as mesma execuo no
software de forma a no acrescentar nada de novo, aos quais devem ser
evitados.
Teste que falharam: Identificar teste que falharam em verses anteriores do
software, e incluir sua execuo nos teste de regresso de forma a evita sua
recorrncia.
Automatizao de testes: Consiste no uso de ferramenta que auxiliem a
execuo dos testes planejados nas etapas de regresso.
3. UTILIZANDO TESTE DE REGRESSO EM UMA APLICAO ORIENTADA A
OBJETOS

Quando se desenvolve um programa orientado objetos, o teste de regresso pode


ser aplicado em algumas de suas etapas de desenvolvimento, as quais so:

Quando um nova subclasse e desenvolvida


Quando uma superclasse alterada
Quando uma classe servidora alterada
Quando uma correo de falha realizada
Quando uma classe reusada em um novo contexto
Com base neste aspectos foi desenvolvida uma aplicao simples no ambiente
Eclipse, de forma a representa algumas destas etapas. A aplicao se baseia em um
aplicativo de cadastro de cliente de um banco, ao qual deve armazenar nome, telefone de
contato e CPF.
Inicialmente o software vai aceitar todas entradas de dados do usurio, o que pode
gerar falhas caso um campo como o de telefone que aceita apenas nmeros inteiros receba
outro tipo primitivo de dados. Esta parte deve ser ento atualizada e inserida novamente no
cdigo da aplicao.
O campo CPF na primeira verso do aplicativo no realizar nenhuma verificao de
validao, o que significa que podemos eventualmente estar armazenando dados
inconsistentes. Para corrigir tal falha deve-se criar uma classe especifica para teste do
nmero do CPF, e verificar assim se valido ou no sua insero no sistema.
U novo campo deve ser includo no sistema, o campo de endereo, deve-se portanto
criar uma nova classe e verificar se o sistema ir se comporta de mesma forma aps a
incluso da mesma. Veja o diagrama de caso de uso do sistema:
Observe que as funcionalidades so bem simples, resumindo-se basicamente em
operaes padres de um banco de dados, insero, pesquisa e remoo.
Veja o diagrama de classe da aplicao antes de inserimos as atualizao do sistema:

As modificaes implementadas iro se caracterizar por mtodos de verificao


adicional na funo criar (), e por um novo campo de insero de endereo na classe Cliente.

3.1. REALIZANDO UM ROTEIRO DE TESTES

Um roteiro de testes um maneira de realizar teste manuais em softwares, a partir


da documentao de especificao de determinado caso de uso, de forma que o testador
possa seguir um sequncia de passos de forma prtica.
O projetista de teste identifica as funcionalidades da aplicao que devem receber o
teste e quais os tipos de teste sero aplicados (funcionalidade, carga, desempenho). Define-
se um objetivo que deve ser alcanado, podendo ter ou no um pr-condio que indica o
que necessrio para sua realizao.
importante explorar mentalmente as diversas maneiras de utilizar a aplicao,
tentando fazer com que a mesma levante todas excees, provoca-la para que ela d
mensagens de erro, imaginar de que maneira as funcionalidades poderiam apresentar um
comportamento inesperado.
Abaixo definimos os casos de testes a serem realizados seguindo o roteiro de teste:

Caso de teste 01 - Objetivo: O sistema deve guardar informaes do


nmero de telefone do usurio
Pr-condio: O usurio deve estar na tela de insero de telefone
1.
1. Fornea o nmero do 2. A aplicao deve prosseguir
telefone e confirme a para a etapa do cadastro de
operao endereo

Procedimento de Teste Resultado Esperado

Caso de teste 02 - Objetivo: O sistema deve guardar apenas informaes


vlidas de CPF fornecidas pelo usurio
Pr-condio: O usurio deve estar na tela de insero de CPF
2.
1. Fornea o nmero de CPF e 2. A aplicao deve prosseguir
confirme a operao para a etapa de cadastro de
nmero telefnico

Procedimento de Teste Resultado Esperado

Caso de teste 03 - Objetivo: O sistema deve prov acesso as


funcionalidades de insero dos dados do campo de endereo
Pr-condio: O usurio deve estar na tela de insero de endereo
3.
2. Fornea as informaes do 3. A aplicao deve finaliza a
endereo e confirme a operao de cadastro
operao

Procedimento de Teste Resultado Esperado


Como no foi implementado a incluso da classe Endereo vamos concentra, nossa
tabela de dados de teste nos dois primeiro casos de teste. A tabela e uma representao dos
dados de teste que sero inseridos no programa de forma a fora sua execuo normal ou no
dependendo de como o sistema ir tratar as entrada de dados:
Tabela de caso de teste 01 (antes da verificao)
N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 verificar
Teste 02 Joo 45553451222 aaaaaaaaaa verificar
Teste 03 Fernando 12345667812 1,678 verificar
Teste 04 Lucas 23456678122 @#!!! verificar
Teste 05 Pierre 12312312311 10^20 verificar

Resultados obtidos na realizao dos testes:

Tabela de caso de teste 01 (antes da atualizao do sistema)


N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 No encontrados
Teste 02 Joo 45553451222 aaaaaaaaaa NumberFormatException
Teste 03 Fernando 12345667812 1,678 NumberFormatException
Teste 04 Lucas 23456678122 @#!!! NumberFormatException
Teste 05 Pierre 12312312311 10^20 NumberFormatException

Aps a atualizao do sistema com a incluso da classe Atualizao e do mtodo


numeroException (), responsvel pelo tratamento das excees da entrada de dados no campo
telefone:
Tabela de caso de teste 01 (Aps a atualizao do sistema)
N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 No encontrados
Teste 02 Joo 45553451222 aaaaaaaaaa Corrigidos
Teste 03 Fernando 12345667812 1,678 Corrigidos
Teste 04 Lucas 23456678122 @#!!! Corrigidos
Teste 05 Pierre 12312312311 10^20 Corrigidos

O sistema passa a no aceita qualquer entrada que no seja do tipo inteiro, solicitando
em caso de erro, que o usurio reinsira os dados novamente, para assim prosseguir com seu
funcionamento normal.
Vamos agora testa o campo de entrada de CPF, vale ressalta que um CPF vlido
resultado de um clculo matemtico, este qual ser feito por nossa aplicao de forma a garantir
que o CPF fornecido seja corrigido ou no pelo sistema.
Tabela de caso de teste 02 (antes da verificao)
N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 verificar
Teste 02 Joo 45553A51222 986194567 verificar
Teste 03 Fernando 1.2345667812 981194568 verificar
Teste 04 Lucas @#$%!!!!!!!!! 981198867 verificar
Teste 05 Pierre 10^20 981194561 verificar

Resultados obtidos na realizao dos testes:

Tabela de caso de teste 02 (antes da atualizao do sistema)


N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 No encontrados
Teste 02 Joo 45553A51222 986194567 No encontrados
Teste 03 Fernando 1.2345667812 981194568 No encontrados
Teste 04 Lucas @#$%!!!!!!!!! 981198867 No encontrados
Teste 05 Pierre 10^20 981194561 No encontrados

O sistema aceitou todas entradas de dados fornecidas, porm sabemos que muitas desta
entradas de dados so invlidas, vejamos como o sistema trata esses mesmo dados aps a
atualizao e uso do mtodo cpfException ().
Tabela de caso de teste 02 (Aps a atualizao do sistema)
N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 Corrigidos
Teste 02 Joo 45553A51222 986194567 Corrigidos
Teste 03 Fernando 1.2345667812 981194568 Corrigidos
Teste 04 Lucas @#$%!!!!!!!!! 981198867 Corrigidos
Teste 05 Pierre 10^20 981194561 Corrigidos

Resta apenas implementar o campo endereo na classe Cliente, vamos usar duas
entradas vlidas para verificar como ficou a sada de dados da aplicao:
Tabela de caso de teste 03 (Aps a atualizao do sistema)
N Nome CPF Telefone Erros
Teste 01 Ana 12345667812 981194567 Corrigidos
Teste 02 Joo 11122233561 986194567 Corrigidos

Inserido os dados de endereo:


N Rua Bairro Cidade Estado Erros
Teste 01 Campinas Nova Cidade Boa Vista Roraima verificar
Teste 02 Rio Nilo Bela Vista Boa vista Roraima verificar

Aps inserirmos os dados vamos realizar a busca dos dados no sistema e verificar se
realmente ser exibido os dados de endereo fornecidos.
Sada de tela:

Observe que a aplicao est realizando o tratamento adequado do campo CPF, caso
seja encontrado um CPF invlido o sistema automaticamente fornece uma opo vlida
(somente para teste claro).
Nosso diagrama de classe aps atualizao ficou assim:

Aps as verificaes e notvel que nosso sistema continuou a operar normalmente aps
ser realizando o tratamento e as atualizaes das Classes, dizemos assim que o teste de regresso
foi bem sucedido e no houve regresso do sistema.
4. CDIGO DA APLICAO (JAVA)
5. JUNIT

O JUnit uma ferramenta open source, criado por Erick Gamma e Kent Beck, com
suporte criao de teste automatizados em na linguagem de programao JAVA.
Este framework facilita a criao de cdigo para a automao de teste unitrios com a
apresentao dos resultados. Com ele pode ser verificado se cada mtodo de uma classe
funciona da forma esperada, exibindo possveis erros e falhas, podendo ser usando tanto para
bateria de teste como para extenso.
Vantagens do JUnit:
Permite a criao rpida de cdigo de teste possibilitando um aumento na qualidade do
desenvolvimento e teste;
Amplamente utilizado pelos desenvolvedores da comunidade cdigo-aberto, possuindo
um grande nmero de exemplos;
Uma vez escritos, os testes so executados rapidamente sem que, para isso, seja
interrompido o processo de desenvolvimento;
JUnit checa os resultados dos testes e fornece uma resposta imediata;
JUnit livre e orientado a objetos.
CONCLUSO

O teste de software uma das atividades mais custosas no desenvolvimento de software,


pois envolve uma quantidade significativa de recursos. Aplicaes crticas requerem testes
rigorosos enquanto outras nem tanto, cada caso vai depende do ambiente para o qual foi
projetado.
O planejamento e a anlise dos resultados so fundamentais para que os testes sejam
projetados e aplicados com sucesso, o apoio em ferramentas importante para reduo de
esforo. Testes como os de regresso so caraterizados por serem um dos mais importantes no
desenvolvimento de softwares modernos, porm notvel que a realizao de teste repetitivos
em todas as funcionalidade de um aplicao no to simples.
O Desenvolvimento Dirigido a Teste se torna uma tima abordagem nos teste de
regresso, desenvolva e teste a aplicao, modifique e teste a aplicao, se tudo est
funcionando normalmente avance, seno reavalie o cdigo e realize os teste novamente.
Vale ressalta que no existe uma abordagem padro, cada aplicao possuem diferentes
tcnicas de teste a serem aplicadas, cada qual com suas caractersticas especificas que devem
ser consideradas no momento da realizao dos teste.
Mesmo um programador iniciante pode ter o bom hbito de criar aplicaes analisando
as diversas maneiras comportamentais que seu software pode tomar, e conforme avance em seu
desenvolvimento, trata essas variaes de forma adequada. Resolver um problema pequeno e
simples, ento uma boa dica nunca deixe a fase de teste apenas as vsperas do lanamento de
um produto, corrigir os defeitos ao longo das etapas de produo de uma aplicao bem menos
trabalhosa.

You might also like