-
Alguém para explicar essa questão?
-
Depuração. 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 consequê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 propostas por [MYE 79]:
1. 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.
2. 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.
3. 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.
-
Alternativa I está mal-elaborada, pois se contradiz:
Se a depuração "é consequência de um teste bem-sucedido", por que ela foi realizada se não havia erro?
A alternativa leva a acreditar que a depuração ocorre APENAS devido a erros detectados em testes. No meu entendimento, a depuração ocorre TAMBÉM durante a fase de implementação, portanto antes de testes e validações.
Devemos desconsiderar o erro básico de pontuação após o pois.
Agradeço se alguém puder dar outra explicação.
-
Se um dia topar com uma questão que tem duas alternativas corretas e uma terceira alternativa que talvez seja correta também, pode marcar a opção que diz que estão corretas: "I, II e III."
-
Acredito que este item esteja errado no trecho marcado, pois, antes de compilar a IDE propriamente dita verifica se falta um ponto e vírgula (;), não é necessário executar o código no modo depuração para que identifique um erro tolo desse.
Na verdade, a própria IDE nem permite a execução do código faltando o (;).
II - Há várias ferramentas para depuração disponíveis nos Ambientes Integrados de Desenvolvimento (IDEs), permitindo, por exemplo, detectar a falta de caracteres de fim de instrução e variáveis indefinidas