Menu

Qu'est-ce que le test de composant ou le test de module (apprendre avec des exemples)

what is component testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Qu'est-ce que le test de composants également appelé test de module dans le test de logiciel:

Un composant est l'unité la plus basse de toute application. Donc, les tests de composants; comme son nom l'indique, est une technique de test de l'unité la plus basse ou la plus petite de toute application.

Les tests de composants sont parfois également appelés tests de programmes ou de modules.

Une application peut être pensée comme une combinaison et une intégration de nombreux petits modules individuels. Avant de tester l'ensemble du système, il est impératif que chaque composant OU la plus petite unité de l'application soit testé à fond.

meilleur moyen de convertir youtube en mp4

Dans ce cas, les modules ou les unités sont testés indépendamment. Chaque module reçoit une entrée, effectue un traitement et génère la sortie. La sortie est ensuite validée par rapport à la fonctionnalité attendue.

Qu

Les applications logicielles sont énormes par nature et c'est un défi de tester l'ensemble du système. Cela peut entraîner de nombreuses lacunes dans la couverture des tests. Par conséquent, avant de passer aux tests d'intégration ou aux tests fonctionnels, il est recommandé de commencer par les tests de composants.

Lire aussi=> Différence d'unité, d'intégration et de test fonctionnel

Ce que vous apprendrez:

Test des composants

C'est une sorte de test de boîte blanche.

Ainsi, les tests de composants recherchent les bogues et vérifient le fonctionnement des modules / programmes qui sont testables séparément.

Il existe une stratégie de test et un plan de test pour le test des composants. Et, pour chaque composant, il existe un scénario de test qui sera détaillé dans les cas de test. Le diagramme ci-dessous représente la même chose:

Test des composants

L'objectif des tests de composants

Le principal objectif des tests de composants est de vérifier le comportement d'entrée / sortie de l'objet de test. Il garantit que la fonctionnalité de l’objet de test fonctionne correctement et parfaitement conformément aux spécifications souhaitées.

Entrées pour les tests au niveau des composants

Les quatre principales contributions aux tests au niveau des composants sont:

  • Plan de test du projet
  • Configuration requise
  • Spécifications des composants
  • Implémentations de composants

Qui teste les composants?

Le test des composants est effectué par les services d'assurance qualité ou le testeur.

Qu'est-ce qui est testé dans le cadre des tests de composants?

Les tests de composants peuvent prendre en compte la vérification des caractéristiques fonctionnelles ou non fonctionnelles spécifiques des composants du système.

Cela peut être le test du comportement des ressources (par exemple, la détermination des fuites de mémoire), des tests de performances, des tests structurels, etc.

Quand le test des composants est-il terminé?

Le test des composants est effectué après le test unitaire.

Les composants sont testés dès leur création, il y a donc des chances que les résultats récupérés d'un composant testé dépendent d'autres composants qui à leur tour ne sont pas développés pour le moment.

En fonction du modèle de cycle de vie de développement, les tests de composants peuvent être effectués de manière isolée avec d'autres composants du système. L'isolement est fait pour éviter les influences extérieures.

Donc, pour tester ce composant, nous utilisons des stubs et des pilotespour simuler l'interface entre les composants logiciels.

Les tests d'intégration sont effectués après les tests des composants.

Stratégie de test des tests de composants

Selon la profondeur du niveau de test, le test des composants est divisé en deux parties:

  1. Test de composants en petit (ctis)
  2. Test de composants en grand (CTIL)

Lorsque les tests de composants sont effectués isolément avec d'autres composants, ils sont appelés tests de composants en petit. Cela se fait sans tenir compte de l'intégration avec d'autres composants.

Lorsque les tests de composants sont effectués sans isolation avec d'autres composants du logiciel, ils sont appelés tests de composants dans leur ensemble. Cela se produit lorsqu'il existe une dépendance sur le flux de fonctionnalités des composants et que nous ne pouvons donc pas les isoler.

Si les composants sur lesquels nous avons une dépendance ne sont pas encore développés, nous utilisons des objets factices à la place des composants réels. Ces objets factices sont le stub (appelé fonction) et le pilote (fonction d'appel).

Stubs et pilotes

Avant de passer à la brève description des stubs et des pilotes, je devrais vous présenter les différence entre les tests de composants et les tests d'intégration. La raison en est que les stubs et les pilotes sont également utilisés dans les tests d'intégration, ce qui peut conduire à une certaine confusion entre ces deux techniques de test.

La technique de test d'intégration est une technique dans laquelle nous combinons 2 composants séquentiellement et testons ensemble le système intégré. Les données d'un système sont transmises à un autre système et l'exactitude des données est validée pour le système intégré.

Contrairement aux tests de modules où le composant / module unique est testé minutieusement avant de l'intégrer à d'autres composants. Ainsi, nous pouvons dire que les tests de composants sont effectués avant les tests d'intégration.

Utilisations d'intégration et de composants Stubs et pilotes .

'Conducteurs' sont les programmes factices qui sont utilisés pour appeler les fonctions du module le plus bas au cas où la fonction appelante n'existe pas.

'Stubs' peut être appelé code un extrait de code qui accepte les entrées / demandes du module supérieur et renvoie les résultats / réponse

Comme expliqué précédemment, les composants sont testés individuellement et indépendamment. Ainsi, il peut y avoir certaines caractéristiques des composants, dépendant de l'autre composant qui n'est pas développé actuellement. Donc, pour tester les composants avec ces fonctionnalités «non développées», nous devons utiliser des agents stimulants qui traiteraient les données et les renverraient aux composants appelants.

De cette façon, nous nous assurons que les composants individuels sont testés minutieusement.

les composants individuels sont testés minutieusement

Ici, nous voyons que:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— sont les composants
  • C1, C2 et C3 forment ensemble la sous-unité 1
  • C4 et C5 forment ensemble la sous-unité 2
  • C6, C7 et C8 forment ensemble la sous-unité 3
  • C9 seul fait la sous-unité 4
  • La sous-unité 1 et la sous-unité 2 se combinent pour former l'unité commerciale 1
  • La sous-unité 3 et la sous-unité 4 se combinent pour former l'unité commerciale 2
  • La Business Unit 1 et la Business Unit 2 se combinent pour créer la candidature.
  • Ainsi, le test des composants, dans ce cas, consisterait à tester les composants individuels qui sont de C1 à C9.
  • La Net La flèche entre la sous-unité 1 et la sous-unité 2 montre le point de test d'intégration.
  • De même, le Net la flèche entre la sous-unité 3 et la sous-unité 4 montre le point de test d'intégration
  • La flèche verte entre la Business Unit 1 et la Business Unit 2 indique le point de test d'intégration

Par conséquent, nous ferions:

  • COMPOSANT test pour C1 à C9
  • L'INTÉGRATION tests entre les sous-unités et les unités d'affaires
  • SYSTÈME test de l'application dans son ensemble

Un exemple

Jusqu'à présent, nous devons avoir établi que le test des composants est une sorte de technique de test de boîte blanche . Eh bien, c'est peut-être vrai. Mais cela ne signifie pas que cette technique ne pourrait pas être utilisée dans la technique de test de la boîte noire.

passerelle par défaut wifi windows 10 non disponible

Considérez une énorme application Web qui commence par une page de connexion. En tant que testeur (cela aussi dans un monde agile), nous ne pouvions pas attendre que toute l'application soit développée et prête à être testée. Afin d'augmenter notre temps de mise sur le marché, nous devons commencer les tests tôt. Ainsi, lorsque nous voyons que la page de connexion est développée, nous devons insister pour qu'elle soit mise à disposition pour que nous puissions la tester.

Dès que vous disposez de la page de connexion à tester, vous pouvez exécuter tous vos cas de test (positifs et négatifs) pour vous assurer que la fonctionnalité de la page de connexion fonctionne comme prévu.

Les avantages de tester votre page de connexion à ce stade seraient:

c # questions et réponses d'entretien technique
  • L'interface utilisateur est testée pour sa convivialité (fautes d'orthographe, logos, alignement, formatage, etc.)
  • Essayez d'utiliser techniques de test négatif comme de l'authentification et de l'autorisation. Il y a une énorme probabilité de trouver des défauts dans ces cas.
  • Utilisation de techniques telles que les injections SQL garantirait de tester la violation de la sécurité à un stade très précoce.

Les défauts que vous consigneriez à ce stade agiraient comme des «leçons apprises» pour l'équipe de développement et celles-ci seraient implémentées dans le codage de la page consécutive. Par conséquent, en testant tôt, vous avez assuré une meilleure qualité des pages qui doivent encore être développées.

Étant donné que les autres pages consécutives ne sont pas encore développées, vous aurez peut-être besoin de stubs pour valider la fonctionnalité de la page de connexion. Par exemple ,vous voudrez peut-être une page simple indiquant «connexion réussie», en cas d'informations d'identification correctes et une fenêtre contextuelle de message d'erreur en cas d'informations d'identification incorrectes.

Vous pouvez parcourir notre tutoriel précédent sur Test d'intégration pour avoir plus d'informations sur les stubs et les pilotes.

Comment écrire des cas de test de composants?

Les cas de test pour les tests de composants sont dérivés de produits de travail, par exemple, la conception de logiciels ou le modèle de données. Chaque composant est testé à travers une séquence de cas de test où chaque cas de test couvre une combinaison spécifique d'entrée / sortie, c'est-à-dire une fonctionnalité partielle.

Vous trouverez ci-dessous un exemple de cas de test de composant pour le module de connexion.

Nous pouvons écrire d'autres cas de test de la même manière.

cas de test

Test de composants vs tests unitaires

La toute première différence entre le test de composants et les tests unitaires est que le premier est effectué par des testeurs tandis que le second est effectué par des développeurs ou des professionnels du SDET.

Les tests unitaires sont effectués à un niveau granulaire. D'autre part, le test des composants est effectué au niveau de l'application. Dans les tests unitaires, il est vérifié si un programme individuel ou le morceau de code est exécuté conformément à ce qui est spécifié. Lors des tests de composants, chaque objet du logiciel est testé séparément avec ou sans isolation avec d'autres composants / objets du système.

Ainsi, les tests de composants sont assez similaires aux tests unitaires, mais ils sont effectués à un niveau d'intégration supérieur et dans le contexte de l'application (pas seulement dans le contexte de cette unité / programme comme dans les tests unitaires).

Test composant Vs Interface Vs Intégration Vs Systèmes

Composant , comme je l'ai expliqué, est l'unité la plus basse d'une application qui est testée indépendamment.

Une interface est la couche de jonction des 2 composants. Le test de la plateforme ou de l'interface sur laquelle interagissent les 2 composants est appelé test d'interface.

Maintenant, tester l'interface est un peu différent. Ces interfaces sont pour la plupart API ou services Web , donc le test de ces interfaces ne serait pas similaire à la technique de la boîte noire, vous feriez plutôt une sorte de test d'API ou de test de service Web en utilisant Interface utilisateur SOAP ou tout autre outil.

Une fois le test d'interface terminé, vient le Test d'intégration .

Pendant le test d'intégration, nous combinons les composants individuels testés un par un et le testons de manière incrémentielle. Nous validons pendant l'intégration que les composants individuels lorsqu'ils sont combinés un par un, se comportent comme prévu et que les données ne sont pas modifiées lors du passage d'un module à un autre module.

Une fois tous les composants intégrés et testés, nous effectuons le Test des systèmes pour tester l'ensemble de l'application / du système dans son ensemble. Ce test valide les exigences métier par rapport au logiciel implémenté.

Conclusion

je dirais que Test unitaire et les tests des composants sont effectués côte à côte.

Contrairement aux tests unitaires qui sont effectués par l'équipe de développement, les tests des composants / modules sont effectués par l'équipe de test. Il est toujours recommandé d'effectuer un test complet des composants avant de lancer les tests d'intégration.

Si les tests de composants sont solides, nous trouverons moins de défauts dans les tests d'intégration. Il y aurait des problèmes, mais ces problèmes seraient liés à l'environnement d'intégration ou aux problèmes de configuration. Vous pouvez vous assurer que la fonctionnalité des composants intégrés fonctionne correctement.

J'espère que ce didacticiel a été utile pour comprendre les tests de composants, d'intégration et de système. Si vous avez encore des questions, n'hésitez pas à nous les poser dans les commentaires.

lecture recommandée

^