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

Dans la virtualisation des services, une partie essentielle de la création de services virtuels réalistes consiste à s'assurer 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 sans restriction à 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 (par exemple, API, services tiers, bases de données, applications et autres points de terminaison).

La virtualisation des services permet aux équipes de (1) obtenir l'accès à cet environnement de test complet dont ils ont besoin, y compris tous les composants système critiques dépendants, et (2) modifier le comportement de ces composants dépendants d'une manière qui serait impossible avec un environnement de test par étapes. Permettant ainsi aux équipes de tester plus tôt, plus rapidement et plus complètement.

Comportement avec état

Un comportement avec état est un élément essentiel de la création de dépendances virtualisées réalistes. En d'autres termes, une dépendance virtualisée qui peut conserver son état d'un test à l'autre. Prenons un exemple de simulation d'un composant de panier virtualisé. Une API simple permet de rechercher, d'ajouter, de récupérer et de supprimer des articles du panier. Avec le comportement sans état, la simulation de la recherche et de l'enregistrement des articles dans le panier ne changera pas l'état du panier. Le test des processus 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 virtuel est doté d'un comportement avec état, où son état (vide ou avec un ou plusieurs éléments) est conservé d'un test à l'autre, ainsi que des modifications en fonction des entrées de l'application testée, vous pouvez commencer à tester le processus de manière significative.

À l'aide des tests avec état, le service virtualisé peut désormais changer d'état de vide à «rempli d'é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'élément ajouté, comme indiqué ci-dessous:

Pour résumer, pour avoir des services virtuels fiables et réutilisables, il est essentiel qu'ils puissent imiter le réal service suffisamment pour fournir des résultats significatifs à 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 simuler change en état basé sur différentes entrées potentielles, et cela s'appelle 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 l'un d'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 utilisées explicitement comme modèle de programmation. Dans d'autres cas, comme notre panier, 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 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 à des événements (dans ce cas, l'ajout ou la suppression d'un article du panier).

Les transitions ont souvent spécifiques avant qu'ils ne soient pris, par exemple, le retour à l'état Vide ne se produit que lorsque le nombre d'éléments est à nouveau nul. Transitions souvent effectuer des actions, comme l'incrémentation du nombre d'articles dans le panier, dans cet exemple. Bien qu'il soit peu probable que le panier soit programmé comme une machine à états, il y en a 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 entré. Après un nombre défini de tentatives de connexion (MAX_RETRIES), le compte est bloqué. Dans ce cas, le compte bloqué peut être considéré comme un état final car il est maintenant possible de faire la transition à partir de celui-ci.

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» (Créer, Lire, Mettre à jour, Supprimer) 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 moteur) associée à 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, l'action a lieu).

Pour prendre en charge tout cela, l'outil de gestion des données de test de 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 date 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 de savoir quand est-ce trop de simulation, trop?

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

L'utilisation de la virtualisation pure est très utile pour les tests, car elle supprime la complexité de la gestion d'un service réel et isole l'application testée. En outre, 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 la nécessité d'une copie dédiée du service. Mais un serveur virtuel pur renvoie uniquement 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 d'utilisation plus complexes émergent, nous avons besoin de nos serveurs virtualisés pour «s'intensifier».

En utilisant l'exemple de panier 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 également 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 réussira avec une valeur correcte. Nous pourrions également simuler un état «chariot plein» comme décrit dans la représentation de la machine à états ci-dessus. Un comportement avec état est nécessaire pour donner à nos tests des résultats plus significatifs et une couverture accrue des cas d'utilisation.

Mais il arrive un moment où la simulation de la logique métier devient trop complexe. Le but de la virtualisation est de réduire le travail et d'augmenter la productivité, de sorte que la simulation de la complexité présente des rendements décroissants. Le seuil est difficile à dire, mais si la complexité va bien au-delà de notre panier ou de notre exemple de connexion, il devient alors difficile de justifier l'effort. Comment êtes-vous sûr de simuler le bon comportement? Vous ne voulez pas d'une situation où votre application est conçue pour fonctionner avec un service simulé mais de manière incorrecte avec la réalité! L'utilisation de services en direct est toujours nécessaire pour la validation (heureusement, Parasoft's Responsable environnement 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 testées. La capacité de 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, avec des risques de s'éloigner trop de la «réalité». Une utilisation intelligente de la simulation rapporte de grands avantages de manière isolée, 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 de manière transparente le mélange et la mise en correspondance de ces environnements.