Qu’est-ce que les tests basés sur des modèles ?

Qu’est-ce que les tests basés sur des modèles ?

Tests basés sur des modèles Le test d'intégration continue est une technique de test logiciel qui consiste à comparer le comportement d'exécution du logiciel testé aux prédictions d'un modèle. Un modèle décrit le comportement d'un système, exprimé en termes de séquences d'entrée, d'actions, de conditions, de sortie et du flux de données entre l'entrée et la sortie. Un modèle utilisable doit être compréhensible, réutilisable et partageable, et décrire précisément le système testé.

Il existe de nombreux modèles, chacun décrivant un aspect différent du comportement du système. Voici quelques exemples courants :

• Flux de données
• Flux de contrôle
• Graphiques de dépendance
• Tableaux de décision
• Machines de transition d'état

Les tests basés sur un modèle décrivent le comportement d'un système en réponse à une action déterminée par le modèle. On soumet l'action, puis on vérifie si le système réagit comme prévu par le modèle. Tout écart entre les deux indique soit un défaut du logiciel, soit une erreur du modèle ; il est important de détecter les deux.

Il s'agit d'une méthode formelle légère de validation de système, applicable aussi bien aux tests matériels qu'aux tests logiciels. Les tests étant basés sur une spécification de comportement plutôt que sur le code, cette technique s'inscrit dans cette perspective. test de la boîte noire Famille de techniques de test de logiciels.

Exemple de test basé sur un modèle

La manière la plus simple de comprendre un modèle comportemental est de le suivre pas à pas. Le diagramme ci-dessous modélise une tâche simple d'édition de texte ; chaque case représente un état possible de l'application et chaque flèche une action possible de l'utilisateur.

Le modèle explique une approche simplifiée de l'écriture poétique dans le Bloc-notes et les actions possibles liées à chaque étape. Pour chaque action, comme le lancement de l'application, la saisie d'un poème ou l'enregistrement du fichier, un cas de test Il est possible de générer des données et de vérifier les résultats. En parcourant un chemin différent au sein du même diagramme, par exemple en commençant et en terminant sans enregistrer, on obtient un cas de test différent sans coût de conception supplémentaire, ce qui constitue l'argument économique en faveur de cette technique.

Types de CCP

Il existe deux types de frameworks de tests basés sur des modèles, et la différence entre eux réside simplement dans le moment où les étapes de test sont produites :

• Hors ligne / a priori : Génération des suites de tests avant leur exécution. Une suite de tests est un ensemble de cas de test ; dans ce mode, la suite est stockée, examinée et réexécutée comme n’importe quelle autre suite de tests. tests d'automatisation actifs.
• En ligne / à la volée : Génération de suites de tests pendant l'exécution des tests, où l'étape suivante est choisie en fonction de la façon dont le système a réellement réagi à la précédente.

La génération hors ligne convient aux environnements réglementés nécessitant une suite de tests vérifiable et reproductible. La génération en ligne, quant à elle, est adaptée aux sessions exploratoires de longue durée sur des systèmes à état, car le générateur peut réagir à la réponse réelle plutôt qu'à la réponse prédite.

Comment fonctionnent les tests basés sur des modèles

Quel que soit le framework utilisé, la technique suit les mêmes cinq étapes. Chaque étape produit un artefact que l'étape suivante utilise ; c'est pourquoi c'est le modèle, et non le script de test, que l'équipe maintient.

• Étape 1 : Construire le modèle. Traduire des exigences ou une spécification en un abstracmodèle t du comportement attendu, définissant les états, les transitions entre eux et les entrées qui déclenchent chaque transition.
• Étape 2 : Choisir les critères de sélection des tests. Les critères indiquent au générateur quand s'arrêter. Les plus courants sont la couverture de tous les états, qui visite chaque état au moins une fois ; la couverture de toutes les transitions, qui exécute chaque flèche au moins une fois ; et la couverture des chemins ou des flux de données pour une exploration plus approfondie.
• Étape 3 : Générer des abstraccas de test t. L'outil parcourt le modèle et émet des séquences d'abstract étapes qui satisfont aux critères choisis, ainsi que le résultat attendu à chaque étape.
• Étape 4 : Concrétiser les abdominauxtracTests t. Une couche d'adaptation mappe chaque abstracpasser à une action concrète contre le système, telle qu'une interaction avec une interface utilisateur, une API appel ou message de protocole. Cette carteping est écrit une seule fois et réutilisé par chaque test généré.
• Étape 5 : Exécuter et attribuer les verdicts. Les tests concrets sont effectués sur le système testé, chaque réponse observée est comparée à la prédiction du modèle, et un verdict de réussite ou d'échec est enregistré. tracet retour à l'élément du modèle qui l'a produit.

Le tracLa flexibilité acquise à l'étape 5 offre un avantage concret. Lorsqu'une exigence change, le modèle change et les tests concernés sont régénérés au lieu d'être réécrits, ce qui explique pourquoi les équipes effectuent fréquemment des tests de ce type. les tests de régression contre une spécification stable, l'avantage est maximal.

Différents modèles en test

Pour comprendre la MBT, il est nécessaire de comprendre certains des modèles expliqués ci-dessous. Chacun d'eux met en balance la puissance d'expression et l'effort requis ; le choix dépend donc de la complexité du comportement testé.

Machines à états finis

Ce modèle aide les testeurs à évaluer le résultat en fonction de l'entrée sélectionnée. Différentes combinaisons d'entrées peuvent aboutir à un état correspondant du système.

Le système aura un état spécifique et un état actuel, ce dernier étant déterminé par un ensemble d'entrées fournies par les testeurs.

Prenons l'exemple suivant : un système permet aux employés de se connecter à une application. L'employé est initialement « Extérieur » et passe à « Connecté » une fois authentifié. En étant connecté, il peut alors consulter, imprimer et numériser des documents.

La machine à états correspondant à cet exemple est représentée ici, chaque flèche étant étiquetée par l'entrée qui provoque la transition.

Graphiques d'état

Un diagramme d'états est une extension de la machine à états finis et peut être utilisé pour les systèmes complexes et temps réel. Il décrit les différents comportements du système, possède un nombre défini d'états, et le comportement du système est analysé et représenté sous forme d'événements pour chaque état. L'extension la plus importante en pratique est la hiérarchie : un diagramme d'états permet des états imbriqués et parallèles, ce qui permet de représenter de manière compacte une machine qui nécessiterait des dizaines d'états simples.

Par exemple, les anomalies sont signalées dans l'outil de gestion des anomalies avec le statut « Nouveau ». Une fois corrigée par les développeurs, leur statut passe à « Corrigé ». Si l'anomalie n'est pas corrigée, son statut passe à « À rouvrir ». Les diagrammes d'états doivent être conçus de manière à ce qu'un événement soit déclenché pour chaque état.

Le cycle de vie de ce défaut est illustré ci-dessous, chaque statut étant représenté comme un état et chaque action du flux de travail comme l'événement qui fait passer le défaut d'un état à l'autre.

Langage de modélisation unifié (UML)

Langage de modélisation unifié (UML) UML est un langage de modélisation standardisé à usage général. Il comprend un ensemble de techniques de notation graphique utilisées pour créer des modèles visuels capables de décrire le comportement de systèmes très complexes.

UML a des notations telles que :

• Activités
• de la restauration
• Processus d'affaires
• Composants
• Langage de programmation

Les diagrammes d'activité et de machine à états sont ceux que les générateurs de tests lisent le plus souvent, comme l'illustre l'exemple de modèle UML ci-dessous.

Outils de test basés sur des modèles

Un modèle sur papier ne génère rien par lui-même. Un générateur est nécessaire pour parcourir le modèle et produire des chemins de test ; le marché des outils se divise alors en générateurs open source et en plateformes commerciales de conception de tests.

• GraphWalker — un outil open-source qui lit des modèles sous forme de graphes orientés et génère des chemins de test à partir de ceux-ci, avec des générateurs et des conditions d'arrêt sélectionnables.
• fMBT — un ensemble d'outils de test open source basé sur des modèles, développé par Intel, qui prend en charge la génération et l'exécution de tests sur des modèles d'état.
• Conformiq — un produit commercial de conception de tests automatisés qui génère des cas de test et des scripts à partir de modèles comportementaux graphiques.
• MaTeLo et MBTsuite — des plateformes commerciales destinées à élaborer des modèles d'utilisation statistique et à générer des tests pour les frameworks d'automatisation existants.
• Explorateur de spécifications - MicrosoftL'extension de test basée sur un modèle de Visual Studio, largement citée dans la littérature sur les tests de protocoles.

Le choix dépend moins des listes de fonctionnalités que de deux questions : quelle notation l’équipe maîtrise-t-elle et si l’outil peut générer des tests pour le framework d’automatisation déjà utilisé. Un générateur produisant des suites de tests inexécutables complexifie le processus au lieu de le simplifier.

Tests basés sur des modèles vs conception de tests traditionnelle

Il convient de souligner le contraste avec la conception de tests manuscrits, car les deux approches échouent à des endroits différents plutôt que l'une étant simplement meilleure.

Aspect	Tests basés sur des modèles	Conception de test traditionnelle
Source des cas de test	Généré automatiquement à partir d'un modèle comportemental	Rédigé individuellement par un testeur à partir des exigences
Effet d'une modification des exigences	Mettez à jour le modèle, régénérez les tests concernés	Localisez et modifiez manuellement chaque cas de test concerné.
Couverture	Mesuré par rapport à des critères de modélisation tels que tous les états ou toutes les transitions	Évalué par rapport aux exigences et dépendant du jugement du testeur
Coût initial	Niveau élevé : compétences en modélisation, configuration des outils et couche d’adaptation	Faible : un testeur peut commencer à écrire immédiatement
Meilleur ajustement	Systèmes à état et à longue durée de vie avec une spécification stable	Projets courts, longs métrages ponctuels et travaux exploratoires
Mode de défaillance principal	Un modèle erroné ou obsolète génère silencieusement des tests erronés	Des lacunes et des doublons s'accumulent dans une grande suite

L'évolution décrite ci-dessous replace la technique dans son contexte : l'exécution manuelle des tests a cédé la place à l'exécution automatisée, et les approches basées sur des modèles déplacent l'automatisation un niveau plus tôt, dans la conception même des tests.

Défis des tests basés sur des modèles

Le déploiement de la thérapie comportementale basée sur les modèles (MBT) au sein d'une organisation exige un investissement considérable en argent et en efforts. Voici les inconvénients de la MBT : génie logiciel:

• Les testeurs ont besoin de compétences en modélisation que la conception de tests traditionnelle n'exige pas.
• La courbe d'apprentissage est longue et le premier projet coûte généralement plus cher qu'il ne rapporte.
• Le modèle lui-même peut être difficile à comprendre et à analyser, surtout lorsqu'il se développe.
• Un modèle qui s'écarte des spécifications génère des tests erronés mais confiants.
• La couche adaptatrice qui transforme l'abstracLes étapes menant à des actions concrètes doivent être décrites et mises à jour séparément.
• La taille du modèle augmente rapidement, de sorte qu'un modèle d'état non contraint peut produire plus de chemins que n'importe quelle équipe ne peut en exécuter.

Aucun de ces éléments ne justifie d'éviter cette technique, mais ensemble, ils expliquent pourquoi la thérapie par balayage de masse (MBT) est généralement introduite d'abord sur un sous-système stable plutôt que sur l'ensemble du système. cycle de vie des tests logiciels immediatement.

Avantages des tests basés sur des modèles

Comparativement à ces coûts, les avantages de la MBT sont les suivants :

• Maintenance simplifiée des cas de test et des suites de tests, car c'est le modèle qui est modifié et non les tests individuels.
• Réduction des coûts sur la durée d'un projet de longue durée.
• Agencement des Couverture de test, puisque le générateur explore des chemins qu'une personne éviterait.
• Différentes suites générées peuvent s'exécuter en parallèle sur un nombre quelconque de machines.
• Détection précoce des défauts, car les ambiguïtés apparaissent pendant la construction du modèle, avant même l'exécution du moindre code.
• Une augmentation du nombre de défauts constatés pour un même effort de test.
• Gain de temps sur la conception des tests une fois le modèle et l'adaptateur existants.
• Amélioration de la satisfaction au travail des testeurs, grâce au passage de la rédaction répétitive de scripts à la modélisation et à l'analyse.

Les testeurs élaborent de toute façon des modèles mentaux pendant leur travail, et la méthode MBT consiste simplement à les transposer sur papier où ils peuvent être revus, versionnés et réutilisés. La place de cette technique parmi les autres approches disponibles est détaillée dans [référence manquante]. types de tests logiciels.

FAQ