Parmi la pléthore de réponses à ce jour, personne n’a abordé le partitionnement de l’équivalence et l’ analyse des valeurs limites , considérations essentielles dans la réponse à la question posée. Toutes les autres réponses, bien qu'utiles, sont qualitatives, mais il est possible - et préférable - d'être quantitatives ici. @fishtoaster fournit des indications concrètes, jetant un coup d'œil sous le couvert de la quantification de test, mais le partitionnement par équivalence et l'analyse des valeurs limites nous permettent de faire mieux.
Dans la partition d'équivalence , vous divisez l'ensemble des entrées possibles en groupes en fonction des résultats attendus. Toute entrée d'un groupe donnera des résultats équivalents, de tels groupes s'appellent des classes d'équivalence . (Notez que des résultats équivalents ne signifient pas des résultats identiques.)
Comme exemple simple, considérons un programme qui devrait transformer des caractères ASCII minuscules en caractères majuscules. Les autres personnages doivent subir une transformation d'identité, c'est-à-dire rester inchangés. Voici une ventilation possible en classes d'équivalence:
| # | 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 | 0-9!@#,/"... | 0-9!@#,/"... | 42 |
| 4 | Non-printable chars | ^C,^S,TAB... | ^C,^S,TAB... | 34 |
La dernière colonne indique le nombre de tests si vous les énumérez tous. Techniquement, selon la règle 1 de @ fishtoaster, vous incluez 52 cas tests - tous ceux des deux premières lignes indiquées ci-dessus entrent dans le "cas commun". La règle 2 de @ fishtoaster ajoute également tout ou partie des rangées 3 et 4 ci-dessus. Toutefois, avec le test de partitionnement par équivalence, un seul cas de test dans chaque classe d'équivalence est suffisant. Si vous choisissez "a" ou "g" ou "w", vous testez le même chemin de code. Ainsi, vous avez un total de 4 cas de test au lieu de 52+.
L'analyse de la valeur limite recommande un léger raffinement: elle suggère essentiellement que tous les membres d'une classe d'équivalence ne sont pas équivalents. C'est-à-dire que les valeurs aux limites doivent également être considérées comme dignes d'un cas test à part entière. (Une erreur simple en est la fameuse erreur off-by-one !) Ainsi, pour chaque classe d'équivalence, vous pouvez avoir 3 entrées de test. En regardant le domaine d'entrée ci-dessus - et avec une certaine connaissance des valeurs ASCII -, je pourrais arriver avec ces entrées de scénario de test:
| # | Input | # test cases |
| 1 | a, w, z | 3 |
| 2 | A, E, Z | 3 |
| 3 | 0, 5, 9, !, @, *, ~ | 7 |
| 4 | nul, esc, space, del | 4 |
(Dès que vous obtenez plus de 3 valeurs limites, cela suggère que vous voudriez peut-être repenser vos délinéations de classes d'équivalence d'origine, mais c'était assez simple pour que je ne revienne pas les réviser.) Ainsi, l'analyse des valeurs limites nous amène à 17 cas de test - avec une confiance élevée en couverture complète - comparés à 128 cas de test exhaustifs. (Sans compter que la combinatoire indique qu'un test exhaustif est tout simplement irréalisable pour toute application réelle!)