Certification du logiciel

(1)

Certification du logiciel

Julien Narboux

Master 2

(2)

Plan du cours

1 Introduction

(3)

Plan de la partie:

1 Introduction

(4)

Objectifs du cours

Découvrir les outils et méthodes pour produire des logiciels plus sûrs.

1 Les tests

2 Le typage

3 L’analyse statique de programmes.

4 La preuve de programmes.

(5)

1 Introduction

Julien Narboux (Universit´e de Strasbourg) Certification du logiciel 5 / 230

(6)

Pourquoi s’int´ eresser ` a la correction des logiciels ?

1 Les logiciels sont partout.

2 Les logiciels sont de plus en plus complexes.

3 Les logiciels sont de plus en plus utilis´es pour des syst`emes critiques.

4 Les logiciels contiennent de plus en plus de bugs.

(7)

Comment combattre le pire ennemi de l’informaticien ? le bug !

(8)

Logiciels critiques

Aéronautique Automobile Ferroviaire Nucléaire Santé . . .

(9)

Exemple ”Mariner I”

”July 28, 1962 – Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket’s trajectory.”

(un point `a la place d’une virgule dans une boucle FORTRAN)

(10)

Exemple ”Therac 25”

1985-1987 : Therac-25 machine de radiothérapie. Une condition de concurrence apparaissait quand l’operateur changeait les paramètres trop rapidement. Conséquence: 5 morts.

(11)

Exemple ”Patriot”

1991 : L’anti-missile Patriot ´echoua dans la poursuite d’un missile ”Scud”

`

a cause d’un cumul d’erreurs d’arrondi. Cons´equence: 28 morts.

(12)

Exemple ”Ariane Vol 501”

”Because of the different flight path, a data conversion from a 64-bit floating point to 16-bit signed integer value caused a hardware exception (more specifically, an arithmetic overflow, as the floating point number had a value too large to be

represented by a 16-bit signed integer). Efficiency considerations had led to the disabling of the software handler (in Ada code) for this error trap, although other conversions of comparable variables in the code remained protected. This caused a cascade of problems, culminating in destruction of the entire flight.”

1

(13)

Exemple ”Mars Climate Orbiter”

”The ’root cause’ of the loss of the spacecraft was the failed translation of English units into metric units in a segment of ground-based, navigation-related mission software.”

2

2http://mars.jpl.nasa.gov/msp98/news/mco991110.html

(14)

In 2005, Toyota voluntarily recalled 160 000 of its 2004 and some early 2005 model year Prius hybrids because of a software problem.

May 2008, Chrysler recalled 24 535 of its 2006 Jeep Commanders because of a problem in the automatic-transmission software.

June 2008, Volkswagen recalled about 4000 of its 2008 Passats and Passat Wagons and about 2500 Tiguans for a problem in the engine-control-module software that could cause an unexpected increase in engine revolutions per minute when the air-conditioning is turned on.

November 2008, GM recalled 12 662 of its 2009 Cadillac CTS vehicles for a software problem within the passenger-sensing system that could disable the front passenger air bag when it should be enabled or enable it when it should be disabled.

In 2010, a total of 133,000 Toyota Prius vehicles in the U.S. and 52,000 in Europe are to receive the same software update.

(15)

”And unlike most commercial aircraft, which have strict firewalls between critical avionic systems and the in-flight entertainment systems, there is more commingling of information between the electronic systems used to operate the car and those for

entertaining the driver and passengers. According to a Wharton Business School article entitled ”Car Trouble: Should We Recall the U.S. Auto Industry?,” a few years ago, some Mercedes drivers found that their seats moved if they pushed a certain button; the problem was that the button was supposed to operate the navigation system.”

3

3http:

//spectrum.ieee.org/transportation/systems/this-car-runs-on-code

(16)

Premi` eres id´ ees

Tester quelques exemples On ´ecrit une fonction:

Programme + Propri´et´e → Vrai/Faux Tester toutes les branches possibles .

Probl`emes:

On ne peut pas tester tous les cas.

Les Heisenbug: L’Heisenbug est un bug qui disparaˆıt quand on essaie de l’´etudier. Par exemple une condition de concurrence (race

condition) quand le programme est en mode d´ebuggage peut disparaˆıtre.

(17)

Premi` eres id´ ees

Tester quelques exemples On ´ecrit une fonction:

Programme + Propri´et´e → Vrai/Faux Tester toutes les branches possibles .

Probl`emes:

On ne peut pas tester tous les cas.

Les Heisenbug: L’Heisenbug est un bug qui disparaˆıt quand on essaie de l’´etudier. Par exemple une condition de concurrence (race

condition) quand le programme est en mode d´ebuggage peut disparaˆıtre.

(18)

Solution ? un logiciel pour trouver tous les bugs ?

Probl`eme de l’arrˆet

Il n’existe pas de programme permettant de d´ecider si un programme termine ou pas.

(19)

Premi` ere approche

On réduit la classe des propriétés que l’on va vérifier.

Exemple

pas de probl`eme de type: langages fortement typ´es (Ocaml, Haskell, Scala, . . . )

Exemple

pas de ”plantage”: division par z´ero, ou acc`es en dehors des tableaux (Airbus A380)

(20)

Deuxi` eme solution (compl´ ementaire)

On fait la preuve que le programme vérifie ses spécifications. Un raisonnement fini pour traiter une infinité de cas.

(21)

Ce que l’on souhaite v´ erifier

1 Safety (le programme neplante pas): tous les dereferencement de pointeur sont valides, pas d’overflow arithmétiques, pas de division par zéro, pas d’accés en dehors des tableaux . . .

2 Terminaison

3 Comportement: le programme fait ce qu’il est cens´e faire.

(22)

Quelques outils industriels

Astr´ee Polyspace Coverity FramaC

(23)

Qu’est-ce qu’une preuve ?

un argument convainquant

une suite de d´eductions `a partir des axiomes un algorithme

(24)

Oui mais...

Il peut être difficile de se convaincre qu’une preuve est correcte : le nombres de théorèmes

pr´esence de calculs

trop de d´etails techniques, trop de cas la taille de la preuve

(25)

Oui mais...

(26)

Oui mais...

trop de d´etails techniques, trop de cas

la taille de la preuve

(27)

Oui mais...

(28)

Par définition vérifier qu’une preuve est correcte est un problème décidable.

(29)

On peut donc construire des assistants de preuve.

Exemples Coq Isabelle HOL PVS B

(30)

Deux approaches pour prouver des programmes:

Prouver le programme original (C ou Java) à l’aide d’un système qui génère des obligations de preuve que l’on prouve ensuite avec un assistant de preuve et/ou des démonstrateurs automatiques.

Exemple: Frama-C

Définir et prouver le programme dans le langage de l’outil de preuve et ensuite générer le programme final automatiquement.

Exemple: la m´ethode B, l’extraction de programmes en Coq

(31)

Quid du binaire

Mais si on prouve le code source, le compilateur pourrait encore avoir introduit un bug:

prouver le binaire, prouver le compilateur, . . .

(32)

Part I

Tests

(33)

Plan de la partie: Tests

2 Introduction

3 Tests unitaires Pr´esentation Objet factices

4 S´election des tests En boˆıte noire

Analyse partitionnelle Test aux limites Tests combinatoires Génération aléatoire

Génération à partir d’un modèle

En boˆıte blanche

Test des tests par mutation

(34)

Comparaison des m´ ethodes de v´ erification

Tests: Mise en oeuvre relativementfacile.

Nécessaire: on trouve des erreurs dans le système complet: spécification et implantation.

“Beware of bugs in the above code; I have only proved it correct, not tried it.” Donald Knuth Pas suffisant: exhaustivit´e impossible

Preuves: Exhaustif.

Difficile à mettre en oeuvre, nécessite du personnel formé.

Analyse statique par interpr´etation abstraite:

Exhaustif pour certaines classes de probl`emes (safety).

N’est pas applicable `a tous les programmes.

(35)

V´erification et validation :

environ 30% du d´eveloppement d’un logiciel standard plus de 50% du d´eveloppement d’un logiciel critique Validation ?

Les tests permettent de d´etecter des erreurs, pas de v´erifier qu’un programme est correct.

“Testing can only reveal the presence of errors but never their absence.” - E. W. Dijkstra

(36)

Motivations

1 Trouver des bugs

plus les bugs sont trouvés tôts moins ils coûtent cher par les développeurs

2 Validation: convaincre un tiers de la qualit´e du code.

client hierarchie

organisme de certification

→ Probl`ematique de l’´evaluation d’un jeu de tests.

(37)

Bibliographie

Myers G.J., The Art of Software Testing, John Wiley Ed, New York, 1979

Introduction au test logiciel, Philippe Herrmann:

http://sebastien.bardin.free.fr/poly-herrmann.pdf Le cours de S´ebastien Bardin:

http://sebastien.bardin.free.fr/cours1.pdf

(38)

Exemple introductif

Exercice

1 Ecrire un programme qui prend en entrée trois intreprésentant les longueurs des trois côtés d’un triangle et indique le type de triangle:

scal`ene isoscele equilateral

2 Ecrire les cas de test.

(39)

Tests statiques/dynamiques

statique sans exécuter le programme sur des données réelles: analyse symbolique ou relecture de code.

dynamique ex´ecuter le programme sur des exemples.

(40)

Tests dynamiques

code écrit à la main (tests unitaires) code généré automatiquement action manuelle

action automatis´ee

(41)

Tests: ce qui est test´ e

Test de conformité Test de robustesse Test de sécurité Test de performance

(42)

Cycle en V

(43)

Tests: classement par niveau de d´ etail

Tests unitaires Test des unit´es de programme de fa¸con isol´ee:

uniquement correction fonctionnelle.

Tests d’int´egration Test de la composition des modules via leur interface:

principalement correction fonctionnelle.

Tests de validation Test du produit fini par rapport au cahier des charges:

conformité, robustesse, sécurité, performance.

Recette Test du produit fini par le client.

(44)

Tests d’int´ egration vs tests unitaires

Interface Graphique

Tests d⁰integration

z }| {

Classes Metier

| {z }

Tests unitaires

Acces

Donnees Donnees

(45)

Tests: boˆıte noire/vs boˆıte blanche

Boˆıte noire: Test de l’extérieur vis à vis des spécifications (formelles ou informelles) sans connaissance de l’implantation.

Technique applicable `a tous les niveaux du cycle en V.

Ecriture des tests possible avant le code.

Boˆıte blanche: Tests en ayant connaissance du code.

Si on change le code il faut mettre `a jour les tests.

(46)

Tests

(47)

Processus de test

Les tests peuvent ˆetre ´ecrits:

avant, (d´eveloppement guid´e par le test, test driven development) pendant ou

apr`es le code.

Les tests peuvent être réalisés:

par le développeur (tests unitaires) par une équipe dédiée

(48)

Oracle

Le test est réalisé vis à vis d’un comportement attendu. Celui-ci peut être défini par:

des sp´ecifications une norme

des contrats (préconditions, postconditions et invariants) des versions précédentes

(49)

Plan de la partie: Tests

2 Introduction

En boˆıte blanche

Test des tests par mutation

(50)

Tests unitaires

Principe:

Test des unités de programme de fa¸con isolée, à l’ échelle de la classe ou de la fonction. Pour chaque classe on crée une classe de test avec au moins une méthode de test par méthode.

En pratique:

1 Des annotations pour pr´eciser quelles sont les fonctions de test et d’initialisation des tests (quand le language le permet).

2 Des assertionspour tester des propriétés: un prédicat + un message d’erreur.

3 Des lanceurs de tests: une boucle un peu ´evolu´ee.

(51)

Exemples

Java junit .Net nunit, xunit haskell hunit

ocaml ounit . . .^a

ahttp://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

(52)

Exemple en Java: Junit

Annotations

@Test d´esigne les m´ethodes de test

@Before ex´ecut´ee avant chaque test (fixture)

@After exécutée après chaque test

@BeforeClass ex´ecut´ee avant tous les tests de la classe

@AfterClass exécutée après tous les tests de la classe

@Ignore d´esactive un test

@Test (expected = Exception.class) permet de sp´ecifier qu’un teste doit lever une exception

@Test(timeout=100) permet de limiter le temps de calcul

(53)

Assertions

Les assertions permettent d’exprimer quand le test passe ou ´echoue.

assertsEquals([String message], expected, actual) assertSame([String], expected, actual)

assertNotNull([message], object) fail(String)

. . .

(54)

Exemple

p u b l i c c l a s s J u n i t T e s t 1 {

p r i v a t e C o l l e c t i o n<S t r i n g> c o l l e c t i o n ;

@ B e f o r e C l a s s

p u b l i c s t a t i c v o i d a v a n t C l a s s ( ) { S y s t e m . o u t . p r i n t l n ( ” @ B e f o r e C l a s s ” ) ; }

@ A f t e r C l a s s

p u b l i c s t a t i c v o i d a p r e s C l a s s e ( ) { S y s t e m . o u t . p r i n t l n ( ” @ A f t e r C l a s s ” ) ; }

@ B e f o r e

p u b l i c v o i d s e t U p ( ) {

c o l l e c t i o n =new A r r a y L i s t<S t r i n g>( ) ; c o l l e c t i o n . add ( ” Toto ” ) ;

S y s t e m . o u t . p r i n t l n ( ” @ B e f o r e ” ) ; }

@ A f t e r

p u b l i c v o i d t ea r Do wn ( ) { c o l l e c t i o n . c l e a r ( ) ;

S y s t e m . o u t . p r i n t l n ( ” @ A f t e r ” ) ; }

@Test

p u b l i c v o i d t e s t C o l l e c t i o n I n i t i a l e ( ) { a s s e r t T r u e ( c o l l e c t i o n . s i z e ( ) = = 1 ) ;

S y s t e m . o u t . p r i n t l n ( ” @Test− c o l l e c t i o n i n i t i a l e ” ) ; }

@Test

p u b l i c v o i d t e s t A j o u t U n I t e m ( ) { c o l l e c t i o n . add ( ” T i t i ” ) ;

a s s e r t E q u a l s ( 2 , c o l l e c t i o n . s i z e ( ) ) ;

S y s t e m . o u t . p r i n t l n ( ” @Test− a j o u t d ’ un i t e m ” ) ; }

}

(55)

(56)

@BeforeClass

@Before

@Test - collection initiale

@After

@Before

@Test - ajout d’un item

@After

@AfterClass

(57)

Tests param´ etr´ es

Junit permet de tester une m´ethode sur une collection de donn´ees.

(58)

Probl`emes

Attributs invisibles (privés sans accesseur) Méthodes privées

Solutions

Créer une classe qui hérite de la classe testée avec des accesseurs Utiliser la réflexion pour rendre les méthodes publiques

Remarque

Certains auteurs pensent qu’il vaut mieux ne pas tester les m´ethodes priv´ees.

(59)

Les objets factices

Les Mocks sont des objets facticesqui imitent le comportement d’objets réels. LesMocks ne définissent la sortie que de certaines méthodes et pour une quantité limitée d’entrées.

Ils sont n´ecessaires quand il faut remplacer:

un comportement non déterministe (une méthode qui donne l’heure pour tester un réveil par exemple)

un événement rare (une déconnexion réseau par exemple) une classe qui n’est pas encore implantée

une classe qui produit des temps de calcul trop longs

une classe qui utilise des ressources externes que l’on ne souhaite pas tester⁴ (accès à une BDD, connexion réseau, envoie de mails, . . . ) Les objets factices peuvent être écrits:

`

a la main ou

automatiquement en utilisant la reflexivit´e (EasyMock, Mockito, . . . )

4C¸ a sera l’objet des tests d’int´egration

(60)

Doublures

On peut distinguer plusieurs types de doublures:

bouchons Une doublure qui sert simplement `a remplacer un autre code pour que ¸c`a compile.

mock Une doublure qui v´erifie l’interaction avec l’objet.

espions Une doublure qui enregistre les traitements qui lui sont fait.

(61)

Mockito

i m p o r t s t a t i c o r g . m o c k i t o . M o c k i t o .∗;

L i s t m o c k e d L i s t = mock ( L i s t .c l a s s) ;

when ( m o c k e d L i s t . g e t ( 0 ) ) . t h e n R e t u r n ( ” t o t o ” ) ;

when ( m o c k e d L i s t . g e t ( 1 ) ) . t h e n T h r o w (new R u n t i m e E x c e p t i o n ( ) ) ; // f o l l o w i n g p r i n t s ” t o t o ”

S y s t e m . o u t . p r i n t l n ( m o c k e d L i s t . g e t ( 0 ) ) ; // f o l l o w i n g t h r o w s r u n t i m e e x c e p t i o n S y s t e m . o u t . p r i n t l n ( m o c k e d L i s t . g e t ( 1 ) ) ;

// f o l l o w i n g p r i n t s ” n u l l ” b e c a u s e g e t ( 9 9 9 ) was n o t s t u b b e d S y s t e m . o u t . p r i n t l n ( m o c k e d L i s t . g e t ( 9 9 9 ) ) ;

// a r g u m e n t m a t c h e r s

when ( m o c k e d L i s t . g e t ( a n y I n t ( ) ) ) . t h e n R e t u r n ( ” e l e m e n t ” ) ;

(62)

Mockito: espionnage

m o c k e d L i s t . add ( ” o n e ” ) ; m o c k e d L i s t . c l e a r ( ) ; // v e r i f i c a t i o n

v e r i f y ( m o c k e d L i s t ) . add ( ” o n e ” ) ; v e r i f y ( m o c k e d L i s t ) . c l e a r ( ) ;

v e r i f y ( m o c k e d L i s t , n e v e r ( ) ) . add ( ” n e v e r h a p p e n e d ” ) ;

(63)

Best practice tests unitaires

Ecrire un test par bug trouv´e (tests de r´egression).

Les tests ne doivent pas faire d’hypoth`eses sur le reste du monde.

Les tests ne doivent comporter qu’une seule assertion (sinon d´ecouper en plusieurs tests).

Ne pas m´elanger le code de test avec le reste du code.

Les tests doivent ˆetre ind´ependants les uns des autres:

ne pas appeler un test dans un autre

les tests doivent pouvoir être appelés dans n’importe quel ordre Attention à ne pas mettre trop de code dans les @Before @After pour garder les tests lisibles. Seules les données utilisées danstous les tests de la classe doivent être initialisés dans la méthode @Before.

(64)

Plan de la partie: Tests

2 Introduction

En boˆıte blanche

(65)

Analyse partitionnelle

Id´ee:

Partitionner les domaines d’entrée en un nombre fini de classes d’équivalences correspondant à des comportements ”identiques” du programme.

R´ealiser un test par classe d’´equivalence.

Exemple: valeur absolue abs : int → int 2³² cas

trois classes “naturelles”: x <0,x = 0,x >0

(66)

Test aux limites

Après une analyse partitionnelle, introduire des tests se trouvant aux frontièresdes classes d’équivalence.

fichier vide, fichier de plus de 4Go, fichier sans droit d’écriture ensemble vide, ensemble à un élément, ensemble très gros chaˆıne vide, chaˆıne comportant des caractères spéciaux entier maximum/minimum, zéro

float proche de z´ero, tr`es grand

premier élément, dernier élément d’un tableau . . .

(67)

Tests combinatoires

S´election d’un petit nombre de configurations de test parmi un ensemble de configurations dont la combinatoire explose.

Pour les variables ayant peu de valeurs possibles.

Utile par exemple pour les tests d’int´egration ou de configurations.

Contre-exemple Addition de deuxint:

2³²∗2³²= 2⁶⁴ cas possibles.

Exemple

OS Connexion CPU Java

Linux Ethernet PowerPC Java 1.4

Windows Wifi ARM Java 1.5

MacOS Bluetooth Intel Java 1.6

3⁴ = 81 cas possibles.

(68)

Approche pair-wise

Id´ee sous-jacente

la majorité des erreurs sont détectées par des combinaisons de 2 valeurs de variable.

Un seul test couvre plusieurs paires

Le nombres de paires est bien plus petit que le nombre de combinaisons.

Exemple

OS Connexion CPU Java

Linux Ethernet PowerPC 1.4

Linux Wifi ARM 1.5

Linux Bluetooth Intel 1.6 Windows Ethernet Intel 1.5 Windows Wifi PowerPC 1.6 Windows Bluetooth ARM 1.4

MacOS Ethernet ARM 1.6

MacOS Wifi Intel 1.4

MacOS Bluetooth PowerPC 1.5

9 cas de test.

G´en´eration

Le problème de la génération d’un ensemble de données de tests de cardinal minimal est NP complet. Mais des outils existent:

(69)

N-wise / partionnelle

Lorsque l’on a plusieurs critères l’approchepairwise peut être combinée à l’approche partionnelle.

Exemple

Une fonction qui prend en entrée unintreprésentant un numéro de mois et unint représentant le numéro de jour et renvoie le jour suivant.

partition des entr´ees valides et invalides : m≤0, 1≤m≤12 m>12.

j ≤0, 1≤j ≤28,j = 29, j = 30, j = 31, j >31 . mois de 28, 30 ou 31 jours.

(70)

G´ en´ eration al´ eatoire

n´ecessite un oracle qui fonctionne dans tous les cas (sp´ecification) niveau de couverture souvent faible

difficulté de tester des cas particuliers (ex: trois points alignés) mais c’est facile à mettre en œuvre

QuickCheck (Haskell puis port´e `a d’autres langages)

La bibliothèque fournit des générateurs aléatoires pour les types de base: int, string, float, list, array, . . .

On définit des générateurs.

On teste des prédicats capturant des propriétés de la fonction.

Par exemple:

encrypt(decrypt(x))= x reverse(reverse(l))=l

(71)

Exemple de g´ en´ erateur en Java

Generator<T> est une interface avec une seule m´ethode:

T next() Exemple

c l a s s Name{

p r i v a t e f i n a l S t r i n g f i r s t ; p r i v a t e f i n a l S t r i n g l a s t ;

p u b l i c Name ( S t r i n g f i r s t , S t r i n g l a s t ) { s u p e r( ) ;

t h i s. f i r s t = f i r s t ; t h i s. l a s t = l a s t ; }

p u b l i c S t r i n g g e t L a s t ( ) { r e t u r n l a s t ; } p u b l i c S t r i n g g e t F i r s t ( ) { r e t u r n f i r s t ; } }

c l a s s N a m e G e n e r a t o r i m p l e m e n t s n e t . j a v a . q u i c k c h e c k . G e n e r a t o r<Name>{

G e n e r a t o r<S t r i n g> f i r s t = P r i m i t i v e G e n e r a t o r s . s t r i n g s ( ) ; G e n e r a t o r<S t r i n g>l a s t = P r i m i t i v e G e n e r a t o r s . s t r i n g s ( ) ;

@ O v e r r i d e p u b l i c Name n e x t ( ) {

r e t u r n newName ( f i r s t . n e x t ( ) , l a s t . n e x t ( ) ) ; }

}

Source:http:

//theyougen.blogspot.fr/2010/11/alternative-test-approach-quickcheck.html

(72)

G´ en´ eration ` a partir d’un mod` ele

Les exigences sont formalis´ees sous forme d’un mod`ele.

Le modèle est une représentation abstraite des comportements d’un système.

Le mod`ele est plus ou moins formel: cas d’utilisation, diagrammes d’activit´es, automates, . . . .

(73)

M´ ethodes de test de couverture en boˆıte blanche

Couverture structurelle

par couverture du graphe de flot de contrˆole (CFG) ou par couverture du graphe de flot de donn´ees (DFG) Test de couverture par mutation

S´election des cas de tests en changeant le programme.

(74)

Quelques crit`eres de couverture:

Tous les noeuds le plus faible Tous les arcs / d´ecisions (D)

Toutes les conditions simples (C) peut ne pas couvrir toutes les d´ecisions Toutes les conditions et toutes les d´ecisions (DC)

Toutes les combinaisons de conditions (MC) explosion du nombre de cas, revient `a tester exhaustivement dans le domaine des

bool´eens.

Tous les chemins de longeur k

Tous les chemins le plus fort, impossible `a r´ealiser

(75)

Notion de hi´ erarchie de crit` eres

On dit qu’un crit`ere C1 est plus fort qu’un crit`ere C2 si:

pour tout programme P et pour toute suite de tests TS, si TS couvre C1 pour P alors TS couvre C2 pour P.

(76)

Probl` eme de l’accessibilit´ e

Attention tous les chemins ne sont pas atteignables.

Toutes les instructions ne sont pas forcement atteignables (code mort, code de d´ebuggage).

Savoir si un chemin est atteignable est ind´ecidable.

Le taux de couverture est donc r´eduit.

(77)

Exercice

Limite du crit`ere instruction

Trouver un programme pour lequel le crit`ere instruction n’est pas suffisant.

Solution

if x != 0 then x := 1; y := a/x

(78)

Exercice

Limite du crit`ere instruction

Trouver un programme pour lequel le crit`ere instruction n’est pas suffisant.

Solution

if x != 0 then x := 1;

y := a/x

(79)

Exemple

if ((A && B) || C) then 1 else if D then 3 else 5

Pour couvrir:

D (A && B) || C=true, (A && B) || C=false D=true, D=false

C A=true, A=false, B=true, B=false, C=true, C=false D=true, D=false

MC A=true, B=true, C=true A=true, B=true, C=false A=true, B=false, C=true A=true, B=false, C=false A=false, B=true, C=true A=false, B=true, C=false A=false, B=false, C=true A=false, B=false, C=false D=true, D=false

(80)

Exemple

Pour couvrir:

(81)

Exemple

Pour couvrir:

(82)

Exemple

Pour couvrir:

MC A=true, B=true, C=true A=true, B=true, C=false A=true, B=false, C=true A=true, B=false, C=false A=false, B=true, C=true A=false, B=true, C=false A=false, B=false, C=true

(83)

Probl` eme

Mais il existe dans le code d’un avion une d´ecision avec 76 conditions (un if avec un expression bool´eennes comportant 76 atomes)!

Bv or (Ev /= El) or Bv2 or Bv3 or Bv4 or Bv5 or Bv6 or Bv7 or Bv8 or Bv9 or Bv10 or Bv11 or Bv12 or Bv13 or Bv14 or Bv15 or Bv16 or

Bv17 or Bv18 or Bv19 or Bv20 or Bv21 or Bv22 or Bv23 or Bv24 or Bv25 or Bv26 or Bv27 or Bv28 or Bv29 or Bv30 or Bv31 or Bv32 or Bv33 or Bv34 or Bv35 or Bv36 or Bv37 or Bv38 or Bv39 or Bv40 or Bv41 or Bv42 or Bv43 or Bv44 or Bv45 or Bv46 or Bv47 or Bv48 or Bv49 or Bv50 or Bv51 or (Ev2 = El2) or

((Ev3 = El2) and (Sav /= Sac)) or Bv52 or Bv53 or Bv54 or Bv55 or Bv56 or Bv57 or Bv58 or Bv59 or Bv60 or Bv61 or Bv62 or Bv63 or Bv64 or Bv65 or Ev4 /= El3 or Ev5 = El4 or Ev6 = El4 or Ev7 = El4 or Ev8 = El4 or Ev9 = El4 or Ev10 = El4

Source:http:

//www.tc.faa.gov/its/worldpac/techrpt/ar01-18.pdf

(84)

DO-178B

La norme DO-178B est utilis´ee en a´eronautique.

Level A catastrophic failure condition “prevent continued safe flight and landing“

Level B hazardous / severe-major failure condition “serious or potentially fatal injuries to a small number of . . . occupants”

Level C major failure condition “discomfort to occupants, possibly including injuries”

Level D minor failure condition “some inconvenience to occupants”

Level E no effect on aircraft operational capability or pilot workload

(85)

DO-178B : Couverture de code requise

Level A Level B Level C Level D

Statement Coverage X X X

Decision Coverage X X

Modified Condition / De- cision Coverage

X

(86)

MCDC

DO-178B/ED-12B:

Condition A Boolean expression containing no Boolean operators.

Decision A Boolean expression composed of conditions and zero or more Boolean operators. A decision without a Boolean operator is a condition. If a condition appears more than once in a decision, each occurrence is a distinct condition.

Decision Coverage Every point of entry and exit in the program has been invoked at least once and every decision in the program has taken on all possible outcomes at least once.

Modified Condition/Decision Coverage Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect that

(87)

Probl` eme d’interpr´ etation

There seems to be a variety of opinions about the definition of decision and coverage requirements.

if ((A or B) and (C or D)) then toto();

vs

E:= (A or B) and (C or D);

if (E) then toto();

The certification authorities recommend the ”literal” definition of decision for DC and MC/DC. The logic and control structure in Levels A and B software must be thoroughly exercised, whether it occurs at a branch point or not.

Voir: http://www.faa.gov/aircraft/air_cert/design_approvals/

air_software/cast/cast_papers/media/cast-10.pdf

(88)

Problème: cette définition n’est pas invariante vis à vis d’une transformation du programme:

A:= B or C;

E := A and D;

est ´equivalent logiquement `a E:= (B or C) and D;

mais les tests `a faire pour une couverture MC/DC ne sont pas les mˆemes ! http://shemesh.larc.nasa.gov/fm/papers/

Hayhurst-2001-tm210876-MCDC.pdf

(89)

Couverture structurelle vs tests en boˆıte blanche

Attention!

Il ne faut pas confondre lavérification d’une couverturedes tests avec la génération des tests.

Les tests construits à partir du code ne peuvent pas déceler que des spécifications n’ont pas été implantées.

La norme DO-178B exigent que les tests sont construits `a partir des exigences.

La méthode de couverture est utilisée uniquement pour vérifier que l’on a réalisé suffisamment de tests.

(90)

Outils

Outils pour ´evaluer les couvertures gcover:

http://www.ghs.com/products/safety_critical/gcover.html Cobertura: http://cobertura.github.io/cobertura/

. . .

Outils de g´en´eration de tests Microsoft PEX

http://research.microsoft.com/en-us/projects/pex/

Microsoft SAGE

(91)

G´ en´ eration de tests en deux mots

1 On choisit un chemin du CFG.

2 On génère un prédicat de chemin P par execution symbolique.

3 On trouve une solution de P.

Remarque

Le test `a besoin de la preuve !

(92)

Test des tests par mutation

Id´ee

On cr´ee des erreurs plausibles dans le programme afin de v´erifier qu’il y a assez de tests pour capturer ces erreurs.

Remarque

Les mutations doivent pr´eserver la syntaxe et le typage.

(93)

Exemples de mutations Effacer une instruction.

Remplacer une expression bool´eenne par trueoufalse.

Remplacer une op´eration arithm´etique par une autre, par exemple + par *.

Remplacer n+1 par n et vice-versa.

Remplacer une variable par une autre.

Remplacer une variable par une constante.

Remplacer une constante par une autre.

Remplacer un op´erateur bool´een par un autre: par exemple et par ou,

>par <.

(94)

Les mutants

En pratique assez peu utilis´e.

Implique facilement d’autres crit`eres de couverture.

(95)

Part II

Rappels concernant Coq

(96)

Plan de la partie: Rappels concernant Coq

5 S´equents

6 Curryfication

7 Structures de donn´ees inductives Sans r´ecursion

Avec r´ecursion

8 Pr´edicats inductifs

(97)

Notion de s´ equent

Les systèmes formels modélisant des logiques utilisent souvent un langage basé sur une structure appeléeséquent. Il s’agit d’une paire (Γ,F) composée

d’un multi-ensemble de formules Γ (l’ordre ne compte pas, r´ep´etitions possibles) et

d’une formuleF.

Traditionnellement on note cette paire:

Γ`F

Intuitivement, un séquent permet de représenter le fait que des hypothèses Γ, on peut déduireF.

(98)

Notation Coq

En Coq au lieu d’´ecrire{A₁,A₂, . . . ,A_n} `P on ´ecrit:

H_1 : A_1 H_2 : A_2 H_n : A_n

___________________________________ (1/1) P

(99)

Plan de la partie: Rappels concernant Coq

5 S´equents

6 Curryfication

Avec r´ecursion

(100)

5 S´equents

6 Curryfication

Avec r´ecursion

(101)

Exercice

Montrer que la formule suivante est valide / prouvable : (A→(B→C))↔(A∧B →C) Remarque:

→ est associatif `a droite, on aurait pu ´ecrire:

(A→B→C)↔(A∧B →C)

(102)

Curryfication

D´efinition

La curryfication consiste `a transformer une fonction qui prend plusieurs arguments en une fonction qui prend un seul argument et qui retourne une fonction qui prend en arguments les arguments restants.

(103)

Exemple

En Caml Au lieu d’´ecrire:

# let f(x,y) = x + y;;

val f : int * int -> int = <fun>

On ´ecrit:

# let f x = fun y -> x + y;;

val f : int -> int -> int = <fun>

ou bien

# let f x y = x + y;;

val f : int -> int -> int = <fun>

(104)

Exemple

En Coq

On utilise la curryfication quand on écrit des fonctions ou des théorèmes.

On ´ecrira plutˆot:

Lemma toto: forall p q : R, p > 0 -> q > 0 -> p*q > 0.

que:

Lemma toto: forall p q : R, p > 0 /\ q > 0 -> p*q > 0.

(105)

Pourquoi ?

Pourquoi utiliser la curryfication ?

Afin de pouvoir r´ealiser desapplications partielles plus facilement.

(106)

Pourquoi ?

Pourquoi utiliser la curryfication ? Afin de pouvoir r´ealiser desapplications partielles plus facilement.

(107)

Plan de la partie: Rappels concernant Coq

5 S´equents

6 Curryfication

Avec r´ecursion

(108)

5 S´equents

6 Curryfication

Avec r´ecursion

(109)

Types inductifs

Coq est bas´e sur un formalisme appel´e Calcul des Constructions avec types Inductifs.

(110)

Les d´efinitions inductives consistent `a:

se donner des ´el´ements de base

et des règles pour construire de nouveaux éléments à partir d’éléments déjà connus.

(111)

Premier exemple (sans r´ ecursion)

Inductive mois : Set :=

| Janvier : mois

| Fevrier : mois

| Mars : mois

| Avril : mois

| Mai : mois

| Juin : mois

| Juillet : mois

| Aout : mois

| Septembre : mois

| Octobre : mois

| Novembre : mois

| Decembre : mois.

(112)

D´ efinition d’une fonction par filtrage

Definition mois_suivant (m:mois) : mois :=

match m with

| Janvier => Fevrier | Fevrier => Mars

| Mars => Avril | Avril => Mai

| Mai => Juin | Juin => Juillet

| Juillet => Aout | Aout => Septembre

| Septembre => Octobre | Octobre => Novembre

| Novembre => Decembre | Decembre => Janvier end.

(113)

Comment calculer avec cette fonction ?

Eval compute in (mois suivant Mars). Comment voir le code de cette fonction ? Print mois suivant.

(114)

Comment calculer avec cette fonction ? Eval compute in (mois suivant Mars).

Comment voir le code de cette fonction ? Print mois suivant.

(115)

Comment voir le code de cette fonction ?

Print mois suivant.

(116)

Comment voir le code de cette fonction ? Print mois suivant.

(117)

D´ efinition du mois pr´ ec´ edent

Definition mois_precedent (m:mois) : mois :=

match m with

| Janvier => Decembre | Fevrier => Janvier

| Mars => Fevrier | Avril => Mars

| Mai => Avril | Juin => Mai

| Juillet => Juin | Aout => Juillet

| Septembre => Aout | Octobre => Septembre

| Novembre => Octobre | Decembre => Novembre end.

(118)

Premier lemme

Eval compute in (mois_precedent (mois_suivant Janvier)).

Lemma mois_prec_suiv : forall m:mois, mois_precedent (mois_suivant m)=m. Proof.

intros m. elim m; simpl;

reflexivity. Qed.

(119)

Premier lemme

Eval compute in (mois_precedent (mois_suivant Janvier)).

Lemma mois_prec_suiv : forall m:mois, mois_precedent (mois_suivant m)=m.

Proof.

intros m.

elim m;

simpl;

reflexivity.

Qed.

(120)

elim

12 subgoals m : mois

______________________________________(1/12) mois_precedent (mois_suivant Janvier) = Janvier ______________________________________(2/12) mois_precedent (mois_suivant Fevrier) = Fevrier ______________________________________(3/12) mois_precedent (mois_suivant Mars) = Mars ...

______________________________________(12/12)

(121)

simpl

m : mois

______________________________________(1/12) mois_precedent (mois_suivant Janvier) = Janvier

→simpl→ m : mois

______________________________________

Janvier = Janvier

(122)

Raisonnement par cas

mois_ind : forall P : mois -> Prop,

P Janvier -> P Fevrier -> P Mars ->

P Avril -> P Mai -> P Juin ->

P Juillet -> P Aout -> P Septembre ->

P Octobre -> P Novembre -> P Decembre ->

forall m : mois, P m

(123)

Autre exemple:

Inductive bool : Type :=

| true : bool

| false : bool.

(124)

Apart´ e: l’´ egalit´ e en Coq

Check eq.

eq : forall A : Type, A -> A -> Prop Check refl_equal.

refl_equal : forall (A : Type) (x : A), x = x

C’est un type polymorphe (A:Type). Cela signifie que l’on a une relation d’égalité générique dont le premier argument est le type des

´

el´ements `a comparer.

L’égalité est une relation réflexive, symétrique et transitive. Ces propriétés sont utilisables grâce aux tactiquesreflexivity,

(125)

Egalit´ e de Leibniz

Check eq_ind.

eq_ind : forall (A : Type) (x : A) (P : A -> Prop), P x -> forall y : A, x = y -> P y

(126)

Les tactiques pour l’´ egalit´ e

rewrite rewrite in replace with replace with in subst

(127)

Apart´ e: Les sortes

Une sorte est un type pour les types.

Les propositionsA,B, etc. sont des types (ceux de leurs termes de preuves).

Ces types sont de type Prop.

On dit que A,B, etc. sont de sorteProp.

D’un autre cot´e, les bool´eens bool, les entiersnatsont des types dont le type est Set.

Set etProp sont de typeType.

Set là où l’on calcule Prop là où l’on raisonne

(128)

5 S´equents

6 Curryfication

Avec r´ecursion

(129)

Les entiers de Peano

1 L’élément appelé zéro et noté: 0, est un entier naturel.

2 Si n est un entier naturel alors son successeur not´e S(n) est un entier naturel.

Autre notation: P ::= O | S P

(130)

Coq vs OCaml

Coq

Inductive nat : Set :=

O : nat

| S : nat -> nat.

Caml

type nat = O

| S of nat

(131)

R´ ecursion/Induction sur nat

forall P : nat -> Prop, P 0 ->

(forall n : nat, P n -> P (S n)) ->

forall n : nat, P n

Quantification universelle sur une propri´et´eP: nat -> Prop Conclusion : forall n : nat, P n

2 cas:

1 cas de base

2 r´ecurrence

(132)

forall n : nat, P n

________________

P 0

n : nat IHn : P(n)

________________

P(S(n))

(133)

En Coq, un principe d’induction est automatiquement associé à chaque définition inductive.

(134)

Autre exemple: les listes

Coq

Inductive list : Set :=

Nil : list

| Cons : nat -> list -> list.

Caml

type list = Nil

| Cons of int*list

(135)

Principe d’induction

Check list ind.

list_ind

: forall P : list -> Prop, P Nil ->

(forall (n : nat) (l : list), P l -> P (Cons n l)) ->

forall l : list, P l

(136)

Les constructeurs sont distincts

Pour cela, on dispose d’une tactique sp´ecifique discrimate.

Lemma Mars_Fev : Mars<>Fevrier.

intro H; discriminate.

Qed.

Lemma zero_succ : forall n:nat, ~(S n)=O.

intros n H; discriminate H.

Qed.

(137)

Les constructeurs sont injectifs

Pour cela, on dispose d’une tactique sp´ecifique injection.

Lemma test_injection: forall x y, S x = S y -> x=y.

Proof.

intros.

injection H.

intro.

assumption.

Qed.

(138)

Listes polymorphes

Inductive list (A:Set) : Set :=

nil : list A

| cons : A -> list A -> list A.

nil etcons ont unparam`etre suppl´ementaire : A:Set.

Pour d´efinir la liste [1;2]on obtient:

cons nat 1 (cons nat 2 (nil nat )).

Coq autorise les arguments implicites:

Implicit Arguments nil.

Implicit Arguments cons.

On peut alors ´ecrire:

cons 1 (cons 2 nil ).

(139)

Plan de la partie: Rappels concernant Coq

5 S´equents

6 Curryfication

Avec r´ecursion

(140)

5 S´equents

6 Curryfication

Avec r´ecursion

(141)

Pr´ edicats inductifs

Un prédicat inductif est une propriété définie inductivement.

(142)

Exemple: parit´ e

D´efinition inductive

Inductive even : nat -> Prop :=

| even_O : even 0

| even_SS : forall m : nat, even m -> even (S (S m)).

D´efinition classique

Definition even’ n := exists k, n = 2*k.

(143)

Connection

Lemma l1 : forall n, even n -> even’ n.

(144)

D´ efinitions mutuellement r´ ecursives

Exemple

Inductive even : nat -> Prop :=

| even_O : even 0

| even_S : forall n, odd n -> even (S n) with odd : nat -> Prop :=

odd_S : forall n, even n -> odd (S n).

(145)

Exemple: ≤

D´efinition inductive

Inductive le (n : nat) : nat -> Prop :=

le_n : le n n

| le_S : forall m : nat, le n m -> le n (S m).

D´efinition classique

Definition le (n m: nat) : Prop := exists p:nat, m=n+p.

(146)

Raisonnement par cas

inversion

Lemma toto : forall n, le n 1 -> n = 1 \/ n =0.

Proof.

intros.

inversion H.

left.

reflexivity.

inversion H1.

right.

reflexivity.

Qed.

(147)

Deux cas:

2 subgoals n : nat H : le n 1 H0 : n = 1

______________________________________(1/2) 1 = 1 \/ 1 = 0

n : nat H : le n 1 m : nat H1 : le n 0 H0 : m = 0

______________________________________(2/2) n = 1 \/ n = 0