En quoi les tests d'intégration de composants diffèrent-ils de cela ?

Les tests de composants examinent un composant individuellement. Les tests d'intégration de composants examinent les interfaces et les interactions entre les composants et sont exécutés après les tests de composants.

Les tests de composants sont-ils une boîte noire ou une boîte blanche ?

Les deux, selon qui les gère. Les testeurs travaillent en boîte noire par rapport à la spécification du composant, tandis que les développeurs ayant accès au code effectuent une analyse en boîte blanche au sein de ce même composant.

Qu'est-ce que le test de composants ? Techniques, exemples de cas de test

⚡ Résumé intelligent

Les tests de composants vérifient chaque partie d'une application individuellement, sans l'intégrer au reste, afin que les défauts soient détectés et corrigés au sein d'un seul module avant le début de l'assemblage.

🧩 Portée: Un composant à la fois, isolé des composants qui l'entourent.
👥 Propriétaire: Les testeurs l'exécutent une fois que les développeurs ont terminé les tests unitaires.
(I.e. CTIS : Le test de composants en mode réduit isole complètement le composant.
🔗 CTIL : Les tests de composants à grande échelle conservent les dépendances, réelles ou simulées.
🧱 Doubles: Un pilote appelle le composant ; un stub est appelé par celui-ci.
✅ Exit: Aucun défaut critique, élevé ou moyen ne reste ouvert dans le journal.

Qu'est-ce que le test de composants ?

Test de composants Il s'agit d'un type de test logiciel où les tests sont effectués sur chaque composant individuellement, sans l'intégrer aux autres. D'un point de vue architectural, on l'appelle également… test de moduleet certaines références l'appellent test de programme.

Tout logiciel est composé de plusieurs composants, et les tests au niveau des composants consistent à tester ces composants individuellement. C'est l'une des méthodes les plus fréquentes. test de la boîte noire types de tâches effectuées par l'équipe d'assurance qualité.

Il convient de faire une remarque dès le début concernant la dénomination. Le glossaire ISTQB traite des tests de composants et tests unitaires On utilise souvent les termes « tests unitaires » et « tests de composants » pour désigner le même niveau de test. Dans la pratique, de nombreuses équipes de développement, et cet article le confirment, font la distinction : les développeurs exécutent les tests unitaires sur leur propre code, puis les testeurs exécutent les tests de composants sur la version livrée. Le tableau comparatif à la fin de cet article illustre cette distinction.

Comme le montre le schéma ci-dessous, les tests de composants possèdent leur propre stratégie et leur propre plan de test, dans lesquels chaque partie du logiciel ou de l'application est considérée individuellement. Pour chaque composant, scénario d'essai est défini, puis décomposé en cas de test de haut niveau et enfin en cas de test détaillés de bas niveau. cas de test avec prérequis.

L’usage du terme « tests de composants » varie selon les domaines et les organisations. Les trois raisons les plus courantes de cette différence de perception sont présentées ci-dessous.

Le type de modèle de cycle de vie de développement choisi
La complexité du logiciel ou de l'application testée
Que les tests soient effectués avec ou sans isolation des autres composants de l'application

Le cycle de vie des tests logiciels génère de nombreux artefacts de test, c'est-à-dire les documents créés et utilisés lors des activités de test. Parmi eux figurent la politique et la stratégie de test, qui définissent les types de tests utilisés et leur niveau de détail dans un projet donné.

Qui effectue les tests de composants

Les tests de composants sont effectués par les testeurs. Les tests unitaires sont réalisés par les développeurs, qui testent une fonction ou une procédure individuelle. Une fois les tests unitaires terminés, les tests de composants sont effectués et pris en charge par les testeurs.

Quand effectuer des tests de composants

Les tests de composants sont effectués peu après les tests unitaires réalisés par les développeurs et la mise à disposition de la version de développement à l'équipe de test. Cette version est appelée version de test unitaire (UT). Les principales fonctionnalités de chaque composant sont testées lors de cette phase.

Critères d'entrée pour les tests de composants

L'ensemble minimal de composants à inclure dans la version UT a été développé et testé unitairement.

Critères de sortie pour les tests de composants

Chaque composant fonctionne comme prévu.
Aucun défaut critique, de gravité élevée ou moyenne, ni aucun défaut prioritaire ne reste ouvert dans le journal des défauts.

Techniques de test des composants

En fonction du niveau de profondeur des tests, les tests de composants sont catégorisés de deux manières.

CTIS — Tests de composants en petit
CTIL — Tests de composants à grande échelle

CTIS — Tests de composants en petit

Les tests de composants peuvent être effectués avec ou sans isolation des autres composants de l'application testée. Lorsqu'ils sont réalisés avec les autres composants isolés, on parle de tests de composants à petite échelle.

Exemple 1: Sur un site web comportant cinq pages différentes, tester chaque page séparément et indépendamment des autres composants constitue un test de composants à petite échelle.

Exemple 2: La page d'accueil de guru99.com, présentée ci-dessous, comporte de nombreuses sections, telles que Accueil, Tests, SAPWeb, À apprendre absolument !, Big Data, Projets en direct et Blog.

Tout logiciel est composé de nombreux composants, et chaque composant possède ses propres sous-composants. Tester séparément chaque module listé dans l'exemple 2, sans tenir compte de son intégration avec les autres composants, revient à effectuer des tests de composants à petite échelle.

L'ouverture du menu déroulant Tests révèle les sous-composants du composant Tests : Test manuel, SOAPUI, QTP, JUnit, Selenium, Gestion des tests et Test mobile. Sur la capture d'écran ci-dessous, ces sous-composants sont mis en évidence en rouge.

CTIL — Tests de composants à grande échelle

Les tests de composants effectués sans isolation des autres composants de l'application testée sont appelés tests de composants à grande échelle.

Un exemple permet de mieux comprendre la différence. Supposons qu'une application soit composée de trois composants : le composant A, le composant B et le composant C.

Le développeur a créé le composant B et souhaite le faire tester. Pour tester complètement le composant B, certaines de ses fonctionnalités dépendent du composant A et d'autres du composant C, comme l'illustre le schéma ci-dessous.

Le flux de fonctionnalités est A → B → C, ce qui signifie que le composant B dépend à la fois de A et de C. Dans ce flux, le stub est la fonction appelée et le pilote est la fonction appelante.

Les composants A et C n'ont pas encore été développés. Pour tester complètement le composant B, A et C sont remplacés, selon les besoins, par un pilote et un stub ; les deux éléments manquants servent donc d'objets factices en attendant la création des composants définitifs.

Bout: Un stub est appelé par le composant testé. Le composant C n'étant pas prêt, un stub le remplace et renvoie les réponses attendues par B.
Driver: Un pilote appelle le composant testé. Le composant A n'étant pas prêt, un autre pilote le remplace et invoque le composant B avec les entrées requises.

Exemples de cas de test pour les tests de composants

Les deux pages web ci-dessous sont liées fonctionnellement, ce qui en fait une paire de composants utiles à tester.

La page Web 1 est la page de connexion du site bancaire de démonstration.

Lorsque l'utilisateur saisit un identifiant et un mot de passe valides et clique sur le bouton « Soumettre », la page redirige vers la page d'accueil du site web de démonstration de la banque, illustrée ci-après.

Ici, la page de connexion est un composant et la page d'accueil en est un autre. Tester la fonctionnalité de chaque page séparément constitue un test de composant.

Scénarios de test des composants sur la page web 1 :

Saisissez un identifiant utilisateur invalide et vérifiez qu'un avertissement convivial est affiché à l'utilisateur final.
Saisissez un identifiant et un mot de passe invalides, cliquez sur Réinitialiser, puis vérifiez que les champs identifiant et mot de passe sont effacés.
Saisissez un nom d'utilisateur et un mot de passe valides, puis cliquez sur le bouton « Se connecter ».

Scénarios de test des composants sur la page web 2 :

Vérifiez que le message de bienvenue de la page de gestion s'affiche bien sur la page d'accueil.
Vérifiez que tous les liens situés à gauche de la page Web sont cliquables.
Vérifiez que l'identifiant du responsable est affiché au centre de la page d'accueil.
Vérifiez la présence des trois images différentes sur la page d'accueil, conformément au schéma.

Tests unitaires et tests de composants

Le tableau ci-dessous résume les différences entre les deux niveaux dans la pratique quotidienne.

Tests unitaires	Test des composants
Tester les programmes et modules individuels pour démontrer que le programme s'exécute conformément aux spécifications.	Tester chaque objet ou partie du logiciel séparément, avec ou sans isolation des autres objets.
Validé par rapport aux documents de conception.	Validé par rapport aux exigences de test et aux cas d'utilisation.
Réalisé par les développeurs.	Réalisé par des testeurs.
Fait en premier.	À faire une fois les tests unitaires terminés côté développeurs.
Les défauts sont généralement réparés sur place et ne sont pas consignés officiellement.	Les défauts sont enregistrés et tracguidé tout au long du processus de gestion des défauts.

FAQ

Réduire les risques, vérifier le comportement fonctionnel et non fonctionnel du composant, renforcer la confiance dans sa qualité, détecter les défauts et empêcher leur propagation.ping à des niveaux de test plus élevés.

Les modèles lisent un composant contracLe système identifie et signale les entrées invalides, les valeurs limites et les chemins d'erreur qu'une vérification manuelle a tendance à manquer. Un testeur confirme néanmoins chaque résultat attendu avant l'exécution.

Oui. Un stub renvoyant des réponses prédéfinies et un pilote fournissant des entrées fixes constituent un code standardisé qu'un assistant écrit rapidement. Le choix des réponses réalistes reste une décision humaine.

Les tests de composants examinent un composant individuellement. test d'intégration examine les interfaces et les interactions entre les composants, et s'exécute après les tests des composants.

Code-cadres de niveau tels que JUnit, TestNG, NUnit et pytest, ainsi que des exécuteurs de composants d'interface utilisateur tels que Cypress Tests de composants, Storybook et Jest. Tous s'intègrent dans un l'automatisation pipeline.

Création et maintenance des doublons. Un stub qui s'éloigne du composant réel masque les défauts jusqu'à l'intégration ; il est donc nécessaire de réexaminer chaque réponse simulée une fois la dépendance réelle déployée.

Cela inverse l'ordre. Les cas d'utilisation sont rédigés et automatisés avant même la création du composant, puis le code est ajouté progressivement jusqu'à ce que les tests soient validés. Le composant est livré avec sa suite de tests déjà en place.

Les deux, selon qui les gère. Les testeurs travaillent en boîte noire par rapport aux spécifications du composant, tandis que les développeurs ayant accès au code les appliquent. boîte blanche couverture à l'intérieur du même composant.