Tests de logiciel: Introduction

Tests de logiciel: Introduction

• Ce document présente une introduction aux tests logiciels, couvrant les généralités, les problèmes et le contexte.
• Le matériel principal utilisé est LOG240 avec Alain April et Roger Champagne.
• Ce matériel réutilise le matériel du cours LOG3430 de l'École Polytechnique de Montréal.
• Les auteurs principaux sont Giulio Antoniol et Sègla Kpodjedo.

Définitions de base

• Un logiciel est un ensemble de programmes avec de la documentation associée et des données concernant le fonctionnement d'un système informatique (ISO 24765).
• Un ensemble de programmes inclut le code source ayant fait l'objet de spécifications, de conception, de revues et d'essais.
• Les données sont inventoriées, modélisées, normalisées et créées lors de la production du logiciel.
• Un processus est constitué des processus d'affaires des utilisateurs, décrits, étudiés et optimisés.
• Les règles sont les règles d'affaires décrites, validées, implantées et testées.
• La documentation est un véhicule de communication, réalisée à toutes les étapes clés du cycle de vie.

Assurance Qualité

• Le groupe d'assurance-qualité logicielle est une équipe compétente et formée pour assurer que toutes les actions nécessaires sont prises durant le développement afin que le logiciel soit conforme aux exigences techniques.
• La vérification est l'évaluation d'un système pour déterminer si les produits d'une phase de développement sont conformes aux conditions imposées au début de cette phase. Les activités incluent des inspections et des revues par les pairs des livrables.
• La validation est l'évaluation d'un système durant ou à la fin d'un cycle de développement pour déterminer si les exigences spécifiées sont satisfaites en sollicitant le logiciel avec des cas de test. Elle est habituellement associée à des tests traditionnels basés sur l'exécution.

Missions de l'Assurance Qualité

• Découvrir les fautes dans les documents de manière systématique pour éviter la propagation, grâce à des études structurées et systématiques de la documentation logicielle appelées inspections.
• Dériver systématiquement des cas de test efficaces pour découvrir les anomalies.
• Automatiser et étendre les activités de test et d'inspection au maximum possible des activités du projet.
• Surveiller et contrôler la qualité, comme la fiabilité et la facilité de maintenance, à travers toutes les phases et les activités du projet.
• Mesurer le produit logiciel et les processus par une métrique appropriée, ainsi qu'évaluer empiriquement les tests et les technologies d'inspection.

Défaillances logicielles: Histoires « drôles »

• Un distributeur automatique Tesco à Hounslow, West London (2009) a donné deux fois le retrait demandé après une "erreur opérationnelle", un “computer glitch".
• Une personne a dit: "It makes a change for us to have the joke on the banks for once."
• La banque a dit: "If the people using the ATM see it as a bit of fun, so be it."
• Des événements similaires ont eu lieu en 2008 et 2011 en Europe et en Amérique du Nord.

Défaillances logicielles: Histoires « d'horreur »

• Ariane 5, Vol 501 (1996) a perdu 370 millions $ US à cause d'une mauvaise gestion d'exceptions.
• Conditions préalables: -32768 <= x <= +32767, condition postérieure: y=int16(x)
• La machine de radiothérapie Therac-25 (85-87) a causé des sur-irradiations (jusqu'à 100 fois la dose) et au moins 5 morts, car aucun test n'avait été fait sur les entrées non-standard.
• Mars Climate Orbiter (1999) s'est écrasé sur Mars et a perdu 300 millions $US à cause d'un mélange des systèmes impérial et métrique.

Problèmes dominants

• Nature du développement logiciel : n'est pas une production, mais une utilisation intensive de l'effort humain, également un processus social impliquant diverses industries.
• Le logiciel est souvent livré en retard, avec des surcoûts et une qualité insatisfaisante.
• La validation et la vérification de logiciel sont rarement systématiques et basées sur des techniques sûres.
• Les processus de développement de logiciel sont habituellement instables et incontrôlés.
• La qualité du logiciel est naïvement mesurée, surveillée et contrôlée.

Conséquences chiffrées d'une qualité faible

• Une enquête du groupe Standish (1994) impliquant 350 compagnies et plus de 8000 projets montre que 31% des projets ont été annulés et seulement 9-16% ont été livrés dans les coûts et budgets prévus.
• Une étude américaine (1995) a dénombré 81 milliards $US dépensés par année pour des projets de développement de logiciel qui ont échoué.
• Une étude NIST (2002) montre que les bugs coûtent 59.5 milliards $ par année.
• Une détection anticipée aurait pu sauver 22 milliards $.

Qualités des produits logiciels

• Exactitude
• Fiabilité
• Robustesse
• Performance
• Convivialité
• Facilité de vérification
• Facilité de maintenance
• Facilité de réparation
• Facilité d'évolution
• Facilité de réutilisation
• Portabilité
• Facilité de compréhension
• Interopérabilité

Exemple : feu de signalisation

• Exactitude, fiabilité: laisse le trafic passer selon un modèle correct et une programmation centralisée.
• Robustesse, sécurité : fournit une fonction minimale quand c'est possible et ne signale jamais des verts en conflit.

Subtilités de la sûreté de fonctionnement du logiciel

• Un programme est correct s'il obéit à sa spécification, mais on ne peut établir qu'un programme est correct. On peut en évaluer la fiabilité (approximation statistique)
• Un programme est robuste s'il agit raisonnablement sous des conditions sévères, inhabituelles ou illégales.
• Spécification inadéquate ou partielle : correct, mais pas sécuritaire ou robuste.
• Défailllances Rares : Fiable mais pas correct
• Défaillances « gênantes » → Sécuritaire mais pas correct.
• Défaillances catastrophiques → peut-être Robuste mais pas sécuritaire.

Les besoins de sûreté de fonctionnement varient

• Dans les applications à sécurité-critique, les systèmes de contrôle aérien ont des besoins stricts en matière de sécurité et les systèmes de télécommunications ont des besoins stricts en matière de robustesse.
• Dans les produits de masse, la fiabilité est moins importante que le délai de livraison au marché.
• La fiabilité et la robustesse sont des aspects clés pour les systèmes d'exploitation multi-utilisateurs (e.g., UNIX), mais moins importants pour les systèmes d'exploitation mono-utilisateur (e.g., Windows ou MacOS)

Traitement des fautes logicielles

• Les fautes logicielles sont traitées à travers l'évitement, la détection et la tolérance.
  • Évitement:
    • Méthodologie de conception
    • Vérification
    • Inspections
    • Gestion des configurations
  • Détection:
    • Tests (composants, intégration, système)
    • Débogage (exactitude, performance)
  • Tolérance:
    • Transactions atomiques
    • Redondance modulaire

Définitions & Objectifs du test

• Erreur (Error) : Action humaine qui produit un résultat incorrect (ISO 24765).
• Défaut ou faute (Defect) : Une erreur qui, si elle n'est pas corrigée, pourra causer une défaillance (failure) ou produire des résultats incorrects (ISO 24765). Un défaut est introduit dans le logiciel comme conséquence d'une erreur.
• Défaillance ou panne (Failure) : Cessation de l'aptitude d'un produit à accomplir une fonction requise ou de son incapacité à s'en acquitter à l'intérieur des limites spécifiées précédemment (ISO 25000).
• Test de logiciel : exécution du logiciel pour trouver des fautes ou gagner en confiance.
• Cas de test : item relié aux tests et contenant un ensemble de données d'entrée, des conditions d'exécution et les sorties attendues.
• Jeu (Suite) de tests / Test : ensemble de cas de test, combiné ou non à un ensemble de procédure de test.
• Débogage (localisation de défauts) : localiser le défaut, réparer le code, tester le code à nouveau.
• Test Stub : implémentation partielle d'un composant duquel dépend le composant testé.
• Test Driver : implémentation partielle d'un composant qui dépend du composant testé.
• Les Test stubs et test drivers permettent d'isoler les composants du reste du système pour être testés.
• Dijkstra (1972) : "Le test de programme peut être utilisé pour montrer la présence de bugs, mais jamais pour montrer leur absence." Il n'y a aucune certitude absolue déduite du test.
• Un test devrait être intégré avec d'autres activités de vérification, e.g., les inspections.
• Le but principal est de démontrer que le logiciel a une sûreté de fonctionnement suffisante.
• Oracle : n'importe quel moyen permettant de prédire le résultat.
• Il faut qu'un nombre suffisant de cas de test soient exécutés pour révéler des erreurs ou augmenter la confiance, tout en étant efficace, localisant les fautes, répétable, automatisé et systématique. Ceci améliore l'utilisation des ressources, la réutilisation des tests, le respect du budget et la qualité du produit.

Propriété de la continuité

• La propriété de continuité qui est vraie pour des ponts ne l'est pas pour les logiciels.

Test exhaustif

• Le test exhaustif, utilisant toutes les données possibles, est la plupart du temps impossible.
• Technique pour réduire le nombre de données : le critère de test groupe les éléments d'entrée en classes d'équivalence. Une entrée est sélectionnée dans chaque classe.

Test Intelligent

• Peu importe les moyens pour l'éviter, il reste des défauts dans tout composant logiciel.
• La responsabilité des testeurs : concevoir des tests qui révèlent les défauts et peuvent être utilisés pour évaluer la qualité du logiciel.
• Pour atteindre ces objectifs, le testeur doit intelligemment choisir un sous-ensemble des entrées de test possibles, ainsi que des combinaisons de ces entrées de telle sorte que la probabilité de révéler des défauts soit maximisée, en respectant les contraintes.

Stratégie de conception / Couverture des tests

• Critère associé : Le jeu de test doit couvrir toutes les éventualités dans le modèle.
• La représentation de la spécification mène au test de boîte noire, et la représentation de l'implémentation mène au test de boîte blanche.

Tests Boite Noire

• Nommés "tests basés sur les spécifications" ou "tests fonctionnels".
• Le logiciel à tester est considéré comme une boite opaque.
• Le testeur sait ce que fait le logiciel, mais pas comment.
• Ils sont applicables à tous les niveaux (fonction, module, système complet).
• Les sources d'information sont les spécifications (formelles ou non) et l'ensemble bien défini de pré- et post-conditions.
• Ils sont particulièrement utiles pour révéler des défauts au niveau des spécifications.

Tests Boite Noire - Exemple

• Dans le cas d'un calcul de factorielle: Si la valeur d'entrée n est < 0, un message d'erreur doit être affiché, Si 0 < n < 20, la valeur exacte de n! doit être imprimée, Si 20 < n < 200, une valeur approximative de n! doit être imprimée, et Si n>=200, l'entrée peut être rejetée avec un message.
• Il est naturel de diviser le domaine d'entrée en classes {n<0}, {0< n <20}, {20 < n <200}, {n >= 200}. Les résultats corrects d'un tel jeu supportent l'assertion que le programme fonctionne correctement pour n'importe quelle valeur, mais sans garantie.

Tests Boite Blanche

• Aussi nommée "boite transparente" ou "boite de verre".
• Ils sont concentrés sur la structure interne du code et requièrent que le code (ou un pseudo-code "fidèle") soit disponible au testeur.
• ce sont Des cas de tests conçus pour exercer certaines structures spécifiques;
• Ils prennent plus de temps à concevoir, coder, exécuter et analyser les résultats;
• Ils sont généralement appliqués à de "petits" éléments logiciels et sont utiles pour révéler des défauts de conception, ou de code (contrôle, logique, séquences, initialisation, flux de données).

Tests Boite Blanche - Exemple

• Le critère de test groupe les domaines d'entrée en classes d'équivalence, et la couverture complète essaie d'exécuter chaque classe.

Test boîte noire et test boite blanche

• Boîte noire: les exigences, spécifications, l'expertise du domaine, l'analyse des défauts et les données. Les techniques/approches sont: exploratoire, classes d'équivalence, analyse des valeurs frontalières, transition d'états, analyse cause à effet, cas d'utilisation, table de décision.
• Boîte blanche: l'architecture, le conception, les graphes du code source, les structures internes et la complexité. Les techniques/approches sont: test d'énoncé, test de branche, test de chemin, test de flot de données, test de structure.
• La fonctionnalité manquante ne peut être révélée par une boite blanche et la fonctionnalité inattendue ne peut être révélée par une boite noire.
• Boîte noire : vérifie la conformité avec les spécifications et s'adapte aux niveaux de granularité. Elle dépend de la notation des spécifications et ne détecte pas les tâches non spécifiées.
• Boîte blanche : permet d'être certain au sujet de la couverture du test et est basée sur la couverture du flot de contrôle ou de données. Elle ne s'adapte pas aux niveaux de granularité et ne peut pas révéler les fonctionnalités manquantes.

Aspects pratiques

• La spécification peut être incorrecte ou avoir un besoin manquant, ou contenir un besoin impossible et la conception du système peut contenir une défaillance et le code du programme peut être inexact.

Organisation du test

• Différentes causes potentielles de défaillance existent.
• Dans les gros systèmes, le test implique plusieurs étapes : Module, composant ou unité, intégration, fonction, performance, acceptation, installation.

Différences entre les activités de tests

• Test d'unité : à partir des spécifications de module, avec visibilité des détails de code, échafaudage complexe et comportement de simples modules.
• Test d'intégration : à partir des spécifications d'interface, avec visibilité de la structure d'intégration, quelques échafaudages et interactions entre modules.
• Test du système : à partir des spécifications, pas de visibilité de code, sans "driver" ni "stub" et des fonctionnalités du système.

Test d'intégration

• L'intégration de composants bien testés peut mener à une défaillance due à une mauvaise utilisation des interfaces.
• La défaillance peut être due à une hypothèse incorrecte sur le comportement/état de modules reliés ou à une utilisation de drivers / stubs faibles.

Test de système vs. test d'acceptation

• Test de système : le logiciel est comparé avec les spécifications (vérification) et est effectué par des développeurs.
• Test d'acceptation : le logiciel est comparé avec les spécifications de l'utilisateur final (validation) et est effectué par le client. Parfois, on distingue entre tests « α - β » pour les produits à usage général.

Test durant le cycle de vie

• Beaucoup d'artefacts de développement donnent de riches données et aides pour les tests.

Organisation du cycle de vie

• Besoins => Test d'acceptation, Spécifications/Analyses => Test de système, Conception => Test d'intégration, Diagramme de classe, méthodes, pré- et post-conditions, structure => test de classe.
• Les erreurs auront des effets dévastateurs si non corrigées pendant les tests.
• Les besoins peuvent être en langage naturel qui peut être flexbile mais ambigu et donc avoir une testabilité faible.
• L'évaluation anticipée du test permet d'évaluer la testabilité et de réduire sa durée.
• Niveau le plus bas du test de besoins: générer les données de test pour chaque besoin au moins une fois.

Activités de test

• Les activités standards sont d'établir les objectifs des tests, de concevoir, d'écrire et de tester les cas de test, exécuter les tests, évaluer les résultats, comprendre les causes des défaillances et faire les tests de régression.
• Il faut développer des tests tôt dans le cycle de développement.

Modèle en V et activités de tests

• Le diagramme illustre le modèle en V et les activités de tests associées.

Rôle du testeur

• Les tests tendent à être vus comme destructifs: le but est alors de trouver les points faibles et les erreurs.
• Un testeur doit savoir collaborer, être hiérarchiquement indépendant des développeurs, être spécialiste (posséder compétences et expérience), et ne pas débogguer.

Principes de tests

• Le test est un processus consistant à solliciter un composant logiciel en utilisant un ensemble de cas de tests avec l'intention de (i) révéler des défauts et (ii) évaluer la qualité.
• Quand l'objectif du test est de détecter des défauts, un bon cas de test en est un qui a une probabilité élevée de révéler un défaut encore non-détecté.
• Les résultats de tests devraient être inspectés méticuleusement.
• Un cas de test doit spécifier la sortie ou le résultat attendu.
• Des cas de tests devraient être développés pour des entrées valides, mais aussi pour des entrées invalides.
• La probabilité qu'il existe des défauts additionnels dans un composant logiciel est proportionnelle au nombre de défauts déjà détectés dans ce composant.
• Les tests devraient être réalisés par un groupe indépendant du groupe de développement.
• Les tests doivent être répétables et réutilisables
• Les tests devraient être planifiés.
• Les activités associées aux tests devraient être intégrées dans le cycle de vie du logiciel.
• Les tests requièrent de la créativité et représentent une tâche avec un haut niveau de défi.
• Tester demande de la créativité : les tests sont vus comme un travail ingrat (de moins en moins), et le test est mieux fait par des testeurs indépendants, car le programmeur reste fidèle aux données qui font fonctionner le programme. Un programme peut ne pas fonctionner avec de nouvelles configurations.