Estratégias para testes de software

Estratégias para teste de software URL

• Testes de módulos atômicos
• Usa testes de caixa branca
• Testes de integração
• Testes de validação
• Caixa preta
• Testes de sistema
• Desempenho, segurança
• Testes de aceitação
• No ambiente do usuário

Testes de módulos atômicos

• Testar condições limite
• Todos os caminhos são testados (método caminho básico)
• Usa-se Drives que são chamadas aos módulos (que simulam um modulo ainda não testado)

Testes de integração

Consiste em se integrar os módulos do sistema. Possui duas abordagens:

• Bottom-up
• Parte para os módulos no nível mais baixo. Os módulos são agrupados em clusters para que fique mais fácil de testar e cria-se drivers que vão simular uma parte superior na estrutura da hierarquia dos módulos que ainda não foi testada. 
• Vantagem: São mais simples que o top-down.
• Top-down
• Parte para os módulos de nível mais alto. Há duas formas de percorrer os módulos para testes: Profundidade - testa-se verticalmente até chegar numa folha - e Largura no qual se testa horizontalmente cada nível. 
• Stubs = mock

Testes de validação

• Uma sequencia de testes de caixa-preta que demonstram a funcionalidade dos requisitos.
• Os casos de teste devem ser montados seguindo a especificação de requisitos
• Depois de realizar cada caso de teste, vão existir uma das opções
1. Teste é aceito 
2. Uma lista de deficiências é criada

Testes de sistema

Tem como objetivo colocar o sistema à prova. Tipo mais comuns:

• Testes de recuperação: forçar o sistema a falhar e ver a recuperação do sistema
• Testes de segurança: verificar os mecanismos de segurança do sistema. Senhas, proteção de acesso a funções. recomendável um especialista.
• Teste de stress: consiste em testar o programa em situações limite
• Testes de desempenho: realizado para testar os requisitos de desempenho descritos na especificação. Deve ocorrer ao longo de todos os passos do processo de testes. Confundido com teste de stress.

Testes de aceitação

Visam especificamente capacitar clientes a validar seus requisitos. Realizado exclusivamente pelo usuário final. 

• Alfa teste: realizado nas instalações do desenvolvedor
• Beta teste: realizado nas instalações do cliente

Revisões formais

As revisões capturam erros durante as etapas de desenvolvimento e evita que esses erros sejam descobertos no fim do desenvolvimento.

Tipos de revisões:

• Revisão de especificação é uma revisão em que os requisitos e especificações do usuário são revisados
• Revisão de interface do usuário: preocupa-se com os formatos de entrada e saída, layout de tela, relatório, posição dos componentes na tela, etc. Do campo IHC.
• Revisão de projeto é revisão dada nas decisões de implementação, arquitetura de software, técnicas empregadas, etc.
• Revisão de código: verifica o código fonte
• Revisão de teste: conduzidas para que os dados de teste sejam adequados ao sistema, não pra examinar a saída do teste.

Papeis:

• Apresentador: a tarefa é introduzir o produto, apresenta o produto numa reunião.
• Coordenador: responsável para que as atividades sejam organizadas e atua também como moderador.
• Secretário copista: tomar notas durante da revisão
• Oráculo da manutenção: rever o produto sobre manutenções futuras
• Portador de padrões: especialista em engenharia de software que verifica se normas e padrões estão sendo seguidos
• Representante do usuário: verifica se os requisitos estão sendo atendidos
• Especialista na área do sistema: verifica se o sistema está correto na área da especialidade. Ex.: folha de pagamento.

Responsabilidades do autor

• Anunciar sua intenção de fazer uma revisão
• Escolher participantes e coordenador
• Fornecer material apropriado para a revisão
• Escolher um produto que possa ser revisado em no máximo 60min.

Responsabilidades do coordenador

• Assegurar que a revisão aconteça;
• que os participantes atendam a revisão
• Distribuir o material para a revisão

Responsabilidades dos outros membros

• Ler documentação fornecida antes da reunião (1 hora)

Ao final da revisão:

• Coordenador notifica a gerencia
• É distribuída uma cópia da ata aos participantes
• Produtor vai realizar as ações descritas na ata

Testes de Caixa-Preta

3 métodos para geração de testes de caixa

Método 1: Partição de Classes de Equivalência

São casos de testes baseado na geração de valores típicos da entrada do programa.

Classe de Equivalência

É um subconjunto das entradas possíveis do programa

Passos do método:

1. Definir as condições de entrada
• Faixa de Valores: 1 < ITEM < 1000
• Conjunto ordenado: vetor de até 6 elementos
• Conjunto de Valores: Enum
• Condição booleana
2. Definir as classes de equivalência: conjunto de valores que se entra no programa
• Classe válida: 1 < ITEM < 1000
• Classe inválida: ITEM <= 1 e ITEM >= 1000
• As classes são divididas de acordo com o número de condições do programa
3. Identificação dos casos de teste
• Enumerar as classes de equivalência
• Fazer os casos de teste para as classes válidas, as vezes com poucos casos de teste já possível englobar um número grande de classes válidas. 
• Fazer os casos de teste para as classes inválidas, se for o caso, um caso de teste para cada classe inválida.

Método 2: Grafo de Causa e Efeito

É baseado na análise das entradas do programa e saídas possíveis. A diferença do primeiro é que são todas formatadas para um formato booleano.

Seja um programa simples que recebe dois tokens, as entradas possíveis são

1. Primeiro token MOVTOX
2. Primeiro token MOVTOY
3. Segundo token é a letra de A a Z

Efeitos identificados

70-Comando correto

71-Mensagem M1 (msg de erro significa não é o token MOVTOX ou MOVTOY)

72-Mensagem M2 (msg de erro significa não de token de A a Z

Método 3: Análise de valores de fronteira

Trabalha especificamente com os valores que estejam próximos aos intervalos de validade de entrada do programa. Testa valores focados nas fronteiras dos intervalos.

Princípio da Timidez: os bugs se encontram escondidos nos detalhes do programa.

Ex.: Se os extremos da faixa são os valores a e b, geramos os seguintes casos de teste:

• Entrada sobre a (sobre a fronteira inferior)
• Entrada sobre  a - um valor bem pequeno (um pouco abaixo da fronteira inferior)
• Entrada sobre b (sobre a fronteira superior)
• Entrada sobre b + um valor bem pequeno (um pouco acima da fronteira superior)

Introdução e Testes de Caixa-Branca

O objetivo principal de qualquer técnica de testes é maximizar a relação percentagem de defeito sobre o número de testes feitos. O ideal é fazer o menor número de teste e testar a maior parte do sistema todo.

Princípios

• Testar completamente é impossível
• Testar é um trabalho criativo e difícil
• Testes devem ser planejados e projetados
• Teste requer independência (sem vícios)

Conceitos

• Casos de teste: conjunto de entradas possíveis do programa
• Métodos de teste: métodos para se gerar casos de teste
• Caixa branca ou estruturais
• Caixa preta

Métodos de Testes de Caixa Branca

Cobertura Lógica

São critérios que devem ser obedecidos para determinar os casos de testes.

Fatores para escolha dos critérios:

• Complexidade do programa a se testar
• Estrutura do programa a ser testado
• Criticidade do programa a se testar
• Nível de confiança que se deseja atingir

Critérios

• Cobertura de comandos
• Todos os comandos que existem no programa a ser testado sejam executados
• Cobertura de decisões
• O teste deve passar por todas as decisões do programa nos dois casos (verdadeiro e falso) pelo menos uma vez.
• Cobertura de decisões-condições
• Cobertura de múltiplas condições
• Combinar todas as possibilidades nas duas decisões dadas no exemplo.

Método dos caminhos básicos

• Fortemente embasado na teoria de grafos
• Os casos de testes gerados passem por um número ótimo de caminhos entre a entrada e saída do programa

Definições

• Grafo de controle: descreve o fluxo do programa
• Caminhos independentes: é um caminho que não é constituído pela combinação de dois ou mais outros (não apresenta redundância).
• Existem 3 formas de se contar o número de caminhos independentes (Complexidade Ciclomática)
• Número de regiões: contar o número de regiões (blocos dentro do IF) e uma externa
• C = E -N +2 onde, C número de caminhos independentes, E número de arestas e N número de nós.
• Número de estruturas de decisão + 1

Geração dos casos de teste

Cada caminho independente gera um caso de teste