Validação e Testes de Software - MOD1

Validação de Software

Professor Manoel Mendonça

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

Sobre a Disciplina


Técnicas para Avaliação da
Qualidade de Produtos

Testes
Revisões
Provas Formais


Instrutor

• Manoel Mendonça
– Sala IM 215
– Tel. 3283-6343
– Horário para alunos – quarta à tarde
– manoel.mendonca@ufba.br


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


Principais Artefatos de Software
Uma Visão Simplificada

Especificação Projeto Código
de requisitos

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

Tipo de Descrição Geral
Defeito
Omissã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 nunca
Estranha utilizada


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üidade


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ção (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

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ção
2 Contexto
3 Organização para Realização de Testes
4 Executando Teste
5 Depurando Software
6 Técnicas de Teste


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


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 software


1.5 O Processo de Teste


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


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ência ao
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ção (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

software implementa corretamente uma função específica.
“Estamos construindo certo o produto?”


Validaçã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 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 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
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.


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.
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 Testes
4.2 Teste de Unidade
4.3 Teste de Integração
4.4 Teste de Validação
4.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 Unidade concentram-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 dados local é examinada para ter a garantia
de que dados armazenados temporariamente mantêm sua
integridade durante todos os passos de execução.


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.


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 Teste


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.


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.


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 teste


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.


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


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.


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.


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.


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.


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 manutenabilidade


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.


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 Beta


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.


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.


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.


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.


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.


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.


Teste de Recuperação

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


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


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.


5 Depurando Software

5.5.1 O Quê é depuração
5.5.2 Abordagens à depuração


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.


O Processo de Depuração


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.


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


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.


5.5.2 Abordagens à Depuração
1 - Força bruta
2 - Backtracking
3 - Eliminação da Causa


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.


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.


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.


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.


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.


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


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 e Testes de Software - MOD1

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Validação e Testes de Software - MOD1

Mais de Fernando Palma

Validação e Testes de Software - MOD1