Teste de Software Aula 02 Prof Me Ronnison

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

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

Introdução 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

Terminologia 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ção – scripts de teste – Modelos – logs de teste – módulos – laudos de teste 4 – sistemas módulos de auxílio (help)

Artefatos – representações, linguagens 5

Rede de linguagens de representação 6

Interdependência de representações 7

Como verificar completeza e corretude? 8

Como verificar o texto a seguir? Descrição do módulo Ler. Parm 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 testeja 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

Classificação de defeitos 10 Defeito' Descrição Aplicado a Projeto Omissão falta 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ência alguma 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

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

Revisões e inspeções de artefatos 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 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 são eficientes 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 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 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 16

Revisões e inspeções vs. testes 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

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

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

INTRODUÇÃO 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 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

REVISÕES TÉCNICAS 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 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 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 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 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 FORMAIS (RTF) 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) 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 controlada e assessorada. 29 adequadamente planejada,

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 30

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 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) 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) 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) Restrições: Entre 3 e 5 pessoas; Uma preparação antecipada deve ocorrer, mas ela não deve exigir mais de 2 h de cada pessoa; A duração da reunião deve ser inferior a 2 h. 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) 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) 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

TESTE NO PROGRAMA - DEPURAÇÃO 37

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; 38

ABORDAGENS DA 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. 39

ABORDAGENS DA DEPURAÇÃO Inicie conjunto de hipóteses O responsável pela depuração estabelece hipóteses com relação à localização do defeito e à modificação para corrigi-lo. Modifique conjunto de hipóteses 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. Selecione hipótese Verifique hipótese Sim 40 Corrigido? Não

ABORDAGENS DA DEPURAÇÃO 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 Força bruta Método mais comum e menos eficiente; Usado quando os outros métodos falham; Faz-se imensa planejamento. 42 quantidade de teste, mas sem

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; 43

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

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

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

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