Ajouter de la vie à la virtualisation des services : tests d'état et de transition d'état

Dans la virtualisation des services, un élément essentiel de créer des services virtuels réalistes garantit que le service a un comportement avec état afin qu'il puisse conserver son état d'une exécution de test à l'autre. Mais quelle est la limite ? Quand la simulation devient-elle trop de simulation ? Plongeons-nous dans les tests de transition d'état et comment savoir quand vous en avez besoin.

Pour accélérer les tests fonctionnels, il est essentiel d'avoir un accès illimité à un environnement de test fiable et réaliste. Un environnement de test complet comprend l'application sous test (AUT) et tous ses composants dépendants, tels que les API, les services tiers, les bases de données, les applications et d'autres points de terminaison.

La virtualisation des services permet aux équipes d'effectuer les opérations suivantes, ce qui leur permet en fin de compte de tester plus tôt, plus rapidement et de manière plus complète.

1. Accédez à l'environnement de test complet dont ils ont besoin, y compris tous les composants système dépendants critiques.
2. Modifiez le comportement de ces composants dépendants d'une manière qui serait impossible avec un environnement de test par étapes.

Comportement avec état

Un élément essentiel de la création de dépendances virtualisées réalistes consiste à avoir un comportement avec état. En d'autres termes, une dépendance virtualisée peut conserver son état d'une exécution de test à l'autre. Prenons un exemple de simulation d'un composant de panier d'achat virtualisé. Une API simple permet de rechercher, d'ajouter, de récupérer et de supprimer des articles du panier.

Avec un comportement sans état, la simulation de la recherche et de l'enregistrement d'articles dans le panier ne modifiera pas l'état du panier. Le test de la séquence de récupération et de suppression des données du panier échouera car le panier restera dans son état initial (vide), comme illustré ci-dessous.

Cependant, si le panier d'achat virtuel reçoit un comportement avec état, où son état (vide ou contenant un ou plusieurs éléments) est conservé d'un test à l'autre et change également en fonction des entrées de l'application testée, vous pouvez commencer à tester le processus de manière significative.

À l'aide de tests avec état, le service virtualisé peut désormais passer de l'état vide à « rempli avec l'élément ajouté » et renvoyer les informations appropriées. Si un article est ajouté au panier et que l'AUT interroge le panier, les données appropriées sont renvoyées. Un test plus réaliste est possible en utilisant des tests avec état, et l'interrogation du panier renvoie désormais l'article ajouté, comme indiqué ci-dessous.

Pour résumer, pour disposer de services virtuels fiables et réutilisables, il est essentiel qu'ils puissent imiter suffisamment le service réel pour fournir une sortie significative à l'application testée, ce qui peut nécessiter des tests avec état.

En plus de l'état du service virtuel lui-même, vous devrez peut-être également simuler des changements d'état en fonction de différentes entrées potentielles, et cela s'appelle le test de transition d'état.

Qu'est-ce qu'un test de transition d'état ?

Les transitions d'état sont la composante action des machines à états finis, qui sont définies comme suit:

"... une machine abstraite qui peut être dans exactement un état parmi un nombre fini d'états à un moment donné. Le FSM peut passer d'un état à un autre en réponse à certaines entrées externes ; le passage d'un état à un autre s'appelle une transition. Un FSM est défini par une liste de ses états, son état initial et les conditions de chaque transition.

-Wikipédia

Les machines à états sont un moyen utile de décrire des objets et sont souvent explicitement utilisées comme modèle de programmation. Dans d'autres cas de test, comme notre panier d'achat, il peut y avoir une machine à états implicite pour décrire son comportement. Considérez la machine d'état suivante pour l'exemple de panier ci-dessus.

L'état initial du panier est vide. Au fur et à mesure que des articles sont ajoutés au panier, l'état passe de "Vide" à "Article dans le panier". Les transitions sont initiées en réponse aux événements. Dans ce cas, ajouter ou supprimer un article du panier.

Les transitions ont souvent des conditions avant d'être prises, par exemple, le retour à l'état vide ne se produit que lorsque le nombre d'éléments est à nouveau égal à zéro. Les transitions effectuent souvent des actions, telles que l'incrémentation du nombre d'articles dans le panier, dans cet exemple. Bien qu'il soit peu probable que le chariot soit programmé comme une machine à états, il en existe une implicite qui est utile pour définir son comportement.

Prenons un autre exemple simple de composant de connexion utilisateur qui verrouille un utilisateur après un certain nombre de tentatives:

Dans le composant de connexion, l'état initial est déconnecté. Un utilisateur ne peut être connecté que lorsqu'un code PIN correct est saisi. Après un nombre défini de tentatives de connexion (MAX_RETRIES), le compte est bloqué. Dans ce cas de test, le compte bloqué peut être considéré comme un état final puisqu'il n'y a aucun moyen d'en faire la transition.

Diagrammes de transition d'état

Comme le montrent les deux exemples de transition ci-dessus, les diagrammes d'états sont des représentations graphiques de machines à états finis. Ils modélisent le comportement d'un système ou d'un processus qui peut exister dans différents états et les transitions entre ces états en fonction de certains événements ou conditions.

Dans un diagramme d'états, les états sont représentés par des cases arrondies et les transitions entre états par des flèches. Chaque état représente une condition ou un mode particulier du système. Les transitions indiquent comment le système peut passer d'un état à un autre et sont généralement étiquetées avec l'événement qui provoque la transition.

Les événements dans les machines d'état peuvent être des entrées externes, des actions internes ou le passage du temps. Lorsqu'un événement se produit, le système subit une transition et passe à un nouvel état.

Tableaux de transition d'état

Les tables de transition d'état sont des représentations tabulaires utilisées pour décrire le comportement d'une machine d'état de manière systématique. Le tableau définit les états possibles, les événements d'entrée et les transitions d'état résultantes.

Dans une table de transition d'état, les lignes représentent des états et les colonnes représentent un événement ou une condition d'entrée. Les cellules du tableau spécifient l'état résultant lorsqu'un événement particulier se produit dans un état spécifique. Cela permet une représentation concise et structurée des transitions d'état.

Avantages et inconvénients des tests de transition d'état

Les avantages de l'utilisation des tests de transition d'état sont les suivants.

• Fournit une couverture de test approfondie en examinant systématiquement tous les états et transitions possibles dans l'API, ce qui garantit une couverture plus complète du comportement de l'API.
• La couverture accrue s'accompagne d'une meilleure détection des bogues et des vulnérabilités de sécurité.
• Devient un moyen plus succinct d'exprimer le comportement à mesure que les testeurs se familiarisent avec celui-ci et simplifie globalement les tests d'API.
• Les tests réutilisables réduisent le travail requis pour les tests de régression.

Les tests de transition d'état présentent certains inconvénients. Tout d'abord, le niveau d'effort requis pour représenter une API complexe. Si la traduction du Comportement de l'API sorties dans une machine à états complexe, il sera difficile à comprendre, à utiliser et à entretenir. De plus, les tests de transition d'état sont sensibles aux modifications de l'API. Ils nécessitent une maintenance constante pour suivre ces mises à jour.

Quand utiliser les tests de transition d'état ?

Les tests de transition d'état sont plus logiques, sans surprise, lorsque l'API a une nature avec état, comme le maintien d'une session ou d'un contexte sur plusieurs requêtes. Ce type de test permet de vérifier que l'API gère et maintient correctement l'état tout au long de l'interaction, garantissant un comportement cohérent entre les différentes demandes et transitions.

Les API peuvent documenter leur comportement en termes d'états et d'événements, auquel cas la vérification peut prendre la même forme. Dans d'autres cas, l'API peut impliquer un processus métier complexe comportant plusieurs étapes dans le flux de travail. Les tests de transition d'état peuvent être utilisés pour mieux tester ces scénarios complexes.

Simulation d'état avec Parasoft Virtualize

Alors, comment cela aide-t-il les tests et les services virtuels? Eh bien, il est possible d'utiliser Parasoft Virtualiser pour simuler un comportement avec état afin que les services renvoient des réponses appropriées d'un test à l'autre, représentant des valeurs réalistes attendues par l'AUT.

Les services virtualisés réagissent aux entrées des tests et conservent les valeurs selon les besoins, étendant l'utilité des données de test capturées et simulées, qui restent statiques à moins d'être améliorées avec un comportement avec état. Dans Parasoft Virtualize, un service est virtualisé en tant que CRUD (Create, Read, Update, Delete) pour indiquer que sa source de données de test est persistante et peut être manipulée selon les besoins pendant les tests. Voir la capture d'écran ci-dessous.

Parasoft Virtualize prend en charge le comportement avec état dans la source de données de test ou le moteur associé à chaque service virtuel, qui non seulement stocke les données de test, mais fournit également l'outil CRUD pour manipuler les données en fonction de la réaction aux demandes d'API reçues. Ces mises à jour des données dans la source de date de test sont basées sur des événements d'entrée, comme ceux décrits ci-dessus dans les diagrammes de transition d'état : l'événement d'entrée arrive, la transition d'état se produit et l'action a lieu.

Pour soutenir tout cela, le gestion des données de test L'outil dans Parasoft Virtualize est configuré pour effectuer une mise à jour en fonction d'une source de données et d'un événement arrivant.

Les mises à jour de la source de données de test peuvent être des éléments de données individuels ou des objets entiers. L'outil vous permet également de créer et de supprimer des enregistrements en fonction des règles métier requises. En fait, il est assez puissant pour simuler un comportement complexe, ce qui soulève la question, quand est-ce que trop de simulation, trop ?

Les avantages et les inconvénients de la virtualisation avec état

L'utilisation de la virtualisation pure est utile pour les tests car elle supprime la complexité de la gestion d'un service réel et isole l'application testée. De plus, la suppression des services en direct signifie que les tests peuvent être exécutés en parallèle, sur plusieurs postes de travail en même temps, sans impact sur les systèmes de production ni sur la nécessité d'une copie dédiée du service. Mais un serveur virtuel pur ne renvoie qu'un accusé de réception comme dans "oui, cette API a été appelée". Dans de nombreux cas, cela suffit, jusqu'à ce que, bien sûr, ce ne soit pas le cas. À mesure que des cas de test plus complexes émergent, nous avons besoin que nos serveurs virtualisés s'améliorent.

En utilisant l'exemple de panier d'achat ci-dessus, il est beaucoup plus utile pour votre service d'achat virtuel non seulement de reconnaître que des articles ont été ajoutés au panier, mais aussi de simuler l'ajout d'articles au panier. De cette façon, une requête pour déterminer le nombre d'articles dans le panier aboutira avec une valeur correcte. Nous pourrions également simuler un état "panier plein" comme décrit dans la représentation de la machine d'état ci-dessus. Un comportement avec état est nécessaire pour donner à nos tests des résultats plus significatifs et augmenter la couverture des cas de test.

Mais il arrive un moment où simuler la logique métier devient trop complexe. L'intention de la virtualisation est de réduire le travail et d'augmenter la productivité, il y a donc des rendements décroissants dans la simulation de la complexité.

Le seuil est difficile à dire, mais si la complexité va bien au-delà de notre panier d'achat ou de notre exemple de connexion, il devient difficile de justifier l'effort. Comment pouvez-vous être sûr que vous simulez le bon comportement ? Vous ne voulez pas d'une situation où votre application est conçue pour fonctionner avec un service simulé mais ne fonctionne pas correctement avec la réalité ! L'utilisation de services en direct est toujours nécessaire dans la validation. Heureusement, Responsable Environnement Parasoft CTP module facilite la commutation.

Résumé

Le comportement avec état est un élément essentiel de la création de services virtualisés réalistes, nécessaires pour aider à isoler les applications en cours de test. Conserver l'état des données de test d'un test à l'autre est nécessaire pour des tests plus réalistes et utiles. Parasoft Virtualiser fournit une solution complète de gestion des données de test qui donne vie à des services virtualisés avec des réponses avec état et basées sur l'état aux entrées des appels d'API.

La simulation doit être utilisée avec prudence, car la simulation d'une logique métier complexe a des rendements décroissants et le risque de trop s'éloigner de la réalité. Une utilisation intelligente de la simulation offre de grands avantages dans l'isolement, ce qui à son tour dissocie les dépendances sur les serveurs en direct. Cependant, étant donné que les serveurs en direct jouent toujours un rôle dans la validation finale, des outils de virtualisation de services tels que Parasoft Virtualize sont nécessaires pour prendre en charge le mélange et l'appariement de ces environnements de manière transparente.