Tests

Voir aussi :

• Testing Basic Interview Questions

Terminologie liée au test

• Erreur (error), IEEE 729 :
  Un écart entre une valeur ou condition calculée, observée ou mesurée et la valeur ou condition qui est vraie, spécifiée ou théoriquement correcte.
• Défaut, anomalie (fault, bug), IEEE 729 :
  La manifestation d'une erreur dans un logiciel.
  Un défaut peut causer une panne.
• Panne (failure), IEEE 729 :
  La fin de la capacité d'un système ou d'un de ses composants d'effectuer la fonction requise, ou de l'effectuer à l'intérieur de limites spécifiées.

ANSI/IEEE 729 (1983), Standard Glossary of Software Engineering Technology, Std 729, 1983

Objectifs du test

• Définition (norme IEEE 729) :
  Le test est un processus manuel ou automatique, qui vise à établir qu’un système vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification.
• Le test vise à mettre en évidence les erreurs d’un logiciel.
• Le test n’a pas pour objectif de diagnostiquer la cause des erreurs.
• Le test n’a pas pour objectif de corriger les fautes.
• Le test n’a pas pour objectif de prouver la correction d’un programme.

Qualité de tests

• L’efficacité du test (son aptitude à détecter des erreurs) doit être conforme à certains critères de qualité.
• Le niveau de qualité requis dépend du contexte d’utilisation du logiciel : plus le contexte est critique, plus l’effort de tests doit être important.
• La programmation d’un logiciel aérospatial requiert des exigences de qualité supérieures à la programmation d’un éditeur de dessins techniques.

QUALITÉ (QUALITY), ISO 8402 :
Ensemble des propriétés et caractéristiques d'un produit ou service qui lui confèrent l'aptitude à satisfaire des besoins exprimés ou implicites.

Phases de tests

• tests de composants - faits par les développeurs du logiciel
• tests du système - faits par une équipe de test indépendante

Classifications des méthodes de tests

• classification selon le niveau au cycle de développement
  • test unitaire (unit test or module test) :
    test d'un programme ou d'un module isolé dans le but de s'assurer qu’il ne comporte pas d'erreur d'analyse ou de programmation.
  • test d’intégration (integration test), IEEE 729 :
    une progression ordonnée de tests dans laquelle des éléments logiciels et matériels sont assemblés et testés jusqu'à ce que l’ensemble du système soit testé.
  • tests unitaires vs tests d'intégration
  • test système :
    consiste à tester le logiciel dans des conditions opérationnelles et au delà (surcharge, défaillances matérielles, ...).
    tests système prennent comme entrée tous les composants logiciels ayant réussi les tests d'intégration et aussi le système logiciel lui-même intégré à n'importe quel système
  • test d'acceptation (acceptance test), ISO/IEC 2382-20 :
    test, généralement effectué par le client dans ses locaux après installation d'un système ou d'une unité fonctionnelle, avec la participation du fournisseur, pour vérifier que les dispositions contractuelles soient bien respectées.
  • tests système vs tests d'acceptation
• classification selon le niveau d'accessibilité
  • tests de type boîte noire
  • tests de type boîte blanche
  • comparaison
• classification selon la caractéristique
  • tests de performance
  • tests fonctionnels
  • tests de robustesse
  • tests de vulnérabilité
• autres tests
  • assertions
  • test de régression (regression test) :
    à la suite de la modification d'un logiciel (ou d'un de ses constituants), un test de régression a pour but de montrer que les autres parties du logiciel n'ont pas été affectées par cette modification.
    exemple

Divers

• Tests d’acceptation mettent en évidence des erreurs dans la définition des besoins qui peut ne pas correspondre au niveau de fonctionnalité ou de performance attendus par l’utilisateur.
• Les gains obtenus de la détection d’erreurs doivent dépasser les coûts résultant de la génération, entretien, exécution et évaluation des tests.
• Tests d'un module difficiles si ce module déjà installé dans le système.
• Le nombre de cas à tester est énorme; d'où l’importance de l’automatisation.

Tests de modules

Pour tester un module, les tâches suivantes sont exécutées :

1. construction du pilote ("driver")
2. génération des entrées
3. calcul des sorties attendues (problème de "oracle de tests")
4. exécution du module sur les données choisies en surveillant le comportement du module
5. comparaison des sorties obtenues avec les sorties attendues

Exemple d'un pilote supportant l'exécution de tests d'un module spécifié avec la méthode de traces :

• create_can_traces(n) crée n traces canoniques (différentes de la trace vide)
• get_trace(v) lit (de façon aléatoire) une trace canonique de l’ensemble créé par create_can_traces, dans la variable v
• print_trace(v) imprime la trace canonique v dans un format lisible
• print_err(pname,i) imprime un message d’erreur concernant l’entrée i dans la table (fonction) d’extension (ou table de valeurs de retour) décrivant le programme d’accès pname
• error(pname,i,c) et error2(pname,i,c,c2) impriment un message d’erreur pour l’entrée i, le programme d’accès pname et la trace canonique c (et c2) qui ont provoqué cette erreur
• start_testing() initialise le processus de tests
• end_testing() termine le processus de tests

Problème: selon quels critères générer les entrées ?

Techniques de tests de "boîte transparente"

• critère "chaque instruction" ("statement coverage criterion")
  Exemple :
  
  read(x); read(y);
  if x > 0 then
    write("1");
  else
    write("2");
  end if;
  if y > 0 then
    write("3");
  else
    write("4");
  end if;

  Un jeu de tests :
    { (x=2, y=3), (x=-5, y=10), (x=1, y=-3), (x=-5, y=-7) }
  
  Un jeu de tests minimal :
    { (x=-5, y=10), (x=1, y=-3) }
  
  Faiblesse :
  if x < 0 then
      x := -x;
  end if;
  z := x;
  
  Le jeu { (x=-5) } est complet, mais le cas x > 0 jamais testé.

• critère "chaque arête"

  Un jeu de tests: { (x = 5), (x = -4) }

  Exemple : recherche d’un élément dans un tableau

    trouvé = false;
    if  nombre_d_items ≠ 0 then
      compteur := 1;
      while not trouvé and compteur < nombre_d_items loop
        if table(compteur) = élément_désiré then
          trouvé := true;
        end if;
        compteur := compteur + 1;
      end loop;
    end if;
    if trouvé then
      write("l’élément désiré existe dans le tableau");
    else
      write("l’élément désiré n’existe pas dans le tableau");
    end if;

  Quel jeu de tests proposez-vous ?

• critère "chaque condition"
• critère "chaque chemin" ("path coverage criterion")
  Exemple :
  
  if x ≠ 0 then
    y := 2;
  else
    z := z+3;
  end if;
  if z > 5 then
    z := z/x;
  else
    z := 1;
  end if;

  Le jeu de tests
    { (x=0, z=2), (x=3, z=7) }
  traverse toutes les arêtes, mais la division
  par zéro est toujours possible!
  
  Le jeu de tests
    { (x=0,z=4), (x=3,z=2) }
  serait meilleur.

  • Le nombre de chemins à tester est énorme en général.
  • En pratique, on identifie seulement les chemins critiques :
    • sauter la boucle (tableau vide),
    • exécuter la boucle une ou deux fois (l’élément trouvé),
    • traverser tout le tableau (pas d’élément recherché).

Techniques de tests de "boîte noire"

• tests fonctionnels ("functional testing"), Howden

  soit f(p₁,p₂,...,p_n)

  • Pour tout p_i on choisit un ensemble S_i de valeurs spéciales et on teste f pour chaque couple dans S₁ x S₂ x ... x S_n.
  • Choix de valeurs est déterminé par les types des paramètres et l’implémentation de fonctions (on peut avoir des dépendances entre les ensembles).
  • Choix de valeurs spéciales pour des paramètres scalaires :
    • supposons que le type du paramètre soit l’intervalle [L,U]
    • choix de cas normaux :
      deux bornes, une valeur intérieure
    • choix de cas spéciaux :
      bornes des intervalles (-∞,L-1] et [U+1,∞), valeurs intérieures

  Exemple : si le paramètre est déclaré integer range 1..100 alors les valeurs spéciales choisies pourraient être {-1000,0,1,50,100,101,1000}.

  Application de cette approche au module

  • choix de valeurs spéciales pour les paramètres et l’état du module;
    l’état du module est considéré comme un paramètre implicite.
  • on teste le traitement de situations inattendues pour chaque programme d’accès;
  • le nombre de couples dans S₁ x S₂ x ... x S_n est considérable;
  • la génération automatique de valeurs spéciales est donc importante,
  • la génération de sorties attendues devient un problème.
• tests aléatoires ("random testing")

Comparaison des sorties obtenues avec les sorties attendues

La comparaison des sorties obtenues avec les valeurs attendues se fait, dans la pratique, à la main.

• coûts énormes

Tests de systèmes parallèles et de temps réel

• problèmes avec le non-déterminisme
• difficile de répéter la même exécution
• facteur de temps

Divers

• principe du TDD (Test-Driven Developpement) : avant d'écrire le code d'une fonctionnalité, d'écrire le test pour ce code
• chaque fonctionnalité peut se retrouver avec plusieurs milliers de tests, chacun vérifiant d'une manière différente le bon fonctionnement d'une petite partie de l'application.
• l'automatisation devient nécessaire
• Mantis (http://www.mantisbt.org/) : un outil de suivi d’anomalies (Bug tracking system)
  • requiert une base de données (MySQL) et un serveur Web
  • différents types d’utilisateurs selon les droits décroissants : administrateur, chef de projet, développeur, rapporteur, invité