Comment convaincre les membres de l'équipe de l'existence d'un «mandelbug»


20

Nous développons une application; il comprend une bibliothèque développée par un autre codeur, cette bibliothèque communique avec le serveur via plusieurs connexions réseau, et cela implique plusieurs threads travaillant ensemble. Le code côté serveur est assez compliqué et nous n'avons pas accès au code source.

Récemment, j'ai découvert un mandelbug faisant parfois planter une application. Je pouvais le reproduire une fois et obtenir une trace de pile, alors j'ai ouvert un rapport de bogue. Le bogue lui-même est facile à corriger (exception Web non interceptée dans l'un des threads d'arrière-plan, ce qui oblige CLR à terminer le programme).

Le problème est que le développeur refuse de corriger le bogue, car "il n'est pas convaincu qu'il existe". Malheureusement pour moi, le patron est du côté de lui et dit que ce bogue ne peut pas être corrigé à moins que je fasse un "cas de test solide" pour prouver l'existence du bogue et pour faire un test unitaire vérifiant qu'il a disparu. Ce qui est fondamentalement impossible en raison de la nature du bogue.

Aucun conseil?


12
Je dirais que c'est assez simple. Créez un test unitaire qui prouve que ce que vous dites est vrai.
Charles Sprayberry

1
Avez-vous enregistré la trace de pile sous une forme quelconque? Par exemple, avez-vous une capture d'écran de votre IDE montrant la trace de pile du crash?
Giorgio

7
@fithu: vous êtes un peu trop convaincu que reproduire ce genre de bogue est impossible - cela peut être difficile, mais rarement "impossible". Et comment savoir que le bogue est "facile à corriger" lorsque vous n'avez pas accès au code source? Attraper une exception peut ne pas vraiment résoudre le problème. Ou parlez-vous du code de bibliothèque auquel vous avez accès, et vous avez déjà identifié la ligne exacte où le bogue se produit? Si oui, pourquoi ne proposez-vous pas un correctif dans le code?
Doc Brown

2
@fithu: votre titre d'origine était une sorte de diatribe contre votre patron. Je l'ai changé dans l'espoir que cela empêche la fermeture prochaine de votre question, les diatribes ne sont pas très populaires sur ce site. Si le nouveau titre ne reflète pas correctement votre question, n'hésitez pas à l'améliorer davantage.
Doc Brown

4
@Giorgio: une trace de pile est une preuve qu'un programme peut planter sur une ligne spécifique, cela ne prouve pas que cette ligne est la cause première du bogue. Cela semble être le fait que le PO semble avoir mal compris, et la raison pour laquelle j'ai eu des problèmes pour comprendre certains détails de la question.
Doc Brown

Réponses:


35

Si possible, il faudra peut-être un certain temps pour vérifier si ce défaut peut être reproduit en mettant un peu de sommeil ou un blocage dans votre code d'application. Mais ne passez pas trop de temps. Comme ce problème est dû à plusieurs thèmes (et aussi comme vous l'avez observé), son occurrence sera rare.

Mon conseil est de ne pas trop transpirer. Continuez votre travail. Chaque fois que vous rencontrez ce plantage, mettez à jour votre rapport de bogue avec la trace de la pile, en indiquant qu'il s'agit d'une répétition et en changeant le propriétaire en développeur de bibliothèque. Laissez la direction / responsable décider de réparer ou non en fonction de sa fréquence.

Essayez également de comprendre la mentalité du développeur. Vous avez dit "exception Web non interceptée". Le développeur à ce stade peut ne pas être entièrement sûr des autres effets de cette capture . Il / elle peut donc hésiter à toucher le code.


10

Donc, à partir de vos commentaires plus ou moins clarifiants, je l'ai compris ainsi:

Vous êtes sûr qu'il ne manque qu'une simple gestion supplémentaire des exceptions, et vous savez déjà quelle ligne de code dans la bibliothèque pose problème et comment la bibliothèque pourrait être corrigée.

Pourquoi alors n'ajoutez-vous pas vous-même les quelques lignes de code manquantes à la bibliothèque, demandez à l'équipe de bien vouloir tester la bibliothèque avec ces modifications? Assurez-vous qu'il s'agit d'un changement à faible risque, facile à comprendre par le développeur responsable de la bibliothèque. La pire chose qui puisse arriver est que quelqu'un doit annuler ce changement dans votre VCS si votre correctif provoque un nouveau comportement inattendu.

La plupart des gens sont plus faciles à convaincre lorsque le travail est déjà terminé. En outre, ils réagissent mieux sur "voici une solution améliorée", par opposition à "ce code est erroné, corrigez-le en quelque sorte".

EDIT: lorsque le développeur refuse toujours d'ajouter ce changement, la meilleure option est d'essayer de faire fonctionner le code problématique à l'intérieur d'un faisceau de test isolé où vous simulez l'erreur réseau. Travailler efficacement avec le code hérité décrit de nombreuses techniques sur la façon de résoudre ce type de problèmes. Par exemple, vous pouvez créer une version de test de la bibliothèque, comprenant uniquement les modules et fonctions problématiques, et créer un "environnement factice" autour d'elle où vous pouvez simuler "l'exception réseau" dans des conditions contrôlées. Cela peut sembler être trop d'effort à première vue, mais une fois que vous avez un tel environnement, vous pouvez y ajouter de nombreux tests supplémentaires (et je suppose que cela aura du sens, car lorsque l'auteur de la bibliothèque refuse d'ajouter les éléments manquants) gestion des exceptions en un seul endroit,


Il refuse de fusionner ce changement, car "ce n'est pas nécessaire"
fithu

@fithu: voir ma modification.
Doc Brown

4
@DocBrown +1 pour Ils (les gens) réagissent mieux sur "voici une solution améliorée", par opposition à "ce code est erroné, corrige-le en quelque sorte".
laika

2
@fithu: Venez donc avec un cas de test qui déclenche l'exception non gérée à être levée. C'est-à-dire trouver les paramètres qui le déclenchent.
wirrbel

2

Pour un bogue comme celui-ci, les tests de fuzz automatisés (également appelés tests aléatoires) peuvent être utiles pour essayer de le reproduire. Cela automatise le processus de recherche du bogue en randomisant un ensemble fixe de paramètres (ou entrées) dans la chose que vous testez. Chaque exécution de test, les paramètres sont enregistrés dans un fichier journal, y compris les horodatages, etc. de sorte que lorsque le crash se produit, vous pouvez (théoriquement) simplement rejouer le test, en utilisant les mêmes paramètres, pour le reproduire.

Depuis son automatisation, le processus de test peut exécuter de nombreux tests en peu de temps. Souvent, il peut être exécuté pendant la nuit et le matin, vous pouvez consulter un fichier journal pour voir s'il a reproduit le crash.


3
"il suffit de rejouer le test, en utilisant les mêmes paramètres, pour le reproduire" - pas vraiment possible pour les problèmes de threading / réseau. Mais j'aime l'idée.
2013 à 7h08

2

L'avocat du diable suggère une autre voie.

L'autre développeur a déclaré catégoriquement qu'il n'y avait pas de bogue là-bas.

Pouvez-vous trouver un moyen de souligner l'enfer de son bug prétendument inexistant et de le faire planter beaucoup plus souvent?


2

La trace de la pile est une preuve claire que le bogue existe, ou du moins existait dans une certaine version. Ce que vous n'avez pas, c'est la preuve que le bogue a été corrigé. Ils sont stupides de l'ignorer. J'ai eu des bogues «impossibles à reproduire» après des centaines de milliers d'essais automatisés sur plusieurs systèmes qui se sont déclenchés à chaque fois sur le système d'un client.

J'obtiens quelques bugs comme ça par an, la plupart sans même le bénéfice d'une trace de pile. Dans presque tous les cas, même si je ne pouvais pas le reproduire au préalable, je pouvais assez facilement faire un test automatisé une fois corrigé.

Par exemple, il y a quelques mois, j'ai corrigé un bug qui ne se produisait que lorsque l'utilisateur tapait plus rapidement que 96 mots par minute. Avant de le corriger, tout ce que je savais, c'était que le bug se produisait "parfois". Je n'aurais jamais pensé à écrire un test unitaire pour une saisie rapide. Cependant, après avoir connu la cause profonde, faire un test était trivial.

Même dans les rares cas où un bogue ne peut pas être reproduit même après avoir été corrigé, vous pouvez le fermer par inspection de code.


comment faites-vous un test automatisé pour des choses comme ça? (pour éviter tout malentendu, tout ce que vous avez écrit correspond à ma propre expérience et à mes croyances) Mon dernier bug comme celui-ci était la course aux données pour l'accès simultané non synchronisé, le bug et le correctif ont été très faciles à prouver par inspection de code, mais je ne peux pas imaginez comment tester cela de manière fiable. (J'ai surtout peu de problèmes à concevoir des tests pour des choses simultanées mais je ne peux pas comprendre le code de test pour prouver l'absence de course aux données)
gnat

1
Cela peut tomber dans mon exception d'inspection de code, mais vous pouvez également déclencher des conditions de concurrence en introduisant un retard dans l'un des threads. Souvent, vous pouvez accomplir cela en retardant un stimulus externe, ou moins idéalement, vous pouvez mettre le retard directement dans le code pendant le test.
Karl Bielefeldt

Je vois, merci. Cela semble intéressant, je dois y réfléchir ...
moucher
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.