Verificação e Validação

Transcrição

1 Verificação e Validação Patrícia Macedo Joaquim Filipe João Ascenso 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? 1

2 Garantir a qualidade... Garantir que cada uma das qualidades do software é alcançada: Os objectivos são definidos na especificação dos requisitos São alcançados na implementação Por vezes fácil, por vezes difícil Portabilidade vs segurança Por vezes imediata, por vezes necessita de mais tempo: Compreensão vs evolutibilidade Por vezes fácil de provar, por vezes difícil Dimensão vs correcção O processo ideal Especificação formal completa do problema a resolver Desenho, em notação formal Código, numa linguagem verificável Código de máquina executável Execução em hardware verificável Transformação que preserva a correção Transformação que preserva a correção Transformação que preserva a correção Transformação que preserva a correção 2

3 O que realmente se passa... Mistura de especificações formais e informais Desenho, em notação semi-formal Código, em C++, Java, Ada, Código máquina Pentium Execução em hardware comercial Transformação manual Transformação manual Compilação por um compilador comercial Firmware comercial 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 3

4 Segundo problema Comunicações de dados complexa E.g. Transferência de fundos electrónica Processamento distribuído E.g. Motor de procura www Objectivos de desempenho exigentes 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 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 4

5 Quarto problema Regras para garantir a qualidade... Deve-se verificar o código todos os dias Deve-se comentar o código Deve-se Garantir a qualidade deve descobrir as falhas Responsabiliza os programadores Cria uma imagem de competição Garantir a qualidade é encarada de uma forma negativa Deixa-me apenas programar... 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 5

6 Terminologia Fracasso (failure) Saída incorrecta ou não esperada Sintoma de uma falha Falha (fault) 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) 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] 6

7 Níveis de Teste e o modelo de desenvolvimento de software (reprinted) Execute acceptance tests Specify Requirements (revisited) Design Code Requirements review Design review Specify/Design System/acceptance test plan & test cases review/audit Code Specify/Design System/acceptance tests Integration test plan & test cases review/audit Code Specify/Design Integration tests Code reviews Execute unit tests Unit test plan & test cases review/audit Code Unit tests Execute system tests Execute integration tests (source: I. Burnstein, pg.15) 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 7

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

9 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. Tarefas da fase de teste Elaborar test cases A áreas especifícas do sistema Especificar entradas Criar as saídas desejadas Escolher test cases Nem todos precisam de ser executados simultâneamente Executar os test cases De uma forma sistemática, repetível, e precisa 9

10 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 Planeamento dos testes Software project (management) plan (note: for many authors, QA V&V) (adapted from: Ilene Burnstein, Practical Software Testing) 10

11 Documentos de Especificação de testes 1. Documento de especificação dos Testes de Aceitação 2. Documento de especificação detestes do Sistema 3. Documento de especificação de Testes de Integração 4. Documento de especificação de Testes Unitários Conteudo do Documento de Especificação de Testes 1. Identificador do plano 2. 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 11

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