Qu’est-ce qu’un Test exhaustif ?

Les tests exhaustifs, également appelés tests complets, se produisent lorsque tous les testeurs de votre équipe sont épuisés et lorsque tous les tests prévus ont été exécutés. Il s’agit d’une technique de test d’assurance qualité dans laquelle tous les scénarios ou données sont testés pour les tests. De manière plus compréhensible, un test exhaustif signifie s’assurer qu’il n’y a pas de défauts non découverts à la fin de la phase de test. Tout tester (toutes les combinaisons d’entrées et de conditions préalables) n’est pas réalisable, sauf dans des cas triviaux. En tant que testeurs, nous disons souvent « eh bien, je n’ai jamais assez de temps pour tester ». Même si vous aviez tout le temps dans ce monde, vous n’auriez toujours pas assez de temps pour tester toutes les combinaisons d’entrées et de sorties possibles.

Pourquoi un test exhaustif n’est-il pas pratique et impossible ?

Il n’est pas possible d’effectuer des tests complets ou exhaustifs. Pour la plupart des systèmes, c’est presque impossible pour les raisons suivantes:

  • Le domaine des entrées possibles d’un programme est trop grand pour être complètement utilisé dans le test d’un système. Il existe à la fois des entrées valides et des entrées invalides.
  • Le programme peut avoir un grand nombre d’états. Il peut y avoir des contraintes de synchronisation sur les entrées, c’est-à-dire qu’une entrée peut être valide à un certain moment et invalide à d’autres moments. Une valeur d’entrée qui est valide mais qui n’est pas correctement chronométrée est appelée une entrée inopportune.
  • Le domaine d’entrée d’un système peut être très grand pour être complètement utilisé dans le test d’un programme.
  • Les problèmes de conception peuvent être trop complexes pour être complètement testés. La conception peut avoir inclus des décisions et des hypothèses de conception implicites. Par exemple, un programmeur peut utiliser une variable globale ou une variable statique pour contrôler l’exécution du programme.
  • Il peut ne pas être possible de créer tous les environnements d’exécution possibles du système. Cela devient plus important lorsque le comportement du système logiciel dépend du monde extérieur réel, tel que la météo, la température, l’altitude, la pression, etc.

Exemples de tests exhaustifs

Exemple 1:

 Exemple d'options IE de test exhaustif
Les outils IE > Fenêtre d’options avancées

53 conditions binaires
1 condition avec 3 options
1 condition avec 4 options
2^53 = 9,007,199,254,740,992
x 12
= 108 086 391 056 891 904 combinaisons possibles de conditions

À une seconde par exécution de test:

108,086,391,056,891,904 / 360 = 300,239,975,158,033.067 heures (12 509 998 964 918,04 jours ou 34 273 969 766,9 ans) pour tester toutes les combinaisons possibles.

Exemple 2:

Prenons un site e-commerce qui possède les fonctionnalités suivantes:

  • Connexion
  • Choisir un produit
    • Filtrer le produit avec la couleur
    • Filtrer un produit avec le prix.
  • Acheter le produit (portail de paiement)

Sur la base des paramètres d’identification des risques, les utilisateurs peuvent créer une matrice à inclure dans le plan de test. Chaque paramètre peut recevoir des scores afin que nous puissions avoir une manière correcte d’identifier les zones à haut risque.

  • Impact sur l’entreprise: 1-10
  • Probabilité d’échec: 1-10
  • Régression: 1-5
  • Récupération: 1-5

Créons une matrice pour l’exemple ci-dessus:

Fonctionnalité Impact sur l’entreprise Probabilité de défaillance Régression Récupération
Connexion 10 3 1 1=15
Choisissez un produit avec filtre de couleur 5 5 2 2=14
Choisissez un produit avec filtre de prix 8 5 2 2=17
Ajouter au Panier 10 8 3 4=25
Acheter le produit 10 7 2 2=21

Donc, selon le score, nous avons la fonctionnalité « Ajouter au panier » en tant que candidat principal pour la « zone à risque le plus élevé », nous pouvons maintenant prioriser les tests. Nous pouvons également déterminer pour quelles fonctionnalités l’équipe d’assurance qualité doit effectuer un test quasi exhaustif.
L’équipe d’assurance qualité peut rationaliser le plan d’atténuation des risques en examinant leurs scores

  • Scores 1-5: – Tests unitaires et examens.
  • Scores 5-10:- Tests unitaires + tests de boîtes noires (zones de régression et d’impact commercial élevé)
  • Scores 10-15: – Types de tests typiques avec une profondeur limitée.
  • Scores 15-25: – Types de tests typiques avec profondeur dans certains types de tests.
  • Scores 25-30: – Zones à haut risque. Couverture complète et tests approfondis pour tous les types de tests.

Selon la méthode susmentionnée, les zones dont le score est supérieur à 25 doivent être considérées comme des zones à risque extrêmement élevé et un test quasi exhaustif doit être effectué.Ainsi, pour l’exemple ci-dessus, « Ajouter au panier » devrait mettre en œuvre des tests approfondis pour tous les types de tests et des tests exhaustifs devraient être effectués.