Verificação e Validação Verificação e Validação

Verificação e Validação
Patrícia Macedo
Joaquim Filipe
João Ascenso
Engenharia de Software 2005/2006
EST, Setúbal
Verificação e Validação
„
Verificação
„
„
„
„
Garante que o software cumpre as especificações
Consistência interna
“Estamos a construir o produto de uma forma
adequada ?”
Validação
„
„
„
Garante que o software vai ao encontro das
necessidades do utilizador
Consistência externa
“Estamos a construir o produto certo ?”
Engenharia de Software
1
Garantir a qualidade...
„
Garantir que cada uma das qualidades do software é
alcançada:
„
„
„
Por vezes fácil, por vezes difícil
„
„
Portabilidade vs segurança
Por vezes imediata, por vezes necessita de mais tempo:
„
„
Os objectivos são definidos na especificação dos requisitos
São alcançados na implementação
Compreensão vs evolutibilidade
Por vezes fácil de provar, por vezes difícil
„
Dimensão vs correcção
Engenharia de Software
O processo ideal
Especificação formal completa
do problema a resolver
Transformação que preserva a correção
Desenho, em notação formal
Transformação que preserva a correção
Código, numa linguagem verificável
Transformação que preserva a correção
Código de máquina executável
Transformação que preserva a correção
Execução em hardware verificável
Engenharia de Software
2
O que realmente se passa...
Mistura de especificações
formais e informais
Transformação manual
Desenho, em notação semi-formal
Transformação manual
Código, em C++, Java, Ada, …
Compilação por um compilador comercial
Código máquina Pentium
Firmware comercial
Execução em hardware comercial
Engenharia de Software
Primeiro problema
Necessidades
Especificação
actual
Especificação
“correcta”
Por muito mais sofisticado que seja o processo de teste, o
problema de criar a especificação inicial persiste
Engenharia de Software
3
Segundo problema
„
Comunicações de dados complexa
„
„
Processamento distribuído
„
„
E.g. Motor de procura www
Objectivos de desempenho exigentes
„
„
E.g. Transferência de fundos electrónica
E.g. Sistema de controlo de tráfego aéreo
Processamento complexo
„
E.g. Sistema de diagnóstico médico
Por vezes, o sistema de software é extremamente
complicado, tornando o processo de teste díficil de realizar
Engenharia de Software
Terceiro Problema
Gestão de Projectos
Grupo que
garante a qualidade
Grupo de
desenvolvimento
É díficil dividir as responsabilidades entre o grupo de
desenvolvimento e o grupo que garante a qualidade
Engenharia de Software
4
Quarto problema
„
Regras para garantir a qualidade...
„
„
„
„
Garantir a qualidade deve descobrir as falhas
„
„
„
Deve-se verificar o código todos os dias
Deve-se comentar o código
Deve-se …
Responsabiliza os programadores
Cria uma imagem de “competição”
Garantir a qualidade é encarada de uma forma
negativa
„
“Deixa-me apenas programar...”
Engenharia de Software
Teste de software
„
Testar um módulo, uma conjunto de
módulos ou um sistema
„
„
„
„
„
Utilizar entradas predeterminadas (“test case”)
Capturar a saída
Comparar a saída com a saída esperada
Saída actual igual à esperada => sucesso
Saída actual diferente da esperada => erro
Engenharia de Software
5
Terminologia
„
Fracasso (failure)
„
„
„
Falha (fault)
„
„
„
„
Saída incorrecta ou não esperada
Sintoma de uma falha
Estado de execução inválido
Sintoma de um erro
Poderá produzir um fracasso (ou não)
Erro (error)
„
„
„
Defeito ou anomalia do código fonte
Também é referido como um “bug”
Poderá produzir uma falha (ou não)
Engenharia de Software
Objectivos da fase de teste
„
Revelar fracassos/falhas/erros
„
Localizar fracassos/falhas/erros
„
Mostrar a correcção do sistema
„
Dentro dos limites de precisão
„
Melhorar a confiança que o sistema possui um
comportamento igual ao especificado (verificação)
„
Melhorar a confiança que o sistema faz ou realiza o
desejado (validação)
A fase de teste pode ser utilizada para mostar a
presença de erros, mas
nunca
a sua ausência [Dijkstra]
Engenharia
de Software
6
Níveis de Teste e o modelo de desenvolvimento de
(reprinted)
software
Execute
acceptance tests
Specify
Requirements
Execute
system tests
System/acceptance
Requirements
test plan & test cases
review
review/audit
Specify/Design
Code
System/acceptance tests
Execute
integration tests
Design
Integration
Design
test plan & test cases
review
review/audit
Specify/Design
Code
Integration tests
Execute
unit tests
Code
Code
reviews
(revisited)
Specify/Design
Unit
test plan & test cases
review/audit
Unit tests
Code
(source: I. Burnstein,
pg.15)
Engenharia de Software
Testes unitários
„
„
„
„
(reprinted)
Teste de unidades de programa ou de
componentes
Usualmente da responsabilidade do
programador.
Testes são baseados no código e nas
especificações das unidades
O principal objectivo é detectar defeitos
funcionais e estruturais nas unidades
Engenharia de Software
7
Teste de Integração
„
„
„
„
Testa grupos de componentes integrados
para criar um sub-sistema.
Usualmente da responsabilidade de uma
equipa independente de testes.
Testes são baseados na especificação do
sistema (design)
O principal objectivo é detectar falhas nas
interfaces entre as unidades.
Engenharia de Software
Teste de sistema
„
„
„
„
Testar o sistema como um todo
Usualmente da responsabilidade de uma equipa
independente
Testes são baseados no documento de especificação
de requisitos.
O principal objectivo é avaliar os atributos de
qualidade. (parte-se do principio que os requisitos
funcionais foram testados nos atestes unitarios e de
integração)
Engenharia de Software
8
Testes de Aceitação
„
„
„
„
Testar o sistema como um todo
Usualmente da responsabilidade do cliente
Os testes são baseados na especificação de
requisitos e no manual do utilizador.
O principal objectivo é verificar se o produto
desenvolvido vai de encontro às expectativas
do utilizador.
Engenharia de Software
Tarefas da fase de teste
„
Elaborar “test cases”
„
„
„
„
Escolher “test cases”
„
„
A áreas especifícas do sistema
Especificar entradas
Criar as saídas desejadas
Nem todos precisam de ser executados
simultâneamente
Executar os “test cases”
De uma forma sistemática, repetível, e precisa
Engenharia de Software
9
Duas abordagens
„
Teste “White Box”
„
„
„
„
„
Teste estrutural
Desenho e selecção dos “test cases”, execução
baseada na estrutura do código fonte
Escala: testa os detalhes específicos
Desvantagens: necessita do código fonte
Teste “Black box”
„
„
„
„
Teste baseado na especificação
Desenho e selecção dos “test cases”, execução
baseada nas especificações
Escala: Testa o comportamento geral do sistema
Desvantagem: Menos sistemático
Engenharia de Software
Planeamento dos testes
Software project (management) plan
(note: for many
authors, QA ≠ V&V)
(adapted from: Ilene Burnstein, Practical Software Testing)
Engenharia de Software
10
Documentos de Especificação de
testes
Documento de
de Aceitação
Documento de
Sistema
Documento de
de Integração
Documento de
Unitários
1.
2.
3.
4.
especificação dos Testes
especificação deTestes do
especificação de Testes
especificação de Testes
Engenharia de Software
Conteudo do Documento de Especificação
de Testes
1.
2.
Identificador do plano
Introdução (porque)
„
Descrição geral do sistema a ser testado e/ou das
suas unidades
„
Descrição geral dos objectivos dos testes e das
tecnicas utilziadas
3. Items a serem testados (o quê)
„
Lista de itens a serem testados : procedimentos,
classes, modulos, bibliotecas, componentes
sistemasetc
„
Incluir referencias para os documentos onde estes
items e seus comportamentos são descritos
(documento de especificaçaõd e requisitos e de
desenho, manuais de utilizador etc)
„
Listar também os items que não são testados
Engenharia de Software
11
Conteudo do Documento de Plano de Testes
4. Caracteristicas a serem testadas (o quê)
„
Caracteristicas funcionais e de qulaidade a sere
testadas
„
Lista das caracteristicas a não serem testadas
5. Aproximação (como)
„
Descrição dos vários tipos de teste a aplicar
„
Para cada caracteristica indicar que tipo de teste se
irá realizar
„
Indicar as ferramentas e técnicas que vãos er
aplicadas.
„
Constragimentos (tempo, dinheiro)
6. Ambiente de teste
„ Software e hardware necessários
Engenharia de Software
Conteúdo do Documento de Plano de Testes
7.
Responsabilidades
ƒ Funções e responsabilidade de cada teste.
8. Escalonamento (scheduling)
ƒ Duração de cada tarefa e instante de conclusão
9. Riscos e contigencias
ƒ Os riscos devem ser identificados e avaliados
10. Custos dos testes
„ Custos divididos por tipo de Custos (custos de
palneamento, de concepção, de implementação)
11. Aprovações
„ Datas e assinaturas de quem é responsavel por
aprovar so testesResponsabilidades
Engenharia de Software
12