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 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. Cela peut se faire de façon isolée par rapport au reste du système, en fonction du contexte du cycle de développement du logiciel et 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

Tests 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 tests d’intégration 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:  Tests 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 inter-plateformes 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 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. A 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, 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.

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 tests systèmes traitent le comportement d’un système/produit complet. Le périmètre des tests doit être clairement défini dans le plan de test maitre 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.

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 backups 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 beta (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.

By | 2017-08-07T14:33:52+02:00 juin 28th, 2017|Dossiers thématiques|