Validação de Software Prof-Manuel Mendonça Mod1

Transparncia 1
Validao de Software Mdulo 1 Conceitos Bsicos

Validao de Software
Professor Manoel Mendona
Transparncia 2
Sobre a Disciplina
Transparncia 3
Testes
Revises
Provas Formais
Tcnicas para Avaliao da
Qualidade de Produtos
Transparncia 4
Instrutor
Manoel Mendona
Sala IM 215
Tel. 3283-6343
Horrio para alunos quarta tarde
manoel.mendonca@ufba.br
Transparncia 5
Site da Disciplina
...
Transparncia 6
Bibliografia
A Practitioner's Guide to Software Test Design by Lee
Copeland ISBN:158053791x
Artech House 2004
http://www.opensourcetesting.org
Transparncia 7
Avaliaes
Trabalhos, dois trabalhos
Provas, uma ou duas
Transparncia 8
Plataforma de Trabalho
Java e Eclipse
JUnit
Outras ferramentas
Transparncia 9
0. Conceitos Bsicos
Transparncia 10
0.1 Defeitos e Falhas
Defeito
um problema nos requisitos, no projeto, no cdigo,
na documentao ou nos casos de teste
Falha
um problema no funcionamento do sistema
Falha: conseqncia de um defeito
Transparncia 11
Defeitos e Falhas: Uma Viso Mais Completa
Engano (mistake) => erro cometido cabea do eng. de
software
Defeito (fault) => erro inserido no software
Erro (error) => execuo do erro conduzindo a um estado
incorreto do software
Falha (failure) => manifestao externa do erro
Transparncia 12
Principais Artefatos de Software
Uma Viso Simplificada
Especificao
de requisitos
Projeto Cdigo
Defeitos ocorrem em todos eles !!!
Transparncia 13
Defeitos Introduzidos ao Longo do Processo de
Desenvolvimento
A maior parte de origem humana.
So gerados na comunicao e na transformao de
informaes.
Permanecem presentes nos diversos produtos de
software produzidos e liberados.
A maioria encontra-se em partes do produto de
software raramente utilizadas e/ou executadas.
Transparncia 14
0.2 Alguns Tipos de Defeitos Introduzidos
Informao que fornecida e no necessria ou nunca
utilizada
Informao
Estranha
Informao contida no artefato de software ambgua, isto ,
vrias interpretaes podem ser derivadas da definio levando
o desenvolvedor implementao correta.
Ambigidade
Informao contida em uma parte do artefato de software est
inconsistente com outra informao no artefato de software.
Inconsistncia
Alguma informao no artefato de software contradiz
informao do documento de outra informao no artefato de
software.
Fato Incorreto
Informao necessria do sistema foi omitida do artefato de
software.
Omisso
Descrio Geral Tipo de
Defeito
Transparncia 15
De onde os defeitos vm?
Que defeitos podemos encontrar?
Copyright Guilherme Travassos
COPPE/UFRJ 2003 - http://www.cos.ufrj.br/~ght
Conhecimento do
domnio
Requisitos
Gerais
Outro
Domnio
Artefatos de
Software
Omisso
Inconsistncia
Ambigidade
Fato incorreto
Informao
estranha
Tipos de Defeitos Introduzidos
Transparncia 16
Defeitos Introduzidos ao Longo do Processo
de Desenvolvimento
Principal causa:
traduo incorreta de informaes.
Quanto antes a presena do defeito for revelada,
menor o custo de correo do defeito e maior a
probabilidade de corrigi-lo corretamente.
Soluo:
Introduzir atividades de V V & T ao longo de
todo o ciclo de desenvolvimento.
Transparncia 17
0.3 Verificao e Validao (V&V)
As atividades de avaliao de produtos so parte do tema
chamado Verificao e Validao Verificao e Validao (V&V). (V&V).
A definio de V&V abrange muitas das atividades s quais
nos referimos como Garantia da Qualidade de Software
(SQA).
Transparncia 18
Verificao
refere-se ao conjunto de atividades que garante que o
software implementa corretamente uma funo especfica.
Estamos construindo certo o produto?
Transparncia 19
Validao
software que foi construdo rastrevel s exigncias do
cliente.
Estamos construindo o produto certo?
Transparncia 20
0.4 Garantia da Qualidade de Software
Mtodos de Engenharia de Software: proporcionam a base
a partir da qual a qualidade construda.
Revises Tcnicas Formais: ajudam a garantir a qualidade
do produto produzido como uma conseqncia de cada passo
da engenharia de software.
Medio: ajudam a controlar cada elemento da
configurao de software.
Transparncia 21
Garantia da Qualidade de Software (cont.)
Padres e Procedimentos: ajudam a garantir a uniformidade.
Garantia de Qualidade de Software (SQA): pe em prtica
uma filosofia de qualidade total.
Teste: a qualidade pode ser avaliada.
Transparncia 22
Transparncia 23
Teste de Software
Transparncia 24
Teste
1 Introduo
2 Contexto
3 Organizao para Realizao de Testes
4 Executando Teste
5 Depurando Software
6 Tcnicas de Teste
Transparncia 25
1. Introduo
1.1 Engenharia de Software e Teste
1.2 O qu teste
1.3 Objetivos da Atividade de Teste
1.4 Erros e as atividades de teste
Transparncia 26
1.1 Engenharia de Software e Teste
1- Fase de Definio ("o que")
- Anlise do sistema
- Planejamento do projeto de software
- Anlise de requisitos
2- Fase de Desenvolvimento ("como")
- Projeto de software
- Codificao
- Realizao de testes Realizao de testes
3- Fase de Manuteno ("alteraes")
Transparncia 27
1.2 O Qu Teste
1. a atividade de teste o processo de executar um programa
com a inteno de descobrir um erro
2. um bom caso de teste aquele que tem uma elevada
probabilidade de revelar um erro ainda no descoberto
3. um teste bem-sucedido aquele que revela um erro ainda
no descoberto.
Transparncia 28
1.3 Objetivos da Atividade de Teste
Objetivo: projetar testes que descubram sistematicamente
diferentes classes de erros e faam-no com uma quantidade de
tempo e esforo razovel.
Se a atividade de teste for conduzida com sucesso, ela
descobrir erros no software.
A atividade de teste no pode mostrar a ausncia de bugs.
Ela s pode mostrar se defeitos de software esto presentes.
Transparncia 29
1.4 Erros e as Atividades de Teste
Se erros graves forem encontrados com regularidade,
isto implica que a qualidade e a confiabilidade de software
so suspeitas.
Se erros facilmente corrigveis forem encontrados, isto
implica que a qualidade e a confiabilidade do software esto
aceitveis ou os testes so inadequados para revelar erros
graves
Se no for encontrado erro isto implica que a
configurao de teste no foi suficientemente elaborada e
erros esto escondidos no software
Transparncia 30
1.5 O Processo de Teste
Transparncia 31
2. Contexto
2.1 Princpios Bsicos
2.2 Estratgia de Teste
2.3 Verificao e Validao
2.4 Garantia de Qualidade de Software
Transparncia 32
2.1 Princpios Bsicos
Teste um conjunto de atividades que pode ser planejado
antecipadamente e realizado sistematicamente.
- o planejamento e a realizao das atividades de teste
definem a estratgia de testes de software.
- uma estratgia de teste de software define tcnicas de
projeto de casos de teste e mtodos de teste especficos
para cada etapa do processo de engenharia de software.
Transparncia 33
2.2 Estratgia de Teste de Software
Uma Estratgia de Teste Estratgia de Teste deve acomodar testes de baixo nvel e
testes de alto nvel, deve oferecer orientao ao profissional,
deve oferecer um conjunto de marcos de referncia ao
administrador e deve ser mensurvel.
Transparncia 34
Caractersticas das Estratgias de Teste (a)
a atividade de teste inicia-se no nvel de mdulos e
prossegue "para fora", na direo da integrao de todo o
sistema
diferentes tcnicas de teste so apropriadas a diferentes
pontos de tempo.
a atividade de teste realizada pela equipe de
desenvolvimento do software e para grandes projetos por
um grupo de teste independente.
Transparncia 35
Caractersticas das Estratgias de Teste (b)
as atividades de teste e de depurao so atividades
diferentes, mas a depurao deve ser acomodada em
qualquer estratgia de teste.
deve oferecer um conjunto de marcos de referncia ao
administrador e deve ser mensurvel.
Transparncia 36
2.3 Verificao e Validao (V&V)
A atividade de teste de software um elemento de um tema
mais amplo chamado Verificao e Validao Verificao e Validao (V&V). (V&V).
A definio de V&V abrange muitas das atividades s quais
nos referimos como Garantia da Qualidade de Software
(SQA).
Transparncia 37
Verificao
software implementa corretamente uma funo especfica.
Estamos construindo certo o produto?
Transparncia 38
Validao
software que foi construdo rastrevel s exigncias do
cliente.
Estamos construindo o produto certo?
Transparncia 39
2.4 Garantia da Qualidade de Software
Mtodos de Engenharia de Software: proporcionam a base
a partir da qual a qualidade construda.
Revises Tcnicas Formais: ajudam a garantir a qualidade
do produto produzido como uma conseqncia de cada passo
da engenharia de software.
Medio: ajudam a controlar cada elemento da
configurao de software.
Transparncia 40
Garantia da Qualidade de Software (cont.)
Padres e Procedimentos: ajudam a garantir a uniformidade.
Garantia de Qualidade de Software (SQA): pe em prtica
uma filosofia de qualidade total.
Teste: a qualidade pode ser avaliada.
Transparncia 41
Transparncia 42
3. Organizao para Realizao de Testes
3.1 Desenvolvedores x Testadores
3.2 Como as pessoas vem os testes
3.3 O Grupo Independente de Teste
3.4 Etapas do Teste de Software
3.5 Critrios para Concluso de Testes
Transparncia 43
3.1 Desenvolvedores x Testadores
Quando o teste se inicia h um conflito de interesses:
Desenvolvedores: interesse em demonstrar que o
programa isento de erros.
Responsveis pelos testes: interesse em mostrar que o
programa tem erros.
Transparncia 44
3.2 Como as Pessoas Vem os Testes
Do ponto de vista psicolgico, as pessoas vem os testes
com uma tarefa destrutiva:
Anlise, Projeto e Codificao de Software so tarefas
construtivas
Teste tarefa destrutiva pois visa descobrir problemas
Transparncia 45
3.3 Grupo Independente de Teste
Para suprir o conflito de interesses existe o Grupo Grupo
Independente de Testes Independente de Testes (ITG).
ITG faz parte da equipe de projeto de desenvolvimento
de software, no sentido de estarem envolvidos durante o
processo de especificao e continuam planejando e
especificando procedimentos de teste ao longo de um
grande projeto.
Transparncia 46
3.4 Etapas do Teste de Software
+Testes de Unidade: cada mdulo testado individualmente
garantindo que ele funcione adequadamente. Utiliza as tcnicas de
teste de caixa branca caixa branca.
+Testes de Integrao: os mdulos so montados ou integrados
para formarem um pacote de software. Utiliza principalmente as
tcnicas de teste de caixa preta caixa preta.
+Testes de Alto Nvel (validao e sistema): Os critrios de
validao estabelecidos durante a anlise de requisitos so testados.
Verifica tambm se todos os elementos combinam-se adequadamente
e se a funo/ desempenho global do sistema conseguida. Utiliza as
tcnicas de caixa preta caixa preta.
Transparncia 47
Etapas do Teste de Software
Transparncia 48
3.5 Critrios para Concluso de Teste
Quando realizamos testes, como saber se j testamos o
suficiente?
Respostas pragmticas:
CVoc jamais ter completado a atividade de teste; a carga
simplesmente transfere-se do projetista para o cliente.
CQuando estiver sem tempo ou sem dinheiro.
Transparncia 49
Um Modelo Emprico (a)
Modelo Logartmico do Tempo de Execuo de Poisson:
intensidade de erros real pode ser traada em relao a curva
prevista.
Transparncia 50
Um Modelo Emprico (b)
Transparncia 51
4 Executando Testes
4.1 Nveis de Testes
4.2 Teste de Unidade
4.3 Teste de Integrao
4.4 Teste de Validao
4.5 Teste de Sistema
Transparncia 52
4.1 Nveis de Teste
;Teste de Unidade: concentra-se em cada unidade do software,
de acordo com o que implementado no cdigo fonte.
;Teste de Integrao: concentra-se no projeto e na construo
da arquitetura de software.
;Teste de Validao: em como o software que foi construdo
validado em relao aos requisitos de software.
;Teste de Sistema: o software e outros elementos do sistema
so testados como um todo.
Transparncia 53
Transparncia 54
4.2 Teste de Unidade
Os Testes de Unidade concentram-se em cada unidade do
software, de acordo com o que implementado no cdigo fonte.
Transparncia 55
O Que Testado (a)
Ca interface com o mdulo testada para ter a garantia de que
as informaes fluem para dentro e para fora da unidade de
programa que se encontra sob teste
Ca estrutura de dados local examinada para ter a garantia
de que dados armazenados temporariamente mantm sua
integridade durante todos os passos de execuo.
Transparncia 56
Cas condies de limite so testadas para ter a garantia de que
o mdulo opera adequadamente nos limites estabelecidos para
demarcarem ou restringirem o processamento.
Ctodos os caminhos independentes atravs da estrutura de
controle so exercitados para ter a garantia de que todas as
instrues de um mdulo foram executadas pelo menos uma
vez.
O Que Testado (b)
Transparncia 57
Ctodos os caminhos de tratamento de erros so testados.
O Que Testado (c)
Interface
Estruturas de dados locais
Condies limite
Caminhos independentes
Caminhos de tratamento de erros
Casos de Teste
Transparncia 58
O Ambiente de Teste de Unidade (a)
Uma vez que o mdulo no um programa individual, um
software driver e/ou stub deve ser desenvolvido para cada
unidade de teste.
Transparncia 59
O Ambiente de Teste de Unidade (b)
=Driver na maioria das aplicaes um programa principal que
aceita dados de caso de teste, passa tais dados para o mdulo a
ser testado e imprime os dados relevantes.
=Stub ou programa simulado - serve para substituir mdulos
que estejam subordinados (chamados pelo) ao mdulo a ser
testado. Usa a interface do mdulo subordinado, pode fazer
manipulao de dados mnima, imprime verificao de entrada e
retorna.
Transparncia 60
O Ambiente de Teste de Unidade (c)
Driver
mdulo a
ser testado
Stub 1 Stub 2
Resultados
Interface
Estruturas de dados
locais
Condies limites
Caminhos execuo
Caminhos de tratamento
de erros
casos de teste
Transparncia 61
4.3 Teste de Integrao
Os Testes de Integrao concentram-se no projeto e na
construo da arquitetura de software, almejam descobrir
erros associados a interfaces interfaces.
O objetivo , a partir dos mdulos testados ao nvel de
unidade, integr-los, e testar se a estrutura de programa
construda foi aquela determinada pelo projeto.
Transparncia 62
Transparncia 63
Abordagens
Integrao no incremental: (abordagem big-bang) o
programa completo testado como um todo e o resultado o
caos. Quando erros so encontrados, a correo difcil porque o
isolamento das causas complicado pela vasta amplitude do
programa inteiro.
Integrao incremental: o programa construdo e testado em
pequenos segmentos, onde os erros so mais fceis de serem
isolados e corrigidos; as interfaces tm maior probabilidade de
serem testadas completamente e uma abordagem sistemtica ao
teste pode ser aplicada.
Transparncia 64
Integrao Top-Down (a)
Os mdulos so integrados movimentando-se de cima para
baixo, atravs da hierarquia de controle, iniciando-se do mdulo
de controle principal.
Os mdulos subordinados ao mdulo de controle principal
so incorporados estrutura de uma maneira depth-first
(primeiro pela profundidade) ou breadth-first (primeiramente
pela largura).
Transparncia 65
Integrao Top-Down (b)
Transparncia 66
Passos do Processo de Integrao Top-Down (a)
1. o mdulo de controle usado como um driver de teste e
os stubs so substitudos para todos os mdulos
diretamente subordinados ao mdulo de controle principal.
2. dependendo da abordagem de integrao escolhida, os
stubs subordinados so substitudos, um de cada vez por
mdulos reais.
3. testes so realizados medida que cada mdulo
integrado.
Transparncia 67
4. durante a concluso de cada conjunto de testes, outro stub
substitudo pelo mdulo real.
5. teste de regresso - (realizao de todos ou de alguns dos
testes anteriores) pode ser realizado a fim de garantir que
novos erros no tenham sido introduzidos.
Passos do Processo de Integrao Top-Down (b)
Transparncia 68
4.4 Teste de Validao
Os Testes de Validao concentram-se em como os requisitos
estabelecidos como parte da anlise de requisitos de software
so validados em relao ao software que foi construdo.
Transparncia 69
Transparncia 70
Contexto
Ao trmino da atividade de teste de integrao, o software
est completamente montado como um pacote, erros de
interface foram descobertos e corrigidos e uma srie final
de testes de software - os testes de validao testes de validao - pode iniciar-
se.
Transparncia 71
Princpios (a)
A validao bem sucedida quando o software funciona de
uma maneira razoavelmente esperada pelo cliente.
A Especificao de Requisitos de Software Especificao de Requisitos de Software contm os
critrios de validao critrios de validao que formam a base para uma
abordagem ao teste de validao.
A validao do software realizada por meio de uma srie
de testes de caixa preta que demonstram a conformidade com
os requisitos.
Transparncia 72
O plano e o procedimento de teste so projetados para garantir
que:
todos os requisitos funcionais so satisfeitos
todos os requisitos de desempenho so conseguidos
a documentao est correta
outros requisitos so cumpridos: portabilidade,
compatibilidade, remoo de erros e manutenabilidade
Princpios (b)
Transparncia 73
Reviso de Configurao
Um elemento importante do processo de validao a reviso reviso
de configurao de configurao ou auditoria
O propsito dessa reviso garantir que todos os elementos
da configurao de software tenham sido adequadamente
desenvolvidos, esto catalogados e tm os detalhes
necessrios para apoiar a fase de manuteno do ciclo de vida
do software.
Transparncia 74
Transparncia 75
virtualmente impossvel que se preveja como o cliente
realmente usar/reagir a um programa (as instrues de uso
podem ser mal-interpretadas, combinaes estranhas de dados
podem ser irregularmente usadas, sadas que pareciam claras ao
analista podem ser ininteligveis para um usurios, etc).
Testes devem ser feitos para se saber isto. Existem duas famlias
de testes com esta finalidade:
Testes de Aceitao
Testes Alfa e Testes Beta
Testes Alfa e Beta x Teste de Aceitao
Transparncia 76
Usado quando o software customizado para um cliente
=objetiva capacitar/permitir ao usurio final a validar
todos os requisitos.
=pode variar de um test drive informal a uma srie de
testes planejados.
Teste de Aceitao
Transparncia 77
Usado quando o software desenvolvido como um produto
para muitos clientes, geralmente tem duas fases:
Teste Alfa Teste Alfa - levado a efeito por um cliente nas instalaes do
desenvolvedor.
O software usado num ambiente controlado com o desenvolvedor
"olhando sobre os ombros" do usurio e registrando erros e problemas de
uso.
Testes Alfa e Beta (a)
Transparncia 78
Teste Beta Teste Beta - realizado nas instalaes do cliente pelo
usurio final do software. O desenvolvedor no est
presente.
O cliente registra os problemas (reais ou imaginrios) que so
encontrados e relata-os ao desenvolvedor a intervalos regulares.
Testes Alfa e Beta (b)
Transparncia 79
4.5 Teste de Sistema
O software apenas um elemento de um sistema
baseado em computador mais amplo.
O teste de sistema envolve uma srie de diferentes testes,
cujo propsito primordial por completamente prova o
sistema baseado em computador.
Transparncia 80
Transparncia 81
"apontar o dedo" - quando ocorre um erro, o desenvolvedor
de um elemento do sistema culpa outro pelo problema.
Um Problema Clssico no Teste de Sistema
Transparncia 82
O engenheiro de sistema deve antecipar os problemas
potenciais da interface:
1. projetar caminhos de tratamento de erros que testem todas as
informaes que chegam de outros elementos do sistema.
2. realizar uma srie de testes que simulem dados ruins ou
outros erros em potencial na interface do software.
3. registrar os resultados de teste para usar como "prova" se
algum lhe apontar o dedo.
4. participar do planejamento e projeto dos testes do sistema
para garantir que o software seja adequadamente testado.
Princpios
Transparncia 83
Muitos sistemas baseados em computador precisam recuperar-se de
falhas e retomar o processamento dentro de um tempo previamente
especificado. Em certos casos, o sistema deve tolerar falhas, isto ,
o processamento de falhas no deve fazer com que uma funo
global de sistema cesse. Em outros casos, uma falha do sistema
deve ser corrigida dentro de um perodo previamente especificado;
caso contrrio, graves prejuzos econmicos ocorrero.
O teste de recuperao um teste de sistema que fora o software a
falhar de diversas maneiras e verifica se a recuperao
adequadamente executada.
Teste de Recuperao
Transparncia 84
Qualquer sistema baseado em computador que gerencie
informaes delicadas ou provoque aes que possam
impropriamente prejudicar (ou beneficiar) pessoas constitui um
alvo para o acesso imprprio ou ilegal.
O teste de segurana tenta verificar se todos os mecanismos de
proteo embutidos num sistema o protegero, de fato, de
acessos indevidos.
Teste de Segurana (a)
Transparncia 85
Durante o teste de segurana, o analista desempenha o papel de
pessoa que deseja penetrar no sistema. Qualquer coisa vale!
adquirir senhas mediante contatos externos
atacar o sistema com software customizado projetado para
derrubar quaisquer defesas que tenham sido construdas
Teste de Segurana (b)
Transparncia 86
desarmar o sistema, negando servio a outros
provocar erros intencionalmente, esperando acess-lo
durante a recuperao
"folhear" atravs de dados inseguros esperando descobrir a
chave para a entrada no sistema.
O papel do projetista do sistema fazer com que o acesso custe
mais do que o valor da informao que ser obtida.
Teste de Segurana (c)
Transparncia 87
5 Depurando Software
5.5.1 O Qu depurao
5.5.2 Abordagens depurao
Transparncia 88
O objetivo primordial da depurao ou debugging descobrir
e corrigir a causa de um erro de software.
A depurao ocorre em conseqncia de testes bem
sucedidos. Embora a depurao possa e deva ser ser um
processo disciplinado, ela ainda tem muito de arte.
5.5.1 O Qu Depurao
Transparncia 89
O Processo de Depurao
Transparncia 90
Durante a depurao, encontram-se erros que variam
de brandamente perturbadores a catastrficos.
medida que as conseqncias de uma falha
aumentam, a presso para descobrir a causa tambm
aumenta.
Severidade de Erros
Transparncia 91
1) O sintoma e a causa podem ser geograficamente remotos.
Estruturas altamente acopladas agravam essa situao.
2) O sintoma pode desaparecer (temporariamente) quando
outro erro corrigido.
3) O sintoma pode, de fato, ser causado por no erros (por
exemplo, imprecises de arredondamento).
Por que a Depurao Difcil? (a)
Transparncia 92
4) O sintoma pode ser causado por um erro humano que no
facilmente rastreado.
5) O sintoma pode ser resultado de problemas de
temporizao, e no problemas de processamento.
6) O sintoma pode ser devido a causas que esto distribudas
por uma srie de tarefas que so executadas em diferentes
processadores.
Por que a Depurao Difcil? (b)
Transparncia 93
1 - Fora bruta
2 - Backtracking
3 - Eliminao da Causa
5.5.2 Abordagens Depurao
Transparncia 94
A categoria de depurao por fora bruta provavelmente o
mtodo mais comum e menos eficiente de isolar a causa de um
erro de software.
Usa-se uma filosofia do tipo "deixe que o computador
descubra o erro". Por exemplo, so feitas listagens de memria
(memory dumps), so inseridas instrues WRITE, etc.
Aplica-se o mtodo de fora bruta quando tudo o mais falha.
Fora Bruta (a)
Transparncia 95
Espera-se encontrar, em algum lugar do emaranhado de
informaes, uma pista que possa levar causa de um erro.
No obstante, a massa de informaes produzida possa levar
ao sucesso, mais freqentemente ela conduz a tempo e esforo
desperdiados.
Deve-se gastar o raciocnio primeiro.
Fora Bruta (b)
Transparncia 96
Iniciando-se no local em que o sintoma foi descoberto, o
cdigo fonte rastreado para trs (manualmente) at que o
local da causa seja encontrado.
uma abordagem que pode ser usada com sucesso em
pequenos programas.
Infelizmente, medida que o nmero de linhas de cdigo
aumenta, o nmero de potenciais caminhos de backtracking
pode tornar-se incontrolavelmente alto.
Backtracking
Transparncia 97
Os dados relacionados ocorrncia de erros so organizados
para isolar potenciais causas.
Uma "hiptese de causa" imaginada e os dados so usados
para provar ou refutar a hiptese. Alternativamente, uma lista de
todas as causas possveis desenvolvida e testes so realizados
para eliminar cada uma delas.
Se os testes iniciais indicarem que uma hiptese de causa
apresenta possibilidades, os dados so refinados, numa tentativa
de isolar o bug.
Eliminao da Causa
Transparncia 98
As abordagens de depurao podem ser complementadas
com ferramentas de depurao:
compiladores de depurao,
auxlio rastreadores de depurao dinmicos,
geradores de casos de teste automticos, geradores de
dumps de memria e
geradores de mapas de referncia cruzada.
5.5.3 Dicas Sobre Depurao (a)
Transparncia 99
Um poderoso aliado depurao so "outras pessoas".
O conceito de programao no egostica deve ser ampliado
para "depurao no egostica".
Dicas Sobre Depurao (b)
Transparncia 100
Assim que um erro encontrado, ele deve ser corrigido, porm a
correo de um erro pode introduzir outros erros. Assim, deve-
se fazer 3 perguntas simples, sempre que se realizar uma
"correo" que remover a causa de um erro:
1- A causa do bug reproduzida em outra parte do programa?
2- Qual "bug seguinte" poderia ser introduzido pelo reparo que
se est prestes a fazer?
3- O que poderia ter sido feito para eliminar este bug desde o
princpio?
Dicas Sobre Depurao (c)

Validação de Software Prof-Manuel Mendonça Mod1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Validação de Software Prof-Manuel Mendonça Mod1

Enviado por

Direitos autorais:

Formatos disponíveis

Transparncia 1

Validao de Software Mdulo 1 Conceitos Bsicos

Você também pode gostar