Entre a multiplicidade de respostas, portanto, ninguém tocou no particionamento de equivalência e análise do valor limite , considerações vitais na resposta à questão em questão.
Todas as outras respostas, embora úteis, são qualitativas, mas é possível - e preferível - ser quantitativo aqui. O @fishtoaster fornece algumas diretrizes concretas, apenas examinando os bastidores da quantificação de testes, mas o particionamento de equivalência e a análise do valor de limite nos permitem fazer melhor.
No particionamento de equivalência , você divide o conjunto de todas as entradas possíveis em grupos com base nos resultados esperados. Qualquer entrada de um grupo produzirá resultados equivalentes, portanto, esses grupos são chamados de classes de equivalência . (Observe que resultados equivalentes não não significam resultados idênticos.)
Como um exemplo simples, considere um programa que deve transformar caracteres ASCII em letras minúsculas em caracteres maiúsculos. Outros caracteres devem passar por uma transformação de identidade, ou seja, permanecem inalterados. Aqui está uma possível divisão em classes de equivalência:
| # | Equivalence class | Input | Output | # test cases |
+------------------------------------------------------------------------+
| 1 | Lowercase letter | a - z | A - Z | 26 |
| 2 | Uppercase letter | A - Z | A - Z | 26 |
| 3 | Non-alphabetic chars | [email protected]#,/"... | [email protected]#,/"... | 42 |
| 4 | Non-printable chars | ^C,^S,TAB... | ^C,^S,TAB... | 34 |
A última coluna relata o número de casos de teste, se você enumerar todos eles. Tecnicamente, pela regra 1 do @ fishtoaster você incluiria 52 casos de teste - todos aqueles para as duas primeiras linhas dadas acima se enquadram no "caso comum". @ A regra 2 do fishtoaster adicionaria algumas ou todas as linhas 3 e 4 acima também. Mas, com o teste de particionamento de equivalência, qualquer caso de teste um em cada classe de equivalência é suficiente. Se você selecionar "a" ou "g" ou "w", estará testando o mesmo caminho de código. Assim, você tem um total de 4 casos de teste em vez de 52 +.
Análise de valor limite recomenda um leve refinamento: essencialmente sugere que nem todo membro de uma classe de equivalência é, bem, equivalente. Ou seja, os valores nos limites também devem ser considerados merecedores de um caso de teste. (Uma justificativa fácil para isso é o infame erro direto !) Assim, para cada equivalência classe você poderia ter 3 entradas de teste. Olhando para o domínio de entrada acima - e com algum conhecimento de valores ASCII - eu poderia apresentar estas entradas de caso de teste:
| # | Input | # test cases |
| 1 | a, w, z | 3 |
| 2 | A, E, Z | 3 |
| 3 | 0, 5, 9, !, @, *, ~ | 7 |
| 4 | nul, esc, space, del | 4 |
(Assim que você obtém mais de 3 valores limites que sugerem que você pode querer repensar seus delineamentos de classe de equivalência original, mas isso foi simples o suficiente para não voltar a revisá-los.) Assim, a análise do valor limite nos traz até apenas 17 casos de teste - com uma alta confiança de cobertura completa - em comparação com 128 casos de teste para realizar testes exaustivos. (Sem mencionar que a combinatória dita que testes exaustivos são simplesmente impossíveis para qualquer aplicação do mundo real!)