Objectifs de vérification logiciels GEF492A 2014 Référence: [HvV §14.1] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie.

Présentation au sujet: "Objectifs de vérification logiciels GEF492A 2014 Référence: [HvV §14.1] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie."— Transcription de la présentation:

1 Objectifs de vérification logiciels GEF492A 2014 Référence: [HvV §14.1] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL24-ObjectifsVerificationValidation.pdf

2 Vérification vs validation Vérification: le processus d’évaluer un système ou une composante pour déterminer si le résultat d’une phase de développement donnée satisfait les conditions énoncées au début de la phase Est-ce qu’on a bien bâti le système? Validation: le processus d’évaluer un système ou une composante pour déterminer s’il/elle satisfait les besoins énoncés Est-ce qu’on a bâti le bon système? 2 Automne 2014GEF492 Glossaire IEEE

3 Erreurs, fautes et défaillances Erreurs: une erreur est une erreur humaine (faute typographique, mésinterprétation, omission, etc.) Fautes: une faute est la manifestation d’une erreur dans la représentation logicielle (besoins, conception ou code) Défaillances: une défaillance est une manifestation visible d’une faute observée dans un système en marche (un résultat incorrect, un comportement non désiré, un plantage du système) 3 Automne 2014GEF492

4 Fautes vs défaillances Considérer un programme qui produit le bon résultat de façon consistante il est certainement sans défaillances est-il sans fautes? Pourquoi ou pourquoi pas? Les fautes cachées sont les fautes restantes dans le code (produits) qui ne se manifestent pas (encore) comme des défaillances est-ce que les systèmes avec fautes cachées sont corrects? Que pensez-vous du Arianne 5 dans ce contexte? 4 Automne 2014GEF492

5 Le processus de vérification 5 Automne 2014GEF492 stratégie de test compar e USE Oracle USE sous-ensemble d’entrant entrant sous-ensemble d’entrant sortant attendu sortant actuel résultat du test USE – unité sous essai Y’a rien là, pas vrai?

6 Objectifs de vérification La sélection de la stratégie de test, et plus particulièrement le choix des sous-ensembles d’entrants est une étape critique et difficile dans le processus, et dépend des objectifs de vérification (ou de tests). L’objectif de vérification le plus apparent est la détection de fautes. Un second objectif peut être d’augmenter la confiance de par comportement sans faute. Un troisième objectif peut être la prévention de fautes. 6 Automne 2014GEF492

7 Détection de fautes les tests peuvent seulement prouver la présence de fautes, non pas leur absence Qu’est-ce qui caractérise un test réussi? un test qui trouve une faute, ou une exécution du test sans fautes. La plupart des schémas de tests sont conçus afin de choisir des sous-ensembles d’entrants avec une grande probabilité d'entraîner une défaillance (recherche pour certaines classes de fautes) Comme utilisateur, êtes-vous sûr qu’avec cette stratégie, le système est correct? 7 Automne 2014GEF492

8 Exemple procedure selection-sort(A,n); integer i, j, small, temp; begin for i:= 1 to n-1 do small:=i; for j:= i+1 to n do if abs(A[j]) < abs(A[small]) then small:=j; endif enddo temp:=A[i]; A[i]:=A[small]; [small]:=temp; enddo end selection-sort; 8 Automne 2014GEF492

9 Suffisance de test (1) performer des tests exhaustifs est une tâche presque impossible (à moins, bien sûr que vous avez quelques milliards d’années avant la pension) il faut donc choisir des cas de tests qui testent de façon adéquate sans avoir à considérer toutes les combinaisons possibles Exemple (Selection-sort) – Cas de test # 1 n=2, A[1]= 10, A[2] = 5 Résultat: tous les énoncés sont exécutés 9 Automne 2014GEF492 Est-ce adéquat ? Exemple

10 Suffisance de test (2) Exemple (Selection-sort) – Cas de test # 2 n=0, 1, 17, 1000 pour n= 17 et 1000 tester trois tableaux différents A: entiers aléatoires de 0 à 10 6 B:triés en ordre ascendant C:triés en ordre descendant Résultat: tous les énoncés sont exécutés, et plusieurs tableaux différents sont utilisés 10 Automne 2014GEF492 Ça fait surement l’affaire maintenant ? Exemple

11 Tests par couverture de flux de contrôle la couverture par énoncé (ou tous nœuds) – ce critère de suffisance est plutôt faible la couverture d’énoncés à 100% est habituellement un critère minimum de suffisance la couverture par branches (ou tous arcs) – plus fort que la couverture par énoncés, mais ne donne toujours pas de garanties de la véracité du programme couverture exhaustive (ou tout chemin) – la couverture de flux de contrôle la plus forte (souvent impossible) 11 Automne 2014GEF492

12 Autres critères de suffisance de tests tests par fautes basé sur l’insertion d’un nombre connu de x fautes, les tests doivent en trouver y% tests par erreur la conception des tests est basée sur des erreurs communes (manque de 1, exceptions manquantes, NAND au lieu de NOR, etc.) tests à boites noires les tests sont choisis uniquement selon les spécifications logicielles (aussi appelé tests fonctionnels) tests structurels tests basés sur les structures internes du programme 12 Automne 2014GEF492

13 Augmenter la confiance Comme utilisateur, on est peut-être plus intéressé en la fiabilité du logiciel qu’en son nombre de fautes cachées L’objectif de tests de confiance est de trouver les fautes qui causent le plus souvent des défaillances la sélection aléatoire d’entrants n’est pas efficace à trouver le nombre maximum de fautes, mais elle est essentielle aux tests de fiabilité pourvu que l’ensemble aléatoire soit représentatif de l’utilisation opérationnelle 13 Automne 2014GEF492 La fiabilité est la probabilité que le système ne subisse pas de défaillance pendant les prochaines x heures d’opération

14 Tests de fiabilité 14 Automne 2014GEF492 Taux de défaillances λ λ désiré temps de test écoulé temps de tests additionnels estimés [HvV] Section 19.2

15 Prévention de fautes un schéma de test basé sur la détection de fautes est une approche orientée vers les démonstrations, et place l’emphase de vérification vers la fin de la phase de développement on cherche des fautes dans le code exécutable seulement un schéma de test basé sur la prévention de fautes met l’emphase sur la planification et la conception de tests la conception de cas de tests exécutés tôt peut révéler des fautes dans les besoins (non testables, inconsistants, mal compris) en plus des fautes, les tests peuvent aider à trouver des améliorations au processus 15 Automne 2014GEF492

16 VÉRIFICATION DANS LE CYCLE DE VIE Prochaine séance: Automne 2014GEF492 16