Verificação e Validação

Apresentação em tema: "Verificação e Validação"— Transcrição da apresentação:

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

2 Verificação e Validação (V & V)
É 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. É 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
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! A validação deve ocorrer com antecedência, o que nem sempre é possível. É provável que a validação dos requisitos não descubra todos os defeitos ou as deficiências.

4 V&V Existem duas técnicas: Inspeções de software Inspeção de Software
Testes de Software 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 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. 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 Testes do programa Especificação De requisitos
Projeto de Alto nível Especificação formal Projeto detalhado Programa Testes do programa Protótipo

7 Tipos de Testes Testes de defeitos Testes estatísticos
Encontram inconsistências entre o programa e a sua especificação. São devidos a defeitos do programa. 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 O objetivo da V&V é estabelecer a confiança de que o sistema é “adequado a seu propósito”. 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 A V&V são um processo que estabelece a existência de defeitos. A depuração é um processo que localiza e corrige estes defeitos. Localizar defeitos em um programa nem sempre é um processo simples. O defeito pode estar longe do ponto em que o programa falhou!

10 Localizar um defeito Rastreamento manual.
Programas de testes adicionais. Ferramentas de depuração (watch). 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 integração de sistema Plano de teste de integração de subsistema Teste de Unidade e de módulo Plano de teste de aceitação Teste de inte- gração de sistema Teste de inte- gração de subsistema Teste de aceitação Operação

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

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

14 Continuação... É muito complicado inspecionar um sistema inteiro, composto por vários subsistemas. Os testes são a única técnica viável no nível de sistema. 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... Engenheiros de software experientes relutam em aceitar inspeções. Acham que os testes são suficientes. As inspeções implicam em custos adicionais iniciais.

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

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

18 O Processo de Inspeção

19 O Processo de Inspeção 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 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 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 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 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 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 No teste Nas Inspeções 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 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 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... Durante uma inspeção uma checklist pode ser útil.
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 Utiliza um programa que percorre o código fonte e detecta possíveis anomalias.(Não é necessário executar o código!) 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 O Linux tem o Lint para a linguagem C.
A análise com ferramentas não substitui as inspeções. Existem tipos de erros que a ferramenta não detecta. As linguagens modernas são menos sujeitas a erro: Todas as variáveis precisam ser inicializadas Não existe goto.

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

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

35 Testes É impraticável fazer todos os testes.
Devem ser projetados casos de testes. A empresa pode ter política de casos de teste. 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 Casos de testes Dados de testes Resultados de testes
Relatórios de testes Projetar casos de testes Preparar casos de testes Executar programa com os dados de teste Comparar resultados com os casos de teste

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

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

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

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

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

42 Testes de Caminho É um caso de teste de estrutura, onde cada caminho de execução independente é testado. Nas declarações condicionais são testados os casos verdadeiros e os falsos. 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 É impossível testar todos os caminhos, pois a combinação de caminhos tende a infinito! O ponto de partido é um grafo de fluxo de programa. Cada caminho de programa deve ser testado pelo menos uma vez.

44 Grafo de fluxo para uma rotina de pesquisa binária 1 Inicio>fim Enquanto inicio<=fim 2 3 Se vetor[medio]=chave sim não Se vetor[medio]<chave 8 4 sim não 6 5 9 7

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

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

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

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

49 Testes top-down e bottom-up
São abordagens diferentes da integração do sistema. Top-down  os componentes de alto nível são integrados e testados antes que seus projetos e implementação tenham sido completados. 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
Seqüência de testes Nível 1 Nível 1 Nível 2 Nível 2 Nível 2 Nível 2 Stubs nível 2 Stubs nível 3

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

52 Top-Down X Bottom-Up 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. Demonstração do sistema: Top-down: um sistema de trabalho limitado está disponível na fase inicial. Bottom-up: somente se reutilizar componentes. 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. 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 Ocorrem quando módulos ou subsistemas são integrados para formar sistema maiores. É particularmente importante na orientação a objeto. Os erros de interface não são detectados, testando-se os objetos individuais.

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

55 Tipos de erros de interface
Mau uso Tipos errados, incompletos, invertidos, etc. Mau entendimento Exemplo: uma chamada a uma busca binária em um vetor não ordenado. Ou estouro de fila, etc. 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
Testar os valores dos parâmetros em seus extremos. Testar parâmetros com ponteiros nulos. Projetar testes que devam provocar a falha do componente. Em passagem de mensagem, projete testes que geram muito mais mensagens do que é provável que ocorra na prática. Projetar testes que variam a ordem de uso da memória compartilhada, quando existe mais de um produtor e/ou consumidor. 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 São testes em que a carga do sistema é aumentada constantemente, até que o desempenho do sistema se torne inaceitável. 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. Os testes de stress são relevantes em sistemas distribuídos, com base em rede de computadores. 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 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
Testar as operações (ou métodos) individuais de cada objeto. Pode-se utilizar a técnica da caixa preta. Testar classes de objetos. Idem. Testar grupos de objetos. Testar o sistema orientado a objeto.

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

61 Integração de objetos Testes de cluster (bottom-up e top-down não são indicados). Testes de use-case (ou cenários) Testes de threads. Pode-se provocar um evento e verificar como o processamento de eventos faz o seu caminho. Testes de interação  identificar os caminhos de MM (Message Methods) e identificar o ASF (Atomic System Function). 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ções Estação meteorológica Dados meteorológicos Requisitar (relatório) Ok() Relatar() Resumir() Enviar (relatório) Responder (relatório) Ok()

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

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