Qu'est-ce que le test de module ? Définition, exemples

Par : Thomas Hamilton Thomas Hamilton
Hours Le kit de préparation mis à jour

⚡ Résumé intelligent

Les tests modulaires vérifient les sous-programmes, les sous-routines, les classes et les procédures individuellement plutôt que le programme assemblé, de sorte que les défauts apparaissent à l'intérieur d'un petit bloc de code bien compris où ils restent faciles et peu coûteux à localiser et à réparer.

  • (I.e. Objectif: L'objectif est de mettre en évidence les erreurs d'un module, et non de démontrer que le module fonctionne.
  • (I.e. Orientation: La technique est principalement de type « boîte blanche », complétée par des cas de type « boîte noire » tirés du cahier des charges.
  • ⏩ Parallélisme: Plusieurs modules peuvent être testés simultanément, ce qui raccourcit la durée totale des tests.
  • 🔗 Deux méthodes: Les modules sont combinés soit de manière incrémentale, étape par étape, soit en une seule passe.
  • 🧰 Échafaudage: Les pilotes fournissent des données de test à un module, tandis que les stubs remplacent les modules qu'il appelle.
  • ???? La possession: Les testeurs écrivent les tests de modules après avoir codé, tandis que les développeurs écrivent les tests unitaires pendant le codage.
  • ⚠️ Défis: Le travail non incrémental, les doubles de test mal compris et le débogage fréquent absorbent la majeure partie des efforts.
En savoir plus

Explication des tests de modules : méthodes, pilotes, stubs et comparaisons

Qu’est-ce que le test de modules ?

Tests de modules Le test modulaire est un type de test logiciel qui vérifie les sous-programmes, sous-routines, classes ou procédures individuels d'un programme. Au lieu de tester l'ensemble du logiciel en une seule fois, le test modulaire recommande de tester les plus petits éléments constitutifs du programme.

Les tests de modules sont principalement axés sur le fonctionnement en boîte blanche. Leur objectif n'est pas de démontrer le bon fonctionnement du module, mais de mettre en évidence la présence d'une erreur. Cette inversion est importante : un test qui ne détecte aucune erreur n'a confirmé que très peu de choses, tandis qu'un test qui révèle un défaut a rempli sa fonction.

Les tests au niveau des modules permettent également d'introduire du parallélisme dans le processus de test, car ils offrent la possibilité de tester plusieurs modules simultanément au lieu d'attendre une compilation complète.

Pourquoi faire des tests de modules

Les tests modulaires sont recommandés car ils modifient l'aspect économique de la détection des défauts.

  • La probabilité d'identifier des erreurs ou des bogues dans des portions plus petites d'un programme augmente.
  • Plusieurs modules peuvent être testés simultanément, et cette approche prend donc en charge les tests parallèles.
  • La complexité des tests est facile à gérer, car chaque module est analysé individuellement.
  • Un défaut a été constaté à l'intérieur d'un module. traccapable de se limiter à une petite quantité de code, le temps de débogage diminue considérablement.

Comment faire des tests de modules ?

La conception d'un cas de test Il s'agit d'une partie importante des tests de modules. Lors de la conception des cas de test pour un module, un testeur doit prendre en considération deux éléments.

  • Spécification du module
  • Le code source du module

Analysez la logique du module en utilisant une ou plusieurs des méthodes suivantes : boîte blanche méthodes, puis compléter ces cas de test en appliquant boîte noire méthodes à la spécification du module. Les valeurs réalistes sont aussi importantes que les chemins choisis, alors préparez-vous données de test en même temps que les dossiers, et non après.

Une fois les cas de test conçus, l'étape suivante consiste à combiner les modules à tester. La méthode utilisée est soit une incrémental non incrémental méthode.

  • Méthode non incrémentale — Tous les modules sont testés indépendamment. Le programme combine d'abord tous les modules, puis teste l'ensemble du programme.
  • Méthode incrémentale Chaque module est d'abord testé, puis ajouté progressivement à la collection de modules testés. Un nouveau test est effectué par étapes.
  • Dans le cadre des tests incrémentaux, il existe deux approches : de haut en bas et bas en haut test.
  • Pour exécuter le module avec les données sélectionnées, un pilote est nécessaire pour fournir les données de test, surveiller l'exécution et capturer les résultats.

Le choix entre les deux méthodes implique un compromis entre l'effort de mise en place et la facilité de diagnostic.

Aspect Méthode incrémentale Méthode non incrémentale
Combinaison Un module à la fois, ajouté à une collection testée Tous les modules combinés, puis testés ensemble
Échafaudage nécessaire Plus de conducteurs et de souches, écrits progressivement Moins de doubles de test, puisque les modules réels sont présents.
De défaut d'isolement Solide — un point de défaillance au niveau du module qui vient d'être ajouté Faible — une panne peut avoir n'importe quelle origine.
Meilleur adapté à Constructions de grande envergure avec de nombreux modules interagissant Programmes de petite taille avec peu de modules et un faible couplage

ARTICLES LIÉS

Pilotes et stubs dans les tests de modules

Le pilote mentionné ci-dessus constitue la moitié d'une paire. Étant donné qu'un module testé se situe rarement en haut ou en bas de la chaîne d'appels, les testeurs le remplacent par du code factice s'il manque de part et d'autre.

  • Chauffeur Ce module remplace le module appelant situé au-dessus de celui testé. Il fournit les données de test, invoque le module, surveille son exécution et capture les résultats. Les tests ascendants dépendent des pilotes, car les modules inférieurs sont prêts avant les modules supérieurs.
  • Talon — remplace un module appelé situé en dessous de celui testé. Il accepte l'appel et renvoie une réponse fixe et connue afin que le module testé puisse terminer son exécution. Les tests descendants reposent sur des stubs, car les modules de niveau supérieur sont prêts en premier.

Un cas concret rend l'association tangible. Si un module de calcul de paiement est finalisé alors que l'écran de paiement qui l'appelle ne l'est pas, un pilote lui fournit un ensemble de totaux de commande et enregistre le résultat. Si le service de consultation des taxes appelé par le module est également incomplet, un stub renvoie un taux de taxe fixe afin que le calcul puisse tout de même s'exécuter. Aucun de ces éléments de test n'est livré ; ils sont tous deux supprimés une fois les modules définitifs arrivés, ce qui explique pourquoi la mauvaise compréhension des doubles de test est mentionnée plus loin comme un problème récurrent.

Exemples de conseils pour les tests de modules

Voici quelques conseils à prendre en compte avant d'effectuer des tests de modules.

  • RevConsultez les cas de test avant de les utiliser.
  • Éviter toute confusion quant à l'origine des divergences.
  • Utilisez des outils de test automatisés.
  • Examinez les variables qui devraient rester inchangées.
  • Échanger les modules entre les testeurs pour éviter les autotests.
  • Réutilisez les cas de test.

Le cinquième conseil est plus important qu'il n'y paraît. Un développeur qui ne teste que le module qu'il vient d'écrire reproduit les mêmes hypothèses qui ont engendré le défaut ; par conséquent, faire tourner les modules entre les développeurs est l'un des moyens les plus économiques d'améliorer la qualité.

Tests unitaires vs tests de modules

Ces deux termes sont utilisés indifféremment dans de nombreuses équipes, mais l'auteur et la portée diffèrent.

Test des modules Tests unitaires
Les tests de module sont une collection de tests écrits par un testeur après qu'un code ait été écrit par un développeur. Tests unitaires sont une collection de tests écrits par un développeur au cours du processus de développement logiciel
Les tests de modules peuvent impliquer la combinaison de tests unitaires Les tests unitaires peuvent tester les unités isolément.

Tests de modules vs tests de composants vs tests d'intégration

Les tests de modules côtoient deux niveaux voisins avec lesquels il est facile de les confondre. Le tableau les distingue selon l'objet des tests et la personne qui les effectue habituellement.

Aspect Tests de modules Test de composants Test d'intégration
Sous test Un sous-programme, une classe ou une procédure Un composant autonome avec ses dépendances immédiates Les interfaces entre les modules combinés
Propriétaire habituel Testeur, après l'écriture du code Testeur testeur d'intégration
Andaimes Conducteurs et souches Stubs pour les dépendances externes De moins en moins de doubles en test
Défaut révélé Erreur logique à l'intérieur du module Erreur de comportement dans le composant Erreur d'interface et de transmission de données

Dans l'usage quotidien test de composants Les tests de modules et les tests de modules sont fréquemment considérés comme une seule et même activité, tandis que test d'intégration Cela ne commence qu'une fois que chaque module a été validé individuellement.

Défis liés aux tests de modules

Voici les défis que les équipes rencontrent le plus souvent lors de l'introduction des tests modulaires.

  • Les tests non incrémentiels nécessitent plus de travail — tout combiner au préalable signifie qu'une seule défaillance peut obliger les testeurs à reprendre l'intégralité du programme.
  • Test d'incompréhension double — un stub qui renvoie une valeur irréaliste produit une exécution réussie qui ne prouve rien.
  • Les tests de débogage sont souvent — Le code d'échafaudage comporte ses propres défauts, et le temps passé à corriger un pilote est du temps non consacré au test du module.
  • Besoin de comprendre le code — L’orientation « boîte blanche » signifie qu’un testeur qui ne sait pas lire le module ne peut pas concevoir de cas pertinents pour celui-ci.

FAQ

La famille xUnit couvre la plupart des langages, avec des bibliothèques de simulation fournissant les stubs et un outil de couverture indiquant les chemins d'exécution atteints. Le choix dépend du langage du module, et non du niveau de test.

Un modèle lit le code source du module, énumère les branches et propose un cas pour chacune, y compris les valeurs limites qu'une lecture manuelle omet souvent. RevL'examen reste nécessaire, car les cas générés affirment ce que fait le code plutôt que ce que requiert la spécification.

Oui, et c'est précisément dans le cas de la génération de code que ces assistants sont les plus performants, car un pilote ou un stub est un code répétitif dont la structure est connue. Les valeurs renvoyées nécessitent néanmoins une intervention humaine, car un stub d'apparence plausible peut masquer le défaut même que l'on cherche à identifier.

Il est suffisant que chaque branche et chaque limite du module ait été testée au moins une fois. Un objectif de pourcentage seul est trompeur, car une couverture élevée des instructions peut ne pas impliquer l'exploration de certains résultats de décision.

Après la compilation d'un module et avant que ses interfaces ne soient testées conjointement, il s'agit du premier niveau de test appliqué au code livré. C'est pourquoi les défauts détectés à ce stade n'atteignent jamais les phases d'intégration ou de système.

Suivez le code existant. L'approche descendante convient aux projets où la logique de contrôle est écrite en premier et où les modules inférieurs sont initialisés de manière simplifiée ; l'approche ascendante convient aux projets où les modules utilitaires sont implémentés en premier et appelés par les pilotes.

Le module se compile sans problème, sa spécification est disponible, ses dépendances sont présentes ou simulées, et les données de test sont prêtes. Commencer sans la spécification transforme l'exercice en une description du code.

Les tests ne peuvent jamais prouver qu'un module est exempt de défauts, mais seulement qu'il a résisté aux cas de figure testés. Concevoir des exécutions visant à mettre le module à l'épreuve fournit donc plus d'informations que concevoir des exécutions censées réussir.

Résumez cet article avec :