Techniques de test Boulanger Jean-Louis

Plan Problématique Principe et définition Processus de Test

Problématique

Vérification & Validation (1) Processus qui s’étale sur l’ensemble du développement Processus qui permet de s'assurer que le logiciel correspond à son cahier des charges, le cahier des charges correspond aux besoins de l'utilisateur. Deux objectifs: Mettre en évidence les défauts du système Estimer si le système peut-être mis en service ou non. Le génie logiciel regroupe un ensemble de techniques et pratiques mis en oeuvre tout au long du cycle de développement du logiciel. Les activités qui permettent de s'assurer que le logiciel développé correspond aux attentes de l'utilisateur final sont appelées Vérification et Validation du logiciel. Elles doivent permettre de mettre en évidence les défauts du système et de décider si le système peut être mis en service ou non.

Les défauts dans le logiciel d’où viennent-ils ? Les défauts sont souvent dûs à : Une mauvaise compréhension Une perte d'informations Des oublis, des fautes

Remarques Leitmotiv: Il faut faire des vérifications aux plus tôt. Plus un défaut est découvert tardivement, plus il coûte cher à corriger. Il faut faire des vérifications aux plus tôt.

Vérification & Validation (2) Le produit (logiciel) correspond à sa spécification? Le construisons nous bien ? Validation : Le produit (logiciel) correspond aux attentes? Construisons nous le bon produit ?

Vérification & Validation (3) Fonctions Codées Fonctions spécifiées

Vérification & Validation (4) Techniques d’analyse et de vérification statiques et dynamiques Statique: Analyse des différentes représentation du produit à tous les stades du développement (revues) Dynamique: Il faut un produit qui pourra être « testé ».

Vérification & Validation (5)

La vérification statique. Activités liées aux tests Revue technique Lectures croisées et inspection (contrôle collégial) Analyse statique Recherche d'anomalies : typage impropre, incohérence des interfaces modules, duplication, mauvais usage des variables, non respect des conventions, ... Evaluation symbolique : simulation exécution sur données symboliques Vérification formelle Les tests statiques sont particulièrement utiles dans les cas de non déterminisme exécutoire comme lors de l'utilisation du parallélisme Traitement des sources

Les revues techniques. Le processus de revues techniques est un processus de vérification statique qui inclus : l'inspection de programme, Vérification des règles de programmation Lisibilité Présence et pertinence des commentaires Vérification conformité code/dossier de conception la revue technique, Processus Documentation, code et test l'audit.

Les analyseurs statiques. Les analyseurs statiques sont des logiciels qui permettent de mettre en évidence de nombreuses anomalies, d'effectuer des mesures de complexité, de générer les graphes de contrôle et d'appel et de vérifier le respect de normes de programmation sans exécution du code. Les principales anomalies rencontrées sont (liste non exhaustive): Composants isolés (en général jamais appelés - attention malgré tout aux composants utilisés par les interfaces graphiques) Sauts de niveaux. Un graphe d'appel se structure en niveaux hiérarchiques qui doivent être respectés. Un saut de plusieurs niveaux indique une mauvaise conception de l'application. Graphe trop large (mauvaise décomposition hiérarchique). Graphe trop profond. L'application a été décomposée en petits composants qui risquent de ne plus avoir de fonctionnalités précises et cela risque également de poser des problèmes au moment des tests d'intégration. Cette phase est accompagnée du calcul d'un certain nombre de mesures permettant une quantification de la "qualité" de l'architecture de l'application.

La vérification formelle. Ce type de vérification permet de prouver qu'un programme est conforme à sa spécification. Pour cela il faut utiliser des langages de spécifications formelles (c'est-à-dire que la sémantique du langage doit être définie de manière formelle) et que la notation soit en cohérence avec les techniques de preuves que l'on va utiliser). Les langages Z, B, VDM sont des langages formels. On peut également utiliser des preuves logiques pour décider que le programme est logiquement conforme aux spécifications ou qu'il se terminera, par exemple. La mise en oeuvre des langages formels ou des techniques de preuves logiques n'est pas triviale et ne se justifie que pour des logiciels dits critiques c'est-à-dire ceux qui doivent avoir une (très) bonne fiabilité.

Qu’est ce que le test ? G. Myers, The Art of Software Testing Selon l'I.E.E.E. : « 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. » G. Myers, The Art of Software Testing « Tester c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts. »

Tester Rechercher les inadéquations d'un système logiciel par rapport à des références établies comme (Gaudel & Co, 96) : Spécifications Normes Règles Documents concernant le système Activités liées aux tests statiques : Traitement des sources dynamiques : Repose sur l'exécution

Test dynamique (1) Pour tester un programme, on l’exécute avec des données semblables à celles qu’il devra traiter lorsqu’il sera opérationnel. A partir des anomalies de fonctionnement, on en déduit les défauts du programme.

Test dynamique (2) D’où quelque question: Comment choisir les entrées du programme ? Comment décider que le résultat est bon ou mauvais ? Quand faire les tests ? Quel outillage ?

Efficacité Le test est une activité a part entière du processus de développement, elle doit être organisée, planifiée et outillée. Les tests doivent être reproductible: Formalisation Archivage, Documentation, Outillage, Automatisation du jeu et du rejeu ?