Este documento apresenta conceitos básicos sobre validação de software. Ele discute tópicos como defeitos e falhas, verificação versus validação, garantia da qualidade de software e testes de software. O documento também fornece detalhes sobre organização para realização de testes, técnicas de teste e processos de teste.
10. 0.1 Defeitos e Falhas
• Defeito
– um problema nos requisitos, no projeto, no código,
na documentação ou nos casos de teste
• Falha
– um problema no funcionamento do sistema
Falha: conseqüência de um defeito
Validação de Software – Módulo 1 Conceitos Básicos Transparência 10
11. Defeitos e Falhas: Uma Visão Mais Completa
Engano (mistake) => “erro” cometido “cabeça” do eng. de
software
Defeito (fault) => “erro” inserido no software
Erro (error) => “execução” do “erro” conduzindo a um estado
incorreto do software
Falha (failure) => manifestação externa do “erro”
Validação de Software – Módulo 1 Conceitos Básicos Transparência 11
12. Principais Artefatos de Software
Uma Visão Simplificada
Especificação Projeto Código
de requisitos
Defeitos ocorrem em todos eles !!!
Validação de Software – Módulo 1 Conceitos Básicos Transparência 12
13. Defeitos Introduzidos ao Longo do Processo de
Desenvolvimento
• A maior parte é de origem humana.
• São gerados na comunicação e na transformação de
informações.
• 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.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 13
14. 0.2 Alguns Tipos de Defeitos Introduzidos
Tipo de Descrição Geral
Defeito
Omissão Informação necessária do sistema foi omitida do artefato de
software.
Fato Incorreto Alguma informação no artefato de software contradiz
informação do documento de outra informação no artefato de
software.
Inconsistência Informação contida em uma parte do artefato de software está
inconsistente com outra informação no artefato de software.
Ambigüidade Informação contida no artefato de software é ambígua, isto é,
várias interpretações podem ser derivadas da definição levando
o desenvolvedor à implementação correta.
Informação Informação que é fornecida e não é necessária ou nunca
Estranha utilizada
Validação de Software – Módulo 1 Conceitos Básicos Transparência 14
15. Tipos de Defeitos Introduzidos
Copyright Guilherme Travassos
COPPE/UFRJ – 2003 - http://www.cos.ufrj.br/~ght
De onde os defeitos vêm?
Que defeitos podemos encontrar?
Outro
Domínio
Conhecimento do
domínio
Requisitos
Fato incorreto
Gerais Informação
estranha
Artefatos de
Omissão Software
Inconsistência
Ambigüidade
Validação de Software – Módulo 1 Conceitos Básicos Transparência 15
16. Defeitos Introduzidos ao Longo do Processo
de Desenvolvimento
• Principal causa:
• tradução incorreta de informações.
• Quanto antes a presença do defeito for revelada,
menor o custo de correção do defeito e maior a
probabilidade de corrigi-lo corretamente.
• Solução:
• Introduzir atividades de V V & T ao longo de
todo o ciclo de desenvolvimento.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 16
17. 0.3 Verificação e Validação (V&V)
As atividades de avaliação de produtos são parte do tema
chamado Verificação e Validação (V&V).
A definição de V&V abrange muitas das atividades às quais
nos referimos como Garantia da Qualidade de Software
(SQA).
Validação de Software – Módulo 1 Conceitos Básicos Transparência 17
18. Verificação
refere-se ao conjunto de atividades que garante que o
software implementa corretamente uma função específica.
“Estamos construindo certo o produto?”
Validação de Software – Módulo 1 Conceitos Básicos Transparência 18
19. Validação
refere-se ao conjunto de atividades que garante que o
software que foi construído é “rastreável” às exigências do
cliente.
“Estamos construindo o produto certo?”
Validação de Software – Módulo 1 Conceitos Básicos Transparência 19
20. 0.4 Garantia da Qualidade de Software
– Métodos de Engenharia de Software: proporcionam a base
a partir da qual a qualidade é construída.
– Revisões Técnicas Formais: ajudam a garantir a qualidade
do produto produzido como uma conseqüência de cada passo
da engenharia de software.
– Medição: ajudam a controlar cada elemento da
configuração de software.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 20
21. Garantia da Qualidade de Software (cont.)
– Padrões e Procedimentos: ajudam a garantir a uniformidade.
– Garantia de Qualidade de Software (SQA): põe em prática
uma filosofia de qualidade total.
– Teste: a qualidade pode ser avaliada.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 21
24. Teste
1 Introdução
2 Contexto
3 Organização para Realização de Testes
4 Executando Teste
5 Depurando Software
6 Técnicas de Teste
Validação de Software – Módulo 1 Conceitos Básicos Transparência 24
25. 1. Introdução
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
Validação de Software – Módulo 1 Conceitos Básicos Transparência 25
26. 1.1 Engenharia de Software e Teste
1- Fase de Definição ("o que")
- Análise do sistema
- Planejamento do projeto de software
- Análise de requisitos
2- Fase de Desenvolvimento ("como")
- Projeto de software
- Codificação
- Realização de testes
3- Fase de Manutenção ("alterações")
Validação de Software – Módulo 1 Conceitos Básicos Transparência 26
27. 1.2 O Quê é Teste
1. a atividade de teste é o processo de executar um programa
com a intenção de descobrir um erro
2. um bom caso de teste é aquele que tem uma elevada
probabilidade de revelar um erro ainda não descoberto
3. um teste bem-sucedido é aquele que revela um erro ainda
não descoberto.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 27
28. 1.3 Objetivos da Atividade de Teste
Objetivo: projetar testes que descubram sistematicamente
diferentes classes de erros e façam-no com uma quantidade de
tempo e esforço razoável.
Se a atividade de teste for conduzida com sucesso, ela
descobrirá erros no software.
• A atividade de teste não pode mostrar a ausência de bugs.
• Ela só pode mostrar se defeitos de software estão presentes.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 28
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
são suspeitas.
Se erros facilmente corrigíveis forem encontrados, isto
implica que a qualidade e a confiabilidade do software estão
aceitáveis ou os testes são inadequados para revelar erros
graves
Se não for encontrado erro isto implica que a
configuração de teste não foi suficientemente elaborada e
erros estão escondidos no software
Validação de Software – Módulo 1 Conceitos Básicos Transparência 29
30. 1.5 O Processo de Teste
Validação de Software – Módulo 1 Conceitos Básicos Transparência 30
31. 2. Contexto
2.1 Princípios Básicos
2.2 Estratégia de Teste
2.3 Verificação e Validação
2.4 Garantia de Qualidade de Software
Validação de Software – Módulo 1 Conceitos Básicos Transparência 31
32. 2.1 Princípios Básicos
Teste é um conjunto de atividades que pode ser planejado
antecipadamente e realizado sistematicamente.
- o planejamento e a realização das atividades de teste
definem a estratégia de testes de software.
- uma estratégia de teste de software define técnicas de
projeto de casos de teste e métodos de teste específicos
para cada etapa do processo de engenharia de software.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 32
33. 2.2 Estratégia de Teste de Software
Uma Estratégia de Teste deve acomodar testes de baixo nível e
testes de alto nível, deve oferecer orientação ao profissional,
deve oferecer um conjunto de marcos de referência ao
administrador e deve ser mensurável.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 33
34. Características das Estratégias de Teste (a)
– a atividade de teste inicia-se no nível de módulos e
prossegue "para fora", na direção da integração de todo o
sistema
– diferentes técnicas de teste são 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.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 34
35. Características das Estratégias de Teste (b)
– as atividades de teste e de depuração são atividades
diferentes, mas a depuração deve ser acomodada em
qualquer estratégia de teste.
– deve oferecer um conjunto de marcos de referência ao
administrador e deve ser mensurável.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 35
36. 2.3 Verificação e Validação (V&V)
A atividade de teste de software é um elemento de um tema
mais amplo chamado Verificação e Validação (V&V).
A definição de V&V abrange muitas das atividades às quais
nos referimos como Garantia da Qualidade de Software
(SQA).
Validação de Software – Módulo 1 Conceitos Básicos Transparência 36
37. Verificação
refere-se ao conjunto de atividades que garante que o
software implementa corretamente uma função específica.
“Estamos construindo certo o produto?”
Validação de Software – Módulo 1 Conceitos Básicos Transparência 37
38. Validação
refere-se ao conjunto de atividades que garante que o
software que foi construído é “rastreável” às exigências do
cliente.
“Estamos construindo o produto certo?”
Validação de Software – Módulo 1 Conceitos Básicos Transparência 38
39. 2.4 Garantia da Qualidade de Software
– Métodos de Engenharia de Software: proporcionam a base
a partir da qual a qualidade é construída.
– Revisões Técnicas Formais: ajudam a garantir a qualidade
do produto produzido como uma conseqüência de cada passo
da engenharia de software.
– Medição: ajudam a controlar cada elemento da
configuração de software.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 39
40. Garantia da Qualidade de Software (cont.)
– Padrões e Procedimentos: ajudam a garantir a uniformidade.
– Garantia de Qualidade de Software (SQA): põe em prática
uma filosofia de qualidade total.
– Teste: a qualidade pode ser avaliada.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 40
42. 3. Organização para Realização de Testes
3.1 Desenvolvedores x Testadores
3.2 Como as pessoas vêem os testes
3.3 O Grupo Independente de Teste
3.4 Etapas do Teste de Software
3.5 Critérios para Conclusão de Testes
Validação de Software – Módulo 1 Conceitos Básicos Transparência 42
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.
–Responsáveis pelos testes: interesse em mostrar que o
programa tem erros.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 43
44. 3.2 Como as Pessoas Vêem os Testes
Do ponto de vista psicológico, as pessoas vêem os testes
com uma tarefa destrutiva:
• Análise, Projeto e Codificação de Software são tarefas
construtivas
• Teste é tarefa destrutiva pois visa descobrir problemas
Validação de Software – Módulo 1 Conceitos Básicos Transparência 44
45. 3.3 Grupo Independente de Teste
Para suprir o conflito de interesses existe o Grupo
Independente de Testes (ITG).
ITG faz parte da equipe de projeto de desenvolvimento
de software, no sentido de estarem envolvidos durante o
processo de especificação e continuam planejando e
especificando procedimentos de teste ao longo de um
grande projeto.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 45
46. 3.4 Etapas do Teste de Software
Testes de Unidade: cada módulo é testado individualmente
garantindo que ele funcione adequadamente. Utiliza as técnicas de
teste de caixa branca.
branca
Testes de Integração: os módulos são montados ou integrados
para formarem um pacote de software. Utiliza principalmente as
técnicas de teste de caixa preta.
preta
Testes de Alto Nível (validação e sistema): Os critérios de
validação estabelecidos durante a análise de requisitos são testados.
Verifica também se todos os elementos combinam-se adequadamente
e se a função/ desempenho global do sistema é conseguida. Utiliza as
técnicas de caixa preta.
preta
Validação de Software – Módulo 1 Conceitos Básicos Transparência 46
47. Etapas do Teste de Software
Validação de Software – Módulo 1 Conceitos Básicos Transparência 47
48. 3.5 Critérios para Conclusão de Teste
Quando realizamos testes, como saber se já testamos o
suficiente?
Respostas pragmáticas:
Você jamais terá completado a atividade de teste; a carga
simplesmente transfere-se do projetista para o cliente.
Quando estiver sem tempo ou sem dinheiro.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 48
49. Um Modelo Empírico (a)
Modelo Logarítmico do Tempo de Execução de Poisson:
intensidade de erros real pode ser traçada em relação a curva
prevista.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 49
50. Um Modelo Empírico (b)
Validação de Software – Módulo 1 Conceitos Básicos Transparência 50
51. 4 Executando Testes
4.1 Níveis de Testes
4.2 Teste de Unidade
4.3 Teste de Integração
4.4 Teste de Validação
4.5 Teste de Sistema
Validação de Software – Módulo 1 Conceitos Básicos Transparência 51
52. 4.1 Níveis de Teste
Teste de Unidade: concentra-se em cada unidade do software,
de acordo com o que é implementado no código fonte.
Teste de Integração: concentra-se no projeto e na construção
da arquitetura de software.
Teste de Validação: em como o software que foi construído é
validado em relação aos requisitos de software.
Teste de Sistema: o software e outros elementos do sistema
são testados como um todo.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 52
54. 4.2 Teste de Unidade
Os Testes de Unidade concentram-se em cada unidade do
software, de acordo com o que é implementado no código fonte.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 54
55. O Que é Testado (a)
a interface com o módulo é testada para ter a garantia de que
as informações fluem para dentro e para fora da unidade de
programa que se encontra sob teste
a estrutura de dados local é examinada para ter a garantia
de que dados armazenados temporariamente mantêm sua
integridade durante todos os passos de execução.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 55
56. O Que é Testado (b)
as condições de limite são testadas para ter a garantia de que
o módulo opera adequadamente nos limites estabelecidos para
demarcarem ou restringirem o processamento.
todos os caminhos independentes através da estrutura de
controle são exercitados para ter a garantia de que todas as
instruções de um módulo foram executadas pelo menos uma
vez.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 56
57. O Que é Testado (c)
todos os caminhos de tratamento de erros são testados.
Interface
Estruturas de dados locais
Condições limite
Caminhos independentes
Caminhos de tratamento de erros
Casos de Teste
Validação de Software – Módulo 1 Conceitos Básicos Transparência 57
58. O Ambiente de Teste de Unidade (a)
Uma vez que o módulo não é um programa individual, um
software driver e/ou stub deve ser desenvolvido para cada
unidade de teste.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 58
59. O Ambiente de Teste de Unidade (b)
Driver na maioria das aplicações é um programa principal que
aceita dados de caso de teste, passa tais dados para o módulo a
ser testado e imprime os dados relevantes.
Stub ou programa simulado - serve para substituir módulos
que estejam subordinados (chamados pelo) ao módulo a ser
testado. Usa a interface do módulo subordinado, pode fazer
manipulação de dados mínima, imprime verificação de entrada e
retorna.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 59
60. O Ambiente de Teste de Unidade (c)
• Interface
• Estruturas de dados
locais
Driver • Condições limites
• Caminhos execução
módulo a • Caminhos de tratamento
ser testado de erros
Resultados
Stub 1 Stub 2
casos de teste
Validação de Software – Módulo 1 Conceitos Básicos Transparência 60
61. 4.3 Teste de Integração
Os Testes de Integração concentram-se no projeto e na
construção da arquitetura de software, almejam descobrir
erros associados a interfaces.
interfaces
O objetivo é, a partir dos módulos testados ao nível de
unidade, integrá-los, e testar se a estrutura de programa
construída foi aquela determinada pelo projeto.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 61
63. Abordagens
Integração não incremental: (abordagem “big-bang”) o
programa completo é testado como um todo e o resultado é o
caos. Quando erros são encontrados, a correção é difícil porque o
isolamento das causas é complicado pela vasta amplitude do
programa inteiro.
Integração incremental: o programa é construído e testado em
pequenos segmentos, onde os erros são mais fáceis de serem
isolados e corrigidos; as interfaces têm maior probabilidade de
serem testadas completamente e uma abordagem sistemática ao
teste pode ser aplicada.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 63
64. Integração Top-Down (a)
Os módulos são integrados movimentando-se de cima para
baixo, através da hierarquia de controle, iniciando-se do módulo
de controle principal.
Os módulos subordinados ao módulo de controle principal
são incorporados à estrutura de uma maneira depth-first
(primeiro pela profundidade) ou breadth-first (primeiramente
pela largura).
Validação de Software – Módulo 1 Conceitos Básicos Transparência 64
66. Passos do Processo de Integração Top-Down (a)
1. o módulo de controle é usado como um driver de teste e
os stubs são substituídos para todos os módulos
diretamente subordinados ao módulo de controle principal.
2. dependendo da abordagem de integração escolhida, os
stubs subordinados são substituídos, um de cada vez por
módulos reais.
3. testes são realizados à medida que cada módulo é
integrado.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 66
67. Passos do Processo de Integração Top-Down (b)
4. durante a conclusão de cada conjunto de testes, outro stub
é substituído pelo módulo real.
5. teste de regressão - (realização de todos ou de alguns dos
testes anteriores) pode ser realizado a fim de garantir que
novos erros não tenham sido introduzidos.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 67
68. 4.4 Teste de Validação
Os Testes de Validação concentram-se em como os requisitos
estabelecidos como parte da análise de requisitos de software
são validados em relação ao software que foi construído.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 68
70. Contexto
Ao término da atividade de teste de integração, o software
está completamente montado como um pacote, erros de
interface foram descobertos e corrigidos e uma série final
de testes de software - os testes de validação - pode iniciar-
se.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 70
71. Princípios (a)
A validação é bem sucedida quando o software funciona de
uma maneira razoavelmente esperada pelo cliente.
A Especificação de Requisitos de Software contém os
critérios de validação que formam a base para uma
abordagem ao teste de validação.
A validação do software é realizada por meio de uma série
de testes de caixa preta que demonstram a conformidade com
os requisitos.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 71
72. Princípios (b)
O plano e o procedimento de teste são projetados para garantir
que:
todos os requisitos funcionais são satisfeitos
todos os requisitos de desempenho são conseguidos
a documentação está correta
outros requisitos são cumpridos: portabilidade,
compatibilidade, remoção de erros e manutenabilidade
Validação de Software – Módulo 1 Conceitos Básicos Transparência 72
73. Revisão de Configuração
Um elemento importante do processo de validação é a revisão
de configuração ou auditoria
O propósito dessa revisão é garantir que todos os elementos
da configuração de software tenham sido adequadamente
desenvolvidos, estão catalogados e têm os detalhes
necessários para apoiar a fase de manutenção do ciclo de vida
do software.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 73
75. Testes Alfa e Beta x Teste de Aceitação
É virtualmente impossível que se preveja como o cliente
realmente usará/reagirá a um programa (as instruções de uso
podem ser mal-interpretadas, combinações estranhas de dados
podem ser irregularmente usadas, saídas que pareciam claras ao
analista podem ser ininteligíveis para um usuários, etc).
Testes devem ser feitos para se saber isto. Existem duas famílias
de testes com esta finalidade:
– Testes de Aceitação
– Testes Alfa e Testes Beta
Validação de Software – Módulo 1 Conceitos Básicos Transparência 75
76. Teste de Aceitação
Usado quando o software é customizado para um cliente
objetiva capacitar/permitir ao usuário final a validar
todos os requisitos.
pode variar de um test drive informal a uma série de
testes planejados.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 76
77. Testes Alfa e Beta (a)
Usado quando o software é desenvolvido como um produto
para muitos clientes, geralmente tem duas fases:
Teste Alfa - é levado a efeito por um cliente nas instalações do
desenvolvedor.
O software é usado num ambiente controlado com o desenvolvedor
"olhando sobre os ombros" do usuário e registrando erros e problemas de
uso.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 77
78. Testes Alfa e Beta (b)
Teste Beta - é realizado nas instalações do cliente pelo
usuário final do software. O desenvolvedor não está
presente.
O cliente registra os problemas (reais ou imaginários) que são
encontrados e relata-os ao desenvolvedor a intervalos regulares.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 78
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 série de diferentes testes,
cujo propósito primordial é por completamente à prova o
sistema baseado em computador.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 79
81. Um Problema Clássico no Teste de Sistema
"apontar o dedo" - quando ocorre um erro, o desenvolvedor
de um elemento do sistema culpa outro pelo problema.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 81
82. Princípios
O engenheiro de sistema deve antecipar os problemas
potenciais da interface:
1. projetar caminhos de tratamento de erros que testem todas as
informações que chegam de outros elementos do sistema.
2. realizar uma série 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
alguém lhe apontar o dedo.
4. participar do planejamento e projeto dos testes do sistema
para garantir que o software seja adequadamente testado.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 82
83. Teste de Recuperação
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 não deve fazer com que uma função
global de sistema cesse. Em outros casos, uma falha do sistema
deve ser corrigida dentro de um período previamente especificado;
caso contrário, graves prejuízos econômicos ocorrerão.
O teste de recuperação é um teste de sistema que força o software a
falhar de diversas maneiras e verifica se a recuperação é
adequadamente executada.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 83
84. Teste de Segurança (a)
Qualquer sistema baseado em computador que gerencie
informações delicadas ou provoque ações que possam
impropriamente prejudicar (ou beneficiar) pessoas constitui um
alvo para o acesso impróprio ou ilegal.
O teste de segurança tenta verificar se todos os mecanismos de
proteção embutidos num sistema o protegerão, de fato, de
acessos indevidos.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 84
85. Teste de Segurança (b)
Durante o teste de segurança, 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 construídas
Validação de Software – Módulo 1 Conceitos Básicos Transparência 85
86. Teste de Segurança (c)
desarmar o sistema, negando serviço a outros
provocar erros intencionalmente, esperando acessá-lo
durante a recuperação
"folhear" através 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 informação que será obtida.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 86
87. 5 Depurando Software
5.5.1 O Quê é depuração
5.5.2 Abordagens à depuração
Validação de Software – Módulo 1 Conceitos Básicos Transparência 87
88. 5.5.1 O Quê é Depuração
O objetivo primordial da depuração ou debugging é descobrir
e corrigir a causa de um erro de software.
A depuração ocorre em conseqüência de testes bem
sucedidos. Embora a depuração possa e deva ser ser um
processo disciplinado, ela ainda tem muito de arte.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 88
89. O Processo de Depuração
Validação de Software – Módulo 1 Conceitos Básicos Transparência 89
90. Severidade de Erros
Durante a depuração, encontram-se erros que variam
de brandamente perturbadores a catastróficos.
À medida que as conseqüências de uma falha
aumentam, a pressão para descobrir a causa também
aumenta.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 90
91. Por que a Depuração é Difícil? (a)
1) O sintoma e a causa podem ser geograficamente remotos.
Estruturas altamente acopladas agravam essa situação.
2) O sintoma pode desaparecer (temporariamente) quando
outro erro é corrigido.
3) O sintoma pode, de fato, ser causado por não erros (por
exemplo, imprecisões de arredondamento).
Validação de Software – Módulo 1 Conceitos Básicos Transparência 91
92. Por que a Depuração é Difícil? (b)
4) O sintoma pode ser causado por um erro humano que não é
facilmente rastreado.
5) O sintoma pode ser resultado de problemas de
temporização, e não problemas de processamento.
6) O sintoma pode ser devido a causas que estão distribuídas
por uma série de tarefas que são executadas em diferentes
processadores.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 92
93. 5.5.2 Abordagens à Depuração
1 - Força bruta
2 - Backtracking
3 - Eliminação da Causa
Validação de Software – Módulo 1 Conceitos Básicos Transparência 93
94. Força Bruta (a)
A categoria de depuração por força bruta provavelmente é o
método 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, são feitas listagens de memória
(memory dumps), são inseridas instruções WRITE, etc.
Aplica-se o método de força bruta quando tudo o mais falha.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 94
95. Força Bruta (b)
Espera-se encontrar, em algum lugar do emaranhado de
informações, uma pista que possa levar à causa de um erro.
Não obstante, a massa de informações produzida possa levar
ao sucesso, mais freqüentemente ela conduz a tempo e esforço
desperdiçados.
Deve-se gastar o raciocínio primeiro.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 95
96. Backtracking
Iniciando-se no local em que o sintoma foi descoberto, o
código fonte é rastreado para trás (manualmente) até que o
local da causa seja encontrado.
É uma abordagem que pode ser usada com sucesso em
pequenos programas.
Infelizmente, à medida que o número de linhas de código
aumenta, o número de potenciais caminhos de backtracking
pode tornar-se incontrolavelmente alto.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 96
97. Eliminação da Causa
Os dados relacionados à ocorrência de erros são organizados
para isolar potenciais causas.
Uma "hipótese de causa" é imaginada e os dados são usados
para provar ou refutar a hipótese. Alternativamente, uma lista de
todas as causas possíveis é desenvolvida e testes são realizados
para eliminar cada uma delas.
Se os testes iniciais indicarem que uma hipótese de causa
apresenta possibilidades, os dados são refinados, numa tentativa
de isolar o bug.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 97
98. 5.5.3 Dicas Sobre Depuração (a)
As abordagens de depuração podem ser complementadas
com ferramentas de depuração:
compiladores de depuração,
auxílio rastreadores de depuração dinâmicos,
geradores de casos de teste automáticos, geradores de
dumps de memória e
geradores de mapas de referência cruzada.
Validação de Software – Módulo 1 Conceitos Básicos Transparência 98
99. Dicas Sobre Depuração (b)
Um poderoso aliado à depuração são "outras pessoas".
O conceito de “programação não egoística” deve ser ampliado
para "depuração não egoística".
Validação de Software – Módulo 1 Conceitos Básicos Transparência 99
100. Dicas Sobre Depuração (c)
Assim que um erro é encontrado, ele deve ser corrigido, porém a
correção de um erro pode introduzir outros erros. Assim, deve-
se fazer 3 perguntas simples, sempre que se realizar uma
"correção" 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
princípio?
Validação de Software – Módulo 1 Conceitos Básicos Transparência 100