Baixe o app para aproveitar ainda mais
Prévia do material em texto
Verificação e Validação de Software Prof. M.e: Ricardo Camparim 2 � Introduzir verificação e validação de software; � Descrever o processo de inspeção de programa; � Explicar análise estática; � Introduzir o processo de desenvolvimento de software Cleanroom. Objetivos 3 Tópicos abordados � Planejamento de verificação e validação; � Inspeções de software; � Análise estática automatizada; � Verificação e métodos formais Verificação e validação 4 Qual a diferença entre Verificação e Validação? Verificação vs validação “Verificação se preocupa em avaliar se o produto está sendo desenvolvido corretamente, enquanto a validação visa assegurar que se está desenvolvendo o produto correto, isto é, o produto que o cliente deseja” (BOEHM, 1981). 5 Verificação vs validação O que deve ser questionado? � Verificação: � Confirmar por testes e com provas objetivas que requisitos especificados foram cumpridos. � Visa garantir que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase, ou seja, tenta responder à pergunta: � “O produto foi construindo corretamente?” 6 Verificação vs validação � Validação: � Confirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridos. � Busca provar que o software implementa cada um dos requisitos corretamente e completamente ou seja, tenta responder à pergunta: � “O produto correto foi construído?” 7 Verificação vs validação � Diferenças: Fonte: www.spider.ufpa.br 8 Verificação vs validação � Problemas: Fonte: www.spider.ufpa.br � Custo por NÃO realizar testes: � Foi feito tudo? � Foi executado corretamente? � Produto falho: � Insatisfação do cliente � Retrabalho � Baixa reputação 9 Processo � O processo de V&V � É um processo que engloba todo o ciclo de vida - V & V deve ser aplicado em cada estágio no processo de desenvolvimento. � Tem dois objetivos principais: � a descoberta de defeitos no sistema; � Assegurar se o sistema é ou não utilizável em uma situação operacional. Ex: Máquinas ultrapassadas 10 Propósitos � Propósitos da Verificação � O propósito do processo Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados. � O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido � Propósitos da Validação Fonte: www.sotex.br 11 Confiabilidade � Confiança de V&V � Depende do propósito do sistema, das expectativas dos usuários e do ambiente de mercado. � Função de software: O nível de confiança depende de quão crítico é o produto para a empresa. � Expectativas do usuário: Os usuários podem ter baixas expectativas de certos tipos de software. � Ambiente de mercado: Colocação de um produto no mercado pode ser mais importante do que descobrir defeitos no programa. Ex: Windows 98 12 Confiabilidade – História de erros de software � Problemas no Mariner (1962) – Custo aprox.: 80 milhões dólares. � Desastre: Mariner, um foguete com uma sonda espacial para Vênus, foi desviado de seu percurso de voo logo após o lançamento. � Causa: Um programador, ao passar para o computador uma fórmula que haviam lhe entregado escrita manualmente, se esqueceu de uma barra. Sem ela, o software tratava variações normais de velocidade como se fossem sérios problemas, causando falhas por tentativas de correções que acabaram por enviar o foguete fora do curso. � 3ª Guerra Mundial “Quase!” (1983). � Desastre: O sistema de alerta precoce soviético falsamente indicou que os Estados Unidos tinham lançado cinco mísseis balísticos. Felizmente, o oficial de serviço soviético argumentou: se os EUA estavam realmente atacando, eles lançariam mais de cinco mísseis. por isso ele relatou o aparente ataque como um alarme falso. � Causa: Um bug no software soviético falhou ao detectar reflexos solares como falsos mísseis. Fonte: http://www.edn.com/ � Inspeções de software � Preocupadas com a análise estática das representações do sistema para descobrir problemas (verificação estática). � pode ser complementadas por alguma análise automática do texto de origem de um sistema ou dos documentos associados. � Teste de software � preocupado com a execução e observação do comportamento do produto (verificação dinâmica). � O sistema é executado com dados de teste e o seu comportamento operacional é observado. 13 Verificação estática e dinâmica � Teste de programa � Pode revelar a presença de erros e NÃO a ausência; � Um teste bem sucedido é um teste que descobre um ou mais erros; � É a única técnica de validação para requisitos não funcionais (desempenho, confiabilidade); � Deve ser usado em conjunto com a verificação estática para uma cobertura total das atividades de V&V. 14 Teste de programa 15 Tipos de testes � Os testes de defeito � Testes projetados para descobrir defeitos no sistema; � Um teste bem sucedido é aquele que revela a presença de defeitos em um sistema. � Testes estatísticos � Usado para testar o desempenho e a confiabilidade do Programa; � Confiabilidade: número de falhas no sistema, etc... � Desempenho Tempo de execução, tempo de resposta, etc. 16 Teste de depuração � Testes de depuração e de defeitos são processos distintos; � Verificação e validação estão relacionados ao estabelecimento da existência de falhas em um programa; � Depuração está relacionado à localização e reparação dessas falhas. 17 Processo de depuração 18 Planejamento de V&V � Planejamento cuidadoso é necessário para obter sucesso nos processos de inspeção e teste; � O planejamento deve iniciar no começo do processo de desenvolvimento (em cada fase); � O processo de planejamento deve decidir sobre o equilíbrio entre as abordagens estáticas e dinâmicas; � O planejamento de testes se ocupa em estabelecer os padrões para o processo de testes. 19 Plano de teste � O plano de teste é um dos documentos produzidos na condução de um projeto. � Como ele funciona: � Um ‘integrador’ entre diversas atividades de testes no projeto; � Mecanismo de comunicação para os stakeholders (a equipe de testes e outros interessados); � Guia para execução e controle das atividades de testes. Fonte: http://www.devmedia.com.br 20 � O plano de teste pode ser elaborado pelo gerente de projeto ou gerente de testes; � Visa planejar as atividades a serem realizadas; � Definir os métodos a serem empregados; � Planejar a capacidade necessária; � Estabelecer métricas e formas de acompanhamento do processo. Plano de teste 21 Estrutura de um plano de teste � Processo de teste; � Rastreabilidade de requisitos; � Itens testados; � Cronograma de testes; � Procedimentos de registro de testes; � Requisitos de hardware e de software; � Restrições 22 Estrutura de um plano de teste � Gráfico de Gantt para estrutura de um plano de teste . Fonte: http://www.wthreex.com 23 O processo de inspeções Planejamento Visão Geral Preparação Individual Reunião de Inspeção Retrabalho Acompanhamento apresentado à equipe de inspeção Cada membro da equipe estuda a especificação e procura defeitos no código. Durante a inspeção, os erros descobertos são anotados. Modificações são feitas para corrigir os erros descobertos. Uma nova inspeção pode ser ou não necessária. 24 Pré-condições para inspeções � Uma especificação precisa deveestar disponível; � Os membros da equipe devem estar familiarizados com os padrões organizacionais; � O código sintaticamente correto ou outras representações do sistema devem estar disponíveis; � Um checklist de erros deve ser preparado; � A gerência deve aceitar que a inspeção aumentará os custos no início do processo de software; � A gerência não deve usar inspeções para avaliar pessoal 25 Inspeções de software � Envolve pessoas examinando uma representação de software para descobrir anomalias e defeitos; � Não há a necessidade de execução do sistema, assim pode ser usada antes da implementação (processo V&V estático); � Pode ser aplicada a qualquer representação do sistema (requisitos, projeto, dados de teste, etc.); � Técnica muito eficaz para a descoberta de erros (testes de mesa). 26 Sucessos da inspeção �Muitos defeitos diferentes podem ser descobertos em uma única inspeção. � Em teste, um defeito pode mascarar outros, assim várias execuções são necessárias. � Conhecimento sobre o domínio e sobre programação aumentam a eficácia. � Revisores tem alta probabilidade de já ter visto os tipos de erros que normalmente surgem. 27 � Inspeções (estática) e testes(dinâmico) são complementares: � Inspeções => verificação; � Testes => verificação e validação. � Ambos devem ser usados durante o processo de V&V; � As inspeções podem verificar a conformidade com uma especificação: � Não verificam a conformidade com os requisitos reais do cliente. � As inspeções não podem verificar características de qualidade, tais como desempenho, usabilidade, etc. Inspeções e testes 28 Inspeções de programa � Abordagem formalizada para revisões de artefatos; � Voltadas explicitamente para detecção de falhas (não correção); � Falhas podem ser erros lógicos (por exemplo, uma variável não iniciada) ou não conformidade com padrões. 29 Checklist para inspeção de programa � Um checklist de erros comuns deve ser usado para direcionar a inspeção; � Checklists de erros são dependentes de linguagem de programação. � Refletem os erros característicos com maior probabilidade de surgimento na linguagem. � Exemplos de itens da checklist: inicialização de variáveis, terminação de laços, etc. � Inspeções também podem “executar” o sistema, através da análise passo-a-passo de seu código. Classe de defeitos Checagem de inspeção Defeitos nos dados Todas as variáveis do programa são iniciadas antes de seu uso? Todas as constantes foram denominadas Existe alguma possibilidade de overflow de buffer Defeitos de controle Para cada declaração condicional, a condição está correta? Cada laço está certo para terminar? Se um identificador break é requerido após cada caso em declarações ‘case’, esse identificador foi incluído? Defeitos de entrada/saída Todas as variáveis de entrada são utilizadas? Entradas inesperadas podem fazer com que os dados sejam corrompidos? Defeitos de interface Todas as chamadas de funções ou métodos tem o número correto de parâmetros? Os tipos formais e reais de parâmetros combinam? Os parâmetros estão na ordem certa? Defeitos de Gerenciamento de armazenamento Se o armazenamento dinâmico é utilizado, foi alocado espaço correto? 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 erros foram levadas em conta? 30 Verificações de inspeções 31 Benefícios da inspeção Detecção de defeitos antecipada � As inspeções melhoram a qualidade desde o início do projeto detectando mais defeitos desde a fase de requisitos. 32 Os defeitos inseridos em uma fase não são identificados na própria fase, e se estendem por várias outras fases do desenvolvimento. A maior parte dos defeitos inseridos na fase de requisitos são identificados na mesma fase, ou logo em seguida; o mesmo acontece para as outras fases. Sem inspeção Com inspeção Adaptado Prof. Márcio Eduardo Delamaro – ICMC/USP Benefícios da inspeção 33 Benefícios da inspeção � As inspeções melhoram a produtividade uma vez que os defeitos são encontrados quando são mais fáceis e mais baratos para corrigir. Adaptado Prof. Márcio Eduardo Delamaro – ICMC/USP 34 Técnicas de inspeção de Software � A Inspeção faz o uso da revisão com base na leitura e compreensão dos artefatos de software; � As técnicas de leitura podem auxiliar na melhoria do entendimento dos artefatos; � Segundo Braga e Coelho (2012), algumas das principais técnicas de leitura são: � Ad-hoc: � A detecção de defeitos depende exclusivamente da habilidade, do conhecimento e da experiência do inspetor. � Checklist (LBCh): � Baseia-se em uma série de questões (tipo sim/não) sobre assuntos do artefato a ser inspecionado. � Cenário (LBCe): � Seguindo um cenário, o inspetor adquire um conhecimento mais aprofundado do sistema, possibilitando que ele ache defeitos mais sutis; 35 Técnicas de inspeção de Software 36 Técnicas de da inspeção de Software � Stepwise Abstraction (SA): � Esta técnica fornece instruções de leitura mais estruturadas e precisas e é ideal para inspecionar documentos de código; � Perspectiva (LBPe): � O produto de software deve ser inspecionado a partir das perspectivas dos diferentes stakeholders. Ela pode ser dividida em três partes: introdução, instruções e perguntas � N-fold: � Método de leitura que consiste na replicação do processo de realização de inspeções formais usando diversas equipes, que fazem o trabalho em paralelo (único moderador). 37 Análise estática � Técnicas de Análise Estática � São técnicas de verificação de sistema que não envolvem a execução de um programa; � Trabalham em uma representação fonte do software (modelo ou o código) do programa em si; � Podem ser usadas para identificar erros antes que uma versão executável do sistema esteja disponível; � Inspeções e avaliações em pares são uma forma de análise estática; 38 � Técnicas de Análise Estática para sistemas críticos: � Verificação formal; � Verificação de modelos; � Análise estática automática. Análise estática 39 Verificação e método formais � Os métodos formais utilizam modelo formal de sistema que serve como uma especificação; � Esses métodos formais são relacionados, principalmente, a uma análise matemática da especificação; � No processo de V & V, os métodos formais podem ser usados em diferentes estágios: 40 Verificação e método formais � Estágio 1: � A especificação é desenvolvida e matematicamente analisada por inconsistências. É eficaz em descobrir erros de especificação e omissões; � Estágio 2: � Utilização de argumentos matemáticos para verificar, se o código de um sistema de software é consistente com sua especificação. É eficaz em descobrir erros de programação e design. 41 Argumentos a favor dos métodos formais � A produção de uma especificação matemática requer uma análise detalhada dos requisitos, por isso, a descoberta de erros é mais provável; � Podem detectar erros de implementação antes do teste quando o programa é analisado em paralelo com a especificação � Requerem notações especializadas que não podem ser compreendidas por especialistas de domínio; � Desenvolver uma especificação é muito dispendioso, mas é mais dispendioso mostrar que um programa atende à essa especificação; � Pode ser possível atingir o mesmo nível de confiança em um programa mais barato usando outras técnicas de V &V. 42 Argumentos contra os métodos formais � Abordagem alternativa à análise formal; � Baseada em uma noção maisrestrita de correção; � Usada na verificação de projetos de sistemas de hardware e em sistemas críticos de software. Ex: � Software de controle de veículos de exploração de Marte de NASA; � Software processador de chamadas telefônicas. 43 Verificação de modelos � Estágios verificação de modelo: � Envolve a criação de um modelo de um sistema e a verificação da correção desse modelo, geralmente como uma máquina de estado finito estendida; � Um conjunto de propriedades desejáveis de sistema é identificado e escrito em uma notação formal; 44 Verificação de modelos � O verificador de modelos explora todos os caminhos pelo modelo (isto é, todas as possíveis transições de estado) e verifica se uma propriedade especificada pelo usuário é válido para cada caminho; 45 Verificação de modelos Requisitos, projeto ou programa Construção de modelo Especificação de propriedade Modelo de estado finito estendido do sistema Propriedades do sistema desejadas Verificador de modelo Confirmação ou não � Computacionalmente, a verificação de modelos é muito cara: � Usa uma abordagem exaustiva para verificar todos os caminhos do modelo de sistema; � Tamanho do sistema aumenta, também aumenta o número de estados, e, consequentemente, o número de caminhos a ser verificado; � Para sistemas grandes, a verificação de modelos pode ser pouco útil, devido ao tempo de computador requerido para executar as verificações. 46 Verificação de modelos � As ferramentas de análise estática trabalham no código fonte de um sistema; � A análise estática automatizada é mais fácil de ser introduzida em um processo de desenvolvimento do que a verificação formal ou a verificação de modelos: � Programadores não precisam aprender notações especializadas para escrever as especificações de programa. 47 Análise estática automatizada � Os analisadores estáticos automatizados são as ferramentas de software que fazem a varredura no código fonte de um programa e detectam possíveis defeitos e anomalias; � A intenção é desenhar um código para as anomalias no programa, como: variáveis usadas sem iniciação, sem uso, ou ainda, dados, cujos valores poderiam sair dos limites. 48 Análise estática automatizada 49 Classe de defeitos Checagem da análise estática Defeitos em dados Variáveis utilizadas antes da inicialização Variáveis declaradas, mas nunca utilizadas Variáveis atribuídas duas vezes, mas nunca utilizadas entre as atribuições Possíveis violações de limites de vetor Variáveis não declaradas Defeitos de controle Código inacessível Ramos incondicionais centro de loops Defeitos de entrada/saída Saída de variáveis duas vezes sem atribuição intermediária . Defeitos de interface Desacordo quanto ao tipo de parâmetro Desacordo quanto ao número de parâmetros Não utilização dos resultados de funções Funções e procedimentos não chamados Defeitos de gerenciamento De armazenamento Ponteiros não atribuídos Ponteiro aritmético Perdas de memória Checagem da análise estática 50 Estágios da análise estática � Análise de fluxo de controle: � Verifica laços com múltiplos pontos de saídas ou de entrada, encontra código inacessível, etc. � Análise de uso de dados: � Detecta variáveis não iniciadas, variáveis que são declaradas mas nunca usadas, etc. � Análise de interface: � Verifica a consistência das declarações de rotina e procedimentos e seus usos. 51 Estágios da análise estática � Análise de caminho: � Identifica caminhos através do programa e estabelece as declarações executadas naquele caminho; � Pode também verificar se certo predicados são verdadeiros; � Destaca as informações para inspeção ou revisão de código. � Outros tipos de análises: � Ex: Análise de fluxo de informações: Identifica as dependências das variáveis ou I/O. � Limitações: escalabilidade, completude, precisão, excesso de informações 52 � Particularmente valiosa quando uma linguagem como C é usada, já que trata-se de uma linguagem com checagem de tipo fraca e, por isso, muitos erros não são detectados pelo compilador. �Menos efetiva para linguagens como Java, que possuem uma checagem de tipos forte e, portanto, podem detectar muitos erros durante a compilação �O analisador estático pode descobrir áreas de vulnerabilidade, tais como buffer, overflows ou insumos não fiscalizados; Uso da análise estática 53 �É rotineiramente usada no desenvolvimento de segurança em muitos sistemas críticos de segurança: Ex: � Microsoft introduziu a análise estática no desenvolvimento de drivers de dispositivos; � Como parte do processo de V & V, muitos sistemas críticos, incluindo os de aviação e os sistemas nucleares, são analisados estaticamente. Uso da análise estática 54 Desenvolvimento de software Cleanroon � Nome derivado processo ‘Cleanroom’ na fabricação de semicondutores; � A filosofia é a prevenção ao invés de remoção de defeitos; � Esse processo de desenvolvimento de software é baseado em: � Desenvolvimento incremental; � Especificação formal; � Programação estruturada; � Verificação estática usando argumentos de correção; � Testes estatísticos para determinar a confiabilidade de programa. 55 O processo Cleanroom Especificar formalmente o sistema Desenvolver perfil operacional Definir incrementos do software Construir programa estruturado Verificar código formalmente Integrar incremento Projetar testes estatísticos Testar sistema integrado 56 Características do processo Cleanroon � Especificação formal usando um modelo de transição de estados; � Desenvolvimento incremental onde o cliente prioriza os incrementos (o software é particionado em incremento desenvolvidos e validados separadamente); � Programação estruturada – controle limitado e construções abstratas são usadas no programa; � Verificação estática usando rigorosas inspeções de software; � Testes estatísticos do sistemas, cada incremento de software é testado estatisticamente para determinar a confiabilidade. 57 Especificação formal e inspeções � O modelo baseado em estados é a especificação e o processo de inspeção checa o programa com relação a esse modelo; � A abordagem utilizada para o desenvolvimento tem como base transformações bem definidas, que tentam preservar a exatidão em cada transformação, para uma representação mais detalhada; � Argumentos matemáticos são usados para aumentar a confiança no processo de inspeção. 58 Equipes no processo Cleanroom � Equipe de especificação: Responsável pelo desenvolvimento e pela manutenção da especificação do sistema; � Equipe de desenvolvimento: Responsável por desenvolver e verificar o software. O software não é executado durante esse processo; � Equipe de certificação: Responsável pelo desenvolvimento de um conjunto de testes estatísticos para exercitar o software após o seu desenvolvimento (certificação da confiabilidade do software). 59 Avaliação de processo Cleanroon �Resultados na IBM tem mostrado que os softwares possuem bem menos erros; � Avaliação mostra que o processo não é mais caro do que outras abordagens; � Menos erros do que em um processo de desenvolvimento tradicional; � Uso do processo tem sido restrito a organizações tecnologicamente avançadas. 60 Resumo � Verificação certifica a conformidade com a especificação; � Validação certifica que o programa faz o que o usuário precisa; � Planos de teste descrevem os itens a serem testados; � Inspeção de programas é o processo de analisar o código fonte, sem executá-lo.� O código do programa é sistematicamente checado por uma pequena equipe, para localizar defeitos. 61 Resumo � Ferramentas de análise estática pode revelar anomalias no programa (possíveis defeitos); � Processo de desenvolvimento Cleanroom é uma abordagem de desenvolvimento de software que se apoia em desenvolvimento incremental, verificação estática e teste estatístico. 62 � DEVMEDIA. Revista Engenharia de Software. Disponível em: http://www.devmedia.com.br/revista-engenharia-de-software- magazine. � SOFTEX. Qualidade – MPS.BR. Disponível em http://www.softex.br/mpsbr. � SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2008. 552pp. � PRESSMAN, Roger S. Engenharia de software. São Paulo, SP: Makron Books do Brasil, 2007. 1056p. � Projeto Spider. Disponível em: http://www.ufpa.br/srbo/Disciplinas/CBCC_CBSI_Mestrado_Qualidade/2012.2/VERVAL.pdf. � Prof. Márcio Eduardo Delamaro – ICMC/USP . Disponível em: moodle.stoa.usp.br/mod/resource/view.php?id=32906. � Fábio Procópio. Engenharia de Software. Disponível em: https://sites.google.com/site/fabiooprocopio/engenharia-de-software. � Caso de Desenvolvimento para Projetos Pequenos: Elaboração. Gráfico de Gantt. Disponível em: http://www.wthreex.com/rup/examples/devcase_sp/sip_iie.htm. � Jessica MacNeil.Mariner 1 destroyed due to code error, July 22, 1962. Disponível em: http://www.edn.com. Referências
Compartilhar