Les tests des logiciels Introduction

Importance Les « bogues » : des conséquences parfois mortelles, parfois gênantes et très coûteuses 50 à 60 % du coût total du projet d’un logiciel (hors maintenance) De nouvelles méthodes, de nouveaux outils, un nouveau métier …

Définitions L’assurance qualité : ensemble des dispositions qui vont être prises tout au long des différentes phases de fabrication d’un logiciel pour accroître les chances d’obtenir en final un logiciel qui corresponde aux objectifs d’utilité désirés et fixés. Les activités de tests sont un sous-ensemble des activités de l’assurance qualité. Les activités de tests appartiennent au processus de développement.

Définitions Erreur Défaut (faute) Anomalie (défaillance). est commise par une ressource participant à la création du logiciel. Défaut (faute) est en quelque sorte le résultat d’une erreur. Anomalie (défaillance). est un comportement observé différent du comportement attendu (ou spécifié). Une erreur génère un défaut qui génère une anomalie

Une typologie de défauts (1) Calcul : mauvais calcul Logique : mauvaise expression d’un prédicat Entrée / sortie : mauvaise communication avec l’extérieur mauvaise description, une mauvaise conversion ou un formatage adéquat Traitement de données Mauvais(e) accès (manipulation) aux (de) données. Exemple : mauvaise utilisation de pointeur, variable non définie, débordement d’indice, etc.

Une typologie de défauts (2) Interface Mauvaise communication entre les constituants internes du logiciel. Exemple : appel de la procédure P1 au lieu de P2. Définition des données Exemple : la donnée est définie comme un entier au lieu d’un réel ; en simple précision au lieu d’être en double, etc.

Définition de l’activité de tests (1) Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus. (IEEE)

Définition de l’activité de tests (2) Tester, c’est exécuter le programme dans l’intention de trouver des erreurs (G.J. Myers). Le test est une technique de contrôle consistant à s’assurer, au moyen de son exécution, que le comportement d’un programme est conforme à des données préétablies. (AFCIQ)

Objets & Critères de classification Les objets nécessaires aux tests sont : les spécifications de programme, le code source du programme, le code binaire du programme, Critères : d’utilisation de ces objets. Donc 7 classes de techniques possibles

Typologie des techniques de tests Légende : la case colorée et coché indique que la classe demande l’existence de l’objet correspondant

Présentation des 7 classes (1) Classe 1 : sont groupées dans cette classe toutes les techniques de tests « aveugles » (tests faits par l’utilisateur ou un certain ensemble de tests aléatoires). Classe 2 : le code source est examiné pour identifier des erreurs indépendantes de l’application. Techniques d’analyse statique du flot de données, les revues de codes, les analyseurs de complexité, etc.

Présentation des 7 classes (2) Classe 3 : formée par l’analyse dynamique du flot des données. Classe 4 : sont comprises dans cette classe toutes les techniques d’analyse de spécifications (cohérence, etc.). Classe 5 : tests aux limites, graphes cause-effet, la plupart des tests aléatoires, tests basés sur la syntaxe, etc.

Présentation des 7 classes (3) Classe 6 : techniques d’exécution symbolique de programme et de preuve d’exactitude d’algorithme. Classe 7 : sont regroupées ici la plupart des techniques structurelles. Techniques de couverture des instructions, des arcs du graphe de contrôle, PLCS, etc. Techniques de tests mutationnels. Méthodes de couverture basées sur les flots de données.

Fonctionnel / structurel & Boîte « noire » / « blanche » Les techniques qui n’ont pas besoin du code source sont appelées techniques fonctionnelles (ou boîte noire), cas des classes 1, 4 et 5. Les classes 2, 3, 6 et 7 s’appellent techniques de tests boîte « blanche » ou structurelles basées sur le code source.

Statique / dynamique Les techniques qui exécutent le code binaire en examinant le comportement réel du programme s’appellent « dynamiques ». Cas des classes 1, 3, 5 et 7. Les autres techniques, qui examinent la forme (le code source), sont appelées statiques. Cas des classes 2, 4 et 6.

Tests fonctionnels et structurels Les techniques fonctionnelles testent ce qui devrait être fait détection des erreurs omises détection d’erreurs, localisation à effectuer Les techniques structurelles testent ce qui est fait détection des erreurs commises. localisation aisée

Rapport de détection & couverture Le rapport de détection D est égal nombre de défauts trouvés / nombre total de défauts Note le nombre total de défauts est le nombre de défauts détectés à la fin de la phase de tests. C’est une approche empirique. La couverture de tests est égale au nombre de cas spécifiés / nombre de cas testés.

Les tests fonctionnels Approche par les données Techniques fonctionnelles classiques Analyse partitionnelle Tests aux limites Approche par le comportement Passe par une modélisation du logiciel avec des graphes orientés ou des arbres. Technique cause – effets, Tests syntaxiques avec des grammaires ou automates d’états finis, Tests aléatoires ou statistiques.

Technique fonctionnelle classique C’est la technique la plus employée et de très loin. Elle consiste à tester chacune des fonctions du logiciel avec des jeux d’essais établis vis-à-vis d’un cahier des charges ou des spécifications.

Technique d’analyse partitionnelle Voisine de la technique fonctionnelle classique Elle s’intéresse au domaine des variations de données en entrée pour partitionner ce domaine en classes d’équivalence

Technique de tests aux limites Voisine de la technique fonctionnelle classique Basée sur le principe que « les erreurs se cachent dans les coins » Elle fait ressortir les aspects liés aux domaines de variation des données et identifie leurs intervalles de variations pour en déduire des jeux d’essais.

Technique cause effets Elle met en avant le comportement du logiciel Elle consiste à lier les effets c.-à-d. les sorties aux causes qui sont à l’origine c.-à-d. les entrées par un graphe.

Les techniques syntaxiques Elle met en avant le comportement du logiciel Elle consiste à modéliser le logiciel par une grammaire ou un automate d’états finis.

Technique de tests aléatoires ou statistiques Elle met en avant le comportement du logiciel. Elle consiste à générer des données aléatoires pour solliciter le logiciel. Sa version manuelle est le « monkey tests »: tests réalisés par un béotien

Techniques structurelles Statiques Revue de code Mesure des caractéristiques du code Analyse du flot de données Dynamiques L’objectif est la couverture de la structure du code

Revue de code Elle consiste à : la relecture par une équipe du code pour vérifier le respect de règles de programmation et des bonnes pratiques. Elle dépend de la sagacité et de l’attention du lecteur

Mesure des caractéristiques du code Elle consiste à mesurer des caractéristiques du code telles que : Le nombre de lignes par module, Le taux de commentaires, Le nombre de données en entrée et en sortie … Et de les comparer à des seuils afin de décider suivant une stratégie de tests établie en amont. La plus connue est la mesure de complexité de Mc Call ou celle de Halstead par exemple.

Analyse du flot de données Elle consiste à analyser le flot de données ou le flot de contrôles pour vérifier typiquement l’absence de variables déclarées mais jamais utilisées, l’absence de variables écrites à 2 reprises sans être relue entre ces 2 opérations.

Les types de tests au cours d’un projet On distingue principalement pendant le projet les tests unitaires, les tests d’intégration, les tests de validation; en maintenance corrective ou évolutive les tests de non régression.

Les principaux cycles de vie d’un logiciel Les cycles les plus connus sont : le cycle de vie en cascade, le cycle de vie en V, le cycle de vie Merise, le cycle de vie en spirale.

Les tests unitaires (1) Ils concernent les modules élémentaires en conception classique, les machines abstraites en conception par abstraction, les objets terminaux en orienté objet. Ces entités élémentaires ont leurs entrées, leurs sorties, leurs propres données, une fonction clairement identifiée ainsi qu’une interface au moins.

Les tests unitaires (2) Il est souhaitable de réaliser ces tests sur machine cible mais en réalité ils s’exécutent sur une machine de développement. Ces tests sont d’abord conçus dans un dossier de tests unitaires, puis exécutés ce qui donne lieu à un compte rendu et des fiche d’anomalies ou de non conformités. Toutes les techniques de tests sont applicables.

Les tests d’intégration (1) Ils testent les interfaces entre les entités élémentaires, leur comportement dans l’environnement, leurs interactions avec le matériel, D’où la nécessité de les réaliser sur machine cible même s’ils débutent sur machine de développement.

Les tests d’intégration (2) Ils sont réalisés vis-à-vis de la conception générale ou préliminaire. Toutes les techniques de tests sont applicables : pour les logiciels standards, seules les techniques fonctionnelles sont réalisées, en général, pour les logiciel critiques, les techniques structurelles sont appliquées.

Outils d’intégration Les bouchons Les lanceurs qui simulent des composants non encore intégrés. Les lanceurs qui sollicitent les entrées des composants non encore intégrés. Ces programmes, bouchons et lanceurs, sont testés.

Organisation de l’intégration Il est délicat d’établir l’ordre des tests. Cet ordre dépend de l’architecture, la disponibilité des composants, de l’environnement à mettre en place (matériels, logiciels, bouchons, lanceur, …) Et influe sur le planning de développement

Stratégies d’intégration Premier choix intégration en une seule fois, intégration par incréments c.-à-d. composant par composant, intégration par agrégats c.-à-d. groupes de composants par groupes de composants. Deuxième choix Démarche ascendante : commencer par les composants de plus bas niveau, Démarche descendante : commencer par les composants de plus haut niveau.

Intégration en une seule fois Avantages pas de développement de bouchons et lanceurs, pas de contraintes sur le développement; Inconvénients risque de grandes difficultés de localisation des erreurs et de maîtrise du logiciel.

Intégration par incréments Avantages localisation aisée des erreurs; Inconvénients grand nombre de bouchons à développer, de nombreuses étapes.

Intégration par agrégats Avantages peu d’outillage (bouchons, …) et de jeux d’essais bien adaptée à une livraison par lot; Inconvénients localisation des erreurs pas très aisée mais quand même circonscrite

Intégration ascendante / descendante

Tests de validation (1) Vérification Validation on vérifie que l’on a bien fait le logiciel. Validation on valide que l’on a fait le bon logiciel. En validation, on adopte le point de vue de l’utilisateur et donc on réalise des tests fonctionnels, boîte noire.

Tests de validation (2) Ils s’exécutent vis-à-vis des spécifications ou de l’étude préalable sur des machines cibles d’exploitation dans un environnement réel ou une simulation de cet environnement.

Tests de non régression (1) Aujourd’hui, 54% des erreurs sont détectées par le client, d’où des maintenances correctives et évolutives. Le but est de maîtriser et tester l’introduction de nouvelles erreurs lors de maintenances.

Tests de non régression (2) Sur les logiciels standards S’interroger de manière informelle sur l’impact de la modification sur les autres composants et sur les variables manipulées. Sur les logiciels critiques Recours à des outils d’analyse de flots, Examination de graphe d’appel logiciel, Technique d’injection de défaut.

Tests de non régression (3) Les modifications réalisées suivent le cycle normal de tests : réaliser une campagne de tests unitaires sur les composants modifiés, adapter et rejouer les tests d’intégration qui font appel aux composants modifiés, adapter et rejouer les tests de validation qui font appel aux fonctions modifiées, mettre à jour les spécifications.

Conclusion Beaucoup de travail en perspective, des techniques qui évoluent, des outils nouveaux. Merci !

Bibliographie Le test des logiciels par Spyros Xanthakis, Pascal Régnier, Constantin Karapoulios. Edition Hermes Sciences. M.-C. Gaudel, B. Marre, F. Schlienger et G. Bernot. Précis de génie logiciel. Collection Enseignement de l'Informatique. Masson, 1996. 142 pages. Préface de Michel Lemoine. La qualité des logiciels par Jean-Pierre Martin. Afnor