読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

ソフトウェアテスト技法ドリル 第2章 線を意識する(2)

アドベントカレンダー23日目 第2章 線を意識する(2)

こんにちは。リリカルです。前回の続きでWACATEの予習です。

WACATE2016 夏 満員御礼!と 予習内容について - WACATEブログ

第2章 線を意識する

前回に続き、境界値分析や同値分割の例題が扱われています。実数の境界値分析における考え方や、複数の変数の同値分割と境界値分析についてです。ここでは問題は割愛しますが、ここで注意するのは「異常値は他の異常値を隠す」ということです。

これは意外とやりがちです。(特に、テストを急いで終わらせようとしたり、テストケース数をなるべく減らそうとした時に)

ドリル本の例では「アルファベットの大文字・小文字、数値のみが入力可能」というのと「文字列長は5〜30文字」という仕様に対して、"@ABC"といったテストデータを使うとどうなるか、ということが書かれています。

一見、ここでエラーとなれば「特殊文字でエラーになる」と「文字列長が5文字未満だとエラー」の、一度に二つの要素が確認できるように思えますが、これでは一体どちらが原因となってエラーとなったのか外からではわかりません。あるいは、特殊文字を先にチェックするロジックが組まれていたらそもそも文字列長は見ない実装になっているかもしれません。

このテストケースは何を確認したいものか?」というのは常に意識すべきです。これはドリル本p.26のテストデータの例に「本テストデータを選んだ理由」という欄があることからもうかがえます。そして、一度に検証できる異常値は1つであるということも覚えておくべきことです。

バグの検出に有効なテストケースを絞り込むという文脈においてテスト技法を使うことは大切ですが、それ以前に必要なテストが漏れてしまってはどうしようもありません。発散させてないのに収束させようとしているわけですから、余計にテストの質が下がってしまいます。

ドリル本ではこのほかに、日付と時刻における境界値分析、ループ境界のような隠された境界値、負荷テストについても扱っています。

隠された内部的な値を使ってテストするのはグレーボックステストとも言われ、とても重要です。自分も、以前テストしていた時に全く意識していなかった境界からバグが出て、「なぜ?」と開発者に聞いてみたら、全く想像していなかったステータス値が制御に使われていたことがありました。こう言った実装に近い話はぜひ首を突っ込んで聞いてみるといいと思います。開発者にとっては当たり前の情報も、テストする側にとっては宝のような情報となることがあります。

次回予告

次回は第3章、「面で逃さない」に入っていきます。