Classer les tests logiciels par type suppose d’abord de choisir un critère de classement. Niveau d’exécution, objectif fonctionnel ou non fonctionnel, degré d’automatisation : chaque grille produit une taxonomie différente. Cet article compare ces grilles, détaille les écarts entre catégories et identifie les zones où la norme ISO/IEC 25010:2023 redessine les frontières.
Comparatif des types de tests logiciels par niveau et objectif
Le tableau ci-dessous croise deux axes : le niveau d’exécution (du composant isolé au système complet) et la nature de ce qui est vérifié (comportement attendu ou attribut de qualité). Cette distinction structure la majorité des stratégies de test.
Lire également : Quels sont les quatre types de données ?
| Type de test | Niveau | Objectif principal | Automatisation courante |
|---|---|---|---|
| Test unitaire | Composant | Vérifier une fonction ou méthode isolée | Quasi systématique |
| Test d’intégration | Assemblage | Valider les échanges entre modules | Fréquente |
| Test fonctionnel (système) | Application complète | Contrôler la conformité aux exigences métier | Variable |
| Test de bout en bout | Chaîne complète | Simuler un parcours utilisateur réel | Moyenne (coût élevé de maintenance) |
| Test d’acceptation | Système | Confirmer l’adéquation avec le besoin client | Souvent manuel |
| Test de performance | Système / infrastructure | Mesurer temps de réponse, charge, endurance | Quasi systématique |
| Test de sécurité | Variable | Identifier les vulnérabilités exploitables | Mixte (scan + audit manuel) |
La colonne « Automatisation courante » révèle un gradient net. Les tests unitaires et de performance s’automatisent facilement, alors que les tests d’acceptation restent liés à un jugement humain sur la valeur métier.
A lire aussi : Comment diminuer l'utilisation du CPU ?
Tests fonctionnels et non fonctionnels : une frontière redessinée par ISO/IEC 25010:2023
La distinction entre tests fonctionnels et non fonctionnels paraît simple. Les premiers vérifient ce que le logiciel fait, les seconds comment il le fait. En pratique, la frontière bouge.
La norme ISO/IEC 25010, révisée en 2023, définit désormais neuf caractéristiques de qualité produit au lieu de huit. L’ajout de la sûreté (safety) crée une catégorie de tests explicitement rattachée au modèle de qualité. La norme a aussi remplacé « utilisabilité » par « capacité d’interaction » et « portabilité » par « flexibilité ».
Ce changement de vocabulaire n’est pas cosmétique. Un test de « flexibilité » ne couvre pas exactement le même périmètre qu’un ancien test de portabilité : il intègre la capacité du logiciel à s’adapter à de nouveaux contextes d’usage, pas seulement à tourner sur un autre environnement.
Conséquences pour la couverture de test
Une équipe qui structure ses tests non fonctionnels autour de l’ancienne norme oublie la sûreté. Pour un logiciel embarqué ou un système médical, cette lacune peut invalider une certification.
- Les tests de sûreté évaluent si le logiciel peut provoquer un dommage physique, financier ou environnemental, même en cas de défaillance partielle.
- Les tests de capacité d’interaction vont au-delà de l’ergonomie classique : ils incluent l’accessibilité, la reconnaissance des erreurs utilisateur et la protection contre les actions involontaires.
- Les tests de flexibilité mesurent l’effort nécessaire pour adapter le logiciel à un nouveau contexte technique ou métier, ce qui recoupe les enjeux de maintenabilité.
En revanche, les tests de sécurité et de performance conservent un périmètre stable entre les deux versions de la norme.
Tests automatisés et stabilité du code : le piège des tests instables
L’automatisation des tests est un prérequis dans les pipelines d’intégration continue. Le rapport DORA 2025 constate une relation positive entre l’usage de l’IA dans le développement, la capacité de livraison et la performance produit. Il observe aussi une relation négative avec la stabilité quand les contrôles sont insuffisants : tests automatisés absents ou mal entretenus, gestion de versions approximative, boucles de retour lentes.
Un problème spécifique aggrave cette instabilité : les tests instables, appelés flaky tests. Ces tests échouent alors que le code fonctionne correctement, puis passent au lancement suivant sans modification. Ils finissent par habituer les équipes à ignorer les échecs de la suite de tests.
Flaky tests : un défaut de fiabilité du test lui-même
La fiabilité des tests eux-mêmes devient un sujet de qualité à part entière. Un test instable mine la confiance dans le pipeline et ralentit les livraisons. Les causes fréquentes :
- Dépendance à un état partagé (base de données, fichier temporaire) non réinitialisé entre deux exécutions.
- Attente d’un délai fixe au lieu d’une condition explicite, ce qui provoque des échecs intermittents sur des environnements plus lents.
- Ordre d’exécution implicite entre tests censés être indépendants.
Corriger un flaky test demande souvent plus d’effort que corriger le défaut applicatif qu’il était censé détecter. Le coût de maintenance de la suite de tests automatisés pèse autant que sa couverture dans la fiabilité globale du processus.
Tests de systèmes intégrant de l’IA : une catégorie émergente
Les tests classiques reposent sur des résultats déterministes : pour une entrée donnée, on attend une sortie précise. Un système intégrant de l’IA produit des résultats probabilistes dépendants des données d’entraînement, ce qui rend les oracles de test traditionnels inadaptés.
La série ISO/IEC TS 42119 complète progressivement les pratiques de test logiciel pour traiter ces spécificités. Le périmètre inclut notamment des pratiques de red teaming, où des testeurs recherchent activement les vulnérabilités et les biais d’un système d’IA.
Cette catégorie de tests ne remplace pas les tests fonctionnels ou de performance. Elle s’y ajoute pour couvrir des risques que les approches classiques ne détectent pas : dérive du modèle dans le temps, sensibilité excessive à certaines distributions de données, comportements imprévisibles en conditions limites.
Tester un logiciel intégrant de l’IA exige de tester aussi les données, pas seulement le code. La qualité du jeu de données d’entraînement, sa représentativité et son actualisation deviennent des objets de vérification au même titre qu’une spécification fonctionnelle.
La cartographie des types de tests logiciels ne se résume plus à la pyramide unitaire-intégration-système. L’évolution d’ISO/IEC 25010 vers neuf caractéristiques, l’émergence des tests spécifiques à l’IA et le poids croissant de la fiabilité des suites de tests elles-mêmes redéfinissent les contours de chaque catégorie. Le critère de classement le plus utile reste celui qui correspond à la stratégie de risque du projet, pas à un modèle théorique figé.
