バグの発見と分析
デバッグ
デバッグとは，テストによりソフトウェア故障（不具合）が見つかった後の作業であり，次の2つの過程からなる．
- エラーの正確な性質と原因となっているプログラム内の箇所を見つけること．
- エラーを修正すること．
デバッグの考え方 (デバッグの方法 ~ エラーの分析) について， John Wiley & Sons, Inc., 1979. (長尾真，松尾正信訳: ソフトウェア・テストの技法
,
近代科学社，1980) より抜粋，要約する．
- デバッグの方法
- 帰納法によるデバッグ
- データの組織化
- 仮説の設定
- 仮説の証明
- 推定によるデバッグ
- 原因の列挙
- データによる原因の消去
- 残った仮説の証明
- 逆戻りデバッグ
- テストによるデバッグ
- 帰納法によるデバッグ
- デバッグの原則
- エラーを十分分析せよ
- いきづまったときは，明日までのばそう（時間を置いて考え直す）
- いきづまったときは，問題を他人に説明しよう（問題をもう一度整理する）
- デバッグツールに頼るな（あくまで手段）
- 実験を避ける（実験は最後の手段）
- エラー修正の原則
- 1 つのバグがあるところには，別のエラーもある可能性が高い．
- エラーの兆候ではなく，エラーそのものを修正する．
- 修正が正しいという確率は100%ではない．
- 修正が正しい確率は，プログラムが大きいほど落ちる．
- エラー修正は新しいエラーを生む可能性がある．
- 他の部分に同様のエラーがないかを確認する．
- エラーの分析
エラーを修正した後，エラーの内容を次のような観点から分析することにより，将来の設計やテストにフィードバックしていくことが重要である．- いつエラーが起きたのか
- 誰がエラーを作ったのか
- なぜエラーが起きたのか
- どうすればエラーを防げたか
- なぜエラーは早期に発見されなかったのか
- どのようにしてエラーは発見されたのか
バグの分類
バグを修正した後，その内容を分析することにより，将来の設計，製造ににフィードバックしていくことが重要である．
バグ内容の分類とバグ原因の分類の一般的な例を示す．
- 設計工程のバグ
- バグ内容分類
- 要求仕様不良
- 要求仕様誤り
- 要求仕様が不完全
- 表現，記述の不良（内容曖昧，理解不能）
- 機能仕様不良
- 機能仕様誤り
- 機能仕様が不完全
- 表現，記述の不良（内容曖昧）
- 要求仕様不良
- バグ原因
- 仕様・機能の理解不足
- 検討不足／考慮漏れ
- コミュニケーション誤り（連絡誤り／周知漏れ）
- 単純ミス
- バグ内容分類
- 製造工程のバグ
- バグ内容分類
- 構造不良
- 制御不良（競合条件誤り，タイミング問題を含む）
- 処理論理誤り
- 処理過不足
- データ
- データ定義，構造，宣言誤り
- データアクセス誤り（ポインタ誤り等)
- データ初期設定誤り，漏れ
- データ解放誤り，漏れ
- インタフェース
- 外部インタフェース誤り
- 内部インタフェース誤り
- タイミング問題
- ユーザインタフェース不良
- システム，ソフトウェア構成
- OS 呼び出し，使用方法不良
- API 使用誤り
- 性能不良
- その他
- デグレード
- 構造不良
- バグ原因
- 単純ミス
- 機能・仕様の理解不足
- 検討不足／考慮漏れ
- コミュニケーション誤り（連絡誤り／周知漏れ）
- 言語／環境理解不足
- 水平展開漏れ
- その他
- バグ内容分類
バグの分析ポイント
バグを分析する際，その内容に応じてその後の対処方法も異なる場合が多い．バグ内容に応じて適切な対処を行うことが重要である．
バグ内容の分析の主な観点を示す．
- バグ内容
- "論理誤り" が多い．
作業を中断して，処理フローやプログラム(モジュール)構造のレビューを実施する．
最悪，再設計を考慮すべき場合もある． - "インタフェース誤り" が多い．
各モジュール間のインタフェースの仕様を再確認する．インタフェース仕様に曖昧さや誤りがないか確認する． - "競合条件誤りやタイミング誤り" が多い．
机上では検出できにくいバグが中心に発見されるのであれば，発見されるべきバグが検出されており，デバッグ工程が順調に進んでいると言える． - ハイゼンバグ
それを調査しようとすると変貌したり消えたりするバグのことである．量子力学の不確定性原理を提唱したハイゼンベルクからのもじりである．次のようなバグである．- 結合テストでは発生するが同じチェックをしているはずの単体テストでは発生しない．
- リリース版では発生するが，デバッグ版あるいはデバッガでは発生しない
- 調査のための出力命令を入れると発生しなくなる．
- ユーザー環境では発生するが開発環境では発生しない．
- "論理誤り" が多い．
- "単純ミス" が多い．
チェックの観点を絞って，徹底的にソースコードレビューを行う．
発生頻度が高い単純バグの例としては，次のようなものがある．- 判定条件の誤り
- モジュールコールにおけるパラメータの数，属性の不一致
- ループの終了条件の誤り
- データの型の不一致
- リターンコード判定抜け
- 初期値設定忘れ
- バッファのクリア忘れ
- "検討不足／考慮漏れ"が多い．
該当部分について，再設計をを含め重点的に見直す．
バグの発見がなぜ遅れたかも分析し，対処する必要がある．
- 前工程で発見されるべきバグ"が多い．
大きな品質問題になる．早めに分析，対処する． - "試験実施時の誤り" あるいは，"試験準備の誤り" が多い．
- 実行結果をハードコピーで残しておくことを励行する．また，結果確認は複数人によるクロスチェックを行う．
- 試験手順に無理・ムラがないかどうかをチェツクする．
・試験項目が抽象的すぎる．
・手順の記述が概略的すぎる．
・試験項目消化基準が不明確である． - 試験結果を，見落としていないかを再チェツクする．
- "試験環境の不備" が多い
試験環境を整備する，または，環境が整っている場所で再試験を行う． - "修正方法の誤り" が多い（デグレード）
修正内容のレビュー方法を見直す．修正後の確認，特に影響範囲の調査を徹底する．
／