Vrification et Validation

Gnie Logiciel Master 1 II

Mihaela Sighireanu

Objectifs
I. Introduire la vrification et la validation (V&V) du logiciel et comprendre leurs diffrences. II.Dfinir le plan de V&V et ses composantes. III.Introduire le test de logiciel et ses composantes. IV.Dcrire le processus d'inspection de code et son rle dans le V&V. V.Dcrire l'analyse statique comme une technique de vrification.

I: Vrification versus Validation

Vrification:

Avons-nous construit le produit bien? i.e., le logiciel doit tre conforme sa spcification

Validation:

Avons-nous construit le bon produit? i.e., le logiciel doit faire ce que l'utilisateur a besoin

Processus de V&V

Le processus de V&V doit tre appliqu chaque tape du dveloppement. Ses objectifs:

Montrer que le systme n'a pas de dfauts.

Principalement pour les systmes critiques de niveau A. Ceci ne veut pas dire TOUS les dfauts mais plutt augmenter la confiance dans ce systme.

Dcouvrir des dfauts dans le systme.

S'assurer que le systme construit est utile et utilisable en pratique.

Types de V&V

Statique = inspection/analyse statique (i.e., sans excution) du systme pour dcouvrir des problmes ou prouver sa correction.

Sans excution, peut tre manuelle ou automatique

Dynamique = exprimenter et observer le comportement l'excution du systme.

Le systme est excut sur des donnes de test et son excution est observe (manuellement ou automatiquement).

V&V statiques et dynamiques

II: Plan de V&V

Le plan doit tre fait avec attention pour obtenir le plus de rsultats en test et inspection. Il doit tre fait trs tt pour commencer tt dans le processus de dveloppement. Doit tablir le rapport entre la part de la V&V statique et dynamique. Le plan de test doit indiquer les politiques suivre pour crire les tests plutt que les tests eux mme.

V&V et dveloppement en V

Structure d'un plan de test

Processus de test

Description des principales phases du test.

Traabilit des charges

Comment les charges ont t testes (tests en annexes).

Composants tests

Liste de composants tests (tests en annexes).

Agenda des tests

Agenda de tests, les ressources ncessaires et son intgration avec l'agenda du dveloppement.

Procdure d'enregistrement des tests Besoins logiciels et matriels Contraintes diverses

e.g., insuffisance en testeurs, etc.

III: Test du logiciel

Peut rvler la prsence d'erreurs et NON leur absence. La technique utilisable actuellement pour valider les charges non-fonctionnelles car elle est base sur une excution du logiciel.

L'analyse statique est au niveau de la recherche pour ce type de charges.

Doit tre fait en conjonction avec l'inspection statique pour amliorer la couverture du processus de V&V.

Types de tests

Test de dfaut

Utilis pour trouver les dfauts du systme. Un test de dfaut bon est celui qui dcouvre des dfauts dans le systme. Utilis pour montrer que le logiciel satisfait les charges. Un test de validation bon est celui qui montre que la charge sous test est bien implmente.

Test de validation

Test versus dpannage

Test de dfaut et dpannage (debug) sont deux processus diffrents:

Le test a comme objectif de rvler la prsence de dfauts dans un logiciel Le dpannage a comme objectif de localiser et rparer ces dfauts. Le dpannage formule des hypothses sur la cause du dfaut et utilise le test pour les valider.

Test dans ce cours

(a) Dcrire les principes du test de systme et test de composant. (b) Donner quelque stratgies pour crire des tests. (c) Dcrire une chane d'outils ncessaires pour l'automatisation du test.

voir plus en M2 LC+LP: Mthodes de test

III(a): Processus de test: classes

Test de composant

Concerne les briques de base du logiciel En gnral, fait pas le programmeur du composant ... sur la base de son exprience avec le programme. Concerne des groupes de composants intgrs pour crer un systme ou un sous-systme. En gnral, fait par une quipe indpendante sur la base de la spcification du systme.

Test de systme

Processus de test: tapes

Processus de test: politique

Le test exhaustif est impossible raliser... La politique de test dfinit l'approche utilise pour slectionner les tests crire et excuter. Exemple:

Tester toutes les fonctions accessibles par des menus. Tester la combinaison (en squence) des fonctions accessibles par les menus. Tester les fonctions avec entres utilisateur ayant des valeurs correctes et incorrectes.

Test de systme

Demande la composition de briques de base pour construire un sous-systme ou le systme. Peut concerner une distribution partielle ou une extension/incrment d'une distribution. Deux phases:

Test d'intgration: l'quipe a accs au code et le test est fait au fil de l'intgration des composantes. Test de distribution (release): l'quipe teste le systme complet comme une bote noire (i.e., sans regarder le code).

Test d'intgration

Compose les briques et teste pour dfauts provenant de l'interaction de ces briques. Pour faciliter la localisation des dfauts, l'intgration doit tre incrmentale. Approches:

Top-down: construire le squelette fonctionnel et puis le dcorer avec des briques.

Facilite la validation de l'architecture et la dmonstration prcoce d'un prototype.

Bottom-up: intgrer les briques par groupes et puis attaquer les fonctionnalits.

Facilite l'implmentation du test.

Du code supplmentaire peut tre ncessaire pour observer les rsultats des tests.

Test de distribution

But: accrotre la confiance des clients Test de validation, i.e., montre que le systme satisfait ses charges. Approche bote noire :

Tests bass sur la spcification uniquement, sans connaissance des choix d'implmentation. On teste les fonctionnalits, les performances et le comportement aux limites (stress) du logiciel.

Test en bote noire

Test en bote noire : politiques

Comment choisir les tests pour rvler des dfauts:

Choisir les entres qui gnrent toutes les messages d'erreur. Dfinir des entres qui provoquent le buffer overflow . Rpter les mmes entres ou sries d'entres plusieurs fois. Forcer la gnration des sorties invalides. Forcer des sorties trop courtes ou trop larges. Couvrir tous les squences d'utilisation avec des scnarios positifs et ngatifs. etc.

Exemple: LIBSYS

Tester le mcanisme de login avec un utilisateur correct et incorrect pour tester que les utilisateurs corrects sont accepts et ceux incorrects sont rejets. Tester la fonctionnalit de recherche avec 0, 1, 2 ou plusieurs sources slectionnes et avec des articles existants ou non-existants. Tester l'interface d'affichage des documents avec diffrents formats. Tester le mcanisme de tlchargement. Tester l'envoi d'email pour confirmer le tlchargement correct du document.

Test de performance

Teste les proprits non-fonctionnelles comme le temps de rponse et la fiabilit.

Tests avec une charge croissante de tches; Tests en prsence d'erreurs de transmission ou de temps de rponse trs grands; etc.

Tests aux limites

Excute le systme en utilisant des entres trs proches ou au del des limites prvues. Permet de tester le comportement du systme en cas de panne et ainsi s'assurer qu'il ne provoque pas des pertes de service ou de donnes inacceptables. Trs utiliss dans les systmes distribus (sites web) pour exhiber des comportements anormaux en cas de charge du rseau.

Test de composant

= test unitaire, processus qui teste les composantes en isolation. C'est un test de dfaut. La composante sous test (IUT - Implementation Under Test) peut tre:

Des fonctions ou des mthodes d'un objet; Des classes contenant champs et mthodes; Des classes composites avec des fonctionnalits accessibles par une classe abstraite ou interface.

Test de classe

Pour couvrir par test une classe

Tester toutes les mthodes de la classe; Tester les setters et getters de tous les champs; Tester les objets dans tous les tats possibles de la classe.

L'hritage rend cette tche plus difficile... Exemple: la bibliothque LASER (le voir sous Eclipse et JUnit)

Test d'interface

Trouver des dfauts cause d'erreurs dans les interfaces ou d'hypothses invalides sur les mthodes de l'interface.

Un composant appelle une mthode de l'interface d'un autre composant avec un ordre invers des paramtres ou avec des pointeurs null. La vitesse de rponse d'une mthode d'interface ne correspond pas au critres d'utilisation. L'activation d'un composant ne se fait pas dans le bon ordre et casse les hypothses de son utilisation. etc.

III(b): Ecriture des tests

Vocabulaire:

Casdetest(TC):uneexcutionduprogrammedclenchepardesdonnesde test(DT). Suitedetests(TS):unensembledeDT. Objectifdetest(TO):comportementtester. Systmesoustest(SUTouIUT):systme/composanttester.

But:crireunensembledetestsavecunbon couvrementdeV&V. Approches:

Enpartantdescharges:requirementbased Enpartantdesentres:partitiontesting

Test des charges

Un bon principe pour l'criture des charges est que les charges doivent tre testables. C'est un test de validation:

Pour chaque charge crire une TS. Une spcification complte des charges est trs utile ce niveau.

XP: spcifier les charges en crivant leurs tests.

Exemple: charges LIBSYS

L'utilisateur doit tre capable de rechercher un article dans un ensemble des DB ou dans un sous-ensemble qu'il a slectionn. Le systme doit fournir les programmes de visualisation pour tous les formats de documents. A chaque commande soit tre associ un numro unique que l'utilisateur doit pouvoir le copies dans son compte.

Exemple: tests LIBSYS

Tester des recherches pour des articles connus et absents avec un ensemble de 1 DB. Tester des recherches pour des articles connus et absents avec un ensemble de deux DB. Tester des recherches pour des articles connus et absents avec un ensemble de plus que deux DB. Tester la slection d'une DB et lancer la recherche pour des articles prsents et absents. Tester la slection de plusieurs DB et lancer la recherche pour des articles prsents et absents. etc.

Test des entres/sorties

Les entres et les rsultats peuvent tre partags en classes dont les lments concernent le mme comportement du IUT. Une telle classe = classe d'quivalence ou partition. Les TC doivent tre choisis dans chaque classe. On part de la spcification!

Exemple: search
Procedure Search (Key:ELEM, T: SEQ of ELEM) returns (Found: BOOLEAN, L: ELEM_INDEX) Pre-condition:

Classes d'quiv des entres:

Conformes la pre-cond Invalides pour la pre-cond e.g., T vide Key dans T

La squence T a au moins un lment

Post-condition:

L'lment est trouv la position L

(FOUND and T[L]=Key) (not FOUND and not (!i. 0<=i<=size(T) et T[i]=Key))

Key absent du T

Ou Key n'est pas dans le tableau

Exemple: search

Test structurel

= en bote blanche car les tests sont crits en partant de la structure du code. But: gnrer des DT qui excutent le programme pour couvrir toutes les instructions/branches/etc.

Principe du test structurel

Partir du graphe de contrle du programme:

Les noeuds sont des instructions ou des dcisions. Les arcs sont des changement de contrle.

Exemple: binary search

Dfinir des TC tels que des chemins indpendants sont excuts:

1 2 3 4 5 6 7 8 9 10 14 1 2 3 4 5 14 1 2 3 4 5 6 7 11 12 5 1 2 3 4 6 7 2 11 13 5 ...

Test structurel: politiques

Critres de couverture du code:

S: Toutes les instructions D: Toutes les arcs (dcisions) C: Toutes les conditions atomiques DC: Toutes les combinaisons D et C MC/DC: Toutes les combinaisons boolennes de C pour une D All-uses: tous les chemins entre la dfinition et l'utilisation d'une variables ...

III(c): Automatisation du test

Le test est trs coteux: jusqu' 50% du cot du logiciel. Des outils d'aide au test existent pour:

L'excution automatique des tests: suite Xunit Le calcul de la couverture La comparaison des rsultats

mais il faut souvent les adapter au logiciel dvelopp.

Un cadre automatique idal

IV: Inspections de code

Consiste examiner le code, sans l'excuter, soit par des humains (inspection) soit par un logiciel (analyse statique). Comme l'excution du code n'est pas requise, ces mthodes peuvent tre appliques avant d'avoir une implmentation (mme compilable). Appliquable tout autre reprsentation que du code (cahier de charges, design, suite de tests, etc.). Le but: dcouvrir des dfauts ou des anomalies. Le principe: plusieurs dfauts peuvent tre rvls par une lecture de code par des relecteurs qui ont une expertise du domaine/du langage de programmation/du formalisme de spcification/du design.

Inspection et test

L'inspection et le test sont des mthodes complmentaires; les deux peuvent tre utiliss pendant le processus V&V:

L'inspection vrifie la conformit une spcification mais pas une charge utilisateur. L'inspection ne peut pas vrifier des charges nonfonctionnelles comme les performances, l'ergonomie, etc. Le test demande une implmentation excutable.

Inspection de code

But: dtecter des dfaut mais pas le corriger! Dfauts recherchs (exemples) :

Erreurs logiques Mauvaise utilisation des variables, par exemple sans initialisation, avec une smantique diffrente... Non respect des standards de codage, etc.

Pr-conditions de l'inspection

Une spcification prcise doit tre disponible. Les inspecteurs doivent connatre des standards de codage de l'entreprise. Des exemples de code correct doivent tre disponibles. Une liste d'erreurs (checklist) inspecter doit tre prte. Avoir l'acceptation de la hirarchie pour le cot supplmentaire au stade prcoce du dveloppement. Ne pas utiliser l'occasion pour valuer le personnel.

Processus d'inspection
1. Planification (moment, participants, code) 2. Amorage (distribution des tches) 3. Prparation individuelle 4. Runion d'inspection 5. Conclusions et traitement des rsultats 6. Suivi des conclusions

Procdure d'inspection

Prsentation du systme inspecter aux Insp. Distribution du code et des documents aux Insp. Inspection avec enregistrement des dfauts trouvs. Modification du code pour corriger les dfauts. Re-inspection pour s'assurer des rsultats (non-obligatoire).

Participants

Auteur ou propritaire du code

Le programmeur responsable produire le code et les documents ncessaires son inspection. Il est aussi responsable corriger les dfauts trouvs lors de l'inspection.

Inspecteur

Trouve des dfaut, anomalies, omissions, inconsistances dans le code et/ou le document; peut mme attaquer des choix de conception.

Lecteur

Prsente le code aux inspecteurs lors de la runion d'Insp.

Secrtaire de sance

Enregistre les rsultats de la runion.

Mdiateur et/ou responsable d'inspection

Gre la runion et fait un rapport la hirarchie; amliore le processus d'inspection, les listes d'erreurs et les standards de codage.

Checklist

Liste des erreurs les plus communes surveiller pendant l'inspection. Les dfauts rpertoris dpendent du langage de programmation utilis. Plus le typage est faible, plus longue sera la liste. Exemples: initialisation mauvaise/absente des variables, nommage incorrect des constantes, terminaison de boucle, etc.

Exemples de checklist

Erreurs de donnes

Toutes les variables sont initialises avant utilisation? Toutes les constantes utilises sont nommes? La taille des tableaux est Size ou Size-1? Les chanes de caractres ont un caractre de fin? Les tampons peuvent dborder?

Erreurs de contrle

Les conditions des IF sont correctes? Toute boucle termine? Les expressions/instructions composes sont correctement parenthses? Tous les case sont traits dans un CASE? Le break est prsent?

Exemple de checklist

Erreurs d'entre/sortie

Tous les variables d'entre sont utilises? Toutes les variables de sortie sont initialises avant la sortie? Les valeurs d'entre non prvues peuvent corrompre le systme?

Erreurs d'interface

Tous les appels de mthode/fonction ont le nombre correct de paramtres? Les paramtres actuels et formels ont la mme smantique? Les paramtres sont dans le bon ordre?

Erreurs d'accs la mmoire

Le changement d'une structure modifie correctement les liens? La mmoire dynamique est bien alloue et initialise? Est-elle libre?

Gestion des exceptions

Toutes les conditions d'erreurs ont t gres (par des exceptions/messages)?

Performances de l'inspection

En vitesse:

500 instructions/heure en prsentation 125 instructions/heure/personne en prparation 90/125 instructions/heure en runion

Cot trs lev: 40h*homme pour 500 lignes Mais trs efficace et flexible: 80% des erreurs en moyenne pour tout type de code.

IV: Analyse statique

= (Semi-)Algorithmes d'analyse de code pour:

Dcouvrir des dfauts potentiels Synthtiser des proprits invariantes du code

N'impose pas que le code soit excutable et peut s'appliquer sur une partie du code. Base sur des heuristiques/approximations sres (mais pas exactes), ses rsultats doivent tre interprts car prsence des faux positifs . Une aide importante pour les inspecteurs, mais ne remplace pas compltement l'inspection de code. Techniques utilises dans les compilateurs. Moins efficace pour les langages structurs/fortement typs (par exemple Java).

Exemples d'analyses

Dfauts de donnes:

Dfauts I/0

Variables utilises avant initialisation Variables dclares mais pas utilises Variable non lue entre deux affectations Violation des bornes de reprsentation Division par 0

Double affichage sans affectation

Dfauts d'interface

Paramtres en mauvais nombre/type Rsultat de fonction non utilis Fonctions non utilises

Dfauts de gestion mmoire

Dfauts de contrle

Mmoire non initialis/libre Arithmtique de pointeurs complexe

Code mort Boucle infinie

Types d'analyse statique

Analyse du flot de contrle: code mort, boucles avec points d'entre/sortie complexes Analyse d'utilisation des donnes: utilisation de variables, conditions de test redondantes ou inutilises, etc. Analyse d'interfaces: conformit entre dclaration et utilisation de procdures. Analyse du flot d'information: calcule les relations entre les variables d'entre et de sortie. Analyse de chemins: identifie tous les chemins d'excution possibles et leurs instructions. Voir cours en M2

Exemples d'outils

Lint ou Splint pour C Jlint pour Java Py-lint pour Python etc.

Vrification et mthodes formelles

Les mthodes formelles d'analyse

Preuve Model-checking

peuvent tre utilises quand une spcification formelle du systme existe.

= Analyse statique exacte (quand c'est dcidable).

Pro mthodes formelles

Raliser une spcification formelle demande une analyse approfondie du systme ce qui peut rvler des dfauts, incohrences, etc. Aide l'inspection de code. Permet une gnration de code/test/certification automatise. Exemple: Cleanroom

Contre mthodes formelles

Demande des notations/maths qui ne sont pas comprises par les experts du domaine. Trs coteux (experts) pour produire une spcification formelle et encore plus pour prouver que l'implmentation satisfait la spc. On peut atteindre le mme niveau de confidence en utilisant des techniques de V&V moins coteuses.

Conclusion

Gnie logiciel

Travail important mais difficile car... il n'existe pas UNE solution gnrale... mais un ensemble de principes, techniques et outils... qui volue en permanence avec les nouveaux types de logiciel. Demande de la rigueur, de l'abstraction, des connaissances approfondies en programmation et maths, des facilits d'criture et expression.

Projet

Date limite du rendu: vendredi 28 mai 16h

au secrtariat de l'UFR (papier) ou par mail Cahier de charges: prendre en compte les commentaires faits au premier rendu. Spcification formelle: B ou ADT Design: diagrammes UML Plan de test avec suites de test d'acceptation, d'intgration, de fonctionnement.

Contenu du rendu: