Engenharia de Software Verificação e Validação Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Verificação e Validação Assegurar que um Sistema de Software cumpra as especificações e atenda às necessidades do usuário. É um processo de ciclo de vida completo: Revisão de Requisitos Revisão de Projeto Inspeção de Código Teste do Produto Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Verificação x Validação Verificação: Estamos construindo corretamente o produto? Validação: Estamos construindo o produto correto? Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

O Processo de V&V Processo contínuo: deve ser aplicado a todas as fases do desenvolvimento Objetivos principais: Descobrir defeitos no sistema Descobrir se o sistema é usável em uma situação operacional Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Meta de V&V Estabelecer a confiança de que o software é adequado ao seu propósito. NÃO significa que o sistema não tenha defeitos: Deve ser suficientemente bom para o seu uso O grau de certeza exigido depende do tipo e do uso do sistema Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Teste e Depuração Processos distintos V&V: estabelecer a existência de erros Depuração: Localizar e consertar os erros Formular uma hipótese sobre o comportamento do sistema e testar a hipótese para encontrar o erro Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

O Processo de Depuração Resultados dos testes Especificação Casos de teste Localizar Erro Projetar o conserto Consertar o erro Testar novamente o programa Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Planejamento de V&V Planejar para tirar o máximo dos processos de teste e inspeção Planejamento deve começar cedo Deve balancear verificação estática e testes Plano de testes define padrões para o processo de testes (como testar e não o que testar) Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Planejamento dos testes Especificação dos requisitos Especificação do sistema Projeto do sistema Projeto detalhado Codificação de Módulos e unidades e teste Plano de teste de aceitação Plano de testes de integração do sistema Plano de testes de integração do sub-sistemas Serviço Teste de aceitação Teste de integração do sistema Teste de integração dos subsistemas Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

O Plano de Teste de Software Processo de Teste Rastreabilidade dos requisitos Itens de teste Cronograma de testes Procedimentos para registrar os testes Requisitos de hardware e software Restrições Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Inspeções e Testes Complementares Ambos devem ser usados no processo de V&V Inspeções podem verificar conformidade com uma especificação mas não com os requisitos reais do usuário Inspeções não podem verificar requisitos não-funcionais Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Inspeções de software Envolve pessoas examinando a representação do sistema com o objetivo de descobrir anomalias e defeitos Não requer a execução do sistema, então pode ser utilizada antes da implementação Pode ser aplicada a qualquer representação do sistema (requisitos, projeto, dados de teste, etc.) Técnica muito efetiva para descobrir erros Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Sucesso das inspeções Muitos defeitos diferentes podem ser descobertos em uma única inspeção. Nos testes, um defeito pode mascarar outros, então são necessárias muitas execuções. Conhecimento do domínio da aplicação e da linguagem de programação pode ajudar a identificar erros que são freqüentemente cometidos Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Inspeções de programas Abordagem formal para revisão de documentos Tem como objetivo a detecção (não a correção) de defeitos Defeitos podem ser erros lógicos, anomalias no código que possam indicar uma condição de erro (ex: uma variável não inicializada) ou não-conformidade com padrões Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Pré-condições para inspeção Uma especificação precisa deve estar disponível Os membros da equipe devem estar familiarizados com os padrões da organização Um código sintaticamente correto deve ser disponibilizado Um checklist deve estar preparado Os gerentes devem aceitar que as inspeções irão aumentar os custos em determinado momento do processo Os gerentes não devem usar as inspeções para avaliação da equipe Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

O processo de inspeção Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Procedimento de inspeção Visão geral do sistema é apresentada para a equipe de inspeção Código e documentos associados são distribuídos para a equipe com antecedência A inspeção ocorre e os erros são anotados Modificações são realizadas para consertar os erros descobertos Uma reinspeção pode ser necessária ou não Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Equipes de inspeção Compostas de pelo menos 4 membros (nota do professor: isso é questionável!!) Autor do código a ser inspecionado Inspetor que encontra erros, omissões e inconsistências Leitor que lê o código para a equipe Moderador que coordena a reunião e anota os erros cometidos Outros papéis: escriba e moderador-chefe Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Checklists de inspeção Checklists comos erros mais comuns devem ser utilizados para guiar as inspeções Checklists de erros são dependentes da linguagem de programação Quanto mais fraca a checagem de tipos, maior o checklist Exemplos: inicialização, nomeação de constantes, terminação de loops, limites de arrays, etc. Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Taxas de inspeção 500 linhas/hora durante a visão geral 125 linhas de código/hora durante a preparação individual 90-125 linhas/hora podem ser inspecionadas Inspeção é, portanto, um processo caro Inspecionar 500 linhas custa cerca de 40 pessoas/hora Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Análise Estática Automática Ferramentas para analisar código fonte tentando encontrar erros potenciais Auxiliam mas não substituem as inspeções Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Análise Estática Automática Classes de Erros Análise Estática Erros de Dados Variáveis utilizadas antes de inicialização Variáveis declaradas e nunca usadas Variáveis atribuídas 2 vezes e nunca utilizada entre as duas atribuições Possíveis violações dos limites de um array Variáveis não declaradas Erros de Controle Código não executável Condicionais com mais de uma condição Falhas de entrada/saída Saída da mesma variável duas vezes sem alteração. Falhas de interface Erro de tipo de parâmetros Erro de número de parâmetros Resultados de funções não utilizados Funções e procedimentos nunca chamados. Falhas de gerenciamento de memória Ponteiros não atribuídos Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Estágios da análise estática Análise do fluxo de controle: Verifica loops com múltiplas saídas e entradas, encontra códigos inalcançáveis, etc. Análise de uso de dados: Detecta variáveis não inicializadas, variáveis declaradas duas vezes sem uso intermediário, variáveis declaradas mas nunca usadas, etc. Análise de interface: Verifica a consistência das declarações e uso de procedimentos Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Estágios da análise estática Análise dos fluxos de informação: Identifica as dependências entre variáveis. Não detecta anomalias, mas serve de insumo para as inspeções de código Análise de caminho: Identifica caminhos através do programa e verifica os comandos executados em cada caminho. Também serve de insumo para as inspeções de código. Esses dois últimos estágios geram muita informação, então devem ser usados com cuidado. Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

LINT static analysis 138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored LINT static analysis Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Uso de análise estática 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 Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho