Guia Completo de Técnicas e Estratégias de Teste de Software

Técnica Estrutural (Caixa Branca)

Técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de identificar defeitos nas estruturas internas do software, através de situações que exercitem adequadamente todas as estruturas de controle e dados utilizadas na codificação.

Os testes são usados para:

• Garantir que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez;
• Exercitar todas as decisões lógicas para valores falsos ou verdadeiros;
• Executar todos os laços em suas fronteiras e dentro de seus limites operacionais;
• Exercitar as estruturas de dados internas para garantir a sua validade.

Por que se preocupar com teste Caixa Branca?

• O número de caminhos é muito grande e é muito provável que alguns sejam inexecutáveis;
• Em geral, acreditamos que um determinado caminho é pouco provável, mas a realidade não é intuitiva;
• É provável achar erros nos caminhos não percorridos.

Reduzir o número de testes

Conjunto Base: número de caminhos que executarão todos os comandos e todas as condições ao menos uma vez.

Objetivo: Definir massas de testes para o conjunto base. O conjunto base não é único.

Técnica Baseada em Erros

Técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de validar os erros mais frequentemente cometidos durante o processo de desenvolvimento de software.

Técnica Funcional (Caixa Preta)

Técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de garantir que os requisitos do software que foi construído sejam plenamente atendidos.

Os testes são usados para:

• Demonstrar que as funções do software são operacionais;
• A entrada é adequadamente aceita;
• A saída é corretamente produzida;
• A integridade das informações externas (tabelas) é mantida.

Categoria de Erros

• Funções incorretas ou esquecidas;
• Erros de interface;
• Erros na estrutura de dados ou acesso ao banco de dados;
• Erros de performance;
• Erros de inicialização e término.

1. Tipos de Teste

Os tipos de teste são aplicáveis ao conjunto de características definidas para realização dos testes em cada nível, durante o desenvolvimento de sistemas.

• Teste de Funcionalidade: testes projetados para a descoberta de erros funcionais.
• Teste de Interface: as interfaces internas e externas são testadas à medida que cada módulo (ou cluster) é incorporado à estrutura.
• Teste de Conteúdo de Informação: testes projetados para a descoberta de erros associados às estruturas de dados globais e locais.
• Teste de Desempenho: testes projetados para a verificação dos limites de desempenho estabelecidos durante o projeto do software.
• Teste de Carga (Stress): realizado para confrontar os programas com situações anormais, exigindo recursos em quantidade, frequência ou volumes anormais.
• Teste de Sensibilidade: tenta descobrir combinações de dados dentro de classes de entrada válidas que possam causar instabilidade ou processamento impróprio.
• Teste Automático: O teste manual leva muito tempo. O teste do software deve ser repetido após cada mudança do programa. Test drivers podem rodar automaticamente e gerar relatórios de teste.

Teste de Unidade

• A Interface com o módulo é testada para garantir que as informações fluem para dentro e para fora da unidade de programa sob teste;
• A Estrutura de Dados local é examinada para garantir que dados armazenados temporariamente mantêm sua integridade;
• As condições de Limite são testadas para garantir que o módulo opera adequadamente nos limites estabelecidos;
• Todos os Caminhos Independentes através da estrutura de controle são executados para garantir que todas as instruções foram executadas pelo menos uma vez;
• Todos os Caminhos de Tratamento de Erros são testados.

Teste de Unidade x Ambiente

O módulo não é um programa individual; deve-se ter programas de ligação para a realização dos testes no ambiente.

• Driver: é um programa principal que aceita dados de caso de teste, repassa os dados para o módulo a ser testado e imprime os resultados.
• Stub: é um programa simulado que substitui módulos subordinados ao módulo a ser testado.

Teste de Integração

O objetivo é, a partir dos módulos testados ao nível de unidade, construir a estrutura de programa determinada pelo projeto.

• Integração Não Incremental: o programa completo é testado como um todo. A correção de erros é difícil devido à complexidade de isolamento.
• Integração Incremental: o programa é construído e testado em pequenos segmentos, facilitando o isolamento e correção de erros.
• Integração Top-Down: os módulos são integrados de cima para baixo, iniciando pelo módulo de controle principal.

O processo de integração é executado em 5 passos:

1. Definir a utilização de driver e stubs;
2. Substituir stubs um de cada vez;
3. Realizar testes a cada módulo integrado;
4. Substituir stub por módulo real;
5. Teste de Regressão: realizar testes anteriores para garantir que novos erros não foram introduzidos.

Integração Bottom-Up

Os módulos são integrados de baixo para cima, eliminando a necessidade de stubs.

1. Definir o cluster (conjunto de módulos);
2. Escrever driver;
3. Realizar testes a cada cluster;
4. Remover os drivers e combinar os clusters para cima na estrutura.

Teste de Validação

Inicia quando o software está completamente montado. A validação é bem-sucedida quando o software funciona conforme esperado pelo cliente.

• Todos os requisitos funcionais e de desempenho são satisfeitos;
• A documentação está correta;
• Outros requisitos são cumpridos: portabilidade, compatibilidade e manutenibilidade.

Revisão de Configuração

Garante que todos os elementos da configuração de software foram adequadamente desenvolvidos e catalogados.

Testes Alfa e Beta

• Software Customizado: Realizam-se Testes de Aceitação pelo usuário final.
• Software como Produto: Teste Alfa (instalações do desenvolvedor) e Teste Beta (instalações do cliente).

Teste de Sistema

Envolve uma série de testes para pôr à prova o sistema baseado em computador.

• Teste de Recuperação: força o software a falhar e verifica a recuperação.
• Teste de Segurança: verifica se os mecanismos de proteção impedem acessos indevidos.

2. Teste em Projetos Orientados a Objetos

• Consistência e correção dos modelos de Análise e Projeto OO;
• O conceito de unidade se amplia devido ao encapsulamento;
• A integração foca nas classes e sua execução em cenários de uso.

Estratégias de Teste OO

• Classes são a menor unidade;
• O teste concentra-se nos estados dos objetos e suas interações (Thread-based, Use-case based, Cluster-based).

Projeto de Casos de Teste OO

• Testes baseados em cenários: concentram-se no que o usuário faz.
• Testes randômicos: identificam operações aplicáveis a uma classe e geram sequências de teste.

Um bom método e técnicas de teste são fundamentais para garantir sistemas confiáveis e com menos manutenção.