Uma análise de técnicas de design de testes combinatórios

Omitirei a discussão aqui de técnicas de design de teste bem conhecidas e amplamente utilizadas, como classes de equivalência, teste de valor limite e teste de pares; discutirei outras técnicas menos comuns. Você também pode ler meu artigo sobre problemas com técnicas de design de testes combinatórios .

Teste de tabela de decisão

As tabelas de decisão são uma excelente ferramenta para documentar requisitos e descrever a funcionalidade de uma aplicação. Essas tabelas são muito convenientes para descrever a lógica de negócio da aplicação e, além disso, podem servir como uma base sólida para a criação de casos de teste. Se o aplicativo testado não tiver documentação adequada, é um bom motivo para usar Tabelas de Decisão. Apresentar requisitos de forma compacta e simples facilita bastante a criação de casos de teste.

Abordagem:

As Tabelas de Decisão descrevem a lógica da aplicação com base nas entidades (propriedades/condições) do estado do sistema. Cada tabela de decisão deve descrever apenas um estado do sistema.

Entidade (Propriedade) de 1 a M representa diversas propriedades do sistema; eles são apresentados na tabela como dados de entrada que podem ser inseridos no sistema. Ações de 1 a P são ações que podem ocorrer com a combinação especificada de entidades. Dependendo da combinação de todos os dados de entrada das entidades, as ações assumem os valores necessários. Cada regra define um conjunto exclusivo de dados de entrada para todas as propriedades que levam à execução de ações específicas.

Depois de compor a tabela de decisão, geralmente é possível simplificá-la, por exemplo, removendo alguns ou todos os cenários impossíveis. Então, a tabela pode ser transformada em casos de teste.

Teste de transição de estado

O teste de transição de estado, assim como o teste de tabela de decisão, é uma ferramenta valiosa para documentar requisitos e descrever a estrutura e o design de um sistema. Ao contrário dos testes de tabelas de decisão, que descrevem um estado específico do sistema, os testes de transição de estado descrevem como esses estados do sistema podem mudar. Os diagramas definem todos os eventos que ocorrem durante a operação do aplicativo e como o aplicativo responde a esses eventos.

Abordagem:

Existem dois tipos de representações visuais desta técnica:

1. Diagramas de Transição de Estado
2. Tabelas de transição de estado

Diagramas de Transição de Estado

Como exemplo, consideremos a reserva de passagens aéreas. Funciona aproximadamente da seguinte forma: Inicialmente, os clientes fornecem à companhia aérea informações para reserva - local de partida, destino, data e hora de partida. Um funcionário da companhia aérea atua como interface entre o cliente e o sistema de reserva de passagens, utilizando as informações fornecidas pelo cliente para criar uma reserva. Depois disso, a reserva do cliente fica no estado “Feita”. Além disso, após a criação da reserva, o sistema inicia um cronômetro. Quando o cronômetro expirar e o bilhete reservado não tiver sido pago, o sistema cancelará a reserva desse bilhete.

O círculo representa o estado do sistema de reserva de passagens aéreas, o estado “Feito”. A seta indica uma transição para o estado "Feito". A descrição abaixo da seta ("get_info") é um evento originado de fora do sistema. O comando na descrição abaixo da seta (após "/") significa que o sistema executou alguma ação em resposta ao evento - neste caso, iniciando um cronômetro. O círculo preto indica o ponto inicial/entrada do diagrama.

Se o cronômetro não expirar e tivermos pago o bilhete reservado, o sistema entra no estado “Pago”. Isso é representado pela seta denominada "payMoney" e pela transição do estado "Feito" para o estado "Pago".

• Estado (representado como um círculo no diagrama) : Este é o estado do sistema onde aguarda um ou mais eventos. O estado lembra os dados de entrada recebidos até o momento e indica como o sistema reagirá aos eventos recebidos. Os eventos podem desencadear ações e/ou levar a uma mudança de estado.
• Transição (representada no diagrama como uma seta) : Representa uma transição de um estado para outro, ocorrendo devido a um evento.
• Evento (representado como um retângulo acima da seta) : Um evento é algo que faz com que o aplicativo mude de estado. Os eventos podem vir de fora do aplicativo, como por meio da interface do usuário do aplicativo. Simultaneamente, o próprio aplicativo pode gerar eventos, por exemplo, um evento como “temporizador expirado”. Quando ocorre um evento, o aplicativo pode permanecer no mesmo estado, alterar o estado ou executar uma ação. Os eventos podem ter parâmetros; por exemplo, o evento "pay_money" pode ter parâmetros como "Dinheiro", "Cheque", "Cartão de Débito" ou "Cartão de Crédito".
• Ação (representada após "/" no rótulo acima da transição) : Esta é uma ação iniciada por uma mudança de estado. Podem ser ações como “imprimir ticket”, “exibir na tela” etc. Normalmente, as ações criam saídas que servem como dados de saída do sistema. As ações ocorrem durante as transições; os próprios estados são passivos.
• O ponto de entrada é mostrado no diagrama como um ponto preto.
• O ponto de saída é mostrado no diagrama como um símbolo de "alvo".

Tabelas de transição de estado

As tabelas de transição de estado são tabelas que consistem em quatro colunas: Estado Atual, Evento, Ação e Próximo Estado.

A vantagem das Tabelas de Transição de Estado é que elas definem todos os cenários possíveis de Transição de Estado, não apenas os corretos. Portanto, as Tabelas de Transição de Estado geralmente levam à descoberta de combinações de Transição de Estado indefinidas e não documentadas, que são melhores para identificar antes de escrever o código.

• Os diagramas de transição de estado podem ser facilmente usados para criar casos de teste. É necessário criar um conjunto de casos de teste que cubra todas as transições pelo menos uma vez.
• A partir de tabelas de transição de estado, também é relativamente simples gerar casos de teste. É necessário passar por todas as combinações válidas (se o tempo permitir ou os riscos não proibirem, é possível passar por todas as combinações inválidas também).

Matrizes ortogonais

Quantas combinações existem para o par de valores “1” e “2”? {1,1}, {1,2}, {2,1} e {2,2}. Uma matriz ortogonal é uma matriz bidimensional com uma propriedade especial – em quaisquer duas colunas da matriz, todas as combinações de valores nessas colunas estão presentes. Ou seja, se você pegar quaisquer duas colunas da matriz ortogonal, onde os valores só podem ser "1" ou "2", você encontrará as seguintes linhas para essas colunas - {1,1}, {1,2}, { 2,1} e {2,2}.

Como exemplo, considere um sistema com três parâmetros de entrada, cada um dos quais é binário (ou seja, assume o valor “1” ou “2”).

A matriz ortogonal é representada como - L_4 (2 ^ 3), onde L_4 indica que a matriz ortogonal possui quatro linhas e (2 ^ 3) indica que a matriz possui três colunas, com valores que podem ser "1" ou "2 ".

L_4, onde 4 é o número de linhas

2 ^ 3, onde 2 é o valor máximo (== 2, 3,…, N) e 3 é o número de colunas

Matriz Ortogonal - é uma matriz bidimensional com a seguinte propriedade: escolha quaisquer duas colunas da matriz e você encontrará todas as combinações de valores nessas colunas.

Usando matrizes ortogonais:

1. Identifique variáveis (número de dados de entrada). É necessário selecionar dados de entrada, quaisquer combinações de valores que possam existir logicamente.
2. Determine o número de valores que cada variável pode assumir. No momento em que o número de valores for determinado, outras técnicas de projeto de teste já deverão ter sido aplicadas para reduzir o número de valores (por exemplo, valores limite, classes de equivalência e quaisquer outros).
3. Determine um array ortogonal onde haverá uma coluna para cada variável (a coluna do array ortogonal possui tantas opções de valor quanto a variável).
4. Projete a tarefa de teste na matriz ortogonal.
5. Escreva casos de teste.

Algoritmo Todos os Pares

A essência do algoritmo AllPairs é que não há necessidade de testar todas as combinações de valores para todas as variáveis. Em vez disso, concentra-se em testar todas as combinações de valores para cada par de variáveis.