validação e testes de software - mod1

Transparência 1Validação de Software – Módulo 1 Conceitos Básicos

Validação de Software

Professor Manoel Mendonça


Sobre a Disciplina


� Testes� Revisões� Provas Formais

Técnicas para Avaliação daQualidade de Produtos


Instrutor

• Manoel Mendonça– Sala IM 215

– Tel. 3283-6343

– Horário para alunos – quarta à tarde

– [email protected]


Site da Disciplina

• ...


Bibliografia

A Practitioner's Guide to Software Test Design by Lee Copeland ISBN:158053791x

Artech House © 2004

http://www.opensourcetesting.org


Avaliações

• Trabalhos, dois trabalhos• Provas, uma ou duas


Plataforma de Trabalho

• Java e Eclipse• JUnit• Outras ferramentas


0. Conceitos Básicos


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 defeito


Defeitos e Falhas: Uma Visão Mais Completa

Engano (mistake)=> “erro” cometido “cabeça” do eng. desoftware

Defeito (fault) => “erro” inserido no software

Erro (error) => “execução” do “erro” conduzindo a um estadoincorreto do software

Falha (failure)=> manifestação externa do “erro”


Principais Artefatos de SoftwareUma Visão Simplificada

Especificaçãode requisitos

Projeto Código

Defeitos ocorrem em todos eles !!!


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.


0.2 Alguns Tipos de Defeitos Introduzidos

Informação que é fornecida e não é necessária ou nunca utilizada

Informação Estranha

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.

Ambigüidade

Informação contida em uma parte do artefato de software está inconsistente com outra informação no artefato de software.

Inconsistência

Alguma informação no artefato de software contradiz informação do documento de outra informação no artefato de software.

Fato Incorreto

Informação necessária do sistema foi omitida do artefato de software.

Omissão

Descrição GeralTipo de Defeito


De onde os defeitos vêm?

Que defeitos podemos encontrar?

Copyright Guilherme TravassosCOPPE/UFRJ – 2003 - http://www.cos.ufrj.br/~ght

Conhecimento do domínio

RequisitosGerais

OutroDomínio

Artefatos de SoftwareOmissão

Inconsistência

Ambigüidade

Fato incorreto

Informação estranha

Tipos de Defeitos Introduzidos


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.


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çãoVerificação e Validação(V&V).(V&V).

A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA).


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

� 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?”


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.


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.


Teste de Software


Teste

1 Introdução2 Contexto3 Organização para Realização de Testes4 Executando Teste5 Depurando Software6 Técnicas de Teste


1. Introdução

1.1 Engenharia de Software e Teste1.2 O quê é teste1.3 Objetivos da Atividade de Teste1.4 Erros e as atividades de teste


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 testesRealização de testes

3- Fase de Manutenção ("alterações")


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.


1.3 Objetivos da Atividade de Teste

Objetivo: projetar testes que descubram sistematicamente diferentes classes de errose 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.


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 erroisto implica que a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software


1.5 O Processo de Teste


2. Contexto

2.1 Princípios Básicos2.2 Estratégia de Teste2.3 Verificação e Validação2.4 Garantia de Qualidade de Software


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.


2.2 Estratégia de Teste de Software

Uma Estratégia de TesteEstratégia de Testedeve acomodar testes de baixo nívele

testes de alto nível, deve oferecer orientação ao profissional,

deve oferecer um conjunto de marcos de referênciaao

administrador e deve ser mensurável.


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.


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ênciaao administrador e deve ser mensurável.


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çãoVerificação e Validação(V&V).(V&V).

A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA).


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

� 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?”


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.


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.


3. Organização para Realização de Testes

3.1 Desenvolvedores x Testadores3.2 Como as pessoas vêem os testes3.3 O Grupo Independente de Teste3.4 Etapas do Teste de Software3.5 Critérios para Conclusão de Testes


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.


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 problemas


3.3 Grupo Independente de Teste

Para suprir o conflito de interesses existe o Grupo Grupo Independente de TestesIndependente 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.


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 brancacaixa 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 pretacaixa 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 pretacaixa preta.


Etapas do Teste de Software


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.


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.


Um Modelo Empírico (b)


4 Executando Testes

4.1 Níveis de Testes4.2 Teste de Unidade4.3 Teste de Integração4.4 Teste de Validação4.5 Teste de Sistema


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.


4.2 Teste de Unidade

Os Testes de Unidadeconcentram-se em cada unidade do software, de acordo com o que é implementado no código fonte.


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 dadoslocal é examinada para ter a garantia de que dados armazenados temporariamente mantêm sua integridade durante todos os passos de execução.


� as condições de limitesã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 independentesatravé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.

O Que é Testado (b)


� todos os caminhos de tratamento de errossão testados.

O Que é Testado (c)

InterfaceEstruturas de dados locaisCondições limiteCaminhos independentesCaminhos de tratamento de erros

Casos de Teste


O Ambiente de Teste de Unidade (a)

Uma vez que o módulo não é um programa individual, um software driver e/ou stubdeve ser desenvolvido para cada unidade de teste.


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.

� Stubou 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.


O Ambiente de Teste de Unidade (c)

Driver

módulo a

ser testado

Stub 1 Stub 2Resultados

• Interface

• Estruturas de dados

locais

• Condições limites

• Caminhos execução

• Caminhos de tratamento

de erros

casos de teste


4.3 Teste de Integração

Os Testes de Integraçãoconcentram-se no projeto e na construção da arquitetura de software, almejam descobrir erros associados ainterfacesinterfaces.

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.


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.


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


Integração Top-Down (b)


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 stubssubordinados são substituídos, um de cada vez por módulos reais.

3. testes são realizados à medida que cada módulo é integrado.


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.

Passos do Processo de Integração Top-Down (b)


4.4 Teste de Validação

Os Testes de Validaçãoconcentram-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.


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 - ostestes de validaçãotestes de validação- pode iniciar-se.


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 SoftwareEspecificação de Requisitos de Softwarecontém os critérios de validaçãocrité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.


O plano e o procedimento de teste são projetados para garantir que:

todos os requisitos funcionais são satisfeitos

todos os requisitos de desempenhosão conseguidos

a documentaçãoestá correta

outros requisitos são cumpridos: portabilidade, compatibilidade, remoção de errose manutenabilidade

Princípios (b)


Revisão de Configuração

Um elemento importante do processo de validação é a revisão revisão de configuraçãode configuraçãoou 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.


É virtualmente impossível que se preveja como o cliente

realmenteusará/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 Beta

Testes Alfa e Beta x 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 driveinformal a uma série de testes planejados.

Teste de Aceitação


Usado quando o software é desenvolvido como um produto para muitos clientes, geralmente tem duas fases:

Teste AlfaTeste 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.

Testes Alfa e Beta (a)


Teste BetaTeste Beta- é realizado nas instalações do clientepelo usuário final do software. O desenvolvedor nãoestá presente.

O cliente registra os problemas (reais ou imaginários) que são encontrados e relata-os ao desenvolvedor a intervalos regulares.

Testes Alfa e Beta (b)


4.5 Teste de Sistema

O software é apenas um elemento de um sistema baseado em computador mais amplo.

O teste de sistemaenvolve uma série de diferentes testes, cujo propósito primordial é por completamente à prova o sistema baseado em computador.


"apontar o dedo" - quando ocorre um erro, o desenvolvedor de um elemento do sistema culpaoutro pelo problema.

Um Problema Clássico no Teste de Sistema


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.

Princípios


Muitos sistemas baseados em computador precisam recuperar-se de falhas e retomar o processamento dentro de um tempo previamente especificado. Em certos casos, o sistema deve tolerar falhas, isto é, o processamento de falhas não deve fazer com que uma função global de sistema cesse. Em outros casos, uma falha do sistema deve 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 a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada.

Teste de Recuperação


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çatenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos.

Teste de Segurança (a)


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ídas

Teste de Segurança (b)


desarmar o sistema, negando serviço a outros

provocar erros intencionalmente, esperando acessá-lodurante 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.

Teste de Segurança (c)


5 Depurando Software

5.5.1 O Quê é depuração5.5.2 Abordagens à depuração


O objetivo primordial da depuração ou debuggingé descobrir e corrigir a causa de um erro de software.

A depuraçãoocorre 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.

5.5.1 O Quê é Depuração


O Processo de Depuração


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.

Severidade de Erros


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

Por que a Depuração é Difícil? (a)


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.

Por que a Depuração é Difícil? (b)


1 - Força bruta

2 - Backtracking

3 - Eliminação da Causa

5.5.2 Abordagens à Depuração


A categoria de depuração porforç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.

Força Bruta (a)


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.

Força Bruta (b)


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 backtrackingpode tornar-se incontrolavelmente alto.

Backtracking


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 realizadospara eliminar cada uma delas.

Se os testes iniciais indicarem que uma hipótese de causa apresenta possibilidades, os dados são refinados, numa tentativade isolar o bug.

Eliminação da Causa


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 dumpsde memória e

geradores de mapas de referência cruzada.

5.5.3 Dicas Sobre Depuração (a)


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".

Dicas Sobre Depuração (b)


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?

Dicas Sobre Depuração (c)

validação e testes de software - mod1

Documents