Baixe o app para aproveitar ainda mais
Prévia do material em texto
TESTES DE SOFTWARE – AULA 2 Rio de Janeiro, 21 de agosto de 2011 TESTE NO PROJETO DE SISTEMAS E TESTE NO PROGRAMA DEPURAÇÃO 1. Compreender a necessidade de testes na especificação do projeto; 2. Aprender como planejar e aplicar testes no projeto de software; 3. Compreender e identificar a origem e a causa do erro; 4. Compreender e implementar técnicas e estratégias para identificação do erro. 3 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. 4 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: 5 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. 6 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. 7 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. 8 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. 9 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. 10 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. 11 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. 12 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. 13 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). 14 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. 15 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 16 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). 17 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 18 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). 19 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. 20 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. 21 REVISÕES TÉCNICAS FORMAIS (RTF) Ao final, os participantes devem decidir se: 1. Aceitam o produto sem modificações adicionais; 2. Rejeitam o produto devido a erros graves (uma vez corrigidos, outra revisão deve ser realizada); 3. Aceitam o produto provisoriamente (erros menores foram encontrados e devem ser corrigidos, sem revisão adicional). 22 REVISÕES TÉCNICAS FORMAIS (RTF) 23 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; 24TESTE 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. 25 ABORDAGENS DA DEPURAÇÃO 26 Inicie conjunto de hipóteses Modifique conjunto de hipóteses Selecione hipótese Verifique hipótese Corrigido? NãoSim 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): 1. Força bruta 2. Rastreamento (backtracking) 3. Eliminação da causa 27 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. 28 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; 29 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. 30 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. 31 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: 32 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. 33 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. 34 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. 35 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. 36 PISTAS PARA A DEPURAÇÃO
Compartilhar