Le "Guide du praticien pour la conception de tests logiciels" de Lee Copeland a été publié en 2003.
Depuis lors, il a fermement ancré dans la liste des livres que tout testeur doit lire. Cela vaut la peine d'être lu dans l'original. Il se lit très bien: la langue n'est pas compliquée, le style est facile. Au cours de l'ouvrage, l'auteur ironise légèrement sur lui-même, ses élèves, ses lecteurs et, en général, sur la sphère de notre activité.
Ce qui suit n'est pas une traduction, mais plutôt un résumé détaillé de la section «Black Box Testing Techniques», qui décrit l'application des techniques de conception de test.
Le livre est tombé entre mes mains sur les conseils d'un ancien collègue, pour lequel un merci spécial à lui.
Pour être le plus efficace et le plus efficace, le scénario de test doit être conçu et non pas simplement giflé.
Test de classe d'équivalence
Test de la valeur limite
Test de la table de décision
Test par paire
Test de transition d'état
Test de cas d'utilisation
Test de classe d'équivalence
Technique
- Définissez les classes d'équivalence.
- Créez des cas de test pour chaque classe d'équivalence.
Une classe d'équivalence est un ensemble de données qui exécute les mêmes modules et doit produire les mêmes résultats.
Toutes les données de la classe sont équivalentes, ce qui signifie que si un cas de test dans la boîte d'équivalence a découvert / non trouvé un défaut, tous les autres cas de test à l'intérieur de cette classe d'équivalence détecteront / ne trouveront pas le même défaut.
Une autre approche consiste à utiliser des classes d'équivalence non pas pour les entrées, mais pour les sorties. Divisez les variantes de sortie en classes d'équivalence, déterminez quelles valeurs d'entrée peuvent déclencher de telles sorties. L'avantage est que chaque option de sortie possible est vérifiée. L'inconvénient est qu'au sein de la classe d'équivalence en sortie, plusieurs classes d'équivalence en entrée peuvent être masquées.
S'il y a plusieurs variables:
- des classes valides de plusieurs variables sont combinées dans un cas de test;
- les classes invalides sont testées séparément.
Faites savoir à vos concepteurs et programmeurs lorsqu'ils vous ont aidé. Ils apprécieront cette pensée et pourront recommencer.
Test de la valeur limite
Technique
- Définir les classes d'équivalence
- Définissez les limites de chaque classe d'équivalence
- Créez des cas de test pour chaque valeur de limite, en choisissant un point directement sur la bordure, au-dessus et en dessous de la bordure.
Il ne faut pas oublier qu'un point au-dessus ou au-dessous de la limite peut être une instance d'une autre classe d'équivalence, auquel cas vous n'avez pas besoin de dupliquer le test.
Les valeurs sont déterminées par type. Si la limite est de 5, les points 4 et 6 sont testés pour le champ où les nombres entiers sont entrés, et les points 4.99 et 5.01 sont testés pour le champ où les montants en roubles et copecks sont entrés.
S'il y a plusieurs variables:
- les valeurs minimales des limites valides sont combinées dans un cas de test;
- les valeurs maximales des limites valides sont combinées dans un autre cas de test;
- les limites non valides sont testées séparément, comme c'est le cas avec les classes non valides.
Les tests de valeur limite se concentrent sur les limites car c'est là que se cachent tant de défauts.
Test de la table de décision
Technique
- Définissez toutes les conditions
- Faire toutes les combinaisons possibles de conditions
- Supprimez les combinaisons inutiles. Ceux dans lesquels la modification des valeurs n'a aucun effet sur le résultat (peu importe - DC) sont supprimés
- Définir les actions
- Créer des cas de test pour chaque combinaison
Table de décision - représente la relation entre les conditions composites et les actions résultantes.
Si la condition est une plage de valeurs, des tests sont en outre créés pour vérifier les valeurs au-dessus et en dessous de la limite.
En regardant attentivement le tableau, vous pouvez voir que dans les règles 1, 2, 3, 4, si le code de stock n'est pas valide, vérifier les conditions restantes n'a pas de sens. Les règles 5 et 6 peuvent être combinées, car la condition de vérification des fonds n'affecte pas le résultat. Les conditions qui n'affectent pas le résultat sont marquées comme «DC». Le tableau est converti:
Parce que il y a toujours la possibilité que la table ne soit pas convertie correctement ou que le code soit mieux écrit de manière incorrecte afin que la table d'origine soit toujours à portée de main.
Le célèbre testeur de logiciels Mick Jagger donne d'excellents conseils à ce sujet: «Vous ne pouvez pas toujours obtenir ce que vous voulez, mais si vous essayez parfois, vous pourriez trouver, vous obtenez ce dont vous avez besoin.»
Test de paire
Technique
- Définissez les paramètres
- Déterminer le nombre de valeurs pour chaque paramètre (choix de variable)
- Créez un tableau contenant des colonnes pour chaque paramètre et des valeurs dans des colonnes qui contiennent toutes les combinaisons des valeurs de ces paramètres entre elles.
- Faites correspondre le tableau orthogonal résultant à des fins de test.
- Créez des cas de test.
Il a été déterminé expérimentalement que la plupart des défauts sont soit des défauts monomode, soit des défauts double mode, c'est-à-dire manifesté lorsqu'un seul paramètre est combiné avec un seul autre paramètre, alors que la valeur des paramètres restants n'a pas d'importance.
Si le nombre de combinaisons de valeurs variables est important, vous ne devez pas essayer de tester toutes les combinaisons possibles, il est préférable de vous concentrer sur le test de toutes les paires de valeurs variables.
Deux approches de test par paire: la méthode des tableaux orthogonaux et l'algorithme allpair.
Un tableau orthogonal est un tableau à deux dimensions qui a une propriété spéciale: si vous sélectionnez deux colonnes dans le tableau, alors toutes les combinaisons possibles de valeurs de paramètres y seront présentes, toutes les paires de colonnes ont la même propriété.
Toutes les paires - pour créer un tableau, un algorithme est utilisé qui génère des paires directement, sans utiliser d'équilibrage supplémentaire. S'il existe un grand nombre de paramètres qui prennent un petit nombre de valeurs, cette méthode est meilleure pour l'appariement.
Il n'est pas nécessaire de faire des combinaisons par paire manuellement, pour cela il y a beaucoup d' outils .
Il convient de garder à l'esprit que des restrictions peuvent survenir du fait que certaines combinaisons de paramètres n'auront jamais lieu.
Il n'y a pas de «physique des défauts logiciels» sous-jacente qui garantit que les tests par paires seront avantageux. Il n'y a qu'une seule façon de le savoir - essayez-le.
Diagramme de transition d'état
Technique
État - Condition dans laquelle le système attend un ou plusieurs événements. L'état se souvient de ce qui a été reçu à l'entrée et détermine la réponse qui doit se produire. Cet événement peut être amené dans un nouvel état et / ou lancer une nouvelle action. L'état reflète généralement la valeur d'une variable du système. Représenté sous la forme d'un cercle.
Transition - Représente la transition de l'état actuel vers un nouvel état, suite à une action. Représenté sous forme de flèche.
Événement - L'événement qui a provoqué le changement d'état. Habituellement, un événement entre dans le système depuis le monde extérieur via une interface. Parfois, cet événement est déclenché à l'intérieur du système lui-même, par exemple, comme une minuterie, une chute en dessous d'un certain niveau. On pense que l'événement se produit instantanément. Un événement peut être indépendant ou lié. Lorsqu'un événement se produit, le système peut changer d'état ou rester dans le même état et / ou lancer une action. Les événements peuvent avoir des paramètres associés (numéro de carte, montant dans le compte). Représenté en légende de la flèche de transition.
Action - Une opération lancée à la suite d'un changement d'état. Il s'agit souvent d'une réponse du système. N'oubliez pas qu'une action se produit pendant la transition entre les états. Les États eux-mêmes sont statiques. Il est indiqué par une barre oblique dans la signature de la flèche de transition après l'événement.
Un diagramme de transition d'état est une entité spécifique (par exemple, un processus de sauvegarde). Une erreur courante est une tentative de mélanger différentes entités dans un même diagramme (par exemple, Réservation et Passager avec des événements et des actions associés à chacun d'eux).
Il peut être utilisé lorsque le système a besoin de connaître l'arrière-plan ou l'ordre correct des opérations.
Sur la base du diagramme de transition d'état, une table de transition d'état est compilée. Le tableau contient 4 colonnes: état actuel, événement, action, état suivant.
L'avantage de la table de transition d'état est qu'il s'agit d'une liste de toutes les combinaisons possibles de transitions d'état à état, y compris celles qui ne sont pas valides. Lors de l'analyse d'un tel tableau, des lacunes dans les exigences peuvent être constatées. L'utilisation d'une table de transition d'état peut vous aider à rechercher des transitions d'état non valides.
Vous pouvez choisir l'une des 4 options pour créer des cas de test:
- Créez des ensembles de cas de test pour que tous les états soient complétés au moins une fois. Dans un cas de test, une transition entre plusieurs états peut être décrite. Il s'agit d'un niveau de couverture de test plutôt faible.
- Créez des ensembles de cas de test pour que tous les événements soient déclenchés au moins une fois. Les cas de test qui couvrent tous les événements en même temps couvrent toutes les conditions. Encore une faible couverture de test.
- Créez des ensembles de cas de test de sorte que tous les chemins soient complétés au moins une fois. Cette méthode est bonne du point de vue de la couverture des tests, mais elle n'est pratiquement pas faisable. Si le diagramme a des cycles, le nombre de chemins possibles peut être infini.
- Créez des ensembles de cas de test pour que toutes les transitions soient effectuées au moins une fois. Cette méthode fournit un bon niveau de couverture de test, il est donc recommandé de l'utiliser.
La stratégie recommandée pour créer des cas de test consiste à tester toutes les transitions d' état au moins une fois. Dans les systèmes à haut risque où une couverture de test plus fiable est requise, il est possible de créer des cas de test pour chaque chemin (chaîne de transition) entre les états.
Et maintenant pour quelque chose de complètement différent. Monty Python
Test de cas d'utilisation
Technique
Cas d'utilisation - ce sont des scénarios qui décrivent comment un acteur (généralement une personne, mais peut-être un autre système) utilise le système pour atteindre un objectif spécifique. Les cas d'utilisation sont décrits du point de vue de l'utilisateur et non du système. Le travail interne pour maintenir l'intégrité du système ne fait pas partie du cas d'utilisation.
Au moins un scénario de test doit vérifier le scénario principal et au moins un scénario doit se trouver dans des scénarios alternatifs.
Utiliser les recommandations de cas de test de cas
- Commencez avec des données valides et les scénarios les plus courants.
- Vérifiez les valeurs limites et les valeurs non valides (en utilisant les techniques discutées précédemment).
- Scénarios rarement utilisés critiques pour le système (le soi-disant arrêt du réacteur nucléaire)
- Tests pour chaque branche d'extension de chaque étape
- Essayez d'effectuer l'opération d'une manière inhabituelle
- Pervert condition préalable si cela peut vraiment arriver
- Si une transaction a des boucles, exécutez-la en boucle, et pas une ou deux fois - soyez plus difficile
- Trouvez un chemin très long et sinueux et suivez-le
- S'il est prévu que la transaction sera exécutée dans un ordre logique, essayez de l'exécuter dans l'ordre inverse (par exemple, remplissez les champs non pas de haut en bas, mais de bas en haut)
- Créez des tests à toute épreuve
Modèle de description de cas d'utilisation
Si vous n'essayez pas de choses étranges. vous savez que les utilisateurs le feront.