Baixe o app para aproveitar ainda mais
Prévia do material em texto
TESTES DE SOFTWARE – AULAS 2 e 3 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 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. 7 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. 8 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. 9 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. 10 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. 11 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). 12 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. 13 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 14 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). 15 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 16 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). 17 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. 18 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. 19 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). 20 REVISÕES TÉCNICAS FORMAIS (RTF) 21 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; 22 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. 23 ABORDAGENS DA DEPURAÇÃO 24 Inicie conjunto de hipóteses Modifique conjunto de hipóteses Selecione hipótese Verifique hipóteseCorrigido? 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 25 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. 26 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; 27 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. 28 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. 29 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: 30 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. 31 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. 32 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. 33 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. 34 PISTAS PARA A DEPURAÇÃO
Compartilhar