バグの発生源を分離する
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/12/31 07:52 UTC 版)
このステップはシステムのどの部分が問題を引き起こしているかを特定するものである。これは度々デバッグ作業で最も困難な(ゆえにやりがいのある)ステップとなる。都合の悪いことに問題の発生箇所は兆候の出現箇所と常に同じであるわけではない。例えば、入力レコードが破壊されていたら、プログラムが別のレコードを処理したり間違った情報に基づいて動作するまでエラーは起きないことがあり、その場合レコードが読み込まれてから長い時間が経ってしまっている。 このステップは反復的なテストを必要とすることが多い。プログラマは最初に入力が正しいことを検証し、次に正しく読み込まれたか、正しく処理されたかなどを検証していく。モジュール化されたシステムではモジュール間のインタフェースを通してやり取りされるデータの妥当性を検査することで、このステップをわずかに楽にすることができる。入力が正しく、しかし出力がそうでなければ、エラーの発生源はそのモジュールの中にある。入力と出力を反復的にテストすることでデバッガはエラーが起きている箇所を数行のコードまで特定することができる。 経験の厚いプログラマは、以前の似た状況からの類推でどこに問題があるか仮説を立てることができる。そして疑わしい箇所の入力と出力をテストする。このようなデバッグは科学的手法の一種である。経験の浅いデバッガはプログラムをステップ実行して、プログラムの振る舞いが期待のものと異なる箇所を探そうとする。異常な振る舞いを探すためにどの変数に着目するか決めなければならないので、これもまた科学的手法の一種である。別のアプローチは二分探索の類を使うことである。処理またはデータのフローの中央付近でテストすることで、エラーがプログラムのそれより前で起きているか後で起きているかを確定することができる。データに何も問題が検出されなければ、エラーはそれより後で起きていることになる。二分探索を使わない場合の探索時間が最大tだとすれば、二分探索を使った場合の探索時間は最大log2 tである。
※この「バグの発生源を分離する」の解説は、「デバッグ」の解説の一部です。
「バグの発生源を分離する」を含む「デバッグ」の記事については、「デバッグ」の概要を参照ください。
- バグの発生源を分離するのページへのリンク