境界値テストについては、以前の記事にてデシジョンテーブルと共に紹介しました。
しかし、以前の記事では紹介しきれていないことがあるので、別に記事を書いて紹介しようと思います。
表題の通りなのですが、有効桁数については、コーディング時にも気を付ける必要がありますし、境界値テストを行う際にも気を付ける必要があります。
有効桁数を見誤ると、境界値付近の値が与えられた場合に意図せぬ挙動を示すことがあります。
例えば、株価に応じて処理を変える必要がある場面において、以下のような条件指定をしたとします。
1 2 3 4 5 6 7 |
if (株価 >= 1 and 株価 <= 100) { … } else if (株価 >= 101 and 株価 <= 1000) { … } else if (株価 >= 1001 and 株価 <= 10000) { … } … |
そして、1つ目のif文と2つ目のif文の境界値を見るために、株価が99円・100円・101円・102円のテストケースを用意したとします。
これは一見正しそうに見えるのですが、有効桁数が見落とされており、バグを引き起こすコーディングであり、バグを発見できないテストケースです。
実は株価は1円単位とは限らず、0.1円単位のこともあります。
もし、ここで100.1円という株価が与えられた場合、1つ目のif文も2つ目のif文もすり抜けてしまい、意図せぬ分岐に進んでしまいます。
そして、テストケースでは100円より大きく101円より小さい値が設定されていないので、このバグを見つけ出すことができません。
正しくは、以下のようにコーディングするべきです。
1 2 3 4 5 6 7 |
if (株価 >= 1 and 株価 <= 100) { … } else if (株価 > 100 and 株価 <= 1000) { … } else if (株価 > 1000 and 株価 <= 10000) { … } … |
そして、1つ目のif文と2つ目のif文の境界値を見るテストケースとしては、最小桁数での境界を見ることができるように、株価が99.9円・100.0円・100.1円のテストケースを用意するべきです。
いかがでしたでしょうか。
今回紹介した例は、私が本当に目にしたことがあるバグです。
金融案件のように数字を扱う案件では発生しがちなバグだと思うので、有効桁数に気を付ける必要があるということを心に留めておきましょう。
コメント