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

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

Engenharia de Software

Verificação e Validação


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


Verificação x Validação

• Verificação:

Estamos construindo corretamente o produto?

• Validação:

Estamos construindo o produto correto?


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


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


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


O Processo de Depuração

Resultadosdos testes

Resultadosdos testes

Testar novamenteo programa

Testar novamenteo programa

EspecificaçãoEspecificação Casos de testeCasos de teste

Localizar ErroLocalizar Erro Projetar o conserto

Projetar o conserto Consertar o erroConsertar o erro


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)


Planejamento dos testes

Especificação dosrequisitos

Especificação dosrequisitos

Especificação dosistema

Especificação dosistema

Projeto dosistema

Projeto dosistema Projeto detalhado

Projeto detalhado

Codificação de Módulos e unidades

e teste

Codificação de Módulos e unidades

e teste

Teste de aceitaçãoTeste de aceitação Teste de integração

do sistema

Teste de integraçãodo sistema

Teste de integraçãodos subsistemas

Teste de integraçãodos subsistemas

Serviço

Plano de teste de aceitação

Plano de testes de integração do

sistema

Plano de testes de integração do

sub-sistemas


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


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


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


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


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


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


O processo de inspeção

Inspectionmeeting

Individualpreparation

Overview

Planning

Rework

Follow-up


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


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


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.


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


Análise Estática Automática

• Ferramentas para analisar código fonte tentando encontrar erros potenciais

• Auxiliam mas não substituem as inspeções


Análise Estática Automática

Classes de Erros Análise EstáticaErros 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


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


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.


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.c140% lint lint_ex.c

lint_ex.c(10): warning: c may be used before setlint_ex.c(10): warning: i may be used before setprintarray: 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


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...

Documents

Transcript of Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...