「マンデルバグ」の存在をチームメンバーに納得させる方法
アプリケーションを開発しています。これには、別のコーダーによって開発されたライブラリが含まれ、このライブラリは複数のネットワーク接続を介してサーバーと通信します。これには、複数のスレッドが連携して行われます。サーバー側のコードは非常に複雑で、ソースコードにアクセスできません。
最近、私は mandelbug がアプリケーションを時々クラッシュさせることを発見しました。一度再現してスタックトレースが取れたので、バグレポートを公開しました。バグ自体は簡単に修正できます（CLRでプログラムを終了させるバックグラウンドスレッドの1つでキャッチされないWeb例外）。
問題は、開発者が「バグが存在することを確信していない」ため、バグの修正を拒否していることです。不幸にも上司は彼と一緒にサイディングしていて、私がバグの存在を証明し、それがなくなったことを確認する単体テストを作成する「しっかりしたテストケース」を作らない限り、このバグは修正できないと言います。バグの性質上、基本的に不可能なこと。
何かアドバイス？
可能であれば、この欠陥を再現できるかどうかを確認するのに少し時間を費やすかもしれませんスリープまたはブロックを入れることによってアプリケーションコードで==。しかし、あまり時間をかけないでください。この問題はマルチtheading（およびあなたが観察したように）によるものであるため、発生することはまれです。
私のアドバイスは、これにあまり汗を流さないことです。作業を続けてください。このクラッシュに遭遇したときはいつでも、スタックトレースでバグレポートを更新して、これが繰り返し発生であることを伝え、所有者をライブラリ開発者に変更します。その頻度に応じて修正するかどうかを経営陣/リーダーに決定させます。
また、開発者の考え方も理解してください。 「キャッチされていないWeb例外」と言いました。この段階の開発者これを取得することによる他の影響が何であるかは完全にはわからない場合があります。したがって、彼/彼女はコードに触れることに消極的かもしれません。
だから、あなたの多かれ少なかれ明確なコメントから、私はこのようにそれを得ました：
あなたは、単純な追加の例外処理だけが欠けていることを確信しており、libのどのコード行が問題であり、libをどのように修正できるかをすでに知っています。
それでは、不足している数行のコードを自分でライブラリに追加しないでください。その変更を使用してライブラリをテストするようにチームに親切に頼んでください。 libの責任者である開発者が理解しやすい、低リスクの変更であることを確認してください。発生する可能性のある最悪の事態は、修正によって新しい予期しない動作が発生した場合、誰かがVCSの変更を元に戻す必要があることです。
ほとんどの人は、作業がすでに完了していると納得しやすくなります。また、「このコードは間違っています。どういうわけか修正します」とは対照的に、「改善されたソリューションはこちらです」に対してよりよく反応します。
編集：開発者がその変更の追加を拒否する場合、最良のオプションは、ネットワークエラーをシミュレートする分離されたテストハーネス内で問題のあるコードを機能させることです。 レガシーコードで効果的に作業する は、このような種類の問題に取り組む方法に関する多くのテクニックを説明しています。たとえば、問題のあるモジュールと関数のみを含むライブラリのテストバージョンを作成し、制御された条件下で「ネットワーク例外」をシミュレートできる「モック環境」を作成できます。一見、それは一見あまりにも多くの努力のように思えるかもしれませんが、そのような環境ができたら、それに多くの追加テストを追加できます（そして、libの作成者が欠けているものを追加するのを拒否したとき、それは理にかなっていると思います） 1か所での例外処理、そのようなバグの増加が予想されます）。
スタックトレースは、バグが存在する、または少なくとも特定のビルドに存在したという明確な証拠です。あなたが持っていないのは、バグが修正されたという証拠です。彼らはそれを無視するのはばかげている。お客様のシステムで毎回をトリガーした複数のシステムで数十万回の自動試行を行った後、「再現不可能」のバグがありました。
毎年、このようなバグがいくつか発生しますが、ほとんどの場合、スタックトレースの利点さえありません。ほとんどの場合、事前に再現することはできませんでしたが、修正後は簡単に自動テストを行うことができました。
たとえば、数か月前に、ユーザーが1分あたり96ワードより速く入力した場合にのみ発生するバグを修正しました。修正する前は、バグが「ときどき」発生することしか知りませんでした。高速タイピングのための単体テストを書くことは決してありません。しかし、根本的な原因がわかった後、それをテストするのは簡単でした。
バグを修正しても再現できないというまれなケースでも、コードインスペクションでバグを閉じることができます。
このようなバグの場合、自動化された ファズテスト （ランダムテストとも呼ばれます）が再現を試みるのに役立ちます。これは、テストするものに固定されたパラメーター（または入力）のセットをランダム化することにより、バグを見つけるプロセスを自動化します。テストを実行するたびに、タイムスタンプなどのパラメーターがログファイルに記録されるため、クラッシュが発生した場合、（理論的には）同じパラメーターを使用してテストを再生し、再現することができます。
テストプロセスは自動化されているため、短期間に多くのテストを実行できます。多くの場合、一晩実行したままにしておくことができ、午前中にログファイルをチェックして、クラッシュを再現したかどうかを確認できます。
悪魔の擁護者は別の道を示唆しています。
他の開発者は、そこにはバグがないと断言しています。
彼の存在しないとされているバグから地獄にストレスを与え、それをより頻繁にクラッシュさせる方法を考え出すことができますか？