Validação e Testes de Software - MOD1
Upcoming SlideShare
Loading in...5
×
 

Validação e Testes de Software - MOD1

on

  • 11,951 views

Este material pertence ao Professor Manuel Mendonça e está disponível para Download no site do DCC da UFBA.

Este material pertence ao Professor Manuel Mendonça e está disponível para Download no site do DCC da UFBA.

Statistics

Views

Total Views
11,951
Views on SlideShare
6,530
Embed Views
5,421

Actions

Likes
3
Downloads
518
Comments
0

14 Embeds 5,421

http://www.portalgsti.com.br 4046
http://testesdesoftware.blogspot.com.br 690
http://testesdesoftware.blogspot.com 584
http://feeds.feedburner.com 33
url_unknown 30
http://testesdesoftware.blogspot.pt 13
http://www.testesdesoftware.blogspot.com.br 9
http://www.testesdesoftware.blogspot.com 8
http://translate.googleusercontent.com 2
http://191612280685791701_19317d95a3f85ba36cff0bbfd1b451ec53699a91.blogspot.com 2
http://webcache.googleusercontent.com 1
http://testesdesoftware.blogspot.co.uk 1
https://www.google.com.br 1
http://www.testesdesoftware.blogspot.pt 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Validação e Testes de Software - MOD1 Validação e Testes de Software - MOD1 Presentation Transcript

    • Validação de Software Professor Manoel MendonçaValidação de Software – Módulo 1 Conceitos Básicos Transparência 1
    • Sobre a DisciplinaValidação de Software – Módulo 1 Conceitos Básicos Transparência 2
    • Técnicas para Avaliação da Qualidade de Produtos Testes Revisões Provas FormaisValidação de Software – Módulo 1 Conceitos Básicos Transparência 3
    • Instrutor • Manoel Mendonça – Sala IM 215 – Tel. 3283-6343 – Horário para alunos – quarta à tarde – manoel.mendonca@ufba.brValidação de Software – Módulo 1 Conceitos Básicos Transparência 4
    • Site da Disciplina • ...Validação de Software – Módulo 1 Conceitos Básicos Transparência 5
    • Bibliografia A Practitioners Guide to Software Test Design by Lee Copeland ISBN:158053791x Artech House © 2004 http://www.opensourcetesting.orgValidação de Software – Módulo 1 Conceitos Básicos Transparência 6
    • Avaliações • Trabalhos, dois trabalhos • Provas, uma ou duasValidação de Software – Módulo 1 Conceitos Básicos Transparência 7
    • Plataforma de Trabalho • Java e Eclipse • JUnit • Outras ferramentasValidação de Software – Módulo 1 Conceitos Básicos Transparência 8
    • 0. Conceitos BásicosValidação de Software – Módulo 1 Conceitos Básicos Transparência 9
    • 0.1 Defeitos e Falhas • Defeito – um problema nos requisitos, no projeto, no código, na documentação ou nos casos de teste • Falha – um problema no funcionamento do sistema Falha: conseqüência de um defeitoValidação de Software – Módulo 1 Conceitos Básicos Transparência 10
    • Defeitos e Falhas: Uma Visão Mais Completa Engano (mistake) => “erro” cometido “cabeça” do eng. de software Defeito (fault) => “erro” inserido no software Erro (error) => “execução” do “erro” conduzindo a um estado incorreto do software Falha (failure) => manifestação externa do “erro”Validação de Software – Módulo 1 Conceitos Básicos Transparência 11
    • Principais Artefatos de Software Uma Visão Simplificada Especificação Projeto Código de requisitos Defeitos ocorrem em todos eles !!!Validação de Software – Módulo 1 Conceitos Básicos Transparência 12
    • Defeitos Introduzidos ao Longo do Processo de Desenvolvimento • A maior parte é de origem humana. • São gerados na comunicação e na transformação de informações. • Permanecem presentes nos diversos produtos de software produzidos e liberados. • A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas.Validação de Software – Módulo 1 Conceitos Básicos Transparência 13
    • 0.2 Alguns Tipos de Defeitos Introduzidos Tipo de Descrição Geral DefeitoOmissão Informação necessária do sistema foi omitida do artefato de software.Fato Incorreto Alguma informação no artefato de software contradiz informação do documento de outra informação no artefato de software.Inconsistência Informação contida em uma parte do artefato de software está inconsistente com outra informação no artefato de software.Ambigüidade Informação contida no artefato de software é ambígua, isto é, várias interpretações podem ser derivadas da definição levando o desenvolvedor à implementação correta.Informação Informação que é fornecida e não é necessária ou nuncaEstranha utilizadaValidação de Software – Módulo 1 Conceitos Básicos Transparência 14
    • Tipos de Defeitos Introduzidos Copyright Guilherme Travassos COPPE/UFRJ – 2003 - http://www.cos.ufrj.br/~ght De onde os defeitos vêm? Que defeitos podemos encontrar? Outro Domínio Conhecimento do domínio Requisitos Fato incorreto Gerais Informação estranha Artefatos de Omissão Software Inconsistência AmbigüidadeValidação de Software – Módulo 1 Conceitos Básicos Transparência 15
    • Defeitos Introduzidos ao Longo do Processo de Desenvolvimento • Principal causa: • tradução incorreta de informações. • Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente. • Solução: • Introduzir atividades de V V & T ao longo de todo o ciclo de desenvolvimento.Validação de Software – Módulo 1 Conceitos Básicos Transparência 16
    • 0.3 Verificação e Validação (V&V) As atividades de avaliação de produtos são parte do tema chamado Verificação e Validação (V&V). A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA).Validação de Software – Módulo 1 Conceitos Básicos Transparência 17
    • Verificação refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica. “Estamos construindo certo o produto?”Validação de Software – Módulo 1 Conceitos Básicos Transparência 18
    • Validação refere-se ao conjunto de atividades que garante que o software que foi construído é “rastreável” às exigências do cliente. “Estamos construindo o produto certo?”Validação de Software – Módulo 1 Conceitos Básicos Transparência 19
    • 0.4 Garantia da Qualidade de Software – Métodos de Engenharia de Software: proporcionam a base a partir da qual a qualidade é construída. – Revisões Técnicas Formais: ajudam a garantir a qualidade do produto produzido como uma conseqüência de cada passo da engenharia de software. – Medição: ajudam a controlar cada elemento da configuração de software.Validação de Software – Módulo 1 Conceitos Básicos Transparência 20
    • Garantia da Qualidade de Software (cont.) – Padrões e Procedimentos: ajudam a garantir a uniformidade. – Garantia de Qualidade de Software (SQA): põe em prática uma filosofia de qualidade total. – Teste: a qualidade pode ser avaliada.Validação de Software – Módulo 1 Conceitos Básicos Transparência 21
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 22
    • Teste de SoftwareValidação de Software – Módulo 1 Conceitos Básicos Transparência 23
    • Teste 1 Introdução 2 Contexto 3 Organização para Realização de Testes 4 Executando Teste 5 Depurando Software 6 Técnicas de TesteValidação de Software – Módulo 1 Conceitos Básicos Transparência 24
    • 1. Introdução 1.1 Engenharia de Software e Teste 1.2 O quê é teste 1.3 Objetivos da Atividade de Teste 1.4 Erros e as atividades de testeValidação de Software – Módulo 1 Conceitos Básicos Transparência 25
    • 1.1 Engenharia de Software e Teste 1- Fase de Definição ("o que") - Análise do sistema - Planejamento do projeto de software - Análise de requisitos 2- Fase de Desenvolvimento ("como") - Projeto de software - Codificação - Realização de testes 3- Fase de Manutenção ("alterações")Validação de Software – Módulo 1 Conceitos Básicos Transparência 26
    • 1.2 O Quê é Teste 1. a atividade de teste é o processo de executar um programa com a intenção de descobrir um erro 2. um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto 3. um teste bem-sucedido é aquele que revela um erro ainda não descoberto.Validação de Software – Módulo 1 Conceitos Básicos Transparência 27
    • 1.3 Objetivos da Atividade de Teste Objetivo: projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço razoável. Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software. • A atividade de teste não pode mostrar a ausência de bugs. • Ela só pode mostrar se defeitos de software estão presentes.Validação de Software – Módulo 1 Conceitos Básicos Transparência 28
    • 1.4 Erros e as Atividades de Teste Se erros graves forem encontrados com regularidade, isto implica que a qualidade e a confiabilidade de software são suspeitas. Se erros facilmente corrigíveis forem encontrados, isto implica que a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves Se não for encontrado erro isto implica que a configuração de teste não foi suficientemente elaborada e erros estão escondidos no softwareValidação de Software – Módulo 1 Conceitos Básicos Transparência 29
    • 1.5 O Processo de TesteValidação de Software – Módulo 1 Conceitos Básicos Transparência 30
    • 2. Contexto 2.1 Princípios Básicos 2.2 Estratégia de Teste 2.3 Verificação e Validação 2.4 Garantia de Qualidade de SoftwareValidação de Software – Módulo 1 Conceitos Básicos Transparência 31
    • 2.1 Princípios Básicos Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado sistematicamente. - o planejamento e a realização das atividades de teste definem a estratégia de testes de software. - uma estratégia de teste de software define técnicas de projeto de casos de teste e métodos de teste específicos para cada etapa do processo de engenharia de software.Validação de Software – Módulo 1 Conceitos Básicos Transparência 32
    • 2.2 Estratégia de Teste de Software Uma Estratégia de Teste deve acomodar testes de baixo nível e testes de alto nível, deve oferecer orientação ao profissional, deve oferecer um conjunto de marcos de referência ao administrador e deve ser mensurável.Validação de Software – Módulo 1 Conceitos Básicos Transparência 33
    • Características das Estratégias de Teste (a) – a atividade de teste inicia-se no nível de módulos e prossegue "para fora", na direção da integração de todo o sistema – diferentes técnicas de teste são apropriadas a diferentes pontos de tempo. – a atividade de teste é realizada pela equipe de desenvolvimento do software e para grandes projetos por um grupo de teste independente.Validação de Software – Módulo 1 Conceitos Básicos Transparência 34
    • Características das Estratégias de Teste (b) – as atividades de teste e de depuração são atividades diferentes, mas a depuração deve ser acomodada em qualquer estratégia de teste. – deve oferecer um conjunto de marcos de referência ao administrador e deve ser mensurável.Validação de Software – Módulo 1 Conceitos Básicos Transparência 35
    • 2.3 Verificação e Validação (V&V) A atividade de teste de software é um elemento de um tema mais amplo chamado Verificação e Validação (V&V). A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA).Validação de Software – Módulo 1 Conceitos Básicos Transparência 36
    • Verificação refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica. “Estamos construindo certo o produto?”Validação de Software – Módulo 1 Conceitos Básicos Transparência 37
    • Validação refere-se ao conjunto de atividades que garante que o software que foi construído é “rastreável” às exigências do cliente. “Estamos construindo o produto certo?”Validação de Software – Módulo 1 Conceitos Básicos Transparência 38
    • 2.4 Garantia da Qualidade de Software – Métodos de Engenharia de Software: proporcionam a base a partir da qual a qualidade é construída. – Revisões Técnicas Formais: ajudam a garantir a qualidade do produto produzido como uma conseqüência de cada passo da engenharia de software. – Medição: ajudam a controlar cada elemento da configuração de software.Validação de Software – Módulo 1 Conceitos Básicos Transparência 39
    • Garantia da Qualidade de Software (cont.) – Padrões e Procedimentos: ajudam a garantir a uniformidade. – Garantia de Qualidade de Software (SQA): põe em prática uma filosofia de qualidade total. – Teste: a qualidade pode ser avaliada.Validação de Software – Módulo 1 Conceitos Básicos Transparência 40
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 41
    • 3. Organização para Realização de Testes 3.1 Desenvolvedores x Testadores 3.2 Como as pessoas vêem os testes 3.3 O Grupo Independente de Teste 3.4 Etapas do Teste de Software 3.5 Critérios para Conclusão de TestesValidação de Software – Módulo 1 Conceitos Básicos Transparência 42
    • 3.1 Desenvolvedores x Testadores Quando o teste se inicia há um conflito de interesses: –Desenvolvedores: interesse em demonstrar que o programa é isento de erros. –Responsáveis pelos testes: interesse em mostrar que o programa tem erros.Validação de Software – Módulo 1 Conceitos Básicos Transparência 43
    • 3.2 Como as Pessoas Vêem os Testes Do ponto de vista psicológico, as pessoas vêem os testes com uma tarefa destrutiva: • Análise, Projeto e Codificação de Software são tarefas construtivas • Teste é tarefa destrutiva pois visa descobrir problemasValidação de Software – Módulo 1 Conceitos Básicos Transparência 44
    • 3.3 Grupo Independente de Teste Para suprir o conflito de interesses existe o Grupo Independente de Testes (ITG). ITG faz parte da equipe de projeto de desenvolvimento de software, no sentido de estarem envolvidos durante o processo de especificação e continuam planejando e especificando procedimentos de teste ao longo de um grande projeto.Validação de Software – Módulo 1 Conceitos Básicos Transparência 45
    • 3.4 Etapas do Teste de Software Testes de Unidade: cada módulo é testado individualmente garantindo que ele funcione adequadamente. Utiliza as técnicas de teste de caixa branca. branca Testes de Integração: os módulos são montados ou integrados para formarem um pacote de software. Utiliza principalmente as técnicas de teste de caixa preta. preta Testes de Alto Nível (validação e sistema): Os critérios de validação estabelecidos durante a análise de requisitos são testados. Verifica também se todos os elementos combinam-se adequadamente e se a função/ desempenho global do sistema é conseguida. Utiliza as técnicas de caixa preta. pretaValidação de Software – Módulo 1 Conceitos Básicos Transparência 46
    • Etapas do Teste de SoftwareValidação de Software – Módulo 1 Conceitos Básicos Transparência 47
    • 3.5 Critérios para Conclusão de Teste Quando realizamos testes, como saber se já testamos o suficiente? Respostas pragmáticas: Você jamais terá completado a atividade de teste; a carga simplesmente transfere-se do projetista para o cliente. Quando estiver sem tempo ou sem dinheiro.Validação de Software – Módulo 1 Conceitos Básicos Transparência 48
    • Um Modelo Empírico (a) Modelo Logarítmico do Tempo de Execução de Poisson: intensidade de erros real pode ser traçada em relação a curva prevista.Validação de Software – Módulo 1 Conceitos Básicos Transparência 49
    • Um Modelo Empírico (b)Validação de Software – Módulo 1 Conceitos Básicos Transparência 50
    • 4 Executando Testes 4.1 Níveis de Testes 4.2 Teste de Unidade 4.3 Teste de Integração 4.4 Teste de Validação 4.5 Teste de SistemaValidação de Software – Módulo 1 Conceitos Básicos Transparência 51
    • 4.1 Níveis de Teste Teste de Unidade: concentra-se em cada unidade do software, de acordo com o que é implementado no código fonte. Teste de Integração: concentra-se no projeto e na construção da arquitetura de software. Teste de Validação: em como o software que foi construído é validado em relação aos requisitos de software. Teste de Sistema: o software e outros elementos do sistema são testados como um todo.Validação de Software – Módulo 1 Conceitos Básicos Transparência 52
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 53
    • 4.2 Teste de Unidade Os Testes de Unidade concentram-se em cada unidade do software, de acordo com o que é implementado no código fonte.Validação de Software – Módulo 1 Conceitos Básicos Transparência 54
    • O Que é Testado (a) a interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para fora da unidade de programa que se encontra sob teste a estrutura de dados local é examinada para ter a garantia de que dados armazenados temporariamente mantêm sua integridade durante todos os passos de execução.Validação de Software – Módulo 1 Conceitos Básicos Transparência 55
    • O Que é Testado (b) as condições de limite são testadas para ter a garantia de que o módulo opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento. todos os caminhos independentes através da estrutura de controle são exercitados para ter a garantia de que todas as instruções de um módulo foram executadas pelo menos uma vez.Validação de Software – Módulo 1 Conceitos Básicos Transparência 56
    • O Que é Testado (c) todos os caminhos de tratamento de erros são testados. Interface Estruturas de dados locais Condições limite Caminhos independentes Caminhos de tratamento de erros Casos de TesteValidação de Software – Módulo 1 Conceitos Básicos Transparência 57
    • O Ambiente de Teste de Unidade (a) Uma vez que o módulo não é um programa individual, um software driver e/ou stub deve ser desenvolvido para cada unidade de teste.Validação de Software – Módulo 1 Conceitos Básicos Transparência 58
    • O Ambiente de Teste de Unidade (b) Driver na maioria das aplicações é um programa principal que aceita dados de caso de teste, passa tais dados para o módulo a ser testado e imprime os dados relevantes. Stub ou programa simulado - serve para substituir módulos que estejam subordinados (chamados pelo) ao módulo a ser testado. Usa a interface do módulo subordinado, pode fazer manipulação de dados mínima, imprime verificação de entrada e retorna.Validação de Software – Módulo 1 Conceitos Básicos Transparência 59
    • O Ambiente de Teste de Unidade (c) • Interface • Estruturas de dados locais Driver • Condições limites • Caminhos execução módulo a • Caminhos de tratamento ser testado de erros Resultados Stub 1 Stub 2 casos de testeValidação de Software – Módulo 1 Conceitos Básicos Transparência 60
    • 4.3 Teste de Integração Os Testes de Integração concentram-se no projeto e na construção da arquitetura de software, almejam descobrir erros associados a interfaces. interfaces O objetivo é, a partir dos módulos testados ao nível de unidade, integrá-los, e testar se a estrutura de programa construída foi aquela determinada pelo projeto.Validação de Software – Módulo 1 Conceitos Básicos Transparência 61
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 62
    • Abordagens Integração não incremental: (abordagem “big-bang”) o programa completo é testado como um todo e o resultado é o caos. Quando erros são encontrados, a correção é difícil porque o isolamento das causas é complicado pela vasta amplitude do programa inteiro. Integração incremental: o programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de serem isolados e corrigidos; as interfaces têm maior probabilidade de serem testadas completamente e uma abordagem sistemática ao teste pode ser aplicada.Validação de Software – Módulo 1 Conceitos Básicos Transparência 63
    • Integração Top-Down (a) Os módulos são integrados movimentando-se de cima para baixo, através da hierarquia de controle, iniciando-se do módulo de controle principal. Os módulos subordinados ao módulo de controle principal são incorporados à estrutura de uma maneira depth-first (primeiro pela profundidade) ou breadth-first (primeiramente pela largura).Validação de Software – Módulo 1 Conceitos Básicos Transparência 64
    • Integração Top-Down (b)Validação de Software – Módulo 1 Conceitos Básicos Transparência 65
    • Passos do Processo de Integração Top-Down (a) 1. o módulo de controle é usado como um driver de teste e os stubs são substituídos para todos os módulos diretamente subordinados ao módulo de controle principal. 2. dependendo da abordagem de integração escolhida, os stubs subordinados são substituídos, um de cada vez por módulos reais. 3. testes são realizados à medida que cada módulo é integrado.Validação de Software – Módulo 1 Conceitos Básicos Transparência 66
    • Passos do Processo de Integração Top-Down (b) 4. durante a conclusão de cada conjunto de testes, outro stub é substituído pelo módulo real. 5. teste de regressão - (realização de todos ou de alguns dos testes anteriores) pode ser realizado a fim de garantir que novos erros não tenham sido introduzidos.Validação de Software – Módulo 1 Conceitos Básicos Transparência 67
    • 4.4 Teste de Validação Os Testes de Validação concentram-se em como os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi construído.Validação de Software – Módulo 1 Conceitos Básicos Transparência 68
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 69
    • Contexto Ao término da atividade de teste de integração, o software está completamente montado como um pacote, erros de interface foram descobertos e corrigidos e uma série final de testes de software - os testes de validação - pode iniciar- se.Validação de Software – Módulo 1 Conceitos Básicos Transparência 70
    • Princípios (a) A validação é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. A Especificação de Requisitos de Software contém os critérios de validação que formam a base para uma abordagem ao teste de validação. A validação do software é realizada por meio de uma série de testes de caixa preta que demonstram a conformidade com os requisitos.Validação de Software – Módulo 1 Conceitos Básicos Transparência 71
    • Princípios (b) O plano e o procedimento de teste são projetados para garantir que: todos os requisitos funcionais são satisfeitos todos os requisitos de desempenho são conseguidos a documentação está correta outros requisitos são cumpridos: portabilidade, compatibilidade, remoção de erros e manutenabilidadeValidação de Software – Módulo 1 Conceitos Básicos Transparência 72
    • Revisão de Configuração Um elemento importante do processo de validação é a revisão de configuração ou auditoria O propósito dessa revisão é garantir que todos os elementos da configuração de software tenham sido adequadamente desenvolvidos, estão catalogados e têm os detalhes necessários para apoiar a fase de manutenção do ciclo de vida do software.Validação de Software – Módulo 1 Conceitos Básicos Transparência 73
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 74
    • Testes Alfa e Beta x Teste de Aceitação É virtualmente impossível que se preveja como o cliente realmente usará/reagirá a um programa (as instruções de uso podem ser mal-interpretadas, combinações estranhas de dados podem ser irregularmente usadas, saídas que pareciam claras ao analista podem ser ininteligíveis para um usuários, etc). Testes devem ser feitos para se saber isto. Existem duas famílias de testes com esta finalidade: – Testes de Aceitação – Testes Alfa e Testes BetaValidação de Software – Módulo 1 Conceitos Básicos Transparência 75
    • Teste de Aceitação Usado quando o software é customizado para um cliente objetiva capacitar/permitir ao usuário final a validar todos os requisitos. pode variar de um test drive informal a uma série de testes planejados.Validação de Software – Módulo 1 Conceitos Básicos Transparência 76
    • Testes Alfa e Beta (a) Usado quando o software é desenvolvido como um produto para muitos clientes, geralmente tem duas fases: Teste Alfa - é levado a efeito por um cliente nas instalações do desenvolvedor. O software é usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros" do usuário e registrando erros e problemas de uso.Validação de Software – Módulo 1 Conceitos Básicos Transparência 77
    • Testes Alfa e Beta (b) Teste Beta - é realizado nas instalações do cliente pelo usuário final do software. O desenvolvedor não está presente. O cliente registra os problemas (reais ou imaginários) que são encontrados e relata-os ao desenvolvedor a intervalos regulares.Validação de Software – Módulo 1 Conceitos Básicos Transparência 78
    • 4.5 Teste de Sistema O software é apenas um elemento de um sistema baseado em computador mais amplo. O teste de sistema envolve uma série de diferentes testes, cujo propósito primordial é por completamente à prova o sistema baseado em computador.Validação de Software – Módulo 1 Conceitos Básicos Transparência 79
    • Validação de Software – Módulo 1 Conceitos Básicos Transparência 80
    • Um Problema Clássico no Teste de Sistema "apontar o dedo" - quando ocorre um erro, o desenvolvedor de um elemento do sistema culpa outro pelo problema.Validação de Software – Módulo 1 Conceitos Básicos Transparência 81
    • Princípios O engenheiro de sistema deve antecipar os problemas potenciais da interface: 1. projetar caminhos de tratamento de erros que testem todas as informações que chegam de outros elementos do sistema. 2. realizar uma série de testes que simulem dados ruins ou outros erros em potencial na interface do software. 3. registrar os resultados de teste para usar como "prova" se alguém lhe apontar o dedo. 4. participar do planejamento e projeto dos testes do sistema para garantir que o software seja adequadamente testado.Validação de Software – Módulo 1 Conceitos Básicos Transparência 82
    • Teste de RecuperaçãoMuitos sistemas baseados em computador precisam recuperar-se defalhas e retomar o processamento dentro de um tempo previamenteespecificado. Em certos casos, o sistema deve tolerar falhas, isto é,o processamento de falhas não deve fazer com que uma funçãoglobal de sistema cesse. Em outros casos, uma falha do sistemadeve ser corrigida dentro de um período previamente especificado;caso contrário, graves prejuízos econômicos ocorrerão.O teste de recuperação é um teste de sistema que força o software afalhar de diversas maneiras e verifica se a recuperação éadequadamente executada.Validação de Software – Módulo 1 Conceitos Básicos Transparência 83
    • Teste de Segurança (a) Qualquer sistema baseado em computador que gerencie informações delicadas ou provoque ações que possam impropriamente prejudicar (ou beneficiar) pessoas constitui um alvo para o acesso impróprio ou ilegal. O teste de segurança tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos.Validação de Software – Módulo 1 Conceitos Básicos Transparência 84
    • Teste de Segurança (b) Durante o teste de segurança, o analista desempenha o papel de pessoa que deseja penetrar no sistema. Qualquer coisa vale! adquirir senhas mediante contatos externos atacar o sistema com software customizado projetado para derrubar quaisquer defesas que tenham sido construídasValidação de Software – Módulo 1 Conceitos Básicos Transparência 85
    • Teste de Segurança (c) desarmar o sistema, negando serviço a outros provocar erros intencionalmente, esperando acessá-lo durante a recuperação "folhear" através de dados inseguros esperando descobrir a chave para a entrada no sistema. O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida.Validação de Software – Módulo 1 Conceitos Básicos Transparência 86
    • 5 Depurando Software 5.5.1 O Quê é depuração 5.5.2 Abordagens à depuraçãoValidação de Software – Módulo 1 Conceitos Básicos Transparência 87
    • 5.5.1 O Quê é Depuração O objetivo primordial da depuração ou debugging é descobrir e corrigir a causa de um erro de software. A depuração ocorre em conseqüência de testes bem sucedidos. Embora a depuração possa e deva ser ser um processo disciplinado, ela ainda tem muito de arte.Validação de Software – Módulo 1 Conceitos Básicos Transparência 88
    • O Processo de DepuraçãoValidação de Software – Módulo 1 Conceitos Básicos Transparência 89
    • Severidade de Erros Durante a depuração, encontram-se erros que variam de brandamente perturbadores a catastróficos. À medida que as conseqüências de uma falha aumentam, a pressão para descobrir a causa também aumenta.Validação de Software – Módulo 1 Conceitos Básicos Transparência 90
    • Por que a Depuração é Difícil? (a) 1) O sintoma e a causa podem ser geograficamente remotos. Estruturas altamente acopladas agravam essa situação. 2) O sintoma pode desaparecer (temporariamente) quando outro erro é corrigido. 3) O sintoma pode, de fato, ser causado por não erros (por exemplo, imprecisões de arredondamento).Validação de Software – Módulo 1 Conceitos Básicos Transparência 91
    • Por que a Depuração é Difícil? (b) 4) O sintoma pode ser causado por um erro humano que não é facilmente rastreado. 5) O sintoma pode ser resultado de problemas de temporização, e não problemas de processamento. 6) O sintoma pode ser devido a causas que estão distribuídas por uma série de tarefas que são executadas em diferentes processadores.Validação de Software – Módulo 1 Conceitos Básicos Transparência 92
    • 5.5.2 Abordagens à Depuração 1 - Força bruta 2 - Backtracking 3 - Eliminação da CausaValidação de Software – Módulo 1 Conceitos Básicos Transparência 93
    • Força Bruta (a) A categoria de depuração por força bruta provavelmente é o método mais comum e menos eficiente de isolar a causa de um erro de software. Usa-se uma filosofia do tipo "deixe que o computador descubra o erro". Por exemplo, são feitas listagens de memória (memory dumps), são inseridas instruções WRITE, etc. Aplica-se o método de força bruta quando tudo o mais falha.Validação de Software – Módulo 1 Conceitos Básicos Transparência 94
    • Força Bruta (b) Espera-se encontrar, em algum lugar do emaranhado de informações, uma pista que possa levar à causa de um erro. Não obstante, a massa de informações produzida possa levar ao sucesso, mais freqüentemente ela conduz a tempo e esforço desperdiçados. Deve-se gastar o raciocínio primeiro.Validação de Software – Módulo 1 Conceitos Básicos Transparência 95
    • Backtracking Iniciando-se no local em que o sintoma foi descoberto, o código fonte é rastreado para trás (manualmente) até que o local da causa seja encontrado. É uma abordagem que pode ser usada com sucesso em pequenos programas. Infelizmente, à medida que o número de linhas de código aumenta, o número de potenciais caminhos de backtracking pode tornar-se incontrolavelmente alto.Validação de Software – Módulo 1 Conceitos Básicos Transparência 96
    • Eliminação da Causa Os dados relacionados à ocorrência de erros são organizados para isolar potenciais causas. Uma "hipótese de causa" é imaginada e os dados são usados para provar ou refutar a hipótese. Alternativamente, uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada uma delas. Se os testes iniciais indicarem que uma hipótese de causa apresenta possibilidades, os dados são refinados, numa tentativa de isolar o bug.Validação de Software – Módulo 1 Conceitos Básicos Transparência 97
    • 5.5.3 Dicas Sobre Depuração (a) As abordagens de depuração podem ser complementadas com ferramentas de depuração: compiladores de depuração, auxílio rastreadores de depuração dinâmicos, geradores de casos de teste automáticos, geradores de dumps de memória e geradores de mapas de referência cruzada.Validação de Software – Módulo 1 Conceitos Básicos Transparência 98
    • Dicas Sobre Depuração (b) Um poderoso aliado à depuração são "outras pessoas". O conceito de “programação não egoística” deve ser ampliado para "depuração não egoística".Validação de Software – Módulo 1 Conceitos Básicos Transparência 99
    • Dicas Sobre Depuração (c) Assim que um erro é encontrado, ele deve ser corrigido, porém a correção de um erro pode introduzir outros erros. Assim, deve- se fazer 3 perguntas simples, sempre que se realizar uma "correção" que removerá a causa de um erro: 1- A causa do bug é reproduzida em outra parte do programa? 2- Qual "bug seguinte" poderia ser introduzido pelo reparo que se está prestes a fazer? 3- O que poderia ter sido feito para eliminar este bug desde o princípio?Validação de Software – Módulo 1 Conceitos Básicos Transparência 100