検索
連載

ソフトウェア技術者のためのバグ百科事典(21)【総まとめ】バグの特定手順を解説山浦恒央の“くみこみ”な話(142)(2/3 ページ)

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第21回は、シリーズの総まとめとして、バグの検出から修正までの「バグ特定手順」の一連の流れを解説します。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

3.2 再現性を見つける

 バグの再現性、規則性が明らかになると、ほぼ、バグの原因を特定できたことになります。例えば、「10周期に1回で異常事象が発生する」「再テストでも同じ事象が再現する」などです。さまざまな入力値から、規則性を探します。例えば、実装抜けのバグ(第126回掲載)やビルド構成(第134回掲載)のバグについては、場合にもよりますが、入力が同じならば、同じ結果を返す可能性が高いでしょう(図2)。

図2
図2 絶対値を求めるプログラム(左:バグありの絶対値取得関数、右:正しい絶対値取得関数)(クリックで拡大)

 図2は、絶対値を求めるプログラムの例題です。例えば、左のようなa < 0の場合は、何もしない条件を記述し忘れていた場合を考えます。左の例では、呼び出し側で、myabs(5)として呼び出すと「-5」となり、正しい絶対値となりません。ですが、5ともう一度入れれば、バグは再現します。

 苦労するのは、再現性が分かりにくいバグです。例えば、処理時間のバグ(第133回掲載)は、負荷が高いタイミングが作用するため、低負荷時にはバグが再現しない可能性があります。他にも複数のタスクやスレッドが非同期で動作する場合は、動作次第では不可解な事象が発生することも少なくありません。

 再現性があっても、再現性を見つけることは簡単ではありません。例えば、うるう年のバグ(第122回第123回掲載)は、4年に1回という長い時間が関係します。この場合、バグの特定に時間がかかるでしょう。

3.3 バグの原因を絞り込む

 バグの原因を特定するために、関係する箇所を絞り込みます。例えば、「バグの原因はハードウェアかソフトウェアか」「バグの原因は、OSか、当該アプリケーションプログラムか」「バグの原因はAモジュールが原因か」などを考察します。

 通信系プログラムのバグ(第140回掲載)の原因を調べるならば、機器の間にWireSharkなどのパケットキャプチャーツールを使います(図3)。

図3
図3 UDPの送受信の例

 図3は、UDPの送受信の例題を示しました。「機器Aからデータを送信できるが、機器Bに届かない」という事象の場合、「送信先の指定が関係しているか」「LANケーブルが断線しているか」などの絞り込みが可能です。

3.4 不良の箇所を見つける

 バグがある範囲を絞り込んだら、ソースコードを読み、関連する変数を表示し、不良の箇所を見つけます(図4)。

図4
図4 無限ループの例

 図4は、無限ループの例です。仕様やプログラムを追うと、不良の箇所が見つかります。単純なコーディングのバグ(第135回第138回掲載)や境界値のバグ(第130回掲載)の場合、「何でこんなミスをしてしまったのだろう」と落ち込むことも少なくありません。

3.5 対策を立案する

 バグの場所が分かると、バグの修正および確認方法を立案します。ただし、フェーズによっては、バグを修正したくてもできないことがありますね。例えば、仕様変更(第136回掲載)に関わるバグ、要求仕様のバグ(第128回掲載)や、残りの予算が十分でない場合、運用方法でカバーする必要があります。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る