Teste de Software Estratégias de Teste de Software.

Prévia do material em texto

Teste de Software
Estratégias de Teste de Software
Prof. Daniel Silos
2011 – 1ª Edição
Introdução
• Integra métodos de projetos de casos de teste
em uma série bem planejada de passos
objetivando a construção bem-sucedida do
software.
• Fornece roteiro que descreve passos a serem
conduzidos como parte do teste:
– quando os passos são planejados e executados ?
– quanto de esforço, tempo e recursos são
necessários?
2
Introdução
• Qualquer estratégia deve incorporar:
– Planejamento de teste
– Projeto de casos de teste
– Execução e teste;
– Coleta e avaliação de dados (resultado).
3
Introdução
• Deve ser flexível – promover um
planejamento razoável e acompanhamento
gerencial ao projeto.
4
Uma Abordagem Estratégica
• Teste
– Conjunto de atividades que podem ser planejadas
antecipadamente e conduzidas sistematicamente;
– Deve ser definido um gabarito para o teste;
5
Estratégias (1/2)
• Algumas estratégias (que incluem gabarito)
apresentam algumas características genéricas:
- Teste efetivo – a equipe deve conduzir revisões
técnicas formais (erros serão eliminados antes do
teste).
- Teste começa no nível de componente e segue
“para fora”, em direção a integração de todo o
sistema.
6
Estratégias (2/2)
• Algumas estratégias (que incluem gabarito)
apresentam algumas características genéricas:
- Diferentes técnicas de teste são adequadas em
diferentes momentos.
- O teste é conduzido pelo desenvolvedor e (em
projetos grandes) por um grupo de teste
independente.
7
Teste Vs. Depuração
• São tarefas diferentes;
• A depuração deve ser acomodada em 
qualquer estratégia de teste de software;
8
Estratégia
• Deve adequar:
– Testes de baixo nível
• Verificar pequeno fragmento de código-fonte;
– Testes de nível alto
• Validam as principais funções do sistema com base nos
requisitos do cliente
9
Verificação e Validação
• O teste faz parte de um aspecto mais amplo
(V&V – Verificação e Validação).
• Verificação
– Conjunto de atividades que garante que o
software implementa corretamente uma função
específica.
• Validação
– Conjunto de atividades que garante que o
software construído corresponde aos requisitos
do cliente.
10
Verificação e Validação
• Segundo Boehm,
– Verificação: Estamos construindo o produto
corretamente?
– Validação – Estamos construindo o produto certo?
11
Verificação e Validação (1/2)
• A definição V & V engloba muitas das
atividades que são abrangidas pela garantia da
qualidade de software (SQA), que inclui:
• Revisões técnicas formais
• Auditoria de qualidade e configuração
• Monitoramento de desempenho
• Simulação
• Estudo de viabilidade
• Revisão da documentação
12
Verificação e Validação (2/2)
• A definição V & V engloba muitas das
atividades que são abrangidas pela garantia da
qualidade de software (SQA), que inclui:
• Revisão da base de dados
• Análise de algoritmos
• Teste de desenvolvimento
• Teste de usabilidade
• Teste de qualificação
• Teste de instalação
13
“Teste é uma parte inevitável de qualquer
esforço necessário para desenvolver um
sistema de software”
William Howden
14
Teste
• Último reduto no qual a qualidade pode ser
avaliada
• Não deve ser encarado como uma rede de
proteção
• Você não pode testar a qualidade. Se ela não
estiver lá antes de você começar a testar, não
estará lá quando o teste terminar.
• Deve ser utilizado para confirmar a qualidade
oriunda de aplicação de um processo de
Engenharia de Software.
15
Organização do Teste de Software
“Otimismo é o risco ocupacional da 
programação; teste é o tratamento.” 
Kent Beck
16
Ponto de vista psicológico
Análise
Projeto
Implementação
Tarefas 
Construtivas
Teste Tarefa Destrutiva
17
Enfoque do teste pelo Engenheiro
• Provar que o programa funciona.
• Acaba não focando na descoberta de erros.
• Infelizmente erros existirão e se ele não
encontrá-los, o cliente o fará.
18
Quem deve participar do teste ?
• Desenvolvedor
– É sempre responsável por testar unidades
individuais (componentes).
– Em muitos casos, também conduz testes de
integração (um passo que leva à construção (e
teste) da arquitetura completa do software.
• Grupo independente de Teste (Independent
Group Test – ITG)
– Se envolve no projeto após a arquitetura completa
do software ser completada.
19
Quem trabalha e como é o trabalho ?
• O Engenheiro de Software e o ITG trabalham
juntos para garantir a execução de testes
rigorosos;
• O Desenvolvedor deve estar disponível para
corrigir eventuais erros descobertos.
“O primeiro erro que o pessoal comete é pensar que
a equipe de teste é responsável pela garantia de
qualidade.”
Bryan Marich
20
Teste em arquitetura de softwares 
convencionais
21
Testes em arquiteturas orientadas a 
objetos (1/2)
• Apresentam um conjunto diferente de
desafios;
• Definição precisa ser ampliada para incluir
técnicas de descobrimentos de erros (por
exemplo, revisões técnicas formais) aplicada
em modelos de análise e projeto.
• Completeza e consistência de representações
OO precisam ser avaliadas à medida que são
construídas.
22
Testes em arquiteturas orientadas a 
objetos (2/2)
• Teste de unidade perde um tanto do seu
significado e estratégias de integração mudam
significativamente.
• Estratégias de Teste e Táticas de Teste
precisam levar em conta as características
singulares de softwares OO.
23
Critérios para completamento do teste
• Quando o teste é terminado, como saber se
ele foi suficiente?
– Não há uma resposta única;
– Algumas respostas pragmáticas:
• O teste nunca acaba, passa do engenheiro do software
para o seu cliente.
• O teste acaba quando o tempo acaba ou o dinheiro
acaba.
24
Critérios Estatísticos
• Musa & Ackerman
• Ex: 95% de confiança que a probabilidade de
mil horas de operação de CPU livre de falhas,
em um ambiente probabilisticamente
definido, é de pelo menos 0,995.
25
Tópicos Estratégicos (1/4)
• Tom Gilb enfatiza os seguintes tópicos na
implementação de uma estratégia de
software:
– Especificação dos requisitos do produto de um
modo quantificável muito antes do teste começar.
– Enunciar explicitamente os objetivos do teste.
– Entender os usuários do software e desenvolver
um perfil para cada categoria de usuário.
– Desenvolver um plano de teste que enfatiza “teste
de ciclo rápido”.
26
Tópicos Estratégicos (2/4)
• Tom Gilb enfatiza os seguintes tópicos na
implementação de uma estratégia de
software:
– Construir software “robusto”, projetado para
testar a si próprio (técnicas antidefeitos –
diagnóstico de certas classes de erros. O projeto
deve inserir automação de teste e teste de
regressão).
– Usar revisões técnicas formais como filtro antes
do teste.
27
Tópicos Estratégicos (3/4)
• Tom Gilb enfatiza os seguintes tópicos na
implementação de uma estratégia de
software:
– Conduzir revisões técnicas formais para avaliar a
estratégia de teste e os casos de teste
propriamente ditos.
– Desenvolver uma abordagem de aperfeiçoamento
contínuo para o processo de teste (Medição –
Utilização de métricas – abordagem estatística).
28
Tópicos Estratégicos (4/4)
“Testar apenas com base nos requisitos
perceptíveis ao usuário final é como
inspecionar um edifício com base no trabalho
feito pelo decorador de interiores, em
detrimento das fundações, da estrutura e dos
encanamentos.”
Boris Beizer
29
Estratégia – Software Convencional
• Teste de Unidade
– Componente ou módulo do software;
– Enfoca lógica interna de processamento e as
estruturas de dados dentro dos limites de um
componente.
– Pode ser conduzido em paralelo paraos diversos
componentes.
30
Considerações – Teste de unidade
• O que se testa?
– Interface;
– Estrutura lógica dos dados;
– Condições-limites;
– Caminhos independentes;
– Caminhos de manipulação de erros.
31
Considerações – Teste de unidade
• Erros mais comuns:
1. Precedência aritmética mal entendida ou
incorreta;
2. Operações em modo misto;
3. Inicialização incorreta;
4. Falta de precisão;
5. Representação incorreta de uma expressão
32
Considerações – Teste de unidade
• Erros mais comuns no cálculo:
1. Comparações de tipos de dados diferentes;
2. Operadores ou precedência lógica incorreta;
3. Expectativa de igualdade quando o erro de precisão
torna a igualdade improvável
4. Comparação incorreta de variáveis;
5. Terminação de ciclo inadequada ou inexistente;
6. Falha na saída quando iteração divergente é
encontrada;
7. Variáveis de ciclo inadequadamente modificadas.
33
Considerações – Teste de unidade
• Teste nos limites – uma das mais importantes tarefas;
• Entre os erros potenciais que devem ser testados
quando a manipulação de erros é avaliada estão:
1. A descrição do erro é intelegível;
2. O erro mencionado não corresponde ao erro
encontrado;
3. A condição de erro provoca a intervenção do sistema
antes da manipulação do erro;
4. O processamento da condição de exceção está incorreto;
ou
5. A descrição de erro não fornece informação suficiente
para ajudar na localização da causa do erro.
34
Procedimentos de teste de unidade
• É normalmente considerado um apêndice ao
passo de codificação.
• O projeto de teste de unidade pode ser
realizado antes da codificação ser iniciada
(abordagem ágil preferida) ou depois do
código ter sido gerado.
• Cada caso de teste deve ser relacionado a um
conjunto de resultados desejados.
35
Procedimentos de teste de unidade
• Um componente não é um programa isolado, portanto
há necessidade do desenvolvimento de softwares
pseudocontrolador (driver) e/ou pseudocontrolado
(stub) para cada teste de unidade.
• Pseudocontrolador vs. Pseudocontrolado
– Representam despesas indiretas – desenvolvidos mas não
entregues ao cliente.
– Se forem simples, as despesas são baixas.
– Se forem complexos, o teste do módulo pode ser adiado
para o teste integrado (onde haverá também a presença
de pseudocontrolados ou pseudocontroladores)
36
Procedimentos de teste de unidade
• O teste é simplificado quando um módulo de
alta coesão é projetado.
• Quando há apenas uma função por
componente, o número de casos de teste é
reduzido e os erros podem ser mais
facilmente previstos e descobertos.
37
Teste de Integração
• Se todos os módulos funcionam individualmente, por
que voltar a testá-los em conjunto?
• O problema é justamente colocá-los em conjunto –
interfaces.
– Dados podem ser perdidos através de uma interface; um
módulo pode ter efeito imprevisto ou adverso sobre outro;
– Subfunções, quando combinadas podem não produzir a
função principal desejada;
– Imprecisão aceitável individualmente pode ser amplificada
para níveis inaceitáveis;
– Estruturas de dados globais podem apresentar problemas.
38
Integração Descendente
• Também conhecido como top-down.
• É uma abordagem incremental para
construção da arquitetura de software.
• Os módulos são integrados movendo-se
descendentemente pela hierarquia de
controle, começando com o módulo de
controle principal (programa principal).
39
Integração Descendente
• Os módulos subordinados (e os subordinados
em última instância) ao módulo de controle
principal são incorporados à estrutura de
maneira primeiro-em-profundidade ou
primeiro-em-largura.
• Exemplos.
40
Processo de Integração
• Cinco passos:
1. O módulo de controle principal é usado como
pseudocontrolador do teste, e
pseudocontrolados são substituídos por todos os
componentes diretamente subordinados ao
módulo de controle principal.
2. Dependendo da abordagem de integração
selecionada, os pseudocontrolados
subordinados são substituídos, um de cada vez,
pelos componentes reais.
41
Processo de Integração
• Cinco passos:
3. Testes são conduzidos à medida que cada
componente é integrado.
4. Ao término de cada conjunto de testes, outro
pseudocontrolado é substituído pelo
componente real.
5. O teste de regressão pode ser realizado para
garantir que novos erros não tenham sido
introduzidos.
42
Principal problema logístico
• Quando o processamento nos níveis baixos da
hierarquia é necessário para testar adequadamente os
níveis superiores. Pseudocontrolados ficam no lugar
dos módulos de baixo nível, no início do teste
descendente, assim, nenhum dado significativo pode
fluir para cima na estrutura do programa. O testador
fica com três escolhas:
1. Adiar muitos testes, até que pseudocontrolados sejam
substituídos pelos módulos reais;
2. Desenvolver pseudocontrolados que realizam funções
limitadas, simulando o módulo real; ou
3. Integrar o software de baixo para cima, na hierarquia.
• Vantagens e Desvantagens.
43
Integração Ascendente
• Também chamado de Bottom-Up.
• Inicia a construção e teste de módulos 
atômicos (por exemplo, componentes nos 
níveis mais baixos da estrutura do programa).
• A necessidade de pseudocontrolados é 
eliminada.
44
Integração Ascendente
• Pode ser implementada com os seguintes passos:
1. Componentes de baixo nível são combinados em
agregados (clusters ou construções), que realizam
uma subfunção específica do software.
2. Um pseudocontrolador (driver, um programa de
controle para teste) é escrito para gerenciar a
entrada e saída do caso de teste.
3. O agregado é testado.
4. Pseudocontroladores são removidos e agregados
são combinados movendo-se para cima na estrutura
do programa.
45
Teste de Regressão
• Cada vez que um novo módulo é adicionado
como parte do teste de integração, o software
se modifica.
• Teste de regressão é a reexecução de algum
subconjunto de testes já conduzidos para
garantir que tais modificações não tragam
efeitos colaterais indesejados.
• Pode ser feito manualmente ou através de
uma ferramenta automatizada.
46
Teste de Regressão
• A suíte de teste de regressão possui três
diferentes classes:
– Uma amostra representativa de testes que vão
exercitar todas as funções do software;
– Testes adicionais que focalizam funções do
software, que serão provavelmente afetadas pela
modificação;
– Testes que focalizam os componentes de software
que foram modificados.
47
Teste fumaça
• Abordagem de teste de integração;
• Comumente utilizada quando os produtos de
software estão sendo desenvolvidos;
• É projetado como mecanismo marca-passo
para projetos de prazo crítico.
48
Teste fumaça
• Em essência, abrange as seguintes atividades:
1. Componentes de software que foram traduzidos
para código são integrados em uma
“construção”. Uma construção inclui todos os
arquivos de dados, bibliotecas, módulos
reusáveis e componentes submetidos a
engenharia, que são necessários para
implementar uma ou mais funções do produto.
49
Teste fumaça
2. Uma série de testes é projetada para expor erros
que impeçam a construção de desempenhar
adequadamente a sua função. O propósito deve
ser descobrir erros “bloqueadores” (show
stopper) que têm a maior probabilidade de
colocar o projeto de software fora do
cronograma.
3. A construção é integrada com outras construções
e o produto inteiro (na sua forma atual) passa
pelo teste fumaça diariamente. A abordagem de
integração pode ser ascendente e descendente.
50
Teste fumaça
“O teste fumaça deve exercitar o sistema 
inteiro de ponta a ponta. Ele não precisa ser 
exaustivo, mas deve ser capaz de expor os 
problemas principais. Deve ser suficientementerigoroso para que, se a construção passar, possa 
ser assumido que ela é suficientemente estável 
para ser testada mais rigorosamente. 
McConnell
51
Teste fumaça
• Vantagens de sua aplicação em projetos
complexos de prazo crítico:
– O risco de integração é minimizado;
– A qualidade do produto final é aperfeiçoada
(erros funcionais e defeitos de projeto
arquitetural e no nível do componente –
corrigidos logo no início);
– Diagnóstigo e correção de erros são
simplificados;
– Progresso é fácil de avaliar.
52
Opções Estratégicas
• Discussões sobre vantagens e desvantagens do teste de
integração ascendentes versus descendentes;
• Estratégia combinada (teste sanduíche);
– Usa testes descendentes para os níveis mais altos da
estrutura, acoplada com testes ascendentes para os níveis
subordinados.
– Identificação de módulos críticos (aborda vários requisitos
do software, tem um alto nível de controle, é complexo ou
propenso a erro ou tem requisitos de desempenho bem
definidos).
– Módulos Críticos devem ser testados tão cedo quanto
possível.
– Testes de regressão devem focalizar função de módulo
crítico.
53
Documentação do teste de integração
• Plano global para integração e descrição dos
testes específicos são documentados em uma
Especificação de Teste.
• O plano de teste descreve a estratégia global
de integração.
• O teste é dividido em fases e construções que
tratam de características funcionais e
comportamentais específicas do software.
54
Estratégias para Software OO
• Teste de unidade no contexto de OO
– O conceito de unidade se modifica.
– O encapsulamento guia a definição de classes e
objeto (cada classe e cada instância empacotam
atributos e métodos que manipulam os atributos).
– Apesar de uma unidade encapsulada ser o foco de
um teste de unidade, um módulo é diferente de
uma classe.
– Superclasses e subclasses.
55
Estratégias para Software OO
• Teste de unidade no contexto de OO
– O teste de classe para o software OO é o
equivalente ao teste de unidade para o software
convencional.
56
Estratégias para Software OO
• Teste de integração no contexto de OO
– Software OO - Sem estrutura óbvia de controle
hierárquico (estratégias ascendentes e
descendentes perdem seus significados);
– Duas Estratégias:
1. Teste baseado no caminho de execução (thread-
based testing)
2. Teste baseado no uso (use-based testing)
57
Estratégias para Software OO
1. Teste baseado no caminho de execução (thread-
based testing)
• integra o conjunto de classes necessárias para
responder a uma entrada ou um evento do sistema.
• Cada caminho de execução é integrado e testado
individualmente.
• Teste de regressão é aplicado (garantia da não
ocorrência de efeito colateral).
58
Estratégias para Software OO
2. Teste baseado no uso (use-based testing)
• Começa a construção testando as classes
independentes (usam muito, poucas ou não usam
classes servidoras).
• Segue testando a camada seguinte (classes
dependentes), que utilizam as classes
independentes.
59
Estratégias para Software OO
2. Pseudocontroladores e Pseudocontrolados
• Pseudocontroladores
– Podem ser usados para testar operações no mais baixo
nível e para testar grupos inteiros de classes.
– Também pode ser utilizado para substituir a interface com
o usuário de modo que testes da funcionalidade do sistema
possam ser conduzidos antes da implementação da
interface.
60
Estratégias para Software OO
– Teste Agregado
• É outra etapa para software Orientado a Objetos;
• Reuni um conjunto de classes colaboradoras e casos
de testes são projetados objetivando-se encontrar
erros nas colaborações.
61
Teste de Validação
• Inicia-se ao final do teste de integração;
• Não há diferenças em softwares orientados a
objetos e convencionais.
• Foco nas ações visíveis ao usuário e saídas do
sistema reconhecidas pelo usuário.
62
Teste de Validação
• Critérios de Teste de Validação
– Validação
• série de testes que demonstram conformidade com os requisitos.
– Plano de teste
• classes de testes a serem conduzidas.
– Procedimento de teste
• casos de testes específicos.
– Condições após os testes
• Teste ok ou descoberto desvio da especificação e uma lista de
deficiências é criada.
– Detalhes das correções
63
Teste de Validação
• Revisão da Configuração
– Garantir que todos elementos da configuração de
software tenham sido adequadamente
desenvolvidos, estejam catalogados e tenham os
detalhes necessários para apoiar a fase de suporte
do ciclo de vida do software.
– Algumas vezes é chamada de auditoria.
64
Teste de Validação
• Testes Alfa e Beta
– Ideal quando o produto é destinado a vários
clientes.
– Realizado pelo usuário final.
65
Teste de Sistema
• Não são conduzidos apenas por engenheiros
de software.
• Série de diferentes testes cuja finalidade
principal é exercitar por completo o software.
• Inclui testes de integração e validação.
• Busca verificar o funcionamento correto do
software quando outros elementos são
inseridos (pessoas, hardware, informações,
etc.).
66
Teste de Sistema
• Teste de Recuperação
– Muitos sistemas devem se recuperar de falhas e
retornar o processamento dentro de um tempo
pré-determinado.
– Em outras ocasiões, o sistema deve ser tolerante a
falhas (falhas de processamento não devem
interromper a função global do sistema).
– Em outras situações, uma falha do sistema precisa
ser corrigida dentro de um período de tempo
especificado (risco de prejuízo econômico).
67
Teste de Sistema
• Teste de Recuperação
– Força o software a falhar de diversos modos e verifica
se recuperação é adequadamente realizada.
– Se for automática, a reinicialização, os mecanismos de
verificação, a recuperação dos dados e o reinício são
avaliados quanto à correção.
– Se requer intervenção humana, o tempo médio para
reparo (mean-time-to-repair, MTTR) é avaliado para
determinar se está dentro de limites aceitáveis.
68
Teste de Sistema
• Teste de Segurança
– Hackers, empregados descontentes e vingativos,
indivíduos desonestos são alguns exemplos de
pessoas que podem tentar invadir o sistema,
descobrir a senha de um funcionário, etc.
– O teste verifica se os mecanismos de proteção
incorporados a um sistema vão de fato protegê-lo de
invasão.
– O papel do projetista do sistema é tornar o custo da
invasão maior do que o valor da informação que será
obtida.
69
Teste de Sistema
• Teste de Estresse
– Projetados para submeter programas a situações
anormais.
– “Quanto podemos judiar do sistema até que ele
falhe?”
– O teste executa um sistema que demanda
recursos em quantidade, frequencia ou volume
anormais.
– Teste de sensibilidade (comuns a algoritmos
matemáticos).
70
Teste de Sistema
• Teste de Desempenho
– Sistemas de tempo real e embutidos
(embarcados).
– Testa o desempenho durante a execução, no
contexto de um sistema integrado.
– Frequentemente acoplado ao teste de estresse e
geralmente requer medição tanto do hardware
quanto do software (ex: ciclos de processador /
interrupções).
71
Depuração
• Ocorre como consequência de teste bem
sucedido (descoberta de erro);
• É a ação que resulta na reparação do erro.
• Pode e deve ser um processo ordenado, mas
ainda é excessivamente uma arte.
72
Depuração
• O processo de depuração
– Não é teste, mas sempre ocorre como
consequência deste.
– Apresenta dois possíveis resultados:
1. A causa é encontrada e corrigida;
2. A causa não é encontrada.
73
Depuração
• O processo de depuração
– Por que é tão difícil?
1. O sintoma e a causa podem ser geograficamente
remotos;
2. O sintoma pode desaparecer (temporariamente)quando outro erro é corrigido;
3. O sintoma pode ser causado por não-erros (ex:
imprecisões de arredondamento).
4. O sintoma pode ser causado por erro humano (difícil
de rastrear).
74
Depuração
• O processo de depuração
– Por que é tão difícil?
5. O sintoma pode ser resultado de problema de tempo (não
de processamento);
6. Pode ser difícil reproduzir precisamente condições de
entrada (aplicação em tempo real na qual a ordem das
entradas é indeterminada);
7. O sintoma pode ser intermitente. Isso é particularmente
comum em sistemas embutidos.
8. O sistema pode ser devido a causas que estão distribuídas
em várias tarefas sendo executadas em diferentes
processadores.
75
Depuração
• Abordagens de Depuração
“A depuração é uma aplicação direta do método
científico que foi desenvolvido durante 2.500
anos. A base da depuração é localizar a fonte
do problema [a causa] por particionamento
binário, por meio de hipóteses de trabalho que
prevêem novos valores a serem examinados.”
Bradley, J.H.
76
Depuração
• Abordagens de Depuração
– Três estratégias:
1. Força bruta
2. Rastreamento;
3. Eliminação de causa.
77
Depuração
• Táticas de Depuração
– Força Bruta
• mais comum e menos eficiente para isolar a causa de
um erro de software. É aplicado quando tudo mais
falha.
– Rastreamento
• Abordagem comum que pode ser utilizada em
programas pequenos. Começando no lugar em que um
sintoma foi descoberto, o código-fonte é rastreado
(manualmente) até que o lugar da causa seja
encontrado.
78
Depuração
• Táticas de Depuração
– Eliminação de causa.
• É manifestada por indução ou dedução e introduz o conceito
de particionamento binário. Os dados relacionados à
ocorrência do erro são organizados para isolar causas em
potencial. Uma “hipótese de causa” é concebida e os dados
mencionados são usados para provar ou rejeitar a hipótese.
Alternativamente, uma lista de todas as causas possíveis é
desenvolvida e são conduzidos teste para eliminar cada uma.
Se os testes iniciais indicam que uma hipótese particular de
causa é promissora, os dados são refinados em uma
tentativa de isolar o defeito.
79
Depuração
• Depuração automatizada
– Qualquer abordagem de depuração pode ser
complementada com ferramentas de depuração;
– Fornecem apoio semi-automático para o
Engenheiro de Software.
80
Depuração
• O fator pessoal
– Auxílio de outras pessoas.
– Novo ponto de vista.
– “Quando tudo mais falha, busque ajuda!”.
81
Correção do Erro
• Ume vez encontrado o defeito, o mesmo precisa
ser corrigido.
• A correção de um defeito pode gerar outros erros
e fazer mais mal do que bem.
• Perguntas importantes que devem ser feitas:
1. A causa do defeito está reproduzida em outra parte
do programa?
2. Qual o “próximo defeito” que pode ser introduzido
pelo conserto que estou prestes a fazer?
3. O que poderíamos ter feito para prevenir a
ocorrência desse defeito?
82
Referência
• Capítulo 13 – Engenharia de Software – Roger 
Pressman – McGraw Hill – 6ª Edição.
83