Différentes familles de test logiciel, typologie des tests

Dans cet article vous découvrirez plus en détail des différentes familles de test logiciel par niveau.

  1. Tests de composants/unitaire

  2. Tests d’intégration

  3. Tests système

  4. Tests d’acceptation

familles test logiciel

Familles de test : Tests de composants/unitaire 

Bases de test

  • Exigences des composants
  • Conception détaillée
  • Code

Objets habituels de test

  • Composants
  • Programmes
  • Conversions de données/utilitaires ou programmes de migration
  • Modules de bases de données

Les premiers sur la liste des familles de test sont les tests de composants (également connus sous les noms de tests unitaires, de modules ou de programmes) cherchent des défauts dans, et vérifient le fonctionnement des, logiciels (p.ex. modules, programmes, objets, classes, etc.) qui sont testables séparément.
Dans le contexte du cycle de développement du logiciel et du système, ces tests peuvent être effectués de manière isolée par rapport au reste du système.  Des bouchons, pilotes et simulateurs peuvent être utilisés. Les tests de composants peuvent inclure des tests de fonctionnalités et des tests de caractéristiques non-fonctionnelles, telles que le comportement des ressources (p.ex. fuites mémoire) ou des tests de robustesse, ainsi que des tests structurels (p.ex. couverture des branches). Les cas de test sont dérivés des livrables tels que les spécifications des composants (spécifications détaillées), la conception du logiciel ou le modèle de données.
La plupart du temps, les tests de composants se font avec l’accès au code du logiciel testé et sur un environnement de développement comme un framework de tests unitaire ou avec les outils de débogage. En pratique ils impliquent généralement le programmeur ayant écrit le code. Habituellement, les défauts sont corrigés dès qu’ils sont trouvés, sans formellement enregistrer des incidents. Une approche des tests de composants est de préparer et automatiser des cas de tests avant le codage. Cela s’appelle l’approche « Tester d’abord » (en anglais : « test first »)ou « Développement piloté par les tests. Cette approche, fortement itérative est basée sur des cycles de développement de cas de tests, puis construction et intégration de petits bouts de code, puis exécution des tests de composants et correction des défauts trouvés jusqu’à leur réussite.

Familles de test : Test d’intégration 

Bases de test

  • Conception du logiciel et du système
  • Architecture
  • Workflows, Cas d’utilisation

Objets habituels de test

  • Sous-systèmes
  • Implémentation de bases de données
  • Infrastructures
  • Interfaces
  • Configuration système et données de configuration

Les deuxièmes sur la liste des familles de test sont les tests d’intégration. Ils testent les interfaces entre les composants, les interactions entre différentes parties d’un système comme par exemple le système d’exploitation, le système de fichiers, le matériel ou les interfaces entre les systèmes. Plusieurs niveaux de tests d’intégration peuvent être effectués sur des objets de taille variable.

Par exemple : test d’intégration des composants testant les interactions entre les composants logiciels et effectués après les tests de composants; tests d’intégration système testant l’intégration entre les différents systèmes ou entre logiciel et matériel et pouvant être effectués après les tests système. Dans ce cas, l’organisation en charge du développement peut ne contrôler qu’un côté de l’interface. Cela peut être considéré comme un risque métier. Les processus commerciaux mis en œuvre comme les workflows peuvent impliquer plusieurs systèmes. Les aspects interplateformes peuvent être significatifs. Plus la portée de l’intégration est vaste, plus il devient difficile d’isoler les défauts liés à un composant ou un système particulier. Cela peut conduire à un accroissement des risques et du temps nécessaire pour résoudre les problèmes.
Des stratégies de test d’intégration systématique peuvent être basées sur l’architecture des systèmes (telles que top-down ou bottom-up), les tâches fonctionnelles, les séquences d’exécution de transactions, ou d’autres aspects du système ou du composant. Afin d’isoler facilement les fautes, et détecter les défauts au plus tôt, l’intégration devrait normalement être incrémentale plutôt qu’être effectuée en une fois (“big bang”).
Les tests de caractéristiques non fonctionnelles particulières (p.ex. performances) peuvent être inclus dans les tests d’intégration. À chaque étape de l’intégration, les testeurs se concentrent uniquement sur l’intégration elle-même. Par exemple, s’ils sont en train d’intégrer le module A avec le module Bée, les testeurs s’appliquent à tester la communication entre les modules et non pas leurs fonctionnalités individuelles. Les approches fonctionnelles et structurelles peuvent toutes deux être utilisées. Idéalement, les testeurs devraient comprendre l’architecture et influencer le planning d’intégration. Si les tests d’intégration sont prévus avant que les composants ou les systèmes ne soient fabriqués, les tests pourront être conçus dans le bon ordre pour être efficaces et efficients.

Familles de test : Tests système

Bases de test

  • Spécifications
  • Système et logiciel
  • Cas d’utilisation
  • Spécifications fonctionnelles
  • Rapports d’analyse des risques

Objets habituels de test

  • Manuels-système, utilisateur et opérationnels
  • Configuration système et données de configuration

Les prochains tests à aborder dans les familles de test sont les tests systèmes qui traitent le comportement d’un système/produit complet. Le périmètre des tests système doit être clairement défini dans le plan de test maître ou le plan de test du niveau.
Pour les tests système, l’environnement de test devrait correspondre à la cible finale ou à un environnement de production de façon à minimiser les risques de défaillances dues à l’environnement. Les tests système peuvent inclure des tests basés sur les risques et/ou sur les spécifications et les exigences, les processus commerciaux, les cas d’utilisation, ou autres descriptions de haut niveau du comportement du système, les modèles de comportement, les interactions avec le système d’exploitation et les ressources système. Les tests système devraient examiner à la fois les exigences fonctionnelles et les non fonctionnelles du système ainsi que la qualité des données.
Les testeurs doivent également s’adapter aux exigences peu ou pas documentées. Les tests fonctionnels au niveau système commencent par l’utilisation des techniques de spécification de tests les plus appropriées (boîte noire). Par exemple, une table de décision peut être créée pour les combinaisons d’effets décrits dans les processus commerciaux. Les techniques basées sur les structures (boîte blanche) peuvent ensuite être utilisées pour évaluer la minutie des tests par rapport à un élément comme la structure de menu ou la navigation dans la page web. Une équipe de tests indépendante exécute souvent des tests système.

Familles de test : Tests d’acceptation

Bases de test

  • Exigences utilisateur
  • Exigences du système
  • Cas d’utilisation
  • Processus métier
  • Rapports d’analyse des risques

Objets habituels de test

  • Processus métier sur l’intégralité du système
  • Processus opérationnels de maintenance
  • Procédure utilisateur
  • Formulaires
  • Rapports
  • Données de configuration

Les tests d’acceptation relèvent souvent de la responsabilité des clients ou utilisateurs d’un système; d’autres responsables (parties prenantes) peuvent aussi être impliqués. Les objectifs des tests d’acceptation sont de prendre confiance dans le système, dans des parties du système ou dans des caractéristiques non fonctionnelles du système. La recherche d’anomalies n’est pas l’objectif principal des tests d’acceptation. Les tests d’acceptation peuvent évaluer si le système est prêt à être déployé et utilisé, bien que ce ne soit pas nécessairement le dernier niveau Testeur Certifié Syllabus Niveau Fondation Comité Français des Tests Logiciels International Software Testing Qualifications Board Version 2011 Page 27 de 80 3-Nov- 201131-Mar-2010 © International Software Testing Qualifications Board de tests. Par exemple, une intégration système à grande échelle peut arriver après les tests d’acceptation du système. Les tests d’acceptation peuvent se faire à plusieurs niveaux de tests, par exemple:

  • Des tests d’acceptation peuvent avoir lieu sur un composant sur étagère quand il est installé ou intégré
  • Les tests d’acceptation de l’utilisabilité d’un composant peuvent être effectués pendant les tests unitaires
  • Les tests d’acceptation d’une évolution fonctionnelle peuvent être exécutés avant les tests système

Les formes habituelles des tests d’acceptation incluent :

  • Tests d’acceptation utilisateur : ces tests vérifient l’aptitude et l’utilisabilité du système par des utilisateurs.
  • Tests (d’acceptation) opérationnelle
  • L’acceptation du système par les administrateurs système, dont :
  • Tests des back-up et restaurations
  • Reprise après sinistre
  • Gestion des utilisateurs
  • Tâches de maintenance
  • Chargements de données et tâches de migration
  • Vérification périodique des vulnérabilités de sécurité

Tests d’acceptation contractuelle et réglementaire

– Les tests d’acceptation contractuelle sont exécutés sur base des critères d’acceptation contractuels pour la production de logiciels développés sur mesure. Les critères d’acceptation devraient être définis lors de la rédaction du contrat. Les tests d’acceptation réglementaires sont exécutés par rapport aux règlements et législations qui doivent être respectés, telles que les obligations légales, gouvernementales ou de sécurité. Tests alpha et bêta (ou sur le terrain) Les développeurs de logiciels pour le public, ou de COTS (logiciel commercial sur étagère), souhaitent souvent recueillir l’avis des clients potentiels ou existants sur leur marché, avant de mettre en vente. Les Alpha tests sont exécutés sur le site de l’organisation effectuant le développement mais pas par les équipes de développement. Les Béta tests ou tests sur le terrain sont exécutés par des personnes sur leurs sites propres. Les organisations peuvent aussi utiliser d’autres termes, tels que « tests d’acceptation usine » ou « tests d’acceptation sur site » pour des systèmes qui sont testés avant d’être transférés sur le site client.

Pour aller plus loin consultez notre article sur les différents types de test par nature et niveau.

En Résumé : Les Fondamentaux des Tests Logiciels

En somme, les différentes familles de tests logiciels que nous avons explorées, des tests de composants aux tests d’acceptation, en passant par les tests d’intégration et de système, sont tous cruciaux pour assurer la qualité et la fiabilité des logiciels. Ces tests permettent de détecter et de corriger les défauts à chaque étape du développement du logiciel, ce qui permet de créer un produit final qui répond aux attentes et aux besoins des utilisateurs.

Néanmoins, il est important de noter que le domaine des tests logiciels est vaste et complexe, et qu’il ne se limite pas à ces familles de tests.

Pour approfondir ce sujet, nous vous invitons à consulter nos autres articles sur le thème des tests logiciels :

N’hésitez pas à nous faire part de vos questions ou commentaires. Nous sommes toujours là pour vous aider à approfondir vos connaissances en matière de tests logiciels.