Comment corrigez-vous un bogue que vous ne pouvez pas répliquer?
La question dit tout. Si plusieurs utilisateurs signalent un bogue, mais qu'il n'y a aucun enregistrement du bogue survenu dans le journal, le bogue ne peut pas être répété, peu importe la difficulté avec laquelle vous essayez, comment le résoudre? Ou même pouvez-vous?
Je suis sûr que cela est arrivé à beaucoup d'entre vous. Qu'avez-vous fait dans cette situation et quel a été le résultat final?
Edit: Je suis plus intéressé par ce qui a été fait sur un bogue introuvable , pas un bogue insoluble. Les bogues non résolus sont tels que vous savez au moins qu’il ya un problème et que vous avez un point de départ, dans la plupart des cas, pour le rechercher. Que faites-vous dans le cas d'un impossible à trouver? Pouvez-vous même faire quelque chose du tout?
Ceux-ci sont connus comme Heisenbugs .
La langue
Différents langages de programmation auront leur propre style de bogues.
C
L'ajout d'instructions de débogage peut rendre le problème impossible à dupliquer parce que l'instruction de débogage elle-même déplace les pointeurs (suffisamment loin pour éviter un SEGFAULT). Les problèmes de pointeur sont un cauchemar à suivre et à répliquer, mais il existe des débogueurs (tels que GDB et DDD ) qui peuvent aider.
Java
Une application comportant plusieurs threads peut uniquement afficher ses bogues avec un calendrier ou une séquence d'événements très spécifique. Une implémentation incorrecte des accès concurrents peut provoquer des blocages dans des situations difficiles à répliquer.
JavaScript
Certains navigateurs Web sont connus pour les fuites de mémoire. Le code JavaScript qui fonctionne correctement dans un navigateur peut entraîner un comportement incorrect dans un autre navigateur. L'utilisation de bibliothèques tierces rigoureusement testées par des milliers d'utilisateurs peut s'avérer utile pour éviter certains bogues obscurs.
Environnement
En fonction de la complexité de l'environnement dans lequel l'application (qui a le bogue) est en cours d'exécution, le seul recours possible pourrait consister à simplifier l'environnement. Est-ce que l'application s'exécute:
- sur un serveur?
- sur un bureau?
- dans un navigateur web?
Dans quel environnement l'application génère-t-elle le problème?
- développement?
- tester?
- production?
Quittez les applications superflues, supprimez les tâches en arrière-plan, arrêtez tous les événements planifiés (tâches cron), supprimez les plug-ins et désinstallez les add-ons du navigateur.
La mise en réseau
La mise en réseau est essentielle pour de nombreuses applications:
- Assurez des connexions réseau stables, y compris des signaux sans fil.
- Le logiciel se reconnecte-t-il correctement après une défaillance du réseau?
- Est-ce que toutes les connexions sont correctement fermées afin de libérer les descripteurs de fichier?
- Est-ce que les gens utilisent la machine qui ne devrait pas l'être?
- Des périphériques non autorisés interagissent-ils avec le réseau de la machine?
- Y a-t-il des usines ou des tours de radio à proximité pouvant causer des interférences?
- La taille et la fréquence des paquets se situent-elles dans les limites nominales?
- Tous les périphériques réseau conviennent-ils à une utilisation intensive de la bande passante?
Cohérence
Éliminez autant d'inconnues que possible:
- Isoler les composants architecturaux.
- Supprimez les éléments non essentiels ou éventuellement problématiques (conflictuels).
- Désactiver différents modules d'application.
Supprimez toutes les différences entre production, test et développement. Utilisez le même matériel. Suivez exactement les mêmes étapes, parfaitement, pour configurer les ordinateurs. La cohérence est la clé.
Enregistrement
Utilisez des quantités massives de journalisation pour corréler les événements temporels survenus. Examinez les journaux pour détecter les erreurs évidentes, les problèmes de synchronisation, etc.
Matériel
Si le logiciel semble correct, considérez les défauts matériels:
- Les connexions physiques au réseau sont-elles solides?
- Y a-t-il des câbles desserrés?
- Les copeaux sont-ils bien assis?
- Est-ce que tous les câbles ont des connexions propres?
- L'environnement de travail est-il propre et exempt de poussière?
- Des câbles ou des appareils cachés ont-ils été endommagés par des rongeurs ou des insectes ?
- Y a-t-il des blocs défectueux sur les lecteurs?
- Les ventilateurs de la CPU fonctionnent-ils?
- La carte mère peut-elle alimenter tous les composants? (CPU, carte réseau, carte vidéo, lecteurs, etc.)
- Est-ce que une interférence électromagnétique pourrait être le coupable?
Et surtout pour embarqué:
- Alimentation insuffisante?
- Contamination de la carte?
- Mauvais joints de soudure/mauvais reflux?
- Le processeur n'est pas réinitialisé lorsque les tensions d'alimentation sont hors tolérance?
- Mauvaises réinitialisations, car les Rails d'approvisionnement sont rétro-alimentés par les ports d'E/S et ne se déchargent pas complètement?
- Latch-up?
- Broches d'entrée flottantes?
- Marges de bruit insuffisantes (parfois négatives) aux niveaux logiques?
- Marges temporelles insuffisantes (parfois négatives)?
- Moustaches en étain ?
- Dommages causés par les décharges électrostatiques?
- ESD bouleverse?
- Errata de puce?
- Mauvais usage de l'interface (par exemple, I2C hors carte ou en présence de signaux haute puissance)?
- Conditions de course?
- Composants contrefaits?
Réseau vs. Local
Que se passe-t-il lorsque vous exécutez l'application localement (c'est-à-dire pas sur le réseau)? Est-ce que d'autres serveurs rencontrent les mêmes problèmes? La base de données est-elle distante? Pouvez-vous utiliser une base de données locale?
Micrologiciel
Entre le matériel et le logiciel est un firmware.
- Le BIOS de l'ordinateur est-il à jour?
- La batterie du BIOS fonctionne-t-elle?
- L'horloge du BIOS et l'horloge système sont-elles synchronisées?
Temps et statistiques
Les problèmes de synchronisation sont difficiles à suivre:
- Quand le problème survient-il?
- À quelle fréquence?
- Quels autres systèmes fonctionnent à ce moment?
- L'application est-elle sensible au temps (par exemple, des jours bissextiles ou des secondes bissextiles poseront-ils des problèmes)?
Rassembler des données numériques difficiles sur le problème. Un problème qui, au premier abord, peut sembler aléatoire, pourrait en réalité avoir une tendance.
Gestion du changement
Parfois, des problèmes apparaissent après une mise à niveau du système.
- Quand le problème a-t-il commencé?
- Qu'est-ce qui a changé dans l'environnement (matériel et logiciel)?
- Que se passe-t-il après la restauration d'une version précédente?
- Quelles différences existe-t-il entre la version problématique et la bonne version?
Gestion de la bibliothèque
Différents systèmes d'exploitation utilisent différentes méthodes de distribution des bibliothèques en conflit:
- Windows a DLL Enfer.
- Unix peut avoir de nombreux liens symboliques brisés.
- Les fichiers de bibliothèque Java peuvent être tout aussi cauchemardesques à résoudre.Effectuez une nouvelle installation du système d'exploitation et n'incluez que les logiciels de prise en charge requis pour votre application.
Java.
Assurez-vous que chaque bibliothèque est utilisée qu'une seule fois. Parfois, les conteneurs d'application ont une version de bibliothèque différente de l'application elle-même. Cela pourrait ne pas être possible de répliquer dans l'environnement de développement.
Utilisez un outil de gestion de bibliothèque tel que Maven ou Ivy .
Débogage.
Codez une méthode de détection qui déclenche une notification (par exemple, journal, e-mail, pop-up, bip de bip) lorsque le bogue survient. Utilisez des tests automatisés pour soumettre des données dans l'application. Utilisez des données aléatoires. Utilisez des données qui couvrent les cas Edge connus et possibles. Finalement, le bogue devrait réapparaître.
.
Sleep
Examen du code.
Parcourez le code, ligne par ligne, et décrivez ce que chaque ligne fait à vous-même, à un collègue ou à un canard en caoutchouc . Cela peut permettre de mieux comprendre comment reproduire le bogue.
Rayonnement cosmique.
Les rayons cosmiques peuvent retourner des bits. Ce n'est pas aussi grave qu'un problème dans le passé en raison de la vérification d'erreur moderne de la mémoire. Les logiciels destinés au matériel qui quitte la protection de la Terre sont soumis à des problèmes impossibles à reproduire du fait du caractère aléatoire du rayonnement cosmique.
Outils.
Rare mais cela arrive, en particulier pour les outils de niche (par exemple, un compilateur de micro-contrôleurs C souffrant d’un débordement de la table des symboles)
Infrequent but it happens, especially for niche tools (e.g. a C micro-controller compiler suffering from a symbol table overflow).
Si c'est une application graphique, c'est inestimable de regarder le client générer l'erreur (ou essayer de). Ils feront sans doute quelque chose que vous n'auriez jamais deviné (pas à tort, mais différemment).
Sinon, concentrez-vous sur la journalisation dans cette zone. Connectez-vous à peu près tout (vous pouvez le retirer plus tard) et demandez à votre application de vider son environnement. par exemple. type de machine, type VM, codage utilisé.
Votre application indique-t-elle un numéro de version, un numéro de build, etc.? Vous en aurez besoin pour déterminer avec précision la version en cours de débogage (ou non!).
Si vous pouvez instrumenter votre application (par exemple en utilisant JMX si vous êtes dans le monde Java), instrumentez la zone en question. Statistiques de magasin, par exemple Requêtes + paramètres, durée, etc. Utilisez des tampons pour stocker les dernières "n" requêtes/réponses/versions d'objets/peu importe, et extrayez-les lorsque l'utilisateur signale un problème.
Si vous ne pouvez pas le répliquer, vous pouvez le réparer, mais vous ne pouvez pas savoir que vous l'avez corrigé.
J'ai expliqué le mieux possible comment le bogue avait été déclenché (même si je ne savais pas comment cette situation pourrait se produire), corrigé le problème et assuré que si le bogue refait surface, nos mécanismes de notification laisseraient un futur développeur connaître les choses que j'aurais aimé savoir. En pratique, cela signifiait ajouter des événements de journal lorsque les chemins pouvant déclencher le bogue étaient croisés et que les métriques des ressources associées étaient enregistrées. Et, bien sûr, en vous assurant que les tests ont bien exercé le code en général.
Décider quelles notifications ajouter est une question de faisabilité et de triage. Il en va de même pour le temps que les développeurs doivent consacrer au bogue. On ne peut pas y répondre sans savoir à quel point le bogue est important.
J'ai eu de bons résultats (ne sont plus apparus, et le code était meilleur pour cela), et mauvais (passé trop de temps à ne pas résoudre le problème, que le bogue soit corrigé ou non). C'est à cela que servent les estimations et les priorités.
Parfois, je dois juste m'asseoir et étudier le code jusqu'à ce que je trouve le bogue. Essayez de prouver que le bogue est impossible, et dans le processus, vous pouvez trouver où vous pouvez vous tromper. Si vous parvenez à vous convaincre que c'est impossible, supposez que vous vous êtes trompé quelque part.
Il peut être utile d’ajouter une série de vérifications d’erreur et d’affirmations pour confirmer ou infirmer vos croyances/hypothèses. Quelque chose peut échouer que vous ne vous attendez jamais à.
Cela peut être difficile et parfois presque impossible. Mais selon mon expérience, vous pourrez tôt ou tard être en mesure de reproduire et de corriger le bogue si vous y consacrez suffisamment de temps (si le temps passé en vaut la peine, c'est une autre affaire).
Suggestions générales qui pourraient aider dans cette situation.
- Ajoutez plus de journalisation, si possible, afin d'avoir plus de données la prochaine fois que le bogue apparaît.
- Demandez aux utilisateurs s’ils peuvent reproduire le bogue. Si c'est le cas, vous pouvez leur demander de le reproduire tout en surveillant par-dessus leur épaule et, espérons-le, de savoir ce qui déclenche le bogue.
Faites des changements aléatoires jusqu'à ce que quelque chose fonctionne :-)
Pense. Difficile. Enfermez-vous, n'admettez pas d'interruptions.
Une fois, j'ai eu un bug où la preuve était un vidage hexadécimal d'une base de données corrompue. Les chaînes de pointeurs étaient systématiquement foutues. Tous les programmes de l'utilisateur et notre logiciel de base de données ont fonctionné sans faute lors des tests. Je l'ai regardé pendant une semaine (c'était un client important), et après avoir éliminé des dizaines d'idées possibles, je me suis rendu compte que les données étaient réparties sur deux fichiers physiques et que la corruption s'était produite à l'endroit où les chaînes s'étaient croisées. J'ai réalisé que si une opération de sauvegarde/restauration échouait à un point critique, les deux fichiers pourraient se retrouver "désynchronisés" et être restaurés à des moments différents. Si vous exécutiez ensuite l'un des programmes du client sur des données déjà corrompues, cela produirait exactement les chaînes de pointeurs nouées que je voyais. J'ai ensuite présenté une séquence d'événements reproduisant exactement la corruption.
modifiez le code à l'endroit où vous pensez que le problème se produit, afin que des informations de débogage supplémentaires soient enregistrées quelque part. quand cela se produira la prochaine fois, vous aurez ce dont vous avez besoin pour résoudre le problème.
Il existe deux types de bogues que vous ne pouvez pas répliquer. Le genre que vous avez découvert et le genre que quelqu'un d'autre a découvert.
Si vous avez découvert le bogue, vous devriez pouvoir le répliquer. Si vous ne pouvez pas le répliquer, vous n'avez simplement pas pris en compte tous les facteurs contribuant au bogue. C'est pourquoi chaque fois que vous avez un bogue, vous devriez le documenter. Enregistrez le journal, obtenez une capture d'écran, etc. Si vous ne le faites pas, comment pouvez-vous même prouver que le bogue existe réellement? Peut-être que c'est juste un faux souvenir?
Si quelqu'un d'autre a découvert un bogue et que vous ne pouvez pas le répliquer, demandez-lui évidemment de le répliquer. S'ils ne peuvent pas le répliquer, essayez de le répliquer. Si vous ne pouvez pas le répliquer rapidement, ignorez-le.
Je sais que ça a l'air mauvais, mais je pense que c'est justifié. Le temps qu'il vous faudra pour répliquer un bogue découvert par quelqu'un d'autre est très important. Si le bogue est réel, cela se reproduira naturellement. Quelqu'un, peut-être même vous, tombera à nouveau dessus. S'il est difficile à reproduire, il est également rare et ne causera probablement pas trop de dégâts si cela se produit plusieurs fois.
Vous pouvez être beaucoup plus productif si vous passez votre temps à réparer d’autres bogues et à écrire un nouveau code, alors que vous essayez de reproduire un bogue mystère dont vous ne pouvez même pas garantir l’existence. Attendez qu'il apparaisse à nouveau naturellement, vous pourrez alors passer tout votre temps à le réparer, plutôt que de perdre votre temps à essayer de le révéler.
En supposant que vous ayez déjà ajouté toute la journalisation qui, selon vous, aiderait et que cela ne l’a pas été… deux choses viennent à l’esprit:
Travailler à l'envers du symptôme rapporté. Pensez à vous-même… «Je voulais produire le symptôme signalé, quel morceau de code devrais-je exécuter, et comment pourrais-je y arriver, et comment pourrais-je en arriver là? D mène à C mène à B mène à A. Acceptez le fait que si un bogue n'est pas reproductible, les méthodes normales ne vous aideront pas. J'ai dû regarder le code pendant de nombreuses heures avec ce genre de processus de pensée pour trouver des bugs. Habituellement, cela s'avère être quelque chose vraiment stupide.
Rappelez-vous la première loi de Bob sur le débogage: si vous ne trouvez pas quelque chose, c'est que vous cherchez au mauvais endroit :-)
Discutez du problème, lisez le code, souvent beaucoup. Nous le faisons souvent par paires, car vous pouvez généralement éliminer les possibilités analytiquement assez rapidement.
Commencez par regarder quels outils vous avez à votre disposition. Par exemple, les accidents sur une plate-forme Windows vont à WinQual. Ainsi, si tel est votre cas, vous disposez désormais d'informations sur le vidage sur incident. Pouvez-vous utiliser des outils d’analyse statiques permettant de détecter les bogues potentiels, des outils d’analyse d’exécution, des outils de profilage?
Ensuite, regardez l'entrée et la sortie. Quelque chose de similaire à propos des entrées dans les situations où les utilisateurs signalent l'erreur, ou quelque chose de déplacé dans la sortie? Compiler une liste de rapports et rechercher des modèles.
Enfin, comme l'a déclaré David, regardez le code.
Demandez à l'utilisateur de vous donner un accès à distance pour son ordinateur et de tout voir vous-même. Demandez à l'utilisateur de faire une petite vidéo de la façon dont il reproduit ce bogue et de vous l'envoyer.
Bien sûr, les deux ne sont pas toujours possibles, mais s'ils le sont, cela peut clarifier certaines choses. La manière habituelle de rechercher des bogues est toujours la même: séparer les parties susceptibles de causer un bogue, essayer de comprendre ce qui se passe, réduire l’espace de code susceptible de provoquer le bogue.
Il existe des outils tels que gotomeeting.com, que vous pouvez utiliser pour partager l'écran avec votre utilisateur et observer le comportement. Il pourrait y avoir beaucoup de problèmes potentiels comme le nombre de logiciels installés sur leurs machines, certains utilitaires d’outils en conflit avec votre programme. Je pense que gotomeeting n'est pas la seule solution, mais il pourrait y avoir des problèmes de dépassement de délai, problème de connexion Internet lente.
La plupart du temps, je dirais que les logiciels ne vous signalent pas les messages d'erreur corrects, par exemple, dans le cas de Java et de C #, surveillez toutes les exceptions. Les bogues d'interface utilisateur sont difficiles à résoudre, sauf si vous utilisez des outils de bureau à distance. Et la plupart du temps, il pourrait y avoir un bogue dans les logiciels tiers.