Teste De Unidade

Testes de Unidade:

 Têm como objetivo testar os módulos do programa

 Abordagens para seleção dos casos de teste:

 Funcionais: independentes da lógica da codificação (Teste caixa preta): A idéia é que conhecendo-se o objetivo do módulo, testes podem ser realizados para demonstrar que cada função é totalmente operacional.

 Estruturais: obtidos a partir da estrutura do programa (Teste caixa branca): A idéia é que conhecendo-se o funcionamento interno de um módulo, testes podem ser realizados para garantir que todas as engrenagens se encaixam, ou seja, que a operação interna do módulo tem um desempenho de acordo com as especificações e que os componentes internos foram adequadamente postos à prova.

 Limites e situações extremas

 Necessita-se muitas vezes de stubs e drivers. Driver é um “programa principal” que aceita dados de caso de teste, passa tais dados para o módulo ser testado e imprime os dados relevantes. Os stubs servem para substituir módulos que estejam subordinados ao módulo a ser testado. Um stub, ou “programa simulado”, usa a interface do módulo subordinado, pode fazer manipulação de dados mínima, imprime a verificação e retorna.

• O teste de unidade é simplificado quando um módulo com elevada coesão é projetado. Quando somente uma função é endereçada por um módulo, o número de casos de teste é reduzido e os erros podem ser mais facilmente previstos e revelados.

Testes de integração:

 Têm como objetivo testar interfaces.

 Apesar de todos os módulos funcionarem corretamente individualmente, podem surgir problemas ao serem colocados juntos. Dados podem ser perdidos ao longo de uma interface; um módulo pode ter um efeito inesperado, sobre outro; as subfunções quando combinadas, podem não produzir a função principal esperada; uma imprecisão individualmente aceitável pode ser ampliada até níveis inaceitáveis; as estruturas de dados globais podem apresentar problemas. Etc...

 Não é bom testar tudo junto já que fica difícil determinar as causas de erros encontrados. Pode-se adotar uma estratégia de integração incremental. O programa é construído e testado em pequenos segmentos, ficando mais fácil isolar os erros e corrigi-los.

Testes de Sistema:

 Visam a realização de uma série de testes de forma a observar se os elementos do sistema foram adequadamente integrados, se estão realizando as funções especificadas e se o desejado desempenho global do sistema foi atingido.

 Podem ser realizados os seguintes tipos de teste:

a) Recuperação: Este teste força o sistema a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada. Verifica, por exemplo, se o tempo médio até o reparo se encontra dentro dos limites aceitáveis.

b) Segurança: Verifica se todos os mecanismos de proteção do sistema o protegerão de fato no caso de acessos indevidos.

c) Stress: Realizado para verificar como o sistema se comporta em situações de stress. Exemplo:

 Testes que gerem um número maior de interrupções do que a média esperada.

 Testes em que os índices de entrada de dados são aumentados.

 Testes que exigem o máximo de memória ou outros recursos.

 Testes que provocam procura excessiva por dados.

Testes de aceitação ou validação:

 Têm como objetivo demostrar que o sistema está pronto para ser colocado em operação.

 Quem dirá que o sistema está pronto ? Depende do que foi definido na Especificação de Requisitos com relação aos critérios de validação.

 Escolha dos casos de teste: a cargo dos usuários com a assessoria técnica dos responsáveis pelos testes

 Pode