J'oublierai de discuter ici des techniques de conception de tests bien connues et largement utilisées telles que les classes d'équivalence, les tests de valeurs limites et les tests par paires, je discuterai d'autres techniques moins courantes. Vous pouvez également lire mon article sur   . les problèmes liés aux techniques de conception de tests combinatoires  Test de table de décision  Les tables de décision sont un excellent outil pour documenter les exigences et décrire les fonctionnalités d’une application. Ces tableaux sont très pratiques pour décrire la logique métier de l’application et, en plus de cela, ils peuvent servir de base solide pour créer des cas de test. Si l'application testée ne dispose pas d'une documentation appropriée, c'est une bonne raison d'utiliser des tables de décision. La présentation des exigences sous une forme compacte et simple facilite la création de cas de test.   Approche:  Les tables de décision décrivent la logique de l'application en fonction des entités (propriétés/conditions) de l'état du système. Chaque table de décision ne doit décrire qu'un seul état du système.  règle 1  règle 2  …  règle SUBST   Entités  Propriété 1  …  Propriété M   Actions  Action 1  …  Action P  L'entité (Propriété) de 1 à M représente diverses propriétés du système ; elles sont présentées dans le tableau comme données d'entrée pouvant être saisies dans le système. Les actions de 1 à P sont des actions qui peuvent se produire avec la combinaison d'entités spécifiée. En fonction de la combinaison de toutes les données d'entrée des entités, les actions prennent les valeurs nécessaires. Chaque règle définit un ensemble unique de données d'entrée pour toutes les propriétés qui conduisent à l'exécution d'actions spécifiques.  Après avoir composé le tableau de décision, il est généralement possible de le simplifier, par exemple en supprimant tout ou partie des scénarios impossibles. Ensuite, le tableau peut être transformé en cas de tests.  Tests de transition d'état  Les tests de transition d'état, comme les tests de table de décision, sont un outil précieux pour documenter les exigences et décrire la structure et la conception d'un système. Contrairement aux tests des tables de décision, qui décrivent un état spécifique du système, les tests de transition d'état décrivent comment ces états du système peuvent changer. Les diagrammes définissent tous les événements qui se produisent pendant le fonctionnement de l'application et la manière dont l'application répond à ces événements.   Approche:  Il existe deux types de représentations visuelles de cette technique :  Diagrammes d'état-transition  Tableaux d'état-transition  Diagrammes d'état-transition  A titre d'exemple, considérons la réservation de billets d'avion. Son fonctionnement est à peu près le suivant : initialement, les clients fournissent à la compagnie aérienne des informations pour la réservation : lieu de départ, destination, date et heure de départ. Un employé de la compagnie aérienne sert d'interface entre le client et le système de réservation de billets, utilisant les informations fournies par le client pour créer une réservation. Après cela, la réservation du client est à l'état « Effectuée ». De plus, après avoir créé la réservation, le système démarre un minuteur. Lorsque le délai expire et que le billet réservé n'a pas été payé, le système annule la réservation de ce billet.   Le cercle représente l’état du système de réservation de billets d’avion, l’état « Made ». La flèche indique une transition vers l'état "Made". La description sous la flèche ("get_info") est un événement provenant de l'extérieur du système. La commande dans la description sous la flèche (après "/") signifie que le système a effectué une action en réponse à l'événement - dans ce cas, en déclenchant une minuterie. Le cercle noir indique le point de départ/d’entrée du diagramme.   Si le délai n'expire pas et que nous avons payé le billet réservé, le système passe à l'état « Payé ». Ceci est représenté par la flèche intitulée "payMoney" et la transition de l'état "Made" à l'état "Paid".    (représenté par un cercle sur le schéma)   C'est l'état du système dans lequel il attend un ou plusieurs événements. L'état mémorise les données d'entrée reçues jusqu'à présent et indique comment le système réagira aux événements reçus. Les événements peuvent déclencher des actions et/ou conduire à un changement d’état. Etat :    (représentée sur le schéma par une flèche)   Ceci représente une transition d'un état à un autre, survenant suite à un événement. Transition :    (représenté par un rectangle au-dessus de la flèche)   Un événement est quelque chose qui amène l'application à changer d'état. Les événements peuvent provenir de l'extérieur de l'application, par exemple via l'interface utilisateur de l'application. Simultanément, l'application elle-même peut générer des événements, par exemple un événement tel que « minuterie expirée ». Lorsqu'un événement se produit, l'application peut rester dans le même état, changer d'état ou effectuer une action. Les événements peuvent avoir des paramètres ; par exemple, l'événement « pay_money » peut avoir des paramètres tels que « Cash », « Check », « DebitCard » ou « CreditCard ». Événement :    (représentée après "/" dans le label au dessus de la transition)   Il s'agit d'une action initiée par un changement d'état. Il peut s'agir d'actions telles que « imprimer un ticket », « afficher à l'écran », etc. En règle générale, les actions créent des sorties qui servent de données de sortie du système. Les actions se produisent pendant les transitions ; les États eux-mêmes sont passifs. Action :    est représenté sur le diagramme par un point noir. Le point d'entrée    est indiqué sur le schéma sous la forme d'un symbole « cible ». Le point de sortie  Tableaux d'état-transition  Les tables de transition d'état sont des tables composées de quatre colonnes : État actuel, Événement, Action et État suivant.  L’avantage des tables de transition d’état est qu’elles définissent tous les scénarios de transition d’état possibles, pas seulement les bons. Par conséquent, les tables d’état-transition conduisent souvent à la découverte de combinaisons état-transition non définies et non documentées, qu’il est préférable d’identifier avant d’écrire le code.  Les diagrammes d'état et de transition peuvent être facilement utilisés pour créer des cas de test. Il est nécessaire de créer un ensemble de cas de test qui doivent couvrir toutes les transitions au moins une fois.  À partir des tables de transition d'état, il est également relativement simple de générer des cas de test. Il faut parcourir toutes les combinaisons valides (si le temps le permet ou si les risques ne l'interdisent pas, il est également possible de parcourir toutes les combinaisons invalides).  Tableaux orthogonaux  Combien de combinaisons existe-t-il pour la paire de valeurs « 1 » et « 2 » ? {1,1}, {1,2}, {2,1} et {2,2}. Un tableau orthogonal est un tableau bidimensionnel avec une propriété spéciale : dans deux colonnes quelconques du tableau, toutes les combinaisons de valeurs dans ces colonnes sont présentes. Autrement dit, si vous prenez deux colonnes du tableau orthogonal, où les valeurs ne peuvent être que "1" ou "2", vous trouverez les lignes suivantes pour ces colonnes - {1,1}, {1,2}, { 2,1} et {2,2}.  A titre d'exemple, considérons un système avec trois paramètres d'entrée, dont chacun est binaire (c'est-à-dire prend la valeur « 1 » ou « 2 »).  Lignes  variable 1  variable 2  variable 3   1  1  1  1   2  2  1  1   3  1  2  1   4  1  1  2   5  2  2  1   6  1  2  2   7  2  1  2   8  2  2  2  Le tableau orthogonal est représenté par - L_4(2^3), où L_4 indique que le tableau orthogonal comporte quatre lignes et (2^3) indique que le tableau comporte trois colonnes, avec des valeurs qui peuvent être "1" ou "2". ".  Lignes  variable 1  variable 2  variable 3   1  1  1  1   2  1  2  2   3  2  1  2   4  2  2  1  L_4, où 4 est le nombre de lignes  2^3, où 2 est la valeur maximale (== 2, 3,…, N) et 3 est le nombre de colonnes  Tableau orthogonal - est un tableau bidimensionnel avec la propriété suivante : choisissez deux colonnes du tableau et vous trouverez toutes les combinaisons de valeurs dans ces colonnes.  Utilisation de tableaux orthogonaux :  Identifiez les variables (nombre de données d’entrée). Il est nécessaire de sélectionner les données d'entrée, toutes les combinaisons de valeurs qui peuvent logiquement exister.  Déterminez le nombre de valeurs que chaque variable peut prendre. Au moment où le nombre de valeurs est déterminé, d'autres techniques de conception de tests devraient déjà avoir été appliquées pour réduire le nombre de valeurs (par exemple, valeurs limites, classes d'équivalence et autres).  Déterminez un tableau orthogonal où il y aura une colonne pour chaque variable (la colonne du tableau orthogonal a autant d'options de valeur que la variable).  Projetez la tâche de test sur le tableau orthogonal.  Rédiger des cas de tests.  Algorithme toutes les paires  L'essence de l'algorithme AllPairs est qu'il n'est pas nécessaire de tester toutes les combinaisons de valeurs pour toutes les variables. Au lieu de cela, il se concentre sur le test de toutes les combinaisons de valeurs pour chaque paire de variables.  En tant que professionnel de l’assurance qualité, il est important de comprendre ces nuances. Bien que théorique dans certains cas, la compréhension de la complexité des techniques de conception de tests combinatoires permet aux professionnels de l'assurance qualité de tester efficacement la logique métier complexe des applications et de fournir des logiciels de haute qualité à leurs utilisateurs.

This story contains new, firsthand information uncovered by the writer.

About Me

Read My Articles

Hire Me

Cet audio est produit dans la langue originale de l'histoire !

Une analyse des techniques de conception de tests combinatoires

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps