VV&T

VISÃO GERAL

Prof. Dr. Marcelo Fantinato

Sistemas de Informação, EACH/USP

Visão Geral
 VV&T – Validação, Verificação e Teste:

 Atividades para garantir a qualidade do “produto”

 Verificação: o software está sendo construído corretamente?
 Os métodos e as técnicas foram aplicadas adequadamente?
 Validação: o software correto está sendo construído?
 Os requisitos/desejos do usuário estão sendo satisfeitos?

 V&V:
 Espalhadas por todo o processo de desenvolvimento

 Teste:
 Uma atividade específica de V&V
 Talvez a atividade mais importante/crítica (pelo menos a mais “famosa”)
Objetivos
 Identificar (para se corrigir):
 Defeitos/Erros no software

 Software: qualquer artefato produzido durante o ciclo de desenvolvimento

do software.
 Exemplos:
 Especificações de Requisitos
 Diagramas UML
 Código Fonte
 Código Executável
 Casos de Teste
 Manuais de Usuário

 Preferencialmente, identificar os erros na própria fase em que são

cometidos
 para diminuir custos de reparo
Fases

Análise e Projeto

Implementação
Especificação
de Requisitos
A1 A4 A7 A10 A13

Teste
A2 A5 A8 A11 A14

A3 A6 A9 A12 A15

A19
A16
A17 Gerenciamento de Projeto A20
A18 A21

A22 A25
A23
Documentação de A26
A24 Sistema/Usuário A27
Fases

Análise e Projeto

Implementação
Especificação
de Requisitos
A1 A4 A7 A10 A13
V&V V&V V&V V&V V&V

Teste
A2 A5 A8 A11 A14
V&V V&V V&V V&V V&V

A3 A6 A9 A12 A15
V&V V&V V&V V&V V&V

V&V A19 V&V

A16
V&V A17 Gerenciamento de Projeto A20 V&V
A21 V&V
V&V A18

V&V A22 A25 V&V

V&V A23
Documentação de A26 V&V
V&V A24 Sistema/Usuário A27 V&V
Padronização IEEE (610.12-1990)
 Engano (Mistake):
 Ação humana que produz um resultado incorreto

 Defeito (Fault):
 Passo, processo ou definição de dados incorretos

 Erro (Error):
 Diferença entre o valor obtido e o valor esperado
 Qualquer estado intermediário incorreto ou resultado inesperado na execução do
programa constitui um erro

 Falha (Failure):
 Produção de uma saída incorreta com relação à especificação

Obs.: Aplicada para erros em programas

Padronização IEEE (610.12-1990)

Engano
causa

conseqüência

Defeito
causa

conseqüência

Erro
causa

conseqüência

Falha
Padronização IEEE (610.12-1990)

Engano Depuração

busca/encontra
a presença encontra/corrige
(ele não sabe qual é)
Defeito (ele sabe qual é)

Testador Programador
Erro

evita novas
busca/encontra
(ele sabe qual é)
Falha
Padronização IEEE (610.12-1990)
 Exemplo:

 Especificação: “(...) para idade maior ou igual a 60 anos, fornecer

10% de desconto, senão fornecer apenas 5% de desconto (...)”

 Código: (...)
if idade > 60 then desconto = 10%
else desconto = 5%
(...)
Total = Total * (1 - desconto)
(...)
Receber Total
Finalizar Transação
Padronização IEEE (610.12-1990)

 O que o testador faz quando “pega um erro”?

 Abre uma “Solicitação de correção de defeito”

 Descreve a FALHA observada (que indica a presença de um defeito)
 Opcionalmente, apresenta informações adicionais para ajudar na
identificação do defeito
Padronização IEEE (610.12-1990)

 Português: Software tolerante a falha?

 Deveria ser: Software tolerante a defeitos!

 Inglês (Original): Fault-tolerant software!

 Exemplo de problema com tradução/nomenclatura

Tipos de defeitos de software
 Omissão: informações necessárias não estão presentes no artefato

 Incorreção: informações no artefato contradizem informações da

especificação de requisitos ou o conhecimento de geral do domínio

 Inconsistência: informações em uma parte do artefato estão

inconsistentes com outras informações no mesmo artefato

 Ambigüidade: informações no artefato são ambíguas, isto é,

possibilitam diferentes interpretações aos leitores

 Estranheza: informações presentes no artefato não são

necessárias/usadas

 Inconformidade: informações são apresentadas no artefato fora do

padrão esperado
Classificação de Defeitos da IBM
Dimensão Explicação
Atividade Momento em que o defeito foi encontrado

Gatilho Causa da aparição do defeito

Impacto Descreve os efeitos para o cliente

Alvo Representa qual entidade deve ser corrigida.

Tipo de Descreve a correção necessária

defeito
Qualificador Classifica um defeito: omissão; incorreção; excesso.

Idade Identifica se o defeito foi encontrado em uma entidade que já existia, nova,
reescrita ou re-corrigida
Fonte Identifica se o componente contendo o defeito foi produzido dentro da empresa,
se foi reusado de outro projeto, se foi adaptado tendo sido implementado para
outro ambiente,ou se foi adquirido de terceiros
Classificação de Defeitos na HP
 Origem: Onde?
 Especificação de Requisitos

 Projeto

 Código

 Ambiente/Suporte

 Documentação

 Outros
Classificação de Defeitos na HP
 Tipo: O que?
 Requisitos ou Especificações, Funcionalidade

 Interface de HW, Interface de SW, Interface com Usuário, Descrição

Funcional

 Comunicação entre processos, Definição de dados, Projeto de módulos,

Descrição lógica, Verificação de erros, Normas

 Lógica, Computação, Manipulação de dados, Implementação e interface

módulos, Padrões

 Teste de HW, Teste de SW, Integração de Software, Ferramentas de

Desenvolvimento
Classificação de Defeitos na HP
 Modo: Por que?
 Omissão

 Obscuro

 Erro

 Melhoramento

 Modificação
V ou V?
 Verificação: o artefato foi elaborado corretamente?
 Aderência do artefato a padrão/regras/procedimentos definidos
 Completude, precisão, consistência/coerência
 Pode ser independente do desejo do usuário

 Validação: o artefato elaborado representa realmente o software

desejado?
 Existência de elementos
 Deve ser dependente do desejo do usuário

 Análise Sintática X Análise Semântica

 Sintática: Verificação
 Semântica: Validação
Atividades V&V
 Análise Estática:
 Não envolve a execução propriamente dita do artefato
 Aplicável a qualquer artefato intermediário do ciclo de desenvolvimento
 Exemplos:
 Para uma máquina de estados: verificar a consistência do modelo - se não há estados
mortos (além do estado terminal), se não há estados sem nomes, se não há transições
inconsistentes ou incoerentes, se não há estados/transições ausentes etc
 Para um projeto de GUI: verificar se o projeto segue um determinado padrão institucional

 Análise Dinâmica:
 Envolve a execução do produto – o código propriamente dito ou alguma
especificação executável
 Aplicável a artefatos intermediários/finais executáveis
 Exemplos:
 Para uma máquina de estados: simular seu funcionamento
 Para um projeto de GUI: simular a navegação
Atividades V&V
 Análise Estática:
 Revisões Formais: exemplo mais clássico
 Revisão Técnica: executada por membros de outras fases/equipes
 Inspeção / Revisão por pares: executada por membros de mesma fase/equipe
 Exemplo paralelo: inspeção de um automóvel

 Vantagem: Custo
 Desvantagem: Descentralização

 Análise Dinâmica:
 Teste de software: exemplo mais clássico
 Teste de unidade, teste de integração, teste de sistema
 Testes funcionais (caixa preta) e Testes estruturais (caixa branca)
 Testes de funcionalidade, de desempenho, de segurança, de carga, de confiabilidade etc
 Vantagem: Centralização
 Desvantagem: Custo
Inspeção
 Provadas como um técnica eficaz de detecção de defeitos
 Mais barato que testes de software
 equipe de inspeção com quatro pessoas, inspecionar cem linhas de código =
uma pessoa/dia
 Possivelmente metade do esforço em teste para detectar a presença dos

 Possibilidade de detectar a presença de defeitos:

 Inspeção Informal: 60% dos defeitos
 Inspeção Formal: 90% dos defeitos

 Início: inspeção em programas, IBM – década de 70

 Ferramenta de apoio: Checklist (específica para cada fase/artefato)

Inspeção
 Possibilidade de automação
 Verificadores de anomalias

 Exemplos:
 Máquina de estados finitos:
 Código fonte: variáveis não iniciadas ou usadas
Atividade em grupo
 Fazer uma análise do ciclo de vida de desenvolvimento de software
e de atividades de V&V:
 Quais artefatos são gerados, em cada fase?
 Relembrar ciclos de vida em cascata, espiral/incremental,RUP etc

 Para cada um destes artefatos, para quais deles seria

apropriado/adequado/vantajoso ter atividades de V&V?
 Quais seriam as atividades de V&V para cada artefato?

 Depois de completo, definir uma seqüência de prioridades das atividades

de V&V, caso nem todas possam ser implementadas.

 Dica: faça uma tabela (fase, artefato de saída, necessidade de V&V,

atividade/técnica de V&V, prioridade)

 Informação adicional: deve ser entregue no final da aula!

Referências
 Qualidade de Software – Teoria e Prática
Ana Regina C da Rocha, José Carlos Maldonado, Kival Chaves Weber
Pearson – Prentice Hall
Seções: 3.4 e 3.6

 Engenharia de Software
Ian Sommerville
6ª Edição
Addison Wesley
Capítulo:19