Close

Les différents types de tests logiciels

Comparez différents types de tests logiciels, tels que les tests unitaires, les tests d'intégration, les tests fonctionnels, les tests d'acceptation, et plus encore !

Portrait de Sten Pittet
Sten Pittet

Auteur collaborateur


Vous pouvez utiliser de nombreux types de tests différents pour vous assurer que les changements apportés à votre code fonctionnent comme prévu. Cependant, tous les tests ne sont pas égaux, et nous allons voir ici comment les principales pratiques de test diffèrent les unes des autres.

Tests manuels ou automatisés ?


À un niveau supérieur, nous devons faire la distinction entre les tests manuels et les tests automatisés. Les tests manuels sont effectués en personne, en cliquant dans l'application ou en interagissant avec le logiciel et les API avec les outils appropriés. Cette méthode est très coûteuse, car il faut quelqu'un pour configurer un environnement et exécuter les tests, et elle peut être sujette à l'erreur humaine, car le testeur peut faire des fautes de frappe ou omettre des étapes dans le script de test.

Les tests automatisés, d'autre part, sont effectués par une machine qui exécute un script de test programmé à l'avance. Ces tests peuvent énormément varier en termes de complexité, de la vérification d'une seule méthode dans une classe jusqu'à s'assurer que l'exécution d'une séquence d'actions complexes dans l'interface utilisateur mène aux mêmes résultats. Cette méthode est beaucoup plus robuste et fiable que les tests automatisés, mais la qualité de vos tests automatisés dépend de la qualité de vos scripts de test. Si vous débutez avec les tests, vous pouvez lire notre tutoriel sur l'intégration continue avant de programmer votre première suite de tests. Vous recherchez d'autres outils de test ? Consultez ces tutoriels de test DevOps.

Les tests automatisés sont un élément clé de l'intégration continue et de la livraison continue. Ils constituent un excellent moyen d'adapter votre processus de QA à mesure que vous ajoutez de nouvelles fonctionnalités à votre application. Mais il est toujours utile de lancer des tests manuels avec ce qu'on appelle des tests exploratoires, comme nous le verrons dans ce guide.

Découvrir la solution

Développez et exploitez des logiciels grâce à Open DevOps

Matériel connexe

Tests automatisés pour DevOps

Les différents types de tests


Tests d'unités

Les tests unitaires sont de très bas niveau, près de la source de votre application. Ils consistent à tester les méthodes et fonctions individuelles des classes, des composants ou des modules utilisés par votre logiciel. Les tests unitaires sont en général assez bon marché à automatiser et peuvent être exécutés très rapidement par un serveur d'intégration continue.

Tests d'intégration

Les tests d'intégration vérifient que les différents modules ou services utilisés par votre application fonctionnent bien ensemble. Par exemple, ils peuvent tester l'interaction avec la base de données ou s'assurer que les microservices fonctionnent ensemble comme prévu. Ces types de tests sont plus coûteux à exécuter, car ils nécessitent que plusieurs parties de l'application soient fonctionnelles.

Tests fonctionnels

Les tests fonctionnels se concentrent sur les exigences métier d'une application. Ils vérifient uniquement la sortie d'une action et non les états intermédiaires du système lors de l'exécution de cette action.

Il y a parfois une certaine confusion entre les tests d'intégration et les tests fonctionnels, car ils nécessitent tous les deux plusieurs composants pour interagir. La différence réside dans le fait qu'un test d'intégration peut simplement vérifier que vous pouvez interroger la base de données, tandis qu'un test fonctionnel s'attend à obtenir une valeur spécifique de la base de données, telle que définie par les exigences du produit.

Tests de bout en bout

Les tests de bout en bout reproduisent le comportement d'un utilisateur avec le logiciel dans un environnement applicatif complet. Ils vérifient que les différents flux d'utilisateurs fonctionnent comme prévu et peuvent être aussi simples que le chargement d'une page Web ou la connexion. Des scénarios beaucoup plus complexes peuvent aussi vérifier les notifications par e-mail, les paiements en ligne, etc.

Les tests de bout en bout sont très utiles, mais ils sont coûteux à réaliser et peuvent être difficiles à gérer lorsqu'ils sont automatisés. Il est recommandé d'avoir quelques tests clés de bout en bout et de s'appuyer davantage sur des tests de niveau inférieur (tests unitaires et d'intégration) pour être en mesure d'identifier rapidement les changements de dernière minute.

Tests d'acceptation

Les tests d'acceptation sont des tests formels exécutés pour vérifier si un système répond à ses exigences métier. Ils nécessitent que l'application soit entièrement opérationnelle et se concentrent sur la simulation du comportement des utilisateurs. Ils peuvent aussi aller plus loin et mesurer la performance du système et rejeter les changements si certains objectifs ne sont pas atteints.

Tests de performance

Les tests de performance vérifient les comportements du système lorsqu'il est soumis à une charge élevée. Ces tests sont non fonctionnels et peuvent prendre diverses formes pour comprendre la fiabilité, la stabilité et la disponibilité de la plateforme. Par exemple, il peut s'agir d'observer les temps de réponse lors de l'exécution d'un nombre important de requêtes, ou le comportement du système face à une quantité élevée de données.

Les tests de performance sont par nature assez coûteux à mettre en œuvre et à exécuter, mais ils peuvent vous aider à comprendre si de nouveaux changements vont dégrader votre système.

Smoke tests

Les smoke tests sont des tests simples qui vérifient le fonctionnement de base de l'application. Ils sont conçus pour être rapides à exécuter, et leur but est de vous donner l'assurance que les caractéristiques principales de votre système fonctionnent comme prévu.

Les « smoke tests » peuvent être utiles juste après la création d'un build afin de décider si vous pouvez exécuter des tests plus coûteux. Ils peuvent également être utiles après un déploiement afin de vous assurer que l'application s'exécute correctement dans l'environnement nouvellement déployé.

Comment automatiser vos tests

Une personne peut effectuer tous les tests mentionnés ci-dessus, mais il sera très coûteux et contre-productif de le faire. En tant qu'êtres humains, nous avons une capacité limitée à accomplir un grand nombre d'actions de manière répétée et fiable. Une machine en est facilement capable et testera que la combinaison identifiant/mot de passe fonctionne pour la 100e fois sans se plaindre.

Pour automatiser vos tests, vous devrez d'abord les programmer en utilisant un framework de test adapté à votre application. PHPUnit, Mocha, RSpec sont des exemples de frameworks de test que vous pouvez utiliser pour PHP, Javascript et Ruby respectivement. Il existe de nombreuses options pour chaque langue. Vous devrez donc peut-être faire des recherches et échanger avec les communautés de développeurs pour déterminer le meilleur framework pour vous.

Si vos tests peuvent être exécutés via un script depuis votre terminal, vous pouvez les faire exécuter automatiquement par un serveur d'intégration continue comme Bamboo ou utiliser un service cloud comme Bitbucket Pipelines. Ces outils surveilleront vos dépôts et exécuteront votre suite de tests chaque fois que de nouveaux changements seront apportés au dépôt principal.


An individual can execute all the tests mentioned above, but it will be very expensive and counter-productive to do so. As humans, we have limited capacity to perform a large number of actions in a repeatable and reliable way. But a machine can easily do that rapidly and will test that login/password combination works for the 100th time without complaining.

To automate your tests, you will first need to write them programmatically using a testing framework that suits your application. PHPUnitMochaRSpec are examples of testing frameworks that you can use for PHP, Javascript, and Ruby respectively. There are many options out there for each language so you might have to do some research and ask developer communities to find out what would be the best framework for you.

When your tests can be executed via script from your terminal, you can have them be automatically executed by a continuous integration server like Bamboo or use a cloud service like Bitbucket Pipelines. These tools will monitor your repositories and execute your test suite whenever new changes are pushed to the main repository.

Chaque push vers le dépôt est vérifié grâce à Bitbucket Pipelines

Si vous débutez avec les tests, vous pouvez lire notre tutoriel sur l'intégration continue avant de programmer votre première suite de tests.

Tests exploratoires

Plus il y aura de fonctionnalités et d'améliorations dans votre code, plus vous aurez besoin d'effectuer des tests pour vous assurer que votre système fonctionne correctement. Et pour chaque bug que vous corrigez, il serait judicieux de vérifier qu'il ne réapparaît pas dans les nouvelles versions. L'automatisation est la clé pour atteindre cet objectif, et la création de tests fera tôt ou tard partie de votre workflow de développement.

La question est donc de savoir s'il vaut encore la peine d'effectuer des tests manuels. La réponse courte est oui, et les efforts devraient être axés sur ce qu'on appelle les tests exploratoires, dont l'objectif est de découvrir les erreurs non évidentes.

Une session de tests exploratoires ne doit pas durer plus de deux heures et doit avoir un périmètre clair pour aider les testeurs à se concentrer sur un domaine spécifique du logiciel. Une fois que tous les testeurs ont été informés, c'est à eux d'essayer différentes actions pour vérifier le comportement du système. Ce type de test est coûteux par nature, mais très utile pour identifier des problèmes d'interface utilisateur ou vérifier les workflows utilisateur complexes. Cela vaut la peine de le faire chaque fois qu'une nouvelle capacité importante est ajoutée à votre application, afin de comprendre son comportement dans les cas limites.


The more features and improvements go into your code, the more you'll need to test to make sure that all your system works properly. And then for each bug you fix, it would be wise to check that they don't get back in newer releases. Automation is key to make this possible and writing tests sooner or later will become part of your development workflow.

So the question is whether it is still worth doing manual testing? The short answer is yes, and it should be focused on what is called exploratory testing where the goal is to uncover non-obvious errors.

An exploratory testing session should not exceed two hours and need to have a clear scope to help testers focus on a specific area of the software. Once all testers have been briefed, is up to them to try various actions to check how the system behaves. This type of testing is expensive by nature but is

Remarque sur les tests

Pour conclure ce guide, il est important de parler de l'objectif des tests. S'il est important de vous assurer que les utilisateurs peuvent utiliser votre application (je peux me connecter, je peux enregistrer un objet), il est tout aussi important de vérifier que votre système ne s'arrête pas lorsque des données incorrectes ou des actions inattendues sont exécutées. Vous devez anticiper ce qui se passera si un utilisateur fait une faute de frappe, tente d'enregistrer un formulaire incomplet ou utilise la mauvaise API. Vous devez vérifier qu'il n'est pas simple de compromettre des données et d'accéder à des ressources non autorisées. Une bonne suite de tests devrait essayer de pousser votre app à ses limites et de la faire crasher.

Et enfin, les tests font partie intégrante du code ! Ne les oubliez pas lors de la revue de code, car ils pourraient être le sésame final avant la mise en production.


To finish this guide, it's important to talk about the goal of testing. While it's important to test that users can use your application (I can log in, I can save an object) it is equally important to test that your system doesn't break when bad data or unexpected actions are performed. You need to anticipate what would happen when a user makes a typo, tries to save an incomplete form or uses the wrong API. You need to check if someone can easily compromise data, get access to a resource they're not supposed to. A good testing suite should try to break your app and help understand its limit.

And finally, tests are code too! So don't forget them during code review as they might be the final gate to production.

Sten Pittet
Sten Pittet

Cela fait maintenant dix ans que je travaille dans le secteur logiciel et j'ai occupé différentes fonctions, du développement à la gestion de produits. Après avoir passé les cinq dernières années chez Atlassian à travailler sur des outils de développement, j'écris désormais des articles sur le développement des logiciels. En dehors de mon travail, j'affine mes compétences de père au contact d'un adorable bébé.


Partager cet article
Thème suivant

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration Devops

Communauté DevOps

Illustration Devops

Lire le blog

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter Devops

Thank you for signing up