eng.ª do software - 9. verificação e validação
DESCRIPTION
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.TRANSCRIPT
ENGENHARIA DO SOFTWARE I
Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
[email protected], D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel
Menezes de Sequeira.
Engenharia do Software I 2
Na aula anterior
Desenho de interfaces com o utilizadorProblemas de desenhoHeurísticas de Nielsen para interfaces com
o utilizadorEstilos de interacçãoProcesso de desenho de interfaces com o
utilizadorAnálise dos utilizadoresPrototipagem de interfaces com o utilizadorAvaliação de interfaces
2009/2010
Engenharia do Software I 3
Verificação e validação
2009/2010
Engenharia do Software I 4
Sumário
Verificação e validaçãoPlaneamento da verificação e validaçãoInspecções de softwareAnálise estática automáticaDesenvolvimento de software em sala limpa
2009/2010
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
Engenharia do Software I 6
Verificação vs. validaçãoVerificação Estamos a construir
certo o produto?Software tem de cumprir especificação.
Validação Estamos a construir o produto certo?
Software tem de fazer o que utilizador quer.
2009/2010
Engenharia do Software I 7
Processo de verificação e validação Processo de ciclo de vida completo:
aplicado em cada etapa do processo de software
Principais objectivosDescobrir defeitos no sistemaAferir se o sistema é útil e usável em
operação
2009/2010
Engenharia do Software I 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 defeitosTem de ser suficientemente bom para a
utilização pretendidaTipo de utilização determina grau de
confiança necessário
2009/2010
Engenharia do Software I 9
Confiança
Depende de Propósito do sistemaExpectativas do utilizadorAmbiente de marketing
2009/2010
Engenharia do Software I 10
ConfiançaFunção do software Nível de confiança depende de quão
crítico é o software para organização.
Expectativas do utilizador Utilizadores podem ter expectativas baixas relativamente a certos tipos de software.
Ambiente de marketing Lançar produto rapidamente no mercado pode ser mais importante que encontrar defeitos no programa.
2009/2010
Engenharia do Software I 11
Verificações estática e dinâmica
Inspecção de software
Analisar representação estática do sistema para descobrir problemas.
Pode ser complementada por análise de documentação e de código baseada em ferramentas.
Teste de software
Exercitar sistema e observar comportamento do produto.
Sistema executado com dados de teste e comportamento operacional observado.
2009/2010
Verificação estática
Verificação dinâmica
12Engenharia do Software I
Verificação e validação estáticas e dinâmicas
2009/2010
Inspecções de software
Especificação de requisitos
Desenho de alto nível
Especificação formal
Desenho pormenorizado
Programa
ProtótipoTeste de software
Engenharia do Software I 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 14
Tipos de testes
Testes de defeitosDescobrem defeitos do sistemaTeste com sucesso revela presença de
defeito
Testes de validaçãoMostram que software cumpre requisitosTeste com sucesso mostrar que requisito foi
devidamente implementado
2009/2010
Capítulo 23
Engenharia do Software I 15
Teste e depuração
São processos distintosVerificação e validação estabelecem
existência de defeitos em programaDepuração localiza e corrige erros
Depurar envolve formular hipóteses sobre comportamento do programa e testá-las para encontrar erro no sistema
2009/2010
16Engenharia do Software I
Localizar erro
Processo de depuração
2009/2010
Resultados do teste
EspecificaçãoCasos
de teste
Desenhar correcção do erro
Corrigir erro
Testar programa de novo
Engenharia do Software I 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
18Engenharia do Software I
Modelo em V
2009/2010
Especificação de requisitos
Desenho de pormenor
Codificação e teste de módulos e unidades
Testes de aceitação
Testes de integração de subsistemas
Testes de integração de sistema
Serviço
Especificação de sistema
Desenho de sistema
Plano de testes de integração
de subsistemas
Plano de testes de integração de sistemas
Plano de testes de aceitação
Engenharia do Software I 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 20
Plano de teste de softwareProcesso de teste
Descrever principais fases do processo.
Rastreabilidade de requisitos
Utilizadores interessados sobretudo em cumprimento: prever teste individual de requisitos.
Itens testados Especificar produtos do processo de software a testar.
Calendário de testes
Calendarizar testes e afectação de recursos. Ligar a calendário geral de desenvolvimento do projecto.
Procedimento de registo de testes
Executar testes não chega: resultados de testes sistematicamente registados. Possível auditar processo de teste e verificar sua correcta execução.
Requisitos de hardware e software
Indicar ferramentas de software necessárias e utilização do hardware estimada .
Restrições Restrições que afectam processo (falta de pessoal).
2009/2010
Engenharia do Software I 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 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 23
Inspecções e testes Técnicas de verificação complementares
Ambas usadas durante processo de verificação e validação
InspecçõesPodem verificar cumprimento de especificação Não podem verificar cumprimento dos requisitos
reais do clienteNão podem verificar características não funcionais
como desempenho ou usabilidade
2009/2010
Engenharia do Software I 24
Inspecções de programa Abordagem formalizada a revisões
documentais
Destinadas explicitamente a detectar defeitos (e não a corrigi-los)
DefeitosErros lógicosAnomalias 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 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 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
27Engenharia do Software I
Processo de inspecção
2009/2010
Planeamento
Visão global
Preparação individual
Reunião de inspecção
Retrabalho
Seguimento
Engenharia do Software I 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 29
Papéis na inspecçãoAutor ou proprietário
Programador ou designer responsável pela produção do programa ou documento. Responsável por corrigir defeitos descobertos no processo de inspecção.
Inspector Procura erros, omissões e inconsistências em programas e documentos. Pode identificar questões mais genéricas fora do escopo da equipa.
Leitor Apresenta o código ou documento durante a reunião.
Secretário Regista os resultados da reunião.
Presidente ou moderador
Gere o processo e facilita a inspecção. Reporta resultados do processo ao moderador chefe.
Moderador chefe
Responsável pela melhoria do processo de inspecção, pela actualização das listas de verificação, pelo desenvolvimento de normas, etc.
2009/2010
Engenharia do Software I 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çãoNomes de variáveis e constantesTerminação de ciclosLimites de matrizes
2009/2010
Engenharia do Software I 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 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 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 34
Taxa de inspecção
RitmoVisão global: 500 instruções/horaPreparação individual: 125 instruções/horaInspecção: 90-125 instruções/hora
CustoProcesso de inspecção é caroInspecção de 500 linhas exige esforço de 40
humanos hora – cerca de £2800 no Reino Unido (≈ 3260 €)
2009/2010
Engenharia do Software I 35
Análise estática automática Levada a cabo por analisadores estáticos
Analisadores estáticosFerramentas de softwareAnalisam o código fonteTentam descobrir potenciais condições de
erroReportam à equipa de verificação e validaçãoEficazes como auxílio às inspecçõesSuplementam inspecção, não a substituem
2009/2010
36
Verificações da análise estática
Tipo de erro Verificação
Dados Variáveis usadas antes de inicializadasVariáveis declaradas mas nunca usadasDupla atribuição sem utilização intermédiaPossível violações dos limites de matrizesVariáveis não declaradas
Controlo Código inatingívelEntradas incondicionais em ciclos
Entrada/saída Variáveis escritas duas vezes sem atribuição pelo meio
Interface Tipos de argumentos e parâmetros incompatíveisNúmero de argumentos inválidoResultados de funções não usadosFunções e procedimentos não usados
Memória Ponteiros sem atribuiçãoAritmética de ponteiros
2009/2010 Engenharia do Software I
Engenharia do Software I 37
Etapas da análise estáticaFluxo de controlo
Verifica ciclos com múltiplos pontos de entrada ou saída, procura código inatingível, etc.
Utilização de dados
Detecta variáveis por inicializar, variáveis escritas duas vezes sem atribuição intermédia, variáveis declaradas mas nunca usadas, etc.
Interface Verifica consistência da declaração de funções e procedimentos e da sua utilização.
Fluxo de informação
Identifica dependências de variáveis de saída. Não detecta anomalias por si só, mas realça informação para inspecção ou revisão de código.
Caminhos Identifica caminhos ao longo do programa e realça as instruções executadas em cada um deles. Potencialmente útil num processo de revisão.
2009/2010
Usar com cuidado! Geram grande quantidade de
informação.
Usar com cuidado! Geram grande quantidade de
informação.
Engenharia do Software I 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 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 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 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 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 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 emDesenvolvimento incrementalEspecificação formalVerificação estática usa argumentos de correcçãoTestes estatísticos mostram fiabilidade do
programa
2009/2010
44Engenharia do Software I
Processo de sala limpa
2009/2010
Especificar sistema
formalmente
Desenvolver perfil
operacional
Construir programa
estruturado
Verificar formalmente
código
Integrar incremento
Desenhar testes
estatísticos
Testar sistema
integrado
Definir incrementos do software
retrabalho
Engenharia do Software I 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
Capítulo 24
Engenharia do Software I 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 47
Equipas do processo de sala limpaEspecificação Responsável por desenvolver e manter
especificação do sistema.
Desenvolvimento Responsável por desenvolver e verificar software. Software não é executado nem compilado durante este processo.
Certificação Responsável por desenvolver conjunto de testes estatísticos para exercitar software após desenvolvimento. Modelos de crescimento de fiabilidade usados para determinar quando fiabilidade é aceitável.
2009/2010
Engenharia do Software I 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 49
A reter Verificação e validação diferentes
Verificação: conformidade com especificaçãoValidaçã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 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 51
A ler
Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006
Capítulo 22
2009/2010