Est-il raisonnable d'insister pour reproduire chaque défaut avant de le diagnostiquer et de le réparer?


70

Je travaille pour une entreprise de produits logiciels. Nous avons de grandes entreprises clientes qui mettent en œuvre notre produit et nous leur fournissons une assistance. Par exemple, s’il ya un défaut, nous fournissons des correctifs, etc. En d’autres termes, c’est une configuration assez typique.

Récemment, un ticket m'a été attribué et affecté concernant une exception trouvée par un client dans un fichier journal qui concerne l'accès simultané à une base de données dans une implémentation en cluster de notre produit. La configuration spécifique de ce client peut donc être critique dans la survenue de ce bogue. Le client ne nous a fourni que son fichier journal.

L’approche que j’ai proposée à mon équipe a été d’essayer de reproduire le bogue dans une configuration similaire à celle du client et d’obtenir un journal comparable. Cependant, ils sont en désaccord avec mon approche, affirmant que je n'ai pas besoin de reproduire le bogue, car il prend trop de temps et nécessite de simuler un cluster de serveurs sur des ordinateurs virtuels. Mon équipe suggère simplement de "suivre le code" pour voir où se trouve le code non sécurisé par les threads et / ou les transactions, et de mettre en œuvre le changement à partir d'un simple développement local, qui n'est pas une implémentation de cluster comme l'environnement à partir duquel l'occurrence du bogue provient.

Pour moi, travailler à partir d'un plan abstrait (code de programme) plutôt que d'une manifestation tangible et visible (reproduction à l'exécution) me semble difficile, alors je voulais poser une question générale:

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Ou:

Si je suis un développeur expérimenté, devrais-je être capable de lire du code multithread et de créer une image mentale de ce qu’il fait dans tous les scénarios de cas d’utilisation plutôt que d’exécuter l’application, de tester différents scénarios de cas d’utilisation et code ligne par ligne? Ou suis-je un mauvais développeur pour avoir exigé ce type d'environnement de travail?

Le débogage est-il pour les poules mouillées?

À mon avis, tout correctif soumis en réponse à un ticket d'incident doit être testé dans un environnement simulé aussi proche que possible de l'environnement d'origine. Sinon, comment pouvez-vous savoir que cela va vraiment résoudre le problème? C'est comme si on sortait un nouveau modèle de véhicule sans essai de collision avec un mannequin pour démontrer que les sacs gonflables fonctionnent réellement.

Last but not least, si vous êtes d'accord avec moi:

Comment parler à mon équipe pour la convaincre que mon approche est raisonnable, conservatrice et plus résistante aux balles?


7
il est parfois insensé d’insister sur la reproduction lorsque vous avez un journal avec trace de pile. Certains bogues d'accès simultané en Java ressemblent à cela. En réalité, le plus simple est d'obtenir un journal avec NPE et une trace de pile pointant vers une ligne qui "semble" utiliser un objet créé avec new. Et il n’est pas garanti que ces bogues soient reproductibles de manière fiable, conformément à la spécification du modèle de mémoire Java
Gnat,

5
Voulez-vous la réponse "correcte" - vous devez reproduire chaque bogue pour que vous sachiez qu'elle est corrigée, ou la réponse "laissez le client nous payer des dollars" - parfois vous n'avez ni le temps ni les ressources nécessaires pour le faire, et votre patron s'attend à ce que vous utilisiez votre expertise pour faire un bon effort pour le réparer quand même?
KutuluMike


20
Surpris que la communauté ici soit en accord avec toi. Franchement, je suis tout à fait d'accord avec tes coéquipiers. Parfois, surtout lorsqu'il s'agit de bogues dans des conditions de course, il est beaucoup plus logique et simplement plus simple de suivre le code que de passer beaucoup de temps à créer un environnement de test qui pourrait même ne pas exposer le problème . Si vous ne trouvez pas quoi que ce soit en traçant le code, alors que, s'il est logique de dépenser l'effort pour créer un environnement de test, mais il est une mauvaise répartition du temps de commencer en créant l'environnement de test.
Ben Lee

5
Vous ne pouvez pas prouver que vous avez résolu le problème sans pouvoir le répliquer. Parfois, il peut être judicieux de deviner les contraintes de ressources, mais je voudrais que ce soit l'exception et non la règle. Bien que, si c'est vraiment difficile de reproduire les problèmes, il y a peut-être autre chose qui ne va pas, comme la conception ou l'architecture sous-jacente.
dietbuddha

Réponses:


72

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Vous devriez faire de votre mieux. Je sais que parfois, certaines conditions et certains environnements sont si complexes qu'ils ne peuvent pas être reproduits exactement , mais vous devriez certainement essayer si vous le pouvez.

Si vous n'avez jamais reproduit le bogue et que vous l'avez vu par vous-même, comment pouvez-vous être sûr à 100% que vous l'avez vraiment corrigé? Peut-être que votre solution proposée introduit un autre bogue subtil qui ne se manifestera que si vous essayez réellement de reproduire le défaut d'origine.

Si je suis un développeur senior, devrais-je être capable de lire du code (multithread) et de créer une image mentale de ce qu'il fait dans tous les scénarios de cas d'utilisation plutôt que d'exiger l'exécution de l'application, de tester différents scénarios de cas d'utilisation sur le terrain et de suivre les étapes le code ligne par ligne? Ou suis-je un mauvais développeur pour avoir exigé ce type d'environnement de travail? Le débogage est-il pour les poules mouillées?

Je ne ferais pas confiance à quelqu'un qui gère le code "dans sa tête", si c'était sa seule approche. C'est un bon endroit pour commencer . Reproduire le bogue, le corriger, puis démontrer que la solution empêche le bogue de se reproduire - c'est là qu'il devrait se terminer .

Comment parler à mon équipe pour la convaincre que mon approche est raisonnable, conservatrice et plus résistante aux balles?

Parce que s'ils ne reproduisent jamais le bogue, ils ne peuvent pas savoir avec certitude qu'il est corrigé. Et si le client revient et se plaint que le bogue est toujours là, ce n'est pas une bonne chose. Après tout, ils vous paient un gros salaire (je suppose) pour régler ce problème.

Si vous ne parvenez pas à résoudre le problème correctement, vous avez brisé la confiance du client (dans une certaine mesure) et s’il existe des concurrents sur votre marché, ils ne peuvent pas rester votre client.


3
"Reproduire le bogue, le corriger, puis démontrer que la solution empêche le bogue de se reproduire - c’est là que le bogue devrait s’arrêter." - mon point exactement
amphibient

2
"Parce que s'ils ne reproduisent jamais le bogue, ils ne peuvent pas savoir avec certitude qu'il est corrigé." Amen ...
Marjan Venema

11
J'aimerais aussi ajouter quelque chose à cette réponse: étant donné que vous n'avez pas cette configuration, votre société devrait déterminer s'il s'agit même d'une configuration prise en charge. Si votre entreprise prend officiellement en charge de telles configurations, vous devez disposer d'un environnement configuré de la même manière, uniquement pour effectuer votre travail d'assurance qualité. Cela entraînera certainement des dépenses supplémentaires, et c’est pourquoi la société devrait décider des configurations de son produit à prendre en charge.
Andy

Il devrait y avoir un argument coût / bénéfice ici. S'il faut des semaines pour se reproduire, la valeur de la reproduction est probablement faible car on ne s'attaque pas à d'autres problèmes. Si la reproduction prend quelques secondes, la valeur de la reproduction est probablement élevée, en raison de la certitude du correctif. La décision devrait tenter d’équilibrer cela, une déclaration générale «devrait» ou «ne devrait pas» est inutile.
Orip

1
@orip: L’analyse coûts / avantages doit également prendre en compte le client: le coût de l’ignorance du client avec le risque possible de perdre le compte (et éventuellement de perdre d’autres clients en raison de ce qu’ils ont entendu de ce client initial, ou rencontrez également le bogue mais ne l’ont pas encore signalé de manière formelle) l'emportent sur le coût du temps passé par le développeur à reproduire et à corriger le bogue?
FrustratedWithFormsDesigner

35

Comment ont-ils l'intention de vérifier que le bogue en question a été corrigé? Veulent-ils envoyer du code non testé à l'utilisateur et lui permettre de le comprendre? Toute configuration de test qui ne s'est jamais avérée reproduire l'erreur ne peut pas être invoquée pour démontrer l'absence de l'erreur. Vous n'avez certainement pas besoin de reproduire la totalité de l'environnement client, mais vous en avez assez pour reproduire l'erreur.

Je ne pense pas qu'il soit déraisonnable d'essayer de reproduire chaque bogue avant de le réparer. Cependant, si vous essayez de le reproduire et que vous ne le pouvez pas, il devient alors plus une décision de votre part de déterminer si les correctifs aveugles sont une bonne idée.


2
Je suis d'accord, cependant, si un bogue est détecté lors de l'examen, il peut fournir les informations critiques nécessaires à sa reproduction. Vous pouvez ensuite le reproduire et prouver que le correctif est correct ...
2013

3
Si vous pouvez trouver une condition de concurrence multithread par inspection de code, vous devriez pouvoir la reproduire de manière cohérente en modifiant le code à l'aide d'instructions de verrouillage supplémentaires qui forcent les threads à démarrer / arrêter dans une séquence qui le déclenche. ex Thread1-Startup et pause, thread2-Startup et pause, 1-commencez à utiliser un objet partagé et mettez en pause, 2 modifiez-vous un objet partagé et mettez-vous en pause, 1-essayez d'utiliser un objet partagé et barf. Le plus gros problème avec ce type d’approche est que, bien que ce soit quelque chose que vous pouvez démontrer dans un débogueur, il ne convient pas pour l’ajouter à une suite de tests automatisés. BTDT-GTTS.
Dan Neely

2
@DanNeely: Si un thread écrit une valeur dans un tableau, puis stocke une référence dans un champ, et qu'un autre thread lit ce champ et accède à l'élément de tableau correspondant, comment pourrait-on reproduire des bogues pouvant survenir si le JIT déplace la référence en écriture opération avant celle de l'élément write?
Supercat

27

Idéalement, vous voulez pouvoir reproduire chaque bogue de manière à pouvoir au moins vérifier qu'il a été corrigé.

Mais ... Ce n'est peut-être pas toujours réalisable ni physiquement possible. Surtout avec les logiciels de type 'entreprise' où chaque installation est unique. Il y a aussi l'évaluation coûts / avantages. Quelques heures consacrées à la lecture du code et à quelques suppositions éclairées à propos d'un problème non critique peuvent coûter beaucoup moins cher qu'une équipe de support technique qui passe des semaines à essayer de configurer et de dupliquer l'environnement d'un client, dans l'espoir de pouvoir dupliquer le problème. problème. À l'époque où je travaillais dans le monde de l'entreprise, nous invitions souvent les codeurs à réparer les bogues sur site, car il n'y avait aucun moyen de dupliquer la configuration du client.

Donc, dupliquez quand vous le pouvez, mais si vous ne le pouvez pas, alors exploitez votre connaissance du système et essayez d'identifier le coupable dans le code.


11

Je ne pense pas que vous devriez faire de reproduire l'erreur une obligation de regarder le bogue. Comme vous l'avez mentionné, il existe plusieurs manières de déboguer le problème - et vous devez toutes les utiliser. Vous devriez vous compter chanceux d'avoir pu vous fournir un fichier journal! Si vous ou un membre de votre entreprise pouvez reproduire le bogue, c'est parfait! Si ce n'est pas le cas, vous devriez quand même essayer d'analyser les journaux et rechercher les circonstances dans lesquelles l'erreur s'est produite. Comme vos collègues l'ont suggéré, il est peut-être possible de lire le code, de déterminer les conditions dans lesquelles le bogue peut survenir, puis de tenter de recréer le scénario vous-même.

Cependant, ne publiez pas le correctif non testé. Tous les changements que vous apportez doivent passer par la routine de développement standard, de test d’assurance qualité et de test d’intégration. Cela peut s'avérer difficile à tester - vous avez mentionné le code multithread, qui est notoirement difficile à déboguer. C’est là que je suis d’accord avec votre approche pour créer une configuration ou un environnement de test. Si vous avez trouvé un problème dans le code, vous devriez trouver beaucoup plus simple de créer l'environnement, de le reproduire et de tester le correctif.

Pour moi, il s'agit moins d'un problème de débogage que d'un problème de service client. Vous avez reçu un rapport de bogue d'un client. vous avez la responsabilité de faire preuve de diligence raisonnable pour trouver le problème et le résoudre.


5
"Cependant, ne publiez pas le correctif non testé." Comment? S'il ne peut pas reproduire les conditions qui ont provoqué le bogue, comment va-t-il les reproduire pour tester le correctif? De plus, je ne présumerais pas que OP n'a pas fait de son mieux.
Tulains Córdova

"Si vous avez trouvé un problème dans le code, vous devriez trouver beaucoup plus simple de créer l'environnement, de reproduire le problème et de tester le correctif." J'ai lu que la question du PO était la suivante: "Devrais-je exiger de tous les rapports de bogue un cas de repro avant de tenter de diagnostiquer le problème?" Non, tu ne devrais pas.
Michael K

Je m'attendrais à ce que la plupart des tests soient des tests de régression des fonctionnalités existantes.
Michael Durrant

4
@MichaelK: Votre réponse semble entrer en conflit avec elle-même. Si vous ne déterminez pas les étapes à suivre pour reproduire le bogue, comment saurez-vous ce que devraient être vos scénarios de test? Vous n'aurez peut-être pas toujours besoin de reproduire les bugs vous-même, mais la plupart de ces cas surviendront lorsque les étapes à suivre pour les reproduire sont déjà connues. Si tout ce que vous avez est un fichier journal sans étapes connues, vous n'avez aucun scénario de test pour le contrôle qualité.
Ellesedil

8
Je pense que ce qu'il dit, c'est que vous n'avez pas nécessairement à reproduire le problème pour pouvoir rechercher une solution. Et en supposant que vous la localisiez et que vous trouviez une solution, vous saurez alors quelles conditions installer sur le serveur de test pour reproduire. À ce stade, vous savez même comment configurer le code précédent - le configurer, vérifier qu'il est reproductible, déployer le correctif, vérifier qu'il est corrigé.
GalacticCowboy

9

À mon avis ... en tant que décideur, vous devez pouvoir justifier votre position. Si l'objectif du service d'assistance de troisième ligne est de corriger les bugs dans les meilleurs délais avec un effort acceptable du client, toute approche doit alors être conforme à cet objectif. En outre, s’il est prouvé que l’approche donne les résultats escomptés les plus rapides, il n’ya aucun problème à convaincre l’équipe.

Ayant travaillé dans le support, je me suis toujours raisonnablement attendu à ce que le client soit capable de donner un "script" des actions qu'il a effectuées pour reproduire le bogue de manière cohérente et, le cas échéant, des exemples candidats ayant produit le bogue.

Si j'étais nouveau dans le système et que je n'avais aucune connaissance du code, je commencerais par essayer d'identifier les sources possibles de l'erreur. Il se peut que la journalisation ne soit pas suffisante pour identifier un code candidat. En fonction du client, je pourrais être enclin à leur donner une version de débogage afin qu’ils puissent vous restituer des fichiers journaux qui donnent des indices supplémentaires sur la position du code incriminé.

Si je suis capable d'identifier rapidement le bloc de code, une cartographie visuelle du flux peut suffire à repérer le code. Sinon, une simulation basée sur des tests unitaires peut suffire. Il se peut que la configuration d’un environnement de réplication client prenne moins de temps, en particulier si le problème peut être reproduit avec une grande précision.

Je pense que vous trouverez peut-être que votre approche devrait être une combinaison des solutions proposées et qu'il est essentiel de savoir quand arrêter et passer à la suivante pour faire le travail efficacement.

Je suis persuadé que l’équipe soutiendra l’idée que, s’il ya une chance que leur solution trouve le bogue plus rapidement, leur donner un laps de temps approprié pour prouver que cela n’a pas trop d’impact sur le temps nécessaire pour le résoudre. itinéraire que vous prenez.


8

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Je dis oui, avec quelques réserves.

  • Je pense que c'est correct de lire le code et d'essayer de trouver des endroits qui peuvent sembler problématiques. Créez un correctif et envoyez-le au client pour voir si cela résout le problème. Si cette approche continue d'échouer, vous devrez peut-être explorer d'autres options. N'oubliez pas que, même si vous corrigez un bogue, ce n'est peut-être pas le bogue signalé.
  • Si vous ne pouvez pas le reproduire dans les limites du raisonnable et que vous ne trouvez aucun indicateur rouge dans le code, cela peut nécessiter une coordination plus étroite avec le client. J'ai déjà visité des sites clients avant de procéder au débogage sur site. Ce n'est pas le meilleur environnement de développement, mais parfois si le problème est environnemental, trouver la cause exacte sera plus facile si vous pouvez le reproduire de manière cohérente.

J'ai été du côté des clients de la table dans ce scénario. Je travaillais dans un bureau du gouvernement américain qui utilisait une grappe de base de données Oracle incroyablement grande (plusieurs téraoctets de données et le traitement de millions d'enregistrements par jour).

Nous avons rencontré un problème étrange qu'il nous était très facile de reproduire. Nous avons signalé le bogue à Oracle et sommes allés de l'avant avec eux pendant des semaines en leur envoyant des journaux. Ils ont dit qu’ils n’étaient pas en mesure de reproduire le problème, mais ils nous ont envoyé quelques correctifs afin que l’espoir puisse résoudre le problème. Aucun d'entre eux ont fait.

Ils ont finalement fait venir deux développeurs sur notre site pour résoudre le problème sur site. Et c’est à ce moment que la cause fondamentale du bogue a été trouvée et qu’un correctif ultérieur a correctement résolu le problème.


6

Si vous n'êtes pas positif sur le problème, vous ne pouvez pas être positif sur la solution. Savoir reproduire le problème de manière fiable dans au moins une situation de test permet de prouver que vous savez comment provoquer l'erreur et vous permet donc également de prouver, d'un autre côté, que le problème a été résolu, en raison de l'absence ultérieure. d'erreur dans le même cas de test après l'application du correctif.

Cela dit, les conditions de concurrence, les problèmes de concurrence et d’autres bogues "non déterministes" sont parmi les plus difficiles à cerner de cette manière, car ils se produisent rarement, sur un système avec une charge plus importante et plus complexe que la copie de celui-ci. le programme et ils disparaissent lorsque la tâche est réexécutée ultérieurement sur le même système.

Le plus souvent, ce qui ressemble à l'origine à un bogue aléatoire finit par avoir une cause déterministe qui le rend reproductible de manière déterministe une fois que vous savez comment faire. Ceux qui défient cela, les véritables Heisenbugs (des bogues apparemment aléatoires qui disparaissent lorsqu'on tente de les tester dans un environnement stérile et surveillé), sont liés à 99,9% au moment choisi pour le chronométrage, et une fois que vous comprenez que votre chemin devient plus clair; recherchez les éléments qui pourraient échouer si quelque chose d'autre obtenait un mot bord à côte pendant l'exécution du code, et lorsque vous trouvez une telle vulnérabilité, tentez de l'exploiter dans un test pour voir s'il présente le comportement que vous essayez de reproduire.

Une quantité importante d’inspection approfondie du code est généralement requise dans ces situations; vous devez examiner le code, en abandonnant toute idée préconçue sur la manière dont le code est censé se comporter, et imaginer des scénarios dans lesquels il pourrait échouer dans la façon dont votre client a observé. Pour chaque scénario, essayez de développer un test pouvant être exécuté efficacement dans votre environnement de test automatisé actuel (c’est-à-dire, sans avoir besoin d’une nouvelle pile de machines virtuelles uniquement pour ce test), ce qui prouverait ou réfuterait que le code se comporte comme vous le souhaitiez ( ce qui, selon vos attentes, prouverait ou réfuterait que ce code est une cause possible des problèmes des clients). C'est la méthode scientifique pour les ingénieurs en logiciel; observer, émettre des hypothèses, tester, réfléchir, répéter.


4

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Non, ce n'est vraiment pas le cas. Ce serait une politique stupide.

Le problème que je vois avec votre question et votre proposition est qu’ils ne parviennent pas à faire la distinction entre

  • rapports de bugs
  • échecs ( erreurs )
  • bugs (aussi parfois appelés erreurs )

Un rapport de bogue est une communication concernant un bogue. Cela vous dit que quelqu'un pense que quelque chose ne va pas. Cela peut être ou ne pas être spécifique sur ce qui est supposé être faux.

Un rapport de bogue est la preuve d'un échec.

Un échec est un incident de quelque chose qui ne va pas. Un dysfonctionnement spécifique, mais pas nécessairement avec des indices sur ce qui peut l’avoir causé.

Un échec peut être causé par un bug.

Un bug est une cause d'échec; quelque chose qui peut (en principe) être changé afin d’éviter que les échecs qu’il provoque se reproduisent.

Parfois, lorsqu'un bogue est signalé, la cause est immédiatement résolue. Dans un tel cas, reproduire le bogue serait absurde. À d'autres moments, la cause n'est pas claire du tout: le rapport de bogue ne décrit pas un échec particulier, ou le fait, mais l'échec est tel qu'il ne fournit pas d'indice sur ce qui pourrait en être la cause. Dans de tels cas, j'estime que votre conseil est justifié - mais pas toujours: on n'insiste pas pour écraser une deuxième fusée de 370 millions de dollars avant d'accepter d'enquêter sur la cause de la chute de la première (un bug particulier dans le logiciel de contrôle).

Et il y a aussi toutes sortes de cas entre les deux; par exemple, si un rapport de bogue ne prouve pas, mais suggère seulement, qu'un problème potentiel que vous étiez déjà au courant pourrait jouer un rôle, cela pourrait être une incitation suffisante pour que vous l'examiniez de plus près.

Ainsi, bien qu'il soit judicieux d'insister sur la reproductibilité pour les cas les plus difficiles, il est déconseillé de l'appliquer en tant que règle stricte.


4
S'il n'est pas raisonnable de reproduire le bogue, comment savez-vous que vous l'avez corrigé? Peu importe la complexité de la façon de reproduire un bogue.
BЈовић

Vous savez que le bogue a été corrigé lorsqu'il est si facile à reproduire que vous n'en avez pas besoin.
Reinierpost

Le but n'est pas de corriger les bugs, mais d'avoir un bon produit. Vous effectuez un changement de code qui améliore le code et, selon vous, et l'avis du relecteur, corrigez peut-être le bogue. Ensuite, le produit sera testé à nouveau. Peut-être par des testeurs involontaires ou utilisateurs finaux.
gnasher729

Je conviens que les nouveaux tests doivent toujours être effectués lorsque cela est possible, mais ce n'est pas la question. La question ici est de savoir s’il est raisonnable de toujours insister sur la reproductibilité du problème.
reinierpost

3

Comme pour tout ce qui concerne le développement logiciel, la bonne réponse est un compromis.

En théorie, vous ne devriez jamais essayer de corriger un bogue si vous ne pouvez pas prouver qu'il existe. Cela pourrait vous amener à apporter des modifications inutiles à votre code qui ne résoudront rien en fin de compte. Et le prouver, c'est d'abord le reproduire, puis créer et appliquer un correctif, puis démontrer que cela ne se produit plus. Votre instinct ici vous oriente dans la bonne direction - si vous voulez être sûr d'avoir résolu le problème de votre client, vous devez savoir ce qui l'a causé au départ.

En pratique, ce n'est pas toujours possible. Peut-être que le bogue ne se produit que sur de grands clusters avec des dizaines d'utilisateurs accédant simultanément à votre code. Peut-être existe-t-il une combinaison spécifique d'opérations de données sur des ensembles de données spécifiques qui déclenche le bogue et vous n'avez aucune idée de ce que c'est. Peut-être que votre client a exécuté le programme de manière interactive non-stop pendant des centaines d’heures avant que le bogue ne se manifeste.

Dans tous les cas, il est fort probable que votre service ne disposera ni du temps ni de l’argent pour reproduire le bogue avant de commencer à travailler. Dans de nombreux cas, il est bien plus évident pour vous, le développeur, qu'il existe un bogue dans le code qui vous indique la bonne situation. Une fois le problème diagnostiqué, vous pourrez peut-être revenir en arrière et le reproduire. Ce n’est pas idéal, mais en même temps, une partie de votre travail de développeur senior consiste à savoir comment lire et interpréter le code, en partie pour localiser ce type de bogues enfouis.

À mon avis, vous vous concentrez sur la mauvaise partie de la question. Que faire si vous ne pouvez finalement pas reproduire le bogue en question? Rien n’est plus frustrant pour un client que d’entendre "ouais, nous savons que vous avez bloqué le programme mais nous ne pouvons pas le reproduire, donc ce n’est pas un bug." Lorsque votre client entend cela, il l'interprète en ces termes: "Nous savons que notre logiciel est défectueux, mais nous ne pouvons pas nous occuper de corriger les bugs, il suffit donc de se croiser les doigts." S'il est préférable de fermer un bogue signalé comme "non reproductible", ou de le fermer comme "non reproductible, mais nous avons apporté des modifications raisonnables pour essayer d'améliorer la stabilité"?


3

À moins que l'erreur soit évidente, évidente et triviale, avec un message d'erreur très spécifique, etc., il est souvent très difficile de corriger un bogue si l'utilisateur ou le responsable ne sont pas en mesure de le répliquer.

Aussi, comment leur prouver que le bogue est corrigé si vous ne pouvez pas répliquer les étapes?

Le problème avec votre cas est que l’utilisateur ne sait pas non plus comment l’erreur s’est produite, c’est-à-dire dans quel écran de quelle opération. Ils ont simplement le journal.

Je pense que votre argument est raisonnable. Si vous aviez des pouvoirs psychiques , vous ne travailleriez probablement pas pour un salaire.

Je pense que vous devriez dire à vos patrons que, sans pouvoir reproduire l'erreur, il faudrait un temps inconnu pour la découvrir, et rien ne garantit que vous le ferez.

Le problème viendra lorsqu'un de vos collègues trouvera le bogue par pur hasard et le corrigera.


3

Passons à l'extrême et supposons que vous ayez trouvé le bogue beaucoup plus tôt: dans votre code, tel que vous l'écriviez. Dans ce cas, vous n'aurez aucun scrupule à résoudre le problème ici: vous constaterez une faille logique dans le code que vous venez d'écrire, il ne fait pas ce que vous souhaitiez. Vous ne ressentirez pas le besoin de configurer tout un environnement pour montrer que c'est en fait un bug.

Maintenant, un rapport de bogue arrive. Vous pouvez faire plusieurs choses. L'une d'elles est de revenir au code et de le relire. Supposons maintenant que lors de cette seconde lecture, vous trouviez immédiatement le bogue dans le code - il ne fait tout simplement pas ce que vous vouliez, et vous n'avez pas remarqué que vous l'avez écrit. Et , cela explique parfaitement le bogue qui vient d'arriver! Vous faites le correctif. Cela t'a pris vingt minutes.

Cela a-t-il corrigé le bogue qui a provoqué le rapport de bogue? Vous ne pouvez pas être sûr à 100% (il y a peut-être eu deux bogues causant la même chose), mais c'est probablement ce qui s'est passé.

Vous pouvez également reproduire la configuration du client aussi bien que possible (quelques jours de travail) et éventuellement reproduire le bogue. Dans de nombreux cas, il existe des problèmes de synchronisation et de concurrence qui font que vous ne pouvez pas reproduire le bogue, mais vous pouvez essayer beaucoup de temps et parfois voir la même chose se produire. Vous commencez maintenant le débogage, recherchez l'erreur dans le code, placez-la dans l'environnement et essayez plusieurs fois. Vous ne voyez plus le bogue se produire.

Cela a-t-il corrigé le bogue qui a provoqué le rapport de bogue? Vous ne pouvez toujours pas être sûr à 100% - premièrement, vous avez peut-être vu un bogue complètement différent de celui du client, deux, peut-être n'avez-vous pas essayé assez souvent, et trois, peut-être que la configuration est toujours légèrement différente et fixé sur ce système, mais pas celui du client.

Donc, la certitude est impossible à obtenir dans tous les cas. Mais la première méthode est beaucoup plus rapide (vous pouvez aussi donner un correctif au client plus rapidement), beaucoup moins cher et, si vous trouvez un bogue de codage clair qui explique le symptôme, il est plus probable que le problème soit également résolu.

Donc ça dépend. Si l'installation d'un environnement de test (ou mieux: un test automatisé qui montre le problème) est peu coûteuse, faites-le. Mais si cela coûte cher et / ou si les conditions dans lesquelles le bogue est affiché sont imprévisibles, il est toujours préférable d'essayer de trouver le bogue en lisant d'abord le code.


supposez-vous que le code était le mien pour commencer?
amphibient

D'après mon expérience, les rapports de bogues finissent souvent avec le gars qui a écrit le code, mais ce n'est pas important pour ma réponse. Vous pouvez également lire le code d'autres personnes et y voir des bugs.
RemcoGerlich

1

En lisant la question, je ne vois aucune opposition fondamentale entre votre position et celle de votre équipe.

  • Oui, vous devez faire de votre mieux pour reproduire le problème survenant dans le client. Toutefois, au mieux, vous devez définir une zone de temps pour cela et le journal ne contiendra peut-être pas suffisamment de données pour reproduire le problème.

    Si tel est le cas, tout dépend de la relation avec ce client. Cela peut aller de vous n'aurez rien d'autre de lui, à votre peut envoyer un développeur sur site avec des outils de diagnostic et la capacité de les exécuter sur le système défaillant. Habituellement, nous sommes quelque part entre et si les données initiales ne suffisent pas, il existe des moyens d'en obtenir davantage.

  • Oui, un développeur expérimenté devrait être capable de lire le code et est susceptible de trouver la raison du problème après le contenu du journal. En réalité, il est souvent possible d'écrire un test unitaire qui pose le problème après avoir lu attentivement le code.

    Réussir à écrire de tels tests unitaires revient presque à reproduire l’environnement fonctionnel de rupture. Bien sûr, cette méthode ne garantit pas non plus que vous trouverez quoi que ce soit. Comprendre la séquence exacte des événements menant à une défaillance dans certains logiciels multithreads peut être très difficile à trouver en lisant simplement le code, et la capacité à déboguer en direct risque de devenir critique.

En résumé, j'essayais simultanément pour les deux approches et je demandais soit un système en direct montrant le problème (et montrant qu'il est corrigé par la suite), soit un test d'unité d'analyse décisif (et montrant également qu'il est corrigé après le correctif).

Essayer simplement de corriger le code et de l’envoyer à l’état sauvage a effectivement l’air très risqué. Dans des cas similaires qui m’arrivaient (où nous n’avons pas reproduit le défaut en interne), j’ai clairement indiqué que si un correctif échouait dans la nature et ne résolvait pas le problème du client, ou n’avait d’autres conséquences négatives inattendues, le gars qui avait proposé cela devrait aider l'équipe de support à trouver le problème réel. Y compris traiter avec le client si nécessaire.


1

Il me semble que vous avez besoin d’une journalisation plus détaillée.

Bien que l'ajout de journalisation supplémentaire ne puisse garantir que vous n'aurez pas besoin de déboguer (ou, dans ce cas, de reproduire la situation), cela vous donnera une bien meilleure idée de ce qui s'est réellement passé.

Surtout dans les situations compliquées / de threading, ou dans tout ce qui ne peut pas utiliser un débogueur, le recours à "debug by printf ()" peut être votre seul recours. Dans ce cas, connectez-vous autant que vous le pouvez (plus que nécessaire) et disposez de bons outils pour filtrer le bon grain de l'ivraie.


1

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Comme personne ne l’a dit en termes clairs encore: Absolument pas!

Comme pour tout ce qui se passe dans le développement logiciel, la correction de bogues implique de garder à l'esprit le temps, les risques et les coûts. Trouver un équilibre entre ceux-ci est la moitié de la description de poste d'un développeur.

Certains bugs ne sont pas assez importants pour passer 2 jours, mais suffisamment pour consacrer 10 minutes à les corriger. D'autres bogues ne sont pas déterministes et vous savez déjà qu'un environnement de test ne peut pas prouver qu'ils ont été corrigés. Si la configuration de l'environnement de test prend 2 jours, vous ne le faites pas pour ces bogues. Au lieu de cela, vous passez du temps à des choses plus intelligentes, telles que la recherche de moyens pour configurer un environnement de test en 5 minutes au lieu de 2 jours.

Et bien sûr, il y a des bugs qui, si vous vous trompez, un client perdront plus de 100 000 $. Et les bogues où le client perdra plus de 100 000 $ pour chaque heure où le bogue n’est pas corrigé. Vous devez regarder le bogue et prendre une décision. Les instructions générales pour traiter tous les bogues de la même manière ne fonctionnent pas.


0

Très bonne question! Mon opinion est que si vous ne pouvez pas reproduire le problème, vous ne pouvez pas à 100% affirmer que le correctif que vous avez apporté ne le fera pas:

a) corrige réellement le problème. b) créer un autre bug

Il arrive parfois qu'un bogue se produise et que je le répare et que je ne me donne pas la peine de le tester. Je sais à 100% que cela fonctionne. Mais jusqu'à ce que notre service d'assurance qualité indique que cela fonctionne, je considère qu'il est toujours possible qu'un bogue soit toujours présent ... ou qu'un nouveau bogue soit créé à partir du correctif.

Si vous ne pouvez pas reproduire le bogue, puis installer la nouvelle version et confirmer sa correction, vous ne pouvez pas, avec une certitude de 100%, affirmer que le bogue a disparu.

J'ai essayé pendant quelques minutes de penser à une analogie pour vous aider à expliquer aux autres mais rien ne m'est venu à l'esprit. Une vasectomie est un exemple amusant mais ce n'est pas la même situation :-)


Supposons, par exemple, que l'on reçoive un rapport signalant qu'un programme formate parfois de manière incorrecte certains nombres au format décimal lorsqu'il est installé sur une version française de Windows; une recherche de code paramètre de culture révèle l' on découvre une des méthodes qui permet d' économiser la culture actuelle du fil et des ensembles à l' InvariantCultureintérieur d' une CompareExchangeboucle, mais remet à zéro après [tel que si le CompareExchangeéchoue la première fois, la variable de la culture « enregistrée » sera écrasés] . Reproduire les circonstances de l'échec serait difficile, mais le code est clairement faux et pourrait causer le problème indiqué.
Supercat

Dans un tel cas, serait-il nécessaire de reproduire la défaillance ou le fait que le code en question serait clairement capable de provoquer des défaillances telles que celle indiquée est suffisant si on l'inspecte pour tout autre lieu où des modes de défaillance similaires pourraient se produire?
Supercat

Eh bien c'est tout cela, "cela dépend" de l'argument de la situation. S'il s'agissait d'un système critique en vie ou en cas de décès ou si le client s'attendait à ce type de test, alors oui, faites de votre mieux pour reproduire le problème et le test. J'ai dû télécharger le code sur une machine cliente pour pouvoir déboguer car nous ne pouvions pas reproduire un problème sur nos serveurs de test. C'était une sorte de problème de sécurité Windows. Créé un correctif et tout le monde est heureux. C'est difficile si la configuration de l'environnement de test est plus difficile que la résolution du bogue. Ensuite, vous pouvez demander au client. La plupart du temps, ils sont d'accord pour le tester eux-mêmes.
Jaydel Gluckie

En cas de suspicion de problèmes de filetage, même si l’on parvient à manipuler les choses de manière à forcer les choses au "mauvais" moment, existe-t-il un moyen de savoir si le problème que vous avez reproduit est le même que celui observé par le client? Si le code a un défaut tel que tout ce qui se passe avec un certain timing causerait un échec, et qu'il est au moins théoriquement possible qu'un tel timing se produise, je pense que le code devrait être corrigé, que l'on puisse ou non créer un environnement de test pour créer les timings requis se produisent. Dans beaucoup de ces situations ...
Supercat

... les environnements de test et de production sont susceptibles d'avoir suffisamment de différences temporelles pour que juger de la possibilité d'une mauvaise synchronisation particulière peut s'avérer extrêmement difficile et peu informatif. L'important est d'examiner les endroits potentiellement sensibles à la synchronisation afin de s'assurer qu'ils ne le sont pas, car les tests de sensibilité de synchronisation sont sujets à beaucoup de faux négatifs.
Supercat

0

[bug lié à] accès simultané à la base de données, implémentation en cluster, multithread

Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?

Je ne passerais pas trop de temps à essayer de le reproduire. Cela ressemble à un problème de synchronisation et on le trouve plus souvent en raisonnant (en commençant par des journaux comme celui-ci, il faut localiser le sous-système dans lequel le problème se produit) qu'en trouvant un moyen de le reproduire et en l'attaquant avec un débogueur . D'après mon expérience, réduire le niveau d'optimisation du code ou parfois même activer d'autres instruments peut suffire à ajouter suffisamment de retard ou la primitive de synchronisation manquante pour empêcher le bogue de se manifester.

Oui, si vous n'avez pas le moyen de reproduire le bogue, vous ne pourrez pas être sûr de le résoudre. Mais si votre client ne vous donne pas le moyen de le reproduire, vous pouvez également rechercher quelque chose de similaire avec les mêmes conséquences, mais une cause fondamentale différente.


0

Les deux activités (examen du code et test) sont nécessaires, aucune n'est suffisante.

Vous pourriez passer des mois à construire des expériences pour tenter de reproduire le bogue et ne jamais aller nulle part si vous ne regardiez pas le code et ne formiez pas une hypothèse permettant de réduire l'espace de recherche. Vous pourriez passer des mois à regarder votre nombril en essayant de visualiser un bogue dans le code, vous pourriez même penser que vous l'avez trouvé une fois, deux fois, trois fois, puis que le client de plus en plus impatient lui dise: «Non, le bogue est toujours là. "

Certains développeurs sont relativement meilleurs à une activité (révision de code ou construction de tests) qu’à l’autre. Un gestionnaire parfait pèse ces points forts lors de l'attribution des bogues. Une approche d'équipe peut être encore plus fructueuse.

En fin de compte, il peut ne pas y avoir suffisamment d'informations pour reproduire le bogue, et vous devez le laisser mariner pendant un certain temps en espérant qu'un autre client trouve un problème similaire, ce qui vous permet de mieux comprendre le problème de configuration. Si le client qui a vu le bogue le souhaite vraiment, il travaillera avec vous pour collecter plus d'informations. Si ce problème ne se pose qu'une seule fois, il ne s'agit probablement pas d'un bogue de priorité élevée, même si le client est important. Parfois, ne pas faire fonctionner un bogue est plus intelligent que de passer du temps à la recherche d’heures de travail à la recherche d’un défaut vraiment obscur avec peu d’informations.

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.