Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Quelques définitions Une défaillance (failure) est un comportement inacceptable démontré par un système —La fréquence de ces défaillances est une mesure de la fiabilité d’un système —Un bon design doit donc avoir comme objectif de produire un système fiable (ayant peu de défaillances). —Une défaillance résulte d’une mauvaise réalisation des exigences du système Un défaut (defect) dans un système est une faille pouvant contribuer à l’occurrence d’une ou plusieurs défaillances —Cette faille peut se trouver aussi bien dans l’énoncé des spécifications que à l’intérieur du code souce. —Parfois, c’est l’accumulation de plusieurs défaut qui cause une défaillance —Dans certains cas, un défaut peut demeurer caché (c’est-à-dire que sa présence ne caus pas de défaillances) Une erreur (error) est une inattention ou une mauvaise décision prise par un développeur logiciel menant à l’introduction d’un défaut

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Tester de facon efficace et effective Afin de tester d’une facon effective, il faut découvrir autant de défauts que possible dans un système. Afin de tester de facon efficace, il faut trouver un maximum de défauts en effectuant le moins de tests possibles C’est un peu un travail de détective: —Le testeur doit penser comme un programmeur afin de découvrir ou il peut avoir introduit une erreur. —Le testeur ne doit négliger aucune piste, il doit suspecter toutes les composantes. —Il doit demeurer efficace afin de ne pas perdre un temps précieux à attraper les coupables.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality4 Les tests en boite de verre Aussi appelé tests en boite blanche ou tests structuraux Dans ce cas, le testeur a accès au design interne du système Il peut —Lire les documents de design —Examiner le code sourceView the code —Observer l’exécution du système et avoir accès aux variables internes Les programmeurs devraient toujours effectuer ce genre de tests pour le code qu’ils produisent

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality5 Production d’un graphe pour les tests structuraux Afin d’assister le programmeur dans la production de tests systématiques Les branchements dans le code produisent des noeuds (les conditions, les boucles) Une fois le graphe produit, il existe différentes facons de couvrir ce graphe en effectuant des tests: —Couvrir tous les chemins (généralement infaisable) —Couvrir toutes les branches (souvent la solution préférée) —Couvrir tous les noeuds (le plus simple)

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality6 Un graphe pour les tests structuraux

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality7 Les tests en boite noire Ici le testeurs donne au système des valeurs d’entrée et en regarde la sortie (les résultats produits) Ils n’ont pas accès au: —Code source —Aux données internes —Ou à toute documentation décrivant la partie interne du système

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality8 Les classes d’équivalence Il est impossible (et inutile) de tester un système en essayant d’y entrer toutes les valeurs possibles imaginables —Cela prendrait en fait un temps infini! Il faut plutôt regrouper les valeurs d’entrée en groupes pour lesquels, chacune des valeurs incluses dans un groupe devrait être traitée de facon similaire par le système. —Ces groupes sont appelés classes d’équivalence. —Un testeur devrait s’assurer d’exécuter le système avec au moins une valeur provenant de chacune des classes d’équivalence —Le testeur doit -Comprendre le fonctionnement du système -Avoir une bonne intuition de la facon dont le logiciel a été concue

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality9 Exemples de classes d’équivalence On veut vérifier si un nombre est un numéro de mois valide (1-12) —Les classes d’équivalence sont: [-∞..0], [1..12], [13.. ∞] On veut vérifier si une chaine de caractères est un mois de l’année —Les classes d’équivalence sont -12 classes pour chacun des mois -Une classe représentant les chaines de caractères invalides

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality10 Combiner les classes d’équivalence Même en définissant des classes d’équivalence, en combinant les différentes entrées possibles, il peut y avoir un trop grand nombre de combinaisons afin de tester toutes les possibilités. —Par exemple si un système accepte 4 entrées, chacune d’elle ayant 5 classes d’équivalence, cela donne 5 4 (i.e. 625) classes d’équivalence possibles pour tout le système. Il faut alors s’assurer de tester au moins une valeur pour chaque classe d’équivalence individuelle. Il faut aussi identifier et tester les combinaisons pour lesquelles les valeurs d’entrée pourraient s’influencer Puis, il serait bon de tester quelques combinaisons prisent au hasard.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality11 Exemple combinant plusieurs classes d’équivalence On veut valider une date entrée sous le format ‘jour’ ‘nom du mois’ ‘année’ Les classes d’équivalence sont: —Pour le jour [-∞..0], [1..28], [29], [30], [31], [32, ∞] —Pour les mois, il y a 12 classes + 1 autres classes pour les chaines invalides —Pour les années, il y a les années régulières: [-∞..1581] [1582, ∞] et les années bissextiles [années divisibles par 4] [années divisibles par 100] [années divisibles par 400] Ce qui donne un total de 6x13x5= 390 classes

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality12 Tests aux frontières Les erreurs se produisent souvent aux frontières des classes d’équivalences Il faut donc toujours tester ces cas frontière —e.g. le nombre 0 peut souvent causer problèmes Par exemple, dans la validation d’un mois de l’année —On procède aux tests pour les classes d’équivalence —Puis on teste aux frontières, c’est-à-dire les valeurs 0, 1, 12 et 13 ainsi que, possiblement, une valeur très grande (positive et négative)

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Exemple avec une condition logique Le train d’attérissage d’un avion doit être déployé si l’avion est à moins de 2 minutes de l’attérissage ou du décollage ou si il se trouve à moins de 2000 pieds du sol. Si la visibilité est de moins de 1000 pieds, alors le train d’attérissage doit être déployé lorsque l’avion est à moins de 3 minutes du décollage ou de l’attérissage ou si il vol à moins de 2500 pieds du sol. Une condition logique permet de tester si le train est déployé lorsqu’il le faut. Afin de tester cette condition, il y aura 108 classes d’équivalence.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality14 Exemple d’une condition logique avec erreur if(!landingGearDeployed && (min(now-takeoffTime,estLandTime-now))< (visibility < 1000 ? 180 :120) || relativeAltitude < (visibility < 1000 ? 2500 :2000) ) { throw new LandingGearException(); } Trouver le défaut dans le code suivant:

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Écrire des cas de tests et des plans d’inspection Un cas de test (test case) est une suite d’instructions permettant de détecter un défaut particulier dans un logiciel. Un cas de test peut inclure plusieurs tests. Chaque test implique l’exécution du système avec des valeurs particulières.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality16 Test plans A test plan is a document that contains a complete set of test cases for a system —Along with other information about the testing process. The test plan is one of the standard forms of documentation. If a project does not have a test plan: —Testing will inevitably be done in an ad-hoc manner. —Leading to poor quality software. The test plan should be written long before the testing starts. You can start to develop the test plan once you have developed the requirements.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality17 Information à inclure dans un cas de test A. Identification et classification: —Chaque cas de test devrait être identifié par un numéro et par un titre descriptif. —Le système, sous-système ou module testé doit être clairement identifié. —L’importance du test doit être indiqué. B. Instructions: —Donner des instructions claires au testeur. —Possiblement référer à une documentation pertinente. C. Résultat attendu: —Décrire les résultats à attendre en réponse aux entrées. —Le testeur doit rapporter une erreur si une défaillance se produit. D. Nettoyage (au besoin): —Donner les instructions à suivre afin de ramener le système à son état normal.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality18 Niveau d’importance des cas de test Niveau 1: —Test critique. —Vérifie si le système peut s’exécuter de facon correcte. —En cas d’échec, on ne peut poursuivre les autres tests. Niveau 2: —Test général. —Vérifie des fonctions spécifiques du système. —En cas d’échec on peut poursuivre les tests concernant les autres aspects du système. Niveau 3: —Test spécifique. —Vérification d’éléments de moindre importance. —Le système est fonctionnel mais n’est pas complet.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality19 Determiner les cas de test par énumération des attributs du système Les cas de test doivent doivent couvrir tous les aspects mentionnés dans les spécification. Chaque détail mentionné dans les spécifications est un attribut. —Un attribut est quelque chose qui peut être testé. —Il faut donc énumérer ces attributs afin de créer les tests. —Lire le document de spécifications et encercler tous les attributs identifiés. Toutefois, plusieurs attributs sont implicites, donc il ne sont pas explicitement mentionnés dans les spécifications.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Stratégies de test pour un système de grande taille Test Big bang versus test d’intégration Dans un test big bang, le système est testé comme une unité Il est toutefois préférable de tester un système de facon incrémentale: —Tester chaque sous-système de facon isolée —Intégrer graduellement ces sous-système jusqu’à arriver au système complet —Les tests incrémentaux peut être effectués de facon horizontale ou verticale -Les tests horizontaux sont possibles lorsque le système est constitué de sous-applications relativement indépendantes

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality21 Tests de haut en bas D’abord tester les interfaces utilisateur. Les fonctionnalités sousjacentes sont simulés à l’aide de stubs. —Un stub est une portion code retournant des valeurs fictives pour des requêtes effectuées par les couches de plus haut niveau. —Aucun calcul réel n’est effectué. A mesure que les tests sont réussit, on descend graduellement vers les couches de plus bas niveau.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality22 Tests de bas en haut Débuter par les couches de plus bas niveau. Il faut alors concevoir des pilotes (drivers) qui testeront ces couches de plus bas niveau. —Les pilotes sont des programmes simples générant des données servant à tester les couches de plus bas niveaux.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality23 Tests en sandwich Les tests en sandwich est une approche hybride. Les interfaces sont testés avec des stubs. Les fonctions de plus bas niveau sont testés à l’aide de pilotes. Lorsque le système est complet, ce sont seulement les couches mitoyennes qui demeurent à tester.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality24 Exemples de tests incrémentaux

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality25 Le cycle de tests Quand un défaillance est identifiée: Un rapport est créé afin de documenter cette défaillance. Une priorité est attribuée à cette défaillance. Les défaillances de basse priorité sont incluses dans une liste (known bugs list). Un développeur se voit attribuer la responsabilité de réparer une défaillance. Une nouvelle version du système est alors créée.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality26 L’effet d’entrainement Il arrive souvent que la correction d’une erreur entraine d’autres erreurs Le développeur corrigeant l’erreur ne connait pas nécessairement toutes les ramifications du système Ce développeur peut aussi faire des erreurs La fiabilité du système graduellement régresse

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality27 Tests de régression Il peut être couteux de lancer tous les tests à chaque fois qu’une modification est apportée au système. Alors seul un sous-ensemble de tests pré-identifié doit être lancé. Ce processus s’appelle tests de régression. Les tests de régression sont minutieusement choisis de facon à bien couvrir l’ensemble des fonctions du système. La ‘loi’ de conservation des bogues: Le nombre de bogues dans un système est proportionnel au nombre de bogues déjà réparés

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality28 Les tests effectués par les utilisateurs et les clients Test Alpha —Effectué par les utilisateurs sous la supervision de l’équipe de développement. Test Beta —Effectué par l’utilisateur dans son environnement normal de travail. —Souvent recrutés à partir d’une liste de clients priviliégé ou experts. —Un open beta release est une version non finale mis à disposition de la population générale. Test d’acceptation —Effectué par le client, à son initiative.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Inspections L’inspection est une activité au cours de laquelle, des responsables désignés examinent le code source ou la documentation produite à la recherche de défauts. Normallement, l’inspection se fait lors de réunion prévues à cet effet —il arrive aussi que l’inspection soit réalisée par une seule personne.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality30 Roles dans l’équipe d’inspection L’auteur Le modérateur. —Organise la réunion. —Veille au bon déroulement. Le secrétaire. —Prend note des défauts identifiés. Paraphraseurs. —Parcours le document en y apportant ses explications —Ne doit pas être l’auteur

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality31 Principes de l’inspection Tous les documents doivent être inspectés —code, design, plan de tests, spécifications S’assurer de l’efficacité et de l’expérience de l’équipe —entre deux et cinq personnes —incluant des développeurs d’expérience Les participants doivent se préparer à l’avance Seuls les documents prêts sont inspectés —pas de versions préliminaires ou inachevées Identifier les défauts, ne pas perdre du temps à expliquer comment les résoudre Prendre son temps Ré-inspecter à nouveau lorsque les défauts représentent disons 20% du document

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality32 L’inspection est un processus entre pairs Les patrons ne devrait pas y participer Permet une meilleure ouverture sans crainte de répercussions C’est un travail d’équipe qui vise à produire de meilleurs documents Le but n’est pas de blamer quelqu’un ou de trouver des coupables

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality33 Le déroulement de l’inspection 1.Le modérateur distribue les documents. 2.Les participants se prépare à l’avance. 3.Lorsque la réunion débute, le modérateur explique la procédure qui sera suivie. 4.Les paraphraseurs décrivent le document en l’expliquant dans leurs mots. puisque le paraphraseur n’est pas l’auteur, il devrait décrire ce qu’il voit, non pas ce qu’il voulait dire. 5. Chacun déclare les défauts qu’il repère.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality34 Doit-on tester avant d’inspecter? Il est bon d’inspecter le logiciel avant de le tester. De nombreuses erreurs sont ainsi plus facilement identifiées. Si le test se fait d’abord et que plusieurs défauts sont identifiés à l’inspection, il faut alors recommencer les test.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Principale cause des erreurs Analyse des causes d’erreur Déterminer les facteurs ayant menés aux défauts, tels que: —Manque d’expérience —Horaire trop serré —Design mal concu

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality36 Mesure de la qualité La qualité de votre processus de développement peut se mesurer indirectement à partir de Le nombre de défaillances recontrées par vos utilisateurs. Le nombre de défaillances trouvées lors des tests. Le nombre de défauts trouvés lors des inspections. Le pourcentage de code qui est ré-utilisé des projets précédents. Le nombre d’appels recus de la part des utilisateurs

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality37 Analyse post-mortem Il est toujours bon de refaire l’historique d’un projet terminé afin d’en tirer des lecons, Examiner le processus de développement suivi Revoir les décisions de design prisent Identifier les choses qui auraient pu être mieux menées Déterminer comment les prochains projets pourraient bénéficier de ces observations

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality Difficultés et risques dans l’assurance de qualité Il peut être facile d’oublier de tester des aspects importants dans un logiciel: —Exécuter le logiciel quelques fois n’est pas suffisant. Il peut y avoir un conflit entre livrer rapidement et assurer un niveau de qualité supérieur —Créer une équipe dédiée d’assurance de qualité. —Compiler des statistiques sur la qualité de la production. —Allouer suffisamment de temps pour les activités de tests.

© Lethbridge/Laganière 2005 Chapter 10: Testing and Inspecting for High Quality39 Difficultés et risques dans l’assurance de qualité Chacun a une perception et une attitude différente vis-à- vis l’atteinte de la qualité —Former votre équipe aux procédures de tests. —Donner de la retro-action à votre équipe sur l’assurance de qualité. —Chacun devrait avoir déjà travaillé dans une équipe d’assurance de qualité