En tant que qui est relativement nouveau dans l'ensemble de l'appui et de l'environnement de fixation de bugs et un jeune programmeur, je n'avais jamais rencontré un bug qui ne se produit que dans l'environnement WebSphere mais pas sur l'environnement de test localhost, jusqu'à aujourd'hui. Quand j'ai eu pour la première fois ce rapport de bogue, j'ai été confus pourquoi je ne pouvais pas la reproduire sur l'environnement de test localhost. J'ai décidé d'essayer l'environnement de test Webphere pour voir ce qui se passerait et j'ai reproduit avec succès le bogue. Le problème est que je ne peux pas apporter des modifications et construire sur le site WebSphere Test Enviroment. Je ne peux que apporter des modifications à mon environnement local. Compte tenu de ce handicap quelles méthodologies existent pour résoudre ce genre de bugs. Ou y a-t-il même des méthodologies du tout? Des conseils ou une aide sur la manière d'approcher des problèmes comme celui-ci?
3 Réponses :
Les journaux prouvent une aide énorme qui me permettait de trouver le motif de l'endroit où il se cassait. Je vais certainement garder ces conseils à l'esprit à l'esprit pour tous les débogage.
En bref, la méthodologie consiste à isoler et à comprendre les différences entre les environnements et lequel une ou une personne peut causer le problème.
Vérifiez votre construction locale. Assurez-vous que la même version (code et base de données) en tant que test et prod. Si c'est le cas, quelles sont les différences d'environnement qui pourraient affecter le problème que vous voyez? (Multi-noyau, équilibrage de la charge, version du système d'exploitation, version 3rd Bibliothèque). N'exécutez pas localement dans le débogueur, assurez-vous de faire fonctionner une version de sortie (si c'est ce qui est sur le test et prodez) et peut-être même faire un déploiement local plutôt que de bâtir à partir de la source.
Vérifiez si ce sont des données particulières qui pourraient causer le problème. Si vous le pouvez, retirez une copie de la base de données du test sur local et voyez si cela vous permet de reproduire le problème.
Vérifiez avec d'autres développeurs. Voir s'ils peuvent reproduire. la question dans leur environnement. Vérifiez auprès de vos gars QA, obtenez leurs réflexions sur ce qui pourrait causer un tel problème (souvent, ils auront des problèmes "similaires" et pourraient vous donner un indice).
À ce stade, si rien ne vous aide, je vais généralement dans un état profond de zen pour essayer de comprendre ce qui me manque. Mais, il doit y avoir une différence, il vous suffit de le trouver.
Avec les bûches (j'ai comparé les journaux locaux aux journaux de test), prenez le temps de remarquer les différences d'environnement et d'arrêter simplement de penser à ce qui me manque et découvrit l'erreur.
Bien pour vous. Penser profondément sur le problème obtient un mauvais rap parfois, mais cela peut être très efficace. :)
La méthode scientifique s'applique toujours - Vérifiez d'abord vos hypothèses. Si les systèmes sont différents, le problème peut réside dans une sorte de défaut implicite étant différent ou une implémentation différente d'une certaine fonction.
Dans tous les processus de débogage, la localisation est la clé. Vous devez d'abord isoler la zone du problème. Si votre système d'exploitation, vos correctifs, ses bibliothèques et votre logiciel principal sont tous identiques, ce sont probablement les paramètres système (limites pour les sockets, les descripteurs de fichiers, etc.). Si vous savez que vous avez assez d'inodes, de l'espace et de la mémoire sont laissés, ce n'est pas un problème de ressource. Si l'ordinateur est à peine réactif à votre produit interactif, votre charge est trop élevée, ou si vous avez des processus en fuite. N'oubliez pas que chaque processus doit fonctionner et assurez-vous qu'ils ont eu ce dont ils ont besoin.
Il peut également être que le code ne peut tout simplement pas gérer la charge du système de production. Les mécanismes de verrouillage sont une cause très populaire de problèmes dans la production VS Dev / Test Systems, simplement parce que vous ne pouvez pas générer suffisamment de cas de test que vous obtenez gratuitement en production.
La journalisation peut être facilement négligée, mais j'aime aussi ajouter de nombreuses valeurs de débogage dans le code, pour faciliter le débogage. Je ne peux même pas compter combien de fois une variable d'environnement, un chemin ou un symbole brisé a ruiné ma journée, juste pour réaliser que ce serait un correctif trivial si j'ai examiné les valeurs des variables lors de l'exécution, pas seulement en regardant le code statique.
Si tout le reste échoue, ltrace et strace est le meilleur moyen de vraiment regarder ce qui se passe sous la hotte. Ils ne sont pas faciles à lire, mais une fois que vous vous êtes habitué à la manière dont vous avez accéléré des valeurs de retour de SysCalls, vous obtenez un outil de débogage très puissant.