Вы находитесь на странице: 1из 63

CEDESC Curso de Especializao em Desenvolvimento de Software PETROBRAS

Verificao, Validao e Testes: Teste de Software


Guilherme Horta Travassos
www.cos.ufrj.br/~ght

Grupo de Engenharia de Software Experimental

http://ese.cos.ufrj.br

Roteiro
Mdulo I: Conceitos e Definies de Teste de Software Mdulo II:Tcnicas de Teste de Software Mdulo III: Estratgias para Projeto e Execuo dos Testes Mdulo IV: Planejamento e Controle de Testes de Software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulo I
Conceitos e Definies de Teste de Software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulo I: Roteiro
Conceitos Bsicos de Teste de Software em Geral Elementos do Teste de Software Mitos associados s Atividades de Teste de Software Nveis de Teste Desenvolvimento x Teste de Software Testes de Software em Normas e Modelos de Maturidade de Processo

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Definies
Garantia de Qualidade de Software
Verificao:
Assegurar consistncia, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software.
Estamos construindo corretamente o produto?.

Validao:
Assegurar que o produto requisitos do software. final corresponde aos

Estamos construindo o produto correto?.

Teste:
Examina o comportamento do produto atravs de sua execuo.
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Definies
Falta (Fault):
inserida no software quando um desenvolvedor comete algum equvoco. Um equvoco pode causar vrias faltas ao mesmo tempo que vrios enganos pode causar uma falta idntica.

Falha (Failure):
Representa um comportamento incorreto apresentado por um software em conseqncia de uma falta.

Erro (Error):
Representa o quanto um resultado incorreto.

Defeito (Defect):
Termo genrico para falta, falha ou erro..
IEEE 610.12, 1990. A Glossary of Software Engineering Terminology in Schach, S.R. (2008). Introduction to Object-Oriented Software Engineering. McGraw-Hill

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste e Depurao
Teste:
Processo de executar um software ou sistema com o objetivo de revelar a presena de falhas; ou, falhando nesse objetivo, aumentar a confiana sobre o software

Depurao:
uma conseqncia no previsvel do teste. Aps revelada a presena do erro, o defeito deve ser encontrado e corrigido

Depurao no teste!
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Elementos do Teste de Software


Caso de Teste:
Descreve uma condio particular a ser testada.
Composto por valores de entrada, restries para a sua execuo e um resultado ou comportamento esperado.

Procedimento (Roteiro) de Teste:


Descreve os passos necessrios para a execuo de um ou um grupo de casos de teste

Critrios de Cobertura dos Testes:


Permitem a identificao de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado.
A Cobertura dos Testes determina o percentual de elementos testados em um programa.
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Elementos do Teste de Software


Rodada (Bateria) de Teste:
Consiste na execuo de todos os procedimentos de teste para uma verso do produto em um determinado ambiente de teste
Uma nova rodada de teste deve ser executada caso o critrio de aceitao do produto no tenha sido atingido

Incidentes de Teste:
Qualquer evento ou comportamento diferenciado que ocorra durante a execuo dos testes que requer futura investigao
No h garantia que todo incidente seja uma falha, pois ainda precisa ser analisado

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Defeitos no Desenvolvimento de Software


Quanto antes a presena do defeito for revelada, menor o custo de correo do defeito e maior a probabilidade de corrigi-lo corretamente Principal causa:
Traduo incorreta de informaes

Soluo:
Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (1)


Mito:
No possvel testar at que o sistema exista...

Fatos:
Testar muito mais do que apenas ver o que vai acontecer E muito mais que apenas executar casos de teste! Documentos de requisitos podem e devem ser testados em relao aos objetivos do negcio ou projeto para assegurar completude e correo

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (2)


Mito:
Desenvolvedores devem pensar nos requisitos apenas no incio do desenvolvimento, e se preocupar com testes apenas no final...

Fatos:
Ter os testadores envolvidos durante a anlise de requisitos uma das melhores formas de se assegurar requisitos de boa qualidade Trocas tardias nos requisitos causam impacto nos testes Ter os usurios envolvidos nos requisitos e nos testes fundamental!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (3)


Mito:
Requisitos so contrrio... utilizados no teste, mas no o

Fatos:
Voc no testa requisitos, mas testa a partir deles! fcil escrever requisitos pouco vagos ou ambguos, que parecem estar ok. Quando bons testadores observam a especificao de requisitos, eles aconselham casos de teste especficos para acertar os requisitos vagos, ambguos ou no muito explcitos. Boa engenharia de requisitos produz melhores testes; boa anlise de testes melhora os requisitos!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (4)


Mito:
Se escrever testes difcil, isto somente um problema dos testadores...

Fatos:
Nem todos os requisitos so criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fcil definir o teste, para outros um verdadeiro pesadelo! Especificar requisitos no funcionais testveis tais como usabilidade ou desempenho difcil Frases como fcil de usar, interface amigvel, muito confivel ou desempenho aceitvel no representam especificao de requisitos!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (5)


Mito:
No se preocupe, pequenas requisitos no afetaro os testes modificaes nos

Fatos:
Uma modificao aparentemente pequena nos requisitos pode trazer grande impacto para os testes Voc deve testar todas as modificaes para confirmar que o sistema est executando corretamente. possvel que testes de regresso sejam necessrios O esforo do teste face a modificao vai depender dos riscos associados modificao e dos impactos conhecidos (e desconhecidos!) no sistema

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (6)


Mito:
Os testadores no precisam dos requisitos

Fatos:
O sistema deve apoiar o negcio a atingir um objetivo, ento o que o sistema realmente faz deve ser comparado com este objetivo Uma especificao de requisitos representa o orculo para o teste! Sim, testadores precisam dos requisitos, caso contrrio, voc poderia argumentar que o que vem sendo executado no realmente um teste!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (7)


Mito:
Os testadores no podem testar sem os requisitos

Fatos:
Este tambm um mal entendido comum Algumas vezes modificaes so realizadas nos sistemas onde requisitos so inadequados ou no existentes. Isto faz o teste ser mais difcil, mas no possvel dizer que no pode ser feito
Aplicar teste exploratrio pode ser uma sada

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Objetivo dos Testes de Software


Refutar a assertiva de que o produto est correto
Determinar entradas que faam as sadas obtidas diferirem das sadas esperadas de acordo com a especificao (busca de um contra-exemplo) um processo destrutivo, sob o ponto de vista psicolgico, contrariamente s demais fases da Engenharia de Software, onde constri-se um produto

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Caracter Caractersticas dos Testes de Software


Uma das atividades mais desenvolvimento de software onerosas do

ltimo recurso para avaliao do produto antes de sua entrega ao usurio final Atividade essencial para ascenso ao nvel 3 do CMMI e Nvel D do MPS Atividade relevante para avaliao de produtos de software (ISO 9126, ISO 14598-5)
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Princ Princpios de Teste de Software


Os testes devem ser rastreveis aos requisitos do usurio
devem ser realizados para testar os requisitos do usurio

Devem ser completamente planejados antes de seu incio.


O planejamento primordial para sua execuo

O princpio de Paretto se aplica:


80% de todos os erros encontrados a partir das falhas reveladas estaro concentrados em 20% dos componentes do software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Princ Princpios de Teste de Software


Devem ser aplicados inicialmente em pequena escala e depois expandidos

No possvel aplic-los exaustivamente

Para aumentar sua eficcia, deve ser executado por equipes independentes (quem no desenvolveu o software) Para evitar vis na execuo, os testadores devem ser diferentes daqueles que planejaram os testes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software
O que identifica um bom teste ?
Possui alta probabilidade de revelar falhas No redundante abrangente o suficiente Possui um nvel adequado de complexidade

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Testabilidade de Software
Simplesmente tenta mostrar a facilidade com que um software pode ser testado Operao
quanto melhor funciona, mais eficientemente pode ser testado

Observao
o que voc v o que voc testa

Controle
quanto melhor podemos controlar o software, mais podemos automatizar e melhorar o teste

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Testabilidade de Software
Decomposio
Controlando o escopo do teste, podemos mais rapidamente isolar os problemas e executar re-teste adequado

Simplicidade
Quanto menos existe para se testar, mais rapidamente podemos testar o software

Estabilidade
Quanto menos modificaes, menos problemas para testar

Compreenso
quanto mais informao tivermos, mais adequado ser o teste
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Teste de Software No ocorrncia de falha:


Software de alta Qualidade?

OU
Teste de baixa Qualidade?

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software
Defeitos e erros "emboscados" no software e no revelados

Falhas a se manifestarem na utilizao pelos usurios e defeitos corrigidos durante a manuteno.

CUSTOS ALTSSIMOS!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software
Custos resultantes de testes insuficientes:

US$ 22.2 a 59.5 bi


(NIST, National Institute of Standards and Technology ,Maio 2002)

Atividade que tipicamente envolve:


Execuo do software com entradas representativas para as futuras condies de operao Comparao entre sadas produzidas e esperadas Comparao entre estados resultantes e esperados Mensurao de caractersticas de execuo (memria e tempo consumidos,etc.)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software

Se falhas graves se manifestam torna-se necessria a modificao do projeto, se erros so encontrados com regularidade colocam Qualidade e confiabilidade sob suspeita revelando a necessidade de NOVOS TESTES!
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Teste de Software
Defeitos de fcil correo indicam que as funes aparentemente funcionam bem.

Qualidade e confiabilidade aceitveis, ou testes inadequados para revelar a ocorrncia de falhas graves?

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software
Estratgias para Teste
Unidade Integrao Sistema Re-Teste
Regresso Fumaa
Requisitos Alta ordem

Projeto

Integra Integrao

Aceitao Instalao

cdigo Unidade

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software
Unidade Integrao Funcional
No-Funcional

Perspectiva dos projetistas/desenvolvedores

Perspectiva do Cliente/Usurio Aceitao Instalao

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Infra-Estrutura para Teste


Driver
Interface Estruturas de Dados Locais Condies Limites Caminhos Independentes Caminhos de tratamento de erros

Componente a ser testado

Casos de Teste

Stub

Stub

Resultados

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Unidade
a fase do processo de teste em que se testam as menores unidades de software desenvolvidas
O universo alvo desse tipo de teste so os mtodos dos objetos ou mesmo pequenos trechos de cdigo

Objetivo:
encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo

Existem situaes em que voc no ter os recursos para realizar o teste completo das unidades.
Selecione os mdulos crticos e aqueles complexidade e apenas teste estes mdulos Utilize inspees de cdigo com alta

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Integrao
"Se todos os mdulos funcionam individualmente (analisado atravs do teste de unidade), por que se tem dvida de que eles funcionaro quando colocados juntos? O problema exatamente "coloc-los juntos" tendo uma interface. Teste de Integrao
Fase destinada construo da estrutura do programa, realizandose, ao mesmo tempo, testes para descobrir erros associados a interface A partir dos mdulos testados no nvel de unidade, construir a estrutura de programa que foi determinada pelo projeto Alm disso, encontrar falhas provenientes da integrao interna dos componentes de um sistema Tipos de falhas: envio e recebimento de dados
Ex: Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um mtodo do objeto B, porm este objeto B pode retornar um valor Y, desta forma gerando uma falha

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Integrao
Aplicar a abordagem big bang para integrao uma estratgia ingnua que est fadada ao fracasso.
Teste de integrao deve ser conduzido de forma incremental e organizada!

Top-Down
Quando voc desenvolve um cronograma detalhado para o projeto voc tem que considerar a maneira na qual a integrao de componentes ocorrer de forma que os componentes estejam disponveis quando necessrios

Bottom-up
Integrao bottom-up elimina a necessidade de stubs complexos

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Sistema
Objetivo:
executar o sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em busca de falhas

Testes executados em condies similares (de ambiente, interfaces sistmicas e massa de dados) quelas que um usurio utilizar no seu dia-a-dia Um sistema divide-se em caractersticas Funcionais e NoFuncionais:
Funcional:
Ignora a estrutura do sistema Foco na funcionalidade

No-Funcional
Considera as caractersticas de qualidade do sistema: Portabilidade, Recuperabilidade, Segurana, Eficincia, ... Usabilidade,

Sistema = Funcional + No-Funcional

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Sistema
Tipos especficos de Teste de Sistema:
Recuperao
fora o software a falhar numa variedade de situaes e verifica a capacidade de recuperao do produto

Segurana
verifica se os mecanismos de proteo construdos para o sistema iro de fato proteg-lo de alguma utilizao ou intruso imprpria.

Stress
executa o sistema de forma a exigir recursos em quantidade, freqncia ou volume anormais

Desempenho
avalia o desempenho do software quando integrado ao sistema. Normalmente est associado ao teste de stress

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Estratgias para Re-Teste


Podem ocorrer para qualquer estratgia de teste, em caso de mudanas no software no planejamento dos testes Dois tipos:
Regresso
Teste de regresso uma estratgia importante para reduo de efeitos colaterais. Consiste em se 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.
Execute testes de regresso toda vez que uma modificao maior realizada no software (incluindo a integrao de novos mdulos) Efetue a gerncia de configurao

Fumaa (smoke testing)


Teste fumaa pode ser caracterizado como estratgia de integrao incremental. O software reconstrudo (com novos componentes incorporados) e exercitado diariamente.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Aceitao
Assim como os outros tipos de teste, validao tenta descobrir erros, mas o foco est nos requisitos - nas caractersticas que estaro imediatamente aparentes para o usurio final Os testes so realizados, geralmente, por um grupo restrito de usurios finais do sistema Teste formal conduzido para determinar se um sistema satisfaz ou no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou no o sistema.
Critrios para Teste de Aceitao
1. 2. A funcionalidade (caso de uso) ou caractersticas de desempenho esto de acordo com o especificado e so aceitas Uma variao da especificao descoberta e uma lista de discrepncias (deficincias) criada

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Aceitao
Reviso da Configurao Assegura que todos os elementos da configurao de software foram propriamente desenvolvidos, esto catalogados e possuem o nvel de detalhe suficiente para serem utilizados durante o ciclo de vida do software
Algumas vezes identificada como auditoria.

Teste Alfa e Beta Alfa: executado na instalao do desenvolvedor pelo cliente Beta: executado na instalao de um ou mais clientes pelo usurio final do software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Instalao
Consiste em instalar o sistema nos locais em que esto os usurios Dispensado no caso do teste de aceitao ter sido executado no ambiente do usurio Focam: A integridade do sistema instalado; e A verificao quanto a se alguma caracterstica funcional ou no funcional foi afetada pelas condies do local de operao

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Desenvolvimento x Testes

Requisitos do Sistema

Teste de Aceitao

Requisitos do Software

Teste de Sistema

Modelo de Projeto

Teste de Integrao

Cdigo

Teste de Unidade Execuo dos testes

Projeto dos Testes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Teste de Software em Normas e Modelos de Maturidade de Processos


ISO 12207
Norma para definio de processos de ciclo de vida de software
Objetivo auxiliar na definio de processos de software organizacionais

ISO 15504 SPICE


Padro internacional para Avaliao de Processo de Software inspirada pelo Software CMM e ISO 9001
Objetivo de harmonizar diferentes modelos (Software CMM, CMMI, ISO 9001, ISO 12207 e Bootstrap)

CMMI e MPS
Modelos para estabelecimento de padro de qualidade para processos de software
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Teste de Software
Recomendaes:
Convide os testadores a participar das revises dos requisitos e inspees Comece o planejamento do teste em paralelo com a anlise de requisitos Inclua sugestes de condies de teste e casos de teste para utilizar como exemplos na especificao de requisitos Inclua no documento de requisitos qualquer caso especfico que vier a mente quando estiver analisando os requisitos Utilize cenrios de negcios e casos de uso para dar exemplos especficos de como o sistema deveria funcionar Identifique critrios mensurveis para ambos os tipos de requisitos (funcionais e no funcionais) ...

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulo II
Tcnicas de Teste de Software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulo II: Roteiro


Projeto de Casos de Teste Critrios de Teste Tcnicas de Teste:
Funcional x Estrutural x Baseada em Erros

Exerccios de Fixao

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto de Casos de Teste


Projeto de teste pode ser to difcil quanto o projeto do prprio produto a ser testado Poucos programadores/analistas gostam de teste; menos ainda de projeto de casos de teste Projeto de teste um dos melhores mecanismos para preveno de defeitos O projeto de casos de teste to eficaz em identificar erros quanto a execuo dos casos de teste projetados
Funciona como uma forma de reviso!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto de Casos de Teste


Esteja certo que voc projeta testes para executar todo caminho de tratamento de erro
Seno, o caminho pode falhar quando ativado, revelando uma situao nem sempre agradvel do sistema

Existem algumas situaes nas quais voc no ter todos os recursos para realizar um teste completo das unidades
Selecione os componentes mais crticos e aqueles com alta complexidade ciclomtica e teste inicialmente estes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrios de Teste
Dados um programa P e um conjunto de casos de teste T, definem-se:
Critrio de Seleo de Casos de Teste:
procedimento para escolher casos de teste para o teste de P.

Critrio de Adequao de Casos de Teste:


predicado para avaliar T no teste de P;

Existe uma forte correspondncia entre critrios de seleo e de adequao de casos de teste
Dado um critrio de adequao C, existe um critrio de seleo CS que estabelece: selecione T tal que T seja adequado a C Dado um critrio de seleo CS, existe um critrio de adequao C que estabelece: T adequado se foi selecionado de acordo com CS

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrio de Seleo de Casos de Teste


um mtodo de escolha de casos de teste
se obedecido, gera um conjunto de casos de teste capaz de identificar falhas causadas por uma determinada categoria de erros

Um critrio de seleo de casos de teste deve ser


vlido:
acusa falhas sempre que existam erros no artefato sendo testado

confivel:
as falhas encontradas so indiferentes escolha dos dados e das aes desde que satisfaam as condies dos casos de teste

completo:
segundo um padro de completude

vivel:
Deve possuir um custo de aplicao razovel
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Critrio de Adequao de Casos de Testes


Define quais propriedades precisam ser testadas para garantir inexistncia de erros Como impossvel garantir inexistncia de erros, o conceito utilizado, na prtica, para definir uma qualidade mnima que ser validada pelo teste Objetivo:
... obter, de maneira sistemtica um conjunto T de casos de teste efetivo quanto meta principal de teste revelar falhas no programa

Propriedades:
i) incluir todos os desvios de fluxo de execuo ii) incluir pelo menos um uso de todo computacional iii) T mnimo e finito resultado

T C-adequado todo elemento requerido por C exercitado por pelo menos um t, t T


http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Tcnicas para Teste de Software


Tcnicas:
Funcional (ou caixa preta/caixa fechada) Estrutural (ou caixa branca/caixa aberta) Baseada em erros A questo no est em qual delas utilizar e sim como combin-las de forma a maximizar os benefcios das atividades de teste!

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Baseia-se na especificao do software para derivar os requisitos de teste Aborda o software macroscpico de um ponto de vista

Envolve dois passos principais:


identificar as funes que o software (especificao dos requisitos, casos de uso) deve realizar

criar casos de teste capazes de verificar se essas funes esto sendo executadas corretamente

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Problema:
Dificuldade em quantificar a atividade de teste - no se pode garantir que partes essenciais ou crticas do software foram executadas

Critrios da Tcnica Funcional:


Particionamento em Classes de Equivalncia Anlise do Valor Limite Grafo de Causa-Efeito

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Particionamento em Classes de Equivalncia
Divide o domnio de entrada do programa em classes de dados (classes de equivalncias)
os dados de teste so derivados a partir das classes de equivalncia Eventualmente, pode se considerar o domnio de sada como referncia (ex. relatrios)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Particionamento em Classes de Equivalncia
Dois Passos:
Identificar classes de equivalncia condio de entrada vlidas e invlidas
( um processo heurstico)

Definir os casos de teste enumeram-se as classes de equivalncia casos de teste para as classes vlidas casos de teste para as classes invlidas

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Particionamento em Classes de Equivalncia
Mtodo caixa-preta que divide o domnio de entrada de um sistema em classes (categorias) de dados das quais casos de teste podem ser derivados Fora a definio de um caso de teste que revela categorias de erros, desta forma reduzindo o nmero total de casos de teste que devem ser desenvolvidos Baseado na avaliao de classes de equivalncia para uma condio de entrada Se um conjunto de objetos podem ser ligados por relacionamentos que so simtricos, transitivos e reflexivos, uma classe de equivalncia est presente.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Particionamento em Classes de Equivalncia
Uma classe de equivalncia representa um conjunto de estados vlidos e invlidos para uma condio de entrada. Tipicamente uma condio de entrada pode ser um valor numrico especfico, uma faixa de valores, um conjunto de valores relacionados, ou uma condio lgica. Diretrizes:
Se uma condio de entrada especifica uma faixa de valores ou requer um valor especfico, uma classe de equivalncia vlida e duas invlidas so definidas; Se uma condio de entrada especifica um membro de um conjunto ou lgica, uma classe de equivalncia vlida e uma invlida so definidas

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Classe de Equivalncia: Exemplo


Especificao do programa Identifier:
O programa deve determinar se um identificador vlido ou no em Silly Pascal (uma estranha variante do Pascal). Um identificador vlido deve comear com uma letra e conter apenas letras ou dgitos. Alm disso, deve ter no mnimo 1 caractere e no mximo 6 caracteres de comprimento.

Exemplo:
abc12 (vlido); cont*1 (invlido); 1soma (invlido); a123456 (invlido)

BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software. 2000 (disponivel em http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, ltimo acesso em 07/03/2007)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Classe de Equivalncia: Exemplo


Classes de equivalncia
Condies de Entrada Tamanho t do identificador Primeiro caractere c uma letra S contm caracteres vlidos Classes Vlidas 1t6
(1)

Classes Invlidas t>6


(2)

Sim
(3)

No
(4)

Sim
(5)

No
(6)

Exemplo de Conjunto de Casos de Teste


T0 = {(a1,Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Anlise do Valor Limite
Por razes no completamente identificadas, um grande nmero de erros tende a ocorrer nos limites do domnio de entrada invs de no centro Anlise do Valor Limite uma tcnica de teste que explora os limites dos valores para preparar os casos de teste Est tcnica complementa o particionamento em

classes de equivalncia

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Anlise do Valor Limite - Diretrizes
Se uma condio de entrada especifica uma faixa de valores limitadas em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b; Se uma condio especifica um nmero de valores, casos de teste deveriam ser desenvolvidos para exercitar os nmeros mnimo e mximo. Valores imediatamente acima e abaixo do mnimo e mximo so tambm testados
Ex: A={1..10}; Casos de Teste => {1, 10, 0,11}

Aplique as diretrizes 1 e 2 para as condies de sada. Por exemplo, assuma que uma tabela de temperatura x presso necessria como sada de um programa de anlise de engenharia. Casos de teste deveriam ser projetados para criar um relatrio de sada que produza o mximo (e mnimo) nmero possvel de entradas na tabela; Se uma estrutura de dados interna do programa tem identificados seus limites (ex. Um vetor com 100 posies), esteja certo de projetar um caso de teste para exercitar a estrutura de dados em seu limite

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Anlise do Valor Limite: Exemplo


Consideremos a seguinte situao:
"... o clculo do desconto por dependente feito da seguinte forma: a entrada a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes at 12 anos (inclusive) o desconto de 15%. Entre 13 e 18 (inclusive) o desconto de 12%. Dos 19 aos 21 (inclusive) o desconto de 5% e dos 22 aos 24 de 3%..."

Aplicando o teste de valor limite convencional sero obtidos casos de teste semelhantes a este:
{-1,0,12,13,18,19,21,22,24,25} incluindo valores fora da faixa.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Funcional
Grafo de Causa-Efeito
Tcnica para identificao de casos de teste que explora as condies lgicas e as aes correspondentes. Basicamente, 4 passos devem ser executados:
Para cada mdulo, Causas (condies de entrada) e efeitos (aes realizadas s diferentes condies de entrada) so relacionados, atribuindo-se um identificador para cada um. Em seguida, um grafo de causa-efeito (rvore de deciso) desenhado. Neste ponto, transforma-se o grafo numa tabela de deciso. As regras da tabela de deciso so, ento, convertidas em casos de teste.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Grafo Causa-Efeito: Exemplo


Causa: valor compra > 80 ^ #produtos < 3 Efeito: frete grtis
<3 >80 Valor compra <=80 Cobrar Frete #produtos >=3 Frete Grtis rvore de Deciso

Causa Tabela de Deciso Efeito

Valor Compra >80 #Produtos Cobrar Frete Frete Grtis V <3

>80 >=3 V

<=80 -V

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Estrutural
baseada no conhecimento da estrutura interna da implementao Teste dos detalhes procedimentais A maioria dos critrios dessa tcnica utiliza uma representao de programa conhecida como grafo de programa ou grafo de fluxo de controle

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Programa Identifier.c
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* 01 01 01 01 01 01 01 01 01 02 03 04 05 05 06 07 07 07 08 09 10 10 11 */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ { char achar; int length, valid_id; length = 0; printf ("Digite um possvel identificador\n"); printf ("seguido por <ENTER>: "); achar = fgetc (stdin); valid_id = valid_starter (achar); if (valid_id) length = 1; achar = fgetc (stdin); while (achar != '\n') { if (!(valid_follower (achar))) valid_id = 0; length++; achar = fgetc (stdin); } if (valid_id && (length >= 1) && (length < 6) ) printf ("Valido\n"); else printf ("Invalido\n"); }

BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software. 2000 (disponivel em http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, ltimo acesso em 07/03/2007)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Estrutural (Grafo de Programa)

Detalhes considerados:
n arco caminho:
simples completo livre de lao

fluxo de controle
Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Estrutural (Grafo de Programa)

Ns:
blocos indivisveis
no existe desvio para o meio do bloco uma vez que o primeiro comando do bloco executado, os demais comandos so executados seqencialmente

Arestas ou Arcos:
representam o fluxo de controle entre os ns

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Estrutural
Critrios da Tcnica Estrutural:

Engenharia de Software: Teoria e Prtica Shari Lawrence Pfleeger - Prentice Hall- Cap. 08

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Estrutural
Critrios de Fluxo de Controle
Todos-Ns: 1,2,3,4,5,6,7,8,9,10,11 Todos-Arcos: arcos primitivos: <1,2>,<1,3>,<5,6>,<5,7>, <8,9>,<8,10> Todos-Caminhos

Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Tcnica Baseada em Erros


Os requisitos de teste so derivados a partir dos erros mais freqentes cometidos durante o processo de desenvolvimento do software Critrios da Tcnica Baseada em Erros:
Semeadura de Erros Anlise de Mutantes (teste de unidade) Mutao de Interface (teste de integrao)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Anlise de Mutantes
Garantir a ausncia de determinados tipos de defeitos Considerando todos os programas Q, possvel provar a correo de P
T P P(t) Q(t) Q

tT

impraticvel executar e comparar todos os programas Q Estabelece-se ento uma vizinhana (P) que contm apenas um conjunto finito de programas Esses programas contm pequenos desvios sintticos que representam defeitos simples
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Anlise de Mutantes
Hiptese do Programador Competente Programadores experientes escrevem programas corretos ou muito prximos do correto

Efeito de Acoplamento Casos de teste capazes de revelar erros simples so to sensveis que, implicitamente, tambm so capazes de revelar erros mais complexos

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Anlise de Mutantes
Os operadores de mutao determinam o tipo de alterao sinttica que deve ser feita para a criao dos mutantes
Introduzir pequenas alteraes semnticas atravs de pequenas alteraes sintticas que representam defeitos tpicos Ex: FORTRAN (22 operadores), C (71 operadores)

Operadores dependem da linguagem alvo

X=4 Y=2 Z=1

read x, y, z m := x if m < y m := y if m < z m := z print m

read x, y, z m := x if m y m := y if m < z m := z print m

2
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Aplicao de Critrios
Estudos Tericos e Experimentais avaliam:
Custo
esforo necessrio para que o critrio seja utilizado # de casos de teste para satisfazer o critrio

Strength
Dificuldade de satisfao Dificuldade de satisfazer um critrio, tendo satisfeito outro.

Eficcia
Capacidade que um critrio possui de detectar erros

Estratgia Incremental de Teste


Custo benefcio da combinao de critrios

Ambiente de Teste, Depurao e Manuteno de Software


Facilitam a aplicao de diferentes critrios para o teste
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Exerccios de Fixao
1. Utilizao da Equivalncia Tcnica de Particionamento por

Programa para verificao de tipos de tringulo

2. Utilizao da Anlise do Valor Limite


Programa para verificao de temperatura e presso crticas em indstria qumica

3. Utilizao do Grafo de Causa Efeito


Programa para clculo de valor de ligao em um programa de uma companhia telefnica

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulo II Concluses
As tcnicas de teste atualmente existente complementares e podem ser utilizadas em conjunto so

Deve ser feita uma anlise de custo-benefcio na empresa a respeito da aplicao de vrias tcnicas em conjunto.

Diferente tipos de aplicaes (ex: 00, aplicaes web, software embarcados) possuem caractersticas especficas
Isso impacta nas atividades desenvolvimento e testes
Tcnicas diferenciadas para desenvolvimento e testes

Apoio Ferramental essencial para a aplicao dessas tcnicas como meio para reduzir o esforo e custo de sua implantao

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulos III/IV
Estratgias de Projeto, Execuo e Controle dos Testes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mdulos III/IV: Roteiro


Estratgias de Teste Explorando Casos de Uso para o Teste Projetando Testes a partir de Caso de Uso Definindo e Configurando um Ambiente de Teste Executando os Testes Apoiando a Depurao das Falhas Critrio de Parada dos Testes Mtricas para avaliao dos testes Concluses

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Estratgias de Teste
Baseada na implementao:
Tenta-se testar cada linha de cdigo Muito caro Muito difcil quando se tem vrios caminhos
Em OO, s vezes no faz sentido!

Baseada na especificao:
Cobrir as imposies e restries feitas pelos desenvolvedores a partir dos requisitos estabelecidos para o sistema Pode apoiar o desenvolvimento do software (teste de integrao)
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Estratgias de Teste
A freqncia com que cada tipo de usurio utiliza o sistema refletir a importncia relativa das caractersticas do sistema.
Esta freqncia de uso pode ser representada por um perfil operacional

Ter um perfil operacional qualificado representa uma estratgia eficiente para descobrir defeitos que os usurios mais encontrariam.
Este perfil difcil de se obter antes do lanamento do produto

Extenses ao modelo de casos de uso podem ser feitas para se considerar este perfil operacional
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Explorando Casos de Uso para o Teste


Provem uma representao para os requisitos funcionais de um sistema. Identificam todos os atores que disparam as funcionalidades do sistema.
Ator: representa um usurio do sistema ou um estmulo de um outro sistema.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Extenso ao modelo de Casos de Uso para apoiar teste


Casos de uso criticalidade:
Freqncia:
define quantas vezes um determinado uso do sistema realizado num perodo de tempo. mais difcil de ser obtida, porm possvel de ser estimada

devem

considerar

freqncia

Criticalidade:
define a importncia de um uso do sistema em relao ao contexto geral de utilizao facilmente obtida a partir do julgamento de um especialista do domnio.

Combinando-se estes dois critrios pode-se priorizar os casos de uso mais importantes e mais freqentes.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Extenso ao modelo de Casos de Uso para apoiar teste


A freqncia de utilizao do sistema deve ser registrada para cada Ator O perfil pode ser identificado a partir da anlise da responsabilidade do ator (consideraes sobre o domnio).
Esta caracterstica utilizada para ordenar os atores face a sua freqncia de utilizao individual do sistema. Pode-se considerar ordenaes relativas (primeiro, segundo,...), implcitas (alto, mdio, baixo) ou at percentuais.

Esta tcnica no altera o processo bsico de escolha de tipos de teste e de dados de entrada:
a modificao ocorre em como sistematicamente distribuir os casos de teste pelos casos de uso com uma prioridade calculada.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Extenso ao modelo de Casos de Uso para apoiar testes: Exemplo


Modelagem de um sistema bancrio simples onde os correntistas podem acessar suas contas atravs de terminais ATM. Os funcionrios acessaro estas contas atravs do sistema a ser desenvolvido. Correntistas podem realizar operaes de crdito, dbito e verificao de saldo. Os atores deste exemplo so correntista, caixa, gerente e sistema eletrnico de transferncia de fundos.

Trans E letFundos Realiz arDeps ito

Correntis ta

Reali z arSaque Caix a

G erente

Realiz arAjus tes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Processo
1. Definir o conjunto completo de atores. 2. Definir o conjunto completo de casos de uso incluindo as associaes com os atores. 3. Construir o perfil de uso para cada ator. 4. Calcular a freqncia para cada caso de uso a partir dos perfis dos atores. 5. Combinar as avaliaes de freqncia e criticalidade num valor que represente a prioridade de teste. 6. Alocar casos de teste com base na prioridade de teste dos casos de uso.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Template - Caso de Uso


ID Caso de Uso: RealizarDepsito Nvel UC: Sistema Cenrio: Atores: Transf. Eletrnica de Fundos, Gerente e Correntista Pr-Condies: Conta deve estar aberta e ativa Descrio: Trigger: Ator inicia um depsito numa conta. Sistema solicita a conta destino e o valor do depsito. Ator informa o nmero da conta e valor do depsito. Sistema responde adicionando o valor depositado. Sistema atualiza contadores de atividade na conta. Sistema verifica se valor depositado necessita de notificao e caso necessrio, gera a notificao. Requisitos Relevantes: Capacidade de aumentar valor em conta. Ps-Condies: Saldo da conta foi incrementado pelo valor depositado. Seqncias Alternativas: Se a conta no estiver ativa, ativ-la primeiro e depois Realizar o depsito. Regra de Negcio: (1) o valor do depsito deve ser maior que R$ 10,00 (2) caso o valor do depsito seja maior que R$10000,00, notificar cliente por e-mail (3) ambos os campos so obrigatrios Excees: Nmero de Conta invlida, Conta inativa e Valor Invlido. Usos concorrentes: RealizarSaque Casos de Uso relacionados: RealizarSaque Freqncia: Criticalidade: Risco:
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Perfil dos Atores


Nome: Funcionrio Abstrato: S/n Descrio (Papel): Tem acesso s contas bancrias Nvel Conhecimento: Variado Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia Baixa

Nome: Caixa Abstrato: N/s Descrio (Papel): Lida diretamente com os correntistas. Nvel Conhecimento: Treinados, mas com nveis de experincia diversos. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Mdia Alta __

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Perfil dos Atores


Nome: Gerente Abstrato: N/s Descrio (Papel): Supervisiona os caixas e gerencia as contas. Nvel Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia Mdia

Nome: Correntista Abstrato: N/s Descrio (Papel): Dono de uma conta, pode disparar atividades na mesma. Nvel Conhecimento: Novato. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia __

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Perfil dos Atores

Nome: Transferncia Eletrnica de Fundos Abstrato: N/s Descrio (Papel): Inicia atividades na conta, com algumas restries. Nvel Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Mdia Mdia __

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Avaliao de Freqncia e Criticalidade


Caso de Uso Freqncia Criticalidade Prioridade de Teste Alta

RealizarDepsito

Mdia

Alta

RealizarSaque

Alta

Alta

Mdia

RealizarAjustes

Mdia

Baixa

Baixa

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Avaliao de Freqncia e Criticalidade


Realizar Depsito de $1000

TransEletFundos RealizarDepsito

Correntista

Realizar Depsito de $10000

Caixa

RealizarSaque

Realziar Depsito c om n de c onta invlido

Gerente

RealizarAjustes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir de Casos de Uso


Um caso de uso formado por:
Atores: perfis de usurios que executam o caso de uso Pr-condies: restries para a execuo de um caso de uso Seqncia de Aes (Fluxo principal): passos ordenados para execuo de um caso de uso Ps-condies: condio final a ser estabelecida ao final da execuo do caso de uso Seqncias Alternativas: fluxos de aes que ocorrem paralelamente ao fluxo principal, dada uma ao especfica Regras de negcio: restries (regras) para execuo de um mais passos do fluxo principal ou alternativo Excees: estados invlidos para o sistema

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


A partir desse conjunto de informaes, os testes podem ser gerados, iniciando pelos casos de teste Passos a serem seguidos para gerao dos testes
(seguiremos o exemplo do caso de uso Realizar Depsito para o Ator CORRENTISTA, sem maiores regras):

1. Identifique os elementos presentes no caso de uso (ex.


itens de menu, campos de formulrios, botes, aes alternativas, etc.)

Itens de Menu: Depsito e Saque Campo: conta de destino e valor do depsito.

2. Identifique a dependncia entre esses elementos (ex. um


campo s pode ser preenchido caso uma opo do caso de uso tenha sido previamente escolhida)

Os campos conta de destino e valor do depsito s aparecem caso o item de menu Depsito tenha sido escolhido anteriormente
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Projeto dos Testes a partir dos casos de uso


Passos a serem seguidos para gerao dos testes:
3. Defina os casos de teste individuais para cada elemento do caso de uso usando uma das tcnicas de teste apresentadas (ex. particionamento por equivalncia, anlise do valor
limite, etc.)

Nmero de equivalncia):

Conta

(usando

particionamento

por

Tcon ={(12345-6, invlida), (, invlido), (24567-2, vlido), (36265-1,invlido inativa)}

Valor do Depsito (usando anlise do valor limite):


Tval = {nulo(em branco), 9.99; 10; 10000; 10000.01}

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Passos a serem seguidos para gerao dos testes:
4. Defina os casos de teste elementos de um caso de uso
CT01: CT02: CT03: CT04: CT05: CT06: CT07:

agrupando

os

diferentes

Um caso de teste ser uma tupla <(conta,valor), resultado>


<(,nulo), invlido> <(12345-6, 10),invlido> <(36265-1, 10000),invlido> <(24567-2, 9.99),invlido> <(24567-2, 10),vlido> <(24567-2, 10000),vlido> <(24567-2, 10000.01),vlido gerar notificao>

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Passos a serem seguidos para gerao dos testes:

5. Represente as seqncias de aes para o caso de uso, incluindo o fluxo principal e fluxos alternativos. Alm disso, deve ser considerada a ordem de preenchimento dos elementos do caso de uso (ex. elementos que dependem de
outro)

No diagrama a seguir, estamos considerando que o sistema no finaliza a operao, caso os dados de conta de destino e valor de depsito invlidos sejam informados

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Correntista

Sistema

1.O ator escolhe a opo REALIZAR DEPSITO

2. O sistema exibe a tela de depsito

3. O ator informa o valor do depsito e um telefone de contato

4. Apresenta mensagem de dados invlidos (valor < 10) ou (conta invlida) ou (conta inativa)

valor >= 10 5. O Sistema responde adicionando o valor depositado

6. Sistema atualiza contadores de atividade na conta

7. Sistema verifica se valor depositado necessita de notificao

valor <= 10000 valor > 10000 8. O sistema envia notificao or e-mail

9. O sistema finaliza o depsito e retorna tela inicial

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Passos a serem seguidos para gerao dos testes:
6. A partir do diagrama definido no passo anterior, alm dos casos de teste definidos individualmente para cada elemento do caso de uso, definida o(s) procedimento(s) de teste para avaliar um cenrio do caso de uso

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Os procedimentos de teste visam a definio dos passos e a ordem para executar os casos de teste definidos para os elementos do caso de uso O nmero de procedimentos de teste depende da quantidade de fluxos que podem ser extrados do diagrama construdo
Esse nmero tambm influenciado pela quantidade de casos de teste definidos para cada evento que compe o grafo
Cada evento est associado a um ou mais casos de teste

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Definio dos procedimentos de teste:
7. Extraia os diferentes caminhos do diagrama, considerando que todas as aes devam ser executadas ao menos uma vez.
A deciso de qual algoritmo de grafo de programa usar depende de quem esta projetando os testes.
Ex. Caminhos diferentes em caso de ciclos podem ser extrados ou no, alm de outros problemas conhecidos de grafos.

No caso do nosso exemplo, dois caminhos foram extrados:


CAMINHO 1: 1, 2, 3, 4, 2, 3, 5, 6, 7, 9 CAMINHO 2: 1, 2, 3, 4, 2, 3, 5, 6, 7, 8, 9

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Definio dos procedimentos de teste:
7. Por fim, gere procedimentos de teste que executem todos os casos de teste definidos no passo, combinando os casos de teste de diferentes elementos Procedimentos:
PT01: Teste de valores invlidos (CT01, CT02, CT03, CT04) + Teste de valor de depsito = 10 (CT05 limite inferior)
CAMINHO 1

PT02: Teste de valor de depsito = 10000 (CT06 limite superior sem a gerao de notificao)
CAMINHO 1

PT03: Teste de valor de depsito = 10000.01 (CT07 limite superior com a gerao de notificao)
CAMINHO 2

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Exemplo de Procedimento de Teste


Procedimento de Teste 01:
Passo
1. 2. 3. 4. 5. 6. 7. 8. 9. Ator inicia um depsito numa conta. Sistema solicita o valor do depsito e um telefone para contato. Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de dados invlidos Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de dados invlidos Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de valor de depsito invlido Ator informa a conta destino e o valor do depsito. CT01 CT01 CT02 CT02 CT03 CT03 CT04 CT04 CT05 CT05 CT05 CT05
Copyright G.H. Travassos 2010

Caso de Teste

10. Sistema apresenta uma mensagem de valor de depsito invlido 11. Ator informa a conta destino e o valor do depsito. 12. Sistema atualiza contadores de atividade na conta. 13. Sistema verifica se valor depositado necessita de notificao. e caso necessrio, gera a notificao 14. O sistema finaliza o caso de uso
http://ese.cos.ufrj.br

Prioriza Priorizao de Procedimentos de Teste


Devemos supor que existam casos e procedimentos de teste para os outros casos de uso. Sendo assim, em que ordem os procedimentos de teste devem ser executados?
Normalmente, aplicaes possuem um fluxo de atividades definido Esse fluxo pode ser seguido durante a execuo dos testes Assim, resultados da execuo de um procedimento de teste pode ser aproveitado em procedimentos seguintes
Ex: primeiramente executar um cadastro, e depois uma alterao (ou excluso do item que foi includo, ou sua consulta)

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Prioriza Priorizao de Procedimentos de Teste


No exemplo do sistema bancrio, podemos supor a existncia de casos e procedimentos de teste para o caso de uso LOGAR NO SISTEMA
Assim, todos os casos de teste para REALIZAR DEPSITO dependem dos casos de teste para LOGAR NO SISTEMA, pois isso uma pr-condio do caso de uso Assim, procedimentos de teste para REALIZAR DEPSITOS devem ser executados aps os procedimentos de teste para LOGAR NO SISTEMA

Uma outra opo seria unir os procedimentos de teste para o caso de uso LOGAR NO SISTEMA com os procedimentos de teste para REALIZAR DEPSITO

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Projeto dos Testes a partir dos casos de uso


Note que nesses exemplos, casos e procedimentos de teste foram apenas citados, no especificados!
A especificao consiste na documentao dos casos e procedimentos de acordo com o que foi apresentado no mdulo I
Especificar as dependncias entre os casos de teste, Especificar as restries do procedimento de teste, Requisitos computacionais para execuo, ... Exemplos que no foram especificados para o sistema bancrio:
Restrio: Para todos os procedimentos de teste definidos, o correntista j deve estar autenticado no sistema) Comportamento a ser observado: atualizao do contador de atividade da conta
http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Definindo e Configurando um Ambiente de Teste


Antes do incio da execuo dos testes, deve ocorrer a configurao do ambiente em que os testes sero executados Isso inclui:
Espao fsico para execuo dos testes
Testes podem requerer a alocao de um espao especfico

Equipamentos
Testes podem requerer a alocao de um equipamento diferenciado (ex. servidor, um simulador, etc.)

Banco de dados e servidores


Testes requerem uma base de dados independente da base de desenvolvimento para evitar dados sem integridade (normais durante o desenvolvimento), garantindo que esses dados no interfiram nos resultados dos testes

Ferramentas
A execuo dos testes pode necessitar de ferramentas especficas para os testes, como simuladores ou capture-replay

Material de apoio, treinamento


Pode haver a necessidade de materiais adicionais de apoio ou treinamentos especficos para a execuo dos testes em um projeto. Ex. treinamento sobre o uso de um simulador de vo

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Definindo e Configurando um Ambiente de Teste


O ambiente de teste deve ser configurado de acordo com o nvel de teste e com o tipo de software a ser realizado
Nvel de teste (exemplos):
Um ambiente para teste de stress deve prover uma simulao em que os recursos da infra-estrutura so sobrecarregados ou mltiplos acessos devem se providos Teste de segurana deve tentar revelar vulnerabilidades da infraestrutura onde o sistema ficar disponvel Teste alfa deve prever uma infra-estrutura similar quela em que o sistema ir funcionar aps a entrega ...

Tipo de software (exemplo):


Um ambiente de teste para sistema embarcado deve prover simuladores especficos para o hardware Alguns tipos de software requerem habilidades para execuo dos testes. Ex. um simulador de vo ...

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Executando os Testes
Testador:
Seguir o que foi definido durante o planejamento Registrar todas as atividades que ocorrem
Normalmente, no conseguimos prever as falhas, e podemos perder a seqncia de eventos que a ocasionou Tentar explicar com detalhes o que levou ocorrncia da falha, utilizando telas capturas

Analisar a possibilidade de executar testes em paralelo


Alguns procedimentos de teste podem ser executados em paralelo. Ex. testes para itens diferentes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Controlando os Testes
Gerente de Teste:
Garantir que os testes planejados estejam sendo executados e verificar os resultados dos testes Analisar o grau de impacto dos incidentes relatados Repassar os incidentes de teste equipe de desenvolvimento
Utilizar ferramentas de bug tracking (ex. BugZilla)
Facilita a documentao e possibilita o acompanhamento de um incidente de teste at a sua correo pelos desenvolvedores

Definir um momento adequado para finalizar os testes


Chega um ponto onde os custos de continuar os testes so maiores que os benefcios dos testes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Apoiando a Depurao das Falhas


(Rastreabilidade) Incidente de Teste (Falha)
Observado atravs de um

Caso/Procedimento de Teste
Associado a um

Item de Teste
Que possui

Defeito
Que dever ser corrigido
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Apoiando a Depurao das Falhas


(Rastreabilidade) Criar nveis na matriz de rastreabilidade para casos e procedimentos de teste
Link dos casos e procedimentos de teste com os itens do projeto
(classes componentes casos de uso requisitos)

A matriz deve ser atualizada constantemente em caso de mudanas nos itens do projeto
Facilita a evoluo dos testes, e conseqentemente testes de regresso
Indicao explcita dos casos ou procedimentos de teste a serem atualizados ou que no fazem mais parte dos testes de um software

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Mtricas para Avalia Avaliao dos Testes Objetivo:


Caracterizar estatisticamente as atividades de teste de um projeto Medir, avaliar e sugerir melhorias nas atividades de teste ou de desenvolvimento para projetos futuros Permitir realizao de estudos a respeito de decises tomadas ao longo dos testes No mea s para colecionar medies! Mea para identificar ou resolver um problema.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Exemplos de M Mtricas de Teste (1) complexidade ciclomtica (McCabe) quantidade de falhas tempo gasto com teste (por fase) esforo gasto com teste (por fase) natureza das causas de falhas
ex: artefato do processo de desenvolvimento

distribuio das causas no tempo modos de observao das falhas


ex. durante os testes ou aps a entrega

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Exemplos de M Mtricas de Teste (2) categoria das falhas


ex. gravssima, grave, normal, leve

distribuio de falhas por item de teste distribuio de falhas no tempo tempo para corrigir o defeito que originou uma falha esforo para corrigir o defeito que originou uma falha cobertura de teste
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Mtricas para Avalia Avaliao de Testes: Exemplo de Estrat Estratgia


Objetivos da medio:
reduzir o nmero de falhas em programas entregues reduzir o esforo gasto em re-trabalho desnecessrio

Quais as perguntas que se relacionam com os objetivos:


quantas falhas por item de teste x categorias foram detectadas em produtos j entregues quanto tempo gasto em alterao de artefatos j desenvolvidos qual o percentual deste tempo que seria desnecessrio caso fossem adotados princpios mais eficazes

Mtricas a serem coletadas:


quantidade de falhas relatadas aps a aceitao # itens de teste categoria das falhas

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrios de Parada dos Testes


Questes fundamentais:
independente da quantidade de falhas reveladas, os testes tem um perodo pr-definido de acordo com o cronograma do projeto Garantir a inexistncia de defeitos uma atividade impraticvel e custosa ao processo Definir critrios viveis para aceitao de um produto!!!

O Gerente de Teste deve tomar a deciso sobre quando parar os testes


Diferentes categorias de software possuem diferentes graus de criticalidade, alguns muito elevados
Ex: Aplicao mdica, aplicao financeira, software para avies, dentre outros.

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrios de Parada dos Testes


Como chegar a deciso de parar os testes?
Os resultados dos testes direcionam essa tomada de deciso

Vamos seguir dois cenrios:


Cenrio 1:
o critrio de aceitao do produto foi atingido dentro do perodo para os testes

Cenrio 2:
O perodo para testes se encerrou e o critrio de aceitao no foi 100% atingido

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrios de Parada dos Testes


Cenrio 1: o critrio de aceitao foi atingido
O nmero de falhas foi diminuindo ao longo das rodadas de teste Na rodada final, no foram reveladas falhas graves (no necessitando novos testes) Portanto, o sistema pode j se encontrar em um estado confivel.
Resultados por Rodada de Teste
100 90 80

Incidentes ou Falhas

70 60 50 40 30 20 10 0 Rodada 1 Rodada 2 Rodada 3 Rodada 4

FIM DOS TESTES!!!

Rodadas
Incidentes Falhas confirmadas

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Critrios de Parada dos Testes


Cenrio 2: O perodo para testes se encerrou e o critrio de aceitao no foi 100% atingido
Quanto mais rodadas de teste, menor o nmero de falhas?
No necessariamente! Pode haver uma rodada que revele mais falhas que outra anterior

Fazer uma anlise custo-benefcio sobre a continuidade de executar os testes


Resultados por Rodada de Teste
40 35

Incidentes ou Falhas

30 25 20 15 10 5 0 Rodada 1 Rodada 2 Rodada 3 Rodada 4

Qual o % atingido para o critrio de aceitao do produto?

Rodadas
Incidentes Falhas confirmadas

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Automao dos Testes


A qualidade e produtividade dos testes so dependentes do critrio de teste utilizado e da existncia de ferramentas de teste para apoio
Com a ausncia de ferramentas automatizadas a aplicao de um critrio torna-se uma atividade propensa a erros e limitada a projetos simples

Ferramentas apiam Teste de Regresso:


Casos de teste podem ser facilmente obtidos para reavaliao do software aps uma modificao Benefcios:
Possibilidade de verificar se a funcionalidade do software foi alterada, comparando os resultados obtidos nos testes de regresso com os resultados do teste original Reduo dos custos para a execuo de novos testes
Copyright G.H. Travassos 2010

http://ese.cos.ufrj.br

Automao dos Testes


Ferramentas de Teste
Seleo de Ferramentas
que atividades de teste esto previstas no processo do software?

Contribuem para reduzir as falhas produzidas pela interveno humana


aumento da qualidade e produtividade da atividade de teste aumento da confiabilidade do software

Facilitam a conduo de estudos experimentais e observao de oportunidades de melhoria do processo

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

Automao dos Testes


Ferramentas de Teste
Possibilidades:
Gerao Execuo Gerenciamento de testes

Razes:
Testes so altamente repetitivos Tempo destinado aos testes curto

Uma execuo automtica completa pressupe:


Fornecer as entradas Executar os casos de teste Coletar e verificar os resultados

Website com diversas ferramentas de teste gratuitas:


www.opensourcetesting.org

O uso de ferramentas, embora importante, pode no ser trivial!


http://ese.cos.ufrj.br
Copyright G.H. Travassos 2010

Concluso
A atividade de Teste no auto-contida
Ela depende de artefatos gerados em outras fases Esses artefatos devem ser construdos de forma adequada facilitando os testes

Diversas estratgias de teste podem ser adotadas. Foram apresentadas:


Heursticas para ordenao de classes OO Projeto dos testes a partir de casos de uso

Outras questes devem realizao dos testes

ser

consideradas

durante

Configurao do ambiente para teste Registro dos incidentes de teste Envio dos incidentes equipe de desenvolvimento para identificao dos defeitos Apoio depurao dos testes Automao de diferentes atividades relacionadas aos testes

http://ese.cos.ufrj.br

Copyright G.H. Travassos 2010

CEDESC Curso de Especializao em Desenvolvimento de Software PETROBRAS

Verificao, Validao e Testes: Teste de Software


Guilherme Horta Travassos
www.cos.ufrj.br/~ght

Grupo de Engenharia de Software Experimental

http://ese.cos.ufrj.br