デバッグ

デバッグとは

デバッグとは、その名の通りプログラムからバグを取り除くことです。

ほんとのこと言うと私はこの作業あまり好きではありません。

プログラミングは想像力と創造力を駆使する建設的な作業ですが、 デバッグは粗探しみたいなもので、自分で作成したプログラムなら、まだしも 他人が作ったプログラムのデバッグは、「そんな細かいことまで・・・」って言われてしまうような仕事です。

でも、プログラムを作成した以上デバッグをしないわけにはいきません。 　どんなに注意して作成したプログラムであっても、たくさんのバグが潜んでいるものなのです。

逆に考えれば、デバッグで確認できるから、今はとりあえずこの方法でプログラミングしておいて、 デバッグの時に考えようとすることもできます。

ここでは、特に自分で作ったプログラムを自分でデバッグするという観点で話を進めていきたいと思います。

デバッグのコツ

コツというほどのことではないかもしれませんが、デバッグしていてバグを見つけた場合 まずは、現象をよく見る事です、今自分が見ているディスプレイや印刷物、表示器から得られる情報を 粒さに検討する事が、バグ修正の近道です。

あるデータの異常に気づいたら、そのデータだけではなく、他のデータやステータス表示、 もしハードが繋がっているシステムであれば、装置の状況、装置の表示機（LED）などを観察しましょう。

貴方が作成したプログラムなのですから、その状態を見ただけで原因が分かることも多いと思います。

なので、異常発見→直ぐにデバッガーという発想は控えてください。

もうひとつ、もし複合的なバグ、外部要因によるバグであれば、デバッガーを動作さてみたら、現象は起こらなく なってしまうこともありえます。 そして、納入後ある日突然そのバグが姿を現すなんてことも・・・。

もしかしたらそのバグを修正する、ただ一度のチャンスということもあるのです。

心構え

自身が作成したプログラムをデバッグする場合、まずはバグは必ずあるという心構えを持ってください。

どうしても自分で作成したプログラムなので、ここは大丈夫だろうとか、ここは作りながら、ある程度デバッグしたから、 きっと巧く動くだろうといった、といった先入観ができてしまいます。

また、無意識に危険な操作を避けることもあります＾＾

まずは先入観をなくし、１から仕様書を読みデバッグしましょう。

バグの種類

理由はともかく、起きている現象からバグの種類を整理してみましょう。

• 仕様書との不一致

仕様書に書いてある通りに動作しないということです。 何度も仕様書は読んでいるはずななのに、思い込みや勘違いから起こります。

デバッグは仕様書を再度見直しながら行ないましょう。

• 論理的な不具合

インプットとアウトプットの関係があっていないということです。

たとえば、100という数値を入力しれば、120という値が表示されるはずなのに119と表示されてしまうということです。

上の例は単純ですが、会計ソフトでの残高集計、消費税の計算など、複雑で、発見することも困難なバグもあります。

• ハングアップしてしまう

ある操作をするとアプリケーションがフリーズしてしまうという致命的なバグです。

ある操作というのが限定できれば、解決はさほど難しくはありません、デバッガーでその操作を引っ掛ければ 原因はすぐに発見できるでしょう。

但し、ある操作が限定できない場合、または、たまにしか起きないとなれば、ちょっと厄介です、いくつかの要因が 組み合わさったバグかもしれません。

• 異様に時間が掛かる処理がある

データベースを使用したプログラムによくありがちな現象です、バグとは言えないのですが、 SQL文、データベースのインデックスの付け方、予期しないデータ量、などなど、全てもう一度確認する必要があります。

以上、簡単に整理してみました。

この中で最も重要なのは、「仕様書との不一致」，「ハングアップしてしまう」です、できるだけ早く発見し修正しましょう。 ここで、もし、大幅な修正が必要であれば、他のデバッグは殆ど無駄になる可能性があります。 そして最も時間がかかるのは「論理的な不具合」です、システムの規模にもよりますが、 テストしなければならないパターンが膨大になる可能性があります。

デバッグの段階

とにかく、第一段階では、通常の作業で不具合が生じないようにします。

それが終われば、とりあえず、担当者やエンドユーザーにお披露目できるからです。 お披露目することで、早めに修正点などを指摘してもらうことができます。

第2段階では、いろいろなパターンを試しさらにバグを取り除いていきます。

先ほど書いた通常の作業とは、プログラマである私が考えた作業であって エンドユーザーは全く違う操作をすることもありえます。

いろいろなパターンとは何かというと、作成したアプリケーションの分野にもよるのですが、 例えば、操作の順番、多種のモードがある場合は全てのモードでの複合的チェック、 データ量の増減による印刷物のチェック・・・・などなど、 膨大な作業となります。　

自分が考え付く全てのパターンをチェックできれば言う事はないのですが、 時間が限られている場合は、プログラム的に全てのルーチンのチェックができるようにパターンを考えてみましょう。

全く同じオブジェクトや関数を通るパターンは、1回のチェックで済ませてしまうなどの工夫凝らします。 　これは、自分で自分のプログラムをデバッグするということの唯一の利点でもあります。

そして、第3段階は実データでのチェックです。

OAなどのパソコンソフトの場合、デバッグ中はテスト用のデータをデータベースに作成しデバッグすることが多いと思います。 そのほうが、効率的ですし、実データは手に入らないかもしれません。

しかし、最終段階では、実データのデバッグが不可欠となります、システムの入れ替えであったり、旧システムのデータベースの流用 などの場合は実データは簡単に手に入れる事ができますが、新システムの場合は実データなるものは存在しません。

なので、仮のデータもいいので、実際の運用時に想定されるデータ量を作成し、テストしてみましょう。 データ量が増えただけで、発見できるバグも沢山あると思います。

納入後の不具合対応について

アプリケーションが完成し納入した後でも、バグの修正は引き続き行なわれます。

今度は自分でバグを探すというのではなく、エンドユーザーからのフィードバッグという形でバグが発見されていきます。 　電話やメール、または呼び出し等で、不具合の状況が伝えられてきます。

この時、注意しなくてはいけない事があります。 エンドユーザーの状況説明には、推測が含まれているということです。

例えば、「データベースに接続できなくて、データの一覧が表示されません」というメールがきたとします、 この中で「データベースに接続できなくて」という言葉、エンドユーザーは何を根拠にそう言っているのでしょう、 もしかしたら、「データが表示されないのはデータベースに接続できないからだ」という推測かもしれません。

調査を始める前にユーザーを確認したほうが懸命です。

必死にデータベース接続周辺を調査をしても、なにも見つからず、実は表示時の単純なバグであったということになりかねません。

もう1つ、システム、アプリケーションの規模にもよるのですが、不具合報告書という表を作って、エンドユーザーに渡しておきましょう 不具合報告書というのは、不具合を報告するための簡単なフォーマットです。

• 不具合発見日
• アプリケーションバージョンNo.
• 報告者名
• 不具合状況
• 対応報告

ぐらいで充分でしょう。

大切なことは、一不具合に対して一枚の報告書とすることです。 この方が管理し易いでしょう。

もし、膨大な数量になるのであれば、別に不具合リストなるもの作成し、シリアルNo.などを付けて 関係づけておきましょう。

エクセルで作成し、エクセルファイルと、10枚くらい印刷して渡しておきます。

全ての不具合をこのフォーマットに書いてくれると期待してはいけませんが、 何もフォーマットがないよりはずっと有効的ですし、ユーザー、担当者も慣れてくれば、 このフォーマットを利用するようになっていきます。

電話で直接、報告されても自分で報告書に書いておけば、管理もし易くなると思います。