Qualité Logicielimad-hafidi.com/Cours/Genie/QL.pdf · Qualité Logiciel Pr Hafidi Imad...

Génie logiciel TEST

Hafidi Imad-ENSAK-Cours QL 1

Qualité Logiciel

Pr Hafidi Imad [email protected]


Introduction

Notion de qualité   La notion de qualité est une partie intégrante du processus de

fabrication d'un produit   Un organisme international a édicté une série de normes sur

ce sujet(Norme ISO)

Pourquoi ?


  Il faut de comprendre l'évolution du rapport producteur/acheteur pour expliquer cette apparition de notion de qualité dans le monde économique.


  Les objectifs de qualité rejoignent bien souvent les objectifs de productivité  Adéquation aux besoins   Efficacité temps/espace   Fiabilité   Sécurité,   Intégrité  Testabilité, Traçabilité   Adaptabilité, Maintenabilité,  Convivialité (interface, aide et documentation)   Pérennité (facilité de la maintenance)


  La qualité vise à réduire le nombre d'erreurs résiduelles, maîtriser les coûts et la durée du développement sans nuire à l’innovation et à la créativité.


  Les moteurs de l'assurance qualité sont multiples : on peut citer   L'organisation du processus : découper le processus pour le

maîtriser   Les ressources humaines : les équipes doivent être motivées

pour mettre en place des procédures qualité   L'utilisation de techniques, méthodes, outils   Les considérations managériales, politiques et économiques :

considérer le retour sur investissement de la mise en place de procédures qualité par une analyse coûts bénéfices.


Assurance qualité

Assurance qualité : "Mise en oeuvre d'un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l'obtention de la qualité requise."

Plus précisément toutes les normes qualité insistent sur trois aspects essentiels : communication, contrôle, organisation.


Organisation   Le processus de développement est classiquement organisé

en différentes phases conformément à la figure


  Une tâche essentielle du chef de projet est d'organiser ces différentes phases et de les lier à des activités en y affectant les ressources nécessaires tant humaines que logicielles ou matérielles. L'enchaînement des activités constituera le workflow du projet.

  Chaque activité débouche sur un produit intermédiaire dont la production détermine la fin de l'activité et qui devra être contrôlé avant de passer à l'activité suivante.


Contrôle   L'assurance qualité passe par des contrôles réguliers et inclut

  la validation : permet de répondre à la question "sommes nous en train de faire le bon produit? "

  la vérification : répond à la question "est ce que nous faisons le produit correctement"


Croissance des erreurs


Inspection   le rôle primordial de contrôles intermédiaires. La validation

et la vérification sont en partie garanties par la mise en place des d'inspections, revues, relectures pour tous les produits intermédiaires du développement (prototypes/ maquettes, documents de spécification, de conception, code, jeux de tests)

  L'inspection est une lecture critique d'un document (spécification, conception, code, plan d'intégration...); elle est destinée à améliorer la qualité d'un document.

  l'inspection est faite par une équipe indépendante du projet constituée par: un Modérateur, un Experts(s), Secrétaire , le client


  une inspection doit donner lieu à la rédaction de fiches de défauts avec une échelle de gravité et la définition des responsabilités concernant la correction des défauts.

  Les inspections sont à la base des décisions prises en revues. Une revue est une réunion permettant de valider une des phases du cycle de vie


  - les revues produits: état d'un projet sous ses différents aspects: Techniques, Financiers, Commerciaux, Calendrier, ...

  les revues techniques (celles qui nous intéressent le plus dans le cadre de ce cours): elles permettent de fournir au marketing et à l'unité de développement une évaluation des aspects techniques du projet et des coûts de réalisation

  les réunions de décision: elles valident le passage à la phase suivante et font bien souvent suite à l'une des deux précédentes.


Communication   L’assurance qualité insiste sur la nécessité de communiquer à

différents niveaux:   entre développeurs et environnement, (clients avant le

développement, support pendant la phase de maintenance) : cahier des charges, dossier d'analyse, manuel d'installation, dossier de conception, plan projet, plan qualité

  entre les développeurs (dossier d'analyse, dossier de conception, plan qualité, commentaires du code, résultats de tests…).

 Certains documents sont plus spécifiquement dédiés à la gestion de la qualité, il s'agit du manuel qualité de l'entreprise et du plan qualité du projet.


Manuel qualité   Le manuel qualité décrit les procédures définies par une

entreprise ou une organisation pour atteindre ses objectifs de qualité.

  Il répertorie les méthodes et procédures à utiliser pour:  Gestion de projets   Réalisation, Vérification, Validation,   Evaluation de la Qualité (Mesures).

  En s'appuyant sur:  Rédaction de standards, normes (ISO, DOD..) , conventions,

guides,   Expérience acquise des projets, pour améliorer le processus.


Plan de qualité   Le plan qualité logiciel définit, pour un projet

donné, en accord avec le manuel qualité de l'entreprise, les méthodes techniques et outils permettant d'atteindre les objectifs de qualité pour un coût donné.

  Le plan qualité fait partie des éléments contractuels liant un client et son fournisseur de logiciels. Il est établi lors de la phase de planification.



Analyse Statique du code

  L’analyse statique de code consiste à étudier un programme source sans exécution du code en faisant appel à des listes de défauts typiques ou à des métriques dont les valeurs acceptables sont définies dans le plan qualité du projet.

  Cette activité doit être réalisée avant le processus de tests informatiques car elle permet souvent de mettre en évidence des erreurs de logique qui peuvent être coûteuses à corriger si elles sont découvertes tard.


  Les moyens mis en œuvre:   étude visuelle du programme source ,   étude graphique du flot de contrôle, des graphes d’appels,  métrologie du logiciel.

  Les résultats:   logique employée dans le programme,   communications entre les composants,   erreurs syntaxiques et structurelles,   style employé.


Inspection : par des extérieurs, checklist de défauts   Références aux données, variables non initialisées, indices de

tableaux compris entre les bornes   Calculs, conversions de types, division par zéro   précédence des opérateurs, Comparaisons entre types

consistants, vérifier opérateurs > >= et > >=, vérifier expressions booléennes & ou not, Contrôle

  terminaison des boucles, sortie des procédures et fonctions, conditions initiales, une itération en trop (ou en moins)

  toutes les possibilités d’un case testées.


  Cette liste n’est pas limitative et doit être adaptée à chaque langage.

  Le plan qualité prévoit en général l’utilisation de règles de programmation qui doivent également être vérifiées.



Introduction au test de logiciels

Introduction   Les tests permettent de vérifier de manière dynamique que le

produit réalisé est conforme aux intentions.   L’activité de tests est aussi vieille que le développement mais

elle est encore trop souvent empirique. Elle est pourtant le dernier rempart contre les erreurs résiduelles.


Définition Norme IEEE (Standard Glossary of Software Engineering

Terminology) « 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. »


  « Tester peut révéler la présence d'erreurs mais jamais leur absence »  Vérification partielle : le test ne peut pas montrer la conformité

du système (nécessité d'une infinité de tests)

  « Tester, c'est exécuter le programme dans l'intention d'y trouver des anomalies ou des défauts »  Objectif : détection des bugs


Bug   Anomalie (fonctionnement) : différence entre comportement

attendu et comportement observé   Défaut (interne) : élément ou absence d'élément dans le

logiciel entraînant une anomalie   Erreur (programmation, conception) : comportement du

programmeur ou du concepteur conduisant à un défaut


Erreur Défaut Anomalie

Limite de la vérification   Indécidabilité : Un problème est indécidable s'il n'existe pas

d'algorithme capable de le résoudre dans le cas général   Ex : Problèmes indécidables

  L'exécution d'un programme termine  Deux programmes calculent la même chose  Un programme est une implantation correcte de sa spécification

Il n'existe pas d'algorithme permettant de prouver la correction de n'importe quel programme


Limite de test   Explosion combinatoire : Nombre d'exécutions possibles

d'un programme potentiellement infini

Mais test = processus fini Nécessité d'approcher l'infini (l'extrêmement grand) par le fini

(heuristique)


Évolution du test   le test de logiciels :

  est la méthode la plus utilisée pour assurer la qualité des logiciels

  fait l'objet d'une pratique trop souvent artisanale

  le test de logiciels devrait être :   une activité rigoureuse   fondée sur des modèles et des théories   de plus en plus automatique


Exemple   Spécification : Le programme prend en entrée trois entiers,

interprétés comme étant les longueurs des côtés d'un triangle. Le programme retourne la propriété du triangle correspondant : scalène, isocèle ou équilatéral.

  Exercice : Écrire un ensemble de tests pour ce programme


  16 cas correspondant aux défauts constatés dans des implantations de cette spécification

  Moyenne des résultats obtenus par un ensemble de développeurs expérimentés : 55%

La construction de tests est une activité difficile, encore plus

sur de grandes applications


Vocabulaire du test   Objectif de test : comportement du système à tester   Données de test : données à fournir en entrée au système de

manière à déclencher un objectif de test   Résultats d'un test : conséquences ou sorties de l'exécution

d'un test (affichage à l'écran, modification des variables, envoi de messages...)

  Cas de test : données d'entrée et résultats attendus associés à un objectif de test


Exemple : tri d'une liste d'entiers


Problème de l’oracle   Oracle : décision de la réussite de l'exécution d'un test,

comparaison entre le résultat attendu et le résultat obtenu   Problème : décision pouvant être complexe

  types de données sans prédicat d'égalité   système non déterminisme : sortie possible mais pas celle

attendue   heuristique : approximation du résultat optimal attendu


  Ex : Trouver le minimum d'une liste d'entiers   Entrée : [4; 2; 3; 6] Sortie attendue : 2  Oracle : Égalité entre entiers OK

  Ex : Calculer l'itinéraire le plus rapide entre deux villes   Entrée : Paris – Lyon Sortie attendue : ...A6...  Oracle : Trajet de 4h17 (quel que soit l'itinéraire choisi) OK

  Ex : Problème du sac à dos (résolu avec une heuristique)  Oracle : Résultat = résultat optimal + 5% OK


  Oracle : En général, résultat attendu = ensemble de conditions si plusieurs solutions possibles et énumération impossible

  Risques : Échec d'un programme conforme si définition trop stricte du résultat attendu   Faux positif (false-fail)

  Voir l'exemple du calcul d'itinéraire dans lequel on impose un chemin.


  Validité des tests : Les tests n'échouent que sur des programmes incorrects

  Faux positif (false-fail) : fait échouer un programme correct

  Complétude des tests : Les tests ne réussissent que sur des programmes corrects

  Faux négatif (false-pass) : fait passer un programme incorrect

  Validité indispensable, complétude impossible en pratique  Toujours s'assurer que les tests sont valides


Processus test   1.Choisir les comportements à tester (objectifs de test)   2. Choisir des données de test permettant de déclencher ces

comportements + décrire le résultat attendu pour ces données   3. Exécuter les cas de test sur le système + collecter les résultats   4. Comparer les résultats obtenus aux résultats attendus pour

établir un verdict


Exécution d’un Test   Scénario de test :

  Préambule : Suite d'actions amenant le programme dans l'état nécessaire pour exécuter le cas de test

 Corps : Exécution des fonctions du cas de test   Identification (facultatif) : Opérations d'observation rendant

l'oracle possible   Postambule : Suite d'actions permettant de revenir à un état

initial


Exemple : Pop (supprimer le sommet d'une pile)


Types de test


Test boite noire : Test fonctionnel   Sélection des tests à partir d'une spécification du système

(formelle ou informelle), sans connaissance de l'implantation Possibilité de construire les tests pendant la conception, avant

le codage


Ex : Distributeur de café et thé


Test Boite blanche : Test structurel   Sélection des tests à partir de l'analyse du code source du

système

  Construction des tests uniquement pour du code déjà écrit


40

analysedu code

if xthen res := yelse res := 0endif

SUCCÈS

res = 0

Test boîte blanche

x = 1, y = 0 res = 0

sélection

exécution

oracle

x

res := y res := 0

true false

x AND y


Couverture de chaque instruction (C0)   Critère de couverture : Règle pour sélectionner les tests et

déterminer quand les arrêter   Au pire, on peut sélectionner des cas de test au hasard jusqu'à

ce que le critère choisi soit satisfait   Oracle : Permet de déterminer la sortie attendue associée

aux cas sélectionnes  Difficile a mettre en place si on veut automatiser  Complètement le processus de test


  Selon ce critère, chaque instruction doit être exécutée avec des données de test

  Sélectionner des cas de test jusqu’a ce qu'un outil de   couverture indique que toutes les instructions du code ont

été exécutées


Exemple

  Apres le quatrième test, toutes les instructions sont exécutée   Il est rare que le jeu minimal soit bon d'un point de vue

fonctionnel


Boite noire VS Boite blanche   Complémentarité : détection de fautes différentes

  Boîte noire : détecte les oublis ou les erreurs par rapport à la spécification

  Boîte blanche : détecte les erreurs de programmation

  Ex : Addition d'entiers modulo 100 000

  Boîte noire : détecte l'erreur par rapport à la spécification   Boîte blanche : détecte l'erreur pour les valeurs (600,500)


Cycle de vie d’un logiciel


Test unitaire   Test des unités de programme de façon isolée,

indépendamment les unes des autres, c'est-à-dire sans appel à une fonction d'un autre module, à une base de données...  méthodes, classes, modules, composants

  Ex : GPS  Algorithme de calcul d'itinéraire sur des exemples de graphes

construits à la main


Test d’intégration   Test de la composition des modules via leur interface

communications entre modules, appels de procédures...   Ex : GPS

  Lecture des données depuis la base de données  Communications avec l'IHM


Test système   Test de la conformité du produit fini par rapport au cahier

des charges, effectué en boîte noire au travers de son interface

  Ex : GPS  Utilisation du logiciel sur des scénarios réalistes et complets


Test de conformité   But : Assurer que le système présente les fonctionnalités

attendues par l'utilisateur   Méthode : Sélection des tests à partir de la spécification, de

façon à contrôler que toutes les fonctionnalités spécifiées sont implantées selon leurs spécifications

  Ex : Service de paiement en ligne   Scénarios avec transaction acceptée/refusée, couverture des

différents cas et cas d'erreur prévus


Test de robustesse   But : Assurer que le système supporte les utilisations

imprévues   Méthode : Sélection des tests en dehors des comportements

spécifiés (entrées hors domaine, utilisation incorrecte de l'interface, environnement dégradé...)

  Ex : Service de paiement en ligne   Login dépassant la taille du buffer  Coupure réseau pendant la transaction


Test de sécurité   But : Assurer que le système ne possède pas de vulnérabilités

permettant une attaque de l'extérieur   Méthode : Simulation d'attaques pour découvrir les faiblesses

du système qui permettraient de porter atteinte à son intégrité

  Ex : Service de paiement en ligne   Essayer d'utiliser les données d'un autre utilisateur   Faire passer la transaction pour terminée sans avoir payé


Test de performance   But : Assurer que le système garde des temps de réponse

satisfaisants à différents niveaux de charge   Méthode : Simulation à différents niveaux de charge

d'utilisateurs pour mesurer les temps de réponse du système, l'utilisation des ressources...

  Ex : Service de paiement en ligne   Lancer plusieurs centaines puis milliers de transactions en

même temps


Un type de test transversale


Test de non régression   But : Assurer que les corrections et les évolutions du code

n'ont pas introduit de nouveaux défauts   Méthode : À chaque ajout ou modification de fonctionnalité,

rejouer les tests pour cette fonctionnalité, puis pour celles qui en dépendent, puis les tests des niveaux supérieurs   Lourd mais indispensable  Automatisable en grande partie



Fiabilité & SDF logiciel

  les problèmes lies a la maîtrise des risques et la sûreté de fonctionnement ont vu leur importance et leur retentissement considérablement augmenter.


Exemple   Extraits d'un article de Libération du 19 novembre 2004

suite a la succession de pannes des réseaux informatiques français :  A la racine de toutes ces pannes, on trouve des défaillances de

l'informatique. Il s'agit d'anomalies logicielles.  On contrôle la qualité des services ou encore la couverture des

réseaux, mais pas la vulnérabilité des systèmes.   Si la panne survient, c'est que les operateurs rognent sur tout, y

compris sur la fiabilité de leur système.   Le consommateur est bien en droit de réclamer aujourd'hui la

garantie d'une fiabilité absolue. Celle-ci doit devenir un motif d'achat, donc un argument de vente impératif.


Terminologie générale de la sûreté de fonctionnement   Un système est un ensemble de composants en interaction

destine a accomplir une tâche donnée. C'est le cas par exemple des systèmes de production, systèmes de transport, systèmes informatiques, etc...

  La sureté de fonctionnement (SdF, en anglais dependability) d'un système est la propriété qui permet a ses utilisateurs de placer une confiance justifiée dans le service qu'il leur délivre. On dit aussi que la SdF est la science des défaillances.

  Un système subit une défaillance quand il ne peut plus délivrer le service attendu. La panne est l‘état du système résultant d'une défaillance.


  La sûreté de fonctionnement comprend 5 composantes :   la fiabilité,   la disponibilité,   la maintenabilite,   la sécurité-innocuite   la sécurité-confidentialite


  La fiabilite (reliability) est la caractéristique du système exprimée par la probabilité qu'il délivre le service attendu dans des conditions données et pendant une durée déterminée. La fiabilité exprime l'aptitude a la continuité du service.

  La disponibilité (availability) est exprimée par la probabilité que le système délivre le service attendu dans des conditions données et a un instant donne. La disponibilité caractérise donc l'aptitude du système a fonctionner quand on a besoin de lui.


  La maintenabilite (maintainability) caractérise l'aptitude du système a être réparé quand il est defaillant, ou a évoluer.

  La sécurité-innocuite (safety) caractérise l'aptitude du système a ne pas encourir de défaillances catastrophiques.

  La sécurité-confidentialite (security) caractérisé l'aptitude du système a se prémunir contre les accès ou manipulations non autorisées (virus, attaques,...).



Maintenance & évolution du logiciel

  La maintenance des systèmes est de deux types :   La maintenance corrective ou réparation remet en

fonctionnement un système après sa défaillance.   La maintenance préventive est effectuée alors que le système

fonctionne et a pour but de retarder l'occurrence des défaillances futures.


Qualité Logicielimad-hafidi.com/Cours/Genie/QL.pdf · Qualité Logiciel Pr Hafidi Imad...

Documents

Transcript of Qualité Logicielimad-hafidi.com/Cours/Genie/QL.pdf · Qualité Logiciel Pr Hafidi Imad...