Depuração
Autor: Simone Cunha | Publicado: 2010-05-09T22:21:00-03:00

Segundo PRESSMAN, quando o caso e teste descobre um erro, a depuração é a ação que resulta na reparação do erro. A depuração não é teste, mas sempre ocorre em conseqüência do teste. A depuração tenta relacionar sintoma com causa levando assim a correção do erro. A mesma apresenta dois resultados: a causa será encontrada e corrigida ou a causa não será encontrada. No caso da última pode suspeitar de uma causa, projetar um caso de teste para ajudar a validar aquela suspeita e trabalhar para correção do erro de um modo interativo.
Independente da abordagem adotada, a depuração tem como objetivo primordial encontrar e corrigir a causa de um erro de software.
Em geral três estratégias de depuração foram proposta por [MYE 79]: 


Força Bruta – método mais comum e menos eficiente para isolar a causa de um erro de software. Adotamos a filosofia “deixe o computador encontrar o erro”, são feitas listagem da memória, são invocados rastreadores da execução e o programa é carregado com comandos de saída.
Rastreamento – usada com sucesso em programas pequenos, o código-fonte é rastreado manualmente até que o lugar da causa é encontrado. Infelizmente, a medida que o número de linhas-fonte aumenta, o número de caminhos potenciais para trás pode se tornar inadmissivelmente grande. 
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. Sendo uma hipótese de causa concebida e os dados mencionados são usados para provar ou rejeitar a hipótese. De forma alternativa uma lista de todas as causas possíveis é desenvolvida e são conduzidos testes 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.
A depuração automatizada é feita através de ferramentas que oferecem apoio semi-automático. Ambientes Integrados de Desenvolvimento (IDEs - Integrated Development Environments) fornecem um modo de captar alguns dos erros predeterminados específicos de linguagens. Uma grande variedade de compiladores de depuração, ajudas dinâmicas de depuração (“rastreadores”), geradores automáticos de casos de teste e ferramentas de mapeamento de referência cruzada estão disponíveis. Porém ferramentas não são substitutos para avaliação cuidadosa baseada em um modelo completo de projeto de software e em um código-fonte claro.
A correção de um defeito pode introduzir outros erros. Van Vleck [VAN89] sugere três perguntas simples que todo engenheiro de software deve formular antes de fazer a correção:
A causa do defeito está reproduzida em outra parte do programa? Verifique o padrão de lógica errado que muitas das vezes encontra em outro lugar que pode resultar na descoberta de outros erros.
Qual o próximo defeito que pode ser introduzido pelo concerto que estou prestes a fazer? Antes da correção deve-se avaliar o acoplamento da lógica e das estruturas de dados. Se a correção acontecer em uma parte altamente acoplada, cuidado especial deve ser considerado.
O que poderíamos ter feito para prevenir a ocorrência desse defeito? Move a garantia de qualidade de software. Se corrigirmos o processo, bem como o produto, o defeito será removido do programa em questão podendo ser eliminado de todos os futuros programas.