ENGENHARIA DE

SOFTWARE

Validação e Testes

Darlines Sánchez Muñoz. PhD

INTRODUÇÃO
 A validação destina-se a mostrar que um sistema
está de acordo as suas especificações e que atende
as expectativas do cliente
 Deve-se verificar processos por medio de
inspeções em cada estagio do processo de
software desde a especificação de requisitos até o
desenvolvimento do sistema.
 A maior parte da validação é observada depois da
implementação

2
INTRODUÇÃO
 Como já vimos os sistemas são divididos em
subsistemas pelo que não se faz o processo de
validação no sistema como um todo.
 Os testes são feitos em conjunto e evoluem
conjuntamente com a implementação do sistema.

3
ETAPAS DO PROCESSO DE TESTES
I. Teste de unidade: São testados os componentes
individuais, para garantir que eles operam
corretamente. São testados
independentemente.

II. Teste de modulo: Um modulo é uma coleção de

componentes dependentes. Devem ser testados
sem outros módulos do sistema.

III. Teste de subsistema: Testar conjuntos de

módulos. Deve-se detectar erros de interface de
4
módulos.
ETAPAS O PROCESSO DE TESTES
IV. Teste de sistema: Detectar erros que resultem
das interações não previstas entre subsistemas
e de problemas com a interface dos subsistemas

V. Teste de aceitação: Etapa final antes que o

sistema seja aceitado para uso operacional. O
sistema é testado com os dados oferecidos pelo
cliente, no lugar de testes simulados.

5
PROCESSO DE TESTES

6
TESTES PARA A DETECÇÃO DE
DEFEITOS

 O objectivo é expor defeitos latentes em um

sistema de software antes do sistema ser
entregue, contrastando com os processos de
validação.
 Um teste bem sucedido para a detecção de
defeitos é aquele que faz com que o sistema opere
incorrectamente e que expõe um defeito
existente.

7
TESTES PARA A DETECÇÃO DE
DEFEITOS

8
TESTES PARA A DETECÇÃO DE
DEFEITOS

Casos de testes: Especificações de entrada para o

teste e da saída esperada do sistema

Dados de teste: Entradas que forem criadas para

testar o sistema.

9
TESTES CAIXA PRETA (TESTES
FUNCIONAIS)

Ostestes são derivados da especificação de

programa ou de componente.

O sistema é uma caixa preta e cujo comportamento

só pode ser determinado estudando as suas
entradas e as saídas relacionadas.

O testador baseia-se só na funcionalidade.

10
TESTES CAIXA PRETA (TESTES
FUNCIONAIS)

11
TESTES CAIXA BRANCA(TESTES DE
ESTRUTURA)

 Os testes são derivados do conhecimento da

estrutura e da implementação do software

 São usados para unidades de programas

relativamente pequenas. (sub-rotinas, operações
associadas com um objeto)

 O testador pode analisar o código e utilizar

conhecimento sobre a estrutura de um componente
a fim de derivar os dados para o teste 12
TESTES CAIXA BRANCA(TESTES DE
ESTRUTURA)

13
TESTES DE INTERFACE
 Ocorrem quando módulos ou subsistemas são
integrados para criar sistema maiores.

 Cada modulo do sistema tem uma interface definida

que é chamada por outros componentes do programa.

 O objetivo do teste é detectar erros que possam ter

sido introduzidos no sistema em razão de erros ou
suposições invalidas sobre as interfaces.

 É um teste maioritariamente usado para o

14
desenvolvimento orientado a objetos.
TESTES DE INTERFACE

15
TESTES ORIENTADOS A OBJETO

 Podem ser identificados quatro níveis de testes:

 Testar as operações principais associadas com
objetos: São funções ou procedimentos e podem ser
usadas as abordagem de caixa preta ou branca.

 Testar classes de objetos individuais: O principio de

caixa preta permanece inalterable, mas a noção de
uma classe equivalente tem que ser estendida para
cobrir sequencias de operação relacionada
16
TESTES ORIENTADOS A OBJETO
 Podem ser identificados quatro níveis de
testes:
 Testar agrupamento de objetos

 Testar o sistema orientado a objetos

17
ENGENHARIA DE
SOFTWARE

Validação e Testes

Darlines Sánchez Muñoz. PhD