Un champ accepte une quantité de 1 à 100. Quels cas de test écririez-vous ?

Utilisez le partitionnement en classes d'équivalence plus l'analyse des valeurs limites. Les partitions sont sous la plage, dans la plage valide et au-dessus de la plage, donc un représentant de chacune. Les limites sont la partie intéressante : 0, 1, 2, 99, 100, 101. Ajoutez ensuite les cas non numériques : vide, négatif, décimal, espaces, très grands nombres et texte, plus le comportement du champ au collage plutôt qu'à la saisie.

J'utiliserais le partitionnement en classes d'équivalence pour découper l'espace, puis l'analyse des valeurs limites pour les parties intéressantes. Les partitions sont en dessous de un, de un à cent, et au-dessus de cent, donc une valeur de chacune couvre les classes. Puis les limites, là où vivent réellement les défauts, parce que le décalage d'une unité est l'erreur la plus courante dans un test de plage : 0, 1, 2, 99, 100 et 101. Si je ne peux exécuter que six cas, ce sont ces six-là. Ensuite je m'attaque à tout ce qui n'est pas un entier bien élevé, parce que c'est là que la validation est oubliée : vide, une seule espace, un négatif, un décimal comme 1.5, un zéro en tête, un nombre très long qui déborde le type derrière, la notation scientifique, et du texte brut. Je teste aussi la méthode de saisie, parce que taper, coller et cliquer sur les flèches du navigateur passent souvent par des chemins de code différents, et j'ai trouvé des bugs où la saisie était validée et le collage non. Et je vérifie le serveur, pas seulement le navigateur, en envoyant 101 directement à l'API, puisque la validation côté client est un confort et non un contrôle.