Qu'est-ce qu'un test d'intégration?

Mes amis et moi avons eu du mal à classer exactement ce qu'est un test d'intégration.

En rentrant chez moi, je viens de me rendre compte que chaque fois que j’essaie de donner un exemple concret de test d’intégration, c’est un test d’acceptation, c’est-à-dire. Quelque chose qu'un homme d'affaires dirait à haute voix et spécifie ce que le système devrait fournir.

J'ai consulté la documentation de Ruby on Rails pour connaître leur classification de ces types d'essais, et elle est maintenant complètement rejetée.

Pouvez-vous me donner une brève description académique d'un test d'intégration avec un exemple du monde réel?

Pour le moment, j'aime bien cette déclaration: "Ce n'est pas important ce que vous appelez, mais ce qu'il fait" faite par Gojko Adzic dans cet article .

Vous devez vraiment spécifier aux personnes qui parlent les tests ce que vous avez l’intention de tester.

Beaucoup de gens ont des points de vue différents selon leur rôle.

Pour les testeurs, TMap est une méthodologie de test généralement acceptée aux Pays-Bas . TMap fait la distinction suivante.

• Test de l'unité
• test d'intégration unitaire
• test du système
• test d'intégration système
• test d'acceptation (tous types / niveaux)
• test d'acceptation fonctionnelle
• test d'acceptation utilisateur
• test d'acceptation de production

Ils ont des types plus spécifiques de tests qui peuvent être effectués dans les tests mentionnés ci-dessus. Regardez ce mot doc pour un aperçu.

Wikipedia a également un bon aperçu .

Le livre du programmeur pragmatique dit:

• un test unitaire est un test qui exerce un module
• les tests d'intégration montrent que les principales parties d'un système fonctionnent bien ensemble

En examinant ces différentes sources et en intégrant certaines de mes propres expériences et opinions, je commencerais par distinguer trois catégories.

• qui fait les tests en général
• ce qui est testé

• quel est le but du test

  • Test unitaire : teste la logique dans les classes par les programmeurs pour montrer la correction au niveau du code. Ils doivent être rapides et ne pas dépendre d'autres parties du système que vous n'avez pas l'intention de tester.
  • Test d'acceptation fonctionnelle : teste un scénario de cas d'utilisation sur un ensemble de données limité (spécialement créé) effectué par le service de test pour montrer que chaque scénario spécifié fonctionne comme prévu.
  • Test d'acceptation des utilisateurs : teste des scénarios de cas d'utilisation sur la production, tels que des données effectuées par des représentants des utilisateurs pour les amener à accepter formellement l'application.
  • Test d'intégration : testez les chemins de communication entre les différentes parties du module, réalisés par le service de test ou les développeurs, pour montrer que tous les modules fonctionnent correctement ensemble.

Ma liste ci-dessus n’est qu’un début et une suggestion, mais j’ai vraiment l’impression que: «L’appel que vous appelez n’est pas important, mais son rôle»

J'espère que cela t'aides.

26-10-2016 Edit: Récemment, une très belle introduction a été placée sur les tests unitaires YouTube et les tests d'intégration - Les réflexions de MPJ - FunFunFunction # 55

test d'intégration, il s'avère être un test d'acceptation

Évidemment.

Ces deux sont presque la même chose. Mais la définition du test présente des dimensions légèrement différentes.

Intégration == le système dans son ensemble.

Acceptation == le système dans son ensemble.

La seule différence - et c'est subtile - est la définition des cas de test.

Intégration == cas de test pour tester la profondeur et le degré d'intégration. Est-ce que cela fonctionne pour tous les cas extrêmes et les cas d'angle? Les cas de test tendent à être techniques, écrits par des concepteurs et des codeurs.

Acceptance == cas de test pour n'exercer que 80% de l'ensemble des fonctionnalités axées sur l'utilisateur final. Pas tous les cas bord et coins. Les cas de test ont tendance à être non techniques, rédigés par les utilisateurs finaux.

Personnellement, j’aime penser à un test d’intégration comme à un test de fonctionnalité lorsque chaque composant du système est réel , sans objets fictifs.

Un vrai référentiel, une vraie base de données, une vraie interface utilisateur. Vous testez des fonctionnalités spécifiques lorsque le système est entièrement assemblé et qu'il est supposé l'être une fois déployé.

Dans mon (je l'avoue) peu d'expérience, j'ai compris que le mot intégration peut réellement créer des malentendus: en réalité, il est difficile de trouver quelque chose de complètement isolé dans un système, certains éléments nécessiteront certainement une certaine intégration.

Ainsi, je me suis habitué à faire les distinctions suivantes:

• J'utilise des tests unitaires pour identifier, documenter et mettre en évidence tous les comportements que la classe que je teste est responsable d'accomplir.
• Je fais des tests d'intégration chaque fois que j'ai dans mon système un composant (éventuellement plus d'un) en conversation avec un autre système " externe ". (continue ci-dessous ...)
• J'implémente un test d'acceptation pour définir, documenter et souligner un certain flux de travail attendu par le système.

Dans la définition du test d'intégration, par externe, j'entendais les systèmes situés en dehors de ma plage de développement : je ne peux pas changer immédiatement leur comportement, pour quelque raison que ce soit. Il peut s'agir d'une bibliothèque, d'un composant du système qui ne peut pas être modifié (c'est-à-dire partagé avec d'autres projets de l'entreprise), d'un dbms, etc. Pour ces tests, je dois configurer quelque chose de très similaire à l'environnement réel du système. fonctionnera dans: un système externe doit être initialisé et réglé à un certain état; des données réalistes doivent être enregistrées dans la base de données; etc.

Au lieu de cela, lorsque je fais des tests d'acceptation, je simule des choses: je travaille sur quelque chose de différent, je travaille sur les spécifications du système, pas sur sa capacité à collaborer avec des entités externes.

C'est vraiment une vision plus étroite par rapport à ce que KeesDijk a décrit plus tôt, mais je suppose que les projets sur lesquels j'ai travaillé jusqu'à présent étaient suffisamment petits pour me permettre ce niveau de simplification.

Un test d'intégration vérifie que les composants d'un système complexe (logiciels, avions, centrales, etc.) fonctionnent ensemble comme prévu.

Imaginons qu'il s'agisse d'un avion (avec un logiciel, c'est plus abstrait et difficile à faire la différence). Les tests d'intégration comprennent, vérifiant:

• interaction correcte entre certains composants. Exemple: en appuyant sur le bouton de démarrage, le moteur démarre et l'hélice atteint la vitesse de rotation attendue (l'avion reste toujours au sol)
• interaction correcte avec les composants externes. Exemple: vérifier que la radio intégrée peut communiquer avec une radio fixe (avion encore au sol)
• interaction correcte entre tous les composants impliqués, de sorte que le système dans son ensemble fonctionne comme prévu. Exemple: une équipe de pilotes d'essais et d'ingénieurs démarre l'avion et vole avec lui (ils portent tous des parachutes ...).

Le test d'intégration répond à un problème technique , à savoir que le système fonctionne malgré sa subdivision en composants. Dans le logiciel, les composants peuvent être des cas d’utilisation, des modules, des fonctions, des interfaces, des bibliothèques, etc.

Le test d'acceptation vérifie que le produit est adapté à l'usage auquel il est destiné. Ils sont en principe effectués par le client. En prenant l'analogie de l'aéronef, ils vérifient notamment que:

• Les scénarios d’entreprise envisagés donnent les résultats escomptés dans une situation presque réelle. Exemple: répétez un embarquement avec des passagers d’essai pour vérifier que le personnel peut contrôler l’embarquement comme prévu avec les procédures opérationnelles. Certains scénarios peuvent être si simples qu’ils ressemblent à des tests unitaires, mais ils sont réalisés par l’utilisateur (par exemple, essayez les prises électriques avec les équipements de l’entreprise).
• le système fonctionne dans une situation commerciale presque réelle. Exemple: effectuez un vol d’essai vide entre deux destinations réelles, avec des pilotes nouvellement formés de la compagnie aérienne pour vérifier que la consommation de carburant est conforme aux promesses.

Le test d'acceptation aborde davantage un problème de responsabilité . Dans une relation client / fournisseur, il peut s'agir d'une responsabilité contractuelle (respect de toutes les exigences). Mais dans tous les cas, il incombe également à l’organisme utilisateur de s’assurer que ses fonctions peuvent être exécutées avec le système et d’éviter avec prudence tout problème imprévu (par exemple, cette société de chemins de fer qui a découvert lors des essais de réception qu’elle avait dû raccourcir certaines les nouveaux wagons étaient 5 cm trop grand - pas de blague!).

Conclusions: Les tests d'intégration et d'acceptation se chevauchent. Ils ont tous deux l'intention de montrer que le système dans son ensemble fonctionne. Cependant, le "tout" peut être plus grand pour le client (car le système peut lui-même faire partie d'un système organisationnel plus grand) et plus technique pour l'intégrateur de système:

Les tests d'intégration ne sont rien d'autre que la vérification de la connexion et de l'exactitude du flux de données entre deux modules ou plus.

Par exemple: lorsque nous composons un courrier (un module) et l'envoyons à un ID utilisateur valide (deuxième module), le test d'intégration consiste à vérifier si le courrier envoyé est présent dans les éléments envoyés.

Une définition pratique d'un test d'intégration est la suivante: Tout test nécessitant une interaction avec quelque chose hors processus.

Par exemple:

• Le système de fichiers
• Le réseau
• Une base de données
• Une API externe

Il existe un type de contrat entre votre processus et le monde externe, et le vérifier au minimum devrait être l'objectif d'un test d'intégration. c'est-à-dire qu'il ne devrait pas simplement vérifier le contrat. Si c'est le cas, vous vous dirigez vers l'espace système / de bout en bout.

Les tests unitaires sont capables de tester toute la logique au sein de votre processus, et ils peuvent le faire facilement, précisément en raison de l'absence de dépendances sur le "monde extérieur" lent / fragile / complexe.

Bien qu'il existe des tests d'intégration que cette définition ne couvre pas (d'où la raison pour laquelle je l'ai appelée une définition pratique ), je pense qu'ils sont beaucoup moins communs / utiles.

NB: à proprement parler, oui, cette définition couvrirait également les tests de système / de bout en bout. Dans ma philosophie, il s’agit d’une forme de test d’intégration «extrême», ce qui explique pourquoi leurs noms soulignent un autre aspect. Dans l’autre sens, un test unitaire peut être considéré comme un test d’intégration à zéro composant, c’est-à-dire que tous les tests peuvent être considérés comme se situant quelque part sur le spectre d’intégration, intégrant entre les composants 0-n :-)