Test Niveaux

• Tests de logiciel : niveaux de tests
• Le matériel utilisé provient du cours LOG3430 de l'École Polytechnique de Montréal, par Giulio Antoniol et Sègla Kpodjedo.

Plan

• Sont abordés la nécessité des différents niveaux de tests, l'architecture et ces niveaux, les harnais, les tests système, d'intégration et unitaires.
• Traite également des tests de régression, alpha, bêta et d'acceptation, concluant par un sommaire des niveaux de tests.

Le besoin de différents niveaux de tests

• L'utilisation de niveaux/phases de tests aide à la gestion de la complexité.
• Différents niveaux de tests visent des objectifs distincts.
• Les principaux niveaux de tests s'adaptent selon que le système est implémenté de manière procédurale ou orientée objet.
• L'implémentation procédurale comprend: fonction/procédure, sous-système (groupe de fonctions/procédures), et système.
• L'implémentation orientée objet comprend méthode, classe, cluster (groupe de classes), et système.
• Une source pour plus d'informations, I. Burnstein, Practical Software Testing, Springer, 2003, figure 6.1.

Architecture et niveaux de tests

• Le modèle de cycle de vie en V "classique" inclut les exigences, l'architecture, la conception, le code, les tests unitaires, les tests d'intégration et les tests du système.
• L'architecture trois couches comprend la présentation, la logique d'affaires et l'accès aux données, divisées en sous-systèmes et unités.

Harnais de tests

• Un harnais de tests est composé de pilotes (drivers) et de substituts (stubs).
• Des ressources sont nécessaires pour l'implémentation et les tests.
• Des outils et frameworks de tests peuvent être utilisés : JUnit, TestNG, jMock, EasyMock, Mockito, uispec4j, FitNesse, et Hamcrest.
• Voir I. Burnstein, Practical Software Testing, Springer, 2003, figure 6.5 pour plus d'informations.

Tests Système : Les Divers Types

• Les tests fonctionnels, de performance, de marges (stress testing), de configuration, de sécurité, de reprise (recovery testing), de fiabilité et de convivialité (usability testing) existent.
• Tous les types de tests ne sont pas nécessaires pour chaque système.
• Les tests des niveaux précédents (unitaires, intégration) peuvent être réutilisés, mais sont souvent adaptés pour dégager les caractéristiques du système entier.

Tests Système : Tests Fonctionnels

• L'objectif est de tester toutes les fonctions du système en mode "boîte noire".
• Toutes les classes de valeurs d'entrée valides doivent être acceptées.
• Toutes les classes de valeurs d'entrée invalides doivent être rejetées, tout en maintenant le système disponible.
• Chaque classe de sortie possible doit être exercée et évaluée.
• Tous les états du système et leurs transitions doivent être exercés et évalués.
• Toutes les fonctions doivent être exercées.

Tests Système : Tests de Performance

• Le but ici est de valider que les fonctions du système sont réalisées selon les exigences de performance spécifiées (quantifiées).
• Consultez I. Burnstein, Practical Software Testing, Springer, 2003, figure 6.11 pour référence.

Tests Système : Tests de Marges (Stress Testing)

• Un système "stressé" fonctionne avec toutes ses ressources allouées au maximum.
• L'objectif est de trouver l'ultime point de rupture du système.
• Ces tests permettent de trouver des défauts que d'autres formes de tests ne détectent pas.
• Ils aident à identifier un manque prématuré de ressources, des interblocages ou des conditions de concurrence critique.
• Il est important de réaliser ces tests aux niveaux d'intégration et unitaire pour donner plus de temps pour une éventuelle réingénierie.

Tests Système : Tests de Configuration

• Cette catégorie est souvent appliquée aux composants matériels interchangeables ou reconfigurables, mais aussi aux logiciels.
• Le but est d'évaluer la performance et la disponibilité après une reconfiguration, et montrer que les commandes, les menus, et les composants fonctionnent correctement.
• Les tests suggérés incluent permuter les composants interchangeables, induire des défaillances pour vérifier le comportement du système.

Tests Système : Tests de Sécurité

• Les préoccupations principales sont disponibilité, intégrité des données, et confidentialité.
• Les problèmes peuvent provenir de personnes malhonnêtes (vol de données, usurpation, déni de service) ou d'erreurs de développeurs.
• Requiert des connaissances poussées en sécurité informatique.

Tests Système : Tests de Reprise

• Ils évaluent le comportement du système après une perte de ressources.
• Redémarrage : l'état actuel du système est effacé, un état stable est récupéré depuis le dernier point de reprise (checkpoint), puis le système est relancé.
• Commutation (switchover) : la capacité du système à basculer vers une ressource de remplacement est testée.
• Analyse des transactions pour perte, fusion, erreurs, ou duplication.

Tests d'Intégration : Buts

• Détecter les défauts aux interfaces des unités, puis assembler les unités en sous-systèmes et ensuite en système complet.
• La plupart du temps, effectués après revue et réussite des tests unitaires.
• L'implémentation procédurale intègre progressivement un module à la fois pour minimiser les nouvelles interfaces.
• L'implémentation OO intègre progressivement un groupe de classes à la fois, en se basant sur les relations.

Tests d'Intégration : Remarques Préliminaires

• Une fois les composants testés individuellement, les combiner avec les systèmes opérationnels.
• Les composants peuvent être défectueux, car les stubs et pilotes utilisés lors des tests unitaires sont seulement des approximations.
• Des anomalies peuvent survenir au niveau des interfaces.
• L'ordre d'intégration est important, car les pilotes et stubs sont coûteux.

Tests d'Intégration : Autres Remarques Préliminaires

• Bien planifier l'intégration pour identifier rapidement les causes de défaillances.
• Le développement n'est pas séquentiel : codage, tests unitaires et tests d'intégration peuvent être simultanés.
• La stratégie d'intégration influence l'ordre de codage, le test unitaire, les coûts et le détail du test.

Tests d'Intégration : Stratégies pour Procédures et Fonctions

• Les modules et leurs dépendances sont modélisés avec un graphe.
• Les approches courantes sont Big Bang, ascendante, descendante et "en sandwich".

Intégration Pour du Procédural : Big Bang

• Tous les composants sont introduits ensemble et testés en tant que système unique.
• Approprié pour les systèmes petits et bien structurés.
• Convient si une confiance élevée dans les composants existe.
• Il est difficile de trouver la cause principale en cas de défaillances.
• Exige d'attendre que tous les composants soient prêts.
• Généralement non recommandé.

Intégration Pour du Procédural : Intégration Descendante

• Test du système niveau par niveau, en commençant par le plus haut niveau.
• Utiliser des "stubs" pour simuler les composants non encore testés.
• Deux modes principaux : en largeur d'abord ou en profondeur d'abord.

Intégration Pour du Procédural: Intégration Descendante - Aspects Positifs et Négatifs

• En cas de bug, la zone suspecte est limitée.
• Le test peut commencer tôt, dès que les composants de haut niveau sont codés.
• Possibilité de validation de la fonctionnalité principale en avance.
• Les composants peuvent être développés en parallèle.
• Des problèmes de performance peuvent survenir tard dans le processus.
• L’écriture de nombreux stubs peut être complexe, longue et source d'erreurs.
• Peu adapté si les spécifications des composants de bas niveau sont instables.

Intégration Pour du Procédural : Intégration Ascendante

• Le système est testé niveau par niveau, commençant par le plus bas niveau.
• Chaque composant du niveau le plus bas de la hiérarchie est testé en premier.
• Si un problème survient, la cause est soit dans le composant testé, soit dans l'interface avec les composants de niveau inférieur.

Intégration Pour du Procédural: Intégration Ascendante - Avantages et Désavantages

• Nécessité de développer des pilotes de test, mais pas de stubs.
• Les anomalies sont plus facilement isolées, en particulier celles d'interface.
• Le test peut commencer tôt, dès qu'un composant "feuille" est prêt.
• Initialement, les tests peuvent être effectués en parallèle.
• Favorise les routines utilitaires invoquées par d'autres niveaux.
• Permet de valider en avance les composants de performance critique.
• Les composants principaux peuvent être testés en dernier.
• Peut requérir un nombre élevé de tests.
• Peut révéler des défauts de conception au niveau supérieur.

Intégration Pour du Procédural : Intégration en Sandwich

• Choisir une couche cible au milieu.
• Utiliser une approche descendante pour les couches supérieures.
• Utiliser l’approche ascendante dans les couches inférieures.

Intégration Pour du Procédural: Intégration en Sandwich - Avantages et Inconvénients

• Test de l'exactitude des modules utilitaires dès le départ.
• Pas besoin de stubs pour les utilitaires.
• Permet de commencer le test d'intégration des composants supérieurs en avance: tests “contrôle” du composant faits plus tôt.
• L'absence des pilotes de test des couches supérieures est à souligner.
• Cette méthode ne teste pas de manière exhaustive les composants individuels de la couche cible.

Intégration pour du Procédural : Critères de Comparaison

• La disponibilité de stubs et de pilotes.
• Les critères de comparaison dépendent du délai de livraison au marché.
• La date de début de l'intégration doit être tôt.
• Prise en compte de la capacité de planifier et contrôler le processus.
• L'approche descendante est compliquée à cause de l'instabilité des composants de niveau inférieur.

Intégration pour du Procédural : Synthèse des Différentes Approches (1/2)

• Tableau comparatif des approches ascendante, descendante, Big-Bang et sandwich selon différents critères comme le moment où l'intégration commence, le délai de livraison, l'utilisation de pilotes et de stubs, et la facilité de planification.

Intégration pour du Procédural : Synthèse des Différentes Approches (2/2)

• Peu importe l'approche choisie, il faut définir et utiliser des critères de couverture.
• L'approche devrait être basée sur la gestion du risque.
• Les modules "risqués" sont testés le plus tôt possible.
• La disponibilité des modules est déterminante.

Intégration pour du Procédural : Conception (1/2)

• Privilégier les tests boîte noire et boîte blanche.
• La réutilisation des tests unitaires est possible, mais peut nécessiter des modifications ou des ajouts.
• Mettre l'emphase sur les "interfaces" des modules.
• Utiliser des approches basées sur le flux de contrôle et le flux de données.

Intégration pour du Procédural: Conception (2/2)

• Le critère de couverture est que chaque module appelé doit l'être par chacun de ses modules appelants.

Intégration pour de l'Orienté-Objet (OO) : Particularités

• Il existe 2 problèmes distincts : tester les interactions des composants et déterminer un ordre optimal d'intégration.
• Vérifier que les composant interopèrent de manière correcte pour la fonctionnalité.
• Dans un contexte non-OO, centrer l'intégration sur l'interface unité.
• Dans un contexte OO, centrer sur les classes.
• Le polymorphisme et le dynamic binding nécessitent de tester plusieurs invocations d’interfaces.

Intégration pour de l'OO : Niveaux d'Intégration

• L'intégration des membres dans une seule classe.
• L'intégration de deux classes ou plus à travers l'héritage (cluster).
• L'intégration de deux classes ou plus à travers un contenant [containment] (cluster).
• L'intégration de deux classes associées ou plus pour former un composant.
• L'intégration des sous-systèmes dans une application simple.

Intégration pour de l'OO : Héritage et Polymorphisme

• Selon la complexité de l'héritage et du polymorphisme, le nombre d'ensembles de tests varie.
• Aucune classe n'est abstraite.

Intégration pour de l'OO : Clusters (1/2)

• Reposent sur la notion de grappe d'objets (cluster of objects).
• Une grappe est un ensemble de classes liées, les classes coopérant pour supporter une fonctionnalité.

Intégration pour de l'OO : Clusters (2/2)

• Pour choisir les classes à intégrer, intégrer d'abord les grappes coopérant pour supporter des fonctionnalités simples ou celles où les classes coopèrent peu.
• Une architecture en couches bien utilisée est utile pour ce besoin.

Intégration pour de l'OO : Conception

• L'interface entre les éléments logiciels demeure au centre.
• L'accent est mis sur les messages échangés entre les objets, plutôt que sur le comportement interne de chaque objet.
• Contrairement au cas procédural, il est rare qu'on intègre un système OO une classe à la fois.

Tests Unitaires : Les Unités

• L'unité est le plus petit composant logiciel testable.
• Tests unitaires : l'assurer que chaque unité est fonctionnelle selon ses spécifications.
• Caractéristiques de l'implémentation procédurale : fonction cohésive, compilable séparément, tâche dans l'organigramme des tâches et code tenant sur une page.

Tests Unitaires : État de l'Art

• Les tests doivent être planifiés et publics.
• La planification implique : allocation de ressources, conception des tests divers et test par une personne indépendante.
• Public implique : les résultats de tests sont sauvegardés, les données liées aux défauts trouvés font partie de l'historique de l'unité et l'unité est revue avant les tests.

Tests Unitaires : État de la Pratique (Trop Souvent)

• Le développeur teste lui-même le code informellement dès que ça compile.
• Aucun résultat d'exécution de test n'est sauvegardé, pas plus que les données associées aux défauts trouvés.
• Une revue, lorsqu'elle existe, est informelle et sans mémoire.

Tests Unitaires : Tâches du Testeur

• Les principales tâches sont : planifier l'approche générale, concevoir les tests/procédures, définir les relations entre les tests et préparer le code auxiliaire.

Tests Unitaires : Conception

• La conception d'un test comprend les données de test et les procédures de test.
• Les relations entre les tests (suites) et la conception doivent être sauvegardées pour être réutilisées.
• L'emphase est mise sur les tests boîte blanche, mais les tests boîte noire sont importants aussi.
• Pour les unités critiques, il est recommandé de prévoir des tests de stress, de performance et de sécurité.

Tests Unitaires : Particularités OO (1/7)

• Décision : l'unité est-elle une classe OU une méthode ?
• Compromis entre l'intégralité des tests et leur coût.
• Si l'unité est une méthode : l'avantage est une bonne couverture, l'inconvénient est la production de substituts (stub).

Tests Unitaires : Particularités OO (2/7)

• Si l'unité est une classe : à l'inverse, les autres méthodes de la même classe sont utilisées directement et elle permet d'identifier les défauts liés.
• Un inconvénient est qu'au niveau des méthodes individuelles, le test est moins "complet".

Tests Unitaires : Particularités OO (3/7)

• Tester adéquatement une classe est une préoccupation.
• Si l'unité est considérée comme une classe, alors il est requis de bien définir la couverture de fonctionnalité et bien sélectionner les séquences d'invocation.

Tests Unitaires : Particularités OO (4/7)

• Un exemple utilise comme classe une pile (stack).
• Dans cette situation, d'autres séquences sont possibles, mais une combinaison des deux approches peut être une solution.

Tests Unitaires : Particularités OO (5/7)

• Observer l’état et les changements d’états d’un objet représente une autre préoccupation.
• En plus d'une valeur retournée, l'état de l'objet et ses transitions sont des points d'intérêt.
• Les séquences de tests sont alors augmentées avec des invocations visant à vérifier l'état de l'objet.

Tests Unitaires : Particularités OO (6/7)

• Lors du test d'une pile, il faut ajouter des séquences pour l'ajout sur une pile pleine et le retrait d'une pile vide.
• La méthode d'accès à l'état de l'objet doit exister.

Tests Unitaires : Particularités OO (7/7)

• Il faut re-tester une classe ainsi que ses classes dépendantes à chaque fois que son implémentation change, même avec une interface intacte.
• Si une classe parent change, il est nécessaire de re-tester ses descendants.
• Il faut également re-tester toutes les méthodes héritées des classes enfants si la classe enfant est ajoutée ou modifiée.
• Si une méthode est réimplémentée (overriding) dans une classe enfant, il faut la re-tester.

Tests Unitaires : Exécution et Enregistrement des Résultats

• L'exécution des tests unitaires peut débuter une fois l'unité prête, les tests conçus et le harnais disponible.
• Les résultats des tests sont saisis et les causes probables sont notées.
• Une unité est prête à être intégrée au système après ses tests unitaires.
• Elle peut être intégrée avant certains tests si quelqu'un assume les risques.

Tests de (Non) Régression

• Ce n'est pas un niveau de test à proprement parler.
• Il s'agit de réexécuter des tests suite à des modifications pour s'assurer qu'aucun élément existant n'a été altéré.
• Ces tests sont pertinents à tous les niveaux.

Tests Alpha, Bêta et d'Acceptation

• Les usagers prennent part plus activement aux tests, et l'objectif est de vérifier le bon fonctionnement du système.
• Les tests se font dans un environnement de production et dans des conditions d'utilisation réelles.

Tests Alpha, Bêta et d'Acceptation : Logiciel Pour un Client Unique

• Tests d'acceptation basés sur les exigences et le manuel d'utilisation.
• Le client autorise le paiement final.
• Des tests d'installation permettent d'interconnecter le nouveau système à des infrastructures existantes.

Tests Alpha, Bêta et d'Acceptation : Logiciel "de Masse"

• Tests alpha et bêta.
• Un test alpha est réalisé en interne par les employés.
• Un test bêta est envoyé à un petit groupe de clients.
• Les problèmes sont signalés à l'organisation de développement.
• Les problèmes ne sont pas toujours corrigés immédiatement.

Sommaire sur les Niveaux de Tests

• Chaque niveau se concentre sur un niveau d'abstraction particulier, possède des objectifs spécifiques, révèle des types de défauts et utilise des artefacts pour concevoir les tests
• C'est utile pour évaluer les caractéristiques et la qualité, et c'est associé à un plan orienté niveaux.