Buscar

Testes de Software: Revisões e Depuração

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
TESTES DE SOFTWARE – AULA 2
Rio de Janeiro, 21 de agosto de 2011
TESTE NO PROJETO DE SISTEMAS
E TESTE NO PROGRAMA 
DEPURAÇÃO
*
Compreender a necessidade de testes na especificação do projeto;
Aprender como planejar e aplicar testes no projeto de software;
Compreender e identificar a origem e a causa do erro;
Compreender e implementar técnicas e estratégias para identificação do erro.
*
OBJETIVOS DESTA AULA
*
 À medida que o trabalho da engenharia de software é desenvolvido, é normal que ocorram erros. É importante que estes erros sejam encontrados e corrigidos antes que sejam passados para os usuários finais.
Um dos métodos utilizados para a detecção destes erros logo no início do processo de desenvolvimento de software são as revisões de software. Elas são aplicadas em várias etapas durante o processo de engenharia de software e servem para revelar erros que podem ser eliminados. 
*
INTRODUÇÃO
*
Lembre-se: Errar é humano e, embora algumas pessoas captem bem alguns de seus erros, outros tantos escapam mais facilmente a quem lhe deu origem do que a outras pessoas.
Uma revisão – genericamente falando, é uma forma de usar a diversidade de um grupo de pessoas para: 
 
*
INTRODUÇÃO
*
Apontar aperfeiçoamentos necessários no produto de uma única pessoa ou de uma equipe.
Confirmar aquelas partes de um produto em que aperfeiçoamentos são indispensáveis ou desnecessários.
Obter trabalho técnico de qualidade mais uniforme, ou pelo menos mais previsível, que possa ser alcançada sem revisões, de modo a tornar o trabalho técnico mais gerenciável.
*
INTRODUÇÃO
*
Diferentemente da revisão de software, A depuração de software é comumente definida como a tarefa de localização e remoção de defeitos. Ela ocorre como consequência de um teste bem sucedido, ou seja, ela ocorre sempre que um defeito é revelado. 
 
É importante observar que defeitos podem ser revelados em diferentes fases do ciclo de vida do software e a depuração possui características diferentes, dependendo da fase em que se encontra o software. 
*
INTRODUÇÃO
*
A depuração durante a codificação é um atividade complementar à de codificação.
Já a depuração depois do teste é ativada pelo teste bem-sucedido, isto é, revela a presença de defeitos.
A depuração durante a manutenção ocorre pode necessidade de manutenção no software, que pode ter sido causada, por um defeito revelado depois de liberado o software ou pela necessidade de acrescentar novas características.
*
INTRODUÇÃO
*
São utilizadas logo no início do processo de Gestão de Qualidade.
Por que são importantes?
 
 Ao se descobrir um erro logo no início do processo, fica menos caro corrigí-lo. Temos que levar em consideração também que os erros podem aumentar à medida que o processo continua. 
*
REVISÕES TÉCNICAS
*
Por que são importantes? (cont.)
 
 Um erro relativamente insignificante, sem tratamento no início do processo, pode ser ampliado e se transformar em um conjunto de erros graves para a sequência do projeto.
 
 Minimizam o tempo devido à redução do número de reformulações que serão necessárias ao longo do projeto.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
Muitas vezes o termo erro é utilizado para indicar um problema de qualidade que é descoberto antes do software ser liberado ao usuário final. 
 Utilizamos a revisões técnicas para encontrar erros durante o processo de desenvolvimento, de modo a não se tornarem defeitos depois da liberação do software. A descoberta precoce de erros, evita que sejam propagados para a próxima etapa na gestão da qualidade.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
Segundo Pressman, diversos estudos e análise sobre o tema indicam que a atividades de projeto introduzem de 50 a 60% de todos os erros, durante a gestão da qualidade. Entretanto, técnicas de revisão demonstraram ser até 75% eficazes na descoberta de falhas no projeto.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
O benefício das revisões é a descoberta precoce dos defeitos de software, de forma que possam ser corrigidos antes do passo seguinte.
Ao detectar e suprimir estes erros, o processo de revisão reduz substancialmente o custo dos passos subsequentes.
*
REVISÕES TÉCNICAS
*
A formalidade do processo de revisão é relacionada a fatores como a maturidade do processo de desenvolvimento, requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria. 
 
O modo como uma revisão é conduzida depende do seu objetivo (ex: encontrar defeitos, obter compreensão, auditoria, discussão ou decisões por um consenso).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Uma RTF é uma atividade de garantia de qualidade de software executada por engenheiros de software e outros profissionais.
Cada RTF é realizada como um encontro e somente será bem sucedida se for adequadamente planejada, controlada e assessorada.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Objetivos:
Descobrir erros na função, lógica ou implementação
Verificar se o software atende aos requisitos
Garantir que o software foi representado de acordo com os padrões
Obter um software que seja desenvolvido uniformemente
Tornar os projetos mais gerenciáveis
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais:
Planejamento  Selecionar a equipe, alocar as funções, definir os critérios de entrada e de saída para os diversos tipos de revisão formal (ex: inspeção), e selecionar quais as partes dos documentos serão vistos.
Kick-off  Distribuir os documentos, explicar os objetivos, processos e documentos para os participantes; e checar os critérios de entrada (para os diversos tipos de revisão).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais (cont.):
Preparação individual  trabalho feito antecipadamente por cada participante da reunião de revisão, tomando nota dos defeitos em potenciais, questões e comentários.
Reunião de revisão
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais (cont.):
Retrabalho  Resolver defeitos encontrados. Atividade tipicamente realizada pelo autor. 
Acompanhamento  Checar se os defeitos foram encaminhados, obtendo métricas e checando o critério de saída (para certos tipos de revisões formais).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Restrições:
 Entre 3 e 5 pessoas;
 Uma preparação antecipada deve ocorrer, mas ela não deve exigir mais de 2h de cada pessoa;
 A duração da reunião deve ser inferior a 2h.
Uma RTF concentra-se numa parte específica e pequena do software, pois ao estreitar o foco, tem-se a probabilidade maior de revelar erros.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Tipicamente uma reunião é programada para o dia seguinte ao da preparação, e conta com o produtor e os revisores.
Durante a RTF, um revisor registra ativamente todos os problemas levantados. Estes são sintetizados no final da reunião de revisão e é produzida uma lista de problemas de revisão, além do relatório sintetizado da revisão técnica formal. Normalmente o relatório sintetizado é um formulário de uma página, cujo anexo é a lista de problemas de revisão.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Ao final, os participantes devem decidir se:
 
Aceitam o produto sem modificações adicionais;
Rejeitam o produto devido a erros graves (uma vez corrigidos, outra revisão deve ser realizada);
Aceitam o produto provisoriamente (erros menores foram encontrados e devem ser corrigidos, sem revisão adicional).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
O processo de depuração frequentemente ocorre em consequência de um teste. Quando um caso de teste descobre um erro, a depuração será o processo que irá resultar na remoção deste erro.
 
O Processo de depuração tenta combinar o sintoma com a causa, levando assim à correção do erro. Normalmente apresentará um dentre dois resultados:
A causa será encontrada e corrigida;
A causa não será encontrada;
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
Independente da abordagem adotada, a depuração tem um objetivo primordial, que é encontrar e corrigir a causa de erro ou defeito. 
 
Um dos modelos existentes é o modelo genérico de depuração chamado de Hipóteses-Validação. O modelo define a atividade de depuração como um processo interativo de síntese, verificação e refinamento de hipótese.
*
ABORDAGENS DA DEPURAÇÃO
*
*
Inicie conjunto de hipóteses
Modifique conjunto de hipóteses
Selecione hipótese
Verifique hipótese
Corrigido?
Não
Sim
ABORDAGENS DA DEPURAÇÃO
O responsável pela depuração estabelece hipóteses com relação à localização do defeito e à modificação para corrigi-lo. 
O processo de depuração é guiado pela certificação/refutação das hipóteses levantadas, bem como pela geração de novas hipóteses e refinamentos das já existentes. 
*
Segundo Pressman, o objetivo da depuração é alcançado por uma combinação de avaliação sistemática, intuição e sorte, sendo definido basicamente três estratégias (Myers):
 
Força bruta
Rastreamento (backtracking)
Eliminação da causa
*
ABORDAGENS DA DEPURAÇÃO
*
Força bruta
Método mais comum e menos eficiente;
Usado quando os outros métodos falham;
Faz-se imensa quantidade de teste, mas sem planejamento.
*
ABORDAGENS DA DEPURAÇÃO
*
Rastreamento (backtracking)
 
A partir do local do sintoma descoberto, rastreia-se para trás até encontrar a causa;
Bastante comum, porém restrita a programas pequenos, pois o número de caminhos retroativos potenciais pode ser muito alto;
Em sistemas/programas médios/grandes é ineficiente;
*
ABORDAGENS DA DEPURAÇÃO
*
Eliminação da causa
 
Os dados relacionados à ocorrência de erros são organizados para isolar causas em potencial;
Uma “hipótese de causa” é imaginada e dados acima são usados para provar ou reprovar a hipótese;
Uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada uma.
*
ABORDAGENS DA DEPURAÇÃO
*
Efetuar testes e depuração é um traço humano inato;
Certas pessoas são boas para fazer isso, outras não;
A depuração é uma das partes mais frustrantes da programação. Ela indica o reconhecimento de que erramos;
A elevada ansiedade, a pressão, o tempo curto, a pouca disposição para aceitar a possibilidade de erro, aumenta a dificuldade da tarefa;
Quando um erro é enfim corrigido, vem um grande suspiro de alívio e uma diminuição da tensão.
*
CONSIDERAÇÕES PSICOLÓGICAS
*
Segundo Pressman, uma vez encontrado o erro, ele precisa ser corrigido. A correção de um defeito pode introduzir outros erros e, portanto, causar mais danos do que trazer benefícios.
Segundo Van Vleck, três perguntas devem ser feitas antes de fazer a “correção” que remove a causa de um defeito:
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 1. A causa do defeito é reproduzida em outra parte do programa?
 Em muitas situações, o defeito é provocado por um padrão de lógica errôneo que pode ser reproduzido em outro lugar.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 2. Qual o próximo defeito que poderia ser introduzido pelo reparo que estou prestes a fazer?
 Se a correção tiver de ser feita em um módulo com alto acoplamento, deve-se tomar um cuidado especial.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 3. O que poderíamos ter feito para eliminar este defeito já no início?
 Se corrigirmos o processo, bem como o produto, o defeito pode ser eliminado de todos os programa futuros. 
*
CORREÇÃO DO ERRO
*
O sintoma e a causa podem estar geograficamente distantes;
O sintoma pode desaparecer quando outro erro é corrigido;
O sintoma pode ser causado por não erro (ex: arredonda);
O sintoma pode ser causado por um erro humano;
O sintoma pode ser causado por problema de sincronização;
Pode ser difícil reproduzir com precisão as condições que originam o erro;
O sintoma poder ser intermitente.
O sintoma pode ocorrer devido as causas distribuídas por várias tarefas, executando em diferentes processadores.
*
PISTAS PARA A DEPURAÇÃO
*

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Outros materiais