Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Eng.ª do Software - 9. Verificação e validação

11,334 views

Published on

Verificação e validação. Unidade de Engenharia do Software I para o curso de METI no ISCTE-IUL no 2.º semestre do ano lectivo de 2009/2010.

Published in: Education
  • Be the first to comment

Eng.ª do Software - 9. Verificação e validação

  1. 1. Engenharia do Software I<br />Manuel Menezes de Sequeira<br />DCTI, ISCTE-IUL<br />Manuel.Sequeira@iscte.pt, D6.02<br />As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por  Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.<br />
  2. 2. Na aula anterior<br />Desenho de interfaces com o utilizador<br />Problemas de desenho<br />Heurísticas de Nielsen para interfaces com o utilizador<br />Estilos de interacção<br />Processo de desenho de interfaces com o utilizador<br />Análise dos utilizadores<br />Prototipagem de interfaces com o utilizador<br />Avaliação de interfaces<br />2009/2010<br />2<br />Engenharia do Software I<br />
  3. 3. Verificação e validação<br />2009/2010<br />3<br />Engenharia do Software I<br />
  4. 4. Sumário<br />Verificação e validação<br />Planeamento da verificação e validação<br />Inspecções de software<br />Análise estática automática<br />Desenvolvimento de software em sala limpa<br />2009/2010<br />4<br />Engenharia do Software I<br />
  5. 5. Objectivos<br />Apresentar verificação e validação de software e sua distinção<br />Descrever processo de inspecção de software e seu papel na verificação e validação<br />Explicar análise estática como técnica de verificação<br />Descrever processo de desenvolvimento de software em sala limpa<br />2009/2010<br />5<br />Engenharia do Software I<br />
  6. 6. Verificação vs. validação<br />2009/2010<br />Engenharia do Software I<br />6<br />
  7. 7. Processo de verificação e validação<br />Processo de ciclo de vida completo: aplicado em cada etapa do processo de software<br />Principais objectivos<br />Descobrir defeitos no sistema<br />Aferir se o sistema é útil e usável em operação<br />2009/2010<br />Engenharia do Software I<br />7<br />
  8. 8. Objectivos da verificação e validação<br />Criar confiança de que software é adequado ao seu propósito<br />Não significa que seja completamente livre de defeitos<br />Tem de ser suficientemente bom para a utilização pretendida<br />Tipo de utilização determina grau de confiança necessário<br />2009/2010<br />Engenharia do Software I<br />8<br />
  9. 9. Confiança<br />Depende de <br />Propósito do sistema<br />Expectativas do utilizador<br />Ambiente de marketing<br />2009/2010<br />Engenharia do Software I<br />9<br />
  10. 10. Confiança<br />2009/2010<br />Engenharia do Software I<br />10<br />
  11. 11. Verificações estática e dinâmica<br />2009/2010<br />Engenharia do Software I<br />11<br />Verificação estática<br />Verificação dinâmica<br />
  12. 12. Verificação e validação estáticas e dinâmicas<br />2009/2010<br />12<br />Engenharia do Software I<br />Inspecções de software<br />Especificação de requisitos<br />Desenho de alto nível<br />Especificação formal<br />Desenho pormenorizado<br />Programa<br />Protótipo<br />Teste de software<br />
  13. 13. Teste de software<br />Pode revelar erros<br />Não demonstra ausência de erros<br />Única técnica de validação para requisitos não funcionais: software tem de ser executado para observar como se comporta<br />Usado em conjunto com verificação estática para cobrir completamente verificação e validação<br />2009/2010<br />Engenharia do Software I<br />13<br />
  14. 14. Tipos de testes<br />Testes de defeitos<br />Descobrem defeitos do sistema<br />Teste com sucesso revela presença de defeito<br />Testes de validação<br />Mostram que software cumpre requisitos<br />Teste com sucesso mostrar que requisito foi devidamente implementado<br />2009/2010<br />Engenharia do Software I<br />14<br />Capítulo 23<br />
  15. 15. Teste e depuração<br />São processos distintos<br />Verificação e validação estabelecem existência de defeitos em programa<br />Depuração localiza e corrige erros<br />Depurar envolve formular hipóteses sobre comportamento do programa e testá-las para encontrar erro no sistema<br />2009/2010<br />Engenharia do Software I<br />15<br />
  16. 16. Processo de depuração<br />2009/2010<br />16<br />Engenharia do Software I<br />Resultados do teste<br />Especificação<br />Casos de teste<br />Localizar erro<br />Desenhar correcção do erro<br />Corrigir erro<br />Testar programa de novo<br />
  17. 17. Planeamento da verificação e validação<br />Planear cuidadosamente para obter máximo resultado de processos de teste e inspecção<br />Planear logo no início do processo de desenvolvimento<br />Identificar equilíbrio entre verificação estática e teste<br />Definer normas para processo de teste<br />Não descrever testes de produto<br />2009/2010<br />Engenharia do Software I<br />17<br />
  18. 18. Modelo em V<br />2009/2010<br />18<br />Engenharia do Software I<br />Especificação de requisitos<br />Serviço<br />Testes de aceitação<br />Especificação de sistema<br />Desenho de sistema<br />Testes de integração de sistema<br />Plano de testes de integração de subsistemas<br />Plano de testes de integração de sistemas<br />Plano de testes de aceitação<br />Desenho de pormenor<br />Testes de integração de subsistemas<br />Codificação e teste de módulos e unidades<br />
  19. 19. Estrutura de um plano de teste de software<br />Processo de teste<br />Rastreabilidade de requisitos<br />Itens testados<br />Calendário de testes<br />Procedimento de registo de testes<br />Requisitos de hardware e software<br />Restrições<br />2009/2010<br />Engenharia do Software I<br />19<br />
  20. 20. Plano de teste de software<br />2009/2010<br />Engenharia do Software I<br />20<br />
  21. 21. Inspecções de software<br />Exame de representações fonte para descobrir anomalias e defeitos<br />Não requerem execução do sistema: podem ocorrer antes da implementação<br />Aplicadas a qualquer representação do sistema<br />Requisitos<br />Desenho<br />Dados de configuração<br />Dados de teste<br />Etc.<br />Eficazes a descobrir erros em programas<br />2009/2010<br />Engenharia do Software I<br />21<br />
  22. 22. Sucesso da inspecção<br />Muitos diferentes defeitos podem ser descobertos numa única inspecção<br />Como um defeito pode esconder outro, necessárias várias execuções<br />Como conhecimento do domínio e de programação é reutilizado, revisores podem já ter visto tipos de erro mais comuns<br />2009/2010<br />Engenharia do Software I<br />22<br />
  23. 23. Inspecções e testes<br />Técnicas de verificação complementares<br />Ambas usadas durante processo de verificação e validação<br />Inspecções<br />Podem verificar cumprimento de especificação <br />Não podem verificar cumprimento dos requisitos reais do cliente<br />Não podem verificar características não funcionais como desempenho ou usabilidade<br />2009/2010<br />Engenharia do Software I<br />23<br />
  24. 24. Inspecções de programa<br />Abordagem formalizada a revisões documentais<br />Destinadas explicitamente a detectar defeitos (e não a corrigi-los)<br />Defeitos<br />Erros lógicos<br />Anomalias no código que podem indicar uma condição errónea (e.g., variável não inicializada)<br />Violação de normas<br />2009/2010<br />Engenharia do Software I<br />24<br />
  25. 25. Pré-condições da inspecção<br />Disponibilidade de especificação precisa<br />Membros da equipa familiarizados com normas organizacionais<br />Disponibilidade de código ou outras representações do sistema sintacticamente correctas<br />2009/2010<br />Engenharia do Software I<br />25<br />
  26. 26. Pré-condições da inspecção<br />Lista de verificação de erros preparada<br />Gestão mentalizada para aumento inicial dos custos devido à inspecção<br />Gestão mentalizada para não usar inspecções para avaliação de pessoal (i.e., para não procurar os responsáveis pelos erros)<br />2009/2010<br />Engenharia do Software I<br />26<br />
  27. 27. Processo de inspecção<br />2009/2010<br />27<br />Engenharia do Software I<br />Planeamento<br />Visão global<br />Preparação individual<br />Reunião de inspecção<br />Retrabalho<br />Seguimento<br />
  28. 28. Procedimento de inspecção<br />Apresentar visão geral do sistema à equipa de inspecção<br />Distribuir com tempo código e documentos associados<br />Inspeccionar anotando erros descobertos<br />Corrigir erros descobertos<br />Reinspeccionar se necessário<br />2009/2010<br />Engenharia do Software I<br />28<br />
  29. 29. Papéis na inspecção<br />2009/2010<br />Engenharia do Software I<br />29<br />
  30. 30. Listas de verificação da inspecção<br />Devem usar-se para guiar inspecção<br />Dependem da linguagem de programação e reflectem seus erros típicos<br />Verificação de tipos “fraca” implica lista maior<br />Exemplos<br />Inicialização<br />Nomes de variáveis e constantes<br />Terminação de ciclos<br />Limites de matrizes<br />2009/2010<br />Engenharia do Software I<br />30<br />
  31. 31. Verificações da inspecção<br />Erros nos dados<br />Variáveis inicializadas antes de usadas?<br />Sem números mágicos (constantes sem nome)?<br />Índice máximo de matrizes é comprimento ou comprimento - 1?<br />Deve atribuir-se explicitamente delimitador a cadeias de caracteres?<br />Pode ocorrer transbordamento de memória? <br />Erros de entrada e saída<br />Variáveis de entrada todas usadas?<br />Variáveis de saída com valor atribuído antes da saída?<br />Entradas inesperadas podem causar corrupção?<br />2009/2010<br />Engenharia do Software I<br />31<br />
  32. 32. Verificações da inspecção<br />Erros no controlo<br />Guardas de instruções condicionais correctas?<br />Terminação de ciclos assegurada?<br />Instruções compostas correctamente envolvidas?<br />Cobertura de instruções de selecção de casos correcta?<br />Se necessária, foi incluída quebra depois de cada caso?<br />Erros de interface<br />Invocações com número correcto de argumentos?<br />Tipos de argumentos e parâmetros correspondem?<br />Argumentos estão na ordem correcta?<br />Se componentes acedem a memória partilhada, têm o mesmo modelo da sua estrutura?<br />2009/2010<br />Engenharia do Software I<br />32<br />
  33. 33. Verificações da inspecção<br />Erros de gestão de armazenamento<br />Quando estrutura com ligações modificada, ligações correctamente atribuídas?<br />Memória dinâmica correctamente reservada?<br />Memória libertada quando deixa de ser necessária?<br />Erros de gestão de excepções<br />Lida-se com todas possíveis condições de erro?<br />2009/2010<br />Engenharia do Software I<br />33<br />
  34. 34. Taxa de inspecção<br />Ritmo<br />Visão global: 500 instruções/hora<br />Preparação individual: 125 instruções/hora<br />Inspecção: 90-125 instruções/hora<br />Custo<br />Processo de inspecção é caro<br />Inspecção de 500 linhas exige esforço de 40 humanos hora – cerca de £2800 no Reino Unido (≈ 3260 €)<br />2009/2010<br />Engenharia do Software I<br />34<br />
  35. 35. Análise estática automática<br />Levada a cabo por analisadores estáticos<br />Analisadores estáticos<br />Ferramentas de software<br />Analisam o código fonte<br />Tentam descobrir potenciais condições de erro<br />Reportam à equipa de verificação e validação<br />Eficazes como auxílio às inspecções<br />Suplementam inspecção, não a substituem<br />2009/2010<br />Engenharia do Software I<br />35<br />
  36. 36. Verificações da análise estática<br />2009/2010<br />Engenharia do Software I<br />36<br />
  37. 37. Etapas da análise estática<br />2009/2010<br />Engenharia do Software I<br />37<br />Usar com cuidado! Geram grande quantidade de informação.<br />Usar com cuidado! Geram grande quantidade de informação.<br />
  38. 38. lint<br />1 // test.c<br /> 2 #include <stdio.h><br /> 3 <br /> 4 printarray (Anarray)<br /> 5 int Anarray;<br /> 6 {<br /> 7 printf("%d", Anarray);<br /> 8 }<br /> 9 <br />10 main()<br />11 {<br />12 int Anarray[5]; int i; char c;<br />13 printarray(Anarray, i, c);<br />14 printarray(Anarray) ;<br />15 }<br />> cc test.c<br />> lint test.c<br />test.c(13): warning: c may be used before set<br />test.c(13): warning: i may be used before set<br />printarray: variable # of args. test.c(4) :: test.c(13)<br />printarray, arg. 1 used inconsistently test.c(4) :: test.c(13)<br />printarray, arg. 1 used inconsistently test.c(4) :: test.c(14)<br />printf returns value which is always ignored<br />2009/2010<br />Engenharia do Software I<br />38<br />
  39. 39. Utilização da análise estática<br />Particularmente útil para linguagens fracamente tipificadas (e.g., C) em que compilador não detecta muitos erros<br />Relação custo-benefício menos boa para linguagens fortemente tipificadas (e.g., Java) em que compilador detecta muitos erros<br />2009/2010<br />Engenharia do Software I<br />39<br />
  40. 40. Verificação e métodos formais<br />Pode usar-se métodos formais quando houver especificação matemática do sistema<br />Técnica de verificação estática por excelência<br />Envolvem análise matemática pormenorizada da especificação<br />Podem produzir demonstração formal da conformidade de programa com especificação<br />2009/2010<br />Engenharia do Software I<br />40<br />
  41. 41. Argumentos a favor de métodos formais<br />Produzir especificação matemática requer análise pormenorizada dos requisitos, o que pode revelar erros<br />Podem detectar erros de implementação antes de testes quando programa analisado em conjunto com especificação<br />2009/2010<br />Engenharia do Software I<br />41<br />
  42. 42. Argumentos contra métodos formais<br />Requerem notações especializadas não compreendidas por peritos do domínio<br />Muito caro desenvolver especificação e mais caro ainda mostrar que um programa cumpre especificação<br />Pode ser possível atingir mesmo nível de confiança em programa de forma mais económica usando outras técnicas de verificação e validação<br />2009/2010<br />Engenharia do Software I<br />42<br />
  43. 43. Desenvolvimento de software em sala limpa<br />Nome derivado do processo de “sala limpa” usado no fabrico de semicondutores<br />Prevenção e não remoção de defeitos<br />Processo de desenvolvimento baseado em<br />Desenvolvimento incremental<br />Especificação formal<br />Verificação estática usa argumentos de correcção<br />Testes estatísticos mostram fiabilidade do programa<br />2009/2010<br />Engenharia do Software I<br />43<br />
  44. 44. Processo de sala limpa<br />2009/2010<br />44<br />Engenharia do Software I<br />Especificar sistema formalmente<br />Desenhar testes estatísticos<br />Testar sistema integrado<br />Definir incrementos do software<br />Construir programa estruturado<br />Desenvolver perfil operacional<br />retrabalho<br />Verificar formalmente código<br />Integrar incremento<br />
  45. 45. Características do processo de sala limpa<br />Especificação formal com modelo de transição de estados<br />Desenvolvimento incremental com cliente prioritizando incrementos<br />Programação estruturada – Construções de controlo e abstracção limitadas usadas no programa<br />Verificação estática usando inspecções rigorosas<br />Testes estatísticos do sistema<br />2009/2010<br />Engenharia do Software I<br />45<br />Capítulo 24<br />
  46. 46. Especificação formal e inspecções<br />Modelo baseado em estados é especificação do sistema<br />Processo de inspecção verifica programa relativamente a modelo<br />Abordagem à programação torna clara correspondência entre modelo e sistema<br />Argumentos matemáticos (e não demonstrações) usados para aumentar confiança no processo de inspecção<br />2009/2010<br />Engenharia do Software I<br />46<br />
  47. 47. Equipas do processo de sala limpa<br />2009/2010<br />Engenharia do Software I<br />47<br />
  48. 48. Avaliação do processo de sala limpa<br />Resultados muito impressionantes<br />Poucas falhas nos sistemas entregues<br />Avaliações independentes mostram que não é mais caro que outras abordagens<br />Menos erros que em processos “tradicionais”<br />Pouco usado: pouco claro como transferir processo para ambiente com engenheiros menos hábeis ou motivados<br />2009/2010<br />Engenharia do Software I<br />48<br />
  49. 49. A reter<br />Verificação e validação diferentes<br />Verificação: conformidade com especificação<br />Validação: cumprimento de requisitos do cliente<br />Processo de testes guiado por plano<br />Técnicas de verificação estática envolvem exame e análise do programa para detectar erros<br />2009/2010<br />Engenharia do Software I<br />49<br />
  50. 50. A reter<br />Inspecções muito eficazes na descoberta de erros<br />Código sistematicamente verificado por pequena equipa para localizar erros de software<br />Ferramentas de análise estática descobrem anomalias que indiciam erros no código<br />Processo de desenvolvimento de sala limpa<br />Desenvolvimento incremental<br />Verificação estática<br />Testes estatísticos<br />2009/2010<br />Engenharia do Software I<br />50<br />
  51. 51. A ler<br />IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006<br />Capítulo 22<br />2009/2010<br />Engenharia do Software I<br />51<br />

×