「再現不可能な」バグに対処するための良い戦略はありますか？
非常に多くの場合、「再現できない」欠陥のバグレポートを取得または送信します。それらは、コンピュータまたはソフトウェアプロジェクトで再現できる場合がありますが、ベンダーのシステムでは再現できません。または、ユーザーが再現する手順を提供しましたが、ローカルで欠陥を確認することはできません。もちろん、このシナリオには多くのバリエーションがあるので、簡単にするために、私が学ぼうとしていることは次のとおりです。
「再現不可能な」バグに対するあなたの会社の方針は何ですか？それらを棚に置き、閉じ、無視しますか？サードパーティのフレームワークで断続的で再現性のないバグが時々見られます。これらはほとんどの場合、ベンダーによって即座にクローズされます...しかし、これらは実際のバグです。
これらのタイプのバグを修正するのに役立つテクニックを見つけましたか？通常、私が行うことは、ユーザーからシステム情報レポートを取得し、再現する手順を実行してから、キーワードを検索し、あらゆる種類のパターンを確認することです。
- エラーの生成に使用された手順を確認してください
多くの場合、エラーを報告している人、またはエラーを再現している人は、何か間違ったことをして、同じ状態にならないようにします。報告者と一緒にそれをウォークスルーしてみてください。管理者権限が正しく表示されていないというユーザーINSISTがありました。エラーを再現しようとしましたが、再現できませんでした。一緒に見てみると、その場合は通常のユーザーとしてログインしていたことがわかりました。
- エラーの生成に使用されたシステム/環境を確認してください
私は多くの「再現不可能な」バグを発見しましたが、後でXバージョンのSafariを実行しているMac OS（10.4）で再現可能であることがわかりました。そして、これはブラウザとレンダリングだけに適用されるのではなく、何にでも適用できます。ユーザーがRDPであるかローカルであるか、管理者であるかユーザーであるかなど、現在実行されている他のアプリケーション...再現不可能と呼ぶ前に、環境をできるだけ環境に近づけてください。
- スクリーンショットとログを収集
ユーザーがすべてを正しく実行し、まだバグが発生していること、およびユーザーが実行していることを正確に実行していて、バグが発生していないことを確認したら、次に、実際に何ができるかを確認します。スクリーンショットとログは重要です。あなたはそれがどのように見えるか、そしてその時に何が起こっていたかを正確に知りたいのです。
ログには、システムで再現できる情報が含まれている可能性があります。正確なシナリオを再現できれば、エラーを隠さないようにすることができる場合があります。
スクリーンショットもこれに役立ちます。「Xピースは正しくロードされましたが、Yに依存しているため、ロードされるべきではない」ということがわかり、ヒントが得られる可能性があるためです。ユーザーが何をしているかを説明できたとしても、スクリーンショットはさらに役立つ可能性があります。
- ユーザーから段階的な説明を収集します
ユーザーを非難することは非常に一般的であり、ユーザーが言うことを信用しない（「ユーザーコントロール」を「何か」と呼ぶため）が、ユーザーが見ているものの名前を知らない場合でも、ユーザーはそれを行うことができます。彼らが見ている行動のいくつかを説明してください。これには、実際のエラーが発生する数分前に発生した可能性のあるいくつかのマイナーエラー、または通常は高速な特定のものの速度低下が含まれます。これらすべてのことは、あなたのマシンではなく、彼らのマシンでエラーを引き起こしている側面を絞り込むのに役立つ手がかりになります。
- 別のアプローチを試してエラーを生成してください
他のすべてが失敗した場合は、問題を引き起こしているコードのセクションを調べてみてください。リファクタリングするか、回避策を使用してください。すでに存在する情報の半分（できればUAT）から開始するシナリオを作成できる場合は、ユーザーにそのアプローチを試してもらい、エラーが引き続き発生するかどうかを確認してください。エラーをよりよく調べることができるように、エラーを別の観点から捉える、代替ではあるが類似したアプローチを作成するのが最善ですか。
簡単な回答：理論上のバグを修正し、将来の障害を監視およびログに記録するコードを追加することを目的として、障害の疑いのあるコードについて詳細なコードレビューを実施します。
長い答え：組み込みシステムの世界から実際の例を挙げます。カスタム電子機器を含む産業用機器と、その上で実行される組み込みソフトウェアを作成します。
ある顧客から、1つのサイト上の多数のデバイスでランダムな間隔で同じ障害が発生していると報告されました。いずれの場合も症状は同じでしたが、明らかな原因を特定することはできませんでした。
明らかに、私たちの最初のステップは、ラボ内の同じデバイスで障害を再現することでしたが、これを行うことはできませんでした。
そこで、代わりに、欠陥の疑いのあるコードを部門内に回覧し、できるだけ多くのアイデアや提案を得ようとしました。次に、これらのアイデアについて話し合い、次のような理論を決定するために、いくつかのコードレビュー会議を開催しました。（a）現場で観察された障害の最も可能性の高い原因を説明した。 （b）それを再現できなかった理由を説明した。 （c）将来発生する障害を防ぐために、コードに加えることができる改善につながりました。
（理論上の）バグ修正に加えて、監視コードとログコードも追加したため、障害が再度発生した場合でも、問題のデバイスから有用なデータを抽出できます。
私の知る限り、この改善されたソフトウェアはその後サイトに展開され、成功したようです。
エラー報告、ログファイル、および厳しい要求により、「これが再度発生した場合は、すぐに連絡してください」。
それが別のコンテキストではなく、あるコンテキストで発生する場合は、両方の違いを列挙し、それらを排除しようとします。
これが機能する場合もあります（たとえば、他のハードウェア、デュアルコアとハイパースレッディング、ラップトップディスクとワークステーションディスクなど）。
時々そうではありません。可能であれば、リモートデバッグを開始する場合があります。それでも問題が解決しない場合は、お客様のシステムを入手してみてください。
しかしもちろん、そもそもあまり多くのバグを書くことはありません:)
「無菌」と「不気味」を解決
この状況には、2つのクローズドバグカテゴリがあります。
滅菌済み-再現できません。
不気味な-問題があることは認められていますが、断続的に表示され、完全には理解できず、誰もが気味の悪いケースになります。
Visual Studio2010の新機能のいくつかが役立ちます。見る：
さて、あなたはそれを再現するために最善を尽くします、そしてあなたがそれができないならば、あなたは長い間考えて、そのような問題がどのように起こるかを考えます。それでもわからない場合は、それについてできることはあまりありません。
再現可能な問題について話しますが、一部のシステムでのみ発生します。これらは扱いやすいです：
最初のステップ：ある種のリモートソフトウェアを使用して、問題が発生しているシステムで問題を再現するために何をすべきかを顧客に指示させます。これが失敗した場合は、閉じます。
2番目のステップ：別のシステムで問題を再現してみてください。これが失敗した場合は、顧客システムの正確なコピーを作成してください。
3番目のステップ：それでも失敗する場合は、お客様のシステムでデバッグを試みる以外に選択肢はありません。
再現できたら修正できます。どのシステムでも構いません。
トリッキーな問題は、真に再現不可能な問題です。つまり、断続的にしか発生しない問題です。そのために、私は報告書、ログ、厳しい要求の態度を取り入れなければなりません。 :)
実稼働環境の正確な複製である実稼働前の環境でも、バグを再現できない場合があります。並行性の問題はこれで有名です。
その理由は、単にハイゼンベルグ効果、つまり観測の変化の振る舞いが原因である可能性があります。もう1つの理由は、バグをトリガーするイベントの組み合わせにヒットする可能性が非常に低いためである可能性があります。
運が良ければ、再生可能な監査ログがあり、問題が再現される可能性が大幅に高まります。大量のトランザクションで環境にストレスをかけることもできます。これにより時間を効果的に圧縮できるため、たとえば週に1回バグが発生した場合、システムに本番負荷の7倍の負荷をかけると、1日で確実に再現できる可能性があります。
最後の手段は、ホワイトボックステストです。このテストでは、コードを1行ずつ記述してユニットテストを実行します。
このようなバグ（再現性はほとんどない）を分類し、特定のユーザーアクションに基づいて再現性が高いバグとは異なる方法で対処することが重要です。
問題の説明を明確にし、動作を再現して観察する手順を示します：明確なレポートは、チーム全体が問題を理解するのに役立ち、誤った結論を排除します。たとえば、空白の画面を報告するユーザーは、ユーザーアクションでのHMIフリーズとは異なります。手順の順序とユーザーアクションのおおよそのタイミングも重要です。ユーザーは画面遷移後すぐにオプションを選択しましたか、それとも数分間待ちましたか？タイミングに関する興味深いバグは、自動車エンジニアを困惑させたバニラアイスクリームにアレルギーのある車です。
システム構成と起動パラメーター：ハードウェア構成とアプリケーションソフトウェアバージョン（ドライバーとファームウェアバージョンを含む）でさえ、1つか2つのトリックを実行する場合があります。バージョンまたは構成の不一致は、他のセットアップで再現するのが難しい問題を引き起こす可能性があります。したがって、これらはキャプチャする必要のある重要な詳細です。ほとんどのバグ報告ツールには、問題のログ記録中に報告する必須パラメーターとしてこれらの詳細があります。
広範なロギング：これは、関連するプロジェクトで追跡されるロギング機能に依存します。組み込みLinuxシステムで作業している間、一般的な診断ログだけでなく、dmesgやtopコマンドログなどのシステムレベルのログも提供します。間違った部分がコードフローではなく、異常なメモリ使用量/ CPU使用率であることをあなたは決して知らないかもしれません。問題の種類を特定し、調査のために関連するログを報告します。
コードレビューとウォークスルー：開発チームは、これらの問題を最後に再現してからアクションを実行するのを永遠に待つことはできません。バグレポートと利用可能なログを調査し、これに基づいて設計とコードからさまざまな可能性を特定する必要があります。必要に応じて、考えられる根本原因について修正プログラムを準備し、修正プログラムを特定したテスターを含むチーム間で修正プログラムを配布して、バグが再現可能かどうかを確認する必要があります。
修正が特定され、チェックインされた後、単一のテスター/チームによる観察に基づいてこれらの問題をクローズしないでください：おそらく最も重要な部分は、これらの問題をクローズするためのアプローチです。これらの問題の修正がチェックインされたら、集中的なテストを実行し、リグレッションエラーがある場合はそれを特定するために、さまざまな場所にあるすべてのテスト/検証チームに通知する必要があります。それらのすべて（事実上それらのほとんど）のみが再現不可能であると報告し、閉鎖評価は上級管理職によって行われなければなりません。
ロギングはあなたの友達です！
一般に、再現できないバグを発見した場合は、お客様にログを追加するように依頼するか（利用可能な場合）、関心のある領域にログを追加したバージョンをリリースします。私たちが持っているロギングは優れており、非常に冗長になる能力があるため、追加のロギングを含むバージョンのリリースは頻繁には発生しません。
また、メモリダンプの使用も検討する必要があります（IMOもロギングの傘下にあります）。ミニダンプの作成は非常に高速であるため、通常、負荷がかかっている場合でも（作成されるダンプの数が少ない限り）本番サーバーで実行できます。
私の見方：問題を再現できることは、デバッグ、実験、およびより自由に遊ぶことができる環境を提供するため、素晴らしいことですが、バグの再現は、デバッグに不可欠ではありません。！バグが他の誰かのシステムでのみ発生している場合でも、同じ方法で問題を診断してデバッグする必要があります。今回は、それをどのように行うかについて賢くする必要があります。
プログラム全体で例外処理コードにログを追加します。ログを収集する方法が必要です（ユーザーはログを電子メールで送信できます）。
コードバージョンと正常な環境のプリエンプティブチェックも良いことです。最近のソフトウェアアップデートの容易さにより、ユーザーが実行しているコードと環境はほぼ確実にテストされていません。コードをリリースしたときには存在しませんでした。
私が現在開発しているWebプロジェクトでは、あなたのテクニックと非常によく似た何かをしています。ブラウザのバージョンやオペレーティングシステムなどの情報を収集するために、ユーザーに誘導できるページを作成しています。また、アプリのレジストリ情報を収集して、アプリが何をしているかを確認できるようにします。
これは非常に現実的な問題です。私はウェブ開発についてしか話すことができませんが、問題を調査するために必要な基本的な情報をユーザーが私に提供することはめったにありません。他の種類の開発と同様のことを行うことは完全に可能だと思います。私の計画は、このシステムをますます便利にするために、このシステムに取り組み続けることです。
しかし、私のポリシーは、バグがどんなに煩わしくても、再現できないという理由だけでバグを閉じることは決してありません。そして、それがバグではないが、ユーザーが単に混乱している場合があります。これは私が推測する別の種類のバグですが、同じくらい重要です。
Windows 7には、ユーザーが行っていることを記録してからレポートを送信できる優れた新機能があります。これは、すべての段階のスクリーンショットを含むドキュメントとして提供されます。うまくいけば、開発者が思いもよらない順序でユーザーがアプリケーションを操作している場合に役立つでしょう。開発者のアプリの論理的な使用方法がエンドユーザーの実際の使用方法に適合しない場合にのみ発生するバグをたくさん見てきました...多くの微妙なエラーが発生します。
受け入れられた答えは、最良の一般的なアプローチです。大まかに言えば、バグを修正することの重要性と、ユーザーに役立つ機能または拡張機能として追加できるものとを比較検討する価値があります。 「再現不可能な」バグの修正には2日かかるでしょうか？その間に、バグ修正よりも多くのメリットをユーザーに提供する機能を追加できますか？たぶん、ユーザーはこの機能を好むでしょう。私は時々開発者として私が見ることができる欠陥に固執しました、そしてそれからユーザーはフィードバックを求められます、そして彼らの誰も私が見ることができるバグについて実際に言及しません、しかしソフトウェアは彼らが本当に望む機能を欠いています！！
場合によっては、デバッグ中にバグを再現しようとする単純な永続性が最も効果的なアプローチになることがあります。この戦略が機能するためには、バグが完全に「再現不可能」ではなく「断続的」である必要があります。 10回に1回でもバグを繰り返すことができ、バグが発生している可能性が最も高い場所についてのアイデアがある場合は、それらのポイントにブレークポイントを設定し、バグを繰り返して、何が起こっているかを正確に確認することができます。私はこれが1つか2つのケースでロギングするよりも効果的であることを経験しました（ただし、ロギングは一般的に私の最初の頼みの綱です）。
再現できない場合は、ログを取得し、正確な手順のスクリーンショットを再現します。