TESTES2011

T

S

M

Quando considera-se que um projeto atendeu suas

espectativas?

É possível garantir que um certo programa está de

acordo com uma especificação? acordo com uma especificação?

É possível provar que um programa não tem erros?

T

S

Duas metas:

Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos.

Descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não

Q

?

“Os testes podem somente mostrar a presença

de erros, não sua ausência”. (Dijkstra et al.,

1972)

Critérios para o fim dos testes

Funcionalidade

Expectativa do usuário
Mercado

Quando o tempo ou o dinheiro acaba
Técnicas estatísticas

P

T

Casos de

teste _{de teste}Dados Resultados de teste Projetar casos de teste Preparar dados de teste Executar programa com dados de teste

Comparar resultados para os casos de teste

P

T

É muito difícil (em alguns casos impossível) testar

cada possível sequencia de execução de um software

Escolhe-se testar as funções mais importantes e

mais susceptíveis a erros. mais susceptíveis a erros.

Uma empresa pode definir regras. Por exemplo:
Todas as funções do sistema acessadas por meio de

menus devem ser testadas

Combinações de funções (por exemplo, formatação de um texto) acessadas via menus devem ser testadas

Todas as funções devem ser testadas com entradas

P

T

Pode ser dividido em:
Teste de sistemas

Teste de componentes
Teste de Usuário

T

S

Envolve a integração de dois ou mais componentes

que implementam funções ou características do sistema e depois o teste deste sistema integrado

Divide-se em:

Testes de integração
Testes de integração
Testes de releases

Testes de desempenho

Em um processo de desenvolvimento iterativo, o

teste de integração concentra-se em testar o componente a ser entregue.

Em um processo de desenvolvimento em cascata,

T

I

A equipe de testes deve acessar o código-fonte do

sistema.

Os testes de integração geralmente estão

relacionados à descoberta de defeitos no sistema

Fundamentalmente são testes para sistemas
Fundamentalmente são testes para sistemas

incompletos compostos de clusters e

agrupamentos de componentes de sistema.

Não há garantias de que unidades testadas em

T

Também chamados de testes de aceitação

Se o release for bom o suficiente, o cliente poderá aceitá-lo para seu uso.

A equipe de testes concentra-se em validar se o

sistema atende aos requisitos e em assegurar que sistema atende aos requisitos e em assegurar que o sistema é confiável.

Os clientes, normalmente, são envolvidos nos

testes.

T

D

Verificar propriedades emergentes como

desempenho e confiabilidade

Testar o comportamento do sistema em caso de falha
Estressar o sistema e causar o surgimento de defeitos.

T

C

Também chamado de testes de unidade

A idéia é testar individualmente cada um dos componentes

Normalmente desenvolvido pelos próprios
Normalmente desenvolvido pelos próprios

desenvolvedores

A meta é expor defeitos nesses componentes

T

C

O que testar?

Funções ou métodos individuais de um objeto

Classes de objeto com vários atributos e métodos
Componentes compostos que constituem diferentes

objetos ou funções objetos ou funções

Erros comuns incluem:

Precedência de operadores aritméticos e/ou lógicos
Inicialização incorreta

T

C

Eles devem testar ou verificar:
Interface

As estruturas de dados:

Inicialização: valores assumidos por omissão
Possibilidades de overflow e underflowPossibilidades de overflow e underflow

As condições de limite:

Tamanhos de arrays
Saídas de laços

Caminhos logicamente independentes
Os estados dos objetos

T

U

Realizados com dados do cliente

A motivação maior para este tipo de teste é

o fato do desenvolvedor nunca conseguir

prever como o usuário realmente usará um

prever como o usuário realmente usará um

software

Os testes de aceitação podem ser:

T

U

Quando o software é voltado para o

mercado, geralmente assumem a forma de

testes alfa e beta

Testes alfa:

Testes alfa:

Feitos por um determinado cliente
Nas instalações do desenvolvedor

Testes beta:

Realizados por possíveis clientes, em suas

T

A realização de testes não consegue mostrar ou

provar que um software ou programa está correto

Os testes bem sucedidos são aqueles que revelam

erros não descobertos anteriormente! erros não descobertos anteriormente!

A

P

C

T

Teste funcional ou de caixa-preta

Baseados na funcionalidade do programa
Teste estrutural ou de caixa-branca

Baseados na estrutura do programa
Teste de interface

Teste de interface

Baseados na funcionalidade do programa e nas suas interfaces internas

Particularmente importante para sistemas orientados a objetos

T

C

P

O objetivo principal é validar os requisitos

Visam mostrar que:

As entradas são aceitas

As saídas são as esperadas
As saídas são as esperadas

A integridade dos dados é mantida

Exemplos:

Particionamento de equivalência

T

C

B

Usa-se o conhecimento sobre o sistema para

propor casos de teste

Servem para garantir que todas as estruturas

dos programas e todos os possíveis casos

sejam testados

sejam testados

A motivação é a constatação de que, em geral,

os erros se concentram mais nos casos

especiais

Exemplos:

testes de caminho básico

T

I

Categorias:

Mau uso da interface (e.g. erro na passagem dos parâmetros)

Mau entendimento da interface (e.g. busca binária com um vetor não ordenado)

Erros de timing (e.g. sistemas concorrentes – um dado desatualizado)

E

T

E

-

O teste das unidades parte do nível mais

alto para o mais baixo na hierarquia de

controle do software

Deve ser usado quando o processo de

desenvolvimento é top-down

desenvolvimento é top-down

Vantagens:

Erros de projeto são detectados cedo

Uma versão restrita do sistema fica logo

E

-

O teste das unidades parte do nível mais

baixo para o mais alto na hierarquia de

controle do software

A integração dos módulos já pode usar os

A integração dos módulos já pode usar os

módulos subordinados reais, que estão

sempre disponíveis

Desvantagem:

O software não existe, ou não pode ser testado,

T

E

Tentam confrontar o software ou os

programas com situações anormais

Dois objetivos:

Teste do comportamento do sistema durante

uma falha

T

C

Possível apenas quando há várias versões dos

sistemas

Protótipo

Versões para plataformas diferentes
Sistemas antigos

Sistemas críticos

Os resultados das diferentes versões são

comparados

A

T

JUnit

EasyAccept
...

P

P

Testes têm função dupla

Detectar a presença de erros

Verificar a usabilidade do sistema

Testes não podem demonstrar ausência de

erros

O processo de teste envolve: teste de

unidade, teste de módulo, teste de

sub-sistema, teste de sistema e teste de

aceitação

P

P

Abordagens: teste de caixa preta, teste de

caixa branca, teste de interface

Algumas estratégias de teste: top-down,

Algumas estratégias de teste: top-down,

bottom-up, teste de estresse, e teste

comparativo