A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Verificação e Validação Profa. M.Sc. Yáskara Menescal UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO – UFERSA DEPERTAMENTO DE CIÊNCIAS.

Apresentações semelhantes


Apresentação em tema: "Verificação e Validação Profa. M.Sc. Yáskara Menescal UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO – UFERSA DEPERTAMENTO DE CIÊNCIAS."— Transcrição da apresentação:

1 Verificação e Validação Profa. M.Sc. Yáskara Menescal UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO – UFERSA DEPERTAMENTO DE CIÊNCIAS EXATAS E NATURAIS - DCEN

2 Verificação e Validação (V & V) 4 É o nome dado aos processos de verificação e análise que asseguram que o software cumpra com as suas especificações e atenda às necessidades dos clientes que estão pagando por ele. 4 É um processo do ciclo de vida. Inclui: Revisões dos requisitos Revisões de projeto Inspeções de código Testes do produto

3 Verificação e Validação 4 Não é a mesma coisa: –Validação: estamos construindo o produto certo? Supõe falhas na especificação!!! –Verificação: estamos construindo certo o produto? Admite que a especificação esteja correta e supõe falhas no desenvolvimento! 4 A validação deve ocorrer com antecedência, o que nem sempre é possível. 4 É provável que a validação dos requisitos não descubra todos os defeitos ou as deficiências.

4 V&V 4 Existem duas técnicas: Inspeção de Software Testes de Software 4 Inspeções de software analisam e verificam as representações do sistema, tais como: –Documento de requisitos –Diagramas de projeto –Código-fonte do programa São aplicadas em todos os estágios do processo. Podem ser complementadas por alguma análise automática de texto dos documentos do sistema.

5 V&V 4 Testes de software. Envolve: Executar uma implementação do software com os dados de teste. Examinar as saídas do teste e seu comportamento operacional. 4 Enquanto as inspeções são empregadas em todos os estágios do processo de software, os testes são utilizados somente quando um protótipo ou um programa estiver disponível.

6 Inspeções de software Especificação De requisitos Projeto de Alto nível Especificação formal Projeto detalhado Programa Protótipo Testes do programa

7 Tipos de Testes 4 Testes de defeitos –Encontram inconsistências entre o programa e a sua especificação. –São devidos a defeitos do programa. 4 Testes estatísticos –Testam o desempenho e a confiabilidade do programa. O desempenho é medido pelo tempo que leva para executar o teste. A confiabilidade é medida pela contagens do número de falhas observadas.

8 Nível de confiança 4 O objetivo da V&V é estabelecer a confiança de que o sistema é adequado a seu propósito. 4 O nível de confiança depende: –Da função do software o quanto o software é importante para a organização. –Das expectativas do usuário a tolerância do usuário às falhas hoje é menor do que a 20 anos atrás. –Ambiente de mercado deve levar em conta os programas dos concorrentes, o preço e os prazos de entrega.

9 V&V x Depuração 4 A V&V são um processo que estabelece a existência de defeitos. 4 A depuração é um processo que localiza e corrige estes defeitos. 4 Localizar defeitos em um programa nem sempre é um processo simples. 4 O defeito pode estar longe do ponto em que o programa falhou!

10 Localizar um defeito 4 Rastreamento manual. 4 Programas de testes adicionais. 4 Ferramentas de depuração (watch). 4 Testes de regressão checam se as mudanças feitas em um programa não introduziram novos erros no programa. Isto pode se tornar dispendioso!

11 Modelo de Desenvolvimento com Testes Especificação de requisitos Especificação de sistema Projeto de sistema Projeto detalhado Plano de teste de aceitação Plano de teste de integração de sistema Plano de teste de integração de subsistema Teste de Unidade e de módulo Operação Teste de aceitação Teste de inte- gração de sistema Teste de inte- gração de subsistema

12 Plano de teste de software 4 Processo de teste –Descrição das fases do processo de teste. 4 Rastreamento dos requisitos –Todos os requisitos devem ser individualmente testados. 4 Itens a serem testados –Especificar quais produtos do processo de software que devem ser testados. 4 Cronograma –Deve estar vinculado ao cronograma do desenvolvimento. 4 Registros de testes –Como os testes devem ser registrados? 4 Requisitos de hardware e software. 4 Restrições.

13 Quanto à eficácia... 4 Em 1987, Basili e Selby provaram empiricamente a eficácia das inspeções e dos testes. 4 Constataram que a revisão estática de código era mais eficaz e menos dispendiosa do que os testes dinâmicos de defeitos! 4 Em 1992, Gilb e Graham constataram que isto é verdadeiro. 4 Fagan relata que mais de 60% dos erros podem ser detectados por inspeções informais do programa. 4 Porém, segundo Mills, através de uma inspeção formal (cleanroom), pode-se detectar mais de 90% dos erros!!! 4 A inspeção não descarta os testes. 4 A inspeção deve preceder os testes.

14 Continuação... 4 É muito complicado inspecionar um sistema inteiro, composto por vários subsistemas. 4 Os testes são a única técnica viável no nível de sistema. 4 Os testes, além de localizar erros, também são necessários para determinar a confiabilidade, o desempenho e para validar a interface com o usuário.

15 Continuação... 4 Engenheiros de software experientes relutam em aceitar inspeções. 4 Acham que os testes são suficientes. 4 As inspeções implicam em custos adicionais iniciais.

16 Inspeção de programa 4 Desenvolvida por Fagan (IBM) uma equipe com membros de diferentes graus de experiência deve revisar todo o código, linha por linha. 4 A equipe de inspeção deve ter em mãos uma especificação detalhada. 4 Todos os membros devem estar familiarizados com os padrões adotados na empresa. 4 O código a ser inspecionado deve estar completo. 4 A inspeção resulta num documento com a lista dos erros. 4 A equipe de revisão não deve sugerir como os erros encontrados deverão ser corrigidos.

17 A Equipe de Inspeção 4 Autor – desenvolvedor do artefato que será inspecionado 4 Inspetor – examina o produto na tentativa de encontrar defeitos 4 Leitor – apresenta o artefato aos demais participantes 4 Escritor – registra as informações sobre cada defeito encontrado 4 Moderador – possui o papel mais crítico de todo o processo, liderando toda a equipe

18 O Processo de Inspeção

19 4 Planejamento –O moderador é responsável por: Selecionar a equipe de inspeção Checar se o produto está pronto para inspeção Organizar a reunião Delegar as atividades de cada membro Garantir a completude dos materiais a serem inspecionados –O autor e o moderador decidem quantas reuniões de inspeção serão requeridas

20 O Processo de Inspeção 4 Visão Geral –O autor apresenta as principais características do produto a ser inspecionado –É uma etapa opcional e depende da necessidade identificada pelo moderador

21 O Processo de Inspeção 4 Preparação –Os inspetores analisam o produto de trabalho em busca de não-conformidades –Fazem as anotações necessárias –O moderador analisa os logs antes da reunião para determinar se a equipe está preparada para suas tarefas

22 O Processo de Inspeção 4 Reunião –O leitor realiza a leitura e interpretação do produto –O autor tira quaisquer dúvidas que surgirem –A equipe de inspetores identifica os possíveis defeitos –A reunião não deve passar de duas horas –Não devem ser discutidas formas de corrigir os defeitos

23 O Processo de Inspeção 4 Re-Trabalho –O autor corrige os defeitos identificados na reunião Defeitos considerados mais relevantes devem ser corrigidos primeiro

24 O Processo de Inspeção 4 Acompanhamento –O moderador: Analisa o material corrigido pelos autores Verifica se os defeitos foram corrigidos com sucesso Decide se uma nova inspeção é necessária

25 Testes e Inspeção 4 No teste –Você começa com um problema –Em seguida tem que encontrar o bug –Depois, deve imaginar a correção –Por fim, implementa e testa a correção 4 Nas Inspeções –Você vê o defeito –Então imagina a correção –Finalmente, implementa e revisa a correção

26 Testes e Inspeção 4 Nos Testes –Se o programa produziu um resultado não usual, você precisa Detectar que aquilo não foi usual Descobrir o que o sistema estava fazendo Encontrar em que ponto estava no programa Descobrir que defeito poderia causar este comportamento estranho

27 Continuação... 4 Durante uma inspeção uma checklist pode ser útil. 4 Uma checklist contem um roteiro de possíveis erros: –Defeitos nos dados: Todas as variáveis foram inicializadas? As constantes foram nomeadas? Tamanho máximo de um vetor? Pode haver overflow de buffer? –Defeitos de controle As condições estão corretas? Todos os loops estão certos de terminar? Os parênteses estão corretos nas condições compostas? Num case todas as alternativas estão declaradas?

28 Continuação... (Checklist) –Defeitos de Entrada/saída Todas as variáveis de entrada são utilizadas? Todas as variáveis de saída têm um valor designado antes de saírem? Entradas inesperadas podem corromper os dados? –Defeitos de interface Todas as chamadas de funções e métodos têm o número correto de parâmetros? Os tipos de parâmetros combinam? Os parâmetros estão na ordem certa? Se componentes acessam memória compartilhada, eles têm a mesma estrutura de memória compartilhada?

29 Continuação... (Checklist) –Defeitos de gerenciamento de armazenamento Se uma estrutura linkada é modificada, todos os links foram corretamente redesignados? Se o armazenamento dinâmico é utilizado, o espaço foi alocado corretamente? O espaço é explicitamente liberado, depois que não é mais necessário? –Defeitos de gerenciamento de exceções Todas as possíveis condições de erro foram levadas em conta?

30 Análise automatizada 4 Utiliza um programa que percorre o código fonte e detecta possíveis anomalias.(Não é necessário executar o código!) 4 Pode analisar: –Fluxo de controle –Utilização dos dados –As interfaces (se o compilador não realizar esta tarefa) –Fluxo de informações (entrada saída) –Caminho (todos os caminhos possíveis no programa)

31 Análise automatizada 4 O Linux tem o Lint para a linguagem C. 4 A análise com ferramentas não substitui as inspeções. Existem tipos de erros que a ferramenta não detecta. 4 As linguagens modernas são menos sujeitas a erro: –Todas as variáveis precisam ser inicializadas –Não existe goto.

32 Testes 4 Apresentam duas fases: –Testes de componentes cada componente é testado individualmente. –Testes de integração é testada a interação entre os componentes e a funcionalidade e o desempenho do sistema como um todo. –Inevitavelmente são descobertos defeitos em componentes, durante os testes de integração.

33 Sistemas orientados a objetos 4 Sob perspectiva de testes, os sistemas baseados em objetos diferem dos sistemas baseados em funções. 4 Em sistemas baseados em funções existe distinção nítida entre programas (funções) e módulos. 4 Na orientação a objeto não há esta distinção: os objetos podem ser simples entidades ou entidades complexas. 4 Não há uma hierarquia de objetos bem definida. 4 As estratégias de integração top-down e bottom-up são inadequadas. 4 O limite entre teste de componente e teste de integração não é exato.

34 Detecção de defeitos 4 O teste de validação se destina a demonstrar que o sistema cumpre com suas especificações. 4 O teste de detecção de defeitos tem por objetivo fazer com que o sistema opere incorretamente, expondo um defeito existente. 4 Casos de teste são especificações das entradas para o teste e da saída esperada. 4 Casos de teste não podem ser gerados automatica-mente, porque não tem como prever a saída. 4 Já os dados de teste podem ser gerados automaticamente.

35 Testes 4 É impraticável fazer todos os testes. 4 Devem ser projetados casos de testes. 4 A empresa pode ter política de casos de teste. 4 Por exemplo: –Testar todas as funções acessadas por meio de menus. –Testar todas as combinações de funções acessadas pelo mesmo menu. –Todas a funções devem ser testadas com dados corretos e incorretos.

36 Processo de teste Projetar casos de testes Preparar casos de testes Executar programa com os dados de teste Comparar resultados com os casos de teste Casos de testes Dados de testes Resultados de testes Relatórios de testes

37 Teste de caixas preta (Testes funcionais) 4 Cada componente é considerado uma caixa preta. 4 O testador está preocupado somente com a funcionalidade do componente. 4 Também pode ser utilizado na orientação a objeto. 4 Principal dificuldade: selecionar os dados de entrada que tenham grande probabilidade de detectar uma anomalia.

38 Dados de entrada 4 Se dividem em classes: –Números positivos –Números negativos –Strings sem brancos ou com brancos –Datas, etc 4 Os programas normalmente se comportam de maneira comparável para todos os membros de uma classe. 4 Essas classes são chamadas de partições de equivalência.

39 Casos de teste 4 O testador deve identificador todas as partições de equivalência. 4 Os casos de teste são escolhidos a partir de cada uma destas partições. 4 Valores que não pertencem a nenhuma partição ou que se encontram nos extremos de uma partição, são valores atípicos. 4 Os erros normalmente ocorrem, quando se processam valores atípicos.

40 Outras diretrizes de testes 4 Utilizar seqüências com somente um único valor. 4 Utilizar seqüências diferentes, de tamanhos diferentes, em diferentes testes. 4 Utilizar o primeiro, o médio e o último elemento de uma seqüência.

41 Teste de estrutura 4 Também chamados de testes de caixa branca ou caixa de vidro ou caixa clara 4 Neste caso, os dados de teste são derivados do código. Dados de teste Saídas do testeCódigo de componente derivaTesta

42 Testes de Caminho 4 É um caso de teste de estrutura, onde cada caminho de execução independente é testado. 4 Nas declarações condicionais são testados os casos verdadeiros e os falsos. 4 Quando os módulos são integrados, torna-se inviável o teste de estrutura então usa-se o teste de caminho.

43 Teste de caminho 4 É impossível testar todos os caminhos, pois a combinação de caminhos tende a infinito! 4 O ponto de partido é um grafo de fluxo de programa. 4 Cada caminho de programa deve ser testado pelo menos uma vez.

44 Se vetor[medio]=chave não sim Enquanto inicio<=fim Inicio>fim Se vetor[medio]

45 Teste de caminho 4 A rotina de pesquisa binária é simples e o projeto do caso de teste é direto. 4 Porém, se o programa tem uma estrutura complexa de ramificações, pode ser difícil prever qualquer caso de teste. 4 Neste caso, pode ser utilizado um analisador de programa dinâmico. 4 Este conta o número de vezes que cada declaração do programa foi executada.

46 Testes de integração 4 Quando todos os componentes já foram testados, deve ser testada a integração destes. 4 Estes testes devem começar a partir da especificação do sistema. 4 Tão logo alguns componentes estejam concluídos, deve ser testada a integração dos mesmos.

47 Testes de integração 4 Maior problema: –como localizar um erro que foi detectado nesta etapa? –Em qual componente ele está? 4 Solução: testes incrementais!

48 A B T1 T2 T3 A B C T1 T2 T3 T4 T1 T2 T3 T4 T5 T6 A B C D Testes de integração incremental Na prática, pode ser necessário integrar diversos componentes simultaneamente! O erro detectado pode não estar no componente incrementado!

49 Testes top-down e bottom-up 4 São abordagens diferentes da integração do sistema. 4 Top-down os componentes de alto nível são integrados e testados antes que seus projetos e implementação tenham sido completados. 4 Bottom-up os componentes de nível inferior são integrados e testados antes que os componentes de nível superior tenham sido desenvolvidos.

50 Testes de integração top-down Nível 1Nível 2 Nível 1 Seqüência de testes Stubs nível 2 Stubs nível 3

51 Testes de integração bottom-up Nível N Nível N-1 Seqüência de testes Driver de teste

52 Top-Down X Bottom-Up 4 Validação da arquitetura: –Top-down: tende a encontrar erros na arquitetura no inicio do desenvolvimento. –Bottom-up: o projeto de alto nível só é validado num estágio avançado do processo. 4 Demonstração do sistema: –Top-down: um sistema de trabalho limitado está disponível na fase inicial. –Bottom-up: somente se reutilizar componentes. 4 Implementação de teste: –Top-down : os testes são difíceis de implementar, pois há necessidade de simular os stubs. –Bottom-up : é necessário escrever drivers de teste. 4 Observação de teste: –Ambos têm problemas de observação do teste. Os componentes de alto nível tendem a não ter saídas e os de baixo nível necessitam de um ambiente artificial (drivers) para que o teste possa ser observado.

53 Testes de Interface 4 Ocorrem quando módulos ou subsistemas são integrados para formar sistema maiores. 4 É particularmente importante na orientação a objeto. 4 Os erros de interface não são detectados, testando-se os objetos individuais.

54 Tipos de Interfaces 4 De parâmetros –Quando dados ou referências de funções são passados de um componente para outro. 4 De memória compartilhada –Quando um bloco de memória é compartilhado entre subsistemas. 4 De procedimento –Quando um subsistema encapsula um conjunto de procedimento que podem ser chamados por outros subsistemas. 4 De passagem de mensagem –Quando um subsistema pede um serviço de outro subsistema, passando-lhe uma mensagem.

55 Tipos de erros de interface 4 Mau uso –Tipos errados, incompletos, invertidos, etc. 4 Mau entendimento –Exemplo: uma chamada a uma busca binária em um vetor não ordenado. Ou estouro de fila, etc. 4 Erros de timing –Ocorrem em sistema de tempo real com memória compartilhada, quando o produtor de dados e o consumidor de dados trabalham com velocidades diferentes. –É possível que o consumidor de dados acesse dados desatualizados!

56 Diretrizes para testes de interface 4 Testar os valores dos parâmetros em seus extremos. 4 Testar parâmetros com ponteiros nulos. 4 Projetar testes que devam provocar a falha do componente. 4 Em passagem de mensagem, projete testes que geram muito mais mensagens do que é provável que ocorra na prática. 4 Projetar testes que variam a ordem de uso da memória compartilhada, quando existe mais de um produtor e/ou consumidor. 4 Quando a linguagem é bem tipificada (Pascal, Java) então o compilador se encarrega de encontrar a maioria dos erros de interface.

57 Testes de stress 4 São testes em que a carga do sistema é aumentada constantemente, até que o desempenho do sistema se torne inaceitável. 4 Funções: –Testar a falha do sistema. A falha corrompe os dados ou provoca a perda de algum serviço? –Causar stress no sistema e assim acarretar a detecção de defeitos que normalmente não se manifestariam. 4 Os testes de stress são relevantes em sistemas distribuídos, com base em rede de computadores. 4 A rede se torna inundada de dados de coordenação, que os diferentes processos devem trocar e, assim, os processos cada vez mais lentos.

58 Objetos 4 Os objetos: –São maiores do que funções isoladas. –Não são integrados em subsistemas. –São mal acoplados. –Não há um nível superior óbvio. –Na reutilização de objetos, o testador pode não ter acesso ao código fonte.

59 Testes orientados a objetos 4 Testar as operações (ou métodos) individuais de cada objeto. Pode-se utilizar a técnica da caixa preta. 4 Testar classes de objetos. Idem. 4 Testar grupos de objetos. 4 Testar o sistema orientado a objeto.

60 Testes de classes de objeto 4 Testar isoladamente todas as operações associadas ao objeto. 4 Estabelecer e testar os valores de todos os atributos associados com o objeto. 4 Testar todos os estados possíveis em eventos que provoquem a mudança de estado no objeto. 4 Testar todas as subclasses com a operações herdadas da superclasse.

61 Integração de objetos 4 Testes de cluster (bottom-up e top-down não são indicados). 4 Testes de use-case (ou cenários) 4 Testes de threads. Pode-se provocar um evento e verificar como o processamento de eventos faz o seu caminho. 4 Testes de interação identificar os caminhos de MM (Message Methods) e identificar o ASF (Atomic System Function). 4 Um ASF é um evento de entrada, seguido de uma seqüência de rotas de MM e que termina com um evento de saída.

62 Testes baseados em Use-case Controlador de comunicaçõesEstação meteorológicaDados meteorológicos Requisitar (relatório) Ok() Responder (relatório) Ok() Relatar() Enviar (relatório) Resumir()

63 Use-Case 4 O diagrama de seqüência explicita um Use- case e permite identificar caminhos de operações a serem testados. 4 Permite identificar entradas e saídas. 4 É claro que devemos também levar em conta as exceções que foram suprimidas no diagrama anterior.

64 Ferramentas de teste 4 Gerenciador de testes gerencia os testes e acompanha os dados de teste e os resultados esperados. 4 Gerador de dados Gera os dados de teste a partir de padrões ou a partir da seleção em um banco de dados de teste. 4 Oráculo Gera previsões dos resultados esperados. 4 Comparador de arquivos Compara e relata as diferenças entre resultados de 2 ou mais testes. 4 Gerador de relatórios Gera um relatório dos resultados de teste. 4 Analisador dinâmico Adiciona código a um programa para contar o número de execuções de cada declaração do programa. 4 Simulador De máquina, de interface e de entrada e saída (timing)


Carregar ppt "Verificação e Validação Profa. M.Sc. Yáskara Menescal UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO – UFERSA DEPERTAMENTO DE CIÊNCIAS."

Apresentações semelhantes


Anúncios Google