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
Localizar Erro
Especificação
Projetar o
conserto
Casos de teste
Consertar o erro
Faculdade 7 de Setembro – Sistemas de Informação
Engenharia de Software – Prof. Ciro Coelho
Testar novamente
o programa
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
Plano de teste
de aceitação
Serviço
Projeto do
sistema
Plano de testes
de integração do
sistema
Teste de aceitação
Projeto detalhado
Plano de testes
de integração do
sub-sistemas
Teste de integração
do sistema
Codificação de
Módulos e unidades
e teste
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ãoconformidade 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
Planning
Overview
Follow-up
Individual
preparation
Rework
Inspection
meeting
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
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 static analysis
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
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