ブラックボックステスト

『知識ゼロから学ぶ　ソフトウェアテスト』   高橋寿一著　　
　ブラックボックス




3. エンジニアが最もよく使う手法　ブラックテスト

ブラックボックステストは、プログラムを一種のブラックボックスと見立て、様々な入力を行うことによって、ソースコードを利用せずにテストを行う手法です。ほとんどのソフトウェアのテストがブラックボックステスト手法で行っています。それでは、ブラックボックステストの手法を紹介していきます。


同値分割法


予定の作成を例にとります。月を入力する際には、1~12までの整数を入れる必要があります。ここでは、1~12までの整数が有効同値、０以下の整数＆13以上の整数は無効同値になります。その値を実際に入れてソフトウェアが十分対応できるかを確認するテスト手法です。
ここで考えるべきことは、組み合わせです。予定作成で必要なのは月入力だけではありません。日を入力する必要もあります。日も当然のように、0以下の整数&32(または31など)以上の整数は無効同値です。
「月は有効同値にして、日は無効同値に・・・」といったように全てのテストケースを抜き出すと、非常に時間がかかることはお分かりでしょう。ソフトウェアのテスト現場では、ある程度この無効同値のテストを省略する必要が出てきます。もちろん省略されたテストケースでバグが出ることは許されません。
実践的なテストケースを考える必要が出てくるわけです。

境界値分析法
同値分割法と境界値分析法は常にセットで用いられる方法であることを覚えていてください。
これは、その名の通り、境界をテストすることになります。
上の予定作成の例を考えると、テストすべきとこは、無効同値の上限である0と有効同値の下限である１、有効同値の上限である12と無効同値の下限である13をテストします。

＊）現場の常識として、ゼロは常に境界値になります。入力値としてゼロが許されている場合は必ずゼロを入力する必要があります。


実践としてまとめます。
データを入力する機能がある場合、かならず『よいデータ』と『悪いデータ』を入力します。
<よいデータ>
・ユーザーがよく使いそうなデータ
・プログラムが許す最小のデータ
・プログラムが許す最大のデータ
・ゼロ（もしくは悪いデータとして）
・５cデータ
<悪いデータ>
・非常に小さなデータ
・非常に大きなデータ
・長いデータ
・無効なデータ


ディシジョンテーブル
ディシジョンテーブルテストも非常に古くから用いられている手法です。ディシジョンテーブルでは、全ての入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記します。表にまとめることで全体のテスト構成を見ることができ、テストケースの抜けを発見しやすくなります。
ただし、多くの項目がある場合だと表を用いることが困難になるので、兼ね合いも考える必要がでてきます。


状態遷移テスト
状態遷移テストとは、「状態」をモデル化してテストを行う手法といえます。
状態遷移には、以下の図のように、大きく分けて状態（state）と遷移（transition）の２つによって表現されます。



ソフトウェアには、ある程度ユーザの操作に制限を加える必要があります。
そうしないと、大量のコードが必要になったり、思わぬとこでバグを生じたりと様々な不具合が発生するからです。
そのために、「状態(state)」という概念が生まれました。

一応の補足として、中には、状態の区別がはっきりしないソフトウェアもあります。
Linuxのコマンドラインインターフェースには、状態遷移テストを仕様する利点がほとんどありません。
なぜなら、いつでも全てのコマンドを受け入れる状態になっているため、状態が１つしかないからです。

さて、状態遷移テストで見るかるバグを紹介します。
・期待していない状態に遷移するバグ
これは、分岐やswitch文が正しく書かれていない場合に起こるバグです。
・遷移自体がない場合
ある状態からある状態に遷移できないバグを発見することができます。

状態遷移テストの問題点を挙げます。
状態遷移テストの場合はいくつか問題点が指摘されています。状態数が増えると、モデルが複雑化します。モデリングに時間がかかりすぎて実際にテストする時間が減ることさえあります。
本格的にソフトウェアテストが必要とされるアプリケーションでは、複雑でモデリングが難しいので、ツールを使うのは必須でしょう。

ランダムテスト
ランダムテストとは、いきあたりばったり、何も考えもなしに入力や操作を行う手法です。
問題点は、山のようにあります。
例えば、テスト手法にのっとったやり方で見つからないバグはありませんが、ランダムテストで見つからないバグは多岐にわたります。

とはいえ、このテスト手法は荒っぽいやり方ながら結構なバグが見つかってしまうところが問題です。全くテストをしていないソフトウェアの倍胃、全体の10％はランダムテストで見つかるとも言われています。

しかし、正当なテスト手法でないため、見つかったバグの何倍ものバグがプログラムの中に潜んでいることを認識すべきです。そして、そのバグは、ランダムテストでは見つからないことも認識すべきです。


＊）ランダムテストが有効な場合だってあります。
たくさんの数をランダムに入力するプログラムを作成して、自動化しておくと、威力を発揮することがあります。
例えば、日本語入力テストなどでは、ご存知のように漢字は数万語もあり、その境界値を見つけるのは、かなり面倒です。そんなときは自動化ツールを使ってランダムに日本語を生成し一昼夜走らせておくのも１つの手です。