Teste de Software – Aula 02 Prof. Me. Ronnison Reges Vidal.

Apresentação em tema: "Teste de Software – Aula 02 Prof. Me. Ronnison Reges Vidal."— Transcrição da apresentação:

1 Teste de Software – Aula 02 Prof. Me. Ronnison Reges Vidal

2 CONTEÚDO Unidade 1 – Teste no projeto de sistema Introdução Terminologia Artefatos Rede de Linguagens de representação 2

3 O controle da qualidade deve ser realizado continuamente junto com o desenvolvimento ainda antes de se dispor do código Algumas propriedades do código são difíceis ou muito caras de testar – torna-se necessário o uso de técnicas de controle da qualidade alternativas aos testes. – Revisões, inspeções e leitura dirigida, se bem realizadas, têm mostrado muito bons resultados. 3 Introdução

4 Artefato – artefato (work product) é qualquer resultado tangível do desenvolvimento e que teve a sua qualidade verificada de alguma forma – artefato é um conceito recursiva artefatos podem ser compostos por outros artefatos Exemplos de artefatos – documentos de especificaçãomódulos de auxílio (help) – scripts de teste – Modelos – logs de teste – módulos – laudos de teste – sistemas 4 Terminologia

5 5 Artefatos – representações, linguagens

6 6 Rede de linguagens de representação

7 7 Interdependência de representações

8 8 Como verificar completeza e corretude?

9 Descrição do módulo LerParm do arcabouço de teste Provê funções para a leitura e análise léxica dos comandos de teste. Pressupõe-se que cada comando de teste esteja integralmente em uma linha. Cada comando de teste inicia com o caractere '=' seguido de um string que identifica o comando. Cada comando pode requerer zero ou mais parâmetros que se encontram na mesma linha que o comando. Parâmetros podem ser literais ou simbólicos. Os parâmetros simbólicos precisam ser declarados antes de serem utilizados. Os parâmetros têm tipo e a leitura deve respeitar esses tipos. Se for do interesse do programador, módulos de teste específico podem ler e processar por conta própria linhas do script. Isto pode ser necessário quando um módulo necessita de um grande número de parâmetros ou de dados especiais. 9 Como verificar o texto a seguir?

10 10 Classificação de defeitos Defeito'DescriçãoAplicado a Projeto Omissãofalta informação necessária no artefato um ou mais requisitos ou características não são abordados no artefato' Incorreção alguma informação contida no artefato conflita com o domínio do problema, ou com o serviço a ser por ele prestado o artefato de projeto contém uma reificação errônea de um requisito Inconsistênciaalguma informação contida no artefato contradiz o que se encontra em outros artefatos ou mesmo neste artefato um conceito registrado no artefato de projeto está em desacordo com o que se encontra em outros artefatos

11 11 Classificação de defeitos DefeitoDescriçãoAplicado a projeto AmbiguidadeInformação contida no artefato admite uma variedade de interpretações Um conceito contido no artefato de projeto favorece dúvidas quanto ao seu significado, possibilitando um erro de compreensão. DesnecessárioInformação contida no artefato não é utilizada ou não é necessária O artefato de projeto contém informação que, mesmo se relevante, não deveria se encontrar nesse artefato (ex. erro de nivelamento da abstração) DuplicataUm mesmo conceito é definido ou especificado em dois ou mais artefatos ou locais de um mesmo artefato O artefato de projeto repete a especificação de um mesmo conceito já existente em um ou mais outros artefatos

12 Uma revisão é uma leitura crítica do artefato e da documentação complementar, anotando: – os defeitos encontrados – as dúvidas e dificuldades de compreensão – as possibilidades de melhorias Uma inspeção é uma leitura crítica formalizada do artefato e da documentação complementar – segundo um plano definido – obedecendo a regras de leitura definidas – envolvendo uma pequena equipe – anotando defeitos, dúvidas e melhorias Revisões e inspeções são complementares a testes – ou ao contrário? 12 Revisões e inspeções de artefatos

13 Revisões e inspeções podem ser utilizadas para controlar a qualidade de qualquer artefato em qualquer linguagem de representação destinada a humanos – especificações – modelos – projetos – código – scripts de teste – processos de desenvolvimento definidos – planos – padrões – auxílio (help) para o usuário – documentação para o usuário – teses, dissertações, trabalhos de fim de curso –... 13 Revisões e inspeções de artefatos

14 Revisões e inspeções informam diretamente o defeito – em geral o custo é baixo para localizar completamente o defeito – podem ser realizadas com relação a artefatos não executáveis ou ainda incompletos revisões devem ser praticadas a partir do primeiro momento do desenvolvimento eliminam defeitos antes dos conseqüentes erros se propagarem para outros artefatos ou para o serviço – um defeito na especificação provoca um erro ao criar a arquitetura (projeto) que se manifesta sob a forma de um defeito na arquitetura – um defeito em um projeto provoca um erro ao redigir o código que se manifesta sob a forma de um defeito no código – a execução de um defeito no código causa um erro endógeno – um defeito pode estabelecer uma vulnerabilidade que, se explorada com sucesso, causa um erro exógeno reduz significativamente o retrabalho inútil – defeitos eliminados cedo reduzem o volume de retrabalho inútil 14 Revisões e inspeções são eficientes

15 Parcela significativa dos defeitos existentes em um artefato é encontrada através de revisões ou inspeções – uma parcela significativa dos defeitos de sistemas entregues têm origem em defeitos nas especificações (70%?) precisa-se reduzir esta classe de defeitos – segundo vários autores a inspeção, quando for praticada, encontra de 60% a 80% do total dos defeitos encontrados mas isso não é de se esperar? – se o controle é feito antes dos testes, então sobram menos defeitos a serem encontrados através dos testes – também sobram menos defeitos remanescentes entregues ao usuário – alguns autores mencionam que se economiza perto de 40% do custo total de desenvolvimento quando se praticam inspeções também é de se esperar, ou não? Afinal a inspeção reduz o custo do retrabalho inútil 15 Revisões e inspeções são eficientes

16 16 Revisões e inspeções são eficientes Figure 1. Custo de Desenvolvimento de Software Figure 2.Custos escondidos no retrabalho de defeitos Brykczynski, B.; Meeson, R.; Wheeler, D.A.; “Software Inspection: Eliminating Software Defects”; Sixth Annual Software Technology Conference; 1994

17 Contrastando, testes informam o sintoma (falha) obrigando diagnosticar a causa (defeito) custo alto para identificar a causa e localizar correta ec ompletamente o defeito somente podem ser realizados com relação a artefatos executáveis ocorre tarde no desenvolvimento depois de já se ter comprometido muitos recursos 17 Revisões e inspeções vs. testes

18 À 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. 18 Revisão Técnicas Formais

19 19 Revisão Técnicas Formais 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:

20 20 Revisão Técnicas Formais  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.

21 Diferentemente da revisão de software, A inspeção ou 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. 21 INTRODUÇÃO

22  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 pode ocorrer a 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. 22 INTRODUÇÃO

23 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. 23 REVISÕES TÉCNICAS

24 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. 24 REVISÕES TÉCNICAS

25 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. 25 REVISÕES TÉCNICAS

26 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. 26 REVISÕES TÉCNICAS

27 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. 27 REVISÕES TÉCNICAS

28 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). 28 REVISÕES TÉCNICAS FORMAIS (RTF)

29 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. 29 REVISÕES TÉCNICAS FORMAIS (RTF)

30 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 30 REVISÕES TÉCNICAS FORMAIS (RTF)

31 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). 31 REVISÕES TÉCNICAS FORMAIS (RTF)

32 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 32 REVISÕES TÉCNICAS FORMAIS (RTF)

33 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). 33 REVISÕES TÉCNICAS FORMAIS (RTF)

34 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. 34 REVISÕES TÉCNICAS FORMAIS (RTF)

35 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. 35 REVISÕES TÉCNICAS FORMAIS (RTF)

36 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). 36 REVISÕES TÉCNICAS FORMAIS (RTF)

37 37 TESTE NO PROGRAMA - DEPURAÇÃO

38 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; 38 TESTE NO PROGRAMA - DEPURAÇÃO

39 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. 39 ABORDAGENS DA DEPURAÇÃO

40 40 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.

41 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 41 ABORDAGENS DA DEPURAÇÃO

42 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. 42 ABORDAGENS DA DEPURAÇÃO

43 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; 43 ABORDAGENS DA DEPURAÇÃO

44 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. 44 ABORDAGENS DA DEPURAÇÃO

45  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. 45 CONSIDERAÇÕES PSICOLÓGICAS

46 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: 46 CORREÇÃO DO ERRO

47 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. 47 CORREÇÃO DO ERRO

48 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. 48 CORREÇÃO DO ERRO

49 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. 49 CORREÇÃO DO ERRO

50 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. 50 PISTAS PARA A DEPURAÇÃO