Tests logiciels

Debugging
Debugging
C’est l’étape qui suit la découverte de défaillance dans un logiciel

Inclut deux étapes :

- Déterminer la nature et l’emplacement de l’erreur dans le programme

- Corriger l’erreur (fix the error)
Premier Bug documenté
"First actual case of bug being found,". The engineers who found the moth were
the first to literally "debug" a machine.

Source : https://www.nationalgeographic.org/thisday/sep9/worlds-first-computer-bug/
Debugging : la tâche la moins aimée par les développeurs
L’obstacle de l’égo : le debugging confirme que les programmeurs commettent
des erreurs

Très exigeant mentalement

Généralement effectué sous pression

L’erreur peut être n’importe où dans le programme

Parler de votre expérience
Comment faites vous le debogage?
Debugging par Brute Force
Implémentée soit avec les outils automatiques de debugging ou en ajoutant des
commandes “print” partout dans le programme

Méthode aléatoire

Produit une quantité massive de données

Exige peu de réflexion - la méthode la moin exigeante mentalement

Pas efficace

Ignore le processus de réflexion

Systematic debugging
Reproduire le Bug

Trouver le bug en utilisant la méthode scientifique

1. Étudier les données

2. Faire une hypothèse
3. Faire des expériences
4. Répéter

Corriger l’erreur

Référence : http://web.mit.edu/6.031/www/fa17/classes/13-debugging/
Reproduire le Bug
Trouver le test minimal répétable qui produit la défaillance

- Sera utilisé plusieurs fois lors de la recherche et la correction du Bug

- Sera rajouté aux tests de régression après la correction du Bug
Exemple
Un utilisateur entre le text des pièces de Shakespeare dans la méthode et
découvre qu’au lieu de retourner un terme commun comme “the” ou “a” la
méthode retourne “e”

Les pièces de Shakespeare incluent 100 000 ligne contenant plus de 800 000
mots → il est plus simple de minimiser la taille de l’entrée
Méthodes de réduction des données
Exemple de Shakespeare :

- Est-ce que la première moitié des pièces cause le même problème?

(dichotomie - binary search)
- Est ce qu’une seule pièce cause le problème?
- Est ce qu’un seul discours cause le problème?
Exercice 1
Exercice 2
Pour localiser un bug
1. Étudier les données : Regarder l'entrée de test qui provoque le bug, les
résultats incorrects, les assertions ayant échoué et les traces qui en résultent.
2. Faire une hypothèse : Proposer une hypothèse cohérente avec toutes les
données, sur l'endroit où le bug pourrait être, ou où il ne peut pas être.
3. Faire des expériences : Concevoir et exécuter une expérience qui teste
l’hypothèse. Il est bon de faire de l'expérience une observation dans un
premier temps - une sonde qui collecte des informations mais perturbe le
moins possible le système.
4. Répéter : Ajouter les données recueillies lors de l’expérience et faire une
nouvelle hypothèse.
Étudier les données
- Lire le stack trace
- Le dernier appel apparaît en haut
- L’appel le plus ancien apparaît en bas
- L’appel en haut/bas peut être :
- Votre code
- Lancé d’une librairie
- appelée par le code que vous avez écrit
- Qui appelle le code que vous avez écrit

→ votre propre code (où le bug se trouve probablement) est souvent quelque part
au milieu du stack trace
Exemple de stack trace
Faire une hypothèse
Les hypothèses devraient porter sur l'endroit où se trouve réellement le bug (ou
non) et ce qui pourrait l'avoir causé
Slicing
Trouver les parties du programme qui ont contribué au calcul d’une certaine valeur
Prioriser les hypothèses
- un ancien code bien testé est probablement plus fiable que le code
récemment ajouté.
- Le code de la bibliothèque Java est probablement plus fiable que votre code
- Le compilateur et l'environnement d'exécution Java, la plate-forme du
système d'exploitation et le matériel sont de plus en plus fiables, car ils sont
très utilisés et testés..
Faire des expériences
- Utiliser l'expérience pour tester l’hypothèse
- Possibilité d’utiliser les instructions “print”
- Ne pas oublier de supprimer le print à la fin
- breakpoints
Utilisation du debugger
Permet d’observer l'exécution du programme

Un débogueur permet d’exécuter un programme pas à pas et l’arrêter aux points

d'arrêt

Permet d’observer la définition, la modification et l'utilisation des variables

Debugging in Eclipse
Répéter
Après l'expérience, réfléchir aux résultats et modifier l’hypothèse

Si l’observation est en désaccord avec les prédictions de l'hypothèse :

- rejeter l’hypothèse
- faire une nouvelle hypothèse

Si l'observation correspond à la prédiction:

- affiner l'hypothèse (concernant l'emplacement et la cause du bug)

Répéter le processus avec la nouvelle hypothèse

Débogage par intuition (Debugging by gut feeling)
Dans une certaine mesure, les ingénieurs logiciels expérimentés développent une
capacité à "sentir" la cause d'une erreur"
Dans de nombreux cas, le débogage par intuition est plus rapide que n'importe quel
procédure de débogage systématique
Limites :
- Il faut arrêter le débogage intuitif au bon moment lorsqu'il n'y parvient pas...
- ... puis passer au débogage systématique
Procédure suggérée :
- Pour une durée strictement limitée, debugger par intuition
- Si succès : Eurêka ! sinon : arrêter et démarrer le débogage systématique
Techniques de réparation d’erreur
Corriger l’erreur et non pas le symptôme

Où il y a un bug, il y a probablement un autre

Vérifier que le problème n’existe plus

Vérifier qu’il n’y a pas d’effets secondaires : utiliser les tests de régression
Autres conseils
Si on arrive à une impasse :

- Expliquer le problème à quelqu’un d’autre

- Rubber duck debugging
- Parler du problème aide à mieux le comprendre

- Laisser le problème de côté pour un moment

Ne jamais oublier que

“Stuckness shouldn’t be avoided. It’s the psychic predecessor of all real understanding.
An egoless acceptance of stuckness is a key to an understanding of all Quality, in
mechanical work as in other endeavors.”

— Robert M. Pirsig
Issue tracking system
Système de gestion des incidents

Système qui permet de gérer les bug/changement

Utilisation de ticket

Documenter le problème dans le ticket

suivre l’avancement
ticket
Un ticket = un rapport sur le problème

Structure:

- steps to reproduce
- Expected results / actual results (put triangle (1,1,1) expected…)

Assigned to someone (attribuer)

Type(bug, feature request), severity(blocker, major, minor)

Examples: Jira, bugzilla, gitHub

Video -
https://www.youtube.com/watch?v=rR4n-0KYeKQ
Continuous integration
Continuous integration is a software development process where developers
integrate the new code they've written more frequently throughout the
development cycle, adding it to the code base at least once a day. Automated
testing is done against each iteration of the build to identify integration issues
earlier.

[source: https://www.ibm.com/topics/continuous-integration]
 Version Control System
Système de gestion de version
Version control
la pratique du suivi et de la gestion des modifications apportées au code logiciel.
Les systèmes de contrôle de version sont des outils logiciels qui aident les
équipes logicielles à gérer les modifications apportées au code source au fil du
temps

Le logiciel de contrôle de version conserve une trace de chaque modification du

code dans un type spécial de base de données. Si une erreur est commise, les
développeurs peuvent revenir en arrière et comparer les versions antérieures du
code pour aider à corriger l'erreur tout en minimisant les perturbations pour tous
les membres de l'équipe.
branching
https://learngitbranching.js.org/