debugging - 統計デバッグとは

Question

統計デバッグとは 明確で簡潔な説明はまだ見つかっていませんが、この用語は確かに印象的です。

単なる研究テーマなのか、それともどこかで実際の開発に使われているのか。つまり、プログラムのバグを見つけるのに役立ちますか?

Answer 1

私は、長年にわたってさまざまな素晴らしい協力者とともに、統計デバッグを作成しました。数か月前にあなたの質問に気付きたかったのに! しかし、まだ興味がある場合は、この遅い回答が何もないよりはましかもしれません。

非常に高いレベルでは、統計的デバッグとは、プログラムの成功/失敗の統計モデルを使用してバグを追跡するという考え方です。これらの統計モデルは、特定のプログラムの動作と実行の最終的な成功または失敗との間の関係を明らかにします。たとえば、プログラムの特定の分岐が、左に行くこともあれば右に行くこともあることに気付いたとします。また、分岐が左側にある実行は問題ありませんが、分岐が右側にある実行はクラッシュする可能性が 75% 高いことにも気付きます。したがって、ここには統計的な相関関係があり、より詳しく調査する価値があるかもしれません。統計的デバッグは、障害と相関するプログラムの (誤った) 動作を見つけるプロセスを形式化して自動化し、開発者をバグの根本原因に導きます。

元の質問に戻ります。

単なる研究テーマなのか、それともどこかで実際の開発に使われているのか。

これは主に研究テーマですが、「現実の」世界では 2 つの方法で存在しています。

1. Cooperative Bug Isolation Projectの公開展開では、 Fedora Linux で実行されているさまざまなオープン ソース プログラムのバグを探しています。インストルメント化済みのパッケージをダウンロードできます。それらを使用するたびに、バグを見つけるのに役立つデータが提供されます。

2. Microsoft は、.NET の統計デバッグの実装である Holmesをリリースしました。これは Visual Studio にうまく統合されており、統計デバッグを使用して独自のコード内の独自のバグを見つけるのに非常に簡単な方法であるはずです。私は Holmes に関する Microsoft Research と密接に協力してきましたが、彼らは高品質のツールを作成する方法を知っている優秀な人々です。

注意すべき 1 つの警告: 統計デバッグには、適切な統計モデルを構築するための十分な生データが必要です。CBI のパブリック展開では、その生データは実際のエンド ユーザーから取得されます。Holmes の場合、Microsoft は生データが社内の自動ユニット テストと手動テストから得られると想定していると思います。動作しないのは、実行がまったくないコード、または実行が失敗するだけで反例が成功しないコードです。統計的デバッグは、良い実行と悪い実行の対比に基づいて機能するため、両方にフィー​​ドする必要があります。実行せずにバグハンティング ツールが必要な場合は、何らかの静的分析が必要になります。私もそれについて研究していますが、それは統計的デバッグではありません。:-)

これが役に立ち、長すぎなかったことを願っています。フォローアップの質問にお答えします。ハッピーバグハンティング！

Answer 2

それは、「まあ、おそらく動作する...」と言ってソフトウェアを出荷するときです;-)

編集: これは、機械学習と統計的クラスタリングを使用して、バグの優れた予測因子であるプログラム内のパターンを見つけようとする研究トピックであり、より多くのバグが隠れている可能性がある場所を特定します。

Answer 3

統計的サンプリングのように聞こえます。製品を購入する際、「組み立てライン」から出てくるすべての製品の品質がチェックされているわけではありません。

統計的サンプリングでは、特定の割合の製品をチェックして、すべての問題がないことをほぼ確認する必要があります。いくつかの問題が忍び寄るリスクを最小限に抑え、テストプロセスが破壊的なものである場合に絶対に必要です-生産ラインの100％で破壊的なテストを実行する場合、配布用に多くを残すことはありません:-)

正直に言うと、すべての実行パスと考えられるすべての入力値をチェックしない限り、テストで既にこれを行っています。最も単純なシステム以外のすべてをテストするために必要な労力は、それだけの価値はありません。余分な費用がかかると、あなたの製品は非競合品になります。

統計的サンプリングは、100 単位ごとにテストするだけではないことに注意してください。問題を検出する可能性を高めるために、サンプリングを対象とする方法があります。たとえば、過去のデータから、ほとんどのエラーが特定のフェーズで導入されたことが示唆されている場合は、そのフェーズをターゲットにします。開発者の 1 人が他の開発者よりも問題を抱えている場合は、その開発者の作業をより綿密にチェックしてください。

いくつかの研究論文をざっと見ただけでわかることですが、統計的デバッグとは、過去の問題の履歴に基づいて領域をターゲットにするということです。

私たちのソフトウェアですでにこれを行っていることは知っています。修正されるバグはすべて、問題を再現する単体テストとシステム テストに合格する必要があるため (TDD は、バグを修正する前にこれらのテストを作成する必要があると述べています)、これらのテストは自動的に回帰テスト スイートに追加されます。より多くの問題を引き起こす原因は、将来的により頻繁にテストされます。