Le Guide Essentiel du Test Logiciel : Processus et Types

Classé dans Informatique

Écrit le en français avec une taille de 9,13 KB

Objectifs du Test Logiciel

Le processus de test logiciel poursuit deux objectifs distincts :

  1. Démontrer au développeur et au client que le logiciel répond à leurs exigences.
  2. Découvrir les défauts ou les bogues du logiciel présentant un comportement incorrect, indésirable ou non conforme à ses spécifications.

Le premier objectif mène au test de validation, où l'on s'attend à ce que le système fonctionne correctement avec un ensemble de cas de test reflétant son utilisation prévue. Le second objectif conduit au test de défauts, où les cas de test sont conçus pour exposer les failles du système.

Les tests ne peuvent pas démontrer qu'un logiciel est exempt de défauts ou qu'il se comportera comme spécifié en toutes circonstances. Il est toujours possible qu'un test négligé puisse révéler d'autres problèmes dans le système.

Stratégies de Test

Les politiques de test peuvent être basées sur l'expérience d'utilisation du système et se concentrer sur la vérification des fonctionnalités opérationnelles. Par exemple :

  • Toutes les fonctions du système accessibles via des menus doivent être testées.
  • Les combinaisons de fonctions (par exemple, le formatage de texte) accessibles par les mêmes menus doivent être testées.
  • Toutes les fonctions nécessitant une saisie de l'utilisateur doivent être testées avec des entrées correctes et incorrectes.

Types de Tests Logiciels

Test de Système

Le test de système implique l'intégration de deux ou plusieurs composants qui implémentent des fonctions du système, puis le test de ce système intégré. Pour les systèmes complexes, il existe deux phases distinctes :

Test d'Intégration

L'équipe de test a accès au code source du système. Lorsqu'un problème est découvert, l'équipe d'intégration tente de trouver sa source et d'identifier les composants à déboguer.

But : Le processus d'intégration consiste à construire un système à partir de ses composants et à tester le système résultant pour déceler les problèmes survenant dans les interactions entre ces composants.

Test de Version (Release Testing)

Une version du système, qui pourrait être distribuée aux utilisateurs, est testée. L'équipe se concentre sur la validation du système par rapport aux exigences et s'assure de sa fiabilité.

But : Il s'agit du processus de test de la version du système qui sera distribuée aux clients. L'objectif principal est d'accroître la confiance du fournisseur dans le fait que le système répond aux exigences.

Test de Performance

Une fois le système complètement intégré, il peut être testé par rapport à des propriétés émergentes telles que la performance et la fiabilité.

Test de Composants (Test Unitaire)

Parfois appelé test unitaire, c'est le processus de test des composants individuels du système. Il s'agit d'un processus de recherche de défauts, dont le but est d'exposer les failles de ces composants. Différents types de composants peuvent être testés à ce stade :

  • Des fonctions ou des méthodes spécifiques d'un objet.
  • Des classes d'objets avec plusieurs attributs et méthodes.
  • Des composants composites constitués de différents objets ou fonctions, possédant une interface définie pour accéder à leurs fonctionnalités.

Test d'Interfaces

Le test d'interfaces est particulièrement important pour le développement orienté objet et basé sur des composants. Les objets et composants sont définis par leurs interfaces et peuvent être réutilisés en combinaison avec d'autres composants dans différents systèmes.

Types d'Interfaces

  • Interfaces de paramètres : Des données ou des références à des fonctions sont transmises d'un composant à un autre.
  • Interfaces à mémoire partagée : Une zone de mémoire est partagée entre plusieurs composants.
  • Interfaces procédurales : Un composant expose un ensemble de procédures qui peuvent être appelées par d'autres composants.
  • Interfaces par passage de messages : Un composant demande un service à un autre en lui transmettant un message.

Erreurs d'Interface Courantes

Ces erreurs sont parmi les plus fréquentes dans les systèmes complexes :

  • Utilisation incorrecte de l'interface : Un composant appelle un autre composant et commet une erreur dans l'utilisation de son interface.
  • Incompréhension de l'interface : Un composant interprète mal la spécification de l'interface d'un autre et fait des suppositions incorrectes sur son comportement.
  • Erreurs de synchronisation : Ces erreurs se produisent dans les systèmes temps réel utilisant des interfaces à mémoire partagée ou par passage de messages.

Directives pour le Test d'Interfaces

  • Examinez le code à tester et listez explicitement chaque appel à des composants externes.
  • Testez toujours les interfaces avec des pointeurs nuls lorsque des pointeurs sont transmis.
  • Concevez des tests qui provoquent l'échec du composant lorsqu'il est appelé via une interface procédurale.
  • Utilisez des tests de stress dans les systèmes à passage de messages.
  • Lorsque plusieurs composants interagissent via une mémoire partagée, concevez des tests qui varient l'ordre d'activation de ces composants.

Conception des Cas de Test

La conception de cas de test (entrées et sorties attendues) fait partie intégrante du test des composants et du système. Plusieurs approches peuvent être utilisées :

  • Test basé sur les exigences : Les cas de test sont conçus pour vérifier les exigences du système.
  • Test par partitionnement : On identifie des partitions dans les données d'entrée et de sortie, et on conçoit des tests pour que le système traite des entrées de chaque partition et génère des sorties dans chaque partition.
  • Test structurel : La connaissance de la structure du programme est utilisée pour concevoir des tests qui exercent toutes les parties du programme.

Test de Chemin (Path Testing)

C'est une stratégie de test structurel dont le but est d'exercer chaque chemin d'exécution indépendant d'un composant ou d'un programme. Si chaque chemin est testé indépendamment, toutes les instructions du composant auront été exécutées au moins une fois.

Automatisation des Tests

Le test est une phase coûteuse et intensive en main-d'œuvre du processus logiciel. Par conséquent, les outils de test automatisé sont essentiels. Un atelier de test logiciel est un ensemble intégré d'outils pour soutenir ce processus.

  1. Gestionnaire de tests : Gère l'exécution du programme de test, en gardant une trace des données, des résultats attendus et des ressources.
  2. Générateur de données de test : Génère des données de test pour le programme à tester.
  3. Oracle de test : Génère des prédictions sur les résultats attendus des tests.
  4. Comparateur de fichiers : Compare les résultats des tests avec des résultats antérieurs et signale les différences.
  5. Générateur de rapports : Fournit des outils pour identifier et rapporter les résultats des tests.
  6. Analyseur dynamique : Ajoute du code au programme pour compter le nombre d'exécutions de chaque instruction et générer un profil d'exécution.
  7. Simulateur : Simule l'environnement cible sur lequel le programme s'exécutera.

Points Clés du Test Logiciel

  • Les tests peuvent seulement démontrer la présence d'erreurs ; ils ne peuvent pas prouver l'absence de défauts restants.
  • Le test de composants est la responsabilité du développeur. Le test de système est généralement effectué par une équipe de test distincte.
  • Le test d'intégration est l'activité initiale du test de système. Le test de version se concentre sur la validation des exigences client avant la distribution.
  • Lors des tests, il est crucial d'essayer de "casser" le système en utilisant son expérience pour choisir des cas de test efficaces.
  • Le test d'interfaces vise à découvrir des défauts dans les interactions entre composants, souvent dus à des erreurs d'interprétation des spécifications ou à des hypothèses de synchronisation invalides.
  • Le partitionnement par équivalence est une technique pour dériver des cas de test en se basant sur des partitions dans les ensembles de données d'entrée et de sortie.
  • Le test structurel se base sur une analyse du programme pour guider la sélection des cas de test.
  • L'automatisation réduit les coûts des tests en soutenant le processus avec une variété d'outils logiciels.

Entrées associées :