Différence entre test unitaire, test de système, test d’intégration et test de régression

Test unitaire

Les tests unitaires sont effectués sur les unités individuelles d’un programme et sont destinés à examiner un composant individuel qui a été modifié ou introduit pour la première fois. Chaque test qui vise à valider un module unique doit être présenté avec la documentation technique connexe jointe, qui contiendra entre autres informations les sorties que le module testé est censé fournir. Les tests unitaires se concentrent sur la fonctionnalité et la fiabilité du logiciel et sont effectués dans une phase de test avant l’intégration du système. Si un défaut était découvert lors d’un test unitaire, sa nature et son impact sur le système général seraient évalués; l’objectif est de le résoudre avant que le module testé ne soit approuvé.

Test du système

Les tests du système sont effectués sur tous les composants et modules nouveaux ou modifiés qui caractérisent un produit. L’objectif est de comprendre comment les différents blocs unitaires interagissent les uns avec les autres et s’ils fournissent globalement les résultats requis; l’accent est mis sur la validation et la vérification des exigences du système et sur la manière dont les modules individuels fonctionnent ensemble lorsqu’ils sont connectés. Habituellement, les tests sur le système sont plus d’un: le premier mérite une mention spéciale (normalement appelé “test de fumée”), qui vise à étudier en termes généraux le comportement du programme et si les principales fonctions sont exécutées correctement, sans s’attarder sur les détails. Les tests sur l’ensemble du système prennent beaucoup de temps, car il est nécessaire d’en effectuer un grand nombre pour analyser tous les scénarios possibles qui peuvent se produire; le Plan de test joue à ce stade un rôle très délicat, car il contient la description des cas de test, la séquence dans laquelle ils doivent être effectués et la documentation nécessaire pour lister les résultats. Lorsqu’une erreur est découverte et corrigée, le test doit être répété pour s’assurer que les corrections apportées n’ont eu aucune influence négative sur des composants qui n’avaient auparavant aucune erreur (le test de régression déjà mentionné ci-dessus).

Test d’intégration

Après avoir effectué les différents tests système, il est nécessaire de s’assurer que le programme développé fournit les résultats souhaités même s’il est exécuté dans des environnements autres que le programme natif: il est donc nécessaire d’effectuer des tests d’intégration, dans lesquels le produit est testé avec d’autres interfaces et applications. Contrairement aux tests système, dans les tests d’intégration, il n’est pas nécessaire de tester à nouveau si un défaut est découvert après sa correction. Les tests d’intégration sont divisés en différents groupes et peuvent être effectués ou non en fonction de l’application à tester:

• Test de compatibilité : garantir que l’application fonctionne avec différentes configurations en fonction de celles disponibles pour l’utilisateur
• Tests de performance: ils évaluent la capacité de l’application à fonctionner correctement lorsque, par exemple, plusieurs utilisateurs l’utilisent simultanément ou que le nombre d’entrées augmente
• Tests de contrainte : ils testent le bon fonctionnement de l’application lorsqu’elle est sollicitée avec des charges de travail inhabituelles
• Tests de charge: ils sont complémentaires des tests de résistance et évaluent le fonctionnement de l’application sous des charges de travail normales

Test de régression

Le test de régression, déjà mentionné dans les paragraphes précédents, est effectué chaque fois que la procédure d’une pièce de programme est modifiée suite à l’identification d’un défaut ; lorsqu’une erreur est corrigée, il se peut qu’une nouvelle soit introduite involontairement: il y a donc introduction d’une incertitude sur la capacité de l’application à répéter correctement toutes les fonctions précédemment exécutées. Le test de régression est généralement effectué en parallèle avec d’autres tests et peut être considéré comme un contrôle de qualité pour s’assurer que le code qui vient d’être modifié continue à remplir correctement les fonctions qui n’ont pas été modifiées et qui répondent aux mêmes exigences vérifiées précédemment. En conclusion, on peut affirmer que le test de régression garantit que le reste de la demande non sujet à modification n’est pas affecté par des erreurs résultant de la correction d’autres.