プログラマは毎回慎重にプログラムを作成していますが、如何しても一定数のバグが発生してしまいます。
そこで今回はバグが発生する仕組みについて考えて見ます。
ベテランはバグを出さないの?
ベテランプログラマが作成したプログラムは、バグが発生しにくいものです。
しかし、ベテランプログラマは作成したプログラム初めて実行するときにも、バグは存在しないのでしょうか?
そのような事は、ほとんど無いと思います。
ベテラン・新人を問わず、プログラマが作成したプログラムを同僚やお客さんに渡す前には、動作確認(テスト)を行います。
自分がテストを行ってバグを見つけた場合は、プログラマは自分で修正してから、プログラムの完成を宣言すると思います。
一般的に「バグが発生した」とは、プログラマが「完成した」と宣言して、他の人プログラムが渡った状態でバグが発見された事をいうと思います。
プログラムをテストしているなら、バグが残っている状態で他の人に渡る事は無いはずです。
しかし、バグが残った状態で他の人の手に渡ります。
これはバグが発生する条件を、プログラマがテスト出来ていない事から発生します。
すべてはテスト出来ない
自分は今日、映画館に行きました。
映画の鑑賞料金は年齢別に次の4パターンになっていました。
一般 ¥1,800
高校生・大学生 ¥1,500 *要学生証
中学生・小人(3歳以上) ¥1,000
シニア(60歳以上) ¥1,000 *要年齢証明
このお客さんから申告された4パターンに対して、料金を返すプログラムを作成したとしたら、テストは4パターンを行えは良い事になります。簡単にテストできそうです。
しかし注意書きがあるように、高校生・大学生とシニアは証明書が必要です。
証明書が無い場合は一般料金になります。
高校生・大学生とシニアの場合に証明書のチェックを入れると、証明書の在り無しで2パターン増えて、合計6パターンのテストが必要になりました。
テストの数は増えましたがキチンとテストすれば、まだバグを出さないで済みそうです。
しかし、よく考えてください。
シニアの年齢証明書に記載されている年齢が、何歳でもシニア料金にして良いのでしょうか。
年齢証明書に書かれている年齢ごとに、正しく料金が返る事をテストしようとすると。。。
100パターン以上はテストが必要になりそうです。
これでは、すべてのパターンをテストする事は出来ません。
多くのバグは多すぎるパターンをテスト出来ない事から発生します。
パターンを削減する
先ほどのシニアの年齢証明書のテストは、以下の2パターンくらいで収める事ができると思います。
年齢証明書の年齢が60歳の場合は、シニア料金
年齢証明書の年齢が59歳の場合は、一般料金
プログラムの実装方法にもよりますが、年齢証明書の年齢が60以上になっているか比較する事で、シニア料金で鑑賞できるか判定している事が多いと思います。
その場合は、比較を行うプログラムが正しく動作しているのかをテストする事で、目的を達成する事ができます。
ここで利用した技法を「境界値分析」と呼びます。
しかし、これは比較をプログラムで行っている場合にのみ有効です。
もしも、プログラム内部で年齢1歳刻みの料金データベースを利用している場合は、多くのバグを見逃してしまうでしょう。
テストケースを設計する
バグが出ないプログラムを作成するプログラマは、テストすべきパターンを効率よく作成出来るプログラマである事が多いです。
先ほどのように、年齢別にどのような料金が適用されるべきなのか、料金が適用されるための条件などをまとめた物を「テストケース」と呼びます。
ユーザーの手にバグが発生するプログラムを渡さないためには、優れたテストケースを設計することが、大切な条件になります。
0 件のコメント:
コメントを投稿