Test (informatique)
Un article de Freepedia.
En informatique, un test (anglicisme) désigne une procédure de vérification partielle d'un système informatique : le but est de s'assurer que le système informatique réagit de la façon prévue par ses concepteurs.
Sommaire |
Définition
Cette définition est issu de la norme IEEE 729: Le test est un processus manuel ou automatique, qui vise à établir qu’un système vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification.
Ainsi le test vise à mettre en évidence les erreurs d’un logiciel. Cependant il n'a pas pour objectif de : diagnostiquer la cause des erreurs, de corriger les erreurs et de prouver la bonne exécution d’un programme.
Procédure de test
On applique sur tout ou une partie du système informatique un échantillon de données d'entrées et d'environnement, et on vérifie si le résultat obtenu est conforme à celui attendu. S'il ne l'est pas, cela veut dire que le système informatique testé présente une anomalie de fonctionnement.
Classification des test
Il existe différentes façon de classer les tests informatiques. On peut classer ces façon selon trois axes : le niveau de détail (qui dépend essentiellement de où on en est dans le cycle de vie), le niveau d'accessibilité (boite noire ou blanche) et la caractéristique (fonctionnelle ou performance etc.).
Classification selon le niveau de détail
- tests unitaires : vérification des fonctions une par une,
- tests d'intégration : vérification du bon enchaînement des fonctions et des programmes,
- test de non-régression : vérification qu'il n'y a pas eu de dégradation des fonctions par rapport à la version précédente,
Classification selon le niveau d'accessibilité
- boite noire : à partir d'entrée définie on vérifie que le résultat final convient,
- boite blanche : on a accès à l'état complet du système que l'on vérifie à chaque ligne
Classification selon la caractéristique
On ne peut pas être exhaustif, on se contentera de quelques exemples :
- tests de performance : vérification que les performances annoncées dans la spécification sont bien atteintes.
- test fonctionnel : vérification que les fonctions sont bien atteintes.
- test de robustesse : vérification de la robustesse du logiciel.
En dehors du cas très particulier de systèmes extrêmement simples, il est impossible de tester exhaustivement un logiciel, car le nombre de configurations possibles croît comme 2n où n est le nombre de bits dans la mémoire du calculateur ; le nombre de configurations accessibles, inférieur, reste tout de même prohibitif. La réussite des tests ne permet donc pas de conclure au bon fonctionnement du logiciel. On essaye cependant, heuristiquement, de faire que si une bogue est présente, le test la mette en évidence, notamment en exigeant une bonne couverture des tests :
- couverture en points de programme : chaque point de programme doit avoir été testé au moins une fois
- couverture en chemins de programme : chaque séquence de points de programme possible dans une exécution doit avoir été testée au moins une fois (impossible en général).
Si l'on veut des assurances plus fortes de bon fonctionnement, on peut utiliser des méthodes formelles.
Les JUnit permettent, en Java, de faciliter les tests apportés au programme.
Selon la complexité du logiciel, des séquences de vérification globale peuvent s'avérer nécessaires qui mettent en jeu la maîtrise d'ouvrage et toutes les composantes du projet, au-delà du logiciel lui-même (processus, organisation, formation, accompagnement du changement) : réception, qualification, certification, homologation, simulation, VABF (vérification d'aptitude au bon fonctionnement)... les termes varient selon les contextes.</br> Voir également les articles Cycle en V et Gestion de projet.
PS : différence entre tests d'application et tests d'API ?
