Apprendre à enquêter sur les bogues [fermé]

Je ne sais même pas comment définir cette difficulté. Cela me rappelle le test que deux employés potentiels m'ont fait avant d'obtenir un emploi. Ils choisiraient un objet dans la pièce et ensuite je serais autorisé à poser des questions pour m'aider à déterminer ce qu'est cet objet (un peu comme 20 questions). J'étais ridiculement bon dans ce domaine (non, je n'ai jamais obtenu de points forts pour l'humilité), alors je supposais que je serais vraiment bon pour résoudre les bugs ...

Mais voici ce que j'ai découvert récemment. Je suis vraiment bon dans cette situation car il est vraiment facile de voir tout ce qui se trouve dans la pièce, donc je peux aborder mon problème avec un concept de ses composants. En substance, je "sais ce que je ne sais pas". Mais avec la programmation, je rencontre beaucoup de situations où le problème est complètement inconnu pour moi. Je sais qu'il est cassé, mais je n'ai aucune idée de comment il pourrait être cassé. J'ai suivi toutes les instructions, je connais assez bien la technologie ...

Si je suis honnête, j'ai l'impression d'avoir du mal à imaginer des choses qui pourraient mal tourner afin que je puisse les tester et, espérons-le, trouver une solution.

Comment puis-je développer cette compétence? Que dois-je faire pour aider mon imagination apparemment limitée à trouver des moyens de briser mon projet? Y a-t-il des exercices (des puzzles peut-être?) Qui peuvent m'améliorer dans ce domaine? Je suis conscient que le plus grand remède est probablement l'expérience ... mais j'espère aider à accélérer le processus si je le peux. Regarder mon écran d'ordinateur vide pendant quelques heures à la fois n'est même pas amusant ...

Chaque défaut dans le logiciel est finalement dû à un écart entre les hypothèses et la réalité. Les bogues insidieux sont simplement des écarts entre des hypothèses particulièrement profondes et la réalité. La capacité de diagnostiquer les bogues dépend de votre capacité à remettre en question vos propres hypothèses, et cela nécessite en effet une prise de conscience que vous ne savez pas certaines choses, vous les avez simplement assumées et vous aviez raison jusqu'à présent.

Évidemment, les outils du commerce, les fichiers journaux, les débogueurs, etc. sont utiles pour découvrir de telles hypothèses et réaligner votre modèle mondial avec le système réel. Mais jusqu'à ce que vous soyez prêt à remettre en question l'hypothèse cruciale, par exemple "Ce ne peut pas être une mauvaise entrée car nous avons une vérification complète des entrées", vous passerez tout votre temps à vérifier les mauvaises parties du système, ou tout simplement à ne pas savoir où chercher. en premier lieu.

Que dois-je faire pour aider mon imagination apparemment limitée à trouver des moyens de briser mon projet?

Dans la plupart des cas, je ne dirais absolument rien. Vous ne devriez pas essayer d'imaginer des choses qui pourraient provoquer la rupture du programme. Vous devriez être déterminer systématiquement ce qui est à l' origine de la casser.

Vous devriez entrer dans le processus de débogage avec les informations suivantes:

• les étapes qui ont été prises et les valeurs qui ont été entrées pour produire le bogue;
• ce que le programme devrait faire une fois ces étapes et ces contributions données;
• ce que le programme est en train de faire quand donné les étapes et les entrées.

S'il y a un message d'erreur, obtenez toutes les informations que vous pouvez à ce sujet. Si le message d'erreur lui-même n'est pas clair et que vous ne savez pas ce que cela signifie dans la pratique (certains messages d'erreur ne sont pas toujours particulièrement utiles), utilisez Google, StackOverflow ou toute autre ressource en ligne pour trouver des informations à ce sujet. .

S'il n'y a pas de message d'erreur affiché sur le frontal, vérifiez tous les journaux dans lesquels l'application écrit pour les messages d'erreur pendant la période pendant laquelle vous avez reproduit le bogue. Le code peut s'être exécuté jusqu'à la fin, mais a rencontré une exception qui est gérée en cours de route, ce qui annule le résultat final et produit une entrée dans les journaux. Recherchez-les, faites de même ci-dessus et identifiez exactement ce qu'ils signifient.

S'il existe des traces de pile fournies avec des exceptions levées par votre code (et il devrait y en avoir), regardez les lignes de code mentionnées. La ligne elle-même n'est peut-être pas celle qui produit réellement le problème. Si vous obtenez une NullPointerException dans un morceau de code Java, le stacktrace vous indiquera où vous avez essayé d'utiliser quelque chose qui était nul lorsque vous vous attendiez à ce qu'il ne soit pas. Cela ne vous indique pas exactement la ligne à l'origine du problème, mais elle vous indique généralement quelle variable n'a pas la valeur que vous attendez d'elle, vous pouvez donc consulter toutes les références / affectations à cette variable pour déterminer que la valeur n'est pas définie ou que la valeur est définie de manière incorrecte.

Si rien de tout cela n'a aidé, lancez votre débogueur. Si vous l'avez réduit à une section du code qui, selon vous, est à l'origine du problème - mais vous ne savez pas exactement quelle (s) ligne (s) - passez à l'étape suivante. Si ce n'est pas le cas, parcourez le tout. C'est là que vous devez savoir exactement ce que le programme devrait faire avec des entrées données, car vous devez regarder chaque valeur après chaque ligne et déterminer exactement où elle s'écarte de ce que vous attendez d'elle.

Vous ne savez toujours pas quel est le problème? Demandez de l'aide à quelqu'un . Un collègue, un ami, une communauté en ligne. Montrez-leur tout le travail que vous venez de faire. Montrez-leur les messages d'erreur, les traces de pile, expliquez ce que le programme fait en termes généraux (s'ils ne le savent pas déjà), ce qu'il devrait faire dans ce cas particulier (par exemple, renvoyer la valeur 4), ce qu'il fait réellement (par exemple renvoyant la valeur 5). Si vous l'avez réduit à quelques lignes de code dans le débogueur, dites "Je sais que le problème est dû à ces lignes dans le code, il définit la valeur sur X alors qu'elle devrait être Y, mais je ne vois pas pourquoi cela se produit ".

Passer quelques heures à regarder fixement votre écran n'est certainement pas amusant, mais il n'y a aucune raison que vous fassiez cela. S'il y a un problème avec votre code, vous devez lire ou parcourir le code.

Dans une certaine mesure, c'est comme enquêter sur une affaire pénale ou un puzzle époustouflant.

D'abord, tu as la victime. Après avoir creusé un certain temps dans l'affaire, vous avez identifié quelques suspects et vous avez également développé une hypothèse de travail sur la façon dont la victime pourrait être tuée. Vous continuez à enquêter, à chercher des informations plus utiles, à vous rapprocher de plus en plus de la véritable source du problème.

Il arrive que de temps en temps vous entrez dans une impasse (jeu de mots voulu). Cela en fait partie, et il n'y a rien de mal à cela, tant que vous parvenez à vous remettre sur les rails le plus rapidement possible. La clé est, de toujours penser à quelle information dont vous avez besoin ensuite, qui soit fournit votre hypothèse (et vous fournit de plus amples informations), ou prouve qu'elle est fausse. Trouvez ensuite un moyen d'obtenir ces informations de manière efficace, tirez vos conclusions et continuez jusqu'à ce que vous puissiez enfin condamner le coupable.

Et parfois vous vous rendez compte que tous les faits et indications nécessaires pour repérer le coupable vous attendaient déjà il y a une demi-heure. Bien que gênant, c'est parmi les parties les plus intéressantes, car si vous faites un examen critique de vos actions et de vos erreurs, vous pourrez peut-être apprendre et vous améliorer . Posez-vous des questions comme:

• Comment aurais-je pu éviter cette perte de temps?
• Qu'est-ce que j'ai oublié en premier lieu et pourquoi?
• Sur quelles hypothèses non validées et / ou erronées ai-je eu recours?

Cela entraînera vos capacités. Cela développera également votre instinct , donc au fil du temps, vous apprendrez à remarquer automatiquement toutes ces choses mineures qui sont trop facilement négligées, vous conduisant plus rapidement à la bonne réponse. À la fin, tout est question de pratique délibérée .

Enfin, n'oubliez pas toujours ce que Sherlock Holmes nous a appris: lorsque vous avez éliminé l'impossible, tout ce qui reste, aussi improbable soit-il, doit être la vérité.

Que dois-je faire pour aider mon imagination apparemment limitée à trouver des moyens de briser mon projet?

Laissez l'histoire vous guider. Si votre projet est bien géré, vous devez disposer d'une base de données de chaque bogue qui a déjà été corrigé dans le produit, ainsi qu'une analyse de la façon dont le bogue a été trouvé, comment il a été reproduit, comment il a été analysé et comment il a été corrigé. Ce n'est pas une base de données en écriture seule. Lisez la base de données et très bientôt, des taxonomies de bogues commenceront à vous apparaître.

Cela vous donnera un bon aperçu des types de problèmes qui se produisent dans votre produit. Si vous êtes plus généralement intéressé par ce qui ne va pas dans toutes sortes de logiciels, en particulier en mettant l'accent sur les défauts affectant la sécurité, je vous suggère de lire la liste CWE: http://cwe.mitre.org/data/index.html

Donc, plutôt que d'essayer de reproduire et de corriger un défaut spécifique, je pense que vous demandez de penser à de nouveaux tests que vous pourriez utiliser pour enquêter sur le produit pour voir si le produit fonctionne dans ces circonstances, par exemple: que se passe-t-il si j'entre des caractères spéciaux dans notre le mot de passe de la page d'inscription est enregistré, ou ce qui se passe si je ferme de force le programme pendant qu'il écrit dans la base de données. Ces cas sont en effet difficiles à imaginer.

Le développement de logiciels au cours des 10 dernières années (Agile / XP / TDD, etc.) a pris de la valeur en répondant uniquement aux exigences explicites, puis en déclarant la fonctionnalité terminée, et en ne trouvant pas tous les moyens possibles de casser quelque chose (il y a des exceptions possibles, si vous êtes travailler pour la NASA ou faire de la sécurité avec un chapeau blanc, mais même dans ce cas, il y a lieu de faire valoir de telles choses dans les critères d'acceptation de la user story).

Donc, si vos fonctionnalités répertorient explicitement comme critères d'acceptation ce que les systèmes ont besoin, comme la façon de gérer les entrées, ses caractéristiques de performance, les actions du flux de travail des utilisateurs, etc., alors vous avez une liste complète de ce que les tests doivent vérifier. Des tests doivent être effectués pour valider que les exigences ont été respectées, et la meilleure façon de le faire est de répertorier explicitement toutes vos exigences. Jetez un œil aux quadrants de test Agile .

Certaines personnes préconisent que ces tests soient la déclaration explicite des exigences, qui doivent être écrites avant le code, c'est-à-dire Test First (ou Test Driven Development).

Cependant, j'apprécie que vous n'ayez pas l'impression que vous envisagez un nouveau projet où vous pouvez définir vos propres meilleures pratiques de développement avant de commencer et que vous venez à la place après que le logiciel a été écrit et qu'on vous demande de le `` tester ''. C'est en effet plus difficile mais les mêmes principes s'appliquent, vous ne pouvez le tester qu'une fois que vous savez ce qu'il était censé faire. S'il n'y a pas de liste complète des exigences auxquelles l'équipe de développement a répondu pour vous permettre de travailler, alors poser des questions est la meilleure façon de procéder. Selon votre équipe, il peut être nécessaire de le faire délicatement, car les personnes qui n'ont pas explicitement énuméré leurs exigences avant de créer un système logiciel n'aiment pas se souvenir de ce qu'elles ont manqué, mais il est essentiel de bien effectuer cette tâche.

Une fois que vous avez trouvé une exigence - elle doit être robuste / elle doit être sécurisée, puis essayez de creuser plus profondément et de découvrir à quel point elle doit être sécurisée, ou combien d'échec est acceptable, il y a toujours une limite, peu de gens ont une preuve NSA niveau de sécurité comme exigence pour leur application ou voudrait payer pour cela. Plus vous creusez, plus il devrait être clair quant aux types d'attaques de sécurité contre lesquelles vous devez vous défendre ou faciles à utiliser. Certaines connaissances du domaine sont alors utiles, en sécurité, en design, en performance, etc., c'est là que vous posez encore plus de questions aux experts que vous pouvez trouver dans votre équipe, ou ici sur SE, ou google / books.