state transition testing technique
Découvrez ce qu'est le test de transition d'état et comment utiliser le diagramme de transition d'état:
Dans notre dernier article, nous avons vu le ' Graphique des causes et des effets ’Technique d’écriture de cas de test. Aujourd'hui, passons à la prochaine méthode d'écriture de cas de test dynamique - la technique de transition d'état.
Ce document explore l’extension de ce concept de test à des applications plus grandes, qui ne sont pas des FSM dans leur ensemble, mais que certains de leurs composants le sont, de manière à adopter sa caractéristique unique «d’être avec état» et de règles de transition, ce qui présente de nombreux avantages.
Test de transition d'état
Le test de transition d'état est un Technique de test en boîte noire , qui peut être appliquée pour tester les «machines à états finis».
Une «machine à états finis (FSM)» est un système qui sera dans différents états discrets (comme «prêt», «pas prêt», «ouvert», «fermé»,…) en fonction des entrées ou des stimuli.
Les états discrets avec lesquels aboutit le système dépendent des règles de transition du système. Autrement dit, si un système donne une sortie différente pour la même entrée, en fonction de son état antérieur, alors il s'agit d'un système à états finis.
De plus, si chaque transaction est testée dans le système, on parle de couverture «0-switch». Si le test couvre 2 paires de transactions valides, alors il s'agit d'une couverture «à 1 commutateur», et ainsi de suite.
Ce que vous apprendrez:
Quelle est la technique de test de transition d'état?
La technique de transition d'état est une technique de test dynamique, qui est utilisée lorsque le système est défini en termes d'un nombre fini d'états et que les transitions entre les états sont régies par les règles du système.
Ou en d'autres termes, cette technique est utilisée lorsque les caractéristiques d'un système sont représentées comme des états qui se transforment les uns dans les autres. Les transformations sont déterminées par les règles du logiciel. La représentation picturale peut être représentée comme:
Donc ici nous voyons qu'une entité transitions de l'État 1 à l'État 2 en raison de certains saisir condition, ce qui conduit à un un événement et aboutit à action et donne enfin le production .
Pour l'expliquer avec un exemple:
Vous visitez un guichet automatique et retirez 1000 $. Vous obtenez votre argent. Maintenant, vous manquez de solde et faites exactement la même demande de retrait de 1000 $. Cette fois, ATM refuse de vous donner de l'argent en raison d'un solde insuffisant. Alors, voici le transition , qui a causé le changement d'état est le retrait le plus tôt
Définition du test de transition d'état
Après avoir compris ce qu'est la transition d'état, nous pouvons maintenant arriver à une définition plus significative des tests de transition d'état. Il s'agit donc d'une sorte de test boîte noire dans lequel le testeur doit examiner le comportement de AUT (Application Under Test) par rapport à diverses conditions d'entrée données dans une séquence.
Le comportement du système est enregistré pour les valeurs de test positives et négatives.
Quand utiliser les tests de transition d'état?
Les tests de transition d'état peuvent être utilisés dans les situations suivantes:
tests pilotés par les données dans soapui à l'aide d'un script groovy
- Lorsque l'application testée est un système en temps réel avec différents états et transitions englobés.
- Lorsque l'application dépend de l'événement / des valeurs / des conditions du passé.
- Quand la séquence des événements doit être testée.
- Lorsque l'application doit être testée par rapport à un ensemble fini de valeurs d'entrée.
Quand ne pas utiliser les tests de transition d'état?
Vous ne devez pas vous fier aux tests de transition d'état dans les situations suivantes:
- Lorsque le test n'est pas requis pour les combinaisons d'entrées séquentielles.
- Lorsque différentes fonctionnalités de l'application doivent être testées (plus comme des tests exploratoires).
Exemple de test de transition d'état dans le test de logiciel
Dans le scénario pratique, les testeurs reçoivent normalement les diagrammes de transition d'état et nous sommes tenus de les interpréter.
Ces diagrammes sont soit fournis par les Business Analysts, soit par une partie prenante et nous utilisons ces diagrammes pour déterminer nos cas de test.
Prenons la situation ci-dessous:
Nom du logiciel - Manage_display_changes
Caractéristiques - Le logiciel répond aux demandes d'entrée pour changer de mode d'affichage pour un dispositif d'affichage de l'heure.
Le mode d'affichage peut être réglé sur l'une des quatre valeurs:
- Deux correspondant à l'affichage de l'heure ou de la date.
- Les deux autres lors de la modification de l'heure ou de la date.
Les différents états sont les suivants:
- Changer de mode (CM): L'activation de cette option fera basculer le mode d'affichage entre «affichage de l'heure (T)» et «affichage de la date (D)».
- Réinitialiser (R): Si le mode d'affichage est réglé sur T ou D, alors une «réinitialisation» entraînera le réglage du mode d'affichage sur les modes «modifier l'heure (AT)» ou «modifier la date (AD)».
- Réglage de l'heure (TS): L'activation de ceci entraînera le retour du mode d'affichage à T depuis AT.
- Date Set (DS): L'activation de ceci entraînera le retour du mode d'affichage à D depuis AD.
Diagramme de transition d'état
Maintenant, passons à l'interpréter:
Ici:
# 1) Les différents états sont:
- Temps d'affichage (S1),
- Changer l'heure (S3),
- Afficher la date (S2), et
- Change Date (S4).
# 2) Les différentes entrées sont:
- Changer de mode (CM),
- Réinitialiser (R),
- Réglage de l'heure (TS),
- Réglage de la date (DS).
# 3) Les différentes sorties sont:
- Alter Time (AT),
- Temps d'affichage (T),
- Affichage de la date (D),
- Modifier la date (AD).
# 4) Les états modifiés sont:
- Temps d'affichage (S1),
- Changer l'heure (S3),
- Afficher la date (S2) et
- Change Date (S4).
Étape 1: Écrivez tous les états de départ. Pour cela, prenez un état à la fois et voyez combien de flèches en sortent.
- Pour l'état S1, deux flèches en sortent. Une flèche va à l'état S3 et une autre flèche va à l'état S2.
- Pour l'état S2 - Il y a 2 flèches. L'un va à l'état S1 et l'autre va à S4
- Pour l'état S3 - Une seule flèche en sort, passant à l'état S1
- Pour l'état S4 - Une seule flèche en sort, passant à l'état S2
Mettons ceci sur notre table:
Puisque pour les états S1 et S2, il y a deux flèches qui sortent, nous l'avons écrit deux fois.
Étape 2: Pour chaque état, notez leurs états de transition finaux.
- Pour l'état S1 - Les états finaux sont S2 et S3
- Pour l'état S2 - Les états finaux sont S1 et S4
- Pour l'état S3 - L'état final est S1
- Pour l'état S4 - l'état final est S2
Mettez ceci sur la table en tant qu'état de sortie / résultant.
Étape 3: Pour chaque état de démarrage et son état de fin correspondant, notez les conditions d'entrée et de sortie
- Pour que l'état S1 passe à l'état S2, l'entrée est le mode de changement (CM) et la sortie est la date d'affichage (D) indiquée ci-dessous:
De la même manière, notez les conditions d'entrée et sa sortie pour tous les états comme suit:
Étape 4:
Ajoutez maintenant l'ID de cas de test pour chaque test illustré ci-dessous:
Maintenant, convertissons-le en cas de test formels:
De cette manière, tous les cas de test restants peuvent être dérivés. Je suppose l'autre attributs des cas de test comme les conditions préalables, la gravité, la priorité, l'environnement, la construction, etc. sont également inclus dans le scénario de test.
Résumant à nouveau les étapes:
- Identifiez les états initiaux et leur état final en fonction des lignes / flèches qui sortent de l'état initial.
- Pour chaque état initial, découvrez la condition d'entrée et le résultat de sortie
- Marquez chaque ensemble comme un cas de test distinct.
Plus d'exemples de technique de transition d'état
Voici un autre exemple de la technique de test de transition d'état dans des applications logicielles plus grandes.
Description:
' Test fonctionnel avec état » L'approche peut être utilisée pour tester des pièces ou des composants spécifiques de l'application, avec la caractéristique d'une machine à états finis (FSM).
Étapes de la mise en œuvre:
#1) La première étape de la mise en œuvre des «tests fonctionnels avec état» consiste à identifier les différents composants / parties de l'application qui peuvent être classés comme FSM. Les entrées, états et sorties sont soigneusement suivis pour chacun de ces FSM.
#deux) L'étape suivante consisterait à développer des cas de test pour ces FSM basés sur des règles de transition, des entrées, des sorties et des états de transition.
# 3) La troisième étape serait d'intégrer les tests de ces composants avec d'autres composants d'interfaçage pour valider l'application de bout en bout.
Cela peut être expliqué au moyen d'un exemple d'application nommée «Projet de maison», qui suit la construction d'une maison, avec divers composants d'application comme l'approbation de l'architecture de la maison, l'enregistrement du terrain et de la maison, la sélection de l'entrepreneur en construction , approbation du prêt logement, etc.
Par exemple,
Nous envisagerons de tester une composante FSM de l'application «Projet de maison»: l'approbation du prêt au logement.
Demande d'approbation de prêt au logement (HLA)
L'application HLA sera gérée par un utilisateur de traitement de prêt indépendant, qui traite la demande de prêt. Les différentes étapes du traitement de la demande sont détaillées ci-dessous:
1.1.1 Étape 1: Collecte des documents
La première étape est la collecte des documents pertinents pour la demande de prêt, comme indiqué dans le tableau ci-dessous. Ce sont les «conditions» d’une candidature réussie. Le demandeur recueille les documents requis et les applique au prêt immobilier.
L'utilisateur de traitement de prêt accuse réception des documents et fait passer l'état de la demande de prêt (c'est-à-dire l'état du composant d'application HLA) à l'état «appliqué».
Tableau 1: Liste des documents
1.1.2 Étape 2: Évaluation du prêt
VPN gratuit Chine
À ce stade, le prêteur évalue la demande de prêt pour déterminer si elle répond à ses exigences de crédit. Les pièces justificatives sont vérifiées à ce moment.
Tableau 2: Criticité des documents
Les documents nécessaires à l'évaluation, c'est-à-dire les «conditions» qui doivent être validées à ce stade, sont validés. Chaque condition a une criticité qui lui est attachée (mentionnée comme «Y» dans le tableau ci-dessus). Une fois que toutes les conditions critiques requises sont satisfaites, l'application passe à l'état «Confirmé», c'est-à-dire que le composant d'application HLA est à l'état «Confirmé».
Point à noter:
#1) Ce principe apporte une structure et une objectivité aux conditions de test et aux définitions «État» du système .
De plus, toutes les «conditions» de validation du système ne sont pas essentielles pour qu'il atteigne cet état «Confirmé». Dans le tableau ci-dessus, 4 conditions sont marquées comme «non critiques» pour que l'application atteigne l'état «confirmé».
#deux) Le nombre de validations peut être réduit de manière optimale, en fonction du risque ou de la criticité des règles requises pour chaque état. Cela réduira considérablement le temps requis pour l'exécution des tests et en même temps ne compromettra pas la qualité des tests.
# 3) Ceci n'est pas seulement utile pour tester les composants individuels, mais également pour tester le système de bout en bout.
# 4) Aussi, très utile lors de la création de suites de tests de régression.
Donc, à ce stade, il s'agit d'un test de type 0-switch. Mais les étapes ultérieures de l'approbation peuvent être des types de validations à 1 ou 2 commutateurs pour cette étape.
Par exemple, Le «certificat de mariage» n'est peut-être pas trop pertinent à ce stade, mais dans les dernières étapes de l'approbation, lorsque le risque pour le demandeur de payer l'IME est envisagé, le certificat de mariage peut devenir pertinent - c'est-à-dire si le conjoint est également employé , il réduit le risque, et s'il n'est pas utilisé, il augmente le risque.
# 5) Le principe ci-dessus peut être utilisé pour étendre les conditions de test en fonction des besoins du composant à ce stade.
1.1.3 Étape 3: approbation conditionnelle
L'état actuel de l'application est «Confirmé». Le prêteur donnerait une «approbation conditionnelle» pour que le processus de prêt progresse. Des validations supplémentaires sont nécessaires pour déplacer l'application HLA vers l'état «Approuvé».
1.1.4 Étape 4: approbation
Des validations critiques sont effectuées à ce stade:
- Évaluation par l'Assurance Hypothécaire (LMI) des prêteurs: cela impliquerait 2 validations ou plus de l'authenticité de la propriété.
- Le prêteur peut exiger des informations qui n'ont pas été fournies lors de l'étape de «confirmation».
Une fois les conditions ci-dessus satisfaites, l'application passe à l'état «Approuvé». L'autorité finale du processus d'approbation peut contre-vérifier la crédibilité du demandeur de prêt en demandant plus de détails ou peut ne pas demander si les autres documents du demandeur sont concluants. Autrement dit, plus d'entrées provenant de différents composants de l'application principale seraient nécessaires pour prouver la validité .
# 6) En d'autres termes, davantage de validations peuvent être nécessaires (ou réduites) pour la transition vers un état différent en fonction des conditions d'entrée dans le composant à partir d'autres composants de l'application.
Le diagramme ci-dessous illustre le processus d'approbation.
Figure 1: Processus d'approbation des prêts
Risques et défis
- Pour les applications volumineuses, une connaissance approfondie des applications est essentielle pour diviser l'application en différents composants logiques afin de permettre la catégorisation en tant que FSM et composants ordinaires. Cela peut exiger un temps coûteux de la part des PME.
- Toutes les applications n'auraient pas la faisabilité de ce type de catégorisation FSM.
- Étant donné que les composants FSM interagissent avec les composants normaux de l'application, les entrées des FSM à partir de différents composants nécessitent une planification et une exécution minutieuses.
Avantages des tests de transition d'état
- Dans le cadre de cette technique, en utilisant une représentation illustrée ou tabulaire du comportement du système, le testeur se familiarise avec la conception de l'application et se sent facile à couvrir et à concevoir les tests de manière efficace et efficiente.
- Les états non planifiés ou non valides du système sont également couverts en utilisant cette technique.
- À l’aide du diagramme de transition d’état, il est facile de vérifier si toutes les conditions sont couvertes.
Inconvénients des tests de transition d'état
- Cette technique ne peut pas être utilisée pour les systèmes d’états non finis.
- La définition de tous les états possibles pour des systèmes volumineux et complexes est une tâche assez lourde.
Conclusion
Le test de transition d'état est une approche utile lorsque différentes transitions de système doivent être testées pour des systèmes à états finis.
Tester une application avec le concept de «test fonctionnel avec état» peut donner aux organismes de test une approche de test unique pour tester des applications complexes, ce qui augmenterait la productivité de l'exécution des tests sans compromettre la couverture des tests.
Les tests de transition d'état sont une approche de test unique pour tester des applications complexes, ce qui augmenterait la productivité d'exécution des tests sans compromettre la couverture des tests.
La limitation de cette technique est qu’elle ne peut pas être utilisée tant que le système testé n’a que des états finis.
lecture recommandée
- Qu'est-ce que la technique de test basée sur les défauts?
- Qu'est-ce que la technique de test orthogonal Array (OATS)?
- Test fonctionnel vs test non fonctionnel
- Qu'est-ce que le test de comparaison (apprendre avec des exemples)
- Qu'est-ce que le test de mutation: tutoriel avec des exemples
- Qu'est-ce que les tests d'endurance dans les tests logiciels (exemples)
- Qu'est-ce que les tests de bout en bout: cadre de test E2E avec exemples
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)