Qu'est-ce qu'un test d'intégration exactement?
Mes amis et moi avons eu du mal à classer exactement ce qu'est un test d'intégration.
Maintenant, sur le chemin du retour, je viens de réaliser que chaque fois que j'essaie de donner un exemple réel d'un test d'intégration, il se révèle être un test d'acceptation, c'est-à-dire. quelque chose qu'un homme d'affaires dirait à haute voix qui précise ce que le système devrait offrir.
J'ai vérifié la documentation Ruby sur Rails pour leur classification de ces types de tests, et c'est maintenant complètement perdu).
Pouvez-vous me donner une courte description académique d'un test d'intégration avec un exemple réel?
Pour l’instant, j’aime cette déclaration: "Ce n’est pas important ce que vous appelez, mais ce qu’elle fait" faite par Gojko Adzic dans cet article .
Vous devez vraiment spécifier avec les personnes qui parlent des tests ce que vous avez l'intention de tester.
Il y a beaucoup de gens qui ont des opinions différentes, selon leur rôle.
Pour les testeurs, une méthodologie de test généralement acceptée aux Pays-Bas est TMap . 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 (toutes sortes/niveaux)
- test d'acceptation fonctionnelle
- test d'acceptation des utilisateurs
- test d'acceptation de la production
Ils ont des types de tests plus spécifiques qui peuvent être effectués dans le cadre des tests mentionnés ci-dessus. Regardez ce document Word pour un aperçu.
Wikipedia a également un Nice overview .
Le livre le 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 regardant ces différentes sources et en faisant part de mes propres expériences et opinions, je commencerais par faire des distinctions par trois catégories
- qui fait les tests en général
- ce qui est testé
quel est le but du test
- Test unitaire : testez la logique dans les classes par les programmeurs pour montrer l'exactitude du niveau de 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 : testez des scénarios 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 spécifié.
- Test d'acceptation des utilisateurs : testez des scénarios de cas d'utilisation sur la production comme des données effectuées par des représentants des utilisateurs pour les faire accepter formellement l'application
- Test d'intégration : Testez les voies de communication entre les différentes parties du module effectuées par le département de test ou par 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 je pense vraiment: "Ce n'est pas important ce que vous appelez, mais ce qu'il fait"
J'espère que cela t'aides.
26-10-2016 Edit: Tout récemment, une très belle introduction a été placée sur YouTube Tests unitaires vs tests d'intégration - MPJ's Musings - FunFunFunction # 55
test d'intégration, il se révèle être un test d'acceptation
Évidemment.
Ces deux sont presque la même chose. Mais la définition du test comporte 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 subtil - est la définition des cas de test.
Intégration == cas de test pour tester la profondeur et le degré d'intégration. Cela fonctionne-t-il pour tous les cas Edge et les cas d'angle? Les cas de test ont tendance à être techniques, écrits par des concepteurs et des codeurs.
Acceptation == cas de test pour exercer uniquement les 80% axés sur l'utilisateur final de l'ensemble de fonctionnalités. Pas tous les cas Edge et Corner. Les cas de test ont tendance à être non techniques, écrits 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, pas de faux objets.
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 ressemble à ce qu'il est censé être lors du déploiement.
Dans ma (j'admets) petite expérience, j'ai compris que l'intégration de Word peut vraiment créer des malentendus: vraiment, il est difficile de trouver quelque chose de complètement isolé dans un système, certains éléments auront besoin d'une intégration à coup sûr.
Ainsi, je me suis habitué à faire les distinctions suivantes:
- J'utilise test unitaire pour identifier, documenter et souligner tous les comportements que la classe que je teste doit accomplir.
- Je fais tests d'intégration chaque fois que j'ai un composant (peut-être plus d'un) dans mon système qui a une conversation avec un autre système "external". (continue ci-dessous ...)
- J'implémente un test d'acceptation pour définir, documenter et stresser un certain workflow attendu par le système.
Dans la définition du test d'intégration, par externe, j'entendais un système qui est hors 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 qu'il est 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é sur 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 faux 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 vue 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 (par exemple logiciel, avion, centrale électrique) fonctionnent ensemble comme prévu.
Imaginons que nous parlions d'un avion (avec un logiciel, c'est plus abstrait et difficile de 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 embarquée peut communiquer avec une radio fixe (avion toujours au sol)
- interaction correcte entre tous les composants impliqués, afin 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 (ils portent tous des parachutes ...).
Le test d'intégration résout 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 prévu. Ils sont en principe exécutés par le client. Prenant l'analogie de l'avion, ils comprennent la vérification que:
- les scénarios d'affaires envisagés conduisent au résultat attendu dans une situation quasi réelle. Exemple: répéter l'embarquement avec des passagers test pour vérifier que le personnel peut surveiller l'embarquement comme prévu avec les procédures d'exploitation. Certains scénarios pourraient être si simples qu'ils ressembleraient à des tests unitaires, mais ils sont effectués par l'utilisateur (par exemple, essayez les fiches électriques avec l'équipement 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 à la promesse.
Le test d'acceptation répond plus à 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 est également de la responsabilité de l'organisation utilisatrice de s'assurer que ses fonctions peuvent être poursuivies avec le système et d'éviter prudemment tout problème imprévu (par exemple, comme cette société de chemins de fer qui a découvert lors des tests d'acceptation qu'elle devait raccourcir certains quais parce que les nouveaux wagons étaient 5 cm trop grands - 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" pourrait être plus grand pour le client (car le système peut lui-même faire partie d'un système organisationnel plus large), 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 ou plusieurs modules.
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: Tout test qui nécessite 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 extérieur, et la vérification minimale de ce contrat devrait être l'objectif d'un test d'intégration. c'est-à-dire qu'il ne doit faire que 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 à l'intérieur de vos limites de processus, et ils peuvent le faire facilement précisément en raison du manque de dépendances sur le lent/fragile/"monde extérieur" complexe.
Bien qu'il existe des tests d'intégration, cette définition ne couvre pas (d'où la raison pour laquelle je l'ai appelée définition pratique ), je pense qu'ils sont beaucoup moins courants/utiles.
N.B. À strictement parler, oui, cette définition couvrirait également les tests système/de bout en bout. Dans ma philosophie, ils sont une forme de test d'intégration "extrême", d'où la raison pour laquelle leurs noms mettent l'accent sur un autre aspect. Dans l'autre sens, un test unitaire peut être considéré comme un test d'intégration à zéro composante, c'est-à-dire Tous les tests peuvent être considérés comme se situant quelque part sur le spectre d'intégration, intégrant entre 0 et n composants :-)