Indications pour le débogage
Mise à jour : novembre 2007
Les indications suivantes fournissent plusieurs techniques pour le débogage du code.
Obligatoire
Apprenez à utiliser les outils de débogage.
Vous devez connaître et maîtriser les outils de débogage. Pour plus d'informations, consultez Débogage dans Visual Studio.
Sachez où vos symboles sont archivés.
Les symboles de chaque produit doivent être archivés sur les serveurs de symboles. Vous devez juste savoir où se trouvent ces serveurs. Pour plus d'informations, consultez « How to Use the Microsoft Symbol Server » dans MSDN Library.
Analysez et corrigez les bogues qui bloquent les processus.
Pour les utilisateurs, une application qui cesse de répondre (se bloque) équivaut à un arrêt brutal. Dans les deux cas, les utilisateurs perdent leur travail et doivent recommencer. Toutefois, les blocages étaient considérés comme beaucoup plus difficiles à analyser et à corriger. Ce n'est plus le cas pour un large pourcentage de blocages de processus. Utilisez les outils et les techniques les plus récents pour résoudre ces problèmes. Pour plus d'informations, consultez « How to Troubleshoot Program Faults with Dr. Watson » dans MSDN Library.
Sachez comment déboguer un minidump.
La plupart des testeurs et des clients bloquent votre code sans bénéficier d'un débogueur joint au programme. Si vous ne pouvez pas reproduire facilement le problème, vous ne disposerez que d'un minidump. Apprendre à déboguer en utilisant un minidump est essentiel. Pour plus d'informations, consultez « Minidump Files » dans MSDN Library.
Sachez comment récupérer une pile (ou stack) endommagée.
La récupération d'une pile endommagée est complexe, mais essentielle parce qu'un grand nombre de défaillances réelles ont des piles qui paraissent incompréhensibles. Pour plus d'informations, consultez « Troubleshooting Common Problems with Applications: Debugging in the Real World » dans MSDN Library.
Évitez
De croire que les tests trouveront tous les bogues.
Les tests ne seront jamais capables de trouver tous les bogues. Ce n'est pas possible. Le code est trop complexe. Même si les tests pouvaient trouver tous les bogues, vous n'auriez jamais le temps de les corriger tous. Vous devez donc concevoir votre produit afin qu'il ne contienne pas de bogues dès le départ. Épargnez-vous la difficulté d'avoir à les corriger ultérieurement. Vous devez prendre la responsabilité de la qualité de votre code. L'équipe de test ne fait que vérifier la qualité de votre code. Ne vous reposez pas sur les testeurs pour réparer vos erreurs.
Recommandé
Sachez comment déboguer des applications multithread.
L'introduction de threads dans un programme peut entraîner son échec de différentes manières. Tout que vous faites dans un environnement monothread pour déboguer des applications devient plus important à mesure que le nombre de threads augmente. Par exemple, vous ne pouvez pas toujours intercepter l'erreur à l'endroit où elle se produit. Généralement, l'erreur est détectée ultérieurement, probablement dans un autre thread. Dans ces situations, vous ne pouvez même pas remonter la pile des appels pour rechercher le problème ; l'erreur s'est produite dans un autre thread, avec une autre pile. D'une manière générale, un comportement proactif favorisera le processus de débogage.
Apprenez à effectuer un débogage distant.
On parle de débogage distant lorsque vous voulez déboguer un problème qui se produit sur un autre ordinateur tout en continuant à travailler sur votre propre ordinateur. Les développeurs le font fréquemment lorsqu'un segment de code s'exécute sans problème sur leur propre ordinateur, mais se bloque sur un autre système. Ils peuvent le déboguer à distance sur l'autre système, sans se déplacer. Pour plus d'informations, consultez Programme d'installation du débogage distant.
Apprenez à déboguer sur des serveurs de production.
Les procédures de débogage sont différentes lorsque vous essayez de déboguer le code sur un serveur de production auquel les clients accèdent. Cette méthode devient plus courante car le code est de plus en plus écrit pour le Web. Pour plus d'informations, consultez « Troubleshooting Common Problems with Applications: Debugging in the Real World » dans MSDN Library.
Commentez toutes les corrections de bogues.
Lorsque vous corrigez une erreur, incluez dans le code un numéro de version, un ID de bogue et votre alias. Si quelqu'un examine le code par la suite et a une question à propos de la correction, il pourra ainsi vous contacter pour obtenir des informations.
Examinez toutes les corrections de bogues.
Vous devez réviser toutes les corrections dans le code. Demandez à au moins une personne d'examiner votre code.
Vérifiez les corrections des bogues pernicieux avant l'archivage.
Évitez de corriger le même bogue deux fois. Utilisez une génération pour vérifier que la correction est correcte, surtout pour les bogues pernicieux.
Utilisez un document de version de test pour signaler toutes les corrections de bogue.
Coordonnez-vous avec l'équipe de test en documentant toutes vos corrections de bogue dans un document de version de test (TRD) et en l'envoyant à l'équipe de test par courrier électronique.
Utilisez le Symbol Server pour indexer et archiver vos symboles de produit.
En autorisant le Symbol Server à indexer et à archiver vos symboles de produit, vous facilitez et vous accélérez le débogage à partir de n'importe quel système, y compris les systèmes des clients.
Non recommandé
Corriger les bogues des tiers sans les en informer.
Chercher et essayer de corriger les bogues des autres est une très bonne pratique. Cela vous permet d'approfondir votre connaissance du code et d'aider les autres. La seule chose que vous ne devez pas faire est archiver une correction sans informer le propriétaire du code au sujet de cette correction.
Corriger un bogue avec la mention « non reproductible » sans essayer la même version dans le même environnement.
Vous devez revenir à la version du produit dans laquelle le bogue a été trouvé. Ne supposez pas que s'il ne se produit pas dans la version actuelle du produit, le bogue a dû être corrigé car ce n'est pas forcément le cas. Le code a pu être modifié et simplement masquer le bogue. Si vous analysez un bogue jusqu'à ce que vous le voyiez se produire, vous pourrez trouver la cause profonde du problème et le résoudre afin que le bogue ne se produise plus sur aucun ordinateur.
Voir aussi
Concepts
Indications pour l'écriture de code sécurisé