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.

1. Engenharia do Software I Manuel Menezes de Sequeira DCTI, ISCTE-IUL Manuel.Sequeira@iscte.pt, D6.02 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.

2. Na aula anterior Desenho de interfaces com o utilizador Problemas de desenho Heurísticas de Nielsen para interfaces com o utilizador Estilos de interacção Processo de desenho de interfaces com o utilizador Análise dos utilizadores Prototipagem de interfaces com o utilizador Avaliação de interfaces 2009/2010 2 Engenharia do Software I

3. Verificação e validação 2009/2010 3 Engenharia do Software I

4. Sumário Verificação e validação Planeamento da verificação e validação Inspecções de software Análise estática automática Desenvolvimento de software em sala limpa 2009/2010 4 Engenharia do Software I

5. Objectivos Apresentar verificação e validação de software e sua distinção Descrever processo de inspecção de software e seu papel na verificação e validação Explicar análise estática como técnica de verificação Descrever processo de desenvolvimento de software em sala limpa 2009/2010 5 Engenharia do Software I

6. Verificação vs. validação 2009/2010 Engenharia do Software I 6

7. Processo de verificação e validação Processo de ciclo de vida completo: aplicado em cada etapa do processo de software Principais objectivos Descobrir defeitos no sistema Aferir se o sistema é útil e usável em operação 2009/2010 Engenharia do Software I 7

8. Objectivos da verificação e validação Criar confiança de que software é adequado ao seu propósito Não significa que seja completamente livre de defeitos Tem de ser suficientemente bom para a utilização pretendida Tipo de utilização determina grau de confiança necessário 2009/2010 Engenharia do Software I 8

9. Confiança Depende de Propósito do sistema Expectativas do utilizador Ambiente de marketing 2009/2010 Engenharia do Software I 9

10. Confiança 2009/2010 Engenharia do Software I 10

11. Verificações estática e dinâmica 2009/2010 Engenharia do Software I 11 Verificação estática Verificação dinâmica

12. Verificação e validação estáticas e dinâmicas 2009/2010 12 Engenharia do Software I Inspecções de software Especificação de requisitos Desenho de alto nível Especificação formal Desenho pormenorizado Programa Protótipo Teste de software

13. Teste de software Pode revelar erros Não demonstra ausência de erros Única técnica de validação para requisitos não funcionais: software tem de ser executado para observar como se comporta Usado em conjunto com verificação estática para cobrir completamente verificação e validação 2009/2010 Engenharia do Software I 13

14. Tipos de testes Testes de defeitos Descobrem defeitos do sistema Teste com sucesso revela presença de defeito Testes de validação Mostram que software cumpre requisitos Teste com sucesso mostrar que requisito foi devidamente implementado 2009/2010 Engenharia do Software I 14 Capítulo 23

15. Teste e depuração São processos distintos Verificação e validação estabelecem existência de defeitos em programa Depuração localiza e corrige erros Depurar envolve formular hipóteses sobre comportamento do programa e testá-las para encontrar erro no sistema 2009/2010 Engenharia do Software I 15

16. Processo de depuração 2009/2010 16 Engenharia do Software I Resultados do teste Especificação Casos de teste Localizar erro Desenhar correcção do erro Corrigir erro Testar programa de novo

17. Planeamento da verificação e validação Planear cuidadosamente para obter máximo resultado de processos de teste e inspecção Planear logo no início do processo de desenvolvimento Identificar equilíbrio entre verificação estática e teste Definer normas para processo de teste Não descrever testes de produto 2009/2010 Engenharia do Software I 17

18. Modelo em V 2009/2010 18 Engenharia do Software I Especificação de requisitos Serviço Testes de aceitação Especificação de sistema Desenho de sistema Testes de integração de sistema Plano de testes de integração de subsistemas Plano de testes de integração de sistemas Plano de testes de aceitação Desenho de pormenor Testes de integração de subsistemas Codificação e teste de módulos e unidades

19. Estrutura de um plano de teste de software Processo de teste Rastreabilidade de requisitos Itens testados Calendário de testes Procedimento de registo de testes Requisitos de hardware e software Restrições 2009/2010 Engenharia do Software I 19

20. Plano de teste de software 2009/2010 Engenharia do Software I 20

21. Inspecções de software Exame de representações fonte para descobrir anomalias e defeitos Não requerem execução do sistema: podem ocorrer antes da implementação Aplicadas a qualquer representação do sistema Requisitos Desenho Dados de configuração Dados de teste Etc. Eficazes a descobrir erros em programas 2009/2010 Engenharia do Software I 21

22. Sucesso da inspecção Muitos diferentes defeitos podem ser descobertos numa única inspecção Como um defeito pode esconder outro, necessárias várias execuções Como conhecimento do domínio e de programação é reutilizado, revisores podem já ter visto tipos de erro mais comuns 2009/2010 Engenharia do Software I 22

23. Inspecções e testes Técnicas de verificação complementares Ambas usadas durante processo de verificação e validação Inspecções Podem verificar cumprimento de especificação Não podem verificar cumprimento dos requisitos reais do cliente Não podem verificar características não funcionais como desempenho ou usabilidade 2009/2010 Engenharia do Software I 23

24. Inspecções de programa Abordagem formalizada a revisões documentais Destinadas explicitamente a detectar defeitos (e não a corrigi-los) Defeitos Erros lógicos Anomalias no código que podem indicar uma condição errónea (e.g., variável não inicializada) Violação de normas 2009/2010 Engenharia do Software I 24

25. Pré-condições da inspecção Disponibilidade de especificação precisa Membros da equipa familiarizados com normas organizacionais Disponibilidade de código ou outras representações do sistema sintacticamente correctas 2009/2010 Engenharia do Software I 25

26. Pré-condições da inspecção Lista de verificação de erros preparada Gestão mentalizada para aumento inicial dos custos devido à inspecção 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) 2009/2010 Engenharia do Software I 26

27. Processo de inspecção 2009/2010 27 Engenharia do Software I Planeamento Visão global Preparação individual Reunião de inspecção Retrabalho Seguimento

28. Procedimento de inspecção Apresentar visão geral do sistema à equipa de inspecção Distribuir com tempo código e documentos associados Inspeccionar anotando erros descobertos Corrigir erros descobertos Reinspeccionar se necessário 2009/2010 Engenharia do Software I 28

29. Papéis na inspecção 2009/2010 Engenharia do Software I 29

30. Listas de verificação da inspecção Devem usar-se para guiar inspecção Dependem da linguagem de programação e reflectem seus erros típicos Verificação de tipos “fraca” implica lista maior Exemplos Inicialização Nomes de variáveis e constantes Terminação de ciclos Limites de matrizes 2009/2010 Engenharia do Software I 30

31. Verificações da inspecção Erros nos dados Variáveis inicializadas antes de usadas? Sem números mágicos (constantes sem nome)? Índice máximo de matrizes é comprimento ou comprimento - 1? Deve atribuir-se explicitamente delimitador a cadeias de caracteres? Pode ocorrer transbordamento de memória? Erros de entrada e saída Variáveis de entrada todas usadas? Variáveis de saída com valor atribuído antes da saída? Entradas inesperadas podem causar corrupção? 2009/2010 Engenharia do Software I 31

32. Verificações da inspecção Erros no controlo Guardas de instruções condicionais correctas? Terminação de ciclos assegurada? Instruções compostas correctamente envolvidas? Cobertura de instruções de selecção de casos correcta? Se necessária, foi incluída quebra depois de cada caso? Erros de interface Invocações com número correcto de argumentos? Tipos de argumentos e parâmetros correspondem? Argumentos estão na ordem correcta? Se componentes acedem a memória partilhada, têm o mesmo modelo da sua estrutura? 2009/2010 Engenharia do Software I 32

33. Verificações da inspecção Erros de gestão de armazenamento Quando estrutura com ligações modificada, ligações correctamente atribuídas? Memória dinâmica correctamente reservada? Memória libertada quando deixa de ser necessária? Erros de gestão de excepções Lida-se com todas possíveis condições de erro? 2009/2010 Engenharia do Software I 33

34. Taxa de inspecção Ritmo Visão global: 500 instruções/hora Preparação individual: 125 instruções/hora Inspecção: 90-125 instruções/hora Custo Processo de inspecção é caro Inspecção de 500 linhas exige esforço de 40 humanos hora – cerca de £2800 no Reino Unido (≈ 3260 €) 2009/2010 Engenharia do Software I 34

35. Análise estática automática Levada a cabo por analisadores estáticos Analisadores estáticos Ferramentas de software Analisam o código fonte Tentam descobrir potenciais condições de erro Reportam à equipa de verificação e validação Eficazes como auxílio às inspecções Suplementam inspecção, não a substituem 2009/2010 Engenharia do Software I 35

36. Verificações da análise estática 2009/2010 Engenharia do Software I 36

37. Etapas da análise estática 2009/2010 Engenharia do Software I 37 Usar com cuidado! Geram grande quantidade de informação. Usar com cuidado! Geram grande quantidade de informação.

38. lint 1 // test.c 2 #include <stdio.h> 3 4 printarray (Anarray) 5 int Anarray; 6 { 7 printf("%d", Anarray); 8 } 9 10 main() 11 { 12 int Anarray[5]; int i; char c; 13 printarray(Anarray, i, c); 14 printarray(Anarray) ; 15 } > cc test.c > lint test.c test.c(13): warning: c may be used before set test.c(13): warning: i may be used before set printarray: variable # of args. test.c(4) :: test.c(13) printarray, arg. 1 used inconsistently test.c(4) :: test.c(13) printarray, arg. 1 used inconsistently test.c(4) :: test.c(14) printf returns value which is always ignored 2009/2010 Engenharia do Software I 38

39. Utilização da análise estática Particularmente útil para linguagens fracamente tipificadas (e.g., C) em que compilador não detecta muitos erros Relação custo-benefício menos boa para linguagens fortemente tipificadas (e.g., Java) em que compilador detecta muitos erros 2009/2010 Engenharia do Software I 39

40. Verificação e métodos formais Pode usar-se métodos formais quando houver especificação matemática do sistema Técnica de verificação estática por excelência Envolvem análise matemática pormenorizada da especificação Podem produzir demonstração formal da conformidade de programa com especificação 2009/2010 Engenharia do Software I 40

41. Argumentos a favor de métodos formais Produzir especificação matemática requer análise pormenorizada dos requisitos, o que pode revelar erros Podem detectar erros de implementação antes de testes quando programa analisado em conjunto com especificação 2009/2010 Engenharia do Software I 41

42. Argumentos contra métodos formais Requerem notações especializadas não compreendidas por peritos do domínio Muito caro desenvolver especificação e mais caro ainda mostrar que um programa cumpre especificação 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 2009/2010 Engenharia do Software I 42

43. Desenvolvimento de software em sala limpa Nome derivado do processo de “sala limpa” usado no fabrico de semicondutores Prevenção e não remoção de defeitos Processo de desenvolvimento baseado em Desenvolvimento incremental Especificação formal Verificação estática usa argumentos de correcção Testes estatísticos mostram fiabilidade do programa 2009/2010 Engenharia do Software I 43

44. Processo de sala limpa 2009/2010 44 Engenharia do Software I Especificar sistema formalmente Desenhar testes estatísticos Testar sistema integrado Definir incrementos do software Construir programa estruturado Desenvolver perfil operacional retrabalho Verificar formalmente código Integrar incremento

45. Características do processo de sala limpa Especificação formal com modelo de transição de estados Desenvolvimento incremental com cliente prioritizando incrementos Programação estruturada – Construções de controlo e abstracção limitadas usadas no programa Verificação estática usando inspecções rigorosas Testes estatísticos do sistema 2009/2010 Engenharia do Software I 45 Capítulo 24

46. Especificação formal e inspecções Modelo baseado em estados é especificação do sistema Processo de inspecção verifica programa relativamente a modelo Abordagem à programação torna clara correspondência entre modelo e sistema Argumentos matemáticos (e não demonstrações) usados para aumentar confiança no processo de inspecção 2009/2010 Engenharia do Software I 46

47. Equipas do processo de sala limpa 2009/2010 Engenharia do Software I 47

48. Avaliação do processo de sala limpa Resultados muito impressionantes Poucas falhas nos sistemas entregues Avaliações independentes mostram que não é mais caro que outras abordagens Menos erros que em processos “tradicionais” Pouco usado: pouco claro como transferir processo para ambiente com engenheiros menos hábeis ou motivados 2009/2010 Engenharia do Software I 48

49. A reter Verificação e validação diferentes Verificação: conformidade com especificação Validação: cumprimento de requisitos do cliente Processo de testes guiado por plano Técnicas de verificação estática envolvem exame e análise do programa para detectar erros 2009/2010 Engenharia do Software I 49

50. A reter Inspecções muito eficazes na descoberta de erros Código sistematicamente verificado por pequena equipa para localizar erros de software Ferramentas de análise estática descobrem anomalias que indiciam erros no código Processo de desenvolvimento de sala limpa Desenvolvimento incremental Verificação estática Testes estatísticos 2009/2010 Engenharia do Software I 50

51. A ler IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006 Capítulo 22 2009/2010 Engenharia do Software I 51