Explicação

Nada proporciona satisfação maior ao usuário, com relação ao software, do que uma visão clara de suas expectativas, para que sejam verificadas e validadas. Os casos de teste refletem os requisitos que devem ser verificados. Entretanto, a verificação desses requisitos pode ser feita de forma diferente e por testadores distintos. Por exemplo, a execução do software para verificar sua função e desempenho pode ser feita por um testador usando técnicas de teste automatizadas, a seqüência de desligamento de um sistema de computadores pode ser realizada por teste manual e observação, ao passo que a participação no mercado e as vendas (também requisitos do produto) serão realizadas através da avaliação do produto e das vendas competitivas.

Como talvez você não consiga verificar todos os requisitos, nem seja responsável por isso, é essencial para o sucesso do projeto selecionar os requisitos mais apropriados e importantes para o teste. Os requisitos escolhidos para verificação representarão um equilíbrio entre o custo, o risco e a necessidade de verificá-los.

A identificação dos casos de teste é importante por vários motivos.

• Os casos de teste constituem a base do design e do desenvolvimento dos Scripts de Teste.
• A "profundidade" do teste é proporcional ao número de casos de teste. O aumento do número de casos de teste gera uma maior confiança na qualidade do produto e no processo de teste, já que cada caso de teste reflete um cenário, uma condição ou um fluxo diferente através do produto.
• A principal avaliação da abrangência do teste é a cobertura baseada em requisitos, de acordo com o número de casos de teste identificados, implementados e/ou executados. Uma declaração como "Executamos e verificamos 95% dos casos de teste críticos" é mais significativa do que a declaração "Executamos 95% do total de teste".
• A escala do esforço de teste é proporcional ao número de casos de teste. Com uma análise abrangente dos casos de teste, é possível estimar com mais precisão a duração dos estágios subseqüentes do ciclo de teste.
• Os tipos de design e desenvolvimento de testes e os recursos necessários são amplamente controlados pelos casos de teste.

Geralmente, os casos de teste são categorizados ou classificados pelo tipo ou requisito de teste ao qual estão associados e variam de acordo com isso. A prática consiste em desenvolver pelo menos dois casos de teste para cada requisito de teste:

• Um caso de teste demonstrará que o requisito foi atendido. Isso é chamado de um caso de teste positivo.
• Outro caso de teste, conhecido como negativo, refletindo uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o requisito só pode ser atendido sob a condição desejada.

Derivando Casos de Teste para Teste de Unidade

O teste unitário exige a avaliação da estrutura interna da unidade e de suas características comportamentais. O teste da estrutura interna requer um  conhecimento de como a unidade foi implementada. Os testes com base nesse conhecimento são denominados testes de caixa branca. O teste das características comportamentais de uma unidade concentram-se nos comportamentos da unidade que podem ser observados externamente, sem conhecimento nem preocupação com sua implementação. Os testes baseados nesse método são conhecidos como testes caixa preta. A obtenção de casos de teste com base nos dois métodos é descrita a seguir.

Teoricamente, você deve testar todo caminho possível através do código. Atingir essa meta nas unidades, embora sejam muito simples, é impraticável ou quase impossível. Na pior das hipóteses, você deve testar todos os caminhos decisão-a-decisão (caminho DD) pelo menos uma vez, o que resulta na execução de todas as instruções pelo menos uma vez. Em geral, uma decisão é uma instrução if, e um caminho DD é aquele que une duas decisões.

Para atingir esse nível de cobertura de teste, recomenda-se escolher dados de teste que permitam avaliar cada decisão de todas as maneiras possíveis. Com essa finalidade, os casos de teste devem garantir que:

• Toda expressão Booleana é avaliada como true e false. Por exemplo, a expressão (a<3) OR (b>4) avalia até quatro combinações de true/false
• Todo loop infinito é testado uma ou mais vezes, ou então não é testado.

Use as ferramentas de cobertura de código para identificar o código não experimentado pelo teste caixa branca. O teste de confiabilidade deve ser realizado simultaneamente com o teste caixa branca.

Exemplo:

Suponha que você execute um teste de estrutura em uma função membro na classe Conjunto de Inteiros. O teste - com a ajuda de uma procura binária - verifica se o conjunto contém um determinado número inteiro.

A função-membro e seu fluxograma correspondente. As setas pontilhadas ilustram como você pode usar dois casos de teste para executar todas as instruções pelo menos uma vez.

Teoricamente, para que uma operação seja totalmente testada, o caso de teste deve percorrer todas as combinações de rotas contidas no código. Em membro, há três rotas alternativas no loop while. O caso de teste pode percorrer o loop várias vezes ou nenhuma. Se o caso de teste não percorrer o loop, haverá apenas uma rota através do código. Se ele percorrer o loop uma vez, haverá três rotas. Se percorrer duas vezes, haverá seis rotas e assim por diante. Portanto, o número total de rotas será 1+3+6+12+24+48+..., que, na prática, é um número não gerenciável de combinações de rotas. Esse é o motivo pelo qual você deve escolher um subconjunto de todas as rotas. Neste exemplo, você pode usar dois casos de teste para executar todas as instruções. Em um caso de teste, você pode escolher Conjunto de Inteiros = {1,5,7,8,11} e t = 3 como dados de teste. No outro caso de teste, você pode escolher Conjunto de Inteiros = {1,5,7,8,11} e t = 8.

Consulte Técnica: Teste de Unidade para obter informações adicionais

Testes de Black-Box

A finalidade de um teste de caixa preta é verificar o comportamento especificado pela unidade, sem observar como a unidade implementa esse comportamento. Os testes caixa preta se concentram e se baseiam na entrada e saída da unidade.

Particionamento de Equivalência é uma técnica para reduzir o número necessário de testes. Para cada operação, você deve identificar as classes de equivalência dos argumentos e os estados dos objetos. Uma classe de equivalência é um conjunto de valores de acordo com os quais o objeto deve se comportar. Por exemplo, um Conjunto possui três classes de equivalência: vazio, algum elemento e cheio.

Use as ferramentas de cobertura de código para identificar o código não experimentado pelo teste caixa branca. O teste de confiabilidade deve ser realizado simultaneamente com o teste caixa preta.

As duas subseções a seguir descrevem como identificar os casos de teste através da seleção dos dados deteste para argumentos específicos.

Casos de Teste baseados em Argumentos de Entrada

Um argumento de entrada é aquele utilizado por uma operação. Você deve criar casos de teste utilizando argumentos de entrada para cada operação, em cada uma das condições de entrada a seguir: 

• Valores normais de cada classe de equivalência.
• Valores na fronteira de cada classe de equivalência.
• Valores fora das classes de equivalência.
• Valores inválidos.

Lembre-se de tratar o estado do objeto como um argumento de entrada. Se, por exemplo, você testar uma operação incluir em um objeto Conjunto, deverá testar incluir com valores de todas as classes de equivalência do Conjunto, ou seja, com um Conjunto completo, com algum elemento no Conjunto e com um Conjunto vazio.

Casos de Teste baseados em Argumentos de Saída

Um argumento de saída é um argumento alteração por uma operação. Um argumento pode ser de entrada ou de saída. Selecione a entrada para que você obtenha a saída de acordo com cada uma das seguintes.

• Valores normais de cada classe de equivalência.
• Valores na fronteira para cada classe de equivalência.
• Valores fora das classes de equivalência.
• Valores inválidos.

Lembre-se de tratar o estado do objeto como um argumento de saída. Se, por exemplo, você testar uma operação remover em uma Lista, deverá escolher valores de entrada de modo que a Lista fique cheia, tenha algum elemento e fique vazia após a execução da operação (teste com valores de todas as respectivas classes de equivalência).

Se o objeto for controlado por estado (a reação varia de acordo com o estado do objeto), você deve usar uma matriz de estado, conforme a mostrada na figura a seguir.

Uma matriz de estado para teste. Você pode testar todas as combinações de estado e de estímulos na base da matriz.

Consulte Técnica: Teste de Unidade para obter informações adicionais