Test logiciel et validation des structures internes

Le test est l'exécution ou l'évaluation d'un système ou d'un composant par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus.

Tester, c'est exécuter le programme dans l'intention d'y trouver des anomalies ou des défauts.

Un mécanisme permettant de décider la réussite d'un scénario de test, en déterminant si les réponses obtenues correspondent aux exigences du scénario.

Un programme ou script dédié à exécuter les cas de tests, collecter les résultats et comparer aux attentes.

Un défaut de conception d'un programme informatique à l'origine d'un dysfonctionnement.

Ensemble des méthodes et techniques utilisées pour tester un logiciel et garantir sa qualité.

Un cas de test est un ensemble d'entrées de test, de conditions d'exécution et de résultats attendus pour un objectif particulier, comme la conformité du programme avec une spécification.

Les bugs peuvent entraîner des pertes financières et même des pertes en vies humaines dans certains cas.

Le développement logiciel est intrinsèquement sujet aux erreurs.

Le test n'est pas seulement l'exécution d'un programme, mais aussi la vérification des résultats par rapport à des attentes définies.

Le test vise à trouver des erreurs, mais ne peut pas garantir l'absence d'erreurs. Le test peut montrer qu'il y a des erreurs, mais jamais qu'il n'y en a pas.

Le test est une activité de contrôle qualité indépendante du développement.

Le test statique consiste à analyser le code sans l'exécuter, par exemple via la relecture de code ou l'utilisation d'outils d'analyse.

Le test dynamique consiste à exécuter le programme et à observer son comportement, par exemple en utilisant des cas de test.

Le test dynamique consiste à exécuter le programme avec des valeurs en entrée et à observer son comportement pour détecter des erreurs.

Le métier de testeur est crucial pour garantir la qualité d'un logiciel, car c'est lui qui est chargé de trouver les erreurs et les imperfections du programme.

Le testeur doit imaginer des situations qui peuvent provoquer des erreurs dans le logiciel et prévoir des tests pour les détecter. C'est une activité créative et stratégique.

Le métier de testeur est souvent mal perçu car il met en évidence les erreurs et les retards. Cependant, c'est une activité essentielle pour garantir la qualité du produit.

Un programmeur ne doit pas tester son propre programme pour éviter les biais et les erreurs de jugement.

Il faut tester le logiciel en supposant qu'il y aura des erreurs, car la perfection est illusoire.

Les résultats attendus d'un test doivent être définis avant son exécution pour pouvoir évaluer efficacement sa réussite.

L'analyse des résultats de chaque test est cruciale pour identifier et corriger les erreurs, et ne doit pas être effectuée par le même personne qui a exécuté le test.

Une méthode de test consistant à vérifier le code ligne par ligne pour s'assurer qu'il fonctionne comme prévu.

Des données de test sont utilisées pour valider le fonctionnement des structures de données internes d'un programme.

Une méthode de test qui se concentre sur le comportement externe du logiciel. Les testeurs ne connaissent pas le code interne.

Un document qui décrit un ensemble d'étapes spécifiques pour tester un logiciel.

Les tests de boîte noire s'intéressent au comportement du système sans se soucier de sa structure interne. Ils testent si le système fonctionne comme prévu, en utilisant des entrées et en observant les sorties.

Ces tests se concentrent sur la définition de ce qu'un programme est censé faire, sans se soucier de son code. On considère le logiciel comme une boîte noire, en étudiant ses entrées et sorties.

Le niveau de détail des spécifications est crucial pour les tests de boîte noire. Plus les spécifications sont précises, plus il est facile de générer des cas de tests et de prévoir les résultats attendus.

Les tests de boîte blanche examinent le code source du programme pour identifier les erreurs potentielles. Ils s'assurent que tous les chemins de code sont testés, y compris les conditions d'arrêt des boucles.

Les tests de boîte blanche garantissent que toutes les conditions d'arrêt des boucles sont vérifiées. Cela signifie que le code ne continuera pas à tourner indéfiniment, ce qui pourrait entraîner des blocages ou des erreurs.

Les tests de boîte blanche sont utilisés pour vérifier que le code fonctionne correctement et que les boucles sont gérées de manière appropriée.

Les tests de boîte blanche sont souvent utilisés en complément des tests de boîte noire pour garantir une couverture complète de tous les aspects du programme.

Les tests de boîte noire testent les fonctionnalités du logiciel sans tenir compte de son code source, tandis que les tests de boîte blanche examinent le code source pour vérifier son fonctionnement interne et ses performances.

Le processus de vérification que le logiciel répond aux exigences du client et qu'il fonctionne correctement dans son contexte d'utilisation.

Le processus de vérification que le logiciel est conçu et codé avec les spécifications techniques.

Le triangle du test représente les trois piliers du test logiciel: la portée, le temps et les ressources.

Le test peut être réalisé en théorie en prédisant le résultat attendu, en utilisant une formule ou un autre programme, mais en pratique, des approximations et des erreurs peuvent survenir.

Un testeur efficace doit comprendre le système qu'il teste, connaître les techniques de test et savoir les appliquer efficacement.

L'activité de test est souvent perçue comme un travail ingrat, mais elle est essentielle pour garantir la qualité du logiciel et éviter des pertes importantes.

Il est généralement plus efficace de faire tester le logiciel par des personnes indépendantes du développement pour éviter les biais et les erreurs.

Technique de vérification qui consiste à analyser le code source, les spécifications ou les documents de conception sans exécuter le programme.

Technique de vérification qui explore tous les chemins d'exécution possibles d'un programme pour détecter des bugs ou prouver certaines propriétés du programme.

Technique de vérification qui utilise un modèle formel du programme pour prouver sa correction ou pour détecter des erreurs.

Les erreurs logicielles peuvent avoir des conséquences importantes, allant de pertes financières à des pertes de vies humaines.

Les bugs surviennent inévitablement dans le développement logiciel, même chez les développeurs expérimentés.

Une entrée non standard dans un système a causé des problèmes, entraînant des dommages et des pertes.

Une erreur de conversion d'unités a conduit à un échec de la mission spatiale.

Les tests structurels (boîte blanche) sont basés sur l'analyse du code source et permettent de détecter des erreurs au niveau des instructions, des branches et des chemins du code.

Les tests fonctionnels (boîte noire) sont basés sur la spécification du logiciel et s'assurent que le logiciel répond aux exigences définies.

La couverture de code basée sur le flot de contrôle vise à exécuter chaque instruction du code au moins une fois.

Le test aux limites consiste à tester les valeurs aux limites des domaines d'entrée ou de sortie du logiciel pour détecter des erreurs de bord.

Les tests combinatoires visent à tester toutes les combinaisons possibles des valeurs d'entrée d'une partie du logiciel.

Les tests unitaires consistent à tester des unités de code (modules, fonctions) indépendamment des autres parties du logiciel.

La validation d'un module consiste à vérifier qu'un module indépendant est correctement implémenté et respecte sa spécification.

Les tests unitaires et les tests d'intégration sont complémentaires et doivent être utilisés simultanément pour garantir la qualité du logiciel.

Les tests d'intégration servent à tester l'interaction entre les différentes parties d'un système (comme des modules) pour s'assurer qu'elles fonctionnent correctement ensemble.

L'intégration du Big Bang consiste à tester tout le système en même temps. C'est une approche risquée car il est difficile de trouver l'origine d'un bug.

L'intégration ascendante est une méthode de test où l'on commence par tester les composants individuels et on les combine progressivement jusqu'à obtenir le système complet.

L'intégration descendante est une méthode de test où l'on commence par tester les composants principaux et on ajoute progressivement les composants secondaires.

L'intégration Sandwich est une méthode de test qui combine les deux méthodes précédentes (ascendante et descendante). Elle permet de tester à la fois les composants individuels et les interactions entre eux.

Les tests de conformité, ou tests système, vérifient si le système logiciel répond aux exigences spécifiées au départ.

Les tests de non-régression sont effectués après chaque modification du logiciel pour vérifier que les corrections ou les améliorations n'ont pas introduit de nouveaux bugs.

Ce type de test vérifie le bon fonctionnement du logiciel en utilisant des données d'entrée valides.

Ce type de test vérifie le comportement du logiciel face à des données d'entrée incorrectes ou inattendues.

Ce type de test analyse la performance du logiciel en fonction de la charge et du temps d'exécution.

Une méthode de test logicielle qui consiste à développer les tests avant le code.

Les tests boîte blanche, également appelés tests structurels, se concentrent sur l'analyse du code source du logiciel. Ils examinent le code ligne par ligne pour s'assurer qu'il fonctionne correctement.

Le graphe de flot de contrôle (CFG) est une représentation visuelle des chemins possibles dans un programme. Il permet de comprendre comment le code s'exécute et facilite l'identification des erreurs.

Le concept de couverture de code vise à s'assurer que chaque ligne de code est exécutée au moins une fois pendant les tests. Cela permet de détecter des erreurs dans des parties du code rarement utilisées.

Les tests de mutation sont une technique de test boîte blanche qui consiste à modifier intentionnellement le code source pour observer l'impact de ces modifications sur le comportement du programme.

Les tests boîte noire sont des tests qui examinent le comportement du logiciel sans se soucier de sa structure interne. Ils simulent les actions d'un utilisateur réel en utilisant des données d'entrée et en observant les résultats.

Exige que chaque condition atomique (condition ne contenant aucun opérateur logique) soit évaluée à Vrai et Faux. En d'autres termes, il faut s'assurer que chaque condition simple est testée dans tous ses états possibles (vrai et faux).

Elle permet de s'assurer que chaque condition atomique est évaluée à Vrai et Faux, ce qui permet de détecter les erreurs potentielles dans les branches du code.

Elle consiste à tester le code source en vérifiant que chaque instruction de branche est exécutée au moins une fois.

Elle s'applique aux conditions multiples (avec des opérateurs logiques comme 'et', 'ou') et vise à tester chaque combinaison possible des valeurs des conditions atomiques.

Chaque exécution d'un programme correspond à un chemin de contrôle spécifique à travers le graphe de contrôle.

Un critère de couverture est un ensemble de règles définissant les propriétés que des tests doivent respecter pour garantir une certaine qualité.

La couverture des fonctions vérifie si chaque fonction du programme a été appelée au moins une fois.

La couverture des instructions vérifie si chaque ligne du code a été exécutée et vérifiée.

La couverture des points de test vérifie si chaque point de décision (condition) a été exécuté et vérifié.

La couverture des chemins d'exécution vérifie si chaque chemin d'exécution possible a été exécuté et vérifié.

La couverture des chemins implique l'exécution de chaque chemin possible dans le code, y compris les différents choix conditionnels.

La couverture des décisions exige que chaque branche conditionnelle du code soit exécutée au moins une fois.

La couverture modifiée des conditions/décisions (MC/DC) s'assure que chaque condition atomique d'une décision ait un impact indépendant sur la décision finale.

La couverture des conditions multiples (CCM) exige que toutes les combinaisons possibles de valeurs booléennes des conditions atomiques soient évaluées.

La couverture du CFG en pratique peut être complexe car certaines instructions peuvent être inaccessibles en raison de la logique du programme.

Les tests de flot de contrôle sont généralement plus adaptés pour les petits systèmes logiciels.

Un test qui est effectué par des utilisateurs réels sur une version du produit dans un environnement réel, permettant de tester le logiciel dans des conditions réelles.

Un test qui est effectué par des utilisateurs potentiels dans un environnement réel, permettant de tester le logiciel avant sa sortie.

La couverture des nœuds implique l'exécution de chaque instruction du code au moins une fois, garantissant que chaque nœud dans le CFG est visité.

Le taux de couverture des nœuds mesure la proportion de nœuds (instructions) dans le code qui ont été exécutés lors des tests.

Un taux de couverture des nœuds de 100% ne garantit pas que tous les scénarios possibles du code sont testés. Il est possible qu'un cas de test particulier ne déclenche pas toutes les branches ou conditions du code.

Le taux de couverture des arêtes mesure la proportion de branches (arêtes) dans le code qui ont été exécutées lors des tests.

Le test de mutation est une technique de test plus poussée qui modifie intentionnellement le code source pour observer l'impact de ces mutations sur le comportement du programme.

Les tests de boîte blanche ou tests structurels examinent le code source ligne par ligne pour s'assurer que chaque instruction fonctionne comme prévu.

Les tests boîte noire reposent sur l'idée de considérer le logiciel comme une boîte noire, c'est-à-dire sans se soucier de son code interne. On se concentre sur les entrées et sorties du logiciel pour valider son comportement.

La partitionnement en classes d'équivalence consiste à diviser l'ensemble des données d'entrée possibles en classes équivalentes. Chaque classe représente un ensemble de données qui devrait produire le même résultat. On choisit ensuite une valeur représentative de chaque classe pour le test.

L'analyse de la valeur limite consiste à choisir des valeurs à la limite de chaque classe d'équivalence. Cela permet de tester les cas limites et les potentiels problèmes de bord.

Ensemble de valeurs d’entrée qui produisent le même résultat attendu.

Technique de test basée sur la division du domaine d’entrées en classes d’équivalence.

Choisir un représentant de chaque classe d’équivalence pour tester le logiciel.

Utiliser une seule variable à la fois lors du partitionnement en classes d’équivalence.

Des valeurs d’entrée valides peuvent ne pas révéler tous les défauts. Il est important de tester avec des données invalides pour identifier les erreurs dans la gestion des erreurs.

Des valeurs d’entrée à l’extérieur du domaine de validité peuvent révéler des défauts dans la gestion des erreurs et la robustesse du logiciel.

Les classes d’équivalence doivent être choisies de manière à refléter le comportement attendu du système.

Les tests intuitifs ne garantissent pas un ensemble complet de tests et peuvent manquer des cas importants. Il est important d’utiliser des méthodes de test plus rigoureuses.

Chaque variable d'entrée d'un programme crée une partition du domaine d'entrée. Cela divise l'espace d'entrée en zones distinctes, ce qui permet de créer des cas de test.

Ce type de partitionnement est la méthode la plus courante et la plus simple à mettre en œuvre. Cette technique analyse l'ensemble des données en fonction de classifications préétablies.

Bien que simple, ce partitionnement ne teste pas toutes les combinaisons possibles d'entrées. Il peut manquer des situations critiques qui pourraient causer des erreurs.

Considère le domaine d'entrée comme la combinaison de tous les domaines possibles de chaque variable. Cela implique l'exploration de toutes les interactions possibles entre les variables.

Le SECT génère un grand nombre de cas de test, ce qui peut être difficile à gérer de manière manuelle. Toutefois, cette méthode offre une couverture de test complète.

Pour chaque variable, on choisit un représentant par classe d'équivalence. Le nombre de cas de test est égal au nombre maximum de classes d'équivalence pour chaque variable.

Le WECT ne considère pas les interactions entre les variables. Il peut manquer des erreurs liées à des combinaisons spécifiques d'entrées.

Le SECT se base sur toutes les combinaisons possibles des classes d'équivalence. Cela garantit que toutes les interactions entre les variables sont testées.

Le SECT génère un nombre de cas de test égal au produit du nombre de classes d'équivalence pour chaque variable.

Ce type de partitionnement utilise des valeurs invalides en plus des valeurs valides pour explorer des situations inattendues et augmenter la robustesse des tests.

Le WRECT utilise un représentant par classe d'équivalence valide et un élément invalide pour un seul cas de test. Les autres classes dans le cas de test sont valides.

Le SRECT se base sur le produit Cartésien de toutes les classes d'équivalence (valides et invalides). Cela permet une couverture complète des cas valides et invalides.

Les spécifications des données invalides manquent souvent de clarté, ce qui rend plus difficile l'utilisation des tests par classes d'équivalence robustes.

La fonction NextDate prend trois variables (MOIS, JOUR, ANNEE) pour calculer la date du jour suivant.

L'analyse de la valeur limite consiste à choisir des valeurs à la limite de chaque classe d'équivalence. Cela permet de tester les cas limites et les potentiels problèmes de bord.

Les tests intuitifs (ou ad-hoc) sont des tests qui sont basés sur l'intuition du testeur. Par exemple, le testeur peut choisir de tester un module avec des valeurs qui lui semblent pertinentes, sans se soucier de la couverture des cas de test.

Les tests boîte noire considèrent le logiciel comme une boîte noire, en ne se préoccupant que de ses entrées/sorties et non de sa structure interne.

L'importance et le niveau de détail des spécifications sont essentiels pour les tests boîte noire. Plus les spécifications sont précises, plus il est facile de générer des cas de tests et de prévoir les résultats attendus.

Réduire les données de test, éviter la redondance et garantir une couverture complète.

Ensemble de valeurs d’entrée qui produisent le même résultat attendu.

Tester les valeurs aux limites de chaque classe d'équivalence pour détecter les erreurs.

Vérifier que le système complet répond aux exigences définies et fonctionne correctement dans son contexte d'utilisation.

L'expérience montre que les programmeurs font souvent des erreurs aux bornes des classes d'équivalence.

Le nombre de cas de test pour WECT est déterminé en prenant la valeur maximale du nombre de classes d'équivalence de chaque variable d'entrée.

Le nombre de cas de test pour SECT est déterminé en multipliant le nombre de classes d'équivalence de chaque variable d'entrée.

Le nombre de cas de test pour WECT est max(|A|, |B|, |C|), où |A| est le nombre de classes d'équivalence de la variable A, etc.

Le nombre de cas de test pour SECT est |A| x |B| x |C|, où |A| est le nombre de classes d'équivalence de la variable A, etc.

Il est important de bien comprendre le comportement du système à tester pour choisir les classes d'équivalence pertinentes.

Il est important de choisir prudemment les classes d'équivalence, car un mauvais choix peut conduire à manquer des erreurs importantes.

Les classes d'équivalence regroupent les données avec l'hypothèse que le programme a le même comportement avec tous les éléments d'une classe d'équivalence donnée.