Quelle est la différence entre les tests unitaires, fonctionnels, d’acceptation et d’intégration (et tout autre type de test que je n’ai pas mentionné)?
Selon l’endroit où vous regardez, vous obtiendrez des réponses légèrement différentes. J’ai beaucoup lu sur le sujet et voici ma distillation; encore une fois, ceux-ci sont légèrement laineux et d’autres peuvent être en désaccord.
Tests unitaires
Teste la plus petite unité de fonctionnalité, généralement une méthode / fonction (par exemple, en atsortingbuant une classe à un état particulier, l’appel de la méthode x sur la classe doit provoquer le déclenchement de y). Les tests unitaires doivent être axés sur une caractéristique particulière (par exemple, appeler la méthode pop lorsque la stack est vide devrait InvalidOperationException
une InvalidOperationException
). Tout ce qu’il touche doit être fait en mémoire; Cela signifie que le code de test et le code à tester ne doivent pas:
Tout type de dépendance qui est lent / difficile à comprendre / initialiser / manipuler doit être remplacé / simulé / mis à part en utilisant les techniques appropriées afin que vous puissiez vous concentrer sur ce que fait l’unité de code et non sur ses dépendances.
En bref, les tests unitaires sont aussi simples que possible, faciles à déboguer, fiables (en raison de facteurs externes réduits), rapides à exécuter et à prouver que les plus petits composants de votre programme fonctionnent comme prévu avant d’être assemblés. La mise en garde est que, même si vous pouvez prouver qu’ils fonctionnent parfaitement en vase clos, les unités de code peuvent exploser lorsqu’elles sont combinées, ce qui nous amène à …
Tests d’intégration
Les tests d’intégration reposent sur des tests unitaires en combinant les unités de code et en testant le bon fonctionnement de la combinaison résultante. Cela peut être soit les entrailles d’un système, soit la combinaison de plusieurs systèmes pour faire quelque chose d’utile. En outre, l’environnement permet également de différencier les tests d’intégration des tests unitaires. Les tests d’intégration peuvent et vont utiliser des threads, accéder à la firebase database ou faire tout ce qui est nécessaire pour s’assurer que tout le code et les différentes modifications d’environnement fonctionnent correctement.
Si vous avez construit du code de sérialisation et que l’unité a testé ses entrailles sans toucher au disque, comment savez-vous que cela fonctionnera lorsque vous chargez et enregistrez sur le disque? Vous avez peut-être oublié de vider et d’éliminer les filestreams. Vos permissions de fichiers sont peut-être incorrectes et vous avez testé les entrailles dans les stream de mémoire. Le seul moyen de le savoir est de le tester “pour de vrai” en utilisant un environnement proche de la production.
Le principal avantage est qu’ils trouveront des bogues que les tests unitaires ne peuvent pas faire, tels que le câblage de bogues (par exemple, une instance de classe A reçoit une instance nulle de B) et des bogues d’environnement (mon ordinateur La machine à 4 cœurs de votre collègue ne peut pas réussir les tests. Le principal inconvénient est que les tests d’intégration touchent plus de code, sont moins fiables, les défaillances sont plus difficiles à diagnostiquer et les tests plus difficiles à gérer.
De plus, les tests d’intégration ne prouvent pas nécessairement qu’une fonctionnalité complète fonctionne. L’utilisateur peut ne pas se soucier des détails internes de mes programmes, mais je le fais!
Tests fonctionnels
Les tests fonctionnels vérifient l’exactitude d’une caractéristique particulière en comparant les résultats d’une entrée donnée à la spécification. Les tests fonctionnels ne concernent pas les résultats intermédiaires ou les effets secondaires, mais le résultat (ils ne se soucient pas qu’après avoir fait x, l’object y a l’état z). Ils sont écrits pour tester une partie de la spécification, par exemple, “la fonction d’appel Square (x) avec l’argument de 2 retours 4”.
Tests d’acceptation
Les tests d’acceptation semblent être divisés en deux types:
Les tests d’acceptation standard impliquent d’effectuer des tests sur le système complet (par exemple, en utilisant votre page Web via un navigateur Web) pour voir si la fonctionnalité de l’application satisfait à la spécification. Par exemple, “cliquer sur une icône de zoom devrait agrandir la vue du document de 25%”. Il n’y a pas de véritable continuum de résultats, juste un résultat positif ou négatif.
L’avantage est que les tests sont décrits en anglais et que le logiciel, dans son ensemble, est complet. L’inconvénient est que vous avez déplacé un autre niveau dans la pyramide de test. Les tests d’acceptation touchent des montagnes de code, ce qui rend la recherche d’une panne difficile.
En outre, dans le développement de logiciels agiles, les tests d’acceptation des utilisateurs impliquent la création de tests pour refléter les user stories créées par / pour le client du logiciel pendant le développement. Si les tests réussissent, cela signifie que le logiciel doit répondre aux exigences du client et que les articles peuvent être considérés comme complets. Une suite de tests d’acceptation est essentiellement une spécification exécutable écrite dans un langage spécifique au domaine qui décrit les tests dans le langage utilisé par les utilisateurs du système.
Conclusion
Ils sont tous complémentaires. Parfois, il est avantageux de se concentrer sur un type ou de les éviter complètement. La principale différence pour moi est que certains tests examinent les choses du sharepoint vue d’un programmeur, tandis que d’autres utilisent le focus client / utilisateur final.
L’important est de savoir ce que ces termes signifient pour vos collègues. Différents groupes auront des définitions légèrement différentes de ce qu’ils veulent dire par exemple lorsqu’ils disent des tests “de bout en bout”.
Je suis tombé récemment sur le système de nommage de Google pour leurs tests, et je l’aime plutôt – ils contournent les arguments en utilisant simplement Small, Medium et Large. Pour décider de la catégorie à laquelle un test appartient, ils examinent quelques facteurs: combien de temps cela prend-il pour exécuter, accède-t-il au réseau, à la firebase database, au système de fichiers, aux systèmes externes, etc.
http://googletesting.blogspot.com/2010/12/test-sizes.html
J’imagine que la différence entre Small, Medium et Large pour votre lieu de travail actuel peut varier de celle de Google.
Cependant, il ne s’agit pas seulement de scope, mais de finalité. L’importance des points de vue de Mark sur les différentes outlook pour les tests, par exemple entre programmeur et client / utilisateur final.
http://martinfowler.com/articles/microservice-testing/
L’article du blog de Martin Fowler parle des stratégies de test du code (en particulier dans une architecture de micro-services), mais la majeure partie s’applique à toute application.
Je vais citer un extrait de sa diapositive:
- Tests unitaires: utilisez les plus petits logiciels testables de l’application pour déterminer s’ils se comportent comme prévu.
- Tests d’intégration – Vérifiez les chemins de communication et les interactions entre les composants pour détecter les défauts d’interface.
- Tests de composants – limiter la scope du logiciel utilisé à une partie du système sous test, en manipulant le système via des interfaces de code internes et en utilisant des tests doubles pour isoler le code sous test des autres composants.
- Contrats de contrat – vérifie les interactions à la limite d’un service externe en affirmant qu’il respecte le contrat attendu par un service consommateur.
- Tests de bout en bout – vérifiez qu’un système répond aux exigences externes et atteint ses objectives, en testant l’ensemble du système, de bout en bout.
Test d’unité – Comme son nom l’indique, cette méthode teste au niveau de l’object. Les composants logiciels individuels sont testés pour toute erreur. La connaissance du programme est nécessaire pour ce test et les codes de test sont créés pour vérifier si le logiciel se comporte comme prévu.
Test fonctionnel – Est effectué sans aucune connaissance du fonctionnement interne du système. Le testeur essaiera d’utiliser le système en suivant uniquement les exigences, en fournissant différentes entrées et en testant les sorties générées. Ce test est également appelé test en boîte fermée ou boîte noire.
Test d’acceptation – Il s’agit du dernier test effectué avant la transmission du logiciel au client. Il est effectué pour s’assurer que le logiciel développé répond à toutes les exigences du client. Il existe deux types de tests d’acceptation: l’un est effectué par les membres de l’équipe de développement, appelé test d’acceptation interne (test Alpha) et l’autre est exécuté par le client ou l’utilisateur final (test bêta).
Test d’intégration – Les modules individuels déjà soumis à des tests unitaires sont intégrés les uns aux autres. Généralement, les deux approches sont suivies:
1) Top-Down
2) Bottom-up
C’est très simple.
Tests unitaires: Il s’agit des tests réellement réalisés par les développeurs ayant des connaissances en codage. Ce test est effectué à la phase de codage et fait partie du test de la boîte blanche. Lorsqu’un logiciel est mis au point pour le développement, il est transformé en un morceau de code ou une tranche de code appelée unité. Et les tests individuels de ces unités ont été appelés tests unitaires effectués par les développeurs pour détecter des erreurs humaines telles que le manque de couverture de relevé, etc.
Test fonctionnel: Ce test est effectué lors de la phase de test (QA) et fait partie du test de la boîte noire. L’exécution réelle des cas de test précédemment écrits. Ce test est en fait effectué par les testeurs, ils trouvent le résultat réel de toute fonctionnalité du site et comparent ce résultat au résultat attendu. S’ils ont trouvé une disparité, alors c’est un bug.
Test d’acceptation: connaître comme UAT. Et cela a été fait par le testeur ainsi que par les développeurs, l’équipe de direction, l’auteur, les rédacteurs et tous ceux qui sont impliqués dans ce projet. Pour que le projet soit enfin prêt à être livré avec des bogues gratuits.
Test d’intégration: Les unités de code (expliquées au point 1) sont intégrées les unes aux autres pour compléter le projet. Ces unités de codes peuvent être écrites dans une technologie de codage différente ou peuvent être de version différente. Par conséquent, ces tests sont effectués par les développeurs pour s’assurer que toutes les unités du code sont compatibles avec d’autres et qu’il n’y a aucun problème d’intégration.
Quelques idées (relativement) récentes contre les moqueries excessives et les tests unitaires purs:
test unitaire: le test d’un module individuel ou d’un composant indépendant dans une application est connu pour être un test unitaire, le test unitaire sera effectué par le développeur.
test d’intégration: en combinant tous les modules et en testant l’application pour vérifier la communication et le stream de données entre les modules fonctionnent correctement ou non, ce test est également effectué par les développeurs.
test fonctionnel vérifiant la fonctionnalité individuelle d’une application est un test fonctionnel
Test d’acceptation Ce test est effectué par l’utilisateur final ou le client, que l’application de construction soit conforme aux exigences du client ou aux spécifications du client.
Je vais vous expliquer cela avec un exemple pratique et aucune théorie:
Un développeur écrit le code. Aucune interface graphique n’est encore implémentée. Le test à ce niveau vérifie que les fonctions fonctionnent correctement et que les types de données sont corrects. Cette phase de test est appelée test unitaire.
Lorsqu’une interface graphique est développée et que l’application est affectée à un testeur, il vérifie les besoins de l’entreprise avec un client et exécute les différents scénarios. Cela s’appelle le test fonctionnel. Ici, nous cartographions les exigences du client avec les stream d’application.
Tests d’intégration: supposons que notre application comporte deux modules: RH et finances. Le module HR a été livré et testé précédemment. Maintenant, Finance est développé et est disponible pour tester. Les fonctionnalités interdépendantes sont également disponibles dès maintenant. Dans cette phase, vous testerez les points de communication entre les deux et vérifierez qu’elles fonctionnent comme demandé dans les exigences.
Les tests de régression sont une autre phase importante, qui est effectuée après tout nouveau développement ou correction de bogue. Son but est de vérifier les fonctions qui fonctionnaient auparavant.